Plusieurs services derrière un seul serveur avec Nginx Proxy Manager
Quand un même serveur héberge plusieurs projets, on finit tôt ou tard par se heurter aux ports 80 et 443, que un seul processus peut écouter. Un article de Habr issu du blog Selectel montre pas à pas comment résoudre ce problème avec Nginx Proxy Manager.
L'auteur commence par expliquer le problème : les ports privilégiés, la règle d'un seul écouteur par port, les soucis de CORS quand le frontend et le backend sont séparés par des ports, et l'absence de HTTPS. Un proxy inverse résout cela en servant d'intermédiaire et en répartissant le trafic selon le domaine et le chemin. Autre avantage : le pare-feu n'a besoin que des ports 22, 80 et 443.
L'environnement de test est un VDS avec 2 vCPU, 2 Go de RAM et 40 Go de NVMe, sous Ubuntu 24.04 avec Docker installé depuis le dépôt officiel. Le réseau est créé avec docker network create proxy, puis le conteneur jc21/nginx-proxy-manager démarre avec des volumes pour les données et les certificats. J'ai apprécié que l'interface d'administration sur le port 81 ne soit liée qu'à 127.0.0.1 et qu'on y accède via un tunnel SSH.
Ensuite, un hôte proxy est configuré : le Forward Hostname reçoit le nom du conteneur, et le certificat SSL se rattache dans l'onglet SSL. whoami de traefik sert aux tests. Le cas où l'application tourne directement sur l'hôte est aussi traité : l'adresse de passerelle du réseau Docker s'obtient avec docker network inspect, et le pare-feu est configuré pour empêcher d'atteindre l'application en contournant le proxy.
Il y a aussi quelques réserves. Les exemples mélangent des domaines différents et l'image utilise le tag latest, ce qui peut nuire à la reproductibilité avec le temps. Malgré cela, c'est un bon point de départ pour qui veut faire tourner plusieurs services à la maison ou sur un VDS sans éditer à la main les configurations nginx.
Source : Habr (blog Selectel)
L'auteur commence par expliquer le problème : les ports privilégiés, la règle d'un seul écouteur par port, les soucis de CORS quand le frontend et le backend sont séparés par des ports, et l'absence de HTTPS. Un proxy inverse résout cela en servant d'intermédiaire et en répartissant le trafic selon le domaine et le chemin. Autre avantage : le pare-feu n'a besoin que des ports 22, 80 et 443.
L'environnement de test est un VDS avec 2 vCPU, 2 Go de RAM et 40 Go de NVMe, sous Ubuntu 24.04 avec Docker installé depuis le dépôt officiel. Le réseau est créé avec docker network create proxy, puis le conteneur jc21/nginx-proxy-manager démarre avec des volumes pour les données et les certificats. J'ai apprécié que l'interface d'administration sur le port 81 ne soit liée qu'à 127.0.0.1 et qu'on y accède via un tunnel SSH.
Ensuite, un hôte proxy est configuré : le Forward Hostname reçoit le nom du conteneur, et le certificat SSL se rattache dans l'onglet SSL. whoami de traefik sert aux tests. Le cas où l'application tourne directement sur l'hôte est aussi traité : l'adresse de passerelle du réseau Docker s'obtient avec docker network inspect, et le pare-feu est configuré pour empêcher d'atteindre l'application en contournant le proxy.
Il y a aussi quelques réserves. Les exemples mélangent des domaines différents et l'image utilise le tag latest, ce qui peut nuire à la reproductibilité avec le temps. Malgré cela, c'est un bon point de départ pour qui veut faire tourner plusieurs services à la maison ou sur un VDS sans éditer à la main les configurations nginx.
Source : Habr (blog Selectel)
Commentaires 0
Laissez le premier commentaire, dans la langue de votre choix.
Connectez-vous pour commenter