Discourse unter / ausführen, während eine benutzerdefinierte App unter /tickets auf derselben Domain läuft

Installation
1

Hallo zusammen,

ich versuche, die korrekte Architektur für das Bereitstellen einer benutzerdefinierten Anwendung unter einem Subpfad zu bestätigen, während Discourse unter dem Stammverzeichnis (/) bleibt, ohne die internen Mechanismen von Discourse zu ändern.

Was ich möchte (Endziel)

https://meinedomain.com/         → Discourse
https://meinedomain.com/tickets  → Benutzerdefiniertes Ticketsystem (Go + Gin)

Anforderungen:

  1. Discourse muss unter / bleiben, das benutzerdefinierte System muss unter /tickets sein
  2. Dieselbe Domain
  3. Kein Discourse-Plugin

Aktuelle Umgebung

  1. OVH VPS (Ubuntu) Discourse läuft in Docker (/var/discourse)
  2. Benutzerdefinierte Go-Anwendung läuft auf demselben Server unter 127.0.0.1:8080
  3. Externer nginx, der auf dem Host installiert ist (nicht im Container)

Ich versuche NICHT, Discourse in einem Unterordner wie /forum auszuführen. Ach ja, bevor jemand fragt: Ja, ich habe versucht, das Discourse-Tickets-Plugin zu verwenden – es funktioniert nicht so, wie ich es möchte.

2

Sie können dies ganz einfach mit nginx tun, obwohl es nicht empfohlen wird, ist mir nicht bekannt, dass Discourse die Route /tickets für irgendetwas verwendet.

3

Vielen Dank für die schnelle Antwort! Ich verwende nginx und habe Schwierigkeiten. Das ist meine Konfiguration und es funktioniert immer noch nicht.

Das steht in meiner app.yml-Datei

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

/etc/nginx/sites-enabled/dateiname

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 Header
        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

Können Sie genauer erläutern, wo genau Sie Schwierigkeiten haben?

2 „Gefällt mir“
5

Ich denke, das sind wahrscheinlich Ihre besten Anweisungen, wenn auch „rückwärts“. Sie werden diesen Anweisungen folgen, aber sozusagen rückwärts. Ihr externer Reverse-Proxy wird / an Discourse und /tickets an Ihre Anwendung weiterleiten.

6

@pfaffman Was ich also mitnehme ist: Das Konzept wiederverwenden, nicht die Konfiguration – eine externe Reverse-Proxy davor schalten, die routet:

  • / → Discourse

  • /tickets → meine benutzerdefinierte App

Discourse bleibt von /tickets völlig unberührt.
Also diesem Leitfaden folgen, richtig: Serve Discourse from a subfolder (path prefix) instead of a subdomain

1 „Gefällt mir“
7

Ich denke, der externe Nginx ist der einfachste Weg, dies zu tun. Es wäre möglich, eine Vorlage zu erstellen, die es dem internen ermöglicht, dies zu tun, aber es ist komplizierter und meiner Meinung nach mit wenig Gewinn verbunden.

Ja, aber Sie müssen am Discourse-Container keine Änderungen vornehmen, außer die SSL/Let’s Encrypt-Vorlagen zu entfernen und möglicherweise einen Socket zu verwenden. (Daher ist in diesem Thema nicht viel hilfreich.)

8

Ich habe es zum Laufen gebracht!

Vielen Dank für eure Antworten!

image
image623×257 6.75 KB

Der „Tickets“-Link, den ich zum Discourse-Header hinzugefügt habe, funktioniert auch, wenn er auf leer und NICHT auf selbst gesetzt ist, da /tickets dann als Discourse-Route behandelt wird und versucht, nur die React-Ansicht auszutauschen. Leer erzwingt einen vollständigen Seitenneuladen.