MODIF : @pfaffman a réécrit ceci en un sujet autonome à partir de ce que @tophee avait écrit plus tôt. Ce n’est pas encore testé par moi, et j’ai réorganisé les mots de Chris, donc toute erreur est probablement de la responsabilité de @pfaffman.
Y a-t-il des raisons de ne pas utiliser NGINX Proxy Manager au lieu de faire cela manuellement comme décrit dans Run other websites on the same machine as Discourse ?
Je l’utilise déjà. Je l’ai eu sur mon serveur personnel pendant un certain temps et lorsque j’ai migré mon instance Discourse vers un nouveau serveur cloud, j’ai réalisé que j’avais oublié la majeure partie de la configuration du proxy inverse NGINX que j’avais faite il y a 4 ans sur l’ancien serveur, alors je me suis dit : pourquoi ne pas le faire avec NGINX Proxy Manager ? À ma surprise, j’ai constaté qu’il avait été mentionné assez rarement ici sur Meta, ce qui m’a fait me demander s’il y avait des inconvénients que j’aurais pu manquer…
En effet, cela a nécessité quelques essais et erreurs, mais j’ai réussi à le faire fonctionner comme suit (aucune garantie que ce soit la meilleure façon de faire — en fait, je sais qu’il doit y avoir une meilleure méthode — donc les corrections et améliorations sont les bienvenues) :
Pour commencer, il y a deux façons d’accéder à votre instance Discourse : 1. en exposant un port, 2. via websocket. Je crois avoir appris quelque part sur ce forum que le websocket est plus rapide / plus efficace, c’est donc ce que j’utilise, mais exposer un port devrait être beaucoup plus simple, donc si vous ne parvenez pas à faire fonctionner le socket, essayez d’exposer un port. Donc, pour éviter toute confusion : pour accéder à Discourse via un port, suivez les étapes 0, 1, 2, 3, 4 et 8 ci-dessous. Si vous souhaitez utiliser un websocket, suivez les étapes 0, 1, 5, 6, 7, 8 et 9.
0. Point de départ
Supposons donc que vous ayez terminé l’installation standard de 30 minutes et supposons que vous n’ayez pas encore laissé Discourse obtenir un certificat Let’s Encrypt — car vous n’en avez pas besoin lorsque vous utilisez un proxy inverse. NGINX Proxy Manager s’en chargera. Cela n’a pas d’importance non plus si vous avez déjà un certificat. NGINX Proxy Manager en obtiendra simplement un nouveau.
1. Installer NGINX Proxy Manager
La prochaine étape consiste à installer NGINX Proxy Manager afin d’avoir deux conteneurs Docker supplémentaires en cours d’exécution (NGINX Proxy Manager et son conteneur de base de données).
Ensuite vient la partie délicate dont vous parlez.
Le premier obstacle est que Discourse s’exécute sur le réseau bridge par défaut de Docker, tandis que NGINX Proxy Manager s’exécute par défaut sur un réseau « créé par l’utilisateur » par défaut (appelé npm_default dans mon cas), ce qui signifie que NGINX Proxy Manager ne peut pas voir Discourse. 
2. Placer tous les conteneurs sur le réseau bridge par défaut
Donc, tant que je ne sais pas si et comment Discourse peut être déplacé vers un réseau personnalisé, nous devons déplacer NGINX Proxy Manager vers le réseau bridge par défaut. Nous pouvons le faire en ajoutant network_mode: bridge aux deux conteneurs NGINX Proxy Manager dans notre fichier docker compose.
3. Utiliser l’adresse IP au lieu du nom de service
Le problème suivant est que le fichier docker compose standard ne fonctionnera plus si vous le déplacez simplement vers le réseau bridge. NGINX Proxy Manager ne pourra plus trouver son conteneur de base de données. En effet, la résolution DNS interne des noms de service (sur laquelle repose le fichier docker-compose) n’est disponible que sur les réseaux créés par l’utilisateur, et non sur les réseaux Docker par défaut. Nous devons donc recourir à des adresses IP codées en dur (ce qui explique pourquoi ce n’est absolument pas la solution optimale, car cela échouera si les adresses IP de vos conteneurs changent). Vous devez donc démarrer le conteneur même si vous savez qu’il ne fonctionnera pas, noter l’IP du conteneur de base de données NGINX Proxy Manager, et remplacer DB_MYSQL_HOST: "db" dans votre fichier docker compose par DB_MYSQL_HOST: "<ip_conteneur_db>".
Maintenant, tous les conteneurs devraient être sur le réseau bridge par défaut afin que NGINX Proxy Manager puisse voir à la fois Discourse et sa base de données.
4. Rendre Discourse accessible
Mais « voir » Discourse et pouvoir y accéder ne sont pas la même chose. Vous devez donc vous assurer que Discourse acceptera tout le trafic que NGINX Proxy Manager lui transmet. Si vous ne vous souciez pas d’utiliser le websocket, je suppose que vous pouvez simplement pointer NGINX Proxy Manager vers le port 80 (pas 443) de l’IP de votre conteneur Discourse, comme ceci :
Je n’ai pas testé cela, cependant. Comme je l’ai mentionné, j’utilise la configuration websocket, qui nécessite quelques étapes supplémentaires. Notez que le nom d’hôte/IP et le port ci-dessus seront ignorés lorsque vous utilisez le websocket.
5. Configurer app.yml pour utiliser le websocket
Ceci est expliqué dans le message d’origine, donc je n’entrerai pas dans les détails.
6. Monter le websocket dans le conteneur NGINX Proxy Manager
Nous devons donner à NGINX Proxy Manager accès au websocket en le montant comme volume : - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. C’est le dernier changement à apporter au fichier docker compose par défaut de NGINX Proxy Manager, voici donc la version finale qui fonctionne pour moi :
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
network_mode: bridge
ports:
- '80:80'
- '81:81'
- '443:443'
environment:
DB_MYSQL_HOST: "172.17.0.6"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "my-super-safe-pwd"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
db:
image: 'jc21/mariadb-aria:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'my-super-safe-pwd'
volumes:
- ./data/mysql:/var/lib/mysql
7. Configurer NGINX Proxy Manager pour utiliser le websocket
Dernière étape : indiquer à NGINX Proxy Manager d’utiliser le websocket. Pour autant que je me souvienne, activer simplement « Prise en charge des Websockets » ne suffisait pas, j’ai donc copié l’emplacement NGINX du message d’origine dans l’onglet « Avancé », comme ceci :
Je n’ai pas réussi à faire fonctionner cela sous l’onglet « Emplacements personnalisés ».
8. N’oubliez pas d’activer SSL
Je n’ai pas mentionné la configuration SSL dans NGINX Proxy Manager car elle semble assez évidente et je ne pense pas qu’il importe à quel moment du processus vous l’activez. Donc, si vous ne l’avez pas encore fait, voici à quoi ressemble la mienne :
9. Attention
tl;dr Chaque fois que vous redémarrez le conteneur Discourse, vous devez également redémarrer le conteneur principal NGINX Proxy Manager (pas besoin de redémarrer la base de données).
Si vous accédez à Discourse via le websocket, vous devez être conscient que lorsque vous reconstruisez votre conteneur Discourse (ce qui est nécessaire tous les quelques mois pour mettre à jour l’image de base), l’ancien websocket sera supprimé et un nouveau créé. Par conséquent, NGINX Proxy Manager perdra le contact avec votre instance Discourse et renverra une erreur 502. Peut-être qu’une future mise à jour de NGINX Proxy Manager pourra trouver automatiquement le nouveau websocket, mais actuellement (janvier 2022), NGINX Proxy Manager ne trouvera pas votre conteneur Discourse reconstruit à moins que vous ne redémarriez NGINX Proxy Manager.
Explication
Si vous vous demandez pourquoi les instructions ci-dessus combinent le websocket avec les ports, la raison simple est que, alors que j’écrivais ce post, il m’est soudainement venu à l’esprit que NGINX Proxy Manager et Discourse n’ont probablement même pas besoin d’être sur le même réseau Docker lorsque nous utilisons le websocket. Et lorsque cela a été confirmé, personne n’avait envie de réécrire complètement les instructions.
C’est l’aspect le plus fascinant des forums de support : faire du bon travail en décrivant votre problème vous conduit souvent à la solution sans même poster votre question. Et dans ce cas, je répondais à la question de quelqu’un d’autre mais j’ai peut-être aussi trouvé la réponse à ma propre question. 
Mais après avoir examiné NGINX Proxy Manager pendant 12 secondes ou plus, je pense qu’il fera très bien l’affaire. Il existe un autre outil « magique » de proxy NGINX dont j’ai déjà vu la discussion, mais avec ma profonde connaissance de NGINX Proxy Manager, je pense qu’il pourrait être préférable. Je pourrais jeter un coup d’œil, car je me désenchante de plus en plus avec Traefik.
). Bref, tout s’est déroulé comme prévu. Ensuite, j’ai apporté les modifications nécessaires pour faire fonctionner Discourse avec les websockets : tout a fonctionné cette fois aussi. Heureusement, la configuration précédente de Discourse avait créé des sauvegardes automatiques, donc en quelques clics, j’ai tout restauré (plus j’utilise Discourse, plus je l’apprécie !).