Eviter les conflits entre docker et les plages réseau du Ministère
Le 14 janvier 2026
ou comment publier des services conteneurisés pour tous les services du Ministère ?
Symptôme du dysfonctionnement
Vous êtes un service du Ministère et vous essayez d’utiliser une nouvelle application qui est bien joignable, résolution et flux, mais aucune réponse ne retourne du serveur.
Vous êtes Maitre d’œuvre une application que vous avez déployée au travers de services conteneurisés, qui fonctionne pour tous les services exceptés quelques uns.
Description du problème
Vous êtes un service dont les plages réseaux sont incluses dans 10.255.0.0/16, 172.17.0.0/16 ou 172.18.0.0/16.
Vous avez utilisé les plages par défaut de docker :
| Réseau | Plage par défaut | Usage |
|---|---|---|
| Overlay (utilisateur) | 10.0.0.0/8 | Communication inter-services Swarm |
| Ingress | 10.255.0.0/16 | Load balancing des services publiés |
| docker_gwbridge | 172.18.0.0/16 | Connectivité conteneurs → hôtes |
| Bridge local | 172.17.0.0/16 | Réseau par défaut (peu utilisé en Swarm) |
Comment y remédier
Il faut forcer les plages que docker ou docker swarm va utiliser. Nous avons réservé les plages suivantes à cette effet :
- Ingress : 10.254.0.0 /16
- Bridge local : 172.20.224.0/20
Elles vous garantissent aucun conflit avec un service et sont réservées à cet effet pour toute évolution future des plages des services. Vous référer à la documentation en vigueur pour paramétrer votre docker ou demander au Piag.
Vous avez en annexe la liste précise des plages affectées à des services. La reconfiguration du service docker ou l’initialisation du cluster Swarm est obligatoire au maitre d’œuvre pour s’assurer que son application sera opérationnelle pour tout le pôle Ministériel. Si un service concerné le souhaite, il est possible de migrer ses plages, ce qui implique des charges pour ces équipes locales et une reconfiguration de ses routeurs RIE.