Bonjour à tous. J’ai récemment mis en place mon installation Discourse en utilisant AWS CloudFront (CF) pour l’accélération complète du site - et la décharge SSL à l’aide de certificats AWS dans CF. Notez que cette installation s’écarte du guide officiel concernant la configuration du CDN et du SSL - cela pourrait donc être controversé et entraîner de futurs problèmes de support. Soyez donc prévenus… il y a des dragons ici. Je partage ici la configuration qui a fonctionné pour moi :
-
Configurez Discourse pour qu’il écoute uniquement sur le port 80 et désactivez Let’s Encrypt en commentant les lignes indiquées dans app.yml :
-
Configurez Discourse pour qu’il prête attention à l’en-tête CF,
cloudfront-forwarded-proto, plutôt qu’àx-forwarded-proto(que CF ne transmet pas - et ne peut étrangement pas être configuré pour transmettre à l’origine… fou !
)
-
Configurez votre distribution CF avec un cname pour votre nom d’hôte public prévu (par exemple, forum.example.com) en utilisant un certificat AWS ACM (que vous avez généré).
-
Configurez l’origine CF en utilisant l’IP élastique publique du serveur EC2 hébergeant Discourse (par exemple, ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com). Configurez-la pour http uniquement (c’est-à-dire uniquement le port 80 - pas de 443). Vous n’avez pas besoin de configurer votre origine avec un nom d’hôte fantaisiste dans DNS comme forum-origin.example.com. Le nom d’hôte ou l’IP EC2 fonctionne très bien.
-
Configurez les “comportements” de CF pour les différents chemins de requête. L’essentiel ici est de configurer le comportement de mise en cache pour les éléments qui sont évidemment des ressources statiques ; et de configurer la non-mise en cache pour tout le reste (c’est-à-dire que ces requêtes sont simplement transmises telles quelles à l’origine sans mise en cache). Une autre chose essentielle ici est que la dernière règle de transmission (“par défaut”) utilise une “politique de requête d’origine” personnalisée qui transmet tous les en-têtes d’origine à l’origine en plus de l’en-tête CF
cloudfront-forwarded-proto. Configurez également les redirections http vers https dans vos comportements - de sorte que toutes les requêtes des utilisateurs finaux soient forcées en https par CF.
-
Ne configurez pas “DISCOURSE_CDN_URL”
-
Activez “force https”
-
Ne configurez pas “long polling base url” - laissez-le vide. Malgré tous les avertissements sévères concernant les problèmes lors de la transmission à un proxy, cela fonctionne très bien pour moi jusqu’à présent. Peut-être que la connexion keep alive par défaut de CF est suffisamment longue pour l’empêcher de perdre la connexion.
Je pense que c’est tout… 
Le résultat final est que toutes les requêtes, http/documents, toutes les ressources statiques de support, tous les appels ajax, etc., sont tous servis sur le même nom de domaine (par exemple, forum.example.com). Le comportement de mise en cache (et le comportement de transmission) est dicté par vos “comportements” configurés dans CF. Et toutes les connexions sont cryptées à l’aide de certificats AWS ACM terminés sur le bord de CF - et ensuite le trafic non crypté/http est renvoyé au serveur d’origine.
J’ose dire que cela pourrait être plus propre que ce que meta.discourse.org a en ce moment 
.