Passer de Docker 25 à Docker 29 sur un VPS Linux

Docker Engine 25 est sorti début 2024. Depuis, quatre versions majeures se sont succédé et la branche 29 est la branche courante : la 29.0.0 date du 10 novembre 2025 et la 29.9.3 a été publiée le 3 novembre 2026. Si votre VPS Linux tourne encore en 25.x, vous n'avez plus de correctifs de sécurité à ce niveau, et plusieurs comportements ont changé en route. Ce tutoriel recense les ruptures utiles pour un administrateur, puis déroule une procédure de mise à jour avec contrôle avant et après.

Tout ce qui suit est tiré des notes de version et de la page des fonctionnalités dépréciées de la documentation officielle Docker (liens en fin d'article). Pour un hôte de test ou de production avec accès root, un VPS Linux convient parfaitement.

Pourquoi quitter Docker 25

Le moteur Docker (Docker Engine, le démon dockerd et sa CLI) reçoit ses correctifs sur les branches récentes. La version 28.5.2 corrigeait par exemple trois vulnérabilités de haute gravité dans runc, le runtime qui exécute les conteneurs, permettant de sortir d'un conteneur. La 29.9.3 corrige elle aussi plusieurs failles. Rester en 25 revient à accumuler de la dette sur la couche qui isole vos services.

Autre raison : les jalons de dépréciation. Plus vous attendez, plus le saut devient large, et plus la lecture des notes de version devient longue.

Définitions : moteur, conteneur, démon et pare-feu

Avant de configurer quoi que ce soit, il faut distinguer les éléments qui reviennent dans ce guide :

• Docker Engine : le moteur qui crée et exécute les conteneurs sur un système Linux ou Unix. Il se compose du démon dockerd et de la CLI, la ligne de commande docker.
• Conteneur : un processus isolé, lancé à partir d'une image, qui embarque ses propres fichiers et ses dépendances.
• Image : le modèle en lecture seule à partir duquel un conteneur est créé. Un serveur Web Apache, une base MySQL ou PostgreSQL, ou un environnement Python ou PHP sont des images courantes.
• Runtime : le composant bas niveau qui lance le conteneur. Docker utilise runc pour cela.
• Pilote de stockage (storage driver) et image store : la manière dont les images et leurs couches sont stockées sur le disque.
• Fichier de configuration : /etc/docker/daemon.json règle le démon, au format JSON.
• Pare-feu : Docker s'appuie par défaut sur iptables. nftables est une option expérimentale dans la 29.0.
• cgroup : le mécanisme Linux qui limite les ressources (processeur, mémoire RAM) d'un groupe de processus.

Ce qui a changé de la 26 à la 29

Docker 26 : l'API minimale remonte

Le support des versions d'API inférieures à 1.24 a été supprimé définitivement en 26.0. Les anciens clients et scripts qui parlent à l'API Docker peuvent être concernés. Les champs Container et ContainerConfig de l'inspection d'image ont aussi disparu : il faut lire Config. Le champ Aliases contenant l'ID court du conteneur est également retiré au profit de DNSNames.

Docker 28 : le gros changement réseau

La 28.0.0 (février 2025) est la version qui demande le plus d'attention sur un serveur exposé :

• les hôtes distants ne peuvent plus se connecter directement aux ports publiés d'un conteneur sans passer par la publication, et les hôtes voisins ne peuvent plus atteindre les ports liés à une adresse de loopback ;
• l'accès routé direct aux ports non publiés est bloqué dans la chaîne DOCKER. Pour le conserver, il faut publier les ports ou utiliser le mode nat-unprotected ;
• les règles de publication de ports et d'isolation réseau ont été profondément modifiées, et le démon exige le support d'ipset dans le noyau ;
• les adresses MAC des interfaces de conteneur (bridge et macvlan) sont générées aléatoirement ;
• les serveurs DNS lus dans le fichier /etc/resolv.conf de l'hôte sont interrogés depuis le namespace réseau de l'hôte, et Google DNS n'est plus utilisé en repli.

La politique FORWARD d'ip6tables passe à DROP uniquement si le forwarding IPv6 est activé sur l'hôte. Si votre pare-feu repose sur UFW ou sur des règles manuelles, relisez notre guide pour ouvrir des ports avec UFW et vérifiez la cohérence après migration.

Docker 28.2 : suppressions de compatibilité

Le pull d'images au format schema 1 (très anciennes images) est supprimé en 28.2, de même que le repli vers le pull par tag sur des registres non conformes. Le champ IsAutomated et le filtre is-automated de docker search sont retirés. Si un vieux conteneur refuse de se télécharger, l'image source est probablement trop ancienne : reconstruisez-la.

Docker 29 : image store, cgroup, nftables

• API minimale v1.44 à la sortie de la 29.0 (donc compatible avec les clients Docker 25.0 et suivants). D'après les notes de version, la 29.3.0 a abaissé ce minimum à v1.40 (Docker 19.03).
• Image store containerd par défaut pour les installations neuves. Il ne s'applique pas aux démons configurés avec userns-remap.
• nftables expérimental : on l'active avec l'option firewall-backend du démon réglée sur nftables.
• cgroup v1 déprécié, avec un support maintenu au moins jusqu'en mai 2029. Migrer vers cgroup v2 est recommandé.
• Docker Content Trust retiré de la CLI.
• Les paquets Debian armhf ciblent ARMv7 et les paquets 32 bits pour Raspbian ne sont plus fournis.
• Le module Go github.com/docker/docker est déprécié au profit de github.com/moby/moby/client et github.com/moby/moby/api. Cela ne concerne que ceux qui développent contre l'API.

Tableau récapitulatif

Préparer la migration

Ne mettez pas à jour un serveur de production sans filet. Quelques vérifications suffisent à éviter l'essentiel des surprises.

1. Inventaire : notez la version actuelle, le pilote de stockage, les conteneurs en cours (serveur Web, base de données, scripts Python ou PHP, FTP ou SMTP) et les réseaux utilisés.
2. Sauvegarde (backup) : exportez vos volumes, vos bases de données (export ou dump MySQL ou PostgreSQL) et vos fichiers Compose, versionnés avec Git si possible, et faites un snapshot du VPS si vous en avez un. Les sauvegardes d'ElypseCloud sont une option, pensez à la commander ; sinon, un rsync vers une machine distante fait l'affaire.
3. Nettoyage : supprimez ce qui ne sert plus, avec les précautions du guide nettoyer Docker avec prune.
4. Environnement de test : clonez la pile sur un second serveur et jouez la migration complète dessus.

docker version
docker info | grep -Ei "storage driver|cgroup|server version"
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"
docker compose ls
sudo iptables-save > ~/iptables-avant-docker29.txt

La dernière commande conserve l'état des règles pour comparer ensuite. Le fichier de configuration /etc/docker/daemon.json mérite aussi une copie, comme le reste de votre configuration Docker.

Repérer les points fragiles

• Cherchez dans vos scripts les appels à docker commit --pause (remplacé par --no-pause, cible de suppression en 30.0) et les options --time de docker stop et docker restart (remplacées par --timeout).
• Repérez les conteneurs liés avec --link : les variables d'environnement des liens legacy sont désactivées par défaut en 29.0, et les liens sur le bridge par défaut ont une cible de suppression en 30.0. Préférez des réseaux définis par l'utilisateur.
• Vérifiez que votre noyau supporte ipset.
• Si vous exposez l'API Docker en TCP à distance, TLS est la règle pour l'authentification des connexions distantes : les connexions non authentifiées étaient dépréciées dès la 26.0.

Accès SSH et authentification avant la migration

Une migration se fait presque toujours en ligne de commande, via SSH (Secure Shell), sur une machine distante. Toutes les commandes de ce guide se lancent dans un shell Unix. Gardez ces réflexes :

• ouvrez une seconde session SSH et ne fermez la première qu'après avoir vérifié la nouvelle connexion, surtout si le pare-feu change pendant la mise à jour ;
• connectez-vous avec un compte d'administration non root, puis passez en root avec sudo ;
• privilégiez une authentification par clé plutôt que par mot de passe ;
• notez l'adresse IP du serveur et le nom de domaine qui y pointe, pour les tests de l'étape suivante.

ssh admin@adresse-ip-du-vps
sudo -i

Effectuer la mise à jour

La procédure ci-dessous suppose une installation faite avec le dépôt officiel Docker, comme décrit dans notre guide installer Docker sur un VPS. Si Docker vient du paquet de votre distribution, changez d'abord de dépôt.

Configurer live-restore pour limiter l'interruption

L'option live-restore maintient les conteneurs actifs quand le démon s'arrête. Configurez-la dans le fichier de configuration /etc/docker/daemon.json avant la mise à jour, puis rechargez le démon :

{
  "live-restore": true
}

sudo systemctl reload docker

Elle ne dispense pas de prévoir une fenêtre de maintenance : un changement de version majeure peut tout de même nécessiter un redémarrage des conteneurs, surtout avec les changements de règles réseau de la 28.

Mettre à jour les paquets

Sur Debian ou Ubuntu avec le dépôt officiel, lancez les commandes une à une et passez à la commande suivante seulement si la précédente réussit :

sudo apt-get update
apt-cache madison docker-ce | head
sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl restart docker

Sur les distributions de la famille Red Hat (Rocky Linux, Fedora), utilisez dnf upgrade sur les mêmes paquets (packages). Après l'opération :

docker version
docker info | grep -Ei "storage driver|cgroup"
docker ps -a
sudo iptables-save > ~/iptables-apres-docker29.txt
diff ~/iptables-avant-docker29.txt ~/iptables-apres-docker29.txt | head -50

Le diff sera long, c'est normal : la 28 a refondu les règles. Ce qui compte, c'est le test fonctionnel qui suit.

Vérifier après la migration

1. Services : chaque conteneur répond-il comme avant ? Testez depuis l'extérieur, avec l'adresse IP publique ou le nom de domaine, pas seulement depuis le serveur. Notre guide lister les ports en écoute avec ss aide à comparer ce qui est réellement ouvert.
2. Communication entre conteneurs : testez les noms DNS internes, les réseaux personnalisés et les anciens liens.
3. Résolution DNS : depuis la 28.0, la source des serveurs DNS a changé de comportement, donc un conteneur qui comptait sur un résolveur de repli peut échouer.
4. Compose : relancez docker compose up -d et lisez les avertissements. Voir Docker Compose sur un VPS Linux.
5. Journaux (logs) : journalctl -u docker --since "1 hour ago" montre les erreurs de démarrage.

Image store containerd : faut-il changer ?

Pour les installations neuves, l'image store containerd est le défaut en 29. Sur un serveur mis à jour, rien ne vous oblige à basculer. Si vous décidez de le faire plus tard, traitez-le comme un chantier séparé : un changement de store ne reprend pas les images existantes de l'ancien magasin. Planifiez un nouveau pull ou une reconstruction, et testez d'abord.

Pare-feu : iptables ou nftables

Le support nftables est expérimental dans la 29.0. Si vous gérez déjà votre pare-feu avec nftables, lisez le guide pare-feu nftables et testez sur un hôte jetable avant d'activer firewall-backend. Pour la production, gardez la configuration que vous maîtrisez.

Services courants à contrôler après la mise à jour

Un conteneur n'a pas les mêmes besoins qu'un autre. Ce tableau sert de checklist pour les services les plus fréquents sur un serveur Linux. Vérifiez aussi les scripts (shell, Python ou PHP) qui appellent la CLI ou l'API Docker.

Après un redémarrage de l'hôte (boot), vérifiez que le service Docker démarre seul et que chaque conteneur revient dans l'état attendu.

Prévoir le retour arrière

La 28.0 prévient qu'un retour à une version antérieure demande un nettoyage manuel des nouvelles règles réseau, ou un redémarrage de l'hôte. Le plan de repli réaliste est donc :

1. arrêter les conteneurs et le démon ;
2. réinstaller la version 25 choisie dans apt-cache madison ;
3. redémarrer l'hôte pour repartir de règles réseau propres ;
4. restaurer les volumes ou le snapshot si les données ont été touchées.

Ce scénario se répète sur la copie de test, pas en urgence sur le serveur de production. Sur une machine avec beaucoup de services, un serveur dédié ou un second VPS donne de la marge pour tester en parallèle.

Aller plus loin

Si les ruptures vous paraissent lourdes, comparez avec Podman dans Podman ou Docker sur un VPS Linux. Si vos conteneurs sont des applications web, pensez aussi à placer un reverse proxy devant, comme dans le guide Nginx reverse proxy, plutôt que de publier chaque port à l'extérieur.

Une mise à jour de moteur n'est pas un événement rare : prévoyez d'en refaire une tous les quelques mois. Plus l'écart est faible, moins les notes de version sont longues à lire et moins les changements se cumulent.

Sources officielles

• Notes de version Docker Engine 29
• Notes de version Docker Engine 28
• Fonctionnalités dépréciées de Docker Engine