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