gsa*_*gsa 9 amazon-web-services amazon-ecs docker
我配置了一个包含 3 个实例 (m5.large) 的 AWS ECS 集群,每个可用区(A、B 和 C)各有一个实例。该服务配置如下:
在任务定义中,我使用了以下内容:
在容器级别,我仅配置了内存软限制:
我使用 awslogs 进行日志记录。上述配置有效,当我启动服务时,每个实例中都会运行一个 docker。其中一个实例中的“docker stats”显示以下内容:
MEM USAGE / LIMIT
230MiB / 7.501GiB
Run Code Online (Sandbox Code Playgroud)
容器实例(ECS控制台)显示如下:
Resources Registered Available
CPU 2048 2048
Memory 7680 5632
Ports 5 ports
Run Code Online (Sandbox Code Playgroud)
上述结果在所有 3 个实例中都是相同的 - 已预留 2 GB 内存(软限制),内存上限为近 8 GB 的实例内存(未设置硬限制)。到目前为止,一切都按预期进行。
但是当我从 Jenkins 重新部署代码(使用强制部署)时,我在 Jenkins 日志中收到以下错误:
"message": "(service App-V1-Service) was unable to place a task because no container instance met all of its requirements. The closest matching (container-instance 90d4ba21-4b19-4e31-c42d-d7223b34f17b) has insufficient memory available. For more information, see the Troubleshooting section of the Amazon ECS Developer Guide.
Run Code Online (Sandbox Code Playgroud)
在 Jenkins 中,作业显示为“成功”,但正在运行的是旧版本的代码。所有三个实例都有足够的可用内存。另外,我已将最低健康百分比更改为 30,希望 ECS 可以停止容器并重新部署新容器。任何解决方案或进一步调试的指针都会有很大帮助。
在部署过程中,ECS 计划将根据软限制为每个容器分配内存,可以
2048 * 3 = 6144 MB
Run Code Online (Sandbox Code Playgroud)
小于实例中的可用内存
5632 (available memory) < 6144 (required memory)
Run Code Online (Sandbox Code Playgroud)
如果您在同一个 ECS 容器实例中运行副本,那么我建议保持最小软限制,该限制应小于或等于 1GB, ECS 也建议这样做。
因此,通过此配置,您也将运行蓝绿部署。由于保持软限制最小并没有什么坏处,因为容器可以在需要时扩展以使用更多内存,因此为软限制应用一些大内存不会影响性能。
我不建议降低Minimum Healthy Percent: 0
软限制,因为将软限制降低到1GB 将解决该问题。
或者,如果您想保持相同的内存限制,则减少Minimum Healthy Percent