Services 顶层元素

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

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

每个服务还可以包含一个 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 可以使用数组或映射（map）。

annotations:
  com.example.foo: bar

annotations:
  - com.example.foo=bar

attach

当定义并将 attach 设置为 false 时，Compose 不会收集服务日志，除非您显式请求。

默认的服务配置是 attach: true。

build

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

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

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

当平台基于 Linux 内核时，cpu_period 配置 CPU CFS (Completely Fair Scheduler) 周期。

cpu_quota

当平台基于 Linux 内核时，cpu_quota 配置 CPU CFS (Completely Fair Scheduler) 配额。

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 必须与Deploy Specification中的 cpus 属性一致。

cpuset

cpuset 定义了允许执行的明确 CPU。可以是范围 0-3 或列表 0,1。

cap_add

cap_add 指定了附加的容器capability，作为字符串。

cap_add:
  - ALL

cap_drop

cap_drop 指定了要删除的容器capability，作为字符串。

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

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

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

注意

与 Dockerfile 中的 CMD 指令不同，command 字段不会自动在镜像中定义的SHELL指令的上下文中运行。如果您的 command 依赖于 shell 特有的功能（例如环境变量扩展），您需要显式地在 shell 中运行它。例如

command: /bin/sh -c 'echo "hello $$HOSTNAME"'

值也可以是列表，类似于Dockerfile使用的exec-form 语法。

configs

