Blau / Grün-Bereitstellungen mit CloudFront

Ich suche nach einer Möglichkeit, Blue / Green-Bereitstellungen mit CloudFront durchzuführen .

Hat jemand eine gute Lösung für den Wechsel von einer CloudFront-Distribution zu einer anderen oder erstellt wirklich jeder nur seine Distribution und berührt sie dann nie wieder?

Meine CloudFront-Distribution besteht aus einem S3- Ursprung für statischen Inhalt (Javascript usw.) und einem benutzerdefinierten Ursprung, der auf eine AWS-ELB verweist.

Keine Änderungen an CloudFront

Unter normalen Umständen nehmen wir keinerlei Änderungen an unserer CloudFront-Distribution vor. Wir versionieren unseren statischen Inhalt im S3-Ursprung, indem wir den Namen der statischen Inhaltsdateien in S3 ändern und unter dem Elastic Load Balancer (ELB) Rolling-Bereitstellungen für EC2-Instanzen durchführen. Es gibt jedoch Situationen, in denen wir die CloudFront-Distribution selbst testen und ändern müssen oder die Umgebung so stark ändern müssen, dass wir auf eine neue ELB in einer neuen Umgebung verweisen müssen.

Zwei CloudFront-Distributionen

Die erste Option , die ich versuchte , war zwei separate Cloudfront haben Web Distributionen , einen für meine aktuellen oder A, Umwelt und eine für meinen neuen oder B, Umwelt. Ich habe versucht, eine Route53- gewichtete Routing-Richtlinie zu verwenden, bei der ich zwei Datensätze für meinen www.domain.com-Route53-Datensatz hinzugefügt habe, von denen einer auf CloudFront Distribution A mit einer Gewichtung von 1 und der andere auf CloudFront Distribution B mit einer Gewichtung von 0 zeigt Es ist geplant, die Gewichtung zu ändern, wenn ich von Verteilung A zu Verteilung B wechseln möchte. Es kann jedoch immer nur für eine CloudFront-Verteilung der alternative Domain-Name (CNAME) von www.domain.com registriert werden, oder es wird der folgende Fehler angezeigt :

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

Eine CloudFront-Distribution

Die zweite Option besteht darin, eine CloudFront-Webdistribution beizubehalten. Ich habe S3 und benutzerdefinierte Ursprünge, die auf meine A- und B-Umgebungen verweisen, und aktualisiere dann das CloudFront- Cache-Verhalten , um auf den anderen Ursprung zu verweisen, wenn ich von einer Umgebung in eine andere wechseln möchte. Dies ist äußerst umständlich, da diese Aktualisierungen 15 bis 60 Minuten dauern. Der Fortschritt der Aktualisierung wird nicht angezeigt. Abhängig von der Art Ihrer Änderung müssen Sie möglicherweise eine CloudFront-Invalidierung durchführen, damit Sie keine zwischengespeicherten Inhalte bereitstellen aus der alten Umgebung zusammen mit neuen Inhalten.

Danke für deinen Rat!

Zwei Cloudfront-Distributionen

Da AWS Überlappungen zwischen alternativen Wildcard-CNAMEs in demselben AWS-Konto zulässt, können Sie auf folgende Weise zwischen zwei Cloudfront-Distributionen wechseln:

• Verwenden Sie www.domain.com als alternativen CNAME für die Produktverteilung 1
• Verwenden Sie * .domain.com als alternativen CNAME für die Produktverteilung 2
• Verweisen Sie Ihren CNAME-DNS www.domain.com auf Distribution 1 oder Distribution 2. (* .cloudfront.net).
• Entfernen Sie den alternativen CNAME aus der Distribution, von der Sie den Inhalt nicht mehr bereitstellen möchten.

Die beiden unterschiedlichen Verteilungs-DNSs (* .cloudfront.net) können jedoch auf dieselben Edge-Knoten verweisen. Dies bedeutet, dass Ihre Inhalte so bereitgestellt werden, dass der CNAME von cloudfront.net mit den Edge-Knoten abgeglichen wird, von denen sie bereitgestellt werden Hostname. In diesem Fall ist digder Schnitt nicht sauber , wenn beide Verteilungen dieselben Randknoten verwenden (dies kann zum Beispiel mit überprüft werden ).

Beispiel: Wenn beide Distributionen einen oder mehrere Edge-Knoten gemeinsam nutzen, hat die Distribution 1 mit Alt CNAME www.domain.com Vorrang vor der Distribution 2 mit der allgemeineren * .domain.com, bis der CNAME aus der Konfiguration von Distribution 1 in allen Edge-Knoten entfernt wird . Daher kann sich die von einer Anforderung abgerufene Version während der Übergangszeit von der anderen unterscheiden.

