『高级篇』docker之DockerSwarm的了解（27）

原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『高级篇』docker之DockerSwarm的了解（27）

这次一起了解下docker Swarm，什么是dockerSwarm。

什么是docker Swarm

产品背景

使用docker的流程，ssh到一台服务器，运行docker命令来运行本机的docker服务，随着docker发展，越来越多的服务想要运行在docker容器中，如果在这样挨个的登录在每个ssh主机上管理容器，就非常的吃力了，而且我们的应用也需要高可用，也需要避免单点的故障，docker现有的能力已经很难满足这样的需求了，在这样的背景下，docker社区就产生类的dockerSwarm项目。

概念

什么是swarm，swarm这个名词比较贴切，swarm这个单词的意思就是动物的集群行为，比如我们常见的蜂群，鱼群，大雁南飞都可以成为swarm，swarm项目就是把多个docker 实例聚集在一起形成一个大的docker实例，对外提供集群服务，同时这个集群提供所有的api，用户可以相使用docker实例一样使用docker的集群。

昨日今日

docker swarm在1.12之前是一个独立的项目，需要单独下载，在1.12之后该项目就合并到了docker中，成为docker的子项目，目前docker唯一的一个原生支持docker集群的管理工具。

docker swarm的架构图

下面这个图，就可以看到docker swarm管理docker的一个架构图。以前使用docker命令行是针对docker主机的，然后到这台机器上单独的控制这台机器上的主机，有了swarm之后，客户端命令是针对docker集群的。它的命令几乎等同于docker的原生命令，它把命令发送给swarm，swarm选择发送一个节点去真正的执行，swarm是通过docker自带的远程的API，来实现对docker的控制。

下面这个图，这张图跟上面一张图描述的是一个事情，只不过它暴露了更多的的细节，上面的大框和下面的小框都代表了一台服务器，物理机或者虚拟机，我们从上面说，上面是swarm的一个manager节点，管理这个worker节点，可以看到管理了多少个cpu，多少个内存，每个上面运行的服务，每个服务的状况，比如他们的标签，他们的健康状态，Manager管理者每个节点的生命周期，比如加入一个节点，下线一个节点，manager还管理者每个服务的生命周期，服务的部署，更新，停止，删除，Node节点比较单纯他就运行了docker daemon，因为在1.12之后swarm已经融入了docker本身，开发一个远程的api给manager节点调度，运行具体的服务和容器，下面咱们一起看看服务的部署流程是怎样的，在这样的架构上是如何体现的。

环境的搭建

想想之前学习的mesos，需要先安装docker，Marathon，zookeeper，加入我们现在有5台liunx服务器，每个上面都装有docker，选择一台作为manager，上面执行下图的第一条命令，执行完之后会打印出来一个token作为dockerSwarm的凭证，然后在每个worker节点下执行第二条命令，表示要加入集群，只需要token和对应manager节点的ip和端口号，集群环境就搭建完毕了

如何部署

客户端的发起docker命令，两种方式

直接ssh到manager节点，执行docker命令。
通过远程访问的方式，通过Remote API调用manager上的docker命令，我们这张图画的就是第二种方式。

docker Client 在manager节点的外边，假如执行了docker service create，先会经过docker Deamon接受这条命令，传给Scheduler模块，Scheduler模块主要实现调度的功能，负责选择出来最优的节点，里面包含了2个子模块，Fiter 和Strategy，Fiter很明显是过滤节点，用来找出满足条件的节点（资源足够多，节点正常的），Strategy是过滤出来后选择出最优的节点（对比选择资源剩余最多的节点，或者找到资源剩余最少的节点），当然Fiter 和Strategy都是用户可以单独定制的，中间的Cluster是抽象的worker节点集群，包含了Swarm节点里面每个节点的信息，右边的Discovery是信息维护的模块，比如Label Health。Cluster最终调用容器的api，完成容器启动的刘而成。

调度模块

用户在创建服务的时候，选择最优的节点，选择最优节点的管理分为2个阶段。
过滤和策略

filter

Constraints

约束过滤器，根据当前的操作系统的类型，内核版本，存储的类型进行指标上的约束，也可以自定义约束。当前系统启动的时候可以通过label指定当前机器所具有的特性然后通过Constraints把他们过滤出来。

