Spécification Compose Deploy

Table des matières

Le déploiement est une partie facultative de la spécification Compose. Il fournit un ensemble de spécifications de déploiement pour gérer le comportement des conteneurs dans différents environnements.

Attributs

`endpoint_mode`

endpoint_mode spécifie une méthode de découverte de service pour les clients externes se connectant à un service. La Spécification Compose Deploy définit deux valeurs canoniques :

endpoint_mode: vip : Assigne au service une IP virtuelle (VIP) qui agit comme la façade pour que les clients atteignent le service sur un réseau. La plateforme route les requêtes entre le client et les nœuds exécutant le service, sans que le client connaisse combien de nœuds participent au service ou leurs adresses IP ou ports.
endpoint_mode: dnsrr : La plateforme configure des entrées DNS pour le service de sorte qu'une requête DNS pour le nom du service retourne une liste d'adresses IP (DNS round-robin), et le client se connecte directement à l'une d'entre elles.

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

`labels`

labels spécifie les métadonnées pour le service. Ces étiquettes sont seulement définies sur le service et non sur aucun conteneur pour le service. Cela suppose que la plateforme a un concept natif de "service" qui peut correspondre au modèle d'application Compose.

services:
  frontend:
    image: example/webapp
    deploy:
      labels:
        com.example.description: "Cette étiquette apparaîtra sur le service web"

`mode`

mode définit le modèle de réplication utilisé pour exécuter un service ou une tâche. Les options incluent :

global : Assure qu'exactement une tâche s'exécute en continu par nœud physique jusqu'à l'arrêt.
replicated : Exécute en continu un nombre spécifié de tâches à travers les nœuds jusqu'à l'arrêt (par défaut).
replicated-job : Exécute un nombre défini de tâches jusqu'à un état de complétude (se termine avec le code 0).
- Le total des tâches est déterminé par replicas.
- La concurrence peut être limitée en utilisant l'option max-concurrent (CLI seulement).
global-job : Exécute une tâche par nœud physique avec un état de complétude (se termine avec le code 0).
- S'exécute automatiquement sur les nouveaux nœuds quand ils sont ajoutés.

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

Note

Les modes de tâche (replicated-job et global-job) sont conçus pour les tâches qui se complètent et se terminent avec le code 0.

Les tâches complétées restent jusqu'à être supprimées explicitement.

Les options comme max-concurrent pour contrôler la concurrence sont supportées seulement via la CLI et ne sont pas disponibles dans Compose.

Pour plus d'informations détaillées sur les options de tâche et le comportement, voir la documentation Docker CLI

`placement`

placement specifies constraints and preferences for the platform to select a physical node to run service containers.

`constraints`

constraints defines a required property the platform's node must fulfill to run the service container. For a further example, see the CLI reference docs.

deploy:
  placement:
    constraints:
      - disktype=ssd

`preferences`

preferences defines a strategy (currently spread is the only supported strategy) to spread tasks evenly over the values of the datacenter node label. For a further example, see the CLI reference docs

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

`replicas`

If the service is replicated (which is the default), replicas specifies the number of containers that should be running at any given time.

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

`resources`

resources configures physical resource constraints for container to run on platform. Those constraints can be configured as:

limits: The platform must prevent the container to allocate more.
reservations: The platform must guarantee the container can allocate at least the configured amount.

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

`cpus`

cpus configures a limit or reservation for how much of the available CPU resources, as number of cores, a container can use.

`memory`

memory configures a limit or reservation on the amount of memory a container can allocate, set as a string expressing a byte value.

`pids`

pids tunes a container's PIDs limit, set as an integer.

`devices`

devices configures reservations of the devices a container can use. It contains a list of reservations, each set as an object with the following parameters: capabilities, driver, count, device_ids and options.

Devices are reserved using a list of capabilities, making capabilities the only required field. A device must satisfy all the requested capabilities for a successful reservation.

`capabilities`

capabilities are set as a list of strings, expressing both generic and driver specific capabilities. The following generic capabilities are recognized today:

gpu: Graphics accelerator
tpu: AI accelerator

To avoid name clashes, driver specific capabilities must be prefixed with the driver name. For example, reserving an NVIDIA CUDA-enabled accelerator might look like this:

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

`driver`

A different driver for the reserved device(s) can be requested using driver field. The value is specified as a string.

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

`count`

If count is set to all or not specified, Compose reserves all devices that satisfy the requested capabilities. Otherwise, Compose reserves at least the number of devices specified. The value is specified as an integer.

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

count and device_ids fields are exclusive. Compose returns an error if both are specified.

`device_ids`

If device_ids is set, Compose reserves devices with the specified IDs provided they satisfy the requested capabilities. The value is specified as a list of strings.

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

count and device_ids fields are exclusive. Compose returns an error if both are specified.

`options`

Driver specific options can be set with options as key-value pairs.

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

`restart_policy`

restart_policy configures if and how to restart containers when they exit. If restart_policy is not set, Compose considers the restart field set by the service configuration.

condition. When set to:
- none, containers are not automatically restarted regardless of the exit status.
- on-failure, the container is restarted if it exits due to an error, which manifests as a non-zero exit code.
- any (default), containers are restarted regardless of the exit status.
delay: How long to wait between restart attempts, specified as a duration. The default is 0, meaning restart attempts can occur immediately.
max_attempts: The maximum number of failed restart attempts allowed before giving up. (Default: unlimited retries.) A failed attempt only counts toward max_attempts if the container does not successfully restart within the time defined by window. For example, if max_attempts is set to 2 and the container fails to restart within the window on the first try, Compose continues retrying until two such failed attempts occur, even if that means trying more than twice.
window: The amount of time to wait after a restart to determine whether it was successful, specified as a duration (default: the result is evaluated immediately after the restart).

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

`rollback_config`

rollback_config configures how the service should be rollbacked in case of a failing update.

parallelism: The number of containers to rollback at a time. If set to 0, all containers rollback simultaneously.
delay: The time to wait between each container group's rollback (default 0s).
failure_action: What to do if a rollback fails. One of continue or pause (default pause)
monitor: Duration after each task update to monitor for failure (ns|us|ms|s|m|h) (default 0s).
max_failure_ratio: Failure rate to tolerate during a rollback (default 0).
order: Order of operations during rollbacks. One of stop-first (old task is stopped before starting new one), or start-first (new task is started first, and the running tasks briefly overlap) (default stop-first).

`update_config`

update_config configures how the service should be updated. Useful for configuring rolling updates.

parallelism: The number of containers to update at a time.
delay: The time to wait between updating a group of containers.
failure_action: What to do if an update fails. One of continue, rollback, or pause (default: pause).
monitor: Duration after each task update to monitor for failure (ns|us|ms|s|m|h) (default 0s).
max_failure_ratio: Failure rate to tolerate during an update.
order: Order of operations during updates. One of stop-first (old task is stopped before starting new one), or start-first (new task is started first, and the running tasks briefly overlap) (default stop-first).

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