Réseaux Docker : Bridge, Host, Overlay et plus

Les conteneurs Docker sont isolés par défaut : ils ne peuvent pas communiquer entre eux ni avec l’extérieur sans configuration réseau. Docker propose 6 types de réseaux pour répondre à tous les scénarios : du développement local à la production distribuée. Ce guide vous apprend à choisir le bon réseau, à connecter vos conteneurs de manière sécurisée et à éviter les erreurs courantes.

Ce que vous allez apprendre

• Bridge : le réseau par défaut, idéal pour connecter des conteneurs sur un même hôte
• Host : performances maximales en partageant le réseau de l’hôte
• Overlay : communication entre conteneurs sur différents serveurs (Swarm/Kubernetes)
• Macvlan/Ipvlan : intégration directe au réseau physique (applications legacy)
• None : isolation totale pour les cas spéciaux de sécurité
• Bonnes pratiques : sécurité, dépannage et optimisation réseau

Prérequis : Avoir lu le guide Docker : Guide Complet pour comprendre les bases des conteneurs.

Vue d’ensemble des types de réseaux

Docker propose 6 drivers réseau natifs, chacun adapté à un cas d’usage spécifique. Le choix du bon réseau impacte directement la sécurité, les performances et la facilité de maintenance de vos applications conteneurisées.

Tableau comparatif des réseaux Docker

Type	Isolation	Performance	Multi-hôtes	Cas d’usage principal
Bridge	✅ Bonne	Bonne	❌ Non	Développement, apps multi-conteneurs
Host	❌ Aucune	⚡ Maximale	❌ Non	Performance critique, monitoring
Overlay	✅ Bonne	Bonne	✅ Oui	Production distribuée, Swarm
Macvlan	✅ Excellente	⚡ Très bonne	❌ Non	Applications legacy, intégration réseau physique
Ipvlan	✅ Excellente	⚡ Très bonne	❌ Non	Environnements avec restrictions MAC
None	🔒 Totale	N/A	❌ Non	Sécurité maximale, jobs batch

Glissez pour voir

Règle d'or pour choisir

• Développement local → Bridge (par défaut)
• Production mono-hôte → Bridge personnalisé
• Production multi-hôtes → Overlay
• Performance critique → Host (avec précautions)
• Intégration réseau existant → Macvlan/Ipvlan

Commandes essentielles

Avant de plonger dans chaque type, voici les commandes de base pour gérer les réseaux Docker :

# Lister tous les réseaux
docker network ls

# Créer un réseau personnalisé
docker network create mon_reseau

# Inspecter un réseau (voir les conteneurs connectés, subnet, etc.)
docker network inspect mon_reseau

# Connecter un conteneur existant à un réseau
docker network connect mon_reseau mon_conteneur

# Déconnecter un conteneur d'un réseau
docker network disconnect mon_reseau mon_conteneur

# Supprimer un réseau
docker network rm mon_reseau

# Nettoyer les réseaux inutilisés
docker network prune

Le réseau Bridge : la fondation

Le réseau bridge est le réseau par défaut de Docker. Quand vous lancez un conteneur sans spécifier de réseau, il rejoint automatiquement le bridge par défaut (docker0). Ce type de réseau crée un réseau privé interne à votre machine, où les conteneurs peuvent communiquer entre eux.

Analogie : Un réseau bridge, c’est comme un switch réseau virtuel installé sur votre machine. Chaque conteneur connecté reçoit une adresse IP privée et peut parler aux autres conteneurs du même switch.

Architecture du réseau Bridge

Le bridge Docker fonctionne ainsi :

1. Docker crée un bridge virtuel (docker0 par défaut) avec une plage d’adresses IP (ex: 172.17.0.0/16)
2. Chaque conteneur reçoit une interface virtuelle eth0 connectée au bridge
3. Les conteneurs communiquent entre eux via leurs adresses IP privées
4. Pour sortir vers Internet, le trafic passe par des règles NAT (iptables)

Bridge par défaut vs Bridge personnalisé

Docker crée automatiquement un bridge nommé bridge (ou docker0), mais il est fortement recommandé de créer des bridges personnalisés pour vos applications.

