为什么将 Ruby on Rails 部署到生产环境据说“很难”？答案

【问题标题】：Why is it supposedly "hard" to deploy Ruby on Rails to production?为什么将 Ruby on Rails 部署到生产环境据说“很难”？
【发布时间】：2009-06-18 16:36:33
【问题描述】：

我承认，在部署测试代码和生产代码方面，我没有遵循很多“正确”的做法。我一直在使用 ASP.NET，我通常在 Visual Studio 中本地运行它，它可以工作，我上传它，我在生产服务器上再次测试它。

我读过一些人说部署 Rails 应用程序更难，并且 ruby 网站上有关于部署 RoR 的特殊程序/方法。我只玩过RoR。部署有什么特别之处？您不只是复制和粘贴代码并运行它（从开发机器到生产）？是不是因为一个在 Apache 中，另一个在内置服务器上运行？

如果重要的话，这将在 Mac 服务器上。

【问题讨论】：

标签： ruby-on-rails deployment

【解决方案1】：

部署 RoR 不再困难，尤其是使用 Phusion Passenger。

有点困难的是，使用 capistrano、vlad 等进行自动化生产环境设置。如果您不介意简单地将代码复制到服务器，那么您可以做到这一点。大多数人选择不这样做，因为您失去了自动化部署工具为您带来的许多好处。

【讨论】：

我什至使用 capistrano 来设置一个新的 railsapp 来自动部署。所以我说“cap setup:fresh”，这将处理所有事情，比如设置一个 testurl，设置一个本地 gitrepository 和我的源服务器，进行初始提交，设置一个新的 vhost 等等......

【解决方案2】：

我猜人们认为 Rails 应用程序比说一些 PHP 应用程序更难部署，你只需将代码放在某个地方并指向 Apache 或其他任何东西。但是，如上所述，您现在可以使用 Phusion Passenger 做到这一点。

我们使用 Nginx+Passenger，但不是为了简化部署。 Capistrano 是我们选择的部署工具，实际上，除非你有一个非常简单的应用程序，否则无论如何你都会想要像 Capistrano 这样的东西。例如，在我们的部署中，我们做了很多事情：

运行任何数据库迁移
根据上次部署和本次部署之间对 Git 的所有提交自动生成发行说明
通过电子邮件通知不同的人（根据部署到我们的暂存环境还是生产环境，使用不同的列表） - 我们通过与 Capistrano 集成的 cap_gun 执行此操作。
通知 New Relic RPM 部署，以便它可以在我们的 RPM 分析中标记它
通知 Hoptoad 部署，因此在报告任何异常时它也可以拥有该数据
生成我们的 sitemap.xml 文件，然后 ping Google 告诉他们有一个新文件
更新 crontab 文件（我将每个服务器的 crontab 文件存储在我们的 git 存储库中，然后在部署时查看是否有新版本并进行相应更新等）。
刷新/重启 memcached

除了 Capistrano 之外还有其他方法，但它是一种经过验证的工具，具有很大的灵活性，而且设置普通配置非常简单。

所以，我的看法是，一旦您进入任何超越最简单应用程序的应用程序，您将需要/想要做一些事情，而不仅仅是简单地更新代码。不过，一开始，如果您只需要代码更新，可能还需要 Rails 迁移，那么您可以做一些简单的事情，例如乘客和代码同步，或者查看 Heroku 或 Engine Yard 之类的工具，他们通过执行 Git 克隆来进行部署（然后提供一些额外的能力）。

【讨论】：

【解决方案3】：

另一种超级简单的部署方式是使用http://heroku.com/

【讨论】：

heroku 很棒，我已经用了几个星期了，和它一起工作非常愉快
很抱歉投了反对票，但是每次我读到有关 Rails 部署的信息并且有人建议使用 heroku 时，我都会忍不住想“是的，heroku 是在 HEROKU 上部署的一种简单方法”。 heroku 是一种服务，而不是在 其他任何地方、vps、自己的服务器等部署应用程序的通用方式。

【解决方案4】：

将 Rails 部署到生产环境时遇到的一些问题：

数据库连接。您需要确保为生产环境设置了数据库连接器。
数据库迁移。您必须针对生产数据库运行数据库迁移，即使您可能已经在生产/测试/暂存中运行它们
Ruby 版本。版本或子版本或 Ruby 可能会让您失望，例如An error occurred while installing debugger-linecache (1.1.1), and Bundler cannot continue
宝石依赖。您的生产环境可能具有与开发不同的包和 gem。 Bundler 将在很大程度上解决这个问题并安装依赖项，但偶尔仍有问题需要您手动解决。
依赖关系。某些机器上的某些 gem 具有特定的依赖关系。我经常看到在我的适用于 OSX 的 unix box 上使用 gems 时遇到问题，反之亦然。

请注意，如果在同一台机器上，最后 3 个不应该影响您，但我根据标题将它们包括在内并且是全面的。

【讨论】：

我从未使用过它。这只是当时的炒作。随着时间的推移，它失去了人气，恕我直言，所以除了 RoR 之外，我再也找不到使用它的理由了。不一定喜欢 RoR 和约定优于配置（我认为那是 RoR）。谢谢。

【解决方案5】：

这不是特别难。如果您遵守约定，那么只需进行一些配置，就可以归结为：

cap deploy

...但是，有时需要预先付出一些努力才能使工作流程到位。

好消息是，很多人已经为 RoR 打包了解决方案和堆栈，您可以即插即用。例如，google ec2onrails - 这是一个打包的 Ubuntu 映像和一组 capistrano 任务，用于在 Amazon 的 EC2 云中运行 rails 应用程序，其中已经设置了许多开箱即用的常用东西。

选择一个好的托管服务提供商，你应该也能找到类似的东西。

【讨论】：

【解决方案6】：

部署 Rails 应用程序的一种简单方法是使用 Phusion Passenger。部署不会比任何编程语言或框架更容易。您可以在 Mac 服务器上执行此操作。

【讨论】：

【解决方案7】：

另一种部署 Rails 的简单方法是使用 jruby 和 glassfish gem。

【讨论】：