Lineare Bereitstellungen von Amazon ECS - Amazon Elastic Container Service

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.

Lineare Bereitstellungen von Amazon ECS

Lineare Bereitstellungen verlagern den Datenverkehr im Laufe der Zeit schrittweise von der alten Service-Revision auf die neue, sodass Sie jeden Schritt überwachen können, bevor Sie mit dem nächsten fortfahren. Mit linearen Bereitstellungen von Amazon ECS können Sie das Tempo der Verkehrsverlagerung kontrollieren und neue Service-Revisionen bei steigendem Produktionsdatenverkehr validieren. Dieser Ansatz bietet eine kontrollierte Methode zur Implementierung von Änderungen mit der Möglichkeit, die Leistung bei jedem Schritt zu überwachen.

Ressourcen, die für eine lineare Bereitstellung erforderlich sind

Im Folgenden sind Ressourcen aufgeführt, die an linearen Bereitstellungen von Amazon ECS beteiligt sind:

  • Verkehrsverlagerung — Der Prozess, den Amazon ECS verwendet, um den Produktionsverkehr zu verlagern. Bei linearen Bereitstellungen von Amazon ECS wird der Datenverkehr in gleichen prozentualen Schritten mit konfigurierbaren Wartezeiten zwischen den einzelnen Schritten verschoben.

  • Schrittprozent — Der Prozentsatz des Datenverkehrs, der während einer linearen Bereitstellung in jedem Schritt verlagert werden soll. Dieses Feld akzeptiert Double als Wert, und gültige Werte liegen zwischen 3,0 und 100,0.

  • Step Bake Time — Die Wartezeit zwischen den einzelnen Verkehrsverschiebungen bei einem linearen Einsatz. Gültige Werte liegen zwischen 0 und 1440 Minuten.

  • Bereitstellungszeit — Die Zeit in Minuten, die Amazon ECS nach der Umstellung des gesamten Produktionsverkehrs auf die neue Service-Revision wartet, bevor die alte Service-Revision beendet wird. Dies ist die Dauer, in der sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden, nachdem sich der Produktionsdatenverkehr verlagert hat.

  • Lebenszyklusphasen – Eine Reihe von Ereignissen während des Bereitstellungsvorgangs, z. B. „nach der Verschiebung des Produktionsdatenverkehrs“.

  • Lifecycle-Hook — Eine Lambda-Funktion, die in einer bestimmten Lebenszyklusphase ausgeführt wird. Sie können eine Funktion erstellen, die die Bereitstellung verifiziert. Für PRODUCTION_TRAFFIC_SHIFT konfigurierte Lambda-Funktionen oder Lifecycle-Hooks werden bei jedem Produktions-Traffic-Shift-Schritt aufgerufen.

  • Zielgruppe — Eine ELB-Ressource, die verwendet wird, um Anfragen an ein oder mehrere registrierte Ziele (z. B. Instanzen) weiterzuleiten. EC2 Wenn Sie einen Listener erstellen, geben Sie eine Zielgruppe für die Standardaktion an. Der Datenverkehr wird an die in der Listener-Regel angegebene Zielgruppe weitergeleitet.

  • Listener — Eine ELB-Ressource, die mithilfe des von Ihnen konfigurierten Protokolls und Ports nach Verbindungsanfragen sucht. Die Regeln, die Sie für einen Listener definieren, bestimmen, wie der Amazon ECS Anforderungen an registrierte Ziele weiterleitet.

  • Regel — Eine ELB-Ressource, die einem Listener zugeordnet ist. Eine Regel definiert, wie Anfragen weitergeleitet werden, und besteht aus einer Aktion, einer Bedingung und einer Priorität.

Überlegungen

