Ruby version trouble with rbenv, apache2 and passenger

Chef Infra (archive)
1

Hi,

I’ve got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode’s APT repository and therefore runs
with ruby 1.8. The cookbooks I’m using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don’t like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there’s no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

–
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. https://github.com/fooforge/
XING. http://www.xing.com/profile/Mike_Adolphs

2

Hey Mike,

If you use the omnibus chef full installers for 10.12 you'll get
ruby 1.9.2p290, for chef use only of course. gem_package and chef_gem are
also working properly in the 10.12 release so gem_package will install gems
to the system ruby context and chef_gem will install a gem into the chef
ruby context.

I'd encourage you to use the omnibus installer if at all possible and
provide the app ruby some other way, maybe building a package yourself
using fpm or bunchr.

If you're unable to for any reason then perhaps the chef_gem cookbook we
wrote will help: GitHub - heavywater/chef-chef_gem: Provides chef_gem resource to chef <= 0.10.8

Also, we avoid using rbenv/rvm for prodction deploys, they're handy tools
for dev workstations, but there are better ways of getting system ruby in
place for production use.

On Sat, Jun 30, 2012 at 5:11 PM, Mike Adolphs mike@fooforge.com wrote:

Hi,

I've got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode's APT repository and therefore runs
with ruby 1.8. The cookbooks I'm using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don't like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there's no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

--
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. fooforge (Mike Stojan) · GitHub
XING. http://www.xing.com/profile/Mike_Adolphs

3

Hi Sean,

thanks for the insights! I'll definitely have a look regarding Omnibus. We're already using it for Redhat/Centos based servers, but apparently using it for Debian as well didn't come to my mind so far..

