Rails的部署在过去的五年中经历了很多变化。当初Basecamp上线的时候，我把它部署在mod_ruby上，因为只有一个应用程序所以我并不关心跑多个程序之后会导致它们相互依赖的问题。
更加见鬼的是，在早期的时候，如果没有太大的负荷你甚至可以把Rails当作CGI。我们曾经把这种方式应用于Rails的开发模式，因为在开发模式下每个请求都会导致重新装载整个堆。
随后，我们把Rails的部署移至FCGI。那也是一个可用的平台，我们用了好几年。但是FCGI在很长的一段时间内都没有进行开发，多少显得落伍了，而且它需要很多的巫术才能正常工作。
然后Mongrel来了
然后Mongrel来了，并且我们认识到应用服务器和web服务器之间并不需要一种新的协议来通信--使用HTTP即可！于是，很多Mongrel进程开始在各种各样的代理服务器和负载均衡之后运行着。
今天，Mongrel（以及它的亲属：基于Ruby的web服务器，比如Thin和Ebb）仍然是Rails主要的部署环境，因为它的稳定，它的快速，以及它多样的功能。
多样选择前的困惑
但除了应用服务器，我们还需要进行很多其它的选择。在前端用什么web服务器？Apache，nginx还是lighttpd？使用web服务器内置的代理还是HAProxy或者Proud？在后面需要运行多少个Mongrel进程？使用Monit还是让上帝去监控进程？
在这些问题面前，我们有很多正确、可靠的答案。在37signals，之前好几年我们都使用Apache2.2+HAProxy+Monit+Mongrel的组合方式。其实当你决定使用哪些工具之后，部署已经不是问题了。
但太多可选的、看上去都正确的方案，反而让我们无从选择。当你完成了Rails应用程序的构建之后，我很能理解你的心情：你并不想成为一个了解各种web服务器，代理服务器，负载均衡以及进程监控工具的专家。
我觉得这就是这个迷思的主要根源--太多的选择。在怎样部署Rails上我们缺乏一个明确的答案，一个没有如果，没有但是，没有“这取决于”的答案。
当今年年初Phusion团队推出Passenger (也叫mod_rails)的时候，我高兴得有点忘乎所以了。这是一个免费的、开源的Apache模块，它使Rails的部署就像mod_php一样简单。
通过非常简单的步骤完成Passenger的安装之后，你就得到了一个有着web服务器、负载均衡、应用程序服务器以及进程监控所有这些功能的Apache。进入你的程序。然后touch一下tmp/restart.txt，它就启动了。就这么简单！
不知什么原因，Passenger并没有很快地流传开来。但现在已经有很多大型的网站运行于Passenger之上了，包括Shopify, MTV, Geni, Yammer等。我们马上就会把Ta-da List移到Passenger上，之后，希望37signals系列其它的应用也能都移过去。
虽然可能还有一些原因让我们不得不使用定制的、多层的、手工配置的部署环境--就像那些不能使用mod_php的特例一样，但我们终于找到了一个默认的正确答案。Passenger的“开箱即用”让我们无需在第一次部署Rails应用程序的时候犹豫不决了，即使是面对共享主机的情况。
总而言之，Rails的部署已经不再困难，Phusion Passenger让一切变得异常简单。
【本文翻译仅为外语学习及阅读目的，原文作者个人观点与译者及译言网无关】
