使用 Auto Scaling Groups、CloudFormation 和 CodeDeploy 的蓝/绿部署

use*_*152 5 amazon-web-services aws-cloudformation autoscaling aws-code-deploy

我尝试通过复制 AutoScalingGroup 来设置蓝/绿部署,但是这会使 CloudFormation 堆栈与其原始资源分离,因为 CodeDeploy 创建新副本并删除原始资源。我从另一篇文章 ( https://forums.aws.amazon.com/thread.jspa?messageID=861085 ) 中了解到 AWS 正在为此开发改进,但是现在我正在尝试以下解决方法。任何想法都会非常有帮助。

CloudFormation 创建以下内容:

  • 弹性负载均衡器
  • 目标组
  • AutoScalingGroup 一(带有 LaunchConfiguration)
  • AutoScalingGroup 2(与 1 相同,但没有实例)
  • 部署组(使用就地部署样式)将修订部署到 AutoScalingGroup One

CloudFormation 完成后,我在控制台中手动执行以下操作:

  1. 我将创建的部署组更新为部署样式蓝/绿,并将其原始环境设置为 AutoScalingGroup One。
  2. 我将一个实例添加到 AutoScalingGroup 二
  3. 我在 CodeDeploy 中创建了一个部署。但是,这不起作用,因为当新实例附加到 AutoScalingGroup Two 时,它会立即添加到 TargetGroup 并且不会通过运行状况检查。

关于如何使用 CloudFormation 实施一组资源以简化蓝绿色部署的任何想法,即单击 CodeDeploy 并且 CloudFormation 资源仍然保持不变?

小智 1

关于您描述的最初问题,您是否尝试过健康检查宽限期?这应该可以防止您所描述的当实例到达目标组时运行状况检查失败的问题。

另一种方法(其自身有很多缺点)是调整 CloudFormation 模板,以补偿 CodeDeploy 替换蓝绿部署中的 ASG 时的行为。

  1. 在 ASG 模板中,创建一个名为“ManageAutoScalingGroup”的“是/否”参数。在此参数值为“yes”时有条件创建ASG。在retain的ASG上设置删除策略,以便当参数更改为“no”时CloudFormation将保留该组。
  2. 在此参数上使用默认值“yes”来启动该组。
  3. 一旦实例运行正常,并且 CodeDeploy 已完成初始就地部署,您可以将 DeploymentGroup 更改为使用蓝绿,其中 CodeDeploy 将替换您的 ASG。
  4. 请务必更新 ASG 并将 ManageAutoScalingGroup 更改为“no”。CloudFormation 将从堆栈中删除引用,但会将资源保留在原处。

这将为您提供通过 CodeDeploy 所需的一键部署,但请注意,它会带来一些成本:

  • CodeDeploy 不会复制 Auto Scaling 组的 TargetGroup 参数(如https://forums.aws.amazon.com/thread.jspa?threadID=249406&tstart=0中其他人所述)中其他人所述)。您应该能够巧妙地使用 CloudWatch 事件规则和 SSM 自动化来解决此问题,以便在 ALB 更改其状态时将实例标记为不正常。
  • CodeDeploy 生成的副本似乎相当不可靠。至少有一次,我看到我的 LaunchTemplate 版本重置为不正确的值。我还遇到过这样的情况:部署组丢失了它应该跟踪的 ASG。
  • 继续将模板中的更改应用到 ASG 很麻烦。“刷新”组的过程是: 1) 恢复前面描述的参数,以便 CloudFormation 将生成一个新组。2) 修改部署组,以该组为目标,完成就地部署。3) 修改部署组以恢复蓝绿部署并相应更新您的堆栈。

我对这个部门的 CodeDeploy 印象不太深刻。我很乐意看到它们以与 ASG 相同的方式工作,ASG 将在应用新的 LaunchTemplate 版本时替换自身。如果您感觉有点雄心勃勃,您可以通过利用带有 ASG 实例生命周期挂钩的 Step Functions 来模仿此行为。这是我有时间时正在考虑的解决方案。

  • 感谢您的回复。我们最终放弃了蓝绿部署,转而使用通过 cloudformation 进行更新的就地部署。当AWS改进代码部署和云信息的集成时,我们可能会重新考虑蓝绿部署 (2认同)