服务顶级元素

服务是在应用程序内对计算资源的抽象定义，可以独立于其他组件进行扩展或替换。服务由一组容器支持，平台根据复制要求和放置约束运行这些容器。由于服务由容器支持，因此它们由 Docker 镜像和一组运行时参数定义。服务内的所有容器都是使用这些参数相同创建的。

Compose 文件必须声明一个 `services` 顶级元素作为映射，其键是服务名称的字符串表示形式，其值是服务定义。服务定义包含应用于每个服务容器的配置。

每个服务还可以包含一个 `build` 部分，该部分定义如何创建服务的 Docker 镜像。Compose 支持使用此服务定义构建 Docker 镜像。如果未使用，则忽略 `build` 部分，Compose 文件仍被认为有效。构建支持是 Compose 规范的一个可选方面，在 Compose 构建规范文档中进行了详细描述。

每个服务都定义运行其容器的运行时约束和要求。`deploy` 部分对这些约束进行分组，并允许平台调整部署策略，以最佳方式将容器的需求与可用资源相匹配。部署支持是 Compose 规范的一个可选方面，在 Compose 部署规范文档中进行了详细描述。如果未实现，则忽略 `deploy` 部分，Compose 文件仍被认为有效。

示例

简单示例

以下示例演示如何定义两个简单的服务、设置其镜像、映射端口以及使用 Docker Compose 配置基本环境变量。

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"

  db:
    image: postgres:13
    environment:
      POSTGRES_USER: example
      POSTGRES_DB: exampledb

高级示例

在以下示例中，`proxy` 服务使用 Nginx 镜像，将本地 Nginx 配置文件安装到容器中，公开端口 `80` 并依赖于 `backend` 服务。

`backend` 服务从位于 `backend` 目录中的 Dockerfile 构建镜像，该镜像设置为在 `builder` 阶段构建。

services:
  proxy:
    image: nginx
    volumes:
      - type: bind
        source: ./proxy/nginx.conf
        target: /etc/nginx/conf.d/default.conf
        read_only: true
    ports:
      - 80:80
    depends_on:
      - backend

  backend:
    build:
      context: backend
      target: builder

有关更多示例 Compose 文件，请浏览 Awesome Compose 示例。

属性

annotations

`annotations` 定义容器的注释。`annotations` 可以使用数组或映射。

annotations:
  com.example.foo: bar

annotations:
  - com.example.foo=bar

attach

在 Docker Compose 版本 2.20.0 中引入

当定义 `attach` 并将其设置为 `false` 时，Compose 不会收集服务日志，除非您明确请求它。

默认服务配置为 `attach: true`。

build

`build` 指定从源代码创建容器镜像的构建配置，如 Compose 构建规范中所定义。

blkio_config

`blkio_config` 定义一组配置选项，用于设置服务的块 IO 限制。

services:
  foo:
    image: busybox
    blkio_config:
       weight: 300
       weight_device:
         - path: /dev/sda
           weight: 400
       device_read_bps:
         - path: /dev/sdb
           rate: '12mb'
       device_read_iops:
         - path: /dev/sdb
           rate: 120
       device_write_bps:
         - path: /dev/sdb
           rate: '1024k'
       device_write_iops:
         - path: /dev/sdb
           rate: 30

device_read_bps, device_write_bps

设置给定设备上读/写操作的每秒字节数限制。列表中的每个项目必须有两个键

`path`：定义受影响设备的符号路径。
`rate`：可以是表示字节数的整数，也可以是表示字节值的字符串。

device_read_iops, device_write_iops

设置给定设备上读/写操作的每秒操作数限制。列表中的每个项目必须有两个键

`path`：定义受影响设备的符号路径。
`rate`：表示每秒允许的操作数的整数值。

权重

修改相对于其他服务的分配给服务的带宽比例。取值为 10 到 1000 之间的整数，默认为 500。

按设备加权

按设备微调带宽分配。列表中的每个项目必须有两个键

`path`：定义受影响设备的符号路径。
`weight`：10 到 1000 之间的整数值。

cpu_shares

`cpu_shares` 以整数值定义服务容器相对于其他容器的相对 CPU 权重。

cpu_period

`cpu_period` 在平台基于 Linux 内核时配置 CPU CFS（完全公平调度程序）周期。

cpu_quota

`cpu_quota` 在平台基于 Linux 内核时配置 CPU CFS（完全公平调度程序）配额。

cpu_rt_runtime

`cpu_rt_runtime` 为支持实时调度的平台配置 CPU 分配参数。它可以是使用微秒作为单位的整数值，也可以是持续时间。

 cpu_rt_runtime: '400ms'
 cpu_rt_runtime: 95000`

cpu_rt_period

`cpu_rt_period` 为支持实时调度的平台配置 CPU 分配参数。它可以是使用微秒作为单位的整数值，也可以是持续时间。

 cpu_rt_period: '1400us'
 cpu_rt_period: 11000`

cpus

`cpus` 定义分配给服务容器的（可能是虚拟的）CPU 数量。这是一个分数。`0.000` 表示没有限制。

如果设置了 `cpus`，则必须与部署规范中的 `cpus` 属性一致。

cpuset

`cpuset` 定义允许执行的显式 CPU。可以是范围 `0-3` 或列表 `0,1`

添加功能

`cap_add` 指定作为字符串的附加容器功能。

cap_add:
  - ALL

删除功能

`cap_drop` 指定要删除的容器功能为字符串。

cap_drop:
  - NET_ADMIN
  - SYS_ADMIN

控制组

在 Docker Compose 版本 2.15.0 中引入

`cgroup` 指定要加入的 cgroup 命名空间。如果未设置，则由容器运行时决定选择哪个 cgroup 命名空间（如果支持）。

`host`：在容器运行时 cgroup 命名空间中运行容器。
`private`：在它自己的私有 cgroup 命名空间中运行容器。

控制组父级

`cgroup_parent` 指定容器的可选父 cgroup。

cgroup_parent: m-executor-abcd

命令

`command` 覆盖容器镜像声明的默认命令，例如 Dockerfile 的 `CMD`。

command: bundle exec thin -p 3000

该值也可以是一个列表，其方式类似于 Dockerfile。

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

如果值为 `null`，则使用镜像中的默认命令。

如果值为 `[]`（空列表）或 `''`（空字符串），则忽略镜像声明的默认命令，即将其覆盖为空。

