Using Puppet to install and manage your WebLogic infrastructure

WebLogic Installed Without any tools, the installation and configuration of a WebLogic infrastructure is a big and complex task. Fortunately, our WebLogic installation and configuration modules make the task automatable and repeatable. But we know from our customers, that whitout any guidelines, it is still difficult to get started. There is so much to configure and so much install that it is hard to figure out where to start. To help you, we have implemented some extensive examples. In this blog post, I’m going to take you trough the setup we have made for a basic WebLogic installation.

Get the examples

We have created a git repository that contains an example on how to best use our Oracle and WebLogic modules. In there we show you how to use best our modules. We are going to use this repository.

Go to your preferred working directory and enter:

$ git clone

This will create a local copy.

Although this repository is called a reference implementation, it is by no means the only way to do stuff. In general, there are many more methods you can use. We have chosen some methods we think are working best in large enterprise setups. But because we learn every day, this repository will change in time. Wat was the best today might be superseded by something better tomorrow.

The tools of trade

The repository contains a setup that is targeted at Enterprises. But we have designed it, so you run parts of it on your own Workstation running Vagrant and VirtualBox. So to get started, you’ll need Vagrant and VirtualBox. You can find the information on how to install VirtualBox here at the VirtualBox website. Vagrant To install Vagrant, go to the vagrant downloads page, and download the package for your platform. Then install it using standard procedures for your operating system. Because we only use Puppet inside the virtual machine, you don’t need to install Puppet on our workstation.

Required software

The examples repository doesn’t contain the Oracle or Puppetlabs software needed to get the nodes running. You’ll need to download these yourself and put them in the software directory. In the README, you can find a list of the software needed when you want to run all of the boxes. For our example we only need:

Masterless Puppet

Most of our clients use Puppet Enterprise. So the examples contain a full blown implementation using Puppet Enterprise 2005.2. To allows us to focus on the WebLogic part; we are going to use the masterless version. This will install Puppet on the Vagrant machine and run it local. You only need one Virtual Machine.

All set….go

Before we dive in and explain some things, let’s first get our WebLogic machine up and running.

$ vagrant up ml-wls1

This will start Vagrant, create a virtual machine and start Puppet. This is how it should look.

Bringing machine 'ml-wls1' up with 'virtualbox' provider...
==> ml-wls1: Importing base box 'puppetlabs/centos-6.6-64-puppet'...
==> ml-wls1: Matching MAC address for NAT networking...
==> ml-wls1: Checking if box 'puppetlabs/centos-6.6-64-puppet' is up to date...
==> ml-wls1: Setting the name of the VM: reference_implementation_ml-wls1_1447585083469_97072
==> ml-wls1: Fixed port collision for 22 => 2222. Now on port 2200.
==> ml-wls1: Clearing any previously set network interfaces... removed...

==> ml-wls1: Setting hostname...
==> ml-wls1: Configuring and enabling network interfaces...
==> ml-wls1: Mounting shared folders...
    ml-wls1: /vagrant => /Users/hajee/Dropbox/enterprisemodules/examples/reference_implementation
==> ml-wls1: Running provisioner: shell...
    ml-wls1: Running: /var/folders/r0/r9sl0ryd1l34fcxy5v3wzgfc0000gn/T/
==> ml-wls1: Installing required gems
==> ml-wls1: Successfully installed thor-0.19.1
==> ml-wls1: Successfully installed librarianp-0.6.3 removed...

==> ml-wls1: Successfully installed faraday-0.9.2
==> ml-wls1: Successfully installed multi_json-1.11.2
==> ml-wls1: Successfully installed awesome_print-1.6.1
==> ml-wls1: 17 gems installed
==> ml-wls1: Installing required puppet modules
==> ml-wls1: Setting up hiera directories
==> ml-wls1: Setting up Puppet module directories
==> ml-wls1: Setting up Puppet manifest directories
==> ml-wls1: Running provisioner: shell...
    ml-wls1: Running: inline script
==> ml-wls1: Notice: Compiled catalog for in environment production in 9.10 seconds
==> ml-wls1: Notice: /Stage[setup]/Em_license::Copy/File[/etc/puppetlabs/puppet/em_license]/ensure: created
==> ml-wls1: Notice: /Stage[main]/Timezone/File[/etc/sysconfig/clock]/content: content changed '{md5}c5daf08a96d4decb4886f54d6a280348' to '{md5}9926b9918f0c50c6af273e1995024147' removed...

Wls_install::Managed_server[wls2]/Wls_server[wlsonly/wls2]/ensure: created
==> ml-wls1: Notice: /Stage[main]/Profile::Wls::Wlsonly::Domain/Wls_cluster[wlsonly/WlsOnlyCluster]/ensure: created
==> ml-wls1: Notice: /Stage[main]/Profile::Wls::Wlsonly::Domain/Wls_install::Support::Nodemanagerautostart[wlsony_nodemanager]/File[/etc/init.d/nodemanager_wlsonly]/ensure: defined content as '{md5}fd3ba830e6b3557c53e9b326fb1c5247'
nodemanager_wlsonly]/returns: executed successfully
==> ml-wls1: Notice: Applied catalog in 231.78 seconds

