11.3. Deploying Rails

Deploying a Rails application into production is an exciting moment. After a journey that brought you from requirement gathering to a full implementation of the application, you are finally ready to deploy your application to the world (or to a selected few within an intranet).

This may come as a surprise to you, but historically, this was often the exact moment when troubles started brewing. In fact, the easy-to-use framework that increased your productivity and made you love Web programming was once anything but easy when it came to moving from development to production mode.

11.3.1. A Brief History of Deploying Rails

Deployment has always been Rails' Achilles' heel. While PHP developers had their mod_php module for the Apache Web server, and ASP and ASP.NET developers could count on IIS, Rails developers were left with a bad taste in their mouths due to a series of solutions that didn't really work reliably.

The timeline of recommended deployment configurations and technologies has been a rollercoaster ride and moved just as speedily as one. In the beginning there was WEBrick, but it wasn't really meant for production use, so in 2004 when Rails came out, the recommended configuration for Rails or any other Ruby Web framework was to use Apache with FastCGI. The problem was that FastCGI was, for all intents and purposes, an old and abandoned technology that somehow managed to get the spotlight thanks to the fact that an equivalent module a la PHP didn't exist for Rails. The community at large quickly learned about the instability of this configuration and started looking for something better. Apache + FastCGI was also a very poor solution for shared hosting, because it required far too much maintenance and in some cases users were forced to open tickets with their hosting company just to restart FastCGI whenever it inexplicably stopped working.

Thanks to a more solid implementation of FastCGI, a lightweight and fast Web server called Lighttpd (aka Lighty) managed to become the de facto recommended configuration for deploying applications in 2005. Some users experimented with Lighttpd and SCGI, or Apache and FastCGID, but most people in the Rails community were rolling with Lighty and its implementation of FastCGI.

There were some people who were satisfied by this solution and a few of them are probably still using this configuration to a certain extent, but most experienced Rails developers will confess to the fact that FastCGI was rather problematic. Other alternatives popped up but none of them really hit it big with the mainstream audience.

Until 2006 that is. Two years after Rails' first release, a drastically better solution came along. Zed Shaw created an application server called Mongrel. It was fast and allowed you to run a cluster of Mongrels (a few processes each responding on a different port). Suddenly, a proper deployment solution was available. In fact, it was now possible to use Apache2 to serve static content while proxying the execution of Ruby code to Mongrel (or a cluster of Mongrel processes). Apache2 was very fast at serving static content, and Mongrel did a great job as a Ruby-based application server. Zed Shaw and his oddly named application server saved the day.

In 2007, several people started to show an appreciation for a Russian Web server called Nginx. It was lighter than Apache2, faster according to many, and easy to configure. In 2007, Nginx + Mongrel finally became a widely adopted solution. Engine Yard, one of the most prominent Rails hosting companies out there, embraced the combination and to date is still using it to flawlessly serve millions of page views.

Whether in conjunction with Apache2, Lighttpd, Ngnix, or other load balancing software, proxying HTTP requests to Mongrel or similar application servers (for example, Ebb or Thin) became (and to a great extent still is) the way to go.

No, I'm not going to tell you that the Rails community has abandoned Mongrel in favor of something else. But something even more revolutionary did come along in 2008. Before briefly discussing what changed in '08, it's important to understand that Apache2 + Mongrel or Nginx + Mongrel work perfectly fine today and are, in fact, a good way to scale applications.

If you need to serve more requests, you can simply add extra mongrels and, assuming that you added extra nodes to the network, you can have them run Mongrel processes and use Apache2 (or Nginx, or any other load balancer) to load balance them when the requests come in.

Actually, you can even use a load balancer like Pen, which won't serve static content, and causes Mongrel to serve the whole request (even though this is not as fast as it would be with Apache2 or Nginx).

The only criticism that we are able to afford against this type of deployment is that it's not very straightforward compared to something like mod_php. It's not as hard as proving or disproving that P = NP, but it can still be intimidating to newcomers.

I have a truly marvelous proof of the P = NP proposition, which this margin is too narrow to contain.

Furthermore, though it's a very good solution to scale up and out Rails applications, it requires a sizeable amount of resources, and each Mongrel process (which is mostly Ruby code) has a non-negligible memory footprint.

These are not huge tradeoffs as long as you have the resources and know what you are doing. It is, however, a solution that works best for those people who are deploying at least on a VPS (Virtual Private Server) or, even better, on a dedicated server.

Naturally, cloud services that are available through elastic computing a la Amazon Web Services are fine too.

It's not ideal, you might even think it's downright problematic, for people who want to deploy Rails on cheap shared hosting. Meanwhile, PHP and Apache2 are easily deployed pretty much everywhere.

In 2008, this last obstacle to the deployment of Rails was shattered by something called Phusion Passenger (aka mod_rails). This is a module for Apache2 to serve Rails applications. As you can imagine, it's roughly the Rails equivalent of what PHP has always had (only smarter and more optimized). Passenger is stable, very fast, and, especially when combined with Ruby Enterprise Edition, a free edition of Ruby 1.8 created by the same company (http://phusion.nl), it tends to have a relatively small memory footprint. Shared hosting companies love Passenger and it's extremely easy to set up thanks to an installer that takes care of everything and informs you about a simple manual step. Hongli Lai and Ninh Bui, the authors of Passenger, really saved the day.

