Tatsächlich benötigte dies etwas Probieren, 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):
Anweisungen, die @pfaffman in den OP verschoben hat
Zunächst 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 gelesen, dass WebSocket schneller/effizienter ist, daher verwende ich dies. Das Freigeben eines Ports sollte jedoch viel einfacher sein. Wenn Sie also den Socket nicht zum Laufen bekommen, versuchen Sie es mit dem Freigeben eines Ports (mehr dazu weiter unten).
Nehmen wir also an, Sie haben die 30-minütige Standardinstallation abgeschlossen und nehmen wir an, Sie haben Discourse noch kein Let’s Encrypt-Zertifikat erteilen lassen – denn Sie benötigen keines, wenn Sie einen Reverse-Proxy verwenden. NPM kümmert sich darum. Es ist jedoch egal, ob Sie bereits ein Zertifikat haben. NPM wird einfach ein neues beantragen.
1. NPM installieren
Der nächste Schritt ist die Installation von NPM, damit zwei weitere Docker-Container laufen (NPM und sein Datenbank-Container).
Nun kommt der knifflige Teil, den Sie angesprochen haben.
Das erste Hindernis ist, dass Discourse im standardmäßigen Docker-bridge-Netzwerk läuft, während NPM standardmäßig in einem benutzerdefinierten Netzwerk (in meinem Fall npm_default genannt) läuft. Das bedeutet, dass NPM 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 NPM in das Standard-bridge-Netzwerk verschieben. Dies können wir erreichen, indem wir network_mode: bridge zu beiden NPM-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. NPM 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 hartkodierte IP-Adressen verlassen (was bedeutet, dass dies definitiv keine optimale Lösung ist, da sie fehlschlägt, wenn sich die IP-Adressen Ihrer Container ändern). Sie müssen den Container also starten, auch wenn Sie wissen, dass er nicht funktionieren wird, notieren Sie sich die IP des NPM-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, sodass NPM sowohl Discourse als auch dessen Datenbank sehen kann.
4. Discourse erreichbar machen
Aber Discourse „sehen" und darauf zugreifen können, ist nicht dasselbe. Sie müssen also sicherstellen, dass Discourse den gesamten Verkehr akzeptiert, den NPM an ihn weiterleitet. Wenn es Ihnen egal ist, WebSocket zu verwenden, können Sie NPM einfach auf Port 80 (nicht 443) der Discourse-Container-IP zeigen, wie folgt:
Ich habe dies jedoch nicht getestet. Wie erwähnt, verwende ich das WebSocket-Setup, was weitere Schritte erfordert. Beachten Sie, dass der oben genannte Hostname/IP und Port ignoriert werden, wenn Sie WebSocket verwenden.
5. app.yml so konfigurieren, dass WebSocket verwendet wird
Dies ist im OP erklärt, daher gehe ich nicht näher darauf ein.
6. WebSocket im NPM-Container mounten
Wir müssen NPM Zugriff auf den WebSocket gewähren, indem wir ihn als Volume mounten: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. Dies ist die letzte Änderung an der Standard-NPM-Docker-Compose-Datei. Hier ist also 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. NPM so konfigurieren, dass es den WebSocket verwendet
Letzter Schritt: Weisen Sie NPM an, den WebSocket zu verwenden. Soweit ich mich erinnere, reichte es nicht aus, nur „WebSocket-Unterstützung" einzuschalten. Daher habe ich den NGINX-Standort aus dem OP in den Reiter „Erweitert" kopiert, wie folgt:
Ich habe dies im Reiter „Benutzerdefinierte Standorte" nicht zum Laufen gebracht.
8. Vergessen Sie nicht, SSL zu aktivieren
Ich habe die SSL-Konfiguration in NPM nicht erwähnt, da sie ziemlich selbsterklärend 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. Abschließender Hinweis
Als ich diesen Beitrag schrieb, fiel mir plötzlich ein, dass NPM und Discourse wahrscheinlich gar nicht im selben Docker-Netzwerk sein müssen, wenn wir den WebSocket verwenden. Ich habe derzeit keine Zeit, dies zu überprüfen, aber wenn dies zutrifft, können Sie einfach die Schritte 2, 3 und 4 oben vergessen, und es sollte funktionieren.
Das ist der faszinierendste Aspekt von Support-Foren: Wenn man seine Probleme gut beschreibt, führt das oft zur Lösung, ohne dass man die Frage überhaupt gestellt hat. In diesem Fall habe ich die Frage einer anderen Person beantwortet, aber möglicherweise auch die Antwort auf meine eigene gefunden. 