ECS服务任务替换优化：如何实现先启健康新任务再终止旧任务？

可以实现你想要的零停机替换顺序，但当前通过健康检查失败触发替换的方式行不通，得调整触发逻辑，利用ECS的滚动更新机制：

为什么当前方式会导致停机 #

ECS对不健康任务的处理逻辑是：一旦任务被标记为不健康，就会被排除在「健康实例计数」之外。你的服务配置了Min healthy percent=100%，ECS会优先终止已无法提供服务的不健康任务，再启动新任务补全健康实例数量，这就造成了停机窗口。

实现期望顺序的具体方案 #

1. 替换触发任务更新的方式 #

不要再让旧任务主动失败健康检查，改用以下两种方式之一触发更新：

• 修改任务定义触发更新：当内部检测到新配置时，更新任务定义（比如新增/修改一个无关环境变量，例如CONFIG_VERSION，值设为新配置的版本号），然后更新ECS服务使用这个新的任务定义。
• API触发更新：让旧任务在检测到新配置后，调用ECS的UpdateService API，指定使用包含新配置的任务定义来触发服务更新。

2. 利用现有服务配置实现滚动更新 #

你已经配置了Min healthy percent=100%和Max healthy percent=200%，这正好符合滚动更新的要求：

• Min healthy percent=100%：保证更新过程中健康实例数不会低于原有数量，避免服务能力下降。
• Max healthy percent=200%：允许ECS先启动最多一倍的新任务，等新任务健康后再终止旧任务。

这样ECS会严格按照你期望的顺序执行：

1. 服务收到更新指令后，启动新任务
2. 等待新任务通过健康检查（包含startPeriod=20秒的启动等待期，以及连续通过指定次数的健康检查）
3. 确认新任务健康后，终止旧任务

3. 保留内部检测逻辑的兼容方案 #

如果必须保留旧任务检测新配置的逻辑，可以让旧任务在检测到新配置后，不触发健康检查失败，而是调用ECS API触发服务更新，之后旧任务继续正常提供服务，直到ECS自动将其终止。

关于健康检查配置 #

你当前的容器健康检查配置是合理的，无需调整，只要配合上述滚动更新触发方式，就能实现零停机替换。

内容的提问来源于stack exchange，提问作者Paul Grimshaw