J’ai configuré Discourse deux fois, une fois dans un conteneur et la version actuelle dans une VM. Sur les deux installations, Discourse n’est pas accessible. Je ne suis pas sûr de ce qui pourrait clocher.
Une fois terminé, je peux voir que le conteneur fonctionne mais il renvoie une erreur 502 Bad Gateway.
Comment je l’ai configuré : Proxy inverse Nginx (inclut SSL) → VM. Cela ne fonctionne pas.
Il ne se charge même pas lorsque je l’ajoute directement dans mon fichier hosts.
D’après les dernières lignes de l’installation, je vois que Docker a créé un nouveau réseau :
Comment puis-je le faire utiliser l’IP de la machine HÔTE ?
Je n’ai pas besoin d’un autre réseau dans un réseau. Je suis content que Docker utilise l’IP HÔTE car c’est le seul service sur cette VM.
Toute aide serait grandement appréciée !
Existe-t-il une méthode officielle pour installer sans Docker ?
Non, cette machine a une adresse IP locale et le trafic est acheminé vers l’adresse IP locale via mon pare-feu. Ce n’est pas le problème.
L’adresse IP publique a un enregistrement A pour le serveur et elle est correctement acheminée. forum.somedomain.com pointe –> vers le bon serveur.
Oui, j’ai passé l’installation. Je l’ai terminée à 100% (3 fois) jusqu’au point où le conteneur fonctionne.
Il passe toutes les vérifications de domaine/DNS. Il indique que c’est valide.
Non, cela ne peut pas atteindre la limite de débit car le certificat SSL est émis via mon proxy inverse. J’ai le certificat.
Cette installation est terminée à 100%. Le problème est que Docker crée un nouveau réseau 172.17.0.1 qui n’est pas nécessaire car je voudrais utiliser l’adresse IP locale de l’hôte 192.xx.xx.xx.
Le conteneur fonctionne mais sur un réseau différent. Je ne parviens pas à le faire fonctionner sur l’adresse IP de l’hôte.
L’hôte docker devrait être l’adresse IP du serveur hôte (192.xxx.xxx.xxx) et non un nouveau réseau. Il fonctionne probablement mais sur ce réseau.
Comment dire à l’installation d’utiliser mon adresse IP locale et non 172.17.0.1 ?
Vous ne pouvez pas utiliser discourse-setup avec un proxy inverse. Vous devrez modifier le fichier yml vous-même. Il existe certains sujets sur l’exécution de Discourse avec d’autres sites sur la même machine.
Vous devrez supprimer les modèles ssl et letsencrypt si vous utilisez un proxy inverse qui gère le SSL.
C’est justement ça, je n’exécute aucun autre service sur cette machine. C’est une VM autonome.
Je pense qu’il y a un malentendu.
Le ./docker-setup s’installe avec succès. Il crée son propre réseau pour l’application 172.17.0.1.
Comment faire pour que l’installation ou le conteneur Docker utilise l’IP de l’hôte 192.168.1.X, c’est-à-dire utiliser un réseau bridge et ne pas en créer un propre.
C’est assez trivial. Vous autorisez le port http dans app.yml où Ngix envoie le trafic. Et le SSL est désactivé. Ce sont les deux seules choses que vous avez à corriger. Bien sûr, vous devez indiquer la vraie IP, mais cela doit être fait à chaque fois qu’il s’agit d’un backend Discourse, Moodle, WordPress ou autre. UFW essaie de limiter l’accès uniquement entre le frontend et le backend car il n’est pas nécessaire d’autoriser l’accès direct au backend.
Si je me souviens bien, voici la documentation sur la configuration d’Apache2. Nginx fait la même chose, mais à sa manière bien sûr.
L’installation se termine avec succès, puis les problèmes commencent.
Je ne peux pas accéder au conteneur Docker depuis l’hôte à cause du réseau docker0. Je peux pinger 172.17.0.2 et il est opérationnel, mais depuis la machine hôte, 192.168.1.10:80/443 ne transmet pas le trafic au conteneur.
Tout ce que je veux, c’est que le conteneur Docker utilise le réseau de l’hôte car le conteneur a les ports 80 et 443 exposés.
Le premier proxy inverse Nginx gère le trafic venant de l’extérieur et le transmet correctement à la VM. S’il ne le faisait pas, ./discourse-setup n’aurait pas correctement détecté le nom de domaine et n’aurait pas pu récupérer les certificats SSL pour le conteneur.
Au final, je sais que le conteneur fonctionne à 100%, je ne peux juste pas y accéder à cause du réseau Docker.
Si vous avez besoin d’informations, n’hésitez pas à me le faire savoir.
Une autre façon d’aborder cela est d’utiliser l’image de base de Discourse https://hub.docker.com/r/discourse/base
Et de construire votre propre orchestration avec, par exemple, docker compose (en vous rappelant que vous avez besoin d’autres services comme redis et postgres)
Je peux faire cela avec Nginx ou Nginx+Varnish vers Discourse sur le même VPS ou sur un VPS avec une IP différente. Vous ne précisez pas ce que vous faites réellement avec votre Nginx agissant comme proxy inverse. Vos exemples sont un peu difficiles car il n’y a aucun moyen de savoir s’il s’agit d’exemples ou si vous essayez réellement d’utiliser un réseau privé.
Mais :
Bien sûr que non, car cela s’occupe du trafic entrant. Vous devez utiliser un autre port pour le backend.
Quelque chose comme ceci (qui est réellement utilisé avec Varnish, mais le principe est totalement le même, et très basique) :
Je ne suis pas sûr de quoi, car ce réseau Docker est déroutant.
Absolument, c’est pourquoi je suis frustré par Docker lol.
Ci-dessous, c’est exactement comment le réseau WAN transmet et achemine le trafic de mon proxy inverse Nginx vers l’hôte correct.
map $scheme $hsts_header {
https "max-age=63072000;includeSubDomains; preload";
}
server {
set $forward_scheme https;
set $server "10.10.1.38";
set $port 443;
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name forum.domainname.com;
# Let's Encrypt SSL
include conf.d/include/letsencrypt-acme-challenge.conf;
include conf.d/include/ssl-ciphers.conf;
ssl_certificate /srv/ssl/domainname.pem;
ssl_certificate_key /srv/ssl/domainname-ke.pem;
# Asset Caching
include conf.d/include/assets.conf;
# Block Exploits
include conf.d/include/block-exploits.conf;
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
# Force SSL
include conf.d/include/force-ssl.conf;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $http_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
location / {
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
# Proxy!
include conf.d/include/proxy.conf;
}
}
Ce qui est étrange, c’est que j’ai configuré un conteneur Docker une fois pour un client qui voulait un gestionnaire de proxy inverse Nginx et c’était extrêmement simple.
docker-compose up -d
C’était tout. L’IP privée 192.168.1.3 pouvait atteindre les 80/443 exposés des conteneurs et le trafic sortant était correctement acheminé vers 192.168.1.3.
C’est déroutant car c’est un système de paquetage qui joue dans son propre bac à sable. Essentiellement, c’est ça.
Mais comprendre Docker est une chose différente que de l’utiliser (et maintenant un tas de développeurs ont commencé à pleurer ). Votre proxy inverse envoie du trafic vers une adresse IP via un pare-feu et vous devez indiquer cette adresse IP et le port d’écoute. Et vous avez Discourse, alias Docker, sur cette adresse IP, et le port que vous indiquez dans app.yml. Le Nginx interne qui fonctionne avec Discourse lui-même s’occupe du reste.
Discourse ne devrait pas écouter sur le port 443 car vous avez déjà terminé le SSL.
Et vous ne pouvez fondamentalement pas utiliser la mise en cache sur le proxy inverse. Le backend, Discourse, n’est pas une page web. C’est une application web qui envoie du JavaScript et du JSON.
Ça, je peux être d’accord. Je ne dirais pas pleurer, c’est juste inutile pour les administrateurs système et les développeurs qui connaissent leur chemin sous Linux. Créer un LxC ou une VM qui est isolée pour ensuite laisser Docker créer un autre environnement isolé est redondant et inutile.
C’est là que ça devient confus. app.yml expose 80:80 et 443:443 sur 172.17.0.2 qui est sur le réseau Docker 172.17.0.1/16 avec l’IP de la VM sur 10.10.1.38.
Comment faire en sorte que Discourse/Docker autorise tout le trafic arrivant sur 10.10.1.38 à être transmis à 172.17.0.2 et que tout le trafic sortant soit transmis à 10.10.1.38. C’est tout ce qui est nécessaire pour résoudre ce problème. Littéralement.
Mon proxy inverse gérera le routage de la WAN vers forum.domaine.com
Seulement si vous ne les modifiez pas. Comme vous devriez le faire et n’utiliser qu’un seul port.
80:80 et 443:443 sont les valeurs par défaut et sont utilisés en soi uniquement lorsqu’il n’y a pas de proxy inverse, ou quoi que ce soit d’autre, agissant comme un frontend.
J’étais occupé à vérifier tous les fichiers de base et je pense avoir trouvé.
Tellement simple lol. Je suis occupé à reconstruire, cela pourrait fonctionner à 100 % en utilisant les méthodes d’installation standard officiellement prises en charge.
). Votre proxy inverse envoie du trafic vers une adresse IP via un pare-feu et vous devez indiquer cette adresse IP et le port d’écoute. Et vous avez Discourse, alias Docker, sur cette adresse IP, et le port que vous indiquez dans 
