解读docker swarm能力，实战演练Docker Swarm集群编排

背景

　   以前写过<<docker-compose真香>> 和《docker-compose、docker stack前世此生》两篇博客， 回顾一下思路：

① docker-compose是docker引擎顶层的容器编排工具(Python实现)，须要单独安装； docker stack 是docker引擎原生支持的容器编排技术(Go实现)

② 二者都支持最新docker-compose.yml 版本3容器编排文件，部分指令有差别。

③ docker-compose 能现场Build镜像，更适用于开发、测试时候单机迭代部署；docker stack须预先准备镜像，具有生产环境诸多特性。

昨天docker-compose编排的单机多容器忽然崩溃，为提升项目服务可用性评价值（SLA）， 决心切换到docker stack生产部署。

Docker Swarm优点

Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual Docker host.

Docker Swarm是Docker平台原生内置的集群编排技术，它将Docker主机池变成了 单个虚拟主机。

有不少理由促使你采用容器集群解决方案。随着应用程序的增加，将面临新的强制要求：例如可伸缩性，可管理性和高可用性。

Docker Swarm 直接优点：

1. Native  Clustering

2. Production Grade

3. Work out of the box

4. Easy to setup and use

5. Active Community

高可用支撑生产业务

　　Stack、Service、Container 金字塔模型定义了一个完整的生产应用架构：

• task是Docker Swarm中最小部署单位，task与容器Container是一对一的关系

• service是一个或一组容器在生产环境的预期状态（也可说是一组task的集合），在Worker节点上执行；有两种模式(对应下面docker-stack.yml-deploy-mode配置节)

• （默认）replicated: 指定容器数量
• global: 每一个节点一个容器(容器数量由可用节点决定)　

• stack 是一组服务，协做支撑整个业务

部署策略

  还支持 副本集、滚动更新、更新和回滚策略，以上配置均可以在docker-compose.yml 版本3官方文档找到对应的配置字段：

deploy：
  endpoint_mode: 服务发现的方式： vip，dnsrr
　labels： 为服务指定的标签
　mode：replicated （指定数量的容器）   global（每一个节点一个容器）
　replicas： 实例数量
　resources： 配置资源
　restart_policy：  重启策略
　update_config:  服务更新策略
　　 parallelism： 同时更新容器数量
　　 delay： 容器组更新的间隔时间
　　 failure_action:  更新失败的操做：continue、rollbak，pause（默认）
　　 monitor： 监视更新失败的等待时间
　　 max_failure_ratio: 更新的失败容错率
　　 order：操做策略：stop-first（先中止某容器，再建立新容器）、start-first （先建立新容器，因此会与即将消灭的容器有时间重叠）
  rollback_config： 回滚策略
　　　　...同上...

集群多节点部署

　　Docker Swarm在以多主机模型支撑业务，对于开发者/部署者来讲, 一个节点或多节点部署的配置流程是相似的。

  有两种形式节点： managers，workers

managers节点

• 维护集群状态  

使用Raft协议保持集群内部一致性；

测试目的，可使用单个manager运行swarm；（单manager fail， 服务继续运行）

• 调度服务
• 支撑swarm mode  HTTP endpoints

workers节点

      workers节点的惟一目的是执行容器，workers节点不参与Raft distributed state, make scheduling decisions, or serve the swarm mode HTTP API.

能够建立只有一个manager的群集，可是若是没有一个manager节点，则不可能有一个工做节点。

默认状况下，全部manager也是worker。在单个manager节点集群中，您能够运行诸如docker service create之类的命令，而调度程序会将全部任务放在本地引擎上。

  

Load Balancing

 + https://docs.docker.com/engine/swarm/key-concepts/#services-and-tasks

ingress load balancing

做用在外部要访问的服务上，通常服务会对外暴露一个port，（若是你没有指定的话，swarm manager会自动给这个服务分配一个PublishedPort ）

外部Clients能在集群任一节点的PublishedPort 上访问服务（不论这个节点当前是否有这个服务的running task）。

 服务发现（这里天然说的是Docker Stack中某个对外暴露的服务），有两种模式（对应docker-stack.yml： deploy---->endpoint_mode）

• vip:  Docker Swarm为服务分配1个虚拟ip，服务后有多少节点、服务请求到哪一个节点容器对于客户端是透明的。  默认
  
• dnsrr: Docker Swarm 为服务创建DNS记录，返回可用容器的ip列表， 客户端直接请求其中一个ip， 这种方式通常用于自建负载均衡器

internal load balancing：

做用在每一个服务上，swarm内部有一个DNS组件（自动为每一个服务分配dns条目），swarm manager使用依据DNS名称分发请求。

