Fattening the workflow, part 2: r10k

In the previous post I discussed the control repository structure. In this post I'll talk about r10k. That tool is used for deploying control repository branches into matching Puppet environments on the Puppet server. Installing r10k is very straightforward with the bundled gem:

$ /opt/puppetlabs/puppet/bin/gem install r10k

After this you'll need a settings file for r10k, /etc/puppetlabs/r10k/r10k.yaml:

--- 
 :cachedir: /opt/puppetlabs/puppet/cache/r10k 
 :sources: 
 control: 
 basedir: /etc/puppetlabs/code/environments 
 prefix: false 
 remote: [email protected]:myorg/control-repo.git

Several requirements must be met before the configuration above will work:

• The control repo (remote) must exist at the Git provider side
• A private SSH key must be installed for the root user - assuming you run r10k as root
• The public part of the SSH key must be added and given read-only access to the control repo. These keys are often called "deployment keys" at the Git provider side.
• Similarly the deployment key must be added to all private Puppet module repositories at the Git provider side

Finally you need to let r10k know which SSK key it should use. This can be done by editing the SSH settings for root in the file /root/.ssh/config:

Host gitlab.com 
  StrictHostKeyChecking no 
  RSAAuthentication yes 
  IdentityFile /etc/puppetlabs/r10k/ssh/id_rsa 
  User git

The private part of the SSH key (for example id_rsa) will need to be at the above path (/etc/puppetlabs/r10k/ssh/id_rsa) and its file permissions need to be sufficiently limited (for example 0400).

At the end, if all goes well, you can turn all control repo branches into Puppet environments with r10k:

$ r10k deploy environment -vp

The parameter -p (alias --puppetfile) makes r10k update all modules listen in the Puppetfile. If that parameter is omitted only the control repo itself will be updated. I recommend locking the module versions in the Puppetfile: this avoids the -p switch from accidentally upgrading the Puppet modules to incompatible versions. Detailed instructions are available in the official documentation for r10k.

Most often you will be deploying a single environment, be it "production" or a feature environment. This can be done by defining the environment on the command-line:

$ r10k deploy environment my_feature -vp

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

Read more on Puppet in our article What is Puppet and how does it work