AWS ECS 503 服务在部署时暂时不可用

Question

我正在为我的应用程序使用带有应用程序负载均衡器的 Amazon Web Services EC2 容器服务。当我部署一个新版本时，我得到 503 Service Temporarily Unavailable 大约 2 分钟。它比我的应用程序的启动时间多一点。 这意味着我现在无法进行零停机部署。

是否有设置在启动时不使用新任务？或者我在这里错过了什么？

更新：

ALB 目标组的健康检查号如下：

Healthy threshold:     5
Unhealthy threshold:   2
Timeout:               5 seconds
Interval:              30 seconds
Success codes:         200 OK

健康阈值是“在考虑不健康目标健康之前需要连续成功的健康检查次数”
不健康阈值是“连续健康检查失败的次数在考虑目标不健康之前需要。'
超时是“没有响应意味着健康检查失败的时间量，以秒为单位。”
间隔 是“单个目标的健康检查之间的大致时间量”

更新 2： 因此，我的集群由两个 EC2 实例组成，但可以根据需要进行扩展。所需的最小计数是 2。我每个实例运行一个任务，因为我的应用程序需要一个特定的端口号。在我部署（jenkins 运行 aws cli 脚本）之前，我将实例数设置为 4。没有这个，AWS 无法部署我的新任务（这是另一个需要解决的问题）。网络模式为桥接。

Answer 1

因此，问题似乎在于任务定义中容器设置的端口映射。 在我使用 80 作为主机和 8080 作为容器端口之前。我以为我需要使用这些，但主机端口实际上可以是任何值。如果将其设置为 0，则 ECS 将分配一个 32768-61000 范围内的端口，因此可以将多个任务添加到一个实例。为了使其工作，我还需要更改我的安全组，让流量来自 ALB 到这些端口上的实例。
因此，当 ECS 可以在同一个实例上运行多个任务时，50/200 最小/最大健康百分比是有意义的，并且可以在不需要添加新实例的情况下部署新的任务修订。这也确保了零停机部署。

感谢所有提问或评论的人！

Answer 2

由于您使用的是 AWS ECS，请问服务的“最低健康百分比”和“最高健康百分比”是多少

确保您的“最大运行状况百分比”为 200，“最小运行状况百分比”为 50，以便在部署期间不会出现所有服务都停止运行的情况。

请查找这两个术语的文档定义：

最大百分比提供了部署期间正在运行的任务数量的上限，使您能够定义部署批量大小。

最低健康百分比提供了在部署期间运行任务数量的较低限制，使您能够在不使用额外集群容量的情况下进行部署。

“最低健康百分比”的限制为 50 将确保在部署新版本的容器之前只有一半的服务容器被杀死，即如果服务的所需任务值为“2”而不是部署时只有“1”个旧版本的容器将首先被杀死，一旦部署了新版本，第二个旧容器将被杀死并部署一个新版本的容器。这将确保在任何给定时间都有处理请求的服务。

类似地，“最大健康百分比”的限制为 200，告诉 ecs-agent 在部署期间的给定时间，服务的容器最多可以达到所需任务的两倍。

如有任何其他问题，请告诉我。

Answer 3

根据您的设置，您的应用程序启动应该需要超过 30 秒才能通过 2 次运行状况检查并被标记为不正常（假设在您的应用程序关闭后立即进行第一次检查）。并且至少需要 2 分钟到 3 分钟，然后才能再次标记为健康（在最好的情况下，在您的应用重新上线后立即检查，或者在最坏的情况下，在您的应用重新上线之前立即检查）。

因此，一个快速而肮脏的修复方法是增加不健康阈值，以便在更新期间不会将其标记为不健康。并且可能会降低健康阈值，以便更快地再次标记为健康。

但是，如果您真的想实现零停机，那么您应该使用您的应用程序的多个实例，并告诉 AWS 按照 Manish Joshi 的建议进行部署（以便在您的 ELB 后面始终有足够的健康实例来保持您的站点正常运行)。

Answer 4

我解决这个问题的方法是在应用程序根目录中有一个平面文件，ALB 将监控它以保持健康。在部署之前，脚本将在监视节点的同时删除此文件，直到它注册OutOfService。

