Liste de contrôle opérationnelle pour la mise en réseau avec pont Docker en production, avec exemples pratiques

Introduction

La mise en réseau avec pont Docker est le mode réseau par défaut pour les conteneurs sur un hôte unique. En production, de petites erreurs de configuration peuvent entraîner des conflits d'adresses IP, une découverte de services défaillante ou des échecs de connectivité. Ce guide fournit une liste de contrôle opérationnelle pratique pour vous aider à gérer les réseaux en pont de manière sûre et fiable. Vous apprendrez à inventorier votre environnement, à effectuer des modifications de configuration ciblées, à vérifier la connectivité, à récupérer après des défaillances courantes et à exécuter des vérifications opérationnelles reproductibles.

Un processus opérationnel clair pour la mise en réseau en pont réduit les retouches en séparant la recherche, la mise en œuvre et la révision. Le premier pilote utile doit être étroit, mesurable et facile à inspecter localement avant le déploiement. Les étapes décrites ici sont conçues pour les développeurs, les consultants DevOps et les équipes techniques de startups qui ont besoin d'une configuration de réseau en pont fiable sans dépendre de réseaux overlay ou d'outils externes.

Tout au long de ce guide, vous trouverez des commandes concrètes avec les sorties attendues et des exemples de configuration. Tous les exemples utilisent le pont par défaut docker0 et un réseau en pont personnalisé appelé app-bridge. Ceux-ci sont construits à des fins d'illustration et doivent être adaptés à votre environnement.

Inventaire des versions et de l'environnement

Avant d'apporter des modifications, enregistrez les versions et la topologie. Cette base de référence permet d'identifier les problèmes de compatibilité et simplifie les retours en arrière. Attribuez un responsable unique, tel que l'ingénieur plateforme de garde, pour maintenir cet inventaire et le mettre à jour après tout changement de réseau. Révisez l'inventaire trimestriellement ou après des mises à niveau majeures de Docker.

Version de Docker

Exécutez :

docker version --format '{{.Server.Version}}'

Sortie attendue (exemple) :

24.0.7

Notez les versions client et serveur séparément si elles diffèrent. Utilisez docker version pour plus de détails. Des versions client et serveur incohérentes peuvent provoquer des incompatibilités d'API et un comportement inattendu, en particulier lors de l'utilisation d'options réseau plus récentes. Par exemple, un client Docker 27 parlant à un serveur Docker 20 peut échouer à définir silencieusement certaines options de pont.

Configuration du démon

Vérifiez les paramètres effectifs du démon, en particulier pour la mise en réseau en pont :

docker info --format '{{json .Plugins.Network}}'

Sortie attendue (exemple) :

["bridge","host","ipvlan","macvlan","null","overlay"]

Recherchez bridge dans la liste. S'il est absent, le démon n'est pas compilé avec le support du pont, ce qui est extrêmement rare mais casserait toute la mise en réseau en pont. Ensuite, inspectez la configuration du pont par défaut :

docker network inspect bridge

Cela renvoie un tableau JSON avec des détails comme Subnet, Gateway et Options. Par exemple :

[
  {
    "Name": "bridge",
    "Id": "a1b2c3d4...",
    "Scope": "local",
    "Driver": "bridge",
    "EnableIPv6": false,
    "IPAM": {
      "Driver": "default",
      "Options": null,
      "Config": [
        {
          "Subnet": "172.17.0.0/16",
          "Gateway": "172.17.0.1"
        }
      ]
    },
    "Containers": {},
    "Options": {
      "com.docker.network.bridge.default_bridge": "true",
      "com.docker.network.bridge.enable_icc": "true",
      "com.docker.network.bridge.enable_ip_masquerade": "true",
      "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
      "com.docker.network.bridge.name": "docker0",
      "com.docker.network.driver.mtu": "1500"
    }
  }
]

Champs clés à enregistrer :

• Subnet : Le pont par défaut utilise généralement 172.17.0.0/16. Si votre organisation utilise cette plage en interne, vous devez modifier la valeur par défaut du démon ou éviter le pont par défaut.
• Options.com.docker.network.bridge.enable_icc : La communication inter-conteneurs est activée par défaut sur le pont par défaut, mais ce n'est pas sécurisé pour la production. Les ponts personnalisés offrent un contrôle plus fin.
• Options.com.docker.network.bridge.enable_ip_masquerade : Cela permet aux conteneurs d'atteindre les réseaux externes via NAT. Gardez-le activé sauf si vous avez des besoins de routage spécifiques.