配置

配置允许服务调整其行为，而无需重新构建 Docker 镜像。只有在 `configs` 属性明确授予权限时，服务才能访问配置。支持两种不同的语法变体。

如果平台上不存在 `config` 或在 Compose 文件的 `configs` 顶级元素中未定义 `config`，Compose 会报告错误。

为配置定义了两种语法：简写语法和长写语法。

您可以授予服务对多个配置的访问权限，并且可以混合使用简写和长写语法。

简写语法

简写语法仅指定配置名称。这允许容器访问配置并将其作为文件安装到服务的容器的文件系统中。在 Linux 容器中，安装点的默认位置为 `/<config_name>`，在 Windows 容器中为 `C:\<config-name>`。

以下示例使用简写语法来授予 `redis` 服务对 `my_config` 和 `my_other_config` 配置的访问权限。`my_config` 的值设置为文件 `./my_config.txt` 的内容，`my_other_config` 定义为外部资源，这意味着它已在平台中定义。如果外部配置不存在，则部署失败。

services:
  redis:
    image: redis:latest
    configs:
      - my_config
      - my_other_config
configs:
  my_config:
    file: ./my_config.txt
  my_other_config:
    external: true

长写语法

长写语法在服务的任务容器内创建配置的方式上提供了更多粒度。

`source`：配置在平台中存在的名称。
`target`：要在服务的任务容器中安装的文件的路径和名称。如果未指定，则默认为 `/<source>`。
uid 和 gid：服务任务容器内拥有已挂载配置文件的数值 UID 或 GID。如果未指定，默认值为运行容器的 USER。
mode：服务任务容器内挂载文件的权限，采用八进制表示。默认值为世界可读 (0444)。写入权限位将被忽略。可以设置可执行权限位。

以下示例在容器中将my_config 的名称设置为 redis_config，将模式设置为 0440（组可读），并将用户和组设置为 103。redis 服务无法访问 my_other_config 配置文件。

services:
  redis:
    image: redis:latest
    configs:
      - source: my_config
        target: /redis_config
        uid: "103"
        gid: "103"
        mode: 0440
configs:
  my_config:
    external: true
  my_other_config:
    external: true

容器名称

container_name 是一个字符串，用于指定自定义容器名称，而不是默认生成的名称。

container_name: my-web-container

如果 Compose 文件指定了 container_name，则 Compose 不会将服务的容器数量扩展到一个以上。尝试这样做会导致错误。

container_name 遵循正则表达式格式 [a-zA-Z0-9][a-zA-Z0-9_.-]+

凭据规范

credential_spec 配置托管服务帐户的凭据规范。

如果您有使用 Windows 容器的服务，则可以对 credential_spec 使用 file: 和 registry: 协议。Compose 还支持其他协议以满足自定义用例。

credential_spec 必须采用 file://<filename> 或 registry://<value-name> 格式。

credential_spec:
  file: my-credential-spec.json

使用 registry: 时，凭据规范将从守护程序主机上的 Windows 注册表中读取。必须在以下位置找到具有给定名称的注册表值：

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs

以下示例从注册表中名为 my-credential-spec 的值加载凭据规范

credential_spec:
  registry: my-credential-spec

gMSA 配置示例

为服务配置 gMSA 凭据规范时，只需使用 config 指定凭据规范，如下例所示

services:
  myservice:
    image: myimage:latest
    credential_spec:
      config: my_credential_spec

configs:
  my_credentials_spec:
    file: ./my-credential-spec.json|

依赖项

使用 depends_on 属性，您可以控制服务的启动和关闭顺序。如果服务紧密耦合，并且启动顺序会影响应用程序的功能，则此属性非常有用。

简写语法

简写语法只指定依赖项的服务名称。服务依赖关系会导致以下行为

Compose 按依赖顺序创建服务。在以下示例中，db 和 redis 在 web 之前创建。
Compose 按依赖顺序删除服务。在以下示例中，web 在 db 和 redis 之前删除。

简单示例

services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

Compose 保证在启动依赖服务之前已启动依赖项服务。Compose 等待依赖项服务“就绪”后，再启动依赖服务。

长写语法

长格式语法允许配置简写格式中无法表达的其他字段。

restart：设置为 true 时，Compose 会在更新依赖服务后重新启动此服务。这适用于由 Compose 操作控制的显式重启，不包括容器死亡后容器运行时自动重启。在 Docker Compose 版本 2.17.0 中引入。
condition：设置依赖项被视为满足的条件
- service_started：与上面描述的简写语法等效
- service_healthy：指定在启动依赖服务之前，依赖项应“正常运行”（如 healthcheck 所示）。
- service_completed_successfully：指定在启动依赖服务之前，依赖项应成功运行完成。
required：设置为 false 时，Compose 只会在依赖服务未启动或不可用时发出警告。如果未定义，则 required 的默认值为 true。在 Docker Compose 版本 2.20.0 中引入。

服务依赖关系会导致以下行为

Compose 按依赖顺序创建服务。在以下示例中，db 和 redis 在 web 之前创建。
Compose 等待对标有 service_healthy 的依赖项执行的健康检查通过。在以下示例中，预期 db 在创建 web 之前处于“正常运行”状态。
Compose 按依赖顺序删除服务。在以下示例中，web 在 db 和 redis 之前删除。

services:
  web:
    build: .
    depends_on:
      db:
        condition: service_healthy
        restart: true
      redis:
        condition: service_started
  redis:
    image: redis
  db:
    image: postgres

Compose 保证在启动依赖服务之前已启动依赖项服务。Compose 保证在启动依赖服务之前，标有 service_healthy 的依赖项服务处于“正常运行”状态。

部署

deploy 指定服务的部署和生命周期配置，如 Compose 部署规范中所定义。

开发

在 Docker Compose 版本 2.22.0 中引入

develop 指定用于维护与源代码同步的容器的开发配置，如开发部分中所定义。

设备控制组规则

device_cgroup_rules 定义此容器的设备 cgroup 规则列表。格式与 Linux 内核在控制组设备白名单控制器中指定的格式相同。

device_cgroup_rules:
  - 'c 1:3 mr'
  - 'a 7:* rmw'

设备

devices 以 HOST_PATH:CONTAINER_PATH[:CGROUP_PERMISSIONS] 的形式定义已创建容器的设备映射列表。

