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>
本文来自博客园,作者:aspirant,转载请注明原文链接:https://www.cnblogs.com/aspirant/p/11481805.html