docker swarm和compose 的使用(阿里)

基本的docker使用参考：Docker 入门 到部署Web 程序- (阿里面试常用的docker命令和优点)

昨天去阿里面试 问我如果给你5台服务器 如何部署docker,我说一个个拷贝，面试官听了脸都绿了，

说有没有听说过用swarm和compose 部署docker集群，我说没用过，

后来回来一看自己的项目，我晕，每天用的yaml文件 就是 compose。

赶紧做一下总结：阿里的人喜欢让你写命令，比如 你是否记得 docker的部署命令启动命令之类的：

5. 部署与维护

docker stack

部署命令:

docker stack deploy -c docker-compose.yml --with-registry-auth youclk，

私有仓库必须加 --with-registry-auth 才能下载镜像。除此之外常用的如下：

# network volume service secret 用法都类似，同出一系嘛...
docker stack ls
docker stack ps youclk
docker stack rm youclk

docker service

我使用 Compose 的场景一般都结合 Swarm，因此很少去记手动创建或者更改配置的命令了，意义也不大。除了查看移除等与上文相似以外，此处还应记两个:

docker service logs --tail   youclk_proxy
docker service update --force youclk_proxy

分别是查看日志和服务异常后强制重启。

这是我的项目中用到的compose部署文件：manifest.yaml

version: v1
common:
  tools:
    oracle-jdk:
