What Puppet Isn’t


As much as I really don’t want to write anything even remotely negative about a piece of software that helps me pay my bills, I really feel the need to address what Puppet can’t do. My motivation is the many consulting engagements and conversations I’ve had where people have asked “Can Puppet do X” and I regrettably have to say no.

As much as I’d love Puppet to be a gigantic all-in-one multi-tool that does everything in everyone’s infrastructure, the truth is that it does one thing really well – configuration management. Anything else – and this includes tooling to make it work really spectacularly – has to be installed separately (ie: GIT for versioning your Puppet codebase, although much of this tooling can be managed with Puppet).

So here’s a list of stuff Puppet doesn’t do, with my recommendations on what you can use instead.

Application Deployment

This is the #1 thing people ask me about. No, Puppet doesn’t do application deployment. It might look somewhat like it can in that there is code in one place that turns into configuration files somewhere else, but Puppet is not well-suited for application deployment. There’s a few reasons for this.

First of all, Puppet works on a state modeling concept. It compares your node’s current state with the catalog that was shipped to the node via the Puppet Master. It only converges on catalog items that have changed. Application deployment’s needs do not align well with this paradigm. Plus, it’s the node that requests instructions from the central codebase. Application deployment uses more of a push model.

Second of all, Puppet does not have a rollback feature. This is one of the many reasons why version control is critical when using Puppet. True application deployment systems have the ability to roll back to a previous release should something go horribly wrong. If you were to try to shoehorn Puppet into deploying your applications, you’d be scrambling if an error got into production.

What you should use instead

I’ve worked with Capistrano before, and it’s a great solution if you’re looking for free and open source application deployment. It’s most popularly used for Ruby on Rails applications, but I’ve successfully used it in a LAMP stack environment.

If you need something a bit more enterprise-level, one of PuppetConf 2014’s sponsors, Xebia Labs, provides a full continuous delivery solution. This means they’ll not only help you with your application deployments, but make sure your code is well-tested too.

Security Monitoring

You could potentially setup Puppet to do a bit of security monitoring. Audit is a metaparameter (which means it can be used with any resource) that can be set to monitor any aspect of a resource. You can also tag those resources, then use tagmail to send the audit reports for those resources to a mailing list.

However, remember Puppet run only about every 30 minutes on a node (or at whatever time you specify). That means if something changes with a resource, it could be up to 30 minutes before you receive a notification that something happened. Additionally, audit can be really chatty, which in turn can turn that signal into noise real fast. And we know what happens to noise. Auto-trash. Plus, Puppet doesn’t tell you who changed that resource, just that something changed.

What you should use instead.

Tripwire has been a popular security monitoring tool for years. It has a free and an enterprise version. It’s a stable and robust tool, and seriously, if you have security concerns, you should try it out.

Patch Management

This is a concern that causes much rending of clothing and tearing of hair. It’s a pain in the butt. You need to keep your packages updated, your stuff stable and secure.

You can kinda use Puppet for patch management. Sort of. But it’s not a fully-featured tool that will make patch management that much easier for you.

If you have purchased Puppet Enterprise licenses, you can do a facsimile of patch management by using Live Management, our orchestration tool. In the Puppet Enterprise Console, under Live Management, click Advanced Tasks -> Package. Select the nodes you wish to view in the left hand panel. Then click “checkupdates” in the main section. This will give you the list of packages that need updating. To update a given package, click “Return to action list” then click “Update” in the options. Enter the name of the package in the text box, then click “Run.”

This solves the issue of needing to update a package across multiple nodes, but you can only update one package at a time. I love Live Management, it’s a powerful tool, but it wasn’t designed with patch management in mind.

What you should use instead

Literally anything. I personally have not used a patch management tool, but SolarWinds has a patch management tool that has a demo version. There doesn’t seem to be an open source patch management tool at this time, which means the first person to come up with something is going to be really popular.

Obviously I’m a huge fan of Puppet. It’s made my life, and the lives of our clients, much easier in so many ways. However, it’s the right tool for a very specific job. No matter how much you love your shiny beautiful wrench, you shouldn’t try to use it as a hammer.

PuppetConf2014 is a wrap!



Holy crap that was a great conference. It took a couple of days to recover, but I think it went really well.

I taught Practitioner Sat-Mon, had a workshop Tuesday, then I did session operator duty on Wednesday. In between, I attended a couple of talks and sat at the Walk-In Clinic dispensing advice. I had much more fun than I should have, but there it is.

Here, have some links:

My workshop Github repo

I attended Jeff McCune’s talk about using Puppet with containers. Here’s his repo.

Day 1 wrap-up with great tweets

Day 2 wrap-up with tweets

Puppet’s Simplified Agent Installer


I just played around with installing a Puppet agent using PE 3.2, using the new simplified installer. It’s nifty once you figure out how it works. Here’s what I did.

First of all, I’m using two nodes, a master and agent, using CentOS 6.5, running virtualized on VMWare Fusion. First, I installed the PE master using the usual bundled install script.

Then, I used PE console to add the proper package class to the available classes. I then classified the Master to use the class. In this case, I used pe_repo::platform::el_6_x86_64. I then ran puppet agent -t on the master to get the packages and scripts in the proper place. Just for shits n’ giggles, I did a service pe-httpd restart to be sure everything would work.

On the node, I then ran:

curl -k https://master.puppetlabs.vm:8140/packages/current/install.bash  | bash

That was it. Everything installed and Puppet is running. Of course, we’re just curling a bash file, and we’re still using a bash script to install Puppet once more…BUT this beats the heck out of an answers file when you think about massive deployments that need fast provisioning.

Rails Girls LA


I have three weeks working out of my house, which is a luxury nowadays. So I’m going to finally do something entirely local, technical, and fun: Rails Girls LA. They’re doing a weekend workshop for beginning Ruby on Rails. While I’ll probably be way overstacked on skills for their first day, I’m doing the first day anyway. They might go over something I’m unfamiliar with, and I really have been wanting to network with other technical women in the Los Angeles area. Plus, the event is in Pasadena, which means networking with women close to home.

At DreamHost, I was usually the go-to person for reading Ruby on Rails error messages. Nobody else could read those damn things. So here’s the funny part – I knew how to debug Ruby on Rails code, but not how to actually write it. I know some Ruby basics, but not enough, really, considering Puppet is written in Ruby, and someday I’d love to teach the “Extending Puppet Using Ruby” class.

I’ve done some self-guided Ruby learning, but I’m nowhere near strong. The kicker came when I taught Advanced Puppet and a duo of our Sales Engineers knew more about how to write Ruby on the fly than I did.

I think a free workshop will knock out two goals – networking and learning Ruby. I’m rather excited about this.

PuppetConf 2014


The deadline for signing up to talk at PuppetConf 2014 is tomorrow. I have registered to do a beginner’s talk regarding new user confusion. I’ll post more about it if/when my talk is approved.

Last year’s PuppetConf was informative, interesting, and a lot of fun. If you get into Puppet at all, I recommend either getting your talk in now, or registering to attend. There’s a 35% off deal right now, which puts the conference at a much cheaper price than a lot of technical conferences.