Berücksichtigen Sie bei der Auswahl eines Bereitstellungstyps Folgendes:

  • Ressourcennutzung: Bei linearen Bereitstellungen werden vorübergehend sowohl die blaue als auch die grüne Version des Dienstes gleichzeitig ausgeführt, wodurch sich Ihr Ressourcenverbrauch bei Bereitstellungen verdoppeln kann.

  • Überwachung der Bereitstellung: Lineare Bereitstellungen bieten detaillierte Informationen zum Bereitstellungsstatus, sodass Sie jede Phase des Bereitstellungsprozesses und jede Verkehrsverlagerung überwachen können.

  • Rollback: Lineare Bereitstellungen erleichtern das Rollback zur vorherigen Version, wenn Probleme erkannt werden, da die blaue Version so lange läuft, bis die Backzeit abgelaufen ist.

  • Schrittweise Validierung: Lineare Bereitstellungen ermöglichen es Ihnen, die neue Version bei steigendem Produktionsdatenverkehr zu validieren, was für mehr Vertrauen in die Bereitstellung sorgt.

  • Bereitstellungsdauer: Lineare Bereitstellungen dauern aufgrund der schrittweisen Verlagerung des Datenverkehrs und der Wartezeiten zwischen den einzelnen Schritten länger als all-at-once Bereitstellungen.

So funktioniert die lineare Bereitstellung

Der Bereitstellungsprozess von Amazon ECS Linear 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).

  1. Vorbereitungsphase: Erstellen Sie die grüne Umgebung neben der bestehenden blauen Umgebung.

  2. 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.

  3. 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.

  4. Phase der linearen Verkehrsverlagerung: Verlagern Sie den Produktionsdatenverkehr auf der Grundlage Ihrer konfigurierten Bereitstellungsstrategie schrittweise in gleichen prozentualen Schritten von blau nach grün.

  5. Ü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.

  6. Abschlussphase: Schließen Sie die Bereitstellung ab, indem Sie die blaue Umgebung beenden.

Die Phase der linearen Verkehrsverlagerung folgt diesen Schritten:

  • Anfänglich — Die Bereitstellung beginnt damit, dass 100% des Datenverkehrs an die blaue (aktuelle) Service-Revision weitergeleitet werden. Die grüne (neue) Dienstversion empfängt Testdatenverkehr, aber zunächst keinen Produktionsdatenverkehr.

  • Schrittweise Verkehrsverlagerung — Der Verkehr wird schrittweise in gleichen prozentualen Schritten von blau auf grün umgestellt. Bei einer Konfiguration in Schritten von 10,0% treten Verkehrsverschiebungen beispielsweise wie folgt auf:

    • Schritt 1:10,0% zu Grün, 90,0% zu Blau

    • Schritt 2:20,0% zu Grün, 80,0% zu Blau

    • Schritt 3:30,0% zu Grün, 70,0% zu Blau

    • Und so weiter, bis 100% Grün erreicht

  • Step Bake Time — Zwischen den einzelnen Traffic-Shift-Schritten wartet das Deployment auf eine konfigurierbare Dauer (Step-Bake-Time), sodass die Leistung der neuen Version angesichts der erhöhten Datenverkehrslast überwacht und validiert werden kann. Beachten Sie, dass die Backzeit des letzten Schritts übersprungen wird, sobald der Verkehr zu 100,0% verlagert wurde.

  • Lifecycle-Hooks — Optionale Lambda-Funktionen können während der Bereitstellung in verschiedenen Lebenszyklusphasen ausgeführt werden, um automatisierte Validierung, Überwachung oder benutzerdefinierte Logik durchzuführen. Für PRODUCTION_TRAFFIC_SHIFT konfigurierte Lambda-Funktionen oder Lifecycle-Hooks werden bei jedem Produktions-Traffic-Shift-Schritt aufgerufen.

Lebenszyklusphasen der Bereitstellung

Der lineare Bereitstellungsprozess durchläuft verschiedene Lebenszyklusphasen mit jeweils spezifischen Verantwortlichkeiten und Validierungspunkten. Wenn Sie diese Phasen verstehen, können Sie den Bereitstellungsfortschritt überwachen und Probleme effektiv beheben.

Jede Lebenszyklusphase kann bis zu 24 Stunden dauern, und zusätzlich kann jeder Verkehrsverlagerungsschritt in PRODUCTION_TRAFFIC_SHIFT 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 hat eine Zeitüberschreitung, schlägt bei der Bereitstellung fehl und leitet dann ein Rollback ein, wenn eine Phase 24 Stunden erreicht hat.

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 Unterstützung für Lebenszyklus-Hooks
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 Verkehr wird schrittweise in gleichen prozentualen Schritten von Blau auf Grün umgestellt, bis 100% des Verkehrs auf Grün entfallen. Bei jeder Verkehrsverlagerung wird ein Lifecycle-Hook mit einem Timeout von 24 Stunden ausgelöst.
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