Hallo zusammen. Ich habe kürzlich meine Discourse-Installation mit AWS CloudFront (CF) für die vollständige Websitebeschleunigung eingerichtet – und SSL-Offloading mit AWS-Zertifikaten in CF. Beachten Sie, dass diese Installation von der offiziellen Anleitung bezüglich CDN- und SSL-Konfiguration abweicht – das könnte kontrovers sein und zu zukünftigen Supportproblemen führen. Seien Sie also gewarnt… hier lauern Drachen. Ich teile hier die Konfiguration, die für mich funktioniert hat:
-
Richten Sie Discourse so ein, dass es nur auf Port 80 lauscht, und deaktivieren Sie Let’s Encrypt, indem Sie die angegebenen Zeilen in app.yml auskommentieren:
-
Richten Sie Discourse so ein, dass es auf den CF-Header
cloudfront-forwarded-protoachtet und nicht aufx-forwarded-proto(den CF nicht weiterleitet – und seltsamerweise nicht so konfiguriert werden kann, dass er an den Ursprung weitergeleitet wird… verrückt!
)
-
Richten Sie Ihre CF-Distribution mit einem CNAME für Ihren beabsichtigten öffentlichen Hostnamen (z. B. forum.example.com) unter Verwendung eines AWS ACM-Zertifikats (das Sie generiert haben) ein.
-
Richten Sie den CF-Ursprung mit der öffentlichen Elastic IP des EC2-Servers ein, auf dem Discourse gehostet wird (z. B. ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com). Konfigurieren Sie ihn nur für HTTP (d. h. nur Port 80 – keine 443). Sie müssen Ihren Ursprung nicht mit einem schicken Hostnamen in DNS wie forum-origin.example.com einrichten. Der EC2-Hostname oder die IP-Adresse funktionieren einwandfrei.
-
Richten Sie die CF-“Behaviors” für die verschiedenen Anfragepfade ein. Der Schlüssel hier ist, das Caching-Verhalten für offensichtlich statische Ressourcen zu konfigurieren; und kein Caching für alles andere zu konfigurieren (d. h. diese Anfragen werden einfach so wie sie sind an den Ursprung weitergeleitet, ohne Caching). Ein weiterer wichtiger Punkt hier ist, dass die letzte Weiterleitungsregel (“default”) eine benutzerdefinierte “Origin Request Policy” verwendet, die alle ursprünglichen Header zusätzlich zum CF
cloudfront-forwarded-proto-Header an den Ursprung weiterleitet. Konfigurieren Sie auch HTTP-zu-HTTPS-Umleitungen in Ihren Behaviors – damit alle Endbenutzeranfragen von CF auf HTTPS erzwungen werden.
-
Konfigurieren Sie “DISCOURSE_CDN_URL” nicht.
-
Aktivieren Sie “force https”.
-
Konfigurieren Sie “long polling base url” nicht – lassen Sie es leer. Trotz aller düsteren Warnungen, dass dies bei der Weiterleitung über einen Proxy problematisch ist, funktioniert es für mich bisher einwandfrei. Vielleicht ist die Standard-Keep-Alive-Verbindung von CF lang genug, um zu verhindern, dass die Verbindung abbricht.
Ich glaube, das war’s… 
Das Endergebnis ist, dass alle Anfragen, HTTP/Dokumente, alle unterstützenden statischen Ressourcen, alle AJAX-Aufrufe usw. unter demselben Domainnamen (z. B. forum.example.com) bedient werden. Das Caching-Verhalten (und das Weiterleitungsverhalten) wird durch Ihre in CF konfigurierten “Behaviors” bestimmt. Und alle Verbindungen werden mit AWS ACM-Zertifikaten verschlüsselt, die am CF-Edge terminiert werden – und dann werden unverschlüsselte/HTTP-Verbindungen an den Ursprungsserver zurückgesendet.
Ich wage zu behaupten, dass dies sauberer sein könnte als das, was meta.discourse.org derzeit macht 
.