Docker-Compose.yml详解

本文是基于version 3

build

在构建时应用的配置选项。
build 可以指定为包含构建上下文路径的字符串:

version: "3.7" services: webapp: build: ./dir 

或者,作为具有在context下指定的路径的对象,以及可选的Dockerfile和args:

version: "3.7" services: webapp: build: context: ./dir dockerfile: Dockerfile-alternate args: buildno: 1 

如果你同时指定image和build,则compose会通过build指定的目录构建容器镜像,而构建的镜像名为image中指定的镜像名和标签。

build: ./dir image: webapp:tag 

包含Dockerfile的目录的路径,或者git存储库的URL。

当提供的值是相对路径时,它将被解释为相对于Compose文件的位置。该目录还是发送到Docker守护程序的构建上下文。

Compose用生成的名称构建并标记它,然后使用该镜像。

build: context: ./dir 

备用Dockerfile。

Compose使用一个替代文件进行构建。还必须指定一个构建路径。

build: context: . dockerfile: Dockerfile-alternate 

添加构建镜像的参数,环境变量只能在构建过程中访问。
首先,在Dockerfile中指定要使用的参数:

ARG buildno ARG gitcommithash RUN echo "Build number: $buildno" RUN echo "Based on commit: $gitcommithash" 

然后在args键下指定参数。 你可以传递映射或列表:

build: context: . args: buildno: 1 gitcommithash: cdc3b19 12345 build: context: . args: - buildno=1 - gitcommithash=cdc3b19 

可以在指定构建参数时忽略该值,在这种情况下,构建时的值就是运行Compose的环境中的值。

args: - buildno - gitcommithash 

:YAML布尔值(true,false,yes,no,on,off)必须用引号括起来,这样分析器会将它们解释为字符串。

注意:此选项是v3.2中的新增功能
指定缓存的镜像列表。
(等同于 docker container build –cache_from 的作用)

build: context: . cache_from: - alpine:latest - corp/web_app:3.14 

注意:此选项是v3.3中的新增功能
使用Docker标签将元数据添加到生成的图像中。您可以使用数组或字典。
我们建议您使用反向DNS表示法,以防止标签与其他软件使用的标签冲突。
(等同于 docker container build –labels 的作用)

build: context: . labels: com.example.description: "Accounting webapp" com.example.department: "Finance" com.example.label-with-empty-value: "" 123456 build: context: . labels: - "com.example.description=Accounting webapp" - "com.example.department=Finance" - "com.example.label-with-empty-value" 

注意:以3.5版文件格式添加
设置 /dev/shm 此构建容器的分区大小。指定为表示字节数的整数值或表示字节值的字符串。(等同于 docker container build –shm-size 的作用)

build: context: . shm_size: '2gb' 123 build: context: . shm_size: 10000000 

cap_add,cap_drop

添加或删除容器功能。(ps:没用过)

cap_add: - ALL cap_drop: - NET_ADMIN - SYS_ADMIN 

cgroup_parent

为容器指定一个可选的父cgroup。(ps:没用过)

cgroup_parent: m-executor-abcd 

command

覆盖默认命令。

command: bundle exec thin -p 3000 

支持 shell 格式和 [] 格式

command: ["bundle", "exec", "thin", "-p", "3000"] 

configs

container_name

指定自定义容器名称,而不是生成的默认名称。
由于Docker容器名称必须唯一,因此如果您指定了自定义名称,则不能将服务扩展到1个以上的容器。尝试这样做会导致错误。
(等同于 docker run –name 的作用)

container_name: my-web-container 

credential_spec

depends_on

定义容器启动顺序 (此选项解决了容器之间的依赖关系, 此选项在 v3 版本中 使用 swarm 部署时将忽略该选项)
示例

  • docker-compose up 以依赖顺序启动服务,下面例子中 redis 和 db 服务在 web 启动前启动
  • 默认情况下使用 docker-compose up web 这样的方式启动 web 服务时,也会启动 redis 和 db 两个服务,因为在配置文件中定义了依赖关系
  • docker-compose stop按依赖关系顺序停止服务。在以下示例中,web在db和redis之前停止。
version: "3.7" services: web: build: . depends_on: - db - redis redis: image: redis db: image: postgres 

deploy

注意:仅版本3。
指定与部署和运行服务相关的配置, deploy 部分是 docker stack 使用的, docker stack 依赖 docker swarm,并且被忽略docker-compose up和docker-compose run。

v3.3 版本中新增的功能, 指定服务暴露的方式

  • endpoint_mode: vip-Docker为服务分配了虚拟IP(VIP),该虚拟IP充当客户端访问网络上服务的前端。Docker在客户端与服务的可用工作节点之间路由请求,而客户端却不知道有多少节点正在参与服务或其IP地址或端口。(这是默认设置。)
  • endpoint_mode: dnsrr-DNS轮询(DNSRR)服务发现不使用单个虚拟IP。Docker设置服务的DNS条目,以便对服务名称的DNS查询返回IP地址列表,并且客户端直接连接到其中之一。在需要使用自己的负载平衡器或混合Windows和Linux应用程序的情况下,DNS轮询很有用。