Ein bisschen spät im Spiel hier, aber für alle anderen, die danach suchen. Ich glaube, dass dies mit Lambda @ Edge durchgeführt werden kann. Ähnlich wie bei A / B-Tests. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . Sie können eine Lambda-Funktion implementieren, die ausgelöst wird, wenn ein Benutzer eine URL anfordert. Wählen Sie, ob der blau / grüne Inhalt aus verschiedenen Quellen oder mit einem URL-Präfix geliefert werden soll. Ein Cookie-Wert bestimmt, welche Bereitstellung bereitgestellt wird. Wenn die erste Anfrage eintrifft (kein Cookie), setzen Sie das Cookie nach dem Zufallsprinzip auf 95% Blau, 5% Grün.

Wie lange dauert es bei Aufnahmen aus der Hüfte, den Ursprung innerhalb einer Cloud-Front-Distribution zu ändern? 1) Stellen Sie neuen Code hinter ELB bereit, wärmen Sie ihn auf. 2) Fügen Sie diesen ELB als neuen Ursprung zu Ihrer Cloud-Front-Distribution hinzu, während Sie den alten Ursprung entfernen.

Um Verzögerungen zu vermeiden, die mit CloudFront-Updates oder DNS-Updates verbunden sind, können Sie die Autoscale-Gruppe hinter Ihrer ELB austauschen. 1) Setzen Sie neuen Code in das neue ASG ein, wärmen Sie es auf. 2) Registrieren Sie Ihr bestehendes ELB mit diesem neuen ASG. 3) Entfernen Sie das alte ASG von Ihrem ELB.

Ich habe mich auch mit diesem Thema befasst und habe ein Workaround durchgeführt (siehe unten).

Hintergrund:

Für CloudFront muss der CNAME in der Distributionskonfiguration für Ihr gesamtes Konto eindeutig sein. Daher funktioniert die Steuerung von Blau / Grün über DNS für verschiedene Distributionen nicht. Es gibt einen Hack, der Platzhalter verwendet, der jedoch keine Garantie dafür gibt, dass die richtigen Dateien bereitgestellt werden. Die Steuerung von Blau / Grün über DNS und CloudFront ist nicht möglich.

Wenn Sie eine Konfiguration in CloudFront (einschließlich CNAME) ändern, müssen Sie 15 bis 60 Minuten warten, während die Änderungen an die Edgeserver weitergegeben werden. Auch kein ideales Setup.

Umgehen Sie:

Für eine App mit nur einer Seite kann diese Konfiguration den Trick bewirken:

• App-URL: app.meinedomäne.com/app
• S3 Struktur:
  • App / (Ihre Live-Site)
  • app2 / (deine nicht so live Seite)

Konfigurieren Sie nun CloudFront so, dass Ihr Bucket zum Bereitstellen der Dateien verwendet wird. An diesem Punkt hängt alles von Ihren Cache-Einstellungen ab. Da CloudFront ewig dauert, legen Sie den CacheControl-Header für unsere S3-Objekte fest. Für index.html verwenden wir 5 Minuten, alles andere 1 Tag. Tauschen Sie zum Wechseln die S3-Verzeichnisnamen aus. Innerhalb von 5 Minuten wird die App in jeder Hinsicht live sein.

Für Apps, die bereits ausgeführt werden, haben wir die Build-Version in den Code integriert und eine Build-Konfigurations-JSON-Datei im Stammverzeichnis der App. Dann fordert die App gelegentlich die json-Datei an. Überprüfen Sie, ob die Version veraltet ist, und fordern Sie eine Aktualisierung an.

Einschränkungen

Sie können Einweichversuche nicht sehr gut durchführen. Ich nehme an, es ist möglich, die TTL von index.html auf einige Stunden oder Tage zu erhöhen (je nach Bedarf), um sicherzustellen, dass die Clients neue Versionen erhalten, wenn ihr lokaler Cache abläuft.

In diesem Blog - Post der Autor Geräte ab über Lambda @ Edge - Prüfung arbeitet der Code in der AWS - Dokumentation aus (können Sie ihre Beispiele hier sehen: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- examples.html ).

Grundsätzlich erstellen Sie eine einzelne Cloudfront-Distribution, die auf zwei unterschiedliche Ursprünge verweist. Dann können Sie mit dem Lambda @ Edge den Datenverkehr zu einem beliebigen Ursprung leiten (über Cookies), und natürlich können Sie andere Dinge über das Lambda implementieren, z .