服务顶级元素

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

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

每个服务还可以包含一个 build 部分，用于定义如何为该服务创建 Docker 镜像。 Compose 支持使用此服务定义构建 Docker 镜像。如果未使用，build 部分将被忽略，但 Compose 文件仍被视为有效。构建支持是 Compose 规范的可选部分，并在 Compose Build 规范 文档中有详细说明。

每个服务都定义了运行时约束和要求来运行其容器。deploy 部分对这些约束进行分组，并允许平台调整部署策略，以使容器的需求与可用资源达到最佳匹配。Deploy 支持是 Compose 规范的可选部分，并在 Compose Deploy 规范 文档中有详细说明。如果未实现，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:
  com.example.foo: bar

annotations:
  - com.example.foo=bar

附着

当 attach 被定义并设置为 false 时，Compose 不会收集服务日志， 直到您明确请求它。

默认服务配置为 attach: true。

构建

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

blkio_config

blkio_config 定义了一组配置选项，用于为服务设置块 I/O 限制。

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: 可以是表示字节数的整数值，也可以是表示字节值的字符串。

设备读IOPS, 设备写IOPS

为指定设备的读/写操作设置每秒操作次数的限制。 列表中的每一项必须包含两个键：

• path: 定义受影响设备的符号路径。
• rate: 作为整数值，表示每秒允许的操作次数。

权重

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

weight_device

按设备精细调整带宽分配。列表中的每一项必须包含两个键：

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

cpu_count

cpu_count 定义了服务容器可用 CPU 的数量。

cpu_percent

cpu_percent 定义了可用 CPU 的可用百分比。

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 指定了额外的容器 能力 作为字符串。

cap_add:
  - ALL

cap_drop

cap_drop 指定容器 capabilities 以删除 作为字符串。

cap_drop:
  - NET_ADMIN
  - SYS_ADMIN

cgroup

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

• host: 在容器运行时 cgroup 命名空间中运行容器。
• private: 在其私有的 cgroup 命名空间中运行容器。

cgroup_parent

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 顶级元素中定义，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 是一个字符串，用于指定自定义容器名称，而不是默认生成的名称。

container_name: my-web-container

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

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

credential_spec

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

如果您有使用 Windows 容器的服务，则可以将 file: 和 registry: 协议用于 credential_spec。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

通过 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: 指定在启动依赖服务之前，依赖项预期应为“健康”状态（由 健康检查指示）。
  • service_completed_successfully: 指定依赖项预期在启动依赖服务之前成功运行完成。

• required: 当设置为 false 时，Compose 仅在依赖服务未启动或不可用时发出警告。如果未定义，则默认值 required 为 true。引入于 Docker Compose 版本 2.20.0。

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

• Compose 会等待标记为 service_healthy 的依赖项通过健康检查。在以下示例中，web 创建之前，预期 db 处于“healthy”状态。

• 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 部署规范中所定义。

开发

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

device_cgroup_rules

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_opt

dns_opt 列出要传递给容器 DNS 解析器的自定义 DNS 选项（Linux 上为 /etc/resolv.conf 个文件）。

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

dns_search

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

dns_search: example.com

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

域名

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

driver_opts

driver_opts 指定作为键值对列表传递给驱动程序的选项列表。这些选项依赖于驱动程序。

services:
  app:
    networks:
      app_net:
        driver_opts:
          com.docker.network.bridge.host_binding_ipv4: "127.0.0.1"

有关更多信息，请参阅 网络驱动程序文档。

入口点（ENTRYPOINT）

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_file: .env

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

在 环境 部分中声明的环境变量会覆盖这些值。即使这些值为空或未定义，也是如此。

env_file 也可以是一个列表。列表中的文件按从上到下的顺序处理。对于在两个环境文件中指定的同一个变量，以列表中最后一个文件的值为准。

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

列表元素也可以声明为映射，这样就可以设置额外的属性。

必需

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

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

格式化

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

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 # comment -> VAL
  • VAR=VAL# not a comment -> VAL# not a comment
• 引号值的内联注释必须跟在闭合引号之后。
  • VAR="VAL # not a comment" -> VAL # not a comment
  • VAR="VAL" # comment -> 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 进行显式引用
• 在命名空间声明中使用 service:{name} 语法对另一个服务的引用 (ipc, pid, network_mode)

不支持带有 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 密钥，而后者又从 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

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

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

extra_hosts

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 指定了用户在容器内必须属于的附加组，可以通过名称或编号指定。

此功能的一个实用场景是当多个容器（以不同用户身份运行）需要读取或写入共享卷上的同一文件时。该文件可以由所有容器共享的组拥有，并在 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", "http://localhost"]
  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", "http://localhost"]

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

test: ["CMD-SHELL", "curl -f http://localhost || exit 1"]

test: curl -f https://localhost || 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 构建规范，则有其他选项可用于控制拉取镜像与从源代码构建镜像的优先级，但拉取镜像是默认行为。

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

初始化

init 在容器内运行初始化进程 (PID 1)，该进程转发信号并回收进程。 将此选项设置为 true 可为服务启用此功能。

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

使用的 init Binaries是特定于平台的。

进程间通信

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

• shareable: 为容器提供独立的私有 IPC 命名空间，并允许与其他容器共享。
• service:{name}: 使容器加入另一个容器的 (shareable) IPC 命名空间。

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

隔离

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

标签

labels 向容器添加元数据。您可以使用数组或映射。

建议您使用反向 DNS 表示法，以防止您的标签与其他软件使用的标签发生冲突。

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

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

Compose 创建带有规范标签的容器：

• com.docker.compose.project 在 Compose 创建的所有资源上设置为用户项目名称
• com.docker.compose.service 设置在服务容器上，使用 Compose 文件中定义的服务名称

