Using Automated Configuration Management with the DPK

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.

component_postboot_setup_list:
  searching:
    run_control_id:                       searching
    os_user:                              "%{hiera('domain_user')}"`

Next, we define the database connection settings for the web_profile hash.

    db_settings:
      db_name:                            "%{hiera('db_name')}"
      db_type:                            "%{hiera('db_platform')}"
      db_opr_id:                          "%{hiera('db_user')}"
      db_opr_pwd:                         "%{hiera('db_user_pwd')}"
      db_connect_id:                      "%{hiera('db_connect_id')}"
      db_connect_pwd:                     "%{hiera('db_connect_pwd')}"`

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.

Below is an example of the PTSFConfigureSrchInstance plugin.

    acm_plugin_list:
      PTSFConfigureSrchInstance:
        env.ptsf_search_instance:         PTSF_DEFAULT
        env.search_provider:              ES
        env.search_nodes:                 1
        env.node1_search_port:            9200
        env.node1_search_host:            psvagabond.psadmin.io
        env.node1_search_admin_user:      esadmin
        env.node1_search_admin_password:  esadmin
        env.node1_search_read_user:       people
        env.node1_search_read_password:   peop1e
        env.search_call_back_user:        PS
        env.search_call_back_password:    PS
        env.gateway_host:                 psvagabond.psadmin.io
        env.gateway_port:                 8000
        env.default_local_node:           PSFT_LM

    acm_plugin_order:
      - PTSFConfigureSrchInstance

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.

    component_preboot_setup_list:
      - searching
      - push_notifications

PeopleBooks has a good list of delivered plugins and what configuration options are available.

Testing ACM via DPK

To test the ACM with the DPK, we can tell Puppet to run only the ACM preboot or postboot step. Use the command below to execute a single DPK Profile:

puppet apply -e "include ::pt_profile::pt_tools_postboot_config" --trace --debug

This will run the postboot configuration you have defined in psft_customizations.yaml without running anything else defined in Puppet.

Validating ACM

If you use the --trace --debug options when running Puppet, you can see the output from the PTEM_CONFIG app engine.

########################################################### 
    ######## AUTOMATED CONFIGURATION MANAGER ######## 
###########################################################

PTEM_CONFIG:PTSFConfigureSrchInstance: Configure Peoplesoft system to talk to Search Server and assign roles

Configuring plug in : PTEM_CONFIG:PTSFConfigureSrchInstance 
STATUS: SUCCESS 
DESCRIPTION: NONE 
SEVERITY: NONE 
Configuration completed : PTEM_CONFIG:PTSFConfigureSrchInstance

****Completed environment configuration****

You can also get information about missing or invalid configuration from your ACM definition with the output:

########################################################### 
    ######## AUTOMATED CONFIGURATION MANAGER ######## 
###########################################################

Validation of variables failed : PTEM_CONFIG:PTSFConfigureSrchInstance 
Required property env.ptsf_search_instance is missing

Sample psft_customizations.yaml for ACM

Here is a gist with the Elasticsearch ACM Plugin configured. This Hiera data will configure an Elasticsearch instance in your environment.

Using the DPK to install only WebLogic

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.

I’ll document the custom manifests in this post, but if you want to download the code you can grab it from GitHub. Copy the files in the project into the corresponding folders under the puppet\etc folder on your machine.

psft_customizations.yaml Updates

For the WebLogic install, I wanted the software to install in the e:/oracle folder. I added/updated these values in my psft_customizations.yaml file:

oracle_base:      e:/oracle

jdk_location:           "%{hiera('oracle_base')}/jdk1.7.0_95"
weblogic_location:      "%{hiera('oracle_base')}/bea"

You don’t need to use oracle_base and can ignore these changes if you want WebLogic installed to the default location.

weblogic.pp Manifest

Create a new manfiest under etc\manfiests (or copy the site.pp file) and name it weblogic.pp. In the weblogic.pp manifest, we are doing two things:

  1. Create the oracle_base folder (the DPK will fail if the base folder doesn’t exist)
  2. Call a custom DPK role (we’ll create this next)

Here is the weblogic.pp file:

# Verify the Oracle Base folder is present - DPK doesn't like it when the base folder isn't created.
file { hiera('oracle_base') :
    ensure => 'directory',
}

# Call custom profile to install WebLogic (and JDK)
node default {
  include ::pt_role::pt_tools_weblogic
}

If you’ve looked at the site.pp file you’ll recognize the second section. The first part of the file is Puppet code to create a folder if it doesn’t exist.

If you aren’t familiar with Puppet, the Puppet CookBook is a good place to get familiar with writing manifests.

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.