Noyau hôte et iptables

La mise en réseau en pont repose sur iptables pour le NAT et le filtrage. Vérifiez la version du noyau et la version d'iptables :

uname -r
iptables --version

Assurez-vous que le module br_netfilter est chargé. Ce module permet à iptables de voir le trafic ponté, ce qui est essentiel pour les politiques de communication inter-conteneurs et la publication de ports.

lsmod | grep br_netfilter

S'il est manquant, chargez-le et rendez-le persistant :

sudo modprobe br_netfilter
# Ajoutez les lignes suivantes au fichier /etc/modules-load.d/br_netfilter.conf :
# br_netfilter

Vérifiez également les paramètres sysctl :

sudo sysctl net.bridge.bridge-nf-call-iptables

Attendu :

net.bridge.bridge-nf-call-iptables = 1

S'il est à 0, activez-le :

sudo sysctl -w net.bridge.bridge-nf-call-iptables=1
# Rendez-le permanent dans /etc/sysctl.conf ou /etc/sysctl.d/99-bridge.conf

Schéma topologique

Créez un schéma simple montrant l'hôte Docker, le pont docker0, les ponts personnalisés et les conteneurs connectés. Notez les sous-réseaux IP, les ports exposés et les règles de pare-feu de l'hôte. Stockez ce schéma dans un contrôle de version ou une documentation. Incluez les détails suivants :

• Adresses IP et interfaces de l'hôte.
• Nom de chaque pont, sous-réseau et passerelle.
• Noms des conteneurs, adresses IP statiques ou dynamiques et ports publiés.
• Toute règle de pare-feu affectant le trafic du pont.

Utilisez un outil comme draw.io, Lucidchart, ou même un fichier texte avec la syntaxe Mermaid. Mettez à jour le schéma chaque fois qu'un réseau change.

Prérequis

Confirmez les points suivants avant tout changement de réseau :

• Le démon Docker est en cours d'exécution : docker info revient sans erreur.
• L'utilisateur a les permissions pour créer des réseaux et exécuter des conteneurs (généralement dans le groupe docker ou avec sudo).
• Aucun sous-réseau en conflit sur le réseau hôte. Par exemple, si le réseau local de l'hôte est 10.10.0.0/24, n'utilisez pas cette plage pour un pont.
• Le pont par défaut n'est pas utilisé pour les conteneurs de production (meilleure pratique). Exécutez docker network inspect bridge et assurez-vous que la section Containers est vide. Si des conteneurs de production y sont attachés, migrez-les vers un pont personnalisé en suivant les étapes de la section suivante.

Chemin de configuration sécurisé

Au lieu de modifier le pont docker0 par défaut, créez un réseau en pont personnalisé avec des paramètres IPAM explicites. Cela limite le rayon d'impact, permet une meilleure isolation et facilite la gestion. Décidez qui possède la configuration réseau : dans une petite équipe, c'est souvent l'ingénieur DevOps ; dans les grandes équipes, un groupe d'ingénierie plateforme possède les modèles de réseau. Révisez la configuration trimestriellement ou lorsque l'environnement Docker est mis à niveau.

Créer un réseau en pont personnalisé

Choisissez un sous-réseau sans chevauchement dans votre plage privée. Dans cet exemple, utilisez 10.10.0.0/24 avec la passerelle 10.10.0.1. Les indicateurs --subnet et --gateway sont obligatoires si vous voulez une attribution d'adresses IP déterministe.

docker network create \
  --driver bridge \
  --subnet 10.10.0.0/24 \
  --gateway 10.10.0.1 \
  --opt com.docker.network.bridge.name=br-app \
  app-bridge

Sortie attendue :

<network-id>

L'option --opt com.docker.network.bridge.name=br-app nomme l'interface du pont Linux sur l'hôte, ce qui facilite son identification dans ip addr ou brctl show. Si vous l'omettez, Docker utilise un nom d'interface aléatoire comme br-4e5f6a7b8c9d. Vérifiez la création :

docker network ls | grep app-bridge

Sortie attendue :

<network-id>   app-bridge   bridge   local

Inspectez le nouveau réseau :

docker network inspect app-bridge

Confirmez que le sous-réseau et la passerelle correspondent à vos valeurs prévues.