com.docker.compose 标签前缀是保留的。在 Compose 文件中指定带有此前缀的标签会导致运行时错误。

链接

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_address

适用于 Docker Compose 2.24.0 及更高版本。

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

注意

容器运行时可能会拒绝此值（即 Docker Engine >= v25.0）。在这种情况下，你应该使用 networks.mac_address 代替。

mem_limit

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

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

mem_reservation

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

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

mem_swappiness

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

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

默认值取决于平台。

memswap_limit

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 设置为正整数，则容器无法访问 swap。
• 如果未设置 memswap_limit，且 memory 已设置，则容器可以使用与 memory 设置值相同的交换空间，前提是主机容器配置了交换内存。例如，如果 memory="300m" 且未设置 memswap_limit，则容器总共可以使用 600m 的内存和交换空间。
• 如果 memswap_limit 被显式设置为 -1，则允许容器使用无限制的交换空间，最大可达主机系统上可用的数量。

network_mode

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地址, ipv6地址

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

顶级 networks 部分中的相应网络配置必须包含一个 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_address

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

优先级

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

在下面的示例中，应用服务首先连接到 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_kill_disable

如果设置为 oom_kill_disable，Compose 会配置平台，使其在内存耗尽的情况下不会终止容器。

oom_score_adj

oom_score_adj 调整了在内存不足时平台优先终止容器的偏好。取值范围必须在 -1000 到 1000 之间。

pid

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

pids_limit

pids_limit 调整容器的 PID 限制。设置为 -1 表示不限制 PID。

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 is [IP:](port | range)
• CONTAINER is port | range
• PROTOCOL 将端口限制为指定的协议。tcp 和 udp 的值由规范定义， Compose 提供了对特定平台协议名称的支持。

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

要么同时指定两个端口（HOST:CONTAINER），要么仅指定容器端口。在后一种情况下， 容器运行时会自动分配主机上任何未分配的端口。

HOST:CONTAINER 应始终指定为（带引号的）字符串，以避免与 yaml base-60 float 冲突。

示例：

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

post_start

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

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

pre_stop

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

pull_policy 定义了 Compose 在开始拉取镜像时所做的决定。可能的值有：

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

read_only

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 Runtime Spec 的实现的名称，例如 "runc"。

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

默认值为 runc。要使用不同的运行时，请参阅 替代运行时。

缩放

scale 指定了该服务默认部署的容器数量。 当两者都设置时，scale 必须与 部署规格 中的 replicas 属性保持一致。

密钥

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

支持两种不同的语法变体：短语法和长语法。在同一个 Compose 文件中，可以同时使用密钥的长语法和短语法。

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

在顶级 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。默认值为运行容器的 USER。
• 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 覆盖每个容器的默认标签方案。

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

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

shm_size

shm_size 配置服务容器允许的共享内存（Linux 上的 /dev/shm 分区）的大小。 它被指定为一个 字节值。

stdin_open

stdin_open 将服务的容器配置为使用分配的 stdin 运行。这与使用 -i 标志运行容器相同。有关更多信息，请参阅 保持 STDIN 打开。

支持的值为 true 或 false。

stop_grace_period

stop_grace_period 指定了当容器未能处理 SIGTERM（或通过 stop_signal 指定的任何停止信号）时，Compose 在发送 SIGKILL 之前必须等待多长时间才能停止容器。它被指定为一个 时间段。

    stop_grace_period: 1s
    stop_grace_period: 1m30s

容器退出前发送 SIGKILL 的默认值为 10 秒。

stop_signal

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

stop_signal: SIGUSR1

storage_opt

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

storage_opt:
  size: '1G'

sysctls

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

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

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

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

tmpfs

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

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

• : The path inside the container where the tmpfs will be mounted.
• : 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 覆盖容器的默认 ulimit。它可以指定为单个限制的整数，也可以指定为软/硬限制的映射。

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

用户

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

userns_mode

userns_mode 设置服务的用户命名空间。支持的值是平台特定的，并且可能取决于平台配置。

userns_mode: "host"

uts

uts 配置服务容器的 UTS 命名空间模式集。如果未指定，由运行时决定分配 UTS 命名空间（如果支持）。可用值包括：

• 'host': 结果是容器使用与主机相同的 UTS 命名空间。

    uts: "host"

卷

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

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

下面的示例展示了一个被 backend 服务使用的命名卷 (db-data)，以及为单个服务定义的绑定挂载。

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: 可以是托管容器的平台上的主机路径（绑定挂载），也可以是卷名称。
• CONTAINER_PATH: 容器中挂载卷的路径。
• ACCESS_MODE: 以逗号分隔的 , 选项列表：
  • rw: 读写权限。如果未指定，这是默认值。
  • ro: 只读权限。
  • z: SELinux 选项，表示绑定挂载的主机内容在多个容器之间共享。
  • Z: SELinux 选项，表示绑定挂载的主机内容是私有的，不与其他容器共享。

注意

在没有 SELinux 的平台上，SELinux 重新标记绑定挂载选项将被忽略。

注意

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

长语法

长格式语法允许配置短格式中无法表达的额外字段。

• type: 挂载类型。可以是 volume, bind, tmpfs, npipe, 或 cluster
• source: 挂载的源，绑定挂载的主机路径，或者在顶级 volumes 键中定义的卷名称。不适用于 tmpfs 挂载。
• target: 容器中挂载卷的路径。
• read_only: 将卷设置为只读的标志。
• bind: 用于配置额外的绑定选项:
  • propagation: 绑定使用的传播模式。
  • 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

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

您也可以通过使用 container: 前缀，从非 Compose 管理的容器挂载卷。

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

working_dir

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