class pt_role::pt_tools_weblogic inherits pt_role::pt_base {
  notify { "Applying pt_role::pt_tools_weblogic": }
  $ensure   = hiera('ensure')
  contain ::pt_profile::pt_weblogic
  Class['::pt_profile::pt_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.

# Custom Profile to prepare for WebLogic installation
class pt_profile::pt_weblogic {
  notify { "Applying pt_profile::pt_weblogic": }

  ## Hiera lookups
  $ensure                    = hiera('ensure')
  $env_type                  = hiera('env_type')

  $tools_archive_location      = hiera('archive_location')

  $jdk_hiera             = hiera('jdk')
  $jdk_location          = $jdk_hiera['location']
  $jdk_remove_value      = $jdk_hiera['remove']
  if $jdk_remove_value == false {
    $jdk_remove = false
  }
  else {
    $jdk_remove = true
  }
  notice ("JDK remove is ${jdk_remove}")

  $weblogic_hiera        = hiera('weblogic')
  $weblogic_location     = $weblogic_hiera['location']
  $weblogic_remove_value = $weblogic_hiera['remove']
  if $weblogic_remove_value == false {
    $weblogic_remove = false
  }
  else {
    $weblogic_remove = true
  }
  notice ("Weblogic remove is ${weblogic_remove}")

  $redeploy = hiera('redeploy', false)
  class { '::pt_setup::weblogic_deployment':
    ensure                 => $ensure,
    tools_archive_location => $tools_archive_location,
    inventory_location     => $inventory_location,
    jdk_location           => $jdk_location,
    jdk_remove             => $jdk_remove,
    weblogic_location      => $weblogic_location,
    weblogic_remove        => $weblogic_remove,
    redeploy               => $redeploy,
  }
  contain ::pt_setup::weblogic_deployment
}

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.

# Custom Puppet Class to deploy WebLogic using the DPK
class pt_setup::weblogic_deployment (
  $ensure                 = present,
  $deploy_pshome_only     = false,
  $tools_archive_location = undef,
  $tools_install_user     = undef,
  $tools_install_group    = undef,
  $oracle_install_user    = undef,
  $oracle_install_group   = undef,
  $db_type                = undef,
  $pshome_location        = undef,
  $pshome_remove          = true,
  $inventory_location     = undef,
  $oracleclient_location  = undef,
  $oracleclient_remove    = true,
  $jdk_location           = undef,
  $jdk_remove             = true,
  $weblogic_location      = undef,
  $weblogic_remove        = true,
  $tuxedo_location        = undef,
  $tuxedo_remove          = true,
  $ohs_location           = undef,
  $ohs_remove             = true,
  $redeploy               = false,
) {

  notice ("Applying pt_setup::weblogic_deployment")

  $jdk_tag          = 'jdk'
  $weblogic_tag     = 'weblogic'

  $jdk_archive_file      = get_matched_file($tools_archive_location, $jdk_tag)
  if $jdk_archive_file == '' {
    fail("Unable to locate archive (tgz) file for JDK in ${tools_archive_location}")
  }
  $weblogic_archive_file = get_matched_file($tools_archive_location, $weblogic_tag)
  if $weblogic_archive_file == '' {
    fail("Unable to locate archive (tgz) file for Weblogic in ${tools_archive_location}")
  }

  $jdk_patches = hiera('jdk_patches', '')
  if ($jdk_patches) and ($jdk_patches != '') {
    notice ("JDK patches exists")
    $jdk_patches_list = values($jdk_patches)
  }
  else {
    notice ("JDK  patches does not exists")
    $jdk_patches_list = undef
  }

  pt_deploy_jdk { $jdk_tag:
    ensure            => $ensure,
    deploy_user       => $tools_install_user,
    deploy_user_group => $tools_install_group,
    archive_file      => $jdk_archive_file,
    deploy_location   => $jdk_location,
    redeploy          => $redeploy,
    remove            => $jdk_remove,
    patch_list        => $jdk_patches_list,
  }

  $weblogic_patches = hiera('weblogic_patches', '')
  if ($weblogic_patches) and ($weblogic_patches != '') {
    notice ("Weblogic patches exists")
    $weblogic_patches_list = values($weblogic_patches)
  }

  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => $ensure,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
    patch_list                => $weblogic_patches_list,
    require                   => Pt_deploy_jdk['jdk'],
  }

}

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 🙂

#29 – PeopleSoft Cloud Architecture w/ Graham Smith

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.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

  • SQL Server/Windows @ 3:00
  • Reaction to Changes in PeopleSoft @ 8:00
  • PeopleSoft Cloud Architecture @ 12:00
  • Why the PCA? @ 30:30
  • Graham’s Predictions about PeopleSoft @ 35:00
  • How the PS Admin role is changing @ 43:30