问Docker进程管理

EN

我们已经开发了一个为Docker容器量身定做的进程管理器，并且已经成功地使用它来准确地解决您所描述的问题。最好的起点是take a look at chaperone-docker on github。第一页上的自述文件包含一个指向最小基本映像的快速链接，以及一个完全配置的LAMP堆栈，因此您可以试用它并查看完全配置的映像是什么样子的。它是开源的，并且有完整的文档。

这是一个非常有趣的问题，这里涉及到PID1，以及docker用CMD或ENTRYPOINT中指定的命令替换PID1的事实。发生的情况是，如果父进程死了，它变成了一个孤儿，子进程不会自动被任何东西采用(因为没有您习惯的传统初始化系统意义上的PID1 )。Here is some excellent reading给你一些想法。你可能会从他们的简化初始化系统("my_app")附带的baseimage-docker镜像中获得一些里程，这将为你解决一些问题。然而，我强烈警告您不要自动地对您的所有容器采用Phusion思维模式，因为在该领域存在一些意识形态摩擦。我不记得在Docker的Github上有任何关于潜在的最小init系统来解决这个问题的讨论，但我不能想象这将是一个永远的问题。祝好运!

如果你有两个ruby进程，听起来好像孩子还没有退出，应用程序已经停止工作了。很可能EventMachine反应堆就在后台。

电子数据交换应用程序真的需要spawn the additional Ruby process吗？这只是在Docker和你的应用程序之间添加了另一层。直接使用CMD [ "ruby", "boot.rb" ]运行服务器。如果你发现问题仍然发生在单个进程中，那么你需要找出是什么导致你的应用程序挂起。

当一个进程作为PID1的docker运行时，它也需要handle the SIGINT and SIGTERM信号。

# Trap ^C 
Signal.trap("INT") { 
  shut_down 
  exit
}

# Trap `Kill `
Signal.trap("TERM") {
  shut_down
  exit
}

当容器真的死了的时候，Docker也有restart policies。

docker run --restart=always

• no不会在容器退出时自动重新启动容器。这是默认设置。仅当容器以非零退出状态退出时，
• on-failure[:max-retries]才会重新启动。或者，限制Docker守护程序重启重试的次数。无论退出状态如何，
• always始终重新启动容器。当您指定always时，Docker守护进程将尝试无限期地重新启动容器。容器还将始终在守护进程启动时启动，而不管容器的当前状态如何。无论退出状态如何，
• unless-stopped始终重新启动容器，但如果容器以前已置于停止状态，则不要在后台进程启动时启动它。