build:
  tools:
    maven: 3.3.
  run:
    workDir: ./
    cmd:
      - sh deploy/compile.sh
  target:
    distDir: ./target/
    files:
      - ./*.jar
      - ../deploy
autodeploy:
    targetDir: /opt/meituan/com.sankuai.qcs.regulation.nanjingnew/
    env:
    run: sh deploy/run.sh
    check: sh deploy/check.sh
    checkRetry: 3 #后面下掉，加默认值为1
    CheckInterval: 20s #后面下掉

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

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

1. YAML 简介

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

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

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

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

# ex1
  - cat
  - dog
  - bird

# ex2
  -
    - cat
    - dog
    - bird

# ex3
  animal: [cat, dog, bird]

• 值类型和字符串。

2. Docker Compose

2.1 安装与简介

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

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

安装命令:

curl -L https://github.com/docker/compose/releases/download/1.19.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose

2.2 配置参数

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

services

所有服务的根节点。

image

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

services:
  web:
    image: nginx

ports

端口映射，例：

ports:
  - "80:80"
  - "81:81"

volumes

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

volumes:
  - "/etc/nginx/www:/www"
  - "/var/run/docker.sock:/tmp/docker.sock:ro"

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

  web:
  services:
    image: nginx
    volumes:
      - type: volume
        source: logs
        target: /mnt
        volume:
          nocopy: true

volumes:
  logs:
    driver_opts:
      type: nfs
      o: addr=***.cn-hangzhou.nas.aliyuncs.com,rw
      device: ":/"

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

docker volume create --driver local \
    --opt type=nfs \
    --opt o=addr=***.cn-hangzhou.nas.aliyuncs.com,rw \
    --opt device=:/ \
    logs
volumes:
  logs:
    external: true

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

docker plugin install vieux/sshfs

# 若配置了密钥对则可省略 password 参数
docker volume create \
  -d vieux/sshfs \
  --name sshvolume \
  -o "sshcmd=user@1.2.3.4:/remote" \
  -o "password=$(cat file_containing_password_for_remote_host)\
sshvolume

networks

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

services:
  web:
    image: nginx
    networks:
      - proxy
      - youclk
networks:
  youclk:
    external: true
  proxy:
    external: true

secrets

配置服务密码访问，例：

services:
  redis:
    image: redis:latest
    deploy:
      replicas:
    secrets:
      - my_secret
      - my_other_secret
secrets:
  my_secret:
    file: "./my_secret.txt"
  my_other_secret:
    external: true
docker secret create [OPTIONS] SECRET [file|-]
echo "admin:password" | docker secret create my_secret -
docker secret create my_secret ./secret.json

healthcheck

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

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost/alive"]
  interval: 5s
  timeout: 3s

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

FROM nginx
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
HEALTHCHECK --interval=5s --timeout=3s CMD curl -f http://localhost/alive || exit 1

depends_on

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

depends_on:
  - redis

environment & env_file

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

environment:
  - VIRTUAL_HOST=test.youclk.com
env_file:
  - ./common.env

deploy

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

deploy:
  mode: replicated
  replicas:
  restart_policy:
    condition: on-failure
    max_attempts:
  update_config:
    delay: 5s
    order: start-first # 默认为 stop-first，推荐设置先启动新服务再终止旧的
  resources:
    limits:
      cpus: "0.50"
      memory: 1g
deploy:
  mode: global # 不推荐全局模式（仅个人意见）。
  placement:
    constraints: [node.role == manager]

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

3. Swarm

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

docker swarm init

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

docker swarm join --token SWMTKN--3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx 172.17.0.2:

执行 docker swarm leave 脱离集群。

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

docker node demote [NODE]
docker node inspect [NODE]
docker node ls
docker node promote [NODE]
docker node ps [NODE]
docker node rm [NODE]
docker node update [OPTIONS] NODE

4. 应用案例

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

server
{
    listen ;
    server_name localhost;
    location /alive {
        return ;
    }
}

server {
    listen  ;
    return   https://$host$request_uri;
}
FROM jwilder/nginx-proxy
ADD ./src /etc/nginx/conf.d
ADD https://gitee.com/youclk/entry/raw/master/debian/sources-vpc.list /etc/apt/sources.list
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
HEALTHCHECK --interval=5s --timeout=3s CMD curl -f http://localhost/alive || exit 1
version: "3.5"

services:

  proxy:
    image: $REGISTRY/proxy
    ports:
      - "80:80"
      - "81:81"
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
    deploy:
      placement:
        constraints: [node.role == manager]
      restart_policy:
        condition: on-failure
        max_attempts: 3
      update_config:
        delay: 5s
        order: start-first
      resources:
        limits:
          cpus: "0.50"
          memory: 1g

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

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

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

version: "3.5"

services:

  proxy:
    image: vfarcic/docker-flow-proxy
    ports:
      - "80:80"
    networks:
      - proxy
    environment:
      - LISTENER_ADDRESS=swarm-listener
      - MODE=swarm
    secrets:
      - dfp_users_admin
    deploy:
      replicas:
      labels:
        - com.df.notify=true
        - com.df.port=
        - com.df.serviceDomain=localhost
        - com.df.reqPathSearchReplace=/alive,/v1/docker-flow-proxy/ping

  swarm-listener:
    image: vfarcic/docker-flow-swarm-listener
    networks:
      - proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DF_NOTIFY_CREATE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/reconfigure
      - DF_NOTIFY_REMOVE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/remove
    deploy:
      placement:
        constraints: [node.role == manager]

networks:
  proxy:
    external: true
secrets:
  dfp_users_admin:
    external: true

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

services:
  proxy:
    image: vfarcic/docker-flow-proxy
    ports:
      - "80:80"
      - "443:443"
    networks:
      - proxy
    environment:
      - LISTENER_ADDRESS=swarm-listener
      - MODE=swarm
    deploy:
      replicas:
      labels:
        - com.df.notify=true
        - com.df.httpsOnly=true
        - com.df.httpsRedirectCode=

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

labels:
  - com.df.notify=true
  - com.df.httpsRedirectCode=
  - com.df.serviceDomainAlgo=hdr_dom（host）

  - com.df.srcPort.=
  - com.df.port.=
  - com.df.serviceDomain.=localhost
  - com.df.reqPathSearchReplace.=/alive,/v1/docker-flow-proxy/ping

  - com.df.srcPort.=
  - com.df.port.=
  - com.df.serviceDomain.=youclk.com,localhost
  - com.df.httpsOnly.=true

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

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

services:
  visualizer:
    image: dockersamples/visualizer
    networks:
      - proxy
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    deploy:
      placement:
        constraints: [node.role == manager]
      labels:
        - com.df.notify=true
        - com.df.serviceDomain=visualizer.youclk.com
        - com.df.port=
        - com.df.usersSecret=admin

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

version: ''

services:

  frs_orasvr:
    build:
      context: ./frsDB
      dockerfile: Dockerfile
    image: frs_orasvr_img:v1
    container_name: frs_orasvr
    hostname: frs_orasvr
    ports:
      - "1521:1521"
    volumes:
      - /DATA/compose_frs/frsDB/cafisFRSDB/:/frs
    networks:
      - qrtSwamComposeNet

networks:
  qrtSwamComposeNet:
    driver: overlay

这里请注意几个内容：

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长得如何：

FROM 172.100.1.15:5000/oracle11g_server_v3
RUN mkdir /frs/
COPY /cafisFRSDB/ /frs/
COPY /cafisFRSDB/listener.ora /app/oracle/11.2.0/network/admin/
CMD ["/bin/bash", "/frs/startup.sh"]

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)

version: ''
services:

  frs_ftsoft:
    build:
      context: ./ftsoft
      dockerfile: Dockerfile
    image: frs_ftsoft_img:v1
    networks:
      - composefrs_qrtSwamComposeNet
    container_name: frs_ftsoft
    hostname: frs_ftsoft
    mac_address: xx:xx:xx:xx:xx:xx
    volumes:
     - /data/CabisSvr/DockerFrs/ftsoft:/frs

networks:
  composefrs_qrtSwamComposeNet:
    external: true

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 ls

ID                           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）