Sí y no. Hagamos un paso atrás y analicemos esto.
Antes, por lo que suena, estabas ejecutando varios sitios web con Apache. Apache escuchaba en los puertos 80 y 443 y luego “proxyaba” (redirigía) las solicitudes como “hosts virtuales”, de modo que podías ejecutar muchos sitios web en el mismo servidor, todos escuchando en los mismos puertos (80 y 443). Esto era “LAMP 101”… la forma de los hosts virtuales.
Ahora, digamos que instalas Discourse de la manera oficial OOTB (out-of-the-box). Discourse OOTB intentará vincularse a los mismos puertos y fallará porque Apache ya los está utilizando (vinculados). Tienes opciones:
- Ejecutar Discourse en un socket de dominio Unix y configurar Apache para hacer proxy inverso de la aplicación Discourse como un host virtual.
Nota: Lo he probado y funciona; pero esto no está respaldado oficialmente (ni siquiera de manera no oficial) por Discourse.
- Migrar de Apache a nginx y ejecutar todos tus servidores web desde nginx, además de hacer proxy inverso de la aplicación Discourse como un host virtual, utilizando un socket de dominio Unix para la aplicación de producción de Discourse-docker.
Nota: Esto tampoco está respaldado oficialmente por Discourse; y la mayoría de las personas que ejecutan sitios con Apache encontrarán un poco complicado migrar todo su código mod_rewrite de Apache2 y el contenido codificado de geo-ip a nginx; pero es factible, por supuesto, especialmente si tus aplicaciones están construidas tanto para nginx como para Apache2 (eso es más fácil, pero aún así no está respaldado oficialmente).
- Exponer el contenedor Docker de Discourse en puertos distintos a 80 y 443.
Nota: Esto tampoco está (realmente) recomendado (pero está respaldado oficialmente, según recuerdo). Sin embargo, la mayoría de las personas no quieren acceder a una aplicación web escribiendo números de puerto como https://mi-grande-app-discourse.org:3334, por lo que la mayoría no hace esto en producción. El desarrollo es otra historia.
Mi recomendación “sin conocer todos tus detalles”, como alguien con mucha experiencia en LAMP y ahora cada vez más en Discourse, es ejecutarlos en servidores separados (esto está respaldado oficialmente por Discourse); pero si realmente estás apretado de dinero y debes ejecutarlos todos en el mismo servidor (o simplemente te gusta tener un servidor grande y complicado), entonces necesitarás aprender a configurar Apache2 para hacer proxy inverso a un socket de dominio Unix hacia/desde la aplicación Discourse.
Lo he probado y es posible configurar Apache2 para hacer proxy inverso a Discourse utilizando un socket de dominio Unix; pero esta solución no está respaldada oficialmente (en absoluto).
Nota: El enlace para configurar Apache2 con HAProxy fue una solución que no pude hacer funcionar fácilmente; así que la abandoné (no es necesario usar solo HAProxy, hay “formas más antiguas” de hacerlo). Sin embargo, quizás te convenga más seguir este tutorial de Discourse:
Espero que esto ayude de alguna manera, @nekodroid