Laboratoire de réseau Docker : créez un environnement local sûr pour tester et dépanner

Introduction

Le réseau Docker est l'une des sources de confusion les plus courantes lorsqu'on passe d'un conteneur unique à des applications multi-conteneurs. Des réseaux mal configurés entraînent des conteneurs qui ne peuvent pas communiquer entre eux, des échecs de résolution DNS ou une exposition involontaire à l'hôte. Plutôt que d'expérimenter sur un hôte de production, vous pouvez construire un laboratoire de réseau Docker local sûr pour tester des configurations, dépanner des comportements et créer des flux de travail d'apprentissage reproductibles. Un laboratoire contrôlé vous aide à isoler les problèmes, vérifier les correctifs et gagner en confiance avant d'apporter des modifications ailleurs dans votre infrastructure.

Ce guide vous explique comment mettre en place un tel laboratoire avec des commandes concrètes et les sorties attendues. Nous allons créer des réseaux bridge Docker dédiés, lancer des conteneurs avec des adresses IP statiques et des noms d'hôte personnalisés, tester la connectivité et la résolution DNS, démontrer l'isolation réseau, puis examiner les modes de défaillance courants ainsi que les étapes de récupération. Tous les exemples sont conçus pour fonctionner sur un seul hôte Linux avec Docker installé, y compris Docker Desktop sur Windows ou macOS. Les commandes sont sûres pour votre environnement local et n'affectent pas les autres réseaux Docker ou conteneurs en cours d'exécution.

Un laboratoire local est particulièrement précieux lorsque vous apprenez les concepts de réseau Docker ou que vous dépannez un problème que vous soupçonnez d'être lié au réseau. Au lieu de deviner ou de lire une longue documentation, vous pouvez reproduire le problème en quelques minutes, tester des correctifs et documenter ce qui fonctionne. La possibilité d'inspecter l'intérieur du réseau directement dans les conteneurs vous donne un aperçu immédiat de la façon dont Docker gère le réseau sous le capot.

Inventaire de la version et de l'environnement

Avant de commencer, confirmez que votre environnement répond aux prérequis suivants :

• Docker Engine version 20.10 ou ultérieure, ou équivalent Docker Desktop.
• Un hôte Linux (natif ou machine virtuelle) avec un shell Bash. Windows Subsystem for Linux 2 (WSL2) fonctionne bien, tout comme Docker Desktop avec des conteneurs Linux.
• Une familiarité de base avec la CLI Docker et les commandes de cycle de vie des conteneurs telles que docker run, docker exec et docker rm.
• Aucun réseau défini par l'utilisateur nommé labnet1 ou labnet2, et aucun conteneur nommé lab1, lab2 ou lab3 (nous allons les créer).

Pour vérifier votre version de Docker, exécutez :

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

Sortie attendue similaire à :

20.10.21

Confirmez également que vous pouvez lister les réseaux actuels :

docker network ls

Vous devriez voir une sortie similaire à la suivante (les ID de réseau varieront) :

NETWORK ID     NAME      DRIVER    SCOPE
abc123def456   bridge    bridge    local
ghi789jkl012   host      host      local
mno345pqr678   none      null      local

Si vous voyez les réseaux par défaut bridge, host et none, vous êtes prêt à continuer. Ce laboratoire utilise des réseaux bridge définis par l'utilisateur, qui offrent une résolution DNS automatique entre les conteneurs et une isolation de la pile réseau de l'hôte.

Chemin de configuration sûr

Nous allons construire le laboratoire de manière incrémentale, en vérifiant chaque étape avant de passer à la suivante. Cette approche limite la portée des modifications et facilite le retour en arrière : si quelque chose ne va pas, vous pouvez supprimer uniquement les ressources que vous venez de créer sans affecter le reste de votre environnement.

Étape 1 : Créer un réseau bridge défini par l'utilisateur isolé

Créez un réseau nommé labnet1 avec un sous-réseau spécifique pour éviter les conflits avec les réseaux existants et permettre des attributions d'IP statiques :

