EDIT: @pfaffman ha riscritto questo come un argomento autonomo partendo da quanto scritto in precedenza da @tophee. Non è ancora stato testato da me e ho spostato le parole di Chris, quindi eventuali errori sono probabilmente di @pfaffman.
Ci sono motivi per non utilizzare NGINX Proxy Manager invece di farlo manualmente come descritto in Run other websites on the same machine as Discourse?
Io lo sto già utilizzando. Lo ho avuto sul mio server domestico per un po’ e quando ho migrato la mia istanza di Discourse su un nuovo server cloud, ho realized che avevo dimenticato la maggior parte della configurazione del reverse proxy NGINX che avevo fatto 4 anni fa sul vecchio server, quindi ho pensato: perché non farlo con NGINX Proxy Manager? A mia sorpresa, ho scoperto che è stato menzionato piuttosto raramente qui su Meta, così ho iniziato a chiedermi se ci fossero degli svantaggi che potessi aver trascurato…
Infatti, questo ha richiesto un po’ di tentativi ed errori, ma sono riuscito a farlo funzionare come segue (nessuna garanzia che questo sia il modo migliore per farlo - anzi, so che deve esserci un modo migliore - quindi correzioni e miglioramenti sono molto benvenuti):
Per iniziare, ci sono due modi per accedere alla tua istanza di Discourse: 1. esponendo una porta, 2. tramite websocket. Credo di aver letto da qualche parte su questo forum che il websocket è più veloce/più efficiente, quindi è quello che sto usando, ma esporre una porta dovrebbe essere molto più semplice, quindi se non riesci a far funzionare il socket, prova a esporre una porta. Quindi, per evitare confusione: per accedere a Discourse tramite una porta, segui i passaggi 0, 1, 2, 3, 4 e 8 riportati di seguito. Se vuoi usare un websocket, segui i passaggi 0, 1, 5, 6, 7, 8 e 9.
0. Punto di partenza
Quindi, supponiamo di aver completato l’installazione standard di 30 minuti e supponiamo che non hai ancora lasciato che Discourse acquisisse un certificato Let’s Encrypt - perché non ne hai bisogno quando usi un reverse proxy. NGINX Proxy Manager se ne occuperà. Non importa, comunque, se hai già un certificato. NGINX Proxy Manager ne otterrà semplicemente uno nuovo.
1. Installa NGINX Proxy Manager
Il prossimo passo è installare NGINX Proxy Manager in modo da avere due contenitori Docker in esecuzione in più (NGINX Proxy Manager e il suo contenitore del database).
Ora viene la parte difficile a cui stai chiedendo.
Il primo ostacolo è che Discourse viene eseguito sulla rete bridge predefinita di Docker, mentre NGINX Proxy Manager viene eseguito di default su una rete “creata dall’utente” (chiamata npm_default nel mio caso), il che significa che NGINX Proxy Manager non può vedere Discourse. 
2. Porta tutti i contenitori nella rete bridge predefinita
Quindi, finché non so se e come Discourse possa essere spostato su una rete personalizzata, dobbiamo spostare NGINX Proxy Manager nella rete bridge predefinita. Possiamo farlo aggiungendo network_mode: bridge a entrambi i contenitori di NGINX Proxy Manager nel nostro file docker compose.
3. Usa l’indirizzo IP invece del nome del servizio
Il prossimo problema è che il file docker compose standard non funzionerà più se lo sposti semplicemente sulla rete bridge. NGINX Proxy Manager non sarà più in grado di trovare il suo contenitore del database. Questo perché la risoluzione DNS interna per i nomi dei servizi (su cui si basa il file docker-compose) è disponibile solo sulle reti create dall’utente, non sulle reti Docker predefinite. Quindi dobbiamo ricorrere a indirizzi IP codificati a mano (ed è per questo che questa non è certamente la soluzione ottimale, perché si romperà se gli indirizzi IP dei tuoi contenitori cambiano). Quindi devi avviare il contenitore anche se sai che non funzionerà, annota l’IP del contenitore del database di NGINX Proxy Manager e sostituisci DB_MYSQL_HOST: "db" nel tuo file docker compose con DB_MYSQL_HOST: "<ip_del_contenitore_db>".
Quindi ora tutti i contenitori dovrebbero essere sulla rete bridge predefinita in modo che NGINX Proxy Manager possa vedere sia Discourse che il suo database.
4. Rendi Discourse accessibile
Ma “vedere” Discourse e poterlo accedere non è la stessa cosa. Quindi devi assicurarti che Discourse accetti tutto il traffico che NGINX Proxy Manager inoltra ad esso. Se non ti importa di usare il websocket, suppongo che tu possa semplicemente puntare NGINX Proxy Manager alla porta 80 (non 443) dell’IP del tuo contenitore Discourse, così:
Non l’ho testato, però. Come ho detto, sto usando la configurazione websocket, che richiede alcuni passaggi aggiuntivi. Nota che il nome host/IP e la porta sopra verranno ignorati quando usi il websocket.
5. Configura app.yml per usare il websocket
Questo è spiegato nell’OP, quindi non entrerò nei dettagli.
6. Monta il websocket nel contenitore NGINX Proxy Manager
Dobbiamo dare a NGINX Proxy Manager accesso al websocket montandolo come volume: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. Questa è l’ultima modifica al file docker compose predefinito di NGINX Proxy Manager, quindi ecco la versione finale che funziona per me:
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. Configura NGINX Proxy Manager per usare il websocket
Ultimo passaggio: dì a NGINX Proxy Manager di usare il websocket. Per quanto ne ricordo, non era sufficiente attivare solo “Supporto Websockets”, quindi ho copiato la posizione NGINX dall’OP alla scheda “Avanzate”, così:
Non sono riuscito a farlo funzionare sotto la scheda “Posizioni personalizzate”.
8. Non dimenticare di attivare SSL
Non ho menzionato la configurazione SSL in NGINX Proxy Manager perché sembra abbastanza ovvia e non penso che importi in quale punto del processo la attivi. Quindi, se non l’hai ancora fatto, ecco com’è la mia:
9. Avviso
tl;dr Ogni volta che riavvii il contenitore Discourse, devi anche riavviare il contenitore principale di NGINX Proxy Manager (non c’è bisogno di riavviare il db).
Se stai accedendo a Discourse attraverso il websocket, devi essere consapevole che quando ricompili il tuo contenitore Discourse (come richiesto ogni pochi mesi per aggiornare l’immagine base), il websocket precedente verrà eliminato e ne verrà creato uno nuovo. Di conseguenza, NGINX Proxy Manager perderà il contatto con la tua istanza Discourse e restituirà un errore 502. Forse un futuro aggiornamento di NGINX Proxy Manager sarà in grado di trovare automaticamente il nuovo websocket, ma attualmente (gennaio 2022) NGINX Proxy Manager non troverà il tuo contenitore Discourse ricompilato a meno che tu non riavvii NGINX Proxy Manager.
Spiegazione
Se ti chiedi perché le istruzioni sopra combinano il websocket con le porte, la ragione semplice è che, mentre scrivevo questo post, mi è venuto in mente all’improvviso che NGINX Proxy Manager e Discourse probabilmente non hanno nemmeno bisogno di essere sulla stessa rete Docker quando usiamo il websocket. E quando ciò è stato confermato, nessuno si è sentito di riscrivere completamente le istruzioni.
Questo è l’aspetto più affascinante dei forum di supporto: fare un buon lavoro nel descrivere il tuo problema spesso ti porta alla soluzione senza nemmeno pubblicare la tua domanda. E in questo caso, stavo rispondendo alla domanda di qualcun altro, ma potrei aver trovato anche la risposta alla mia. 
Ma dopo aver guardato NGINX Proxy Manager per 12 secondi o più, penso che farà il suo dovere. Esiste anche un’altra soluzione “automagica” per NGINX proxy di cui ho visto parlare in passato, ma con la mia estesa conoscenza di NGINX Proxy Manager, penso che questa possa essere migliore. Potrei darci un’occhiata, dato che sto perdendo interesse in Traefik.
è morto. Esiste un modo per risolvere questo problema di Postgres? Perché è successo? C’è la possibilità (temo di no!) di non perdere tutte le modifiche che ho apportato a Discourse quando funzionava? A proposito, è normale che ogni piccola modifica o tentativo di risolvere qualcosa finisca con qualcos’altro che smette di funzionare? 
Non sono arrabbiato con te; il problema è tutto Discourse, non i tuoi suggerimenti: ho dedicato molto tempo a cercare di far funzionare questo forum “apparentemente” bello, ma ogni volta c’è qualcosa che va storto, e la mia sensazione che Discourse sia poco affidabile sta diventando sempre più forte.
), insomma, tutto è andato per il verso giusto. Poi ho apportato le modifiche necessarie per far funzionare Discourse con i WebSocket: anche questa volta tutto è andato bene. Fortunatamente, la configurazione precedente di Discourse aveva eseguito backup automatici, quindi con pochi clic ho ripristinato tutto (più uso Discourse, più lo amo!).