Executando Discourse em / enquanto serve um app customizado em /tickets no mesmo domínio

Instalação
1

Olá a todos,

Estou tentando confirmar a arquitetura correta para servir uma aplicação personalizada em um subcaminho enquanto mantenho o Discourse na raiz (/), sem modificar os internos do Discourse.

O que eu quero (objetivo final)

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

Requisitos:

  1. O Discourse deve permanecer em / e o sistema de tickets deve ficar em /tickets
  2. Mesmo domínio
  3. Sem plugin do Discourse

Ambiente atual

  1. VPS OVH (Ubuntu) com Discourse rodando em Docker (/var/discourse)
  2. Aplicação Go personalizada rodando no mesmo servidor em 127.0.0.1:8080
  3. Nginx externo instalado no host (não dentro do contêiner)

Eu NÃO estou tentando rodar o Discourse em uma subpasta como /forum. Ah, e antes que alguém pergunte, sim, eu tentei usar o plugin de tickets do Discourse - ele não funciona como eu gostaria.

2

Você pode fazer isso facilmente com o nginx, embora não seja recomendado, não estou ciente de o discourse usar a rota /tickets para qualquer coisa.

3

Obrigado pela resposta rápida! Estou usando nginx e com dificuldades. Esta é a minha configuração e ainda sem sucesso.

Isto está dentro do meu arquivo 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

Você pode detalhar exatamente onde está com dificuldades?

2 curtidas
5

Eu acho que essas são provavelmente as suas melhores instruções, no entanto. Você seguirá essas instruções, mas de forma meio invertida. Você fará com que seu proxy reverso externo sirva / para o Discourse e /tickets para o seu aplicativo.

6

@pfaffman Então, o que estou entendendo é: reutilize o conceito, não a configuração — coloque um proxy reverso externo na frente que roteia:

  • / → Discourse

  • /tickets → meu aplicativo personalizado

O Discourse permanece totalmente alheio a /tickets.
Então, siga este guia, certo: Serve Discourse from a subfolder (path prefix) instead of a subdomain

1 curtida
7

Eu acho que o nginx externo é a maneira mais fácil de fazer isso. Seria possível criar um template que permitisse ao interno fazer isso, mas é mais complicado e, eu acho, com pouco ganho.

Sim, mas você não precisa fazer nenhuma alteração no container do Discourse além de remover os templates de ssl/let’s encrypt e talvez usar um socket. (Então, na verdade, pouca coisa naquele tópico é de muita ajuda.)

8

Consegui fazer funcionar!

Agradeço as respostas de vocês dois!

image
image623×257 6.75 KB

O link “Tickets” que adicionei ao cabeçalho do Discourse também funciona, quando definido como em branco, e não como ‘self’, pois /tickets é então tratado como uma rota do Discourse e tenta apenas trocar a visualização do React. Em branco força uma recarga completa da página.