当docker使用'/bin/sh-c'运行SIGTERM时，SIGTERM不会到达节点脚本

Question

当我的Dockerfile以

CMD node .

Docker使用命令/bin/sh-c"节点."来运行该容器。而不是简单的节点。（我知道，我可以用CMD["节点", "."] ）。

我认为这种行为实际上很好，因为它意味着容器中的PID1是/bin/sh，而不是我简单的节点脚本。

如果我正确理解PID1负责收获孤儿僵尸进程，我真的不想对此负责...所以如果/bin/sh可以做到这一点，那就太好了。（我实际上认为这是docker重写我的CMD的原因）。

问题是，当我发送一个SIGTERM到容器（以/bin/sh-c"节点"开始。），通过docker-作曲家停止或docker-作曲家杀死-s SIGTERM，信号没有到达我的节点进程，因此在10秒的宽限期后，它每次都被强制杀死。不漂亮。

有没有办法让某人管理我的僵尸，让我的节点实例接收docker发送的信号？




Answer 1

我的PID1问题解决方案：

Dockerfile以以下内容结束：

ENTRYPOINT ["/bin/bash", "-c"]

或者将ENTRYPOINT完全从Dockerfile中删除。默认值为/bin/sh-c。

比我运行这个外壳脚本，它具有节点的文件名，并且具有chmod x：

#!/bin/bash

docker run --rm -it -p 8083:80 -v $HOME/node/work/:/root/node/:rw node_node "echo pid1 > /dev/null && node $@"

诀窍是回声pid1

echo将捕获PID1并将输出发送到/dev/null。

例如./node-v将在运行的容器中返回Node.js的版本。

使用/node/root/node/hello world.js命令运行Web服务器时，CTRL C将再次工作。

这是我的DockerizedNode.js开发环境。

编辑：

完全疯狂的想法，但是将这个名为bash脚本的节点添加到$PATH。所以在主机上，您可以键入节点-v而不是./节点-v。你在Docker容器中运行节点，它看起来完全像是安装在主机上的。：）

Answer 2

有一些工具可以解决这个问题：

• https://github.com/yelp/dumb-init
• https://github.com/krallin/tini

我认为如果你只有一个进程，你所需要做的就是用一个信号处理程序显式处理信号，而bash对你没有用。

使用[“node”，“]语法，您可以使用https://nodejs.org/api/process.html#process_signal_events 让它在一个学期内退出。我相信这就足够了。

或者使用bash脚本，您可以使用陷阱"退出0"TERM

您也可以使用像http://skarnet.org/software/s6/这样的流程主管

Answer 3

我认为您必须了解ENTRYPOINT和CMD的角色，并在Dockerfile中使用ENTRYPOINT（exec表单）方式。

ENTRYPOINT，指定容器的起始可执行文件，是Docker容器的核心部分。每个容器都必须有一个入口点来决定从何处开始。默认情况下，该值为/bin/bash-c。此外，CMD设置的所有内容都将作为参数附加到ENTRYPOINT。

因此，如果您未能在Dockerfile中指定ENTRYPOINT，那么实际的入口点将是/bin/bash-c{your_command_in_CMD}，不幸的是，它不会传递信号。

ENTRYPOINT有两种形式：exec形式和shell形式

• exec form： ENTRYPOINT[可执行文件，参数1，参数2]
• shell形式：命令参数1参数2

正如Docker参考资料所指出的：建议使用exec表单，而shell表单的缺点是命令由/bin/bash-c执行，这可能无法很好地处理信号：

shell表单阻止使用任何CMD或run命令行参数，但有一个缺点，即您的ENTRYPOINT将作为/bin/sh-c的子命令启动传递信号。这意味着可执行文件将不是容器的PID 1-并且不会接收Unix信号-因此您的可执行文件将不会从docker停止接收SIGTERM