6 ms·

As always, it bears repeating: rvm/rbenv don't belong in production. They exist to allow developers on Macbooks to sync their version of Ruby with whatever is

by alrs 13y ago

As always, it bears repeating: rvm/rbenv don't belong in production. They exist to allow developers on Macbooks to sync their version of Ruby with whatever is packaged in the Linux distro or BSD variant that runs in production. If I had a Mac I'd skip the ad-hoc Ruby environment switchers and skip straight to Vagrant.

3pt14159 13y ago
I used to agree with you. Why would you take a 20 or 30 percent performance hit when you are busy shelling out tens of thousands for hardware load balancers. Then one day a rare instruction set on our colocated server (so not something super standard like linode) was specified during the compilation step of ruby and (due to an extremely subtle co-bug between ruby and the compiler). It took us fucking weeks to find this hisenbug that was somehow causing workers to drop, but only during times of very high load. Probably lost $500k worth of customers, dev time, and company moral. Now I have a different view. Keep things as simple and as "normal" as possible. That way you can always upgrade to the next version, you don't hit weird bugs when you libraries assume that Time.now is second-accurate, instead of sub-second accurate (MRI vs Enterprise Ruby). RVM is made for production (http://stackoverflow.com/a/6282260/384700 http://stackoverflow.com/a/6282260/384700) and it saves a lot of headaches to just go with the flow. As for mac dev, I agree that it is a waste of time compared to working out of Ubuntu, but designers like photoshop and Vagrant is non-trivial for them to set up, especially for people that work on multiple projects.
- alrs 13y ago
  I'm confused. Simple and normal, to me, means "use packaged Ruby." Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs. If you need a nonstandard compile-time option you go to work on the package source, make the change, put your custom package up in your private apt/yum repo, and leave things alone until the next security update comes down the pike. Me, I consider hosting to be entirely fungible. I'd rather change vendors than mess about with custom packaging big chunks of the stack to work around weirdness. Wherever I have encountered Phusion's REE I have ripped it out, with good results.
  - kawsper 13y ago
    > Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs. I think most people that uses rbenv or RVM in production is only compiling new versions if the specified version isn't there already.
  - joevandyk 13y ago
    Building a package wouldn't fix the bug. The ruby binary in the package would contain the same problematic compile-time option.
    - alrs 13y ago
      It absolutely would. You change the compile-time option and build the package with that change.
      - joevandyk 13y ago
        Right, so the ruby binary inside the package that you just built would contain the bug caused by that particular compile-time option.
        alrs 13y ago
        I want to be sure that we're on the same page. No. 3pt14159 said that he used to use distro-packaged Ruby, but stopped because his distro used a compile-time option that didn't play well with his vendor's hardware. 3pt14159's solution was to start using rvm on production boxes. I think that is a bad idea, and that either: 1. 3pt14159 should just pull down the package source, change the compile time option, rebuild the package, and use the mildly customized package in production. 2. 3pt14159 should not waste time working around hardware weirdness, and just switch to a vendor that doesn't have these problems.
- FireBringer 13y ago
  You shouldn't necessarily be compiling ruby on your server anyways you should be using a package (rpm, deb) to install it. Especially if you are losing $500k because you decided to compile ruby on your production server.
  - bradleyland 13y ago
    One of the challenges of running a production application based on Ruby is the fact that relying on distro packages will fail miserably. Rubygems, in particular, does not work well with distro installed Ruby interpreters.
    - FireBringer 13y ago
      I was talking about creating your own packages.
      - bradleyland 13y ago
        Ah, I re-read your comment in an entirely different light now, and I agree that packaging your own deps is a great way to avoid surprises when you roll your infrastructure.
