EDIT: @pfaffman reescribió esto como un tema independiente a partir de lo que @tophee había escrito anteriormente. Aún no lo he probado, y he movido las palabras de Chris, por lo que cualquier error probablemente sea de @pfaffman.
¿Hay alguna razón para no usar NGINX Proxy Manager en lugar de hacerlo manualmente como se describe en Run other websites on the same machine as Discourse?
Ya lo estoy usando. Lo he tenido en mi servidor doméstico durante un tiempo y, cuando migré mi instancia de Discourse a un nuevo servidor en la nube, me di cuenta de que había olvidado la mayor parte de la configuración del proxy inverso de NGINX que hice hace 4 años en el servidor antiguo, así que pensé: ¿por qué no hacerlo con NGINX Proxy Manager? Para mi sorpresa, descubrí que se ha mencionado bastante raramente aquí en meta, por lo que empecé a preguntarme si había algunas desventajas que podría haber pasado por alto…
En efecto, esto requirió un poco de prueba y error, pero logré que funcionara de la siguiente manera (sin garantía de que esta sea la mejor manera de hacerlo; de hecho, sé que debe haber una mejor manera, así que las correcciones y mejoras son muy bienvenidas):
Para empezar, hay dos formas de acceder a tu instancia de Discourse: 1. exponiendo un puerto, 2. a través de un websocket. Creo que aprendí en algún lugar de este foro que el websocket es más rápido/más eficiente, así que es lo que estoy usando, pero exponer un puerto debería ser mucho más fácil, así que si no puedes hacer que el socket funcione, prueba exponiendo un puerto. Entonces, para evitar confusiones: para acceder a Discourse a través de un puerto, sigue los pasos 0, 1, 2, 3, 4 y 8 a continuación. Si quieres usar un websocket, sigue los pasos 0, 1, 5, 6, 7, 8 y 9.
0. Punto de partida
Así que asumamos que has completado la instalación estándar de 30 minutos y asumamos que no dejaste que Discourse obtuviera un certificado de Let’s Encrypt todavía, porque no lo necesitas cuando usas un proxy inverso. NGINX Proxy Manager se encargará de eso. No importa, sin embargo, si ya tienes un certificado. NGINX Proxy Manager simplemente obtendrá uno nuevo.
1. Instalar NGINX Proxy Manager
El siguiente paso es instalar NGINX Proxy Manager para que tengas dos contenedores Docker más en ejecución (NGINX Proxy Manager y su contenedor de base de datos).
A continuación está la parte complicada de la que estás preguntando.
El primer obstáculo es que Discourse se ejecuta en la red bridge predeterminada de Docker, mientras que NGINX Proxy Manager se ejecuta por defecto en una “red creada por el usuario” predeterminada (llamada npm_default en mi caso), lo que significa que NGINX Proxy Manager no puede ver Discourse. 
2. Traer todos los contenedores a la red bridge predeterminada
Así que mientras no sé si y cómo Discourse puede moverse a una red personalizada, tenemos que mover NGINX Proxy Manager a la red bridge predeterminada. Podemos hacer esto agregando network_mode: bridge a ambos contenedores de NGINX Proxy Manager en nuestro archivo docker compose.
3. Usar la dirección IP en lugar del nombre del servicio
El siguiente problema es que el archivo docker compose estándar ya no funcionará si simplemente lo mueves a la red bridge. NGINX Proxy Manager ya no podrá encontrar su contenedor de base de datos. Esto se debe a que la resolución DNS interna para nombres de servicio (en la que se basa el archivo docker-compose) solo está disponible en redes creadas por el usuario, no en las redes predeterminadas de Docker. Así que tenemos que recurrir a direcciones IP codificadas (lo cual es definitivamente no la solución óptima porque se romperá si las direcciones IP de tus contenedores cambian). Entonces necesitas iniciar el contenedor aunque sepas que no funcionará, anota la IP del contenedor de base de datos de NGINX Proxy Manager y reemplaza DB_MYSQL_HOST: "db" en tu archivo docker compose con DB_MYSQL_HOST: "<ip_del_contenedor_db>".
Ahora todos los contenedores deberían estar en la red bridge predeterminada para que NGINX Proxy Manager pueda ver tanto Discourse como su base de datos.
4. Hacer Discourse accesible
Pero “ver” Discourse y poder acceder a él no es lo mismo. Así que necesitas asegurarte de que Discourse acepte cualquier tráfico que NGINX Proxy Manager le reenvíe. Si no te importa usar el websocket, supongo que puedes simplemente apuntar NGINX Proxy Manager al puerto 80 (no 443) de la IP de tu contenedor de Discourse, así:
No lo he probado, sin embargo. Como mencioné, estoy usando la configuración de websocket, que requiere algunos pasos adicionales. Ten en cuenta que el nombre de host/IP y el puerto anteriores se ignorarán cuando uses el websocket.
5. Configurar app.yml para usar websocket
Esto está explicado en el OP, así que no entraré en detalles.
6. Montar el websocket en el contenedor de NGINX Proxy Manager
Necesitamos dar a NGINX Proxy Manager acceso al websocket montándolo como un volumen: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. Este es el último cambio en el archivo docker compose predeterminado de NGINX Proxy Manager, así que aquí está la versión final que funciona para mí:
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. Configurar NGINX Proxy Manager para usar el websocket
Último paso: decirle a NGINX Proxy Manager que use el websocket. Por lo que recuerdo, no fue suficiente solo activar “Soporte de Websockets”, así que copié la ubicación de NGINX del OP a la pestaña “Avanzado”, así:
No logré que esto funcionara bajo la pestaña “Ubicaciones personalizadas”.
8. No olvides activar SSL
No mencioné la configuración SSL en NGINX Proxy Manager porque parece bastante obvio y no creo que importe en qué punto del proceso lo actives. Así que si aún no lo has hecho, así es como se ve el mío:
9. Aviso
tl;dr Cada vez que reinicies el contenedor de Discourse, también necesitarás reiniciar el contenedor principal de NGINX Proxy Manager (no es necesario reiniciar la base de datos).
Si estás accediendo a Discourse a través del websocket, debes ser consciente de que cuando reconstruyas tu contenedor de Discourse (como se requiere cada pocos meses para actualizar la imagen base), el websocket anterior se eliminará y se creará uno nuevo. Como consecuencia, NGINX Proxy Manager perderá el contacto con tu instancia de Discourse y arrojará un error 502. Tal vez una futura actualización de NGINX Proxy Manager podrá encontrar el nuevo websocket automáticamente, pero actualmente (enero de 2022) NGINX Proxy Manager no encontrará tu contenedor de Discourse reconstruido a menos que reinicies NGINX Proxy Manager.
Explicación
Si te preguntas por qué las instrucciones anteriores combinan el websocket con los puertos, la razón simple es que, mientras escribía este post, de repente se me ocurrió que NGINX Proxy Manager y Discourse probablemente ni siquiera necesitan estar en la misma red Docker cuando usamos el websocket. Y cuando esto fue confirmado, nadie sintió ganas de reescribir completamente las instrucciones.
Este es el aspecto más fascinante de los foros de soporte: hacer un buen trabajo describiendo tu problema a menudo te lleva a la solución sin siquiera publicar tu pregunta. Y en este caso, estaba respondiendo a la pregunta de otra persona pero también podría haber encontrado la respuesta a la mía. 
Pero después de mirar NGINX Proxy Manager durante 12 segundos o más, creo que funcionará bien. También he visto discutir antes otra herramienta automática de proxy NGINX, pero con mi extenso conocimiento de NGINX Proxy Manager, creo que esta podría ser mejor. Podría echarle un vistazo, ya que estoy perdiendo el interés en Traefik.
está muerto.
), en resumen, todo salió bien. Luego, hice la modificación para que Discourse funcione con websockets: todo bien también esta vez. Afortunadamente, la configuración anterior de Discourse realizó copias de seguridad automáticas, así que con solo unos pocos clics restauré todo (¡cuanto más uso Discourse, más me encanta!).