Done. You now got a full running WebLogic domain running. You can access it from your workstation by opening the webbrowser and going to address and logging in with weblogic and password welcome01.

The structure

To get WebLogic installed and configured, we have used a Puppet pattern that is called ‘profiles and roles’. You can find more information about the pattern here at the puppetlabs website.

Connect backend for Hiera

We love hiera, but we for big configurations, we dislike yaml. Because the example is targeted at big setups, we are using Connect. Connect is a flexible hiera backend that allows for example including files and easy referencing (connecting) other values. In a future blog post we will dive into connect, and why we think it is a good replacement for yaml-files.

In our setup we have applied the role role::wls::wlsonly_master to our system. You can find this here. To look at what this role does, let’s look at the manifest describing it. You can find that in the file /modules/role/manifests/wls/wlsonly_master.pp. Here is the content:

class role::wls::wlsonly_master()
  contain profile::base::config 
  contain profile::base::hosts
  contain profile::wls::os
  contain profile::java
  contain profile::wls::software
  contain profile::wls::wlsonly::domain

  Class['profile::base::hosts'] ->
  Class['profile::wls::os'] ->
  Class['profile::java'] ->
  Class['profile::wls::software'] ->

It show’s you the major steps done:

  1. profile::base::config - This is the base configuration of the system. It applies all stuff needed for all of our systems.
  2. profile::base::hosts - This defines all the nodes (/etc/hosts) we need to run our examples.
  3. profile::wls::os - This applies all OS-specific parameters and packages we need to get WebLogic software up and running.
  4. profile::java - This install the Java software
  5. profile::wls::software - This install the WebLogic software
  6. profile::wls::wlsonly::domain - This create’s and configures our domain.

Although all parts are interesting, in this blog post we are going to focus on the way we setup and configure our WebLogic domain.

The domain

In the role definition, we saw that the domain is configured in profile::wls::wlsonly::domain. Let look into that.

class profile::wls::wlsonly
  contain profile::wls::wlsonly::domain

Because we focussed on WebLogic only, this is a simple profile. It redirects to profile::wls::wlsonly::domain. We have chosen to use this extra level of abstraction to allow other building blocks to be included as well. You - could for example - include a profile that creates all required JMS queue’s and datasources.

Domain parameters

When we open the profile, we see a list of parameters:

class profile::wls::wlsonly::domain(
  String  $domain_name,
  String  $nodemanager_address,
  Integer  $nodemanager_port,
  String  $adminserver_address,
  Integer $adminserver_port,
  String  $domains_dir,
  String  $apps_dir,
  String  $os_user,
  String  $weblogic_user,
  String  $weblogic_password,
  String  $weblogic_home_dir,
  Integer $version,
  Array   $admin_server_arguments,
  Hash    $servers,

These parameters allow you to tweak all sorts of stuff you need for a WebLogic domain. If you want to use a specific user on the OS level, you can set $os_user. If you want your WebLogic admin server to run on a specific port number, you can set ` $adminserver_port`. This is the level you would want to specify the specifics for your organization.

Single node or cluster

In profile::wls::wlsonly::domain, the first significant part of the domain creation, is the specification of the machines and servers that are going to take part in the domain.

# This statement creates all machines and WebLogic servers. The content of
# the $servers variable are read through hiera. Here you ca decide if your configuration
# is a single node system or a multi-node cluster. The nodes and machines them selfs are 
# created after the domain is created.
create_resources('wls_install::cluster_node', $servers, $defaults)

We have chosen to put the names and definitions of the machines and servers into hiera. This makes it possible to use the same Puppet code no matter if your domain contains one server and one machine or if you are building a large cluster with multiple servers and multiple machines.

When we look at our node config. we see that in this example we use a two node setup.

wls_server('wls1') do
  machine_name:  'wls_machine_1',
  listenaddress: host('').ip,

wls_server('wls2') do
  machine_name:  'wls_machine_2',
  listenaddress: host('').ip,

with profile::wls::wlsonly::domain:: do
  domain_name = 'wlsonly'
  servers = {

This setup always create’s a WebLogic Cluster. If you specify just one machine, it will be a one machine cluster, but still a cluster.


We hope this article helped you not only to get a basic WebLogic system up and running, but also provided you with some insights on how we have structured it. And last but not least to get you started with a setup for your own infrastructure. We feel [our modules]/shop) make it easy to get your WebLogic installation up and running. Please let us know what you think! In future blog posts we will also describe Oracle Database setups and a setup for Fusion Middleware.