问加快对接-合成停运

EN

当码头工说它是“优雅地停下来”的时候，这到底是什么意思？

基本上，当您执行Ctrl+C时，您将向在前台运行的应用程序发送SIGINT (2)信号。大多数情况下，该信号的语义类似于在执行docker-compose stop或更基本的docker stop时提出的SIGTERM (15)信号，如果您只关注单个容器应用程序的话。

是码头-撰写尝试一些关机协议，然后杀死我的容器后，只有在超时？

是的，其思想是，运行的应用程序可以捕获SIGINT和SIGTERM信号，并在退出之前执行一些清理操作。

相反，SIGKILL (9)信号(例如由docker kill引发)会导致进程立即终止。

您可能对这个相关的所以回答感兴趣，我给出了一个入口点bash脚本的玩具示例，它“捕获”SIGINT和SIGTERM信号(当然不是SIGKILL )。

有什么我可以做的，以加快集装箱停运时，通过ctrl+c在码头-合成？

我想说的是，当您执行docker stop或其他操作时，容器退出所花费的时间取决于相应映像的实现。

乍一看，你可以修改(例如，缩短)提供给容器的时间，以便优雅地停下来：

• docker stop -t TIMEOUT (医生)
• docker-compose stop -t TIMEOUT (医生)

但这肯定不是一个恰当的解决办法。

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

1. 使用bash脚本作为包装器，最终调用另一个程序，但忘记使用exec内置程序。 推荐的实践是在bash的最后一个命令前面加上exec (例如，参见sudo-bmitch/docker-base)。
2. 当bash脚本本身不应该立即终止时，您可以忘记处理捕获信号(包括SIGINT和SIGTERM)并相应地进行操作，这也可能是您观察到的问题的原因。这与所谓的PID 1僵尸收割问题有关. 要解决这个问题，您可能需要使用docker run标志--init运行映像，或者添加docker-compose.yml参数init (相关的SO .)。

如果你发现自己频繁地重新启动容器，而有些容器不优雅地退出，或者有很长的出口时间(即。在它被杀死之前，您需要超过10个)，现在您可以使用stop_grace_period完成每个服务/容器的操作。

stop_grace_period指定在试图停止容器时，如果它不处理SIGTERM (或者使用stop_signal指定了哪个停止信号)，在发送SIGKILL之前组合实现必须等待多长时间。指定为持续时间。

例如

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