Comments on: Rails deployment: wouldn't it be great if it worked like this?

By: Roger Pack

Roger Pack — Thu, 07 Feb 2008 22:21:38 +0000

Have you looked into mod_ruby? I believe I once read that it can handle multiple rails guys going at once, but…I’d say the main problem with mod_rails is the huge RAM cost. Unless all the rails apps are trained to ‘play nice’ and ‘not take too long’ and ‘don’t override each other class methods’ you’ll need lots and lots of memory. Or I could be wrong. I don’t see an easy way out. Thoughts?

By: Greg Lorriman

Greg Lorriman — Mon, 04 Feb 2008 22:42:00 +0000

My own problems with with deployment where mostly due to the bad documentation on the mongrel site. It is confusing. I instead turned to my VPS service documentation for mongrel setup, and it was also inadequate. I ended up having to solve the problems myself, having never configured Apache before: it took a long time.

A secondary problem is the number of problems with gem updates/installs. Gems seems to confuse the functionality of ‘install’ and ‘update’. Even though I technically needed to update, actually I had to install. It took a long time to discover that.

By: Hongli

Hongli — Mon, 28 Jan 2008 21:15:06 +0000

Dan Kubb: Yes it would, but instead of port administration you now have to do socket administration (though this is easier because there’s less chance on conflicts). It would be best if no administration is needed, at all.

By: Dan Kubb

Dan Kubb — Mon, 28 Jan 2008 21:11:07 +0000

I know the thin server just added support for running via unix sockets. I wonder if this would solve problem #3.

By: Hongli

Hongli — Mon, 28 Jan 2008 20:45:24 +0000

Neil Wilson: mod_rails will not run the Rails app inside Apache’s process space. It is not mod_ruby. Rails apps crashing will have no effect on Apache other than returning an Internal Server Error back to the client.

Whether all this trouble is worth it, is something that the users should decide.

By: Neil Wilson

Neil Wilson — Mon, 28 Jan 2008 19:30:53 +0000

You’ll probably pull in all the Apache memory management routines, which you would have to use to get Ruby running in the shared space without running into something else. Otherwise you risk potentially destabalising the web server with your parent forking structure.

I don’t think there is much to be gained from sticking Rails within the Apache process. The real gain is CoW forking from the cluster start up processes with preloading, and again I wonder if it is worth creating the programming necessary to allow forking across users – with all the security problems that may turn up.

Fire up a mongrel/thin cluster using forking from user space using crontab @boot with the Rails app in the Unix user home directory. If you use thin as opposed to Mongrel you can use Unix sockets rather than ports and they have proper names! A crontab watch script can allow a restart on a file touch.

What I suggest is simple and can be done today with existing technology. You can use edge Rails and Gems – even a different Ruby interpreter if you change your path.

One commercial advantage of having multiple backend application servers running is that you can charge per port. The more concurrent ports you require for your app, the more it costs.

By: Hongli

Hongli — Mon, 28 Jan 2008 18:25:51 +0000

Neil Wilson: You’re misunderstanding a few things, namely:
- Ruby’s current garbage collector is not copy-on-write friendly, this is correct. But I’ve already fixed this. See my previous blog articles in the Optimizing Rails category.
- Ruby’s copy-on-write unfriendliness only affects the Ruby object heap, not everything else. A garbage collection will *not* make all the Apache data pages dirty as well.

By: Neil Wilson

Neil Wilson — Mon, 28 Jan 2008 14:42:14 +0000

Slight problem with your vision. ‘mod_rails’ is an Apache module. If you fork that then you will replicate the entire Apache process again – including the bits you don’t want. Add to that the Ruby interpreters annoying inability to handle Copy on write effectively and you’ll be up to Mongrel size in no time.

What you actually need is a mongrel cluster generator that forks the processes, and a Ruby interpreter that doesn’t expand cause memory replication. Then what you do is create a Unix user for every customer you have, and boot empty mongrel clusters on preallocated ports (the ones you’ve paid for) via the users own crontab. The mongrels run in user space, pointing at a blank Rails app sat in the users home directory. This is all created automagically via the Unix skeleton system. The web server proxies onto these ports for whaver domain it is managing. You then upload the Rails app into the home directory via capistrano in the normal fashion.

The solution is here http://accounts4free.rubyforge.org/svn/multi-tenant, but is in a pretty rough form at present and is probably out of date with regards to Rails 2, etc.

By: Saimon Moore

Saimon Moore — Mon, 28 Jan 2008 12:56:33 +0000

Good idea, right the module for nginx first and make sure it does ‘fair’:http://brainspl.at/articles/2007/11/09/a-fair-proxy-balancer-for-nginx-and-mongrel proxying while you’re at it

By: karmi

karmi — Mon, 28 Jan 2008 10:13:53 +0000

“Why can’t Rails deployment be as easy as PHP, i.e. upload-and-forget?”

”

Because the current Rails Way of deployment with versioned source code and Capistrano promotes much better and healthier development practices than PHP deployment in “upload-and-forget” style?

(If you’re looking for “a la PHP” Ruby framework, have a look on magnificent http://sinatra.rubyforge.org/)