Fattening the Puppet workflow, part 1: The control repository

If editing Puppet code and Hiera directly with puppetmaster feels too easy, you can complicate the Puppet workflow as much you like by adding more components to the palette. Adding the so called control repository and r10k to Puppet environment maintenance instantly adds several phases to your initially simple workflow. There are also benefits that I'll discuss later on.

The control repository (control repo for short) is a Git repository that is used to create dynamic Puppet environments on the Puppet master. Each Git branch can be turned into a matching Puppet environment. The name of the default branch, production, is the same as the environment the Puppet agents use by default. The content of the control repo branches look like this:

$ ls control-repo
data
environment.conf
hiera.yaml
manifests
Puppetfile
README.md
site

Puppetfile contains references to the Puppet modules that should be included in the module folder of the environment:

forge "https://forgeapi.puppetlabs.com"

# Puppet Forge module
mod 'puppetlabs/stdlib', '6.5.0'

# Module from Git
mod 'puppet-mymodule',
  :git => '[email protected]:myorg/puppet-mymodule.git',
  :ref => '7beca37fe16978b1addf4493e4ea6186e00a9e87'

Under the manifests directory you have file site.pp which is used mainly to load classes from Hiera's classes array:

# Default value [] prevents the Puppet run from failing
# when there is a computer that doesn't have any classes
# in the classes array.
lookup('classes', {merge => unique, default_value => []}).include

The file environment.conf is also fairly simple:

# Look first under "site", then under "modules" and then
# in the global module path shared between all environments 
modulepath = site:modules:$basemodulepath

# Make sure that nodes always use the latest code. If you
# have lots of Puppet Agents you might have to set this
# value higher.
environment_timeout = 0

The file hiera.yaml is an environment specific settings file for Hiera. Hiera version 5 allows three level hierarchy that includes a global level, environment specific level and module specific level. The module level is an option for the bit aged params.pp pattern. The module level is loaded implicitly and is not visible in hiera.yaml:

---
version: 5
defaults:
  datadir: data
  data_hash: yaml_data

hierarchy:
  - name: "Per-node data"
path: "nodes/%{trusted.certname}.yaml"
  - name: "Common data"
path: "common.yaml"

The folder site includes the Puppet modules that are included directly in the control repo. This helps avoid overhead from having to maintain external Git modules and references to them in the Puppetfile.

The folder data contains the Hiera hierarchy. When using hiera.yaml file , the data folder contains the file common.yaml and the folder nodes, which contains the yaml files for each node.

Fattening the workflow series:

• Part 1: The control repository
• Part 2: r10k
• Part 3: GitLab and similar
• Part 4: Roles and profiles
• Part 5: Hiera and content encryption

...