在 docker 中守护进程是最佳实践吗？

Question

许多最佳实践指南强调让您的进程成为守护进程，并让某些东西监视它以在发生故障时重新启动。这在一段时间内是有道理的。一个具体的例子可以是sidekiq。

bundle exec sidekiq -d

然而，在我构建 Docker 时，我发现自己只需执行命令，如果进程突然停止或退出，整个 docker 容器就会崩溃，并且一个新的容器会自动启动 - 基本上就是守护进程并监视某些内容的整个过程（所有 STDOUT 都发送到 CloudWatch / Elasticsearch 进行监控）。

我觉得这也倾向于强化 docker 容器中单个进程的想法，如果你守护进程，我认为这往往会鼓励违反该通用标准。

即使您在容器内只运行一个进程，是否有关于此的最佳实践文档？

Answer 1

您不会对容器内的进程进行守护进程。

通常在命令-d中看到，使用分离（非守护进程）模式，其中 docker 容器将在后台运行，完全与当前 shell 分离。docker run -d

对于在容器中运行多个进程，后台进程将是 Supervisor。
请参阅“在 docker 中使用 Supervisor ”（或更新的docker --init内容）。