EDIT: @pfaffman hat dies basierend auf dem, was @tophee zuvor geschrieben hatte, als eigenständiges Thema neu verfasst. Es wurde von mir noch nicht getestet, und ich habe Chris’ Worte umgestellt, sodass etwaige Fehler wahrscheinlich auf @pfaffman zurückzuführen sind.
Gibt es Gründe, nicht stattdessen NGINX Proxy Manager zu verwenden, anstatt dies manuell wie in Run other websites on the same machine as Discourse beschrieben durchzuführen?
Ich verwende ihn bereits. Ich habe ihn seit geraumer Zeit auf meinem Heimserver und als ich meine Discourse-Instanz auf einen neuen Cloud-Server migriert habe, fiel mir auf, dass ich die meisten der NGINX-Reverse-Proxy-Einstellungen vergessen hatte, die ich vor 4 Jahren auf dem alten Server vorgenommen hatte. Also dachte ich: Warum nicht NGINX Proxy Manager dafür verwenden? Zu meiner Überraschung stellte ich fest, dass er hier auf Meta nur selten erwähnt wurde, und ich begann zu überlegen, ob es Nachteile gibt, die ich übersehen habe …
Tatsächlich erforderte dies ein wenig Versuch und Irrtum, aber ich habe es wie folgt zum Laufen gebracht (keine Garantie, dass dies der beste Weg ist – tatsächlich weiß ich, dass es einen besseren geben muss – daher sind Korrekturen und Verbesserungen sehr willkommen):
Zu Beginn gibt es zwei Möglichkeiten, auf Ihre Discourse-Instanz zuzugreifen: 1. durch Freigabe eines Ports, 2. über WebSocket. Ich glaube, ich habe irgendwo in diesem Forum gelernt, dass WebSocket schneller/effizienter ist, daher verwende ich das, aber das Freigeben eines Ports sollte viel einfacher sein. Wenn Sie also den Socket nicht zum Laufen bekommen, versuchen Sie es mit einem freigegebenen Port. Um Verwirrung zu vermeiden: Um über einen Port auf Discourse zuzugreifen, befolgen Sie die Schritte 0, 1, 2, 3, 4 und 8 unten. Wenn Sie einen WebSocket verwenden möchten, befolgen Sie die Schritte 0, 1, 5, 6, 7, 8 und 9.
0. Ausgangspunkt
Gehen wir also davon aus, dass Sie die 30-minütige Standardinstallation abgeschlossen haben, und nehmen wir an, Sie haben Discourse noch kein Lets-Encrypt-Zertifikat erteilen lassen – denn bei Verwendung eines Reverse-Proxy wird es nicht benötigt. NGINX Proxy Manager übernimmt das. Es spielt jedoch keine Rolle, ob Sie bereits ein Zertifikat haben. NGINX Proxy Manager wird einfach ein neues erhalten.
1. NGINX Proxy Manager installieren
Der nächste Schritt ist die Installation von NGINX Proxy Manager, sodass Sie zwei weitere Docker-Container ausgeführt haben (NGINX Proxy Manager und dessen Datenbank-Container).
Als Nächstes kommt der knifflige Teil, den Sie angesprochen haben.
Das erste Hindernis ist, dass Discourse im Standard-Docker-bridge-Netzwerk läuft, während NGINX Proxy Manager standardmäßig in einem standardmäßig erstellten „benutzerdefinierten Netzwerk" läuft (in meinem Fall npm_default genannt), was bedeutet, dass NGINX Proxy Manager Discourse nicht sehen kann. 
2. Alle Container in das Standard-bridge-Netzwerk bringen
Solange ich nicht weiß, ob und wie Discourse in ein benutzerdefiniertes Netzwerk verschoben werden kann, müssen wir NGINX Proxy Manager in das Standard-bridge-Netzwerk verschieben. Dies können wir tun, indem wir network_mode: bridge zu beiden NGINX Proxy Manager-Containern in unserer docker-compose-Datei hinzufügen.
3. IP-Adresse anstelle des Dienstnamens verwenden
Das nächste Problem ist, dass die Standard-docker-compose-Datei nicht mehr funktioniert, wenn Sie sie einfach in das bridge-Netzwerk verschieben. NGINX Proxy Manager kann seinen Datenbank-Container nicht mehr finden. Dies liegt daran, dass die interne DNS-Auflösung für Dienstnamen (auf die sich die docker-compose-Datei verlässt) nur in benutzerdefinierten Netzwerken verfügbar ist, nicht jedoch in den Standard-Docker-Netzwerken. Wir müssen uns also auf hart kodierte IP-Adressen zurückziehen (was bedeutet, dass dies definitiv nicht die optimale Lösung ist, da sie fehlschlägt, wenn sich die Container-IPs ändern). Sie müssen also den Container starten, auch wenn Sie wissen, dass er nicht funktionieren wird, notieren Sie sich die IP des NGINX Proxy Manager-Datenbank-Containers und ersetzen Sie DB_MYSQL_HOST: "db" in Ihrer docker-compose-Datei durch DB_MYSQL_HOST: "<db_container_IP>".
Jetzt sollten sich alle Container im Standard-bridge-Netzwerk befinden, damit NGINX Proxy Manager sowohl Discourse als auch dessen Datenbank sehen kann.
4. Discourse zugänglich machen
Aber Discourse „sehen" und darauf zugreifen können, ist nicht dasselbe. Sie müssen also sicherstellen, dass Discourse den gesamten Verkehr akzeptiert, den NGINX Proxy Manager weiterleitet. Wenn Ihnen die Verwendung des WebSockets egal ist, können Sie NGINX Proxy Manager einfach auf Port 80 (nicht 443) der Discourse-Container-IP zeigen, wie hier:
Das habe ich jedoch nicht getestet. Wie erwähnt, verwende ich das WebSocket-Setup, das weitere Schritte erfordert. Beachten Sie, dass der oben genannte Hostname/IP und Port ignoriert werden, wenn Sie den WebSocket verwenden.
5. app.yml konfigurieren, um WebSocket zu verwenden
Dies wird im Originalbeitrag (OP) erklärt, daher gehe ich nicht weiter darauf ein.
6. WebSocket im NGINX Proxy Manager-Container einbinden
Wir müssen NGINX Proxy Manager Zugriff auf den WebSocket gewähren, indem wir ihn als Volume einbinden: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. Dies ist die letzte Änderung an der Standard-docker-compose-Datei von NGINX Proxy Manager, also hier die finale Version, die bei mir funktioniert:
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. NGINX Proxy Manager konfigurieren, um den WebSocket zu verwenden
Letzter Schritt: Weisen Sie NGINX Proxy Manager an, den WebSocket zu verwenden. Soweit ich mich erinnere, reichte es nicht aus, einfach „WebSocket-Unterstützung" einzuschalten, also habe ich den NGINX-Location-Eintrag aus dem OP in den Reiter „Erweitert" kopiert, wie hier:
Ich habe dies nicht unter dem Reiter „Benutzerdefinierte Standorte" zum Laufen gebracht.
8. SSL nicht vergessen zu aktivieren
Ich habe die SSL-Konfiguration in NGINX Proxy Manager nicht erwähnt, da sie ziemlich offensichtlich erscheint und ich nicht denke, dass es wichtig ist, zu welchem Zeitpunkt im Prozess Sie sie aktivieren. Wenn Sie es also noch nicht getan haben, sieht meine Konfiguration so aus:
9. Wichtiger Hinweis
tl;dr: Wann immer Sie den Discourse-Container neu starten, müssen Sie auch den Haupt-NGINX Proxy Manager-Container neu starten (die Datenbank muss nicht neu gestartet werden).
Wenn Sie über den WebSocket auf Discourse zugreifen, müssen Sie beachten, dass beim Neuaufbau Ihres Discourse-Containers (was alle paar Monate erforderlich ist, um das Basis-Image zu aktualisieren), der vorherige WebSocket gelöscht und ein neuer erstellt wird. Infolgedessen verliert NGINX Proxy Manager die Verbindung zu Ihrer Discourse-Instanz und wirft einen 502-Fehler. Vielleicht wird ein zukünftiges Update von NGINX Proxy Manager in der Lage sein, den neuen WebSocket automatisch zu finden, aber derzeit (Januar 2022) findet NGINX Proxy Manager Ihren neu aufgebauten Discourse-Container nicht, es sei denn, Sie starten NGINX Proxy Manager neu.
Erklärung
Wenn Sie sich fragen, warum die obigen Anweisungen den WebSocket mit Ports kombinieren, ist der einfache Grund, dass mir beim Schreiben dieses Beitrags plötzlich klar wurde, dass NGINX Proxy Manager und Discourse wahrscheinlich nicht einmal im selben Docker-Netzwerk sein müssen, wenn wir den WebSocket verwenden. Und als dies bestätigt wurde, hatte niemand Lust, die Anweisungen komplett neu zu schreiben.
Dies ist der faszinierendste Aspekt von Support-Foren: Eine gute Beschreibung Ihres Problems führt Sie oft zur Lösung, ohne dass Sie Ihre Frage überhaupt posten müssen. Und in diesem Fall habe ich die Frage eines anderen beantwortet, aber möglicherweise auch die Antwort auf meine eigene gefunden. 
Aber nachdem ich mir NGINX Proxy Manager für 12 Sekunden oder länger angesehen habe, würde ich sagen, dass er gut funktionieren wird. Es gibt noch eine andere „automagische" NGINX-Proxy-Lösung, über die ich bereits zuvor gelesen habe, aber aufgrund meines umfassenden Wissens über NGINX Proxy Manager denke ich, dass diese möglicherweise besser ist. Ich werde mir das vielleicht genauer ansehen, da ich zunehmend an Traefik desillusioniert bin.
tot.
). Kurz gesagt, alles lief wie geplant. Anschließend habe ich die Änderungen vorgenommen, damit Discourse mit Websockets funktioniert – auch diesmal lief alles problemlos. Glücklicherweise hatte die vorherige Discourse-Installation automatische Backups erstellt, sodass ich mit nur wenigen Klicks alles wiederherstellen konnte (je mehr ich Discourse nutze, desto mehr liebe ich es!).