5 ms·

PSA: Do not use system Ruby - http://robots.thoughtbot.com/post/54109839209/psa-do-not-use-system-ruby http://robots.thoughtbot.com/post/54109839209/psa-do-not-

PSA: Do not use system Ruby - http://robots.thoughtbot.com/post/54109839209/psa-do-not-use-system-ruby http://robots.thoughtbot.com/post/54109839209/psa-do-not-use...

sergiotapia 13y ago
I'll give this a read, thanks for sharing.
alrs 13y ago
Correct. Don't use rvm or rbenv on your production Linux boxes. Use packaged Ruby there.
- enko 13y ago
  Er, why not? rvm was originally made for production use! I've used rvm in production for major sites for years with no problems whatsoever, in fact I believe it is best practise. Do you have any reasons for your preference for packaged ruby?
  - regularfry 13y ago
    Best practice says production boxes shouldn't have compilers installed.
    - judofyr 13y ago
      Install compilers on one machine, build Ruby, package it up as a deb/rpm/whatever, distribute to other machines.
      - regularfry 13y ago
        Yep, that's the idea.
        enko 13y ago
        Sounds like an awful lot of work for no good reason I can think of. You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions. "No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
        regularfry 13y ago
        > Sounds like an awful lot of work for no good reason I can think of. Perfectly reproducible deploys and shutting down attack vectors are both very good reasons. > You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions. Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either. > "No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments. Ruby isn't special, or magic. It doesn't get a free pass "just because." If you've got reasons it should be exempt from the best practices that have been learnt elsewhere, let's hear them.
        enko 13y ago
        In the real world, we don't have unlimited time, so we have to try to balance effort required versus the outcomes we desire in order to get the best "bang for buck" out of our time. Your suggestions are incompatible with this imperative. > Perfectly reproducible deploys and shutting down attack vectors are both very good reasons. No they're not. Firstly, I already have good enough deploys. Secondly, the attack vector you're talking about - having a compiler installed (!) - is almost not worth mentioning and certainly does not justify the huge extra effort. We're running a business here. > Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either. Says you, and pretty much only you. Anything else is a massive inconvenience. Everyone does this. It may not be "perfect" but again, we are running businesses here. > If you've got reasons it should be exempt from the best practices that have been learnt elsewhere No, it doesn't work like that. "Best practice" does not mean a blind adherence to some decade-old set of irrelevant rules ahead of all practical operational priorities. What the ruby community has is a practical balance - workable, efficient, fast. What you suggest rings of a disconnected IT department with no incentive to make life easy for those trying to iterate fast. It smacks of ass-covering and excuses; I know it well. You've not made any points I find compelling in the least. Anyway, I don't wish to argue about it, I simply wish to point out, to any others reading this, that your opinion on best practise for ruby deployments is controversial, to say the least. Anyway, I doubt you've actually done any deployments at all in accordance with the ridiculous "best practise" you've outlined. I doubt anyone has. I, on the other hand, have had great success with my approach, as have countless others. As usual, the armchair quarterback has any number of wise-sounding criticisms, but is not actually in the game.

PSA: Do not use system Ruby - http://robots.thoughtbot.com/post/54109839209/psa-do-not-use-system-ruby http://robots.thoughtbot.com/post/54109839209/psa-do-not-use...

sergiotapia 13y ago

I'll give this a read, thanks for sharing.

alrs 13y ago

Correct. Don't use rvm or rbenv on your production Linux boxes. Use packaged Ruby there.

enko 13y ago
Er, why not? rvm was originally made for production use! I've used rvm in production for major sites for years with no problems whatsoever, in fact I believe it is best practise. Do you have any reasons for your preference for packaged ruby?
- regularfry 13y ago
  Best practice says production boxes shouldn't have compilers installed.
  - judofyr 13y ago
    Install compilers on one machine, build Ruby, package it up as a deb/rpm/whatever, distribute to other machines.
    - regularfry 13y ago
      Yep, that's the idea.
      - enko 13y ago
        Sounds like an awful lot of work for no good reason I can think of. You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions. "No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
        regularfry 13y ago
        > Sounds like an awful lot of work for no good reason I can think of. Perfectly reproducible deploys and shutting down attack vectors are both very good reasons. > You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions. Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either. > "No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments. Ruby isn't special, or magic. It doesn't get a free pass "just because." If you've got reasons it should be exempt from the best practices that have been learnt elsewhere, let's hear them.
        enko 13y ago
        In the real world, we don't have unlimited time, so we have to try to balance effort required versus the outcomes we desire in order to get the best "bang for buck" out of our time. Your suggestions are incompatible with this imperative. > Perfectly reproducible deploys and shutting down attack vectors are both very good reasons. No they're not. Firstly, I already have good enough deploys. Secondly, the attack vector you're talking about - having a compiler installed (!) - is almost not worth mentioning and certainly does not justify the huge extra effort. We're running a business here. > Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either. Says you, and pretty much only you. Anything else is a massive inconvenience. Everyone does this. It may not be "perfect" but again, we are running businesses here. > If you've got reasons it should be exempt from the best practices that have been learnt elsewhere No, it doesn't work like that. "Best practice" does not mean a blind adherence to some decade-old set of irrelevant rules ahead of all practical operational priorities. What the ruby community has is a practical balance - workable, efficient, fast. What you suggest rings of a disconnected IT department with no incentive to make life easy for those trying to iterate fast. It smacks of ass-covering and excuses; I know it well. You've not made any points I find compelling in the least. Anyway, I don't wish to argue about it, I simply wish to point out, to any others reading this, that your opinion on best practise for ruby deployments is controversial, to say the least. Anyway, I doubt you've actually done any deployments at all in accordance with the ridiculous "best practise" you've outlined. I doubt anyone has. I, on the other hand, have had great success with my approach, as have countless others. As usual, the armchair quarterback has any number of wise-sounding criticisms, but is not actually in the game.