Compose 部署规范

Deploy 是 Compose 规范的可选部分。它提供了一组部署规范，用于管理容器在不同环境中的行为。

属性

`endpoint_mode`

endpoint_mode 指定了外部客户端连接到服务时的服务发现方法。Compose 部署规范定义了两个规范值：

endpoint_mode: vip：为服务分配一个虚拟 IP (VIP)，作为客户端在网络上访问服务的前端。平台在客户端和运行服务的节点之间路由请求，客户端无需了解服务中有多少节点参与以及它们的 IP 地址或端口。
endpoint_mode: dnsrr：平台为服务设置 DNS 条目，使服务名称的 DNS 查询返回 IP 地址列表（DNS 循环），客户端直接连接到其中一个地址。

services:
  frontend:
    image: example/webapp
    ports:
      - "8080:80"
    deploy:
      mode: replicated
      replicas: 2
      endpoint_mode: vip

`labels`

labels 指定服务的元数据。这些标签仅设置在服务上，而不设置在服务的任何容器上。这假定平台具有一些可以匹配 Compose 应用程序模型的原生“服务”概念。

services:
  frontend:
    image: example/webapp
    deploy:
      labels:
        com.example.description: "This label will appear on the web service"

`mode`

mode 定义了用于运行服务或作业的复制模型。选项包括：

global：确保每个物理节点上持续运行且只有一个任务，直到停止。
replicated：在节点上持续运行指定数量的任务，直到停止（默认）。
replicated-job：执行定义数量的任务，直到完成状态（以代码 0 退出）。
- 总任务数由 replicas 决定。
- 并发度可以使用 max-concurrent 选项进行限制（仅限 CLI）。
global-job：在每个物理节点上执行一个任务，直到完成状态（以代码 0 退出）。
- 新节点添加时自动运行。

services:
  frontend:
    image: example/webapp
    deploy:
      mode: global

  batch-job:
    image: example/processor
    deploy:
      mode: replicated-job
      replicas: 5

  maintenance:
    image: example/updater
    deploy:
      mode: global-job

注意
作业模式（replicated-job 和 global-job）专为完成并以代码 0 退出的任务设计。
已完成的任务会保留，直到明确删除。
控制并发的选项（如 max-concurrent）仅通过 CLI 支持，在 Compose 中不可用。

有关作业选项和行为的更多详细信息，请参阅 Docker CLI 文档

`placement`

placement 指定了平台选择物理节点来运行服务容器的约束和偏好。

`constraints`

constraints 定义了平台节点必须满足的运行服务容器的必需属性。有关更多示例，请参阅 CLI 参考文档。

deploy:
  placement:
    constraints:
      - disktype=ssd

`preferences`

preferences 定义了一种策略（目前只支持 spread 策略），用于将任务均匀地分布在数据中心节点标签的值上。有关更多示例，请参阅 CLI 参考文档

deploy:
  placement:
    preferences:
      - spread: node.labels.zone

`replicas`

如果服务是 replicated（默认），replicas 指定在任何给定时间应运行的容器数量。

services:
  frontend:
    image: example/webapp
    deploy:
      mode: replicated
      replicas: 6

`resources`

resources 配置容器在平台上运行的物理资源限制。这些限制可以配置为：

limits：平台必须阻止容器分配超过限制的资源。
reservations：平台必须保证容器至少可以分配配置的数量。

services:
  frontend:
    image: example/webapp
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 50M
          pids: 1
        reservations:
          cpus: '0.25'
          memory: 20M

`cpus`

cpus 配置容器可以使用多少可用 CPU 资源（以核心数表示）的限制或预留。

`memory`

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

`pids`

pids 调整容器的 PIDs 限制，设置为整数。

`devices`

devices 配置容器可以使用的设备预留。它包含一个预留列表，每个预留都设置为一个对象，包含以下参数：capabilities、driver、count、device_ids 和 options。

设备使用功能列表进行预留，使 capabilities 成为唯一必填字段。设备必须满足所有请求的功能才能成功预留。

`capabilities`

capabilities 设置为字符串列表，表示通用和驱动程序特定功能。目前识别的通用功能如下：

