Add managed server(s) to your domain

After you have installed your software and created your primary domain, most of the time, you need to have some specific WebLogic servers. You can do this by adding some data to your hiera data.

In the editor tab, go to the directory hierdata\nodes and open the file wls01.playground.enterprisemodules.com. This file contains all the node-specific data.

Now uncomment this data:

# wls_profile::servers:
#  wls01:
#    machine_name:    wls_machine_1
#    listenaddress:   localhost.localdomain
#    server_arguments: []

This data tells Puppet to ensure that the server wls01 needs to be available with the specified listen address. Make sure that you save the changes before continuing. See the documentation what kind of properties you can use.

First Puppet run

Puppet runs will read this data and make sure the servers are available with the specified properties. Puppet will detect that the servers is unknown and create it since we will apply Puppet for the first time with this data.

puppet apply site.pp 

To inspect if the server was created, type the following command. This is the information Puppet provides you about the servers it manages. Because Puppet fetches all available information about all servers, this command can take up a significant amount of time.

puppet resource wls_server

Somewhere in the middle of the output, you’ll see:

wls_server { 'MYDOMAIN/wls01'
  ensure                                               => 'present',

So Puppet created the server.

Second Puppet run

One of the essential features of Puppet is that it is idempotent. Idempotent means it will not apply changes a second time. So if we rerun Puppet, it should see that the servers already exists with the specified properties and do nothing.

Let’s verify that and rerun Puppet:

puppet apply site.pp 

We still see the message at the top that Puppet manages the servers. To check if any new servers were created, type the puppet resource command one more time.

puppet resource wls_server

The output is the same as it was after the first run, so Puppet didn’t create any new server.

Add cluster(s) to your domain

After setting up the server, you also migt need a WebLogic cluster. You can do this by adding some data to your hiera data.

In the editor tab, go to the directory hierdata\nodes and open the file wls01.playground.enterprisemodules.com. This file contains all the node-specific data.

Now uncomment this data:

# wls_profile::admin_server::wls_cluster::cluster_name: cluster1
# wls_profile::admin_server::wls_cluster::domain_name: mydom
# wls_profile::admin_server::wls_cluster::cluster_defaults:
#   messagingmode:  unicast
#   migrationbasis: consensus                          

This data tells Puppet to ensure that the server cluster1 needs to be available in the specified domain. By default servers in the cluster are set to the value of wls_profile::servers set in the previous tab. See the documentation what kind of properties you can use.

First Puppet run

Puppet runs will read this data and make sure the cluster is available with the specified properties. Puppet will detect that the cluster is unknown and create it since we will apply Puppet for the first time with this data.

puppet apply site.pp 

Let’s inspect the Puppet output. Somewhere near the top, you’ll see:

Notice: WebLogic cluster cluster1 with servers 

This is the information Puppet provides you about the WebLogic clusters it manages. When you look at the Puppet output, somewhere near the end, you will see this:

Notice: /Stage[main]/Wls_profile::Admin_server::Wls_cluster/Wls_cluster[mydom/cluster1]/ensure: created

So Puppet created the cluster.

Second Puppet run

One of the essential features of Puppet is that it is idempotent. Idempotent means it will not apply changes a second time. So if we rerun Puppet, it should see that the cluster already exists with the specified properties and do nothing.

Let’s verify that and rerun Puppet:

puppet apply site.pp 

We have no longer have the creation message, just as we expected.

Inspecting the WebLogic clusters

Just like with the wls_server, you can also inspect WebLogic clusters with puppet

puppet resource wls_cluster

Because Puppet fetches all available information about all servers, this command can take up a significant amount of time.

Add datasources to your domain

After you have installed your software and created your primary domain, most of the time, you need to have a WebLogic cluster. You can do this by adding some data to your hiera data.

In the editor tab, go to the directory hierdata\nodes and open the file wls01.playground.enterprisemodules.com. This file contains all the node-specific data.

Now uncomment this data:

wls_profile::admin_server::wls_datasources::list:
  MYDOMAIN/my_datasource_1:
    ensure: present

This data tells Puppet to ensure that the datasource my_datasource_1 needs to be available in the specified domain. Make sure that you save the changes before continuing. See the documentation what kind of properties you can use.

First Puppet run

Puppet runs will read this data and make sure the datasource is available with the specified properties. Puppet will detect that the datasource is unknown and create it since we will apply Puppet for the first time with this data.

puppet apply site.pp 

Let’s inspect the Puppet output. Somewhere near the top, you’ll see:

Notice: WebLogic Datasources MYDOMAIN/my_datasource_1 

This is the information Puppet provides you about the datasources it manages. When you look at the Puppet output, somewhere near the end, you will see this:

Notice: /Stage[main]/Wls_profile::Admin_server::Wls_datasources/Wls_datasource[MYDOMAIN/my_datasource_1]/ensure: created

So Puppet created the datasource.

Second Puppet run

One of the essential features of Puppet is that it is idempotent. Idempotent means it will not apply changes a second time. So if we rerun Puppet, it should see that the datasource already exists with the specified properties and do nothing.

Let’s verify that and rerun Puppet:

puppet apply site.pp 

We still see the message at the top that Puppet manages the datasource, but we no longer have the creation message, just as we expected.

Inspecting the datasources

Just like with the wls_server, you can also inspect WebLogic datasources with puppet

puppet resource wls_datasource

Because Puppet fetches all available information about all servers, this command can take up a significant amount of time.

Add JMS resources to your domain

After you have installed your software and created your primary domain, often, you need to have WebLogic JMS modules, queues and topics. You can do this by adding some data to your hiera data.

In the editor tab, go to the directory hierdata\nodes and open the file wls01.playground.enterprisemodules.com. This file contains all the node-specific data.

Now uncomment this data:

wls_profile::admin_server::wls_jms::module_list:
  MYDOMAIN/my_first_module:
    ensure: present

wls_profile::admin_server::wls_jms::queue_list:
  MYDOMAIN/my_first_module:my_first_queue:
    ensure: present

wls_profile::admin_server::wls_jms::topic_list:
  MYDOMAIN/my_first_module:my_first_topic:
    ensure: present

This data tells Puppet to ensure that the module my_first_module needs to be available with the specified queue, and topic in MYDOMAIN. Make sure that you save the changes before continuing. See the documentation what kind of properties you can use for queues. See the documentation what kind of properties you can use for topics.

First Puppet run

Puppet runs will read this data and make sure the WebLogic JMS configuration is available with the specified properties. Puppet will detect that the WebLogic modules, queues and topics are unknown and create them since we will apply Puppet for the first time with this data.

puppet apply site.pp 

Let’s inspect the Puppet output. Somewhere near the bottom, you’ll see:

Notice: /Stage[main]/Wls_profile::Admin_server::Wls_jms/Wls_jms_module[MYDOMAIN/my_first_module]/ensure: created
Notice: /Stage[main]/Wls_profile::Admin_server::Wls_jms/Wls_jms_queue[MYDOMAIN/my_first_module:my_first_queue]/ensure: created
Notice: /Stage[main]/Wls_profile::Admin_server::Wls_jms/Wls_jms_topic[MYDOMAIN/my_first_module:my_first_topic]/ensure: created

So Puppet created the WebLogic JMS module, the queue and the topic.

Second Puppet run

One of the essential features of Puppet is that it is idempotent. Idempotent means it will not apply changes a second time. So if we rerun Puppet, it should see that the wls_jms already exists with the specified properties and do nothing.

Let’s verify that and rerun Puppet:

puppet apply site.pp 

We still see the message at the top that Puppet manages the WebLogic JMS co nfiguration, but we no longer have the creation message, just as we expected.

Inspecting the WebLogic JMS configuration

Just like with the wls_server, you can also inspect WebLogic modules, queues and topics with puppet

puppet resource wls_jms_module
puppet resource wls_jms_queue
puppet resource wls_jms_topic

Because Puppet fetches all available information about all servers, this command can take up a significant amount of time.

Add WebLogic users and groups to your domain

Most of the time, you need to setup groups and users in your domain. You can do this by adding some data to your hiera data.

In the editor tab, go to the directory hierdata\nodes and open the file wls01.playground.enterprisemodules.com. This file contains all the node-specific data.

Now uncomment this data:

# wls_profile::admin_server::wls_users_and_groups::group_list: 
#   MYDOMAIN/group_1:
#     ensure: present
#     users:
#       - user_1
#       - user_2
#   MYDOMAIN/group_2:
#     ensure: present
#     users:
#       - user_2
#       - user_3

This data tells Puppet to ensure that the groups group_1, group_2, users user_1, user_2 and user_3 needs to be available on the server in the specified domain MYDOMAIN. Make sure that you save the changes before continuing. See the documentation what kind of properties you can use.

First Puppet run

Puppet runs will read this data and make sure the groups and users are available with the specified properties. Puppet will detect that the groups and users are unknown and create it since we will apply Puppet for the first time with this data.

puppet apply site.pp 

Let’s inspect the Puppet output. Somewhere near the top, you’ll see:

Notice: WebLogic Groups and Users

This is the information Puppet provides you about the groups and users it manages. When you look at the Puppet output, somewhere near the end, you will see this:

Notice: /Stage[main]/Wls_profile::Admin_server::Wls_users_and_groups/Wls_user[MYDOMAIN/user_1]/ensure: created
Notice: /Stage[main]/Wls_profile::Admin_server::Wls_users_and_groups/Wls_user[MYDOMAIN/user_2]/ensure: created
Notice: /Stage[main]/Wls_profile::Admin_server::Wls_users_and_groups/Wls_group[MYDOMAIN/group_1]/ensure: created
Notice: /Stage[main]/Wls_profile::Admin_server::Wls_users_and_groups/Wls_user[MYDOMAIN/user_3]/ensure: created
Notice: /Stage[main]/Wls_profile::Admin_server::Wls_users_and_groups/Wls_group[MYDOMAIN/group_2]/ensure: created

So Puppet created the groups and users.

Second Puppet run

One of the essential features of Puppet is that it is idempotent. Idempotent means it will not apply changes a second time. So if we rerun Puppet, it should see that the groups and users already exist with the specified properties and do nothing.

Let’s verify that and rerun Puppet:

puppet apply site.pp 

We still see the message at the top that Puppet manages the groups and users, but we no longer have the creation message, just as we expected.

Inspecting the WebLogic users and groups

Just like with the wls_server, you can also inspect WebLogic users and groups with puppet.

puppet resource wls_user
puppet resource wls_group

Because Puppet fetches all available information about all servers, this command can take up a significant amount of time.

You like it?

Do you like what you see here and want to test this on your own infrastructure? No problem. You can sign up for a free trial.

If you have any questions, don’t hesitate to contact us.