Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Erfahren Sie, wie Continuous Deployment funktioniert
In den folgenden Themen wird erklärt, wie CloudFront Continuous Deployment funktioniert.
Themen
Anfragen an die Staging-Distribution weiterleiten
Wenn Sie CloudFront Continuous Deployment verwenden, müssen Sie nichts an den Viewer-Anfragen ändern. Viewer haben nicht die Möglichkeit, unter Verwendung eines DNS-Namens, einer IP-Adresse oder eines CNAME Anforderungen direkt an eine Staging-Verteilung zu senden. Stattdessen senden Zuschauer Anfragen an die primäre (Produktions-) Distribution und CloudFront leiten einige dieser Anfragen auf Grundlage der Datenverkehrskonfigurationse instellungen in der Continuous Deployment Policy an die Staging-Distribution weiter. Es gibt zwei Arten von Datenverkehrskonfigurationen:
- Gewichtet
-
Bei einer gewichtsbasierten Konfiguration wird der angegebene Prozentsatz der Viewer-Anforderungen an die Staging-Verteilung weitergeleitet. Wenn Sie eine gewichtsbasierte Konfiguration verwenden, können Sie auch die Sitzungsbindung aktivieren, wodurch sichergestellt wird, dass Anfragen von demselben Viewer als Teil einer einzigen Sitzung CloudFront behandelt werden. Weitere Informationen finden Sie unter Sitzungs-Stickiness bei gewichtsbasierten Konfigurationen.
- Header-basiert
-
Bei einer Header-basierten Konfiguration werden Anforderungen an die Staging-Verteilung weitergeleitet, wenn die Viewer-Anforderung einen bestimmten HTTP-Header enthält (den Header und Wert geben Sie selbst an). Anforderungen, die den angegebenen Header und Wert nicht enthalten, werden an die primäre Verteilung weitergeleitet. Diese Konfiguration ist hilfreich, wenn Sie lokale Tests durchführen oder die Kontrolle über die Viewer-Anforderungen haben.
Anmerkung
Header, die an Ihre Staging-Verteilung weitergeleitet werden, müssen das Präfix
aws-cf-cd-enthalten.
Sitzungs-Stickiness bei gewichtsbasierten Konfigurationen
Wenn Sie eine gewichtsbasierte Konfiguration verwenden, um Traffic an eine Staging-Verteilung weiterzuleiten, können Sie auch die Sitzungsbindung aktivieren, wodurch sichergestellt wird, dass Anfragen von demselben Viewer als eine einzelne Sitzung CloudFront behandelt werden. Wenn Sie Session Stickiness aktivieren, CloudFront wird ein Cookie gesetzt, sodass alle Anfragen desselben Viewers in einer einzigen Sitzung von einer Distribution bedient werden, entweder von der Primär- oder der Staging-Distribution.
Wenn Sie Sitzungs-Stickiness aktivieren, können Sie auch die Leerlaufdauer (idle duration) angeben. Wenn der Viewer für diese Zeit inaktiv ist (keine Anfragen sendet), läuft die Sitzung ab und CloudFront behandelt future Anfragen von diesem Viewer als neue Sitzung. Sie geben die Leerlaufdauer in Sekunden an. Möglich sind dabei Werte von 300 (fünf Minuten) bis 3 600 Sekunden (einer Stunde).
CloudFront Setzt in den folgenden Fällen alle Sitzungen (auch aktive) zurück und betrachtet alle Anfragen als neue Sitzung:
-
Sie deaktivieren oder aktivieren die Richtlinie für die kontinuierliche Bereitstellung.
-
Sie deaktivieren oder aktivieren die Einstellung für Sitzungs-Stickiness.
Aktualisieren Sie die Primär- und Staging-Distributionen
Wenn einer primären Verteilung eine Richtlinie für die kontinuierliche Bereitstellung angefügt ist, sind die folgenden Konfigurationsänderungen sowohl für die primäre Verteilung als auch für die Staging-Verteilung verfügbar:
-
Alle Einstellungen in Bezug auf das Cache-Verhalten, einschließlich des Standard-Cache-Verhaltens
-
Alle Ursprungseinstellungen (Ursprünge und Ursprungsgruppen)
-
Benutzerdefinierte Fehlerreaktionen (Fehlerseiten)
-
Geografische Einschränkungen
-
Standardstammobjekt
-
Protokollierungseinstellungen
-
Beschreibung (Kommentar)
Sie können auch externe Ressourcen aktualisieren, auf die in der Konfiguration einer Distribution verwiesen wird, z. B. eine Cache-Richtlinie, eine Response-Header-Richtlinie, eine CloudFront Funktion oder eine Lambda @Edge -Funktion.
Primäre Verteilungen und Staging-Verteilungen nutzen nicht denselben Cache
Primäre Verteilungen und Staging-Verteilungen nutzen nicht denselben Cache. Wenn die erste Anfrage an eine Staging-Distribution CloudFront gesendet wird, ist deren Cache leer. Wenn Anforderungen bei der Staging-Verteilung ankommen, beginnt diese mit dem Zwischenspeichern der Antworten (sofern entsprechend konfiguriert).
