在 RailsConf 2007 开幕前夕， ThoughtWorks Studios 发布了 RubyWorks 0.0.1 版本。在其网站上这样介绍这个开源项目：
RubyWorks 是一个 Rails 生产部署环境，它由一组开源软件共同组成，提供了在 RedHat 企业版 Linux 或者 CentOS 服务器上部署 Ruby on Rails 应用程序所需的软件和配置支持。只要将服务器的包管理器（up2date 或者 yum）指向 RubyWorks 发行库，再安装 RubyWorks 提供的软件包，就可以立即获得已经预先配置好的 Rails 部署环境。到目前为止，这是最接近于“一步到位”的 Rails 生产部署环境。
Rails 应用在生产部署环境下的各方面能力（性能、伸缩性、可靠性、可管理性，等等）一直是人们怀疑“Rails 是否能够进入企业应用”的重要原因。经过实践检验，由 HAProxy 、 Monit 、 Mongrel 共同构成的部署环境已经具备了足够强大的能力。但这些软件的配置并不是一件易如反掌的事。
RubyWorks 的出现正是为了解决这个问题：遵循 Rails 社群一贯的“约定俗成优于配置（Convertion-over-Configuration）”的传统，RubyWorks 提供了一个缺省配置好的 Rails 部署环境。缺省配置会在服务器上开启 4 个 Mongrel 进程，分别占用 3002~3005 端口；并用 HAProxy（使用 3001 端口）进行负载均衡。
在《 Agile Web Development with Rails 》的第一版中所推荐的部署方案是基于 FastCGI 的，而第二版则改为推荐基于反向代理的部署方案。James Duncan Davidson 在书中写道：
但 FastCGI 也有很多问题。FastCGI 诞生于 1990 年代中期，但在 Rails 出现之前，它一直默默无闻。即便在被 Rails 重新带回公众视野之后，产品级的、高质量的 FastCGI 环境仍然寥寥无几。很多开发者（包括我们自己）都尝试过各种 Web 服务器与 FastCGI 的组合，并在每种组合中都发现了严重的问题。当然还是有些开发者在 FastCGI 上完成了部署，也没有遇到什么问题，但有那么多人遇到那么多问题，这本身就足以说明：FastCGI 不是一个值得推荐的解决方案。[……]
简而言之，FastCGI 确实是一枚火箭，但有时会因为各种奇怪的原因而爆炸在发射台上。使用代理让 Rails 应用直接与 HTTP 对话，这是整个社群的发展方向。
RubyWorks 项目领导人 Alexey Verkhovsky 也认为，只有在对“节约内存使用”非常重视的情况下（例如虚拟共享主机），FastCGI 才有其价值；而在普通的企业应用中，可靠性和可管理性重于节约内存，这也是 RubyWorks 选择基于反向代理和 Mongrel 的部署方案的原因。
RubyWorks 还计划于近期推出对 Ubuntu 和 Debian 服务器的支持。
评论