Ruby, Chef, Omnibus and you!

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

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.
On Dec 27, 2011 11:13 AM, "Joshua Timberman" joshua@opscode.com 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]: GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms. 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
GitHub - sous-chefs/rvm: Development repository for the rvm cookbook
[4]: GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.
[5]: http://community.opscode.com/cookbooks/rbenv OR
GitHub - sous-chefs/ruby_rbenv: Development repository for the ruby_rbenv cookbook

--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman

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]: GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms. 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
GitHub - sous-chefs/rvm: Development repository for the rvm cookbook
[4]: GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.
[5]: http://community.opscode.com/cookbooks/rbenv OR
GitHub - sous-chefs/ruby_rbenv: Development repository for the ruby_rbenv cookbook

--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman

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:

On Tue, Dec 27, 2011 at 12:32 PM, Alex Soto apsoto@gmail.com 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]: GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms. 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
GitHub - sous-chefs/rvm: Development repository for the rvm cookbook
[4]: GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.
[5]: http://community.opscode.com/cookbooks/rbenv OR
GitHub - sous-chefs/ruby_rbenv: Development repository for the ruby_rbenv cookbook

--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman

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 spheromak@gmail.com 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:
GitHub - spheromak/chef-bundled: specs and support for bundler based chef

On Tue, Dec 27, 2011 at 12:32 PM, Alex Soto apsoto@gmail.com 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]: GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms. 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
GitHub - sous-chefs/rvm: Development repository for the rvm cookbook
[4]: GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.
[5]: http://community.opscode.com/cookbooks/rbenv OR
GitHub - sous-chefs/ruby_rbenv: Development repository for the ruby_rbenv cookbook

--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman

Hi Joshua,

I've tried the omnibus approach but I'm using the FrameOS build now because I need libselinux-ruby and I couldn't get that to build against the 1.9.1 Ruby in Omnibus. I like the idea of having Chef neatly walled off in a chef-full RPM, but it didn't suffice for me. (We're using RHEL5 as our platform).

Cheers,

Peter

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]: GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms. 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
GitHub - sous-chefs/rvm: Development repository for the rvm cookbook
[4]: GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.
[5]: http://community.opscode.com/cookbooks/rbenv OR
GitHub - sous-chefs/ruby_rbenv: Development repository for the ruby_rbenv cookbook

--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman

--
Peter Burkholder | Sr. System Administrator (consultant)
AARP | Digital Strategy & Operations | 601 E Street NW | Washington, DC 20049
pburkholder@aarp.org | aim: peterbtech | w: 202-434-3530 | c: 202-344-7129
For optimal efficiency, I check email at 2-hour intervals during the workday
(except when on-call). Please use IM or phone to contact me for urgent matters

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.

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. :slight_smile:

As for rvm, it in particular doesn't work well for servers in my experience, see here: smoking-chef/cookbooks/rvm at master · phillyrb/smoking-chef · GitHub 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. :slight_smile: I'm 'erikh' on irc if you want to discuss it further and am normally available on typical PST working hours.

-Erik

Ohai!

On Dec 29, 2011, at 8:41 AM, Burkholder, Peter wrote:

