我试图更好地了解Docker的优势，但我并不是真正了解Docker在生产中的工作方式。
假设我有一个Web前端，一个REST API后端和一个数据库。这使3个容器。
假设我要3个前端，5个后端和7个db。 (次要问题:拥有比后端服务器少的数据库有意义吗？)
现在，在上述情况下，如果将它们全部打包在同一主机上，那么我将获得有效使用主机资源的好处，但是当该计算机发生故障或具有网络分区时，我就是DOA。
如果将每个主机将它们分成1个完整的应用程序(即1个FE，1个BE和1个DB)，并在其自己的主机上放置额外的容器，我将获得一些有效利用资源的优势，但在我看来，我仍然会损失很多当我有一个网络分区时，它将断开多种服务。
因此，我几乎要得出这样的结论:每个主机应放入1个容器，但是那意味着我效率很低地利用了我的资源，那么容器在生产中有什么好处？我的意思是，每台计算机的操作系统在存储大小上可能会额外增加几个演出，但是大多数云提供商都会为您提供至少10个演出的存储。面对现实吧，其余的api后端或Web前端甚至都无法接近10个演出……甚至包括操作系统。
所以，毕竟，我试图找出是否遗漏了容器的问题？将应用程序的所有容器保留在1个主机上的好处是否与测试和开发的好处联系在一起？
我知道轻松地在不同的提供者/机器之间移动容器有很多好处，但是在大多数情况下，我个人认为这并不是一个巨大的 yield ，因为这对于图像来说是可行的...
我所缺少的生产中的容器还有其他好处吗？还是测试和开发的主要好处？ (我认为生产中的容器有误吗？)？
最佳答案
注意:这个问题很广泛，可以填满整本书，但我会阐明一点。
容器的好处
关于容器的令人兴奋的部分不是它们在单个主机上的使用，而是它们在连接大型集群的主机上的使用。不要将您的机器视为独立的Docker主机，而应视为承载容器的资源池。
单独的容器并不是开创性的(例如，Docker的CTO在最后一个DockerCon上表示“没人在乎容器”)，但与最先进的调度程序和容器编排框架相结合，它们成为处理生产级的非常强大的抽象软件。
关于它也适用于虚拟机的说法，是的，但是容器相对于VM具有一些技术优势(请参阅:How is Docker different from a normal virtual machine)，使它们易于使用。
在单主机上
在单个主机上，您可以从容器中获得好处(以及许多其他好处):
从单个主机扩展到计算机池(群集)
当需要管理生产集群时，有两种方法:
有很多容器协调器:Kubernetes，Swarm，Mesos，Nomad，Cloud Foundry以及其他许多容器。他们为许多大型公司和基础架构(例如Ebay)提供了动力，因此他们肯定会发现使用它们的好处。
选择正确的复制策略
最好将容器用作一次性资源，这意味着您可以独立停止和重新启动数据库，并且它不会影响后端(除了会因为数据库已关闭而引发错误)。这样，只要在多个主机之间正确复制了服务，您就应该能够处理任何类型的网络分区。
您需要选择适当的复制策略，以确保您的服务保持正常运行。例如，您可以跨云提供商的可用区域复制数据库，以便当整个区域出现故障时，您的数据仍然可用。
例如，使用Kubernetes，您可以将每个容器(1个FE，1个BE和1个DB)放在一个容器中。 Kubernetes将处理在许多主机上复制此Pod的问题，并监视这些Pod始终处于运行状态，如果没有创建新Pod来应对故障。
如果要减轻网络分区的影响，请指定节点关联性，以提示调度程序将容器放置在同一台计算机上，并在适当数量的主机上进行复制。
每个主机多少个容器？
这实际上取决于您使用的计算机数量和拥有的资源。
规则是，如果您未指定任何资源限制(就CPU或内存而言)，则不应为拥有过多容器的主机膨胀。否则，您有可能损害主机并耗尽其资源，这反过来会影响计算机上的所有其他服务。好的复制策略不仅在单个服务级别上很重要，而且对于确保共享主机的服务池的良好运行状况也很重要。
应根据工作量的类型来处理资源限制:数据库可能比前端容器使用更多的资源，因此您应该相应地调整大小。
例如，使用Swarm，您可以显式指定给定服务所需的CPU或内存数量(请参阅docker service documentation)。尽管有很多可能性，您还可以根据CPU或内存的使用情况给出上限/下限。根据选择的值，调度程序会将服务固定到具有可用资源的正确计算机上。
Kubernetes的工作方式几乎相同，您可以为pod设置限制(请参阅documentation)。
Mesos具有更细粒度的资源管理策略，这些策略具有框架(针对特定的工作负载，如Hadoop，Spark等)，并且具有过量使用功能。 Mesos对于大数据类型的工作负载特别方便。
服务应如何划分？
这实际上取决于编排解决方案:
通常:每种容器使用一种服务。关于容器组，评估缩放整个容器组(作为一个原子单位，即一个容器)是否比单独管理它们更方便。
总结
容器最好与业务流程框架/平台一起使用。有很多可用的解决方案来处理容器调度和资源管理。选择一个可能适合您的用例的方法，并学习如何使用它。始终选择适当的复制策略，并牢记可能的故障模式。尽可能为您的容器/服务指定资源限制，以避免资源耗尽，这可能导致主机崩溃。
关于docker - 每个主机在生产中应存在多少个容器？服务应如何划分？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/41214091/