Fonctionnalité	Bridge par défaut	Bridge personnalisé
Résolution DNS	❌ Par IP uniquement	✅ Par nom de conteneur
Isolation	❌ Tous les conteneurs	✅ Seulement ceux connectés
Configuration	❌ Limitée	✅ Subnet, gateway, options

Glissez pour voir

N'utilisez pas le bridge par défaut en production

Le bridge par défaut (docker0) ne permet pas la résolution DNS par nom. Vous devez utiliser les adresses IP, ce qui rend votre configuration fragile. Créez toujours un bridge personnalisé pour vos applications.

Créer un réseau bridge personnalisé

Pour créer un réseau bridge personnalisé, utilisez la commande docker network create :

# Création d'un bridge personnalisé
docker network create --driver bridge mon_reseau

# Vérification
docker network ls

Résolution DNS automatique

Sur un bridge personnalisé, Docker embarque un serveur DNS interne (127.0.0.11). Les conteneurs peuvent se joindre par leur nom au lieu d’utiliser des adresses IP. C’est l’avantage majeur par rapport au bridge par défaut.

Connecter un conteneur à un réseau

Un conteneur peut être attaché à plusieurs réseaux simultanément :

# Connecter un conteneur existant à un réseau
docker network connect mon_reseau mon_conteneur

# Vérifier les réseaux d'un conteneur
docker inspect mon_conteneur --format '{{json .NetworkSettings.Networks}}'

Exemple pratique : application web + base de données

Imaginons une application web qui doit communiquer avec une base de données PostgreSQL. Voici comment configurer le réseau :

1. Créez un réseau dédié à l’application

   docker network create --driver bridge app_network

2. Lancez la base de données sur ce réseau

   docker run -d \
     --name db \
     --network app_network \
     -e POSTGRES_PASSWORD=secret \
     postgres:15

3. Lancez l’application web sur le même réseau

   docker run -d \
     --name webapp \
     --network app_network \
     -p 8080:80 \
     -e DATABASE_HOST=db \
     mon_app_web

4. Vérifiez la communication

   # Depuis le conteneur webapp, pingez la DB par son nom
   docker exec webapp ping -c 3 db

Dans cet exemple, l’application web peut se connecter à PostgreSQL en utilisant simplement db comme hostname, grâce à la résolution DNS automatique du bridge personnalisé.

Paramètres avancés du bridge

Lors de la création d’un bridge, vous pouvez personnaliser plusieurs aspects :

# Bridge avec subnet et gateway personnalisés
docker network create \
  --driver bridge \
  --subnet 10.10.0.0/24 \
  --gateway 10.10.0.1 \
  mon_reseau

# Désactiver la communication inter-conteneurs (isolation stricte)
docker network create \
  --driver bridge \
  --opt com.docker.network.bridge.enable_icc=false \
  reseau_isole

# Attribuer une IP fixe à un conteneur
docker run -d \
  --network mon_reseau \
  --ip 10.10.0.100 \
  nginx

Option	Description
--subnet	Plage d’adresses IP du réseau (ex: 10.10.0.0/24)
--gateway	Passerelle par défaut du réseau
--ip-range	Sous-plage pour l’attribution automatique d’IP
enable_icc=false	Empêche les conteneurs de communiquer entre eux
enable_ip_masquerade	Active/désactive le NAT pour l’accès Internet

Glissez pour voir

Bonne pratique : un réseau par application

Créez un réseau bridge par application ou stack. Cela isole les conteneurs de différentes applications et simplifie le debugging. Par exemple : frontend_network, backend_network, monitoring_network.

Le réseau Host : performances maximales

Le réseau host supprime complètement l’isolation réseau entre le conteneur et la machine hôte. Le conteneur partage directement l’interface réseau de l’hôte, sans aucune couche de virtualisation.

Analogie : Si le bridge est un switch virtuel, le mode host c’est comme brancher directement votre conteneur sur la carte réseau de la machine. Aucun intermédiaire, aucune traduction d’adresses.

Quand utiliser le mode Host ?

Le mode host est réservé à des cas spécifiques où les performances réseau sont critiques :

Cas d’usage	Pourquoi host ?
Monitoring réseau	Accès direct aux interfaces pour capturer le trafic
Applications à faible latence	Élimination du NAT (~0.5ms de gain)
Serveurs de jeux	Latence minimale pour les connexions UDP
Outils de diagnostic	Accès aux mêmes ports que l’hôte

