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

Un conteneur Docker lancé sans option n'est pas isolé : il rejoint le bridge par défaut, où il joint ses voisins par adresse IP et sort vers Internet par une règle NAT. Ce qui lui manque, et qui surprend, c'est la résolution par nom. Docker propose 6 drivers réseau, du poste de développement à la production distribuée. Ce guide vous apprend à choisir le bon, à mesurer ce que chacun autorise vraiment, 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.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Tableau comparatif des réseaux Docker

La colonne qui décide dans presque tous les cas est Multi-hôtes : si vos conteneurs tournent sur plusieurs machines, seul overlay répond, tous les autres drivers s'arrêtent aux frontières de l'hôte. La colonne Isolation vient ensuite : elle indique si un conteneur compromis voit uniquement ses voisins de réseau ou l'ensemble de la pile réseau de la machine. Les mentions de performance sont qualitatives : l'écart entre bridge et host reste marginal tant que vous ne saturez pas la carte réseau.

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

Ces sept commandes couvrent le cycle de vie complet d'un réseau Docker. Retenez surtout docker network inspect : c'est la seule qui affiche à la fois le subnet, la passerelle et la liste des conteneurs réellement attachés, donc le premier réflexe quand deux conteneurs ne se voient pas. Attention à docker network prune : il supprime tous les réseaux sans conteneur attaché, y compris ceux que vous venez de créer pour une stack à l'arrêt.

# 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.

Architecture du réseau Bridge

Le schéma ci-dessous montre les trois éléments qui expliquent la plupart des incidents réseau sur un poste de développement : le bridge virtuel côté hôte, la paire d'interfaces veth qui relie chaque conteneur à ce bridge, et les règles NAT qui traduisent l'adresse privée du conteneur en adresse de l'hôte pour sortir vers Internet. Regardez d'abord où passe la frontière : tout ce qui est au-dessus du bridge appartient au namespace réseau du conteneur, tout ce qui est en dessous appartient à l'hôte.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

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.

Ce que vous voulez faire	Bridge par défaut	Bridge personnalisé
Joindre un conteneur par son IP	possible	possible
Le joindre par son nom	impossible	possible, DNS interne
Sortir vers Internet	possible, par NAT	possible, par NAT
Isoler un groupe de conteneurs	impossible, tous ensemble	possible, un réseau par groupe
Choisir subnet et passerelle	non	oui

Glissez pour voir

Vérifier ce comportement plutôt que le croire

Trois commandes suffisent, et elles corrigent l'idée reçue la plus répandue sur Docker. Lancez deux conteneurs sans préciser de réseau, puis mesurez.

docker run -d --name a alpine:3.22 sleep 300
docker run -d --name b alpine:3.22 sleep 300

IP_B=$(docker inspect -f '{{.NetworkSettings.Networks.bridge.IPAddress}}' b)
docker exec a ping -c2 "$IP_B"     # joint par IP    : OUI
docker exec a ping -c2 b           # joint par nom   : NON
docker exec a ping -c2 9.9.9.9     # sort par NAT    : OUI

Sur Docker Engine 29.1.3, la première et la troisième réussissent, la deuxième échoue. L'isolation supposée du bridge par défaut n'existe pas : ce qui manque est le DNS, pas le cloisonnement.

Le bridge par défaut ne cloisonne rien

Son défaut n'est pas l'absence de résolution par nom, qui se contourne avec une adresse IP. Son défaut est que tous vos conteneurs y atterrissent ensemble, et s'y joignent librement : l'option com.docker.network.bridge.enable_icc y vaut true, ce que docker network inspect bridge affiche. Un bridge personnalisé par application est ce qui sépare réellement deux piles qui n'ont rien à se dire.

L'isolation entre deux réseaux personnalisés, elle, est réelle : un conteneur de l'un ne joint pas l'adresse d'un conteneur de l'autre, ce qui se vérifie de la même façon en quelques secondes.

Créer un réseau bridge personnalisé

La commande docker network create utilise le driver bridge par défaut, --driver bridge est donc redondant ici mais rend l'intention explicite dans un script. Sans option de subnet, Docker choisit lui-même une plage libre dans 172.16.0.0/12. Vérifiez le résultat avec docker network ls : le nouveau réseau doit apparaître avec le scope local et un identifiant court de 12 caractères.

