Tag: pca

The PeopleSoft Cloud Architecture is built on two technologies: Deployment Packages (DPK) and Automated Configuration Management (ACM). On this site, we’ve talked about Deployment Packages quite a bit, but we haven’t discussed Automated Configuration Management. This post will introduce you to what the ACM is and how the DPK uses it.

Use Hiera to Turn ACM On/Off

In the past, I have created custom DPK roles without the DPK profiles that run the ACM. This was mostly to prevent ACM runs when we build a domain. It turns out that you can control the ACM (globally) with your psft_customizations.yaml file.

In the pt_tools_preboot_config and pt_tools_postboot_config profile, there is a Hiera lookup to see if ACM is enabled

$run_preboot_config_setup = hiera('run_preboot_config_setup', true)

or

$run_postboot_config_setup = hiera('run_postboot_config_setup', true)

If you haven’t defined these values, the default will be true. You can disable the ACM by adding this your psft_customizations.yaml:

run_preboot_config_setup: false
run_postboot_config_setup: false

There is a bug in the current DPK (8.55 and 8.56) if you set both values. In the modules/pt_profile/manifests/pt_tools_postboot_config.pp file, line 98 should be:

notify {"POST-Boot setup run is false":}

(Switch the message “PRE-Boot” to “POST-Boot”).

Building ACM Hiera Data

When the DPK runs Automated Configuration Management, it will take the plugins and properties you define in the psft_customizations.yaml file and build a template file on the fly. To define ACM steps to run, you’ll add hashes to one of two sections:

component_preboot_setup_list

component_postboot_setup_list

The labels are self-explanatory, but here is any easy way to know which plugs go in the post boot setup: If the setup requires IB to be running, it goes in post boot. That would include IB Configuration itself and Search Framework configuration.

Here is an example of setting up the Elasticsearch Search Instance via ACM. Unde the component_postboot_setup_list hash, we create a searching hash. (This name can be any string, but we’ll use that string later in the file). Then, we set the Run Control ID to use and the OS user who will run the App Engine.

Then we define the ACM Plugins we want to run. The acm_plugin_list is a hash of ACM Plugin names, and their repective configuration. To get a list of all the possible configuration, you can go into the PIA (PeopleTools > Automated Config Manager > ACM Templates > Template Definitions) and see the delivered ACM plugins.

Once you have filled out the plugin configuration vaules, and if you have multiple ACM hashes, you need to tell the DPK what order you want to execute the ACM plugins. You use the component_preboot_setup_list has to specify that order. Below, you’ll see we have 3 ACM sections we want to execute. These names are the hashes we created under the component_preboot_setup_list section.

With the Deployment Packages, you can install an entire PeopleSoft system. But what if you want to install just one component? You can install the PIA role, but you get WebLogic, Tuxedo, Java, and a PIA domian. In this post, we’ll show how to leverage the DPK with custom Puppet manifests and install only WebLogic (and Java) on a server.

You will need to the DPK Puppet files on the server. Run the bootstrap script and stop at the “Default Initialization” question so nothing gets installed. You can use any parameters you want for the bootstrap script. We’ll be ignoring the site.pp file and using a new manifest file.

WebLogic DPK Role

A new DPK role file was created under etc\modules\pt_role\manifests called pt_tools_weblogic.pp. From the post on the sites.pp file, we introduced the idea of DPK roles. The best practice is to only have one role per machine. For the WebLogic-only install, we’ll create a new role so its clear that this server is only running WebLogic.

The role file uses the ensure attribute from the defaults.yaml file to determine if Puppet should install or remove WebLogic. The default value is to install (ensure = present).

Next, the role calls a new profile called pt_profile::pt_weblogic. Let’s create that file net.

WebLogic DPK Profile

A DPK profile handles the configuration lookup from Hiera and preparing Puppet for the installation (or removal). Our custom profile grabs the installation directory (oracle_base and weblogic_location) from the psft_customizations.yaml file. WebLogic requires Java too, so we configure that in the profile as well.

Create a new profile under etc\modules\pt_profile\manifests and call it pt_weblogic.pp.

WebLogic DPK Deployment

Finally, we’ll call the Puppet code to install Java and WebLogic! We are using two DPK types in this manifest:

pt_deploy_jdk

pt_deploy_weblogic

This is why the DPK needs to be installed before using these manifests. If the DPK is missing, these calls will fail (and so will some of the hiera lookups). The deployment manifest is under the folder etc\modules\pt_setup\manifests. Create the file weblogic_deployment.pp from the code below or from the GitHub project.

The manifests under pt_setup will do the heavy work of installing new software. This custom manifest will deploy Java and WebLogic on our servers. If your bootstrap script didn’t create a dpk\archives folder, the installation will fail. The DPK manifests (and our custom one) will look for the archives before it attempts to install.

Installation

Once your custom manifests are built, go to the puppet\etc\manifests folder. Run the command

puppet apply .\weblogic.pp --trace --debug

to install WebLogic.

Future Improvements

When I did the test, I tried to follow the Roles and Profiles pattern used by the DPK. It might seem complex for a smaller installation. You could combine all this into one manifest, but then it gets ugly to maintain. When we add more software components, the abstraction between configuration and implementation allows us to re-use Puppet code.

This was a test for myself to see if I could break down some of the abstraction in the DPK and write (or modify) manifests to control more of the process. Plus, we have DPK role that we can use for WebLogic-only deployments 🙂

This week Graham Smith joins us to talk about the PeopleSoft Cloud Architecture, the future of PeopleSoft and how the PeopleSoft Administrator role is changing.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.