Know thy WebLogic configuration using Puppet

Know Thy configuration “I would like to start using a configuration management tool like Puppet, but I don’t know how my system is configured!” In the era before configuration management tools, most systems would be built by hand. Command by command the system would be configured. If the sysadmin would spot a problem, he would fix it immediately. Change after change, this process would continue. Resulting in a running system but with a configuration that’s is not fully known and definitely not repeatable. In this blog article, we are going to show you how Puppet can not only manage your configuration, but also help you to get to know all the details of your configuration.

Puppet inner workings

To do this, first let’s look at Puppet’s inner workings. Puppet uses roughly the following process when managing your configuration:

  1. It makes a list of all known resources on your system
  2. It gathers all properties of these resources
  3. It compares them to the specified manifest
  4. Based on the comparison, Puppet makes a list of actions to execute to ensure the resource list and the manifest are equal.

What if we could extract the list of resources and all their properties after step 2? Then we would have a description of the current configuration. Puppet allows you to do this with the command puppet resource.

Let’s do it.

To show you how to do this, we are going to reverse engineer the configuration of host wls1 in our reference implementation. You can find it here. To get this system up and running, check out the blog post “Using Puppet to install and manage your WebLogic infrastructure”.

Let’s get back to what we described in the intro. Puppet makes a list of all known resources. But what resources does Puppet know? Puppet knows about all the resource he can find a type for. Sometimes types are also called custom types. When you install the wls_config module, you install a set of custom types that known about WebLogic. They provide Puppet with all the knowledge required to make a list of all WebLogic resources and change them if needed. If for example, we want to see how the WebLogic domain is configured, we use the wls_domain resource.

$ puppet resource wls_domain
wls_domain { 'wlsonly/wlsonly':
  ensure                                            => 'present',
  exalogicoptimizationsenabled                      => '0',
  jmx_platform_mbean_server_enabled                 => '0',
  jmx_platform_mbean_server_used                    => '1',
  jpa_default_provider                              => 'org.eclipse.persistence.jpa.PersistenceProvider',
  jta_max_transactions                              => '10000',
  jta_transaction_timeout                           => '30',
  log_date_pattern                                  => 'MMM d, yyyy h:mm:ss a z',
  log_file_min_size                                 => '5000',
  log_filecount                                     => '10',
  log_filename                                      => '/data/logs/wlsonly.log',
  log_number_of_files_limited                       => '1',
  log_rotate_logon_startup                          => '0',
  log_rotationtype                                  => 'byTime',
  security_crossdomain                              => '1',
  setconfigurationaudittype                         => 'none',
  setinternalappdeploymentondemandenable            => '1',
  web_app_container_show_archived_real_path_enabled => '0',
}

Puppet used the knowledge of the wls_domain custom type in the wls_config module, to go into WebLogic and get all attributes of the domain. If you asked Puppet to apply this configuration, Puppet would see that there are no differences and do nothing. Let’s test this. Put the output of puppet resource into a file and use Puppet to do its work.

$ puppet apply domain.pp
Notice: Compiled catalog for scratch.debian in environment production in 0.69 seconds
Notice: Applied catalog in 6.76 seconds

Puppet tells you it compiled the catalog and applied it. But it didn’t do anything. For sake of argument let’s see what happens if we change a value in the manifest.

$ puppet apply domain.pp
Notice: Compiled catalog for scratch.debian in environment production in 0.62 seconds
Notice: /Stage[main]/Main/Wls_domain[wlsonly/wlsonly]/jta_transaction_timeout: jta_transaction_timeout changed '30' to '20'
Notice: Applied catalog in 6.40 seconds

Here you see Puppet detected a difference between how WebLogic is configured now and how you told it to be configured. Then it executed an action to make sure the jta_transaction_timeout is set to 20.

But how does Puppet know…

We haven’t been totally honest. Because this system is configured using Puppet, it has some preexisting knowledge. So on what URL is the domain running on? What are the credentials required to connect? We have to provide Puppet this information. How do we do that? Again let’s ask Puppet.

