docker集群——初识Swarm

       为Docker构建原生的集群管理工具的计划早在2014年初就开始了，当时做为一个通讯协议项目，称为Beam。以后，它被实现为一种后台程序，使用Docker API来控制异构化的分布式系统。项目从新命名为libswarm，Swarmd是其后台程序。项目保持了以前的理念，容许任何Docker客户端链接到Docker Engine池里。该项目的第三代被从新进行设计，使用相同的Docker Remote API集，而且在2014年11月份重命名为“Swarm”。基本上，Swarm最重要的部分就是其远程API；维护人员经过努力工做，让这些API和Docker Engine的全部版本100%兼容。咱们称Swarm第一代为“Swarm v1”。

　　2016年2月份，核心团队发现中央服务的扩展被限制以后，Swarm在内部被再次从新设计为swarm.v2。此次，使用了去中心化的集群设计。2016年6月份，发布了SwarmKit，能够做为任意规模的分布式服务的编排工具包。在DockerCon 2016大会上，Docker宣布SwarmKit合并入Docker Engine。这一版本的Swarm称为“Swarm v2”或者“Swarm Mode”。

 

　　以后咱们会一步步体会到，三剑客（Docker Swarm、Docker Machine和Docker Compose）一块儿使用时表现最佳，它们之间无缝集成在一块儿，几乎已经没法将某一个当成单独的部分。

• 使用Docker Machine，用户能够预配机器，能够是虚拟机器也能够是物理机器，并能够在若干云平台以及纯物理机器上运行docker容器。
• 使用Docker Compose，用户能够快速定义Dockerfile，经过简单可是强大的YAML语法描述行为，而且只须要将这些文件“组合”起来就能够启动应用程序。

集群工具和容器管理

       集群工具是一种软件， 容许运维人员和单个终端沟通，其能够向一系列资源发送命令前编排这些资源。取代在集群上手动分发工做负载（容器）的方式，集群工具用来自动化这些任务以及其余不少任务。集群工具用来自动化这些任务以及其余不少任务。集群工具决定在哪里启动job（容器），如何存储job，何时最终重启job等。运维人员仅仅须要配置一些行为，据顶集群的拓扑和规模、调优设置，而且启用或者停用高级特性。Docker Swarm就是这样一种容器的集群工具。

        除了集群工具，咱们还能够选择容器管理器平台。它们不提供容器托管，可是它们和一个或者多个已有系统交互；这样类型的软件一般都是提供了很好的web接口、监控工具，以及其余可视化或者高层级功能。Rancher和Tutum就是这样的容器管理平台。

Docker Swarm的基础和架构

Docker自身对Swarm的描述以下：

　　Docker Swarm是Docker的原生集群。它将Docker宿主机池转变成单个虚拟的Docker宿主机。

Swarm是一种工具，让用户觉得本身管理的是单个巨大的Docker宿主机，而这个宿主机是由不少Docker宿主机组成的。这些主机看上去是一体的，而且使用一个命令行入口点。Swarm让用户在这些主机上编排而且操做必定数量的容器，使用常规的Docker工具、Docker原生工具或者python-docker客户端，甚至能够选择直接curl到Docker Remote API上。

为何使用Swarm

使用容器集群解决方案有不少缘由。随着应用程序的壮大成熟，咱们会遇到不少全新的需求，好比可扩展性、可管理性以及高可用性。市场上有不少可用的工具，使用Docker Swarm能够带来以下优点：

