Ce sujet est un complément à un autre, qui se concentre sur la configuration de Discourse. Ici, nous allons configurer une distribution Cloudfront comme proxy inverse devant Discourse.
La seule raison pour laquelle vous avez besoin de cette combinaison est lorsque vous avez déjà une distribution Cloudfront pour le nom d’hôte principal et que vous souhaitez proxyfier un sous-dossier vers un forum Discourse. Ce guide suppose que le lecteur a une expérience préalable de l’utilisation de Cloudfront en production.
Flux du trafic
Lorsqu’un utilisateur charge le site, deux connexions réseau sont impliquées. Chacune possède un nom d’hôte différent :
- Le navigateur web émettra une requête vers Cloudfront pour le nom d’hôte public.
- Ensuite, Cloudfront émettra une requête vers les serveurs Discourse pour le nom d’hôte d’origine.
.───────. .───────. .─────────.
( browser )───▶( CF )───▶( discourse )
`───────' `───────' `─────────'
Pour notre exemple, nous allons supposer que votre site Discourse sera chargé depuis https://www.example.com/forum/, en utilisant :
| objectif | nom d’hôte |
|---|---|
| nom d’hôte public | www.example.com |
| nom d’hôte d’origine | discourse.example.com |
Configuration de Cloudfront
Cela signifie qu’il y aura au moins deux origines définies : une par défaut pour le site principal et une seconde pour les serveurs Discourse.
Il y aura également au moins deux comportements, l’un pointant vers chaque origine.
Le comportement et l’origine par défaut ne sont pas pertinents pour nos besoins ici ; ils doivent déjà être configurés en fonction de vos besoins. L’origine et le comportement spécifiques à Discourse doivent être configurés comme suit.
Origine
La seconde origine pour les serveurs Discourse doit pointer vers le nom d’hôte d’origine.
Ne configurez pas de chemin d’origine.
La stratégie de protocole doit être HTTPS, avec TLSv1 comme version minimale.
Comportement
Le motif doit correspondre au sous-dossier.
Il doit être attaché à l’origine configurée comme ci-dessus.
Il doit rediriger HTTP → HTTPS.
Il doit autoriser toutes les méthodes HTTP.
Il doit désactiver la mise en cache.
Il doit transmettre tous les en-têtes clients.
Configuration de Lambda@edge
Les environnements d’hébergement mutualisé (y compris discourse.org) utilisent SNI. Pour que cela fonctionne avec Cloudfront, vous devrez utiliser Lambda@edge pour vous assurer que Cloudfront utilise le nom d’hôte d’origine pour SNI, plutôt que l’en-tête Host provenant de la requête du visiteur.
Accédez au tableau de bord AWS Lambda et créez une nouvelle fonction. Utilisez l’environnement d’exécution Node.js et créez un nouveau rôle avec les « autorisations de base Lambda@Edge » :
Cliquez sur « Créer une fonction ».
Une fois que l’éditeur de code apparaît, remplacez l’exemple par ceci :
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;
};
Cliquez sur « Déployer ».
En haut à gauche, choisissez Actions → Déployer vers Lambda@Edge.
Choisissez votre distribution Cloudfront et sélectionnez le bon comportement dans la liste :
Si vous devez apporter des modifications pour une raison quelconque, assurez-vous de « Déployer », puis de « Publier une nouvelle version » depuis l’onglet des versions, puis mettez à jour votre distribution pour utiliser la nouvelle version de Lambda.