Section 13.0. Introduction

13.0. Introduction

In the past, actually deploying a Rails application has been something of a challenge. One of the reasons that deploying Rails was so much more difficult than developing with Rails is that the Rails framework has never claimed responsibility for the details of deployment. Another reason is that there wasn't a really good way to deploy a Rails application with Apache, by far the most common web server (especially in GNU/Linux environments). The problems with FastCGI, and the lack of support for it in Apache (especially the 1.3 branch) only made a prickly problem worse.

Rails' delay in getting an easy, reliable process for deployment hasn't stopped it from experiencing tremendous growth and popularity, but this has undoubtedly caused a lot of frustration and hampered the efforts of many Rails beginners to bring their projects to fruition.

Finally Rails got the care that it desperately needed to make the whole situation less of a pain in the neck. For a while there, everyone was hanging on the edge of their seats, hoping that Apache developers would fix the Apache FastCGI interface that had fallen out of maintenance. While waiting for that, many people flocked to LightTPD as a promising faster/lighter alternative to Apache that also seemed to have its FastCGI interface under control.

Yet although LightTPD was a lot less painful to use with FastCGI, it was still FastCGI, and FastCGI still has problems. FastCGI processes, whether running under Apache or LightTPD still are prone to wandering off, becoming unresponsive, consuming lots of memory, and generally making life unpleasant for their caretakers.

Meanwhile, development of an alternative to WEBrick (the simple built-in Rails development server) was under way. It seems that a guy named Zed Shaw just got fed up and decided to change the Rails deployment world with his own bare hands. The result was Mongrel (http://mongrel.rubyforge.org), which was very good news for all of us. The best thing about Zed is how much he cares about getting a situation together that works for everyone. (He is usually very responsive to questions and feedback about Mongrel.)

So what started as a simple, little, pure-HTTP web server to replace WEBrick turned out to be much more useful than anticipated. However, what has really changed the game is the introduction of the mongrel_cluster gem. Suddenly, serving Rails applications with a small pack of Mongrel processes and a load balancer (such as Apache and mod_proxy_balance) is a snap.

And though some of the earlier efforts, like LightTPD, seem to have stalled, the future looks brighter than ever on the deployment front. After a slow start, other solutions for running Rails applications with more reasonable resource requirements and reliable performance are still emerging. New load balancers such as Pen (http://siag.nu/pen), balance (http://www.inlab.de/balance.html) and Pound (http://www.apsis.ch/pound) are under active development, and there are even new lightweight web servers emerging (such as Nginx; see Ezra Zygmuntowicz's blog entry http://brainspl.at/articles/2006/08/23/nginx-my-new-favorite-front-end-for-mongrel-cluster) that seem especially suitable for serious Rails performance.

Last, but certainly not least, the emergence of Capistrano (http://manuals.rubyonrails.com/read/book/17) as the tool of choice for the automated rollout of Rails applications to production servers has brought an unprecedented taste of "The Rails Way" to the deployment process itself.