在数百台Linux计算机上对内核执行维护升级特别需要。 />
对于每个ELB / ALB步骤如下：
将ec2实例与ELB / ALB断开连接，等待连接耗尽
升级内核并重新引导计算机（不属于自动化，例如运行外部./upgrade.sh）
例如，等待在线，连接到ELB / ALB，等待运行状况检查状态，
继续到负载均衡器中的下一个实例。 br />注意：不是要迁移到类似于Netflix Spinnaker的解决方案或不可变的部署策略实施，而是要使用常规的简单维护工具。
#1 楼
AWS提供了专门的服务来处理这种类型的用例，即EC2 Systems Manager，它可以创建基本补丁集，然后检查它们是否适用于目标系统。
“补丁程序管理器是一项完全托管的服务（免费提供的
），可帮助您简化操作系统的补丁程序，包括定义补丁程序。您要批准部署，
补丁部署方法，补丁发布的时间以及确定整个
实例群中补丁遵从性状态的权限。对于某些实例，它是非常可配置的合理的默认值，
可以帮助您轻松地处理异构集群的补丁。”
-“ Amazon EC2 Systems Manager补丁管理器现在支持Linux”您需要在每个系统上安装SSM代理并添加一个角色，但除此之外，它应该不会引人注目
评论
看起来不错，但是此解决方案不包括在应用补丁程序时进行ELB / ALB断开/连接编排
–菱形
18年4月8日在4:33
针对您的问题的AWS解决方案是使用一个不变的解决方案：使用新内核构建AMI，然后使用ASG将它们循环出ALB，但我知道您不希望这样做！
–Vorsprung
18年4月8日在18:05
如果必须解决此问题，则不必担心在更新之前将它们轮换出来。除了增加IO之外，直到重新启动内核更新才会生效。您可以使用init.d（或upstart或systemd或任何其他脚本）在受控重新引导时从ALB组退出受控退出
–Vorsprung
18年4月8日在19:09
#2 楼
就像评论中的人所说的那样，您可以使用bash或python boto3库中的aws-cli来完成此操作。那么ansible呢？它具有查看ec2实例的能力，并且可以处理维护任务的自动化。如果您不使用Ansible，我强烈建议您将该工具添加到DevOps工具箱中。
您可以按照以下方式构造剧本来完成您想要的事情。
评论
您可以进行+1部署吗？因此，不是从ALB中删除实例，而是添加一个已经升级的实例？这将为您列出的两个等待状态节省大量时间。谢谢@MrDuk的建议，这就是所谓的“不可变的部署”，它目前需要更多的资源和协调才能在具有不同配置的数百台服务器上部署数十个不同的应用程序，理想情况下，这可以通过更好的部署自动化实现，但目前并非如此
如果每个节点都是不同的，并且每个节点都进行了自定义更改，那么我不知道存在可以帮助您解决此问题的工具。但是，您可以使用aws-cli相当容易地编写脚本，其中最复杂的部分是升级/重启/检测
@rombob我必须同意MrDuk。如果您的实例具有并行运行不同版本的能力，那么您应该能够使用不变的部署策略，而无需花费比您建议的步骤更多的精力。
@MrDuk同意，使用aws-cli或aws-sdk是有意义的，想知道是否存在除定制升级，平衡实例的顺序/并行遍历之外的现成解决方案，这是很常见的任务，因此我们开始编写自己的值得与社区核对