Ejecutando Discourse en / mientras se sirve una aplicación personalizada en /tickets en el mismo dominio

Instalación
1

Hola a todos,

Estoy intentando confirmar la arquitectura correcta para servir una aplicación personalizada en una sub-ruta mientras se mantiene Discourse en la raíz (/), sin modificar los internos de Discourse.

Lo que quiero (objetivo final)

https://midominio.com/         → Discourse
https://midominio.com/tickets  → Sistema de tickets personalizado (Go + Gin)

Requisitos:

  1. Discourse debe permanecer en / y el sistema de tickets debe vivir en /tickets
  2. Mismo dominio
  3. Sin plugin de Discourse

Entorno actual

  1. VPS de OVH (Ubuntu) con Discourse ejecutándose en Docker (/var/discourse)
  2. Aplicación Go personalizada ejecutándose en el mismo servidor en 127.0.0.1:8080
  3. Nginx externo instalado en el host (no dentro del contenedor)

NO estoy intentando ejecutar Discourse en una subcarpeta como /forum. Ah, y antes de que alguien pregunte, sí, he intentado usar el plugin de tickets de Discourse; no funciona como quiero.

2

Puedes hacerlo fácilmente con nginx, aunque no es lo recomendado, no estoy al tanto de que discourse use la ruta /tickets para nada.

3

¡Gracias por la rápida respuesta! Estoy usando nginx y tengo dificultades. Esta es mi configuración y todavía no hay suerte.

Esto está dentro de mi archivo app.yml

ports:
  - "127.0.0.1:4000:4000"
  #- "80:80" # http
  #- "443:443" # https

/etc/nginx/sites-enabled/filename

server {
    listen 80;
    server_name mydomain.com;

    # ---- Tickets app ----
    location ^~ /tickets {
        proxy_pass http://127.0.0.1:5000;
        proxy_http_version 1.1;
        proxy_redirect off;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Discourse auth headers
        proxy_set_header X-Discourse-Username $http_x_discourse_username;
        proxy_set_header X-Discourse-User-Id $http_x_discourse_user_id;
        proxy_set_header X-Discourse-Groups $http_x_discourse_groups;
    }

    # ---- Discourse ----
    location / {
        proxy_pass http://127.0.0.1:4000;
        proxy_http_version 1.1;
        proxy_redirect off;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
4

¿Puedes detallar exactamente dónde tienes problemas?

2 Me gusta
5

Creo que esas son probablemente tus mejores instrucciones, sin embargo. Seguirás esas instrucciones, pero de forma inversa. Harás que tu proxy inverso externo sirva / a Discourse y /tickets a tu aplicación.

6

@pfaffman Entonces, lo que entiendo es: reutilizar el concepto, no la configuración — poner un proxy inverso externo delante que enrute:

  • / → Discourse

  • /tickets → mi aplicación personalizada

Discourse permanece totalmente ajeno a /tickets.
Entonces, seguir esta guía, ¿correcto?: Serve Discourse from a subfolder (path prefix) instead of a subdomain

1 me gusta
7

Creo que el nginx externo es la forma más fácil de hacerlo. Sería posible crear una plantilla que permitiera al interno hacerlo, pero es más complicado y, creo, con poca ganancia.

Sí, pero no necesitas hacer ningún cambio en el contenedor de Discourse aparte de eliminar las plantillas de ssl/let’s encrypt y tal vez usar un socket. (Así que, en realidad, no hay mucho en ese tema que sea de mucha ayuda).

8

¡Lo he conseguido hacer funcionar!

¡Muchas gracias a ambos por vuestras respuestas!

image
image623×257 6.75 KB

El enlace “Tickets” que añadí al encabezado de Discourse también funciona, cuando se establece en blanco y NO en sí mismo, ya que /tickets se trata entonces como una ruta de Discourse e intenta simplemente cambiar la vista de react. El blanco fuerza una recarga completa de la página.

1 me gusta
9

Si quieres arreglar eso, estoy bastante seguro de que un componente de tema lo hará agregando una ruta para /tickets y diciéndole que haga… algo (no soy muy bueno con Ember). Además, creo que podrías agregar otro subdominio a tu servidor Discourse (como tickets.mydomain.com) usando DISCOURSE_HOST_ALIASES y luego enlazar a ese dominio, lo que haría una redirección, para que Ember no intente capturar la ruta.