Since the Deployment Packages were released with PeopleTools 8.55, one of my criticisms has been that the DPK is a bit of a sledgehammer. If you define multiple PeopleSoft environments on a server and you want to configure one web server, ALL the domains that the DPK knows about are shut down.
Puppet has an Environments feature that lets you segregate your code and data. While the DPK does not support Puppet Environments out of the box, we can use them to make the DPK less of a sledgehammer when managing our domains. (There is still some sledgehammering going on, so go vote for this idea).
While environments let you separate the
data folder, in this post we’ll separate just the
data folder. This will let us share a common set of code (the
modules folders) but the configuration of each domain will be different.
If you want to extend this to the
manifests folder, copy those into the environment folders with the environment-specific changes. This is useful for testing new code changes or if you want an environment to use a different DPK Role in the
Create Environment Folders
- Make a new
tst folders under
You can have multiple environments under this folder – as many as you want. A strategy that I’m testing is using the database name as the environment name. For this post, I’ll stick with
- Copy your YAML files from
Configure Puppet Environment
puppet\etc folder, add (or modify) the
puppet.conf file to look like this:
This file tells Puppet where to look for your environments, your Hiera configuration, your default module location, and the default Puppet Environment.
Last, we’ll modify the
hiera.yaml file in
c:\programdata\puppetlabs\hiera\etc to include environments:
If you want to share some of the files, like the
defaults.yaml or the
psft_unix_system.yaml file, you could keep those under the main
puppet\etc\data folder. Your
hiera.yaml file would look like this:
Test the Environments
Once our Puppet changes are complete we can test some builds. When we run
puppet apply, we’ll add an additional paratemer: the environment. To build my
dev environment domains, I’ll use this procedure:
puppet apply .\site.pp --environment=dev --debug
dev domains are built and running, you can kick off the
tst build with:
puppet apply .\site.pp --environment=tst --debug
tst environment is building, your
dev domains should stay up and not be affected by the Puppet run. If they are affected, you may have some YAML changes that need to be made. Make sure your configuration’s between the environment don’t overlap (e.g, same
PS_CFG_HOME and domain names).