

One app, one user, one ruby - yashke
http://blog.arkency.com/2012/11/one-app-one-user-one-ruby/

======
bradleyland
This is a trade-off. "Just use the full path to ruby" isn't a terribly
convenient solution, because using the full path isn't the "Unix way". Putting
your custom Ruby in the path is helpful, but in a server environment where I
would assume you're using a lot of automation, that's going to take some
tweaking. Users of RVM know this well.

I guess I don't really understand what the author is advocating? In
"production", we don't run multiple apps requiring different Ruby versions on
the same VM. Ruby 1.9 has been around for quite a while now, so there's not a
lot of fragmentation. We only run one version of Ruby, but we install it to a
location that a "stock" environment supports well. Usually it's
prefix=/usr/local. Then we treat VMs as disposable containers. I don't build
VMs by hand; I let my build tool do that, so upgrading infrastructure versions
usually goes something like this:

* Update the build script and test with a local VM

* Build a new staging VM and migrate the staging instance there

* Once we're confident, do the same to production

------
mlitwiniuk
For some time I always create user deploy and install nginx through passenger
on rbenv (if there is only one app on server) or create separate user per app
and run everything using rbenv+unicorn+nging from apt. Works flawlessly. I
can't agree more, that reating chef recipe is step forward.

