我试图更好地了解Docker的好处，而我并不真正了解它如何在生产中发挥作用。
让我们说我有一个网络前端，一个休息api后端和一个数据库。那就是3个容器。
让我们说我需要3个前端，5个后端和7个db。 （次要问题：dbs比后端服务器少吗？）
现在，鉴于上述情况，如果我将它们全部打包在同一主机上，那么我将获得有效使用主机资源的好处，但是当机器出现故障或网络分区时我就是DOA。
如果我将每个主机分成1个完整的应用程序（即1个FE，1个BE和1个DB），并将额外的容器放在他们自己的主机上，我会获得有效使用资源的一些优势，但在我看来，当我有一个网络分区时，我仍然会失去很多，因为它会占用多个服务。
因此，我几乎倾向于得出每个主机应该放入1个容器的结论，但那意味着我使用的资源非常低效，那么容器在生产中有什么好处？我的意思是，操作系统可能是每台机器存储大小的额外几个演出，但大多数云提供商为您提供至少10演出存储。让我们面对它，一个休息api后端或网络前端甚至不会接近10场演出......甚至包括操作系统。
所以，毕竟，我试图弄清楚我是否错过了容器的意义？将应用程序的所有容器保留在一台主机上的好处是什么，主要与测试和开发的好处有关？
我知道在不同的提供商/机器之间轻松移动容器会带来好处，但在大多数情况下，我并不认为这是一个巨大的收获，因为这可以用图像来实现......
我缺少生产中的容器还有其他好处吗？或者是测试和开发的主要好处？ （我是否认为生产中的容器错了）？
答案 0 :(得分：27)
注意：这个问题非常广泛，可能会填满整本书，但我会说清楚。
关于容器的令人兴奋的部分不是关于它们在单个主机上的使用，而是它们在大型集群上连接的主机上的使用。不要将您的计算机视为独立的docker主机，而应将其视为托管容器的资源池。
容器本身并不突破（即。 Docker的首席技术官陈述最后 DockerCon ＆＃34;没有人关心容器＆ ＃34; ），但与最先进的调度程序和容器编排框架相结合，它们成为处理生产级软件的非常强大的抽象。
关于它也适用于虚拟机的论点，是的，但是容器在虚拟机上具有一些技术优势（参见：How is Docker different from a normal virtual machine），方便使用。
在单个主机上，您可以从容器中获得的好处（以及其他许多主机）：
当管理生产集群时，有两种方法：
有很多容器协调器： Kubernetes ， Swarm ， Mesos ， Nomad ， Cloud Foundry ，可能还有很多其他人。他们为许多大型公司和基础设施提供支持，比如Ebay，所以他们肯定会在使用这些公司时获益。
容器最好用作一次性资源，这意味着您可以独立停止和重新启动数据库，它不应该影响后端（除了因为数据库关闭而抛出错误） 。因此，只要您的服务在多个主机上正确复制，您就应该能够处理任何类型的网络分区。
您需要选择正确的复制策略，以确保您的服务保持正常运行。例如，您可以跨云提供商可用区复制数据库，这样当整个区域出现故障时，您的数据仍然可用。
例如，使用Kubernetes，您可以将每个容器（1 FE，1 BE＆amp; 1 DB）放入一个容器中。 Kubernetes将处理在许多主机上复制此pod并监视这些pod是否始终启动并运行，如果不是，将创建新的pod以应对失败。
如果要减轻网络分区的影响，请指定节点关联，暗示调度程序将容器放在同一台计算机上并在适当数量的主机上进行复制。
这实际上取决于您使用的机器数量和所拥有的资源。
规则是，如果您没有指定任何资源限制（就CPU或内存而言），您不应该使用太多容器来膨胀。否则，您可能会损害主机并耗尽其资源，从而影响计算机上的所有其他服务。良好的复制策略不仅在单个服务级别很重要，而且还可以确保共享主机的服务池具有良好的运行状况。
应根据工作负载的类型处理资源约束：数据库可能会使用比前端容器更多的资源，因此您应该相应地调整大小。
例如，使用Swarm，您可以明确指定给定服务所需的CPU数或内存数（请参阅docker service documentation）。虽然有很多可能性，但您也可以根据CPU或内存使用情况给出上限/下限。根据所选的值，调度程序会使用可用资源将服务固定到正确的计算机上。
Kubernetes的工作方式几乎相同，您可以为您的容器指定限制（请参阅documentation）。
Mesos拥有更精细的资源管理策略和框架（针对特定工作负载，如Hadoop，Spark等等）以及过度提交功能。 Mesos对于大数据类型的工作负载特别方便。
这实际上取决于编排解决方案：
通常：每种容器使用一种服务。关于容器组，评估是否更方便地扩展整个容器组（作为原子单元，即一个容器）而不是单独管理它们。
容器最好与业务流程框架/平台一起使用。有许多可用的解决方案来处理容器调度和资源管理。选择一个可能适合您的用例，并学习如何使用它。始终选择适当的复制策略，记住可能的故障模式。在可能的情况下为容器/服务指定资源约束，以避免资源耗尽，这可能会导致主机关闭。
答案 1 :(得分：1)
这取决于您在容器中运行的应用程序类型。从头脑中我可以想到几种不同的方式来看待这个：
我认为即使没有容器，大多数问题都很有趣。容器可能让您无需考虑单个主机，但您仍需自行决定并测量主机的负载。
答案 2 :(得分：0)
次要问题：拥有比后端服务器少的数据库有意义吗？
是的。
请考虑以下情况：您击中普通（没有很多联接）的SQL select语句从数据库中获取数据，但是您的业务逻辑需要太多的计算。在这种情况下，您可能会考虑将后端服务计数保持在较高的水平并将数据库服务计数保持在较低的水平。
这完全取决于要解决的用例。
答案 3 :(得分：0)
每台主机的容器数量取决于主机的设计比例和容器的工作负载比例。两个比例都是 吞吐量/容量比率。在过去，这被称为执行/带宽的 E/B。执行是 CPU，带宽是 I/o。据说解决方案受 CPU 或 I/O 限制。
今天的内存非常大，关键因素通常是cpu/nest 容量。我们将工作负载描述为 CPU 密集型或嵌套密集型。嵌套容量的一个有用代理是最高级别缓存的大小。一个有用的设计比率估算器是（时钟 x 内核）/缓存。在相同的芯数下，设计比率较低的机器将容纳更多的容器。这在一定程度上是因为具有更多缓存的机器将更好地扩展并且在更高的利用率下看到更少的饱和。作者