It’s easy to find posts about how to set up a Rails server manually. There are a ton of them out there.

It’s also easy to put off setting up Chef until later on. After all, how often are you going to set up a server? Do it manually, then automate when you need to, right? That’s the tradeoff.

Why would you use Chef before you had to?

That’s a good question. Let’s talk about that.

Chef and Vagrant for Test Servers

If you use Vagrant you can easily put together a test server. Unfortunately, if you just type a bunch of commands into your Vagrant server, you’re always at the mercy of the VM going away.

Or you can use Chef. And then you can always get a clean new VM matching your server pretty well.

With a test server, you can answer questions like, “will this work if I type it on the production server?” And you can do it without crashing production. So that’s kind of cool.

Chef If Your Server Gets Owned

The Internet is more dangerous than it used to be. Servers get messed up. People screw with your app, your database, your WordPress install and so on.

If Chef can roll you a new server from scratch, you can reinstall — with the latest security patches — in a hurry if you ever need to.

Fifteen or twenty minutes can seem like a long time, but it’s a lot faster than you can hand-roll a server.

Chef for Staging Servers

Most people don’t put together a staging server – after all, if you just did a bunch of one-off commands, it’s a pain, right? “Most people” are missing out on that being easy because they’re not using Chef.

Why do staging when you can make a Vagrant server, like up above? Mostly to get a really exact match for the server config. Most problems show up on a test server on Vagrant. A few don’t, because they require the exact RAM or CPU specs on your production server, not a local lookalike.

For those last few thorny problems, a staging server is nice.

And with Chef, configuring either or both is pretty easy.

Chef to Make Changes

Chef doesn’t just put together your server in the first place. It will also fix little things as you go along. Chef can be a great way to make sure, for instance, that a config file stays exactly like you want it. You could re-copy it on demand or fix it by hand, but it’s kind of nice not to have to.

Better yet, you can ask Chef to do a dry-run. Then you’re not making changes, you’re just asking Chef, “hey, see if anything I said to keep the same is now wrong.” It works a bit like Tripwire that way.

Chef as Record Keeping

It’s easy to type something ill-advised. It’s easy to make a typo, or to cut-and-paste something you didn’t understand. It’s also easy to have your browser insert Unicode characters or spaces are who-knows-what when you cut and paste.

That means it’s easy to configure a server slightly wrong and not figure it out for hours.

Chef is a heavy-weight way to keep records. And it doesn’t guarantee no typos. But man, being able to go back and say “try that again, what went wrong?” lets you find a lot more typos for yourself, doesn’t it?

Chef As About Ten Different Good Ideas

I’m a believer in getting your server reproducible and well-recorded as quickly as possible. One way to do that is Chef (another is Puppet, another is Ansible, another is SaltStack, another is…)

Of course, it’s easy to say “but deploying with Chef is harder than doing it once!” And I have things to get done! Also, writing deploy code is annoying when I could be writing app code! Plus I totally go off the rails sometimes!

(And you’re not wrong about those.)

But sometimes automation is a really good idea, and it’s nice to have somebody else’s guidelines and mental models around to help you.