docker network create \
  --driver bridge \
  --subnet 192.168.100.0/24 \
  --gateway 192.168.100.1 \
  labnet1

La sortie attendue est l'ID du réseau, par exemple :

6f8d4c9b2a1e

Vérifiez que le réseau existe et a la bonne configuration :

docker network inspect labnet1 --format '{{.Name}} {{.Driver}} {{.IPAM.Config}}'

Sortie attendue :

labnet1 bridge [{192.168.100.0/24 192.168.100.1 map[]}]

Cela confirme que le réseau est un driver bridge avec le sous-réseau et la passerelle spécifiés.

Étape 2 : Lancer deux conteneurs sur le réseau avec des IP statiques

Nous allons exécuter deux conteneurs Alpine Linux car ils sont légers et démarrent rapidement. Chaque conteneur reçoit une adresse IP statique et un nom d'hôte personnalisé. Démarrez le premier conteneur, lab1, avec l'IP 192.168.100.10 :

docker run -dit \
  --name lab1 \
  --network labnet1 \
  --ip 192.168.100.10 \
  --hostname lab1 \
  alpine:latest

La sortie attendue est l'ID du conteneur, par exemple :

abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890

Démarrez le deuxième conteneur, lab2, avec l'IP 192.168.100.20 :

docker run -dit \
  --name lab2 \
  --network labnet1 \
  --ip 192.168.100.20 \
  --hostname lab2 \
  alpine:latest

Vérifiez que les deux conteneurs sont en cours d'exécution :

docker ps --filter "name=lab" --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Sortie attendue :

NAMES   IMAGE            STATUS
lab1    alpine:latest    Up 10 seconds
lab2    alpine:latest    Up 8 seconds

Étape 3 : Tester la connectivité de base entre les conteneurs

Exécutez un ping de lab1 vers lab2 en utilisant son adresse IP :

docker exec lab1 ping -c 2 192.168.100.20

Sortie attendue (les valeurs de temps peuvent varier) :

PING 192.168.100.20 (192.168.100.20): 56 data bytes
64 bytes from 192.168.100.20: seq=0 ttl=64 time=0.123 ms
64 bytes from 192.168.100.20: seq=1 ttl=64 time=0.098 ms

--- 192.168.100.20 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.098/0.110/0.123 ms

Testez maintenant en utilisant le nom du conteneur pour vérifier la résolution DNS :

docker exec lab1 ping -c 2 lab2

La sortie attendue doit être similaire au ping précédent, montrant que lab2 s'est résolu en 192.168.100.20. Cela confirme que le serveur DNS intégré de Docker fonctionne automatiquement sur les réseaux définis par l'utilisateur.

Étape 4 : Exposer un service simple et tester depuis un autre conteneur

Tester au niveau de la couche réseau est utile, mais un laboratoire pratique doit également vérifier la connectivité au niveau des services. Nous allons exécuter un serveur web léger dans lab2 en utilisant le serveur HTTP intégré de Python. Alpine Linux n'inclut pas Python par défaut, donc installez-le d'abord dans lab2 :

docker exec lab2 apk add --no-cache python3

Ensuite, démarrez un serveur HTTP simple sur le port 8000 dans lab2 :

docker exec -d lab2 python3 -m http.server 8000

Le flag -d exécute le serveur en mode détaché dans le conteneur. Vérifiez que le serveur écoute :

docker exec lab2 netstat -tuln | grep 8000

Alternativement, utilisez ss -tuln si netstat n'est pas disponible. La sortie attendue montre une ligne avec 0.0.0.0:8000 indiquant que le serveur écoute sur toutes les interfaces.

Maintenant, testez depuis lab1 en utilisant wget (disponible dans Alpine par défaut) pour récupérer un fichier du serveur. Comme le répertoire racine du serveur est / dans lab2, vous pouvez récupérer /etc/hostname pour voir le nom d'hôte :

docker exec lab1 wget -qO- http://192.168.100.20:8000/etc/hostname

Sortie attendue :

lab2

Vous pouvez également utiliser le nom du conteneur dans l'URL pour tester la découverte de services basée sur DNS :