I've tried the omnibus approach but I'm using the FrameOS build now because I need libselinux-ruby and I couldn't get that to build against the 1.9.1 Ruby in Omnibus. I like the idea of having Chef neatly walled off in a chef-full RPM, but it didn't suffice for me. (We're using RHEL5 as our platform).

Fwiw, you can append to the load path and load the selinux library after installing it as a package. I can't speak to how well this library will work with the Ruby version included in the Omnibus installation (ruby 1.9.2p180 as of now on my test system)

[root@centos6 ~]# rpm -qa | egrep "ruby|chef"
chef-full-0.10.8-2.x86_64
[root@centos6 ~]# shef
chef > recipe
chef:recipe > package "libselinux-ruby"
chef:recipe > run_chef
[Wed, 28 Dec 2011 18:08:37 -0700] DEBUG: Processing package[libselinux-ruby] on centos6.int.housepub.org
[Wed, 28 Dec 2011 18:08:37 -0700] INFO: Processing package[libselinux-ruby] action install ((irb#1) line 1)
[Wed, 28 Dec 2011 18:08:42 -0700] DEBUG: package[libselinux-ruby] checking yum info for libselinux-ruby
[Wed, 28 Dec 2011 18:08:42 -0700] DEBUG: package[libselinux-ruby] installed version: (none) candidate version: 2.0.94-5.2.el6
[Wed, 28 Dec 2011 18:08:42 -0700] DEBUG: Executing yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: ---- Begin output of yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6 ----
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: STDOUT:
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: STDERR:
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: ---- End output of yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6 ----
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: Ran yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6 returned 0
[Wed, 28 Dec 2011 18:08:51 -0700] INFO: package[libselinux-ruby] installed version 2.0.94-5.2.el6
=> true
chef:recipe > $: << "/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/"
=> [ OUTPUT TRUNCATED ]
chef:recipe > require 'selinux'
=> true

I'll also update the relevant COOK ticket where this was discussed.

--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman

Joshua,

On Tue, Dec 27, 2011 at 8:13 PM, Joshua Timberman joshua@opscode.com 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.
...
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?

as you know well, we run FreeBSD on most of our servers. Some of them
don't need ruby except for chef, or don't care about a specific
version. On the others (mostly app servers running rails), we've had a
mixed experience.
Chef on ruby 1.8.7 is prone to crashing hard quite often; sometimes we
have 2-3 crashes in a row on subsequent chef-client runs.
Luckily, we only run 1.8 on a few legacy servers so that's not been a
big issue; at least not big enough to look for a complicated solution.
But that's a good example of something we are looking forward to solve
once we standardize on Omnibus.

The scenario is pretty much the same with our customers: most of the
ones who run Rails apps have already moved to 1.9 (or have been using
JRuby), with a small number of legacy apps on 1.8.

We do love rvm on developer workstations, but we don't really care for
the complexity of running it on production servers.
Also, going forward we are focusing on CloudFoundry, which does a very
good job letting each app use the version of ruby it wants, regardless
of what the rest of the system runs.

So the bottom line for us is: as long as Omnibus works nicely, and we
can have a way of installing a separate ruby 1.9 and gems for it, we
don't really need a move involved solution.

Andrea

Hi,
On Dec 29, 2011, at 1:37 PM, Joshua Timberman wrote:

$: << "/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/"

but then.....

chef > require 'selinux'
=> true
chef > Selinux.lgetfilecon("/etc/ntp.conf")
TypeError: in method 'lgetfilecon', argument 1 of type 'char const *'
from (irb):3:in lgetfilecon' from (irb):3 from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:73:in block in start'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in catch' from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in start'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/bin/shef:34:in <top (required)>' from /opt/opscode/bin/shef:19:in load'
from /opt/opscode/bin/shef:19:in `'

So it loads, but it doesn't work. Hmmm.

-Peter

--
Peter Burkholder | Sr. System Administrator (consultant)
AARP | Digital Strategy & Operations | 601 E Street NW | Washington, DC 20049
pburkholder@aarp.org | aim: peterbtech | w: 202-434-3530 | c: 202-344-7129
For optimal efficiency, I check email at 2-hour intervals during the workday
(except when on-call). Please use IM or phone to contact me for urgent matters

Hello!

On Dec 30, 2011, at 9:05 AM, Burkholder, Peter wrote:

$: << "/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/"

but then.....

chef > require 'selinux'
=> true
chef > Selinux.lgetfilecon("/etc/ntp.conf")
TypeError: in method 'lgetfilecon', argument 1 of type 'char const *'
from (irb):3:in lgetfilecon' from (irb):3 from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:73:in block in start'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in catch' from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in start'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/bin/shef:34:in <top (required)>' from /opt/opscode/bin/shef:19:in load'
from /opt/opscode/bin/shef:19:in `'

So it loads, but it doesn't work. Hmmm.

Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.

--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman

On 30 December 2011 22:23, Joshua Timberman joshua@opscode.com wrote:

Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.

If Omnibus is "The Future" then I'm guessing the Ruby which you ship
inside it is going to have a lot of stuff bolted on.

Is that something you've thought about and are okay with?

I'm generally a little concerned that Omnibus could be very divisive.
Those who can use it and benefit, because their needs are simple, and
those who are excluded because they want to use a technology (SELinux)
which is not included and supported.

Whilst I appreciate you will never cater to all needs, and there is a
core of 'power user' out there who will always do their own thing, the
recommended route for deploying chef-client (which seems to be heading
in an Omnibus direction) needs to cater for the masses, and that
does mean things like SELinux (amongst other things) will become
increasingly important to support properly.

Cheers,
-Alex

On 31 December 2011 02:40, Alex Howells lists@howells.me wrote:

On 30 December 2011 22:23, Joshua Timberman joshua@opscode.com wrote:

Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.

If Omnibus is "The Future" then I'm guessing the Ruby which you ship
inside it is going to have a lot of stuff bolted on.

Is that something you've thought about and are okay with?

NB: This means instead of benefiting from the Ubuntu Security folks
handling all the repackaging when a security bug comes out, you guys
are assuming responsibility for patching your intepreter. No longer is
it just chef-client bugs, now you have responsibility for the full
stack you deployed via Omnibus...

On Dec 30, 2011, at 8:40 PM, Alex Howells wrote:

Whilst I appreciate you will never cater to all needs, and there is a
core of 'power user' out there who will always do their own thing, the
recommended route for deploying chef-client (which seems to be heading
in an Omnibus direction) needs to cater for the masses, and that
does mean things like SELinux (amongst other things) will become
increasingly important to support properly.

I'm not convinced that SELinux is something that the "masses" deal with today, or that it is something they will be dealing with in the near future.

IMO, Chef has a long ways to go with regards to better supporting other OS platforms, even just other versions of Linux that are commonly used in the business community (e.g., RHEL/CentOS). Ideally, we would have both better support for other platforms AND support for SELinux, but in reality we have to face the facts that there will always be limits to the available resources.

Of course, the core code supports multiple platforms fine, but one of the biggest advantages that you're getting with Chef is the community cookbooks, and that's also their Achilles Heel with regards to support for platforms other than Ubuntu. That said, this kind of thing is entirely expected when you're talking about such a young product from such a young company, especially one that has such strong ties to the open source community. Given time, this problem would tend to largely resolve itself as the company grows, the customer list grows, and the community grows.

My biggest concern is the risk that we might all get put on the back burner so that they can focus on Windows. That's the biggest potential market with the biggest potential ROI, and I think it would be the most attractive to bean counters.

However, I also think it is also a huge risk that Microsoft might wipe them out with a single stroke -- or worse, buy them up and then kill support for all non-Microsoft OSes.

--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1

Le 31.12.2011 05:02, Brad Knowles a écrit :

On Dec 30, 2011, at
8:40 PM, Alex Howells wrote:

Whilst I appreciate you will never
cater to all needs, and there is a core of 'power user' out there who
will always do their own thing, the recommended route for deploying
chef-client (which seems to be heading in an Omnibus direction) needs to
cater for the masses, and that does mean things like SELinux (amongst
other things) will become increasingly important to support properly.

I'm not convinced that SELinux is something that the "masses" deal
with today, or that it is something they will be dealing with in the
near future.

I-- Brad Knowles SAGE Level IV, Chef Level 0.0.1

I've
to agree that se-linux is not a widely used system in my experience
(usaully disabled because causing more troubles than help to secure).

As a sysadmin I do prefer to ensure critical system parts are secured
in an usual way than relying on se-linux which would need me to add one
more rule to do a dumb thing touching system files.

I've a point of
view which is: relying on se-linux and saying the box is secure is the
same as thinking you'll be able to stop properly when driving at 200
Km/h with an ABS on a rusty car. In brief: fix the car before adding it
drive assists.

So if you really rely on SE-Linux and can't do an
update path using chef, there's a problem in the way Se-Linux is
configured.

Tensibai.

Links:

[1]
mailto:bknowles@ihiji.com

We use REE and usually install it via a custom written script. I tried
using ruby build but it didn’t work with the latest version of ubuntu
the last time I gave it a shot.

Looks like REE is about become history though so we will have to move
on to something else either MRI or Jruby.

out of curiosity, where have you heard that REE is history ?
I checked Phusion's web site, no mention of this...

Hani

On Sun, Jan 1, 2012 at 6:28 AM, Tim Uckun timuckun@gmail.com wrote:

We use REE and usually install it via a custom written script. I tried
using ruby build but it didn't work with the latest version of ubuntu
the last time I gave it a shot.

Looks like REE is about become history though so we will have to move
on to something else either MRI or Jruby.

The short answer: yes. Nothing about the omnibus approach make this harder, and the alternative is untenable today - target the lowest common denominator (rhel 4, honestly, for a while longer) for everyone.

For the vast majority of dependencies, having to keep track of security updates is already a born cost.

If we want to deliver a sane, viable experience on every platform, this is the way forward, in my opinion.

For the selinux case, building the selinux bindings on platforms that support them is trivial to do.

Adam

Sent from my iPhone

On Dec 30, 2011, at 6:40 PM, Alex Howells lists@howells.me wrote:

On 30 December 2011 22:23, Joshua Timberman joshua@opscode.com wrote:

Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.

If Omnibus is "The Future" then I'm guessing the Ruby which you ship
inside it is going to have a lot of stuff bolted on.

Is that something you've thought about and are okay with?

I'm generally a little concerned that Omnibus could be very divisive.
Those who can use it and benefit, because their needs are simple, and
those who are excluded because they want to use a technology (SELinux)
which is not included and supported.

Whilst I appreciate you will never cater to all needs, and there is a
core of 'power user' out there who will always do their own thing, the
recommended route for deploying chef-client (which seems to be heading
in an Omnibus direction) needs to cater for the masses, and that
does mean things like SELinux (amongst other things) will become
increasingly important to support properly.

Cheers,
-Alex

On Tue, Dec 27, 2011 at 7:13 PM, Joshua Timberman joshua@opscode.com wrote:

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?

Omnibus has been a complete god-send for us. We're stuck on
RedHat/Oracle Linux 5.5, prior to omnibus whenever we rolled out a new
chef client it was a week of intense pain as we tried to find some
combination that worked whilst breaking workstations left right and
centre (we're a combined development/operations team - we use
chef-client on our workstations and CI, then chef-solo all the way
through to production).

In the two days I worked between Christmas and New Year I updated
everything to 0.10.8-2 and then for good measure rolled out a new chef
server using the omnibus packages - compared to our last rollout of
chef server (roughly a year ago - we were on 0.10.0) it was remarkably
painless. We've got the omnibus build process off-pat inside mock now
so I'm hoping to push it onto our Jenkins server some time in the near
future.

We'd previously tried umpteen approaches to getting a good install:

  • rvm
  • third party repos
  • build it everywhere
  • probably some more I've forgotten!

We're principally a Java shop so for the most part we're not worried
about any ruby on a box (other than for Chef) - for sysadmin stuff I
tend to push additional gems into the omnibus ruby, but it's a klunky
approach, if we were actually deploying something which was ruby I'd
want a properly packaged (modern) ruby which I could use, but still
separate from Chef.

--
Alex Kiernan

On Sat, Dec 31, 2011 at 4:02 AM, Brad Knowles bknowles@ihiji.com wrote:

On Dec 30, 2011, at 8:40 PM, Alex Howells wrote:

Whilst I appreciate you will never cater to all needs, and there is a
core of 'power user' out there who will always do their own thing, the
recommended route for deploying chef-client (which seems to be heading
in an Omnibus direction) needs to cater for the masses, and that
does mean things like SELinux (amongst other things) will become
increasingly important to support properly.

I'm not convinced that SELinux is something that the "masses" deal with today, or that it is something they will be dealing with in the near future.

IMO, Chef has a long ways to go with regards to better supporting other OS platforms, even just other versions of Linux that are commonly used in the business community (e.g., RHEL/CentOS). Ideally, we would have both better support for other platforms AND support for SELinux, but in reality we have to face the facts that there will always be limits to the available resources.

Of course, the core code supports multiple platforms fine, but one of the biggest advantages that you're getting with Chef is the community cookbooks, and that's also their Achilles Heel with regards to support for platforms other than Ubuntu. That said, this kind of thing is entirely expected when you're talking about such a young product from such a young company, especially one that has such strong ties to the open source community. Given time, this problem would tend to largely resolve itself as the company grows, the customer list grows, and the community grows.

We've mostly not found it too bad - maybe the cookbooks we're using
are pretty mainstream. The biggest pain we've had recently is the
changes in 0.10.4 (I think) which separated out all the RedHat clones

  • we've a mix of RedHat and Oracle Enterprise Linux and having to pick
    through cookbooks to find the multiple if/case statements which check
    for redhat/fedora/scientific/centos and add in
    "enterpriseenterpriselinux" is pretty dull; some refactoring to have
    ohai report some kind of platform "flavour" would be helpful.

--
Alex Kiernan