amazon-web-services - AWS 自动使用新的 AMI 更新自动扩展组？

Question

这是我在 AWS 中拥有的内容:

• 应用ELB
• Auto Scaling 组在不同区域有 2 个实例(Windows IIS 服务器)
• 启动指向 AMI_A 的配置
• 配置所有关联的后端内容(VPC、子网、安全组等)

一切正常。但是，当我需要更新或更改服务器时，我当前正在手动创建一个新的 AMI_B，使用 AMI_B 创建一个新的 LaunchConfig，更新 AutoScalingGroup 以使用新的 LaunchConfig，将实例的最小数量增加到 4，等待让它们变得可用，然后将数量减少回 2 以杀死旧实例。

我真的很想自动化这个过程。 Amazon 给了我一些 CLI 内容的链接，我能够编写 AMI 创建脚本、创建 LaunchConfig 并更新 AutoScalingGroup...但我没有看到一种简单的方法来编写启动新实例的脚本。

经过一番搜索，我发现了一些 CloudFormation 模板，看起来它们可以做我想要的事情，但大多数都做更多的事情，这让我有点困惑。

我应该探索 CloudFormation 吗？有没有一个简单的指南可以让我开始使用？或者我应该继续使用我已经开始的脚本吗？

PS - 抱歉，如果这是一个重复的问题。 AWS 的情况经常发生变化，因此有时旧的响应可能不是当前的最佳答案。

Answer 1

您可以使用多种选项来自动执行将 Auto Scaling 组中的实例更新为新的或更新的启动配置的过程:

云形成

如果您确实想要使用 CloudFormation 管理 Auto Scaling 组实例的更新，请参阅 UpdatePolicy AWS::AutoScaling::AutoScalingGroup 的属性文档资源和 "What are some recommended best practices for performing Auto Scaling group rolling updates?" AWS 知识中心页面以获取更多建议。

如果您还想在 CloudFormation 资源中编写 AMI 的创建/更新脚本，请参阅我对问题的回答“Create AMI image as part of a cloudformation stack”。

但请注意，CloudFormation 不是一个简单的工具 - 它是一个复杂的、相对较低级别的服务，用于编排 AWS 资源，并且由于其陡峭的学习曲线，将现有脚本迁移到它可能需要一些时间投资。

Elastic Beanstalk

如果简单性最重要，那么我建议您评估 Elastic Beanstalk ，它也支持 rolling和 immutable在部署期间在更全面管理、面向控制台的平台即服务环境中进行更新。引用我对问题的回答，"What is the difference between Elastic Beanstalk and CloudFormation for a .NET project?"了解 CloudFormation 和 Elastic Beanstalk 之间的进一步比较。

代码部署

如果您需要一个用于更新自动扩展组中实例的解决方案，并且可以将其插入到现有脚本中，AWS CodeDeploy可能值得研究。您在实例上安装代理，然后通过 API/CLI/控制台触发部署，它管理将应用程序更新部署到您的实例队列。请参阅Deploy an Application to an Auto Scaling Group Using AWS CodeDeploy以获得完整的教程。虽然 CodeDeploy 支持“就地”部署和“蓝绿”部署(有关详细信息，请参阅 Working With Deployments)，但我认为该服务采用了一种将 S3 托管的应用程序包交换到静态基础 AMI 上的方法，而不是替换 AMI 上的 AMI。每次部署。因此，它可能不是最适合您的 AMI 交换用例，但无论如何也许值得研究。