生产中每个主机应该有多少个容器？如何分割服务？

Question

我试图更好地理解Docker的好处,我并不真正理解它在生产中的作用.

假设我有一个网络前端,一个休息api后端和一个数据库.这使得3个容器.

假设我想要3个前端,5个后端和7个db.(小问题:拥有比后端服务器少的dbs是否有意义？)

现在,鉴于上述情况,如果我将它们全部打包在同一主机上,那么我将获得有效使用主机资源的好处,但是当机器出现故障或有网络分区时,我就是DOA.

如果我将它们分成每个主机的1个完整应用程序(即1个FE,1个BE和1个DB),并将额外的容器放在它们自己的主机上,我会获得有效使用资源的一些优势,但在我看来,我仍然显着地失去了当我有一个网络分区,因为它将取消多个服务.

因此,我几乎倾向于得出每个主机应该放入1个容器的结论,但那意味着我使用的资源非常低效,那么容器在生产中有什么好处？我的意思是,操作系统可能是每台机器存储大小的额外几个演出,但大多数云提供商为您提供至少10演出存储.让我们面对它,休息api后端或网络前端甚至不会接近10场演出......甚至包括操作系统.

所以,毕竟,我想弄清楚我是否错过了容器的重点？将应用程序的所有容器保留在1个主机上的好处是多少,主要与测试和开发优势相关？

我知道在不同的供应商/机器之间轻松移动容器会带来好处,但在大多数情况下,我并不认为这是个人的巨大收获,因为这对图像来说是可行的......

我缺少的生产容器还有其他好处吗？或者是测试和开发的主要好处？(我是否认为生产中的容器错了)？

Answer 1

注意:问题非常广泛,可能会填满整本书,但我会说清楚.

容器的好处

关于容器的令人兴奋的部分不是关于它们在单个主机上的使用,而是它们在大型集群上连接的主机上的使用.不要将您的计算机视为独立的docker主机,而应将其视为托管容器的资源池.

单独容器不是石破天惊(即多克的CTO,说明在最后DockerCon是"无人问津容器"),但耦合到艺术调度和集装箱业务流程框架的状态,他们成为一个非常强大的抽象来处理生产级软件.

至于它也适用于虚拟机的论点,是的,但是容器具有一些技术优势(参见:Docker与普通虚拟机有何不同)而不是虚拟机,这使得它们便于使用.

在单个主机上

在单个主机上,您可以从容器中获得的好处(在许多其他主机中):

• 用作模拟真实生产群集上的行为的开发环境.
• 可重复构建独立于主机(便于共享)
• 使用您不会每天使用的软件包测试新软件而不会使您的机器膨胀.

从单个主机扩展到一个机器池(集群)

在管理生产集群时,有两种方法:

• 创建几个docker主机,并通过脚本或使用docker-compose等解决方案"手动"一起运行/连接容器.监控服务/容器的生命周期由您负责,您应该准备好处理服务停机时间.
• 让容器协调器处理所有事情并监控服务的生命周期,以便更好地应对故障.

有很多容器协调器:Kubernetes,Swarm,Mesos,Nomad,Cloud Foundry,还有很多其他的.它们为许多大型公司和基础设施提供动力,比如Ebay,因此他们确实在使用这些公司时获益.

选择正确的复制策略

容器最好用作一次性资源,这意味着您可以独立地停止和重新启动数据库,它不应该影响后端(除了因为数据库已关闭而抛出错误).因此,只要您的服务在多个主机上正确复制,您就应该能够处理任何类型的网络分区.

您需要选择正确的复制策略,以确保您的服务保持正常运行.例如,您可以跨云提供商可用区复制数据库,以便在整个区域出现故障时,您的数据仍然可用.

例如,使用Kubernetes,您可以将每个容器(1 FE,1 BE和1 DB)放入一个容器中.Kubernetes将处理在许多主机上复制此pod并监视这些pod始终启动并运行,如果不是,将创建新pod以应对失败.

如果要减轻网络分区的影响,请指定节点关联,提示调度程序将容器放在同一台计算机上,并在适当数量的主机上进行复制.

每个主机有多少个容器？

这实际上取决于您使用的机器数量和它们拥有的资源.

规则是,如果未指定任何资源约束(就CPU或内存而言),则不应该使容器容量过大.否则,您可能会损害主机并耗尽其资源,从而影响计算机上的所有其他服务.良好的复制策略不仅在单个服务级别上很重要,而且还可以确保共享主机的服务池的良好运行状况.

应根据工作负载的类型处理资源约束:数据库可能会使用比前端容器更多的资源,因此您应该相应地调整大小.

例如,使用Swarm,您可以明确指定给定服务所需的CPU数或内存数(请参阅docker服务文档).虽然有很多可能性,但您也可以根据CPU或内存使用情况给出上限/下限.根据所选的值,调度程序将使用可用资源将服务固定到正确的计算机上.

Kubernetes的工作方式几乎相同,您可以为pod指定限制(请参阅文档).

Mesos拥有更精细的资源管理策略,包括框架(针对特定工作负载,如Hadoop,Spark等等)以及过度提交功能.Mesos对大数据类型的工作负载特别方便.

如何分割服务？

它真的取决于编排解决方案:

• 在Docker Swarm中,您将为每个组件(FE,BE,DB)创建服务,并为每个服务设置所需的复制编号.
• 在Kubernetes中,您可以创建包含整个应用程序的容器(FE,BE,DB和连接到数据库的卷),也可以为FE,BE,DB +卷创建单独的容器.

通常:每种容器使用一种服务.关于容器组,评估是否更方便地缩放整个容器组(作为原子单元,即容器)而不是单独管理它们.

总结

容器更好地与业务流程框架/平台一起使用.有许多可用的解决方案来处理容器调度和资源管理.选择一个可能适合您的用例,并学习如何使用它.始终选择适当的复制策略,记住可能的故障模式.尽可能为容器/服务指定资源约束,以避免资源耗尽,从而可能导致主机停机.