Declaração Oficial do Discourse sobre a configuração de subpasta
Apoiamos configurações de subpasta para nossos clientes corporativos de nível enterprise e acima. Devido à complexidade técnica da configuração, recomendamos fortemente que você não use esta configuração, a menos que seja muito experiente em configurações personalizadas de subpasta.
É fundamental que você tenha um entendimento profundo de
- Configuração NGINX no contêiner Docker do Discourse
- Encaminhamento seguro do IP original usando cabeçalhos personalizados na cadeia de proxy
- Limitação de taxa (rate limiting) no servidor proxy frontal
Se tudo isso parecer estranho para você, recomendamos fortemente que evite esta configuração.
Para servir o Discourse a partir de uma subpasta (também conhecida como prefixo de caminho) em seu domínio, como https://www.exemplo.com/=SUBPASTA=, veja como fazer!
Configuração do Docker
Na seção env do seu arquivo yml do contêiner docker, adicione a configuração DISCOURSE_RELATIVE_URL_ROOT com a subpasta que você deseja usar. Certifique-se de que não termine com uma barra /.
Editar isso atualizará todo o guia.
env:
...
DISCOURSE_RELATIVE_URL_ROOT: /=SUBPASTA=
A seção run precisa de algumas alterações para enviar todas as rotas do Discourse para o local correto. Aqui está uma seção run completa com suporte a subpasta:
run:
- exec:
cd: $home
cmd:
- mkdir -p public/=SUBPASTA=
- cd public/=SUBPASTA= && ln -s ../uploads && ln -s ../backups
- replace:
global: true
filename: /etc/nginx/conf.d/discourse.conf
from: proxy_pass http://discourse;
to: |
rewrite ^/(.*)$ /=SUBPASTA=/$1 break;
proxy_pass http://discourse;
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: etag off;
to: |
etag off;
location /=SUBPASTA= {
rewrite ^/=SUBPASTA=/?(.*)$ /$1;
}
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: $proxy_add_x_forwarded_for
to: $http_seu_cabecalho_ip_original
global: true
$http_seu_cabecalho_ip_original representa Seu-Cabecalho-IP-Original, que é um Cabeçalho confiável que você define na origem que contém o IP real do cliente.
Isso é necessário porque o tráfego passa por um proxy central, se o Discourse tiver um IP público, você pode falsificá-lo. Se o Discourse for privado, você pode conseguir usar o X-Forwarded-For
Depois de fazer essas alterações, inicialize seu contêiner Docker como de costume, ou reconstrua se estiver alterando um contêiner existente.
./launcher bootstrap app
ou
./launcher rebuild app
Em anexo está um arquivo yml de exemplo completo de um contêiner autônomo.
subfolder-sample.yml (3.1 KB)
Preocupações com limitação de taxa (Rate limiting)
Se você optar por esta configuração, provavelmente desejará limitar a taxa de requisições antes que elas cheguem ao NGINX no contêiner, o que significa que provavelmente evitará usar nosso template de limitação de taxa. É muito difícil configurar o NGINX no contêiner para limitar em um IP mapeado novamente e exigiria mudanças complexas no template.
Posts existentes
Se você fez isso com um site existente que estava em um subdomínio, descobrirá que seus uploads estão quebrados. Existe uma ferramenta que pode ajudar a corrigir todos os caminhos para incluir a subpasta. Primeiro, entre no contêiner Docker e navegue até o diretório Discourse:
cd /var/discourse
./launcher enter app
cd /var/www/discourse
Em seguida, execute o comando de remapagem após fazer um backup:
RAILS_ENV=production bundle exec script/discourse remap '/uploads' '/=SUBPASTA=/uploads'
Veja também: Use a subfolder (path prefix) to serve Discourse with multiple servers sharing a domain para configurações mais esotéricas.
robots.txt
Agora que o Discourse está rodando em uma subpasta, ele não consegue servir seu arquivo robots.txt para controlar quais rotas são rastreadas pelos rastreadores da web. Os rastreadores procurarão no arquivo robots.txt do seu site principal (https://www.exemplo.com/robots.txt). Você precisa copiar o conteúdo do arquivo robots.txt do Discourse (encontrado em https://www.exemplo.com/=SUBPASTA=/robots.txt) e colocá-lo no arquivo robots.txt do seu site principal.