我可以协调多个服务器上Chef的部署资源的回滚吗?

时间:2013-01-08 14:28:51

标签: ruby-on-rails chef continuous-deployment

我正从Capistrano转到Chef来部署一个Rails应用程序(deploy_revision),我不清楚最佳实践(或常见做法)问题。我没有通过谷歌搜索找到太多。

使用Capistrano和“推送”模型,在跨多个服务器部署应用程序时,可以直接识别何时出现部署故障并立即在所有服务器上回滚部署。 Capistrano还在每个应用服务器上建立一个维护页面,然后不会删除该维护页面,除非我已成功部署到所有服务器或回滚部署。

使用Chef和“pull”模型,每个服务器可能会在稍微不同的时间获取其更新。我可能最终会使数据库服务器更新应用程序代码并比应用程序服务器提前几分钟运行数据库迁移。所以我真的没有很好的方法来识别故障并确保构建回滚到上一个成功部署的版本(在所有服务器上)。

我知道我有一些选择:

  1. 不要守护厨师 - 客户。用cron每晚或每小时运行一次。 (如果有些成功,只有一个遇到问题,我仍无法回滚所有服务器。)
  2. 不要守护厨师 - 客户。不要使用deploy_revision。通过knife sshcapistrano-chef运行。 (我现在回到“推”模式,而不是“拉”模型,这是厨师的吸引力的一部分。)
  3. Daemonize chef-client并编写彼此交谈的自定义食谱。 (不热心。)
  4. 放松。别担心。让错误发生然后修复它们。 (这里也没有激动。)
  5. 我可以开始构建其中任何一个,但在我投入大量时间进行构建之前,我希望了解在该领域进行大规模部署的有效方法。你做了什么?

2 个答案:

答案 0 :(得分:3)

Pull适合解决configuration drift的问题。对于按需部署(以及潜在的回滚),推送更好。检查这些(我没有使用过它们):

https://github.com/etsy/deployinator

http://www.rackspace.com/blog/rackspace-open-sources-dreadnot/

答案 1 :(得分:1)

我已经通过chef的deploy_revision策略部署了ROR应用程序并取得了一些成功。克服拉策略的时序控制限制最简单的方法是编写一个可归结为以下内容的部署脚本:

  • 停止chef-client(确保守护程序不处理内容)
  • 手动运行chef-client(这也将重启守护进程)

或者如果你很懒,只需运行chef-client并且不要担心守护进程。

然后使用knife-ssh在适用的节点上执行这些命令。最终结果是您拥有由chef管理的所有与部署相关的配置,但您可以根据需要启动部署。

对于奖励积分,将所有这些包装在Jenkins任务中。您需要将jenks配置为Chef客户端,并在应用程序项目中进行“Deploy to Staging”任务。现在,您可以单击以执行任务,并且您的非厨师讲话的队友可以轻松地进行部署。要获得更多奖励积分,请在成功构建后设置jenkins自动部署!