Esecuzione di Discourse su / mentre si serve un'app personalizzata su /tickets sullo stesso dominio

Supporto Installazione
1

Ciao a tutti,

Sto cercando di confermare l’architettura corretta per servire un’applicazione personalizzata a un sotto-percorso mantenendo Discourse alla radice (/), senza modificare gli interni di Discourse.

Cosa voglio (obiettivo finale)

https://mydomain.com/         → Discourse
https://mydomain.com/tickets  → Sistema di ticketing personalizzato (Go + Gin)

Requisiti:

  1. Discourse deve rimanere a / e l’app personalizzata deve vivere a /tickets
  2. Stesso dominio
  3. Nessun plugin di Discourse

Ambiente attuale

  1. OVH VPS (Ubuntu) Discourse in esecuzione in Docker (/var/discourse)
  2. App Go personalizzata in esecuzione sullo stesso server a 127.0.0.1:8080
  3. Nginx esterno installato sull’host (non all’interno del container)

NON sto cercando di eseguire Discourse in una sottocartella come /forum. Ah, e prima che qualcuno lo chieda, sì, ho provato a usare il plugin per i ticket di Discourse - non funziona come vorrei.

2

Puoi farlo facilmente con nginx, anche se non è consigliato, non sono a conoscenza che discourse utilizzi la rotta /tickets per qualsiasi cosa.

3

Grazie per la rapida risposta! Sto usando nginx e ho difficoltà. Questa è la mia configurazione e ancora niente da fare.

Questo è all’interno del mio file 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

Puoi spiegare esattamente dove stai avendo difficoltà?

5

Penso che quelle siano probabilmente le tue migliori istruzioni, comunque. Seguirai quelle istruzioni, ma in modo inverso. Farai in modo che il tuo proxy inverso esterno serva / a Discourse e /tickets alla tua applicazione.

6

@pfaffman Quindi, quello che ho capito è: riutilizzare il concetto, non la configurazione — mettere un reverse proxy esterno davanti che instrada:

  • / → Discourse

  • /tickets → la mia applicazione personalizzata

Discourse rimane completamente ignaro di /tickets.
Quindi seguire questa guida, giusto: Serve Discourse from a subfolder (path prefix) instead of a subdomain

7

Penso che l’nginx esterno sia il modo più semplice per farlo. Sarebbe possibile creare un template che permettesse a quello interno di farlo, ma è più complicato e, penso, con pochi vantaggi.

Sì, ma non è necessario apportare modifiche al container di Discourse se non rimuovere i template ssl/let’s encrypt e magari usare un socket. (Quindi, in realtà, non molto di quell’argomento è di grande aiuto.)

8

Ce l’ho fatta funzionare!

Grazie a entrambi per le vostre risposte!

image
image623×257 6.75 KB

Anche il link “Tickets” che ho aggiunto all’intestazione di Discourse funziona, quando è impostato su vuoto NON su self, poiché /tickets viene quindi trattato come una rotta di Discourse e tenta solo di cambiare la vista react. Vuoto forza un ricaricamento completo della pagina.

9

Se vuoi risolvere questo problema, sono abbastanza sicuro che un componente tema possa farlo aggiungendo una rotta per /tickets e dicendogli di fare… qualcosa (non sono un esperto di Ember). Inoltre, penso che potresti aggiungere un altro sottodominio al tuo server Discourse (come tickets.mydomain.com) usando DISCOURSE_HOST_ALIASES e poi collegarti a quel dominio, che quindi farebbe un reindirizzamento, in modo che Ember non tenti di prendere la rotta.