devices:
  - "/dev/ttyUSB0:/dev/ttyUSB0"
  - "/dev/sda:/dev/xvda:rwm"

DNS

dns 定义要设置在容器网络接口配置上的自定义 DNS 服务器。它可以是单个值或列表。

dns: 8.8.8.8

dns:
  - 8.8.8.8
  - 9.9.9.9

DNS 选项

dns_opt 将自定义 DNS 选项传递到容器的 DNS 解析器（Linux 上的 /etc/resolv.conf 文件）的列表。

dns_opt:
  - use-vc
  - no-tld-query

DNS 搜索

dns_search 定义要设置在容器网络接口配置上的自定义 DNS 搜索域。它可以是单个值或列表。

dns_search: example.com

dns_search:
  - dc1.example.com
  - dc2.example.com

域名

domainname 声明要用于服务容器的自定义域名。它必须是有效的 RFC 1123 主机名。

入口点

entrypoint 声明服务容器的默认入口点。这会覆盖服务 Dockerfile 中的 ENTRYPOINT 指令。

如果 entrypoint 非空，Compose 将忽略映像中的任何默认命令，例如 Dockerfile 中的 CMD 指令。

另请参见 command，用于设置或覆盖入口点进程要执行的默认命令。

在其简写形式中，值可以定义为字符串

entrypoint: /code/entrypoint.sh

或者，值也可以是一个列表，方式类似于 Dockerfile

entrypoint:
  - php
  - -d
  - zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
  - -d
  - memory_limit=-1
  - vendor/bin/phpunit

如果值为 null，则使用映像中的默认入口点。

如果值为 []（空列表）或 ''（空字符串），则忽略映像声明的默认入口点，即将其覆盖为空。

环境文件

env_file 属性用于指定一个或多个包含要传递给容器的环境变量的文件。

env_file: .env

相对路径是从 Compose 文件的父文件夹解析的。由于绝对路径会阻止 Compose 文件的可移植性，因此在使用此类路径设置 env_file 时，Compose 会发出警告。

environment 部分中声明的环境变量会覆盖这些值。即使这些值为空或未定义，这也适用。

env_file 也可以是一个列表。列表中的文件从上到下依次处理。对于在两个 env 文件中指定的相同变量，列表中最后一个文件的 value 将生效。

env_file:
  - ./a.env
  - ./b.env

列表元素也可以声明为映射，然后允许您设置其他属性。

required

在 Docker Compose 版本 2.24.0 中引入

required 属性默认为 true。当 required 设置为 false 且 .env 文件缺失时，Compose 会静默忽略该条目。

env_file:
  - path: ./default.env
    required: true # default
  - path: ./override.env
    required: false

format

在 Docker Compose 版本 2.30.0 中引入

format 属性允许您为 env_file 使用替代的文件格式。如果未设置，则根据 Env_file 格式中概述的 Compose 规则解析 env_file。

raw 格式允许您使用包含 key=value 条目的 env_file，但 Compose 不会尝试解析值以进行插值。这允许您按原样传递值，包括引号和 $ 符号。

env_file:
  - path: ./default.env
    format: raw

Env_file 格式

.env 文件中的每一行都必须采用 VAR[=[VAL]] 格式。以下语法规则适用

