1、ドッカースウォームさんのプロフィール
- ドッキングウィンドウのバージョン1.12の前に別のプロジェクトに属し、スウォームドッカー1.12リリース後、ドッカーに組み込まれたプロジェクト、サブコマンドのDocke名になってきて
- 群れは、地域社会のネイティブサポートドッカードッカークラスタを管理するためのユニークなツールです
- スウォームは単一の仮想マシンからなる複数のドッカーホストシステムに変換することができます
- ドッカースウォームは、IT運用、保守チームのスケジューリングツールのためのクラスタリングとスケジューリング機能を提供しています
2、ドッカー群発利点
- 任意のサイズの効率的なパフォーマンスを持っています
- 柔軟なスケジューリングコンテナ
- サービスの継続的な可用性
- そして、ドッカーAPIの互換性と統合サポート
- ドッカー群発は、アプリケーション（例えばマルチホストネットワーキング及びストレージボリューム管理など）ドッカーのコア機能のネイティブサポートを提供します
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和自动实现各种功能
| ドッカーマシン | ドッカーホストを作成します |
|---|---|
| ドッカースウォーム | クラスタノードの設定 |
| ドッカーサービス | 単一のクラスタサービスを展開 |
| ドッカースタック | 展開複数のクラスタサービス、およびGUI管理ページ |
A、ドッカースウォームクラスター構造
（A）ビルド実験環境
3台rhel7.5版本的虚拟机一共三台主机：server1 server3 server4server1是主节点（leader节点\manager节点）server3、server4是（work节点）
| ホスト情報 | ホスティング機能 |
|---|---|
| SERVER1（172.25.6.1） | マスターノードの群れクラスタ自体もワーカーノードであります |
| server3の（172.25.6.3） | 労働者の群れのクラスタノード1 |
| SERVER4（172.25.6.4） | 労働者の群れのクラスタノード2 |
設定のテスト環境
実機からの3つのノード（1）は、画像を送信するnginxの
空の実験環境
テストループ情報を削除します。
docker image rm busybox ##删除上个实验的镜像
（2）各ホストの実験はドッカーサービスインストールされていることを確認します
rpm -qa | grep docker ##查看系统是否安装docker软件Server1で：
server3のオン：
SERVER4オン：
（3）、ドッカサービスを開きます
（4）実験環境情報を空にする
docker images ##查看docker镜像是否纯净
（5）、必要なソフトウェアをインストールします
yum install bash-* -y ##安装bash软件方便后续实验命令的输入Server1で：
server2のオン：
server3のオン：
（6）YUMソース情報を表示します
yum repolist ##查看yum源信息Server1で：
server3のオン：
SERVER4オン：
（二）、 Docker Swarm 配置集群节点具体的实现过程（手动搭建swarm集群）
上次做了docker-compose实验之后，发现不是很灵活，现在我们使用docker swarm来部署docker集群不使用docker-compose了
（1）部署基本的swarm集群(Docker Service 部署单个集群服务,手动搭建)
自动实现集群部署、负载均衡、高可用
在server1上：
server1是leader节点，因此在server1上面初始化集群
docker swarm init
在server3上：
server3是worker节点，将server3也加入集群当中
在server4上：
server4是worker节点，将server4也加入集群当中
（2）、在server1上面
[root@server1 ~]# docker node ls集群已经创建好了
server1是管理节点，可以看到基本的swarm集群已经搭建成功
（3）、在server1、server3、server4上导入nginx 镜像
导入nginx镜像
[root@server1 ~]# docker images ##查看镜像信息
[root@server1 ~]# docker load -i nginx.tar ##导入nginx镜像
在server1上：
在server4上：
在server3上：
（三）、在server1上：
（1）、查看创建 docker service 集群的相关命令
准备部署使用容器部署nginx集群服务
docker service --help
docker service create --help
在server1上:
docker service create --name web --replicas 3 --publish 80:80 nginx
利用nginx镜像运行容器，运行三个web（副本），副本个数不限制，会平均分配给三个节点
docker service ls查看总的服务
docker service ps my_web查看每个web服务运行在哪个节点
docker ps查看容器的运行情况
（2）、创建集群 集群的节点为3个 镜像为nginx
[root@server1 ~]# docker service create --name my_web --replicas 3 --publish 80:80 nginx
（3）、查看web服务对应的节点信息
[root@server1 ~]# docker service ps my_web查看每个web服务运行在哪个节点
（4）、在server1、server3、server4上面
集群部署好之后三个节点上面都会出现两个自动生成的网络
[root@server1 ~]# docker network ls ##查看网络信息如果不创建网络系统将会自动生成
手动创建网络信息
[root@server1 ~]# docker network create -d overlay my_net ##手动创建网络信息
（四）、测试
在真机上进行测试：
1、查看负载均衡的情况
curl 172.25.6.1
curl 172.25.6.3
curl 172.25.6.4访问server1：
访问server3：
访问server4：
（在实际的生产环境中每个节点存放的信息相同所以在主机中访问到的信息也相同）
2、模拟用户访问集群时集群的运作机制（负载均衡）
（1）、server1、server3、server4建立各个节点的发布目录
vim index.html
server1
在server1上：
将创建好的发布目录信息复制到nginx 默认的发布目录下
[root@server1 ~]# docker ps ##查看容器ID的信息
在server3上：
将创建好的发布目录信息复制到nginx 默认的发布目录下
在server4上：
将创建好的发布目录信息复制到nginx 默认的发布目录下
3、在真机上：
（1）、（集群的工作方式为每个节点依次访问集群某个结点的信息后才会访问下一个 节点的信息）
（2）、在真机上面验证负载均衡
for i in {1..10}; do curl http://172.25.6.1; done
for i in {1..10}; do curl http://172.25.6.3; done
for i in {1..10}; do curl http://172.25.6.4; done
总结：以上就实现了使用命令搭建swarm集群
二、swarm集群中对运行web服务个数的拉伸、缩减
1、在server1上面：拉伸副本的个数
docker service scale web=10 ##由原来的三个变为六0个
因为有三个web副本，因此刚好三个节点各自运行一个容器
如果是六个副本，那么三个几点各自运行两个容器
其实也不完全是平均分配的
副本数量比较少的时候是平均分配的，副本数量大的时候会根据节点的资源情况分配
1
2、查看节点的信息
[root@server1 ~]# docker service ps my_web ##查看结点的信息
3、查看拉伸后节点循环机制
注：拉伸后的节点会被均匀分配到每个集群节点中所以访问时回访问到新创建的结点的信息
三、实现利用监控页面监控集群中各个节点容器的运行情况（含缩减和拉伸）
利用图形监控更加直观形象
1、在官网上查看相应的配置信息
第一步：
https://github.com ##在网页上输入网址
第二步：
在搜索页面输入visualizer 进行搜索
visualizer 
第三步：
查看官方的服务信息
查看visualizer软件的安装包
2、导入镜像
（1）、visualizer分别在server1、server3、server4 上导入visualizer镜像
导入visualizer镜像
（2）、在官网上查看相关visualizer监控页面创建的命令
3、在server1上面拉起监控的这个容器
[root@server1 ~]#
4、查看监控信息是否已经建立
[root@server1 ~]# docker service ps viz
5、在测试的网页上输入
172.25 .6.1：8080查看到的是之前创建好的10个节点
注意：不管为web的个数是多少，管理节点（自身也是worker节点）都会根据三个worker节点的资源使用情况合理分配并不一定是平均分配的，这一点一定要注意，因此说实现了负载均衡、高可用等等还有就是集群中的每个节点都应该有拉起容器的镜像，因为每个节点都有承担任务的可能性
6、在server1上对web进行缩减
（1）、
[root@server1 ~]# docker servcie scale web=3 ## 缩减web个数
（2）、测试：
7、进行web的拉伸
（1）、在server1上面
[root@server1 ~]# docker servcie scale web=40 #拉伸web个数为40个
（2）、测试：
四、web服务与节点的状态的关系
1、验证集群中的一个节点 挂掉之后 在其上面运行的web 服务将会迁移到其他节点上
（1）、在server4上关闭docker服务
systemctl stop docker
查看浏览器，发现server4出现问题，web会迁移，这就实现了高可用
在server4上:
关闭docker
[root@server1 ~]# systemctl stop docker ##关闭docker服务
（2）在真机上测试：
（发现server4上的web服务迁移到server3上运行）
验证坏掉的节点恢复正常后，集群不能自动给它分配任务
2、开启server4节点验证web容器会不会回迁
（1）、在server4上：
systemctl start docker
即使server4好了，服务也不会迁移回去
再次来新的web的时候他就会自动均衡给server3
查看浏览器
[root@server4 ~]# systemctl start docker ##将挂的server4节点重新打开 
（2）、查看节点的状态
[root@server1 ~]# docker node ls ##查看集群节点的状态
（3）、在visualizer监控页面上观察server4节点上的情况
（server4节点被激活后系统并不能自动的给它分配容器）其实不论节点的个数是多少个，副本的个数不会被限制，而是负载均衡给集群当中所有的节点
体现了在负载均衡的时候哪个节点的性能好资源多，哪个节点就运行的容器多一点
五、服务的滚动更新
1、先将要更新的镜像导入各个节点中
在server1上：
在server3上：
（2）、查看镜像是否被成功的导入
在server4上：
2、查看集群滚动更新的命令用法
[root@server1 ~]# docker service updata --help ## 查看集群滚动更新的方法
3、输入更新的命令
[root@server1 ~]# docker service update --image game2048 --update-parallelism 5 --update-delay 2s nginx ##表示用gam2048 更新nginx 每2s 更新5个
4、在网页上查看更新的情况：
nginx全部被game2048 取代
5、在网页上访问server3
访问的是2048到的游戏页面、说明更新成功