这样所有实时连接都会停止并耗尽。此时，通过停止节点或应用程序进程开始部署。部署后，通过添加回此平面文件并将节点添加回 LB 并进行监控，直到它为此节点注册 Inservice，然后再移动到第二个节点以完成上述相同步骤。

我的脚本如下所示

# Remove Health Check target
echo -e "\nDisabling the ELB Health Check target and waiting for OutOfService\n"
rm -f /home/$USER/$MYAPP/server/public/alive.html

# Loop until the Instance is Out Of Service
while true
do
        RESULT=$(aws elb describe-instance-health --load-balancer-name $ELB --region $REGION --instances $AMAZONID)
        if echo $RESULT | grep -qi OutOfService ; then
                echo "Instance is Deattached"
                break
        fi
        echo -n ". "
        sleep $INTERVAL
done

Answer 5

你说的是 Jenkins，所以我会在回答时考虑到 Jenkins master 服务，但我的回答对于任何其他情况仍然有效（即使它不是ECS 的一个很好的例子，一个 Jenkins master 不能正确扩展，所以只能有一个实例）。

503 网关错误

我经常遇到与负载均衡器未能通过健康检查（无健康实例）相关的503 网关错误。查看您的负载均衡器监控选项卡，确保健康主机的数量始终高于 0。

如果您正在执行 HTTP 健康检查，它必须返回一个 代码 200（有效代码列表可在负载均衡器设置中配置）仅当您的服务器真的启动并运行。否则负载均衡器可能会处理尚未完全运行的实例。

如果问题是您总是收到 503 bad gateway，可能是因为您的实例响应时间过长（在服务初始化时），所以 ECS 将它们视为已关闭并在其初始化完成之前关闭它们。 Jenkins 第一次运行时经常出现这种情况。

为避免最后一个问题，您可以考虑调整负载均衡器ping 目标（健康检查目标适用于经典负载均衡器，监听器应用程序负载均衡器）：

• 使用应用程序负载平衡器，尝试使用总是返回 200 的东西（例如，对于 Jenkins，它可能是像 /robots.txt 这样的公共文件）。
• 对于经典负载平衡器，使用TCP 端口测试 而不是HTTP 测试。如果您正确打开了端口，它将始终成功。

每个实例一个节点

如果您需要确保每个实例只有一个节点，您可以使用经典负载均衡器（它也适用于 ECS）。借助经典负载均衡器，ECS 可确保每台服务器仅运行一个实例。 这也是让非 HTTP 端口可访问的唯一解决方案（例如，Jenkins 需要 80 个，但从属服务器也需要 50000 个）。

但是，由于经典负载均衡器的端口不是动态的，因此您必须进行一些端口映射，例如：

myloadbalancer.mydomain.com:80（负载均衡器的端口 80）-> instance:8081（容器的外部端口）-> service:80（容器的内部端口）。

当然，每个服务都需要一个负载均衡器。

Jenkins 健康检查

如果这确实是您想要启动的 Jenkins 服务，您应该使用 Jenkins Metrics 插件 来获得一个好的 healthcheck URL。

安装它，并在全局选项中，生成一个令牌并激活 ping，您应该能够访问如下所示的 URL：http://myjenkins.domain.com/metrics/mytoken12b3ad1/ping

只有在服务器完全运行时，此 URL 才会回答 HTTP 代码 200，这对于负载均衡器只有在完全准备好时才激活它很重要。

日志

最后，如果您想知道您的实例发生了什么以及它失败的原因，您可以添加日志以查看容器在 AWS Cloudwatch 中所说的内容。

只需在任务定义中添加这个（容器配置）：

日志配置： awslogs
awslogs-group： mycompany （将重新组合您的容器日志的 Cloudwatch 密钥）
awslogs-region： us-east-1 （您的集群区域）
awslogs-stream-prefix： myservice （a创建日志名称的前缀）

它会让您更深入地了解容器初始化过程中发生的事情，如果它花费的时间太长或者它是否失败。

希望对你有帮助！！！