Le paradigme : "Internal vs Exposure"

Le secret absolu de la sécurité en conteneurisation est : N'exposez à Internet (via Ports Mapping) QUE le point d'entrée de votre application (Le Proxy / Front). La Base de données (PostgreSQL, Redis) n'a jamais besoin d'être exposée à Internet (Port 5432 ouvert), l'API (Backend) lui parlera via le Réseau Interne Sécurisé (Bridge Privé) de Docker.

1. La Règle d'or : Fuyez le "Default Bridge" (docker0)

Lorsque vous lancez un conteneur sans spécifier de réseau (juste docker run -d mysql), il est placé sur le réseau Bridge Par Défaut. Historiquement sur ce réseau, les conteneurs peuvent se "pinger", mais uniquement via leur Adresse IP. Or, l'IP changeant à chaque crash de conteneur, votre application Server plantera invariablement en pointant en dur `172.17.0.2`.

En créant un **réseau spécifique (Custom User-Defined Bridge)**, Docker Daemon active automatiquement une puce **DNS Dynamique Magique**. Les conteneurs peuvent désormais se pinger simplement par leur --name.

# Étape 1 : Créer le sous-réseau "ecommerce-net"
docker network create ecommerce-net

# Étape 2 : Lancer la BDD (Invisible de l'extérieur) attachée au réseau "ecommerce-net"
docker run -d --name mysql-db --network ecommerce-net -e MYSQL_ROOT_PASSWORD=secret mysql:8

# Étape 3 : Lancer l'API attachée au même réseau, ce qui lui permet de "pinger" mysql-db
# Le code de l'API s'y connecte via l'URL BDD : mysql://mysql-db:3306 
docker run -d --name node-api --network ecommerce-net -p 8080:3000 mon-app-node

2. L'Exposition de Ports (Port Forwarding / Binding)

Le réseau de Docker bloque tout le trafic entrant par le mur du Daemon local. Pour qu'une requête atteigne votre Serveur Web (NGINX), vous devez percer le pare-feu consciemment (L'option -p).

# Le piège : Le HÔTE est toujours à GAUCHE (host:container)
# L'OS mapping : Tout le web qui tape sur le port 80 de ma machine (Windows/Ubuntu)
# Est magiquement redirigé dans l'espace isolé sur le port 9000 du Conteneur
docker run -d -p 80:9000 --name nginx-server nginx

# Limiter l'écoute uniquement à localhost (Sécurité Vitale pour Proxy inverse Redis)
docker run -p 127.0.0.1:6379:6379 redis

⚠️ Prise d'otage de Ports : Si votre vrai PC / Serveur héberge déjà de façon native un système (Ex: Apache sur le Port 80, ou Skype), vous obtiendrez l'erreur "bind: address already in use" lors du proxy inversé (`-p 80:80`). Vous êtes forcé de diriger le trafic vers un port non utilisé : -p 8080:80.

3. Cas Pratique : Le Reverse Proxy NGINX

Dans une architecture professionnelle moderne, on n'expose pratiquement jamais directement une API Node.js ou Django sur Internet (Port 80/443). On place un Reverse Proxy (NGINX, Traefik, ou Caddy) en "videur de boîte de nuit". C'est le SEUL conteneur de votre réseau à posséder le drapeau -p 80:80. Il dispatche ensuite le trafic en interne.

server {
    listen 80;
    server_name mon-application-cool.com;

    location /api/ {
        # Magie du DNS Docker : NGINX route le trafic vers le conteneur "node-api".
        # Le conteneur "node-api" N'A PAS besoin d'être ouvert avec -p 3000:3000 !
        # Le trafic passe à 100% par le LAN virtuel privé.
        proxy_pass http://node-api:3000/;
        proxy_set_header Host $host;
    }
    
    location / {
        # Front React/Vue : Dirigé vers un autre conteneur local
        proxy_pass http://react-frontend:80/;
    }
}