Questa discussione è un complemento a un’altra, che si concentra sulla configurazione di Discourse. Qui imposteremo una distribuzione Cloudfront come reverse proxy davanti a Discourse.
L’unica volta in cui hai bisogno di questa combinazione è quando già hai una distribuzione Cloudfront per il nome host principale e desideri inoltrare una sottocartella a un forum Discourse. Questa guida presuppone che il lettore abbia esperienza precedente nell’uso di Cloudfront in produzione.
Flusso del traffico
Quando un utente carica il sito, sono coinvolte due connessioni di rete. Ognuna ha un nome host diverso:
- Il browser web invierà una richiesta a Cloudfront per il nome host pubblico.
- Quindi Cloudfront invierà una richiesta ai server Discourse per il nome host di origine.
.───────. .───────. .─────────.
( browser )───▶( CF )───▶( discourse )
`───────' `───────' `─────────'
Per il nostro esempio, faremo finta che il tuo sito Discourse venga caricato da https://www.example.com/forum/, utilizzando:
| scopo | nome host |
|---|---|
| nome host pubblico | www.example.com |
| nome host di origine | discourse.example.com |
Configurazione di Cloudfront
Ciò significa che saranno definiti almeno due origini: una predefinita per il sito principale e una seconda per i server Discourse.
Ci saranno anche almeno due comportamenti, uno puntato a ciascuna origine.
Il comportamento e l’origine predefiniti non sono rilevanti per i nostri scopi qui; devono già essere configurati in modo appropriato alle tue esigenze. L’origine e il comportamento specifici di Discourse dovrebbero essere configurati come segue.
Origine
La seconda origine per i server Discourse dovrebbe essere puntata al nome host di origine.
Non configurare un percorso di origine.
La policy del protocollo dovrebbe essere HTTPS, con TLSv1 come versione minima.
Comportamento
Il modello deve corrispondere alla sottocartella.
Dovrebbe essere collegato all’origine configurata come sopra.
Dovrebbe reindirizzare HTTP → HTTPS.
Dovrebbe consentire tutti i verbi HTTP.
Dovrebbe disabilitare la memorizzazione nella cache.
Dovrebbe inoltrare tutte le intestazioni del client.
Configurazione di Lambda@edge
Gli ambienti di hosting condiviso (incluso discourse.org) utilizzano SNI. Per far funzionare questo con Cloudfront, dovrai utilizzare Lambda@edge per assicurarti che Cloudfront utilizzi il nome host di origine per SNI, invece dell’intestazione Host dalla richiesta del visualizzatore.
Visita la dashboard AWS Lambda e crea una nuova funzione. Usa l’ambiente di runtime Node.js e crea un nuovo ruolo con “Permessi base Lambda@Edge”:
Clicca su “Crea funzione”
Una volta che appare l’editor del codice, sostituisci l’esempio con questo:
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;
};
Clicca su “Distribuisci”.
In alto a sinistra, scegli Azioni → Distribuisci su Lambda@Edge
Scegli la tua distribuzione Cloudfront e seleziona il comportamento corretto dall’elenco:
Se devi apportare modifiche per qualsiasi motivo, assicurati di “Distribuire”, quindi “Pubblica nuova versione” dalla scheda delle versioni, quindi aggiorna la tua distribuzione per utilizzare la nuova versione di Lambda.