Glissez pour voir

Exemple d’utilisation

# Lancer un conteneur en mode host
docker run --network host nginx

# Vérifier : le conteneur utilise l'IP de l'hôte
docker exec mon_conteneur hostname -I
# Affiche l'adresse IP de la machine hôte

Risques de sécurité

Le mode host expose tous les ports du conteneur directement sur l’hôte. Un conteneur compromis pourrait accéder aux ressources réseau de l’hôte. N’utilisez ce mode que si vous avez une raison valable et que vous comprenez les implications.

Limitations du mode Host

• Pas de port mapping (-p n’a aucun effet) : le conteneur utilise directement les ports de l’hôte
• Conflits de ports : si deux conteneurs utilisent le même port, le second échouera
• Pas d’isolation réseau : le conteneur voit tout le réseau de l’hôte
• Non disponible sur Docker Desktop (macOS/Windows) : fonctionne uniquement sur Linux natif

Le réseau Overlay : multi-hôtes distribué

Le réseau overlay permet aux conteneurs de communiquer à travers plusieurs machines physiques. C’est la solution native de Docker pour les architectures distribuées, indispensable avec Docker Swarm ou dans des environnements de production multi-serveurs.

Analogie : Un overlay, c’est comme un VPN privé entre vos serveurs Docker. Les conteneurs pensent être sur le même réseau local, même s’ils sont physiquement sur des machines différentes.

Architecture Overlay

Le réseau overlay fonctionne grâce à :

1. VXLAN : encapsulation du trafic conteneur dans des paquets UDP
2. Chiffrement IPsec (optionnel) : sécurisation du trafic entre nœuds
3. DNS distribué : résolution des noms de conteneurs sur tous les nœuds

Prérequis pour Overlay

Le réseau overlay nécessite l’un de ces contextes :

• Docker Swarm initialisé (recommandé)
• Cluster Kubernetes avec le plugin CNI approprié
• Docker en mode standalone avec un key-value store externe (etcd, Consul)

Création d’un réseau Overlay avec Swarm

1. Initialisez Docker Swarm (si pas déjà fait)

   docker swarm init

2. Créez le réseau overlay

   docker network create \
     --driver overlay \
     --attachable \
     mon_overlay

   L’option --attachable permet aux conteneurs standalone (hors services Swarm) de rejoindre le réseau.

3. Déployez des services sur ce réseau

   docker service create \
     --name api \
     --network mon_overlay \
     --replicas 3 \
     mon_api:latest
   
   docker service create \
     --name db \
     --network mon_overlay \
     postgres:15

4. Vérifiez la communication inter-nœuds

   # Depuis n'importe quel réplica de l'API
   docker exec $(docker ps -q -f name=api) ping -c 3 db

Sécuriser un réseau Overlay avec chiffrement

Par défaut, le trafic overlay n’est pas chiffré. Pour les données sensibles, activez le chiffrement :

docker network create \
  --driver overlay \
  --opt encrypted \
  reseau_securise

Impact du chiffrement

Le chiffrement IPsec ajoute une surcharge CPU de ~10-15% et une légère latence. Activez-le uniquement pour les données sensibles (credentials, données personnelles). Pour le trafic interne non critique, vous pouvez le désactiver.

Paramètres avancés Overlay

Option	Description
--attachable	Permet aux conteneurs standalone de rejoindre le réseau
--encrypted	Active le chiffrement IPsec du trafic
--subnet	Définit le sous-réseau (ex: 10.0.0.0/24)
--gateway	Passerelle du réseau overlay

Glissez pour voir

Le réseau Macvlan : apparaître comme un périphérique physique

Le réseau macvlan attribue à chaque conteneur sa propre adresse MAC. Le conteneur apparaît alors comme un périphérique physique distinct sur le réseau local, avec sa propre adresse IP dans le même sous-réseau que l’hôte.

Analogie : Avec macvlan, votre conteneur obtient sa propre carte réseau virtuelle. Du point de vue du réseau, c’est comme si vous aviez branché un nouvel ordinateur sur le switch.

Cas d’usage de Macvlan

Scénario	Pourquoi Macvlan ?
Applications legacy	Nécessitent une adresse IP accessible directement depuis le réseau
Intégration entreprise	Le conteneur doit apparaître comme un serveur classique
DHCP externe	Le conteneur obtient son IP du serveur DHCP de l’entreprise
Multicast/Broadcast	Applications qui utilisent ces protocoles

Glissez pour voir

Création d’un réseau Macvlan

# Créer un réseau macvlan connecté à l'interface eth0
docker network create \
  --driver macvlan \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  -o parent=eth0 \
  mon_macvlan

# Lancer un conteneur avec une IP dans le réseau local
docker run -d \
  --network mon_macvlan \
  --ip 192.168.1.100 \
  --name serveur_web \
  nginx

Le conteneur serveur_web est maintenant accessible à l’adresse 192.168.1.100 depuis n’importe quelle machine du réseau local.

Modes de fonctionnement Macvlan

Mode	Description
bridge (défaut)	Les conteneurs communiquent entre eux et avec le réseau externe
private	Les conteneurs sont isolés les uns des autres
passthru	Un seul conteneur par interface, accès direct
VEPA	Trafic passe par un switch externe capable de hairpin

Glissez pour voir

# Macvlan en mode private (isolation entre conteneurs)
docker network create \
  --driver macvlan \
  -o macvlan_mode=private \
  -o parent=eth0 \
  --subnet 192.168.1.0/24 \
  reseau_prive

Limitation importante

Avec macvlan, le conteneur ne peut pas communiquer avec l’hôte directement. C’est une limitation du driver. Si vous avez besoin de cette communication, créez une interface macvlan secondaire sur l’hôte.

Le réseau Ipvlan : alternative à Macvlan

Le réseau ipvlan est similaire à macvlan, mais au lieu d’attribuer une adresse MAC unique à chaque conteneur, tous les conteneurs partagent l’adresse MAC de l’hôte. Seules les adresses IP sont distinctes.

Ipvlan vs Macvlan

Critère	Macvlan	Ipvlan
Adresse MAC	Unique par conteneur	Partagée (celle de l’hôte)
Restrictions réseau	Peut poser problème si limite de MAC	Aucune restriction MAC
Mode L3	Non supporté	✅ Supporté
Performance	Excellente	Excellente

Glissez pour voir

Quand choisir Ipvlan ?

• Environnements avec limites d’adresses MAC : certains switches ou hyperviseurs limitent le nombre de MAC par port
• Haute densité de conteneurs : évite l’explosion du nombre d’adresses MAC
• Mode L3 : routage au niveau IP sans broadcast ARP

Modes L2 et L3

Mode L2 (couche liaison) : les conteneurs sont sur le même segment réseau que l’hôte

docker network create \
  --driver ipvlan \
  -o ipvlan_mode=l2 \
  -o parent=eth0 \
  --subnet 192.168.1.0/24 \
  ipvlan_l2

Mode L3 (couche réseau) : routage entre sous-réseaux, pas de broadcast ARP

docker network create \
  --driver ipvlan \
  -o ipvlan_mode=l3 \
  -o parent=eth0 \
  --subnet 10.10.0.0/24 \
  ipvlan_l3

Conseil pratique

Utilisez L2 si vos conteneurs doivent être accessibles directement depuis le réseau local (comme avec macvlan). Utilisez L3 pour des architectures plus complexes avec routage entre sous-réseaux.

Le réseau None : isolation totale

Le réseau none désactive complètement l’accès réseau du conteneur. Aucune interface réseau n’est attachée (sauf loopback 127.0.0.1). Le conteneur est totalement isolé du monde extérieur.

Analogie : Un conteneur avec --network none, c’est comme un ordinateur sans carte réseau. Il peut fonctionner, mais ne peut ni envoyer ni recevoir de données sur le réseau.

Cas d’usage

Scénario	Pourquoi none ?
Jobs batch	Traitement de données sans besoin de réseau
Tests de sécurité	Vérifier qu’une application fonctionne sans réseau
Conteneurs sensibles	Empêcher toute fuite de données par le réseau
Sandbox	Exécuter du code non fiable en isolation

Glissez pour voir

Exemple d’utilisation

# Conteneur totalement isolé du réseau
docker run --network none -d --name batch_job mon_script

# Vérification : seul loopback est disponible
docker exec batch_job ip addr
# Affiche uniquement l'interface lo (127.0.0.1)

