生产中每个主机应该存在多less个容器？ 应该如何拆分服务？
我试图更好地理解Docker的好处，而且我不太了解它在生产环境中的工作原理。
比方说，我有一个Web前端，一个rest后端和一个数据库。 这使得3个容器。
假设我想要前端3，后端5和分贝7。 （小问题：比后端服务器拥有更less的dbs是否合理？）
现在，考虑到上述情况，如果我将它们全部打包在同一台主机上，那么我就可以有效地使用主机的资源，但是当机器发生故障或者有networking分区时，我是DOA。
如果我把它们分成每个主机1个完整的应用程序（即1个FE，1个BE和1个DB），并把额外的容器放在他们自己的主机上，我可以获得一些有效利用资源的优势，但是在我看来，当我有一个networking分区，因为它会占用多个服务。
因此，我几乎认为我应该为每个主机放置一个容器，但这意味着我正在使用我的资源相当低效，那么容器在生产中的好处是什么？ 我的意思是，一个操作系统可能是一台额外的存储大小的机器，但大多数云提供商给你至less10演出存储。 让我们面对现实，restapi后端或networking前端是不会接近10演出…甚至包括操作系统。
所以，毕竟，我想弄清楚我是否错过了容器的要点？ 将一个应用程序的所有容器保存在一个主机上的好处，主要与testing和开发的好处有关？
我知道从不同的提供商/机器中容易地移动容器是有好处的，但是在大多数情况下，我并不认为这是一个巨大的好处，因为这是可以用image processing的。
我错过了生产容器的其他好处吗？ 还是testing和开发的主要好处？ （我在想生产中的容器是错的）？
注意 ：这个问题非常广泛，可以填写整本书，但我会说一些光。
容器的好处
关于容器的令人兴奋的部分不是关于它们在单个主机上的使用，而是关于在大型集群上连接的主机上的使用。 不要将您的机器视为独立的泊坞窗主机，而是将其作为托pipe容器的资源池。
容器本身并不是开创性的（ 即 Docker的CTO在最后的DockerCon上说“没有人关心容器” ），但是加上先进的调度器和容器编排框架，它们成为处理生产级的非常强大的抽象软件。
至于它也适用于虚拟机的说法，是的，但容器在虚拟机上有一些技术上的优势（请参阅： Docker与普通虚拟机的不同之处 ），这些虚拟机便于使用。
在单个主机上
在单个主机上，您可以从容器中获得的好处是（其中包括）：
- 用作模仿真实生产群集上的行为的开发环境。
- 独立于主机的可重复构build（便于共享）
- testing新的软件，而不用每天都不使用的软件包臃肿。
从单个主机扩展到一个机器池（集群）
pipe理生产集群的时机有两种：
- 创build一对docker主机，并通过脚本或使用像docker-compose这样的解决scheme“手动”运行/连接容器。 监控您的服务/容器的使用期限是需要付费的，您应该准备好处理服务停机时间。
- 让容器编排者处理所有事情，并监视服务的生命周期，以更好地应对失败。
有很多的容器编排者： Kubernetes ， Swarm ， Mesos ， Nomad ， Cloud Foundry ，还有可能还有很多其他的。 他们为Ebay等许多大型公司和基础设施供电，所以他们确实发现了使用这些公司的好处。
select正确的复制策略
容器可以更好地用作一次性资源，这意味着您可以独立停止和重新启动数据库，并且不应该影响后端（除了由于数据库已closures而抛出错误之外）。 因此，只要您的服务在多个主机上正确复制，就应该能够处理任何types的networking分区。
您需要select适当的复制策略 ，以确保您的服务保持运行。 例如，您可以跨云提供商可用区域复制数据库，以便在整个区域发生故障时，您的数据仍然可用。
例如，使用Kubernetes，您可以将每个容器（1个FE，1个BE和1个DB）放入一个容器中。 Kubernetes将处理在许多主机上复制这个吊舱，并监视这些吊舱总是处于运行状态，如果不是，将创build一个新的吊舱来应对故障。
如果要减轻networking分区的影响，请指定节点相关性 ，提示调度程序将容器放置在相同的计算机子集上，并在适当数量的主机上进行复制。
每个主机有多less个容器？
这真的取决于你使用的机器数量和他们拥有的资源。
规则是，如果不指定任何资源约束（就CPU或内存而言），则不应该使用容器数量太多的主机。 否则，您将冒险妥协主机并耗尽其资源，从而影响机器上的所有其他服务。 一个好的复制策略不仅在单个服务级别上很重要，而且还要确保共享主机的服务池的良好运行状况。
资源约束应根据工作负载的types进行处理：数据库可能会使用比您的前端容器更多的资源，因此您应该相应地resize。
例如，使用Swarm，可以明确指定给定服务所需的CPU或内存的数量（请参阅docker服务文档 ）。 虽然有很多的可能性，你也可以给CPU或内存使用上限/下限。 根据所选的值，调度程序将使用可用资源将服务连接到正确的机器。
Kubernetes的工作方式几乎相同，您可以为您的Pod指定限制（请参阅文档 ）。
Mesos拥有更多细化的资源pipe理策略，包括框架（针对Hadoop，Spark等多个特定工作负载）以及过度承诺function。 对于大数据types的工作负载，Mesos特别方便。
应该如何拆分服务？
这真的取决于编排解决scheme：
- 在Docker Swarm中，您将为每个组件（FE，BE，DB）创build一个服务，并为每个服务设置所需的复制号。
- 在Kubernetes中，您可以创build包含整个应用程序（FE，BE，DB和附加到数据库的卷）的容器，也可以为FE，BE，DB +卷创build单独的容器。
通常：每种types的容器使用一个服务。 关于容器组，评估是否比单独pipe理容器更方便地缩放整个容器组（作为primefaces单位，即一个容器）。
总结
容器可以更好地与编排框架/平台一起使用。 有很多可用的解决scheme来处理集装箱调度和资源pipe理。 select一个可能适合你的用例，并学习如何使用它。 总是select一个适当的复制策略，记住可能的故障模式。 尽可能为您的容器/服务指定资源约束，以避免可能导致主机停机的资源耗尽。
这取决于您在容器中运行的应用程序的types。 从头顶上我可以想到几个不同的方法来看待这个问题：
- 你的应用程序磁盘空间很重吗？
- 你需要在多台机器上保存应用程序吗？
- 你可以在同一主机上运行多个不同应用程序的不同实例，而不会降低它们的性能吗？
- 你使用像kubernetes或swarm软件来处理你的机器？
我认为即使没有容器，大部分问题都是有意思的。 容器可以释放你对单个主机的思考，但是你仍然必须自己决定和测量主机的负载。