[chef] Re: Re: Ruby, Chef, Omnibus and you!

[Jesse Nelson < >]

We package our own ruby on cent/rhel 4/5/6. We then use bundler to
bundle chef up into an rpm that is self contained. This keeps chef and
all its deps in ruby space away from the system and system gems.  We
do the same thing for other ruby tools/infra we deploy.

We originally tried packaging the ruby and all gems as rpm's but the
management overhead for doing this was pretty heavy. As well as
running into conflicting gem versions for some tools we had out in the
wild.  The new system requires usually just a bump of the chef version
and an rpm rebuild.


my spec files for doing all this are in my repo:
https://github.com/spheromak/chef-bundled


On Tue, Dec 27, 2011 at 12:32 PM, Alex Soto 
<
 >
 wrote:
> I've tried using the rvm cookbook and was disappointed with it.  I use rvm 
> extensively in dev environment but as a server deployment solution I was 
> confused with how it worked and ultimately punted on using it.  Granted I 
> spent very little time trying to figure it out, but I just ended up 
> installing a single ruby version that I compile locally inside my bootstrap 
> script.
>
> However I would like to skip the compile and have different rubies and 
> gemsets on a system.
>
> A wish list in no particular order:
>
> - a recipe that allows deploying a rails app that uses ruby enterprise (or 
> some other version, separate from a 'system' ruby if desired)
> - a ruby version that is used by the system for scripts with it's own 
> gemset separate from whatever rails app is on that node.
> - I'd like it so when you're in the rails application's home dir, the right 
> ruby and gems are setup for running any rake tasks or launching the rails 
> console.  The gems are handled by bundler, but the ruby version 'should' be 
> the same as passenger is using.
> - have various rubies already compiled or packaged, ready for install so I 
> can skip the compile step to cut down on node provisioning time
>
> On Dec 27, 2011, at 11:13 AM, Joshua Timberman wrote:
>
>> Ohai!
>>
>> I'd like to start a conversation and collect feedback about how Chef
>> should manage Ruby at an OS/app level, in particular when Chef is
>> installed using the "Omnibus" full stack installer[0]. Feedback
>> collected will better help us in providing cookbooks that work with
>> Ruby applications besides Chef.
>>
>> The Omnibus full stack installation of Chef includes Ruby for Chef to
>> use. This is convenient for Chef, but it means that the system
>> (typically) will not have Ruby installed anywhere for other tools or
>> applications. While you *can* use the Ruby in the omnibus
>> installation for your applications or other tools, we don't recommend
>> it as it may not match the version of Ruby that you need for your
>> applications.
>>
>> In the past, we assumed that the Ruby installed as a package or
>> otherwise with "knife bootstrap" templates is used by Chef. For many
>> use cases that works fine, however on certain platforms, the default
>> version of Ruby that is available as a native OS package is an
>> outdated version.
>>
>> The Ruby community and the various platform distributors have
>> different goals when it comes to getting Ruby installed on the system,
>> and there are three main approaches. Each of these approaches has
>> different implementation in Chef cookbooks, and indeed different
>> cookbooks exist for each.
>>
>> * Distribution packages
>> * Rvm
>> * rbenv & ruby-build
>>
>> Each approach also has different pros and cons.
>>
>> Distribution packages are very convenient, because typically all you
>> need is "apt-get install ruby" or "yum install ruby" (or
>> equivalent). Compiling source is not required, and all the benefits of
>> using the local package manager are realized. However, they may be out
>> of date for the needs of a particular application. They are also quite
>> different between distributions when it comes to the default packages
>> available in the base repositories, and in the past some have altered
>> the way that Ruby (particularly RubyGems) works. Also, remaining
>> "purely" in package management is difficult because not all the
>> RubyGems you might want to use are packaged, which introduces another
>> layer of complexity for managing systems and applications with
>> Chef. In the past, we managed system packages of Ruby with the
>> `ruby`[1] cookbook beyond what the "bootstrap" process did.
>>
>> Rvm is a set of shell scripts that help install and manage different
>> versions of Ruby and RubyGems. It's flexibility and features have made
>> it a very popular way to deploy and manage Ruby for
>> applications. However, it does assume compiling Ruby versions from
>> source. This is time consuming, and in some environments against
>> security policy (no compilers on production machines). There are at
>> least two cookbooks[3] for managing Rubies through Rvm with Chef.
>>
>> Rbenv is a newer project that can be used to manage versions of
>> Ruby. I personally have not used it, but some folks are switching from
>> Rvm to Rbenv. Rbenv does not install Rubies itself, but it has a
>> helper called `ruby-build` to assist[4]. There are a couple cookbooks
>> for using Rbenv to manage Ruby with Chef[5].
>>
>> What are you doing in your environment to manage Ruby? Are you using
>> the same installation of Ruby with Chef *and* your application? If you're
>> using the Omnibus full-stack installer, are you managing a separate
>> Ruby for your applications?
>>
>> [0]: http://github.com/opscode/omnibus and http://opscode.com/chef/install
>> [1]: http://community.opscode.com/cookbooks/ruby and
>> http://tickets.opscode.com/browse/COOK-409
>> [3]: http://community.opscode.com/cookbooks/rvm OR
>> https://github.com/fnichol/chef-rvm
>> [4]: https://github.com/sstephenson/ruby-build
>> [5]: http://community.opscode.com/cookbooks/rbenv OR
>> https://github.com/fnichol/chef-rbenv
>>
>> --
>> Opscode, Inc
>> Joshua Timberman, Technical Program Manager
>> IRC, Skype, Twitter, Github: jtimberman
>