【问题标题】：How to ensure that the ASG ( Auto scaling Group) replaces existing instances with every change in the Launch configuration如何确保 ASG（Auto Scaling Group）在 Launch 配置中的每次更改都替换现有实例
【发布时间】：2020-08-03 04:31:29
【问题描述】：
基础设施使用 terraform 代码进行配置。
在我们的 AWS 环境中，我们为对存储库的每次提交创建了一个新的 AMI。现在，如果我们想使用这个新的 AMI 为 ALB 后面的 Web 服务器配置自动缩放
- 我们如何确保 ASG 用 Launch 配置中的每次更改替换现有实例，因为我相信，一旦您更改 LC，只有使用新 AMI 启动的扩展/扩展之外的实例并且现有的不会被替换。
另外，您是否知道我们如何以编程方式（通过 terraform）获取在任何时间点运行的服务器数量，以防自动缩放？
这里非常感谢任何帮助。
谢谢！
【问题讨论】：
标签：
terraform
aws-application-load-balancer
launch-configuration
aws-auto-scaling
【解决方案1】：
在大多数情况下，这非常简单，并且网络上已经有十几个实现。
棘手的部分是在 LC 和 ASG 上表达“create_before_destroy”字段。您还应该参考 ASG 资源中的 LC。这样一来，一旦您的 LC 发生更改，您将触发一个创建新 ASG 的工作流程，以替换您当前的。
Very Good Documented Example
另外，您是否知道我们如何以编程方式（通过
terraform) 获取在任何时间点运行的服务器数量，以防万一
自动缩放？
这取决于上下文。如果你有一个静态数字很容易，你可以在你的模块中定义它并坚持下去。如果它是关于传递先前的 ASG 值，那么上面的指南中将再次描述该方式:) 您需要编写一个自定义外部处理程序，以了解您在目标组周围有多少“瞬间”运行的实例。当然可能会有一个新的 AWS REST API 添加，让您有机会查询所有目标组健康检查属性并获得它们的总和（不知道）。再说一次，您可以为扩展策略添加一些自定义规则。
External Handler
旁注：在示例中，部署是使用 ELB 进行的。