Discourse + servidor web. ¿Posible o mejor evitarlo?

Aviso rápido: Soy relativamente nuevo en la creación de un entorno VPS desde cero, pero tengo suficiente experiencia con alojamiento web (específicamente compartido y dedicado gestionado) como para tener una idea de lo que hago y entender los tutoriales.

Dicho esto, actualmente estoy usando el droplet más económico de DigitalOcean para experimentar. Soy un aficionado, no espero tener mucho tráfico y solo estoy tratando de crear dos instancias que ofrezcan una página principal de algún tipo (probablemente WordPress) y un foro de Discourse complementario: una instancia para diseño de juegos y otra para mi comunidad de creadores de contenido.

Sé que Discourse y Apache no funcionan bien juntos debido a la decisión de Discourse de usar el puerto 80, y también sé que existen soluciones alternativas, pero parecen haber varias formas con resultados no confirmados y sin un “sí, esto funciona” oficial por parte de Discourse.

Estoy un poco confundido sobre por qué una plataforma tan increíble ha sido diseñada para ser tan obstaculizadora al gestionar un servidor web junto a ella, pero mi experiencia con el software hasta ahora me ha interesado lo suficiente como para encontrar una manera de hacer que funcione. He visto que existe una integración con WordPress y se promociona en una página de características, pero, de nuevo, Discourse aparentemente no está diseñado para ser nada más que independiente.

¿Alguna recomendación o comentario de quienes han encontrado el mismo problema? ¡Gracias!

Creo que esto es lo que estás buscando:

@neounix tiene experiencia ejecutando Discourse con apache2, así que tal vez pueda darte algunas indicaciones.

4 Me gusta

¿Es esta una recomendación para cambiar a Nginx? No tengo absolutamente ninguna experiencia con él y cualquier servidor web que he usado, incluidos los preconfigurados, ha utilizado Apache.

También existe esto para Apache: Set up Discourse on a server with existing Apache sites

Sin embargo, parece haber un gran número de problemas para que funcione correctamente, especialmente con SSL.

¿Sería más sencillo ejecutar dos droplets, uno para el sitio web y otro específicamente para Discourse? Supongo que podría simplemente cambiar el registro DNS del subdominio para que apunte al droplet de Discourse y eso debería resolver el problema. Solo me parece extraño ejecutar dos servidores para un foro.

Hola @OrbitStorm

¡Bienvenido!

Discourse no es nada obstructivo.

Dominar la ejecución de Discourse en contenedores Docker detrás de un servidor web proxy inverso es una experiencia muy gratificante; ya sea usando Apache2 o nginx.

Si ya tienes aplicaciones funcionando detrás de Apache, ¡es fácil configurar una o incluso 100 instancias de Discourse en contenedores Docker detrás de Apache!

5 Me gusta

Agradezco la respuesta.

Lo digo con el máximo respeto, pero Discourse, tal cual viene de fábrica, requiere efectivamente su propio servidor. Usar un proxy inverso para ejecutar un servidor web en paralelo a Discourse en el mismo VPS es un acierto o un error, como lo demuestran los comentarios y otras quejas, y es posible que SSL funcione o no. Además, es prácticamente imposible tener dos instancias de Discourse en el mismo servidor. Todo eso, para mí, es un obstáculo. No hay otro software de foro, incluidas plataformas de gama alta como XenForo o Invision, que requiera ese nivel de esfuerzo con tanta incertidumbre. Son paquetes costosos, así que supongo que con Discourse obtienes lo que no pagas. Como usuario nuevo que ve todos estos obstáculos, simplemente parece que Discourse fue diseñado sin tener en cuenta nada más (es decir, otros sitios web).

Por lo que vale, como mencioné en mi publicación original, utilicé una implementación de un solo clic para Discourse. Por lo tanto, tendré que hacer todo al revés para intentar configurar Apache (o Nginx, si no encuentro un tutorial) en el mismo servidor. Si voy a usar Discourse como mi plataforma principal de foros, no me interesa ejecutar dos servidores para una sola comunidad. Eso es simplemente absurdo.

