Auto Scaling Group 启动配置更改

Posted

技术标签:

【中文标题】Auto Scaling Group 启动配置更改【英文标题】:Auto Scaling Group launch config changes 【发布时间】:2013-10-13 15:30:22 【问题描述】:

我想知道是否有一种简单的方法或最佳实践来确保 AutoScaling 组中的所有实例都已使用该 AutoScaling 组的当前启动配置启动。

举个例子,假设一个名为 www-asg 的自动扩展组有 4 个所需的实例在 ELB 后面运行网络服务器。我想更改用于启动此自动扩展组实例的 AMI 或用户数据。所以我创建了一个新的启动配置www-cfg-v2 并更新www-asg 以使用它。

# create new launch config
as-create-launch-config www-cfg-v2 \
    --image-id 'ami-xxxxxxxx' --instance-type m1.small \
    --group web,asg-www --user-data "..."

# update my asg to use new config
as-update-auto-scaling-group www-asg --launch-configuration www-cfg-v2

到目前为止,所有 4 个正在运行的实例仍使用旧的启动配置。我想知道是否有一种简单的方法可以用新实例替换所有正在运行的实例来强制执行新配置,始终确保最少的实例保持运行。

我目前的实现方式如下..

    保存给定自动缩放组的当前运行实例列表 暂时增加所需实例的数量 +1 等待新实例可用

    通过终止列表中的一个实例

    as-terminate-instance-in-auto-scaling-group i-XXXX \
        --no-decrement-desired-capacity --force
    

    等待替换实例可用

    如果剩下 1 个以上的实例,则重复 4 个。

    通过

    从列表中终止最后一个实例
    as-terminate-instance-in-auto-scaling-group i-XXXX \
        --decrement-desired-capacity --force
    

    完成,所有实例现在应该使用相同的启动配置运行

我已经大部分自动化了这个过程,但我觉得必须有一些更好的方法来实现相同的目标。有人知道更好更有效的方法吗?

数学

在官方AWS EC2 Forum也发了这个问题。

【问题讨论】:

只是想知道,您是否找到了另一种方法?我所做的几乎与您上面描述的完全相同。 @CocoaNoob: 不......但我现在还没有改变启动配置安静的一段时间。但这是我为滚动更改编写的脚本:gist.github.com/muhqu/76264d73d42edbb75263 @muhqu 你找到了另一种方法吗? @froi 没有。仍然按照我写的那样做...... :-( 【参考方案1】:

我知道的老问题,但我想我会分享我的方法。

我更改 ASG 的启动配置,然后启动与 ASG 中当前相同数量的实例,当它们可用(自动测试)时,它们将附加到 ASG。添加机器后,我们的部署系统会更新 varnish 负载均衡器以使用新实例,而旧实例将被终止。

以上所有操作都是自动化的,根据启动时间的不同,完整的站点规模切换大约需要 5 分钟。

如果您想知道,我们使用 SNS 来处理在添加或删除实例时更新 varnish,或者在我们的负载均衡器扩展(几乎从未发生)的情况下,部署系统将改为更新我们的 route53 配置。

我认为几乎涵盖了所有内容

【讨论】:

所以您使用没有 ELB 的 ASG 并运行 varnish(在其自己的 EC2 实例上)以实现 HTTP 负载平衡?为什么不是 ELB? ..你必须自己做健康检查等,对吧? 没错,它是一个非常“特殊”的应用程序,有很多复杂的路由到 7ish 后端,具体取决于访问的内容。所以清漆处理健康检查和后端选择。对于我们的其他应用程序,我们使用 ELB,除了 SNS,使用相同的方法,服务器在准备好服务后手动添加到 ASG。【参考方案2】:

这并没有太大的不同,但你可以:

    创建新的信用证 使用新的 LC 创建新的 ASG 缩小旧的 ASG 删除旧的 asg 和 LC

我以这种方式进行部署,根据我的经验,从一个 ASG 滚动到另一个 ASG,而不必来回跳跃。但正如我所指出的,这并不是一个巨大的差异。

可能值得一看:https://github.com/Netflix/asgard,这是一个用于管理自动缩放组的 Netflix OSS 工具。我最终没有使用它,但它仍然很有趣。

【讨论】:

创建新 ASG 的一个缺点是您还必须重新创建任何扩展策略(例如触发扩展/缩减操作的警报)。 Netflix 使用 ASG 作为部署单元的方式是一种有趣的方法……但我认为我坚持使用固定数量的自动缩放组,并在发生变化时更改它们的启动配置。无论如何,谢谢你的回答! 是的,这很好。我不使用任何扩展策略,只有固定大小的 ASG,但如果您想动态扩展,这种方法会增加复杂性。

以上是关于Auto Scaling Group 启动配置更改的主要内容,如果未能解决你的问题,请参考以下文章

AWS Auto Scaling Group 具有定义的持续时间点实例和多种实例类型

在 java 中更改 Auto Scaling 组的 Desired Capacity

我应该如何配置 AWS Auto-Scaling Group mixed_instances 策略以仅允许具有多个 EC2 instance_types 的 Spot 实例?

AWS CDK 如何覆盖 Auto Scaling 组中的默认启动配置?

Auto Scaling 启动新实例时自动更新 Route 53

Auto Scaling Group 和 EFS 上具有动态标签的模块