Service Connect-Ressourcen für blaue/grüne, lineare und kanarische 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.

Service Connect-Ressourcen für blaue/grüne, lineare und kanarische Bereitstellungen von Amazon ECS

Wenn Sie Service Connect mit blue/green Bereitstellungen verwenden, müssen Sie bestimmte Komponenten konfigurieren, um eine korrekte Weiterleitung des Datenverkehrs zwischen den blauen und grünen Dienstversionen zu ermöglichen. In diesem Abschnitt werden die erforderlichen Komponenten und ihre Konfiguration erläutert.

Übersicht über die Architektur

Service Connect erstellt sowohl Serviceerkennungs- als auch Service-Mesh-Funktionen über einen verwalteten Sidecar-Proxy, der automatisch in Ihre Amazon-ECS-Aufgaben eingefügt wird. Diese Proxys kümmern sich um Routing-Entscheidungen, Wiederholungsversuche und die Erfassung von Metriken und stellen gleichzeitig das Service-Registry-Backend AWS Cloud Map bereit. Wenn Sie einen Dienst mit aktiviertem Service Connect bereitstellen, registriert sich der Dienst selbst AWS Cloud Map, und die Clientdienste erkennen ihn über den Namespace.

In einer standardmäßigen Service-Connect-Implementierung stellen Client-Services eine Verbindung zu logischen Service-Namen her, und der Sidecar-Proxy übernimmt das Routing zu den eigentlichen Service-Instances. Bei blue/green Bereitstellungen wird dieses Modell um die Weiterleitung von Testdatenverkehr durch die testTrafficRules Konfiguration erweitert.

Während einer blue/green Bereitstellung arbeiten die folgenden Schlüsselkomponenten zusammen:

  • Service-Connect-Proxy: Der gesamte Datenverkehr zwischen Services wird über den Service-Connect-Proxy geleitet, der Routing-Entscheidungen auf der Grundlage der Konfiguration trifft.

  • AWS Cloud Map Registrierung: Sowohl blaue als auch grüne Bereitstellungen werden bei registriert AWS Cloud Map, aber die grüne Bereitstellung wird zunächst als „Test“ -Endpunkt registriert.

  • Test-Datenverkehrs-Routing: Die testTrafficRules in der Service-Connect-Konfiguration bestimmen, wie Test-Datenverkehr identifiziert und an die Grün-Bereitstellung weitergeleitet werden soll. Dies wird durch Header-basiertes Routing erreicht, bei dem spezifische HTTP-Header in den Anfragen den Datenverkehr an die Test-Revision weiterleiten. Standardmäßig erkennt Service Connect den x-amzn-ecs-blue-green-test-Header für HTTP-basierte Protokolle, wenn keine benutzerdefinierten Regeln angegeben sind.

  • Client-Konfiguration: Alle Clients im Namespace erhalten automatisch sowohl Produktions- als auch Testrouten, aber nur Anfragen, die den Testregeln entsprechen, werden an die Grün-Bereitstellung weitergeleitet.

Das Besondere an diesem Ansatz ist, dass er die Komplexität der Serviceerkennung bei Übergängen bewältigt. Wenn der Datenverkehr von der blauen zur grünen Bereitstellung wechselt, werden alle Konnektivitäts- und Erkennungsmechanismen automatisch aktualisiert. Es ist nicht erforderlich, DNS-Einträge zu aktualisieren, Load Balancer neu zu konfigurieren oder Änderungen der Serviceerkennung separat bereitzustellen, da das Service Mesh alles erledigt.

Routing und Testen des Datenverkehrs

Service Connect bietet erweiterte Datenverkehrs-Routing-Funktionen für blue/green Bereitstellungen, einschließlich Header-basiertem Routing und Client-Alias-Konfiguration für Testszenarien.

Header-Regeln für Test-Datenverkehr

Während der blue/green Bereitstellung können Sie Header-Regeln für den Testdatenverkehr so konfigurieren, dass bestimmte Anfragen zu Testzwecken an die grüne (neue) Service-Version weitergeleitet werden. Auf diese Weise können Sie die neue Version mit kontrolliertem Datenverkehr validieren, bevor Sie die Bereitstellung abschließen.

Service Connect verwendet Header-basiertes Routing, um Test-Datenverkehr zu identifizieren. Standardmäßig erkennt Service Connect den x-amzn-ecs-blue-green-test-Header für HTTP-basierte Protokolle, wenn keine benutzerdefinierten Regeln angegeben sind. Wenn dieser Header in einer Anforderung vorhanden ist, leitet der Service-Connect-Proxy die Anforderung automatisch zum Testen an die Grün-Bereitstellung weiter.

