2.1、在Docker Compose中定义服务

单个service是对应用程序中计算资源的一种抽象定义，其可以独立于其他组件进行扩展或替换。多个Services由一组容器提供支持，这些容器由平台根据复制要求和位置限制进行运行。由于服务是基于容器来运行的，因此它们是由一个 Docker 镜像以及一组运行时参数来定义的。服务内的所有容器都会使用这些参数进行完全相同的创建。

一个 Compose 文件必须将服务的顶层元素声明为一个映射结构，其中键为服务名称的字符串表示形式，而值则为服务定义。服务定义包含了应用于每个服务容器的配置信息。

每个服务还可能包含一个构建部分，该部分定义了如何为该服务创建 Docker 镜像。Compose 支持使用此服务定义来构建 Docker 镜像。如果不使用该部分，则该部分将被忽略，但 Compose 文件仍被视为有效。构建支持是 Compose 规范中的一个可选部分，详细内容请参阅 Compose 构建规范文档。

每个服务都会定义其容器运行时的约束条件和要求。部署部分会将这些约束条件进行分类，并让平台根据可用资源来调整部署策略，以最大程度地满足容器的需求。部署支持是 Compose 规范中的一个可选部分，详细内容在 Compose 部署规范文档中有描述。如果未实现部署部分，则该部分将被忽略，而 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

2.2、服务属性

1、annotations ：为容器定义注释。这些注释可以使用数组或者映射的形式。

# map形式
annotations:
  com.example.foo: bar
  
#数组形式
annotations:
  - com.example.foo=bar

2、attach：需要Docker Compose版本是2.20.0或者更高的版本

当“attach”属性被定义并设置为“false”时，Compose 将不会收集服务日志，除非明确要求其进行收集。默认的服务配置为“attach: true”。

3、build：“build”指定了从源代码创建容器镜像的构建配置，该配置是根据“Compose 构建规范”所定义的。

4、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 之间的整数值。

在 /dev/sda 设备上：使用权重 400
在其他所有设备上（如 /dev/sdb）：使用权重 300

weight：设置容器的 全局默认权重（100-1000），影响容器在所有块设备上的 I/O 优先级
weight_device：针对 特定设备 设置权重，只影响在该指定设备上的 I/O 优先级
当两者同时配置时，weight_device 的优先级高于 weight
对于特定设备，使用 weight_device 的设置
对于其他未在 weight_device 中指定的设备，使用 weight 的设置

5、cpu_count：定义了服务容器可使用的 CPU 数量。

6、cpu_percent：定义了可用 CPU 的可使用百分比。

7、cpu_shares：“cpu_shares”这一参数以整数值的形式定义了服务容器相对于其他容器的相对 CPU 权重。

8、cpu_period：“cpu_period”用于配置当平台基于 Linux 内核时的 CPU CFS（完全公平调度器）周期。

9、cpu_quota：“cpu_quota”用于在基于 Linux 内核的平台上配置 CPU 的 CFS（完全公平调度器）配额。

10、cpu_rt_runtime：“cpu_rt_runtime”用于配置支持实时调度器的平台上的 CPU 分配参数。它可以是使用微秒为单位的整数值，也可以是持续时间。

 cpu_rt_runtime: '400ms'
 cpu_rt_runtime: '95000'

数值以 {value}{unit} 的形式将时长表示为字符串。支持的单位包括 us（微秒）、ms（毫秒）、s（秒）、m（分钟）和 h（小时）。数值可以组合多个值，且无需分隔符。

  10ms
  40s
  1m30s
  1h5m30s20ms

11、cpu_rt_period：“cpu_rt_period”用于配置支持实时调度器的平台上的 CPU 分配参数。它可以是使用微秒为单位的整数值，也可以是持续时间。

 cpu_rt_period: '1400us'
 cpu_rt_period: '11000'

12、cpus：决定了要分配给服务容器的（可能为虚拟的）CPU 的数量。这个数量是小数形式。0.000 表示没有限制。设置完成后，所选的 cpus 必须与部署规范中的 cpus 属性保持一致。

13、cpuset：用于定义允许执行的明确的 CPU 范围。它可以是 0 到 3 的一个范围，也可以是 0 和 1 这样的一个列表。

14、cap_add：以字符串的形式指定了额外的容器功能。（Linux功能点参考：capabilities(7) - Linux manual page）