Attacher des conteneurs

Lors de l'exécution de conteneurs, attachez-les au réseau personnalisé. Par exemple, exécutez un serveur web et un client :

docker run -d --name web --network app-bridge nginx:alpine
docker run -dit --name client --network app-bridge alpine sh

Vérifiez que les deux conteneurs ont des adresses IP dans la plage 10.10.0.0/24 :

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' web

Sortie attendue (exemple) :

10.10.0.2

Configurer l'attribution d'adresses IP

Par défaut, les conteneurs obtiennent des adresses IP dynamiques à partir du sous-réseau. Pour les services avec état qui nécessitent une adresse stable, attribuez des adresses IP statiques en utilisant --ip. Cela exige que le sous-réseau soit explicitement défini lors de la création du réseau et que l'adresse IP soit en dehors de tout pool d'allocation dynamique si vous en avez configuré un.

docker run -d --name db --network app-bridge --ip 10.10.0.10 postgres:16

Soyez prudent pour éviter les conflits d'adresses IP. Avant d'attribuer une adresse IP statique, inspectez le réseau pour voir quelles adresses IP sont déjà utilisées :

docker network inspect app-bridge --format '{{range .Containers}}{{.IPv4Address}}{{"\n"}}{{end}}'

Sortie attendue (exemple) :

10.10.0.2/24
10.10.0.3/24

Choisissez ensuite une adresse IP inutilisée. Vérifiez également que le pool IPAM du réseau est suffisamment grand. Pour un sous-réseau /24, vous avez 253 adresses utilisables ; si vous prévoyez plus de conteneurs, utilisez un sous-réseau plus grand comme /22.

Activer la communication inter-conteneurs

Par défaut, les conteneurs sur le même réseau en pont personnalisé peuvent communiquer entre eux sur tous les ports. Si vous avez besoin d'isolation, définissez --opt com.docker.network.bridge.enable_icc=false lors de la création du réseau. Cela indique à Docker d'ajouter des règles iptables qui bloquent le trafic entre les conteneurs sur le même pont, sauf s'ils sont explicitement liés ou si des ports sont publiés.

Exemple :

docker network create \
  --driver bridge \
  --subnet 10.10.10.0/24 \
  --opt com.docker.network.bridge.enable_icc=false \
  isolated-bridge

Utilisez ensuite --link (obsolète mais fonctionne toujours) ou plus couramment des ports publiés et la découverte de services. Avec icc=false, chaque conteneur peut toujours communiquer avec le monde extérieur mais pas directement entre eux. Pour autoriser un trafic spécifique, vous pouvez utiliser --publish sur un conteneur et faire en sorte que les autres y accèdent via l'IP de l'hôte et le port publié, ou utiliser un réseau séparé avec icc=true pour les services qui doivent communiquer.

Ajuster la MTU si nécessaire

Pour les réseaux overlay, VPN ou environnements à trames géantes, vous pourriez avoir besoin d'une MTU plus basse pour éviter la fragmentation. Utilisez --opt com.docker.network.driver.mtu=1400.

docker network create \
  --driver bridge \
  --subnet 10.10.20.0/24 \
  --opt com.docker.network.driver.mtu=1400 \
  low-mtu-bridge

Après la création, vérifiez en exécutant ip link show br-<network-id> sur l'hôte et en contrôlant la valeur MTU.

Documenter les modifications

Tenez un journal des noms de réseaux, sous-réseaux, passerelles et services attachés. Utilisez un fichier de configuration ou un outil d'infrastructure as code comme Terraform ou Ansible. Par exemple, un simple manifeste YAML pour vos réseaux :

networks:
  - name: app-bridge
    subnet: 10.10.0.0/24
    gateway: 10.10.0.1
    options:
      bridge_name: br-app
      icc: true
      mtu: 1500
    owner: Équipe DevOps
    review_frequency: quarterly

Commitez ce fichier dans le contrôle de version et exigez une pull request pour les modifications.

Vérification et diagnostics

Après la configuration, exécutez des vérifications pour confirmer la connectivité, la résolution de noms et l'isolation du réseau. Effectuez ces vérifications immédiatement après tout changement de réseau et dans le cadre de votre surveillance de routine.

Connectivité de base

Depuis le conteneur client, effectuez un ping vers le conteneur web par son nom. Le DNS intégré de Docker permet la résolution de noms sur les réseaux personnalisés, mais pas sur le pont par défaut.

