Dieses Thema ist eine Ergänzung zu einem anderen, das sich auf die Discourse-Konfiguration konzentriert. Hier richten wir eine Cloudfront-Distribution als Reverse-Proxy vor Discourse ein.
Diese Kombination ist nur dann erforderlich, wenn Sie bereits eine Cloudfront-Distribution für den primären Hostnamen haben und einen Unterordner an ein Discourse-Forum weiterleiten möchten. Diese Anleitung setzt voraus, dass der Leser bereits Erfahrung mit dem produktiven Einsatz von Cloudfront hat.
Datenfluss
Wenn ein Benutzer die Seite lädt, sind zwei Netzwerkverbindungen beteiligt. Jede hat einen anderen Hostnamen:
- Der Webbrowser sendet eine Anfrage an Cloudfront für den öffentlichen Hostnamen.
- Anschließend sendet Cloudfront eine Anfrage an die Discourse-Server für den Ursprungs-Hostnamen.
.───────. .───────. .─────────.
( browser )───▶( CF )───▶( discourse )
`───────' `───────' `─────────'
Für unser Beispiel tun wir so, als würde Ihre Discourse-Site unter https://www.example.com/forum/ geladen, wobei folgende Werte verwendet werden:
| Zweck | Hostname |
|---|---|
| Öffentlicher Hostname | www.example.com |
| Ursprungs-Hostnamen | discourse.example.com |
Cloudfront-Einrichtung
Das bedeutet, dass mindestens zwei Ursprünge definiert sein müssen – einer als Standard für die Hauptseite und ein zweiter für die Discourse-Server.
Es werden ebenfalls mindestens zwei Verhaltensweisen (Behaviors) benötigt, die jeweils auf einen der Ursprünge verweisen.
Das Standardverhalten und der Standardursprung sind für unsere Zwecke hier nicht relevant; sie müssen bereits entsprechend Ihren Anforderungen konfiguriert sein. Der spezifische Ursprung und das Verhalten für Discourse sollten wie folgt konfiguriert werden.
Ursprung (Origin)
Der zweite Ursprung für die Discourse-Server sollte auf den Ursprungs-Hostnamen zeigen.
Konfigurieren Sie keinen Ursprungspfad.
Die Protokollrichtlinie sollte HTTPS sein, mit TLSv1 als Mindestversion.
Verhalten (Behavior)
Das Muster muss den Unterordner abdecken.
Es sollte mit dem oben konfigurierten Ursprung verknüpft sein.
Es sollte HTTP auf HTTPS umleiten.
Es sollte alle HTTP-Verben zulassen.
Es sollte das Caching deaktivieren.
Es sollte alle Client-Header weiterleiten.
Konfiguration von Lambda@Edge
Geteilte Hosting-Umgebungen (einschließlich discourse.org) verwenden SNI. Damit dies mit Cloudfront funktioniert, müssen Sie Lambda@Edge verwenden, um sicherzustellen, dass Cloudfront den Ursprungs-Hostnamen für SNI verwendet, anstatt den Host-Header aus der Anfrage des Viewers.
Besuchen Sie das AWS Lambda-Dashboard und erstellen Sie eine neue Funktion. Verwenden Sie die Node.js-Laufzeitumgebung und erstellen Sie eine neue Rolle mit „Basic Lambda@Edge-Berechtigungen":
Klicken Sie auf „Create Function" (Funktion erstellen).
Sobald der Code-Editor angezeigt wird, ersetzen Sie das Beispiel durch folgenden Code:
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;
};
Klicken Sie auf „Deploy" (Bereitstellen).
Wählen Sie oben links unter „Actions" (Aktionen) die Option „Deploy to Lambda@Edge".
Wählen Sie Ihre Cloudfront-Distribution und wählen Sie das korrekte Verhalten aus der Liste aus:
Wenn Sie aus irgendeinem Grund Änderungen vornehmen müssen, stellen Sie sicher, dass Sie zuerst „Deploy" (Bereitstellen) und dann „Publish new Version" (Neue Version veröffentlichen) im Reiter „Versions" wählen. Aktualisieren Sie anschließend Ihre Distribution, um die neue Version von Lambda zu verwenden.