The installation and configuration of a WebLogic domain contains the following steps and puppet classes.
The top level class is the role class class role::wls::wlsonly_master. This class calls the next set
of profile classes
contain profile::base
contain profile::wls::os
contain profile::java
contain profile::wls::software
contain profile::wls::wlsonlyThe purpose of these classes are:
Configure your system with all basic settings you like and need.
Configure all os based stuff needed to run WebLogic
Install java jdk
Install the WebLogic software
create the domain and do all domain configuration including creating and starting the admin server and the node manager. Let's jump into this class and see what is contains.
class profile::wls::wlsonly
{
contain profile::wls::wlsonly::domain
#
# For every datasource create a class. This helps in easy management of parameters.
#
contain profile::wls::wlsonly::datasources::ds0
contain profile::wls::wlsonly::jms
...This class creates the domain and starts the admin server and the nodemanager. We will digg into this one later.
This class contains all code for creating the datasource ds0. If you need mor datasources you can either add them here, or create one datasources class containing all other datasources.
This class contains all JMS related puppet code. Here we create the JMS servers the queue's topics and all JMS related stuff. Just like with the datasource, sometimes we add an other layer.
This class contains some real puppet resources. When puppet reaches this code, the java and WebLogic software is installed, but no domain and domain content is created.
First important step is to create the domain
#
# Here you create your domain. The domain is the first thing a WebLogic installation needs. Here
# you also decide what kind of domain you need. A bare WebLogic
#
wls_install::domain{$domain_name:
domain_name => $domain_name,
domain_template => 'standard',
bam_enabled => false,
b2b_enabled => false,
ess_enabled => false,
development_mode => false,
} ->After this code a basic domain containing an admin server is created but not started.
Then we create and start the nodemanager. This class sleeps for a maximum of 25 seconds while waiting for a nodemanager to be started.
#
# Over here you define the nodemanager. Here you can specify the address
# the nodemanager is running on and the listen address. When you create multiple domains
# with multiple nodemanagers, you have to specify different addresses and/or ports.
#
wls_install::nodemanager{"nodemanager for ${domain_name}":
domain_name => $domain_name,
nodemanager_address => $profile::wls::nodemanager_address,
sleep => 25,
} ->Now we need to tell the nodemanager to start the admin server for the domain
#
# Before you can manage any WebLogic objects, you'll need to have a running admin server.
# This code mages sure the admin server is started. Just like with the nodemanager, you'll need
# to specify unique addresses and ports.
#
wls_install::control{"start_adminserver_${domain_name}":
action => 'start',
domain_name => $domain_name,
} ->In order for the weblogic custom puppet types to access the admin server, it needs information to connect. The next type stores this information for later use.
#
# wls_setting is used to store the credentials and connect URL of a domain. The Puppet
# types need this to connect to the admin server and change settings.
#
wls_setting{$domain_name:
user => $profile::wls::os_user,
weblogic_user => $profile::wls::weblogic_user,
weblogic_password => $profile::wls::weblogic_password,
connect_url => "t3://${profile::wls::adminserver_address}:${profile::wls::adminserver_port}",
weblogic_home_dir => $profile::wls::weblogic_home_dir,
} ->
Because the domain creation creates the Admin server with a set of default settings, we now use the wls_server
type to manage the settings of the Admin server.
#
# You can use this wls_server definition to change any settings for your
# Admin server. because the AdminServer is restarted by wls_adminserver{'soa/AdminServer':}
# These settings are immediately applied
#
wls_server{"${domain_name}/AdminServer":
ensure => 'present',
arguments => $admin_server_arguments,
listenaddress => $profile::wls::adminserver_address,
listenport => $profile::wls::adminserver_port,
machine => 'LocalMachine',
logfilename => "${wls_log_dir}/AdminServer/AdminServer_${domain_name}.log",
log_datasource_filename => "${wls_log_dir}/AdminServer/datasource.log",
log_http_filename => "${wls_log_dir}/AdminServer/access.log",
log_file_min_size => '2000',
log_filecount => '10',
log_number_of_files_limited => '1',
ssllistenport => '7002',
} ~>
Some of the changes on the adminserver require a restart. To be sure we restart the admin server whenever a
change is done in the previous wls_server settings.
#
# This definition restarts the Admin server. It is a refresh-only, so it is only done
# when the statement before actually changed something.
#
wls_adminserver{"${domain_name}/AdminServer":
ensure => running,
refreshonly => true,
server_name => 'AdminServer',
domain_name => $domain_name,
domain_path => "${profile::wls::domains_dir}/${domain_name}",
os_user => $profile::wls::os_user,
nodemanager_address => $profile::wls::nodemanager_address,
nodemanager_port => $profile::wls::nodemanager_port,
weblogic_user => $profile::wls::weblogic_user,
weblogic_password => $profile::wls::weblogic_password,
weblogic_home_dir => $profile::wls::weblogic_home_dir,
subscribe => Wls_install::Domain[$domain_name],
} ->
At this point in time we have a valid but empty domain running. Now this code is applied:
#
# This statement creates all machines and WebLogic servers. The content of
# the $servers variable are read through hiera. Here you can 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)This code is defined at the beginning of the class. It reads the defition of servers and clusters from hiera and creates them. This is some of the magic that allows us to use the same puppet code if we have one node or a cluster of multiple machines.
After this code is done, the domain contains the defines machines and managed servers.
Now we can start to create clusters (if you want to and need to)
#
# This is the cluster definition. The server array is extracted from the list of servers
# and machines,
#
wls_cluster{"${domain_name}/${cluster_name}":
ensure => 'present',
messagingmode => 'unicast',
migrationbasis => 'consensus',
servers => $server_array,
} ->
Now we have a fully defined WebLogic domain with all machines, servers and clusters defined. It doesn't containing any other JEE resources. It is best to define those other resources in other classes.
To be sure everything restarts after a reboot, we create the requires startup files
#
# This class create's a startup script in /etc/init.d.
#
wls_install::support::nodemanagerautostart{'wlsony_nodemanager':
version => $profile::wls::version,
wl_home => $profile::wls::weblogic_home_dir,
user => $profile::wls::os_user,
domain => $domain_name,
domain_path => "${profile::wls::domains_dir}/${domain_name}",
} ->For transporting the definition of a domain to an other node in the cluster, we pack the contents of the doman.
#
# This resource definition pack's the current definition of the domain. This packed domain file
# can be used by other nodes in the cluster. They fetch it, unpack it and use it to enter the domain.
# When the node is part of the domain, the packed file loses its value. Any changes in the domain are managed
# by webLogic.
#
wls_install::packdomain{$domain_name:
domain_name => $domain_name,
weblogic_home_dir => $profile::wls::weblogic_home_dir,
middleware_home_dir => $profile::wls::middleware_home_dir,
jdk_home_dir => $profile::wls::jdk_home_dir,
wls_domains_dir => $profile::wls::domains_dir,
os_user => $profile::wls::os_user,
os_group => $profile::wls::os_group,
download_dir => '/data/install',
log_output => false, # Use true when you are debugging
} ->This concludes the definition of a domain.