以 # 开头的行将被视为注释并被忽略。
空行将被忽略。
未加引号和双引号 (") 的值已应用插值。
每一行代表一个键值对。值可以选择用引号括起来。
- VAR=VAL -> VAL
- VAR="VAL" -> VAL
- VAR='VAL' -> VAL
未加引号的值的内联注释必须以空格开头。
- VAR=VAL # 注释 -> VAL
- VAR=VAL# 不是注释 -> VAL# 不是注释
加引号的值的内联注释必须跟在结束引号之后。
- VAR="VAL # 不是注释" -> VAL # 不是注释
- VAR="VAL" # 注释 -> VAL
单引号 (') 值按字面意思使用。
- VAR='$OTHER' -> $OTHER
- VAR='${OTHER}' -> ${OTHER}
引号可以用\转义。
- VAR='Let\'s go!' -> Let's go!
- VAR="{\"hello\": \"json\"}" -> {"hello": "json"}
双引号值支持常见的shell转义序列，包括\n、\r、\t和\\。
- VAR="some\tvalue" -> some value
- VAR='some\tvalue' -> some\tvalue
- VAR=some\tvalue -> some\tvalue

可以省略VAL，在这种情况下，变量值为空字符串。可以省略=VAL，在这种情况下，变量将被取消设置。

# Set Rails/Rack environment
RACK_ENV=development
VAR="quoted"

环境变量

environment属性定义在容器中设置的环境变量。environment可以使用数组或映射。任何布尔值；true、false、yes、no，都应包含在引号中，以确保YAML解析器不会将其转换为True或False。

环境变量可以通过单个键声明（没有值等于号）。在这种情况下，Compose依赖于您来解析值。如果未解析值，则取消设置变量，并将其从服务容器环境中删除。

映射语法

environment:
  RACK_ENV: development
  SHOW: "true"
  USER_INPUT:

数组语法

environment:
  - RACK_ENV=development
  - SHOW=true
  - USER_INPUT

当为服务同时设置env_file和environment时，environment设置的值优先。

公开端口

expose定义Compose从容器公开的（传入）端口或端口范围。这些端口必须可供关联服务访问，并且不应发布到主机。只能指定内部容器端口。

语法为<portnum>/[<proto>]或<startport-endport>/[<proto>]（用于端口范围）。如果未显式设置，则使用tcp协议。

expose:
  - "3000"
  - "8000"
  - "8080-8085/tcp"

注意
如果镜像的Dockerfile已公开端口，即使Compose文件中未设置expose，它也对网络上的其他容器可见。

扩展

extends允许您在不同的文件甚至不同的项目之间共享公共配置。使用extends，您可以在一个地方定义一组公共服务选项，并从任何地方引用它。您可以引用另一个Compose文件并选择您希望在自己的应用程序中使用的服务，并能够根据自己的需求覆盖某些属性。

您可以将extends与其他配置键一起用于任何服务。extends值必须是使用必需的service和可选的file键定义的映射。

extends:
  file: common.yml
  service: webapp

service：定义作为基准引用的服务的名称，例如web或database。
file：定义该服务的Compose配置文件的位置。

当服务使用extends时，它还可以指定对其他资源的依赖关系，例如volumes的显式声明。但是，重要的是要注意，extends不会自动将目标卷定义合并到扩展的Compose文件中。相反，您有责任确保为被扩展的服务存在等效的资源以保持一致性。Docker Compose会验证Compose模型中是否存在具有引用ID的资源。

extends目标中对其他资源的依赖关系可以是：

通过volumes、networks、configs、secrets、links、volumes_from或depends_on的显式引用
在命名空间声明（ipc、pid、network_mode）中使用service:{name}语法引用另一个服务

不支持使用extends进行循环引用，Compose检测到循环引用时会返回错误。

查找引用的服务

file值可以是：

不存在。这表示正在引用同一个Compose文件中的另一个服务。
文件路径，可以是：
- 相对路径。此路径被视为相对于主Compose文件的位置。
- 绝对路径。

必须在标识的引用Compose文件中存在由service表示的服务。如果出现以下情况，Compose将返回错误：

找不到由service表示的服务。
找不到由file表示的Compose文件。

合并服务定义

两个服务定义（当前Compose文件中的主要定义和extends指定的引用定义）按以下方式合并：

映射：主要服务定义中的映射键会覆盖引用服务定义中的映射键。未被覆盖的键按原样包含。
序列：项目组合成一个新的序列。元素的顺序保持不变，引用项在前，主要项在后。
标量：主要服务定义中的键优先于引用定义中的键。

以下键应视为映射：annotations、build.args、build.labels、build.extra_hosts、deploy.labels、deploy.update_config、deploy.rollback_config、deploy.restart_policy、deploy.resources.limits、environment、healthcheck、labels、logging.options、sysctls、storage_opt、extra_hosts、ulimits。

healthcheck的一个例外是，除非引用映射也指定disable: true，否则主要映射不能指定disable: true。在这种情况下，Compose会返回错误。

例如，以下输入：

services:
  common:
    image: busybox
    environment:
      TZ: utc
      PORT: 80
  cli:
    extends:
      service: common
    environment:
      PORT: 8080

为cli服务生成以下配置。如果使用数组语法，也会产生相同的输出。

environment:
  PORT: 8080
  TZ: utc
image: busybox

blkio_config.device_read_bps、blkio_config.device_read_iops、blkio_config.device_write_bps、blkio_config.device_write_iops、devices和volumes下的项目也视为映射，其中键是容器内的目标路径。

例如，以下输入：

services:
  common:
    image: busybox
    volumes:
      - common-volume:/var/lib/backup/data:rw
  cli:
    extends:
      service: common
    volumes:
      - cli-volume:/var/lib/backup/data:ro

为cli服务生成以下配置。请注意，挂载路径现在指向新的卷名，并且应用了ro标志。

image: busybox
volumes:
- cli-volume:/var/lib/backup/data:ro

如果引用的服务定义包含extends映射，则其下的项目将简单地复制到新的合并定义中。然后，合并过程会再次启动，直到没有剩余的extends键。

例如，以下输入：

services:
  base:
    image: busybox
    user: root
  common:
    image: busybox
    extends:
      service: base
  cli:
    extends:
      service: common

为cli服务生成以下配置。这里，cli服务从common服务获取user键，而common服务又从base服务获取此键。

image: busybox
user: root

序列

以下键应视为序列：cap_add、cap_drop、configs、deploy.placement.constraints、deploy.placement.preferences、deploy.reservations.generic_resources、device_cgroup_rules、expose、external_links、ports、secrets、security_opt。合并产生的任何重复项都将被删除，以便序列仅包含唯一元素。

例如，以下输入：

services:
  common:
    image: busybox
    security_opt:
      - label:role:ROLE
  cli:
    extends:
      service: common
    security_opt:
      - label:user:USER

为cli服务生成以下配置。

image: busybox
security_opt:
- label:role:ROLE
- label:user:USER

如果使用列表语法，以下键也应视为序列：dns、dns_search、env_file、tmpfs。与上面提到的序列字段不同，合并产生的重复项不会被删除。

标量

服务定义中任何其他允许的键都应视为标量。

外部链接

external_links将服务容器链接到Compose应用程序外部管理的服务。external_links定义要使用平台查找机制检索的现有服务的名称。可以指定SERVICE:ALIAS形式的别名。

external_links:
  - redis
  - database:mysql
  - database:postgresql

额外主机

extra_hosts将主机名映射添加到容器网络接口配置（Linux的/etc/hosts）。

简写语法

简写语法在列表中使用纯字符串。值必须以HOSTNAME=IP的形式为附加主机设置主机名和IP地址。

extra_hosts:
  - "somehost=162.242.195.82"
  - "otherhost=50.31.209.229"
  - "myhostv6=::1"

IPv6地址可以包含在方括号中，例如：

extra_hosts:
  - "myhostv6=[::1]"

首选分隔符=，但也可以使用:。在Docker Compose版本2.24.1中引入。例如：

extra_hosts:
  - "somehost:162.242.195.82"
  - "myhostv6:::1"

长写语法

或者，可以将extra_hosts设置为主机名和IP之间的映射：

extra_hosts:
  somehost: "162.242.195.82"
  otherhost: "50.31.209.229"
  myhostv6: "::1"

Compose在容器的网络配置中创建具有IP地址和主机名的匹配条目，这意味着对于Linux，/etc/hosts将获得额外的行：

162.242.195.82  somehost
50.31.209.229   otherhost
::1             myhostv6

添加组

group_add指定附加组（按名称或编号），容器内的用户必须是这些组的成员。

这在多个容器（以不同的用户身份运行）都需要读取或写入共享卷上的同一个文件时非常有用。该文件可以由所有容器共享的组拥有，并在group_add中指定。

services:
  myservice:
    image: alpine
    group_add:
      - mail

在创建的容器内运行id必须显示用户属于mail组，如果没有声明group_add，则不会出现这种情况。

健康检查

healthcheck属性声明一个运行的检查，用于确定服务容器是否“健康”。它的工作方式以及默认值与服务Docker镜像设置的HEALTHCHECK Dockerfile指令相同。您的Compose文件可以覆盖Dockerfile中设置的值。

有关HEALTHCHECK的更多信息，请参见Dockerfile 参考。

healthcheck:
  test: ["CMD", "curl", "-f", "https://127.0.0.1"]
  interval: 1m30s
  timeout: 10s
  retries: 3
  start_period: 40s
  start_interval: 5s

interval、timeout、start_period和start_interval是指定为持续时间的。在 Docker Compose 版本2.20.2中引入。

test 定义了 Compose 用于检查容器健康状况的命令。它可以是字符串或列表。如果它是列表，则第一项必须是NONE、CMD 或CMD-SHELL。如果它是字符串，则相当于指定CMD-SHELL 后跟该字符串。

# Hit the local web app
test: ["CMD", "curl", "-f", "https://127.0.0.1"]

使用CMD-SHELL 使用容器的默认 shell（Linux 系统为/bin/sh）运行配置为字符串的命令。以下两种形式是等效的。

test: ["CMD-SHELL", "curl -f https://127.0.0.1 || exit 1"]

test: curl -f https://127.0.0.1 || exit 1

NONE 禁用健康检查，主要用于禁用服务 Docker 镜像设置的 Healthcheck Dockerfile 指令。或者，可以通过设置disable: true来禁用镜像设置的健康检查。

healthcheck:
  disable: true

主机名

hostname声明要为服务容器使用的自定义主机名。它必须是有效的 RFC 1123 主机名。

镜像

image 指定要从中启动容器的镜像。image 必须遵循开放容器规范可寻址镜像格式，例如[<registry>/][<project>/]<image>[:<tag>|@<digest>]。

    image: redis
    image: redis:5
    image: redis@sha256:0ed5d5928d4737458944eb604cc8509e245c3e19d02ad83935398bc4b991aac7
    image: library/redis
    image: docker.io/library/redis
    image: my_private.registry:5000/redis

如果平台上不存在该镜像，Compose 将根据pull_policy尝试拉取它。如果您还使用Compose 构建规范，则存在控制拉取优先于从源代码构建镜像的替代选项，但是拉取镜像是默认行为。

只要声明了build部分，就可以从 Compose 文件中省略image。如果您未使用 Compose 构建规范，则如果 Compose 文件中缺少image，Compose 将无法工作。

初始化进程

init 在容器内运行一个 init 进程 (PID 1)，它转发信号并收集进程。将此选项设置为true即可为服务启用此功能。

services:
  web:
    image: alpine:latest
    init: true

使用的 init 二进制文件是特定于平台的。

IPC

ipc 配置服务容器设置的 IPC 隔离模式。

shareable：为容器提供它自己的私有 IPC 命名空间，并有可能与其他容器共享。
service:{name}：使容器加入另一个容器的 (shareable) IPC 命名空间。

    ipc: "shareable"
    ipc: "service:[service name]"

隔离

isolation 指定容器的隔离技术。支持的值是特定于平台的。

链接

links 定义到另一个服务中容器的网络链接。指定服务名称和链接别名 (SERVICE:ALIAS)，或只指定服务名称。

web:
  links:
    - db
    - db:database
    - redis

链接服务的容器可在与别名相同的主机名处访问，如果未指定别名，则为服务名称。

链接不需要启用服务间的通信。当没有设置特定的网络配置时，任何服务都能够在default网络上以该服务的名称访问任何其他服务。如果服务声明了它们所附加的网络，则links不会覆盖网络配置，并且未附加到共享网络的服务将无法通信。Compose不会警告您配置不匹配。

链接也像depends_on一样表示服务之间的隐式依赖关系，因此它们决定了服务的启动顺序。

日志记录

logging 定义服务的日志记录配置。

logging:
  driver: syslog
  options:
    syslog-address: "tcp://192.168.0.42:123"

driver名称指定服务容器的日志驱动程序。默认值和可用值是特定于平台的。可以使用options作为键值对设置特定于驱动的选项。

MAC 地址

Docker Compose 版本 2.24.0 及更高版本可用。

mac_address 设置服务容器的 MAC 地址。

注意
容器运行时可能会拒绝此值（例如 Docker Engine >= v25.0）。在这种情况下，您应该改用networks.mac_address。

内存限制

mem_limit 配置容器可以分配的内存量限制，设置为表示字节值的字符串。

设置后，mem_limit必须与部署规范中的limits.memory属性一致。

内存预留

mem_reservation 配置容器可以分配的内存量预留，设置为表示字节值的字符串。

设置后，mem_reservation必须与部署规范中的reservations.memory属性一致。

内存交换率

mem_swappiness 定义为主机内核交换容器使用的匿名内存页面的百分比，值为 0 到 100 之间。

0：关闭匿名页面交换。
100：将所有匿名页面设置为可交换。

默认值是特定于平台的。

内存交换限制

memswap_limit 定义容器允许交换到磁盘的内存量。这是一个修饰符属性，只有当也设置了memory时才有意义。使用交换允许容器在容器用尽所有可用内存时将多余的内存需求写入磁盘。对于经常将内存交换到磁盘的应用程序，会产生性能损失。

如果memswap_limit设置为正整数，则必须同时设置memory和memswap_limit。memswap_limit表示可以使用的内存和交换总量，memory控制非交换内存的使用量。因此，如果memory="300m"且memswap_limit="1g"，则容器可以使用 300m 内存和 700m (1g - 300m) 交换空间。
如果memswap_limit设置为 0，则忽略该设置，并将该值视为未设置。
如果memswap_limit设置为与memory相同的值，并且memory设置为正整数，则容器无法访问交换空间。
如果memswap_limit未设置，并且设置了memory，则如果主机容器配置了交换内存，则容器可以使用与memory设置一样多的交换空间。例如，如果memory="300m"且未设置memswap_limit，则容器总共可以使用 600m 内存和交换空间。
如果memswap_limit明确设置为 -1，则容器允许使用无限的交换空间，最多可以使用主机系统上可用的交换空间。

网络模式

network_mode 设置服务容器的网络模式。

none：关闭所有容器网络。
host：使容器可以原始访问主机的网络接口。
service:{name}：通过引用其服务名称使容器可以访问指定的容器。
container:{name}：通过引用其容器 ID 使容器可以访问指定的容器。

有关容器网络的更多信息，请参见Docker Engine 文档。

    network_mode: "host"
    network_mode: "none"
    network_mode: "service:[service name]"

设置后，不允许使用networks属性，并且 Compose 会拒绝任何包含这两个属性的 Compose 文件。

网络

networks属性定义服务容器附加到的网络，引用networks顶级元素下的条目。networks属性有助于管理容器的网络方面，提供对如何在 Docker 环境中分割和交互服务的控制。这用于指定该服务的容器应连接到的网络。这对于定义容器如何相互通信以及与外部通信非常重要。

services:
  some-service:
    networks:
      - some-network
      - other-network

有关networks顶级元素的更多信息，请参见网络。

别名

aliases声明服务在网络上的替代主机名。同一网络上的其他容器可以使用服务名称或别名来连接到该服务的其中一个容器。

由于aliases是网络范围的，因此同一服务可以在不同的网络上具有不同的别名。

注意
多个容器甚至多个服务可以共享网络范围的别名。如果是这样，则名称解析到的确切容器不能保证。

services:
  some-service:
    networks:
      some-network:
        aliases:
          - alias1
          - alias3
      other-network:
        aliases:
          - alias2

在以下示例中，服务frontend能够在back-tier网络上以主机名backend或database访问backend服务。服务monitoring能够在admin网络上以backend或mysql访问相同的backend服务。

services:
  frontend:
    image: example/webapp
    networks:
      - front-tier
      - back-tier

  monitoring:
    image: example/monitoring
    networks:
      - admin

  backend:
    image: example/backend
    networks:
      back-tier:
        aliases:
          - database
      admin:
        aliases:
          - mysql

networks:
  front-tier:
  back-tier:
  admin:

ipv4_address、ipv6_address

加入网络时，为服务容器指定静态 IP 地址。

顶级网络部分中的相应网络配置必须具有包含每个静态地址的子网配置的ipam属性。

services:
  frontend:
    image: example/webapp
    networks:
      front-tier:
        ipv4_address: 172.16.238.10
        ipv6_address: 2001:3984:3989::10

networks:
  front-tier:
    ipam:
      driver: default
      config:
        - subnet: "172.16.238.0/24"
        - subnet: "2001:3984:3989::/64"

link_local_ips

link_local_ips 指定了一系列链路本地 IP 地址。链路本地 IP 地址是属于已知子网的特殊 IP 地址，完全由运营商管理，通常取决于其部署的架构。

示例

services:
  app:
    image: busybox
    command: top
    networks:
      app_net:
        link_local_ips:
          - 57.123.22.11
          - 57.123.22.13
networks:
  app_net:
    driver: bridge

MAC 地址

在 Docker Compose 版本 2.23.2 中引入

mac_address 设置服务容器连接到此特定网络时使用的 MAC 地址。

优先级

priority 指示 Compose 将服务的容器连接到其网络的顺序。如果未指定，则默认值为 0。

在下面的示例中，app 服务首先连接到 app_net_1，因为它具有最高的优先级。然后它连接到 app_net_3，然后是 app_net_2，后者使用默认优先级值 0。

services:
  app:
    image: busybox
    command: top
    networks:
      app_net_1:
        priority: 1000
      app_net_2:

      app_net_3:
        priority: 100
networks:
  app_net_1:
  app_net_2:
  app_net_3:

禁用OOM杀进程

如果设置了 oom_kill_disable，Compose 将配置平台，以便在内存不足的情况下不会终止容器。

OOM得分调整

oom_score_adj 微调平台在内存不足的情况下终止容器的首选项。值必须在 -1000 到 1000 范围内。

PID

pid 设置 Compose 创建的容器的 PID 模式。支持的值是特定于平台的。

PID 限制

pids_limit 微调容器的 PIDs 限制。设置为 -1 表示 PIDs 无限。

pids_limit: 10

如果设置了 pids_limit，则必须与部署规范中的 pids 属性一致。

平台

platform 定义服务容器在其上运行的目标平台。它使用 os[/arch[/variant]] 语法。

os、arch 和 variant 的值必须符合 OCI 镜像规范中使用的约定。

Compose 使用此属性来确定要拉取哪个版本的镜像和/或在哪个平台上执行服务的构建。

platform: darwin
platform: windows/amd64
platform: linux/arm64/v8

端口

ports 用于定义主机和容器之间的端口映射。这对于允许外部访问容器内运行的服务至关重要。它可以使用简短语法进行简单的端口映射，也可以使用长语法，其中包括协议类型和网络模式等附加选项。

注意
端口映射不能与 network_mode: host 一起使用，否则会发生运行时错误。

简写语法

简短语法是用冒号分隔的字符串，用于设置主机 IP、主机端口和容器端口，格式为

[HOST:]CONTAINER[/PROTOCOL]，其中

HOST 为 [IP:](port | range)
CONTAINER 为 port | range
PROTOCOL 用于将端口限制为指定的协议。tcp 和 udp 值由规范定义，Compose 支持特定于平台的协议名称。

如果未设置主机 IP，则它将绑定到所有网络接口。端口可以是单个值或范围。主机和容器必须使用等效的范围。

指定两个端口 (HOST:CONTAINER)，或只指定容器端口。在后一种情况下，容器运行时会自动分配主机的任何未分配端口。

HOST:CONTAINER 应始终指定为（带引号的）字符串，以避免与 YAML 基数-60 浮点数冲突。

示例

ports:
  - "3000"
  - "3000-3005"
  - "8000:8000"
  - "9090-9091:8080-8081"
  - "49100:22"
  - "8000-9000:80"
  - "127.0.0.1:8001:8001"
  - "127.0.0.1:5000-5010:5000-5010"
  - "6060:6060/udp"

注意
如果容器引擎不支持主机 IP 映射，Compose 将拒绝 Compose 文件并忽略指定的主机 IP。

长写语法

长格式语法允许配置简短格式中无法表达的其他字段。

target：容器端口
published：公开暴露的端口。它定义为字符串，可以使用 start-end 语法设置为范围。这意味着实际端口被分配一个剩余的可用端口，在这个设置的范围内。
host_ip：主机 IP 映射，未指定表示所有网络接口 (0.0.0.0)。
protocol：端口协议 (tcp 或 udp)。默认为 tcp。
app_protocol：此端口使用的应用程序协议（TCP/IP 第 4 层 / OSI 第 7 层）。这是可选的，可用作提示，以便 Compose 为其理解的协议提供更丰富的行为。在 Docker Compose 版本 2.26.0 中引入。
mode：host：用于在每个节点上发布主机端口，或 ingress 用于负载均衡端口。默认为 ingress。
name：端口的人类可读名称，用于记录其在服务中的用法。

ports:
  - name: web
    target: 80
    host_ip: 127.0.0.1
    published: "8080"
    protocol: tcp
    app_protocol: http
    mode: host

  - name: web-secured
    target: 443
    host_ip: 127.0.0.1
    published: "8083-9000"
    protocol: tcp
    app_protocol: https
    mode: host

启动后操作

在 Docker Compose 版本 2.30.0 中引入

post_start 定义容器启动后运行的一系列生命周期钩子。命令运行的确切时间没有保证。

command：指定容器启动后要运行的命令。此属性是必需的，您可以选择使用 shell 格式或 exec 格式。
user：运行命令的用户。如果未设置，则命令将与主服务命令相同的用户一起运行。
privileged：允许 post_start 命令以特权访问权限运行。
working_dir：运行命令的工作目录。如果未设置，则在与主服务命令相同的工作目录中运行。
environment：专门为 post_start 命令设置环境变量。虽然该命令继承为服务的主命令定义的环境变量，但此部分允许您添加新变量或覆盖现有变量。

services:
  test:
    post_start:
      - command: ./do_something_on_startup.sh
        user: root
        privileged: true
        environment:
          - FOO=BAR

更多信息，请参见使用生命周期钩子。

停止前操作

在 Docker Compose 版本 2.30.0 中引入

pre_stop 定义容器停止前要运行的一系列生命周期钩子。如果容器自行停止或突然终止，这些钩子将不会运行。

配置等效于 `post_start`。

特权模式

privileged 将服务容器配置为以提升的权限运行。支持和实际影响是特定于平台的。

配置文件

profiles 定义服务要在其下启用的命名配置文件列表。如果未分配，则服务始终启动，但如果已分配，则只有在激活配置文件时才启动。

如果存在，profiles 遵循 [a-zA-Z0-9][a-zA-Z0-9_.-]+ 的正则表达式格式。

services:
  frontend:
    image: frontend
    profiles: ["frontend"]

  phpmyadmin:
    image: phpmyadmin
    depends_on:
      - db
    profiles:
      - debug

拉取策略

pull_policy 定义 Compose 在开始拉取镜像时做出的决策。可能的值为：

always：Compose 始终从注册表拉取镜像。
never：Compose 不从注册表拉取镜像，而是依赖于平台缓存的镜像。如果没有缓存的镜像，则会报告失败。
missing：只有在平台缓存中不存在镜像时，Compose 才会拉取镜像。如果您没有使用 Compose 构建规范，这是默认选项。出于向后兼容性的考虑，if_not_present 被认为是此值的别名。
build：Compose 构建镜像。如果镜像已存在，Compose 将重新构建镜像。

只读模式

read_only 将服务容器配置为使用只读文件系统创建。

重启策略

restart 定义平台在容器终止时应用的策略。

no：默认重启策略。在任何情况下都不会重启容器。
always：此策略始终重启容器，直到将其删除。
on-failure[:max-retries]：如果退出代码指示错误，则此策略会重启容器。或者，限制 Docker 守护程序尝试的重启重试次数。
unless-stopped：此策略会重启容器，而不管退出代码如何，但在停止或删除服务时停止重启。

    restart: "no"
    restart: always
    restart: on-failure
    restart: on-failure:3
    restart: unless-stopped

您可以在 Docker run 参考页面的重启策略 (--restart) 部分找到有关重启策略的更多详细信息。

运行时

runtime 指定要用于服务容器的运行时。

例如，runtime 可以是 OCI 运行时规范的实现（例如，“runc”）的名称。

web:
  image: busybox:latest
  command: true
  runtime: runc

默认为 runc。要使用其他运行时，请参见替代运行时。

扩展

scale 指定为此服务部署的容器的默认数量。如果两者都设置了，则 scale 必须与部署规范中的 replicas 属性一致。

密钥

secrets 属性允许按服务为基础访问由顶级 secrets 元素定义的敏感数据。服务可以被授予访问多个密钥的权限。

支持两种不同的语法变体：简写语法和长写语法。可以在同一个 Compose 文件中使用长语法和简写语法。

如果密钥在平台上不存在，或者未在 Compose 文件的secrets 顶级部分中定义，Compose 将报告错误。

在顶级 secrets 中定义密钥并不意味着授予任何服务对其的访问权限。此类授权必须在服务规范中作为secrets 服务元素明确指定。

简写语法

简写语法变体仅指定密钥名称。这允许容器访问密钥，并将其以只读方式挂载到容器内的 /run/secrets/<secret_name>。源名称和目标挂载点都设置为密钥名称。

以下示例使用简写语法，将 frontend 服务授予对 server-certificate 密钥的访问权限。server-certificate 的值设置为文件 ./server.cert 的内容。

services:
  frontend:
    image: example/webapp
    secrets:
      - server-certificate
secrets:
  server-certificate:
    file: ./server.cert

长写语法

长写语法提供了更细粒度的控制，用于在服务的容器内创建密钥的方式。

source：密钥在平台上的名称。
target：要在服务的任务容器中的 /run/secrets/ 中挂载的文件名，如果需要其他位置，则为文件的绝对路径。如果未指定，则默认为 source。
uid 和 gid：拥有服务任务容器中 /run/secrets/ 内文件的数字 UID 或 GID。默认值为运行容器的用户。
mode：服务任务容器中 /run/secrets/ 中要挂载的文件的权限，以八进制表示。默认值为世界可读权限（模式 0444）。如果设置了可写位，则必须忽略它。可以设置可执行位。

以下示例将 server-certificate 密钥文件在容器内的名称设置为 server.cert，将模式设置为 0440（组可读），并将用户和组设置为 103。server-certificate 的值设置为文件 ./server.cert 的内容。

services:
  frontend:
    image: example/webapp
    secrets:
      - source: server-certificate
        target: server.cert
        uid: "103"
        gid: "103"
        mode: "0440"
secrets:
  server-certificate:
    file: ./server.cert

安全选项

security_opt 覆盖每个容器的默认标签方案。

security_opt:
  - label:user:USER
  - label:role:ROLE

有关可以覆盖的其他默认标签方案，请参阅安全配置。

    stop_grace_period: 1s
    stop_grace_period: 1m30s

默认值为 10 秒，容器在发送 SIGKILL 之前退出。

停止信号

stop_signal 定义 Compose 用于停止服务容器的信号。如果未设置，Compose 将通过发送 SIGTERM 来停止容器。

stop_signal: SIGUSR1

存储选项

storage_opt 定义服务的存储驱动程序选项。

storage_opt:
  size: '1G'

系统控制

sysctls 定义要在容器中设置的内核参数。sysctls 可以使用数组或映射。

sysctls:
  net.core.somaxconn: 1024
  net.ipv4.tcp_syncookies: 0

sysctls:
  - net.core.somaxconn=1024
  - net.ipv4.tcp_syncookies=0

你只能使用内核中已命名空间的 sysctls。Docker 不支持更改容器内的 sysctls，这些 sysctls 也会修改主机系统。有关受支持的 sysctls 的概述，请参阅在运行时配置命名空间内核参数 (sysctls)。

tmpfs

tmpfs 在容器内挂载临时文件系统。它可以是单个值或列表。

tmpfs:
 - <path>
 - <path>:<options>

：容器内挂载 tmpfs 的路径。
：tmpfs 挂载选项的逗号分隔列表。

可用选项

mode：设置文件系统权限。
uid：设置拥有已挂载 tmpfs 的用户 ID。
gid：设置拥有已挂载 tmpfs 的组 ID。

services:
  app:
    tmpfs:
      - /data:mode=755,uid=1009,gid=1009
      - /run

TTY

tty 配置服务的容器以 TTY 运行。这与使用 -t 或 --tty 标志运行容器相同。有关更多信息，请参阅分配伪 TTY。

支持的值为 true 或 false。

ulimits

ulimits 覆盖容器的默认 ulimits。它被指定为单个限制的整数，或者作为软/硬限制的映射。

ulimits:
  nproc: 65535
  nofile:
    soft: 20000
    hard: 40000

用户

user 覆盖用于运行容器进程的用户。默认值由镜像设置（即 Dockerfile USER）。如果未设置，则为 root。

用户命名空间模式

userns_mode 设置服务的 user namespace。支持的值是特定于平台的，可能取决于平台配置。

userns_mode: "host"

UTS

在 Docker Compose 版本 2.15.1 中引入

uts 配置为服务容器设置的 UTS namespace 模式。如果未指定，则由运行时决定是否分配 UTS namespace（如果支持）。可用值为

'host'：导致容器使用与主机相同的 UTS namespace。

    uts: "host"

卷

volumes 属性定义服务容器可访问的挂载主机路径或命名卷。你可以使用 volumes 定义多种类型的挂载；volume、bind、tmpfs 或 npipe。

如果挂载是主机路径并且仅由单个服务使用，则可以将其声明为服务定义的一部分。要跨多个服务重用卷，必须在 volumes 顶级元素中声明命名卷。

以下示例显示 backend 服务使用命名卷 (db-data)，以及为单个服务定义的 bind 挂载。

services:
  backend:
    image: example/backend
    volumes:
      - type: volume
        source: db-data
        target: /data
        volume:
          nocopy: true
          subpath: sub
      - type: bind
        source: /var/run/postgres/postgres.sock
        target: /var/run/postgres/postgres.sock

volumes:
  db-data:

有关 volumes 顶级元素的更多信息，请参阅卷。

简写语法

简写语法使用带有冒号分隔值的单个字符串来指定卷挂载 (VOLUME:CONTAINER_PATH) 或访问模式 (VOLUME:CONTAINER_PATH:ACCESS_MODE)。

VOLUME：可以是托管容器的平台上的主机路径（bind 挂载）或卷名。
CONTAINER_PATH：容器中挂载卷的路径。
ACCESS_MODE：逗号分隔的 , 选项列表
- rw：读写访问权限。如果未指定，则为默认值。
- ro：只读访问权限。
- z：SELinux 选项，指示 bind 挂载主机内容在多个容器之间共享。
- Z：SELinux 选项，指示 bind 挂载主机内容对于其他容器是私有的且不共享的。

注意
在没有 SELinux 的平台上，将忽略 SELinux 重新标记 bind 挂载选项。

注意
相对主机路径仅受部署到本地容器运行时的 Compose 支持。这是因为相对路径是从 Compose 文件的父目录解析的，这仅适用于本地情况。当 Compose 部署到非本地平台时，它将拒绝使用相对主机路径的 Compose 文件，并显示错误。为避免与命名卷产生歧义，相对路径应始终以 . 或 .. 开头。

长写语法

长格式语法允许配置简短格式中无法表达的其他字段。

type：挂载类型。可以是 volume、bind、tmpfs、npipe 或 cluster
source：挂载的来源，bind 挂载的主机上的路径，或在顶级 volumes 键中定义的卷的名称。对于 tmpfs 挂载不适用。
target：容器中挂载卷的路径。
read_only：将卷设置为只读的标志。
bind：用于配置其他 bind 选项
- propagation：用于 bind 的传播模式。
- create_host_path：如果主机上不存在任何内容，则在源路径上创建一个目录。如果路径上存在任何内容，Compose 不会执行任何操作。为了与 docker-compose 旧版本向后兼容，简写语法会自动暗示这一点。
- selinux：SELinux 重新标记选项 z（共享）或 Z（私有）
volume：配置其他卷选项
- nocopy：禁用创建卷时从容器复制数据的标志。
- subpath：卷内要挂载的路径，而不是卷根目录。
tmpfs：配置其他 tmpfs 选项
- size：tmpfs 挂载的大小（以字节为单位，可以是数字或字节单位）。
- mode：tmpfs 挂载的文件模式，作为 Unix 权限位，以八进制数表示。在 Docker Compose 版本 2.14.0 中引入。
consistency：挂载的一致性要求。可用值是特定于平台的。

提示
使用大型代码库或单体仓库，或者虚拟文件系统无法再扩展以适应您的代码库规模？Compose 现在利用了同步文件共享并自动为绑定挂载创建文件共享。请确保您已使用付费订阅登录 Docker，并在 Docker Desktop 的设置中启用了访问实验性功能和使用 Compose 管理同步文件共享。

来自卷

volumes_from 挂载来自另一个服务或容器的所有卷。您可以选择指定只读访问ro或读写访问rw。如果未指定访问级别，则使用读写访问。

您还可以使用container:前缀挂载来自非 Compose 管理的容器的卷。

volumes_from:
  - service_name
  - service_name:ro
  - container:container_name
  - container:container_name:rw

工作目录

working_dir 覆盖容器的工作目录，该目录由镜像指定，例如 Dockerfile 的WORKDIR。