docker swarm和compose 的使用(阿里)

任何相对完整的应用服务都不可能是由单一的程序来完成支持，计划使用 Docker 来部署的服务更是如此。大型服务需要进行拆分，形成微服务集群方能增强其稳定性和可维护性。本篇随笔将对 Docker Compose 和 Docker Swarm 的原理和配置做整理归纳，并分享其使用经验。

总结一下，这张图很形象：Docker 可以看做集装箱把杂乱的货物一个个整理归类， Compose 则是用于编排这些集装箱，最后 Swarm 就是多提供几条船，挂掉一两条还能继续走，提高稳定性。

1. YAML 简介

Docker Compose 的配置文件采用 YAML 格式，因此有必要在正文之前简要说明下。YAML 是一门专门用来写配置文件的语言，设计目标就是方便读写，其实质上是一种通用的数据串行化格式，基本语法规则如下：

• 大小写敏感。
• # 表示注释。
• 使用缩进表示层级关系。
• 缩进时不允许使用 Tab 键，只允许使用空格。
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可。

YAML 支持的数据结构有三种:

• 对象：animal:cat。
• 数组：一组中划线开头的行，例如:

• 值类型和字符串。

2. Docker Compose

2.1 安装与简介

Docker 可以极为方便地部署单个服务，但这时候我们需要一个工具来整合 Docker 的功能，使之能够更便捷地去管理整个微服务集群的部署和迁移，Docker Compose 正是应此而生。他是由 Python 编写的程序，能够根据指令结合配置文件转换成对应的 Docker API 的操作，并直接体现到 Docker Daemon 中，这就代替我们完成了重复输入复杂指令的过程，主要功能可分为以下两点:

• Service：代表的是运行同种应用程序的一个或多个相同容器的抽象定义，也是我们在Docker Compose 中配置的主要对象。在每个 Docker Compose 的配置文件中，我们可以定义多个服务，并定义服务的配置，以及服务于服务之间的以来关系。
• Project：代表的是由多个服务所组成的一个相对完整的业务单元。

安装命令:

2.2 配置参数

Docker Compose 的核心就是其配置文件，采用 YAML 格式，默认为 docker-compose.yml ，参数详解可查阅“官方文档”，以下只做一个常规摘要。

services

所有服务的根节点。

image

指定服务的镜像名，若本地不存在，则 Compose 会去仓库拉取这个镜像:

ports

端口映射，例：

volumes

挂载主机目录，其中 ro 表示只读，例：

大多数情况下集群中部署的应该都是无状态服务，服务可复制且不固定在某一台宿主机，所以挂载的数据卷最好应当与宿主机脱离关系，例：

当然，这种情况下最好是优先创建数据卷，后在配置文件中引用，例：

若必须挂载集群中一台宿主机的目录作为数据卷，则要安装一个 docker 插件:

networks

配置服务间的网路互通与隔离，例：

secrets

配置服务密码访问，例：

healthcheck

健康检查，这个非常有必要，等服务准备好以后再上线，避免更新过程中出现短暂的无法访问。

其实大多数情况下健康检查的规则都会写在 Dockerfile 中:

depends_on

依赖的服务，优先启动，例：

environment & env_file

设置环境变量和指定环境变量的文件，例：

deploy

部署相关的配置都在这个节点下，例：

若非特殊服务，以上各节点的配置能够满足大部分部署场景了。

3. Swarm

Docker 默认包含了 Swarm，因此可以直接使用，初始化命令：

此时将会默认当前节点为 Leader，以下命令为查看 token：docker swarm join-token （worker|manager），其他节点可以用 manager 或者 worker 的身份加入到当前集群，例：

执行 docker swarm leave 脱离集群。

以下各节点常规操作命令，比较简单，就不解释了:

4. 应用案例

集群最擅长的就是解决多服务问题，只要在同一 network 之下，服务之间默认可以直接通过 service_name 互通有无。但为了避免混乱，各服务与外部的通信最好统一交给一个反向代理服务转发。因对 nginx 比较熟悉，所以我最初选择的代理是“jwilder/nginx-proxy”：

负载均衡使用的是阿里云的 SLB，监听 80 -> 81， 443 -> 80，这样一个服务就实现了节点检查、代理和 https 重定向为一身。拖 nginx 的福，反正用起来就是爽，点击“Nginx 原理解析和配置摘要”进一步了解。