cap_add:
  - ALL

15、cap_drop：以字符串形式指定要删除的容器功能。

cap_drop:
  - NET_ADMIN
  - SYS_ADMIN

cgroup_parent: m-executor-abcd

command: bundle exec thin -p 3000

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

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

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: my-web-container

credential_spec:
  file: my-credential-spec.json

credential_spec:
  registry: my-credential-spec

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

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

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

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 的依赖服务在启动相关服务之前已处于“健康”状态。

23、deploy：“deploy”指定了服务的部署及生命周期的配置，该配置依据“组合部署规范”中所定义的内容进行设定。

24、develop：要求使用Docker Compose 2.22.0及以上版本。“develop”指定了用于使容器与源代码保持同步的开发配置，该配置在“开发”部分中已有明确说明。

25、device_cgroup_rules：为该容器定义了一组设备 cgroup 规则。其格式与 Linux 内核在“控制组设备白名单控制器”中所指定的格式完全相同。Device Whitelist Controller — The Linux Kernel documentation

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

语法格式：

<type> <major>:<minor> <permissions>

设备类型

设备号

权限

实际应用场景

#场景 1：安全加固 - 限制设备访问
services:
  webapp:
    device_cgroup_rules:
      # 允许标准设备
      - 'c 1:3 rwm'    # /dev/null
      - 'c 1:5 rwm'    # /dev/zero
      - 'c 1:7 rwm'    # /dev/full
      - 'c 1:8 rwm'    # /dev/random
      - 'c 1:9 rwm'    # /dev/urandom
      - 'c 5:0 rwm'    # /dev/tty
      - 'c 5:1 rwm'    # /dev/console
      
      # 明确拒绝磁盘访问（安全加固）
      - 'b *:* rm'     # 只允许读和创建设备，不允许写
      # 或完全拒绝
      # - 'b *:* -'    # 拒绝所有块设备访问
      
#场景 2：特定设备访问
services:
  database:
    # 只允许访问特定磁盘
    device_cgroup_rules:
      - 'b 8:0 rwm'    # /dev/sda
      - 'b 8:16 rwm'   # /dev/sdb
      - 'b 259:* rm'   # NVMe 设备（主设备号259）
      # 拒绝其他所有块设备
      - 'b *:* -'
      
#场景 3：GPU 访问控制
services:
  ai-training:
    # 允许访问 NVIDIA GPU
    device_cgroup_rules:
      - 'c 195:* rwm'    # NVIDIA 控制设备
      - 'c 243:* rwm'    # NVIDIA UVM 设备
      - 'c 508:* rwm'    # NVIDIA 计算设备
    devices:
      - /dev/nvidia0:/dev/nvidia0
      - /dev/nvidiactl:/dev/nvidiactl
      - /dev/nvidia-uvm:/dev/nvidia-uvm
      
#场景 4：USB 设备管理
services:
  usb-app:
    device_cgroup_rules:
      # 允许访问特定 USB 设备
      - 'c 180:* rm'     # USB 字符设备（读+创建设备）
      - 'b 8:32 rwm'     # 特定 USB 存储设备
      
      # 或允许所有 USB
      # - 'c 180:* rwm'  # 所有 USB 字符设备
      # - 'b 8:* rwm'    # 所有 USB 块设备
      

常见设备号参考

devices属性的区别

devices 属性将主机设备挂载到容器，一对一设备映射，自动授予指定权限，设备在容器中可见
device_cgroup_rules 属性 控制整个设备类别的访问规则，基于设备号规则，可以批量控制，更细粒度的权限控制

26、devices：定义了针对所创建容器的设备映射列表，其格式为“HOST_PATH:CONTAINER_PATH[:CGROUP_PERMISSIONS]”。

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

设备还可以利用 CDI 语法来让容器运行时自动选择设备：

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

27、dns：用于定义在容器网络接口配置中要设置的自定义 DNS 服务器。它可以是一个单一的值，也可以是一个列表。

dns: 8.8.8.8

dns:
  - 8.8.8.8
  - 9.9.9.9

28、dns_opt：dns_opt 列出要传递给容器的 DNS 解析器的自定义 DNS 选项（在 Linux 系统中，这些选项会保存在 /etc/resolv.conf 文件中）。

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

29、dns_search：用于定义自定义的 DNS 搜索域名，以便在容器网络接口配置中进行设置。它可以是一个单一的值，也可以是一个列表。