Honestamente, creo que es factible. No soy un experto y solo sigo los muy buenos guías y tutoriales que hay por ahí. Tuve pocos o ningún problema al configurar Discourse detrás de Nginx, así que probablemente he tenido un poco de suerte, pero creo que está lejos de ser imposible :slightly_smiling_face:
Me gustan estos:
https://linuxize.com/post/how-to-install-nginx-on-ubuntu-18-04/
https://linuxize.com/post/secure-nginx-with-let-s-encrypt-on-ubuntu-18-04/
Aunque quizás no sea un camino fácil añadir al conjunto multisitio/multicontenedor y la clonación de S3 :sweat_smile:

Y para la combinación Postfix/Dovecot:
https://linuxize.com/post/install-and-configure-postfix-and-dovecot/

1 me gusta

@Benjamin_D El problema que tengo es que todos los tutoriales disponibles aquí omiten algún aspecto de mi entorno actual. Hay un tutorial para Apache pero utiliza CentOS. Yo uso Ubuntu. El otro tutorial de Kane York utiliza Nginx, pero como mencioné, yo uso Apache.

Tampoco estoy haciendo nada excesivamente complejo. Solo estoy usando DigitalOcean, Linux + Ubuntu 18.04, alojando todo en el droplet (sin usar almacenamiento de terceros), etc. Estoy usando Mailgun como solución de correo, pero no creo que ofrezca una bandeja de entrada, lo cual está bien por ahora.

Solo trato de hacerlo lo más sencillo posible.

1 me gusta

@OrbitStorm

De hecho, Discourse es, en mi opinión, el mejor software de código abierto para foros y construcción de comunidades en el planeta en este momento, por muchas razones. Aquí hay algunas:

  1. Discourse es de código abierto, cuenta con una comunidad sólida y un equipo central de desarrollo muy inteligente (y capaz).

  2. Discourse está diseñado para ejecutarse en un contenedor Docker en producción, lo que ofrece muchas ventajas:

  • Discourse se puede implementar fácilmente en modo independiente sin necesidad de un servidor web o una base de datos externa.

  • Discourse se puede implementar fácilmente en modo de múltiples contenedores, lo que proporciona mayor fiabilidad y actualizaciones sin interrupciones.

  • Discourse también se puede implementar en configuraciones de alta disponibilidad utilizando Docker Swarm y Kubernetes, donde Discourse puede escalar hacia arriba y hacia abajo “bajo demanda”.

  • Discourse es fácil de respaldar y restaurar. Podemos tomar la copia de seguridad estándar de Discourse (incluida por defecto) y restaurarla en cualquier lugar del mundo en un contenedor Docker nuevo y virgen.

  1. Discourse funciona fácilmente detrás de servidores proxy inverso como Apache2 y nginx. Esto también tiene muchas ventajas, entre ellas:
  • Discourse puede ejecutarse en un servidor web existente, ya sea nginx o Apache2, con poco esfuerzo, tanto en puertos TCP/IP expuestos por Docker como en sockets de dominio UNIX.

  • Ejecutar aplicaciones basadas en la web detrás de proxies inversos es una práctica bien establecida. Esta configuración no es exclusiva de Discourse, pero Discourse brindará soporte.

  • Configurar SSL es muy sencillo detrás de un proxy inverso y puede ser tan simple como certbot -d mi.grande-discourse.site utilizando LETSENCRYPT, que es compatible y gratuito.

  1. Discourse está completamente documentado, commit a commit, en GitHub, por lo que cualquiera puede seguir los cambios en el código.

  2. Discourse tiene un modelo de negocio progresivo, que ofrece algunas ventajas clave, entre ellas:

  • Discourse, el software central y muchos excelentes complementos, temas y componentes, son gratuitos.

  • Discourse ofrece soporte gratuito, incluido el soporte de configuración estándar, en meta.

  • Discourse ofrece alojamiento comercial para aquellos que no desean autoalojarse o prefieren una gestión más “sin intervención”.

  • Discourse fomenta la consultoría comercial y el desarrollo de complementos en su comunidad, creando un ecosistema empresarial viable.

  1. Hay más, pero quiero cerrar esto.

¿Estamos (o estamos) de acuerdo con cada decisión tomada por el equipo central de Discourse, y ellos están de acuerdo con todas nuestras (o mis) ideas y sugerencias?

No, por supuesto que no; y no deberían estarlo, ni nosotros, ni yo. Somos libres de sugerir, enviar sugerencias de código, PRs, y el equipo central de Discourse abordará estas sugerencias con mente abierta.

