加速 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?

推荐答案

当 docker-compose 说它正常停止"时，这实际上是什么意思?

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

基本上，当您按 Ctrl+C 时，您是在向在前台运行的应用程序发送 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.

您可能对这个相关的 SO answer 感兴趣，我在其中给出了一个捕获"入口点 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 TIMEOUT (doc)
• docker-compose stop -t TIMEOUT (doc)

但这肯定不是一个合适的解决方案.

but this would certainly not be a proper solution.

实际上，在依赖入口点 bash 脚本时，有两个典型的陷阱:

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

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

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

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屋！