前言

在云原生的世界，经过十多年的进化，Docker已经形成了较完备的“后勤”保障服务和建立了荣辱与共的“密友圈”。用一句话可以概括：“Docker走遍天下，Swarm功不可没”。

因此，我们需尽可能做到对Swarm有充分的认识，才能笑傲运维，笑傲云原生。今天博主带着各位继续深挖Swarm，熟练掌握它的核心能力。

Q：如何管理Swarm cluster

上图是一个基于Swarm的docker集群部署/运行架构图，在此图中你可以获得这样一个生产链条（基于Docker engine）：

序号	操作	目的
1	docker compose	基于Compose完成基础的容器编排并生成镜像。
2	docker swarm init	通过Docker engine创建Swarm集群。
3	docker service	通过Swarm向集群发布服务，一键启动多容器的集群。

一句话总结：通过Swarm + Compose的组合，你完全可以掌握docker的集群化管理之钥。那么，针对Swarm而言，它是怎么实现分布式容器部署并如何掌握它的动态管理机制呢？

1. Raft算法

这里，首先不得不提Raft算法了，在多数支持分布式的工具里，你都可以看到它的身影。

Raft是一种更为简单方便易于理解的分布式算法，主要解决了分布式中的一致性问题。相比传统的Paxos算法，Raft将大量的计算问题分解成为了一些简单的相对独立的子问题。——百度百科

博主不对算法本身做太多解释（如感兴趣，可查阅相关资料），我们只需知道这个算法是实现分布式选举的重要支撑。比如节点down了怎么办？

2. 心跳机制

在master-slave模式中，通常存在心跳检测机制。在manager节点中，我们通过docker info命令，可得知Swarm的心跳（默认5s）：

一旦manager出现down，会立即开始选举，创建新的leader；或者worker节点down，任务也会在其他worker进行自动迁移。

3. 动态扩容和缩容

Swarm支持动态扩容和缩容，什么意思？比如当前集群有2个worker，你可以随时邀请新的worker加入，也可以对已有的worker说：“go away”。只需要选择执行以下2个：

序号	操作	目的
1	docker swarm join – token xxx [MANAGER_HOST_IP]:2377	加入swarm集群
2	docker node update --availability drain [NODE_NAME]	剔除swarm集群中的成员
3	docker service scale [SERVICE_NAME]=扩展后的副本数量	动态分配任务

那么，如何验证它的扩容或缩容“如你所愿”？
简单，我们可做如下实验。前提是根据上篇文章（快捷方式）中的步骤，新建一个cluster（其中包含1个manager，2个woker）。

3.1 发布一个3副本的Service

3.1.1 查看当前cluster nodes

在manager节点中，通过docker node ls，得知当前实验集群中，有1个manager，2个worker，且看下图：

3.1.2 发布service

接下来，你可以通过如下命令，发布一个3副本的service（以nginx镜像为例）：

# --replicas指定副本个数，--network指定运行网络，--name指定容器名，-p指定映射端口
docker service create --replicas 3 --network service-nginx --name my_nginx -p 8888:80 nginx

发布完成后，可通过docker service ps my_nginx命令，查看服务的运行节点：

至此，你成功完成了Swarm集群的创建并发布了一个service（my_nginx），且每个节点（含manager）均运行了1个副本，接下来我们就可以进行情景推演了。

3.2 删除 worker node

3.2.1 剔除worker1

我们先来一个剔除worker的操作吧。在manager节点中，可以通过docker node update命令，改变worker1的状态为drain。

提示：drain节点代表不再受manager节点的支配，游离于集群之外。

docker node update --availability drain docker-worker1

执行后，结果为：

3.2.2 查看service运行节点

此刻，你可以通过docker service ps my_nginx命令观察到如下结果：

因为worker1节点罢工，所以woker2节点自动完成副本叠加，保障集群仍然是3副本运行状态。当然，你也可以通过登录worker1和worker2节点，查看（输入docker ps）各自认领的Task：

3.3 新增 worker node

上一节演示了worker down的情景，这一节我们再看看扩容后会发生什么。这里的扩容其实有2种实现方式：一种是通过docker swarm join实现，另一种就是通过docker node update实现。这里只呈现第2种方式。

3.3.1 恢复worker1

首先通过docker 把worker1恢复为active（待命状态）。

提示：active节点代表受manager节点的支配，是集群的一份子。

接下来，我们通过如下命令完成：

docker node update --availability active docker-worker1

结果为：

3.3.2 更改service scale

我们在manager节点中，通过增加副本实现service自动扩容，命令如下：

docker service scale my_nginx=6

结果显示，每个node均认领了2个Task：

4. docker down

当然，你也可以通过systemctl stop docker服务，制造“事故现场”，比如worker1宕机了：

此刻在manager节点中，再查看cluster nodes，发现worker1节点已Down：

接下来重复3.1.2节的动作，你会发现worker1真的光荣退休了：

结语

Docker Swarm提供了很多适合各类生产场景的选项和操作，你可以根据实际情况进行选择和部署。通过Docker集群化管理，可以免去不必要的重复操作，提高工作效率。

各位盆友，如有任何疑问，可留言O。

---

系列回顾

---

微服务实战系列之玩转Docker（十）
微服务实战系列之玩转Docker（九）
微服务实战系列之玩转Docker（八）
微服务实战系列之玩转Docker（七）
微服务实战系列之玩转Docker（六）
微服务实战系列之玩转Docker（五）
微服务实战系列之玩转Docker（四）
微服务实战系列之玩转Docker（三）
微服务实战系列之玩转Docker（二）
微服务实战系列之玩转Docker（一）
微服务实战系列之云原生