configs 允许服务调整其行为，而无需重新构建 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: 在服务任务容器中挂载的文件路径和名称。如果未指定，默认为 /。
• uid 和 gid: 在服务任务容器中拥有挂载配置文件的数字用户 ID (uid) 或组 ID (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 容器，您可以为 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

使用 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 会等待依赖服务处于“ready”状态，然后才启动依赖的服务。

长语法

长语法形式允许配置短语法中无法表达的附加字段。

• 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 的依赖项的健康检查通过。在以下示例中，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 的依赖服务在启动依赖它的服务之前处于“healthy”（健康）状态。

deploy

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

develop

develop 用于指定开发配置，以便使容器与源代码保持同步，定义 在开发部分 中。

device_cgroup_rules

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

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

devices

devices 定义了创建的容器的设备映射列表，格式为 HOST_PATH:CONTAINER_PATH[:CGROUP_PERMISSIONS]。

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

devices 还可以依赖 CDI 语法，让容器运行时选择设备

devices:
  - "vendor1.com/device=gpu"

dns

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

dns: 8.8.8.8

dns:
  - 8.8.8.8
  - 9.9.9.9

dns_opt

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

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 会发出警告。

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

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 format 中概述的 Compose 规则进行解析。

raw 格式允许您使用包含键=值项的 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 属性定义了在容器中设置的环境变量。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 从容器中暴露的（传入）端口或端口范围。这些端口必须可被链接的服务访问，并且不应该发布到主机。只能指定内部容器端口。

端口范围的语法是 <portnum>/[<proto>] 或 <startport-endport>/[<proto>]。如果未明确设置，则使用 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、networks、configs、secrets、links、volumes_from 或 depends_on 等属性明确定义。或者，依赖可以在 ipc、pid 或 network_mode 等命名空间声明中使用 service:{name} 语法引用另一个服务。

Compose 不会自动将这些引用的资源导入到扩展模型中。您有责任确保所有必需的资源在依赖 extends 的模型中明确声明。

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

查找引用的服务

file 的值可以是

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

由 service 表示的服务必须存在于指定的引用 Compose 文件中。如果发生以下情况，Compose 会返回错误：

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

合并服务定义

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

• 映射 (Mappings)：主要服务定义映射中的键会覆盖引用服务定义映射中的键。未被覆盖的键会原样包含。
• 序列 (Sequences)：项目会合并到一个新序列中。元素的顺序会保留，引用的项目在前，主要项目在后。
• 标量 (Scalars)：主要服务定义中的键优先于引用服务定义中的键。

映射

以下键应被视为映射：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）。

短语法

短语法在列表中使用纯字符串。值必须以 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

gpus

gpus 指定要为容器分配的 GPU 设备。这相当于一个隐含了 gpu 功能的 设备请求。

services:
  model:
    gpus: 
      - driver: 3dfx
        count: 2

gpus 也可以设置为字符串 all，以便将所有可用的 GPU 设备分配给容器。

services:
  model:
    gpus: all

group_add

group_add 指定容器内用户必须是其成员的附加组，可以通过名称或数字指定。

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

services:
  myservice:
    image: alpine
    group_add:
      - mail

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

healthcheck

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

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

image

image 指定用于启动容器的镜像。image 必须遵循 Open Container Specification 可寻址镜像格式，格式为 [<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 部分，image 可以从 Compose 文件中省略。如果您未使用 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

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

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

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

链接服务中的容器可以通过与别名相同的主机名访问，如果未指定别名，则使用服务名称。

无需链接即可实现服务间的通信。如果未设置特定的网络配置，任何服务都可以通过该服务名称在 default 网络上访问任何其他服务。如果服务指定了它们连接的网络，links 不会覆盖网络配置。未连接到共享网络的的服务将无法相互通信。Compose 不会警告您配置不匹配。

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

logging

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 顶级元素下的条目。networks 属性有助于管理容器的网络方面，控制服务在 Docker 环境中的分段和交互方式。它用于指定该服务的容器应连接到哪些网络。这对于定义容器如何相互通信以及与外部通信非常重要。

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

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

Implicit default network

如果 Compose 文件中 networks 为空或缺失，Compose 会隐式地认为该服务连接到 default 网络。

services:
  some-service:
    image: foo

这个例子实际上等同于

services:
  some-service:
    image: foo  
    networks:
      default: {}  

如果您希望服务不连接任何网络，您必须设置 network_mode: none。

别名

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 地址。

顶级 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 地址。

gw_priority

gw_priority 最高的网络被选为服务容器的默认网关。如果未指定，默认值为 0。

在以下示例中，app_net_2 将被选为默认网关。

services:
  app:
    image: busybox
    command: top
    networks:
      app_net_1:
      app_net_2:
        gw_priority: 1
      app_net_3:
networks:
  app_net_1:
  app_net_2:
  app_net_3:

priority

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

如果容器运行时在服务级别接受 mac_address 属性，则它将应用于具有最高 priority 的网络。在其他情况下，请使用属性 networks.mac_address。

priority 不影响选择哪个网络作为默认网关。请改为使用 gw_priority 属性。

priority 不控制将网络连接添加到容器的顺序，它不能用于确定容器中的设备名称（例如 eth0 等）。

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 必须与 Deploy Specification 中的 pids 属性保持一致。

platform

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

os、arch 和 variant 的值必须符合 OCI Image Spec 所使用的约定。

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

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

ports

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

注意

端口映射不能与 network_mode: host 一起使用。这样做会导致运行时错误，因为 network_mode: host 已经将容器端口直接暴露给主机网络，因此不需要端口映射。

短语法

短语法是一个以冒号分隔的字符串，用于设置主机 IP、主机端口和容器端口，形式如下

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

• HOST 是 [IP:](port | range)（可选）。如果未设置，则绑定到所有网络接口 (0.0.0.0)。
• CONTAINER 是 port | range。
• PROTOCOL 将端口限制为指定的协议，可以是 tcp 或 udp（可选）。默认为 tcp。

端口可以是单个值或范围。HOST 和 CONTAINER 必须使用等效的范围。

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

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

IPv6 地址可以括在方括号中。

示例

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"  
  - "::1:6000:6000"   
  - "[::1]:6001:6001" 
  - "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：指定在 Swarm 设置中如何发布端口。如果设置为 host，则在 Swarm 的每个节点上发布端口。如果设置为 ingress，则允许在 Swarm 节点之间进行负载均衡。默认为 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 总是从 registry 中拉取镜像。
• never：Compose 不从 registry 中拉取镜像，而是依赖平台缓存的镜像。如果没有缓存镜像，则报告失败。
• missing：Compose 仅当镜像在平台缓存中不可用时才拉取。如果您不使用 Compose Build Specification，这是默认选项。if_not_present 被视为此值的别名，以便向后兼容。
• build：Compose 构建镜像。如果镜像已存在，Compose 会重新构建镜像。
• daily：如果上次拉取时间超过 24 小时，Compose 会检查 registry 以获取镜像更新。
• weekly：如果上次拉取时间超过 7 天，Compose 会检查 registry 以获取镜像更新。
• every_<duration>：如果上次拉取时间早于 <duration>，Compose 会检查 registry 以获取镜像更新。持续时间可以使用周 (w)、天 (d)、小时 (h)、分钟 (m)、秒 (s) 或它们的组合来表示。

services:
  test:
    image: nginx
    pull_policy: every_12h

read_only

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

restart

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

• no：默认的重启策略。在任何情况下都不会重启容器。
• always：策略总是重启容器，直到被移除。
• on-failure[:max-retries]：如果退出代码指示错误，策略会重启容器。可选地，限制 Docker daemon 尝试重启的次数。
• unless-stopped：策略会重启容器，无论退出代码如何，但在服务停止或移除时停止重启。

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

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

runtime

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

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

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

默认为 runc。要使用不同的运行时，请参阅 Alternative runtimes。

scale

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

secrets

secrets 属性授予按服务访问由顶级 secrets 元素定义的敏感数据的权限。服务可以获得对多个 secret 的访问权限。

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

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

在顶级 secrets 中定义 secret 不应意味着授予任何服务访问它的权限。这种授予必须在服务规范中明确说明，作为 secrets 服务元素。

短语法

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

以下示例使用短语法授予 frontend 服务访问 server-certificate secret 的权限。server-certificate 的值设置为文件 ./server.cert 的内容。

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

长语法

长语法提供了在服务容器中创建 secret 的更多细粒度控制。

• source：secret 在平台上存在的名称。
• target：在服务任务容器中要挂载到 /run/secrets/ 的文件名，如果需要备用位置，则为文件的绝对路径。如果未指定，默认为 source。
• uid 和 gid：服务任务容器中 /run/secrets/ 目录下文件的数字 uid 或 gid 所有者。默认值为 USER。
• mode：服务任务容器中要挂载到 /run/secrets/ 的文件的权限，使用八进制表示法。默认值是世界可读权限（模式 0444）。如果设置了可写位，则必须忽略。可执行位可以设置。

请注意，当 secret 的来源是 file 时，Docker Compose 中未实现对 uid、gid 和 mode 属性的支持。这是因为底层使用的 bind-mounts 不允许 uid 重新映射。

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

services:
  frontend:
    image: example/webapp
    secrets:
      - source: server-certificate
        target: server.cert
        uid: "103"
        gid: "103"
        mode: "0o440"
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 标志运行容器相同。有关更多信息，请参阅 Keep stdin open。

支持的值为 true 或 false。

stop_grace_period

stop_grace_period 指定 Compose 在尝试停止容器时，如果容器不处理 SIGTERM（或使用 stop_signal 指定的任何停止信号），在发送 SIGKILL 之前需要等待多长时间。它被指定为持续时间。

    stop_grace_period: 1s
    stop_grace_period: 1m30s

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

stop_signal

stop_signal 定义 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 标志运行容器相同。有关更多信息，请参阅 分配一个伪 TTY。

支持的值为 true 或 false。

ulimits

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

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

user

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），以及为单个服务定义的 bind mount。

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

注意

在没有 SELinux 的平台上，SELinux re-labeling bind mount 选项会被忽略。

注意

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

长语法

长格式语法允许您配置短格式无法表达的附加字段。

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

提示

正在处理大型仓库或 monorepos，或者正在使用的虚拟文件系统无法再随代码库扩展？Compose 现在利用 Synchronized file shares，并自动为 bind mounts 创建文件共享。确保您已使用付费订阅登录 Docker，并在 Docker Desktop 的设置中启用了 Access experimental features 和 Manage Synchronized file shares with 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。