gistfile1.md

The way we protect each environment is to make each node aware of what enironment it is in (via facter) and then have the puppet master configured to point to different directories for modules and manifests.

The important thing to note here is that we are always working with a full set of the code and nothing changes between staging and production, that is critical.

The environment facter is set currently by using this machines domain.

So for example, if a node has 'edherow.com' as its domain it will look at the hiera setup and go to /etc/hieradata/edherow.com/common.yaml:

---
:hierarchy:
  - "%{::domain}/common"
  - "%{::domain}/backup"
  - "%{::domain}/supporter_url_redirects"
  - 'users'
  - 'backup'
  - 'common'

It will do the lookup and see the below key:

---
environment: 'staging3'

In the environment node files the $env variable is setup

$env = hiera('environment')

We then set the puppet.conf on the agent like this

[agent]
environment=<%= @env %>

Once this is done we can implement the following changes to the PuppetMaster conf:

[main]
server=puppet
masterport=8180
confdir=/etc/puppet/$environment
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
config_version=$confdir/bin/current_revision
pluginsync = true

[master]
modulepath = $confdir/modules
manifest = $confdir/manifests/site.pp

So what this means is the GO server will checkout the particular build for the particular environment, so in essence we could have all 4 environments on difference version, there by protecting each from changes (particularly production).

For staging3 the go server would do the following:

cd /etc/puppet.staging3
git checkout <commit number>

The new directory structure is as follows:

/etc/puppet (this is only used for puppet.conf, all other files are dedundant)
/etc/puppet/production
/etc/puppet/staging
/etc/puppet/staging2
/etc/puppet/staging3