Systems administrators have to live with the fact that "configuration management is hard," says James Turnbull, author of the new book Pulling Strings with Puppet. When this task is done, it is often done ad hoc; administrators resort to using a "for" loop and SSH scripts. They may also go with a commercial offering, but this option brings its own challenges. Commercial products are often monolithic and hard to use, configure, learn and manage.
In his book and in this interview, Turnbull describes how to use Puppet and the broader principles of configuration management, particularly when managing multiple systems.
What is Puppet, and how does it benefit IT managers?
Luke Kanies started developing Puppet, a tool to describe and manage configuration. Puppet is an open source client-server application written in Ruby. It has two layers: a configuration language to describe how your hosts and services should look and an abstraction layer that allows you to implement that configuration on a variety of Unix platforms. The abstraction is critical because it allows this implementation without needing to know how each platform configures resources.
How did you get involved with Puppet? Is it related to other kinds of software you have worked with?
My background is infrastructure management, often in large enterprises, and I have a keen interest in tools to make that work easier. I am a strong believer in doing more with less - using automation in order to have more time off. As a result I started reviewing configuration management tools. I didn't find anything I liked until I stumbled across Puppet after reading about it in a blog post. I downloaded it and was amazed at how easy it was to implement. I had Puppet managing a ten-node network a day after I downloaded it.
Puppet is still a young product, but as it grows it'll start to integrate with a lot of other products in this area. For example, you can already manage a Nagios installation with it.
What operating systems work well with Puppet?
Generally, if a platform can run Ruby, then Puppet can be implemented on it. Puppet is focused on managing Unix and Linux infrastructures. It works well on most Linux distributions -- Red Hat, Debian, SuSE, Gentoo, etc. --; and on Solaris, as well as all the flavors of BSD and OSX. Puppet has been run on HP UX and AIX on the IBM pSeries. At this stage, though, Puppet does not support Windows-based platforms.
How has Puppet changed since its first releases?
Puppet is evolving. The last releases have focused on stability and enterprise readiness. The next release completes that cycle by replacing Puppet current messaging, which uses XML-RPC, which has a much more scalable and robust REST implementation. This will allow Puppet to scale to much larger enterprises.
 |
|
|
|
|
"I was amazed with how easy it was to implement. I had Puppet managing a ten-node network a day after I downloaded it."
James Turnbull
Author of Pulling Strings with Puppet
|
|
|
|
|
|
|
|
|
|
That being said, Puppet already manages enterprises with thousands of hosts and facilitates greater integration with other tools. A key example of this is that the REST API enables easier integration with workflow management tools like help desk systems.
What are some applications that can be added onto Puppet? What do they do, and are they designed specifically for the software?
Puppet can be both integrated with other tools and extended itself. You can extend on the base configuration by storing configurations in a database back-end like MySQL or PostgreSQL. A user can also store configuration in an LDAP database, which allows many organizations to leverage data they already have in LDAP about their hosts and services.
At the moment, there are a limited number of applications that are directly integrated with Puppet. The major one right now is Puppetshow, which is a Ruby on Rails application that displays and manipulates Puppet configuration.
What are Puppet's weaknesses? What have been some of the biggest improvements and discoveries in its effective use?
Puppet's current major weakness is the limitations on its ability to scale and integrate. Most of these should be eliminated in the next release. From that point I think Puppet will enjoy a quick and significant growth.
Probably the biggest recent improvements with the product have been community-based. The documentation has expanded considerably and examples – most particularly actual and deployable configuration management examples - have started to appear. One of these is David Schmitt's Complete Configuration, and another is Lab42's similar project. Both of these resources show you how to articulate the configuration of a large number of system components from syslog to MySQL and beyond using Puppet. This makes getting started with Puppet very quick and easy. For a lot of configurations, most of the hard work has already been done for you.
What are some of the most common difficulties users encounter with Puppet? How much of an ability do users have to independently fix these problems?
I actually don't think users encounter major difficulties when engaging with Puppet. The documentation combined with the book and the excellent support provided via the mailing lists and IRC channel make getting started fairly easy.
You don't even have to know anything about Ruby. The community is very helpful and welcoming – one of the benefits of the open source model is the strong engagement from users and contributors.
Puppet is also easy to independently fix and enhance. Being open source means the source code is available to edit and review. If you know any Ruby, and it's a very easy language to pick up and engage with, then you can often fix issues yourself. Puppet is also gathering a strong developer community, and a lot more patches and enhancements are being submitted.
How do you envision Puppet as working with other software to increase user productivity in the future? What will be its functional "niche"?
I think the next big integration targets will be ticketing systems and workflow. Advancement in these areas would allow tickets or workflow to be raised to perform actions. Let's take an example - we want to provision a new web server. We raise a ticket and specify the configuration we want.
The ticket goes through a provisioning workflow, is approved by the appropriate people and then passed to Puppet. Puppet triggers and provisions the web server. The resulting output is passed back to the ticketing system and the ticket is then closed.
That's a very powerful piece of automation, and could make a substantial difference in the cost of operating infrastructure. This is Puppet's ideal niche - making operations run faster, cheaper and more efficiently.
About the author:James Turnbull works for the National Australia Bank as a Security Architect. He is also the author of Hardening Linux, which focuses on hardening Linux hosts including the base operating system, file systems, firewalling, connections, logging, testing your security and securing a number of common applications including e-mail, FTP and DNS. He is also the author of Pro Nagios 2.0, which focuses on enterprise management using the Nagios open source tool.