dns_search: example.com

dns_search:
  - dc1.example.com
  - dc2.example.com
  
#当使用短主机名时，自动尝试添加的域名后缀
# 当 ping web 时，实际尝试：
# 1. web.dc1.example.com
# 2. web.dc2.example.com  
# 3. web（最后尝试无后缀）

30、domainname：声明用于服务容器的自定义域名。该域名必须符合 RFC 1123 标准的合法主机名格式。

services:
  app:
    hostname: "webapp"
    domainname: "prod.company.com"
    # 结果：完整域名为 webapp.prod.company.com

设置容器的 NIS 域名（不是 DNS 搜索域！），这是系统的 domainname 命令，不是 DNS 搜索域

31、driver_opts：需要Docker Compose 2.27.1及以上版本。用于指定一系列以键值对形式呈现的选项，这些选项将传递给网络驱动程序。这些选项是与网络驱动程序相关的。查阅Networking | Docker Docs 获取更详细信息

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

32、entrypoint：定义了服务容器的默认入口点。这会覆盖来自服务的 Dockerfile 中的“ENTRYPOINT”指令。如果entrypoint不为空，则 Compose 会忽略镜像中的任何默认命令，例如 Dockerfile 中的 CMD 指令。

就短格式而言，该值可以表示为一个字符串：

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，则会使用镜像中的默认入口点。

如果值为 []（空列表）或 ''（空字符串），则会忽略由镜像所声明的默认入口点，换句话说，该入口点会被设置为空。

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

#单个文件
env_file: .env

#列表形式
env_file:
  - ./a.env
  - ./b.env

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

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

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

#Map语法
environment:
  RACK_ENV: development
  SHOW: "true"
  USER_INPUT:
      
#Array语法
environment:
  - RACK_ENV=development
  - SHOW=true
  - USER_INPUT

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

extends:
  file: common.yml
  service: webapp

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服务的实际配置如下所示，注意，已挂载的路径现在已指向新的卷名，并且已应用了“只读”标志。

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 服务从 common 服务获取用户密钥，而 common 服务则从 base 服务获取该密钥。

image: busybox
user: root

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

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

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

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:
  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

39、gpus：需要Docker Compose 2.30.0及以上版本。指定了将用于容器运行的 GPU 设备。这相当于一个带有隐式 GPU 特性的设备请求。

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

此外，还可以将“gpus”设置为字符串 all ，以将所有可用的 GPU 设备分配给容器。

services:
  model:
    gpus: all

40、group_add：用于指定容器内的用户需要具备成员资格的其他组（可通过组名或组编号指定）。

这种情况的一个实际应用场景是：当多个容器（以不同用户身份运行）需要共同读取或写入同一个共享卷中的文件时。该文件可以由所有容器共用的一个组来拥有，并在“group_add”中进行指定。

services:
  myservice:
    image: alpine
    group_add:
      - mail

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

41、healthcheck：“healthcheck”属性用于声明一个检查项，用于确定服务容器是否“健康”。其工作方式与服务的 Docker 镜像中设置的“HEALTHCHECK”Dockerfile 指令相同，并且具有相同的默认值。Compose 文件可以覆盖 Dockerfile 中设置的值。

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

interval, timeout, start_period, and start_interval 均被设定为持续时间单位。此功能自 Docker Compose 2.20.2 版本起引入。

test 定义了用于检查容器健康状况的命令 Compose。该命令可以是字符串形式，也可以是列表形式。如果它是列表形式，则第一个元素必须是 NONE、CMD 或 CMD-SHELL。如果它是字符串形式，则相当于先指定 CMD-SHELL，然后再添加该字符串。

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

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

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

“NONE”选项会禁用健康检查功能，其主要用途是通过服务的 Docker 镜像来禁用 Dockerfile 指令集Healthcheck。或者也可以通过设置“disable: true”来禁用由镜像设置的健康检查功能。

healthcheck:
  disable: true

42、hostname：声明服务容器使用的自定义主机名。该主机名必须符合 RFC 1123 标准的规定。

43、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 将会根据拉取策略尝试去获取它。如果您同时使用了“Compose 构建规范”，则还有其他方法可以控制从源代码构建镜像与先进行拉取操作之间的优先级关系，不过拉取镜像始终是默认操作方式。