Docker Swarm网络模型

①  overlay network：覆盖物网络，顾名思义是附着在主机底层网络之上的网络， 这个网络保证了不一样主机之间容器通讯

②  ingress network：进入网络，顾名思义是外部客户端访问服务时，服务节点间负载均衡（节点在开放端口上收到请求，上交给IPVS，选择容器），是一种特殊的overlay网络。

③  docker-gwbridge: 将overlay网络链接到docker宿主机的网络，默认： 服务正在运行的每一个容器都链接到其本地Docker守护程序主机的docker_gwbridge网络

在初始化或刚加入Swarm集群时，会建立一个Ingress和 docker-gwbridge网络 

单机走向集群部署

本次将<<docker-compose真香>> 3容器改造目标：

• 三个服务---->nginx----> receiver------>app，服务容器经过名为webnet 的overlay网络通讯；

• nginx开放外部访问端口80和8080，关注ingress网络

• receiver， app服务须要访问宿主机上搭建的Redis， 关注docker-gwbridge网络

通常两个步骤： ① 搭建集群   ② 发布服务

  搭建Docker Swarm集群

单节点/多节点的初始化方式，可参考 docker swarm  -- help指令； 集群节点的管理可参考 docker  node --help指令

$ docker swarm --help Usage: docker swarm COMMAND Manage Swarm Commands: ca Display and rotate the root CA init Initialize a swarm join Join a swarm as a node and/or manager join-token Manage join tokens, 若是忘记Token，能够执行这个参数 leave Leave the swarm unlock Unlock swarm unlock-key Manage the unlock key update Update the swarm

  发布服务

 可以使用docker service create方式建立服务，我比较喜欢使用docker stack deploy搭配docker-stack.yml文件

 下面是生产部署中追加的production.yml，建立了一个名为eqidstack_webnet的overlay网络

version: "3.7"
services:
  proxy:
    networks:
      - webnet
  receiver:
    deploy:
      replicas: 1 
      restart_policy:
        condition: on-failure
    networks:
      - webnet
    volumes:
      - type: bind
        source: /home/eqidmanager/receiver.secrets.json
        target: /app/appsettings.secrets.json
  app:
    deploy: replicas: 2
      restart_policy:
        condition: on-failure
      update_config:
        parallelism: 1
        delay: 5s
        order: stop-first
    networks:
      - webnet
    volumes:
      - type: bind
        source: /home/eqidmanager/appsettings.secrets.json
        target: /app/appsettings.secrets.json
networks: webnet: 

# docker stack不加载同目录下的.env环境变量文件，原有适用于docker-compose工具的yml文件可采用变通方法
docker stack deploy -c <(docker-compose -f docker-stack.yml -f production.yml config) eqidstack

服务部署效果：

#docker stack ls：
NAME           SERVICES     ORCHESTRATOR
eqidstack      3       Swarm

#docker service ls:

ID 　　　　　　 NAME 　　　　　　     MODE 　　　　 REPLICAS 　 IMAGE 　　　　 　　　　　　　　　　　　 PORTS （服务对外暴露的端口）
jml6ecfa330r eqidstack_app 　     replicated    2/2 　　　　 12205599/eqidmanager:master
3381stpkirgj eqidstack_proxy      replicated   1/1 　　　　 nginx:latest 　　　　　　　　　　　　 *:80->80/tcp, *:8080->8080/tcp
vhz4ef8p4ffp eqidstack_receiver   replicated   1/1 　　　　 12205599/eqidreceiver:master

可经过 

docker network inspect ingress 验证容器eqidstack_proxy.1 链接到ingress网络；

docker network inspect eqidstack_webnet 验证有4个容器链接到 overlay网络

不停服更新/不停服扩容

 手动更新服务配置：docker service update  [opton]  {some_service_name}

咱们来为以上名为{eqidstack_proxy}的服务添加 [重启策略]

  手动扩容：docker service scale [option] {service=replicas}

为名为{eqidstack_proxy}的服务扩容为2容器

 可经过docker service  inspect eqidstack_proxy验证操做结果

总结

docker service 定义某个(副本集)容器在生产环境下的状态，通常业务含义上的服务相关；

docker stack 定义一组服务，服务间协做、调用，支撑整个业务架构；

docker swarm 管理一组服务在集群节点上的的部署

本文以 重难点解读+实战演练的方式记录Docker Swarm生产部署的过程，但愿能和你们查缺补漏，共同探讨。 

+ https://docs.docker.com/compose/compose-file/

+ https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/#manager-nodes

+ https://docs.docker.com/engine/swarm/key-concepts/#services-and-tasks

+ https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/