Pero al final del día, el equipo central debe mantener a la comunidad de Discourse avanzando en una dirección cohesiva, lo cual no es fácil cuando cientos de personas de diferentes culturas desean una configuración diferente y tienen prioridades, modelos de negocio e ideas distintas.

En otras palabras, no hay nada que “evitar” (palabras del título de tu tema) en Discourse, especialmente configurar proxies inversos y dominar Docker. Muchos (incluido yo) nos estamos mudando a Kubernetes gracias a Discourse, no solo para Discourse, sino también para otras aplicaciones web.

Discourse es lo “más alejado” de ser “obstructivo” (de nuevo, tus palabras, no las mías); y debido a que está basado en contenedores, por diseño, “el cielo es el límite” para cómo los administradores de sistemas experimentados pueden implementar Discourse en entornos de producción altamente escalables; y también es lo suficientemente sencillo para que los principiantes puedan implementarlo fácilmente en modo independiente.

¿Necesito decir más?

Como dice la canción de REM (Losing My Religion):

Oh no, he dicho demasiado, lo he montado

Cerrando este tema… ¡Mucha suerte @OrbitStorm

2 Me gusta

Si entiendo correctamente, lo que deseas es que nginx escuche y redirija un subdominio a Apache por un lado, y otro subdominio al contenedor donde está Discourse por el otro (configurado exponiendo el puerto correcto en app.yml o utilizando la plantilla web.socketed), ¿o estás usando Apache como proxy?

Creo que en el tutorial de CentOS se usa nginx en lugar de HAProxy :thinking:

Cerca, pero no. Para reiterar: estoy en Linux + Ubuntu 18.04. Estoy usando Apache para servir un sitio web HTML estándar (WordPress en el futuro) y tengo Discourse instalado en un subdominio. Solo necesito averiguar cómo configurar un proxy inverso (según estos tutoriales) que redirija el tráfico desde los puertos 80 y 443 a nuevos puertos, ya que Apache ya utiliza ambos. No me interesa usar Nginx porque no tengo experiencia con él y no quiero agregarlo a Apache y hacer que mi configuración sea aún más compleja.

No soy un desarrollador avanzado. Solo soy una persona con un dominio fluido del frontend, un conocimiento básico de paneles, un conocimiento limitado de SSH y, básicamente, ningún conocimiento de todo lo demás (por eso estoy usando tutoriales).

Mi objetivo final es tener dos dominios con una página principal respectiva y múltiples instancias de Discourse (una para cada sitio web). Cosas sencillas.

1 me gusta

No estoy seguro si es más complejo usar Apache como servidor y proxy que empaquetar nginx o HAproxy :sweat_smile:
Sobre el tutorial, CentOS o Ubuntu no deberían marcar mucha diferencia, apt en lugar de yum,
https://support.cloudflare.com/hc/en-us/articles/360029696071-Restoring-original-visitor-IPs-Option-2-Installing-mod-remoteip-with-Apache en lugar de

¿Puedo sugerir esto para Apache como proxy inverso?

1 me gusta

Si quieres que tu vida sea fácil, ejecuta Discourse en un droplet dedicado. Realmente no puedes ejecutar Discourse y Apache en un droplet de 1 GB, así que usar dos droplets de 1 GB ni siquiera cuesta más.

2 Me gusta

@pfaffman Mi intención nunca fue quedarme en el droplet más pequeño; solo lo estoy usando mientras configuro todo. No tiene sentido pagar una tarifa horaria mayor mientras experimento.

La única razón por la que no me agrada la idea de ejecutar dos droplets es porque probablemente tendré que migrar de 3 a 4 dominios diferentes a DigitalOcean. No quiero estar pagando por 6 u 8 droplets. Eso es una locura.

Si quieres más de 3 sitios de Discourse, probablemente quieras configurar un multisitio. Tengo una configuración que uso con Traefik, aunque estoy investigando otros proxies inversos.

Si estás usando Apache y deseas tener varios sitios independientes, el término de búsqueda relevante es VirtualHost.

4 Me gusta

Con un droplet pequeño, es posible que desees reducir los buffers. Mi droplet tiene 4 GB de memoria y 4 núcleos compartidos.

2 Me gusta

Pude encontrar una solución gracias a Bobbyiliev de DigitalOcean.

Puedes encontrar esa solución aquí: Discourse not loading with Apache and proxy redirect - #8 by OrbitStorm

3 Me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.