Mithilfe von Testdatenverkehr-Headerregeln können Sie:

  • Anfragen mit bestimmten Headern an die grüne Serviceversion weiterleiten

  • Neue Funktionen mit einem Teil des Datenverkehrs testen

  • Das Serviceverhalten vor dem vollständigen Cutover des Datenverkehrs validieren

  • Implementieren von Canary-Teststrategien

  • Integrationstests in einer produktionsähnlichen Umgebung durchführen

Der Header-basierte Routing-Mechanismus funktioniert nahtlos in Ihrer bestehenden Anwendungsarchitektur. Clientdienste müssen sich des blue/green Bereitstellungsprozesses nicht bewusst sein — sie fügen einfach die entsprechenden Header hinzu, wenn sie Testanfragen senden, und der Service Connect-Proxy verarbeitet die Routing-Logik automatisch.

Weitere Informationen zur Konfiguration von Test-Traffic-Header-Regeln finden Sie ServiceConnectTestTrafficHeaderRulesin der Amazon Elastic Container Service API-Referenz.

Abgleich von Header-Regeln

Regeln für den Header-Abgleich definieren die Kriterien für die Weiterleitung von Testdatenverkehr während blue/green Bereitstellungen. Sie können mehrere Bedingungen konfigurieren, um genau zu steuern, welche Anfragen an die grüne Serviceversion weitergeleitet werden.

Header-Matching unterstützt:

  • Exakte Übereinstimmung mit den Header-Werten

  • Überprüfung der Header-Präsenz

  • Musterbasiertes Matching

  • Mehrere Header-Kombinationen

Zu den Anwendungsfällen gehören beispielsweise das Weiterleiten von Anfragen mit bestimmten User-Agent-Zeichenfolgen, API-Versionen oder Feature-Flags zum Testen an den grünen Service.

Weitere Informationen zur Konfiguration des Header-Matchings finden Sie ServiceConnectTestTrafficHeaderMatchRulesin der Amazon Elastic Container Service API-Referenz.

Client-Aliase für Bereitstellungen blue/green

Client-Aliase bieten stabile DNS-Endpunkte für Dienste während der Bereitstellung. blue/green Diese ermöglichen ein nahtloses Routing des Datenverkehrs zwischen blauen und grünen Service-Revisionen, ohne dass Client-Anwendungen ihre Verbindungsendpunkte ändern müssen.

Während einer blue/green Bereitstellung führen Client-Aliase Folgendes durch:

  • Behalten konsistente DNS-Namen für Client-Verbindungen bei

  • Ermöglichen die automatische Verlagerung des Datenverkehrs zwischen Service-Revisionen

  • Support schrittweiser Strategien zur Migration von Datenverkehr

  • Stellen Rollback-Funktionen bereit, indem sie den Datenverkehr auf die blaue Revision umleiten

Sie können mehrere Client-Aliase für verschiedene Ports oder Protokolle konfigurieren, sodass komplexe Service-Architekturen die Konnektivität während der Bereitstellung aufrechterhalten können.

Weitere Informationen zur Konfiguration von Client-Alias finden Sie ServiceConnectClientAliasin der Amazon Elastic Container Service API-Referenz.

Bewährte Methoden für das Routing des Datenverkehrs

Beachten Sie bei der Implementierung des Datenverkehrs-Routings für blue/green Bereitstellungen mit Service Connect die folgenden bewährten Methoden:

  • Beginnen Sie mit headerbasierten Tests: Verwenden Sie Testdatenverkehr-Headerregeln, um den grünen Service mit kontrolliertem Datenverkehr zu validieren, bevor Sie den gesamten Datenverkehr übertragen.

  • Zustandsprüfungen konfigurieren: Stellen Sie sicher, dass sowohl für blaue als auch für grüne Services entsprechende Zustandsprüfungen konfiguriert sind, um zu verhindern, dass Datenverkehr zu fehlerhaften Instances weitergeleitet wird.

  • Überwachen Sie die Servicemetriken: Verfolgen Sie die wichtigsten Leistungsindikatoren für beide Serviceversionen während der Bereitstellung, um Probleme frühzeitig zu erkennen.

  • Rollback-Strategie planen: Konfigurieren Sie Client-Aliase und Routing-Regeln, um ein schnelles Rollback zum blauen Service zu ermöglichen, falls Probleme festgestellt werden.

  • Testen Sie die Header-Abgleichslogik: Überprüfen Sie Ihre Header-Abgleichsregeln in einer Nicht-Produktionsumgebung, bevor Sie sie auf Produktionsbereitstellungen anwenden.

Arbeitsablauf für die blue/green Bereitstellung von Service Connect

Wenn Sie wissen, wie Service Connect den blue/green Bereitstellungsprozess verwaltet, können Sie Ihre Bereitstellungen effektiv implementieren und Fehler beheben. Der folgende Workflow zeigt, wie die verschiedenen Komponenten in jeder Phase der Bereitstellung interagieren.