$ puppet resource wls_setting
wls_setting { 'wlsonly':
  archive_path      => '/tmp/wls_config-archive',
  connect_url       => 't3://wls1.example.com:7001',
  custom_trust      => 'false',
  debug_module      => 'false',
  user              => 'weblogic',
  weblogic_home_dir => '/opt/oracle/middleware12/wlserver',
  weblogic_password => 'welcome01',
  weblogic_user     => 'weblogic',
}

Here you see a list of settings Puppet uses to connect to WebLogic and do it’s job. The wlsonly in this listing matches the first wlsonly in the title of the resource, e.g. wlsonly/wlsonly.

Packed with this information, we know what we can do to tell Puppet how to connect on systems without prior Puppet knowledge. We create a file containing the settings, and apply it. Here is how this could look:

$ puppet apply settings.pp
Notice: Compiled catalog for scratch.debian in environment production in 0.53 seconds
Notice: /Stage[main]/Main/Wls_setting[mydomain]/user: defined 'user' as 'weblogic'
Notice: /Stage[main]/Main/Wls_setting[mydomain]/weblogic_home_dir: defined 'weblogic_home_dir' as '/opt/oracle/middleware12/wlserver'
Notice: /Stage[main]/Main/Wls_setting[mydomain]/weblogic_user: defined 'weblogic_user' as 'weblogic'
Notice: /Stage[main]/Main/Wls_setting[mydomain]/connect_url: defined 'connect_url' as 't3://mywlsnode.example.com:7001'
Notice: /Stage[main]/Main/Wls_setting[mydomain]/weblogic_password: created password
Notice: /Stage[main]/Main/Wls_setting[mydomain]/debug_module: defined 'debug_module' as 'false'
Notice: /Stage[main]/Main/Wls_setting[mydomain]/archive_path: defined 'archive_path' as '/tmp/wls_config-archive'
Notice: /Stage[main]/Main/Wls_setting[mydomain]/custom_trust: defined 'custom_trust' as 'false'
Notice: Applied catalog in 0.05 seconds

Connecting to a different node

In the example you can see, we configure the connection URL. This means that you can do these commands on a different system than the actual node you are investigating. So you can leave your production system as it is now and use an other system, to get the configuration information. Requirement is that on the system you are running this code on, WebLogic software is installed.

What resources support this functionality?

So now we now how to tell Puppet to connect to our domain and how to get configuration information about a set of resources, but what resource types are available? Well, almost all Puppet types in the wls_config module support this functionality. So it is very easy to get a full list of your configuration. Here is a simple script you can use to get them:

#!/bin/bash 
function query {
  echo "querying $1"
  puppet resource $1 >> weblogic_config.pp
}  


echo '' > weblogic_config.pp
query wls_authentication_provider
query wls_cluster
#... (rest removed)

You can download the full script over here and get a full overview of all details of the WebLogic configurations of your domain. Only the wls_bsu and the ` wls_opatch` types don’t support this functionality. So you will have to figure out what patches are installed your self.

Are we done…?

Do we have ALL information needed to build a full copy of the domain? Based on our past experiences, this approach gives you between 80 and 100% of your WebLogic configuration. This, of course, depending on the depth and size of your domain configuration. To get a feel for the things that are still different and/or missing, you can compare the domain.xml of the original system and a domain.xml of a domain built by Puppet based on this information. If you need it, we also have a utility to make a CSV dump of your full configuration. Contact us if you need this.

The extracted Puppet description is a set of raw resources. When you want to build this into a real manifests, it helps to extract parts into Puppet classed or defined types and use variables for things that are variable. But this approach sure gets you going good and fast.

Now take control of YOUR WebLogic configuration

I hope this blog post has showed you how Puppet can help you extract the configuration of your WebLogic domain. This is even valuable when you are not planning on using Puppet as a system to manage your configuration. Our wls_config provides all the knowledge to extract a large part of the WebLogic configuration from your running domain. All you have to do is extract it and change it to your new needs. Hope this helps you to take control of YOUR WebLogic configuration.