正所谓乐极生悲，某一次我在扩展 Swarm 集群的时候提升了部分 work 节点为 manager， 并且扩展了代理的数量，这让很多服务频繁出现 503，找来找去我发现问题出在 nginx-proxy 代理上。当服务在各节点分布不均的时候，非 leader 节点上的那个代理无法找到服务，废了老大的劲儿也没找到合理的解决方案。

最后我决定选择“Docker Flow Proxy”作为新的代理（好家伙，这一看文档吓我一跳，我还是第一次看到私人的开源项目能把参考文档写得这么详细，作者的细腻程度“令人发指”，小弟顶礼膜拜之），以下是我的案例：

更换代理的过程也并非一帆风顺，我在 https 重定向这个问题浪费了好多时间，最后也没在代理中解决。作者当然是考虑到了这个问题，经典的解决方案应如下：

但奈何哥哥“非经典”呀，我的 https 证书和负载均衡都委托给阿里云的 SLB 了，SLB 代理的后端请求只能限定 http。我的想法还是监听所有请求 443 端口的域名并返回 301，但以下方案并没有成功:

当然重定向可以在各服务内部实现，但我不认为这是个好的解决方案。最后的最后，我想反正迟早都要上 CND，于是就在 CND 中加了 https 重定向（哎，就是带宽的费用要 double 咯...）:

除了代理，最好再加一个监控服务，我选择了官方案例中的 visualizer ，配合 proxy 示例：

visualizer 算是敏感服务了，一般需要用密码保护，这里通过 com.df.usersSecret 指定了密码文件，密码已写入 secrets dfp_users_admin 中。注意，com.df.usersSecret 的值与 dfp_users_* 必须相同，示例已在上文。部署后显示如下：

docker-flow-proxy 还有一个默认的监控服务，显示如下：

不过数据没有统一收集，因此意义不大，看看就好。除此之外就是真正需要部署的应用了，只要服务器性能足够，随便想来几个来几个。

在之前使用Docker的过程中，一直是用 Docker run 命令单独启动container后再加入Overlay网络的方式实现部署工作的. 这种方式看似直接，但是随着服务所包含的container的个数越来越多（docker 命令）也就越来越多，由此带来许多重复工作。。。

在官网上看到了通过 docker-compose 可以执行container的编排，尤其是compose files -- V3版本，加入的许多功能可以方便我们将服务中的contain部署在单独的docker host 或者多个 hosts (swarm 节点) 上，于是考虑到目前对于 docker 的使用情况，确实也到了进行高级特性的尝试阶段，于是乎，走起！

分享一个示例：https://hackernoon.com/deploy-docker-compose-v3-to-swarm-mode-cluster-4159e9cca712#.lyx2e8fd9

上面的说的是如何使用compose V3 + swarm 构建一个猫狗投票系统，官方的例子，描述的很详细，有兴趣的童鞋可以研究一下。。。我在这里部署的方式也是使用了类似的方法，区别之处在与：实例中运用了“docker stack deploy”命令在多个host上面部署，而我使用的是“docker-compose up” 分别在两个host上面启动与部署服务。

准备工作

首先是通过 Swarm 创建 nodes,并且创建Overlay网络模式. 我在这里就不在赘述，大家可以参看我之前的随笔或者利用万能的互联网找到答案。

我这里使用的Docker engine 和 Docker-compose 版本如下：

Docker-compose

众所周知，compose 就是 docker提供给我们用来进行编排的利器，那么我们应该如何使用她呢？

在解析docker-compose.yml之前，我想先说明一下我的业务，在熟悉业务之后，我们再来看看具体的"code".

业务需求：我们要在两个host (swarm node)上面分别建立一组服务，为了简单起见，我将nodes命名为nodeDB和nodeService；顾名思义，我们就是要在nodeDB上面建立database的服务（我这里是部署oracle server），在nodeService上面部署我们的程序(containers). 而 containers 之间的通信就是通过Swarm的Overlay网络来完成的。

NodeDB的docker-compose.yml

这里请注意几个内容：

1. networks: 在 compose file V3中, 允许我们通过networks关键字定义一个基于 Docker0 网络的 subnet。 然后将我们的服务添加到这个subnet中。这样做的好处实现了服务之间的隔离，一旦我们不需要这组服务了，我们可以通过命令“docker-compose down” 卸载服务和对应的subnet,他不会对其他的服务造成影响。

