4.3Réseaux avancés et reverse proxy
L'essentiel en 30 secondes
- On segmente par fonction : un réseau frontal (proxy vers applications) et un réseau backend (applications vers bases) — la base, cantonnée au backend, reste inatteignable directement même si le proxy est compromis.
- Un seul port publié, tout le reste routé : le reverse proxy (frontal) est le seul publié et route par nom d'hôte — les applications ne font qu'exposer en interne et sont jointes par leurs noms.
- Réflexe d'Idir : ajouter un service = une entrée de routage, zéro port supplémentaire — config du proxy montée en lecture seule.
Mini-cas filé — Idir range les ports en pagaille derrière un frontal
Idir, devops junior à Alger, gère deux applications qui publient chacune leur port : les URL sont illisibles et la base est joignable depuis le réseau frontal. Il crée deux réseaux (frontal et backend), ne publie que le port du proxy, route par noms d'hôtes et cantonne la base au backend. Troisième jalon du fil rouge : un point d'entrée unique, des services segmentés, zéro port en pagaille.
Suite des cas 4.1-4.2 — les services fiabilisés d'Idir sont maintenant exposés proprement.
1. Segmenter : un réseau par fonction
Au-delà d'un réseau unique, on segmente : frontal (proxy vers applications) et backend (applications vers bases). Un service appartient à plusieurs réseaux si besoin ; une base n'est que sur backend : même compromise du proxy, elle reste inatteignable directement.
La segmentation, c'est de l'isolation concrète : chaque réseau ne voit que ce qu'il doit voir. Idir y place chaque service selon ce qu'il doit joindre — et rien d'autre.
2. Le reverse proxy : un port pour tous
Traefik ou Nginx en frontal : seul son port 80/443 est publié, il route par nom d'hôte (chaque hôte vers son service). Les applications ne publient plus rien : elles exposent en interne et le proxy les joint par noms. Un point d'entrée, N services — ajouter une application, c'est une entrée de routage.
Nginx (config explicite, parfait pour apprendre) et Traefik (découverte automatique, idéal quand les services bougent) appliquent le même schéma : Idir commence simple avec une config explicite.
3. En local : noms propres, futurs certificats
En développement, on déclare les hôtes dans le fichier hosts (chaque nom vers la machine locale) ; en production, le DNS + TLS chiffrent le trafic. Retenez le schéma : un seul publié, tout le reste routé.
Et la config du proxy se monte en lecture seule : le conteneur la lit sans pouvoir la réécrire.
🔎 Exemple concret — 🔎 Exemple concret — Deux apps derrière Nginx
Le frontal d'Idir : seul le proxy publie le port 80.
services:
proxy:
image: nginx:1.27
ports: ["80:80"]
volumes: [./proxy.conf:/etc/nginx/conf.d/default.conf:ro]
networks: [frontal]
app1:
image: nginx:1.27
networks: [frontal]
app2:
image: nginx:1.27
networks: [frontal]
networks:
frontal:
backend:Lecture : seul le proxy publie le port 80 ; les applications ne sont visibles que par lui.
Leçon : ajouter une troisième application = une entrée de routage, zéro port supplémentaire.
Vocabulaire de la section
- Reverse proxy
- Frontal qui reçoit les requêtes et les ROUTE vers les bons services selon les noms d'hôtes.
Exemple simple : Le proxy d'Idir envoie chaque hôte vers son application.
Ce que ce n'est pas : une publication de chaque port d'application vers l'extérieur.
Réflexe : plusieurs services, un seul port : poser un frontal.
- Segmentation
- Découper en RÉSEAUX PAR FONCTION (frontal, backend) pour isoler les flux.
Exemple simple : Idir cantonne sa base au backend, injoignable depuis l'entrée.
Ce que ce n'est pas : un réseau unique où tout voit tout.
Réflexe : base de données : jamais sur le réseau frontal.
- Routage par hôte
- Chaque NOM D'HÔTE est dirigé vers son service (un hôte = une application).
Exemple simple : Chaque application d'Idir a son nom, routé par le proxy.
Ce que ce n'est pas : un port différent bricolé par application.
Réflexe : nouveau service : une entrée de routage, pas un port.
- EXPOSE
- Déclaration INTERNE d'un port, sans publication vers l'extérieur.
Exemple simple : Les applications d'Idir exposent en interne ; seul le proxy publie.
Ce que ce n'est pas : une publication de port accessible depuis la machine.
Réflexe : derrière un proxy : exposer, ne pas publier.
En pratique — En pratique — Poser un frontal
- Créez les réseaux frontal et backend.
- Lancez deux applications non publiées sur frontal.
- Lancez le proxy publié avec routage par hôte.
- Testez les deux hôtes, puis coupez un backend : l'autre survit.
Script prêt à dire — justifier le frontal à l'équipe (30 s)
« C'est Idir : au lieu d'un port par application, on n'expose que le proxy et il route par noms. Les applications ne sont plus joignables directement, la base reste cantonnée à son réseau, et la prochaine application ne coûtera qu'une ligne de routage. »
À dire quand on propose encore « un port de plus » : montrez la liste des ports actuels.
Modèle copier-coller — frontal Nginx + réseaux (Compose)
services:
proxy:
image: nginx:1.27
ports: ["80:80"]
volumes: [./proxy.conf:/etc/nginx/conf.d/default.conf:ro]
networks: [frontal]
app1:
image: nginx:1.27
networks: [frontal]
app2:
image: nginx:1.27
networks: [frontal]
networks:
frontal:
backend:Deuxième application
Comme Idir : une entrée de routage de plus, aucun port publié supplémentaire.
Services qui bougent souvent
Passer à Traefik : découverte automatique des services, même schéma frontal unique.
Base à protéger
Base cantonnée au backend, jointe par nom depuis les applications : injoignable depuis l'entrée.
Développement local
Noms déclarés dans le fichier hosts : le même fichier de frontal sert en local puis en production.
✓ Bonnes pratiques
- Un seul publié : le proxy.
- Routes par noms d'hôtes explicites.
- Config proxy en montage lecture seule.
✗ Pièges fréquents
- Publier chaque application (ports en pagaille).
- Base sur le réseau frontal.
- Config proxy inscriptible depuis le conteneur.
Points clés à retenir
- Segmenter : frontal vs backend.
- Un proxy publié route tout.
- Apps non publiées, jointes par noms.
- TLS en prod, hosts en dev.
Défi 48h — appliquez demain
Derrière un proxy unique publié : exposez 2 applications non publiées routées par hôtes, base cantonnée au backend, config en lecture seule.
- Je sais segmenter en réseaux frontal et backend.
- Je sais publier seul le proxy et router par hôtes.
- Je sais cantonner la base et monter la config en lecture seule.
Questions fréquentes
Traefik ou Nginx ?
Nginx : config explicite, parfait pour apprendre. Traefik : découverte auto par étiquettes, idéal quand les services bougent. Les deux appliquent le même schéma : un seul publié, routage par hôtes.
Faut-il un proxy en dev ?
Dès deux applications : oui, même simple. C'est le même fichier qui servira en production, sans les ports en pagaille.
Trois apps web sur une machine, un seul port 80. Que faites-vous ?