Using Puppet Environments with the DPK
Aug 29, 2017Dan Iverson
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 modules
, manifests
and data
folder, in this post we’ll separate just the data
folder. This will let us share a common set of code (the manifests
and modules
folders) but the configuration of each domain will be different.
If you want to extend this to the modules
and 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 site.pp
file.
Create Environment Folders
- Make a new
dev
andtst
folders underc:\programdata\puppetlabs\puppet\etc\environments
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 dev
and tst
- Copy your YAML files from
puppet\etc\data
topuppet\etc\environments\dev\data
andpuppet\etc\ environments\tst\data
.
Configure Puppet Environment
Under the puppet\etc
folder, add (or modify) the puppet.conf
file to look like this:
[main]
environment=production
parser=future
environmentpath=c:\programdata\puppetlabs\puppet\etc\environments
hiera_config=c:\programdata\puppetlabs\hiera\etc\hiera.yaml
basemodulepath=c:\programdata\puppetlabs\puppet\etc\modules
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:
---
:backends:
- yaml
:hierarchy:
- "environments/%{::environment}/data/psft_customizations"
- "environments/%{::environment}/data/psft_configuration"
- "environments/%{::environment}/data/psft_deployment"
- "environments/%{::environment}/data/psft_unix_system"
- "environments/%{::environment}/data/defaults"
:yaml:
:datadir: c:\programdata\puppetlabs\puppet\etc
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:
---
:backends:
- yaml
:hierarchy:
- "environments/%{::environment}/data/psft_customizations"
- "environments/%{::environment}/data/psft_configuration"
- "environments/%{::environment}/data/psft_deployment"
- data/psft_unix_system
- data/defaults
:yaml:
:datadir: c:\programdata\puppetlabs\puppet\etc
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:
cd c:\programdata\puppetlabs\puppet\etc\manifests
puppet apply .\site.pp --environment=dev --debug
Once the dev
domains are built and running, you can kick off the tst
build with:
puppet apply .\site.pp --environment=tst --debug
As the 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).
Note: This was originally posted by Dan Iverson and has been transferred from a previous platform. There may be missing comments, style issues, and possibly broken links. If you have questions or comments, please contact [email protected].