docker exec lab1 wget -qO- http://lab2:8000/etc/hostname

Cela devrait produire la même sortie, confirmant que le DNS intégré résout lab2 et que le service HTTP est accessible.

Étape 5 : Créer un deuxième réseau pour démontrer l'isolation

Créez un autre réseau labnet2 avec un sous-réseau différent :

docker network create \
  --driver bridge \
  --subnet 10.10.10.0/24 \
  --gateway 10.10.10.1 \
  labnet2

Attachez un nouveau conteneur lab3 à labnet2 :

docker run -dit \
  --name lab3 \
  --network labnet2 \
  --ip 10.10.10.10 \
  --hostname lab3 \
  alpine:latest

Testez maintenant la connectivité de lab1 (sur labnet1) vers lab3 (sur labnet2) par adresse IP :

docker exec lab1 ping -c 2 10.10.10.10

La sortie attendue montrera 100% de perte de paquets, car les deux réseaux sont isolés à moins que vous ne les connectiez explicitement. Cela démontre l'isolation des réseaux Docker : les conteneurs sur des réseaux bridge définis par l'utilisateur différents ne peuvent pas communiquer directement, même s'ils connaissent les adresses IP de l'autre.

Étape 6 : Connecter un conteneur à plusieurs réseaux

Si nécessaire, vous pouvez connecter lab1 à labnet2 également, ce qui lui permet de communiquer avec lab3. C'est un modèle courant pour les applications multi-niveaux où un conteneur doit accéder à des services sur différents réseaux.

docker network connect labnet2 lab1

Après la connexion, lab1 reçoit une adresse IP supplémentaire sur labnet2. Docker attribue automatiquement la prochaine IP disponible dans ce sous-réseau, par exemple 10.10.10.2. Vérifiez en inspectant les interfaces réseau dans lab1 :

docker exec lab1 ip addr show

Cherchez une interface (probablement eth1) avec une adresse IP dans le sous-réseau 10.10.10.0/24. Testez ensuite à nouveau le ping de lab1 vers lab3 :

docker exec lab1 ping -c 2 10.10.10.10

Maintenant, cela devrait réussir, montrant la connectivité après l'attachement au même réseau. Cela démontre comment Docker permet aux conteneurs de faire partie de plusieurs réseaux, ce qui est utile pour une communication contrôlée entre différents niveaux.

Vérification et diagnostics

Une vérification appropriée garantit que votre laboratoire se comporte comme prévu. Utilisez les commandes suivantes pour inspecter la configuration réseau et la connectivité.

Inspecter les détails du réseau

docker network inspect labnet1

Cela renvoie un objet JSON avec le sous-réseau, la passerelle, les conteneurs attachés et leurs adresses IP. Pour une vue concise, utilisez :

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

Sortie attendue :

lab1 192.168.100.10/24
lab2 192.168.100.20/24

Cela confirme les attributions d'IP.

Vérifier la résolution DNS

Depuis lab1, résolvez le nom d'hôte lab2 en utilisant nslookup (disponible via BusyBox dans Alpine) :

docker exec lab1 nslookup lab2

Sortie attendue similaire à :

Server:    127.0.0.11
Address:   127.0.0.11:53

Name:      lab2
Address:   192.168.100.20

Le serveur DNS à 127.0.0.11 est le DNS intégré de Docker, qui s'exécute dans chaque conteneur sur les réseaux définis par l'utilisateur.

Vérifier l'isolation

Vérifiez que les conteneurs sur des réseaux séparés ne peuvent pas se joindre sans connexion explicite. Depuis lab1 (s'il n'est pas connecté à labnet2), pinguez l'IP de lab3 et confirmez l'échec. Un ping réussi après la connexion démontre le changement.

Examiner les interfaces réseau des conteneurs

docker exec lab1 ip addr show

Cherchez l'interface eth0 avec l'IP attribuée. Vous pouvez également vérifier le routage :

docker exec lab1 ip route

La sortie attendue montre la passerelle par défaut via 192.168.100.1, ainsi que la route du sous-réseau.

