Web 应用程序的多阶段部署的一些最佳实践和一般理论是什么?
我对使用 Git、Capistrano 和Passenger 部署Rails 应用程序特别感兴趣,并且我发现一些帖子讨论了该过程的具体细节:
对于每个阶段(测试、分期、生产),我应该考虑哪些因素?阶段是否应该部署到不同的物理服务器?关于多阶段部署的任何提示或建议?有什么我应该注意的障碍吗?
最好的,
雅各布
Web 应用程序的多阶段部署的一些最佳实践和一般理论是什么?
我对使用 Git、Capistrano 和Passenger 部署Rails 应用程序特别感兴趣,并且我发现一些帖子讨论了该过程的具体细节:
对于每个阶段(测试、分期、生产),我应该考虑哪些因素?阶段是否应该部署到不同的物理服务器?关于多阶段部署的任何提示或建议?有什么我应该注意的障碍吗?
最好的,
雅各布
我总是为每个部署目标创建上限任务并在命令行上使用它们:
# deploy.rb
task :stage do
server 10.0.0.1 ...
end
> cap stage deploy
您还可以在每个目标任务中定义自定义任务,例如在暂存中进行清理但在生产中不进行清理的部署。
由于这些部署目标任务很少非常大,我从来没有真正看到像为多阶段安装上限扩展这样的事情,但我想其他的情况可能会有所不同。
我确实认为生产应该与您的其他环境分开,否则会有危险,分期等过程中的不当行为可能会影响生产性能。
有时我定义上限任务是为了方便暂存,例如爆破数据库并从最近的生产转储中重新加载它。这些任务应通过设置变量等检查其部署目标,并拒绝运行生产以防止深夜打字错误。
在您的 deploy.rb 中放置大量自定义行为是很诱人的,但我发现随着您的环境或 cap api 的变化,这往往会反击并且需要大量的维护工作。
我在大型环境中看到的另一种做法是拥有一个带有结帐的 shell 帐户,该帐户跟踪专门设置为充当 capistrano 控制点的稳定分支。你 ssh 在那里而不是在本地运行 cap 命令。这可以帮助避免本地结帐的 deploy.rb 有您尚未准备好用于部署到生产的修改的问题。这对于 git 和 svn 来说不是什么问题,但是在他们运行 cap 命令的那一刻,仍然必须仔细考虑他们的本地 deploy.rb 是什么。
如今,Heroku 确实让这些事情变得简单,而 EY 和其他公司也不甘落后。
最好有两个不同的服务器环境:登台和生产。我总是忽略测试环境。测试环境类似于生产环境,但完成后回滚数据库。在同一台服务器上运行两者可能会对生产环境的性能和稳定性产生负面影响。升级 gem 以在暂存环境中进行测试可能会对生产产生负面影响并导致停机。
您必须非常警惕两台服务器上的 gem 版本相同。如果一个应用程序的版本在暂存中工作但由于这种差异而不能在生产中使用,这可能会带来麻烦。
我总是会打开一个控制台窗口,准备回滚上次部署,以防出现问题。这个过程真的没有比这更多的了。
为自己节省一些钱并购买最便宜的登台服务器。你是唯一会使用它的人,对吧?只需确保它们来自同一提供商即可。
一年多来,我们一直非常成功地使用 capistrano 多级部署。系统以与 Rails 环境文件几乎相同的方式很好地分离了每个阶段的部署文件。设置和管理非常容易。