On Mon, Jul 2, 2012 at 11:26 PM, Mike Adolphs firstname.lastname@example.org wrote:
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
Mostly it’s all just personal preference here, so by all means use what is
working well for you.
Sent from my iPhone.
Am 02.07.2012 um 20:27 schrieb Sean Escriva email@example.com:
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
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 firstname.lastname@example.org wrote:
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
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
- 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
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?