…because “Poor Man’s Puppet Testing” just sounded lame…
There are better, more effective and automated ways of testing your puppet manifests. However if you are in a position where setting up a CI server is not in the time budget, this article is for you.
This article also assumes you do not have some sort of orchestration tool at your disposal, and uses SSH1 to fake it until we make it. If this is not your situation fret not! You should be able to tailor it to use your orchestration tool of choice with minimal effort.
This article discusses a fairly simple idea – we will be updating some puppet code, committing our changes and having a simple process run noop runs on hosts we specify. The output of these runs will be displayed for us to inspect.
First off, we will need two bash functions. The first is a helper function that
I came up with as a way to abstract away running arbirtray commands on a host
runon. Fancy, right? Fortunately, you should be able to refactor it
to use your tool of choice fairly easily.
Next up, we are going to setup a bash function that is constantly checking a file we specify for hosts to connect and test our manifests against. I use environments to test all code changes2, so the function needs to know about the environment as well as the filename to poll for changes.
With that, we have all the functions we need. Now, let’s put it to use. We will assume I am doing some refactoring in a puppet environment ‘foo’, and want to test changes that would apply to hosts specified in ~/test-hosts
Now open up a new window (or hopefully a pane3) and run the following command:
Suddenly, you will see output in the original pane where we ran
test_puppet_env. For a couple of hosts, this works reasonably well. But
when I am testing a large number of hosts (>5) I typically do the following so
I can grep through the files later rather than read them outright:
Now, in addition to having the output sent to stdout I can have a file I can grep/awk/sed through to find interesting bits of information I’m looking for.
So that’s it. Not too bad, right? Let me know what you think below.
Technically this is SSH in a loop. Sleep well knowing I carry the burden of this terrible deed. Still, let’s keep it between us and not say anything to Luke. ↩
Obviously some code cannot be tested in environments; the most obvious example being types. I assume that you know this, and use something like Vagrant to develop and modify such code in a sandbox. If not, I highly suggest this approach. ↩
tmux (or screen) is your friend here. ↩