Este tópico é um complemento a outro, que se concentra na configuração do Discourse. Aqui, configuraremos uma distribuição do Cloudfront como proxy reverso antes do Discourse.
A única vez em que você precisa dessa combinação é quando você já possui uma distribuição do Cloudfront para o hostname principal e deseja fazer o proxy de uma subpasta para um fórum Discourse. Este guia pressupõe que o leitor tenha experiência prévia com o uso do Cloudfront em produção.
Fluxo de Tráfego
Quando um usuário carrega o site, há duas conexões de rede envolvidas. Cada uma possui um hostname diferente:
- O navegador da web enviará uma solicitação ao Cloudfront para o hostname público.
- Em seguida, o Cloudfront enviará uma solicitação aos servidores do Discourse para o hostname de origem.
.───────. .───────. .─────────.
( browser )───▶( CF )───▶( discourse )
`───────' `───────' `─────────'
Para nosso exemplo, vamos supor que seu site do Discourse será carregado a partir de https://www.example.com/forum/, usando:
| finalidade | hostname |
|---|---|
| hostname público | www.example.com |
| hostname de origem | discourse.example.com |
Configuração do Cloudfront
Isso significa que haverá pelo menos duas origens definidas — uma padrão para o site principal e uma segunda para os servidores do Discourse.
Haverá também pelo menos dois comportamentos, um apontando para cada origem.
O comportamento e a origem padrão não são relevantes para nossos propósitos aqui; eles já devem estar configurados de acordo com suas necessidades. A origem e o comportamento específicos do Discourse devem ser configurados da seguinte forma.
Origem
A segunda origem para os servidores do Discourse deve apontar para o hostname de origem.
Não configure um caminho de origem.
A política de protocolo deve ser HTTPS, com TLSv1 como versão mínima.
Comportamento
O padrão precisa corresponder à subpasta.
Ele deve estar vinculado à origem configurada acima.
Deve redirecionar HTTP → HTTPS.
Deve permitir todos os verbos HTTP.
Deve desativar o cache.
Deve encaminhar todos os cabeçalhos do cliente.
Configurando o Lambda@Edge
Ambientes de hospedagem compartilhada (incluindo discourse.org) usam SNI. Para que isso funcione com o Cloudfront, você precisará usar o Lambda@Edge para garantir que o Cloudfront utilize o hostname de origem para o SNI, em vez do cabeçalho Host da solicitação do visualizador.
Acesse o painel do AWS Lambda e crie uma nova função. Use o ambiente de execução Node.js e crie uma nova função com “Permissões básicas do Lambda@Edge”:
Clique em “Create Function” (Criar função).
Quando o editor de código aparecer, substitua o exemplo por este:
exports.handler = async (event, context) => {
const request = event.Records[0].cf.request;
request.headers['x-forwarded-host'] = [{
key: 'x-forwarded-host',
value: request.headers['host'][0]['value']
}];
request.headers["host"] = [{
key: 'host',
value: request.origin.custom.domainName
}];
return request;
};
Clique em “Deploy” (Implantar).
No canto superior esquerdo, escolha Actions → Deploy to Lambda@Edge (Ações → Implantar no Lambda@Edge).
Escolha sua distribuição do Cloudfront e selecione o comportamento correto na lista:
Se precisar fazer alterações por qualquer motivo, certifique-se de “Deploy” (Implantar), depois “Publish new Version” (Publicar nova versão) na guia de versões e, em seguida, atualize sua distribuição para usar a nova versão do Lambda.