起因
由于要进行服务的微服务化部署，由于硬件限制，我们目前采用的是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，一个是先停止旧的，一个是先启动新的，之后覆盖旧的
以上。
网友评论