$ensure = hiera('ensure') | |
$base = hiera('peoplesoft_base') | |
$appserver_domain_list = hiera('appserver_domain_list') | |
$appserver_domain_list.each | $domain_name, $appserver_domain_info | { | |
$cfg_file = "${appserver_domain_info['ps_cfg_home_dir']}/appserv/${domain_name}/psappsrv.cfg" | |
$dynamic_config = $appserver_domain_info['dynamic_config'] | |
$dynamic_config.each | $setting, $config_value | { | |
$settings_array = split($setting, "/") | |
ini_setting {"app-dynamic-change-${domain_name}-${setting}": | |
ensure => $ensure, | |
path => $cfg_file, | |
section => $settings_array[0], | |
setting => $settings_array[1], | |
value => $config_value, | |
} | |
} | |
} |
Great to see this approach in puppet/DPK. This allows for a very effective configuration.
Using Ansible to do a similar approach, by having separate lists for dynamic vs static config. But also allows the task to determine if the app server needs to be cycled for the change when a change does actually occur. Ansible provides a powerful Jinja templating to sort-of pivot a yaml file into a template to update the psappsrv.cfg file. Here's a sample yaml template file (ie: ps_app_static_config.yml.j2) to specify static configs, but we also separate configs by app, environment and/or type. This allows me to see all the values for app servers for any environment in one location.
- config: "Min Jolt Listeners"
section: "JOLT Listener"
option: "Min Handlers"
default: "4"
changes:
- value: "8"
apps: [ "hr" ]
envs: [ "prd","per" ]
purpose: "main"
- value: "10"
apps: [ "cs", "ih" ]
envs: [ "prd","per" ]
purpose: "main"
- value: "6"
apps: [ "hr", "ih", "cs" ]
envs: [ "qat","upg" ]
purpose: "main"
- config: "Lower ping interval for dispatch instances (default brk)"
section: "PSBRKDSP_dflt"
option: "Scan Interval"
default: "15"
changes:
- value: "5"
apps: [ "hr","cs","fs","ih" ]
envs: [ "dev","tst","qat","prd","per","upg" ]
purpose: "ib"
...
Then read these config rules in an Ansible task, load the yaml to a variable and loop through the sub-elements (Each config item).
The second task will first, loop through each config item in the yaml, then the second loop will check each change/value and determine if the current domain matches the app and environment the value is intended for. Then using the ini module, set the value to the matching section/option in the psappsrv.cfg file. And only if any changes occur, then restart the app server to make the changes take effect.
- name: "Load app/env static config rules"
set_fact:
config_list: "{{ lookup('template', './ps_app_static_config.yml.j2') | from_yaml }}"
# Loop through the custom static config changes defined in the template and apply to domain config file in ini format
- name: "Static psappsrv.cfg changes"
ini_file: dest="{{ appdomain_home }}/psappsrv.cfg"
section="{{ item.0.section }}"
option="{{ item.0.option }}"
value="{{ item.1.value }}"
backup=no
no_extra_spaces=yes
when: domain.app in item.1.apps and domain.env in item.1.envs and domain.purpose == item.1.purpose
with_subelements:
- "{{ config_list }}"
- changes
notify:
- restart appserver
Example of
psft_customizations.yaml
appserver_domain_list
hash with the new section: