RVM in Production

[Mike Bailey]

It occurred to me that RVM *could* result in ops guys feeling like the waiter in LA Story.

http://youtu.be/z-CrML0BzOA

"I'll have a half double decaffeinated half caf with a twist of lemon"

While RVM is great for developer workstations, to me it doesn't seem right for production environments. A slightly longer explanation of my reasoning is here: http://mike.bailey.net.au/2011/07/rvm-in-production/

What are your experiences?

- Mike

e. mi...@bailey.net.au

w. mike.bailey.net.au

[Ben Hoskings]

I agree, I think RVM is fundamentally not suited to production. That is, I think the things that make it a useful tool are exactly the kinds of things you don't want in production.

I build from source. `babushka benhoskings:ruby19.src` :)

—Ben

On 28/07/2011, at 11:43 AM, Mike Bailey wrote:

> It occurred to me that RVM *could* result in ops guys feeling like the
> waiter in LA Story.
>
> http://youtu.be/z-CrML0BzOA
>
> "I'll have a half double decaffeinated half caf with a twist of lemon"
>
> While RVM is great for developer workstations, to me it doesn't seem right
> for production environments. A slightly longer explanation of my reasoning
> is here: http://mike.bailey.net.au/2011/07/rvm-in-production/
>
> What are your experiences?
>

> *- Mike*
> *
> *
>
> e. mi...@bailey.net.au
>
> w. mike.bailey.net.au
>
> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
>

[Pat Allan]

I wouldn't develop without RVM these days - makes it easy to have legacy apps on 1.8.7 and newer ones on 1.9.2 - and ditto for gem development as well.

But I certainly wouldn't want that complexity in a production environment - and have never seen it pushed as an ideal production tool. Mike: is anyone recommending RVM for production?

--
Pat

On 28/07/2011, at 11:43 AM, Mike Bailey wrote:

[Andrew Grimm]

Wayne E Seguin, the creator of RVM, said on SO that it was actually
designed for production
http://stackoverflow.com/questions/5864001/is-rvm-production-ready/6282260#6282260

I humbly disagreed at
http://stackoverflow.com/questions/5864001/is-rvm-production-ready/6286677#6286677

Still, it's more production-ready than bumblebee!

Andrew

[Michael Pearson]

As I said on your blog:

No, RVM isn't great for production.

And while Wayne hasn’t actually come out and said it, he runs RVM as a tool for developers only: frequent updates, shit breaks every so often, moving target, recommend that you always use the latest version, etc etc.

We had RVM on our Ubuntu images for a while, and having “. /usr/local/rvm/scripts/rvm && rvm use ruby-1.9.2 && …” before every command was a pain, as was managing .rvmrc files “what do you mean the deploy hung? Oh, it’s waiting for somebody to type Y to trust the rvmrc”. RVM breaks, and it's expected that you, as a developer, can easily recover from that breakage. This isn't true if it's part of an automated process for building production/test/uat/staging images.

If we kept RVM, I was going to create a .deb of the RVM core followed by .debs of each RVM ruby install.

Since moving to a CentOS image with a locked Ruby-1.9.2 install things have been much easier. It’s always ruby 1.9.2, it’s always the one gemset, and bundler does the heavy lifting of making sure gems match their projects. We've since had to downgrade to 1.8.7 due to an issue in xmpp4r, but that's no biggie - we just made a new image.

My recommendation: build images/machines for each version of ruby you need. If this becomes a problem, it’s a sign that you’re using too many different versions of ruby, not that you should be using RVM outside of your local dev environment.

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--
Michael Pearson
The Bon Scotts; http://www.thebonscotts.com

[Michael Gall]

For what it's worth: I'm a bit of a newbie when it comes to setting up Rails servers and RVM really lead me up the garden path. Really regretted my time with it on a production machine.

I think a lot of the problem with it is the way it interacts (or doesn't interact) with permissions.

--
Checkout my new website: http://myachinghead.net
http://wakeless.net

[Dmytrii Nagirniak]

But I certainly wouldn't want that complexity in a production environment - and have never seen it pushed as an ideal production tool. Mike: is anyone recommending RVM for production?

Just FYI

https://rvm.beginrescueend.com/rvm/myths/

Myth #4: RVM is only for development

One of the most common claims is that rvm is only for use in development. In fact, rvm was originally built for a server setting and is perfect for such use. Not only does it include tools that can be easily automated to make setting up rubies / gems efficient, it also means you can have consistent environments both in development and production.

[Pat Allan]

Hah, okay... well, anyone beside the author of RVM, then?

--
Pat

[Julio Cesar Ody]

I think you think so because, as you put it, you're a newcomer to RVM.
There's a lot of ifs which may or may not apply to the server you're
running your applications on.

I know more developers who write Ruby based on the install they have
locally on their machines than developers who know the difference. Are
you running apps on your server that rely on language features that
match the ones you have on your development machines? If yes, then you
just don't need it. Granted, it's unlikely you'll run a bunch of Ruby
apps, each using a different version of Ruby, on the same server. But
the answer to your question depends on whether that's the case or not.

I use RVM on a VM I run my website and a couple of other things. It's
all Ruby 1.9. I don't really need it. It has never gotten in the way
anyway. Just rather have my rubies and gems sandboxes away from each
other.

P.S.: it's probably not flawless, but reasons not to use RVM in
production more often than not come down to "I feel it's wrong". The
rest seems to circle around not knowing the tool too well.

[Michael Pearson]

*headdesk*

I really should have kept IRC / twitter logs of my arguments with him.

Let me count the ways:

• he recommends that you always use the absolute latest version, locking to a particular 'stable' version is discouraged
• one time, he switched to Rubygems 1.6.2 because "somebody on IRC said it worked best", which broke Ruby 1.9.2 installs (or 1.8.7, I forget)
• default gemsets for JRuby broke JRuby 1.4 OpenSSL (which we were locked to for some time, our fault, but unavoidable)
• he changed the way that the system-wide install works with little to no advance notice, meaning our puppet image creation simply broke one day
• .rvmrc causes prompts by default. If you check .rvmrc into your repo, and then cd into that directory, your automated process will hang. Oh, and it won't create a gemset automatically if one is specified. I ended up putting "rm -f .rvmrc" into our deployment script.
• You can't override some .rvmrc stuff on a system-wide basis
• He discourages people 'packaging' RVM installs to work around these issues

RVM is great for development, but good luck using it in any kind of automated production environment.

[Andrew Grimm]

The 32 people who upvoted him on SO?

Andrew

[Dmytrii Nagirniak]

Hah, okay... well, anyone beside the author of RVM, then?

Yeah. I actually use it on my very little Linode server.

Would be interested to know what are the exact problems people  have with it as I haven't encountered any.

It is probably not worth running RVM if you do any kind of "cloud" thing (1 app per "server").

But for a single server with number of different apps that need different ruby version it's a good choice.

[Michael Pearson]

On Thu, Jul 28, 2011 at 11:56 AM, Julio Cesar Ody <juli...@gmail.com> wrote:

P.S.: it's probably not flawless, but reasons not to use RVM in
production more often than not come down to "I feel it's wrong". The
rest seems to circle around not knowing the tool too well.

We originally used RVM in prod to get around the Ruby VS Debian farnarkle. See previous email as to why this didn't work out well.

[Paul Annesley]

I agree that RVM is a godsend for development, and a pain in production.

We configure production environments using binary packages of Ruby where possible, or manually compile if the packages are considered too old.

Perhaps RVM would shine in a production environment hosting many different Ruby apps. Our production environments are dedicated to single apps.

- Paul

[Julio Cesar Ody]

Yeah, I read it.

http://serverfault.com/questions/227510/is-it-possible-to-skip-rvmrc-confirmation

[Dominik Grabiec]

I was using RVM in production on a Linode for a project a few months ago and it worked relatively well. Granted we really used it to install REE and get the environment set up and no more but it worked well enough for that. Of course we didn't use .rvmrc files or anything like that.

[Michael Pearson]

The .rvmrc thing was the easiest to work around, and if we'd really needed them, I would have either hacked/forked RVM. I'm the only developer at my work that thinks that .rvmrc checked into a repo is a bad idea :) (gemsets? that's what bundler is for! and we're all using ruby-1.9.2 anyway!)

It was the constant changes to the install process / defaults that killed it for me.

On Thu, Jul 28, 2011 at 12:01 PM, Julio Cesar Ody <juli...@gmail.com> wrote:

Yeah, I read it.

http://serverfault.com/questions/227510/is-it-possible-to-skip-rvmrc-confirmation

[Pat Allan]

I don't like the idea of checked-in .rvmrc files at all - granted, I don't work with any large teams though :)

--
Pat

[Julio Cesar Ody]

@ Michael: agreed, that's what Bundler is for. Again, should you
always run your apps on the same version of Ruby, it is a waste of
time.

@ Pat: me neither. That usually fixes a lot of problems all around.

[Dmytrii Nagirniak]

On 28 July 2011 12:25, Julio Cesar Ody <juli...@gmail.com> wrote:

@ Michael: agreed, that's what Bundler is for. Again, should you
always run your apps on the same version of Ruby, it is a waste of
time.

That's not why RVM exists. If everything you run is on one ruby version then there's no point of using RVM at all.

In this case RVM is a tool that solves no problem.

But if you do need multiple versions of Ruby - RVM is the right tool for the job.

At least that's my view on it.

[Mike Bailey]

On Thu, Jul 28, 2011 at 11:48 AM, Pat Allan <p...@freelancing-gods.com> wrote:

But I certainly wouldn't want that complexity in a production environment - and have never seen it pushed as an ideal production tool. Mike: is anyone recommending RVM for production?

The third heading on the homepage is 'Production'. https://rvm.beginrescueend.com/

- Mike

[Chris Berkhout]

I automated my VPS installation of RVM and Ruby with Babushka:
https://github.com/chrisberkhout/babushka-deps/blob/master/system/rvm_system.rb
https://github.com/chrisberkhout/babushka-deps/blob/master/system/rvm_system_ruby19.rb

But it was a pain. When this ends up breaking I'll probably just
switch to a simple binary install (or source if necessary).

For the case that you have a few small, for-fun apps running on the
same server, it's probably as easy to upgrade them to work with one
recent ruby as it is to get multiple rubies working.

And I use bundler instead of gemsets.

Cheers,
Chris

[Julio Cesar Ody]

Which is what I said on the first email I sent to the thread. Michael
was talking specifically about sandboxing gems.

On Thursday, July 28, 2011, Dmytrii Nagirniak <dna...@gmail.com> wrote:
>
> On 28 July 2011 12:25, Julio Cesar Ody <juli...@gmail.com> wrote:
>
>
> @ Michael: agreed, that's what Bundler is for. Again, should you
> always run your apps on the same version of Ruby, it is a waste of
> time.
>

> That's not why RVM exists. If everything you run is on one ruby version then there's no point of using RVM at all.In this case RVM is a tool that solves no problem.

[Simon Russell]

I work with Michael Pearson; I'm one of the people who torments him by
insisting on checking in .rvmrc files. I'm probably also one of the
people who doesn't have a problem with RVM in production, but I
haven't tried using some of the more recent releases. Certainly the
random changes don't help. It seems that if Wayne stopped insisting
people always use the latest version, it wouldn't be such a problem to
automate.

As for .rvmrc, I haven't yet heard a good reason why checking it in is
bad, and I can think of a few reasons it's convenient. I can be
convinced though; and I haven't done a lot of searching to find
opinions conflicting with mine :)

Simon.

[Ben Hoskings]

Part of it might centre around not knowing the tool very well, but then that's the whole point. A production setup should be as simple as it can possibly be (and no simpler). In production, RVM is accidental complexity.

I don't think it's a matter of "I feel it's wrong". It's that I don't want my production ruby runtime to rely on a large set of bash scripts that are prohibitively hard to properly understand or debug quickly.

As soon as you include RVM, you have a bunch of environment-related complexity that wasn't there before, and unless you're using multiple rubies on one server, it's complexity for no gain.

—Ben

[Ivan Vanderbyl]

I've not had any problems using RVM in production - we automate all our setup with Chef (I know, it's painful), which actually introduced the requirement for RVM as chef-client plays badly on 1.9, so our system ruby is 1.8.7 and all our apps run on 1.9.2.

All deployment is with Capistrano, and gemset switching with .rvmrc containing something like this:
rvm use 1.9.2@app_name --create
Takes care of any issues.

I think if we weren't using Chef we probably wouldn't need RVM as we don't run any apps on 1.8.7. But honestly RVM is not a problem once you know what it's doing behind the scenes and have it setup correctly.

I hear what Ben is saying about it being unnecessary complexity, and in most cases it is, but there is times when you need it. In the near future I plan to reconfigure our master image with something like Babushka and/or Dollhouse and remove RVM and Chef completely.

But for now it works, and has done for months.

– Ivan

[Ben Hoskings]

Ahh, reading Ivan's message, it's obvious now - to automatically select a ruby per project.

Are there other common uses?

—Ben

[Ben Hoskings]

I'm curious about the other side of this coin - what do you use your .rvmrcs for?

I've never found a use for .rvmrc (or gemsets), given that I pretty much bundle everything.

—Ben

On 28/07/2011, at 1:33 PM, Simon Russell wrote:

[Ryan Bigg]

RVM Gemsets and bundles solve the same issues as far as I am concerned. They are primarily used for selecting the dependencies for your application.

[Dmytrii Nagirniak]

Ahh, reading Ivan's message, it's obvious now - to automatically select a ruby per project.
Are there other common uses?

I think that's the primary one.

Ben, in terms of complexity, maybe I am missing something, but installing RVM took me the least amount of time.

http://blog.approache.com/2011/05/setting-up-ubuntu-1104-server-for-rails.html

And later installing Ruby was a breath. I don't really feel like it adds complexity.

[Michael Pearson]

Do that twice for your two production instances, once for your showcase environment, once for your test and ci environments.

Realise that you need to change something fundamental in your production instance ("oh hey, let's add varnish") that you'll need to replicate down the chain - move to puppet or chef to automate the process of configuring your servers. Struggle for a while to get RVM source compiling working in a package-centric models of these systems. Have it work, declare success, have it break a few weeks later because the RVM website is down or a new rubygems version broke everything.

I think we're confusing 'production' here - for some people it means n servers in multiple datacenters with munin, newrelic, nagios, an on-call roster, varying levels of dev/operator experience, etc (my job). For some it means a single linode machine that I git push to (my band's website). Both technically 'production', but wildly different environments and requirements.

[Ben Hoskings]

I don't mean setup difficulty - I agree RVM is really easy to set up.

I mean, if you have path issues on the production box, or something else breaking the ruby runtime, it's an order of magnitude easier to debug if RVM isn't involved, because there's no shell fiddling going on.

[Dmytrii Nagirniak]

Michael, Ben,

I see what you mean now.

In case of "toy" production env (which most of us has) - I guess it doesn't matter that much.

For the "real" large environment involving a lot of setup, maintenance and many people - it's a difference.

But in the latter scenario it would probably be a single app for the company with one Ruby version. So RVM is just a wrong tool anyway.

But what other options do we have to run 2 ruby versions?

[Michael Pearson]

On Thu, Jul 28, 2011 at 2:15 PM, Dmytrii Nagirniak <dna...@gmail.com> wrote:

But what other options do we have to run 2 ruby versions?

 

In this case it's self-solving: for a small environment where you can easily log in and manage it, and automation would be overkill, just use RVM.

For a large environment, you can afford another server / VM with a different default interpreter. It'll certainly be cheaper than the labour cost!

So yeah. My previous comments re "No RVM in production" were specific for larger environments.

[Pat Allan]

You could install both, make sure one has a suffix set (so ruby becomes ruby19, irb becomes irb19, etc).

--
Pat

[Ben Hoskings]

My answer is kind of "don't run 2 versions; everything should be on 1.9.2 anyway." :)

I realise that's idealised, but I do think it's OK for there to be a cost to running legacy stuff.

But that's a different discussion altogether. As for an actual answer, I'd just use a separate server. If they're big apps they should have their own servers anyway, and if they're small, a little VPS is cheap (less than an hour's work per month; i.e. it would cost more to configure multiple rubies).

—Ben

On 28/07/2011, at 2:15 PM, Dmytrii Nagirniak wrote:

[Dmytrii Nagirniak]

You could install both, make sure one has a suffix set (so ruby becomes ruby19, irb becomes irb19, etc).

Didn't know about that.
Won't it break stuff because we'd have to use explicitly 'ruby19' instead just 'ruby'?

 

[Pat Allan]

It's a compile-time flag, so I think that Ruby will be built with the expectation of using the suffix. You will need to tweak your deployment commands to use the appropriate ruby, yes.

I've never done this on production, mind you - just on my previous dev machine before I started with RVM.

--
Pat

[Dave Bolton]

And then, you could create some nifty shell scripts that manage your
per-instance environment settings, and then ... oh.

For the record, I think Ben nailed it before -- big environments
should be an app per server, or at least a Ruby per server if more
than one app is on there, while smaller apps could either be a VPS
each, or put the effort into RVM. Here at Westfield we're one app or
Ruby per server. Like Michael said earlier, when you've got a
multitude of environments it can get really hairy (we were stuck on
ancient versions of Ruby for a while because of this), so the less
moving parts the better.

Cheers,
Dave

[Andrew Newman]

Hello,

I'm someone who uses RVM in production. I'll respond to the bits in
the thread that struck me:
* I don't know about now following the Unix way of things - we ended
up using a system wide install for RVM (set :rvm_type, :system
) so it's all in /usr/local. Is that not Unixy enough?
* The "waiting to hit y" thing is a bit of a furphy. You can automate
it in your capistrano deploy with something like: run "rvm rvmrc trust
#{release_path}"
* Also, I care deeply that production and development are as much the
same as possible to avoid the "it works on my machine" problem.

RVM certainly made it a bit harder to deploy but not very much. But I
think it's worth it because it locks down the separation and
deployment of gems and Ruby version (if nothing else) and like I said
similar production to development.

As for the bugs in RVM well this is pretty easy too because if you do
things in development/staging/continuous integration first you know
the bugs and rollback (or wait for a fix or whatever). You hit these
things very early.

[Chris Berkhout]

Hey Ben,

If you do 1.9.2 from source and have only one ruby, how does that fit
with babushka needing a ruby to bootstrap itself?

Cheers,
Chris

[Ben Hoskings]

There's also a system ruby at /usr/bin/ruby, whatever's installed by the package manager (usually 1.8.7). That one bootstraps babushka.

I build 1.9 to /usr/local/bin/ruby, and babushka installs dot-files that put /usr/local/bin before /usr/bin in the path, so ruby1.9 always shadows the system ruby.

—Ben