If you have a “mature”, “legacy”, or just plain old application and are considering using Chef or similar to automate provisioning and deployment, you might be a little discouraged when you browse through the available cookbooks and see that the vast majority of them are written for the latest and greatest programs and frameworks. You might be discouraged at first, like I was, when you see tons of resources for rails apps and ngnix, but not so much for, say, mod_perl and lighttpd. You’ve looked at the documentation for writing cookbooks, and writing a bunch of recipes for your setup looks pretty daunting.
Fortunately it’s not as bad as it looks. I wanted to get our infrastructure at Daily Kos using chef, which meant I had to get it working with our legacy software. The benefits definitely outweighed the headaches from it, and it turned out to be a lot less daunting than it seemed at first. Here are a few general lessons that I’ve learned from getting legacy apps working happily with Chef:
Dig around to see if someone else has already written the cookbook. It may be that someone else has already written cookbooks for parts of your stack. Dig around, use the Googles, or even ask people if they know of a relevant cookbook. Just because you don’t see it in the official Opscode cookbook repo or on the community site doesn’t mean that it’s not out there somewhere.
Could it be added to an existing cookbook? Historically, Daily Kos has run on a mod_perl backend, which has not been the new hotness for many years. Not surprisingly, no one had written a recipe for mod_perl when I first looked into it. Adding it to the existing apache2 cookbook was trivial, though, so I did that. It made what could have been a needlessly difficult task quite straightforward.
Is there an existing cookbook you can crib from? If there’s not an existing cookbook you can use untouched or extend, you might be able to cannibalize it for your purposes. For example, for a while I thought I was going to have to get Apache 1.3 working with Chef. This would have been pretty terrible for many reasons, not least of which having to forward port the old apache13 package from etch to later versions of Debian, and I ended up not having to take it to production. When I thought I was going to have to, though, I adapted the existing apache2 cookbook to install and configure apache13. They weren’t exactly the same, but it was a lot less work than it would have been otherwise.
Another example from personal experience is the lighttpd cookbook (which has been Real Close™ to being released to the world at large for quite a while now, but I’ll get around to it eventually). There wasn’t an existing cookbook I could directly adapt, but I was able to at least derive quite a bit of it from the apache2 cookbook.
Write a cookbook from scratch after all. Hopefully by the time you reach this point, you’ve been able to use the tips above to lessen your load enough and familiarize yourself enough with Chef that it won’t be that big of a deal.
Take the opportunity to tighten your deploys up. If you’re like me, you settled into a workflow for setting up servers that works, but might not be the most efficient. Getting your app working with Chef might be a good opportunity to tighten that process up a bit. For me, the big improvement was finally building custom debs for a bunch of CPAN modules rather than building them directly from CPAN. CPAN is great and all, but after enough time spent sitting and waiting for them to build, along with modules unexpectedly upgrading or dropping certain old versions out of CPAN entirely I took the time to build those debs, and now provisioning’s a lot faster and more consistent. You might not need to build debs, but there’s probably something that could be improved.
Getting your legacy stuff working with Chef might not be quite as straightforward as it is with a newfangled Rails or Sinatra app, but it’s really not that big of a deal. Plus, once it’s out of the way you’re less likely to get delayed by little things like completely forgetting certain random dependencies, or not having anyone else in your company able to set the servers up.
comments powered by Disqus