只要在配置文件中声明了构建部分，就可以省略image属性，如果您未使用 Compose 构建规范，那么如果配置文件中缺少镜像，Compose 将无法正常工作。

44、init：init 会在容器内部运行一个初始化进程（进程 ID 为 1），该进程负责转发信号并回收进程。将此选项设置为“true”可为服务启用此功能。

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

所使用的初始化二进制文件是针对特定平台的。

54、ipc：配置由服务容器设定的进程间通信隔离模式。

shareable：为容器分配其自身的私有 IPC 命名空间，并且可以与其他容器共享该命名空间。

service:{name} 使容器加入另一个容器的（可共享的）IPC 命名空间。

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

55、isolation：指定了容器的隔离技术。支持的值因平台而异。

56、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 会创建带有标准标签的容器：这些标签是 Docker Compose 自动添加的，不需要手动设置

com.docker.compose.project：将由 Compose 创建的所有资源设置为用户项目名称的形式。

com.docker.compose.service：将服务容器设置为与“Compose”文件中定义的服务名称相匹配的项。

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

57、label_file：需要Docker Compose 2.32.2及以上版本。该属性允许你从外部文件或一系列文件中为服务加载标签。这为管理多个标签提供了一种便捷的方式，避免了在“Compose”文件中造成混乱。该文件采用 key-value 格式，与环境文件（env_file）类似。你可以将多个文件以列表形式指定。使用多个文件时，将按照它们在列表中出现的顺序进行处理。如果同一标签在多个文件中均有定义，则列表中最后一个文件中的值将覆盖之前文件中的值。

services:
  one:
    label_file: ./app.labels

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

如果一个标签在 label_file 指定的文件 和 labels 属性中都定义了，则以 labels 属性中的值为准。

58、links：用于定义指向另一个服务中容器的网络链接，可以同时指定服务名称和链接别名（SERVICE:ALIAS），或者仅指定服务名称。

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

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

链接并非服务进行通信所必需的条件。若未设置特定的网络配置，任何服务都能通过其名称在 default 网络中访问到任何其他服务。如果服务指定了其所连接的网络，链接不会覆盖网络配置。未连接到共享网络的服务无法相互进行通信。Compose 不会提醒您有关配置不匹配的问题。

链接同样能够以与“depends_on”相同的方式隐性地表示服务之间的依赖关系，因此它们能够决定服务启动的顺序。

58、logging：定义服务的日志配置

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

 services:
  short_syntax:
    image: app
    models:
      - my_model
  long_syntax:
    image: app
    models:
      my_model:
        endpoint_var: MODEL_URL
        model_var: MODEL

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

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

services:
  some-service:
    image: foo

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

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

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: {}

services:
  backend:
    image: alpine
    command: ip link show
    networks:
      back-tier:
        interface_name: eth0

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"

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

services:
  app:
    networks:
      app_net:
        driver_opts:
          foo: "bar"
          baz: 1

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:

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:

pids_limit: 10

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

ports:
  - "3000"
  - "3000-3005"
  - "8000:8000"
  - "9090-9091:8080-8081"
  - "49100:22"
  - "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

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

欲了解更多信息，请参阅“使用生命周期钩子(Use lifecycle hooks.)”部分。

74、pre_stop：需要Docker Compose 2.30.0及以上版本。该属性定义了一组在容器停止之前运行的生命周期钩子。如果容器是自行停止或突然被终止的，那么这些钩子将不会运行。配置与 post_start相同。

75、privileged：配置服务容器以使用提升权限的方式运行。支持情况和实际影响因平台而异。

76、profiles：定义了服务在启用时所依据的命名配置文件列表。如果未进行指定，则服务将始终启动；但如果进行了指定，则只有在激活了相应的配置文件时，服务才会启动。如果存在的话，这些 profiles 将遵循 [a-zA-Z0-9][a-zA-Z0-9_.-]+ 这样的正则表达式格式。

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

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