- otterley 13y ago
  Pointing to the author's declaration that "rvm was made for production" is not exactly the best evidence of such, especially in light of mine and my colleagues' endless hours trying to figure out how to fit it into a non-interactive-shell environment.
  - jeltz 13y ago
    I have had similar experiences with rvm in production environments. chruby (probably also rbenv, haven't used it) is easier to understand and trivial to set up with non-interactive shells.
  - eulerphi 13y ago
    I've had similar problems with RVM. Ultimately I used the system-wide RVM installation and this chunk of code: export PATH=$PATH:/usr/local/rvm/bin/rvm . /usr/local/rvm/scripts/rvm . $REPO/.rvmrc . $(rvm jruby-$JRUBY_VERSION do rvm env --path) cd $REPO bundle exec torquebox deploy Definitely not ideal and I spent a large amount of hours figuring out how to use it non-interactively. I'm still somewhat worried that some things might go wrong if some of the code I didn't write in this repo attempts to call binaries directly. Basically with bundle exec --deployment, all gems are stored in $CODE/.vendor which is necessary to allow users to install their own gems, with the root installation. Bundle exec has to be used, I messed around with RVM wrappers, but they don't work with the --deployment bundler use.
    - otterley 13y ago
      You're doing too much. All you need to do is: source /usr/local/rvm/environments/$BUILD You can put it in a wrapper script if you like. It will unset all conflicting environment variables first.
      - eulerphi 13y ago
        The thing is that the rvmrc has the jruby version env set. So I need to load it first. And it contains an 'rvm use' which I don't want to fail. I suppose I can slim the rvmrc down to just include the environment and then all I would need to do is source the rvmrc? Thoughts?
- regularfry 13y ago
  I use ruby-install to build precompiled MRI packages. I'd be very interested to know if that might have avoided your problem.
otterley 13y ago
In mature production environments, sometimes you do need more than one Ruby environment on a host. I've seen this case where multiple programs must be deployed on a host, one of which was built a long time ago (i.e. legacy). (This applies not only to Ruby, BTW.) Maybe rvm/rbenv is not the best solution, but some solution is needed. You can either invent one yourself, or adapt something that's already been built. We're using rvm, and while I'm not a huge fan of it and would rather switch to rbenv, I've managed to tame it so that it's not such a huge beast, using various wrappers so that non-interactive Ruby programs work start up in the correct environment.
- alrs 13y ago
  If the divide is ruby 1.8 and 1.9, Debian packages both, and they can be installed simultaneously. If it's more arcane than that, it sounds like kvm or lxc is the answer. If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. One fix would be to update the ancient software so that it can use modern Ruby. Another fix would be to re-architect the solution so that the greater system could operate across multiple OS instances. The least attractive option would be to use packaged Ruby for the modern stuff, and a hand-compiled Ruby for the legacy stuff.
  - joevandyk 13y ago
    If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. Why? Why can't you have a stable app using Ruby 1.9 that hasn't need any updates (other than security) in three years running on the same machine that also runs another newer application which uses Ruby 2.0 and Rails 4? To me, that's not "technical debt".
    - regularfry 13y ago
      Maybe "wasting asset" is a better metaphor. At some point, there'll come an OS release on which that Ruby won't even build (and this can happen sooner than you'd think - 1.8.7 needs to be patched to build on Wheezy, for instance; by the time Jessie goes stable 1.9.3 will probably have been deprecated and unsupported too). At that point, you're forced into porting to a newer Ruby just so you can keep up with security patches to the underlying OS. It might not be "technical debt" per se, but it's definitely a maintenance cost.
yxhuvud 13y ago
The problem is that the ruby versions packaged in the distros are not always as compatible as one could wish. Sometimes it is the list of default gems that is different (like how fedora packages bignum as a gem), and sometimes it is the distro packaged gems that just doesn't look like the stock versions. I've seen examples of gems split into two gems, as well as gems that has had their version dependencies altered. things like that easily makes either rubygems or bundler very unhappy. The thing about distro packaged software is that you have to trust the distro to do the right thing, and it only takes so many examples of them doing something stupid before that trust is lost.
- chrislaco 13y ago
  Sometimes it's not even gems/libs, but dist specific patches to the language itself. RHEL used to be notorious for breaking their Perl 5 dists. The first rule of Perl was to compile your own the server.
irahul 13y ago
You are entitled to your opinion, but as other commenter pointed out, rvm was created for production. > hey exist to allow developers on Macbooks to sync their version of Ruby with whatever is packaged in the Linux distro or BSD variant that runs in production. Or to allow developers who run ubuntu to develop multiple projects which need conflicting versions of the Gem and interpreters seamlessly. Also, I sometimes deploy multiple projects on same production box where the 2 might need different interpreters, and they almost always need separate gemsets. I can manage the interpreters and LOAD_PATH manually, but then I will end up creating an unholy mess which will somewhat resemble rvm. I am curious. What are your reasons for "rvm doesn't belong in production"?
- alrs 13y ago
  The best example of why the rvm model fails on the dev side is nokogiri. Yeah, sure, you can have multiple versions of Ruby and the Nokogiri gem on the same box. libxml2, borrowed from the GNOME project, is the C library that is doing all of the heavy lifting underneath. If the version of libxml2 on your dev machine is different than the version in prod, it doesn't much matter if you've got the same version of Ruby and the same version of Nokogiri. Use Vagrant. You will get a complete Linux VM for each different project that will match up perfectly with whatever the prod environment looks like.
  - irahul 13y ago
    Do you deploy with Vagrant? I think container might be the way forward, but I am not convinced, and I don't deploy Vagrant to production(containers might be the future for deployment but Vagrant in it's current state isn't). I don't use vagrant in production because I use a Ubuntu box for development and rvm/bundler, virtualenv/pip...cover my needs for maintaining different and isolated dev environments.
    - alrs 13y ago
      No, I don't deploy with Vagrant. Nor would I. Use Vagrant to spin up Linux VMs locally so that you can have a dev environment that matches production.
deleted 13y ago
[deleted]

by alrs 13y ago

3pt14159 13y ago

I used to agree with you. Why would you take a 20 or 30 percent performance hit when you are busy shelling out tens of thousands for hardware load balancers. Then one day a rare instruction set on our colocated server (so not something super standard like linode) was specified during the compilation step of ruby and (due to an extremely subtle co-bug between ruby and the compiler). It took us fucking weeks to find this hisenbug that was somehow causing workers to drop, but only during times of very high load. Probably lost $500k worth of customers, dev time, and company moral. Now I have a different view. Keep things as simple and as "normal" as possible. That way you can always upgrade to the next version, you don't hit weird bugs when you libraries assume that Time.now is second-accurate, instead of sub-second accurate (MRI vs Enterprise Ruby). RVM is made for production (http://stackoverflow.com/a/6282260/384700 http://stackoverflow.com/a/6282260/384700) and it saves a lot of headaches to just go with the flow. As for mac dev, I agree that it is a waste of time compared to working out of Ubuntu, but designers like photoshop and Vagrant is non-trivial for them to set up, especially for people that work on multiple projects.

alrs 13y ago
I'm confused. Simple and normal, to me, means "use packaged Ruby." Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs. If you need a nonstandard compile-time option you go to work on the package source, make the change, put your custom package up in your private apt/yum repo, and leave things alone until the next security update comes down the pike. Me, I consider hosting to be entirely fungible. I'd rather change vendors than mess about with custom packaging big chunks of the stack to work around weirdness. Wherever I have encountered Phusion's REE I have ripped it out, with good results.
- kawsper 13y ago
  > Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs. I think most people that uses rbenv or RVM in production is only compiling new versions if the specified version isn't there already.
- joevandyk 13y ago
  Building a package wouldn't fix the bug. The ruby binary in the package would contain the same problematic compile-time option.
  - alrs 13y ago
    It absolutely would. You change the compile-time option and build the package with that change.
    - joevandyk 13y ago
      Right, so the ruby binary inside the package that you just built would contain the bug caused by that particular compile-time option.
      - alrs 13y ago
        I want to be sure that we're on the same page. No. 3pt14159 said that he used to use distro-packaged Ruby, but stopped because his distro used a compile-time option that didn't play well with his vendor's hardware. 3pt14159's solution was to start using rvm on production boxes. I think that is a bad idea, and that either: 1. 3pt14159 should just pull down the package source, change the compile time option, rebuild the package, and use the mildly customized package in production. 2. 3pt14159 should not waste time working around hardware weirdness, and just switch to a vendor that doesn't have these problems.
FireBringer 13y ago
You shouldn't necessarily be compiling ruby on your server anyways you should be using a package (rpm, deb) to install it. Especially if you are losing $500k because you decided to compile ruby on your production server.
- bradleyland 13y ago
  One of the challenges of running a production application based on Ruby is the fact that relying on distro packages will fail miserably. Rubygems, in particular, does not work well with distro installed Ruby interpreters.
  - FireBringer 13y ago
    I was talking about creating your own packages.
    - bradleyland 13y ago
      Ah, I re-read your comment in an entirely different light now, and I agree that packaging your own deps is a great way to avoid surprises when you roll your infrastructure.
otterley 13y ago
Pointing to the author's declaration that "rvm was made for production" is not exactly the best evidence of such, especially in light of mine and my colleagues' endless hours trying to figure out how to fit it into a non-interactive-shell environment.
- jeltz 13y ago
  I have had similar experiences with rvm in production environments. chruby (probably also rbenv, haven't used it) is easier to understand and trivial to set up with non-interactive shells.
- eulerphi 13y ago
  I've had similar problems with RVM. Ultimately I used the system-wide RVM installation and this chunk of code: export PATH=$PATH:/usr/local/rvm/bin/rvm . /usr/local/rvm/scripts/rvm . $REPO/.rvmrc . $(rvm jruby-$JRUBY_VERSION do rvm env --path) cd $REPO bundle exec torquebox deploy Definitely not ideal and I spent a large amount of hours figuring out how to use it non-interactively. I'm still somewhat worried that some things might go wrong if some of the code I didn't write in this repo attempts to call binaries directly. Basically with bundle exec --deployment, all gems are stored in $CODE/.vendor which is necessary to allow users to install their own gems, with the root installation. Bundle exec has to be used, I messed around with RVM wrappers, but they don't work with the --deployment bundler use.
  - otterley 13y ago
    You're doing too much. All you need to do is: source /usr/local/rvm/environments/$BUILD You can put it in a wrapper script if you like. It will unset all conflicting environment variables first.
    - eulerphi 13y ago
      The thing is that the rvmrc has the jruby version env set. So I need to load it first. And it contains an 'rvm use' which I don't want to fail. I suppose I can slim the rvmrc down to just include the environment and then all I would need to do is source the rvmrc? Thoughts?
regularfry 13y ago
I use ruby-install to build precompiled MRI packages. I'd be very interested to know if that might have avoided your problem.

otterley 13y ago

In mature production environments, sometimes you do need more than one Ruby environment on a host. I've seen this case where multiple programs must be deployed on a host, one of which was built a long time ago (i.e. legacy). (This applies not only to Ruby, BTW.) Maybe rvm/rbenv is not the best solution, but some solution is needed. You can either invent one yourself, or adapt something that's already been built. We're using rvm, and while I'm not a huge fan of it and would rather switch to rbenv, I've managed to tame it so that it's not such a huge beast, using various wrappers so that non-interactive Ruby programs work start up in the correct environment.

alrs 13y ago
If the divide is ruby 1.8 and 1.9, Debian packages both, and they can be installed simultaneously. If it's more arcane than that, it sounds like kvm or lxc is the answer. If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. One fix would be to update the ancient software so that it can use modern Ruby. Another fix would be to re-architect the solution so that the greater system could operate across multiple OS instances. The least attractive option would be to use packaged Ruby for the modern stuff, and a hand-compiled Ruby for the legacy stuff.
- joevandyk 13y ago
  If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. Why? Why can't you have a stable app using Ruby 1.9 that hasn't need any updates (other than security) in three years running on the same machine that also runs another newer application which uses Ruby 2.0 and Rails 4? To me, that's not "technical debt".
  - regularfry 13y ago
    Maybe "wasting asset" is a better metaphor. At some point, there'll come an OS release on which that Ruby won't even build (and this can happen sooner than you'd think - 1.8.7 needs to be patched to build on Wheezy, for instance; by the time Jessie goes stable 1.9.3 will probably have been deprecated and unsupported too). At that point, you're forced into porting to a newer Ruby just so you can keep up with security patches to the underlying OS. It might not be "technical debt" per se, but it's definitely a maintenance cost.

yxhuvud 13y ago

The problem is that the ruby versions packaged in the distros are not always as compatible as one could wish. Sometimes it is the list of default gems that is different (like how fedora packages bignum as a gem), and sometimes it is the distro packaged gems that just doesn't look like the stock versions. I've seen examples of gems split into two gems, as well as gems that has had their version dependencies altered. things like that easily makes either rubygems or bundler very unhappy. The thing about distro packaged software is that you have to trust the distro to do the right thing, and it only takes so many examples of them doing something stupid before that trust is lost.

chrislaco 13y ago
Sometimes it's not even gems/libs, but dist specific patches to the language itself. RHEL used to be notorious for breaking their Perl 5 dists. The first rule of Perl was to compile your own the server.

irahul 13y ago

You are entitled to your opinion, but as other commenter pointed out, rvm was created for production. > hey exist to allow developers on Macbooks to sync their version of Ruby with whatever is packaged in the Linux distro or BSD variant that runs in production. Or to allow developers who run ubuntu to develop multiple projects which need conflicting versions of the Gem and interpreters seamlessly. Also, I sometimes deploy multiple projects on same production box where the 2 might need different interpreters, and they almost always need separate gemsets. I can manage the interpreters and LOAD_PATH manually, but then I will end up creating an unholy mess which will somewhat resemble rvm. I am curious. What are your reasons for "rvm doesn't belong in production"?

alrs 13y ago
The best example of why the rvm model fails on the dev side is nokogiri. Yeah, sure, you can have multiple versions of Ruby and the Nokogiri gem on the same box. libxml2, borrowed from the GNOME project, is the C library that is doing all of the heavy lifting underneath. If the version of libxml2 on your dev machine is different than the version in prod, it doesn't much matter if you've got the same version of Ruby and the same version of Nokogiri. Use Vagrant. You will get a complete Linux VM for each different project that will match up perfectly with whatever the prod environment looks like.
- irahul 13y ago
  Do you deploy with Vagrant? I think container might be the way forward, but I am not convinced, and I don't deploy Vagrant to production(containers might be the future for deployment but Vagrant in it's current state isn't). I don't use vagrant in production because I use a Ubuntu box for development and rvm/bundler, virtualenv/pip...cover my needs for maintaining different and isolated dev environments.
  - alrs 13y ago
    No, I don't deploy with Vagrant. Nor would I. Use Vagrant to spin up Linux VMs locally so that you can have a dev environment that matches production.

deleted 13y ago

[deleted]