Docker进程pipe理
我有一个在Docker容器中运行的已部署的应用程序，实际上是一个永远运行的websocket客户端。 每个部署我重build容器，并使用Dockerfile设置的命令启动与docker run 。
现在，我已经注意到有几次这个过程偶尔会死掉而不重新启动。 在运行docker ps ，我可以看到容器已经启动，并且已经运行了两个星期，但是运行在其中的进程已经死亡，主机没有任何智慧
我是否需要尽可能在docker集装箱内部有一个stream程pipe理器来pipe理集装箱化的stream程？
编辑：
Dockerfile： https ： //github.com/DVG/catpen-edi/blob/master/Dockerfile
我们开发了一个为Docker容器量身定制的stream程pipe理器，并且已经使用它取得了相当大的成功，可以准确解决您所描述的问题。 最好的出发点是看看github上的chaperone-docker 。 第一页上的自述文件包含一个指向最小基本图像的快速链接以及一个完全configuration的LAMP堆栈，因此您可以尝试一下，看看完全configuration的图像是什么样的。 它是开源的，完整的文档。
这是一个非常有趣的问题，这里涉及到PID1，以及ENTRYPOINT用CMD或ENTRYPOINT指定的命令代替PID1的事实。 发生的事情是，如果父进程死了，subprocess就不会自动被任何东西所采用，并成为一个孤儿（因为在传统的init系统中没有像以前那样的PID1）。 这里有一些很棒的阅读给你一些想法。 你可能会从他们的简化的初始化系统（“my_app”）附带的baseimage-docker映像中获得一些baseimage-docker ，这将为你解决一些这个问题。 不过，我强烈build议您不要自动采用所有容器的Phusion思维模式，因为在这个空间中存在一些意识形态的摩擦。 我不记得有关Docker的Github关于可能的最小初始化系统的任何讨论来解决这个问题，但我无法想象这将永远是一个问题。 祝你好运！
如果你有两个ruby进程，这听起来像孩子还没有退出，应用程序刚刚停止工作。 EventMachine反应堆可能位于后台。
EDI应用程序真的需要产生额外的Ruby过程吗？ 这只在Docker和你的应用程序之间增加了另外一层。 用CMD [ "ruby", "boot.rb" ]直接运行服务器。 如果您发现单个进程仍然存在问题，那么您将需要find导致您的应用程序挂起的原因。
当进程正在运行，因为PID 1是docker，它也需要处理SIGINT和SIGTERM信号。
# Trap ^C Signal.trap("INT") { shut_down exit } # Trap `Kill ` Signal.trap("TERM") { shut_down exit }
Docker在容器确实死亡时也有重启策略 。
docker run --restart=always
no退出时不自动重启容器。 这是默认的。on-failure[:max-retries]仅在容器以非零退出状态退出时重新启动。 （可选）限制Docker守护程序尝试重新启动的次数。always始终重新启动容器，无论退出状态如何。 当你总是指定的时候，Docker守护进程会尝试无限期地重启容器。 无论容器的当前状态如何，容器也将始终在守护进程启动时启动。unless-stopped始终重新启动容器，不pipe退出状态如何，但是如果容器之前已经处于停止状态，则不要在守护进程启动时启动它。