Bereitstellungsphasen

Eine Service blue/green Connect-Bereitstellung durchläuft mehrere unterschiedliche Phasen:

  1. Ausgangszustand: Der blaue Service wickelt 100 % des Produktionsdatenverkehrs ab. Alle Client-Services im Namespace stellen über den in Service Connect konfigurierten logischen Service-Namen eine Verbindung zum blauen Service her.

  2. Green Service-Registrierung: Wenn die grüne Bereitstellung beginnt, wird sie AWS Cloud Map als „Test“ -Endpunkt registriert. Der Service-Connect-Proxy in den Client-Services empfängt automatisch sowohl Produktions- als auch Testroutenkonfigurationen.

  3. Test-Datenverkehrs-Routing: Anfragen, die die Test-Datenverkehr-Header (z. B. x-amzn-ecs-blue-green-test) enthalten, werden vom Service-Connect-Proxy automatisch an den grünen Service weitergeleitet. Der Produktionsdatenverkehr fließt weiterhin zum blauen Service.

  4. Vorbereitung der Datenverkehrsverlagerung: Nach erfolgreichen Tests bereitet der Bereitstellungsprozess die Verlagerung des Produktionsdatenverkehrs vor. Sowohl die blauen als auch die grünen Services sind weiterhin registriert und fehlerfrei.

  5. Verlagerung des Produktionsdatenverkehrs: Die Service-Connect-Konfiguration wird aktualisiert, um den Produktionsdatenverkehr an den grünen Service weiterzuleiten. Dies geschieht automatisch, ohne dass Aktualisierungen des Client-Services oder DNS-Änderungen erforderlich sind.

  6. Bake-Zeitraum: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde.

  7. Blue Service-Abmeldung: Nach erfolgreicher Verkehrsverlagerung und Validierung wird der Blue Service abgemeldet AWS Cloud Map und beendet, wodurch die Bereitstellung abgeschlossen ist.

Verhalten des Service-Connect-Proxys

Der Service Connect-Proxy spielt eine entscheidende Rolle bei der Verwaltung des Datenverkehrs während der blue/green Bereitstellung. Wenn Sie sein Verhalten verstehen, können Sie effektive Test- und Bereitstellungsstrategien entwickeln.

Die wichtigsten Verhaltensweisen von Proxys bei blue/green Bereitstellungen:

  • Automatische Routenerkennung: Der Proxy erkennt automatisch sowohl Produktions- als auch Testrouten, AWS Cloud Map ohne dass Anwendungsneustarts oder Konfigurationsänderungen erforderlich sind.

  • Header-basiertes Routing: Der Proxy untersucht eingehende Anforderungs-Header und leitet den Datenverkehr auf der Grundlage der konfigurierten Test-Datenverkehrsregeln an die entsprechende Service-Revision weiter.

  • Zustandsprüfung-Integration: Der Proxy leitet den Datenverkehr nur an fehlerfreie Service-Instances weiter und schließt fehlerhafte Aufgaben automatisch aus dem Routing-Pool aus.

  • Wiederholungsversuch und Schutzschalter: Der Proxy bietet eine integrierte Wiederholungslogik und Funktionen zum Unterbrechen von Verbindungen, wodurch die Ausfallsicherheit bei Bereitstellungen verbessert wird.

  • Erfassung von Metriken: Der Proxy erfasst detaillierte Metriken sowohl für blaue als auch für grüne Services und ermöglicht so eine umfassende Überwachung während der Bereitstellung.

Serviceerkennungs-Aktualisierungen

Einer der Hauptvorteile der Verwendung von Service Connect für blue/green Bereitstellungen ist die automatische Verarbeitung von Service Discovery-Updates. Herkömmliche blue/green Bereitstellungen erfordern oft komplexe DNS-Updates oder eine Neukonfiguration des Load Balancers, aber Service Connect verwaltet diese Änderungen transparent.

Während einer Bereitstellung verarbeitet Service Connect Folgendes:

  • Namespace-Aktualisierungen: Der Service-Connect-Namespace umfasst automatisch sowohl blaue als auch grüne Service-Endpunkte mit entsprechenden Routing-Regeln.

  • Client-Konfiguration: Alle Client-Services im Namespace erhalten automatisch aktualisierte Routing-Informationen, ohne dass Neustarts oder Neubereitstellungen erforderlich sind.

  • Schrittweiser Übergang: Serviceerkennung-Aktualisierungen werden schrittweise und sicher durchgeführt, sodass laufende Anfragen nicht unterbrochen werden.

  • Rollback-Unterstützung: Wenn ein Rollback erforderlich ist, kann Service Connect die Serviceerkennungs-Konfigurationen schnell rückgängig machen, um den Datenverkehr zurück zum blauen Service zu leiten.