在 docker stop 之后，Monit 不再使用 bash 脚本启动

Question

我有一个 docker 容器，它使用 monit 启动一些服务，例如 mongodb、nginx。我有一个 bash 脚本，docker 使用它来启动监控。以下是文件内容：

#!/bin/bash

# Monit will start all apps
/usr/bin/monit -c /etc/monitrc &

# Stay up for container to stay alive
while [ 1 ] ; do
  if !(pgrep monit)
  then /usr/bin/monit -c /etc/monitrc &
  fi
  sleep 5m
done

问题是当我运行docker create 命令来创建容器时，bash 脚本运行正常并且monit 启动了所有服务，但是如果我停止容器并重新启动它，有时monit 不会出现或者如果它出现，它不会启动服务。任何人都可以验证我的 bash 脚本是否正常。我使用了以下参考https://blog.deimos.fr/2016/01/13/docker-why-you-should-use-monit-instead-of-supervisord/

Answer 1

要在容器中运行多个进程，请使用支持在 Docker 中作为 PID 1 运行的初始化系统，例如 s6 通过 s6-overlay 或 supervisord。在两者之间添加自定义脚本只是在服务链中增加了一个额外的链接，并有可能将问题引入系统。

信号和 Docker

docker stop 向容器进程发送 SIGTERM signal，然后在默认 10 秒后发送 SIGKILL，这将终止容器和其中运行的任何内容。

在 docker 下运行的进程是 PID 1，所以 needs to handle 任何 signals 你要对其采取行动，否则它们将被忽略。对于服务管理器，这需要将 SIGTERM 传递给所有托管服务。请注意，the blogtrap 和脚本的EXIT 上的示例脚本会运行一个脚本来干净地停止所有monit 服务。 EXIT 包括SIGTERM。

在您的示例脚本中，容器中运行的所有进程将在 docker stop 超时后以 SIGKILL 终止。

服务和 SIGKILL

我没有经常使用monit，但作为服务管理器，我希望它能够优雅地处理被 SIGKILL（或 kill -9）杀死并在下一次（可能虽然不是）。

nginx 通常会在SIGKILL 中存活，因为默认情况下它不会主动在磁盘上存储太多状态。

mongodb 确实需要彻底关闭。 SIGKILL 将保留需要手动清理的数据库锁定文件。