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.
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.
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.
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.
3 thoughts on “What Puppet Isn’t”
Hmm. Packaging an app into an rpm/deb, using ensure => latest, and cutting releases by sticking the newest package into your repo seems pretty effective to me.
Correct, but again this is about maintaining end state versus the flexibility in-house developers often need when deploying their applications.
Interestingly enough, I spend a lot of time having these exact discussions, but with some slightly different use cases or roles. In general I think it turns into a desire to use puppet for remote arbitrary command execution.
Application Deployment is a very common one. Although I’ve recently gotten really interested in the idea of using custom written MCollective agents/applications for this purpose.
Another painful one I’ve run into recently is use of @@exported resources with tags to become a service discovery tool. It’s been super painful when I’ve seen this attempted to be done.
Patch management is an interesting one, I hadn’t thought much about it before.