• 原生集群：Swarm是Docker原生的，由Docker团队和社区开发。不须要任何额外的需求，Swarm就能够和Machine、Compose以及生态系统里的其余工具集成。
• 生产环境可用：Swarm v1在2015年11月份成熟，而且能够在生产环境里使用。研发团队已经证实Swarm可以扩展到控制1000个节点的Engine。Swarm v2由于使用了去中心化的发现机制，容许构建数千个节点的集群。
• 开箱即用：Swarm不要求用户从新构建本身的应用程序来适配其余的编排工具。用户可使用本身的Docker镜像和配置，不须要任何改动，就能够实现大规模部署。
• 易于搭建和使用：Swarm很容易操做。仅仅经过在Machine命令里添加一些参数，或者使用Docker1.12版本后的Docker命令，就能够实现高效部署。将发现服务集成到Swarm Mode里，使其能够快速安装——不须要搭建外部的Consul、Etcd或者Zookeeper集群。
• 活跃的社区：Swarm是一个有活力的项目，有很是积极的社区支撑，开发很快速。
• Hub上可用：用户不须要安装Swarm，它是一个Docker镜像（Swarm v1），所以用户仅仅须要从Hub里拉去这个镜像就能够运行，或者它已经集成进Docker Engine。Swarm Mode已经集成进Docker1.12+版本了。

宠物模型  VS 牛群模型

在建立而且利用基础架构时有两种对立的方案：宠物模型 VS 牛群模型

• 宠物模型：管理员部署服务器或者虚拟机，而且对其持续进行维护。登陆机器或容器，安装软件，完成配置，而且确保一切运行正常。所以，这些机器或者容器是管理员的宠物。
• 牛群模型：管理员把基础架构当成牛群模型时，他们并不关心基础架构某个组件的命运。管理员不会登陆到任何单元里，也不会作手动处理。相反，他们使用批量方案，借助自动化工具完成部署、配置以及管理。若是某个服务器或者容器死机了，它会被自动复活，或者生成另外一个服务器或者容器来替代有问题的组件。所以，在这种场景下，运维人员管理的是牛群模型。

Swarm特性

Swarm核心特性以下：

• Swarm v1支持1.6.0版本或更新版本的Docker Engine。从1.12版本开始，Swarm v2内嵌到了Docker Engine里。
• Swarm每一个版本的API都和同版本的Docker API兼容。API能够向后兼容一个版本。
• 在Swarm v1里，为多个Swarm主节点的实现，选主机制使用的是主库（仅仅在使用发现服务，如Etcd、Consul或者Zookeeper部署Swarm时才支持）。
• 在Swarm v2里，使用去中心化的机制来构建选主机制。Swarm v2再也不须要特定的发现服务，由于他集成了Etcd，这是Raft公式算法的一种实现。
• 在Swarm v1的术语里，主Swarm master节点被称为primary（主节点），其余master节点被称为replica（副本）。在Swarm v2里，有Master和Worker节点的概念。集群使用Raft自动管理主节点。
• 基础和高级调度选项。schedule（调度器）是一种决定容器物理上放置于哪台主机的算法。Swarm使用一系列内置的调度器。
• Constraint（约束条件）和affinity（共同关系）辅助运维人员作出调度决策。好比，某个用户想要让数据库容器物理上接近，就能够通知调度器去这么作。约束条件和共同关系使用Docker Swarm label（标签）。
• 在Swarm v2里，使用内建DNS Round-Robin实现集群内的负载均衡，也支持外部负载均衡，经过路由网络机制，由IPVS实现。
• 高可用和故障恢复机制意味着用户能够建立超过一个master的Swarm。所以，若是某个master服务宕机了，还有其余master能够继续控制。当构建至少3个节点的集群时，默承认用Swarm v2。全部节点均可以做为master节点。另外，Swarm v2包括健康指标信息。

其余开源编排工具的不一样之处:

能够参考：巅峰对决之Swarm、Kubernetes、Mesos

Swarm v1架构

 

先从管理器部分开始介绍，图片的左侧有一个标为Docker Swarm API 的长方形。Swarm暴露出一系列和Docker相似的远程API，用户可使用任意Docker客户端链接到Swarm上。可是，Swarm API和标准的Docker远程API略有不一样，由于Swarm API还包含集群相关的信息。好比，在Docker Engine上运行docker info能够获得单个Engine的信息，可是若是在Swarm集群上调用docker info，则会获得集群里的节点数量以及每一个节点的信息和健康情况。

