Introduction

I’ve been using Puppet for about 2 years now and have decided to start sharing my thoughts and experiences. I have read many blogs over this time which have helped me get to where I am now, and I’m hoping that I can write down some of the things I have learned so that it may assist others. In particular one of the basics of writing a Puppet module which I think is often glossed over is setting up some decent testing.

I’ve written some basic puppet-rspec tests for modules I have developed in my workplace, but this has been limited to running tests locally. The trigger for writing this article/series funnily enough was the idea to explore using Travis CI for some automated testing of personal modules. I’ll cover some other basics of Puppet modules, and I’m hoping at the same time to convert myself (and maybe you) to a more test driven development workflow.

This article will be focussing on setting up our local testing environment.

Some recommended reading:

• https://docs.puppet.com/guides/style_guide.html
• https://docs.puppet.com/puppet/latest/reference/modules_fundamentals.html

Assumptions:

• You have some experience with Git/GitHub
• You have some experience with Puppet
• You have some experience with Vagrant

I’m also assuming that you can take care of the software installations yourself.

Software Versions:

• Vagrant 1.7.4
• Virtualbox 5.0.20

You’ll also need the following Vagrant plugins to be installed:

vagrant plugin install vagrant-auto_network
vagrant plugin install vagrant-hosts
vagrant plugin install vagrant-r10k

Getting Started

We will get started by obtaining the source code I have already prepared from GitHub:

git clone https://github.com/pckls/puppet-pmb-vagrant.git
cd puppet-pmb-vagrant
git checkout tags/v0.0.1 -b feature/part1

Ok, so what did we just do?

We cloned a Git repository and created a branch based on a tag. To put that in simple terms, we have just time traveled through the repository to a point in the past that coincides with this article (part 1 = v0.0.1). Let’s take a quick look around.

The Vagrantfile we are using is relatively complicated, you are welcome to take a look but you can also just ignore it and assume it just works (nodes.yaml is the only place you need to look to add/remove nodes).

The contents of nodes.yaml should be:

---
centos7:
    boxname: puppetlabs/centos-7.0-64-puppet
    cpus: 1
    memory: 512
trusty:
    boxname: puppetlabs/ubuntu-14.04-64-puppet
    cpus: 1
    memory: 512

We have two nodes in our Vagrant environment, one CentOS 7 and one Ubuntu Trusty server.

The contents of puppet/environments/vagrant/manifests/site.pp should be:

hiera_include(classes, [])

This is a really simply site.pp manifest that will include classes defined in Hiera. I’m not going to explain this here but you can read the official Puppet documentation to learn more if you don’t already know about this.

The contents of puppet/environments/vagrant/hieradata/common.yaml should be:

---
classes:
  - pmb

All nodes will include the class pmb in their catalog.

The contents of puppet/Puppetfile should be:

mod 'pmb', :git => 'https://github.com/pckls/puppet-pmb.git', :tag => 'v0.0.1'

This file defines the modules that are checked out by the vagrant-r10k plugin and used to provision the servers in our test environment. You can override the r10k checked out module by putting your own version of the module into puppet/modules_dev but we’ll talk about this more later.

At v0.0.1 the pmb module has a single class with the following contents:

class pmb {

  notice("Hello, my Operating System is ${::operatingsystem}")

}

Quick summary:

• We have two nodes in our Vagrant environment of differing OS
• We are using Hiera to classify our nodes
• We are including the pmb class/module for each of our nodes
• We are using v0.0.1 of the pmb module
• The pmb module outputs some text, including the operatingsystem fact

Hopefully you have followed everything so far, as previously mentioned this article is written assuming you have already encountered Puppet/r10k/Vagrant before and explaining these concepts is not the intended purpose.

We Have Liftoff

Now that we (hopefully) understand what is happening it’s time to bring up our test environment. Make sure you are back in the root of the repository we checked out and issue the following command:

vagrant up

This will take a few minutes to complete and you should end up with a whole bunch of output. If you look carefully you should find the following lines:

==> centos7: Notice: Scope(Class[Pmb]): Hello, my Operating System is CentOS
...
==> trusty: Notice: Scope(Class[Pmb]): Hello, my Operating System is Ubuntu

This is what we expect, both nodes are provisioned with the pmb class which outputs some text, including the operatingsystem fact. Pretty simple stuff, and not very useful so far. In the next installment we’ll move onto making changes to the pmb module and get some simple automated testing working.