On Dec 27, 2011, at 11:13 AM, Joshua Timberman wrote:
We're actually building tooling out to do this, likely scheduled for release later this week to our developers and their testing environment -- chef 0.9 still, but I can describe how we're doing it. We have potentially unique deployment needs; where possible I'm detailing those as well, which might shed some light on our rationale and expose a few issues with chef in general. We have a `ruby_build' provider which performs builds of ruby which live in /opt/ruby, and a chef-only build of ruby in /opt/chef-ruby which is built on bootstrap and has compatible recipes to bootstrap legacy systems. There's a (very) small selector tool (ala rvm, but less needy -- see below) for shell users, but the important bit is the clear separation between the "chef ruby" and the "application rubies". The application rubies are linked into deployment dirs by application preference, which are then used by monit/cron/etc with bundler and all that fun stuff (we have about 15 rails applications deployed so this can get a little hairy). As a result, we're able to completely walk away from debian packages which have caused us grief in the past. I realize that may not be an acceptable solution for everyone. Note that chef-client not living in /usr/bin, at least on 0.9 w/ 0.9-compatible opscode chef recipes, is very problematic so all our chef tooling is linked into /usr/bin from the recipe that installs our chef ruby. It's the /etc/init.d scripts that get copied from the gem that are the pain in particular. I would like to advocate this approach, notably, the part where the ruby used by chef *is not used by anything else*. This avoids all sorts of issues (for example, our capistrano deployment system integrates with chef search for reasons I may not be able to discuss) with chef, shef, etc being a part of other ruby-related components on the system. If you could make this happen, I could literally remove about 200 lines of code. :) As for rvm, it in particular doesn't work well for servers in my experience, see here: https://github.com/phillyrb/smoking-chef/tree/master/cookbooks/rvm which is a series of (chef-solo) recipes based on other community versions I built out a while back -- I have had no end to the hell I unleashed with those recipes. Just having it on the boxes introduces all sorts of pathing/rvm-shell issues. rbenv seems to suffer a similar fate with its on-login requirements (but I haven't explored it as well). ruby-build OTOH should work fine and I will be exploring that as an alternative to the (very simple in implementation) provider guts for the cookbook described above. I'm not sure if this helps for anything than to describe an alternative approach, but I figured I should chime in anyways. :) I'm 'erikh' on irc if you want to discuss it further and am normally available on typical PST working hours. -Erik |
Archive powered by MHonArc 2.6.16.