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

[Thom May < >]

https://gist.github.com/1854175 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 
<
 >
 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 
> <
 >
>  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 
>> <
 >:
>>
>> 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 
>> <
 >
>>  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. 
>>> 
 
>>> Web. http://fooforge.com/
>>> Github. https://github.com/fooforge/
>>> XING. http://www.xing.com/profile/Mike_Adolphs
>>
>>
>
>