Después de pasar una semana buscando una solución para instalar Discourse junto con Apache, me veo obligado a pedir consejo sobre mis próximos pasos, ya que parece que activar un certificado SSL para Discourse detrás de Apache es prácticamente imposible, dado el diseño de Discourse orientado a Nginx.
Estructura actual de mi entorno de alojamiento:
Droplet de Digital Ocean de 10 dólares
Ubuntu 18.04
Apache con SSL de Let’s Encrypt para la página principal HTML
PHP, MySQL y phpMyAdmin
Webmin (sin SSL)
Discourse
Me gustaría mantener la flexibilidad de instalar WordPress, por lo que no estoy convencido de que Nginx sea la mejor opción, ya que he leído que Apache mantiene una mejor compatibilidad con WordPress.
Mi objetivo: activar un certificado SSL en todo mi dominio, incluido Discourse, sin necesidad de migrar Discourse a su propio droplet. Si esto requiere un uso limitado de Nginx, no hay problema. Solo necesito saber qué tutoriales consultar para resolver este caos.
Estoy buscando algo similar, pero ustedes llevan la ventaja en el proceso. Tengo algunas dudas sobre su configuración, si no les importa responderlas.
¿Tienen un proxy inverso?
¿El proxy inverso maneja SSL?
¿Los otros servidores no usan SSL y dependen del proxy inverso para gestionarlo, o están aplicando defensa en profundidad con cada servidor manejando su propio SSL?
¿La comunicación entre el proxy inverso y los servidores se realiza exclusivamente mediante sockets y no mediante puertos?
Por si acaso, he realizado pruebas extensas con Apache2 y nginx como proxies inversos frente a Discourse en producción (usando sockets Unix) y nginx no es “mucho más rápido”.
En esta configuración, nginx es “ligeramente más rápido” y la diferencia de velocidad no es perceptible para el usuario.
Además, las pruebas de Google PageSpeed en las herramientas para webmasters (Lightspeed), promediadas en el tiempo, no muestran diferencias significativas entre los dos proxies inversos.
Este comentario, por si acaso, no se basa en la teoría ni en repetir lo que otros han escrito; se basa en pruebas reales en producción.
Hacemos funcionar todas nuestras instancias de Discourse detrás de proxies inversos Apache2 (originalmente eran proxies inversos nginx) porque nos gusta ejecutar muchos sitios web (hosting virtual) en nuestros servidores donde ya tenemos aplicaciones LAMP alojadas.
¡Cualquiera que quiera usar Apache2 como proxy inverso en lugar de nginx estará perfectamente bien! Este hecho hace que Discourse esté fácilmente disponible para una amplia base de usuarios y servidores (Apache2 y nginx).
@fzngagan No estoy empezando de cero y ese tutorial es para CentOS, cuando claramente indiqué en mi publicación que estoy usando Ubuntu.
@EricGT Mira la solución que compartí en mi propio hilo, porque encontrar soporte si usas algo distinto de Nginx o CentOS es prácticamente imposible, como lo demuestra este hilo donde no he recibido respuestas a mi pregunta, sino un debate fuera de tema sobre Apache versus Nginx.
Eso puede ser cierto, pero Apache tiene un soporte más amplio. Discourse es el único software de foros que esencialmente obliga a sus usuarios a usar Nginx. Por eso prefiero mantenerme con Apache porque es más común, más fácil para usuarios nuevos y el soporte será mucho más sencillo de encontrar. La “optimización” no es algo que me interese.
Sin embargo, la comunidad de Discourse lo desalienta activamente y se niega a brindar soporte a quienes desean hacerlo, con la excepción de enlazar tutoriales no respaldados. He creado múltiples hilos y hecho aún más preguntas, pero eres el único que se ha acercado remotamente a brindar soporte (en otro hilo) compartiendo tu configuración, y como novato se esperaba que yo la descifrara y la aplicara a mi caso. Todo lo demás ha sido “mira este tutorial desactualizado” o charlas fuera de tema.
Bueno, como hemos declarado claramente en varias ocasiones, hay un límite en lo que podemos ofrecer de forma gratuita aquí debido a limitaciones de tiempo y salud mental. Por eso contamos con una instalación estandarizada que funciona bien para el 95% de las personas que la prueban, y brindamos soporte completo para esa opción.
Si deseas explorar opciones de soporte pagado para instalaciones personalizadas, te recomendamos visitar Marketplace.
Este foro funciona principalmente de igual a igual, por lo que tu afirmación no tiene ningún sentido. Además, aún no he planteado ninguna pregunta compleja, solo pido aclaraciones o actualizaciones de tutoriales existentes que se siguen enlazando continuamente a pesar de estar desactualizados o ser incorrectos. Tuve que pedir ayuda a DigitalOcean, un proveedor de alojamiento, para configurar un proxy inverso adecuado. Eso es increíble, incluso para software de código abierto.
Tu respuesta me da la impresión de que el “soporte” aquí es simplemente una farsa para vender más.
En primer lugar, utilizamos Discourse en producción detrás de un proxy inverso Apache2 (en más de una instancia) y no tuvimos ningún problema al configurarlo; más allá de lo normal: “buscar en Google cuando necesitas ayuda”, algo que todos hacen sin dudarlo.
En segundo lugar, nunca he pedido al equipo de Discourse ni a nadie en meta que brinde soporte para Apache2 como nuestro proxy inverso, ya que esta configuración no está oficialmente soportada. Discourse no (que yo sepa) “oficialmente” soporta configuraciones multi-contenedor, proxies inversos (Apache2), Kubernetes, Docker Swarm y un número casi infinito de otras configuraciones. Es comprensible y correcto que el equipo de Discourse, que ofrece este gran software de forma gratuita y hace público todo el código, cada commit en Github, limite sus “configuraciones oficialmente soportadas”. Creo que Jeff lo resumió de manera muy acertada:
Bueno, como claramente hemos indicado varias veces, hay un límite para lo que podemos ofrecer de forma gratuita aquí debido a restricciones de tiempo y cordura. - Jeff A.
En tercer lugar, Discourse proporciona varios tutoriales para configuraciones “no soportadas”, como el uso de Apache2 como proxy inverso; sin embargo, configurar un proxy inverso no es una “tarea de Discourse” en sí misma. Configurar un proxy inverso es una “tarea genérica de administración de sistemas” que es básicamente la misma para cualquier aplicación de backend, incluido Discourse.
Ejecutamos Apache como proxy inverso frente a varias aplicaciones web, incluidas Discourse, Docker Registry y otros contenedores y aplicaciones de Docker. El uso de Apache2 (o nginx) como proxy inverso no es específico de Discourse. Es una tarea genérica de administración de sistemas.
En cuarto lugar, existe una gran cantidad de información en internet sobre cómo configurar Apache2 como proxy inverso para una aplicación. Es totalmente innecesario y poco útil para tu causa, intimidar al equipo de Discourse por este tema. Intimidar a las personas y usar términos como “farsa” es tanto inexacto como poco útil para tu causa (o para cualquiera aquí).
Así que, para resumirte @OrbitStorm (este es mi último mensaje en tu tema, así que por favor léelo con atención), lo que se ha dicho antes, incluidas las amables y pacientes palabras de J. A., es que tienes muchas opciones.
Puedes ir fácilmente a internet y aprender a configurar Apache2 como proxy inverso (esto es lo que hicimos), y es divertido y gratuito para ti aprender a realizar esta tarea genérica de administración de sistemas.
Puedes contratar a alguien para que lo haga por ti si no estás dispuesto a aprender, o no puedes “descifrarlo” por tu cuenta o no tienes tiempo.
Puedes publicar aquí, quejarte y gritar, llamando a meta y a este foro una “farsa” y lanzando insultos a todos para intentar intimidarlos y que te apoyen personalmente en una configuración no soportada.
Recomiendo encarecidamente, como usuario de Discourse y administrador de sistemas con varias décadas de experiencia, que no elijas la opción #3 (la intimidación y el acoso no funcionarán con el equipo de meta, esto te lo puedo asegurar); y que consideres la #1 si no quieres gastar dinero en ayuda.
Configurar Apache2 como proxy inverso para Discourse es realmente bastante sencillo. Hay algunos mensajes en Discourse meta sobre esto (algunos actuales, otros antiguos) y hay innumerables tutoriales en internet sobre cómo configurar Apache2 como proxy inverso para una aplicación web. La técnica es la misma. Recomiendo exponer un socket Unix al ejecutar en modo proxy inverso.
Honestamente, es divertido configurar Apache2 como un host virtual proxy inverso para Discourse. ¿Por qué hacerlo estresante y lanzar insultos a los chicos que crearon este gran software y lo regalan de forma gratuita? ¡Discourse es un regalo gratuito! Si quieres configurar Discourse de manera diferente a las configuraciones oficialmente soportadas, ¡nadie te va a detener!
Para cerrar, @OrbitStorm, te aconsejo encarecidamente (hablando como usuario de Discourse, no como miembro del equipo) que cambies tu enfoque de intimidar en meta para obtener soporte. Como dije, ejecuto Discourse en configuraciones “no oficialmente soportadas” y he publicado actualizaciones y código aquí para ayudar a otros (devolviendo algo a esta gran comunidad). Ya he publicado código funcional que es fácil de seguir para configurar Apache2 como proxy inverso, al igual que otros antes que yo.
Por favor, elige la opción #1 (hazlo tú mismo) o la #2 (contrata a alguien para que lo haga); y por favor abandona tu enfoque actual de la #3 (intimidar, acosar e insultar al equipo de meta). Si quieres elegir la #3, publica en nuestros foros de Unix y Linux y puedes intimidarme allí si quieres, todo lo que quieras
Has preparado este muro de texto en respuesta sin abordar realmente el tema original, en un vano intento de actuar como un justiciero de algo que ni siquiera está siendo atacado. De hecho, me etiquetaste como “intimidador” (¿en serio?) porque respondí a un sin sentido fuera de tema de un tipo que me atacó con argumentos ad hominem sobre mi inteligencia y convirtió este hilo en su tribuna para hablar de Nginx (comentarios que han sido convenientemente eliminados para ocultar la naturaleza tóxica que este foro fomenta hacia los nuevos usuarios). Tu primer mensaje no fue muy diferente, ya que respondió a mi pregunta sin realmente responderla. Eres parte del problema.
Sigue hablando de obligaciones, y sin embargo, aquí estás, respondiendo persistentemente a mis hilos solo para ser confrontacional (como hizo Stephen). No sabía que existiera una regla que me prohibiera pedir soporte para una configuración de alojamiento popular (W3Techs fue citado anteriormente y muestra un 67% de cuota para Apache). Podrías haber dejado mis hilos sin respuesta si no te parecía bien, pero elegiste ser beligerante y desviar la conversación.
Estás distorsionando intencionadamente mis palabras porque no me conformo con el status quo de aceptar un tutorial obsoleto y luego nunca volver; un factor por el cual prácticamente todos los hilos sobre esta configuración quedan sin resolver (es decir, intimidación por parte de tipos como tú). ¿De verdad crees que no hice mi deber antes de publicar? Acepté lo que sabía que vendría, pero esperaba que otros que pudieran estar en mi situación (como EricGT) pudieran ofrecer algo de valor antes de que fuera aplastado hasta la nada con pomposas “respuestas”.
Llevo 16 años en el desarrollo de juegos y nunca había experimentado un nivel tan insano de falta de profesionalismo y mezquindad como el que he vivido aquí en solo cinco días cortos. Esto es de una cursilería digna de Reddit; una absoluta broma.
No logro ver por qué la configuración SSL tiene que ver con las aplicaciones detrás del proxy , siempre que la plantilla SSL esté desactivada en el app.yml. Nginx, Apache, HAProxy o Traefik, todos comparten el mismo concepto de snippet/block de servidor/host virtual, donde básicamente se especifica SSL activado, la ubicación de los certificados en el host y algunos parámetros SSL. ¡Aquí haya dragones, quizás?
Creo que la solución que buscas no está relacionada con Discourse, sino con Apache. Y creo que cualquier configuración SSL de Apache que funcione fuera de la caja con un host virtual funcionará bien con Discourse, ya que ha funcionado con otros proxies inversos, aunque puedo estar un poco optimista .
Aunque recuerdo haber tenido un problema con los cifrados; asegúrate de copiar y pegar con cuidado (la línea es muy larga) los que se usan dentro del contenedor Docker.
Sobre esta pendiente resbaladiza, creo que es como esquiarse fuera de pista: es genial, pero está muy mal visto por el equipo de rescate de montaña. Y admito que es bastante diferente cuando caes en un barranco mientras aún estás aprendiendo, ya seas un esquiador experimentado o no.
, siempre que la plantilla SSL esté desactivada en el app.yml. Nginx, Apache, HAProxy o Traefik, todos comparten el mismo concepto de snippet/block de servidor/host virtual, donde básicamente se especifica SSL activado, la ubicación de los certificados en el host y algunos parámetros SSL. ¡Aquí haya dragones, quizás?
.