Docker集群管理之Swarm介绍

1 Swarm背景
Docker自诞生以来，其容器特性以及镜像特性给DevOps爱好者带来了诸多方便。然而在很长的一段时间内，Docker只能在单host上运行，其跨host的部署、运行与管理能力颇受外界诟病。跨host能力的薄弱，直接导致Docker容器与host的紧耦合，这种情况下，Docker容器的灵活性很难令人满意，容器的迁移、分组等都成为很难实现的功能点。
Swarm是Docker公司在2014年12月初新发布的容器管理工具。和Swarm一起发布的Docker管理工具还有Machine以及Compose，号称Docker三剑客。
Swarm项目是Docker公司发布三剑客（Swarm，Compose，Machine）中的一员，用来提供容器集群服务，目的是更好的帮助用户管理多个Docker Engine，方便用户使用，像使用Docker Engine一样使用容器集群服务。
现实中我们的应用可能会有很多，应用本身也可能很复杂的，单个docker engine所能提供的资源未必能够满足要求。而且应用本身也会有可靠性这样的要求，希望避免单点故障，这样的话势必需要分布在多个docker engine。在这样一个大背景下，Docker社区就产生了Swarm项目。

Swarm项目正是这样，通过把多个Docker Engine聚集在一起，形成一个大的docker-engine，对外提供容器的集群服务。同时这个集群对外提供Swarm API，用户可以像使用Docker Engine一样使用Docker集群。

2 Swarm简介
Swarm是一套较为简单的工具，用以管理Docker集群，使得Docker集群暴露给用户时相当于一个虚拟的整体。Swarm使用标准的Docker API接口作为其前端访问入口，换言之，各种形式的Docker Client(dockerclient in go, docker_py, docker等)均可以直接与Swarm通信。
Swarm的设计和其他Docker项目一样，遵循“batteries included but removable”原则。笔者对该原则的理解是：batteries included代表设计Swarm时，为了完全体现分布式容器集群部署、运行与管理功能的完整性，Swarm和Docker协同工作，Swarm内部包含了一个较为简易的调度模块，以达到对Docker集群调度管理的效果；“but removable”意味着Swarm与Docker并非紧耦合，同时Swarm中的调度模块同样可以定制化，用户可以按照自己的需求，将其替换为更为强大的调度模块，如Mesos等。另外，这套管理引擎并未侵入Docker的使用，这套机制也为其他容器技术的集群部署、运行与管理方式提供了思路。

3 Swarm 特点
对外以Docker API接口呈现，这样带来的好处是，如果现有系统使用Docker Engine，则可以平滑将Docker Engine切到Swarm上，无需改动现有系统。
Swarm对用户来说，之前使用Docker的经验可以继承过来。非常易上手，学习成本和二次开发成本都比较低。同时Swarm本身专注于Docker集群管理，非常轻量，占用资源也非常少。
“Batteries included but swappable”，简单说，就是插件化机制，swarm中的各个模块都抽象出了api，可以根据自己一些特点进行定制实现。
Swarm自身对docker命令参数支持的比较完善，Swarm目前与Docker是同步发布的。Docker的新功能，都会第一时间在Swarm中体现。

4 Swarm框架结构

 Swarm对外提供两种API， 一种是DockerAPI，用于负责容器镜像的生命周期管理， 另外一种是Swarm集群管理CLI，用于集群管理。
 Scheduler模块，主要实现调度功能。在通过Swarm创建容器时，会经过Scheduler模块选择出一个最优节点，里面包含了两个子模块，分别是Filter和Strategy， Filter用来过滤节点，找出满足条件的节点（比如资源足够，节点正常等等），Strategy用来在过滤出的节点中根据策略选择一个最优的节点（比如对找出的节点进行对比，找到资源最多的节点等等）, 当然Filter/Strategy用户可以定制。
 Swarm对集群进行了抽象，抽象出了Cluster API，Swarm支持两种集群，一种是Swarm自身的集群，另外一种基于Mesos的集群。
 LeaderShip模块用于Swarm Manage自身的HA，通过主备方式实现。
 Discovery Service 服务发现模块，这个模块主要用来提供节点发现功能。