# Tentative de ping vers l'extérieur
docker exec batch_job ping -c 1 google.com
# ping: google.com: Network is unreachable

Communication sans réseau

Un conteneur en mode none peut toujours communiquer via :

• Volumes partagés : échange de fichiers avec l’hôte ou d’autres conteneurs
• Signaux Unix : via docker kill -s SIGNAL
• stdin/stdout : via docker attach ou docker exec

Dépannage réseau Docker

Problèmes courants et solutions

Symptôme	Cause probable	Solution
Conteneur ne peut pas joindre Internet	NAT/masquerade désactivé	sysctl net.ipv4.ip_forward=1
DNS ne résout pas les noms de conteneurs	Utilisation du bridge par défaut	Créer un bridge personnalisé
connection refused entre conteneurs	Conteneurs sur des réseaux différents	Connecter les deux au même réseau
Latence élevée	Overlay sans optimisation	Vérifier MTU, désactiver chiffrement si non nécessaire
Port déjà utilisé (mode host)	Conflit avec service sur l’hôte	Utiliser un autre port ou passer en bridge

Glissez pour voir

Commandes de diagnostic

# Voir les réseaux d'un conteneur
docker inspect -f '{{json .NetworkSettings.Networks}}' mon_conteneur | jq

# Tester la connectivité depuis un conteneur
docker exec mon_conteneur ping -c 3 autre_conteneur
docker exec mon_conteneur nslookup autre_conteneur

# Voir les règles iptables Docker
sudo iptables -L -n -t nat | grep -i docker

# Inspecter le bridge Docker
docker network inspect bridge

# Logs du daemon Docker (problèmes réseau)
journalctl -u docker.service | grep -i network

Outil de debug recommandé

Pour diagnostiquer des problèmes réseau complexes, lancez un conteneur avec des outils réseau :

docker run -it --network mon_reseau nicolaka/netshoot
# Contient : ping, curl, nslookup, tcpdump, netstat, iperf, etc.

Bonnes pratiques réseau

Sécurité

• Isolez les applications : un réseau bridge par stack applicative
• Limitez la communication : utilisez enable_icc=false si les conteneurs n’ont pas besoin de se parler
• Chiffrez les overlay en production pour les données sensibles
• Évitez le mode host sauf nécessité absolue de performance

Organisation

• Nommez vos réseaux de manière explicite : frontend_net, backend_net, monitoring_net
• Documentez les plages d’adresses utilisées pour éviter les conflits
• Utilisez des subnets fixes en production pour faciliter le debugging

Performance

• Bridge : idéal pour la plupart des cas (overhead minimal)
• Host : uniquement si le NAT est un goulot d’étranglement mesuré
• Overlay : ajustez le MTU si vous constatez des problèmes de fragmentation

Travaux Pratiques Docker : Passe à l’action !

Théorie, c’est bien. Pratique, c’est mieux. Pour vraiment maîtriser Docker et les réseaux de conteneurs, je mets à ta disposition une série de TP concrets prêts à l’emploi sur mon dépôt GitHub.

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

📝 7 questions

⏱️ 5 min.

🎯 80%

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

▶ Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

Les 8 points clés des réseaux Docker

1. Bridge : réseau par défaut, idéal pour le développement et les apps multi-conteneurs sur un même hôte

2. Bridge personnalisé : toujours préférer au bridge par défaut pour avoir la résolution DNS par nom

3. Host : performances maximales mais aucune isolation, réservé aux cas spécifiques (monitoring, faible latence)

4. Overlay : indispensable pour les environnements multi-hôtes (Swarm, production distribuée)

5. Macvlan/Ipvlan : intégration au réseau physique, utile pour les applications legacy ou l’intégration entreprise

6. None : isolation totale, pour les jobs batch ou les tests de sécurité

7. Commandes essentielles : docker network create, docker network connect, docker network inspect

8. Bonnes pratiques : un réseau par application, nommage explicite, chiffrement overlay en production

Prochaines étapes

Volumes Docker Persistez vos données avec les volumes standards, bind mounts et tmpfs

Docker Compose Orchestrez vos conteneurs et réseaux dans un fichier YAML

Docker Swarm Déployez des applications distribuées avec overlay networks

Sécuriser Docker Bonnes pratiques de sécurité pour vos conteneurs et réseaux

×

📖 Voir la documentation →