Pièges courants et comment les éviter

Même dans un laboratoire contrôlé, certaines erreurs sont courantes. Les reconnaître tôt peut faire gagner du temps et éviter la frustration.

Piège 1 : Utiliser le réseau bridge par défaut

Beaucoup de débutants placent des conteneurs sur le réseau bridge par défaut et se demandent ensuite pourquoi la résolution DNS échoue. Le réseau bridge par défaut ne fournit pas de résolution DNS automatique entre les conteneurs ; vous devez utiliser des flags --link hérités (obsolètes) ou, mieux, créer un réseau bridge défini par l'utilisateur. Pourquoi cela arrive : Le bridge par défaut de Docker est conçu pour la rétrocompatibilité et n'a pas le serveur DNS intégré ni la découverte automatique de services que les réseaux définis par l'utilisateur offrent. Comment éviter : Créez toujours un réseau défini par l'utilisateur dédié pour vos applications. Ce laboratoire démontre l'approche correcte.

Piège 2 : Conflits d'IP statiques

Attribuer une IP statique déjà utilisée par un autre conteneur sur le même réseau provoque une erreur telle que Address already in use. Pourquoi cela arrive : Docker suit les allocations d'IP dans sa base de données IPAM (IP Address Management), et chaque IP sur un sous-réseau doit être unique. Comment éviter : Avant d'attribuer une IP statique, inspectez le réseau pour voir les allocations existantes en utilisant docker network inspect. Alternativement, utilisez un sous-réseau avec suffisamment d'adresses et planifiez votre schéma d'IP. Si un conflit survient, choisissez une IP différente ou supprimez le conteneur en conflit.

Piège 3 : Oublier de connecter un conteneur au deuxième réseau

Lors du test de connectivité multi-réseaux, il est facile d'oublier qu'un conteneur n'est pas automatiquement attaché à tous les réseaux. Le ping entre réseaux échouera jusqu'à ce que vous connectiez explicitement le conteneur. Pourquoi cela arrive : Les réseaux Docker sont isolés par défaut, et les conteneurs ne rejoignent que les réseaux auxquels ils sont explicitement connectés. Comment éviter : Vérifiez toujours l'appartenance au réseau avec docker network inspect avant d'espérer une communication inter-réseaux. Si nécessaire, utilisez docker network connect comme montré à l'étape 6.

Piège 4 : Mal interpréter les échecs de résolution DNS

Si ping lab2 renvoie Name or service not known, il est tentant de penser que le DNS de Docker est cassé. Pourquoi cela arrive : Habituellement, les conteneurs sont sur le réseau bridge par défaut, ou le nom du conteneur est mal orthographié, ou les conteneurs sont sur des réseaux définis par l'utilisateur différents. Comment éviter : Vérifiez l'appartenance au réseau des deux conteneurs avec docker network inspect. Assurez-vous qu'ils sont sur le même réseau défini par l'utilisateur. Sinon, connectez-les ou créez un nouveau réseau et attachez les deux.

Piège 5 : Laisser les conteneurs et réseaux de test en cours d'exécution

Après avoir expérimenté, vous pouvez oublier de nettoyer, laissant des conteneurs et réseaux orphelins qui consomment des ressources et encombrent votre environnement. Pourquoi cela arrive : Il est facile de passer à la tâche suivante sans supprimer les ressources du laboratoire. Comment éviter : Adoptez une habitude de démonter le laboratoire lorsque vous avez terminé, comme décrit dans la section de nettoyage ci-dessous. Vous pouvez également utiliser des étiquettes ou des conventions de nommage pour identifier facilement les ressources du laboratoire.

Modes de défaillance et récupération

Comprendre les modes de défaillance courants vous aide à récupérer rapidement et à garder votre laboratoire productif.

Conflit d'adresse IP

Si vous tentez d'attribuer une IP statique déjà utilisée, Docker renvoie une erreur comme :

Error response from daemon: Address already in use

Récupération : Choisissez une IP différente ou inspectez les allocations existantes avec docker network inspect labnet1 pour trouver le conflit. Supprimez le conteneur en conflit si nécessaire et réessayez.

