Puppet is amazing. It changed my career (thanks to Luke , and before him Mark). However, I have some itches. I have attempted to write about these before, but haven’t felt like pushing the ‘publish’ button.
I’ve been running Puppet in a atypical way for some time now.
- No Puppet Master
- No distribution packaging
- No commit until I know something works
- Only test from the outside
The only thing I feel I need to expand on is the last: testing. Obviously if you write Ruby code, you should rspec the hell out of it. But should you test Puppet code? It’s mostly a declarative language. If you’re properly declaring the outcomes that you want, then it can be easy. If too much logic creeps in, you’re doing it wrong or you should write a function or type – and you should rspec the hell out of that. This approach has served me for years with decalarative build tools*.
I have no desire to go verify that Puppet does what I tell it. But I do care about the outcome. Also, I need to know that it runs on the target platform, as I use a MacBook.
So I wrote Skewer. Skewer’s only job is to:
- Provision cloud machines (or connect to existing ones)
- Bootstrap Puppet (via shell scripts and rubygems)
- Run Puppet
- Optionally run Cucumber features at the end
That scratches my itch. Skewer probably won’t scratch your itch if you run lots of nodes. It works on Ubuntu, though adding support for other operating systems wouldn’t be too hard. You may also like the Puppet Cloud Provisioner.
Skewer evolved from a Rakefile that I used to test my puppet code. I set out to rewrite it over the Christmas period, and got the last feature passing on Friday. Like my other open source project, I learned a lot while doing it. Skewer has some wrinkles, but I use it in my day job, and I’ve managed to keep that so far.
* Okay, I actually do a little bit more. I use Rake to run puppet parser validate on every .pp file in my project, and I use puppet-lint to catch howlers.