Docker Swarm API 旁边的长方形是集群抽象。这是一个抽象层，容许不一样类型的集群实现为Swarm的后端，而且共享同一组Docker远程API。目前有两种集群后端实现：内建Swarm集群实现和Mesos集群实现。Swarm集群和内建调度器的长方形表示内建的Swarm集群实现，而标识为Mesos集群的长方形则表示Mesos的集群实现。

Swarm后端的内建调度器包含一些调度策略。两种策略分别是Spread和BinPack，若是对Swarm策略比较熟悉，就会注意到这里缺失了Random策略。Random策略没有包含在这里是由于其仅做为测试用途。

和调度策略并排，Swarm仍是用了一系列调度过滤器，过滤掉不知足条件的节点。这里有六种类型的过滤器：Health、Port、Container Slots、Dependency、Affinity和Constraint。当调度新建的容器时，它们就以这个顺序应用到过滤器上。

在代理部分，Swarm代理尝试将其Engine的地址注册到发现服务里。

最后，中间的部分——发现服务，在代理和管理之间协调Engine的地址。目前使用的基于代理的发现服务是LibKV，它将发现功能委派给用户所选择的键值存储，Consul、Etcd或者Zookeeper。相对比而言，咱们还能够不使用任何键值存储，仅仅使用Docker Swarm管理器。该模式称为无代理发现，包括File和Node（在命令行指定地址）。

术语

• Docker Engine是运行在宿主机上的Docker daemon。
• Docker Compose是一个工具，以YAML的格式描述多容器服务的架构方式。
• Docker stack是建立多容器的应用程序（由Compose描述），而不是单个容器的二进制结果。
• Docker daemon和 Docker Engine 这两个术语意思同样，能够互相替换。
• Docker客户端是打包在同一个docker可执行文件里的客户端程序。好比，当运行docker run时，使用的就是Docker客户端。
• Docker网络是软件定义的网络，将一系列容器连接到同一个网络里。默认使用Docker Engine自带的libnetwork（https://github.com/docker/libnetwork）实现。可是用户可使用插件选择部署第三方的网络驱动。
• Docker Machine是一个工具，用来建立可以运行Docker Engine的称为机器的主机。
• Swarm v1里的Swarm节点是预先安装了Docker Engine的机器，而且同时运行着Swarm的代理程序。Swarm节点会将其自身注册到发现服务里。
• Swarm v1里的Swarm master是运行Swarm管理器程序的机器。Swarm master从其发现服务里读取Swarm节点的地址。
• 发现服务是Docker提供的基于令牌的服务或者自托管的服务。对于自托管的服务，用户能够运行HashiCorp Consul、CoreOS Etcd，或者Apache Zookeeper做为键值存储来提供发现服务。
• 选主是Swarm Master所实现的机制，用来肯定主节点。在主节点下线以前，其余Master节点都做为副本角色存在，主节点下线后，就会再次启动选主程序。Swarm Master的数量必定是奇数。
• SwarmKit是由Docker发布的全新Kit，用来抽象编排。理论上，它应该可以运行任何类型的服务，可是实际目前它仅仅编排容器或者容器集。
• Swarm Mode是全新的Swarm，自Docker 1.12版本后能够用，它将SwarmKit集成到了Docker Engine里。
• Swarm Master（在Swarm Mode里）是一个管理集群的节点：它调度服务，维护集群的配置（节点、角色和标签），而且确保仅仅存在一个集群领导者。
• Swarm Worker（在Swarm Mode里）是一个运行任务的节点，运行如托管服务器任务。
• 服务是工做负载的抽象。好比，用户可让服务“nginx”复制10次，意味着用户将有10个任务（10个nginx容器）分布在集群上，而且由Swarm自身作负载均衡。
• 任务是Swarm的工做单元。一个任务就是一个容器。