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