[{"data":1,"prerenderedAt":175},["ShallowReactive",2],{"seo-verification":3,"blog-docker-v29-migration-vps-breaking-changes-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"title":9,"excerpt":10,"readTime":11,"views":12,"isPinned":13,"publishedAt":14,"category":15,"categories":20,"featuredImage":22,"bgImage":23,"posterImage":24,"relatedSolution":22,"intro":25,"sections":26,"ctaTitle":130,"ctaBody":131,"ctaButton":132,"ctaUrl":133,"relatedPosts":134},247,"docker-v29-migration-vps-breaking-changes","Docker v29 sur VPS : migration sans casser vos stacks","Docker Engine v29 change l'API minimale, le backend réseau et le moteur d'images. Guide de migration pour agences qui gèrent un parc de VPS clients.",11,0,false,"2026-08-12T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":18},3,"Déploiement","deploiement","bg-success\u002F10 text-success",[21],{"id":16,"name":17,"slug":18,"color":19,"icon":18},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdocker-v29-migration-vps-breaking-changes-poster.svg","Docker Engine v29, sorti en mars 2026, modifie trois fondations simultanément : version minimale d'API, backend réseau nftables et magasin d'images containerd. Un VPS non préparé qui reçoit cette mise à jour casse silencieusement — docker-compose v1 standalone ne fonctionne plus, Dockge ne démarre plus, les règles iptables que vos stacks supposaient disparaissent. Ce guide vous permet de détecter ce qui est cassé, de migrer proprement, et d'éviter que le prochain `apt upgrade` ne devienne un incident client à 2 h du matin.",[27,31,42,45,55,64,73,82,102,106,109,127],{"type":28,"title":29,"body":30},"h2","Pourquoi Docker v29 casse les stacks existantes — et pourquoi maintenant","Une agence qui gère un parc de VPS clients vit dans un étau particulier : la mise à jour amont (Docker, Ubuntu, Debian) arrive de l'extérieur, indépendamment de qui administre le serveur. Quand un VPS client reçoit `apt upgrade` sans contrôle, trois ruptures arrivent en même temps.\n\n**Première rupture — version minimale d'API.** Docker Engine v29 relève la version minimale d'API à `1.44`. Les clients qui tournent encore avec l'ancien `docker-compose` v1 standalone (binaire `\u002Fusr\u002Flocal\u002Fbin\u002Fdocker-compose`) échouent immédiatement : leur code client est compilé pour des versions d'API antérieures, et le daemon refuse la connexion avec un message d'incompatibilité.\n\n**Deuxième rupture — backend réseau nftables.** Docker v29 active nftables par défaut à la place d'iptables pour gérer les règles de pare-feu des réseaux Docker. Les scripts tiers qui inspectent directement les chaînes iptables (scripts de monitoring, pare-feu custom, certaines règles UFW) ne voient plus les règles Docker — non pas parce qu'elles ont disparu, mais parce qu'elles vivent désormais dans nftables.\n\n**Troisième rupture — magasin d'images containerd.** Le backend de stockage des images bascule vers le magasin containerd. En opt-in depuis v29, il deviendra le défaut en v30. Sur un serveur migré, les images existantes restent accessibles mais le chemin de cache change, ce qui peut surprendre des scripts qui inspectent `\u002Fvar\u002Flib\u002Fdocker\u002Fimage` directement.\n\nL'objection classique — « nos clients gèrent leurs VPS eux-mêmes » — ne protège pas. La rupture arrive de l'extérieur, et c'est l'agence que le client appelle quand son site ne répond plus.",{"type":32,"title":33,"items":34},"ul","Ce que ce guide vous permet de faire",[35,36,37,38,39,40,41],"**Détecter la version d'API** en tension entre votre client `docker` et le daemon du VPS, avant que la prochaine commande ne produise une erreur cryptique.","**Identifier en 30 secondes** si un VPS tourne encore avec `docker-compose` v1 standalone — le binaire déprécié depuis Docker Desktop 3.6 et retiré des paquets officiels.","**Migrer vers le plugin `docker compose` v2** avec les deux commandes exactes, puis vérifier que vos `docker-compose.yml` existants fonctionnent sans modification de syntaxe.","**Comprendre l'impact nftables** sur vos stacks : ce qui continue de fonctionner (les réseaux Docker), ce qui peut casser (vos scripts qui lisent iptables), et la commande de diagnostic qui tranche.","**Activer ou reporter le magasin containerd** selon votre calendrier de migration, avec la clé de configuration exacte et la commande de vérification.","**Évaluer la compatibilité** de Dockge, Portainer et CasaOS App Store avec v29, pour ne pas découvrir l'incompatibilité pendant un incident client.","**Préparer vos VPS clients** pour que le prochain `apt upgrade` soit un événement planifié, pas une urgence nocturne.",{"type":28,"title":43,"body":44},"Prérequis avant de commencer","Ce guide s'applique à tout VPS Ubuntu 22.04\u002F24.04 ou Debian 11\u002F12 sur lequel Docker Engine est installé depuis les dépôts officiels Docker Inc. (pas le paquet `docker.io` de la distribution). Vous avez besoin d'un accès SSH root ou sudo. Aucune interruption de service n'est requise pour les étapes de diagnostic ; la migration du plugin compose nécessite quelques secondes pendant lesquelles les commandes `docker compose` sont indisponibles. Prévoyez un snapshot du VPS avant de modifier `\u002Fetc\u002Fdocker\u002Fdaemon.json` si vous activez le magasin containerd — la restauration en cas de problème prend moins de cinq minutes avec un bon VPS qui propose les snapshots à la demande.",{"type":46,"title":47,"steps":48},"steps","Étape 1 — Diagnostiquer la version d'API",[49,52],{"title":50,"body":51},"Vérifier la version d'API client et daemon","Sur chaque VPS à auditer, exécutez les deux commandes suivantes :\n\n```bash\ndocker version --format '{{.Client.APIVersion}}'\ndocker version --format '{{.Server.APIVersion}}'\n```\n\nSi la version client est inférieure à `1.44` et que le daemon tourne en v29, vous obtenez une erreur lors des prochaines commandes. Le seuil `1.44` est le minimum accepté par Docker Engine v29 : un client compilé pour `1.43` ou antérieur échoue avec `Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client`.\n\nSi les deux lignes affichent `1.44` ou plus, votre client est compatible. Passez à l'étape suivante.",{"title":53,"body":54},"Détecter la présence de docker-compose v1 standalone","La commande `docker-compose` avec tiret et la commande `docker compose` sans tiret ne sont pas la même chose. Le v1 est un binaire Python autonome, le v2 est un plugin Go intégré au CLI Docker.\n\n```bash\nwhich docker-compose && docker-compose --version\n```\n\nSi la commande retourne un chemin dans `\u002Fusr\u002Flocal\u002Fbin\u002F` ou `\u002Fusr\u002Fbin\u002F` avec une version `1.x.x`, vous avez le binaire standalone déprécié. Après la mise à jour Docker v29, ce binaire renvoie `docker-compose: command not found` si le paquet a été retiré, ou l'erreur d'API décrite ci-dessus s'il est encore présent.\n\n```bash\ndocker compose version\n```\n\nSi cette commande renvoie `Docker Compose version v2.x.x`, le plugin v2 est déjà présent. Les deux peuvent coexister temporairement, mais l'objectif est de n'utiliser que le plugin v2.",{"type":46,"title":56,"steps":57},"Étape 2 — Migrer de docker-compose v1 vers le plugin v2",[58,61],{"title":59,"body":60},"Retirer le binaire v1 et installer le plugin","```bash\napt remove docker-compose\napt install docker-compose-plugin\n```\n\nSur un VPS Debian ou Ubuntu qui utilise les dépôts officiels Docker Inc. (`download.docker.com`), le paquet `docker-compose-plugin` est disponible sans configuration supplémentaire. Si `apt remove docker-compose` répond `Package not found`, le binaire a été installé manuellement : localisez-le avec `which docker-compose` et supprimez le fichier.\n\nVérification post-migration :\n\n```bash\ndocker compose version\n# Docker Compose version v2.36.0\n```",{"title":62,"body":63},"Vérifier la compatibilité syntaxique de vos fichiers Compose existants","La grande majorité des fichiers `docker-compose.yml` écrits pour v1 fonctionnent sans modification avec le plugin v2. Les seules ruptures de syntaxe concernent les directives `version:` supérieures à `\"3.8\"` (ignorées en v2, pas bloquantes) et l'option `--compatibility` (retirée). Validez vos fichiers existants :\n\n```bash\ndocker compose config\n```\n\nCette commande résout les variables d'environnement, valide la syntaxe et affiche la configuration résolue. Une sortie sans erreur signifie que votre fichier est compatible.\n\nSi votre équipe utilise des scripts shell avec `docker-compose` (tiret), posez un alias de compatibilité dans `\u002Fetc\u002Fbash.bashrc` du VPS :\n\n```bash\nalias docker-compose='docker compose'\n```\n\nCet alias ne résout pas les scripts qui appellent `docker-compose` en absolu dans un cron ou un service systemd — auditez-les.",{"type":46,"title":65,"steps":66},"Étape 3 — Comprendre et adapter au changement de backend réseau nftables",[67,70],{"title":68,"body":69},"Vérifier que les réseaux Docker fonctionnent toujours","La bonne nouvelle : `docker network` fonctionne correctement avec nftables. Le trafic entre conteneurs, la NAT et l'exposition de ports continuent de fonctionner. Ce qui change, c'est l'outil sous-jacent qui écrit les règles.\n\n```bash\ndocker network ls\n```\n\nVos réseaux bridge existants sont toujours listés. Pour vérifier qu'un conteneur reçoit bien du trafic sur le port attendu, testez directement :\n\n```bash\ncurl -s http:\u002F\u002Flocalhost:8080\u002Fhealth\n```\n\nSi la réponse est correcte, le plan de données Docker fonctionne indépendamment du backend.",{"title":71,"body":72},"Diagnostiquer l'impact sur vos scripts iptables","Le problème se présente quand un script tiers (monitoring, Ansible, règles UFW) inspecte `iptables` pour vérifier que les règles Docker sont présentes :\n\n```bash\niptables -L DOCKER 2>&1\n```\n\nAvec le backend nftables, cette chaîne est vide ou absente. Le script retourne une erreur alors que Docker fonctionne parfaitement. Ce n'est pas une panne Docker — c'est votre outil d'audit qui ne regarde plus au bon endroit.\n\nPour inspecter les règles réelles :\n\n```bash\nnft list ruleset | grep -A 20 'docker'\n```\n\nSi vos scripts de monitoring ou vos playbooks Ansible vérifient la présence de règles iptables spécifiques à Docker, adaptez-les pour interroger nftables plutôt que d'en déduire une panne.\n\nSi vous avez des règles UFW personnalisées qui interagissent avec les règles Docker, consultez la documentation Docker sur le mode `DOCKER-USER` — il existe en nftables comme en iptables, mais la syntaxe d'ajout de règles diffère. L'article [pare-feu-ufw-vps](\u002Fblog\u002Fpare-feu-ufw-vps) couvre UFW de manière générale ; pour l'interaction spécifique à Docker v29, référez-vous aux notes de release officielle.",{"type":46,"title":74,"steps":75},"Étape 4 — Évaluer et activer le magasin d'images containerd",[76,79],{"title":77,"body":78},"Vérifier le driver de stockage actuel","```bash\ndocker info | grep 'Storage Driver'\n```\n\nSur un VPS mis à jour vers v29 sans modification de configuration, vous obtenez typiquement `Storage Driver: overlay2`. Le magasin containerd est en opt-in sur v29 — il n'est pas activé automatiquement. Il deviendra le défaut sur v30.\n\nSi vous voyez `Storage Driver: overlayfs` (signe que quelqu'un a déjà activé le backend containerd), le magasin est actif.",{"title":80,"body":81},"Activer le magasin containerd (opt-in, recommandé avant v30)","Pour activer le magasin containerd sur v29 et préparer la migration avant qu'elle ne soit imposée en v30, ajoutez la clé suivante dans `\u002Fetc\u002Fdocker\u002Fdaemon.json` :\n\n```bash\n{\n  \"features\": {\n    \"containerd-snapshotter\": true\n  }\n}\n```\n\nRedémarrez le daemon :\n\n```bash\nsystemctl restart docker\n```\n\nVérification :\n\n```bash\ndocker info | grep 'Storage Driver'\n# Storage Driver: overlayfs\n```\n\n**Point d'attention** : les images existantes tirées sous `overlay2` restent disponibles, mais les nouvelles couches sont écrites dans le format containerd. Si vous devez revenir en arrière, supprimez la clé et redémarrez — les images du nouveau format ne seront plus accessibles sans le backend containerd. C'est pourquoi un snapshot avant cette étape est conseillé.",{"type":83,"title":84,"headers":85,"rows":89},"comparison","Compatibilité des outils tiers avec Docker Engine v29",[86,87,88],"Outil","État de compatibilité v29","Action recommandée",[90,94,98],[91,92,93],"**Dockge** (jusqu'à 1.4.1 inclus)","Non compatible : le daemon de Dockge appelle des routes d'API retirées en v29. Le panneau ne démarre plus après la mise à jour Docker.","Mettre à jour Dockge vers la version 1.4.2 ou supérieure, qui cible l'API v1.44. Vérifier les notes de release Dockge avant `apt upgrade` sur un VPS qui l'héberge.",[95,96,97],"**Portainer** (Community Edition \u003C 2.21)","Partiellement compatible : l'interface fonctionne, mais les environnements Docker standalone peuvent afficher des erreurs sur les vues réseau. La version 2.21 corrige les appels nftables.","Mettre à jour Portainer via `docker pull portainer\u002Fportainer-ce:latest` puis `docker compose up -d` avant d'upgrader Docker Engine.",[99,100,101],"**CasaOS App Store**","Compatibilité partielle documentée : les apps déployées continuent de fonctionner, mais le gestionnaire d'apps peut signaler des erreurs lors de l'inspection des images si le magasin containerd est activé. Pas de version corrective annoncée au 2026-08.","Garder le magasin containerd en opt-out (défaut v29) sur les VPS CasaOS jusqu'à une version corrective. Tester sur un environnement de copie avant toute mise à jour.",{"type":103,"title":104,"body":105},"tip","Tester la migration sur un snapshot avant de toucher la production","Un VPS avec accès root et snapshots permet de valider chaque étape de cette migration sans risque. Créez un snapshot nommé `avant-docker-v29`, effectuez la migration complète, validez vos stacks, puis supprimez le snapshot. Si quelque chose se passe mal en cours de route, la restauration ramène le VPS à son état initial en moins de cinq minutes. C'est précisément l'usage que les snapshots à la demande couvrent : tester une mise à jour système risquée sur une copie exacte, pas en production client.",{"type":28,"title":107,"body":108},"Dépannage — erreurs réelles et remèdes","Les trois scénarios suivants couvrent la majorité des incidents constatés lors de migrations Docker v29 sur des parcs VPS.",{"type":46,"title":110,"steps":111},"Scénarios d'erreur courants",[112,115,118,121,124],{"title":113,"body":114},"Erreur : `client version X.XX is too old. Minimum supported API version is 1.44`","**Cause** : le binaire `docker-compose` v1 standalone est encore présent et tente de communiquer avec le daemon v29.\n\n**Remède** :\n\n```bash\napt remove docker-compose\napt install docker-compose-plugin\ndocker compose version\n```\n\nSi le binaire a été installé manuellement (hors apt), cherchez-le :\n\n```bash\nwhich docker-compose\nrm \u002Fusr\u002Flocal\u002Fbin\u002Fdocker-compose\n```",{"title":116,"body":117},"Erreur : `docker-compose: command not found` après `apt upgrade`","**Cause** : le paquet `docker-compose` (v1) a été retiré lors de la mise à jour, et le plugin v2 n'a pas été installé.\n\n**Remède** :\n\n```bash\napt install docker-compose-plugin\n```\n\nVérifiez ensuite que vos scripts qui appellent `docker-compose` (avec tiret) utilisent désormais `docker compose` (sans tiret), ou posez l'alias système.",{"title":119,"body":120},"Erreur : `iptables: No chain\u002Ftarget\u002Fmatch by that name` dans un script de monitoring","**Cause** : votre script inspecte la chaîne `DOCKER` dans iptables, mais Docker v29 avec nftables ne l'écrit plus là.\n\n**Remède** : remplacez la vérification iptables par une vérification nftables :\n\n```bash\nnft list ruleset | grep -c 'docker'\n```\n\nSi le count est supérieur à zéro, les règles Docker sont présentes en nftables. Ou utilisez `docker network inspect bridge` pour vérifier l'état du plan de données directement depuis Docker, sans dépendre du backend réseau.",{"title":122,"body":123},"Dockge ne démarre plus après la mise à jour","**Cause** : Dockge 1.4.1 et antérieurs appellent des routes d'API absentes de Docker Engine v29.\n\n**Remède** :\n\n```bash\ncd \u002Fopt\u002Fdockge\ndocker compose pull\ndocker compose up -d\n```\n\nSi le tag `latest` de l'image Dockge est déjà en 1.4.2 ou supérieur, cette commande suffit. Sinon, éditez votre `docker-compose.yml` Dockge pour pointer vers le tag de la version corrective avant de relancer.",{"title":125,"body":126},"Les conteneurs ne répondent plus sur leurs ports après redémarrage du daemon","**Cause** : lors du premier redémarrage de `dockerd` en mode nftables, les règles de NAT sont réécrites dans le bon backend, mais certaines distributions ont un conflit entre le service `iptables-legacy` et nftables qui retarde la mise en place des règles.\n\n**Remède** :\n\n```bash\nsystemctl stop docker\nsystemctl disable iptables\nsystemctl start docker\n```\n\nPuis vérifiez que les conteneurs sont bien redémarrés (`docker compose up -d`) et que les ports sont exposés (`docker ps --format 'table {{.Names}}\\t{{.Ports}}').",{"type":28,"title":128,"body":129},"Préparer votre parc pour éviter le prochain incident","Une migration Docker v29 bien menée n'est pas un événement isolé — c'est l'occasion de mettre en place les réflexes qui évitent la prochaine urgence nocturne.\n\n**Verrouillez la version Docker dans `apt`.** Sur les VPS clients, empêchez Docker de se mettre à jour automatiquement lors des `apt upgrade` non supervisés :\n\n```bash\napt-mark hold docker-ce docker-ce-cli containerd.io\n```\n\nDéverrouillez (`apt-mark unhold`) uniquement quand vous êtes prêt à migrer, après avoir testé sur un snapshot.\n\n**Automatisez l'audit du parc.** Un playbook Ansible qui vérifie la version d'API Docker sur chaque VPS prend moins d'une heure à écrire et vous donne un tableau de bord de l'exposition de votre parc avant chaque release Docker majeure. L'article [ansible-automatiser-serveurs-vps](\u002Fblog\u002Fansible-automatiser-serveurs-vps) couvre la mise en place de ce type d'inventaire.\n\n**Intégrez la migration Docker dans votre routine de correctifs.** La procédure décrite ici — snapshot, vérification d'API, migration compose, test nftables, validation des stacks — se documente en runbook et se rejoue à chaque release majeure. L'article [routine-correctifs-apps-self-hosted](\u002Fblog\u002Froutine-correctifs-apps-self-hosted) donne une structure pour industrialiser ces gestes sur un parc de VPS.\n\n**Testez vos stacks sur un environnement de copie.** Un VPS de staging avec snapshot vous permet de reproduire exactement le contexte d'un VPS client, de rejouer la migration et de valider les stacks avant d'intervenir en production. C'est ce que les VPS avec accès root et snapshots à la demande rendent possible à l'échelle d'une agence.","Des VPS prêts pour Docker v29 — avec snapshot et accès root","Une agence qui gère plusieurs VPS clients a besoin d'une infrastructure Docker homogène, versionnée et préparée aux mises à jour amont. ServOrbit propose des VPS avec accès root, IPv4 dédiée et snapshots — pour que chaque migration se teste d'abord sur un environnement de copie, pas en production client.","Voir les VPS Cloud","\u002Fsolutions\u002Fagences",[135,145,161],{"id":136,"slug":137,"title":138,"excerpt":139,"readTime":11,"views":12,"isPinned":13,"publishedAt":140,"category":141,"categories":142,"featuredImage":22,"bgImage":23,"posterImage":144,"relatedSolution":22},229,"docker-compose-production-checklist","Docker Compose en production : checklist des 10 points","10 paramètres Docker Compose à vérifier avant tout déploiement en production : restart, healthchecks, limits, secrets et logs.","2026-08-06T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":18},[143],{"id":16,"name":17,"slug":18,"color":19,"icon":18},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":146,"slug":147,"title":148,"excerpt":149,"readTime":150,"views":12,"isPinned":13,"publishedAt":151,"category":152,"categories":158,"featuredImage":22,"bgImage":23,"posterImage":160,"relatedSolution":22},224,"routine-correctifs-apps-self-hosted","Applications self-hosted : la routine de correctifs","Inventaire, avis de sécurité, fenêtre de correctif, sauvegarde et vérification : la routine qui manque à la plupart des parcs auto-hébergés.",4,"2026-08-05T00:00:00+00:00",{"id":153,"name":154,"slug":155,"color":156,"icon":157},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[159],{"id":153,"name":154,"slug":155,"color":156,"icon":157},"\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg",{"id":162,"slug":163,"title":164,"excerpt":165,"readTime":11,"views":12,"isPinned":13,"publishedAt":166,"category":167,"categories":172,"featuredImage":22,"bgImage":23,"posterImage":174,"relatedSolution":22},236,"ansible-automatiser-serveurs-vps","Automatiser la gestion de ses serveurs VPS avec Ansible","Découvrez comment automatiser la gestion d'une flotte de serveurs VPS avec Ansible : inventaire, playbooks, rôles et Vault pour une infrastructure repro...","2026-08-08T00:00:00+00:00",{"id":168,"name":169,"slug":170,"color":171,"icon":170},2,"Automatisation","automatisation","bg-brand-action\u002F10 text-brand-action",[173],{"id":168,"name":169,"slug":170,"color":171,"icon":170},"\u002Fblog\u002Fcovers\u002Fansible-automatiser-serveurs-vps-poster.svg",1786536100423]