6

I'm experimenting with Puppet scripts for deployment.

I find the hardest part about the process of writing those scripts is iteratively testing them.

I don't want to puppet apply on my local development machine, that liable to screw stuff up. I have a clean-slate remote box where I want to apply. I also don't see how a puppetmaster can help me; I might be using a puppetmaster at a later point for production deployments, but for now, I just want to get my code working.

So I put together a quick shell script that would rsync the different directories from my local puppet module path to /tmp on the remote machine, and then run puppet apply. This is terribly inconvenient. It's slow, especially if we're talking about a syntax error.

I think what I want really is something like a puppetd <-> puppetmaster connection, where puppetd on the remote machine receives an already compiled manifest. Just an adhoc-one over a SSH connection, without having to actual setup an Puppetmaster, dealing with certificates etc. puppet apply user@host.

There seems to be nothing of the sort, but how do other people deal with this? I experience of working on a Puppet script is incredibly frustrating to me, as is.

miracle2k
  • 29,597
  • 21
  • 65
  • 64
  • 2
    You seem to be under the misaprehension that starting a puppetmaster daemon is difficult, as everything you're describing points to just using a puppetmaster. Most distros have a puppet-server type package, you install it, certificates aren't a bother - you only sign them once. You can just then re-run puppetd/puppet agent on the client, or use puppet kick to do it remotely. Give it a try I say. – Dominic Cleal Jul 04 '12 at 18:36
  • 1
    Other suggestions are to use to both `puppet parser validate` (or `puppet --parseonly` on very old versions) to find syntax errors, puppet-lint to find other higher level issues and consider writing tests for your manifests. see [Verifying Puppet: Checking Syntax and Writing Automated Tests](http://puppetlabs.com/blog/verifying-puppet-checking-syntax-and-writing-automated-tests/) – Dominic Cleal Jul 04 '12 at 18:39
  • 3
    Have you tried running `puppet --noop --test`, which effectively conducts a dry run on a machine? While the nature of your scripts may cause certain conditions that are interdependent to fail in certain edge cases (e.g., using content-based heuristics, exec results, etc.) it should give you a meaningful insight into how your script will execute. I find this method very useful for experimenting with manifest changes where resources are related - Puppet does not have a fixed execution order without extremely tight resource constraints, each dry run may produce a different order. – plasmid87 Sep 18 '12 at 10:59

7 Answers7

9

I'd recommend using Vagrant. If you're not testing the puppet master setup you can use the built in provisioner integration.

Once you have everything setup you can run vagrant provision or just run puppet apply on the vagrant vm.

Here's a related article you may find helpful as well.

Mualig
  • 1,444
  • 1
  • 19
  • 42
Mark Roggenkamp
  • 144
  • 3
3

I would also take a look at puppet rpsec tests, using rspec-puppet and puppetlabs-spec-helper. The rspec-puppet-init will break puppet doc and geppetto and maybe some other things due to the symlinks, and there are some issues with hiera, but the tests are easy to setup otherwise and work well, and can also be tied into jenkins/hudson.

Community
  • 1
  • 1
Lee Lowder
  • 703
  • 1
  • 7
  • 18
2

I usually have two levels of testing for my Puppet scripts.

Unit tests for quick feedback: Written using rspec-puppet, these compile a Puppet catalog for the class/define/etc being tested, and make assertions about it. Run locally each time I make a minor change, and on the build server each time I check in. The tests run quickly (<10 seconds), and pick up syntax and dependency issues.

Functional tests to make sure it really works: Written using Cucumber with the Aruba library. When I'm finished implementing a feature and the unit tests for it pass, these tests provision a VM (using Vagrant) with the appropriate Puppet manifest(s), log in, and make assertions about the VM's state. The tests themselves look something like:

Given I am SSHed into Vagrant box "webserver"
When I type "php --version"
Then the output should include "PHP 5.4.11"
Daniel
  • 10,115
  • 3
  • 44
  • 62
1

Vagrant is the most useful environment for rapid infrastructure development that I've found. It most closely (99%) will mirror your production setup, and you can account for those tiny differences in puppet so everything works as expected. It takes about 30 minutes to get going with it and will pay you back many times over in saved time messing around with file copy scripts :)

If it's helpful to visualize, on my desktop I have 3 terminals side by side:

Terminal 1) Editing puppet manifests, classes, ruby code, etc Terminal 2) Running 'vagrant provision' which simply does a puppet apply along with any facts you want to pass, etc. Terminal 3) 'vagrant ssh' into the box so I can poke around as puppet is doing its work

Hope this helps!

liquidki
  • 1,234
  • 16
  • 16
0

I stumbled across rump while looking at another question. If you're using git, it might be useful. There's a slide deck available.

From the README.md: "Rump helps you run Puppet locally against a Git checkout."

Community
  • 1
  • 1
pwan
  • 2,894
  • 2
  • 24
  • 38
0

Why don't you want to run a puppetmaster? It's created for exactly this situation.

If you absolutely cannot run a puppetmaster, then you would have to wrap your puppet calls in another script that first downloads the file (with curl or wget) and apply them after a successful download. Given that the puppetmaster is a fairly simple application to run, I don't see how not using it would be any better.

0

You may be interested in citac, a toolkit for automated testing of Puppet scripts. It is available on Github: https://github.com/citac/citac

Citac systematically executes your Puppet manifest in various configurations, imitating transient system faults, different resource execution orders, and more. The generated test reports inform you about issues with non-idempotent resources, convergence-related issues, etc.

The tool uses Docker containers for execution, hence your system remains untouched while testing. State changes are tracked during execution of the Puppet script, and detailed test reports are generated.

To get an idea of which bugs the tool is able to detect, a large-scale evaluation with more than 150 public Puppet scripts has been performed. The results are available here: http://citac.github.io/eval/ Please feel free to provide feedback, pull requests, etc. Happy testing!

whummer
  • 487
  • 3
  • 4