Collaboratively work on a Puppet module. Vagrant + r10k.

Once a puppet module is in the forge it is quite easy to share it with other people to try it out. But until then, it can be somewhat cumbersome. They are several reasons why releasing a module to the forge can be delayed :

  • a dependent module has not been officialy released yet
  • a pull request being pending on another module one is relying on.
  • a pull request has been merged but one needs to wait for the maintainer to actually do a new release

All those reasons, make the collaboration on a puppet module a litlle bit harder than a simple puppet module install.

In order to tackle this issue and make collaboration / demo of a puppet module easier let’s see how by using Vagrant and r10k this problem can be solved painlessly and in a versionned controlled way.

r10k

r10k is a project that allows one to specify her puppet module dependencies on a file (Puppetfile) and make a proper deployment on a puppet master or a local folder.

Those dependencies can be expressed either as forge puppet module version number or git repository. When specifying git, the checkout process can be bound on master, a specific branch, a specific commit, etc…

mod 'puppetlabs/ntp', '3.0.3'

mod 'stdlib',
:git => 'git://github.com/puppetlabs/puppetlabs-stdlib.git'

Vagrant (provisioner)

I am sure you’ve heard about vagrant, at least once. It’s a great project that makes collaboration easier by scripting the boot + provisionning of a VM. No more excuses like “it works on my machine”.
By simply using the same Vagrant file and the same base box, two users are sure to have the same result. One of the great feature of vagrant is the provisionning on VM creation.
This is the feature that will be used here. To make the point the following Vagrant file will be used :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

config.vm.box = "MYBASEBOX"
config.vm.provision "puppet" do |puppet|
puppet.module_path = 'modules'
end

end

By default, vagrant will look for a manifet to run in ./manifests/default.pp, hence it is not necessary to specify it here since we will be dropping the file in the correct path.
With the afro mentionned Vagrantfile, vagrant will boot a VM using the MYBASEBOX box and run the manifest/default.pp manifests using the modules/ folder located in the samed directory as your vagrantfile as –modulepath option to puppet.

run.sh (a.k.a “the glue”)

The run.sh script, or however you want to call it, will simply create the appropriate folders and run the r10k install command to retriveve the modules specified in the Puppetfile.
It will then copy an example manifest into manifests/default.pp for vagrant to run it. This is what a basic run.sh could look like :

#!/usr/bin/sh

if [[ ! `gem list r10k` ]];then
gem install r10k
fi
mkdir -p modules
mkdir -p manifests
PUPPETFILE=./Puppetfile PUPPETFILE_DIR=modules r10k --verbose 3 puppetfile install
cp modules/path/to/example.pp manifests/default.pp

It is up to you to customize it to your need.
In this example a file called example.pp was located at the root of the module but it is up to you to have it in an examples folder, simply adapt the script accordingly.

Show time

Long story short, simply run the following command and see the magic happen

vagrant up

Conclusion

By having the Puppetfile and the run.sh script in a git repository, one can easily and repeatedly share the avancement on a given puppet module at any time, without having to wait for upstream release. QED.

Advertisements


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s