docker中的进程是否是最好的实践？
许多最佳实践指南都强调让你的进程成为一个守护进程，并且在发生故障的情况下让它看着它重新启动。 这是有道理的。 一个具体的例子可以是sidekiq。
bundle exec sidekiq -d 但是，在我构buildDocker的时候，我发现自己只是简单地执行命令，如果进程停止或者突然退出，整个Docker容器就会自动启动，并且一个新的会自动启动 – 基本上就是守护一个进程，它（所有的STDOUT都被发送到CloudWatch / Elasticsearch进行监控）。
我觉得这样也倾向于在docker集装箱中重新强调单一stream程的想法，如果你遵循这个守则，在我看来会鼓励违反这个通用标准。
即使你只在容器中运行一个进程，是否还有最佳实践文档？
您不会在容器中守护进程。
-d通常在docker docker run -d命令中看到，使用分离 （不是守护进程）模式，其中docker容器将在后台运行，完全脱离当前shell。
为了在一个容器中运行多个进程， 后台将是一个主pipe 。
请参阅“ 在 docker --init 使用Supervisor ”（或更新的docker --init ）。
一些相关的12个因子应用程序build议
- 一个应用程序在执行环境中作为一个或多个进程执行
- 并发是通过运行额外的进程（而不是线程）
网站：
Docker由PAAS运营商（ dotCloud ）开源，所以作者完全有可能受到这个架构build议的影响。 这将解释为什么Docker被devise为正常运行一个进程。
需要记住的是Docker容器不是虚拟机，尽pipe完全可以像一个虚拟机一样使用它。 在实践中，docker集装箱是在主机服务器上运行的监狱进程。 Kubernetes（Mesos，Docker Swarm模式）等容器编排引擎具有确保容器保持运行的function，并在需要时replace它们。
记得我提到的鸭子发声？ :-)如果你想让你的容器运行多个进程，那么可以运行一个监督程序来保持一切健康并在里面运行（当所有进程停止时容器都会死掉）
https://docs.docker.com/engine/admin/using_supervisord/
这个虚拟机嫉妒的终极performance是Ubuntu的LXD，这里有一整套虚拟机服务在LXC容器内引导
https://www.ubuntu.com/cloud/lxd
总而言之，这是一个最佳做法？ 我觉得没有明确的答案。 就个人而言，我会说两个理由：
- 我非常重视部署12个符合要求的应用程序，所以与单一stream程模型结合在一起
- 如果我需要在同一组数据上运行两个进程，那么在Kubernetes中，我可以在同一个POD中运行容器…意味着Kubernetespipe理进程（作为具有共同数据量的独立容器运行）。
显然，我的理由是具体实施。
有多个运行pipe理程序可以帮助您执行前台进程（或多个进程）来运行它们，并在发生故障（或退出容器）时重新启动它们。
一个是runit（ http://smarden.org/runit/ ），我没有用过我自己。
我的select是S6（ http://skarnet.org/software/s6/ ）。 有人已经为它创build了一个容器信封，名为S6覆盖（ https://github.com/just-containers/s6-overlay ），这是我通常使用，如果/当我需要有一个用户空间进程运行守护进程。 它也有许多方面可以在运行时做容器启动，更改权限等等的准备工作。
tl; dr：我无法find与docker工人直接相关的最佳实践文档，但我同意你的看法。
对于docker工人来说 ，唯一最好的“最佳实践”就是在docker工人自己的网站上 ，它指出集装箱应该是一个过程。 在我看来，这也意味着预先设定的stream程。 所以基本上，我已经得出了和你一样的结论。 （你可能也读过，但是这是其他人阅读的）。
老实说，我认为我们还处于相对新的领域，对docker工人有最好的实践。 有趣的是，这是我与之合作的最佳实践。 我对自己的预先感受更加满意的次数远远超过了我对自己说的那些次数：“男孩，我当然希望自己背弃这一点。 其实我从来没有这样说过。
我能想到的唯一例外是当你试图评估软件，需要一个快速和肮脏的方式将基础设施运送给某人。 EG：“嘿，我刚才听说有一种叫做LAMP堆栈的新东西，这里有一个docker集装箱，它有所有的组件供你玩耍”。 但是，这又是一个exception，如果这样的事情发生在生产环境，甚至任何严重的发展环境中，我都会不寒而栗。
另外，它肯定会强化微观架构风格，我认为这最终是一件好事。