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 Service-Revisionen und die Vorbereitung der Zielgruppen.
-
Bereitstellungsphase: Stellen Sie die neue Service-Revision in der grünen 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 Datenverkehrsverlagerung: 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 Leistungsmetriken und den Alarmstatus während der Bake-Zeit. 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 Bereitstellungs-Workflow umfasst die folgenden detaillierten Schritte:
-
Ausgangszustand: Der blaue Service (aktuelle Produktion) verarbeitet 100 % des Produktionsdatenverkehrs. 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 grüner Umgebungen: Amazon ECS erstellt neue Aufgaben anhand der aktualisierten Aufgabendefinition. Diese Aufgaben sind in einer neuen grünen Zielgruppe registriert, erhalten aber zunächst keinen Datenverkehr.
-
Validierung der Zustandsprüfung: Der Application Load Balancer führt Zustandsprüfungen für grüne Aufgaben durch. Erst wenn grüne Aufgaben die Zustandsprüfungen bestehen, geht die Bereitstellung in die nächste Phase über.
-
Test-Datenverkehrs-Routing: 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.
-
Phase der Produktionsdatenverkehrsverlagerung: Verlagern Sie den Produktionsdatenverkehr basierend auf der Bereitstellungskonfiguration von blau auf grün. Bei blue/green ECS-Bereitstellungen 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-Auslöser werden aktiviert, wenn Probleme erkannt werden.
-
Bake-Zeitraum: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde.
-
Beendigung der blauen Umgebung: Nach erfolgreicher Verlagerung und Validierung des Datenverkehrs wird die blaue Umgebung beendet, um Cluster-Ressourcen freizugeben, oder sie wird beibehalten, um ein schnelles Rollback zu ermöglichen.
-
Endgültiger Status: Die grüne Umgebung wird zur neuen Produktionsumgebung, die 100 % des Datenverkehrs abwickelt. Die Bereitstellung wird als erfolgreich markiert.
Lebenszyklusphasen der Bereitstellung
Der blue/green Bereitstellungsprozess durchläuft verschiedene Lebenszyklusphasen (eine Reihe von Ereignissen während des Bereitstellungsvorgangs, z. B. „nach der Verlagerung des Produktionsverkehrs“), von denen jede mit spezifischen Verantwortlichkeiten und Validierungspunkten verbunden ist. Wenn Sie diese Phasen verstehen, können Sie den Bereitstellungsfortschritt überwachen und Probleme effektiv beheben.
Jede Lebenszyklusphase kann bis zu 24 Stunden dauern. Wir empfehlen, dass der Wert unter 24 Stunden bleibt. Das liegt daran, dass asynchrone Prozesse Zeit benötigen, um die Hooks auszulösen. Das System tritt aufgrund eines Timeouts auf, schlägt bei der Bereitstellung fehl und leitet nach Ablauf einer Phase von 24 Stunden einen Rollback ein. CloudFormation Bereitstellungen haben zusätzliche Timeout-Einschränkungen. Das CloudFormation 24-Stunden-Phasenlimit bleibt zwar in Kraft, erzwingt jedoch ein Limit von 36 Stunden für die gesamte Bereitstellung. CloudFormation schlägt bei der Bereitstellung fehl und leitet dann ein Rollback ein, wenn der Vorgang nicht innerhalb von 36 Stunden abgeschlossen ist.
| Lebenszyklusphasen | Description | Diese Phase für einen Lebenszyklus-Hook verwenden? |
|---|---|---|
| RECONCILE_SERVICE | Diese Phase tritt nur ein, wenn Sie eine neue Servicebereitstellung mit mehr als einer Service-Revision im Status ACTIVE starten. | Ja |
| PRE_SCALE_UP | Die grüne Service-Revision wurde nicht gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja |
| SCALE_UP | Der Zeitpunkt, zu dem die grüne Service-Revision auf 100 % aufskaliert wird und neue Aufgaben gestartet werden. Die grüne Service-Revision bedient derzeit keinen Datenverkehr. | Nein |
| POST_SCALE_UP | Die grüne Service-Revision wurde gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja |
| TEST_TRAFFIC_SHIFT | Die blauen und grünen Service-Revisionen werden ausgeführt. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Die grüne Service-Revision wird von 0 auf 100 % des Test-Datenverkehrs migriert. | Ja |
| POST_TEST_TRAFFIC_SHIFT | Die Verlagerung des Test-Datenverkehrs ist abgeschlossen. Die grüne Service-Revision wickelt 100 % des Test-Datenverkehrs ab. | Ja |
| PRODUCTION_TRAFFIC_SHIFT | Der Produktionsdatenverkehr verlagert sich auf die grüne Service-Revision. Die grüne Service-Revision wird von 0 auf 100 % des Produktionsdatenverkehrs migriert. | Ja |
| POST_PRODUCTION_TRAFFIC_SHIFT | Die Verlagerung des Produktionsdatenverkehrs ist abgeschlossen. | Ja |
| BAKE_TIME | Die Dauer, in der sowohl die blaue als auch die grüne Service-Revision 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 Service-Revision der Produktion. | 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 Services aufrechtzuerhalten.
Wenn Sie eine Lambda-Funktion verwenden, muss die Funktion die Arbeit abschließen oder innerhalb von 15 Minuten IN_PROGRESS zurückgeben. Sie können callBackDelaySeconds verwenden, um den Aufruf von Lambda zu verzögern. Weitere Informationen finden Sie unter der Funktion app.py
