Using r10k to automate deployment of Puppet code.

Automated deployment of Puppet code in its entirety is actually a fairly complicated question. To make automated deployment more palatable, we will break the concept up into two areas.

1. Deployments of control repositories and modules from the Forge
2. Deploying our own custom modules, or modules that includes third-party contributions.

Control repository automation is straightforward, as it impacts only ourselves as an organisation. One of the tricky bits of Puppet, is where the variables should live.
To facilitate and expedite troubleshooting I have adopted some rules of thumb.
1. Non-secret, non-site specific variables and info will be in the module hieradata.
2. Non-secret, site-specific variables and info will be in the profiles.
3. Secrets will be in the control repository.

This post will cover using r10k to deploy control repositories and the environment modules. There are multiple ways to cater for automation of Puppet code. This post will be part one in the deployment, setting up r10k to automate the deploy of control repositories.

If you are not sure what a Control Repository is, it is a mechanism to manage Puppet environments, secrets and environment modules via branches through a single repository.

Stand up a control repository

To make a start, clone the official Puppet control repository:

# git clone https://github.com/puppetlabs/control-repo.git Puppet

Remember to update the origin in the local repository to point to your own upstream repo. Whilst you can use the root user, it is considered best practice to use a dedicated user to deploy the code.

You can now populate your Puppetfile with all your required modules.

Setup r10k

If you have PDK installed, you should already have the r10k binaries in /opt/puppetlabs/bolt/bin/r10k, if not, you can install them via gem.

# puppetserver gem install r10k
# mkdir /etc/puppetlabs/r10k

After the above, create your r10k config file. This can be achieved manually, or by using the r10k module in the forge.

After you’ve created the config file, /etc/puppetlabs/r10k/r10k.yaml, the content should be similar to the below:

---
# The location to use for storing cached Git repos
cachedir: '/var/cache/r10k'
 
deploy:
  purge_levels: [ 'deployment', 'environment', 'puppetfile' ]
 
# A list of git repositories to create
sources:
  puppet:
    remote: '<your upstream repo>'
    basedir: '/etc/puppetlabs/code/environments'
    prefix: false

Provide your deploy user with sudo rights to run the deploy.

echo "srvpuppetdeploy ALL=(ALL) NOPASSWD:/opt/puppetlabs/bolt/bin/r10k" > /etc/sudoers.d/srvpuppetdeploy

Make sure you have set up all the required access between the deploy user and your upstream repository. If all is fine, running r10k should deploy your control repository branches into separate environments within Puppet.

[srvpuppetdeploy@katello puppet_repo]$ sudo /opt/puppetlabs/bolt/bin/r10k deploy environment -pv
INFO     -> Using Puppetfile '/etc/puppetlabs/code/environments/production/Puppetfile'
INFO     -> Deploying environment /etc/puppetlabs/code/environments/production
INFO     -> Environment production is now at 92df9362abb67dde109600b11e4db428e99cf7d0
INFO     -> Deploying Puppetfile content /etc/puppetlabs/code/environments/production/modules/stdlib
INFO     -> Deploying Puppetfile content /etc/puppetlabs/code/environments/production/modules/sqlserver
INFO     -> Deploying Puppetfile content /etc/puppetlabs/code/environments/production/modules/mount_iso
INFO     -> Deploying Puppetfile content /etc/puppetlabs/code/environments/production/modules/powershell
INFO     -> Deploying Puppetfile content /etc/puppetlabs/code/environments/production/modules/puppet_agent

You have now successfully set up r10k on your server to facilitate auto-deployment!