【问题标题】:Can I coordinate rollback of Chef's deploy resource across multiple servers?我可以跨多个服务器协调 Chef 部署资源的回滚吗?
【发布时间】:2012-12-22 10:23:11
【问题描述】:

我正在从 Capistrano 转到 Chef 以部署 Rails 应用程序(使用deploy_revision),我不清楚最佳实践(或常见实践)的问题。通过谷歌搜索,我没有找到太多东西。

借助 Capistrano 和“推送”模型,在跨多个服务器部署应用程序时,可以直接识别部署失败的时间并立即在所有服务器上回滚部署。 Capistrano 还在每个应用服务器上建立了一个维护页面,然后不会关闭该维护页面,除非我已成功部署到所有服务器或回滚了部署。

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

我知道我在这里有一些选择:

  1. 不要守护厨师客户端。使用 cron 每晚或每小时运行一次。 (如果有些服务器成功但只有一个遇到问题,我仍然无法在所有服务器上回滚。)
  2. 不要守护厨师客户端。不要使用 deploy_revision。通过knife sshcapistrano-chef 运行它。 (我现在回到“推”模型而不是“拉”模型,这是 Chef 吸引力的一部分。)
  3. 守护主厨客户端并编写相互对话的自定义食谱。 (对此不感兴趣。)
  4. 放松。别担心。让错误发生,然后修复它们。 (这里也不激动。)

我可以开始构建其中的任何一个,但在我投入大量时间构建之前,我希望了解在该领域进行大型部署的有效方法。你做了什么?

【问题讨论】:

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


    【解决方案1】:

    Pull 适合解决configuration drift 的问题。对于按需部署(和潜在的回滚),推送更好。看看这些(我没用过):

    https://github.com/etsy/deployinator

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

    【讨论】:

      【解决方案2】:

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

      • 停止 chef-client(以确保守护程序不处理任何事情)
      • 手动运行 chef-client(这也会重新启动守护进程)

      或者,如果您很懒惰,只需运行 chef-client 而不必担心守护程序。

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

      对于奖励积分,将所有这些打包在 Jenkins 任务中。您需要将 jenks 配置为 Chef 客户端,并在您的应用项目中执行“部署到暂存”任务。现在您可以单击运行任务,您的不会说厨师的队​​友也可以轻松地进行部署。要获得更多奖励积分,请设置 jenkins 以在成功构建后自动部署!

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-02-26
        • 2019-06-26
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多