评论:Docker蜂群激增，前途无量

众所周知，大规模部署和管理任何东西都是困难的。Docker也不例外。然而，Docker的工程师认识到这一点，并致力于开发三种产品来提供帮助:Docker Machine、Docker Compose和Docker Swarm。

在最高级别，机器可以很容易地旋转起来泊坞主机在您的环境中，谱写可以更容易地在泊坞部署复杂的分布式应用程序，以及群使得原来的聚类的码头工人。

所有这些都是新技术，目前正处于多克公司所有的发展都是可插拔的，这意味着它们是可选的，并且可以支持做同样工作的第三方产品被交换出去。在此之前的泊坞理念，以“电池包括在内，但可移动的。”如果你找到一个第三方工具，你的作品好，你可以自由地使用它来驱动，而不是多克。

在这篇文章中，我们将快速浏览一下泊坞群。

什么是Docker Swarm?

如果Swarm是Docker的原生集群，我们需要定义“集群”。In the context of Swarm, a cluster is a pool of Docker hosts that acts a bit like a single large Docker host. Instead of the hassle of having to decide which host to start every container on, we can tell Swarm to start our containers. In the background, Swarm magically decides which nodes to start them on. This is a great feature and a core tenet of cloud computing.

但是对于熟悉传统故障转移集群的读者来说，Swarm还不是那样。

在撰写本文时(版本0.2)，Swarm还不支持容器故障转移。这意味着，当集群中的一个节点发生故障时，它所承载的容器将不会在另一个节点上重新启动。

这可能是当前版本的Swarm最大的弱点。现在您已经知道了什么是有效的群集群集，让我们看看它目前提供的一些好处。

群是很容易的

有一个很多喜欢群。首先，它很容易。相比于群集技术我已经在过去合作过，群绝对是在公园散步。建立一个群群基本上是以下三个简单的步骤：

1. 创建群集定义
2. 加入主机集群
3. 创建群集管理器

上述步骤的每一个与单个命令来完成：一个命令来创建集群定义，另一个主机添加到该群集，另一个创建集群管理器。而已！

注意，将主机连接到集群的命令必须在每个加入集群的主机上运行。一旦主机加入到集群中，它们就被称为节点。

你已经知道群

一旦你的群集群集启动并运行，你就会觉得很自在。集群的外观、气味和感觉都像普通的Docker。如果你知道Docker，你就知道Swarm。这是因为Swarm与Docker远程API基本兼容。

基本上，每一个码头工人主机运行客户端和守护进程。通过类似的命令 - 守护进程实现了泊坞远程API端点，并通过基于HTTP的API调用的客户机与后台程序搬运工人运行,泊坞窗PS,泊坞窗信息，以及其他。因为Swarm实现了这些API的大部分端点，所以您已经知道的大多数常规的老Docker命令仍然可以工作。

显然会有细微的差别。例如，特定信息而不是返回到一个码头工人主持人，泊坞窗信息和泊坞窗PS当在Swarm集群中运行时，命令返回与整个集群相关的信息。

这是伟大的。学习曲线如此之小，几乎不值得称之为曲线。

日程安排很简单

在一个群簇启动容器趋向于被称为调度。群目前有三种算法，以帮助它决定哪些在其上安排新容器集群中的节点：传播，BinPack和随机。

传播是默认的。它试图在所有节点集群中均匀地平衡容器。要做到这一点，它考虑到每个节点的可用的CPU和RAM，以及它已经运行的集装箱数量。

BinPack是spread的反义词。它通过调度单个节点上的所有容器，直到该节点被充分利用。然后，它开始在集群中的下一个节点上调度容器。BinPack的一个主要目标是使用尽可能少的基础设施——如果您要为云中的实例付费，这很好。它的名字来自于它的操作方式类似于我们填充垃圾箱(垃圾桶)的方式:在开始填充下一个之前先将一个装满到顶部。

随机，没错，是随机的。

调度功能强大

我最喜欢的詹士昌特点是约束。群可以让你的标签节点与我们自己的自定义标签的群集。然后，我们可以使用这些标签来约束其节点的容器可以开始。

例如，您可以根据地理位置标记节点，如“伦敦”、“纽约市”和“新加坡”。但它还不止于此。每个节点都可以使用多个标签进行标记。您可以根据节点部署的区域继续标记节点，例如“生产”或“开发”。我们甚至可以为平台添加另一个标签:“Azure”、“AWS”、“on-prem”等等。

利用这些标签，我们可以轻松地安排容器只从标记为“London”、“production”和“on-prem”的节点开始，所有这些都是通过常规方式完成的搬运工人运行命令。

标签是出奇的简单，但大量强大。

现在缺少的群

好吧，《蜂群》是很棒的，但它绝不是完成的文章。在这里，我将指出我认为尚未添加的最重要的特性。

我们已经说过，群不支持容器的自动重启动（还）。这是一大特色差距，但一个我希望很快堵塞。

群集管理器进程还没有HA(高可用性)。当Swarm 1.0版本发布的时候，我不会对Swarm Manager的HA感到惊讶。

与网络和存储整合是可以理解的限制。由于这样的事实，网络和存储是有大量的开发相对不成熟，仍泊坞窗的两个核心功能，我期待着与这些群的整合需要更长的时间才能到达。

当前，集群中的所有节点都需要运行相同版本的Docker——这无疑会给集群升级到最新版本的Docker带来挑战。

移除电池

Docker Inc.在Swarm和Machine、Compose等编配器组件上投入的时间和精力告诉我两件事:该公司认识到集装箱在规模上面临的挑战，并认真考虑让Docker成为大型企业的平台。

然而，群也不是没有竞争对手的。产品如中间层更成熟，更适合大规模部署，可以轻易取代Swarm。虽然这很好地符合“电池包括但可拆卸”的理念，但对于Docker Inc.来说，这可能会变得棘手。一方面，Docker Inc.想要一个强大的合作伙伴生态系统。另一方面，它需要赚钱。

借鉴了虚拟化巨头的例子：VMware是所有枪，炽烈致力于为客户提供整个堆栈 - 往往在其第三方生态系统为代价的。泊坞窗公司可能很难发现它不跟风作为把利润变得越来越重要。

最后一点——有点个人诉求:Docker缺乏系统管理员和IT运营人员是一个令人担忧的问题。Docker看起来将成为IT基础设施的一个基本组成部分，而我们正面临着系统管理员的巨大短缺。我们最不需要的是将像Docker这样的核心基础设施完全交给开发人员，这些开发人员虽然很优秀，但没有运行生产基础设施的经验。

为了系统管理者们在那里：让自己参与组织内的码头工人的任何部署，为时已晚之前。在传统的环境中，开发者应该对自己有什么容器内，并操作应该拥有什么之外。

这个故事，“回顾：多克群翱翔，天空的极限”最初发表信息世界 。