[chef] Re: Re: Re: Re: Re: Ruby version trouble with rbenv, apache2 and passenger

[Sean Escriva < >]

On Tue, Jul 3, 2012 at 9:31 AM, Wes Morgan <
 
 " target="_blank">
 > 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: https://github.com/heavywater/pennyworth

not that I'm biased or anything ;)

 

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

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: https://github.com/heavywater/chef-chef_gem

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 < " target="_blank"> > 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. " target="_blank">
Web. http://fooforge.com/
Github. https://github.com/fooforge/
XING. http://www.xing.com/profile/Mike_Adolphs