There have been many ways to deploy Puppet code over the years. It’s changed quite a bit since the .25 days. Now we have a few options, puppet-librarian, and r10k. I’ve decided to go with r10k for our needs. This solves many issues for us specifically in a multi tenant environment.

For a multi tenant environment it’s been an issue with segregating code. There have been many solutions over the years. THe biggest allure for r10k is that if a client doesn’t require a modules, we don’t need to deploy them. In addition our clients don’t really understand what deploying code is all about. This is a larger issues in the devops world and not limited to Puppet specifically. What r10k however allows us or anyone to do is to deploy client specific code to clients and not change any modules.

There’s a few configs to note the r10k.yaml file which is located in /etc/puppetlabs/r10k/ and the Puppetfile.

One thing to note is if you’re running Debian the package is significantly older than the gem. At the time of this writing the Debian version is 1.1.4-1 and the gem version is 2.3.0, so I would recommend installing and managing the gem directly.

Now configuring r10k. You can do this via Puppet which I forked an exiting module and updated. But I’ll just go into the manual basics here, it’s actually super simple to install and configure r10k. First you’ll want to update the r10k.yaml file which I mentioned earlier. Below is an example

---
:cachedir: /var/cache/r10k

:sources:
  puppet:
    basedir: /etc/puppetlabs/code/environments
    remote: git@(YOURGITINFO)

You’ll need to have your git path for the remote. The remote is what r10k calls the “control repo”, this repo contains the basics including hieradata and the manifests directory. The basedir and cachedir are completely up to you and your environment. I stuck with the defaults.

Next you’ll need to configure your Puppetfile which basically controls which modules to deploy. For this example we’ll only use 3, but normally you’d have more.

mod 'puppet',
  :git => 'git@(YOURGITPATH)/puppet.git',
  :ref => '1.0'
mod 'network',
  :git => 'git@(YOURGITPATH)/network.git',
  :ref => '1.0'
mod 'tools',
  :git => 'git@(YOURGITPATH)/tools.git',
  :ref => '1.0'

So as you can see here the mod is the name of the module and the name of the destination directory. You can call modules directly from the Puppet Forge or SVN if you really hate yourself. We use self hosted git and rarely use modules from the forge. git is obviously your git location, this supports any git connection. For the ref you can use any reference point, we actually version out our modules, but this can be a branch, tag, commit, etc.

Now that you have everything configured, it’s time to deploy some code!

gerard@helios:~$ sudo -u r10k r10k deploy environment production -v -p
INFO     -> Deploying environment /etc/puppetlabs/code/environments/production
INFO     -> Environment production is now at 6478be7b08edf1c750b4124742f65e161137d4bb
INFO     -> Deploying module /etc/puppetlabs/code/environments/production/modules/puppet
INFO     -> Deploying module /etc/puppetlabs/code/environments/production/modules/network
INFO     -> Deploying module /etc/puppetlabs/code/environments/production/modules/tools

As you can see it’s now deployed the code as expected. Using the -v switch will give you the output, otherwise r10k will not give any output. There are additional options such as debug or color which are pretty neat. Also you’ll notice that I am running this as r10k since all the files are owned by that user.