One thing Nathen said in his talk, and that I’ll repeat here, is that Chef isn’t necessarily “better” than Puppet, or vice versa. If your team already uses one, there’s no need to switch to the other. Puppet was already well established at TeamSnap when I joined the team there, so I’m not pushing a move to Chef. My interest in Chef is more to satisfy my own curiosity.

And speaking of which, if you have a small application that runs comfortably on one server, Chef and Puppet are overkill. In fact, running your own server is probably overkill, too. Consider using Heroku in this case. Seriously, Heroku’s a great product, and pretty affordable for small applications that don’t need a lot of extras. And you won’t need to worry about administering your platform at all.

Over the past several days, I’ve been messing around with Chef for some of my own servers, and although I’m not going to give a full tutorial here, I’ll share some advice from my experience.

First, I really recommend using Hosted Chef, especially if you’re just starting out. Installing your own Chef server is not particularly difficult if you use Debian/Ubuntu packages, but it pulls in a lot of stuff, and unless you’re already an expert in everything it depends on (CouchDB, RabbitMQ, etc.) you’re going to basically be left with a black box anyway. In that case, you might as well let someone else manage the black box for you. You get five nodes for free with Hosted Chef, making it a great option for the first-time Chef experimenter. So skip the Chef Server set up and spend your time on actually using Chef!

Even if you do set up your own Chef server, it’s probably a good idea not to set it up on the same network or cloud as the servers it’ll be managing. It’s not very likely that Amazon or Rackspace will disappear tomorrow, but if they do, and your Chef server is there along with all your production servers, you’ll be starting over from nothing. Keeping your Chef server elsewhere (or using Hosted Chef) would make rebuilding from bare metal a lot easier in this case. (If you’re concerned about traffic, don’t be; my experience so far is that Chef doesn’t hog much bandwidth after you’ve bootstrapped a new node, and even the bootstrap isn’t too heavy.)

Once you’ve got your Hosted Chef or Chef server going, start looking for cookbooks. The Opscode Community is your one-stop shop for this. Take a look around; it’s very likely that you’ll find cookbooks for just about every part of your platform, including app servers, database servers, mail servers, random other bits you depend on, and so on. Don’t reinvent wheels! The cookbooks you get here will almost certainly do what you want. If they don’t, you can fork them and adjust to taste. But you should definitely build upon what’s out there rather than starting from scratch.

That said, you’ll probably want to write your own cookbook at some point, to handle the little nuances and other local preferences that you have. Before you do that, read up on recipes and resources at the Chef wiki. Ruby hackers will feel right at home with Chef’s DSL, and once you’ve got a grip on using recipes and resources, you’ll have no problem assembling your custom cookbook.

Knife, Chef’s command-line tool, is pretty easy to learn, and you’ll be using it extensively. You can edit many of Chef’s data structures, such as roles and data bags, through Knife. One gotcha you’ll probably run into is if you use an editor that forks by default, like MacVim or TextMate, Knife will not wait for you to finish with the editor. Git also exhibits this behavior, so you’ve probably seen it before. You’ll need to either change the EDITOR in your environment to something that doesn’t fork (I use mvim +0 -f --nomru) or pass that something to Knife using the -e switch. It’d be nice if Knife respected a separate KNIFE_EDITOR variable, or allowed the editor to be defined in its configuration, as GIt does. But it’s not so hard to work around once you know what’s happening.

I’ll be working more with Chef in the coming days and weeks, so I’ll likely have more to say then, but at this point I’ve managed to define a lot of infrastructure in Chef, to the point where I can bring up a new server (including provisioning the new cloud instance) with a single command. As an inexplicably-famous hotel heiress once said, that’s hot.

Stay tuned for more in the future…

There were tons of deprecated features that I had to address. Most of them were no big deal. Learning the new ActionMailer API took a bit of head-wrap-around, but in the end it wasn’t a problem. The biggest problem was that Shoulda just failed horribly in all of my functional tests (yes, I’m still using good old Test::Unit, not rspec - that’s a paradigm shift for another day.) The unit tests were fine, but the functional tests that had run perfectly under Rails 2 broke inconsistently under Rails 3. In the end, I ended up rewriting the functional tests to not use Shoulda, and ran those tests instead. When everything else was working, I put the Shoulda-fied tests back in, and they worked fine. I spent a few hours de-Shoulda-fying the tests, but I’ll chalk it up to a useful learning exercise.

One thing that bit me was several of my “destroy” links on the admin side simply failed to work. This was my own damn fault; I should’ve been using form submissions to do these all along. As often happens, Stack Overflow pointed me in the right direction and I replaced all the link_tos with button_tos. That fixed that.

So at this point, I’ve got the application running on Rails 3.0, with all of the tests passing, and it works well in development mode on Pow. The next step will be uploading this to a new app on Heroku, alongside our existing Rails 2 app, and pounding on it for a while. But it all looks good right now.

Once this is done, moving to Rails 3.1 is the next step. We don’t do a lot of JavaScript at Klang, but we’ve got some, so the asset pipeline is likely to be our biggest challenge. And from there, who knows… maybe we’ll all be on Rails 4 by then?