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. # Erforderliche Ressourcen für Amazon blue/green ECS-Bereitstellungen Um eine blue/green Bereitstellung mit verwalteter Verkehrsverlagerung zu verwenden, muss Ihr Service eine der folgenden Funktionen verwenden: + Elastic Load Balancing + Service Connect Dienste, die Service Discovery, Service Connect, VPC Lattice oder Elastic Load Balancing nicht verwenden, können ebenfalls blue/green Bereitstellungen verwenden, profitieren aber nicht von den Vorteilen der verwalteten Verkehrsverlagerung. Die folgende Liste bietet einen allgemeinen Überblick darüber, was Sie für Amazon blue/green ECS-Bereitstellungen konfigurieren müssen: + Ihr Service verwendet Application Load Balancer, Network Load Balancer oder Service Connect Konfigurieren Sie die entsprechenden Ressourcen. + Application Load Balancer – Weitere Informationen finden Sie unter [Application Load Balancer Balancer-Ressourcen für blaue/grüne, lineare und kanarische Bereitstellungen](alb-resources-for-blue-green.md). + Network Load Balancer – Weitere Informationen finden Sie unter [Network Load Balancer Balancer-Ressourcen für Amazon ECS Blue/Green-, Linear- und Canary-Bereitstellungen](nlb-resources-for-blue-green.md). + Service Connect – Weitere Informationen finden Sie unter [Service Connect-Ressourcen für blaue/grüne, lineare und kanarische Bereitstellungen von Amazon ECS](service-connect-blue-green.md). + Stellen Sie den Bereitstellungs-Controller des Services auf `ECS`. + Konfigurieren Sie die Bereitstellungsstrategie als `blue/green` in der Servicedefinition. + Optional können Sie zusätzliche Parameter konfigurieren, z. B.: + Bake-Zeit für die neue Bereitstellung + CloudWatch Alarme für automatisches Rollback + Bereitstellungs-Lebenszyklus-Hooks zum Testen (dies sind Lambda-Funktionen, die in bestimmten Bereitstellungsphasen ausgeführt werden) ## Best Practices Folgen Sie diesen bewährten Methoden für erfolgreiche Amazon blue/green ECS-Bereitstellungen: + Konfigurieren Sie geeignete Zustandsprüfungen, die den Zustand Ihrer Anwendung genau widerspiegeln. + Stellen Sie eine Bake-Zeit ein, die ausreichende Tests der Grün-Bereitstellung ermöglicht. + Implementieren Sie CloudWatch Alarme, um Probleme automatisch zu erkennen und Rollbacks auszulösen. + Verwenden Sie Lebenszyklus-Hooks, um automatisierte Tests in jeder Bereitstellungsphase durchzuführen. + Stellen Sie sicher, dass Ihre Anwendung sowohl blaue als auch grüne Service-Revisionen verarbeiten kann, die gleichzeitig ausgeführt werden. + Planen Sie ausreichend Clusterkapazität ein, um beide Service-Revisionen während der Bereitstellung verarbeiten zu können. + Testen Sie Ihre Rollback-Verfahren, bevor Sie sie in der Produktion implementieren. # Application Load Balancer Balancer-Ressourcen für blaue/grüne, lineare und kanarische Bereitstellungen Um Application Load Balancers mit Amazon blue/green ECS-Bereitstellungen zu verwenden, müssen Sie bestimmte Ressourcen konfigurieren, die das Routing des Datenverkehrs zwischen den blauen und grünen Service-Revisionen ermöglichen. ## Zielgruppen Für blue/green Bereitstellungen mit Elastic Load Balancing müssen Sie zwei Zielgruppen erstellen: + Eine primäre Zielgruppe für die blaue Service-Revision (aktueller Produktionsdatenverkehr) + Eine alternative Zielgruppe für die grüne Service-Revision (neue Version) Beide Zielgruppen sollten mit den folgenden Einstellungen konfiguriert werden: + Zieltyp: `IP` (für Fargate oder EC2 mit `awsvpc`-Netzwerkmodus) + Protokoll: `HTTP` (oder das Protokoll, das Ihre Anwendung verwendet) + Port: Der Port, auf dem Ihre Anwendung lauscht (normalerweise `80` für HTTP) + VPC: Dieselbe VPC wie Ihre Amazon-ECS-Aufgaben + Zustandsprüfung-Einstellungen: So konfiguriert, dass sie den Zustand Ihrer Anwendung ordnungsgemäß überprüfen Während einer blue/green Bereitstellung registriert Amazon ECS je nach Bereitstellungsphase automatisch Aufgaben bei der entsprechenden Zielgruppe. **Example Zielgruppen für einen Application Load Balancer erstellen** Mit den folgenden CLI-Befehlen werden zwei Zielgruppen für die Verwendung mit einem Application Load Balancer in einer blue/green Bereitstellung erstellt: ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 aws elbv2 create-target-group \ --name green-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 ``` ## Application Load Balancer Sie müssen einen Application Load Balancer mit der folgenden Konfiguration erstellen: + Schema: Mit dem Internet verbunden oder intern, je nach Ihren Anforderungen + IP-Adresstyp: IPv4 + VPC: Dieselbe VPC wie Ihre Amazon-ECS-Aufgaben + Subnetze: Mindestens zwei Subnetze in verschiedenen Availability Zones. + Sicherheitsgruppen: Eine Sicherheitsgruppe, die den Datenverkehr auf den Listener-Ports zulässt Die dem Application Load Balancer zugeordnete Sicherheitsgruppe muss über eine ausgehende Regel verfügen, die den Datenverkehr zu der Sicherheitsgruppe zulässt, die Ihren Amazon-ECS-Aufgaben zugeordnet ist. **Example Erstellen eines Application Load Balancers** Der folgende CLI-Befehl erstellt einen Application Load Balancer für die Verwendung in einer Blau/Grün-Bereitstellung: ``` aws elbv2 create-load-balancer \ --name my-application-load-balancer \ --type application \ --security-groups sg-abcd1234 \ --subnets subnet-12345678 subnet-87654321 ``` ## Listener und Regeln Für blue/green Bereitstellungen müssen Sie Listener auf Ihrem Application Load Balancer konfigurieren: + Produktions-Listener: Verwaltet den Produktionsdatenverkehr (normalerweise auf Port 80 oder 443) + Leitet den Verkehr zunächst an die primäre Zielgruppe weiter (blaue Service-Revision) + Leitet den Verkehr nach der Bereitstellung an die alternative Zielgruppe weiter (grüne Service-Revision) + Test-Listener (optional): Verarbeitet den Test-Datenverkehr, um die grüne Service-Version zu validieren, bevor der Produktionsdatenverkehr verlagert wird + Kann an einem anderen Port konfiguriert werden (z. B. 8080 oder 8443) + Leitet den Datenverkehr während des Tests an die alternative Zielgruppe weiter (grüne Service-Revision) Während einer blue/green Bereitstellung aktualisiert Amazon ECS automatisch die Listener-Regeln, um den Datenverkehr je nach Bereitstellungsphase an die entsprechende Zielgruppe weiterzuleiten. **Example Erstellen eines Produktions-Listeners** Der folgende CLI-Befehl erstellt einen Produktions-Listener auf Port 80, der den Datenverkehr an die primäre (blaue) Zielgruppe weiterleitet: ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456 ``` **Example Erstellen eines Test-Listeners** Der folgende CLI-Befehl erstellt einen Test-Listener auf Port 8080, der den Datenverkehr an die alternative (grüne) Zielgruppe weiterleitet: ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 8080 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Erstellen einer Listener-Regel für pfadbasiertes Routing** Der folgende CLI-Befehl erstellt eine Regel, die den Datenverkehr für einen bestimmten Pfad zum Testen an die grüne Zielgruppe weiterleitet: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 10 \ --conditions Field=path-pattern,Values='/test/*' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Erstellen einer Listener-Regel für Header-basiertes Routing** Der folgende CLI-Befehl erstellt eine Regel, die Datenverkehr mit einem bestimmten Header zum Testen an die grüne Zielgruppe weiterleitet: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 20 \ --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` ## Service-Konfiguration Sie müssen über die erforderlichen Berechtigungen verfügen, um Amazon ECS die Verwaltung von Load Balancer-Ressourcen in Ihren Clustern in Ihrem Namen zu erlauben. Weitere Informationen finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Wenn Sie einen Amazon ECS-Service für blue/green Bereitstellungen mit Elastic Load Balancing erstellen oder aktualisieren, müssen Sie die folgende Konfiguration angeben. Ersetzen Sie die *user-input* durch Ihre Werte. Die wichtigsten Komponenten dieser Konfiguration sind: + `targetGroupArn`: Der ARN der primären Zielgruppe (blaue Service-Revision). + `alternateTargetGroupArn`: Der ARN der alternativen Zielgruppe (grüne Service-Revision). + `productionListenerRule`: Der ARN der Listener-Regel für den Produktionsdatenverkehr. + `roleArn`: Der ARN der Rolle, die es Amazon ECS erlaubt, Ressourcen für Elastic Load Balancing zu verwalten. + `strategy`: Auf `BLUE_GREEN` einstellen, um Blau/Grün-Bereitstellungen zu ermöglichen. + `bakeTimeInMinutes`: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde. + `TestListenerRule`: Der ARN der Listener-Regel für den Test-Datenverkehr. Dieser Parameter ist optional. ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012", "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678", "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Datenverkehrsfluss während der Bereitstellung Während einer blue/green Bereitstellung mit Elastic Load Balancing fließt der Datenverkehr wie folgt durch das System: 1. *Ausgangszustand*: Der gesamte Produktionsdatenverkehr wird an die primäre Zielgruppe weitergeleitet (blaue Service-Revision). 1. *Bereitstellung der grünen Service-Revision*: Amazon ECS stellt die neuen Aufgaben bereit und registriert sie bei der alternativen Zielgruppe. 1. *Test-Datenverkehr*: Wenn ein Test-Listener konfiguriert ist, wird der Test-Datenverkehr an die alternative Zielgruppe weitergeleitet, um die grüne Service-Revision zu validieren. 1. *Verlagerung des Produktionsdatenverkehrs*: Amazon ECS aktualisiert die Produktions-Listener-Regel, um den Datenverkehr an die alternative Zielgruppe weiterzuleiten (grüne Service-Revision). 1. *Bake-Zeit*: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde. 1. *Abschluss*: Nach einer erfolgreichen Bereitstellung wird die blaue Service-Revision beendet. Wenn während der Bereitstellung Probleme festgestellt werden, kann Amazon ECS automatisch ein Rollback durchführen, indem der Datenverkehr an die primäre Zielgruppe zurückgeleitet wird (blaue Service-Revision). # Network Load Balancer Balancer-Ressourcen für Amazon ECS Blue/Green-, Linear- und Canary-Bereitstellungen Um einen Network Load Balancer mit Amazon blue/green ECS-Bereitstellungen zu verwenden, müssen Sie bestimmte Ressourcen konfigurieren, die das Routing des Datenverkehrs zwischen den blauen und grünen Service-Revisionen ermöglichen. In diesem Abschnitt werden die erforderlichen Komponenten und ihre Konfiguration erläutert. Wenn Ihre Konfiguration einen Network Load Balancer beinhaltet, fügt Amazon ECS den folgenden Lebenszyklusphasen eine Verzögerung von 10 Minuten hinzu: + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT Diese Verzögerung ist auf Timing-Probleme des Network Load Balancer zurückzuführen, die zu einer Diskrepanz zwischen den konfigurierten Datenverkehrs-Gewichtungen und dem tatsächlichen Datenverkehrs-Routing auf der Datenebene führen können. ## Zielgruppen Für blue/green Bereitstellungen mit einem Network Load Balancer müssen Sie zwei Zielgruppen erstellen: + Eine primäre Zielgruppe für die blaue Service-Revision (aktueller Produktionsdatenverkehr) + Eine alternative Zielgruppe für die grüne Service-Revision (neue Service-Revision) Beide Zielgruppen sollten mit den folgenden Einstellungen konfiguriert werden: + Zieltyp: `ip` (für Fargate oder EC2 mit `awsvpc`-Netzwerkmodus) + Protokoll: `TCP` (oder das Protokoll, das Ihre Anwendung verwendet) + Port: Der Port, auf dem Ihre Anwendung lauscht (normalerweise `80` für HTTP) + VPC: Dieselbe VPC wie Ihre Amazon-ECS-Aufgaben + Zustandsprüfung-Einstellungen: So konfiguriert, dass sie den Zustand Ihrer Anwendung ordnungsgemäß überprüfen Für TCP-Zustandsprüfungen stellt der Network Load Balancer eine TCP-Verbindung mit dem Ziel her. Wenn die Verbindung erfolgreich ist, gilt das Ziel als fehlerfrei. Für HTTP/HTTPS Zustandsprüfungen sendet der Network Load Balancer eine HTTP/HTTPS Anfrage an das Ziel und verifiziert die Antwort. Während einer blue/green Bereitstellung registriert Amazon ECS je nach Bereitstellungsphase automatisch Aufgaben bei der entsprechenden Zielgruppe. **Example Erstellen von Zielgruppen für einen Network Load Balancer** Mit den folgenden AWS CLI-Befehlen werden zwei Zielgruppen für die Verwendung mit einem Network Load Balancer in einer blue/green Bereitstellung erstellt: ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP aws elbv2 create-target-group \ --name green-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP ``` ## Network Load Balancer Sie müssen einen Network Load Balancer mit der folgenden Konfiguration erstellen: + Schema: Mit dem Internet verbunden oder intern, je nach Ihren Anforderungen + IP-Adresstyp: IPv4 + VPC: Dieselbe VPC wie Ihre Amazon-ECS-Aufgaben + Subnetze: Mindestens zwei Subnetze in verschiedenen Availability Zones. Im Gegensatz zu Application Load Balancers arbeiten Network Load Balancers auf der Transportebene (Ebene 4) und verwenden keine Sicherheitsgruppen. Stattdessen müssen Sie sicherstellen, dass die Ihren Amazon-ECS-Aufgaben zugeordneten Sicherheitsgruppen Datenverkehr vom Network Load Balancer auf den Listener-Ports erlauben. **Example Erstellen eines Network Load Balancers** Der folgende AWS CLI-Befehl erstellt einen Network Load Balancer zur Verwendung in einer blue/green Bereitstellung: ``` aws elbv2 create-load-balancer \ --name my-network-load-balancer \ --type network \ --subnets subnet-12345678 subnet-87654321 ``` ## Überlegungen zur Verwendung von NLB bei Bereitstellungen blue/green Beachten Sie bei der Verwendung eines Network Load Balancer für blue/green Bereitstellungen Folgendes: + **Ebene-4-Betrieb**: Network Load Balancers arbeiten auf der Transportebene (Ebene 4) und untersuchen nicht den Inhalt der Anwendungsebene (Ebene 7). Das bedeutet, dass Sie keine HTTP-Header oder -Pfade für Routing-Entscheidungen verwenden können. + **Zustandsprüfungen**: Die Zustandsprüfungen des Network Load Balancer sind auf die Protokolle TCP, HTTP oder HTTPS beschränkt. Bei TCP-Zustandsprüfungen überprüft der Network Load Balancer nur, ob die Verbindung hergestellt werden kann. + **Aufrechterhaltung der Verbindung**: Network Load Balancer speichern die Quell-IP-Adresse des Clients, was aus Sicherheits- und Protokollierungsgründen nützlich sein kann. + **Statische IP-Adressen**: Network Load Balancer stellen statische IP-Adressen für jedes Subnetz bereit. Dies kann nützlich sein, wenn Clients auf die Whitelist gesetzt werden oder wenn Clients eine Verbindung zu einer festen IP-Adresse herstellen müssen. + **Test-Datenverkehr**: Da Network Load Balancer kein inhaltsbasiertes Routing unterstützen, muss der Test-Datenverkehr an einen anderen Port als der Produktionsdatenverkehr gesendet werden. ## Listener und Regeln Für blue/green Bereitstellungen mit einem Network Load Balancer müssen Sie Listener konfigurieren: + Produktions-Listener: Verwaltet den Produktionsdatenverkehr (normalerweise auf Port 80 oder 443) + Leitet den Verkehr zunächst an die primäre Zielgruppe weiter (blaue Service-Revision) + Leitet den Verkehr nach der Bereitstellung an die alternative Zielgruppe weiter (grüne Service-Revision) + Test-Listener (optional): Verarbeitet den Test-Datenverkehr, um die grüne Service-Version zu validieren, bevor der Produktionsdatenverkehr verlagert wird + Kann auf einem anderen Port konfiguriert werden (z. B. 8080 oder 8443) + Leitet den Datenverkehr während des Tests an die alternative Zielgruppe weiter (grüne Service-Revision) Im Gegensatz zu Application Load Balancers unterstützen Network Load Balancer keine inhaltsbasierten Routing-Regeln. Stattdessen wird der Datenverkehr auf der Grundlage des Listener-Ports und des Protokolls weitergeleitet. Die folgenden AWS CLI-Befehle erstellen Produktions- und Test-Listener für einen Network Load Balancer: Ersetzen Sie die *user-input* durch Ihre Werte. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 80 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456 aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 8080 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456 ``` ## Service-Konfiguration Sie müssen über die erforderlichen Berechtigungen verfügen, um Amazon ECS die Verwaltung von Load Balancer-Ressourcen in Ihren Clustern in Ihrem Namen zu erlauben. Weitere Informationen finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Wenn Sie einen Amazon ECS-Service für blue/green Bereitstellungen mit einem Network Load Balancer erstellen oder aktualisieren, müssen Sie die folgende Konfiguration angeben: Ersetzen Sie die *user-input* durch Ihre Werte. Die wichtigsten Komponenten dieser Konfiguration sind: + `targetGroupArn`: Der ARN der primären Zielgruppe (blaue Service-Revision). + `alternateTargetGroupArn`: Der ARN der alternativen Zielgruppe (grüne Service-Revision). + `productionListenerRule`: Der ARN des Listener für den Produktionsdatenverkehr. + `testListenerRule`: (optional) Der ARN des Listener für den Test-Datenverkehr. + `roleArn`: Der ARN der Rolle, die es Amazon ECS erlaubt, Ressourcen für Network Load Balancer zu verwalten. + `strategy`: Auf einstellen, `BLUE_GREEN` um blue/green Bereitstellungen zu ermöglichen + `bakeTimeInMinutes`: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem sich der Produktionsdatenverkehr verlagert hat ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456", "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456", "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567", "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Datenverkehrsfluss während der Bereitstellung Während einer blue/green Bereitstellung mit einem Network Load Balancer fließt der Datenverkehr wie folgt durch das System: 1. *Ausgangszustand*: Der gesamte Produktionsdatenverkehr wird an die primäre Zielgruppe weitergeleitet (blaue Service-Revision). 1. *Bereitstellung der grünen Service-Revision*: Amazon ECS stellt die neuen Aufgaben bereit und registriert sie bei der alternativen Zielgruppe. 1. *Test-Datenverkehr*: Wenn ein Test-Listener konfiguriert ist, wird der Test-Datenverkehr an die alternative Zielgruppe weitergeleitet, um die grüne Service-Revision zu validieren. 1. *Verlagerung des Produktionsdatenverkehrs*: Amazon ECS aktualisiert den Produktions-Listener, um den Datenverkehr an die alternative Zielgruppe weiterzuleiten (grüne Service-Revision). 1. *Bake-Zeit*: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde. 1. *Abschluss*: Nach einer erfolgreichen Bereitstellung wird die blaue Service-Revision beendet. Wenn während der Bereitstellung Probleme festgestellt werden, kann Amazon ECS automatisch ein Rollback durchführen, indem der Datenverkehr an die primäre Zielgruppe zurückgeleitet wird (blaue Service-Revision). # 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 [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)in 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 bei 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 [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)in 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 [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html)in 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. 1. **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. 1. **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. 1. **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. 1. **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. 1. **Bake-Zeitraum**: Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde. 1. **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.