# Compose规范 - 部署
[TOC]
*注意：*部署是Compose规范的可选部分
## 介绍
Compose规范是定义多容器应用程序的一种与平台无关的方法。支持Compose应用程序模型部署的Compose实现可能需要一些额外的元数据，因为Compose应用程序模型过于抽象，无法反映每个服务的实际基础架构需求或生命周期约束。
Compose Specification Deployment允许用户在服务上声明其他元数据，因此Compose实现可获取相关数据以在平台上分配足够的资源并对其进行配置以满足用户的需求。
## 定义
扩展了Compose Specification，以支持`deploy`关于服务的OPTIONAL小节。本部分定义服务的运行时要求。
### endpoint_mode
`endpoint_mode`为连接到服务的外部客户端指定服务发现方法。默认值和可用值是特定于平台的，无论如何Compose规范定义了两个规范值：
* `endpoint_mode: vip`：为服务分配一个虚拟IP（VIP），该虚拟IP充当客户端访问网络上服务的前端。平台在客户端和运行服务的节点之间路由请求，而无需客户端知道有多少节点正在参与服务或其IP地址或端口。
* `endpoint_mode: dnsrr`：平台为服务设置DNS条目，以便对服务名称的DNS查询返回IP地址列表（DNS轮询），并且客户端直接连接到其中之一。
~~~yaml
services:
frontend:
image: awesome/webapp
ports:
- "8080:80"
deploy:
mode: replicated
replicas: 2
endpoint_mode: vip
~~~
### labels
`labels`指定服务的元数据。这些标签*只能*在服务上设置，而*不能*在服务的任何容器上设置。这假定平台是可以与Compose应用程序模型匹配的“服务”的某些本地概念。
~~~yaml
services:
frontend:
image: awesome/webapp
deploy:
labels:
com.example.description: "This label will appear on the web service"
~~~
### mode
`mode`定义用于在平台上运行服务的复制模型。任一`global`（正好一个每个物理节点容器）或`replicated`（容器的指定数量）。默认值为`replicated`。
~~~yaml
services:
frontend:
image: awesome/webapp
deploy:
mode: global
~~~
### placement
`placement`为平台选择约束和首选项，以选择一个物理节点来运行服务容器。
#### constraints
`constraints`定义平台节点必须满足才能运行服务容器的REQUIRED属性。可以通过列表或带有字符串值的映射进行设置。
~~~yaml
deploy:
placement:
constraints:
- disktype=ssd
~~~
~~~yaml
deploy:
placement:
constraints:
disktype: ssd
~~~
#### preferences
`preferences`定义平台节点应满足以运行服务容器的属性。可以通过列表或带有字符串值的映射进行设置。
~~~yaml
deploy:
placement:
preferences:
- datacenter=us-east
~~~
~~~yaml
deploy:
placement:
preferences:
datacenter: us-east
~~~
### replicas
如果服务是`replicated`（默认）服务，请`replicas`指定在任何给定时间应运行的容器数
~~~yaml
services:
fronted:
image: awesome/webapp
deploy:
mode: replicated
replicas: 6
~~~
### resources
`resources`配置容器在平台上运行的物理资源限制。这些约束可以配置为：
* `limits`：平台必须阻止容器分配更多
* `reservations`：平台务必保证容器可以分配至少已配置的数量
~~~yaml
services:
frontend:
image: awesome/webapp
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
reservations:
cpus: '0.25'
memory: 20M
~~~
#### cpus
`cpus`配置容器可以使用的可用CPU资源量（作为内核数）的限制或预留。
#### memory
`memory`配置容器可以分配的内存量的限制或保留，设置为表示[字节值](spec.md)（specifying-byte-values）的字符串
#### devices
`devices`配置容器可以使用的设备的预留。它包含保留的列表，每个组具有下列参数的对象：`capabilities`，`driver`，`count`，`device_ids`和`options`。
使用功能列表保留设备，这`capabilities`是必填字段。设备必须满足所有请求的功能才能成功预订。
##### capabilities
`capabilities`被设置为字符串列表，表示通用和特定于驱动程序的功能。今天公认以下通用功能：
* `gpu`：图形加速器
* `tpu`：AI加速器
为避免名称冲突，驱动程序特定功能必须以驱动程序名称为前缀。例如，保留启用nVidia CUDA的加速器可能如下所示
~~~yaml
deploy:
resources:
reservations:
devices:
- capabilities: ["nvidia-compute"]
~~~
##### driver
可以使用`driver`字段请求用于保留设备的其他驱动程序。该值指定为字符串。
~~~yaml
deploy:
resources:
reservations:
devices:
- capabilities: ["nvidia-compute"]
driver: nvidia
~~~
##### count
如果`count`设置为`all`或未指定，则Compose实现必须保留所有满足请求功能的设备。否则，Compose实现必须至少保留指定数量的设备。该值指定为整数。
~~~yaml
deploy:
resources:
reservations:
devices:
- capabilities: ["tpu"]
count: 2
~~~
`count`和`device_ids`字段是排他的。如果同时指定了组合实现，则必须返回一个错误。
##### device_ids
如果`device_ids`设置为，则Compose实现必须保留具有指定ID的设备，前提是它们满足请求的功能。该值被指定为字符串列表。
~~~yaml
deploy:
resources:
reservations:
devices:
- capabilities: ["gpu"]
device_ids: ["GPU-f123d1c9-26bb-df9b-1c23-4a731f61d8c7"]
~~~
`count`和`device_ids`字段是排他的。如果同时指定了组合实现，则必须返回一个错误。
##### options
可以将特定于驱动程序的选项设置`options`为键值对。
~~~yaml
deploy:
resources:
reservations:
devices:
- capabilities: ["gpu"]
driver: gpuvendor
options:
virtualization: false
~~~
### restart_policy
`restart_policy`配置是否以及如何在退出容器时重新启动容器。如果`restart_policy`未设置，则撰写实现必须考虑`restart`由服务配置设置的字段。
* `condition`：其一`none`，`on-failure`或者`any`（默认值：`any`）。
* `delay`：两次重启尝试之间等待的[时间](spec.md)(specifying-durations)，指定为[持续时间](spec.md)(specifying-durations)（默认值：0）。
* `max_attempts`：放弃之前尝试重新启动容器的次数（默认值：永不放弃）。如果重新启动未在configure内成功完成`window`，则此尝试不会计入配置`max_attempts`值。例如，如果`max_attempts`设置为“ 2”，并且第一次尝试重启失败，则必须尝试两次以上的重启。
* `window`：决定重新启动是否成功之前要等待的[时间](spec.md)(specifying-durations)，指定为[持续时间](spec.md)(specifying-durations)（默认值：立即决定）。
~~~yaml
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`）。
### updatec_onfig
`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`）。
~~~yaml
deploy:
update_config:
parallelism: 2
delay: 10s
order: stop-first
~~~
