Puppet – Admin’s Best Friend

Posted by Alexey Kovyrin under Admin-tips, Networks

If you’ve ever worked in companies with 5-10+ servers and it was your responsibility to install new boxes, change some configuration files and install new software on many boxes you definitely know how painful this work is. Every time you need to change something on 3-5-100 boxes, you go there and make those changes. Most experienced of us used some weird scripts to perform some task on many boxes or used some stuff like dsh. Even with those tricks I’d never wish this work to anyone.

While I was working in Galt, I’ve asked our junior admin to check out puppet and try to use it on our servers. After a week of screaming he’s managed to install and configure it and said “Wow! This is what we definitely need!”. Since then he was using it and was happy :-) . But, unfortunately (for me) I’ve never tried it and when I’ve changed my job and started doing the same old (but not good) things like dsh and for+ssh I’ve started thinking: “Stop! Try puppet – maybe it is what you need!”. And what can i say? Yes! This is what every admin needs! Today we’ve deployed our next web server (we do it pretty often) and it was done with puppet – pretty painlessly and quickly.

So, what is puppet? Let me quote their site:

Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files.

Puppet’s simple declarative specification language provides powerful classing abilities for drawing out the similarities between hosts while allowing them to be as specific as necessary, and it handles dependency and prerequisite relationships between objects clearly and explicitly. Puppet is written entirely in Ruby.

Basically, puppet is a tool which lets you describe whatever you’d like about your server(s) and deploy your configuration (configs, packages, files, directories, cron jobs, user accounts, ssh keys, etc) to any number of servers you need. You can describe some simple parts of your system (like “apache”, “nginx”, “rails”, “useful_gems”, “admin-ssh-keys”, etc) and then describe your servers using those terms (like machine X = apache+rails+useful_gems+admin_ssh_keys). When it is done, you’ll be able to deploy all this stuff with one command!

So, if you’re struggling with deploying some changes on many servers or, even, have only a few of them, I’d recommend to try puppet – it could save you a lots of time and nerves.

P. S. When you’ll try to use it – do not give up for a few days – it is hard to change your way of thinking and start writing correct and convenient scripts using puppet’s language.


No related posts.

6 Responses to this entry

DM says:

To make it work together should I have external IP on client machine? Can’t make it work with certificates.

Scoundrel says:

2DM: No, it works on backbone interface for me. First thing I did was assigning puppet master machine a name like puppet.local and adding an appropriate record to /etc/hosts. Then I’ve specified this name in /etc/puppetmasterd.conf:

1
2
3
[puppetmasterd]
reports = store,rrdgraph,tagmail,log
certname = puppet.local
Ilya Martynov says:

Puppet is nice in theory. In practice we found it is quite unstable for big installations (~100 servers): there are multiple memory leak issues in both puppetmaster and puppet client, stability issues where both die from time to time and even file corruptions. These problems are being slowly fixed with each new release but right now using puppet for big installations is source of constant problems and wastes a lot of time of our sysops team. Unfortunately you don’t notice these problems until you get many servers to manage; on smaller installations it seems to work without problems (or at least they happen less often). In our case number of servers we manage increased slowly so we felt into the trap and now rely on puppet too much so it is quite late to change.

If you start afresh I’d take a look on cfengine: it is not as flexible and nice as puppet but probably is more stable simply because it is more old. In the long run puppet will be probably ok too as it is being developed actively but right now it is in “beta” state.

robbyt says:

re: Ilya

Disclaimer: I haven’t run puppet in a large install, just have done initial research…

From my understanding on the inner-workings of puppet, it’s written in 100% ruby. How can a scripting language have memory leaks? Your version of Ruby may leak memory, but puppet itself cannot. It’s possible that the script may have errors or may not have proper error handling that causes it to be unstable, but i seriously doubt that you’re experiencing memory leaks when using puppetd.

Also, i’m not sure about what sort of file corruptions you’re talking about- corrupt configuration files?

Ask Bjørn Hansen says:

Hi Robby,

Huh? Of course you can have memory leaks in a Ruby program – or something to the same effect.

I’ve seen them too in our install of just a few dozen servers, but a restart of the process every few months seems to be plenty to keep it in check. The benefits by far outweigh the problems. I can’t imagine managing more than one server without it now.

One of the really neat things is that it makes it VASTLY easier to recreate a server when you’re upgrading or replacing it.

– ask