Changer le pool par défaut de Docker ne renumérote pas les réseaux

Modifier default-address-pools ne renumérote pas les réseaux que vous avez déjà, et l'espérer est précisément ce qui transforme un plan soigneux en panne inattendue. Le réglage régit l'attribution automatique des réseaux créés après le redémarrage du démon avec la nouvelle configuration. Tout ce qui tourne déjà conserve le sous-réseau qui lui a été attribué, car ce sous-réseau fait partie de la définition stockée du réseau. Le mythe est commode parce qu'il suggère qu'une seule modification corrige chaque chevauchement, et la réalité est un travail en deux parties : choisissez une plage réellement libre, puis migrez les réseaux qui ne le sont pas.

Le mythe : un seul changement de pool corrige le chevauchement

Le mythe a une forme précise. Quelqu'un lit que le pool par défaut de Docker peut être changé, le change, redémarre le démon et conclut que le réseau de conteneurs n'entre plus en collision avec le VPN du bureau. L'ancien réseau est toujours là, toujours attaché, et détient toujours l'adresse qui entre en collision.

Ce qui a changé, c'est le comportement futur de l'allocateur, ce qui est réellement utile et réellement limité. Les nouveaux réseaux créés sans --subnet explicite sont découpés dans le nouveau pool ; les existants n'ont jamais été dans ce pool. Un redémarrage ne reconstruit pas les réseaux et ne déplace pas les conteneurs entre eux. Si le symptôme persiste après le changement, le changement était réel et le diagnostic incomplet.

Plage de base et préfixe attribué

La configuration a deux champs faciles à confondre. base est la plage dans laquelle l'allocateur découpe, et size est la longueur de préfixe de chaque réseau attribué, donc une base 10.10.0.0/16 avec une taille 24 distribue des /24 à l'intérieur de ce /16. Inverser les rôles produit un schéma d'attribution que vous ne vouliez pas, généralement un seul réseau énorme ou un pool épuisé.

Un pool est une réservation, pas une preuve. Docker évite les conflits qu'il voit dans la table de routage de l'hôte et ne peut pas voir un VPN auquel vous n'êtes pas encore connecté.

Cette limite est toute la raison de choisir délibérément. Les plages à comparer sont celles que l'hôte doit atteindre : le LAN du bureau, les sous-réseaux internes du VPN d'entreprise, les préfixes du labo ou de staging et tout autre hôte de conteneurs sur le même overlay. Écrivez-les en CIDR avant de toucher au démon, car une liste dans votre tête oubliera précisément celle qui compte. Choisissez ensuite une base qui ne chevauche aucune d'elles, et conservez la liste avec le déploiement pour que la personne suivante ne refasse pas l'exercice de mémoire.

Inventorier avant de choisir

Inventoriez d'abord ce qui existe. docker network ls liste les réseaux, et docker network inspect bridge -f '{{.IPAM.Config}}' imprime le sous-réseau qu'un réseau donné utilise. Répétez pour chaque réseau défini par l'utilisateur, car les projets Compose créent les leurs et un --subnet explicite dans un fichier compose contourne entièrement le pool.

Ce dernier point est celui qui survit à la migration. Un changement de pool n'empêche pas un collègue d'épingler 172.18.0.0/16 dans un fichier compose, et le conflit revient avec un autre auteur.

Migrer ce qui existe déjà

Migrer des réseaux existants est une opération distincte et prise en charge. Chaque réseau concerné doit être recréé avec le nouveau sous-réseau, ce qui suppose de détacher puis de rattacher les conteneurs qui l'utilisent, et recréer un réseau supprime ses attachements de conteneurs au lieu de les déplacer. Préservez les volumes et la configuration, et traitez la recréation comme un déploiement plutôt qu'une remise à zéro des données. Faites le travail dans une fenêtre de maintenance, car les conteneurs d'un réseau recréé redémarrent que vous l'ayez prévu ou non.

Suivez la configuration du démon et la procédure de redémarrage documentées, et coordonnez l'interruption. Sur un hôte à démon unique, systemctl restart docker redémarre les conteneurs selon leurs politiques de redémarrage, et c'est un comportement qu'il vaut mieux connaître avant qu'après.

Vérifiez ensuite les deux choses que le changement était censé corriger. Inspectez le nouveau sous-réseau avec docker network inspect et confirmez qu'il se trouve dans la base choisie, puis vérifiez la route vers une destination VPN représentative avec ip route get 10.20.30.40 et confirmez qu'elle va là où vous l'attendez et non dans un pont. Testez aussi la découverte de services et la communication entre conteneurs, car un réseau recréé avec un autre adressage peut casser la résolution de noms d'une manière qui ressemble à un bug applicatif.

Ce qui casse encore ensuite

La partie durable, c'est l'enregistrement. Conservez la liste des attributions, la base et la taille choisies, et les réseaux recréés au même endroit que le déploiement.

Ce n'est pas parce qu'une plage est privée qu'elle est sûre à réutiliser. 10.0.0.0/8 est privée et aussi ce qui a le plus de chances d'être déjà utilisé quelque part sur le chemin, c'est pourquoi la réponse est une réservation précise et non une préférence pour un bloc. La documentation réseau de Docker décrit l'attribution automatique de sous-réseaux et les champs du pool. Choisissez la plage d'après ce que vous devez atteindre, pas d'après ce qui paraît propre.