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

[Ranjib Dey < >]

We use ruby1.8.7 from epel for most of the non ruby deployments (mostly j2ee apps), chef works fine with 1.8.7 , for RoR and related stacks we compile ruby from source straight on the servers(as part of the bootstrap process). Initially we had tried using the os packages but due to the outdated packages or the way ruby 1.9.2 is shipped (ruby19 binary?) or some gem dependencies (like passenger/nokogiri/mysql etc) we had to grab the headers and compile them on the servers later on anyway..so , now we install ruby from source, this has helped us developing a uniform way to manage ruby and gems  across different systems.

In between i had tried rvm, it was a real pita, since it assumes you have a shell and does all the trick based on shell env manipulation, it fails on everywhere which does not involve a shell.  We tried retrofitting the deployment strategies so that it uses an user with a shell , but it was too much patch work. rbenv requires less work in this approach

Till now we have never faced any issue with chef in terms of ruby versions, we always use bundler to manage and contain the gems related to apps/services, that way they never interfere with the system wide installed gems. In few rare occasions  we had issues with bundler versions, so now I have specific cookbook for managing bundler. 

We are looking forward with chef omnibus, but i have tried it out with few containers, and the experience was good. Going forward, it will be interesting to see how omnibus addresses other ruby installations (apart from the ships with itself) in the same server and how the behavior of gem_package like resources are affected. But all these matters a lot more if servers are multi tenant  (i.e. they are serving different ruby apps requiring different ruby versions/gems) or if compiler/header file installation are not feasible. 

regards

ranjib

On Wed, Dec 28, 2011 at 11:11 AM, Jesse Nelson < " target="_blank"> > wrote:

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 < " target="_blank"> > 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
>