加速docker-compose关闭 [英] Speed up docker-compose shutdown

问题描述

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

When I set up my application to run via docker-compose up, it takes several seconds to stop on ctrl+c. However, if I run docker kill ..., the container stops very quickly. Is there anything I can do to speed up container shutdown when killed via ctrl+c within docker-compose up?

特别是，当docker-compose说它优雅地停止时，这实际上是什么意思？ docker-compose是否尝试某些关闭协议，然后仅在超时后才杀死我的容器？

In particular, what does it actually mean when docker-compose says it is "gracefully stopping "? Is docker-compose trying some shutdown protocol and then killing my container only after a timeout?

推荐答案

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

基本上，当您执行Ctrl + C时，发送的是docker-compose，它实际上是什么意思？ SIGINT（2）信号发送给在前台运行的应用程序。在大多数情况下，此信号的语义类似于执行 docker-compose stop 或更基本地时引发的SIGTERM（15）信号。 docker stop 如果您专注于单个容器的应用程序。

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.

docker-compose尝试一些关闭协议然后仅在超时后杀死我的容器？

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

是的，它的想法是正在运行的应用程序可以捕获SIGINT和SIGTERM信号，并且

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

相反，SIGKILL（9）信号（由 docker kill 引发例如，导致该过程立即终止。

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

您可能对与此相关的这样回答，在这里我给出一个玩具示例入口点bash脚本，该脚本捕获了SIGINT和SIGTERM信号（当然不是SIGKILL）。

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).

是在这里我能做些什么来加快在docker-compose up中通过ctrl + c杀死容器时的关闭速度？

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

我会说 docker stop 左右时，容器退出容器所花费的时间很大程度上取决于相应映像的实现。

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超时 （文档）


• docker-compose stop -t超时 （doc）

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

但这肯定不是

实际上，当其中一个依赖于 entrypoint bash脚本时，有两个典型陷阱。 ：

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

1. 使用bash脚本作为包装程序最终调用另一个程序，但忘记使用内置的 exec 。
   
   →推荐的做法是在bash入口点的最后一个命令前加上 exec
   （例如，请参见此行来自 entrypointd.sh 中的 sudo-bmitch / docker-base ）。

1. Use a bash script as a wrapper to finally call another program, but forget to use the exec builtin.
   → The recommended practice consists in prepending the last command of a bash entrypoint with exec (for example, see this line from entrypointd.sh in sudo-bmitch/docker-base).

bash脚本本身不应立即终止，您可能会忘记照顾信号（包括SIGINT和SIGTERM）并采取相应措施，这也可能是导致您发现问题的原因。这与所谓的 PID 1僵尸获取问题。

→要解决此问题，您可能希望使用 docker run 标志运行映像 -init ，或者添加 docker-compose.yml 参数 init （相关的问题）。

When the bash script itself should not terminate immediately, one could forget to take care of trapping the signals (including SIGINT and SIGTERM) and behave accordingly, which can also be the cause of the issue you observe. This is related to the so-called PID 1 zombie reaping problem.
→ To workaround this, you may want to run your image with the docker run flag --init, or add the docker-compose.yml parameter init (related SO Q.)

这篇关于加速docker-compose关闭的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！