A while back I wrote about Opscode and Chef. After futzing with it and trying to reverse engineer an existing server into chef recipes, I concluded that it was more trouble than it was worth. Fast forward two years and I’m finally doing a full rebuild of the server stack in question. I decided I’d give Chef another try, and I’m quite glad I did.
For most of us, the overall theory of automated server setup is easy to understand, so I won’t try to extoll all the virtues of Chef. Instead I’ll just try to hit a few of the pros and cons that I encountered and why I think it’s ultimately worth the time investment.
Pros
EC2 Integration
Bootstrapping an EC2 instance with knife is almost magical. Run the knife CLI command, go wander around for a couple minutes, and when you come back your server is up. All your packages are installed, users created, services configured, and so on. It doesn’t sound that magical until you see it, but trust me, it’s really sweet.
Cross-node Uniformity
Tweaking some basic shell environment settings can make working on a server so much nicer. Things like automatically exporting RAILS_ENV, changing your prompt to show the node role, or adding some handy bash aliases. If you’re like me, you add these tweaks on some servers and forget on others and it’s a source of constant frustration. With Chef, you can put these tweaks into a recipe and include that on all your nodes. When a new node boots, these tweaks are all applied automatically.
Clone Environments Quickly
While this is easy to understand, I think most people probably overlook the time savings here. For my current task, I built a staging server setup with Chef, complete with separate subdomains, user credentials, databases, etc. Doing it with Chef took slightly more time than doing it by hand. However, when I’m done testing on the staging server and want to boot to production, Chef (as of 10.10) supports the concept of environments and can boot the same recipes in a different context. More precisely, it will use all the production settings, all the way down to setting up the correct subdomains in the Apache vhost file. I’m guessing it will save me probably 10 hours of boring “futzing” (apt-get installs, apache config settings, etc.) Implicit here is the up-front savings of not explicitly documenting everything. If you’re like me, you try to document your server stack, but it winds up on a wiki page that never gets updated and then you can’t even find it 3 years later when you actually need it. No longer a problem with Chef, as the recipes are the documentation.
Cost
The Opscode platform is free for up to 5 nodes. If you have a fairly simple site (like me) then 5 should be enough. The price climbs sharply after that, but if you have a big dynamic infrastructure, it’s definitely worth the cost.
Cons
Still Not Heroku
Pushing to Heroku is still much, much easier than setting up your own server stack, even with Chef. If Heroku is an option, it’s hard to argue for setting up your own stack. But often Heroku isn’t an option, whether you need some funky software setup, or even just to save money. If Heroku is out of the picture, then Chef should be at the top of your list.
Opscode Data Bag Security
Chef will need lots of authorization credentials in order to set everything up. Think of all the passwords you have in your YAML configs and you have a basic idea. You can either check them into your repo (which conventional wisdom says is a no-no), or you can keep them in data bags on the Opscode system. I went the data bag route and it works very smoothly. However, that means the keys to the kingdom are stored somewhere on Opscode’s servers. If someone were to compromise Opscode’s database, it would be a very bad day for me. I’m curious if anyone else has advice on how to balance security and convenience with respect to getting all your credentials into your Chef runs.
Update: As mentioned in the comments below, this issue is directly addressed by encrypted data bags. So, that’s one less thing to worry about!
Overall
I am extremely pleased with Chef and the Opscode platform. It was no slower than doing everything by hand, and the knife/EC2 integration actually seemed faster to me than my previous experiences with trying to bootstrap EC2 nodes. My entire stack is stored in the repo along with the application code, and it’s easy to follow along and understand. If I were tasked tomorrow with setting up a new server stack, Chef and EC2 would be the first two tools I reached for in the toolbox.
