DCNANetwork Drivers

Network Drivers

Les drivers réseau définissent COMMENT les containers communiquent. Choisir le mauvais driver, c'est soit avoir des performances dégradées, soit une sécurité insuffisante, soit une configuration qui ne fonctionnera pas du tout dans ton cas d'usage.

Vue d'ensemble

Driver	Scope	Cas d'usage	Isolation
`bridge`	Single host	Apps multi-containers sur un même host	Oui (NAT)
`host`	Single host	Performance maximale, accès aux ports directs	Non
`overlay`	Multi-host	Clusters Swarm, containers sur plusieurs machines	Oui
`macvlan`	Single host	Container visible comme device physique sur le LAN	MAC propre
`ipvlan`	Single host	Environ à MAC limité (switch, VM)	IP propre
`none`	Single host	Container sans réseau (jobs batch, sandboxing)	Totale

Bridge : le driver par défaut

Comment ça marche

Un bridge Linux (docker0 ou un bridge custom) relie les containers d'un même host. Chaque container obtient une IP privée dans le subnet du bridge, et le trafic vers l'extérieur passe par NAT.

Container A ──veth──┐
Container B ──veth──┤ docker0 (172.17.0.1)
Container C ──veth──┘       │
                            NAT
                            │
                        eth0 hôte → Internet

Bridge par défaut vs User-defined bridge

Il y a une distinction cruciale à comprendre :

# Bridge par défaut (docker0) — comportement limité
docker run -d --name c1 nginx
docker run -d --name c2 nginx
docker exec c2 ping c1            # ÉCHEC — pas de DNS !
docker exec c2 ping 172.17.0.2    # OK — par IP seulement

# User-defined bridge — la bonne pratique
docker network create app-net
docker run -d --name c1 --network app-net nginx
docker run -d --name c2 --network app-net nginx
docker exec c2 ping c1            # OK — DNS automatique

Différences importantes :

	Bridge par défaut	User-defined bridge
DNS par nom de container	Non	Oui
Isolation entre bridges	Oui	Oui
`--link` legacy	Possible	Inutile
Connexion à chaud	Non	Oui

# Connexion à chaud (possible uniquement sur user-defined)
docker network connect app-net existing-container
docker network disconnect app-net existing-container

Créer un bridge personnalisé

docker network create \
  --driver bridge \
  --subnet 172.28.0.0/16 \
  --ip-range 172.28.5.0/24 \
  --gateway 172.28.5.254 \
  --opt com.docker.network.bridge.name=my-bridge0 \
  my-custom-bridge

# Voir le bridge créé sur l'hôte
ip link show my-bridge0

Host : partager le réseau de l'hôte

Comment ça marche

Le container n'a pas de namespace réseau séparé — il utilise directement la pile réseau de la machine hôte. Pas de veth, pas de bridge, pas de NAT.

docker run --rm --network host nginx
# nginx écoute directement sur le port 80 de l'hôte
# pas besoin de -p 80:80 — le port EST celui de l'hôte

Quand l'utiliser

