Mettre à jour ses conteneurs sans rien casser

Il y a deux façons de perdre ses données avec Docker, et la mise à jour automatique les réunit toutes les deux : appliquer un changement qu'on n'a pas choisi, à un moment où on ne regarde pas.

Ce guide propose l'inverse. Vous mettez à jour quand vous décidez, en dix minutes par mois, et vous savez revenir en arrière.

D'abord, le tag latest est le vrai problème

image: jellyfin/jellyfin:latest

Ce n'est pas une version. C'est « ce que le mainteneur considère comme actuel au moment où vous tirez l'image ». Deux conséquences :

• Vous ne savez pas ce que vous faites tourner. docker compose up -d sur une machine et sur une autre, à un mois d'écart, ne donne pas la même chose.
• Vous ne pouvez pas revenir en arrière, parce que vous ne savez pas d'où vous veniez.

Épinglez :

image: jellyfin/jellyfin:10.10.7

Vos fichiers ne bougent plus tant que vous ne changez pas ce numéro. C'est tout le principe.

Pour un composant critique — le reverse proxy, une base de données — vous pouvez aller plus loin et épingler l'empreinte, qui ne désigne qu'une image et une seule :

image: postgres:16.4@sha256:....

Étape 1 — Savoir qu'une version est sortie

Sans automatisation, il faut bien une source. Deux options honnêtes :

• Watcher les dépôts de vos services sur GitHub (bouton Watch → Releases only). Un e-mail par publication, avec les notes de version — c'est-à-dire précisément l'information qui manque à une mise à jour automatique.
• Un outil qui NOTIFIE sans appliquer : What's Up Docker ou diun. Ils comparent vos images à ce qui existe et vous préviennent. La décision reste la vôtre.

Étape 2 — Lire les notes de version

C'est l'étape qu'on saute, et c'est celle qui coûte cher. Vous cherchez trois mots : breaking, migration, manual.

Un service qui passe de 2.x à 3.x migre souvent sa base au premier démarrage. Cette migration est irréversible : redescendre d'une version après coup donne un service qui refuse de démarrer sur une base qu'il ne comprend plus.

C'est exactement ce contre quoi une mise à jour automatique ne peut rien.

Étape 3 — Sauvegarder AVANT

docker compose stop

Puis sauvegardez les volumes — voir Sauvegarder son serveur. Si vous n'avez qu'une seule chose à retenir de ce guide : une sauvegarde datant d'avant la mise à jour est ce qui transforme un échec en contretemps.

Arrêter les conteneurs n'est pas facultatif pour une base de données : copier les fichiers d'un Postgres en train d'écrire donne une sauvegarde qui a l'air complète et ne se restaure pas.

Étape 4 — Mettre à jour

Changez le numéro de version dans le docker-compose.yml, puis :

docker compose pull
docker compose up -d

pull télécharge, up -d recrée uniquement les conteneurs dont l'image a changé. Les autres ne sont pas touchés.

Un service à la fois. Six d'un coup, et le jour où quelque chose casse, vous avez six suspects.

Étape 5 — Vérifier, vraiment

docker compose ps
docker compose logs -f --tail=50

ps doit montrer Up, et pas Restarting — un conteneur qui redémarre en boucle donne un service injoignable dont le tableau de bord affiche pourtant « en cours d'exécution ».

Puis ouvrez le service et faites une vraie action : lancez une lecture, ajoutez une photo, dépliez une entrée. Une page d'accueil qui s'affiche ne prouve pas grand-chose.

Revenir en arrière

Remettez l'ancien numéro dans le fichier, puis :

docker compose up -d

Ça suffit tant que les données n'ont pas été migrées. Si elles l'ont été, c'est la sauvegarde de l'étape 3 qu'il faut restaurer — d'où l'étape 3.

Pourquoi ce guide déconseille l'automatisation

Tous les tutoriels recommandent Watchtower. Il a été archivé le 17 décembre 2025 : le dépôt est en lecture seule et le projet annonce lui-même qu'il n'est plus maintenu. Faire appliquer vos correctifs de sécurité par un outil qui n'en reçoit plus est une contradiction.

Mais même maintenu, le raisonnement tiendrait. Une mise à jour automatique :

• applique une migration irréversible sans que personne ne lise les notes ;
• casse à trois heures du matin, et vous l'apprenez par quelqu'un d'autre ;
• rend le diagnostic impossible — « ça marchait hier » ne désigne plus rien, puisque vous n'avez rien changé.

Dix minutes par mois, service par service, avec une sauvegarde derrière. C'est moins séduisant, et c'est ce qui tient.

Le ménage

Les anciennes images restent sur le disque. Après quelques mois :

docker image prune -a

Attention : cette commande supprime toutes les images non utilisées par un conteneur en cours, y compris celles vers lesquelles vous voudriez revenir. Faites-le une fois la nouvelle version éprouvée, pas le jour même.

Et ensuite

• Sauvegarder son serveur pour de vrai
• Mettre en place un reverse proxy