In effetti, questo ha richiesto un po’ di prove ed errori, ma sono riuscito a farlo funzionare come segue (nessuna garanzia che questo sia il modo migliore per farlo - anzi, so che deve essercene uno migliore - quindi correzioni e miglioramenti sono molto graditi):
Istruzioni spostate nell'OP da @pfaffman
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/migliore, 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 (altro su questo più avanti).
Quindi, assumiamo di aver completato l’installazione standard di 30 minuti e di non aver ancora lasciato che Discourse acquisisse un certificato Let’s Encrypt, perché non è necessario quando si utilizza un proxy inverso. NPM se ne occuperà. Non importa comunque se hai già un certificato; NPM ne otterrà semplicemente uno nuovo.
1. Installa NPM
Il prossimo passo è installare NPM in modo da avere due contenitori Docker aggiuntivi in esecuzione (NPM e il suo contenitore di database).
Ora arriva la parte complicata su cui hai chiesto.
Il primo ostacolo è che Discourse viene eseguito sulla rete bridge predefinita di Docker, mentre NPM di default viene eseguito su una rete “creata dall’utente” (nel mio caso chiamata npm_default), il che significa che NPM non può vedere Discourse. 
2. Portare tutti i contenitori nella rete bridge predefinita
Quindi, finché non so se e come Discourse possa essere spostato su una rete personalizzata, dobbiamo spostare NPM nella rete bridge predefinita. Possiamo farlo aggiungendo network_mode: bridge a entrambi i contenitori NPM nel nostro file docker compose.
3. Utilizzare 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. NPM non sarà più in grado di trovare il suo contenitore di 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 è sicuramente 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à, annotare l’IP del contenitore del database NPM e sostituire DB_MYSQL_HOST: "db" nel tuo file docker compose con DB_MYSQL_HOST: "<db_container_IP>".
Ora tutti i contenitori dovrebbero essere sulla rete bridge predefinita in modo che NPM possa vedere sia Discourse che il suo database.
4. Rendere Discourse accessibile
Ma “vedere” Discourse e poterlo accedere non è la stessa cosa. Quindi devi assicurarti che Discourse accetti tutto il traffico che NPM inoltra verso di esso. Se non ti importa di utilizzare il websocket, suppongo che tu possa semplicemente puntare NPM alla porta 80 (non 443) dell’IP del tuo contenitore Discourse, come questo:
Non l’ho ancora testato. 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 si utilizza il websocket.
5. Configurare app.yml per utilizzare il websocket
Questo è spiegato nell’OP, quindi non ci entrerò.
6. Montare il websocket nel contenitore NPM
Dobbiamo dare a NPM 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 NPM predefinito, 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. Configurare NPM per utilizzare il websocket
Ultimo passo: dire a NPM di utilizzare il websocket. Per quanto ricordo, non era sufficiente attivare semplicemente il “Supporto Websockets”, quindi ho copiato la posizione NGINX dall’OP alla scheda “Avanzate”, come questo:
Non sono riuscito a farlo funzionare sotto la scheda “Posizioni personalizzate”.
8. Non dimenticare di attivare SSL
Non ho menzionato la configurazione SSL in NPM perché sembra abbastanza ovvia e non penso che importi in quale punto del processo venga attivata. Quindi, se non l’hai ancora fatto, ecco come appare la mia:
9. Disclaimer finale
Mentre scrivevo questo post, mi è venuto in mente all’improvviso che NPM e Discourse probabilmente non hanno nemmeno bisogno di essere sulla stessa rete Docker quando utilizziamo il websocket. Non ho tempo di verificare questo al momento, ma se è vero, allora puoi dimenticare i passaggi 2, 3 e 4 sopra e dovrebbe funzionare.
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. 