IT Toolbox AI
Docker · Réseaux Docker

Réseaux Docker

Reliez les containers avec des réseaux dédiés et distinguez exposition interne et publication vers l’hôte.

Leçon disponible
20 min

Objectifs

  • Identifier les modes bridge, host et none.
  • Créer et inspecter un réseau utilisateur.
  • Comprendre la résolution DNS par nom de container.
  • Distinguer un port accessible entre containers d’un port publié vers l’hôte.

Comprendre les réseaux Docker

Docker fournit plusieurs drivers réseau. bridge crée un réseau isolé sur l’hôte, host retire une grande partie de l’isolation réseau sous Linux et none ne configure pas de connectivité externe normale.

Un réseau bridge utilisateur regroupe les containers d’une même application et offre une résolution DNS automatique par nom ou alias entre ses membres.

Bridge, host, none et réseaux utilisateur

Sans option, un container rejoint généralement le bridge par défaut. Un bridge utilisateur apporte une meilleure isolation entre projets et une résolution de noms plus pratique.

  • bridge : réseau privé sur l’hôte Docker, adapté à la plupart des applications locales.
  • host : partage la pile réseau de l’hôte sur les plateformes qui le prennent en charge.
  • none : isole le container des réseaux Docker usuels.
  • réseau utilisateur : réseau nommé créé pour un périmètre applicatif.
Lister, créer et inspecter un réseau
docker network ls
docker network create app-network
docker network inspect app-network

Communication par nom de container

Deux containers reliés au même réseau utilisateur peuvent généralement utiliser leurs noms comme noms DNS. Il est donc inutile de figer une adresse IP susceptible de changer lors d’une recréation.

Démarrer deux services sur le même réseau
docker run -d \
  --name backend \
  --network app-network \
  nginx:alpine

docker run -d \
  --name frontend \
  --network app-network \
  nginx:alpine

Depuis frontend, le nom backend peut être résolu sur app-network. Le service doit toutefois écouter sur la bonne adresse et le bon port pour accepter la connexion.

Connecter un container existant

Un container peut appartenir à plusieurs réseaux utilisateur. connect ajoute une connexion et disconnect la retire sans recréer l’objet container.

Ajouter puis retirer une connexion réseau
docker network connect app-network existing-container
docker network disconnect app-network existing-container

Port interne et port publié

Les containers d’un même réseau utilisateur communiquent directement sur leurs ports applicatifs. Publier un port crée en plus un accès depuis l’hôte, et éventuellement depuis l’extérieur selon l’adresse d’écoute et le pare-feu.

Publier le port interne 80 sur le port 8080 de l’hôte
docker run -d --name public-web --network app-network -p 8080:80 nginx:alpine

EXPOSE dans une image documente le port prévu. Seule une publication comme -p 8080:80 crée le mapping vers l’hôte.

Bonnes pratiques

Créez un réseau par périmètre applicatif, connectez uniquement les services qui doivent communiquer et publiez le moins de ports possible.

  • Utiliser les noms de services ou containers plutôt que des IP fixes.
  • Séparer frontend, backend et données lorsque le modèle de sécurité le justifie.
  • Inspecter le réseau avant de modifier ses connexions.

Mini résumé

  • Bridge est le driver courant ; host et none changent fortement l’isolation.
  • Un réseau utilisateur fournit une résolution DNS entre ses containers.
  • network connect et disconnect modifient les appartenances réseau.
  • -p 8080:80 publie un service du container vers l’hôte.

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Pourquoi préférer le nom backend à son adresse IP sur un réseau utilisateur ?
2. Depuis frontend, que représente localhost ?
3. Un service doit être accessible depuis l’hôte sur 8080. Que faut-il configurer ?