Affinity

亲和性过滤器，支持容器的亲和性和镜像的亲和性，比如一个应用，DB容器和web容器放在一起，就可以通过这个来实现，

Dependency

依赖过滤器，link等等吧Dependency会将这些容器放在同一个节点上，有依赖管理的会将创建的容器和依赖的容器放在同一个节点上。

Health filter

健康过滤器，根据节点的健康状态进行过滤，把有问题的节点去掉。

Ports filter

端口过滤器，根据端口的使用情况进行过滤，比如一个8080端口在某个主机上被占用，某些主机未被占用，会选用未被占用的那些主机。

Strategy

Binpack

在同等情况下，会使用资源最多的节点，通过这个策略可以让容器聚集起来。

Spread

在同等情况下，会使用资源最少的节点，通过这个策略可以让容器均匀的分布在每个节点上。

Random

随机选择一个节点。

服务发现

稍微有点复杂，根据场景来说吧

Ingress

基于物理网络之上的虚拟网络，Swarm的上层应用不在依赖于物理网络，并且能够让下面的物理网络保持不变，老铁就理解到这里就可以了，网络本身涉及到的东西太多了，应该也听过网络工程师，既然有这个职位肯定这个不是那么容易学的，在这里就不会深入的进行详解了。

PS：假定运行了一个nginx服务2个实例，nginx1 和nginx2，容器内的端口是80，主机内的端口是8080，这2个容器分别运行在node2和node3上，看到了吧node1虽然没有运行实例但是依然有8080端口在监听，一个集群在所有的worker节点上都是可以访问到的，随便选一个节点输入它的ip和8080端口就可以访问到，或者搭建一个负载均衡External LB，负责轮询的方式访问每个上边的8080端口，为什么在每个节点上都可以访问我们的服务呢？每个服务启动后所有的节点都会更新自己的VIP LB，把新的服务端口号和服务的信息建立一个关系，VIP LB是基于虚拟IP的负载均衡，VIP LB可以通过虚拟IP解析到真实IP，然后访问到服务。

Ingress+ link

就类型docker-compose，可以通过docker-compose.yml文件创建出来一组容器，他们之前通过link的方式进行访问，其实这种就类型docker-compose的link网络。

PS：也就是在Ingress之上多了一个link的场景，可以通过link的方式访问，也不需要主机的网络，link怎么实现的呢，如果让一个容器link到另一个容器很容易毕竟他们在一台主机上，一个服务link到另一个服务其实没有那么简单了，可能包含一个容器，也可能包含很多个容器，可能运行在一台机器上，也可能分布在多台机器上，我们如何实现可以通过名字来访问彼此呢，这用到了容器的dns，这里的nginx服务依赖于tomcat服务，nginx有2个实例，tomcat有一个实例，所有的nginx的容器都会对tomcat的解析，把它解析到tomcat的VIP，VIP负责做负载均衡，原理就是这样的原理，link的方式外部是访问不到的。link只适合swarm集群内部的场景。

自定义网络

使用自定义的网络，首先要创建网络，所有的网络都可以通过名字来连接彼此，而不需要link操作了。只要连接这个网络的彼此，都可以通过名字。底层来说它和link是类型的。通过dns来解析应用的名字。然后通过VIP LB的形式来进行负载均衡。

#创建自定义网络
docker network create --driver=overlay --attachable mynet

#创建服务
docker  service create -p 80:80 --network=mynet --name nginx nginx

Ingress 支持外部访问，Ingress+ link和自定义网络只能容器间进行访问。

服务编排

服务部署&服务发现（上边说到了）
服务更新 -- docker service update
服务扩缩容 -- docker service scale

Swarm

对外以Docker API 接口呈现

好处直接可以平滑的切换到docker swarm上。基本不需要改变现有的系统

容易上手，学习成本低

之前docker的经验可以完成继承过来。

轻量级，节省资源

专注docker集群的管理。插件的机制swarm的模块都抽象出来对应的API，可以根据自己的特点进行定制实现。

对docker命令参数支持完善

跟docker同步发布，docker的新的特性在dockerSwarm上都可以得到体现。

PS：docker Swarm基本都了解的差不多了。下次开始docker swarm的环境搭建。