History

ProductionInstallationOnDebian (work in progress)

A production installation on Debian is not generally a hard task but the whole Rails production setup may be unfamiliar to a lot of sysadmins who haven't run across it before. In general, Rails applications are long-lived processes that sit around and serve requests - sort of like a Java application has a servlet container. There are a whole pile of different ways to accomplish this, and so there's a correspondingly huge and confusing array of online documentation on the web which will make you crazy if you haven't deployed a Rails application into production before.

At the simplest possible level, here are the approaches:

Bad approaches

  1. start mongrel (or webrick) on port 3000 and pray, just like you do in development mode except with thousands of people hitting your single-threaded app. For anything serious, this is not a real option, but it's worth mentioning that some insane people do actually advocate this approach. Don't do it.
  2. install the fcgid (or fastcgi) module. A lot of older (circa 2006) stuff you find on the web will tell you this is "standard". It was, for a few months when Rails was young and every other deployment option sucked even more. In reality, fcgid/fastcgi turned out to be rather unstable and is a big hassle to set up for use with Rails. It's possible that the developers of these modules have improved them by now, in which case I apologize for blackening their good name, but unless you see a whole rash of people recommending fastcgi in 2009 or later, stay away from it.

Good approaches

The viable options as of spring 2009 basically boil down to two:

  1. use a cluster of mongrel or thin webservers as an app container and set it up so that Apache or Lighttpd or whatever proxies the cluster. This has a bunch of advantages in that Apache serves all the images, static html files, etc., and the mongrels deal with dynamic Rails requests. The cluster size can be increased if necessary to deal with more load, or even spread across multiple physical boxes, so it's quite flexible. It also gives maximum flexibility in terms of which main webserver you want to use, as anything capable of reverse-proxying (Apache, Lighttpd, etc) can be used. It's also a complex setup, and the mongrels require monitoring since they don't restart automatically if they crash. In general, while this is a great option, it's more for advanced sysadmin types who like to wake up, reverse-proxy something, eat breakfast, set up monit, drink some coffee, and so forth. If you've never set up a production Rails installation before, go with the simpler Phusion Passenger option unless you seriously need all the power and flexibility and pain. If you want to set this up, the best article to check out is here
  2. use Phusion Passenger. This has the advantage of being nearly as easy to set up as mod_php, and still good enough to serve a production site for an event with a "G" in front of it. The docs for it are here, just follow the instructions that the installer gives. Basically, install the stuff that the development install docs wants you to install, but don't bother with starting backgroundrb or running rake:hyperactive:seed. Instead, install Passenger from the docs on that site. Run the installer and load the .so into Apache by sticking something like the following near the bottom of /etc/apache/apache2.conf, before the vhosts get loaded (note: version numbers may change, use whatever the installer tells you to use if it's different than this):
# Ruby on Rails configuration (Rails sites are served using Phusion Passenger)
#
# Passenger 2.2.2 Apache module which serves Rails sites for us.
#
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2
PassengerRuby /usr/bin/ruby1.8

Once you've got Passenger installed, it's basically just a question of putting the Rails site in /var/www/<hyperactive_app>, and pointing the Apache vhost at /var/www/<hyperactive_app>/current.

Here's a sample Apache vhost:

<VirtualHost 78.129.201.123:80>
  ServerAdmin imc-foo_at_lists.indymedia.org

  DocumentRoot /var/www/indymedia.foo/public
  ErrorLog /var/log/apache2/indymedia_foo.error.log
  CustomLog /var/log/apache2/indymedia_foo.access.log combined

  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn

  # Uncomment for rewrite debugging
  #RewriteLog logs/myapp_rewrite_log
  #RewriteLogLevel 9

  # Check for maintenance file and redirect all requests
  RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
  RewriteCond %{SCRIPT_FILENAME} !maintenance.html
  RewriteRule ^.*$ /system/maintenance.html [L]

  # Rewrite to check for index page
  RewriteRule ^/$ /system/cache/index.html [QSA]

  # Rewrite to check for Rails cached page
  RewriteCond %{THE_REQUEST} !^POST
  RewriteRule ^([^.]+)$ /system/cache/$1.html [QSA]

  # Deflate
  AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</VirtualHost>

Etch note

If you're running Debian stable (etch) add the following to your sources.list:

deb http://www.xapian.org/debian etch main
deb-src http://www.xapian.org/debian etch main

Then run:

su -

enter your root password
wget -O- http://www.xapian.org/debian/archive_key.asc|apt-key add -
exit

sudo apt-get update

Also available in: HTML TXT