2. build: 我们可以通过build命令来指定加载那个Dockerfile。 Dockerfile 提供给我们一种方式将通用的dockr image 定制化成为自己的image，这些定制化的步骤就可以以Dockerfile的方式记录下来。例如，我之前从docker 仓库里pull 下来一个image, 我们叫他baseImage，之后在此基础上进行了我的定制化生成myImage，如果需要在其他机器上面使用myImage,之前的做法吧myImage提交到私有仓库，在需要的时候pull下来，但是如果不同的地方需要不同的myImage (v1,v2,v3...),就有可能造成Image泛滥。现在我们通过Dockerfile的方式记录自己的定制过程，就会方便许多。

OK，啰嗦了一大堆。。。现在我们再来看看我们的Dockerfile长得如何：

Dockerfile的内容很简单，就是copy文件；

CMD -- 就是我们需要在启动container的时候执行的shell脚本，通过她启动oracle服务和实例（业务逻辑需求）。

现在我们cd到docker-compose.yml文件所在的目录，输入命令 “docker-compose up”，命令执行完成后我们可以看到

1. 建立网络 composefrs_qrtSwarmComposeNet

2. 通过 Dockerfile 生成 imge

3. compose运行image，生成container并且调用shell脚本

到此，我们在nodeDB上面的工作就完成了。。。

NodeService的docker-compose.yml

我们要在这个host (swarm node) 部署服务，服务中的container需要与之前node上面oracle服务通信。。。

直接上code (简单起见，只列出了services 中的一个 container)

Compose文件中使用的 Dockerfile 的内容和之前差不多，就不在这里多说了。

注意：

1. 由于之前我们在nodeDB的compose file 里面已经创建过了网络，这里需要指定为external：true （不需要在创建了），在container里面加入即可。

2. 我们直接运行"docker-compose up"会报错，内容大致为找不到指定的网络。。。这是由于我们之前在nodeDB上面创建的network不会自动再新的node上面显示（官方说法），所以我们需要先在 nodeService 上面运行一个container让其加入网络 “composefrs_qrtSwamComposeNet“

例如 “docker run -itd --name=mybusybox --network=composefrs_qrtSwamComposeNet busybox /bin/sh”

之后我们便可以在nodeService上面能够查看到 composefrs_qrtSwamComposeNet 网络，此时再运行“docker-compose up”就OK了。这点还是有点坑的

结论

OK，通过在nodeDB和nodeService上运行两次 " docker-compose up ",命令，我们实现了在不同的hosts节点上运行containers，最终将他们以service的方式展现给外部用户。

PS，我还尝试过用docker stack deploy的方式进行部署，使用它最大的好处就是可以再一台机器上完成部署（传说中的一键部署），但是由于其中的种种限制(例如必须保证需要部署的service中使用的image必须提前存在于指定机器或者私有仓库，且不能使用Dockerfile临时编译; 不能指定conainer的IP，Mac 等等。。。),最终未能如愿，希望在 docker 之后的版本里能够改善吧。

本文只是一种实际部署方案的例子，涉及到的技术有（除Docker/Docker Swarm外）：

Docker overlay network

Fluentd

Prometheus stack

vegasbrianc的Prometheus监控方案

步骤大纲：

部署Docker machine

基本配置

配置网络

启动Fluentd日志服务

部署Docker swarm集群

配置网络

添加Node

部署Prometheus stack

给Node打Label

创建监控网络

启动service

部署应用

识别stateless与stateful

创建应用网络

给Node打Label

启动service

1 部署Docker machine 1.1 基本配置

准备若干Linux服务器（本例使用Ubuntu 16.04），参照Docker CE 镜像源站提到的步骤安装Docker CE。

参照Docker Daemon生产环境配置。

1.2 配置bridge网络

参照Docker Daemon生产环境配置中的mtu和子网章节。

1.3 启动Fluentd日志服务

参考使用Fluentd收集Docker容器日志。

2 部署Docker swarm集群

到一台机器上执行docker swarm init，这个机器将作为manager node。

执行docker node ls会看到类似下面的结果：

$ docker node lsID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
dxn1zf6l61qsb1josjja83ngz * manager1 Ready Active Leader

如果你计划不会把工作负载跑在manager node上，那么使用docker drain：

docker node update --availability drain <node-id>

可参考Docker Swarm基本命令清单。

2.1 配置网络MTU和子网

参考Docker Overlay网络的MTU。

特别注意

