服务顶级元素

服务是应用程序中计算资源的抽象定义，可以独立于其他组件进行扩展或替换。服务由一组容器支持，平台根据复制要求和放置约束运行这些容器。由于服务由容器支持，它们由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

当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: 作为一个整数值，表示每秒允许的操作次数。

weight

修改分配给一个服务的带宽相对于其他服务的比例。 接受一个介于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 配置CPU CFS（完全公平调度器）周期，当平台基于Linux内核时。

cpu_quota

cpu_quota 配置CPU CFS（完全公平调度器）配额，当平台基于Linux内核时。

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

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

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

command: bundle exec thin -p 3000

该值也可以是一个列表，类似于 Dockerfile:

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

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

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

配置

配置允许服务在不重建Docker镜像的情况下调整其行为。 服务只有在通过configs属性明确授予权限时才能访问配置。支持两种不同的语法变体。

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

配置有两种语法定义：短语法和长语法。

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

简短语法

简写语法变体仅指定配置名称。这授予容器对配置的访问权限，并将其作为文件挂载到服务容器的文件系统中。容器内的挂载点位置在Linux容器中默认为/，在Windows容器中默认为C:\。

以下示例使用简写语法授予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: 要在服务的任务容器中挂载的文件的路径和名称。如果未指定，默认为 /。
• 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:// 或 registry:// 的格式。

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: An equivalent of the short syntax described above
  • service_healthy: Specifies that a dependency is expected to be "healthy" (as indicated by healthcheck) before starting a dependent service.
  • service_completed_successfully: Specifies that a dependency is expected to run to successful completion before starting a dependent service.

• 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

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

develop

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

device_cgroup_rules

device_cgroup_rules 定义了此容器的设备控制组规则列表。 格式与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

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

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

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

format

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

raw 格式允许你使用一个包含 key=value 项的 env_file，但 Compose 不会尝试解析这些值以进行插值。 这让你可以原样传递值，包括引号和 $ 符号。

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

环境文件格式

.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

expose 定义了 Compose 从容器暴露的（传入）端口或端口范围。这些端口必须对链接的服务可访问，并且不应发布到主机。只能指定内部容器端口。

语法是 /[] 或 /[] 用于端口范围。 当未明确设置时，使用 tcp 协议。

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

注意

如果镜像的Dockerfile已经暴露了端口，即使Compose文件中没有设置expose，这些端口对网络上的其他容器也是可见的。

extends

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文件的位置。
  • 绝对路径。

由service表示的服务必须存在于所识别的引用Compose文件中。 如果出现以下情况，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

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

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

extra_hosts

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

简短语法

简写语法在列表中使用纯字符串。值必须为额外主机设置主机名和IP地址，格式为HOSTNAME=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 属性声明了一个检查，用于确定服务容器是否“健康”。它的工作方式与 Dockerfile 中的 HEALTHCHECK 指令相同，并且具有相同的默认值，这些值由服务的 Docker 镜像设置。您的 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

hostname 声明了用于服务容器的自定义主机名。它必须是一个有效的 RFC 1123 主机名。

image

image 指定了启动容器的镜像。image 必须遵循开放容器规范 可寻址镜像格式, 如 [/][/][:|@]。

    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

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

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 文件中指定带有此前缀的标签会导致运行时错误。

label_file

label_file 属性允许您从外部文件或文件列表中加载服务的标签。这提供了一种方便的方式来管理多个标签，而不会使 Compose 文件变得杂乱。

该文件使用键值格式，类似于env_file。您可以将多个文件指定为列表。当使用多个文件时，它们按照列表中出现的顺序进行处理。如果在多个文件中定义了相同的标签，列表中最后一个文件的值将覆盖较早的值。

services:
  one:
    label_file: ./app.labels 
  
  two:
    label_file:               
      - ./app.labels
      - ./additional.labels

如果在label_file和labels属性中都定义了标签，则labels中的值优先。

链接

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 设置为正整数，则容器无法访问交换空间。
• 如果未设置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 声明了服务在网络上使用的替代主机名。同一网络上的其他容器可以使用服务名称或别名来连接到服务的某个容器。

由于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_address

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

priority

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 调整容器的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

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

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

profiles

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

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运行参考页面的 重启策略 (--restart) 部分找到更详细的信息。

runtime

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

例如，runtime 可以是 OCI Runtime Spec 的一个实现的名称，例如 "runc"。

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

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

scale

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

secrets

secrets 属性允许访问由顶级元素 secrets 定义的敏感数据，这些数据是基于每个服务的。服务可以被授予访问多个秘密的权限。

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

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

在顶层secrets中定义一个秘密并不意味着授予任何服务访问权限。 此类授权必须在服务规范中明确指定，如 secrets服务元素。

简短语法

简写语法变体仅指定密钥名称。这将授予容器对密钥的访问权限，并将其作为只读挂载到容器内的/run/secrets/。源名称和目标挂载点都设置为密钥名称。

以下示例使用简写语法授予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 配置服务的容器以分配的标准输入运行。这与使用 -i 标志运行容器相同。更多信息，请参见 保持 STDIN 打开。

支持的值为 true 或 false。

stop_grace_period

stop_grace_period 指定了当尝试停止一个容器时，如果它没有处理 SIGTERM（或通过 stop_signal 指定的停止信号），Compose 必须等待多长时间，然后才能发送 SIGKILL。它被指定为一个 持续时间。

    stop_grace_period: 1s
    stop_grace_period: 1m30s

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

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

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

tmpfs

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

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

• path: 容器内部将挂载tmpfs的路径。
• options: tmpfs挂载的选项列表，以逗号分隔。

可用选项：

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

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

tty

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

支持的值为 true 或 false。

ulimits

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

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 属性定义了服务容器可以访问的挂载主机路径或命名卷。您可以使用 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顶级元素的更多信息，请参阅 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。