【每天学一点】docker-compose中的deploy

起因

由于要进行服务的微服务化部署，由于硬件限制，我们目前采用的是Swarm作为容器编排的工具。对应于k8s中的pod，swarm中有dab这种概念，即分布式应用包，目前还没有去探索这个的使用，由于还是实验性的特性，目前还不涉及，这里主要还是通过docker-compose.yaml的方式将多个微服务统一运维。

采用的技术

使用的是docker stack deploy <args>命令进行的部署。

官网上该命令有如下的参数：

docker stack 的可选参数

由于使用的是docker-compose文件，这里直接通过compose-file进行部署即可，例如官网的例子

docker stack deploy --compose-file docker-compose.yml vossibility

甚至可以通过叠加compose文件，来修改前一个文件中的配置

docker stack deploy --compose-file docker-compose.yml -c docker-compose.prod.yml vossibility

那么再来看看其他的可选命令：
namespace和kubeconfig是k8s的专属命令，这里就不做过多解释，直接看swarm相关的。

可选参数	参数含义
prune	表示削减不再引用的服务
resolve-image	请求仓库来重新解析镜像的摘要和支持的平台
with-registry-auth	发送仓库的授权详情到Swarm代理
orchestrator	使用的容器编排服务

目前觉得prune这个参数比较关键，可以把一些down掉的service进行自动清理。

回归正题

如何通过docker-compose.yml配置文件进行集群化部署呢?

首先需要知道的，docker-compose文件中哪个部分主要对应了swarm中的运维需求，答案就是deploy参数下的各种配置。

deploy下的各种配置

上图中的配置一个个来看;

首先来看，最下面标注的docker stack deploy不支持的参数，具体可以参考下图：

不支持的参数

上面的参数，就算yaml中包含，在stack的时候也会被忽略，当然也可以为了docker-compose up留着这些配置。

下面对于各个参数的说明中的例子，直接偷懒粘贴官网的例子了。

endpoint_mode:

这个命令是在 3.2版本中开始引入的，主要是用于指定服务发现方法，以方便外部的客户端连接到swarm

主要包含两个：

• vip: 这个是默认的方案。即通过虚拟的IP对外暴露服务，客户端无法察觉有多少个节点提供服务，也不知道实际提供服务的IP和端口。
• dnsrr：这个是DNS的轮询调度。客户端访问的时候，Docker会通过DNS列表返回对应的服务一系列IP地址，客户连接其中的一个。这种方式通常用于使用自己的负载均衡器，或者window和linux的混合应用。

version: "3.9"

services:
  wordpress:
    image: wordpress
    ports:
      - "8080:80"
    networks:
      - overlay
    deploy:
      mode: replicated
      replicas: 2
      endpoint_mode: vip

  mysql:
    image: mysql
    volumes:
       - db-data:/var/lib/mysql/data
    networks:
       - overlay
    deploy:
      mode: replicated
      replicas: 2
      endpoint_mode: dnsrr

volumes:
  db-data:

networks:
  overlay:

labels

标签是用于service之上，并非附加在service中的容器上。

如果像将其附在所有容器上，则在deploy之外定义labels.

version: "3.9"
services:
  web:
    image: web
    deploy:
      labels:
        com.example.description: "This label will appear on the web service"

mode

用于指定是以副本模式(默认)启动还是全局模式，如果是全局模式，类似于开始于k8s中的DaemonSet，会在每个节点上启动且只启动一个服务。

version: "3.9"
services:
  worker:
    image: dockersamples/examplevotingapp_worker
    deploy:
      mode: global

placement

这个参数在运维的时候尤为关键，主要用于指定容忍和偏好，这个在k8s中同样有对应的概念

version: "3.9"
services:
  db:
    image: postgres
    deploy:
      placement:
        constraints:
          - "node.role==manager"
          - "engine.labels.operatingsystem==ubuntu 18.04"
        preferences:
          - spread: node.labels.zone

其中，容忍包含了:

node attribute	matches	example
node.id	节点id	node.id==2ivku8v2gvtg4
node.hostname	节点主机名	node.hostname!=node-2
node.role	节点角色 (manager/worker)	node.role==manager
node.platform.os	姐节点操作系统	node.platform.os==windows
node.platform.arch	节点架构	node.platform.arch==x86_64
node.labels	用户定义的labels	node.labels.security==high
engine.labels	Docker 引擎的 labels	engine.labels.operatingsystem==ubuntu-14.04

容忍，表示服务可以部署在符合容忍限定的节点上。

至于偏好,只有一个参数，就是spread，其参数值为节点的属性，即容忍表中的内容。

偏好，表示的是服务可以均匀分布在指定的标签下，如：node.labels.zone这个标签在集群中有三个值，分别为west、east、north，那么服务中的副本将会等分为三份，分布到带有三个标签的节点上。

max_replicas_per_node

这个是3.8中添加的配置。

字面意思，就是控制每个节点上最多的副本数

version: "3.9"
services:
  worker:
    image: dockersamples/examplevotingapp_worker
    networks:
      - frontend
      - backend
    deploy:
      mode: replicated
      replicas: 6
      placement:
        max_replicas_per_node: 1

要注意的是，当最大副本数*集群中可部署服务的节点数<副本数，会报错。

replicas

用于指定副本数，只有mode为副本模式的时候生效。

resources

这个参数在运维的时候尤为关键，主要用于限制服务的资源。

注意这里的配置在版本3中和版本2有较大差别。

version: "3.9"
services:
  redis:
    image: redis:alpine
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 50M
        reservations:
          cpus: '0.25'
          memory: 20M

limit用于限制最大的资源使用数量，reservation为最低的资源占用量。

restart_policy

重启策略

version: "3.9"
services:
  redis:
    image: redis:alpine
    deploy:
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s

• condition: 表示的是重启的条件，分为 none，on-failure,any(默认)
• delay：表示尝试重启的时间间隔（默认5s）
• max_attempts: 最多的尝试次数（默认一直重试）
• window：在判断重启是否成功之前等待时间（一个总的时间，如果超过这个时间还没有成功，则不再重启）

rollback_config

3.7版本加入

用于指定回滚的策略

由于和升级策略相关参数基本一直，放在下面讲

update_config

用于指定升级的策略

version: "3.9"
services:
  vote:
    image: dockersamples/examplevotingapp_vote:before
    depends_on:
      - redis
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
        delay: 10s
        order: stop-first

• parallelism：同时升级[回滚]的容器数
• delay：升级[回滚]的时间间隔
• failure_action：失败后如何做：continue, rollback（仅在update_config中有）, or pause (默认 pause)
• monitor: 检测失败的时间检测（默认为5s,支持ns、us、ms、s、m、h）
• max_failure_ratio：最大失败率
• order：有两个stop-first（默认）和start-first，一个是先停止旧的，一个是先启动新的，之后覆盖旧的

---

以上。