We use Debian packages almost exclusively. Often we have to roll our own for one reason or another but for us it's worth the time.
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
Archive powered by MHonArc 2.6.16.