Lineare Bereitstellungen von Amazon ECS

Bei linearen Bereitstellungen wird der Datenverkehr im Laufe der Zeit schrittweise in gleichen Schritten von der alten Service-Version auf die neue übertragen, sodass Sie jeden Schritt überwachen können, bevor Sie mit dem nächsten fortfahren. Mit den 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 an einer linearen Bereitstellung beteiligt sind

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

• Verkehrsverlagerung — Der Prozess, den Amazon ECS verwendet, um den Produktionsverkehr zu verlagern. Bei linearen Amazon ECS-Bereitstellungen wird der Datenverkehr in Schritten zu gleichen Prozentsätzen verlagert, wobei zwischen den einzelnen Schritten konfigurierbare Wartezeiten bestehen.

• Schrittprozentsatz — Der Prozentsatz des Datenverkehrs, der während einer linearen Bereitstellung schrittweise verlagert werden soll. In diesem Feld wird Double als Wert verwendet, und gültige Werte liegen zwischen 3,0 und 100,0.

• Step Bake Time — Die Wartezeit zwischen den einzelnen Verkehrsverlagerungen während einer linearen Bereitstellung. Gültige Werte liegen zwischen 0 und 1440 Minuten.

• Bereitstellungs-Bake-Zeit — Die Zeit (in Minuten), die Amazon ECS nach der Verlagerung des gesamten Produktionsdatenverkehrs auf die neue Service-Revision wartet, bevor die alte Service-Revision beendet wird. Dies ist der Zeitraum, in dem sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden, nachdem sich der Produktionsverkehr geändert hat.

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

• Lifecycle-Hook — Eine Lambda-Funktion oder ein Pausenpunkt in einer bestimmten Lebenszyklusphase. Lambda-Hooks rufen Lambda-Funktionen auf, die Sie für die Ausführung von benutzerdefiniertem Code definiert haben. Pause-Hooks unterbrechen die Bereitstellung und warten auf Ihren AufrufContinueServiceDeployment, um fortzufahren. Hooks, die für jeden Schritt im Produktionsdatenverkehr konfiguriert PRE_PRODUCTION_TRAFFIC_SHIFT sind PRODUCTION_TRAFFIC_SHIFT oder bei jedem Shift-Schritt aufgerufen werden.

• Zielgruppe – Eine Ressource für Elastic Load Balancing, die verwendet wird, um Anfragen an ein oder mehrere registrierte Ziele (z. B. EC2-Instances) weiterzuleiten. 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 Ressource für Elastic Load Balancing, die Verbindungsanforderungen mit dem von Ihnen konfigurierten Protokoll und Port überprüft. Die Regeln, die Sie für einen Listener definieren, bestimmen, wie der Amazon ECS Anforderungen an registrierte Ziele weiterleitet.

• Regel – Eine Ressource für Elastic Load Balancing, 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:

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

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

• Rollback: Lineare Bereitstellungen erleichtern das Zurücksetzen auf die vorherige Version, falls Probleme festgestellt 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 zunehmenden Verlagerung des Datenverkehrs und der Wartezeiten zwischen den einzelnen Schritten länger als bei Komplettbereitstellungen.

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. Lineare Phase der Verkehrsverlagerung: Verlagern Sie den Produktionsdatenverkehr schrittweise von blau auf grün, und zwar in Schritten zu gleichen Prozentsätzen, basierend auf Ihrer konfigurierten Bereitstellungsstrategie.

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) Dienstrevision empfängt Testverkehr, aber zunächst keinen Produktionsverkehr.

• Inkrementelle Verkehrsverlagerung — Der Verkehr wird schrittweise in gleichen Prozentsätzen von blau nach grün verlagert. Bei einer Konfiguration mit 10,0% -Schritten treten Verkehrsverschiebungen beispielsweise wie folgt auf:

  • Schritt 1:10,0% auf Grün, 90,0% auf 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 sind

• Step-Bake-Zeit — Zwischen jeder Erhöhung der Verkehrsschicht wartet die Bereitstellung für eine konfigurierbare Dauer (Step-Bake-Time), damit die Leistung der neuen Version angesichts der erhöhten Verkehrslast überwacht und validiert werden kann. Beachten Sie, dass die Backzeit des letzten Schritts übersprungen wird, sobald der Traffic um 100,0% verlagert wird.

• Lifecycle-Hooks — Optionale Lambda-Funktionen oder Pause-Hooks können in verschiedenen Lebenszyklusphasen während der Bereitstellung konfiguriert werden, um eine automatische Validierung, Überwachung oder benutzerdefinierte Logik durchzuführen. Hooks, die für jeden Schritt der Verkehrsverlagerung in der Produktion konfiguriert PRE_PRODUCTION_TRAFFIC_SHIFT sind PRODUCTION_TRAFFIC_SHIFT oder bei jedem Schritt aufgerufen werden.

Lebenszyklusphasen der Bereitstellung

Der lineare Bereitstellungsprozess durchläuft verschiedene Lebenszyklusphasen mit jeweils spezifischen Verantwortlichkeiten und Validierungsprüfpunkten. 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. Zusätzlich kann jeder Schritt zur Verkehrsverlagerung 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 kommt zu einem Timeout, die Bereitstellung schlägt fehl und initiiert dann ein Rollback, wenn eine Phase 24 Stunden erreicht ist.

CloudFormation Für Bereitstellungen gelten zusätzliche Timeout-Einschränkungen. Das 24-Stunden-Zeitlimit bleibt zwar in Kraft, CloudFormation erzwingt jedoch ein Limit von 36 Stunden für den gesamten Einsatz. CloudFormation schlägt bei der Bereitstellung fehl und leitet dann ein Rollback ein, wenn der Vorgang nicht innerhalb von 36 Stunden abgeschlossen ist.

Für Pause-Hooks können Sie den Timeout auf bis zu 20.160 Minuten (14 Tage) konfigurieren. Der allgemeine Timeout für die Bereitstellung beträgt 30 Tage.

Lebenszyklusphasen	Description	Lifecycle Hook-Unterstützung
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 (nur Lambda)
POST_TEST_TRAFFIC_SHIFT	Die Verlagerung des Test-Datenverkehrs ist abgeschlossen. Die grüne Service-Revision wickelt 100 % des Test-Datenverkehrs ab.	Ja
VERKEHRSSCHICHT VOR DER PRODUKTION	Tritt vor jeder Erhöhung der Verkehrsverlagerung in der Produktion auf. Für diese Phase konfigurierte Lifecycle-Hooks werden bei jeder Verkehrsverlagerung aufgerufen.	Ja
PRODUCTION_TRAFFIC_SHIFT	Der Verkehr wird schrittweise in gleichen Prozentsätzen von Blau auf Grün verlagert, bis 100% des Verkehrs auf Grün entfallen. Bei jeder Verkehrsverlagerung wird ein Lifecycle-Hook mit einem Timeout von 24 Stunden ausgelöst.	Ja (nur Lambda)
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