Continuing on our DPK series, this week we’ll explore how to do advanced web server domain configuration. The
psft_configuration.yaml file gives you many of the configuration options for your web domain. While these settings will help you configure your web domain, there are more changes to WebLogic most administrators make. One of those changes is configuring SSL/Certificates and Logging.
DPK and WSLT
Before the DPK, you could script configuration changes to WebLogic using the WebLogic Scripting language WSLT. WSLT is a great interface to WebLogic, and you can do quite a bit with it.
We use the
psft_customizations.yaml file to document the WLST commands in a section called
config_settings:. This section is not included in
psft_configuration.yaml for the PIA, so it will be a new section for your files. The
config_settings: section is included for app server and process scheduler sections. If you look at the file
puppet\etc\modules\pt_config\tests\test_pia_create.pp you can see the PeopleTools team is using the
config_settings section when creating a test domain.
psft_customizations.yaml file, the
config_settings: section will go below the
webserver_settings: section and above the
site_settings: section. Everything under
config_settings: is broken down into WSLT commands. To make a change to WebLogic, use the tree structure from your web domains’
config.xml file to identify a section to change. E.g,
Servers/PIA/WebServer/PIA/WebServerLog/PIA will be the HTTP access log settings for the PIA server.
Under each WSLT header, you can include a
key: value for any configurable option in WebLogic. For our
Servers/PIA/WebServer/PIA/WebServerLog/PIA above, we’ll enable the access log:
When we run
puppet apply, the Puppet code take this configuration and executes the WLST to make the change to WebLogic. After the
puppet apply run, you can check the
config.xml file to verify the updated configuration.
Using WSLT to Identify Config Values
If you don’t know what the path or values you want to change, you can spin up a WLST session and browse your web domain. To start WLST, run
setWLSEnv.cmd script under your
WL_HOME\server\bin folder. That will set up the environment variables so Java can find the WLST package.
Next, start up a WLST session with
java weblogic.WLST. Your web server needs to be running to connect, and you’ll need the console username and password.
connect('system', 'Passw0rd', 't3://localhost:8000')
Once you connect to your domain, you can use
ls() commands to navigate around the configuration tree. For example, this command will take us to the Access Log settings for the PIA.
You can do much more with WLST, but we’ll save that for another time.
SSL and Certificate Configuration
Now that we can configure a web domain via WLST commands, let’s set up SSL and a certificate for a domain. The DPK will do all the configuration, but it won’t update the
pskey file. A good idea would be to prebuild your
pskey file (using KeyStore Explorer) and be ready to copy into your domains
piaconfig folder after the DPK runs.
This is what the
config_settings section of the
psft_customizations.yaml looks like to configure SSL:
If you have configured SSL through the WebLogic console before, these configuraiton options should look familiar. We tell WebLogic to use a custom keystore (pskey), the password to get into the keystore, the Private Key alias and the password for the Private Key.
In production systems, it’s not a good idea to have your unecrypted password in the yaml files. For Windows, support for encrypting password in the yaml files isn’t there yet. For Linux, eyaml can encrypt your passwords.
This is what a
psft_customizations.yaml looks like for a web server domain:
Update Existing Domains
Unlike other parts of the DPK, the WLST commands execute every time you run
puppet apply .\site.pp. So, if you want to update a config value in your web domain, the DPK will make those changes for you after the domain was created. With the app server and process schedulers, the DPK doesn’t handle changes well. Once the domain is built, configuration changes are not applied to app and batch domains.
The goal of the DPK, Puppet and other automation software is to create a dependable and repeatable process. Taking advantage of these features in the DPK will get you closer to the ideal of complete automation. The ability to issue WLST commands against WebLogic domains gives admins another tool with the DPK to build a system to your specifications.