docker exec client ping -c 4 web

Sortie attendue (tronquée) :

PING web (10.10.0.2): 56 data bytes
64 bytes from 10.10.0.2: seq=0 ttl=64 time=0.120 ms
...
--- web ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss

Si le ping échoue, vérifiez :

• Statut du conteneur : docker ps -a pour voir si les deux sont en cours d'exécution.
• Attribution du réseau : docker inspect -f '{{.NetworkSettings.Networks}}' client devrait afficher app-bridge.
• Adresse IP : docker exec client ip addr pour confirmer qu'il a une IP dans le sous-réseau.

Résolution DNS

Testez la résolution inverse à l'intérieur du conteneur :

docker exec client nslookup 10.10.0.2

La sortie attendue inclut le nom du conteneur web :

Server:         127.0.0.11
Address:        127.0.0.11#53

2.0.10.10.in-addr.arpa  name = web.

Si la résolution échoue, assurez-vous que le conteneur est sur un réseau personnalisé, pas sur le pont par défaut, et que le serveur DNS intégré à 127.0.0.11 est joignable.

Exposition de ports

Si vous avez publié un port, testez depuis l'hôte. Par exemple, exécutez web avec -p 8080:80 :

docker run -d --name web --network app-bridge -p 8080:80 nginx:alpine
curl http://localhost:8080

Sortie attendue : la page HTML par défaut de nginx, commençant par <!DOCTYPE html>.

Vérifiez le mappage de ports avec :

docker port web

Attendu :

80/tcp -> 0.0.0.0:8080

Si vous ne pouvez pas atteindre le service, vérifiez que le pare-feu de l'hôte autorise le trafic entrant sur 8080, et examinez les règles NAT iptables avec sudo iptables -t nat -L -n | grep 8080.

Inspecter les détails du réseau

Affichez le réseau avec docker network inspect app-bridge. Vérifiez la section Containers pour les adresses IP et MAC. Extrait d'exemple :

"Containers": {
  "<container-id>": {
    "Name": "web",
    "IPv4Address": "10.10.0.2/24",
    "MacAddress": "02:42:0a:0a:00:02"
  }
}

Vérifiez que les adresses IP sont dans votre sous-réseau et que les adresses MAC sont uniques.

Règles iptables

Vérifiez qu'iptables a des règles pour le pont personnalisé. Exécutez :

sudo iptables -L -n -v | grep br-app

Vous devriez voir des règles de transfert et de masquage. Par exemple :

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  br-app br-app  anywhere             anywhere

Si vous avez icc=false, vous verrez des règles DROP entre les conteneurs. Si aucune règle n'apparaît, vérifiez si le nom de l'interface du pont est correct et si le réseau a été créé avec les options attendues.

Test d'isolation du réseau

Si vous avez activé icc=false, testez que les conteneurs ne peuvent pas se pinger (sauf autorisation explicite). Par exemple, depuis client, pinguez db :

docker exec client ping -c 2 db

Attendu : aucune réponse ou délai d'attente.