gpu：图形加速器
tpu：AI 加速器

为避免名称冲突，驱动程序特定功能必须以驱动程序名称作为前缀。例如，预留一个支持 NVIDIA CUDA 的加速器可能如下所示：

deploy:
  resources:
    reservations:
      devices:
        - capabilities: ["nvidia-compute"]

`驱动程序`

可以使用 driver 字段请求预留设备的不同驱动程序。该值指定为字符串。

deploy:
  resources:
    reservations:
      devices:
        - capabilities: ["nvidia-compute"]
          driver: nvidia

`count`

如果 count 设置为 all 或未指定，Compose 将预留所有满足请求功能的设备。否则，Compose 将预留至少指定数量的设备。该值指定为整数。

deploy:
  resources:
    reservations:
      devices:
        - capabilities: ["tpu"]
          count: 2

count 和 device_ids 字段是互斥的。如果两者都指定，Compose 将返回错误。

`device_ids`

如果设置了 device_ids，Compose 将预留具有指定 ID 的设备，前提是它们满足请求的功能。该值指定为字符串列表。

deploy:
  resources:
    reservations:
      devices:
        - capabilities: ["gpu"]
          device_ids: ["GPU-f123d1c9-26bb-df9b-1c23-4a731f61d8c7"]

count 和 device_ids 字段是互斥的。如果两者都指定，Compose 将返回错误。

`options`

驱动程序特定选项可以通过 options 设置为键值对。

deploy:
  resources:
    reservations:
      devices:
        - capabilities: ["gpu"]
          driver: gpuvendor
          options:
            virtualization: false

`restart_policy`

restart_policy 配置容器退出时是否以及如何重启。如果未设置 restart_policy，Compose 会考虑服务配置中设置的 restart 字段。

condition。当设置为：
- none，容器不会自动重启，无论退出状态如何。
- on-failure，如果容器因错误退出（非零退出代码），则会重启。
- any（默认），容器无论退出状态如何都会重启。
delay：每次重启尝试之间等待的时间，指定为持续时间。默认值为 0，表示可以立即进行重启尝试。
max_attempts：放弃前允许的最大失败重启尝试次数。（默认：无限重试。）只有当容器在 window 定义的时间内未能成功重启时，失败尝试才计入 max_attempts。例如，如果 max_attempts 设置为 2 并且容器在第一次尝试中未能在窗口内重启，Compose 将继续重试，直到发生两次此类失败尝试，即使这意味着尝试不止两次。
window：重启后等待的时间，以确定是否成功，指定为持续时间（默认：重启后立即评估结果）。

deploy:
  restart_policy:
    condition: on-failure
    delay: 5s
    max_attempts: 3
    window: 120s

`rollback_config`

rollback_config 配置服务在更新失败时如何回滚。

parallelism：一次回滚的容器数量。如果设置为 0，则所有容器同时回滚。
delay：每个容器组回滚之间等待的时间（默认 0 秒）。
failure_action：如果回滚失败，应采取的措施。可以是 continue 或 pause（默认 pause）。
monitor：每个任务更新后监控失败的持续时间 (ns|us|ms|s|m|h)（默认 0 秒）。
max_failure_ratio：回滚期间可容忍的失败率（默认 0）。
order：回滚期间的操作顺序。可以是 stop-first（旧任务在启动新任务之前停止）或 start-first（新任务首先启动，正在运行的任务短暂重叠）（默认 stop-first）。

`update_config`

update_config 配置服务应如何更新。对于配置滚动更新很有用。

parallelism：一次更新的容器数量。
delay：更新一组容器之间等待的时间。
failure_action：如果更新失败，应采取的措施。可以是 continue、rollback 或 pause（默认：pause）。
monitor：每个任务更新后监控失败的持续时间 (ns|us|ms|s|m|h)（默认 0 秒）。
max_failure_ratio：更新期间可容忍的失败率。
order：更新期间的操作顺序。可以是 stop-first（旧任务在启动新任务之前停止）或 start-first（新任务首先启动，正在运行的任务短暂重叠）（默认 stop-first）。

deploy:
  update_config:
    parallelism: 2
    delay: 10s
    order: stop-first