小编Eri*_*son的帖子

我有一个为 SSH 进程提供服务的 ECS 服务。我正在通过 CodeDeploy 部署对此服务的更新。我注意到，与使用 CodePipeline 同时部署相同映像的其他服务相比，该服务的部署速度要慢得多。此服务的不同之处在于它位于 NLB 后面（其他服务没有 LB 或位于 ALB 后面）。

该服务设置为 1 个容器，部署 200%/100%，因此服务会启动 1 个新容器，确保其正常运行，然后删除旧容器。我看到发生的是：

1. Initial新容器在状态中启动
2. 3+分钟后，New Container 变为Healthy. 旧集装箱进入Draining
3. 2+分钟后，旧容器完成Draining并停止

因此，部署需要 5-7 分钟，主要是等待运行状况检查或耗尽。不过，我非常确定 SSH 启动得非常快，并且我对目标组进行了以下设置，这应该会使事情相对较快：

• 对正确端口进行 TCP 健康检查
• 健康/不健康阈值：2
• 间隔：10秒
• 注销延迟：10s
• ECS Docker 停止自定义超时：65s

因此，从 SSH 启动到旧容器终止的最短时间为：

• TCP健康检查转为Healthy需要2*10=20s
• Docker 停止前注销延迟 10 秒
• Docker 停止超时 65 秒

这是 115 秒，比观察到的 5-7 分钟要短得多。其他服务需要 1-3 分钟，而 LB/Target Group 的时间安排则没有那么严格。

有什么想法为什么我的 NLB 背后的服务在这些生命周期转换中循环似乎很慢吗？