Exécuter Discourse à / tout en servant une application personnalisée à /tickets sur le même domaine

Installation
1

Bonjour à tous,

J’essaie de confirmer l’architecture correcte pour servir une application personnalisée à un sous-chemin tout en gardant Discourse à la racine (/), sans modifier les internes de Discourse.

Ce que je veux (objectif final)

https://mondomaine.com/         → Discourse
https://mondomaine.com/tickets  → Système de tickets personnalisé (Go + Gin)

Exigences :

  1. Discourse doit rester à / et l’application personnalisée doit vivre à /tickets
  2. Même domaine
  3. Aucun plugin Discourse

Environnement actuel

  1. VPS OVH (Ubuntu) Discourse fonctionnant dans Docker (/var/discourse)
  2. Application Go personnalisée fonctionnant sur le même serveur à 127.0.0.1:8080
  3. Nginx externe installé sur l’hôte (pas à l’intérieur du conteneur)

Je n’essaie PAS d’exécuter Discourse dans un sous-dossier comme /forum. Ah, et avant que quelqu’un ne le demande, oui, j’ai essayé d’utiliser le plugin de tickets Discourse - il ne fonctionne pas comme je le souhaite.

2

Vous pouvez le faire facilement avec nginx, bien que ce ne soit pas recommandé, je ne suis pas au courant que discourse utilise la route /tickets pour quoi que ce soit.

3

Merci pour la réponse rapide ! J’utilise nginx et j’ai des difficultés. Voici ma configuration et toujours aucun succès.

Ceci est à l’intérieur de mon fichier 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

Pouvez-vous préciser exactement où vous rencontrez des difficultés ?

2 « J'aime »
5

Je pense que ce sont probablement vos meilleures instructions, cependant. Vous suivrez ces instructions, mais en quelque sorte à l’envers. Vous ferez en sorte que votre proxy inverse externe serve / à Discourse et /tickets à votre application.

6

@pfaffman Donc, ce que je retiens, c’est : réutiliser le concept, pas la configuration — placer un proxy inverse externe devant qui route :

  • / → Discourse

  • /tickets → mon application personnalisée

Discourse reste totalement ignorant de /tickets.
Donc, suivre ce guide, n’est-ce pas : Serve Discourse from a subfolder (path prefix) instead of a subdomain

1 « J'aime »
7

Je pense que le nginx externe est la manière la plus simple de le faire. Il serait possible de créer un modèle qui permettrait à celui en interne de le faire, mais c’est plus compliqué et, je pense, pour peu de gain.

Oui, mais vous n’avez pas besoin d’apporter de modifications au conteneur Discourse autres que de supprimer les modèles ssl/let’s encrypt et peut-être d’utiliser une socket. (Donc, en réalité, peu de choses dans ce sujet sont vraiment utiles.)

8

J’ai réussi à le faire fonctionner !

Merci à vous deux pour vos réponses !

image
image623×257 6.75 KB

Le lien « Tickets » que j’ai ajouté à l’en-tête de Discourse fonctionne également, lorsqu’il est défini sur vide et NON sur lui-même, car /tickets est alors traité comme une route Discourse et tente simplement de changer la vue react. Le vide force un rechargement complet de la page.

1 « J'aime »
9

Si vous souhaitez corriger cela, je suis presque certain qu’un composant de thème le fera en ajoutant une route pour /tickets et en lui disant de faire… quelque chose (je ne suis pas très doué avec Ember). De plus, je pense que vous pourriez ajouter un autre sous-domaine à votre serveur Discourse (comme tickets.mondomaine.com) en utilisant DISCOURSE_HOST_ALIASES et ensuite lier à ce domaine, ce qui effectuerait une redirection, afin qu’Ember n’essaie pas de s’approprier la route.