Performance maximale (pas d'overhead NAT/bridge)
Container qui doit écouter sur plusieurs ports dynamiques
Outils de monitoring qui observent les interfaces réseau de l'hôte
Cas où le container a besoin de raw sockets

Quand l'éviter

# Problème : deux containers en mode host ne peuvent pas écouter sur le même port
docker run -d --network host nginx     # port 80 OK
docker run -d --network host apache    # ERREUR : port 80 déjà pris !

Le mode host casse l'isolation — n'utilise pas en production sauf si tu sais ce que tu fais.

Sous macOS/Windows, le mode host ne fonctionne pas comme sous Linux — Docker tourne dans une VM Linux, donc host partage le réseau de la VM, pas de ta machine.

None : isolation totale

docker run --rm --network none alpine
# Seul lo (loopback) existe — aucun accès réseau
ip addr show
# 1: lo: <LOOPBACK,UP,LOWER_UP> inet 127.0.0.1/8

Cas d'usage :

Jobs de traitement de données qui n'ont pas besoin d'internet
Sandboxing d'applications non fiables
Containers qui injectent leur propre interface réseau (ex: service mesh sidecars)

Macvlan : le container comme device physique

Comment ça marche

Docker crée une interface macvlan sur une interface physique de l'hôte. Chaque container obtient sa propre adresse MAC et apparaît comme un device physique distinct sur le réseau local.

Switch réseau
    │
eth0 (hôte) ──┬── macvlan0 → Container A (MAC: 02:42:ac:11:00:02, IP: 192.168.1.100)
              └── macvlan1 → Container B (MAC: 02:42:ac:11:00:03, IP: 192.168.1.101)

docker network create \
  --driver macvlan \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  -o parent=eth0 \
  macvlan-net

docker run -d --network macvlan-net --ip 192.168.1.100 nginx
# Maintenant visible sur le LAN comme une machine physique à 192.168.1.100

La limitation hôte ↔ container

Par défaut, l'hôte ne peut pas communiquer avec ses containers macvlan (limitation du noyau Linux). Pour contourner :

# Créer une sous-interface macvlan sur l'hôte
ip link add macvlan-shim link eth0 type macvlan mode bridge
ip addr add 192.168.1.200/24 dev macvlan-shim
ip link set macvlan-shim up

Cas d'usage macvlan : containers qui doivent avoir une IP statique sur le réseau LAN (appareils IoT, services réseau, monitoring physique).

IPvlan : quand le switch limite les MACs

Différence avec macvlan

Macvlan = un MAC par container. IPvlan = tous les containers partagent le MAC de l'hôte, mais ont des IPs différentes. Utile quand le switch réseau limite le nombre de MACs par port (virtualisation, certains switches managés).

Mode L2 vs L3

# Mode L2 — fonctionne comme macvlan mais avec MAC partagé
docker network create \
  --driver ipvlan \
  --subnet 192.168.1.0/24 \
  -o parent=eth0 \
  -o ipvlan_mode=l2 \
  ipvlan-l2

# Mode L3 — l'hôte agit comme routeur, pas d'ARP broadcast
docker network create \
  --driver ipvlan \
  --subnet 10.10.10.0/24 \
  -o parent=eth0 \
  -o ipvlan_mode=l3 \
  ipvlan-l3

Mode L3 : chaque réseau ipvlan est complètement routé. Pas de broadcast ARP, meilleure scalabilité. L'hôte route le trafic entre les containers et l'extérieur.

Overlay : multi-host (voir chapitre dédié)

Le driver overlay est couvert en détail dans le chapitre "Overlay Networks & Docker Swarm". En résumé : il encapsule le trafic container dans des paquets UDP/VXLAN pour traverser le réseau physique entre plusieurs hosts.

Choisir le bon driver

Besoin d'isoler des containers sur un même host ?
→ bridge (user-defined)

Besoin de performance maximale et l'isolation n'est pas critique ?
→ host

Containers sur plusieurs machines / cluster Swarm ?
→ overlay

Container doit apparaître comme machine physique sur le LAN ?
→ macvlan

Environnement avec limite de MACs par port réseau ?
→ ipvlan

Container de traitement sans besoin réseau ?
→ none

Inspecter et gérer les réseaux

# Lister tous les réseaux (avec drivers)
docker network ls

# Inspecter un réseau (containers connectés, subnet, options)
docker network inspect bridge
docker network inspect bridge --format '{{json .Containers}}'

# Supprimer les réseaux non utilisés
docker network prune

# Supprimer un réseau spécifique
docker network rm my-net  # échoue si des containers y sont connectés

Résumé

bridge : driver par défaut, toujours utiliser un user-defined bridge (DNS automatique)
host : performance max, pas d'isolation, Linux seulement
none : isolation totale, loopback uniquement
macvlan : container avec sa propre MAC/IP sur le LAN physique
ipvlan L3 : routage scalable sans ARP flooding, MAC partagé avec l'hôte
overlay : multi-host via VXLAN (Swarm)

Lab: Network Drivers in Practice

Network Drivers in Practice

Lab: Network Drivers in Practice

Explore bridge, host, and none drivers hands-on.

────────────────────────────────────────

Press Enter to run

Create a custom bridge network with subnet 192.168.100.0/24

Run an nginx container attached to custom-bridge with a fixed IP

Run a container with the 'none' driver (no networking)

Inspect custom-bridge to see the web container's IP

Stop and remove the web container

Remove the custom-bridge network

Network Troubleshooting

Container DNS & Service Discovery