观察docker_gwbridge和ingress的子网是否与已有网络冲突：

$ docker network inspect -f '{{json .IPAM}}' docker_gwbridge
{"Driver":"default","Options":null,"Config":[{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]}$ docker network inspect -f '{{json .IPAM}}' ingress
{"Driver":"default","Options":null,"Config":[{"Subnet":"10.255.0.0/16","Gateway":"10.255.0.1"}]}

如果有冲突则参考Docker Overlay网络的MTU中的方法修改子网。

2.2 添加Node

参考Docker Swarm基本命令清单。

3 部署Prometheus stack

使用的是vegasbrianc的Prometheus监控方案。

整个监控方案包含一下几个组件：

Prometheus

Node-exporter，运行在每个node上

Alertmanager

cAdvisor，运行在每个node上

Grafana

3.1 给Node打Label

挑选一台Node作为运行监控服务的机器。给这个node打上label：

$ docker node update --label-add for-monitor-stack=1 <node-id>

3.2 创建监控网络

$ docker network create -d overlay --attachable monitor-net

参考参考Docker Overlay网络的MTU检查子网与MTU是否配置正确。

3.3 启动service

clone vegasbrianc的Prometheus监控方案 项目代码。

使用我修改过的docker-stack.yml

启动service：

$ docker stack deploy \
--with-registry-auth \
--prune \
-c docker-stack.yml \
p8s-monitor-stack

访问地址：

Prometheus：http://<任意swarm node ip>:9000

Node-exporter：http://<任意swarm node ip>:9010

Alertmanager：http://<任意swarm node ip>:9020

cAdvisor：http://<任意swarm node ip>:9030

Grafana：http://<任意swarm node ip>:9040，用户名admin，密码foobar

4 部署应用 4.1 识别stateless与stateful

如果你的应用由多个组件（service）组成，那么在部署它们之前你得识别出哪些是stateless service哪些是stateful service。

针对每个service你自问以下三个问题：

这个service崩溃之后，是不是只需要重启它就可以了，而不需要关心数据恢复？

这个service是否可以在node之间任意迁移，且不需要分布式存储？

这个service是否无需固定IP？

如果上述回答都是Yes，那么这个service就是stateless的，只要有一个是No，则这个service是stateful的。

对于stateless service，你可以：

用docker stack deploy部署

用docker service create部署

对于stateful service，你可以：

用docker run部署

用docker-compose up部署

如果没有固定IP的要求，那么你也可以用docker stack deploy/docker service create部署，前提是你得保证这个service只会固定在一台机器上运行。

有时候你的应用既有stateless service又有stateful service，这时需要把他们挂载到同一个overlay网络里，这样它们之间就能够互相通信了。

4.2 创建应用网络

创建app-net（你也可以改成自己的名字）

$ docker network create -d overlay --attachable app-net

参考Docker Overlay网络的MTU检查子网与MTU是否配置正确。

4.3 给Node打Label

如果你对于Service部署在哪个Node上有要求，那么你得给Node打上Label：

$ docker node update --label-add <your-label>=1 <node-id>

然后在docker-compose.yaml里添加约束条件：

version: "3.7"
services:
busybox:
image: busybox
deploy:
placement:
constraints:
- node.labels.<your-label> == 1

4.4 启动service

对于stateless service，编写docker-compose.yaml，里面写了同时挂载app-net和monitor-net，比如：

version: "3.7"
services:
busybox:
image: busybox
networks:
app-net:
monitor-net:
aliases:
- busybox
...
networks:
app-net:
external: true
monitor-net:
external: true

注意上面设置了busybox service在monitor-net中的别名，这是因为如果你用docker stack deploy部署，那么busybox的名字默认是<stack-name>_busybox，这样对于prometheus而言此名字不稳定，不便于配置详见Prometehus监控Docker Swarm Overlay网络中的容器。

然后用docker stack deploy部署：

$ docker stack deploy --with-registry-auth --prune -c docker-compose.yaml <stack-name>

如果用docker service create则：

$ docker service create \
--network app-net \
--network monitor-net \
--name <name> \
... 其他参数
<image>

下面举例docker run启动stateful service的方法：

$ docker run -d \
--name <name> \
--network app-net \
... 其他参数 \
<image># 然后再挂载到monitor-net上
$ docker network connect monitor-net <name>

参考：Docker 小记 — Compose & Swarm

参考：Docker - 使用Swarm和compose部署服务（containers）