在 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 服务器的支持。
评论