• 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 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_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）
  • 相关阅读:
    偏态分布的均值与中位数关系
    Leetcode 769. Max Chunks To Make Sorted
    【STL】max_element()函数
    [LeetCode] 1338. Reduce Array Size to The Half
    [LeetCode] 985. Sum of Even Numbers After Queries
    [LeetCode] 984. String Without AAA or BBB
    [LeetCode] 1405. Longest Happy String
    [LeetCode] 1646. Get Maximum in Generated Array
    [LeetCode] 926. Flip String to Monotone Increasing
    [LeetCode] 1658. Minimum Operations to Reduce X to Zero
  • 原文地址：https://www.cnblogs.com/aspirant/p/11481805.html
Copyright © 2020-2023  润新知