在每一个节点上，都会有一个Agent，用于连接Discovery Service，上报docker Daemon的IP端口信息，Swarm Manage会直接从服务发现模块中读取节点信息。

Swarm架构中最主要的处理部分自然是Swarm节点，Swarm管理的对象自然是Docker Cluster，Docker Cluster由多个Docker Node组成，而负责给Swarm发送请求的是Docker Client。

5 Swarm各个模块介绍
5.1 集群管理
swarm Manage CLI用于集群管理。大家可以看这张图，通过三部就可以将集群创建起来。

Swarm容器集群创建完成后，就可以采用docker命令，像使用Docker engine一样使用Swarm集群创建容器了。
5.2 服务发现
服务发现，在swarm中主要用于节点发现，每一个节点上的agent会将docker-egine的ip端口注册到服务发现系统中。Manager会从服务发现模块中读取节点信息。Swarm中服务发现支持已下3中类型的后端。
第一种，是hosted discovery service，是Docker Hub提供的服务发现服务，需要连接外网访问。
第二种，是KV分布式存储系统，现在已支持etcd、zookeeper、consul三种。
第三种，是静态IP：可以使用本地文件或者直接指定节点IP，这种方式不需要启动额外使用其他组件,一般在调试中会使用到。
5.3 Scheduler
调度模块主要用户容器创建时，选择一个最优节点。在选择最优节点过程中，分为了两个阶段：
第一个阶段，是过滤。根据条件过滤出符合要求的节点,过滤器有以下5中，
(1): Constraints，约束过滤器，可以根据当前操作系统类型、内核版本、存储类型等条件进行过滤，当然也可以自定义约束，在启动daemon的时候，通过Label来指定当前主机所具有的特点。
(2) : Affnity，亲和性过滤器，支持容器亲和性和镜像亲和性，比如一个web应用，我想将db容器和web容器放在一起，就可以通过这个过滤器来实现。
(3) : Dependency，依赖过滤器。如果在创建容器的时候使用了--volume-from/--link/--net某个容器，则创建的容器会和依赖的容器在同一个节点上。
(4) : Health filter，他会根据节点状态进行过滤，会去除故障节点。
(5) : Ports filter，会根据端口的使用情况过滤。
调度的第二个阶段是根据策略选择一个最优节点。有以下三种策略
(1) : Binpack，在同等条件下，选择资源使用最多的节点，通过这一个策略，可以将容器聚集起来。
(2) : Spread，在同等条件下，选择资源使用最少的节点，通过这一个策略，可以将容器均匀分布在每一个节点上。
(3) : Random，随机选择一个节点。
5.4 Leadership
Leadership模块，这个模块主要用来提供swarm manager自身的HA。

为了防止Swarm Mange单点故障，引入了HA机制，Swarm Manage自身是无状态的，所以还是很容易实现HA的。 实现过程中采用主备方式，当主节点故障以后，会从新选主提供服务，选主过程中采用分布式锁实现，现在支持etcd、zookeeper、consul三种类型的分布式存储，用来提供分布式锁。 当备节点收到消息后，会将消息转发给主节点。

6 Swarm与三剑客项目集成
三剑客是docker公司去年底发布的三个项目，这三者是可以紧密协作的。可以看一下这张图

最下面是Machine，通过machine可以在不同云平台上创建出包含docker-engine的主机。Machine通过driver机制，目前支持多个平台的docker-egine环境的部署，比如亚马逊、openstack等。 Docker engine创建完以后，就该swarm上场了，swarm将每一个主机上的docker-eg***管理起来，对外提供容器集群服务。最上面是compose项目，compose项目主要用来提供基于容器的应用的编排。用户通过yml文件描述由多个容器组成的应用，然后由Compose解析yml，调用docker API，在swarm集群上创建出对应的容器。
我们知道现在围绕Docker已经产生了很大的一个生态圈。 因此swarm不仅在和自家兄弟集成，也能积极和周边的一些项目集成。比如，swarm现在已经可以和mesos进行集成。Swarm与Mesos集成时，也是以Framework方式集成，实现了Framework所需的接口。这个大特性处在experiment阶段。