加速 docker-compose 关闭

Question

当我将应用程序设置为通过 运行时docker-compose up，需要几秒钟才能在 ctrl+c 上停止。但是，如果我运行docker kill ...，容器会很快停止。当通过 ctrl+c 杀死时，我可以做些什么来加速容器关闭docker-compose up？

特别是，当 docker-compose 说它“正常停止”时，这实际上意味着什么？docker-compose 是否尝试了一些关闭协议，然后仅在超时后才终止我的容器？

Answer 1

如果您发现自己经常重新启动容器，并且有些容器没有正常退出或退出时间很长（即您需要10 秒以上才能杀死容器），那么您现在可以对每个服务/容器执行此操作stop_grace_period

\n

\n

stop_grace_period指定在发送 SIGKILL 之前，如果容器不处理SIGTERM（或使用 指定的任何停止信号stop_signal），Compose 实现在尝试停止容器时必须等待多长时间。指定为持续时间。

\n

\n

例如

\n

services:\n  service_A:\n    ...\n    stop_grace_period: 1s  # SIGKILL after 1s\n  service_B:\n    ...\n    stop_grace_period: 5m30s  # wait a long time before SIGKILL\n

\n\n

所有格式（2.0+）都应该支持它，发行说明表明它从1.10.0（2017-01-18 也引入了 3.0规范）开始可用（在组合中） ，并在1.18docker-compose.yml中进行了重要修复.0（2017-12-18 “服务定义中的设置stop_grace_period现在也设置容器的stop_timeout”）

\n

Answer 2

what does it actually mean when docker-compose says it is "gracefully stopping "?

Basically when you do Ctrl+C you are sending a SIGINT (2) signal to the application that runs in the foreground. Most of the time, the semantics of this signal is similar to the SIGTERM (15) signal that is raised when doing docker-compose stop or more basically docker stop if you are focusing on a single-container application.

Is docker-compose trying some shutdown protocol and then killing my container only after a timeout?

Yes, the idea is that the running application can catch the SIGINT and SIGTERM signal and perform some cleanup operation before exiting.

On the contrary, the SIGKILL (9) signal (raised by docker kill for example) causes the process to terminate immediately.

You might be interested in this related SO answer where I give a toy example of entrypoint bash script that "catches" SIGINT and SIGTERM signals (but not SIGKILL, of course).

Is there anything I can do to speed up container shutdown when killed via ctrl+c within docker-compose up?

I'd say the time spent by your containers to exit when you do docker stop or so strongly depends on the implementation of the corresponding images.

At first sight, you might modify (e.g., shorten) the time offered to the containers to gracefully stop:

• docker stop -t TIMEOUT (doc)
• docker-compose stop -t TIMEOUT (doc)

but this would certainly not be a proper solution.

Actually, there are two typical pitfalls when one comes to rely on an entrypoint bash script:

1. 使用 bash 脚本作为包装器来最终调用另一个程序，但忘记使用exec内置程序。
   ? 推荐的做法包括在 bash 入口点的最后一个命令之前加上exec （例如，请参阅in 中的这一行entrypointd.shsudo-bmitch/docker-base）。

2. 当 bash 脚本本身不应该立即终止时，人们可能会忘记处理捕获信号（包括 SIGINT 和 SIGTERM）并采取相应的行为，这也可能是您观察到的问题的原因。这与所谓的PID 1僵尸收割问题有关。
   ? 要解决此问题，您可能希望使用docker runflag运行图像--init，或添加docker-compose.yml参数（相关 SO Q。）init