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

可以使用 `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：两次重启尝试之间等待的时间，指定为 duration。默认值为 0，表示重启尝试可以立即发生。
  • max_attempts：放弃前允许的最大失败重启尝试次数。（默认：无限重试。）只有当容器未能在由 `window` 定义的时间内成功重启时，失败尝试才会计入 `max_attempts`。例如，如果 `max_attempts` 设置为 `2`，并且容器在第一次尝试时未能在窗口内重启失败，Compose 会继续重试，直到发生两次这样的失败尝试，即使这意味着尝试次数多于两次。
  • window：重启后等待一段时间以确定是否成功的时间量，指定为 duration（默认：重启后立即评估结果）。
deploy:
  restart_policy:
    condition: on-failure
    delay: 5s
    max_attempts: 3
    window: 120s

rollback_config

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

  • parallelism：同时回滚的容器数量。如果设置为 0，所有容器同时回滚。
  • delay：每组容器回滚之间等待的时间（默认 0s）。
  • failure_action：如果回滚失败该怎么办。可以是 `continue` 或 `pause` 之一（默认 `pause`）
  • monitor：每次任务更新后监控故障的持续时间 `(ns|us|ms|s|m|h)`（默认 0s）。
  • 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)`（默认 0s）。
  • max_failure_ratio：更新期间可容忍的故障率。
  • order：更新期间的操作顺序。可以是 `stop-first`（旧任务在启动新任务之前停止）或 `start-first`（新任务先启动，运行中的任务会短暂重叠）之一（默认 `stop-first`）。
deploy:
  update_config:
    parallelism: 2
    delay: 10s
    order: stop-first
页面选项