Si le ping réussit, l'isolation ne fonctionne pas. Vérifiez les options du réseau : docker network inspect isolated-bridge | grep -o 'com.docker.network.bridge.enable_icc": "[^"]*' devrait afficher false. Vérifiez également les règles iptables pour le pont.

Modes de défaillance et récupération

Les réseaux en pont peuvent échouer en raison de conflits d'adresses IP, de problèmes DNS, de mauvaises configurations de pare-feu ou de redémarrages du démon. Voici les modes de défaillance courants et comment récupérer. Désignez un ingénieur de garde pour gérer les incidents réseau, avec un contact principal et un contact secondaire. Documentez chaque incident et examinez-le mensuellement pour identifier les problèmes récurrents.

Conflit d'adresse IP

Symptôme : Les conteneurs perdent la connectivité ou ne peuvent pas démarrer avec une adresse IP statique. Docker peut signaler une erreur comme failed to allocate IP address si l'adresse IP est déjà utilisée en dehors de Docker.

Vérification : docker network inspect app-bridge et recherchez des adresses IP dupliquées ou --ip hors du sous-réseau. Vérifiez également la table ARP de l'hôte : ip neigh | grep 10.10.0.10. Si un appareil externe a la même adresse IP, vous avez un conflit.

Récupération : Déconnectez et reconnectez le conteneur avec une adresse IP correcte, ou supprimez et recréez le réseau après avoir arrêté tous les conteneurs attachés.

docker network disconnect app-bridge <container-id>
docker network connect --ip 10.10.0.12 app-bridge <container-id>

Si l'adresse IP est prise par un appareil externe, modifiez l'adresse IP de l'appareil externe ou choisissez une autre adresse IP statique pour le conteneur.

Échec de la résolution DNS

Symptôme : Les conteneurs ne peuvent pas résoudre les noms, mais la connectivité IP fonctionne.

Vérification : Assurez-vous que le réseau n'est pas le pont par défaut (le pont par défaut ne fournit pas de DNS). Vérifiez /etc/resolv.conf à l'intérieur du conteneur :

docker exec web cat /etc/resolv.conf

Attendu :

nameserver 127.0.0.11
options ndots:0

127.0.0.11 est le serveur DNS intégré de Docker. S'il est manquant ou différent, le conteneur n'est peut-être pas sur un réseau défini par l'utilisateur.

Récupération : Attachez le conteneur à un pont personnalisé s'il était sur le pont par défaut ; redémarrez le conteneur si les paramètres DNS sont obsolètes. Si le problème persiste, vérifiez si la configuration DNS du démon Docker est cassée : docker info | grep -A3 'DNS'.

Perte de connectivité après redémarrage du démon

Docker restaure les réseaux définis par l'utilisateur au redémarrage du démon. Si ce n'est pas le cas, assurez-vous que les fichiers de configuration réseau existent dans /var/lib/docker/network/files.

ls /var/lib/docker/network/files/

Chaque réseau devrait avoir un fichier nommé comme <network-id>.local. S'il est manquant, le réseau peut ne pas être récupérable.

Récupération : Recréez manuellement le réseau avec les mêmes paramètres, puis reconnectez les conteneurs. Utilisez un script ou de l'IaC pour garantir une création reproductible.

docker network create --driver bridge --subnet 10.10.0.0/24 --gateway 10.10.0.1 --opt com.docker.network.bridge.name=br-app app-bridge
# reconnectez chaque conteneur
docker network connect app-bridge web
docker network connect app-bridge client

Vérifiez que les conteneurs conservent leurs adresses IP si elles étaient statiques, ou obtiennent de nouvelles adresses IP si elles étaient dynamiques, et mettez à jour le DNS en conséquence.

Sur-blocage par le pare-feu

Si un pare-feu hôte bloque le trafic inter-conteneurs, ajustez iptables ou firewalld. Exemple : autorisez tout le trafic sur l'interface br-app :

sudo iptables -I FORWARD -i br-app -j ACCEPT
sudo iptables -I FORWARD -o br-app -j ACCEPT

Mais attention : cela désactive toute isolation sur ce pont. Une règle plus ciblée n'autorise que des ports spécifiques entre les conteneurs.

Pour firewalld, ajoutez l'interface du pont à la zone de confiance :

sudo firewall-cmd --permanent --zone=trusted --change-interface=br-app
sudo firewall-cmd --reload

Stratégie de retour en arrière

Avant d'apporter des modifications, prenez un instantané de la configuration réseau en utilisant docker network inspect et enregistrez-le dans un fichier. Pour revenir en arrière, arrêtez les conteneurs, supprimez le réseau personnalisé et restaurez l'état précédent.

# Enregistrer les configurations réseau actuelles
docker network inspect app-bridge > app-bridge-before.json

# Lors du retour en arrière, déconnectez les conteneurs
for c in $(docker network inspect app-bridge -f '{{range .Containers}}{{.Name}} {{end}}'); do
  docker network disconnect app-bridge $c
done

# Supprimez le réseau
docker network rm app-bridge

# Recréez à partir de l'instantané (manuellement ou via un script)
# Utilisez les paramètres du JSON enregistré pour recréer le réseau

Automatisez les instantanés avant chaque modification et stockez-les dans une sauvegarde versionnée.

Pièges et erreurs courants

Même les opérateurs expérimentés commettent des erreurs avec la mise en réseau en pont Docker. Voici les pièges courants, pourquoi ils se produisent et comment les éviter ou en récupérer.

Utiliser le pont par défaut pour la production

Pourquoi cela arrive : C'est l'option la plus simple ; docker run sans --network s'attache au pont par défaut.

Pourquoi c'est un problème : Le pont par défaut ne fournit pas de résolution DNS automatique entre les conteneurs ; vous devez utiliser l'ancien --link. Il ne permet pas non plus une isolation facile ou des sous-réseaux personnalisés. Les modifications du pont par défaut nécessitent un redémarrage du démon et affectent tous les conteneurs.

Comment éviter : Créez un pont personnalisé pour chaque application ou environnement. Appliquez cela par une politique ou en utilisant un script wrapper qui spécifie toujours --network.

Récupération : Arrêtez le conteneur, créez un pont personnalisé et relancez le conteneur avec --network custom-bridge. Si le conteneur doit être joignable par d'autres, utilisez le nom du conteneur comme nom d'hôte.

Épuisement des adresses IP

Pourquoi cela arrive : Utiliser un petit sous-réseau comme /28 ou /29, ou attribuer de nombreuses adresses IP statiques sans nettoyage.

Pourquoi c'est un problème : Les nouveaux conteneurs ne peuvent pas obtenir d'adresses IP, provoquant des échecs.

Comment éviter : Surveillez l'utilisation des adresses IP. Utilisez docker network inspect pour compter les adresses IP utilisées. Pour les pools dynamiques, définissez une taille de sous-réseau appropriée en fonction du nombre de conteneurs attendu. Si vous utilisez des adresses IP statiques, maintenez une feuille de calcul ou une base de données IPAM. Examinez mensuellement.

Récupération : Étendez le sous-réseau en recréant le réseau avec un sous-réseau plus grand (nécessite d'arrêter tous les conteneurs et de les reconnecter). Alternativement, libérez des adresses IP inutilisées en supprimant les conteneurs morts.

Oublier de définir enable_icc=false pour les réseaux multi-locataires

Pourquoi cela arrive : La valeur par défaut est true, et les opérateurs peuvent ne pas penser à l'isolation.

Pourquoi c'est un problème : Tout conteneur sur le même pont peut accéder à tout autre conteneur sur n'importe quel port, contournant la sécurité au niveau applicatif.

Comment éviter : Définissez --opt com.docker.network.bridge.enable_icc=false pour les réseaux qui hébergent des charges de travail non fiables ou multi-locataires. Autorisez ensuite explicitement la communication nécessaire via des ports publiés ou des règles iptables plus granulaires.

Récupération : Vous ne pouvez pas modifier icc sur un réseau existant ; vous devez recréer le réseau avec l'option et reconnecter les conteneurs.

Ignorer les interactions avec le pare-feu de l'hôte

Pourquoi cela arrive : Supposer que Docker gère toutes les règles de pare-feu et que le pare-feu de l'hôte (ufw, firewalld, iptables) n'interférera pas.

Pourquoi c'est un problème : Les règles du pare-feu de l'hôte peuvent bloquer le trafic du pont, surtout s'il y a une politique de refus par défaut sur la chaîne FORWARD. Docker insère ses propres règles, mais l'ordre compte et d'autres outils peuvent les perturber.

Comment éviter : Comprenez la configuration du pare-feu de votre hôte. Assurez-vous que les règles de Docker ne sont pas remplacées. Pour ufw, définissez DEFAULT_FORWARD_POLICY="ACCEPT" dans /etc/default/ufw si nécessaire, et utilisez ufw allow pour les ports publiés.

Récupération : Désactivez temporairement le pare-feu de l'hôte pour tester, puis ajoutez des règles appropriées. Pour iptables, insérez des règles ACCEPT pour l'interface du pont, mais attention à ne pas ouvrir trop largement.

Conflits d'adresses IP statiques avec la plage dynamique

Pourquoi cela arrive : Lors de la création d'un réseau, l'allocateur IPAM par défaut de Docker réserve tout le sous-réseau pour l'allocation dynamique, donc même les adresses IP statiques peuvent être dans cette plage. Si vous attribuez manuellement une adresse IP en dehors du sous-réseau, cela échoue. Mais plus subtil : si vous attribuez une adresse IP statique qui tombe dans le pool dynamique, l'IPAM de Docker ne le sait pas et peut attribuer la même adresse IP à un autre conteneur.

Pourquoi c'est un problème : Les conflits d'adresses IP provoquent une connectivité intermittente ou des échecs de démarrage des conteneurs.

Comment éviter : Réservez une sous-plage pour les adresses IP statiques en utilisant --ip-range lors de la création du réseau. Par exemple, utilisez le sous-réseau 10.10.0.0/24 et la plage IP 10.10.0.128/25, laissant 10.10.0.1-127 pour l'attribution statique.

docker network create \
  --driver bridge \
  --subnet 10.10.0.0/24 \
  --ip-range 10.10.0.128/25 \
  --gateway 10.10.0.1 \
  app-bridge-static

Les conteneurs dynamiques obtiennent des adresses IP >= 10.10.0.128, et vous pouvez attribuer en toute sécurité des adresses IP statiques < 10.10.0.128.

Récupération : Recréez le réseau avec une --ip-range appropriée, ou suivez manuellement les adresses IP statiques pour éviter le pool dynamique.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour les opérations de routine et les examens périodiques. Elle couvre les domaines clés de ce guide. Attribuez un responsable unique (par exemple, l'ingénieur DevOps de garde) pour effectuer les vérifications quotidiennes et un responsable plateforme pour effectuer les audits mensuels. Révisez la liste de contrôle elle-même trimestriellement.

Vérifications quotidiennes/hebdomadaires

Exemple de vérifications ping et DNS :

docker exec client ping -c 1 web
docker exec client nslookup web

Attendu :

1 packets transmitted, 1 packets received, 0% packet loss
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      web
Address 1: 10.10.0.2

Audits mensuels/trimestriels

• Examinez les allocations IPAM pour l'épuisement : vérifiez docker network inspect <réseau> et comptez les adresses IP utilisées. Comparez à la taille du sous-réseau pour garantir au moins 20% d'espace libre.
• Vérifiez qu'aucun conteneur de production n'est attaché au réseau en pont par défaut : docker network inspect bridge ne devrait montrer aucun conteneur. Si des conteneurs sont trouvés, migrez-les en suivant les étapes ci-dessus.
• Mettez à jour la documentation et les schémas pour refléter l'état actuel.
• Testez la récupération après défaillance : simulez un crash de conteneur (docker kill <conteneur> et voyez si la politique de redémarrage fonctionne), et testez la recréation du réseau dans un environnement de test.
• Nettoyez les réseaux inutilisés : docker network prune (attention : supprime tous les réseaux inutilisés). Faites d'abord un essai avec docker network ls -f dangling=true.

Gestion des modifications

• Testez toujours les nouvelles configurations réseau sur un hôte de test d'abord. Créez un miroir du réseau en pont de production et validez toutes les vérifications de connectivité et DNS.
• Utilisez des fichiers de configuration versionnés pour la création de réseaux. Appliquez les modifications via un pipeline CI/CD lorsque cela est possible.
• Planifiez des fenêtres de maintenance pour les modifications réseau. Pour les réseaux critiques, choisissez des périodes de faible trafic et informez les parties prenantes au moins 48 heures à l'avance.
• Ayez un plan de retour en arrière prêt. Prenez des instantanés des configurations avant les modifications et répétez la procédure de retour en arrière au moins une fois par trimestre.

Conclusion

La mise en réseau en pont Docker est une technologie fondamentale qui exige une attention opérationnelle minutieuse. En suivant cette liste de contrôle, vous pouvez réduire les temps d'arrêt et la dérive de configuration. Commencez par un inventaire complet de votre environnement, puis créez des réseaux en pont personnalisés avec des sous-réseaux et des options explicites. Vérifiez la connectivité et le DNS avant de déployer en production, et soyez prêt à récupérer des défaillances courantes en utilisant les étapes décrites.

Vos prochaines étapes :

• Exécutez les commandes d'inventaire et documentez votre état actuel dans un wiki ou un dépôt partagé.
• Créez un nouveau réseau en pont personnalisé pour une application de test et validez la connectivité et l'isolation.
• Intégrez les vérifications quotidiennes dans votre système de surveillance (par exemple, tâches cron, Nagios ou exportateurs Prometheus).
• Partagez cette liste de contrôle avec votre équipe et attribuez un responsable pour chaque tâche récurrente.

N'oubliez pas qu'un processus opérationnel clair pour la mise en réseau en pont réduit les retouches en séparant la recherche, la mise en œuvre et la révision. Le premier pilote utile doit être étroit et facile à inspecter localement. Utilisez ce guide comme un document évolutif et adaptez-le aux normes de votre organisation.