1.基本概念
Docker Swarm 和 Docker Compose 一样，都是 Docker 官方容器编排项目
但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具
而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合
从 Docker 1.12.0 版本开始，Docker Swarm 已经包含在 Docker 引擎中（docker swarm），并且已经内置了服务发现工具
我们就不需要像之前一样，再配置 Etcd 或者 Consul 来进行服务发现配置了
使用docker-compose部署集群实现负载均衡的时候，我们使在一台主机上面做的，不可以动态的拉神web服务的数量
因为使用docker-compose不满足实际生产环境的要求，因此不需要使用docker-compose了
实际当中我们的web（rs）服务器是要随着业务的增加而增加的
因此使用daoker内置的swarm集群来实现
swarm要求docker-compose必须v3版本以上
swarm自带docker stack会替代docker-compose其实docker-machine+docker-swarm，就可以实现自动部署docker和自动实现各种功能
2.Docker swarm的好处
可以实现：负载均衡，高可用（服务的自动迁移）动态拉神与压缩web服务器的数量
每一个节点都会拉起容器，而且都是调度器
但是监控只能在server1这个管理节点上面做
| Docker Machine | 创建 Docker 主机 |
|---|---|
| Docker Swarm | 配置集群节点 |
| Docker Service | 部署单个集群服务 |
| Docker Stack | 部署多个集群服务，以及 GUI 管理页面 |
docker-machine、docker swarm、docker node、docker service 和 docker stack 常用命令要知道
3.搭建实验环境
3台rhel7.3版本的虚拟机一共三台主机：server1 server2 server3server1是主节点（leader节点\manager节点）
| 主机信息 | 主机功能 |
|---|---|
| server1（172.25.2.1） | swarm集群的主节点，自身同时也是一个worker节点 |
| server2（172.25.2.2） | swarm集群的worker节点1 |
| server3（172.25.2.3） | swarm集群的worker节点2 |
（1）使用真机连接server1、server2和server3
（2）从真机给三个节点都发送一个nginx镜像
首先三台机子都必须安装docker，均有nginx的镜像这个我之前的实验已经做过，因此直接在上面做即可，不再演示安装docker服务的过程
（3）三个节点的docker服务已经安装好，并且实验环境干净
server1
server2
server3
4. Docker Swarm 配置集群节点具体的实现过程（手动搭建swarm集群）
昨天做了docker-compose之后，发现不是很灵活，现在我们使用docker swarm来部署docker集群不使用docker-compose了
（1）部署基本的swarm集群(Docker Service 部署单个集群服务,手动搭建)
自动实现集群部署、负载均衡、高可用
（1）在server1上面
server1是leader节点，因此在server1上面初始化集群
docker swarm init
（2）在server2上面
server2是worker节点，将server2也加入集群当中
（3）在server3上面
server3是worker节点，将server3也加入集群当中
（4）在server1上面
docker node ls集群已经创建好了
server1是管理节点，可以看到基本的swarm集群已经搭建成功
（5）在server1、server2、server3上面
导入nginx镜像
docker images
docker tag nginx:1.16 nginx
docker images
（6）在server1上面
准备部署使用容器部署nginx集群服务
docker service --help
docker service create --help
（7）在server1、server2、server3上面
集群部署好之后三个节点上面都会出现两个自动生成的网络
docker network ls
（8）在server1上面
docker service create --name web --replicas 3 --publish 80:80 nginx
利用nginx镜像运行容器，运行三个web（副本），副本个数不限制，会平均分配给三个节点
docker service ls查看总的服务
docker service ps web查看每个web服务运行在哪个节点
docker ps查看容器的运行情况
可以看到3个web刚好负载均衡给了三个节点
可以看到运行了一个容器
（9）在server2上面
docker ps可以看到运行了一个容器
（10）在server3上面
docker ps可以看到运行了一个容器
因为有三个web副本，因此刚好三个节点各自运行一个容器
如果是六个副本，那么三个几点各自运行两个容器
其实也不完全是平均分配的
副本数量比较少的时候是平均分配的，副本数量大的时候会根据节点的资源情况分配
（11）测试
浏览器访问172.25.2.1发现负载均衡的效果不是很明显
（12）在server1上面
docker ps
echo server1 > index.html
docker cp index.html id:/usr/share/nginx/html
（13）在server2上面
docker ps
echo server2 > index.html
docker cp index.html id:/usr/share/nginx/html
（14）在server3上面
docker ps
echo server3 > index.html
docker cp index.html id:/usr/share/nginx/html
（15）浏览器访问验证三个节点是否正常
172.25.2.1
172.25.2.2
172.25.2.3
（16）在真机上面验证负载均衡
for i in {1..10}; do curl http://172.25.2.1; done
for i in {1..10}; do curl http://172.25.2.2; done
for i in {1..10}; do curl http://172.25.2.3; done
总结：以上就实现了使用命令搭建swarm集群
（2）swarm集群中对运行web服务个数的拉伸
（1）在server1上面：拉伸副本的个数
docker service scale web=6由原来的三个变为六个
docker ps查看运行的容器个数，刚好两个web容器
（2）在server2上面
docker ps刚好两个web容器
（3）在server3上面
docker ps刚好两个web容器
（4）在真机上面
for i in {1..10}; do curl http://172.25.2.1; done
for i in {1..10}; do curl http://172.25.2.1; done
for i in {1..10}; do curl http://172.25.2.1; done
和刚才的相比，发现有默认发布页面，因为加入了新的web服务器
以上实现了基本的拉神，缩减也是这个道理
（3）实现利用监控页面监控集群中各个节点容器的运行情况（含缩减和拉伸）
利用图形监控更加直观形象
（1）从真机给server1拷贝一个监控镜像并且导入
注意：这个镜像只需要给管理节点（server1）即可
（2）在server1上面拉起监控的这个容器
在server1上面:
docker load -i ...
docker images
docker service create \
--name=viz \
--publish=8080:8080/tcp \注意端口映射
--constraint=node.role==manager \
--mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
dockersamples/visualizer
可以看到server1上面的监控容器正在运行
（3）直接在浏览器里面访问
172.25.2.1:8080
看到6个web服务运行的容器在三个节点上面，监控界面的容器运行在server1上
可以看出负载均衡、高可用、调度器、服务自动迁移
（4）在server1上面
docker servcie scale web=10拉神web服务的个数，其实就是增多容器的个数
free -m 可以查看一下三个节点的宿主机内存是否够用
（5）在浏览器里面进行查看
注意：不管为web的个数是多少，管理节点（自身也是worker节点）都会根据三个worker节点的资源使用情况合理分配并不一定是平均分配的，这一点一定要注意，因此说实现了负载均衡、高可用等等还有就是集群中的每个节点都应该有拉起容器的镜像，因为每个节点都有承担任务的可能性
（6）在server1上面
docker servcie scale web=5缩减web个数
可以看到server1上面运行了一个web容器
server2上运行了两个web容器
server3上也运行了两个web容器
（7）在浏览器里面查看
（8）同理：再次缩减为3个web并且查看
（9）在server3上面
systemctl stop docker
查看浏览器，发现server3出现问题，web会迁移，这就实现了高可用
（10）在server3上面
systemctl start docker
即使server3好了，服务也不会迁移回去
再次来新的web的时候他就会自动均衡给server3
查看浏览器
其实不论节点的个数是多少个，副本的个数不会被限制，而是负载均衡给集群当中所有的节点
再次压缩一下
这一点也体现了在负载均衡的时候哪个节点的性能好资源多，哪个节点就运行的容器多一点
（4）服务的滚动更新
查看一下命令的用法
拉神一下刚才web的个数
在浏览器里面查看
从真机给三个节点发送服务的镜像
给三个节点导入镜像并且查看
在server1上开始更新服务
更新策略：5s更新一次，一次更新两个
过一会在浏览里面查看，发现已经更新完毕，全部由nginx服务变为game2048服务
这10个容器本来运行的是nginx服务，现在运行的是game2048小游戏可能就是刚才的10个容器已经释放，重新拉起来10个容器注意：每个节点的镜像一定要到位
刷新，容器id一直在变化，这个更能看出负载均衡的效果
在server1上查看一下10个web容器运行的情况
在server1管理节点上面删除原来的10个web服务，只留下监控服务
可以看出server2和server3上面的容器也会立马释放
滚动更新服务演示完毕
（5）swarm的global模式的部署
某些特殊的以用场景，比如说：大型集群当中要对每个节点进行zabbix监控
那么只需要给每个节点部署一个zabbix-agent容器即可，global也就是保证每个节点时刻有且只有一个容器
在server1上以global模式部署集群
这里不需要指定副本的个数，因为global模式默认在每个节点之运行一个容器
如果指定副本个数就会报错，不信你可以试一下
可以看到server1上只有一个web容器
可以看到server2上只有一个web容器
可以看到server3上只有一个web容器
在浏览器里面查看
如果集群当中自动加入一个节点，那么管理节点就会自动在刚进来的节点上面运行一个容器
接下来实现一下
在真机当中再开启一台server4
因为目前运行的服务是game2048，因此给server4一个镜像
在server4上安装docker
给server4导入镜像并且查看
将server4加入集群当中
在server1上查看
可以看到一共4个容器服务，有一个还没起来，就是server4上的那个
查看web服务的细节
再次查看，已经运行
浏览器里面查看，可以看到已经自动为server4添加web服务
补充：对节点设置状态（“active”正常|“pause”暂停|“drain”排除自身work任务）
将server4设置为drain状态，也就是worker不再工作
这里缺少一张截图
在server1上查看各个节点的状态
在浏览器里面查看各个节点的状态
恢复server4为active状态
将server1设置为drain状态，server1上的worker容器会释放，但是监控的容器会正常工作
验证合理
恢复server1
来源：https://blog.csdn.net/ymeng9527/article/details/98867987