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_order 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_order section.

    component_preboot_setup_order:
      - 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.

3 thoughts on “Using Automated Configuration Management with the DPK”

  1. Excellent write-up! Thanks for putting this together. I assume that if we want to override a single item, we still need to include the entire component_preboot_setup_list or component_postboot_setup_list section in psft_customizations.yaml and just override what we want, just like with the other hashes? For example, if all I want to do is change the process schedule report node URL/protocol to use SSL, I still need to copy in all of the other stuff from component_preboot_setup_list, including web_profile: and integration_broker: .

    1. Thanks! Yes, out of the box you need to copy the entire YAML section. Any hash you define that is at the top level (e.g, appserver_domain_list) will override configuration. This is true for the ACM hashes too.

      But, stay tuned. We’ve got a post coming soon about how to enable Hiera Hash Merging so you don’t have to copy the entire hash and can use the YAML file like you mentioned.

  2. Useful post! As Elasticsearch is not managed in current PT8.55 DPK, I was running the ACM Application Engine after executing the DPK to configure ES. I will use your yaml file now, to get full automation.

Leave a Reply

Your email address will not be published. Required fields are marked *