Deploying a small Rails app - suggestions?
We've been working on a smallish Ruby On Rails (ruby 1.8, rails 3.0.1) system for our school finals project; during development, we've been testing on a mix of our development machines and a linux server on our LAN, running WEBrick. For deployment, we've been given a VPS running Debian squeeze/sid, and free hands wrt. deployment options (in other words: "figure it out yourself" :)).
The site isn't going to have high-volume traffic, so running the deployed off WEBrick would probably work - but it feels wrong, and considering this is a learning project we'd like to do stuff at least semi-properly. Also, we want gzip compression, since part of the rails app is a json webservice which will be serving a moderate amount of data - and as far as I've been able to tell, the ruby servers generally don't support this.
I've been doing a lot of googling the last few days to survey the various options, and zowie there's a lot! The only thing I'm pre-emptively ruling out is Apache, mostly because I want to try something new, and partly because it feels a bit... clunky.
Right now I'm investigating cherokee + Thin, which seems decent, but I'm very open to suggestions if there's something more suitable. I've bumped into lighttpd, hiawata and nginx servers, and I've seen mentions of mongrel, passenger and unicorn ruby servers - there's definitely a lot of possible permutations!
For testing, we currently set up SSH tunnels and use etc/hosts to map appname.local to 127.0.0.1 - registering the proper domain and punching holes in the firewall will come at a later time. The main implication for this is that the httpd is running on port 80, but because of the SSH tunnelling the Host: part of the HTTP request header contains the tunnel port number.
In order to hopefully turn these ramblings into an appropriate post, here's some questions:
- When using the Thin ruby server behind another httpd "frontend", can a single instance handle (without queueing) multiple concurrent rails requests, or can it only do that when it's being used as frontend? Should I we use a pool of them on different ports?
- We're currently putting the rails app in /var/rails/appname, and symlinking /var/rails/appname/public to /var/www/appname, and having ownership of everything to
www-data. Does this layout make sense? - There's some framework-controlled 302 redirects going on in the system, especially wrt. user authorization. When connecting directly to WEBrick or Thin, things work as expected. When connecting through Cherokee, for some reason the tunnel port number is stripped from the
Location:response header. Any idea why this is happening? - Whenever cherokee has been restarted, the first request to the rails app gives a "502 bad gateway" HTTP error, presumably because the Thin server is demand-started. Any way to get rid of this initial 502?
Solution 1:
Today best-practice way is to deploy rails with Capistrano (Vlad) and Passenger with nginx / apache (nginx is faster, apache is more common). I am running few moderate traffic rails sites with such setup and it is running smoothly
Some notes:
- Ruby enterprise edition is faster.
- Ruby 1.92 is faster
- If you are memory-constrained (VPS), use nginx
As for your questions:
1. Yes, it can .
2. With capistrano, put stuff current and release directories (to allow rollback) . Why symlink ? Public belongs to application.
3. That is Cherokee bug
4. Keep thin as seperate process, under some process supervisor .