docker swarm和compose 的使用(阿里)

2020-10-27 03:41发布

基本的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 10  youclk_proxy
docker service update --force youclk_proxy

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

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

 

version: v1
common:
  tools:
    oracle-jdk: 8
build: 
  tools:
    maven: 3.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: 1
    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: 2
  restart_policy:
    condition: on-failure
    max_attempts: 3
  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-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx 172.17.0.2:2377

 

执行 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 80;
    server_name localhost;
    location /alive {
        return 200;
    }
}

server {
    listen  81;
    return  301 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: 2
      labels:
        - com.df.notify=true
        - com.df.port=8080
        - 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: 2
      labels:
        - com.df.notify=true
        - com.df.httpsOnly=true
        - com.df.httpsRedirectCode=301

 

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

labels:
  - com.df.notify=true
  - com.df.httpsRedirectCode=301
  - com.df.serviceDomainAlgo=hdr_dom(host)
    
  - com.df.srcPort.1=80
  - com.df.port.1=8080
  - com.df.serviceDomain.1=localhost
  - com.df.reqPathSearchReplace.1=/alive,/v1/docker-flow-proxy/ping
    
  - com.df.srcPort.2=443
  - com.df.port.2=8080
  - com.df.serviceDomain.2=youclk.com,localhost
  - com.df.httpsOnly.2=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=8080
        - 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: '3'

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: '3'
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_gwbridgeingress的子网是否与已有网络冲突:

$ 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-netmonitor-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)

标签: