Reverse proxy : un seul point d'entrée

Prérequis (cursus dev) : proxy, domaine et HTTPS, Caddy en pratique, DNS.

Pourquoi

Sans proxy, chaque app gère son TLS, ses ports, son domaine : bazar ingérable dès 2 apps. Avec un proxy, les apps restent sur un réseau interne sans aucun port publié, et un seul composant parle HTTPS au monde.

Concepts

• Reverse proxy : serveur qui reçoit les requêtes clients et les relaie aux bonnes apps (l'inverse d'un proxy classique qui relaie les clients vers internet).
• Origine unique : un domaine, routage par chemin (/api/* → API, reste → web). Les apps se joignent par nom de conteneur sur le réseau partagé : pas d'IP en dur, pas de port hôte.
• Challenge ACME : l'épreuve par laquelle Let's Encrypt vérifie que tu contrôles le domaine (fichier servi ou champ DNS) avant d'émettre le certificat. D'où : DNS en place avant le premier accès.

Exemple

app.example.fr {
    handle /api/* {
        reverse_proxy api:3001
    }
    handle {
        reverse_proxy web:3000
    }
}

Ajouter une app = un bloc + validate + reload, sans toucher aux autres. Après chaque changement : curl public — la preuve, c'est la réponse HTTP, pas l'absence d'erreur.

Cas réel

Prod + dev sur la même machine : deux blocs, deux paires de conteneurs, volumes et bases séparés. La dev qui tombe ne fait pas broncher la prod — à condition de n'avoir rien partagé.

Pièges

• Fichier de conf bind-mounté par inode : l'écrire en place (cat nouveau > fichier), jamais le remplacer, sinon le conteneur garde l'ancien.
• reload sans validate : une conf invalide peut laisser l'ancienne… ou pire.
• DNS propagé à moitié (cache) : tester avec dig +short depuis l'extérieur avant de conclure.

À retenir

Un proxy, des noms (pas des IP), DNS avant, validate avant reload, curl après, dev/prod séparées.