Mettre à jour des conteneurs sans interruption

Mettre à jour un conteneur, ce n’est pas « tirer une nouvelle image », mais « remplacer la version en cours d’exécution par une nouvelle et pouvoir revenir en arrière ». La différence se manifeste exactement une fois : quand la nouvelle version refuse de démarrer.

Une procédure qui fonctionne

cd /opt/myapp
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f --tail 100

Compose ne recrée que les services dont l’image a changé et laisse les autres tranquilles. L’indisponibilité se limite aux quelques secondes nécessaires au redémarrage du conteneur.

Mais avant de faire cela, remplissez deux conditions.

Premièrement : les versions sont figées. Le fichier doit indiquer postgres:17.2, pas postgres:latest. Sinon, pull finira un jour par apporter une version majeure qui réécrit le format des données, et le retour en arrière devient impossible.

Deuxièmement : la sauvegarde est récente. Une mise à jour qui casse la base de données la casse de façon irréversible. Avant un changement de version majeure, faites un dump — voir ce qu’il faut sauvegarder.

Remplacer sans interruption

Pour un service web derrière un reverse proxy, l’indisponibilité tombe à presque zéro si le conteneur dispose d’un health check : le proxy ne commencera à envoyer des requêtes qu’à une instance prête.

services:
  app:
    image: ghcr.io/example/app:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 5s
      timeout: 3s
      retries: 6
      start_period: 20s

docker inspect -f '{{.State.Health.Status}}' <container>

Sans health check, Compose considère le conteneur comme prêt dès que le processus démarre — alors que l’application est encore en train de lire ses paramètres et d’appliquer les migrations.

Ne supprimez pas l’ancienne image tant que la nouvelle version n’a pas tourné au moins une heure. Un retour en arrière signifie restaurer image: ...:1.4.2 et lancer docker compose up -d, mais uniquement tant que l’ancienne image est encore sur le disque. Un docker image prune -a juste après une mise à jour vous retire cette possibilité.

Retour en arrière

sed -i 's|app:1.5.0|app:1.4.2|' compose.yaml
docker compose up -d app
docker compose logs -f --tail 50 app

Si la nouvelle version a déjà modifié le schéma de la base de données, revenir à l’image précédente ne suffit pas — il faudra restaurer à partir d’une sauvegarde. C’est pourquoi les mises à jour majeures se font à un moment calme et avec une sauvegarde vérifiée : voir exercice de restauration.

Automatisation : prudence

Watchtower peut mettre à jour les conteneurs tout seul. Pour des services domestiques, c’est pratique ; en production, c’est un risque : la mise à jour arrive la nuit, casse la base de données, et personne ne le remarque. Un compromis raisonnable consiste à se limiter aux notifications :

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --monitor-only --schedule "0 0 6 * * *"

Vous apprenez qu’une nouvelle version est sortie et vous mettez à jour manuellement au moment qui vous convient.

Redémarrer la machine

Les paquets système se mettent à jour séparément des conteneurs. Après une mise à jour du noyau, un redémarrage est nécessaire, et les conteneurs avec restart: unless-stopped remontent d’eux-mêmes. Testez-le à l’avance — avec sudo reboot à un moment calme, pas pendant un incident. Un redémarrage logiciel depuis le panneau fonctionne tant que qemu-guest-agent est installé sur le système.

Erreurs courantes

• pull sans up -d. La nouvelle image est téléchargée, mais l’ancien conteneur tourne toujours.
• Le disque est encombré d’anciennes images. Lancez docker image prune une fois par mois — mais pas juste après une mise à jour. Voir espace disque.
• Vous avez tout mis à jour d’un coup. Quelque chose casse — et vous ne pouvez pas dire quoi. Mettez à jour un service à la fois.
• Vous n’avez pas lu les notes de version. Un fichier de configuration incompatible est la cause la plus fréquente d’échec après un changement de version majeure ; voir le détail dans problèmes Docker courants.