# 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, ce qui sert à publier un service sur un réseau frontal tout en gardant l'accès à une base de données sur un réseau privé. Chaque rattachement ajoute une interface dans le conteneur et une entrée DNS supplémentaire. La sortie de docker inspect ci-dessous est un objet JSON indexé par nom de réseau : c'est là que vous lisez l'adresse IP attribuée sur chacun, et donc que vous confirmez qu'un conteneur qui « ne répond pas » n'est tout simplement pas sur le bon réseau.

# 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

Ces options servent surtout à deux besoins : éviter les collisions de plages IP avec le réseau de l'entreprise, et durcir l'isolation entre conteneurs. Le point important à retenir : --ip ne fonctionne que sur un réseau personnalisé. Sur le bridge par défaut, le démon refuse la demande avec user specified IP address is supported on user defined networks only. Le tableau qui suit distingue les drapeaux de la commande (--subnet, --gateway, --ip-range) des options de driver passées avec -o ou --opt (enable_icc, enable_ip_masquerade) : ce ne sont pas les mêmes préfixes et c'est une source d'erreur fréquente.

# 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.

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	Suppression de la traduction d'adresses et du passage par le bridge
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

Le seul cas vraiment incontournable est le premier : un agent qui doit voir les interfaces physiques de la machine, comme une sonde de capture de trafic, ne peut pas travailler depuis un namespace réseau isolé. Pour les trois autres, mesurez avant de basculer : le gain de latence dépend de votre charge et le mode host vous fait perdre toute isolation, ce qui n'est jamais un bon échange sans chiffre à l'appui.

Exemple d'utilisation

Le mode host se demande à l'exécution avec --network host, aucune configuration préalable n'est nécessaire. La vérification qui compte est la deuxième commande : hostname -I doit renvoyer exactement les adresses de la machine hôte, et non une adresse en 172.x. Si vous voyez une adresse privée Docker, c'est que le conteneur est resté sur un bridge.

# Lancer un conteneur en mode host
docker run -d --name proxy_host --network host nginx:1.29

# Vérifier : le conteneur utilise l'IP de l'hôte
docker exec proxy_host 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

Ces limitations ne sont pas des détails de configuration : elles changent la façon dont vous déployez. La deuxième est celle qui surprend le plus en production, parce qu'elle transforme un simple redémarrage en conflit de port silencieux quand le service de l'hôte occupe déjà l'écoute. Vérifiez toujours avec ss -tlnp avant de basculer un conteneur en mode host.

