Mises à jour progressives

docker service update remplace les tâches d'un service lot par lot, en suivant deploy.update_config : combien à la fois, dans quel ordre, combien de temps surveiller chacune. Bien réglée, une livraison passe inaperçue pour les clients.

Comment ça marche

parallelism (1 par défaut) fixe la taille des lots, delay la pause entre deux lots, monitor (5 s) la durée de surveillance de chaque nouvelle tâche. order: stop-first (par défaut) arrête l'ancienne tâche avant de démarrer la nouvelle ; start-first démarre la nouvelle à côté et n'arrête l'ancienne que quand la nouvelle est Running, c'est-à-dire healthy avec un healthcheck. start_period laisse du temps à une application lente avant que les vérifications ratées comptent.

Ce qui casse

Sans healthcheck, les nouvelles tâches reçoivent du trafic pendant leur démarrage. Avec un healthcheck mais sans start_period, une application lente est déclarée unhealthy et tuée encore et encore, et la mise à jour se met en pause. Un parallelism trop grand remplace toutes les répliques d'un coup.

Dans compose.yaml

services:
  api:
    image: registry.shop.internal/shop/api:1.5.0
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
      interval: 5s
      start_period: 60s
    deploy:
      replicas: 2
      update_config:
        parallelism: 1
        order: start-first
        monitor: 10s

Regarde-le casser, puis répare-le

Écris le Dockerfile ou le fichier compose, tape les commandes docker, et regarde un serveur simulé les exécuter à travers redémarrages, mises à jour et trafic. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable