Puppet 2.7 Released (groups.google.com)

It's really similar to Chef, but I find Puppet way easier to work with.

Those aren't just the Ruby world's tools, fwiw.

We use Puppet at Disqus (a Python shop). Puppet and Chef are used by pretty much any modern web deployment that didn't already have a system in something more dated (cfengine? custom made?). At least that's the feeling I get.

I can't speak much to Chef but Puppet has great docs. You might just get an intro book for one or the other and dive in.

Puppet is pretty great and at TransLoc we don't use any Ruby. We combine it with packaging all of our code as Debian packages and it makes bringing up a new server a matter of installing puppet, then running the puppet manifests.

Note that the easiest way to start is to not use any of puppet's built-in client-server stuff (puppetd command). Instead run everything like this:

  $ git clone $REMOTE_REPO_WITH_MANIFESTS puppet
  $ ls
  manifests modules
  $ sudo puppet --modulepath=modules/ --debug manifests/site.pp

You could use something like fabric if you only have 1-2 servers.

Puppet and Chef are pretty agnostic. You can use them to manage only your infrastructure (packages, user accounts, databases) and leave app deployment up to something like capistrano or fabric if you like (although at a certain level of app complexity it makes sense to integrate.)

cfengine has been around longer, but seems to have negative adoption since puppet became well-known. I know a few people who swear by it, though.

FWIW, at my current startup I use Chef to manage a mid-sized collection of servers (app, load balancers, DBs/replicas, task processors) where the app is written mostly in Python, and it took a ton of pain out of scaling up to deal with a very large paying customer two nights ago.

Puppet has better documentation, but learning either is a bit of a trial and error process I think. You might find Blueprint (https://github.com/devstructure/blueprint) useful to bootstrap (the authors are around in the HN community, I think.)

I personally use Chef to deploy PHP-based web applications (very little ruby, only running God to be honest), and at work we deploy Python, Ruby, PHP, and all the services and subsystems our applications require.

The biggest pain is that the docs were iffy, at least for me. I wasn't the one setting up the servers at work, but when setting up a Chef cookbook for personal use, it was a pain to both learn the DSL and deal with the silliness caused by bugs that hadn't quite made it to release yet. At the end of the day though, its more just experimenting with the tools available until you're comfortable with one.

You can also look into Fabric, which is a Python server automation tool.

Here's[1] a nice multi-part graduated walk-through of deploying Django with chef. I'm working using it as a guidepost on deploying my Django stuff (currently hitting a VM on my macbook so I can rollback to a snapshot and make sure it works right).

[1]http://ericholscher.com/blog/2010/nov/8/building-django-app-...

The consensus on CM tool choice is simply, "pick one that's comfortable for you and your team," and, "it doesn't matter which one you use, just be sure you're using configuration management." It's definitely better than dealing with shell scripts, since a lot of things you write in your CM language gets abstracted automatically for whatever operating system you're using (this is the biggest takeaway - you really don't want to rewrite shell scripts just because you've decided to add a different Linux distro or UNIX in your network.)

I've used both Puppet and Chef extensively, and they both do the same thing, they just go about it differently. (shameless plug of a blog post I wrote that compared the two: http://redbluemagenta.com/2011/05/21/puppet-vs-chef)

Also, it's almost always about how you approach configuration management - thankfully, with Puppet and Chef, you don't have to manage everything on a system in your CM right away. If you have to manage SSH authorized_key entries and it's getting annoying to do it by hand, then write a Puppet module / Chef cookbook to manage it for you. Then go on to manage /etc/hosts entries, then to deploying packages... you'll hit a point where you can reasonably rebuild a server from scratch without thinking about it.

There's other CM systems out there too: bcfg2, cfengine, etc.

To help you make an informed choice, this summary of the Configuration Management Summit may be useful:

http://www.usenix.org/publications/login/2010-10/openpdfs/Co...

To help you get started with Cfengine (my specialty):

http://www.cfengine.com/pages/tech http://www.verticalsysadmin.com/cfengine/cfengine_examples.t...

Here is a great article on getting started with configuration management, with lots of workable tips:

http://www.usenix.org/publications/login/2011-04/openpdfs/Lu...

I avoid unnecessary complication but wrapping your head around infrastructural complexity is part of being a programmer.

You are not alone, I'm also very reticent to adding yet one more complex tool into my systems when a few simple and clean shell scripts can do the job.

I see where you're coming from - however, the great thing about CM tools is that they abstract a lot of the weird differences between UNIX's and Linux distributions. Defining a user in Puppet or Chef will create that user the same way, whether it's in RHEL, Solaris, FreeBSD, etc.

Puppet is also more lightweight than Chef in terms of the amount of dependencies it requires, given an already existing installation of Ruby (in fact, I think there's only one dependency: facter.) The only problem is that it comes with a lot less available language features out of the box than Chef, mainly because Puppet doesn't have a way to store and serve configurations of other machines out of the box without something backing the data store, like MySQL or CouchDB.

Cfengine has tripwire-like functionality. There is an example in the default promises.cf that ships with Cfengine 3. (Look for "tripwire".)

Over at Seattle Biomed, we keep everything in the same branch (for now) - all of our nodes are defined in nodes.pp, and we have modules that install software/configuration files as needed. We include modules in the node definition that should comprise the service we want to run on the server.