version: '3.9'
services:
  # 基础服务 - 所有环境都需要
  postgres:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

  # 生产环境应用
  app:
    image: myapp:prod
    environment:
      - APP_ENV=production
      - DB_HOST=postgres
    depends_on:
      - postgres
      - redis
    profiles: ["prod"]
    ports:
      - "8080:8080"

  # 开发环境应用（带热重载）
  app-dev:
    image: myapp:dev
    environment:
      - APP_ENV=development
      - DB_HOST=postgres
    profiles: ["dev"]
    volumes:
      - ./app:/app
      - /app/node_modules
    ports:
      - "3000:3000"
    command: npm run dev

  # 测试环境额外服务
  selenium:
    image: selenium/standalone-chrome
    profiles: ["test", "integration"]
    shm_size: 2gb

  # 监控工具
  prometheus:
    image: prom/prometheus
    profiles: ["monitoring"]
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

  grafana:
    image: grafana/grafana
    profiles: ["monitoring"]
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    depends_on:
      - prometheus

volumes:
  postgres_data:

docker compose up 启动容器服务不带profiles标记的

docker compose --profile dev up 启动开发环境

docker compose --profile dev --profile monitoring up

docker compose --profile "*" up 启动所有服务，包括带prifiles的。

docker compose --profile dev config 查看不同profile的配置

77、provider：需要Docker Compose 2.36.0 及以上版本。该属性用于定义那些 Compose 无法直接管理的服务。Compose 将服务的生命周期交由专门的或第三方组件来负责管理。

  database:
    provider:
      type: awesomecloud
      options:
        type: mysql
        foo: bar
  app:
    image: myapp
    depends_on:
       - database

services:
  test:
    image: nginx
    pull_policy: every_12h

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

81、runtime：指定用于服务容器的运行时环境。例如，runtime 可以是 OCI 运行时规范的一种实现名称（an implementation of OCI Runtime Spec,），比如“runc”。

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

默认使用的运行环境是“runc”。若要使用其他运行环境，请参阅“替代运行环境（ Alternative runtimes）”部分。

82、scale：指定了此服务默认要部署的容器数量。若同时设置了这两个值，则“scale”必须与“Deploy Specification”中的“replicas”属性保持一致。

83、secrets：该属性允许按服务级别访问由“secrets”顶级元素定义的敏感数据。服务可以被授予访问多个 secret 的权限。

支持两种不同的语法形式：短格式语法和长格式语法。在同一个 Compose 文件中，可以同时使用长格式语法和短格式语法来表示密钥信息。

如果密钥不在平台上存在，或者未在“Compose”文件的顶层 secrets 部分中进行定义，那么该操作将会报告错误。

在顶级 secrets 定义的密钥禁止按时授予对该密钥的任何服务访问权限。此类授权必须在服务规范中明确列出，作为密钥服务元素的一部分。

短格式语法：这种段格式的语法变体仅指定了密钥名称。这使得容器能够访问该密钥，并将其以只读方式挂载到容器内的 /run/secrets/ 目录中。源名称和目标挂载点都设置为密钥名称。

以下示例使用了简短的语法来授予 frontend 服务对 server-certificate 密钥的访问权限。服务器证书的值被设置为文件“./server.cert”中的内容。

services:
  frontend:
    image: example/webapp
    secrets:
      - server-certificate
secrets:
  server-certificate:
    file: ./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:
  - label=user:USER
  - label=role:ROLE

    stop_grace_period: 1s
    stop_grace_period: 1m30s

stop_signal: SIGUSR1

storage_opt:
  size: '1G'

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

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

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

92：tty：将服务的容器配置为以终端仿真器（TTY）的形式运行。这与使用 -t 或 --tty 标志运行容器的效果相同。如需了解更多信息，请参阅“分配伪终端”。

支持的值为 true 或者 false。

93、ulimits ：覆盖容器的默认限制设置。其设定方式为：对于单个限制，可指定为一个整数；对于软限制或硬限制，则需以映射形式进行指定。

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

94、use_api_socket ：当“use_api_socket”被设置时，容器能够通过 API 通道与底层容器引擎进行交互。凭证会被挂载到容器内部，因此该容器仅作为针对容器引擎相关命令的纯粹执行代理。通常，由容器运行的命令可以将内容推送到您的注册表中，并从您的注册表中拉取内容。

95、user：覆盖用于运行容器进程的用户。默认设置由镜像决定，例如 Dockerfile 中的 USER 指令。如果没有设置，默认则是以 root 身份运行。

96、userns_mode ：用于设置服务的用户命名空间。其支持的值因平台而异，并可能取决于平台的配置情况。

userns_mode: "host"

uts: "host"

98、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_from:
  - service_name
  - service_name:ro
  - container:container_name
  - container:container_name:rw