Le conteneur ne peut pas résoudre les noms DNS

Si la résolution DNS échoue (par exemple, ping lab2 donne Name or service not known), vérifiez si les conteneurs sont sur le même réseau défini par l'utilisateur. La résolution DNS ne fonctionne que sur les réseaux définis par l'utilisateur, pas sur le bridge par défaut. Vérifiez avec docker network inspect et assurez-vous que les deux conteneurs sont attachés.

Récupération : Connectez les deux conteneurs au même réseau défini par l'utilisateur en utilisant docker network connect.

L'isolation réseau se brise de manière inattendue

Si des conteneurs qui devraient être isolés peuvent soudainement communiquer, vérifiez s'ils sont connectés à un réseau commun (par exemple, tous deux attachés au même bridge). Utilisez docker network inspect pour examiner les connexions.

Récupération : Déconnectez la connexion réseau non intentionnelle avec docker network disconnect <network> <container>.

Le conteneur perd la connectivité après des modifications réseau

Modifier les paramètres réseau (par exemple, déconnecter un conteneur) peut perturber les connexions actives.

Récupération : Reconnectez le conteneur au réseau si nécessaire, ou redémarrez le conteneur avec docker restart <container> pour rétablir le réseau. Dans certains cas, recréer le conteneur peut être nécessaire.

Mauvaise configuration de la publication de port

Si vous exposez un service dans un conteneur mais ne pouvez pas l'atteindre depuis l'hôte, vous avez peut-être oublié de publier le port avec -p. Sans publication de port, le service n'est accessible que depuis d'autres conteneurs sur le même réseau.

Récupération : Relancez le conteneur avec le flag -p approprié, ou utilisez docker network connect pour permettre l'accès depuis un autre conteneur sur le même réseau sans l'exposer à l'hôte.

Stratégie de retour en arrière

Parce que le laboratoire est isolé, le retour en arrière signifie souvent supprimer les réseaux et conteneurs de test. Enregistrez vos commandes de configuration dans un script pour la reproductibilité. Pour tout démonter :

docker rm -f lab1 lab2 lab3
docker network rm labnet1 labnet2

Vérifiez la suppression avec docker network ls et docker ps -a.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour exécuter le laboratoire de manière fiable et l'étendre en toute sécurité. Chaque étape comprend une commande ou une vérification et le résultat attendu. Pour chaque action majeure, attribuez un responsable (vous-même dans un laboratoire personnel, ou un membre spécifique de l'équipe dans un environnement partagé) et examinez les résultats avant de continuer. Dans un contexte d'équipe, revisitez la configuration du laboratoire mensuellement pour vous assurer qu'elle répond toujours aux besoins actuels et qu'aucun conflit n'est survenu.

Répétez ces étapes selon les besoins pour les expériences. Documentez toutes les variations et leurs résultats pour référence future. Tenir un journal de laboratoire vous aide à suivre ce que vous avez testé et les résultats, ce qui facilite la reproduction ou le partage des résultats avec votre équipe.

Conclusion

Un laboratoire de réseau Docker local offre un environnement sûr et reproductible pour apprendre et tester les configurations réseau. Dans ce guide, nous avons créé des réseaux bridge isolés, déployé des conteneurs avec des IP statiques et des noms d'hôte, vérifié la connectivité et le DNS, démontré l'isolation réseau et discuté des modes de défaillance courants avec des étapes de récupération. En suivant la liste de contrôle des opérations et en évitant les pièges décrits, vous pouvez étendre le laboratoire pour tester des scénarios plus complexes tels que les réseaux overlay, les politiques réseau ou les configurations multi-hôtes.

Commencez par un réseau pilote étroit, inspectez le comportement localement, puis appliquez les changements vérifiés à vos environnements de développement ou de production en toute confiance. Les compétences que vous acquérez dans ce laboratoire se transféreront directement aux déploiements Docker réels, vous aidant à dépanner les problèmes de réseau plus rapidement et à concevoir des architectures de conteneurs plus robustes.