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

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

placement

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

约束

constraints 定义平台的节点必须满足的必要属性才能运行服务容器。更多示例,请参见CLI 参考文档

deploy:
  placement:
    constraints:
      - disktype=ssd

偏好

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 配置容器可以使用设备的保留。它包含一个保留列表,每个保留都设置为一个对象,包含以下参数:capabilitiesdrivercountdevice_idsoptions

使用功能列表保留设备,使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

countdevice_ids字段是互斥的。如果同时指定两者,Compose 将返回错误。

device_ids

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

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

countdevice_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”,并且第一次重启尝试失败,则必须尝试两次以上的重启。
  • window:在确定重启是否成功之前等待的时间,指定为持续时间(默认:立即决定)。
deploy:
  restart_policy:
    condition: on-failure
    delay: 5s
    max_attempts: 3
    window: 120s

rollback_config

rollback_config 配置在更新失败的情况下应如何回滚服务。

  • parallelism:一次回滚的容器数量。如果设置为 0,则所有容器同时回滚。
  • delay:每个容器组回滚之间等待的时间(默认为 0 秒)。
  • failure_action:如果回滚失败该怎么办。continuepause之一(默认为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:如果更新失败该怎么办。continuerollbackpause之一(默认为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