Regarding the ruby provisioning I have to say we're now building various packages for about 3 1/2 years, but I think it's time to get a bit more dynamic in this regard. rbenv is less inversive then rvm (I'm using it on my notebook) and more lightweight. Can't really think of a reason for not using it on my servers despite the need of setting environment variables or sourcing /etc/profile when opening up a noninteractive shell.

We have a cookbook and a role for each application. This means we're able to set a global ruby within a generic application_server role and switch to other versions on demand within the specific cookbooks.
I kinda like that although node[:languages][:ruby] is unable to detect rbenv/rvm right now. Don't have a problem with that though. It's nice to have a system ruby for seperating ops from application stuff.

Are there any major reasons for not using rbenv in production despite the ones I've mentioned?

Thanks,
Mike

Sent from my iPhone.

Am 02.07.2012 um 20:27 schrieb Sean Escriva sean.escriva@gmail.com:

Hey Mike,

If you use the omnibus chef full installers for 10.12 you'll get ruby 1.9.2p290, for chef use only of course. gem_package and chef_gem are also working properly in the 10.12 release so gem_package will install gems to the system ruby context and chef_gem will install a gem into the chef ruby context.

I'd encourage you to use the omnibus installer if at all possible and provide the app ruby some other way, maybe building a package yourself using fpm or bunchr.

If you're unable to for any reason then perhaps the chef_gem cookbook we wrote will help: GitHub - heavywater/chef-chef_gem: Provides chef_gem resource to chef <= 0.10.8

Also, we avoid using rbenv/rvm for prodction deploys, they're handy tools for dev workstations, but there are better ways of getting system ruby in place for production use.

On Sat, Jun 30, 2012 at 5:11 PM, Mike Adolphs mike@fooforge.com wrote:
Hi,

I've got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode's APT repository and therefore runs
with ruby 1.8. The cookbooks I'm using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don't like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there's no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

--
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. fooforge (Mike Stojan) · GitHub
XING. http://www.xing.com/profile/Mike_Adolphs

4

On Mon, Jul 2, 2012 at 11:26 PM, Mike Adolphs mike@fooforge.com wrote:

Hi Sean,

thanks for the insights! I'll definitely have a look regarding Omnibus.
We're already using it for Redhat/Centos based servers, but apparently
using it for Debian as well didn't come to my mind so far..

Regarding the ruby provisioning I have to say we're now building various
packages for about 3 1/2 years, but I think it's time to get a bit more
dynamic in this regard. rbenv is less inversive then rvm (I'm using it on
my notebook) and more lightweight. Can't really think of a reason for not
using it on my servers despite the need of setting environment variables or
sourcing /etc/profile when opening up a noninteractive shell.

We have a cookbook and a role for each application. This means we're able
to set a global ruby within a generic application_server role and switch to
other versions on demand within the specific cookbooks.
I kinda like that although node[:languages][:ruby] is unable to detect
rbenv/rvm right now. Don't have a problem with that though. It's nice to
have a system ruby for seperating ops from application stuff.

Are there any major reasons for not using rbenv in production despite the
ones I've mentioned?

Rbenv is certainly more lightweight than rvm. It still feels like a
fragile unneeded step to me and I like to remove the need to reason about
'which ruby' on a production system. I prefer to manage as few local ruby
ecosystems as possible.

A few, rhetorical, questions I would ask: Is there really a need for
multiple rubies for your single production app, if so why? Is there a
ruby-build step required for each new server as it's spun up? Will every
process always have access to the shell environment it needs to find the
right ruby? What complexity is added by using rbenv, is it really a
necessary cost?

Mostly it's all just personal preference here, so by all means use what is
working well for you.

Thanks,
Mike

Sent from my iPhone.

Am 02.07.2012 um 20:27 schrieb Sean Escriva sean.escriva@gmail.com:

Hey Mike,

If you use the omnibus chef full installers for 10.12 you'll get
ruby 1.9.2p290, for chef use only of course. gem_package and chef_gem are
also working properly in the 10.12 release so gem_package will install gems
to the system ruby context and chef_gem will install a gem into the chef
ruby context.

I'd encourage you to use the omnibus installer if at all possible and
provide the app ruby some other way, maybe building a package yourself
using fpm or bunchr.

If you're unable to for any reason then perhaps the chef_gem cookbook we
wrote will help: GitHub - heavywater/chef-chef_gem: Provides chef_gem resource to chef <= 0.10.8

Also, we avoid using rbenv/rvm for prodction deploys, they're handy tools
for dev workstations, but there are better ways of getting system ruby in
place for production use.

On Sat, Jun 30, 2012 at 5:11 PM, Mike Adolphs mike@fooforge.com wrote:

Hi,

I've got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode's APT repository and therefore runs
with ruby 1.8. The cookbooks I'm using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don't like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there's no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

--
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. fooforge (Mike Stojan) · GitHub
XING. http://www.xing.com/profile/Mike_Adolphs

5

Has anyone documented and/or made a reusable cookbook for the build-a-deb/rpm-and-distribute approach to installing the desired Ruby version? The theory sounds nice, but currently using rbenv is a path of less resistance due to the nice cookbook which already exists and the extensive documentation. Learning how to package both Ruby 1.9.3-p194 and JRuby 1.6.7.2 (both of which I need on different servers) seems like a lot of yak-shaving for the benefits it would give me.

Sorry if that's been posted and I missed it.

Wes

On Jul 3, 2012, at 10:26 AM, Sean Escriva wrote:

On Mon, Jul 2, 2012 at 11:26 PM, Mike Adolphs mike@fooforge.com wrote:
Hi Sean,

thanks for the insights! I'll definitely have a look regarding Omnibus. We're already using it for Redhat/Centos based servers, but apparently using it for Debian as well didn't come to my mind so far..

Regarding the ruby provisioning I have to say we're now building various packages for about 3 1/2 years, but I think it's time to get a bit more dynamic in this regard. rbenv is less inversive then rvm (I'm using it on my notebook) and more lightweight. Can't really think of a reason for not using it on my servers despite the need of setting environment variables or sourcing /etc/profile when opening up a noninteractive shell.

We have a cookbook and a role for each application. This means we're able to set a global ruby within a generic application_server role and switch to other versions on demand within the specific cookbooks.
I kinda like that although node[:languages][:ruby] is unable to detect rbenv/rvm right now. Don't have a problem with that though. It's nice to have a system ruby for seperating ops from application stuff.

Are there any major reasons for not using rbenv in production despite the ones I've mentioned?

Rbenv is certainly more lightweight than rvm. It still feels like a fragile unneeded step to me and I like to remove the need to reason about 'which ruby' on a production system. I prefer to manage as few local ruby ecosystems as possible.

A few, rhetorical, questions I would ask: Is there really a need for multiple rubies for your single production app, if so why? Is there a ruby-build step required for each new server as it's spun up? Will every process always have access to the shell environment it needs to find the right ruby? What complexity is added by using rbenv, is it really a necessary cost?

Mostly it's all just personal preference here, so by all means use what is working well for you.

Thanks,
Mike

Sent from my iPhone.

Am 02.07.2012 um 20:27 schrieb Sean Escriva sean.escriva@gmail.com:

Hey Mike,

If you use the omnibus chef full installers for 10.12 you'll get ruby 1.9.2p290, for chef use only of course. gem_package and chef_gem are also working properly in the 10.12 release so gem_package will install gems to the system ruby context and chef_gem will install a gem into the chef ruby context.

I'd encourage you to use the omnibus installer if at all possible and provide the app ruby some other way, maybe building a package yourself using fpm or bunchr.

If you're unable to for any reason then perhaps the chef_gem cookbook we wrote will help: GitHub - heavywater/chef-chef_gem: Provides chef_gem resource to chef <= 0.10.8

Also, we avoid using rbenv/rvm for prodction deploys, they're handy tools for dev workstations, but there are better ways of getting system ruby in place for production use.

On Sat, Jun 30, 2012 at 5:11 PM, Mike Adolphs mike@fooforge.com wrote:
Hi,

I've got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode's APT repository and therefore runs
with ruby 1.8. The cookbooks I'm using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don't like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there's no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

--
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. fooforge (Mike Stojan) · GitHub
XING. http://www.xing.com/profile/Mike_Adolphs

6

Is anybody using fpm to package chef - omnibus?

on the question , sean, you might want to host multiple ruby versions. In
case your business demands you to do so. With so much automation around
virtualized environments, and apps that do reads on raw source code.. you
might end up in requiring multiple versions of the same thing. Look at
python? Even look at rubygems? Why bundler came? Its same but on a package
level not language, packages changes faster. and you'll be using those
packages

On Tue, Jul 3, 2012 at 10:01 PM, Wes Morgan cap10morgan@gmail.com wrote:

Has anyone documented and/or made a reusable cookbook for the
build-a-deb/rpm-and-distribute approach to installing the desired Ruby
version? The theory sounds nice, but currently using rbenv is a path of
less resistance due to the nice cookbook which already exists and the
extensive documentation. Learning how to package both Ruby 1.9.3-p194 and
JRuby 1.6.7.2 (both of which I need on different servers) seems like a lot
of yak-shaving for the benefits it would give me.

Sorry if that's been posted and I missed it.

Wes

On Jul 3, 2012, at 10:26 AM, Sean Escriva wrote:

On Mon, Jul 2, 2012 at 11:26 PM, Mike Adolphs mike@fooforge.com wrote:

Hi Sean,

thanks for the insights! I'll definitely have a look regarding Omnibus.
We're already using it for Redhat/Centos based servers, but apparently
using it for Debian as well didn't come to my mind so far..

Regarding the ruby provisioning I have to say we're now building various
packages for about 3 1/2 years, but I think it's time to get a bit more
dynamic in this regard. rbenv is less inversive then rvm (I'm using it on
my notebook) and more lightweight. Can't really think of a reason for not
using it on my servers despite the need of setting environment variables or
sourcing /etc/profile when opening up a noninteractive shell.

We have a cookbook and a role for each application. This means we're able
to set a global ruby within a generic application_server role and switch to
other versions on demand within the specific cookbooks.
I kinda like that although node[:languages][:ruby] is unable to detect
rbenv/rvm right now. Don't have a problem with that though. It's nice to
have a system ruby for seperating ops from application stuff.

Are there any major reasons for not using rbenv in production despite the
ones I've mentioned?

Rbenv is certainly more lightweight than rvm. It still feels like a
fragile unneeded step to me and I like to remove the need to reason about
'which ruby' on a production system. I prefer to manage as few local ruby
ecosystems as possible.

A few, rhetorical, questions I would ask: Is there really a need for
multiple rubies for your single production app, if so why? Is there a
ruby-build step required for each new server as it's spun up? Will every
process always have access to the shell environment it needs to find the
right ruby? What complexity is added by using rbenv, is it really a
necessary cost?

Mostly it's all just personal preference here, so by all means use what is
working well for you.

Thanks,
Mike

Sent from my iPhone.

Am 02.07.2012 um 20:27 schrieb Sean Escriva sean.escriva@gmail.com:

Hey Mike,

If you use the omnibus chef full installers for 10.12 you'll get
ruby 1.9.2p290, for chef use only of course. gem_package and chef_gem are
also working properly in the 10.12 release so gem_package will install gems
to the system ruby context and chef_gem will install a gem into the chef
ruby context.

I'd encourage you to use the omnibus installer if at all possible and
provide the app ruby some other way, maybe building a package yourself
using fpm or bunchr.

If you're unable to for any reason then perhaps the chef_gem cookbook we
wrote will help: GitHub - heavywater/chef-chef_gem: Provides chef_gem resource to chef <= 0.10.8

Also, we avoid using rbenv/rvm for prodction deploys, they're handy tools
for dev workstations, but there are better ways of getting system ruby in
place for production use.

On Sat, Jun 30, 2012 at 5:11 PM, Mike Adolphs mike@fooforge.com wrote:

Hi,

I've got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode's APT repository and therefore runs
with ruby 1.8. The cookbooks I'm using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don't like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there's no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

--
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. fooforge (Mike Stojan) · GitHub
XING. http://www.xing.com/profile/Mike_Adolphs

7

On Tue, Jul 3, 2012 at 9:31 AM, Wes Morgan cap10morgan@gmail.com wrote:

Has anyone documented and/or made a reusable cookbook for the
build-a-deb/rpm-and-distribute approach to installing the desired Ruby
version? The theory sounds nice, but currently using rbenv is a path of
less resistance due to the nice cookbook which already exists and the
extensive documentation. Learning how to package both Ruby 1.9.3-p194 and
JRuby 1.6.7.2 (both of which I need on different servers) seems like a lot
of yak-shaving for the benefits it would give me.

Um, yea: GitHub - heavywater/pennyworth: pennyworth is a continuous packaging system built around Opscode's Chef, Jenkins and the fpm packaging tool

not that I'm biased or anything :wink:

Sorry if that's been posted and I missed it.

Wes

On Jul 3, 2012, at 10:26 AM, Sean Escriva wrote:

On Mon, Jul 2, 2012 at 11:26 PM, Mike Adolphs mike@fooforge.com wrote:

Hi Sean,

thanks for the insights! I'll definitely have a look regarding Omnibus.
We're already using it for Redhat/Centos based servers, but apparently
using it for Debian as well didn't come to my mind so far..

Regarding the ruby provisioning I have to say we're now building various
packages for about 3 1/2 years, but I think it's time to get a bit more
dynamic in this regard. rbenv is less inversive then rvm (I'm using it on
my notebook) and more lightweight. Can't really think of a reason for not
using it on my servers despite the need of setting environment variables or
sourcing /etc/profile when opening up a noninteractive shell.

We have a cookbook and a role for each application. This means we're able
to set a global ruby within a generic application_server role and switch to
other versions on demand within the specific cookbooks.
I kinda like that although node[:languages][:ruby] is unable to detect
rbenv/rvm right now. Don't have a problem with that though. It's nice to
have a system ruby for seperating ops from application stuff.

Are there any major reasons for not using rbenv in production despite the
ones I've mentioned?

Rbenv is certainly more lightweight than rvm. It still feels like a
fragile unneeded step to me and I like to remove the need to reason about
'which ruby' on a production system. I prefer to manage as few local ruby
ecosystems as possible.

A few, rhetorical, questions I would ask: Is there really a need for
multiple rubies for your single production app, if so why? Is there a
ruby-build step required for each new server as it's spun up? Will every
process always have access to the shell environment it needs to find the
right ruby? What complexity is added by using rbenv, is it really a
necessary cost?

Mostly it's all just personal preference here, so by all means use what is
working well for you.

Thanks,
Mike

Sent from my iPhone.

Am 02.07.2012 um 20:27 schrieb Sean Escriva sean.escriva@gmail.com:

Hey Mike,

If you use the omnibus chef full installers for 10.12 you'll get
ruby 1.9.2p290, for chef use only of course. gem_package and chef_gem are
also working properly in the 10.12 release so gem_package will install gems
to the system ruby context and chef_gem will install a gem into the chef
ruby context.

I'd encourage you to use the omnibus installer if at all possible and
provide the app ruby some other way, maybe building a package yourself
using fpm or bunchr.

If you're unable to for any reason then perhaps the chef_gem cookbook we
wrote will help: GitHub - heavywater/chef-chef_gem: Provides chef_gem resource to chef <= 0.10.8

Also, we avoid using rbenv/rvm for prodction deploys, they're handy tools
for dev workstations, but there are better ways of getting system ruby in
place for production use.

On Sat, Jun 30, 2012 at 5:11 PM, Mike Adolphs mike@fooforge.com wrote:

Hi,

I've got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode's APT repository and therefore runs
with ruby 1.8. The cookbooks I'm using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don't like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there's no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

--
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. fooforge (Mike Stojan) · GitHub
XING. http://www.xing.com/profile/Mike_Adolphs

8

On Tuesday, July 3, 2012 at 9:37 AM, Ranjib Dey wrote:

Is anybody using fpm to package chef - omnibus?

Omnibus uses OS packages under the hood already. Look through the source of the install.sh script.

--
Dan DeLeo

9

ruby-pkg.sh · GitHub in tandem with
https://github.com/digital-science/rbenv-cookbook
gives packaged ruby versions in tandem with rbenv. Works really nicely.
-t

On Tue, Jul 3, 2012 at 5:31 PM, Wes Morgan cap10morgan@gmail.com wrote:

Has anyone documented and/or made a reusable cookbook for the
build-a-deb/rpm-and-distribute approach to installing the desired Ruby
version? The theory sounds nice, but currently using rbenv is a path of less
resistance due to the nice cookbook which already exists and the extensive
documentation. Learning how to package both Ruby 1.9.3-p194 and JRuby
1.6.7.2 (both of which I need on different servers) seems like a lot of
yak-shaving for the benefits it would give me.

Sorry if that's been posted and I missed it.

Wes

On Jul 3, 2012, at 10:26 AM, Sean Escriva wrote:

On Mon, Jul 2, 2012 at 11:26 PM, Mike Adolphs mike@fooforge.com wrote:

Hi Sean,

thanks for the insights! I'll definitely have a look regarding Omnibus.
We're already using it for Redhat/Centos based servers, but apparently using
it for Debian as well didn't come to my mind so far..

Regarding the ruby provisioning I have to say we're now building various
packages for about 3 1/2 years, but I think it's time to get a bit more
dynamic in this regard. rbenv is less inversive then rvm (I'm using it on my
notebook) and more lightweight. Can't really think of a reason for not using
it on my servers despite the need of setting environment variables or
sourcing /etc/profile when opening up a noninteractive shell.

We have a cookbook and a role for each application. This means we're able
to set a global ruby within a generic application_server role and switch to
other versions on demand within the specific cookbooks.
I kinda like that although node[:languages][:ruby] is unable to detect
rbenv/rvm right now. Don't have a problem with that though. It's nice to
have a system ruby for seperating ops from application stuff.

Are there any major reasons for not using rbenv in production despite the
ones I've mentioned?

Rbenv is certainly more lightweight than rvm. It still feels like a fragile
unneeded step to me and I like to remove the need to reason about 'which
ruby' on a production system. I prefer to manage as few local ruby
ecosystems as possible.

A few, rhetorical, questions I would ask: Is there really a need for
multiple rubies for your single production app, if so why? Is there a
ruby-build step required for each new server as it's spun up? Will every
process always have access to the shell environment it needs to find the
right ruby? What complexity is added by using rbenv, is it really a
necessary cost?

Mostly it's all just personal preference here, so by all means use what is
working well for you.

Thanks,
Mike

Sent from my iPhone.

Am 02.07.2012 um 20:27 schrieb Sean Escriva sean.escriva@gmail.com:

Hey Mike,

If you use the omnibus chef full installers for 10.12 you'll get ruby
1.9.2p290, for chef use only of course. gem_package and chef_gem are also
working properly in the 10.12 release so gem_package will install gems to
the system ruby context and chef_gem will install a gem into the chef ruby
context.

I'd encourage you to use the omnibus installer if at all possible and
provide the app ruby some other way, maybe building a package yourself using
fpm or bunchr.

If you're unable to for any reason then perhaps the chef_gem cookbook we
wrote will help: GitHub - heavywater/chef-chef_gem: Provides chef_gem resource to chef <= 0.10.8

Also, we avoid using rbenv/rvm for prodction deploys, they're handy tools
for dev workstations, but there are better ways of getting system ruby in
place for production use.

On Sat, Jun 30, 2012 at 5:11 PM, Mike Adolphs mike@fooforge.com wrote:

Hi,

I've got a bunch of Debian Squeeze application servers which need
rbenv installed together with Apache2 and passenger. The chef-client
is 10.12.0, comes from Opscode's APT repository and therefore runs
with ruby 1.8. The cookbooks I'm using are
http://fnichol.github.com/chef-rbenv/, the apache2 and
passenger_apache2 cookbooks.

Now the problem is that the passenger gem gets installed in the ruby
1.8 context instead of using the ruby installed by rbenv/ruby_build. I
could fix this with a few actions:

  • Making the gem_binary configurable and extending the execute block
    which runs passenger-install-apache2-module in the passenger_apache2
    cookbook
  • Or using the rbenv_script directive from the rbenv cookbook making
    it a dependency for the passenger_apache2 cookbook

I don't like neither of them since both lead to more cookbook
dependencies. On the other hand it seems to be impossible to set
something like use_rbenv_global_ruby_for_anything on a global scale
since there's no way to tell a non-interactive shell to source rc
files except patching chef-client itself.

Since ruby and rbenv|rvm are quite popular - how do you solve this?

Regards,
Mike

--
Mike Adolphs
Stitenstrasse 24
23554 Luebeck

  • Germany -

Mail. mike@fooforge.com
Web. http://fooforge.com/
Github. fooforge (Mike Stojan) · GitHub
XING. http://www.xing.com/profile/Mike_Adolphs