Docker_Swarm集群系统
Docker_Swarm集群系统
一．Docker Swarm 介绍
实践中会发现，生产环境中使用单个 Docker 节点是远远不够的，搭建 Docker 集群势在必行。然而，面对 Kubernetes, Mesos 以及 Swarm 等众多容器集群系统，该如何选择呢？它们之中，Swarm 是 Docker 原生的，同时也是最简单，最易学，最节省资源的，比较适合中小型公司使用。
Swarm 在 Docker 1.12 版本之前属于一个独立的项目，在 Docker 1.12 版本发布之后，该项目合并到了 Docker 中，成为 Docker 的一个子命令。目前，Swarm 是 Docker 社区提供的唯一一个原生支持 Docker 集群管理的工具。它可以把多个 Docker 主机组成的系统转换为单一的虚拟 Docker 主机，使得容器可以组成跨主机的子网网络。
Docker Swarm 是一个为 IT 运维团队提供集群和调度能力的编排工具。用户可以把集群中所有 Docker Engine 整合进一个「虚拟 Engine」的资源池，通过执行命令与单一的主 Swarm 进行沟通，而不必分别和每个 Docker Engine 沟通。在灵活的调度策略下，IT 团队可以更好地管理可用的主机资源，保证应用容器的高效运行。
Swarm是Docker官方提供的一款集群管理工具，其主要作用是把若干台Docker主机抽象为一个整体，并且通过一个入口统一管理这些Docker主机上的各种Docker资源。Swarm和Kubernetes比较类似，但是更加轻，具有的功能也较kubernetes更少一些。
Swarm的基本架构如下图所示，
二．Docker Swarm 优点
任何规模都有高性能表现
对于企业级的 Docker Engine 集群和容器调度而言，可拓展性是关键。任何规模的公司——不论是拥有五个还是上千个服务器——都能在其环境下有效使用 Swarm。
经过测试，Swarm 可拓展性的极限是在 1000 个节点上运行 50000 个部署容器，每个容器的启动时间为亚秒级，同时性能无减损。
灵活的容器调度
Swarm 帮助 IT 运维团队在有限条件下将性能表现和资源利用最优化。Swarm 的内置调度器（scheduler）支持多种过滤器，包括：节点标签，亲和性和多种容器部策略如 binpack、spread、random 等等。
服务的持续可用性
Docker Swarm 由 Swarm Manager 提供高可用性，通过创建多个 Swarm master 节点和制定主 master 节点宕机时的备选策略。如果一个 master 节点宕机，那么一个 slave 节点就会被升格为 master 节点，直到原来的 master 节点恢复正常。
此外，如果某个节点无法加入集群，Swarm 会继续尝试加入，并提供错误警报和日志。在节点出错时，Swarm 现在可以尝试把容器重新调度到正常的节点上去。
和 Docker API 及整合支持的兼容性
Swarm 对 Docker API 完全支持，这意味着它能为使用不同 Docker 工具（如 Docker CLI，Compose，Trusted Registry，Hub 和 UCP）的用户提供无缝衔接的使用体验。
Docker Swarm 为 Docker 化应用的核心功能（诸如多主机网络和存储卷管理）提供原生支持。开发的 Compose 文件能（通过 docker-compose up ）轻易地部署到测试服务器或 Swarm 集群上。Docker Swarm 还可以从 Docker Trusted Registry 或 Hub 里 pull 并 run 镜像。
综上所述，Docker Swarm 提供了一套高可用 Docker 集群管理的解决方案，完全支持标准的 Docker API，方便管理调度集群 Docker 容器，合理充分利用集群主机资源。
三．swarm的路由网络
对于验证过程，可以看到3个web的task分别运行在node1、2、3上，但为什么能够在node-1节点上通过localhost来访问web服务，并且得到从node-2上的容器返回的结果呢？这一切都归功于swarm routing mesh，它的工作原理如下图：
四．Swarm功能模块
这个图作为一个整体实际上都处于一个所谓的集群中，可能对应了一到多台的实际服务器。每台服务器上都装有Docker并且开启了基于HTTP的DockerAPI。这个集群中有一个SwarmManager的管理者，用来管理集群中的容器资源。管理者的管理对象不是服务器层面而是集群层面的，也就是说通过Manager，只能笼统地向集群发出指令而不能具体到某台具体的服务器上要干什么（这也是Swarm的根本所在）。至于具体的管理实现方式，Manager向外暴露了一个HTTP接口，外部用户通过这个HTTP接口来实现对集群的管理。对于稍微大一点的集群，最好是拿出一台实际的服务器作为专门的管理者，作为学习而言，也可以把管理者和被管理者放在一台服务器上。
docker swarm是docker官方提供的一套容器编排系统。它的架构如下：
1. swarm节点
swarm是一系列节点的集合，而节点可以是一台裸机或者一台虚拟机。一个节点能扮演一个或者两个角色，manager或者worker。
1.1 manager节点
Docker Swarm集群需要至少一个manager节点，节点之间使用Raft consensus protocol进行协同工作。
通常，第一个启用docker swarm的节点将成为leader，后来加入的都是follower。当前的leader如果挂掉，剩余的节点将重新选举出一个新的leader。
每一个manager都有一个完整的当前集群状态的副本，可以保证manager的高可用。
1.2 worker节点
worker节点是运行实际应用服务的容器所在的地方。理论上，一个manager节点也能同时成为worker节点，但在生产环境中，不建议这样做。
worker节点之间，通过control plane进行通信，这种通信使用gossip协议，并且是异步的。
2. stacks, services, and tasks
集群中经常谈到的stacks, services, tasks，他们之间的关系。
下面简单解释一下这三者的含义：
2.1 services
swarm service是一个抽象的概念，它只是一个对运行在swarm集群上的应用服务，所期望状态的描述。它就像一个描述了下面物品的清单列表一样：
- 服务名称
- 使用哪个镜像来创建容器
- 要运行多少个副本
- 服务的容器要连接到哪个网络上
- 应该映射哪些端口
2.2 task
在Docker Swarm中，task是一个部署的最小单元，task与容器是一对一的关系。
2.3 stack
stack是描述一系列相关services的集合。通过在一个YAML文件中来定义一个stack。
五. 多主机网络
在前面的章节中，学习过单主机网络，那个时候所有的容器都运行在一个docker host上，他们之间的通信一般使用本地的bridge网络即可。
在Swarm集群中，使用前面也简单提到过的overlay
network driver来让位于不同主机间的容器进行通信。网络模式如下图：
当然你也可以使用第三方提供的其他网络驱动，但对于swarm，还是推荐它自己的overlay network。
