RVM is great for developing on your local machine. But is it safe on a production machine?
I built RVM for production and added the developer 'niceties' later on.
If you would like more information read the documentation on the website and come talk to me in #rvm on irc.freenode.net sometime during the day EDT most days.
Since RVM is just a fancy way of downloading, isolating and switching between existing Ruby implementations, I'd say that it's as production ready as whatever ruby implementation you're currently running it with.
Essentially, all RVM does is point your path at a specific Ruby implementation. This is exactly what happens when you use your *nix distribution's Ruby implementation. The only real difference is that your path will be re-written so that when you run ruby -v it will run a ruby from your current user's .rvm directory instead of a global system directory like /usr/local/bin.
I'd go even further and say that using RVM is a better solution than using what generally gets installed in a *nix distro because it makes it easy to sandbox the specific ruby implementation on a per-user basis. RVM also makes it possible to attempt switching rubies (ie; from 1.8.7 to 1.9.2) on your production app while keeping a solid rollback strategy in place if something doesn't work quite right. It also makes it easier to keep old applications running on one version of Ruby, while switching new apps to more current versions.
I disagree, especially if you're using any kind of automated production process (puppet, chef, fog, etc) and you have more than one or two machines.
We've had issues where version X of RVM worked in a completely different way to version Y of RVM (different default Rubygems versions, different default gemset configs, complete changeup of how system wide install works), breaking our automated provisioning process.
Not an issue if you're developing and on hand to tune things, a killer if you have an unattended scripted / puppet install. We worked around these issues by locking to a particular RVM version, but I remember having a conversation with Wayne where he discouraged this. If we kept using RVM in prod, we were going to actually package it into a series of .debs (one for the install, one for each Ruby).
The way that .rvmrc prompts by default and can only be overriden in the homedir ~/.rvmrc (and not the system-wide one) was also unhelpful.
I actually like the way that RVM will change up and do things this way in development - nothing sucks more than being held back by backward compatibility. This approach, however, cost us some time (and pulled hairs) in production/staging/uat/test.
RVM is apparently a reasonable production tool
You know, I once made a similar rvm is a development tool comment and was informed that rvm was originally a production tool.
So, RVM will make your production environment more complex, which is bad, but it makes it more isolated and compartmentalized, what the language people would call modular, and that's good.
In the end, as long as you test your deployments, I don't see how a static configuration of any kind could be, all by itself, "unsafe".
It all depends on how you are installing RVM , single-user or multi-user . installing RVM system wide can cause lots of mess whole switching between different rubies. Better you opt for single user , minus that RVM does a good job for what it's meant to do .
I guess there's two parts to this question:
Is RVM intended to be for production machines, as opposed to development machines?
Is RVM reliable enough software to be used on production machines?
For (1), Wayne E. Seguin has stated that it's intended to be used on production machines. There's no point in disputing his intent.
For (2), I'm not so sure. Is it appropriate to use software that has a new version number every couple of days on a production machine? Also, RVM once deleted my entire ~/ruby directory. To Wayne's credit, when I told him about it, he fixed it that night, but that doesn't exactly say "production ready" to me.
Edit: I've just read about bumblebee's deletion of /usr, and I'll just say - it could have been worse! LOL.
I've been using RVM on a production webserver for over a year now with zero problems. I've kept it pretty up-to-date, running rvm get head frequently. Zero issues, ever. :)
Yes, I've used rvm on production machines and also set up puppet modules to install rvm as the default system ruby along with gemsets, etc.
If you run multiple apps on a single server, rvm can help you keep all your apps gemsets (and ruby versions) totally separate. However, if you are running only a single app on a server, there may not be as much benefit to having rvm installed.
I've pretty much used RVM on all my production servers running rails apps!. RVM has not let me down.
Related
Full disclosure. I do not use Ruby. I never have even looked into learning it as a language.
We use ruby at our company to power an integration between a couple of our tools. Due to a TLS update we have to update our ruby version from 1.9.2 to the newest version.
On this windows server 2008 r2 machine I have that version of ruby and need to update. The problem is this tool is in constant use. So I cannot reasonably take the server down for a whole day while I try to figure out what to do. Initial research shows that these older versions of ruby are problematic to update.
I have only a half dozen gems to worry about (and found a really good guide on updating those - I think).
Looking for a kind soul who is willing to help a lost soul.
Is this a case of needing to completely uninstall and if so does that mean uninstall my gems as well? Or can I just run an update via cmd?
This is mostly going to come down to your gem dependencies.
As for just the language, the odds of encountering anything that works with Ruby 1.9.3, but not Ruby 2.0+ will be highly unlikely. Plenty of features have been added, but on a whole, backwards compatibility has been maintained.
This is not necessarily the case with gems, as the dependencies and robustness of the code can vary wildly depending on the source. The only real way to answer anything with confidence is to check/compare dependencies of each gem you require with your target Ruby version. Typically increasing the Ruby version is less likely to "break" anything than lowering it obviously, but it is still a significantly plausible scenario you must be wary of and prepare against.
The only real way to do this without downtime is to clone or setup a new environment for testing, install the newer Ruby, install the required gems you have researched dependencies, and test to make sure everything runs/works as expected.
Unfortunately there is no "magic bullet" here that is going to solve this issue for you. Luckily, the vast majority of this does not require knowledge of Ruby syntax and coding, and if everything goes well, will require nothing more than installing Ruby, installing gems, and comparing versions. If you run into issues with specific gems, I am confident that there is a host of people here on SO that can help guide you through reconciling it.
I'm on OSX, 10.8.3, ad use homebrew. I was wondering it would be possible to have multiple instances installed. I have the default /usr/local/ install but would like to have a completely separate version where I can test packages and different installs without screwing up my basic install in /usr/local/ that works great.
I read the wiki and all that about installing into ~/(.)homebrew and then symlinking "brew" to /usr/local/ but I imagine that would conflict with my current install in that directory.
I do not mind, and realize I will have to change my projects to work with the different homebrew path but if anybody has done this and has some suggestions I would greatly appreciate it.
There is still no great way to clean dependencies for formulas well, imo, although progress has definitely been made. I know it's not recommended but I would like to have a "test" homebrew install where I can install all kinds of temporary packages needed for just one or two quick tasks and remove. I appreciate ANY and ALL advice so if you have anything that might be helpful, please do let me know.
Cheers and thank you SO community!
I'd recommend using a virtual machine as a testbed, instead of an alternate homebrew installation path. A VM setup has several advantages:
Homebrew can still live in its preferred, supported path.
You can see exactly what your formula changes will do to a "normal" installation.
You can still use broken, non-relocatable formulae safely.
Files are guaranteed not to leak out of your alternate path and clobber the main Homebrew install or other stuff, like they can if you have errors in your formulas
You can use VM snapshots to provide a clean baseline, and revert to them to discard any changes or mistakes.
You can make a bunch of alternate setups instead of just one or two, and they're all independent.
You can have a minimal install to isolate variables and reduce interactions.
You can even run them with other OS versions.
You can mess around with scary low-level stuff like kernel extensions without fear.
You can hand off an entire machine to a collaborator so they can se exactly what context your testing stuff in.
It's good practice for learning how to automate and modularize machine setup and configuration and will make your code & deployment process better.
Etc etc
I use VMs for all my Homebrew development work and it's great. I will never be doing deployment-oriented work without VMs again. Parallels is good, totally worth the money IMHO, or you can pick up VirtualBox for free.
To get your development code between instances, you can use git or other version control to shuffle them around, or mount virtual shared drives, or both.
Update
Forgive my ignorance, I think I asked him about rvm when I really meant RubyGems. And I think he's thinking of RubyGems because there does seem to be some controversy over it, at least there was in the past: http://stakeventures.com/articles/2008/12/04/rubygem-is-from-mars-aptget-is-from-venus. So please s/rvm/RubyGems/g for the below question.
End update
My server admin is a little wary of using rvm on Debian. Here's what he says:
Unfortunately, the whole rvm system doesn't interact properly with a
packaging system like Debian, and it's a nightmare to deploy when you
do the deployment at different times. [You can easily end up with
different versions of modules on different systems, etc, and you have
to deal with rvm stomping all over the Debian packaging system.]
I think what he's saying here is that we are going to be running the app across multiple servers and if we upgrade one server, it's going to cause serious problems for us.
Is there a way to address his concerns?
RVM in no way shape or form 'stomps' on the debian package system. RVM installs either in $HOME/.rvm for a general user, or in /usr/local/rvm using the 'rvm' group to which members must be added which is the normal place for 3rd party non-mission-critical applications, headers, and libraries.
RVM came into existence because of package managers. They were forever screwing up dependencies of rubies and gems, being behind the times for getting security updates pushed out immediately, for multiple rubies to be installed and managed on the same box without having to play symlink games to get them to work, and made deployments to multiple machines with multiple disparate deployment requirements a nightmare.
RVM solved all of that in a more than fairly seamless matter, with a specific eye on ensuring not only security of the install, and the users that use it, but also to ensuring that the package manager was in no way involved. This ensures that the package management tools and their databases of installed packages wouldn't get suddenly wacked.
I got involved as a user, and then as a developer on the RVM Project because it solved the dilemma so well and so elegantly.
Rubygems does not allows good control of gem versions, but together with bundler it allows a lot better control of version compared to apt-get.
You need to read on Bundler - it allows you to specify loose dependencies in Gemfile and strict ones are recorded in Gemfile.lock.
His concerns are that ruby is a moving target, ruby is updated every few months and all users should always update to latest patch level.
Ruby is a lot different packages (maybe except openssl), where ruby team is updating releases with patches, this allows focusing security efforts in one place, but this is against conservative approach of package managers where a version is picked and only security patches are applied to it, as stable it sounds - it spreads security effort on multiple teams and slows down whole open source community. Operating system maintainers do not want to accept the fact someone does part of the work for them and they could trust someone with it.
As for the repetitiveness of the process your admin is showing a lot of ignorance, RVM allows to lock versions, which is against the the Ruby approach explained above. So the simplest way to lock everything is to lock RVM to one version:
rvm install 1.15.14
But if the locking of RVM is required the preferred way is to lock it to minor version where compatibility is kept, but updates are provided:
rvm install latest-1.15
RVM does not keep this versions going for a very long time, but anytime there are concerns about current stable "stability" - we keep the previous version updated so you can decide which one to use.
#deryldoucette also explained a lot in his answer, I tried to not "reexplain" things.
The Ideal
Using rvm, it would be awesome to be able to have multiple Rubies on one webserver, and through some sort of server configuration, be able to assign Ruby versions to different Rails/Sinatra/etc apps on a per-project basis.
I am aware, from rvm's documentation, that Passenger only works with one Ruby at a time. :(
The Compromise
Failing that, it would be nice to at least be able to concoct a way to be able to assign projects to a Ruby 1.8 or a Ruby 1.9 interpreter. I've read that using Nginx as a reverse proxy allows running Apache and Nginx on the same box. Would it then be possible to have Apache+Passenger using one Ruby, and Nginx+Passenger using a different one? Maybe use something other than Passenger with Nginx?
Am I Barking Up the Wrong Tree?
Am I missing a good solution to this issue? Am I walking into a nightmare configuration situation? Is what I want even viable, or is it necessary to run another box to run a separate Ruby version?
check this post: Phusion Passenger & running multiple Ruby versions from official Phusion blog. It's solve the problem by use Passenger Standalone as reverse proxy.
You could use Thin or Unicorn with Nginx. You could than write a god script or some other startup script to set the ruby version per project (or simply start Thin/Unicorn manually).
Use multiple small virtual machines?
What about keeping all your projects (or at least those on one server) on the same ruby version? Be it using an old version or upgrading old projects?
I think, this way you have the fewest problems.
The compromise is possible. You can it this a variety of ways but probably the easiest is a reverse proxy combined with as many chrooted ruby+webserver+rails installs as you find convenient.
If you're using Mac OS X, you may want to check out POW!, which can handle multiple rubies. There's a linux alternative called hoof, which isn't as developed but is getting close.
What are the advantages and disadvantages of using the built-in Apache for local web development on Mac OS X, specifically 10.6 Snow Leopard?
Instead of using the built-in Apache, I know that options such as MAMP and XAMPP exist. However, for some reason I just haven't wrapped my head around the benefits or potential pitfalls with using the built-in Apache versus using a MAMP/XAMPP-based (or other) solution.
Is the advantage of a MAMP/XAMPP-based solution simply ease of configuration?
When not using the built-in Apache are there other benefits besides ease of configuration? For instance, is there a benefit similar to using virtualenv to avoid tainting a pristine Python install?
If you're only developing static webpages and don't need PHP or MySQL, then why not use the built-in Apache with something like virtualhost-sh or VirtualHostX to ease configuration?
Configuration and Usage Considerations
I am interested in using virtual hosts in order to simultaneously develop multiple websites
I use git for version control and have a tendency to store source files in ~/developmentinstead of ~/Sites (this probably isn't material, but thought I'd mention it)
Related Research
The answers to the SuperUser Question What is the best Apache PHP Setup for a Mac Developer talk about different MAMP, XAMPP, and roll your own solutions
Advantages:
It's already there, you don't have to install anything
If all you are interpreting are .html files only, then it's fine.
Disadvantages:
You can't update it
(Well you shouldn't. You can, it just feels hacky modifying stock system components).
If you wanted to enable PHP/MySQL etc later on you will be changing things in paths on the system that may break between OS updates.
If this is your primary OS, you are now running extra daemons (PHP/MySQL/Apache) in the background that eat up CPU cycles.
Overall though I wouldn't do it. MAMP's daemons are easy to start/stop and your changes are confined to MAMP. If you mess something up or need to quickly get different sites running with different settings it's kinda easier to blast things away in MAMP and start again (not that MAMP is without it's hassles).
If you don't want to use MAMP i'd suggest getting a dedicated Linux box (or use a Linux Virtual Machine) to do this on having been down the OSX Apache path before. It's not pretty. OSX's built in stuff might seem easier at first, but it's inflexible and eventually as your requirements grow you'll wish you hadn't done it.
Update:
I would recommend going with XAMPP over MAMP. It has better performance and is updated more often. Plus XAMPP is Cross platform and Open Source :)
I've used the stock Apache 1.x in previous versions of OS X for both local development and production web sites and have never had a problem with system updates breaking anything. I've never done anything extremely fancy, but have had plenty of vhosts, regular and reverse proxies, PHP, Python and Perl CGIs, custom cgi-bin locations, custom logs, etc, without issues. It has always worked exactly as I expect Apache to work.
This has continued to be the case with Apache 2 under 10.6. So for local development and low-key production stuff, I'd trust it.
I've had the same experience with the stock Apache installs on OS X Server, with the exception that using the provided GUI tools to edit the httpd.conf files has always been a total disaster. They simply never worked for me, overwrote previous changes, or outright crashed.