version: "3.7" services: wordpress: image: wordpress ports: - "8080:80" networks: - overlay deploy: mode: replicated replicas: 2 endpoint_mode: vip mysql: image: mysql volumes: - db-data:/var/lib/mysql/data networks: - overlay deploy: mode: replicated replicas: 2 endpoint_mode: dnsrr volumes: db-data: networks: overlay: 

指定服务标签。这些标签仅在服务上设置,而不在服务的任何容器上设置。

version: "3.7" services: web: image: web deploy: labels: com.example.description: "This label will appear on the web service" 

要在容器上设置标签,请使用deploy之外使用labels

version: "3.7" services: web: image: web labels: com.example.description: "This label will appear on all containers for the web service" 

指定 deploy 的模式

version: "3.7" services: worker: image: dockersamples/examplevotingapp_worker deploy:  global  replicated 

如果服务是replicated(默认)服务,请指定在任何给定时间应运行的容器数。

version: "3.7" services: worker: image: dockersamples/examplevotingapp_worker networks: - frontend - backend deploy: mode: replicated replicas: 6 

资源限制
在此一般示例中,redis服务被限制为使用不超过50M的内存和0.50(不超过单个内核的50%)可用处理时间(CPU),并且具有保留20M的内存和0.25CPU时间(始终可用)。

version: "3.7" services: redis: image: redis:alpine deploy: resources:  limits: cpus: '0.50' memory: 50M  reservations: cpus: '0.25' memory: 20M 

内存不足异常(OOME)
如果服务或容器尝试使用的内存超出系统可用的内存,则可能会遇到内存不足异常(OOME),并且内核OOM杀手可能会杀死容器或Docker守护程序。为防止这种情况的发生,请确保应用程序在具有足够内存的主机上运行。

配置是否以及如何在退出容器时重新启动容器。替换 restart。

定义容器重启策略(接受三个参数)

  • none 不尝试重启
  • on-failure 只有当容器内部应用程序出现问题才会重启
  • any 无论如何都会尝试重启(默认)

尝试重启的间隔时间(默认为 0s)

放弃之前尝试重新启动容器的次数(默认值:一直重启)。如果重启未在configure内成功完成 window,则此尝试不会计入配置max_attempts值。例如,如果max_attempts设置为“ 2”,并且第一次尝试重启失败,则可能会尝试两次以上重启。

检查重启是否成功之前的等待时间(即如果容器启动了, 隔多少秒之后去检测容器是否正常, 默认 0s)。

version: "3.7" services: redis: image: redis:alpine deploy: restart_policy: condition: on-failure delay: 5s max_attempts: 3 window: 120s 

注意:3.7版文件格式及更高版本
配置在更新失败的情况下应如何回滚服务。

一次要回滚的容器数。如果设置为0,则所有容器将同时回滚。

每个容器组回滚之间等待的时间(默认为0s)。

回滚失败策略(默认pause)

  • continue 跳过
  • pause 暂停

更新每个任务以监视失败后的持续时间(ns|us|ms|s|m|h)(默认为0s)。

在回滚期间可以容忍的故障率(默认为0)。

回滚期间的操作顺序。(默认stop-first)

  • stop-first 旧任务,开始新的一个前停止
  • start-first 新的任务首先启动,并且正在运行的任务简单地重叠

配置应如何更新服务。对于配置滚动更新很有用。

version: "3.7" services: vote: image: dockersamples/examplevotingapp_vote:before depends_on: - redis deploy: replicas: 2 update_config: parallelism: 2 delay: 10s order: stop-first 

一次更新的容器数。

在更新一组容器之间等待的时间。

如果更新失败,该怎么办。(默认pause)

  • continue 继续更新
  • rollback 回滚更新
  • pause 暂停更新(默认)

更新每个任务以监视失败后的持续时间(ns|us|ms|s|m|h)(默认为0s)。

更新期间可以容忍的故障率。

:仅支持V3.4及更高版本。
更新期间的操作顺序。(默认stop-first)

  • stop-first 旧任务,开始新的一个前停止
  • start-first 新的任务首先启动,并且正在运行的任务简单地重叠

注意
支持 docker-compose up 和 docker-compose run 但不支持 docker stack deploy 的子选项

  • build
  • cgroup_parent
  • container_name
  • devices
  • tmpfs
  • external_links
  • links
  • network_mode
  • restart
  • security_opt
  • userns_mode

原文链接:https://blog.csdn.net/qq_36306519/article/details/130878264?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168994567316800182722850%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=168994567316800182722850&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-25-130878264-null-null.268%5Ev1%5Ekoosearch&utm_term=docker%E3%80%81wordpress%E3%80%81wordpress%E5%BB%BA%E7%AB%99%E3%80%81wordpress%E4%B8%BB%E9%A2%98%E3%80%81%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E3%80%81

© 版权声明
THE END
喜欢就支持一下吧
点赞10 分享