在Docker中，使用“CMD cmd1 && cmd2”与“CMD cmd1 && exec 2”是否有任何优缺点？

Question

在Docker中，当以shell形式链接多个启动命令(CMD)时，使用shell的exec特性替换它为链的最后一个命令，而不是仅仅将其作为启动shell的子进程运行，有什么好处吗？

下面是一个示例：

CMD npm install && npm start

相对于：

CMD npm install && exec npm start

我认为在后一个例子中，npm start命令将代替shell作为PID 1进程。但我不完全明白这会有什么好处或坏处。

Answer 1

如果用新的可执行文件替换pid 1，而不是将其作为子pid进行分叉，则会减少开销(略有减少)。更重要的是，您直接将信号传递给应用程序，而不是将它们作为pid 1传递给shell。默认情况下，pid 1中运行的shell将忽略由docker发送的SIGTERM，以便优雅地停止应用程序。在10秒没有响应后，docker将发送一个SIGKILL，它将立即终止shell和子进程，而不会让它们有机会耗尽网络连接或完成对任何文件的写入。这可能会导致数据库损坏，这取决于应用程序在容器中的内容。

即使这不适用于您的应用程序(如果没有状态)，每次通过切换到exec语法(假设应用程序在接收到SIGTERM时退出)，也可以节省多达10秒的时间。因此，出于数据安全和速度的考虑，我更喜欢使用exec语法。