I recently talked with Reductive Lab’s Luke Kaines and Google’s Nigel Kersten on the topic of Puppet. First, we go through a quick overview of what Puppet does - establishing the desired configuration of machines by modeling services and then enforcing that model.
As I note in introducing Nigel, while Puppet is well known for managing servers, I haven’t heard about it being used too much to manage desktops, making his expierience that much more interesting. On this note, later in the conversation, Luke paints out the many different scenarios that Puppet is used in: from servers, desktops, to new situations like virtualized installs, even on Amazon EC2.
Using Puppet at Google
Nigel has been using Puppet to manage “many, many thousands” of Mac desktops used at Google by developers and others. He tells us how he got involved in using Puppet last year during WWDC last year and quickly applied its use to managing Google Mac desktops.
How Puppet Works
I then ask Luke and Nigel to tell us how people usually get started with Puppet. Both recommend starting with a very small service to get started quickly, for example, managing sudo or SSH. As Luke explains, sudo is the command that allows users to execute other commands with administrative privileges, and managing it means ensuring that sudo itself is permissioned and configured correctly for use. Nigel says that, indeed, this is exactly the service they started with.
We then dip into the details of Puppet by talking about the modeling language that it uses. While Puppet is written in Ruby, the modeling language isn’t, being more like “the psuedo-code you write down when you’re planning what a program should look like,” as Nigel says. On the topic of the modeling language, Nigel comments on new user’s common reaction to the language, namely looking for something more script-ish. The point of the language is to simply model resources rather than describing in detail how to go about configuring those resources. As such, there’s more giving up control on how configuration desires are fulfilled - focusing on the what and ignoring the how, as Luke says.
Deploying Puppet and Ongoing Use
At this point, I get curious about how Puppet itself is configured and deployed. Each machine to be managed needs the Puppet agent installed that works with the main Puppet server. Nigel also tells us how his team tracked down the unmanaged desktops in Google.
Here, we get into the ongoing use of Puppet once the initial setup is done. Luke talks about his ideas that admins and operations people would benefit from thinking more like developers - using the term “infrastructure developer.” For example, Nigel talks about using a version control system to keep track of the configuration models used by Puppet and Luke talks about work that he and Andrew Shafer (at Reductive Labs as well) are doing around brining unit testing to operations.
Expanding Puppets Use in Google
Finally, while wrapping up, Nigel tells us that his group has convinced the people using CF Engine to manage Linux work-stations to start switching over to Puppet. More than just cause for Luke to do a little dance, this is interesting because, as Nigel says, it’s encouraging the Mac and Linux operations groups to collaborate more which, one would hope, would increase their overall effectiveness both in human terms (reducing repetitive work across the two groups) and work-product quality (making sure both actually have the exact same effect when desired across both platforms).
Disclaimer: Reductive Labs is a client and sponsored this podcast.
Previous Topic