• Pas de publication de ports (-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
• Support partiel hors Linux natif : Docker Desktop 4.34 et versions ultérieures propose le réseau host, mais uniquement pour des conteneurs Linux, après activation dans les réglages, et sans les protocoles situés sous TCP/UDP

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.

Architecture Overlay

Ce schéma répond à une question précise : comment deux conteneurs qui ne partagent aucun câble se retrouvent sur le même sous-réseau logique. La réponse tient dans le tunnel VXLAN dessiné entre les nœuds, qui emballe les trames des conteneurs dans des paquets UDP routés normalement par votre réseau physique. Conséquence pratique visible sur le schéma : chaque nœud doit pouvoir joindre les autres sur le port 4789/UDP, sinon le réseau se crée sans erreur mais aucun trafic ne passe.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

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 driver overlay de Docker Engine n'existe que dans le mode Swarm. C'est un point à vérifier avant toute autre chose : sur un démon Docker isolé, docker network create --driver overlay échoue, et le contournement historique par magasin clé-valeur externe n'est plus une option. Côté pare-feu, prévoyez d'ouvrir les ports entre les nœuds avant les tests, faute de quoi la création réussira sans que le trafic ne circule.

• Docker Swarm initialisé : docker swarm init sur le premier nœud, docker swarm join sur les autres
• Ports ouverts entre nœuds : 2377/TCP pour la gestion du cluster, 7946/TCP et 7946/UDP pour la découverte, 4789/UDP pour le trafic overlay
• Kubernetes n'utilise pas ce driver : un cluster Kubernetes passe par un plugin CNI (Calico, Cilium, Flannel) qui remplace entièrement la couche réseau de Docker

Le magasin clé-valeur externe n'existe plus

Beaucoup de tutoriels décrivent encore un overlay bâti sur etcd ou Consul avec les options --cluster-store et --cluster-advertise du démon. Cette approche, liée au Swarm « classique », a été dépréciée en Docker 20.10 puis retirée en Docker 23.0. Sur une version actuelle, ces options ne sont plus reconnues.

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

La séquence ci-dessous se déroule entièrement sur le nœud manager : c'est lui qui propage la définition du réseau vers les autres nœuds. Un détail à ne pas manquer, un réseau overlay créé sans --attachable reste invisible depuis docker run et n'accepte que des services Swarm, ce qui donne un message network not manually attachable déroutant lors des premiers essais.

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

La documentation Docker annonce une pénalité de performance non négligeable sans avancer de chiffre : elle dépend du processeur et du volume de trafic, donc mesurez sur votre plateforme avant la mise en production. Deux contraintes s'ajoutent : le chiffrement du réseau overlay n'est pas supporté sur Windows, et le protocole IP 50 (IPsec ESP) doit être autorisé entre les nœuds en plus des ports Swarm habituels.

Paramètres avancés Overlay

Ces quatre paramètres se posent à la création du réseau et ne se modifient pas ensuite : changer le sous-réseau d'un overlay impose de le recréer, donc de recréer les services qui l'utilisent. Notez la différence de syntaxe entre les drapeaux propres à la commande et l'option de driver du chiffrement, passée par --opt : c'est l'erreur la plus courante sur cette section.

Option	Description
--attachable	Permet aux conteneurs standalone de rejoindre le réseau
--opt encrypted	Active le chiffrement IPsec du trafic (option de driver, pas de drapeau --encrypted)
--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.

Cas d'usage de Macvlan

Le dénominateur commun de ces quatre scénarios : l'application refuse de fonctionner derrière une traduction d'adresses. Un logiciel de supervision qui découvre ses équipements par broadcast, un serveur qui doit apparaître dans l'inventaire réseau avec sa propre adresse, un client DHCP intégré, tous cassent dès qu'un NAT s'interpose. Si votre application accepte un simple port publié, restez sur un bridge : macvlan demande une coordination avec l'équipe réseau que le bridge évite.

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

Trois valeurs doivent correspondre au réseau physique réel, pas à un plan d'adressage inventé : le --subnet, la --gateway et l'interface parent. Relevez-les avec ip route et ip -br link sur l'hôte avant de lancer la commande, en remplaçant eth0 par le nom réel de votre carte, souvent enp0s3 ou ens18 sur les distributions récentes. Réservez également une plage d'adresses hors du périmètre DHCP avec --ip-range, sinon le serveur DHCP de l'entreprise finira par attribuer une adresse déjà prise par un conteneur.

# 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

Dans la quasi-totalité des déploiements, vous garderez le mode bridge par défaut et ne toucherez pas à cette option. Les trois autres répondent à des contraintes de commutateur : private et VEPA existent pour forcer le trafic entre conteneurs à repasser par l'équipement réseau, donc à être filtré et journalisé par lui. Le mode se choisit à la création avec l'option de driver -o macvlan_mode=, il n'est pas modifiable ensuite.

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

La ligne décisive de ce tableau est la première. Une adresse MAC unique par conteneur est ce qui pose problème dans deux environnements très répandus : les commutateurs configurés avec du port security, qui coupent le port au-delà d'un certain nombre d'adresses, et les hyperviseurs qui n'autorisent pas le mode promiscuous sur une carte virtuelle. Dans ces deux cas, ipvlan passe là où macvlan est bloqué, pour un fonctionnement par ailleurs équivalent.

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 ?

Le signal le plus fiable est un incident, pas une préférence de conception : si votre port de commutateur se désactive ou si vos conteneurs macvlan deviennent injoignables au-delà de quelques instances, vous êtes dans le premier cas ci-dessous. Le troisième point, le mode L3, relève d'un choix d'architecture assumé et suppose que vos routeurs connaissent la route vers le sous-réseau des conteneurs.

• 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

Ipvlan propose deux façons de raccorder les conteneurs, et la différence porte sur qui gère l'accessibilité. En L2, l'hôte répond aux requêtes ARP et vos conteneurs se comportent comme des machines du réseau local, sans configuration côté routeur. En L3, l'hôte devient un routeur pour un sous-réseau qui lui est propre : plus aucun broadcast ne sort, mais vos équipements réseau doivent connaître la route statique vers ce sous-réseau, sinon les réponses ne reviendront jamais.

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.

Cas d'usage

Le point commun de ces situations est que l'absence de réseau est une garantie recherchée, pas une contrainte subie. Le mode none ferme la sortie de données par le réseau au niveau du noyau et non par une règle de pare-feu : il n'y a pas d'interface à contourner. C'est ce qui en fait une réponse solide pour exécuter un traitement sur des données confidentielles ou un binaire dont vous n'avez pas la source.

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

Deux vérifications suffisent à confirmer l'isolation. La première liste les interfaces : seule lo doit apparaître, aucune eth0. La seconde tente une sortie, et le message d'erreur diffère selon la cible : viser un nom de domaine échoue dès la résolution DNS, viser une adresse IP échoue plus loin, au moment de l'émission, faute de route. Les deux confirment l'isolation, mais seul le test par adresse IP prouve qu'aucune route ne sort du conteneur.

# Conteneur totalement isolé du réseau
docker run --network none -d --name batch_job alpine:3.21 sleep 600

# Vérification : seul loopback est disponible
docker exec batch_job ip addr
# 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 ...
#     inet 127.0.0.1/8 scope host lo

# Tentative de sortie par nom : la résolution DNS échoue
docker exec batch_job ping -c 1 google.com
# ping: bad address 'google.com'

# Tentative de sortie par adresse IP : aucune route disponible
docker exec batch_job ping -c 1 1.1.1.1
# ping: sendto: Network 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

Lisez ce tableau de gauche à droite en partant du symptôme observé, pas de la cause supposée. Les deux premières lignes couvrent l'écrasante majorité des tickets sur un poste de développement : le transfert IP désactivé sur l'hôte, souvent par un durcissement système ou un VPN d'entreprise, et l'usage du bridge par défaut qui prive vos conteneurs de la résolution par nom. Avant d'appliquer une solution, confirmez la cause avec les commandes de diagnostic qui suivent : appliquer un correctif au hasard masque le vrai problème.

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

Prenez ces commandes dans l'ordre : elles vont du plus proche du conteneur au plus proche du système. La première dit sur quels réseaux se trouve réellement le conteneur, ce qui règle la moitié des cas. Si les deux conteneurs partagent bien un réseau, nslookup sépare un problème de résolution de noms d'un problème de routage. Les règles iptables et les journaux du démon ne servent qu'ensuite, quand le conteneur ne sort pas vers Internet alors que la communication interne fonctionne.

# 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

Ces trois familles de règles se hiérarchisent : la sécurité d'abord, parce qu'un réseau mal cloisonné se corrige difficilement une fois la production lancée, l'organisation ensuite, parce qu'elle conditionne votre capacité à diagnostiquer, la performance en dernier, parce qu'elle ne devient un sujet qu'avec des mesures à l'appui.

Sécurité

Le principe qui gouverne les quatre points ci-dessous est le moindre privilège appliqué au réseau : un conteneur ne doit pouvoir joindre que ce dont il a besoin. Le gain concret est mesurable lors d'une compromission, un conteneur frontal piraté ne doit pas pouvoir balayer la base de données d'une autre stack. Commencez par le premier point, il apporte à lui seul l'essentiel du cloisonnement pour un coût de mise en place nul.

• 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

Ces conventions coûtent quelques minutes à la création et font gagner des heures au premier incident. La plus rentable est la troisième : un subnet fixe rend vos adresses de conteneurs prévisibles entre deux redémarrages, donc utilisables dans une règle de pare-feu ou un tableau de bord. Sans elle, Docker réattribue les plages dans l'ordre de création et vos références deviennent fausses après un docker network prune.

• 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

Le message principal de cette section est de ne rien changer sans mesure. Le surcoût du bridge reste invisible pour une application web classique, et basculer en mode host « pour aller plus vite » revient à sacrifier l'isolation sans preuve de gain. Le seul réglage qui se justifie souvent est le troisième : sur un réseau overlay, l'encapsulation VXLAN consomme des octets dans chaque paquet, ce qui provoque des blocages sur les gros transferts si le MTU n'est pas ajusté.

• 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.

À 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

Testez vos connaissances

Ce questionnaire porte sur les points où les erreurs coûtent le plus cher : le choix du driver selon la topologie, la différence entre bridge par défaut et bridge personnalisé, et les conditions d'usage du réseau overlay. Comptez cinq minutes, le seuil de réussite est fixé à 80 %.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

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

×

📖 Voir la documentation →