Using mod_proxy to Deescala

New name

Better is nginx + upstream { server unix:… } + thin, it seems:

http://macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-load-balancer-tonight/

----

Background:

From endikos:

basically you set up all your services to listen on non-standard non-priviledged ports, then use Apache to act as a proxy between them and the outside world.  The cool thing is that you can set it up to listen to specific URLs, so that if a pattern matches, it forward that traffic to a specific service, but if a different pattern matches, it will forward to a different services, etc

this also is a security bonus as you get to run your actual services as non-priviledged users

I like it better than chroot jails, myself

the proxypass module can also be set up to load balance if you wish, and bounce traffic betweena pool of listening services

{{ProxyPass /special-area http://special.example.com smax=5 max=10
ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On
<Proxy balancer://mycluster>
BalancerMember ajp://1.2.3.4:8009
BalancerMember ajp://1.2.3.5:8009 loadfactor=20
# Less powerful server, don't send as many requests there,
BalancerMember ajp://1.2.3.6:8009 loadfactor=5
</Proxy>}}

Full docs are here: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

You *can* make rails + passennger listen on those ports, in this particular case, iit would be something more along the lines of of rails + unicorn or rails + mongrel.

ok...  Passenger is an apache module.  It runs as a process inside apache.  It spawns aruby interpreter and consumes the whole of your rails app, then runs it out of Apache itself.  Mogrel/Unicorn are each standalone http services, They're not integrated into apache whatsoever, and listen on their own ports.  When rails first started, you would run a "pack of mongrels" as a standard user, then use a proxy or load balancing service to forward traffic from port 80 to your mongrels and then back out to the end user.  (CONT'D)

This was because there was no efficient way to run rails from inside apache itself.  There was an old fashioned CGI way, and a FastCGI way, but they were still too slow to efficiently run rails.  This is why the "pack of mongrels" became the standard way to run a rails app.  Then the Phusion guys came along an released Passenger and suddenly deploying a rails app was as easy as deploying a PHP app.  However there are caveats to doing it this way.  Since your ruby environment is now running as a single user (whichever user runs the apache service) you're essentially tied to the global gemset.  In theory, you can just load all the gems you might possibly need into your global gemset, but in practice, wierd stuff starts to happen when you try to run hugely different rails versions (like 2 and 3) at the same time.  And this becomes even more difficult since most of us were deploying rails 2 stuff when ruby 1.8.7 started becoming deprecated, but couldnt take the time to update legacy apps to rails 3.  (CONT'D)

Since a single instance of apache can only run a single version of ruby, you're now looking at running multiple instances of apache so that you can tell passenger to run on a different ruby version and gem environment.  After Passenger came into widespread use, RVM started making inroads, and developers loved it.  They could run whatever rubies and gemsets they needed to make their apps work, and no have to have any bloat in a gemset.  But apache/passenger can't work this way.  So now things are swinging back towards the user spawning processes and apache proxying between the user processes, only this time, with mongrel's successor, unicorn.

This way, you can use RVM to manages ruby and gem versions, and have some real flexability in your deployment environment.

Password Summary of changes

For Our King, Only

Using mod_proxy to Deescala