更新自动缩放组AMI并运行实例

Question

我正在尝试为项目设置以下内容

• 弹性负载均衡器后面的自动缩放组中的EC2实例
• 将我的应用程序的新版本部署到EC2实例的CodeDeploy应用程序

我对EC2实例所基于的AMI有疑问。如果我想对系统进行一些更改＆＃39;配置（比如更新 libssl 包），我看到两个选项：

• （1）运行打包程序/手动创建新的AMI并设置我的自动缩放组以使用它。然后，重新启动实例，以便它们使用新的AMI。这显然非常慢，导致停机。
• （2）使用Ansible之类的配置管理工具在实例上运行 yum update libssl ，但这不会保留对将来启动的实例的更改
• （3）创建一个新的AMI（手动或使用打包器）和然后使用配置管理工具关闭旧实例并使用新的AMI运行新实例。这是我认为最好的选项，但我不确定如何详细说明，也不知道如何避免停机。此外，它将保持相当慢（我估计~10分钟）

最好的方法是什么（避免停机）？我应该坚持一些最佳实践吗？

由于

[编辑] 我来自aws-missing-tools的aws-ha-release，它可以从自动缩放组重启所有实例而不会出现任何停机。我想这可以与packer一起使用来强制运行实例使用新的AMI。对此有何反馈？我觉得它有点像hacky。

Answer 1

以下是一些选项：

1使用两个自动缩放组

如果您在部署新代码时试图阻止停机，请利用 ELB可以有多个自动缩放组/启动配置这一事实。

你可以：

• autoscale-A，launchconfig -A ，它们是自动缩放组并启动 您的版本配置＆＃34; A＆＃34;你的服务器
• autoscale-B，launchconfig-B ，它们是自动缩放组并启动配置 你的verison＆＃34; B＆＃34;你的服务器。

表示代码的版本X ， B 表示版本X + 1 （包括任何更改） O / S配置，例如 libssl ）

现在，当你想推出代码版本X + 1时，简单的＆＃34;烘烤＆＃34;一个新的AMI，准确配置你喜欢它，并将自动缩放组B添加到elb。自动缩放组及其实例投入使用后，将自动缩放组A的最大/容量设置为0，将版本X服务器从ELB中取出。只运行您的X + 1版本。当新的实例在未来出现时，例如如果服务器出现故障，他们将使用您的X + 1 AMI并进行所有配置更改。

请注意，如果您的应用程序与数据库通信，则需要确保代码的版本X和版本X + 1可以在相同版本的数据库上运行，例如如果版本X + 1删除了版本X使用的表格，那么您将从用户点击您的应用程序的Verison X时收到错误。当您的代码版本中没有数据库更改，或者当您推出新版本的代码时，如果您具有向后兼容性，则＃1可以正常工作。

2将配置管理工具与健康检查相结合

如果你想做的就是更新O / S，例如修补一个版本，然后你可以结合使用像Ansible这样的工具和ELB健康检查的想法。

• 如果要修补服务器，请扩展实例数 暂时的如果您运行3个实例，则扩展到6个。
• 作为用户数据的一部分，运行Ansible，只运行一次 成功完成，例如更新libssl，你是否允许健康 检查通过和EC2实例为ELB的流量提供服务。
• ELB成功查看新的EC2实例后，缩小范围 自动缩放组中的实例数量为其原始容量（在本例中为3）。
• 注意：最老的 实例将是AWS终止的实例，这意味着将继续运行的唯一实例是您的3个新实例。
• 如果实例失败并且新实例失效，它将从您的基础AMI开始，应用任何Ansible更改（只有在存在更改时，健康检查才会通过并且将其投入使用）。
• （这是您的（2）但修复了不包含libssl版本更改的新实例的问题）

关于速度的说明

• 选项1 将允许失败的实例在服务中比选项2更快（因为您没有等待Ansible运行），代价是不得不预先执行烤＆＃34;你的AMI。

• 选项2 将为您提供更大的灵活性和速度来修补生产服务器，例如如果您需要修补现在＆＃34;这可能是最快捷的方式。有一些像Ansible运行的东西和修补O / S（将该任务与部署代码任务分开）的能力可以带来额外的优势，具体取决于您的用例。在服务器的配置（库，用户管理等）中提供无代理挂钩非常强大，尤其是在云中。

Answer 2

为什么不评估使用启动配置的userdata字段？

总而言之，它是16 KB的纯爱，内置于您生产新机器的食谱中。

如果使用Linux，则使用Bash脚本，如果是WIndows，则可以使用Powershell。

没有其他工具，所有工具都是免费的。

P.S。如果您需要超过16 KB，只需在核心脚本中链接其他脚本的wget，然后通过创建链来对其进行shell。