37signals (the company that created Rails) and several other companies are now moving to Apache2 + Passenger and it is considered by many, including David (Rails' creator), to currently be the recommended way of deploying Rails applications in most circumstances.

The story of Rails' deployment pretty much ends here. There may be changes to it in the future. For example, it is likely that an Nginx version of Passenger will appear soon, even though it hasn't been announced yet as of the time of writing. Likewise, it's not farfetched to assume that Passenger may release a premium, commercial version of its module. But between Mongrel and (in particular) Passenger, we have reached a point where having a solid deployment in production is no longer a dream, and thanks to Passenger, deploying Rails is finally easy.

At the beginning of 2008, Zed Shaw published a now somewhat famous rant entitled "Rails is a ghetto." In this "highly critical" (to use a euphemism) piece, he disassociated himself from the Ruby and Rails communities in a categorical manner, and delegated the leadership of his project to others. Ever since, many people have felt less than enthusiastic about adopting Mongrel in production. This, coupled with the rise of a great product like Passenger, made Mongrel less prominent in the Rails community, though it is still successfully being used by many.

11.3.2. Deploying on Windows

It is usually not recommended to deploy Rails on Windows. Let that news sink in for a moment. Sadly, despite the diligent efforts of some, Windows is currently considered to be a second class citizen when it comes to Ruby and Rails. Though it can be done, and you shouldn't be ashamed of deploying on Windows, a series of caveats and poor performances are associated with this choice.

In fact, according to my latest "Great Ruby Shootout," Ruby 1.8 on Windows would be twice as slow as Ruby 1.8 compiled from source on GNU/Linux, against a set of synthetic benchmarks (using the Ruby Benchmark Suite, a project I created). These results are also confirmed by a great deal of anecdotal evidence, and Rails applications are reported to be (and are in my experience) much slower and less responsive on Windows.

You can find the December 2008 version of the shootout online at http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008.

This is a sad state of affairs, I know, at least for Windows developers. It is possible that things may change in the future, but for the time being, my best recommendation is this: if you can, deploy on Linux, but if you need to deploy on Windows, read on.

Phusion Passenger takes advantage of *nix-specific features and as such is not available for Windows, nor are there plans to change this anytime soon. With this excellent option out of the picture, you are really only left with one solid alternative, and that's using Mongrel with Apache2 (or an equivalent server).

For step-by-step instructions on how to install and configure Mongrel and Apache 2.2, I urge you to follow Paolo Corti's instructions, which are published on his blog at http://www.paolocorti.net/2007/11/15/ruby-on-rails-applications-with-mongrel-cluster-and-apache-url-rewriting-on-windows.

11.3.3. Deploying on GNU/Linux

As mentioned before, the recommended way to deploy your Rails application on Linux is to use Phusion Passenger. The process is very straightforward:

This third step will provide you with step-by-step instructions on how to proceed with enabling the module as well as configuring a virtual host for your site in Apache's configuration files.

Passenger is now also known as mod_rack, thanks to its support for the Rack Web Server interface. As such, installing Apache2 + Passenger will be able to serve more than just Rails applications. Most Rack-enabled Ruby frameworks, including popular choices like Sinatra, Ramaze, and Merb, are supported by this deployment configuration.

A virtual host entry will resemble the following:

<VirtualHost *:80>
    ServerName www.example.com
    DocumentRoot /apps/example/public
</VirtualHost>

Please note that the DocumentRoot needs to point to the public directory of your Rails application.

In any deployment, only the public directory should be readable to your visitors. For this reason, it is not uncommon to store the application on the disk and create symbolic links (for example, with ln -s) from the public folder of the application.

Restarting an application through Passenger is as easy as touching a restart.txt file:

touch /apps/example/tmp/restart.txt

The extensive guide available at http://www.modrails.com/documentation/Users%20guide.html provides you with all the details you'll need to configure and fine tune your Phusion Passenger deployment.

To monitor your processes on Linux, you can use either Monit (http://mmonit.com/monit) or god, which is written in Ruby and available online at http://god.rubyforge.org.

It's also worth pointing out that when developing on Windows and deploying on Linux, it's important to use an editor that's able to work with, and convert, code that has the Unix-style line end character. If you don't, you'll encounter problems on Linux due to the extra character placed at the end of each line by many Windows editors (for example, CR + LF). This is also important when committing code to a repository that may have commits from both Windows and *nix clients.

If you happen to be deploying and developing on Linux, you may want to consider Capistrano, which is an excellent system for uploading applications that are located in a repository or a local folder, to a remote, production machine. Once you define a Capistrano recipe, you will be able to redeploy your application, upon changes, in an entirely automatic manner. You can read more about it online at http://www.capify.org.

Unfortunately, support for Capistrano on Windows has recently been discontinued.