Thursday, February 07, 2008

I’m currently reading Pulling Strings with Puppet, the new book from Apress. So far I’m really enjoying it, look for a review in a week or two. The book whetted my appetite to learn more about Puppet though, so I decided to go to the source and talk to Luke Kanies of Reductive Labs, the development team behind Puppet.

About 4 years ago, I had a pretty clear idea in my head of how I wanted to implement a tool to manage resources, and specifically how each resource type would basically just be a collection of attributes, each with their own behaviour and with the majority of the resource’s behaviour coming from the attributes, not the resource itself. I’m not saying this was a good idea, just that I had it. :)

I was a sysadmin who did a lot of development at the time, which basically meant I was a perl developer, and I was mostly doing OO in my perl. I tried to implement my idea in perl, but I just couldn’t get the class relationships to work (the attributes and resource types each needed to be classes, according to the design in my head). This was back when Python was the shiznit, so I naturally tried it, but Python just makes my eyes bleed (and no, it wasn’t the whitespace, it was things like the fact that ‘print’ was a statement instead of a function, and ‘len’ was a function instead of a method).

I had a friend who had heard Ruby was cool but hadn’t actually tried it himself. Since I was just messing around at the time, I figured I’d give it a go. Four hours in, never having seen a line of Ruby previously, I had a functional prototype.

When I decided to go full time on Puppet, I spent a lot of time agonizing over whether to stick with Ruby (I can’t seem to find a link to the original discussion), because I was rightly concerned that not many people had Ruby deployed and in fact it was a very niche language at the time (this was long before Rails had ever been released).

In the end, I figured developer productivity trumped nearly everything, so I jumped.

How did you get started with systems management?

I am apparently fantastically good at breaking computers, and not so good at fixing them. Thus, when I did fix them, I tended to write code to allow me to repeat that fix. Even in m earliest computer-using days (I’m a Johnny-come-lately—my first computer had a CD-ROM drive and a 500MB hard drive), I could rebuild my computer by booting from a different drive and moving a few directories around.

As I used this ability to get computer jobs, I found that life was always easier when I could teach the computer to do the work rather than doing it myself—the computer doesn’t get bored, and if it’s complaining, I can’t tell. Things got really going for me when I switched from MacOS to *nix (yes, I was doing near-unattended MacOS installs in 1997, using AppleScript and everything).

As the tools got bigger, so did my dreams, and eventually I realized that the only person who was going to create the tool I wanted was me.

Why Puppet?

Puppet’s fundamental advance is its concept of a resource—it builds an abstraction over the things we need to manage, and then uses this abstraction as a kind of API into the operating system. This abstraction allows us to build truly portable configurations that work across multiple platforms, and it also enforces a declarative view of the world instead of the traditional procedural scripting view. See my most recent LCA presentation1 for more information.

The goal for Puppet’s resource abstraction layer is that it can be the lowest layer in a configuration management stack, but so far we haven’t had the time to get much beyond Puppet itself.

What are your future plans for Puppet?

I’m pushing toward a 1.0 this year, hopefully, as soon as I can get the critical APIs stable. I’m also hoping to add a lot of interesting functionality around making each host’s resource catalog more useful outside of Puppet—e.g., you could have all of your resource relationships set up in it, modify /etc/ssh/sshd_config, and then tell Puppet to figure out what services need to restart because of that change.

As we move toward a more database-backed catalog, vs. the current YAML-dumped version, we’ll get a lot more functionality out of it yet, and I can’t really even see most of that functionality right now.

What are some cool things that people are doing with Puppet?

Google’ s managing more than 6000 Mac OS X laptops and desktops with
it, which I think is pretty cool. Red Hat has built a tool called
cft2, which goes some way toward converting traditional-style work
into Puppet code. Julian Simpson at Thoughtworks has done some cool
integration with Cruise Control that uses Puppet and virtualization to
automate testing Puppet configuration3.

Puppet seems like a great solution on the front end of the sysadmin space (configuration management). Is there room for (or a need for) a good Ruby monitoring framework? If not, why not?

I’m not really sure that the language of the framework matters all that much. I chose Ruby because it did the job the best for me during development, not because I wanted a Ruby version of an existing piece of software.

If someone can identify clear shortcomings in existing monitoring tools, to the point where a new tool should be created, it might make sense to implement such a tool in Ruby, but I think the monitoring space is pretty congested right now, so I certainly wouldn’t want to try to product a competitive product there right now.

Do you have a monitoring app that you’re happy with?

Fortunately, I haven’t been an operational admin in years, so I haven’t had to deal with monitoring in a long time. Thus, no, I have no app I’m particularly fond of. I hear a lot about monit, and god (which is apparently pretty new).

I haven’t read the book yet, but I worked pretty closely with James Turnbull as he wrote it, and he’s had a huge impact on the community during its writing. He updated many docs online with the info he gleaned from me, and it seems like the community is very fond of the book.

I just got back from Melbourne, Australia, where James lives, and he’s a great guy; it’s definitely nice to get to meet the various community members in person.