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.
Arbeitsablauf für Amazon blue/green ECS-Servicebereitstellungen
Der blue/green Bereitstellungsprozess von Amazon ECS folgt einem strukturierten Ansatz mit sechs verschiedenen Phasen, die sichere und zuverlässige Anwendungsupdates gewährleisten. Jede Phase dient einem bestimmten Zweck bei der Validierung und Umstellung Ihrer Anwendung von der aktuellen Version (blau) auf die neue Version (grün).
-
Vorbereitungsphase: Erstellen Sie die grüne Umgebung neben der bestehenden blauen Umgebung. Dies beinhaltet die Bereitstellung neuer Serviceversionen und die Vorbereitung der Zielgruppen.
-
Bereitstellungsphase: Stellen Sie die neue Serviceversion in einer umweltfreundlichen Umgebung bereit. Amazon ECS startet neue Aufgaben mit der aktualisierten Service-Revision, während die blaue Umgebung weiterhin den Produktionsdatenverkehr bedient.
-
Testphase: Validieren Sie die grüne Umgebung mithilfe von Test-Datenverkehrs-Routing. Der Application Load Balancer leitet Testanfragen an die grüne Umgebung weiter, während der Produktionsverkehr weiterhin blau ist.
-
Phase der Verkehrsverlagerung: Verlagern Sie den Produktionsdatenverkehr basierend auf Ihrer konfigurierten Bereitstellungsstrategie von blau auf grün. Diese Phase umfasst Überwachungs- und Validierungsprüfpunkte.
-
Überwachungsphase: Überwachen Sie den Zustand der Anwendung, die Leistungskennzahlen und den Alarmstatus während der Backzeit. Ein Rollback-Vorgang wird eingeleitet, wenn Probleme erkannt werden.
-
Abschlussphase: Schließen Sie die Bereitstellung ab, indem Sie je nach Konfiguration die blaue Umgebung beenden oder sie für mögliche Rollback-Szenarien beibehalten.
Workflow
Das folgende Diagramm veranschaulicht den umfassenden blue/green Bereitstellungsablauf und zeigt die Interaktion zwischen Amazon ECS und dem Application Load Balancer:
Der erweiterte Bereitstellungsablauf umfasst die folgenden detaillierten Schritte:
-
Ausgangszustand: Der Blue Service (aktuelle Produktion) verarbeitet 100% des Produktionsverkehrs. Der Application Load Balancer hat einen einzigen Listener mit Regeln, die alle Anfragen an die blaue Zielgruppe weiterleiten, die fehlerfreie blaue Aufgaben enthält.
-
Bereitstellung umweltfreundlicher Umgebungen: Amazon ECS erstellt neue Aufgaben anhand der aktualisierten Aufgabendefinition. Diese Aufgaben sind für eine neue grüne Zielgruppe registriert, erhalten aber zunächst keinen Traffic.
-
Überprüfung der Integritätsprüfung: Der Application Load Balancer führt Integritätsprüfungen für grüne Aufgaben durch. Erst wenn grüne Aufgaben die Integritätsprüfungen bestehen, geht die Bereitstellung in die nächste Phase über.
-
Datenverkehrs-Routing testen: Falls konfiguriert, leiten die Listener-Regeln des Application Load Balancers bestimmte Datenverkehrsmuster (z. B. Anfragen mit Test-Headern) zur Validierung an die grüne Umgebung weiter, während der Produktionsdatenverkehr blau bleibt. Dies wird von demselben Listener gesteuert, der den Produktionsdatenverkehr verarbeitet, wobei unterschiedliche Regeln verwendet werden, die auf den Anforderungsattributen basieren.
-
Verkehrsverlagerung in der Produktion: Je nach Bereitstellungskonfiguration wechselt der Verkehr von blau nach grün. Bei blue/green ECS-Implementierungen handelt es sich um eine sofortige (all-at-once) Verschiebung, bei der 100% des Datenverkehrs von der blauen in die grüne Umgebung verlagert werden. Der Application Load Balancer verwendet einen einzigen Listener mit Listener-Regeln, die die Verteilung des Datenverkehrs zwischen den blauen und grünen Zielgruppen anhand von Gewichtungen steuern.
-
Überwachung und Validierung: Während der gesamten Verkehrsverlagerung überwacht Amazon ECS CloudWatch Metriken, Alarmzustände und den Zustand der Bereitstellung. Automatische Rollback-Trigger werden aktiviert, wenn Probleme erkannt werden.
-
Backzeit: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem sich der Produktionsdatenverkehr verlagert hat.
-
Beendigung der blauen Umgebung: Nach erfolgreicher Verlagerung und Validierung des Datenverkehrs wird die blaue Umgebung beendet, um Clusterressourcen freizugeben, oder sie wird beibehalten, um ein schnelles Rollback zu ermöglichen.
-
Endgültiger Zustand: Die grüne Umgebung wird zur neuen Produktionsumgebung, die 100% des Datenverkehrs abwickelt. Die Bereitstellung wird als erfolgreich markiert.
Phasen des Bereitstellungslebenszyklus
Der blue/green Bereitstellungsprozess durchläuft verschiedene Lebenszyklusphasen (eine Reihe von Ereignissen während des Bereitstellungsvorgangs, z. B. „nach der Verlagerung des Produktionsverkehrs“), für die jeweils spezifische Zuständigkeiten und Prüfpunkte gelten. Wenn Sie diese Phasen verstehen, können Sie den Bereitstellungsfortschritt überwachen und Probleme effektiv beheben.
Jede Phase des Lebenszyklus kann bis zu 24 Stunden dauern. Wir empfehlen, dass der Wert unter der 24-Stunden-Marke bleibt. Das liegt daran, dass asynchrone Prozesse Zeit benötigen, um die Hooks auszulösen. Das System hat eine Zeitüberschreitung, schlägt bei der Bereitstellung fehl und leitet dann ein Rollback ein, wenn eine Phase 24 Stunden erreicht hat. AWS CloudFormation Bereitstellungen haben zusätzliche Timeout-Einschränkungen. Das AWS CloudFormation 24-Stunden-Phasenlimit bleibt zwar in Kraft, erzwingt jedoch ein Limit von 36 Stunden für die gesamte Bereitstellung. AWS CloudFormation schlägt bei der Bereitstellung fehl und leitet dann ein Rollback ein, wenn der Vorgang nicht innerhalb von 36 Stunden abgeschlossen ist.
| Phasen des Lebenszyklus | Beschreibung | Verwenden Sie diese Phase für den Lifecycle-Hook? |
|---|---|---|
| RECONCILE_SERVICE | Diese Phase tritt nur ein, wenn Sie eine neue Servicebereitstellung mit mehr als einer Dienstrevision im Status AKTIV starten. | Ja |
| PRE_SCALE_UP | Die Green Service-Revision wurde nicht gestartet. Die blaue Service-Revision wickelt 100% des Produktionsverkehrs ab. Es gibt keinen Testverkehr. | Ja |
| SCALE_UP | Der Zeitpunkt, zu dem die Green-Service-Revision auf 100% skaliert wird und neue Aufgaben gestartet werden. Die Green-Service-Revision bedient derzeit keinen Traffic. | Nein |
| POST_SCALE_UP | Die Green Service-Revision wurde gestartet. Die blaue Service-Revision wickelt 100% des Produktionsverkehrs ab. Es gibt keinen Testverkehr. | Ja |
| TEST_TRAFFIC_SHIFT | Die blauen und grünen Service-Revisionen werden ausgeführt. Die blaue Service-Revision wickelt 100% des Produktionsverkehrs ab. Die grüne Service-Revision migriert von 0 auf 100% des Testverkehrs. | Ja |
| POST_TEST_TRAFFIC_SHIFT | Die Testverkehrsverlagerung ist abgeschlossen. Die Green-Service-Revision verarbeitet 100% des Testverkehrs. | Ja |
| PRODUCTION_TRAFFIC_SHIFT | Der Produktionsverkehr verlagert sich auf die Version Green Service. Bei der Revision der umweltfreundlichen Dienste geht der Anteil des Produktionsverkehrs von 0 auf 100% über. | Ja |
| POST_PRODUCTION_TRAFFIC_SHIFT | Die Verlagerung des Produktionsverkehrs ist abgeschlossen. | Ja |
| BAKE_TIME | Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden. | Nein |
| CLEAN_UP | Die blaue Service-Revision wurde vollständig auf 0 laufende Aufgaben herunterskaliert. Die grüne Service-Revision ist nach dieser Phase nun die Revision des Produktionsservices. | Nein |
Jede Phase des Lebenszyklus umfasst integrierte Validierungsprüfpunkte, die bestanden werden müssen, bevor mit der nächsten Phase fortgefahren werden kann. Schlägt eine Überprüfung fehl, kann die Bereitstellung automatisch zurückgesetzt werden, um die Verfügbarkeit und Zuverlässigkeit des Dienstes aufrechtzuerhalten.
