3 <= 0.5 * 1 => 200| 3 (der berechnete Wert liegt unter dem Minimum) | | 25 |
3 <= 0.5 * 25 => 200| 13 (Der Wert wird aufgerundet) | | 400 |
3 <= 0.5 * 400 => 200| 200 | | 800 |
3 <= 0.5 * 800 => 200| 200 (Der berechnete Wert ist größer als das Maximum) | Wenn der Schwellenwert beispielsweise 3 ist, startet der Schutzschalter mit der Fehleranzahl, die auf 0 gesetzt ist. Wenn eine Aufgabe den Status `RUNNING` nicht erreicht, erhöht der Bereitstellungs-Schutzschalter die Fehleranzahl um eins. Wenn die Fehleranzahl 3 entspricht, wird die Bereitstellung als `FAILED` markiert. Weitere Beispiele zur Verwendung der Rollback-Option finden Sie unter [Ankündigung des Amazon-ECS-Bereitstellungsschutzschalters](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/). # So erkennen CloudWatch Alarme Bereitstellungsfehler bei Amazon ECS Sie können Amazon ECS so konfigurieren, dass die Bereitstellung auf „Fehlgeschlagen“ gesetzt wird, wenn erkannt wird, dass ein bestimmter CloudWatch Alarm in den `ALARM` Status übergegangen ist. Sie können die Konfiguration optional so einrichten, dass eine fehlgeschlagene Bereitstellung auf die zuletzt abgeschlossene Bereitstellung zurückgesetzt wird. Das folgende `create-service` AWS CLI Beispiel zeigt, wie ein Linux-Service erstellt wird, wenn die Bereitstellungsalarme mit der Rollback-Option verwendet werden. ``` aws ecs create-service \ --service-name MyService \ --deployment-controller type=ECS \ --desired-count 3 \ --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \ --task-definition sample-fargate:1 \ --launch-type FARGATE \ --platform-family LINUX \ --platform-version 1.4.0 \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" ``` Beachten Sie Folgendes, wenn Sie die CloudWatch Amazon-Alarmmethode für einen Service verwenden. + Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde. Amazon ECS berechnet diesen Zeitraum basierend auf der Alarmkonfiguration, die der Bereitstellung zugeordnet ist. Sie können diesen Wert nicht einstellen. + Der `deploymentConfiguration`-Anfrageparameter enthält jetzt den `alarms`-Datentyp. Sie können die Alarmnamen angeben, festlegen, ob die Methode verwendet werden soll und ob ein Rollback initiiert werden soll, wenn die Alarme einen Bereitstellungsfehler anzeigen. Weitere Informationen finden Sie [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)in der *Amazon Elastic Container Service API-Referenz*. + Die `DescribeServices`-Antwort bietet Einblick in den Status einer Bereitstellung, den `rolloutState` und `rolloutStateReason`. Wenn eine neue Bereitstellung gestartet wird, beginnt der Rollout-Status in einem `IN_PROGRESS`-Status. Wenn der Service einen stabilen Status erreicht und die Bake-Zeit abgeschlossen ist, wechselt der Rollout-Status zu `COMPLETED`. Wenn der Service keinen stabilen Status erreicht und der Alarm in den `ALARM`-Status übergegangen ist, wechselt die Bereitstellung in einen `FAILED`-Status. Eine Bereitstellung in einem `FAILED`-Status startet keine neuen Aufgaben. + Zusätzlich zu den Ereignissen zur Statusänderung der Service-Bereitstellung, die Amazon ECS für gestartete und abgeschlossene Bereitstellungen sendet, sendet Amazon ECS auch ein Ereignis, wenn eine Bereitstellung mit aktiviertem Alarmen fehlschlägt. Diese Ereignisse enthalten Details dazu, warum eine Bereitstellung fehlgeschlagen ist oder ob eine Bereitstellung aufgrund eines Rollbacks gestartet wurde. Weitere Informationen finden Sie unter [Statussänderungs-Ereignisse der Amazon-ECS-Servicebereitstellung](ecs_service_deployment_events.md). + Wenn eine neue Bereitstellung gestartet wird, weil eine vorherige Bereitstellung fehlgeschlagen ist und ein Rollback aufgetreten ist, zeigt das `reason`-Feld des Ereignisses für die Statusänderung der Service-Bereitstellung an, dass die Bereitstellung aufgrund eines Rollbacks gestartet wurde. + Wenn Sie den Deployment Circuit Breaker und die CloudWatch Amazon-Alarme verwenden, um Fehler zu erkennen, können beide einen Bereitstellungsfehler auslösen, sobald die Kriterien für eine der beiden Methoden erfüllt sind. Ein Rollback erfolgt, wenn Sie die Rollback-Option für die Methode verwenden, die den Bereitstellungsfehler ausgelöst hat. + Die CloudWatch Amazon-Alarme werden nur für Amazon ECS-Services unterstützt, die den Rolling Update (`ECS`) Deployment Controller verwenden. + Sie können diese Option mithilfe der Amazon-ECS-Konsole oder der AWS CLI konfigurieren. Weitere Informationen finden Sie unter [Erstellen eines Services mit definierten Parametern](create-service-console-v2.md#create-custom-service) und [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) in der *AWS Command Line Interface -Referenz*. + Möglicherweise stellen Sie fest, dass der Bereitstellungsstatus über einen längeren Zeitraum `IN_PROGRESS` bleibt. Der Grund dafür ist, dass Amazon ECS den Status erst ändert, wenn die aktive Bereitstellung gelöscht wurde. Dies geschieht erst nach der Bake-Zeit. Abhängig von Ihrer Alarmkonfiguration scheint die Bereitstellung möglicherweise einige Minuten länger zu dauern als ohne Verwendung von Alarmen (obwohl der neue primäre Aufgabensatz hochskaliert und die alte Bereitstellung herunterskaliert wird). Wenn Sie CloudFormation Timeouts verwenden, sollten Sie erwägen, die Timeouts zu erhöhen. Weitere Informationen finden Sie unter [Erstellen von Wartebedingungen in einer Vorlage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) im *AWS CloudFormation -Benutzerhandbuch*. + Amazon ECS ruft `DescribeAlarms` auf, um die Alarme abzufragen. Die Anrufe werden auf die mit Ihrem `DescribeAlarms` Konto verknüpften CloudWatch Servicekontingente angerechnet. Wenn Sie über andere AWS Dienste verfügen, die anrufen`DescribeAlarms`, kann dies Auswirkungen auf die Abfrage der Alarme durch Amazon ECS haben. Wenn beispielsweise ein anderer Service genügend `DescribeAlarms`-Aufrufe tätigt, um das Kontingent zu erreichen, wird dieser Service gedrosselt. Amazon ECS wird ebenfalls gedrosselt und kann keine Alarme abrufen. Wenn während des Drosselungszeitraums ein Alarm generiert wird, übersieht Amazon ECS möglicherweise den Alarm und der Rollback findet nicht statt. Es gibt keine weiteren Auswirkungen auf die Bereitstellung. Weitere Informationen zu CloudWatch Servicekontingenten finden Sie unter [CloudWatch Servicekontingenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) im *CloudWatch Benutzerhandbuch*. + Wenn sich ein Alarm zu Beginn einer Bereitstellung im Status `ALARM` befindet, überwacht Amazon ECS keine Alarme für die Dauer dieser Bereitstellung (Amazon ECS ignoriert die Alarmkonfiguration). Dieses Verhalten behandelt den Fall, in dem Sie eine neue Bereitstellung starten möchten, um einen anfänglichen Bereitstellungsfehler zu beheben. ## Empfohlene Alarme Wir empfehlen die Verwendung der folgenden Alarmmetriken: + Wenn Sie einen Application Load Balancer verwenden, verwenden Sie die Application-Load-Balancer-Metriken `HTTPCode_ELB_5XX_Count` und `HTTPCode_ELB_4XX_Count`. Diese Metriken überprüfen, ob HTTP-Spitzen vorliegen. Weitere Informationen zu den Application Load Balancer-Metriken finden Sie unter [CloudWatch Metriken für Ihren Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) im *Benutzerhandbuch für Application Load Balancers*. + Verwenden Sie bei einer vorhandenen Anwendung die `CPUUtilization`- und `MemoryUtilization`-Metriken. Diese Metriken überprüfen den Prozentsatz von CPU und Arbeitsspeicher, den der Cluster oder Service verwendet. Weitere Informationen finden Sie unter [Überlegungen](cloudwatch-metrics.md#enable_cloudwatch). + Wenn Sie Amazon Simple Queue Service Warteschlangen in Ihren Aufgaben verwenden, verwenden Sie die `ApproximateNumberOfMessagesNotVisible` Amazon SQS-Metrik. Diese Metrik prüft die Anzahl der Mitteilungen in der Warteschlange, die verzögert und nicht sofort zum Lesen verfügbar sind. Weitere Informationen zu Amazon SQS-Metriken finden Sie unter [Verfügbare CloudWatch Metriken für Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) im *Amazon Simple Queue Service Developer Guide*. ## Bake time (Bake-Zeit) Wenn Sie die Rollback-Option für Ihre Servicebereitstellungen verwenden, wartet Amazon ECS nach der Bereitstellung der Ziel-Servicerevision eine zusätzliche Zeit, bevor es einen Alarm sendet. CloudWatch Dies wird als Bake-Zeit bezeichnet. Diese Zeit beginnt nachdem: + Alle Aufgaben für eine Ziel-Service-Revision werden ausgeführt und befinden sich in einem fehlerfreien Zustand. + Die Revisionen des Quell-Services auf 0 % herunterskaliert wurden Die standardmäßige Bake-Zeit weniger als 5 Minuten beträgt. Die Servicebereitstellung nach Ablauf der Bake-Zeit als abgeschlossen markiert wird. Sie können die Bake-Zeit für eine fortlaufende Bereitstellung konfigurieren. Wenn Sie CloudWatch Alarme verwenden, um Fehler zu erkennen, wenn Sie die Backzeit ändern und dann entscheiden, dass Sie die Amazon ECS-Standardeinstellung verwenden möchten, müssen Sie die Backzeit manuell einstellen. # Lebenszyklus-Hooks für Amazon-ECS-Servicebereitstellungen Wenn eine Bereitstellung beginnt, durchläuft sie Lebenszyklusphasen. Diese Phasen können sich z. B. im Status IN\$1PROGRESS oder SUCCESSFUL befinden. Sie können Lebenszyklus-Hooks verwenden. Dabei handelt es sich um Lambda-Funktionen, die Amazon ECS in Ihrem Namen in bestimmten Lebenszyklusphasen ausführt. Diese Funktionen können eine der Folgenden sein: + Eine asynchrone API, die die Zustandsprüfung innerhalb von 15 Minuten validiert. + Eine Abfrage-API, die einen weiteren asynchronen Prozess einleitet, der den Abschluss des Lebenszyklus-Hook bewertet. Nachdem die Funktion die Ausführung abgeschlossen hat, muss sie einen `hookStatus` zurückgeben, damit die Bereitstellung fortgesetzt werden kann. Wenn ein `hookStatus` nicht zurückgegeben wird oder wenn die Funktion fehlschlägt, wird die Bereitstellung zurückgesetzt. Im Folgenden sehen Sie Werte für `hookStatus`: + `SUCCEEDED` – Die Bereitstellung wird bis zur nächsten Lebenszyklusphase fortgesetzt + `FAILED` – Die Bereitstellung wird auf die letzte erfolgreiche Bereitstellung zurückgesetzt. + `IN_PROGRESS` – Amazon ECS führt die Funktion nach kurzer Zeit erneut aus. Standardmäßig ist dies ein 30-Sekunden-Intervall. Dieser Wert kann jedoch angepasst werden, indem ein `callBackDelay` neben dem `hookStatus` zurückgegeben wird. Das folgende Beispiel zeigt, wie ein `hookStatus` mit einer benutzerdefinierten Callback-Verzögerung zurückgegeben wird. In diesem Beispiel würde Amazon ECS diesen Hook in 60 Sekunden statt in den standardmäßigen 30 Sekunden wiederholen: ``` { "hookStatus": "IN_PROGRESS", "callBackDelay": 60 } ``` Wenn ein Rollback stattfindet, führt Amazon ECS die Lebenszyklus-Hooks für die folgenden Lebenszyklusphasen aus: + PRODUCTION\$1TRAFFIC\$1SHIFT + TEST\$1TRAFFIC\$1SHIFT ## Lebenszyklus-Nutzdaten Wenn Sie Lebenszyklus-Hooks für Ihre ECS-Servicebereitstellungen konfigurieren, ruft Amazon ECS diese Hooks in bestimmten Phasen des Bereitstellungsprozesses auf. Jede Lebenszyklusphase stellt JSON-Nutzdaten mit Informationen zum aktuellen Status der Bereitstellung bereit. In diesem Dokument wird die Nutzdatenstruktur für jede Lebenszyklusphase beschrieben. ### Gängige Nutzdatenstruktur Alle Nutzdaten in der Lebenszyklusphase enthalten die folgenden gemeinsamen Felder: + `serviceArn` – Der Amazon-Ressourcenname (ARN) des Service. + `targetServiceRevisionArn` – Der ARN der Ziel-Service-Revision, die bereitgestellt wird. + `testTrafficWeights`- Eine Übersicht der Service-Revisionen ARNs zu den entsprechenden Prozentwerten des Testverkehrs in Prozent. + `productionTrafficWeights`- Eine Übersicht über die Änderung der Dienste im Vergleich ARNs zu den entsprechenden prozentualen Gewichtsanteilen für den Produktionsverkehr. ### Lebenszyklusphasen-Nutzdaten #### RECONCILE\$1SERVICE Diese Phase findet zu Beginn des Bereitstellungsprozesses statt, wenn der Service abgeglichen wird. Im Folgenden wird ein Beispiel für Nutzdaten für diese Lebenszyklusphase gezeigt. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **Erwartungen in dieser Phase:** + Der primäre Aufgabensatz ist auf 0 % skaliert #### PRE\$1SCALE\$1UP Diese Phase findet statt, bevor die neuen Aufgaben hochskaliert werden. Im Folgenden wird ein Beispiel für Nutzdaten für diese Lebenszyklusphase gezeigt. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Erwartungen in dieser Phase:** + Die Aufgaben der grünen Service-Revision sind auf 0 % skaliert #### POST\$1SCALE\$1UP Diese Phase tritt ein, nachdem die neuen Aufgaben hochskaliert wurden und fehlerfrei sind. Im Folgenden wird ein Beispiel für Nutzdaten für diese Lebenszyklusphase gezeigt. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Erwartungen in dieser Phase:** + Die Aufgaben der grünen Service-Revision sind auf 100 % skaliert + Aufgaben der grünen Service-Revision sind fehlerfrei #### TEST\$1TRAFFIC\$1SHIFT Diese Phase tritt auf, wenn der Test-Datenverkehr auf Aufgaben der grünen Service-Revision umgestellt wird. Im Folgenden wird ein Beispiel für Nutzdaten für diese Lebenszyklusphase gezeigt. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": {} } ``` **Erwartungen in dieser Phase:** + Der Test-Datenverkehr wird derzeit auf die Aufgaben der grünen Service-Revision umgestellt. #### POST\$1TEST\$1TRAFFIC\$1SHIFT Diese Phase tritt ein, nachdem der Test-Datenverkehr vollständig auf die neuen Aufgaben umgestellt wurde. Im Folgenden wird ein Beispiel für Nutzdaten für diese Lebenszyklusphase gezeigt. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Erwartungen in dieser Phase:** + 100 % des Test-Datenverkehrs wurden auf die Aufgaben der grünen Service-Revision umgestellt. #### PRODUCTION\$1TRAFFIC\$1SHIFT Diese Phase tritt ein, wenn der Produktionsdatenverkehr auf die Aufgaben der grünen Service-Revision umgestellt wird. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **Erwartungen in dieser Phase:** + Der Produktionsdatenverkehr wird derzeit auf die neue grüne Service-Revision umgestellt. #### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT Diese Phase tritt ein, wenn der Produktionsdatenverkehr vollständig auf die Aufgaben der grünen Service-Revision umgestellt wurde. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Erwartungen in dieser Phase:** + 100 % des Produktionsdatenverkehrs wurden auf die Aufgaben der grünen Service-Revision umgestellt. ### Kategorien von Lebenszyklusphasen Lebenszyklusphasen gliedern sich in zwei Kategorien: 1. **Einzelne Aufrufphasen** – Diese Phasen werden während einer Servicebereitstellung nur einmal aufgerufen: + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + POST\$1TEST\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT 1. **Wiederkehrende Aufrufphasen** – Diese Phasen können während einer Servicebereitstellung mehrfach aufgerufen werden, beispielsweise wenn ein Rollback-Vorgang stattfindet: + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT ### Bereitstellungsstatus während Lebenszyklus-Hooks Während der Ausführung von Lebenszyklus-Hooks ist der Bereitstellungsstatus `IN_PROGRESS` für alle Lebenszyklusphasen. | Lebenszyklusphase | Bereitstellungsstatus | | --- | --- | | RECONCILE\$1SERVICE | IN\$1PROGRESS | | PRE\$1SCALE\$1UP | IN\$1PROGRESS | | POST\$1SCALE\$1UP | IN\$1PROGRESS | | TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | # Anhalten von Amazon-ECS-Servicebereitstellungen Sie können eine Bereitstellung manuell beenden, wenn eine fehlgeschlagene Bereitstellung nicht durch den Schutzschalter oder die CloudWatch Alarme erkannt wurde. Die folgenden Anhaltungstypen sind verfügbar. + Rollback – Mit dieser Option wird die Servicebereitstellung auf die vorherige Service-Revision zurückgesetzt. Sie können diese Option auch dann verwenden, wenn Sie die Servicebereitstellung nicht für die Rollback-Option konfiguriert haben. Sie können eine Bereitstellung anhalten, die einen der folgenden Status aufweist: Weitere Informationen zum Status der Servicebereitstellung finden Sie unter [Anzeigen des Service-Verlaufs mithilfe von Service-Bereitstellungen in Amazon ECS](service-deployment.md). + PENDING – Die Servicebereitstellung wechselt in den Status ROLLBACK\$1REQUESTED, und dann beginnt der Rollback-Vorgang. + IN\$1PROGRESS – Die Servicebereitstellung wechselt in den Status ROLLBACK\$1REQUESTED, und dann beginnt der Rollback-Vorgang. + STOP\$1REQUESTED – Die Servicebereitstellung wird weiterhin angehalten. + ROLLBACK\$1REQUESTED – Die Servicebereitstellung setzt den Rollback-Vorgang fort. + ROLLBACK\$1IN\$1PROGRESS – Die Servicebereitstellung setzt den Rollback-Vorgang fort. ## Verfahren Bevor Sie beginnen, konfigurieren Sie die erforderlichen Berechtigungen für die Anzeige von Servicebereitstellungen. Weitere Informationen finden Sie unter [Die erforderlichen Berechtigungen für die Anzeige von Amazon-ECS-Servicebereitstellungen](service-deployment-permissions.md). ------ #### [ Amazon ECS Console ] 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Seite mit den Service-Details wird angezeigt. 1. Wählen Sie auf der Seite mit den Service-Details die Option **Bereitstellungen**. Die Seite mit den Bereitstellungen wird angezeigt. 1. Wählen Sie unter **Laufende Bereitstellung** die Option **Rollback** aus. Wählen Sie dann im Bestätigungsfenster die Option **Rollback** aus. ------ #### [ AWS CLI ] 1. Führen Sie `list-service-deployments` aus, um den ARN für die Servicebereitstellung abzurufen. Ersetzen Sie die *user-input* durch Ihre Werte. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` Notieren Sie den `serviceDeploymentArn` für die Bereitstellung, die Sie anhalten möchten. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. Führen Sie `stop-service-deployments`. Verwenden Sie den von `list-service-deployments` zurückgegebenen `serviceDeploymentArn`. Ersetze die *user-input* durch deine Werte. ``` aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK ``` ------ ## Nächste Schritte Entscheiden Sie, welche Änderungen am Service vorgenommen werden müssen, und aktualisieren Sie dann den Service. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). # Bereitstellen von Amazon-ECS-Services durch Ersetzung von Aufgaben Wenn Sie einen Service erstellen, der den Bereitstellungstyp *Fortlaufende Aktualisierung* (`ECS`) verwendet, ersetzt der Amazon ECS Service Scheduler die derzeit ausgeführten Aufgaben durch neue Aufgaben. Die Anzahl der Aufgaben, die Amazon ECS während einer fortlaufenden Aktualisierung für den Service hinzufügt oder entfernt, wird durch die Service-Bereitstellungskonfiguration gesteuert. Amazon ECS verwendet die folgenden Parameter, um die Anzahl der Aufgaben zu bestimmen: + Der `minimumHealthyPercent` stellt die untere Grenze für die Anzahl der Aufgaben dar, die für einen Service während einer fortlaufenden Bereitstellung oder wenn eine Container-Instance ausgelastet ist, ausgeführt und fehlerfrei sein sollten, als Prozentsatz der gewünschten Anzahl von Aufgaben für den Service. Dieser Wert wird aufgerundet. Zum Beispiel, wenn der minimale gesunde Prozentsatz `50` ist und die gewünschte Aufgabenanzahl vier ist, kann der Scheduler zwei bestehende Aufgaben stoppen, bevor er zwei neue Aufgaben startet. Ebenso kann der Scheduler, wenn der minimale fehlerfreie Prozentsatz 75 % beträgt und die gewünschte Anzahl zwei ist, keine Aufgaben stoppen, da der resultierende Wert auch zwei ist. + Der `maximumPercent` stellt die Obergrenze für die Anzahl der Aufgaben dar, die für einen Service während einer fortlaufenden Bereitstellung oder wenn eine Container-Instance ausgelastet ist, ausgeführt werden sollten, als Prozentsatz der gewünschten Anzahl von Aufgaben für einen Dienst. Dieser Wert wird abgerundet. Wenn der maximale Prozentsatz beispielsweise vier beträgt `200` und die gewünschte Anzahl an Aufgaben gleich vier ist, kann der Scheduler vier neue Aufgaben starten, bevor er vier bestehende Aufgaben stoppt. Ebenso, wenn der maximale Prozentsatz `125`. ist und die gewünschte Aufgabenanzahl drei ist, kann der Scheduler keine Aufgaben starten, da der resultierende Wert ebenfalls drei ist. Wenn Aufgaben während einer fortlaufenden Bereitstellung fehlerhaft werden, ersetzt Amazon ECS sie, um Ihren Service aufrechtzuerhalten `minimumHealthyPercent` und die Verfügbarkeit zu schützen. Fehlerhafte Aufgaben werden mit derselben Service-Version ersetzt, zu der sie gehören. Dadurch wird sichergestellt, dass das Ersetzen fehlerhafter Aufgaben in der Quellrevision unabhängig von Aufgabenfehlern in der Zielrevision ist. Wenn die `maximumPercent` Einstellung dies zulässt, startet der Scheduler Ersatzaufgaben, bevor er fehlerhafte Aufgaben beendet. Wenn der `maximumPercent` Parameter den Scheduler daran hindert, zuerst eine Ersatzaufgabe zu starten, stoppt der Scheduler jeweils eine fehlerhafte Aufgabe, um Kapazität freizugeben, bevor eine Ersatzaufgabe gestartet wird. **Wichtig** Beim Festlegen eines minimalen fehlerfreien Prozentsatzes oder eines maximalen Prozentsatzes sollten Sie sicherstellen, dass der Planer mindestens eine Aufgabe anhalten oder starten kann, wenn eine Bereitstellung initiiert wird. Wenn Ihr Service über eine Bereitstellung verfügt, die aufgrund einer ungültigen Bereitstellungskonfiguration nicht mehr besteht, wird eine Serviceereignismeldung gesendet. Weitere Informationen finden Sie unter [service (*service-name*) konnte aufgrund der Konfiguration der Dienstbereitstellung während einer Bereitstellung keine Aufgaben beenden oder starten. Aktualisieren Sie den Wert minimumHealthyPercent oder MaximumPercent und versuchen Sie es erneut.](service-event-messages-list.md#service-event-messages-7). Fortlaufende Bereitstellungen verfügen über zwei Methoden, mit denen Sie schnell feststellen können, wann eine Servicebereitstellung fehlgeschlagen ist: + [So erkennt der Schutzschalter in Amazon ECS fehlgeschlagene Bereitstellungen](deployment-circuit-breaker.md) + [So erkennen CloudWatch Alarme Bereitstellungsfehler bei Amazon ECS](deployment-alarm-failure.md) Die Methoden können getrennt oder zusammen verwendet werden. Wenn beide Methoden verwendet werden, wird die Bereitstellung als fehlgeschlagen eingestuft, sobald das Fehlerkriterium für eine der beiden Fehlermethoden erfüllt ist. Bestimmen Sie anhand der folgenden Anleitungen, welche Methode verwendet werden soll: + Schutzschalter – Verwenden Sie diese Methode, wenn Sie eine Bereitstellung anhalten möchten, falls die Aufgaben nicht gestartet werden können. + CloudWatch Alarme — Verwenden Sie diese Methode, wenn Sie eine Bereitstellung auf der Grundlage von Anwendungsmetriken beenden möchten. Beide Methoden unterstützen das Rollback zur vorherigen Service-Revision. ## Container-Image-Auflösung Amazon ECS löst standardmäßig die in der Aufgabendefinition angegebenen Container-Image-Tags in Container-Image-Digests auf. Wenn Sie einen Service erstellen, der eine einzelne Aufgabe ausführt und verwaltet, wird diese Aufgabe verwendet, um Image-Digests für die Container in der Aufgabe einzurichten. Wenn Sie einen Service erstellen, der mehrere Aufgaben ausführt und verwaltet, wird die erste Aufgabe, die während der Bereitstellung vom Service Scheduler gestartet wird, verwendet, um die Image-Digests für die Container in den Aufgaben einzurichten. Wenn drei oder mehr Versuche, die Container-Image-Digests einzurichten, fehlschlagen, wird die Bereitstellung ohne Image-Digest-Auflösung fortgesetzt. Wenn der Bereitstellungs-Schutzschalter aktiviert ist, schlägt die Bereitstellung zusätzlich fehl und wird zurückgesetzt. Nachdem die Container-Image-Digests eingerichtet wurden, verwendet Amazon ECS die Digests, um alle anderen gewünschten Aufgaben zu starten sowie für zukünftige Service-Aktualisierungen. Dies führt dazu, dass alle Aufgaben in einem Service immer identische Container-Images ausführen, was zu einer Versionskonsistenz für Ihre Software führt. Sie können dieses Verhalten für jeden Container in Ihrer Aufgabe konfigurieren, indem Sie den `versionConsistency`-Parameter in der Container-Definition verwenden. Weitere Informationen finden Sie unter [versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency). **Anmerkung** Amazon-ECS-Agentenversionen, die älter als `1.31.0` sind, unterstützen keine Image-Digest-Auflösung. Agentenversionen `1.31.0` bis `1.69.0` unterstützen Image-Digest-Auflösung nur für Images, die in Amazon-ECR-Repositorys übertragen wurden. Agentenversionen `1.70.0` oder höher unterstützen Image-Digest-Auflösung für alle Images. Die Mindest-Plattformversion von Fargate Linux für die Image-Digest-Auflösung ist `1.3.0`. Die Mindest-Plattformversion von Fargate Windows für die Image-Digest-Auflösung ist `1.0.0`. Amazon ECS erfasst keine Übersichten von Sidecar-Containern, die von Amazon ECS verwaltet werden, wie z. B. der Amazon GuardDuty Security Agent oder der Service Connect-Proxy. Um die potenzielle Latenz im Zusammenhang mit der Container-Image-Auflösung in Services mit mehreren Aufgaben zu reduzieren, führen Sie Version `1.83.0` oder höher des Amazon-ECS-Agenten auf EC2-Container-Instances aus. Um potenzielle Latenzen zu vermeiden, geben Sie Container-Image-Digests in Ihrer Aufgabendefinition an. Wenn Sie einen Service mit einer gewünschten Aufgaben-Anzahl von Null erstellen, kann Amazon ECS keine Container-Digests einrichten, bis Sie eine weitere Bereitstellung des Service mit einer gewünschten Aufgaben-Anzahl von mehr als Null auslösen. Um aktualisierte Image-Digests zu erstellen, können Sie eine neue Bereitstellung erzwingen. Die aktualisierten Digests werden zum Starten neuer Aufgaben verwendet und wirken sich nicht auf bereits ausgeführte Aufgaben aus. Weitere Informationen zum Erzwingen neuer Bereitstellungen finden Sie [forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)in der *Amazon ECS-API-Referenz.* Wenn bei der Verwendung von EC2-Kapazitätsanbietern nicht genügend Kapazität vorhanden ist, um eine Aufgabe bei der ersten Bereitstellung zu starten, kann die Konsistenz der Softwareversionen fehlschlagen. Um sicherzustellen, dass die Versionskonsistenz auch bei begrenzter Kapazität erhalten bleibt, sollten Sie explizit `versionConsistency: "enabled"` in Ihrer Container-Konfiguration für Aufgabendefinitionen festlegen, anstatt sich auf das Standardverhalten zu verlassen. Dies veranlasst Amazon ECS, zu warten, bis Kapazität verfügbar ist, bevor mit der Bereitstellung fortgefahren wird. # Bewährte Methoden für Amazon-ECS-Serviceparameter Um sicherzustellen, dass es zu keinen Ausfallzeiten der Anwendung kommt, läuft der Bereitstellungsprozess wie folgt ab: 1. Starten Sie die neuen Anwendungs-Container, während die vorhandenen Container weiterlaufen. 1. Überprüfen Sie, ob die neuen Container fehlerfrei sind. 1. Stoppen Sie die alten Container. Abhängig von Ihrer Bereitstellungskonfiguration und der Menge an freiem, nicht reserviertem Speicherplatz in Ihrem Cluster kann es mehrere Runden dauern, bis dieser Vorgang abgeschlossen ist und alle alten Aufgaben durch neue Aufgaben ersetzt werden. Es gibt zwei Optionen für die Servicekonfiguration, mit denen Sie die Anzahl ändern können: + `minimumHealthyPercent`: 100 % (Standard) Die Untergrenze für die Anzahl der Aufgaben für Ihren Service, die während einer Bereitstellung im Status `RUNNING` bleiben müssen. Dies wird als Prozentsatz des `desiredCount` ausgedrückt, auf den nächsten ganzen Wert aufgerundet. Mit diesem Parameter können Sie die Bereitstellung vornehmen, ohne zusätzliche Cluster-Kapazität zu nutzen. + `maximumPercent`: 200 % (Standard) Die Obergrenze für die Anzahl der Aufgaben für Ihren Service, die während einer Bereitstellung im Status `RUNNING` oder `PENDING` erlaubt sind. Dies wird als Prozentsatz des `desiredCount` ausgedrückt, auf den nächsten ganzen Wert abgerundet. **Beispiel: Standard-Konfigurationsoptionen** Stellen Sie sich den folgenden Service mit sechs Aufgaben vor, die in einem Cluster bereitgestellt werden, der Platz für insgesamt acht Aufgaben bietet. Die standardmäßigen Servicekonfigurationsoptionen lassen nicht zu, dass bei der Bereitstellung weniger als 100 % der sechs gewünschten Aufgaben ausgeführt werden. Der Bereitstellungsprozess läuft folgendermaßen ab: 1. Ziel ist es, die sechs Aufgaben zu ersetzen. 1. Der Scheduler startet zwei neue Aufgaben, da die Standardeinstellungen voraussetzen, dass sechs Aufgaben ausgeführt werden. Es gibt jetzt sechs bestehende Aufgaben und zwei neue Aufgaben. 1. Der Scheduler stoppt zwei der vorhandenen Aufgaben. Es gibt jetzt vier bestehende Aufgaben und zwei neue Aufgaben. 1. Der Scheduler startet zwei zusätzliche neue Aufgaben. Es gibt jetzt vier bestehende Aufgaben und vier neue Aufgaben. 1. Der Scheduler stoppt zwei der vorhandenen Aufgaben. Es gibt jetzt zwei bestehende Aufgaben und vier neue Aufgaben. 1. Der Scheduler startet zwei zusätzliche neue Aufgaben. Es gibt jetzt zwei bestehende Aufgaben und sechs neue Aufgaben. 1. Der Scheduler stoppt die letzten zwei der vorhandenen Aufgaben. Es gibt jetzt sechs neue Aufgaben. Wenn Sie im obigen Beispiel die Standardwerte für die Optionen verwenden, gibt es eine Wartezeit von 2,5 Minuten für jede neue Aufgabe, die gestartet wird. Darüber hinaus muss der Load Balancer möglicherweise 5 Minuten warten, bis die alte Aufgabe angehalten ist. **Beispiel: `minimumHealthyPercent` ändern** Sie können die Bereitstellung beschleunigen, indem Sie den `minimumHealthyPercent`-Wert auf 50 % setzen. Stellen Sie sich den folgenden Service mit sechs Aufgaben vor, die in einem Cluster bereitgestellt werden, der Platz für insgesamt acht Aufgaben bietet. Der Bereitstellungsprozess läuft folgendermaßen ab: 1. Ziel ist es, sechs Aufgaben zu ersetzen. 1. Der Scheduler stoppt drei der vorhandenen Aufgaben. Es werden immer noch drei vorhandene Aufgaben ausgeführt, die dem `minimumHealthyPercent`-Wert entsprechen. 1. Der Scheduler startet fünf neue Aufgaben. Es gibt drei bestehende Aufgabenaufgaben und fünf neue Aufgaben. 1. Der Scheduler stoppt die übrigen drei vorhandenen Aufgaben. Es gibt fünf neue Aufgaben 1. Der Scheduler startet die letzten neuen Aufgaben. Es gibt sechs neue Aufgaben. **Beispiel: Den freien Speicherplatz im Cluster ändern** Sie können auch zusätzlichen freien Speicherplatz hinzufügen, sodass Sie zusätzliche Aufgaben ausführen können. Stellen Sie sich den folgenden Service mit sechs Aufgaben vor, die in einem Cluster bereitgestellt werden, der Platz für insgesamt zehn Aufgaben bietet. Der Bereitstellungsprozess läuft folgendermaßen ab: 1. Ziel ist es, die vorhandenen Aufgaben zu ersetzen. 1. Der Scheduler stoppt drei der vorhandenen Aufgaben. Es gibt drei bestehende Aufgaben. 1. Der Scheduler startet sechs neue Aufgaben. Es gibt die vorhandenen Aufgaben und sechs neue Aufgaben 1. Der Scheduler stoppt die drei vorhandenen Aufgaben. Es gibt sechs neue Aufgaben. **Empfehlungen** Verwenden Sie die folgenden Werte für die Servicekonfigurationsoptionen, wenn Ihre Aufgaben für einige Zeit inaktiv sind und keine hohe Auslastung aufweisen. + `minimumHealthyPercent`: 50 % + `maximumPercent`: 200 % # Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung Erstellen SIe einen Service, um eine festgelegte Anzahl von Instances einer Aufgabendefinition gleichzeitig in einem Cluster ausführen. Wenn eine Ihrer Aufgaben ausfällt oder anhält, startet der Amazon-ECS-Service-Scheduler eine andere Instance Ihrer Aufgabendefinition, um sie zu ersetzen. Dies trägt dazu bei, dass die von Ihnen gewünschte Anzahl von Aufgaben im Service erhalten bleibt. Entscheiden Sie sich für die folgenden Konfigurationsparameter, bevor Sie einen Service erstellen: + Es gibt zwei Rechenoptionen, die Ihre Aufgaben verteilen. + Eine **capacity provider strategy** (Strategie für Kapazitätsanbieter) veranlasst Amazon ECS, Ihre Aufgaben an einen oder mehrere Kapazitätsanbieter zu verteilen. Wenn Sie Ihre Workloads in Amazon ECS Managed Instances ausführen möchten, müssen Sie die Option zur Kapazitätsanbieter-Strategie verwenden. + Ein **Starttyp** veranlasst Amazon ECS, Ihre Aufgaben direkt entweder auf Fargate oder auf den Amazon-EC2-Instances, die für Ihre Cluster registriert sind, zu starten. Wenn Sie Ihre Workloads in Amazon ECS Managed Instances ausführen möchten, müssen Sie die Option zur Kapazitätsanbieter-Strategie verwenden. + Aufgabendefinitionen, die den `awsvpc`-Netzwerkmodus oder Dienste, die für die Verwendung eines Load Balancer konfiguriert sind, verwenden, müssen über eine Netzwerkkonfiguration verfügen. Standardmäßig wählt die Konsole die standardmäßige Amazon VPC zusammen mit allen Subnetzen und der Standardsicherheitsgruppe innerhalb der standardmäßigen Amazon VPC aus. + Die Standardstrategie für die Aufgabenplatzierung verteilt Aufgaben gleichmäßig auf Availability Zones. Wir empfehlen Ihnen, Availability-Zone-Neuausgleich zu verwenden, um eine hohe Verfügbarkeit Ihres Service sicherzustellen. Weitere Informationen finden Sie unter [Ausgleichen eines Amazon-ECS-Service über Availability Zones hinweg](service-rebalancing.md). + Wenn Sie den **Launch Type** (Starttyp) für Ihre Servicebereitstellung verwenden, startet der Service standardmäßig in den Subnetzen in Ihrer Cluster-VPC. + Für die **Strategie für Kapazitätsanbieter**, wählt die Konsole standardmäßig eine Rechenoption aus. Im Folgenden wird die Reihenfolge beschrieben, in der die Konsole einen Standardwert auswählt: + Wenn der Cluster eine standardmäßige Kapazitätsanbieter-Strategie definiert hat, ist diese ausgewählt. + Wenn in Ihrem Cluster keine standardmäßige Kapazitätsanbieter-Strategie definiert ist, Sie jedoch die Fargate-Kapazitätsanbieter dem Cluster hinzugefügt haben, wird eine benutzerdefinierte Kapazitätsanbieter-Strategie verwendet, die den `FARGATE`-Kapazitätsanbieter benutzt. + Wenn für Ihren Cluster keine standardmäßige Kapazitätsanbieter-Strategie definiert ist, Sie jedoch einen oder mehrere Auto-Scaling-Gruppen als Kapazitätsanbieter zum Cluster hinzugefügt haben, ist die Option **Benutzerdefiniert verwenden (Erweitert)** ausgewählt und Sie müssen die Strategie manuell definieren. + Wenn in Ihrem Cluster keine Standardstrategie für Kapazitätsanbieter definiert ist und keine Kapazitätsanbieter zum Cluster hinzugefügt wurden, ist der Fargate Starttyp ausgewählt. + Die Standardoptionen für die Erkennung von Bereitstellungsfehlern sind die Verwendung der Option **Amazon-ECS-Bereitstellungs-Schutzschalter** mit der Option **Rollback bei Fehlern**. Weitere Informationen finden Sie unter [So erkennt der Schutzschalter in Amazon ECS fehlgeschlagene Bereitstellungen](deployment-circuit-breaker.md). + Entscheiden Sie, ob Amazon ECS die gewünschte Anzahl an Aufgaben in Ihrem Service automatisch erhöhen oder verringern soll. Weitere Informationen finden Sie unter [Automatisches Skalieren Ihres Amazon-ECS-Service](service-auto-scaling.md). + Wenn Sie eine Anwendung mit anderen Anwendungen, die in Amazon ECS laufen, verbinden müssen, bestimmen Sie die Option, die zu Ihrer Architektur passt. Weitere Informationen finden Sie unter [Amazon-ECS-Services verbinden](interconnecting-services.md). + Wenn Sie einen Service erstellen, der den Amazon-ECS-Schutzschalter verwendet, erstellt Amazon ECS eine Servicebereitstellung und eine Service-Revision. Diese Ressourcen ermöglichen es Ihnen, detaillierte Informationen zum Service-Verlauf einzusehen. Weitere Informationen finden Sie unter [Anzeigen des Service-Verlaufs mithilfe von Service-Bereitstellungen in Amazon ECS](service-deployment.md). Informationen darüber, wie Sie einen Service mithilfe von erstellen AWS CLI, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)in der *AWS Command Line Interface Referenz.* Informationen zum Erstellen eines Dienstes mit AWS CloudFormation finden Sie [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html)im *AWS CloudFormation Benutzerhandbuch* unter. ## Einen Service mit den Standardoptionen erstellen Mit der Konsole können Sie schnell einen Service erstellen und bereitstellen. Der Service hat die folgenden Konfigurationseinstellungen: + Wird in der VPC und in Subnetzen bereitgestellt, die Ihrem Cluster zugeordnet sind + Stellt eine Aufgabe bereit + Nutzt die laufende Bereitstellung + Verwendet die Kapazitätsanbieter-Strategie mit Ihrem Standardkapazitätsanbieter + Verwendet den Bereitstellungsschutzschalter, um Fehler zu erkennen, und legt die Option darauf fest, dass die Bereitstellung bei einem Fehler automatisch zurückgesetzt wird Folgen Sie diesen Schritten, um einen Service mit den Standardparametern bereitzustellen. **So erstellen Sie einen Service (Amazon-ECS-Konsole)** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Klicken Sie im Navigationsbereich auf **Cluster**. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus, in dem Sie den Service erstellen möchten. 1. Wählen Sie auf der Registerkarte **Services** die Option **Create** (Erstellen) aus. Die Seite **Service erstellen** wird angezeigt. 1. Führen Sie unter **Service-Details** die folgenden Schritte aus: 1. Geben Sie für **Aufgabendefinition** die Aufgabendefinitionsfamilie und die zu verwendende Revision ein. 1. Wählen Sie für **Service name** (Servicename) einen Namen für Ihren Service aus. 1. Um ECS Exec zum Debuggen des Services zu verwenden, wählen Sie unter **Konfiguration zur Fehlerbehebung** die Option **ECS Exec einschalten** aus. 1. Führen Sie im Abschnitt **Bereitstellungskonfiguration** Folgendes aus: 1. Geben Sie für **Desired tasks** (Gewünschte Aufgaben) die Anzahl der Aufgaben an, die im Service gestartet und aufrecht erhalten werden sollen. 1. (Optional) Um Ihren Service und Ihre Aufgaben besser identifizieren zu können, erweitern Sie den Bereich **Tags** (Tags) und konfigurieren Sie dann Ihre Tags. Damit Amazon ECS automatisch alle neu gestarteten Aufgaben mit dem Clusternamen und den Task-Definition-Tags versieht, wählen Sie **Amazon ECS Managed Tags aktivieren** und anschließend **Aufgabendefinitionen** aus. Damit Amazon ECS automatisch alle neu gestarteten Aufgaben mit dem Clusternamen und den Service-Tags versieht, wählen Sie **Amazon ECS Managed Tags aktivieren** und anschließend **Service** aus. Hinzufügen oder Entfernen eines Tag. + [Ein Tag hinzufügen] Wählen Sie **Add tag** (Tag hinzufügen) und führen Sie dann das Folgende aus: + Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein. + Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein. + [Tag entfernen] Wählen Sie neben dem Tag die Option **Remove tag (Tag löschen)** aus. ## Erstellen eines Services mit definierten Parametern Folgen Sie diesen Schritten, um einen Service unter Verwendung von definierten Parametern bereitzustellen. **So erstellen Sie einen Service (Amazon-ECS-Konsole)** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Bestimmen Sie die Ressource, von der aus Sie den Service starten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-service-console-v2.html) Die Seite **Service erstellen** wird angezeigt. 1. Führen Sie unter Service-Details die folgenden Schritte aus: 1. Geben Sie für **Aufgabendefinition** die zu verwendende Aufgabendefinition ein. Wählen Sie dann für **Revision** die zu verwendende Revision aus. 1. Wählen Sie für **Service name** (Servicename) einen Namen für Ihren Service aus. 1. Wählen Sie für **Bestehender Cluster** den Cluster aus. Wählen Sie **Cluster erstellen**, um die Aufgabe auf einem neuen Cluster auszuführen 1. Wählen Sie aus, wie Ihre Aufgaben auf Ihre Cluster-Infrastruktur verteilt werden. Wählen Sie unter **Datenverarbeitungskonfiguration** Ihre Option aus. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Um ECS Exec zum Debuggen des Services zu verwenden, wählen Sie unter **Konfiguration zur Fehlerbehebung** die Option **ECS Exec einschalten** aus. 1. Führen Sie im Abschnitt **Bereitstellungskonfiguration** Folgendes aus: 1. Für **Service type** (Service-Typ) wählen Sie die Strategie für die Serviceplanung. + Wählen Sie **Daemon** (Daemon), damit der Scheduler genau eine Aufgabe auf jede aktiven Container-Instance verteilt, die alle Bedingungen für die Aufgabenplatzierung erfüllt. + Damit der Scheduler die gewünschte Anzahl von Aufgaben in Ihrem Cluster platziert und verwaltet, wählen Sie **Replica** (Replikat). 1. Wenn Sie **Replica** (Replikat) gewählt haben, geben Sie bei **Desired tasks** (Gewünschte Aufgaben) die Anzahl der Aufgaben ein, die im Service gestartet und gepflegt werden sollen. 1. Wenn Sie **Replikat** auswählen, damit Amazon ECS die Verteilung der Aufgaben auf die Availability Zones überwacht und sie bei einem Ungleichgewicht neu verteilt, wählen Sie unter **Service-Neuausgleich der Availability Zone** die Option **Service-Neuausgleich der Availability Zone** aus. 1. Geben Sie für **Wartefrist der Zustandsprüfung** die Zeitspanne (in Sekunden) ein, die der Service Scheduler warten soll, bevor er fehlerhaftes Elastic Load Balancing, VPC Lattice und Container-Zustandsprüfungen ignoriert, nachdem eine Aufgabe zum ersten Mal gestartet wurde. Wenn Sie keine Übergangsfrist für die Zustandsprüfung angeben, wird der Standardwert 0 verwendet. 1. Ermitteln Sie den Bereitstellungstyp für Ihren Service. Erweitern Sie **Bereitstellungsoptionen** und geben Sie dann die folgenden Parameter an [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Um zu konfigurieren, wie Amazon ECS Bereitstellungsfehler erkennt und behandelt, erweitern Sie **Deployment failure detection** (Erkennung von Bereitstellungsfehlern) und wählen Sie dann Ihre Optionen. 1. Um eine Bereitstellung anzuhalten, wenn die Aufgaben nicht gestartet werden können, wählen Sie **Use the Amazon ECS deployment circuit breaker** (Verwenden des Amazon-ECS-Bereitstellungsschutzschalters). Wenn Sie möchten, dass die Software die Bereitstellung automatisch auf den letzten abgeschlossenen Bereitstellungsstatus zurücksetzt, wenn der Bereitstellungs-Schutzschalter die Bereitstellung auf einen fehlgeschlagenen Status setzt, wählen Sie **Rollback bei Fehler** aus. 1. Um eine Bereitstellung auf der Grundlage von Anwendungsmetriken zu beenden, wählen Sie ** CloudWatch Alarm (e) verwenden** aus. Wählen Sie dann unter **CloudWatch Alarmname** die Alarme aus. Um einen neuen Alarm zu erstellen, gehen Sie zur CloudWatch Konsole. Damit die Software die Bereitstellung automatisch auf den Status der letzten abgeschlossenen Bereitstellung zurücksetzt, wenn ein CloudWatch Alarm die Bereitstellung in einen fehlgeschlagenen Zustand versetzt, wählen Sie **Rollback bei Fehlern** aus. 1. Wenn Ihre Aufgabendefinition den `awsvpc`-Netzwerkmodus verwendet, können Sie eine benutzerdefinierte Netzwerkkonfiguration angeben, indem Sie **Netzwerke** erweitern und dann wie folgt vorgehen: 1. Wählen Sie für **VPC** die VPC aus, die Sie verwenden möchten. 1. Wählen Sie für **Subnets** (Subnetze) ein oder mehrere Subnetze in der VPC aus, die der Aufgaben-Scheduler bei der Platzierung Ihrer Aufgaben berücksichtigen soll. 1. Für die **VPC-Sicherheitsgruppe** können Sie entweder eine vorhandene Sicherheitsgruppe auswählen oder eine neue erstellen. Um eine vorhandene Sicherheitsgruppe zu verwenden, wählen Sie die Sicherheitsgruppe aus und fahren Sie mit dem nächsten Schritt fort. Um eine neue Sicherheitsgruppe zu erstellen, wählen Sie **Create a new security group**. Sie müssen einen Sicherheitsgruppennamen und eine Beschreibung angeben und dann eine oder mehrere eingehende Regeln für die Sicherheitsgruppe hinzufügen. 1. Geben Sie für die **Öffentliche IP** an, ob der Elastic-Network-Schnittstelle (ENI) der Aufgabe eine öffentliche IP-Adresse automatisch zugewiesen wird. AWS Fargate Aufgaben kann eine öffentliche IP-Adresse zugewiesen werden, wenn sie in einem öffentlichen Subnetz ausgeführt werden, sodass sie eine Route zum Internet haben. EC2-Aufgaben kann mit diesem Feld keine öffentliche IP zugewiesen werden. Weitere Informationen finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) und [Zuweisen einer Netzwerkschnittstelle für eine Amazon-ECS-Aufgabe](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html). . 1. (Optional) Um Ihren Service mit Service Connect zu verbinden, erweitern Sie **Service Connect** und geben Sie dann Folgendes an: 1. Wählen Sie **Service Connect einschalten** aus. 1. Geben Sie unter **Service Connect configuration** (Service-Connect-Konfiguration) den Client-Modus an. + Wenn Ihr Service eine Netzwerk-Client-Anwendung ausführt, die nur eine Verbindung zu anderen Services im Namespace herstellen muss, wählen Sie **Nur Client-Seite** aus. + Wenn Ihr Service eine Netzwerk- oder Webservice-Anwendung ausführt und Endpunkte für diesen Service bereitstellen muss und eine Verbindung zu anderen Services im Namespace herstellt, wählen Sie **Client and server** (Client und Server) aus. 1. Um einen Namespace zu verwenden, der nicht der Standard-Cluster-Namespace ist, wählen Sie für **Namespace** den Service-Namespace aus. Dies kann ein Namespace sein, der separat in demselben AWS-Region in Ihrem AWS-Konto oder einem Namespace in derselben Region erstellt wurde und der mithilfe AWS Resource Access Manager von () mit Ihrem Konto geteilt wird.AWS RAM*Weitere Informationen zur gemeinsamen Nutzung von AWS Cloud Map Namespaces finden Sie unter [Kontenübergreifende gemeinsame Nutzung von AWS Cloud Map Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) im Entwicklerhandbuch.AWS Cloud Map * 1. (Optional) Geben Sie eine Protokollkonfiguration an. Wählen Sie **Protokollsammlung verwenden** aus. Die Standardoption sendet Container-Logs an Logs. CloudWatch Die anderen Protokolltreiberoptionen werden mit konfiguriert AWS FireLens. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md). Im Folgenden wird jedes Container-Protokollziel ausführlicher beschrieben. + **Amazon CloudWatch** — Konfigurieren Sie die Aufgabe, um Container-Logs an CloudWatch Logs zu senden. Es werden die standardmäßigen Protokolltreiberoptionen bereitgestellt, mit denen in Ihrem Namen eine CloudWatch Protokollgruppe erstellt wird. Um einen anderen Protokollgruppen-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Data Firehose** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Firehose gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch die Protokolle an einen Bereitstellungsdatenstrom von Firehose gesendet werden. Um einen anderen Namen für den Bereitstellungsdatenstrom anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Kinesis Data Streams** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Kinesis Data Streams gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch Protokolle an einen Datenstrom von Kinesis Data Streams gesendet werden. Um einen anderen Datenstrom-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon OpenSearch Service** — Konfigurieren Sie die Aufgabe, um Container-Logs an eine OpenSearch Service-Domain zu senden. Die Optionen für den Protokolltreiber müssen bereitgestellt werden. + **Amazon S3** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an einen Amazon-S3-Bucket gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, Sie müssen jedoch einen gültigen Amazon-S3-Bucket-Namen angeben. 1. (Optional) Gehen Sie wie folgt vor, um Zugriffsprotokolle zu aktivieren: 1. Erweitern Sie **Konfiguration des Zugriffsprotokolls**. Wählen Sie als **Format** entweder **JSON** oder`TEXT`. 1. Um Abfrageparameter in Zugriffsprotokolle aufzunehmen, wählen Sie **Abfrageparameter einbeziehen** aus. 1. (Optional) Um Ihren Service mit der Serviceerkennung zu verbinden, erweitern Sie **Serviceerkennung** und führen Sie Folgendes aus: 1. Wählen Sie **Serviceerkennung verwenden** aus. 1. Um einen neuen Namespace zu verwenden, wählen Sie unter **Namespace konfigurieren** die Option **Neuen Namespace erstellen** aus, und geben Sie dann einen Namespace-Namen und eine Beschreibung ein. Um einen vorhandenen Namespace zu verwenden, wählen Sie **Vorhandenen Namespace auswählen** und wählen Sie dann den Namespace aus, den Sie verwenden möchten. 1. Geben Sie zur Serviceerkennung Informationen über den Service an, z. B. den Namen und die Beschreibung des Services. 1. Damit Amazon ECS regelmäßig Zustandsprüfungen auf Container-Ebene durchführt, wählen Sie **Zustandpropagation für Amazon-ECS-Aufgaben aktivieren** aus. 1. Wählen Sie für **DNS record type (DNS-Datensatztyp)** den DNS-Datensatztyp aus, der für Ihren Service erstellt werden soll. Die Amazon-ECS-Serviceerkennung unterstützt abhängig von dem Netzwerkmodus, der durch Ihre Aufgabendefinition angegeben wird, nur **A**- und **SRV**-Datensätze. Informationen über diese Datensatztypen finden Sie unter [Unterstützte DNS-Datensatztypen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) im *Amazon Route 53-Entwicklerhandbuch*. + Wenn die von Ihrer Serviceaufgabe angegebene Aufgabendefinition als Netzwerkmodus `bridge` oder `host` verwendet, werden nur Datensätze vom Typ **SRV** unterstützt. Wählen Sie eine Kombination aus Containername und -Port aus, die dem Datensatz zugeordnet werden soll. + Wenn die Aufgabendefinition, die Ihre Serviceaufgabe angibt, den `awsvpc`-Netzwerkmodus verwendet, wählen Sie entweder den Datensatztyp **A** oder **SRV**. Wenn Sie **A** auswählen, fahren Sie mit dem nächsten Schritt fort. Wenn Sie **SRV** wählen, geben Sie entweder den Port an, unter dem der Service gefunden werden kann, oder eine Kombination aus Containername und Port, die dem Datensatz zugeordnet werden soll. Geben Sie für **TTL** die Zeit in Sekunden ein, für die ein Datensatz von DNS-Resolvern und Webbrowsern zwischengespeichert wird. 1. (Optional) Um Ihren Service mithilfe von VPC Lattice zu verbinden, erweitern Sie **VPC Lattice** und gehen Sie dann wie folgt vor: 1. Wählen Sie **VPC Lattice einschalten** aus. 1. Wählen Sie für **Infrastrukturrolle** die Infrastrukturrolle aus. Wenn Sie keine Rolle erstellt haben, wählen Sie **Infrastrukturrolle erstellen** aus. 1. Wählen Sie unter **Zielgruppen** die Zielgruppe(n) aus. Sie müssen mindestens eine Zielgruppe auswählen und können maximal fünf haben. Um zusätzliche Zielgruppen hinzuzufügen, wählen Sie **Zielgruppe hinzufügen** aus. Wählen Sie den **Port-Namen**, **das Protokoll** und den **Port** für jede gewählte Zielgruppe aus. Zum Löschen einer Zielgruppe, wählen Sie **Entfernen** aus. **Anmerkung** Wenn Sie bestehende Zielgruppen hinzufügen möchten, müssen Sie die AWS CLI verwenden. *Anweisungen zum Hinzufügen von Zielgruppen mithilfe von finden Sie unter [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html) in der AWS Command Line Interface Referenz. AWS CLI* Obwohl einem VPC-Lattice-Service mehrere Zielgruppen zugeordnet werden können, kann jede Zielgruppe jeweils nur einem einzigen Service hinzugefügt werden. 1. Um die VPC-Lattice-Konfiguration abzuschließen, indem Sie in der VPC-Lattice-Konsole Ihre neuen Zielgruppen in die Listener-Standardaktion oder in die Regeln eines vorhandenen VPC-Lattice-Services aufnehmen. Weitere Informationen finden Sie unter [Listener-Regeln für Ihren VPC-Lattice-Service](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html). 1. (Optional) Um einen Load Balancer für Ihren Service zu konfigurieren, erweitern Sie **Load balancing** (Load Balancing). Wählen Sie den Load Balancer aus. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (Optional) Um Service-Auto-Scaling zu konfigurieren, erweitern Sie **Service-Auto-Scaling** und geben Sie dann die folgenden Parameter an. Um prädiktives Auto Scaling zu verwenden, das vergangene Ladedaten aus Datenverkehrsflüssen betrachtet, konfigurieren Sie dies, nachdem Sie den Service erstellt haben. Weitere Informationen finden Sie unter [Verwenden Sie historische Muster, um Amazon ECS-Services mit vorausschauender Skalierung zu skalieren](predictive-auto-scaling.md). 1. Um das Auto Scaling der Services zu verwenden, wählen Sie **Auto Scaling des Services**. 1. Geben Sie unter **Mindestanzahl an Aufgaben**, die Untergrenze der Anzahl der Aufgaben an, die das Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht unterschreiten. 1. Geben Sie unter **Höchstanzahl an Aufgaben** die Obergrenze der Anzahl der Aufgaben an, die das Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht überschreiten. 1. Wählen Sie den Richtlinien-Typ aus. Wählen Sie unter **Skalierungsrichtlinientyp** eine der folgenden Optionen aus. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (Optional) Um eine andere als die standardmäßige Strategie zur Platzierung von Aufgaben zu verwenden, erweitern Sie **Task Placement** (Platzierung von Aufgaben) und wählen Sie aus den folgenden Optionen aus. Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md). + **AZ Balanced Spread (Ausgewogene AZ-Verteilung)**: Verteilt Aufgaben über Availability Zones und über Container-Instances in der Availability Zone. + **AZ Balanced BinPack** — Verteilen Sie Aufgaben auf Availability Zones und auf Container-Instances mit dem geringsten verfügbaren Speicher. + **BinPack**— Verteilen Sie Aufgaben auf der Grundlage der geringsten verfügbaren CPU- oder Speichermenge. + **One Task Per Host (Eine Aufgabe pro Host)**: Platziert höchstens eine Aufgabe des Service auf jeder Container-Instance. + **Benutzerdefiniert**: Definieren Sie Ihre eigene Aufgabenplatzierungsstrategie. Wenn Sie **Custom** (Benutzerdefiniert) wählen, definieren Sie den Algorithmus für das Platzieren von Aufgaben und die Regeln, die bei der Aufgabenplatzierung berücksichtigt werden. + Unter **Strategy** (Strategie), für **Type** (Typ) und **Field** (Feld), wählen Sie den Algorithmus und die Entität aus, die für den Algorithmus verwendet werden sollen. Sie können maximal 5 Strategien angeben. + Unter **Einschränkung**, für **Typ** und **Ausdruck**, wählen Sie die Regel und das Attribut für die Einschränkung aus. Um beispielsweise die Einschränkung festzulegen, Aufgaben auf T2-Instances zu platzieren, geben Sie für **Expression** (Ausdruck) **attribute:ecs.instance-type =\$1 t2.\$1** ein. Sie können maximal 10 Einschränkungen angeben. 1. Wenn Ihre Aufgabe ein Daten-Volume verwendet, das mit der Konfiguration bei der Bereitstellung kompatibel ist, können Sie das Volume konfigurieren, indem Sie **Volume** erweitern. Der Volume-Name und der Volume-Typ werden bei der Erstellung einer Revision der Aufgabendefinition konfiguriert und können nicht geändert werden, wenn Sie einen Service erstellen. Um den Namen und den Typ des Volumes zu aktualisieren, müssen Sie eine neue Revision der Aufgabendefinition erstellen und einen Service mithilfe der neuen Revision erstellen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Um ECS Exec zum Debuggen des Services zu verwenden, wählen Sie unter **Konfiguration zur Fehlerbehebung** die Option **ECS Exec einschalten** aus. 1. (Optional) Um Ihren Service und Ihre Aufgaben besser identifizieren zu können, erweitern Sie den Bereich **Tags** (Tags) und konfigurieren Sie dann Ihre Tags. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clusternamen und den Aufgabendefinitions-Tags versieht, wählen Sie **Amazon ECS Managed Tags einschalten** und dann für **Tags verbreiten von** die Option **Aufgabendefinitionen**. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clustername und die Service-Tags versieht, wählen Sie **Amazon ECS Managed Tags** einschalten und dann für **Tags verbreiten von** die Option **Service**. Hinzufügen oder Entfernen eines Tag. + [Ein Tag hinzufügen] Wählen Sie **Add tag** (Tag hinzufügen) und führen Sie dann das Folgende aus: + Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein. + Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein. + [Tag entfernen] Wählen Sie neben dem Tag die Option **Remove tag (Tag löschen)** aus. 1. Wählen Sie **Erstellen** aus. ## Nächste Schritte Im Folgenden finden Sie zusätzliche Aktionen, nachdem Sie einen Service erstellt haben. + Konfigurieren Sie prädiktives Auto Scaling, das vergangene Ladedaten aus Datenverkehrsflüssen berücksichtigt. Weitere Informationen finden Sie unter [Verwenden Sie historische Muster, um Amazon ECS-Services mit vorausschauender Skalierung zu skalieren](predictive-auto-scaling.md). + Verfolgen Sie Ihre Bereitstellung und zeigen Sie Ihren Service-Verlauf für Services an, die der Amazon-ECS-Schutzschalter unterbricht. Weitere Informationen finden Sie unter [Anzeigen des Service-Verlaufs mithilfe von Service-Bereitstellungen in Amazon ECS](service-deployment.md). # Amazon blue/green ECS-Bereitstellungen Eine blue/green Bereitstellung ist eine Release-Methode, die Ausfallzeiten und Risiken reduziert, indem zwei identische Produktionsumgebungen ausgeführt werden, die als blaue und grüne Umgebungen bezeichnet werden. Mit Amazon blue/green ECS-Bereitstellungen können Sie neue Service-Revisionen validieren, bevor Sie den Produktionsdatenverkehr an sie weiterleiten. Dieser Ansatz bietet eine sicherere Methode zur Bereitstellung von Änderungen und bietet die Möglichkeit, bei Bedarf schnell ein Rollback durchzuführen. ## Vorteile Im Folgenden sind die Vorteile der Verwendung von Bereitstellungen aufgeführt: blue/green + Reduziert das Risiko, indem Tests mit Produktionsdatenverkehr durchgeführt werden, bevor die Produktion gewechselt wird. Sie können die neue Bereitstellung anhand von Test-Datenverkehr validieren, bevor Sie den Produktionsdatenverkehr dorthin weiterleiten. + Bereitstellungen mit null Ausfallzeit. Die Produktionsumgebung bleibt während des gesamten Bereitstellungsprozesses verfügbar und gewährleistet so eine kontinuierliche Service-Verfügbarkeit. + Einfaches Rollback, wenn Probleme erkannt werden. Wenn Probleme mit der Grün-Bereitstellung auftreten, können Sie schnell zur Blau-Bereitstellung zurückkehren, ohne dass der Service länger unterbrochen wird. + Kontrollierte Testumgebung. Die grüne Umgebung bietet einen isolierten Bereich, in dem neue Features anhand realer Datenverkehrsmuster getestet werden können, bevor sie vollständig bereitgestellt werden. + Vorhersehbarer Bereitstellungsprozess. Der strukturierte Ansatz mit definierten Lebenszyklusphasen macht Bereitstellungen konsistenter und zuverlässiger. + Automatisierte Validierung durch Lebenszyklus-Hooks. Sie können in verschiedenen Phasen der Bereitstellung automatisierte Tests implementieren, um die Funktionalität zu überprüfen. ## Terminologie Im Folgenden finden Sie die Bedingungen für die blue/green Bereitstellung von Amazon ECS: + Bake-Zeit – Die Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde. + Blau-Bereitstellung – Die aktuelle Produktions-Service-Revision, die Sie ersetzen möchten. + Grün-Bereitstellung – Die neue Service-Revision, die Sie bereitstellen möchten. + Lebenszyklusphasen – Eine Reihe von Ereignissen während des Bereitstellungsvorgangs, z. B. „nach der Verschiebung des Produktionsdatenverkehrs“. + Lebenszyklus-Hook – Eine Lambda-Funktion, die die Bereitstellung in einer bestimmten Lebenszyklusphase verifiziert. + 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. + 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. + Datenverkehrsverlagerung – Der Prozess, den Amazon ECS verwendet, um den Datenverkehr von der Blau-Bereitstellung zur Grün-Bereitstellung zu verlagern. Bei Amazon blue/green ECS-Bereitstellungen wird der gesamte Datenverkehr gleichzeitig vom blauen Service zum grünen Service verlagert. ## Überlegungen Berücksichtigen Sie bei der Auswahl eines Bereitstellungstyps Folgendes: + Ressourcennutzung: In Blue/green Bereitstellungen werden vorübergehend sowohl die blaue als auch die grüne Version des Service gleichzeitig ausgeführt, wodurch sich Ihr Ressourcenverbrauch während Bereitstellungen verdoppeln kann. + Überwachung der Bereitstellung: Blue/green Bereitstellungen bieten detailliertere Informationen zum Bereitstellungsstatus, sodass Sie jede Phase des Bereitstellungsprozesses überwachen können. + Rollback: Blue/green Bereitstellungen erleichtern das Rollback zur vorherigen Version, wenn Probleme erkannt werden, da die blaue Version so lange läuft, bis die Backzeit abgelaufen ist. + Network Load Balancer-Lifecycle-Hooks: Wenn Sie einen Network Load Balancer für blue/green Bereitstellungen verwenden, stehen zusätzliche 10 Minuten für die Lebenszyklusphasen TEST\$1TRAFFIC\$1SHIFT und PRODUCTION\$1TRAFFIC\$1SHIFT zur Verfügung. Dies liegt daran, dass Amazon ECS sicherstellt, dass der Verkehr sicher verlagert werden kann. # 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). 1. **Vorbereitungsphase**: Erstellen Sie die grüne Umgebung neben der bestehenden blauen Umgebung. Dies beinhaltet die Bereitstellung neuer Service-Revisionen und die Vorbereitung der Zielgruppen. 1. **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. 1. **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. 1. **Phase der Datenverkehrsverlagerung**: Verlagern Sie den Produktionsdatenverkehr basierend auf Ihrer konfigurierten Bereitstellungsstrategie von blau auf grün. Diese Phase umfasst Überwachungs- und Validierungsprüfpunkte. 1. **Ü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. 1. **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: ![\[Umfassendes Diagramm, das den blue/green Bereitstellungsprozess in Amazon ECS mit detaillierten Komponenteninteraktionen, Phasen der Verkehrsverlagerung und Überwachungsprüfpunkten zeigt\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/images/blue-green.png) Der erweiterte Bereitstellungs-Workflow umfasst die folgenden detaillierten Schritte: 1. **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. 1. **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. 1. **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. 1. **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. 1. **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. 1. **Ü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. 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. **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. 1. **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\$1SERVICE | Diese Phase tritt nur ein, wenn Sie eine neue Servicebereitstellung mit mehr als einer Service-Revision im Status ACTIVE starten. | Ja | | PRE\$1SCALE\$1UP | Die grüne Service-Revision wurde nicht gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja | | SCALE\$1UP | 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\$1SCALE\$1UP | Die grüne Service-Revision wurde gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja | | TEST\$1TRAFFIC\$1SHIFT | 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\$1TEST\$1TRAFFIC\$1SHIFT | Die Verlagerung des Test-Datenverkehrs ist abgeschlossen. Die grüne Service-Revision wickelt 100 % des Test-Datenverkehrs ab. | Ja | | PRODUCTION\$1TRAFFIC\$1SHIFT | 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\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Die Verlagerung des Produktionsdatenverkehrs ist abgeschlossen. | Ja | | BAKE\$1TIME | Die Dauer, in der sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden. | Nein | | CLEAN\$1UP | 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\$1PROGRESS zurückgeben. Sie können `callBackDelaySeconds` verwenden, um den Aufruf von Lambda zu verzögern. Weitere Informationen finden Sie unter der [Funktion app.py](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25) in der Option sample-amazon-ecs-blue - green-deployment-patterns on. GitHub # 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. # Eine Amazon blue/green ECS-Bereitstellung erstellen Mithilfe von Amazon blue/green ECS-Bereitstellungen können Sie Serviceänderungen vornehmen und testen, bevor Sie sie in einer Produktionsumgebung implementieren. ## Voraussetzungen Führen Sie die folgenden Vorgänge aus, bevor Sie eine blue/green Bereitstellung starten. 1. Konfigurieren Sie die entsprechenden Berechtigungen. + Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Weitere Informationen zu Lambda-Berechtigungen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). 1. Amazon blue/green ECS-Bereitstellungen erfordern, dass Ihr Service eine der folgenden Funktionen verwendet: 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). 1. Entscheiden Sie, ob Sie Lambda-Funktionen für die Lebenszyklusphasen ausführen möchten. + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + TEST\$1TRAFFIC\$1SHIFT + POST\$1TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT Weitere Informationen finden Sie unter [Erstellen einer Lambda-Funktion mit der Konsole](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) im *Entwicklerhandbuch für AWS Lambda *. ## Verfahren Sie können die Konsole oder die verwenden AWS CLI , um einen Amazon blue/green ECS-Service zu erstellen. ------ #### [ Console ] 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Bestimmen Sie die Ressource, von der aus Sie den Service starten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-blue-green-service.html) Die Seite **Service erstellen** wird angezeigt. 1. Führen Sie unter **Service-Details** die folgenden Schritte aus: 1. Wählen Sie für **Aufgabendefinitionsfamilie** die zu verwendende Aufgabendefinition aus. Geben Sie dann unter **Revision der Aufgabendefinition** die zu verwendende Revision ein. 1. Wählen Sie für **Service name** (Servicename) einen Namen für Ihren Service aus. 1. Um den Service in einem vorhandenen Cluster auszuführen, wählen Sie unter **Vorhandener Cluster** den Cluster aus. Um den Service in einem neuen Cluster auszuführen, wählen Sie **Cluster erstellen** aus 1. Wählen Sie aus, wie Ihre Aufgaben auf Ihre Cluster-Infrastruktur verteilt werden. Wählen Sie unter **Datenverarbeitungskonfiguration** Ihre Option aus. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. Führen Sie im Abschnitt **Bereitstellungskonfiguration** Folgendes aus: 1. Wählen Sie für **Service-Typ** die Option **Replikat** aus. 1. Geben Sie für **Desired tasks** (Gewünschte Aufgaben) die Anzahl der Aufgaben an, die im Service gestartet und aufrecht erhalten werden sollen. 1. Damit Amazon ECS die Verteilung der Aufgaben auf die Availability Zones überwacht und sie bei einem Ungleichgewicht neu verteilt, wählen Sie unter **Service-Neuausgleich der Availability Zone** die Option **Service-Neuausgleich der Availability Zone** aus. 1. Geben Sie für **Wartefrist der Zustandsprüfung** die Zeitspanne (in Sekunden) ein, die der Service Scheduler fehlerhafte Elastic-Load-Balancing-, VPC-Lattice- und Container-Zustandsprüfungen ignoriert, nachdem eine Aufgabe zum ersten Mal gestartet wurde. Wenn Sie keine Übergangsfrist für die Zustandsprüfung angeben, wird der Standardwert 0 verwendet. 1. 1. Geben Sie für **Bake-Zeit** die Anzahl der Minuten ein, für die sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden, bevor die blaue Revision beendet wird. Dadurch bleibt Zeit für die Verifizierung und das Testen. 1. (Optional) Führen Sie Lambda-Funktionen in bestimmten Phasen der Bereitstellung aus. Wählen Sie unter **Bereitstellungs-Lebenszyklus-Hooks** die Phasen aus, in denen die Lebenszyklus-Hooks ausgeführt werden sollen. So fügen Sie einen Lebenszyklus-Hook hinzu: 1. Wählen Sie **Hinzufügen** aus. 1. Geben Sie für **Lambda-Funktion** den Funktionsnamen oder ARN ein. 1. Wählen Sie für **Rolle** die IAM-Rolle aus, die berechtigt ist, die Lambda-Funktion aufzurufen. 1. Wählen Sie für **Lebenszyklusphasen** die Phasen aus, in denen die Lambda-Funktion ausgeführt werden soll. 1. Um zu konfigurieren, wie Amazon ECS Bereitstellungsfehler erkennt und behandelt, erweitern Sie **Deployment failure detection** (Erkennung von Bereitstellungsfehlern) und wählen Sie dann Ihre Optionen. 1. Um eine Bereitstellung anzuhalten, wenn die Aufgaben nicht gestartet werden können, wählen Sie **Use the Amazon ECS deployment circuit breaker** (Verwenden des Amazon-ECS-Bereitstellungsschutzschalters). Wenn Sie möchten, dass die Software die Bereitstellung automatisch auf den letzten abgeschlossenen Bereitstellungsstatus zurücksetzt, wenn der Bereitstellungs-Schutzschalter die Bereitstellung auf einen fehlgeschlagenen Status setzt, wählen Sie **Rollback bei Fehler** aus. 1. Um eine Bereitstellung auf der Grundlage von Anwendungsmetriken zu beenden, wählen Sie ** CloudWatch Alarm (e) verwenden** aus. Wählen Sie dann unter **CloudWatch Alarmname** die Alarme aus. Um einen neuen Alarm zu erstellen, gehen Sie zur CloudWatch Konsole. Damit die Software die Bereitstellung automatisch auf den Status der letzten abgeschlossenen Bereitstellung zurücksetzt, wenn ein CloudWatch Alarm die Bereitstellung in einen fehlgeschlagenen Zustand versetzt, wählen Sie **Rollback bei Fehlern** aus. 1. (Optional) Um Ihren Service mit Service Connect zu verbinden, erweitern Sie **Service Connect** und geben Sie dann Folgendes an: 1. Wählen Sie **Service Connect einschalten** aus. 1. Geben Sie unter **Service Connect configuration** (Service-Connect-Konfiguration) den Client-Modus an. + Wenn Ihr Service eine Netzwerk-Client-Anwendung ausführt, die nur eine Verbindung zu anderen Services im Namespace herstellen muss, wählen Sie **Nur Client-Seite** aus. + Wenn Ihr Service eine Netzwerk- oder Webservice-Anwendung ausführt und Endpunkte für diesen Service bereitstellen muss und eine Verbindung zu anderen Services im Namespace herstellt, wählen Sie **Client and server** (Client und Server) aus. 1. Um einen Namespace zu verwenden, der nicht der Standard-Cluster-Namespace ist, wählen Sie für **Namespace** den Service-Namespace aus. Dies kann ein Namespace sein, der separat in demselben AWS-Region in Ihrer AWS-Konto oder einem Namespace in derselben Region erstellt wurde und der mithilfe AWS Resource Access Manager von () mit Ihrem Konto geteilt wird.AWS RAM*Weitere Informationen zur gemeinsamen Nutzung von AWS Cloud Map Namespaces finden Sie unter [Kontenübergreifende gemeinsame Nutzung von AWS Cloud Map Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) im Entwicklerhandbuch.AWS Cloud Map * 1. (Optional) Konfigurieren Sie Header-Regeln für Testdatenverkehr für Bereitstellungen. blue/green Geben Sie unter **Test-Datenverkehrs-Routing** Folgendes an: 1. Wählen Sie **Header-Regeln für Test-Datenverkehr aktivieren** aus, um während des Tests bestimmte Anfragen an die grüne Service-Revision weiterzuleiten. 1. Konfigurieren Sie für **Regeln für den Header-Abgleich** die Kriterien für das Routing von Test-Datenverkehr: + **Header-Name**: Geben Sie den Namen des HTTP-Headers ein, dem der Abgleich entsprechen soll (z. B. `X-Test-Version` oder `User-Agent`). + **Übereinstimmungstyp**: Wählen Sie die Kriterien für den Abgleich aus: + **Exakte Übereinstimmung**: Leitet Anfragen weiter, bei denen der Header-Wert genau dem angegebenen Wert entspricht + **Header vorhanden**: Leitet Anfragen weiter, die den angegebenen Header enthalten, unabhängig vom Wert + **Musterübereinstimmung**: Leitet Anfragen weiter, bei denen der Header-Wert einem bestimmten Muster entspricht + **Header-Wert** (wenn „Exakte Übereinstimmung“ oder „Musterübereinstimmung“ verwendet wird): Geben Sie den Wert oder das Muster ein, mit dem abgeglichen werden soll. Sie können mehrere Header-Abgleichsregeln hinzufügen, um eine komplexe Routing-Logik zu erstellen. Anfragen, die einer der konfigurierten Regeln entsprechen, werden zum Testen an die grüne Service-Revision weitergeleitet. 1. Wählen Sie **Header-Regel hinzufügen**, um zusätzliche Bedingungen für den Header-Abgleich zu konfigurieren. **Anmerkung** Mithilfe von Header-Regeln für den Test-Datenverkehr können Sie neue Funktionen mit kontrolliertem Datenverkehr validieren, bevor Sie die vollständige Bereitstellung abschließen. Auf diese Weise können Sie die grüne Service-Revision mit spezifischen Anfragen (z. B. von internen Testtools oder Beta-Benutzern) testen und gleichzeitig den normalen Datenfluss zur blauen Service-Revision aufrechterhalten. 1. (Optional) Geben Sie eine Protokollkonfiguration an. Wählen Sie **Protokollsammlung verwenden** aus. Die Standardoption sendet CloudWatch Container-Protokolle an Logs. Die anderen Protokolltreiberoptionen werden mit konfiguriert AWS FireLens. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md). Im Folgenden wird jedes Container-Protokollziel ausführlicher beschrieben. + **Amazon CloudWatch** — Konfigurieren Sie die Aufgabe, um Container-Logs an CloudWatch Logs zu senden. Es werden die standardmäßigen Protokolltreiberoptionen bereitgestellt, mit denen in Ihrem Namen eine CloudWatch Protokollgruppe erstellt wird. Um einen anderen Protokollgruppen-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Data Firehose** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Firehose gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch die Protokolle an einen Bereitstellungsdatenstrom von Firehose gesendet werden. Um einen anderen Namen für den Bereitstellungsdatenstrom anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Kinesis Data Streams** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Kinesis Data Streams gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch Protokolle an einen Datenstrom von Kinesis Data Streams gesendet werden. Um einen anderen Datenstrom-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon OpenSearch Service** — Konfigurieren Sie die Aufgabe, um Container-Logs an eine OpenSearch Service-Domain zu senden. Die Optionen für den Protokolltreiber müssen bereitgestellt werden. + **Amazon S3** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an einen Amazon-S3-Bucket gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, Sie müssen jedoch einen gültigen Amazon-S3-Bucket-Namen angeben. 1. (Optional) Konfigurieren Sie **Load Balancing** für die Blau/Grün-Bereitstellung. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. (Optional) Um Ihren Service und Ihre Aufgaben besser identifizieren zu können, erweitern Sie den Bereich **Tags** (Tags) und konfigurieren Sie dann Ihre Tags. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clusternamen und den Aufgabendefinitions-Tags versieht, wählen Sie **Amazon ECS Managed Tags einschalten** und dann für **Tags verbreiten von** die Option **Aufgabendefinitionen**. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clustername und die Service-Tags versieht, wählen Sie **Amazon ECS Managed Tags** einschalten und dann für **Tags verbreiten von** die Option **Service**. Hinzufügen oder Entfernen eines Tag. + [Ein Tag hinzufügen] Wählen Sie **Add tag** (Tag hinzufügen) und führen Sie dann das Folgende aus: + Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein. + Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein. + [Tag entfernen] Wählen Sie neben dem Tag die Option **Remove tag (Tag löschen)** aus. 1. Wählen Sie **Erstellen** aus. ------ #### [ AWS CLI ] 1. Erstellen Sie eine Datei mit dem Namen `service-definition.json` und dem folgenden Inhalt. Ersetzen Sie die durch Ihre *user-input* Werte. ``` { "serviceName": "myBlueGreenService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 2, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true }, "lifecycleHooks": [ { "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample", "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke", "lifecycleStages": [ "PRE_SCALE_UP" ] } ] }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Führen Sie `create-service`. Ersetze die *user-input* durch deine Werte. ``` aws ecs create-service --cli-input-json file://service-definition.json ``` Alternativ können Sie das folgende Beispiel verwenden, das einen blue/green Bereitstellungsdienst mit einer Load Balancer-Konfiguration erstellt: ``` aws ecs create-service \ --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \ --service-name "blue-green-example-service" \ --task-definition "nginxServer:1" \ --launch-type "FARGATE" \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \ --desired-count 3 \ --deployment-controller "type=ECS" \ --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \ --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}" ``` ------ ## Nächste Schritte + Aktualisieren Sie den Service, um die Bereitstellung zu starten. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). + Überwachen Sie den Bereitstellungsprozess, um sicherzustellen, dass er dem blue/green Muster folgt: + Die grüne Service-Revision wurde erstellt und hochskaliert + Der Test-Datenverkehr wird an die grüne Revision weitergeleitet (falls konfiguriert) + Der Produktionsdatenverkehr verlagert sich auf die grüne Revision. + Nach Ablauf der Bake-Zeit wird die blaue Revision beendet # Fehlerbehebung bei Amazon blue/green ECS-Bereitstellungen Im Folgenden finden Sie Lösungen für häufig auftretende Probleme, die bei der Verwendung von blue/green Bereitstellungen mit Amazon ECS auftreten können. Blue/green Bereitstellungsfehler können in den folgenden Phasen auftreten: + *Synchroner Pfad*: Fehler, die sofort als Reaktion auf `CreateService`- oder `UpdateService`-API-Aufrufe auftreten. + *Asynchroner Pfad*: Fehler, die im `statusReason`-Feld von `DescribeServiceDeployments` auftreten und zu einem Rollback der Bereitstellung führen **Tipp** Sie können die [Amazon ECS MCP-Server](ecs-mcp-introduction.md) KI-Assistenten verwenden, um Bereitstellungen zu überwachen und Bereitstellungsprobleme in natürlicher Sprache zu beheben. ## Probleme mit der Load-Balancer-Konfiguration Die Load Balancer-Konfiguration ist eine wichtige Komponente von blue/green Bereitstellungen in Amazon ECS. Die richtige Konfiguration von Listener-Regeln, Zielgruppen und Load-Balancer-Typen ist für erfolgreiche Bereitstellungen unerlässlich. In diesem Abschnitt werden häufig auftretende Probleme mit der Load Balancer-Konfiguration behandelt, die dazu führen können, dass blue/green Bereitstellungen fehlschlagen. Bei der Behebung von Problemen mit dem Load Balancer ist es wichtig, die Beziehung zwischen Listener-Regeln und Zielgruppen zu kennen. In einer blue/green Bereitstellung: + Die Listener-Regel für die Produktion leitet den Datenverkehr an die aktuell aktive (blaue) Service-Revision weiter + Die Test-Listener-Regel kann verwendet werden, um die neue (grüne) Service-Revision zu validieren, bevor der Produktionsdatenverkehr verlagert wird + Zielgruppen werden verwendet, um die Container-Instances jeder Service-Revision zu registrieren + Während der Bereitstellung wird der Datenverkehr schrittweise von der blauen Service-Revision zur grünen Service-Revision verlagert, indem die Gewichtung der Zielgruppen in den Listener-Regeln angepasst wird. ### Fehler bei der Konfiguration der Listener-Regel Die folgenden Probleme beziehen sich auf eine falsche Listener-Regelkonfiguration für blue/green Bereitstellungen. Verwenden eines Application-Load-Balancer-Listener-ARN anstelle eines Listener-Regel-ARN *Fehlermeldung*: `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456` *Lösung*: Wenn Sie einen Application Load Balancer verwenden, müssen Sie einen Listener-Regel-ARN für `productionListenerRule` und `testListenerRule` angeben, und keinen Listener-ARN. Für Network Load Balancer müssen Sie den Listener-ARN verwenden. Weitere Informationen darüber, wie Sie den Listener-ARN finden können finden Sie unter [Listeners für Ihre Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) im *Benutzerhandbuch für Application Load Balancer*. Der ARN für eine Regel hat das Format `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...`. Verwenden derselben Regel sowohl für Produktions- als auch für Test-Listener *Fehlermeldung*: `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789` *Lösung*: Sie müssen unterschiedliche Listener-Regeln für Produktions- und Test-Datenverkehr verwenden. Erstellen Sie eine separate Listener-Regel für Test-Datenverkehr, die an Ihre Testzielgruppe weiterleitet. Zielgruppe, die keinen Listener-Regeln zugeordnet ist *Fehlermeldung*: `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.` *Lösung*: Sowohl die primäre Zielgruppe als auch die alternative Zielgruppe müssen entweder der Produktions-Listener-Regel oder der Test-Listener-Regel zugeordnet werden. Aktualisieren Sie Ihre Load-Balancer-Konfiguration, um sicherzustellen, dass beide Zielgruppen ordnungsgemäß Ihren Listener-Regeln zugeordnet sind. Fehlende Test-Listener-Regel für einen Application Load Balancer *Fehlermeldung*: `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup` *Lösung*: Wenn Sie einen Application Load Balancer verwenden und beide Zielgruppen nicht mit der Produktions-Listener-Regel verknüpft sind, müssen Sie eine Test-Listener-Regel angeben. Fügen Sie Ihrer Konfiguration eine `testListenerRule` hinzu und stellen Sie sicher, dass beide Zielgruppen entweder der Produktions- oder der Test-Listener-Regel zugeordnet sind. Weitere Informationen finden Sie unter [Listeners für Ihre Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) im *Benutzerhandbuch für Application Load Balancer*. ### Fehler bei der Zielgruppenkonfiguration Die folgenden Probleme beziehen sich auf eine falsche Zielgruppenkonfiguration für blue/green Bereitstellungen. Regel für mehrere Zielgruppen mit Datenverkehr in der Listener-Regel *Fehlermeldung*: `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic` *Lösung*: Stellen Sie vor dem Start einer blue/green Bereitstellung sicher, dass in Ihrer Listener-Regel nur eine Zielgruppe Traffic empfängt (mit einer Gewichtung ungleich Null). Aktualisieren Sie Ihre Listener-Regelkonfiguration, um die Gewichtung für alle Zielgruppen, die keinen Datenverkehr erhalten sollen, auf Null zu setzen. Doppelte Zielgruppen in allen Load-Balancer-Einträgen *Fehlermeldung*: `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123` *Lösung*: Jeder Zielgruppen-ARN muss für alle Load-Balancer-Einträge in Ihrer Servicedefinition eindeutig sein. Überprüfen Sie Ihre Konfiguration und stellen Sie sicher, dass Sie für jeden Load-Balancer-Eintrag unterschiedliche Zielgruppen verwenden. Unerwartete Zielgruppe in der Produktions-Listener-Regel *Fehlermeldung*: `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789` *Lösung*: Die Produktions-Listener-Regel leitet den Datenverkehr an eine Zielgruppe weiter, die nicht in Ihrer Servicedefinition angegeben ist. Stellen Sie sicher, dass die Listener-Regel so konfiguriert ist, dass der Datenverkehr nur an die in Ihrer Servicedefinition angegebenen Zielgruppen weitergeleitet wird. Weitere Informationen finden Sie unter [Weiterleitungsaktionen](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions) im *Benutzerhandbuch für Application Load Balancer*. ### Konfigurationsfehler beim Load-Balancer-Typ Die folgenden Probleme beziehen sich auf eine falsche Konfiguration des Load Balancer-Typs für Bereitstellungen. blue/green Mischung aus Application Load Balancer, Classic Load Balancer und Network Load Balancer *Fehlermeldung*: `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)` Ein Classic Load Balancer ist der Elastic Load Balancer der vorherigen Generation. Es wird empfohlen, zu einem Load Balancer der aktuellen Generation zu migrieren. Weitere Informationen finden Sie unter [Migration Ihres Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html). *Lösung*:. Verwenden Sie entweder ausschließlich Classic Load Balancers oder Application Load Balancers und Network Load Balancers. Geben Sie für Application Load Balancers und Network Load Balancers nur das `targetGroupArn`-Feld an. Verwenden der erweiterten Konfiguration mit einem Classic Load Balancer *Fehlermeldung*: `advancedConfiguration field is not allowed with ELBv1 loadBalancers` *Lösung: Die* erweiterte Konfiguration für blue/green Bereitstellungen wird nur mit Application Load Balancers und Network Load Balancers unterstützt. Wenn Sie einen Classic Load Balancer (angegeben mit `loadBalancerName`) verwenden, können Sie das `advancedConfiguration`-Feld nicht verwenden. Wechseln Sie entweder zu einem Application Load Balancer oder entfernen Sie das `advancedConfiguration`-Feld. Inkonsistente erweiterte Konfiguration für alle Load Balancers *Fehlermeldung*: `Either all or none of the provided loadBalancers must have advancedConfiguration defined` *Lösung*: Wenn Sie mehrere Load Balancers verwenden, müssen Sie sie `advancedConfiguration` entweder für alle oder für keinen von ihnen definieren. Aktualisieren Sie Ihre Konfiguration, um die Konsistenz aller Load-Balancer-Einträge sicherzustellen. Fehlende erweiterte Konfiguration bei der Bereitstellung blue/green *Fehlermeldung*: `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy` *Lösung*: Wenn Sie eine blue/green Bereitstellungsstrategie mit Application Load Balancers verwenden, müssen Sie das `advancedConfiguration` Feld für alle Load Balancer-Einträge angeben. Fügen Sie die Erforderliche `advancedConfiguration` zu Ihrer Load Balancer-Konfiguration hinzu. ## Probleme mit Berechtigungen Die folgenden Probleme beziehen sich auf unzureichende Berechtigungen für blue/green Bereitstellungen. Fehlende Vertrauensrichtlinie für die Infrastrukturrolle *Fehlermeldung*: `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.` *Lösung*: Die für die Verwaltung der Load-Balancer-Ressourcen angegebene IAM-Rolle hat nicht die richtige Vertrauensrichtlinie. Aktualisieren Sie die Vertrauensrichtlinie der Rolle, um es dem Service zu erlauben, die Rolle anzunehmen. Die Vertrauensrichtlinie muss Folgendes beinhalten: **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Fehlende Leseberechtigungen für die Load-Balancer-Rolle *Fehlermeldung*: `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)` *Lösung*: Die IAM-Rolle, die für die Verwaltung der Load-Balancer-Ressourcen verwendet wird, ist nicht berechtigt, die Zustandinformationen des Ziels zu lesen. Fügen Sie die Berechtigungsrichtlinie `elasticloadbalancing:DescribeTargetHealth` der Richtlinie der Rolle hinzu. Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Fehlende Schreibberechtigungen für die Load-Balancer-Rolle *Fehlermeldung*: `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)` *Lösung*: Die für die Verwaltung der Load-Balancer-Ressourcen verwendete IAM-Rolle ist nicht berechtigt, Ziele zu registrieren. Fügen Sie die Berechtigungsrichtlinie `elasticloadbalancing:RegisterTargets` der Richtlinie der Rolle hinzu. Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Fehlende Berechtigung zum Ändern von Listener-Regeln *Fehlermeldung*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action` *Lösung*: Die für die Verwaltung der Load-Balancer-Ressourcen verwendete IAM-Rolle ist nicht berechtigt, Listener zu ändern. Fügen Sie die Berechtigungsrichtlinie `elasticloadbalancing:ModifyListener` der Richtlinie der Rolle hinzu. Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Für blue/green Bereitstellungen empfehlen wir, die `AmazonECS-ServiceLinkedRolePolicy` verwaltete Richtlinie Ihrer Infrastrukturrolle zuzuordnen, die alle erforderlichen Berechtigungen für die Verwaltung von Load Balancer-Ressourcen umfasst. ## Probleme mit Lebenszyklus-Hooks Die folgenden Probleme beziehen sich auf Lifecycle-Hooks in Bereitstellungen. blue/green Falsche Vertrauensrichtlinie für die Lambda-Hook-Rolle *Fehlermeldung*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin` *Lösung*: Die für den Lambda-Lebenszyklus-Hook angegebene IAM-Rolle hat nicht die richtige Vertrauensrichtlinie. Aktualisieren Sie die Vertrauensrichtlinie der Rolle, um es dem Service zu erlauben, die Rolle anzunehmen. Die Vertrauensrichtlinie muss Folgendes beinhalten: **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Lambda-Hook gibt den Status FAILED zurück *Fehlermeldung*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.` *Lösung*: Die als Lebenszyklus-Hook angegebene Lambda-Funktion hat den Status FAILED zurückgegeben. Überprüfen Sie die Lambda-Funktionsprotokolle in den CloudWatch Amazon-Protokollen, um die Fehlerursache zu ermitteln, und aktualisieren Sie die Funktion, damit das Bereitstellungsereignis korrekt verarbeitet wird. Fehlende Berechtigung zum Aufrufen der Lambda-Funktion *Fehlermeldung*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action` *Lösung*: Die für den Lambda-Lebenszyklus-Hook verwendete IAM-Rolle ist nicht berechtigt, die Lambda-Funktion aufzurufen. Fügen Sie die `lambda:InvokeFunction`-Berechtigung zur Rollenrichtlinie für den spezifischen Lambda-Funktion-ARN hinzu. Weitere Informationen zu Lambda-Berechtigungen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). Timeout oder ungültige Antwort der Lambda-Funktion *Fehlermeldung*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null` *Lösung*: Die Lambda-Funktion hat entweder das Zeitlimit überschritten oder eine ungültige Antwort zurückgegeben. Stellen Sie sicher, dass Ihre Lambda-Funktion eine gültige Antwort mit einem `hookStatus`-Feld zurückgibt, das entweder auf `SUCCEEDED` oder `FAILED` gesetzt ist. Stellen Sie außerdem sicher, dass das Lambda-Funktions-Timeout Ihrer Validierungslogik entsprechend eingestellt ist. Weitere Informationen finden Sie unter [Lebenszyklus-Hooks für Amazon-ECS-Servicebereitstellungen](deployment-lifecycle-hooks.md). Beispiel für eine gültige Lambda-Antwort: ``` { "hookStatus": "SUCCEEDED", "reason": "Validation passed" } ``` # 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. Lambda-Funktionen oder Lifecycle-Hooks, die für PRODUCTION\$1TRAFFIC\$1SHIFT konfiguriert sind, werden bei jedem Produktions-Traffic-Shift-Schritt aufgerufen. + 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: + 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. ## Wie 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. 1. 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. 1. 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. 1. Phase der linearen Verkehrsverlagerung: Verlagern Sie den Produktionsdatenverkehr auf der Grundlage Ihrer konfigurierten Bereitstellungsstrategie schrittweise in gleichen prozentualen Schritten von blau nach grün. 1. Ü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. 1. 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. Lambda-Funktionen oder Lifecycle-Hooks, die für PRODUCTION\$1TRAFFIC\$1SHIFT konfiguriert sind, 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\$1TRAFFIC\$1SHIFT 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\$1SERVICE | Diese Phase tritt nur ein, wenn Sie eine neue Servicebereitstellung mit mehr als einer Service-Revision im Status ACTIVE starten. | Ja | | PRE\$1SCALE\$1UP | Die grüne Service-Revision wurde nicht gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja | | SCALE\$1UP | 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\$1SCALE\$1UP | Die grüne Service-Revision wurde gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja | | TEST\$1TRAFFIC\$1SHIFT | 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\$1TEST\$1TRAFFIC\$1SHIFT | Die Verlagerung des Test-Datenverkehrs ist abgeschlossen. Die grüne Service-Revision wickelt 100 % des Test-Datenverkehrs ab. | Ja | | PRODUCTION\$1TRAFFIC\$1SHIFT | 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\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Die Verlagerung des Produktionsdatenverkehrs ist abgeschlossen. | Ja | | BAKE\$1TIME | Die Dauer, in der sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden. | Nein | | CLEAN\$1UP | 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 | # Erforderliche Ressourcen für lineare Bereitstellungen von Amazon ECS Um eine lineare Bereitstellung mit verwalteter Verkehrsverlagerung zu verwenden, muss Ihr Service eine der folgenden Funktionen verwenden: + Elastic Load Balancing + Service Connect Die folgende Liste bietet einen allgemeinen Überblick darüber, was Sie für lineare Bereitstellungen von Amazon ECS 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 `linear` in der Servicedefinition. + Optional können Sie zusätzliche Parameter konfigurieren, z. B.: + Bake-Zeit für die neue Bereitstellung + Der Prozentsatz des Datenverkehrs, der in jedem Schritt verlagert werden soll. + Die Wartezeit zwischen den einzelnen Verkehrsverschiebungen in Minuten. + CloudWatch Alarme für automatisches Rollback + Hooks für den Bereitstellungslebenszyklus (dies sind Lambda-Funktionen, die in bestimmten Bereitstellungsphasen wie BEFORE\$1INSTALL, PRODUCTION\$1TRAFFIC\$1SHIFT oder POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT ausgeführt werden) ## Best Practices Folgen Sie diesen bewährten Methoden für erfolgreiche lineare Bereitstellungen von Amazon ECS: + **Stellen Sie sicher, dass Ihre Anwendung beide gleichzeitig ausgeführten Service-Revisionen verarbeiten kann.** + **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.** + Konfigurieren Sie geeignete Zustandsprüfungen, die den Zustand Ihrer Anwendung genau widerspiegeln. + Legen Sie eine Backzeit fest, damit die neue Service-Version ausreichend getestet werden kann. + Implementieren Sie CloudWatch Alarme, um Probleme automatisch zu erkennen und Rollbacks auszulösen. + Wählen Sie Schrittprozentsätze und Backzeiten, um die Bereitstellungsgeschwindigkeit mit den Validierungsanforderungen in Einklang zu bringen. + Verwenden Sie kleinere Prozentsätze (5-10%) für kritische Anwendungen, um das Risiko zu minimieren. + Stellen Sie längere Backzeiten für Anwendungen ein, die Zeit zum Aufwärmen oder Stabilisieren benötigen. + Implementieren Sie CloudWatch Alarme, um Probleme automatisch zu erkennen und Rollbacks bei jedem Anstieg des Datenverkehrs auszulösen. + Überwachen Sie die Anwendungsmetriken bei jeder Verkehrsverlagerung genau, um Leistungseinbußen frühzeitig zu erkennen. + Stellen Sie sicher, dass Ihre Anwendung beide gleichzeitig ausgeführten Service-Revisionen verarbeiten kann. + Testen Sie Ihre Rollback-Verfahren bei unterschiedlichen Datenverkehrsanteilen, bevor Sie sie in der Produktion implementieren. # Eine lineare Amazon ECS-Bereitstellung erstellen Durch die Verwendung linearer Bereitstellungen von Amazon ECS können Sie den Datenverkehr schrittweise in gleichen Schritten über bestimmte Zeitintervalle verlagern. Dies ermöglicht eine kontrollierte Validierung in jedem Schritt des Bereitstellungsprozesses. ## Voraussetzungen Führen Sie die folgenden Vorgänge aus, bevor Sie eine lineare Bereitstellung starten. 1. Konfigurieren Sie die entsprechenden Berechtigungen. + Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Weitere Informationen zu Lambda-Berechtigungen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). 1. Lineare Bereitstellungen von Amazon ECS erfordern, dass Ihr Service eine der folgenden Funktionen verwendet: 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). ## Verfahren Sie können die Konsole oder die verwenden AWS CLI , um einen linearen Amazon ECS-Bereitstellungsservice zu erstellen. ------ #### [ Console ] 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Bestimmen Sie die Ressource, von der aus Sie den Service starten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-linear-service.html) Die Seite **Service erstellen** wird angezeigt. 1. Führen Sie unter **Service-Details** die folgenden Schritte aus: 1. Wählen Sie für **Aufgabendefinitionsfamilie** die zu verwendende Aufgabendefinition aus. Geben Sie dann unter **Revision der Aufgabendefinition** die zu verwendende Revision ein. 1. Wählen Sie für **Service name** (Servicename) einen Namen für Ihren Service aus. 1. Um den Service in einem vorhandenen Cluster auszuführen, wählen Sie unter **Vorhandener Cluster** den Cluster aus. Um den Service in einem neuen Cluster auszuführen, wählen Sie **Cluster erstellen** aus 1. Wählen Sie aus, wie Ihre Aufgaben auf Ihre Cluster-Infrastruktur verteilt werden. Wählen Sie unter **Datenverarbeitungskonfiguration** Ihre Option aus. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. Führen Sie im Abschnitt **Bereitstellungskonfiguration** Folgendes aus: 1. Wählen Sie für **Service-Typ** die Option **Replikat** aus. 1. Geben Sie für **Desired tasks** (Gewünschte Aufgaben) die Anzahl der Aufgaben an, die im Service gestartet und aufrecht erhalten werden sollen. 1. Damit Amazon ECS die Verteilung der Aufgaben auf die Availability Zones überwacht und sie bei einem Ungleichgewicht neu verteilt, wählen Sie unter **Service-Neuausgleich der Availability Zone** die Option **Service-Neuausgleich der Availability Zone** aus. 1. Geben Sie für **Wartefrist der Zustandsprüfung** die Zeitspanne (in Sekunden) ein, die der Service Scheduler fehlerhafte Elastic-Load-Balancing-, VPC-Lattice- und Container-Zustandsprüfungen ignoriert, nachdem eine Aufgabe zum ersten Mal gestartet wurde. Wenn Sie keine Übergangsfrist für die Zustandsprüfung angeben, wird der Standardwert 0 verwendet. 1. Konfigurieren Sie unter **Bereitstellungskonfiguration** die Einstellungen für die lineare Bereitstellung: 1. Wählen Sie als **Bereitstellungsstrategie** die Option **Linear** aus. 1. Geben Sie unter **Prozentsatz des Verkehrszuwachses** den Prozentsatz des Verkehrs ein, der in jedem Schritt verlagert werden soll (z. B. 10%, um den Verkehr in Schritten von 10% zu verlagern). 1. Geben Sie im Feld **Intervall zwischen Inkrementen** die Wartezeit in Minuten zwischen den einzelnen Verkehrsverschiebungen ein. 1. Geben Sie für **Backzeit** die Anzahl der Minuten ein, für die sowohl die blaue als auch die grüne Version nach der letzten Verkehrsänderung gleichzeitig ausgeführt werden, bevor die blaue Version beendet wird. 1. (Optional) Führen Sie Lambda-Funktionen in bestimmten Phasen der Bereitstellung aus. Wählen Sie unter **Bereitstellungs-Lebenszyklus-Hooks** die Phasen aus, in denen die Lebenszyklus-Hooks ausgeführt werden sollen. So fügen Sie einen Lebenszyklus-Hook hinzu: 1. Wählen Sie **Hinzufügen** aus. 1. Geben Sie für **Lambda-Funktion** den Funktionsnamen oder ARN ein. 1. Wählen Sie für **Rolle** die IAM-Rolle aus, die berechtigt ist, die Lambda-Funktion aufzurufen. 1. Wählen Sie für **Lebenszyklusphasen** die Phasen aus, in denen die Lambda-Funktion ausgeführt werden soll. 1. Um zu konfigurieren, wie Amazon ECS Bereitstellungsfehler erkennt und behandelt, erweitern Sie **Deployment failure detection** (Erkennung von Bereitstellungsfehlern) und wählen Sie dann Ihre Optionen. 1. Um eine Bereitstellung anzuhalten, wenn die Aufgaben nicht gestartet werden können, wählen Sie **Use the Amazon ECS deployment circuit breaker** (Verwenden des Amazon-ECS-Bereitstellungsschutzschalters). Wenn Sie möchten, dass die Software die Bereitstellung automatisch auf den letzten abgeschlossenen Bereitstellungsstatus zurücksetzt, wenn der Bereitstellungs-Schutzschalter die Bereitstellung auf einen fehlgeschlagenen Status setzt, wählen Sie **Rollback bei Fehler** aus. 1. Um eine Bereitstellung auf der Grundlage von Anwendungsmetriken zu beenden, wählen Sie ** CloudWatch Alarm (en) verwenden** aus. Wählen Sie dann unter **CloudWatch Alarmname** die Alarme aus. Um einen neuen Alarm zu erstellen, gehen Sie zur CloudWatch Konsole. Damit die Software die Bereitstellung automatisch auf den Status der letzten abgeschlossenen Bereitstellung zurücksetzt, wenn ein CloudWatch Alarm die Bereitstellung in einen fehlgeschlagenen Zustand versetzt, wählen Sie **Rollback bei Fehlern** aus. 1. (Optional) Um Ihren Service mit Service Connect zu verbinden, erweitern Sie **Service Connect** und geben Sie dann Folgendes an: 1. Wählen Sie **Service Connect einschalten** aus. 1. Geben Sie unter **Service Connect configuration** (Service-Connect-Konfiguration) den Client-Modus an. + Wenn Ihr Service eine Netzwerk-Client-Anwendung ausführt, die nur eine Verbindung zu anderen Services im Namespace herstellen muss, wählen Sie **Nur Client-Seite** aus. + Wenn Ihr Service eine Netzwerk- oder Webservice-Anwendung ausführt und Endpunkte für diesen Service bereitstellen muss und eine Verbindung zu anderen Services im Namespace herstellt, wählen Sie **Client and server** (Client und Server) aus. 1. Um einen Namespace zu verwenden, der nicht der Standard-Cluster-Namespace ist, wählen Sie für **Namespace** den Service-Namespace aus. Dies kann ein Namespace sein, der separat in demselben AWS-Region in Ihrer AWS-Konto oder einem Namespace in derselben Region erstellt wurde und der mithilfe AWS Resource Access Manager von () mit Ihrem Konto geteilt wird.AWS RAM*Weitere Informationen zur gemeinsamen Nutzung von AWS Cloud Map Namespaces finden Sie unter [Kontenübergreifende gemeinsame Nutzung von AWS Cloud Map Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) im Entwicklerhandbuch.AWS Cloud Map * 1. (Optional) Konfigurieren Sie Test-Traffic-Header-Regeln für lineare Bereitstellungen. Geben Sie unter **Test-Datenverkehrs-Routing** Folgendes an: 1. Wählen Sie **Header-Regeln für Test-Datenverkehr aktivieren** aus, um während des Tests bestimmte Anfragen an die grüne Service-Revision weiterzuleiten. 1. Konfigurieren Sie für **Regeln für den Header-Abgleich** die Kriterien für das Routing von Test-Datenverkehr: + **Header-Name**: Geben Sie den Namen des HTTP-Headers ein, dem der Abgleich entsprechen soll (z. B. `X-Test-Version` oder `User-Agent`). + **Übereinstimmungstyp**: Wählen Sie die Kriterien für den Abgleich aus: + **Exakte Übereinstimmung**: Leitet Anfragen weiter, bei denen der Header-Wert genau dem angegebenen Wert entspricht + **Header vorhanden**: Leitet Anfragen weiter, die den angegebenen Header enthalten, unabhängig vom Wert + **Musterübereinstimmung**: Leitet Anfragen weiter, bei denen der Header-Wert einem bestimmten Muster entspricht + **Header-Wert** (wenn „Exakte Übereinstimmung“ oder „Musterübereinstimmung“ verwendet wird): Geben Sie den Wert oder das Muster ein, mit dem abgeglichen werden soll. Sie können mehrere Header-Abgleichsregeln hinzufügen, um eine komplexe Routing-Logik zu erstellen. Anfragen, die einer der konfigurierten Regeln entsprechen, werden zum Testen an die grüne Service-Revision weitergeleitet. 1. Wählen Sie **Header-Regel hinzufügen**, um zusätzliche Bedingungen für den Header-Abgleich zu konfigurieren. **Anmerkung** Mithilfe von Header-Regeln für den Test-Datenverkehr können Sie neue Funktionen mit kontrolliertem Datenverkehr validieren, bevor Sie die vollständige Bereitstellung abschließen. Auf diese Weise können Sie die grüne Service-Revision mit spezifischen Anfragen (z. B. von internen Testtools oder Beta-Benutzern) testen und gleichzeitig den normalen Datenfluss zur blauen Service-Revision aufrechterhalten. 1. (Optional) Geben Sie eine Protokollkonfiguration an. Wählen Sie **Protokollsammlung verwenden** aus. Die Standardoption sendet CloudWatch Container-Protokolle an Logs. Die anderen Protokolltreiberoptionen werden mit konfiguriert AWS FireLens. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md). Im Folgenden wird jedes Container-Protokollziel ausführlicher beschrieben. + **Amazon CloudWatch** — Konfigurieren Sie die Aufgabe, um Container-Logs an CloudWatch Logs zu senden. Es werden die standardmäßigen Protokolltreiberoptionen bereitgestellt, mit denen in Ihrem Namen eine CloudWatch Protokollgruppe erstellt wird. Um einen anderen Protokollgruppen-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Data Firehose** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Firehose gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch die Protokolle an einen Bereitstellungsdatenstrom von Firehose gesendet werden. Um einen anderen Namen für den Bereitstellungsdatenstrom anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Kinesis Data Streams** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Kinesis Data Streams gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch Protokolle an einen Datenstrom von Kinesis Data Streams gesendet werden. Um einen anderen Datenstrom-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon OpenSearch Service** — Konfigurieren Sie die Aufgabe, um Container-Logs an eine OpenSearch Service-Domain zu senden. Die Optionen für den Protokolltreiber müssen bereitgestellt werden. + **Amazon S3** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an einen Amazon-S3-Bucket gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, Sie müssen jedoch einen gültigen Amazon-S3-Bucket-Namen angeben. 1. (Optional) Konfigurieren Sie den **Lastenausgleich** für die lineare Bereitstellung. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. (Optional) Um Ihren Service und Ihre Aufgaben besser identifizieren zu können, erweitern Sie den Bereich **Tags** (Tags) und konfigurieren Sie dann Ihre Tags. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clusternamen und den Aufgabendefinitions-Tags versieht, wählen Sie **Amazon ECS Managed Tags einschalten** und dann für **Tags verbreiten von** die Option **Aufgabendefinitionen**. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clustername und die Service-Tags versieht, wählen Sie **Amazon ECS Managed Tags** einschalten und dann für **Tags verbreiten von** die Option **Service**. Hinzufügen oder Entfernen eines Tag. + [Ein Tag hinzufügen] Wählen Sie **Add tag** (Tag hinzufügen) und führen Sie dann das Folgende aus: + Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein. + Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein. + [Tag entfernen] Wählen Sie neben dem Tag die Option **Remove tag (Tag löschen)** aus. 1. Wählen Sie **Erstellen** aus. ------ #### [ AWS CLI ] 1. Erstellen Sie eine Datei mit dem Namen `linear-service-definition.json` und dem folgenden Inhalt. Ersetzen Sie die durch Ihre *user-input* Werte. ``` { "serviceName": "myLinearService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "LINEAR", "maximumPercent": 200, "minimumHealthyPercent": 100, "linearConfiguration": { "stepPercentage": 10.0, "stepBakeTimeInMinutes":6 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Führen Sie `create-service`. ``` aws ecs create-service --cli-input-json file://linear-service-definition.json ``` ------ ## Nächste Schritte + Aktualisieren Sie den Service, um die Bereitstellung zu starten. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). + Überwachen Sie den Bereitstellungsprozess, um sicherzustellen, dass er dem linearen Muster folgt: + Die grüne Service-Revision wurde erstellt und hochskaliert + Der Verkehr wird schrittweise in den angegebenen Intervallen verlagert + Jedes Inkrement wartet vor der nächsten Schicht auf das angegebene Intervall + Nachdem der gesamte Verkehr verlagert wurde, beginnt die Backzeit + Nach Ablauf der Bake-Zeit wird die blaue Revision beendet # Canary-Bereitstellungen von Amazon ECS Bereitstellungen auf Canary leiten zunächst einen kleinen Prozentsatz des Datenverkehrs für erste Tests an die neue Version weiter und verlagern dann den gesamten verbleibenden Datenverkehr auf einmal, nachdem die kanarische Phase erfolgreich abgeschlossen wurde. Mit den kanarischen Bereitstellungen von Amazon ECS können Sie neue Service-Revisionen mit echtem Benutzerverkehr validieren und gleichzeitig das Risiko minimieren. Dieser Ansatz bietet eine kontrollierte Methode zur Implementierung von Änderungen mit der Möglichkeit, die Leistung zu überwachen und bei erkannten Problemen schnell ein Rollback durchzuführen. ## Ressourcen, die für eine Bereitstellung auf Canary erforderlich sind Die folgenden Ressourcen sind Teil der Bereitstellung von Amazon ECS Canary: + Verkehrsverlagerung — Der Prozess, den Amazon ECS verwendet, um den Produktionsverkehr zu verlagern. Bei kanarischen Amazon ECS-Bereitstellungen wird der Datenverkehr in zwei Phasen verlagert: zuerst auf den kanarischen Prozentsatz, dann bis die Bereitstellung abgeschlossen ist. + Canary-Prozentsatz — Der Prozentsatz des Datenverkehrs, der während des Testzeitraums an die neue Version weitergeleitet wurde. + Canary-Bake-Zeit — Die Dauer, für die die Canary-Version überwacht werden muss, bevor mit der vollständigen Bereitstellung fortgefahren wird. + 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. + 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: + Ressourcennutzung: Bei Bereitstellungen auf Canary werden während des Testzeitraums sowohl originale als auch Canary-Tasksets gleichzeitig ausgeführt, wodurch der Ressourcenverbrauch steigt. + Verkehrsaufkommen: Stellen Sie sicher, dass der Prozentsatz der Canary-Benutzer ausreichend Traffic generiert, um eine aussagekräftige Validierung der neuen Version zu ermöglichen. + Komplexität überwachen: Bei Bereitstellungen auf Canary müssen die Metriken zweier verschiedener Versionen gleichzeitig überwacht und verglichen werden. + Rollback-Geschwindigkeit: Bereitstellungen auf Canary ermöglichen ein schnelles Rollback, indem der Datenverkehr wieder auf den ursprünglichen Aufgabenbereich verlagert wird. + Risikominderung: Bereitstellungen auf Canary bieten eine hervorragende Risikominderung, indem sie das Risiko auf einen kleinen Prozentsatz von Benutzern beschränken. + Bereitstellungsdauer: Die Bereitstellungen auf den Kanarischen Inseln beinhalten Evaluierungszeiträume, die die Gesamtbereitstellungszeit verlängern, aber auch Möglichkeiten zur Validierung bieten. ## So funktionieren Bereitstellungen auf Canary Der Bereitstellungsprozess von Amazon ECS Canary 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. 1. 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. 1. 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. 1. Phase der Verkehrsverlagerung auf Canary: Während der Canary-Phase wird der konfigurierte Prozentsatz des Traffics auf die neue Green Service-Version umgestellt, gefolgt von einer Umstellung von 100,0% des Traffics auf die Green Service-Version 1. Ü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. 1. Abschlussphase: Schließen Sie die Bereitstellung ab, indem Sie die blaue Umgebung beenden. Die Phase der Verkehrsverlagerung auf Canary 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. + Verkehrsverlagerung auf die Kanarischen Inseln — Dies ist eine zweistufige Strategie zur Verkehrsverlagerung. + Schritt 1:10,0% auf Grün, 90,0% auf Blau + Schritt 2:100,0% zu Grün, 0,0% zu Blau + Canary Bake Time — Wartet nach der Umstellung auf Canary Traffic auf eine konfigurierbare Dauer (Canary Bake Time), damit die Leistung der neuen Version bei der erhöhten Verkehrslast überwacht und validiert werden kann. + 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. Lambda-Funktionen oder Lifecycle-Hooks, die für PRODUCTION\$1TRAFFIC\$1SHIFT konfiguriert sind, werden bei jedem Produktions-Traffic-Shift-Schritt aufgerufen. ### Lebenszyklusphasen der Bereitstellung Der Bereitstellungsprozess bei Canary durchläuft verschiedene Lebenszyklusphasen, von denen jede spezifische Verantwortlichkeiten und Validierungsprüfpunkte umfasst. 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\$1TRAFFIC\$1SHIFT 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** | Lebenszyklusphasen | Description | Unterstützung für Lebenszyklus-Hooks | | --- | --- | --- | | RECONCILE\$1SERVICE | Diese Phase tritt nur ein, wenn Sie eine neue Servicebereitstellung mit mehr als einer Service-Revision im Status ACTIVE starten. | Ja | | PRE\$1SCALE\$1UP | Die grüne Service-Revision wurde nicht gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja | | SCALE\$1UP | 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\$1SCALE\$1UP | Die grüne Service-Revision wurde gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja | | TEST\$1TRAFFIC\$1SHIFT | 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\$1TEST\$1TRAFFIC\$1SHIFT | Die Verlagerung des Test-Datenverkehrs ist abgeschlossen. Die grüne Service-Revision wickelt 100 % des Test-Datenverkehrs ab. | Ja | | PRODUCTION\$1TRAFFIC\$1SHIFT | Der Canary-Produktionsdatenverkehr wird an die grüne Version weitergeleitet und der Lifecycle-Hook wird mit einem Timeout von 24 Stunden aufgerufen. Im zweiten Schritt wird der verbleibende Produktionsverkehr auf Green Revision umgestellt. | Ja | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Die Verlagerung des Produktionsdatenverkehrs ist abgeschlossen. | Ja | | BAKE\$1TIME | Die Dauer, in der sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden. | Nein | | CLEAN\$1UP | 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 | ### Konfigurationsparameter Für Bereitstellungen auf Canary sind die folgenden Konfigurationsparameter erforderlich: + Kanarischer Prozentsatz — Der Prozentsatz des Datenverkehrs, der während der kanarischen Phase an die neue Version des Dienstes weitergeleitet wurde. Dies ermöglicht Tests mit einer kontrollierten Teilmenge des Produktionsdatenverkehrs. + Canary Bake Time — Die Wartezeit während der Canary-Phase, bevor der restliche Traffic auf die neue Service-Version umgestellt wird. Dies gibt Zeit, um die neue Version zu überwachen und zu validieren. ### Verwaltung des Datenverkehrs Bei Bereitstellungen auf Canary werden Load Balancer-Zielgruppen verwendet, um die Verteilung des Datenverkehrs zu verwalten: + Ursprüngliche Zielgruppe — Enthält Aufgaben aus der aktuellen stabilen Version und erhält den Großteil des Datenverkehrs. + Kanarische Zielgruppe — Enthält Aufgaben aus der neuen Version und erhält einen kleinen Teil des Traffics zu Testzwecken. + Gewichtetes Routing — Der Load Balancer verwendet gewichtete Routing-Regeln, um den Verkehr auf der Grundlage des konfigurierten Canary-Prozentsatzes auf die Zielgruppen zu verteilen. ### Überwachung und Validierung Effektive Bereitstellungen auf Canary-Computern sind auf eine umfassende Überwachung angewiesen: + Zustandsprüfungen — Beide Aufgabensätze müssen Integritätsprüfungen bestehen, bevor sie Traffic empfangen. + Vergleich von Kennzahlen — Vergleichen Sie wichtige Leistungsindikatoren zwischen der Original- und der Canary-Version, wie Reaktionszeit, Fehlerrate und Durchsatz. + Automatisches Rollback — Konfigurieren Sie CloudWatch Alarme so, dass automatisch ein Rollback ausgelöst wird, wenn die Canary-Version eine verminderte Leistung aufweist. + Manuelle Validierung — Nutzen Sie den Testzeitraum, um Protokolle, Kennzahlen und Benutzerfeedback manuell zu überprüfen, bevor Sie fortfahren. ### Bewährte Methoden für Bereitstellungen auf Canary Folgen Sie diesen bewährten Methoden, um erfolgreiche Bereitstellungen mit Diensten auf Canary sicherzustellen. #### Wählen Sie die entsprechenden Prozentsätze für den Traffic Berücksichtigen Sie bei der Auswahl der prozentualen Verkehrszahlen auf Canary die folgenden Faktoren: + Fangen Sie klein an — Beginnen Sie mit 5-10% des Traffics, um die Auswirkungen zu minimieren, falls Probleme auftreten. + Berücksichtigen Sie die Wichtigkeit von Anwendungen — Verwenden Sie kleinere Prozentsätze für unternehmenskritische Anwendungen und höhere Prozentsätze für weniger kritische Dienste. + Verkehrsaufkommen berücksichtigen — Stellen Sie sicher, dass der kanarische Prozentsatz ausreichend Traffic für eine aussagekräftige Validierung generiert. #### Legen Sie angemessene Bewertungszeiträume fest Konfigurieren Sie Evaluierungszeiträume auf der Grundlage der folgenden Überlegungen: + Genügend Zeit einplanen — Legen Sie Testzeiträume fest, die lang genug sind, um aussagekräftige Leistungsdaten zu erfassen, typischerweise 10—30 Minuten. + Verkehrsmuster berücksichtigen — Berücksichtigen Sie die Verkehrsmuster Ihrer Anwendung und die Spitzennutzungszeiten. + Balance zwischen Geschwindigkeit und Sicherheit — Längere Evaluierungszeiträume liefern mehr Daten, verlangsamen aber die Bereitstellungsgeschwindigkeit. #### Implementieren Sie eine umfassende Überwachung Richten Sie eine Überwachung ein, um die Leistung der Canary-Implementierung zu verfolgen: + Wichtige Kennzahlen — Überwachen Sie die Reaktionszeit, die Fehlerrate, den Durchsatz und die Ressourcenauslastung für beide Tasksets. + Alarmbasiertes Rollback — Konfigurieren Sie CloudWatch Alarme so, dass sie automatisch einen Rollback auslösen, wenn Metriken Schwellenwerte überschreiten. + Vergleichende Analyse — Richten Sie Dashboards ein, um Metriken zwischen Original- und Kanarienversionen zu vergleichen. side-by-side + Geschäftskennzahlen — Fügen Sie neben technischen Kennzahlen auch geschäftsspezifische Kennzahlen wie Konversionsraten oder Nutzerinteraktion hinzu. #### Planen Sie Rollback-Strategien Bereiten Sie sich mit diesen Strategien auf mögliche Rollback-Szenarien vor: + Automatisiertes Rollback — Konfigurieren Sie automatische Rollback-Trigger auf der Grundlage von Integritätsprüfungen und Leistungskennzahlen. + Manuelle Rollback-Verfahren — Dokumentieren Sie klare Verfahren für manuelles Rollback, wenn automatische Trigger nicht alle Probleme erfassen. + Rollback-Tests — Testen Sie regelmäßig Rollback-Verfahren, um sicherzustellen, dass sie bei Bedarf korrekt funktionieren. #### Vor der Bereitstellung gründlich validieren Sorgen Sie für eine gründliche Validierung, bevor Sie mit den Bereitstellungen auf Canary fortfahren: + Tests vor der Implementierung — Testen Sie die Änderungen in den Staging-Umgebungen vor der Bereitstellung von Canary gründlich. + Konfiguration der Integritätsprüfung — Stellen Sie sicher, dass Integritätsprüfungen die Anwendungsbereitschaft und Funktionalität genau widerspiegeln. + Überprüfung der Abhängigkeiten — Stellen Sie sicher, dass neue Versionen mit Downstream- und Upstream-Diensten kompatibel sind. + Datenkonsistenz — Stellen Sie sicher, dass Datenbankschemaänderungen und Datenmigrationen abwärtskompatibel sind. #### Koordinieren Sie die Beteiligung des Teams Sorgen Sie für eine effektive Teamkoordination bei Einsätzen auf Canary-Geräten: + Bereitstellungsfenster — Planen Sie die Bereitstellung von Canary-Programmen während der Geschäftszeiten, wenn die Teams für die Überwachung und Reaktion zur Verfügung stehen. + Kommunikationskanäle — Richten Sie klare Kommunikationskanäle für den Bereitstellungsstatus und die Eskalation von Problemen ein. + Rollenzuweisungen — Definieren Sie Rollen und Zuständigkeiten für die Überwachung, Entscheidungsfindung und Rollback-Ausführung. # Erforderliche Ressourcen für Amazon ECS Canary-Bereitstellungen Um eine Canary-Bereitstellung mit verwalteter Verkehrsverlagerung zu verwenden, muss Ihr Service eine der folgenden Funktionen verwenden: + Elastic Load Balancing + Service Connect Die folgende Liste bietet einen allgemeinen Überblick darüber, was Sie für Amazon ECS Canary-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 `canary` in der Servicedefinition. + Optional können Sie zusätzliche Parameter konfigurieren, z. B.: + Bake-Zeit für die neue Bereitstellung + Der Prozentsatz des Datenverkehrs, der während der Canary-Phase an die neue Service-Version weitergeleitet werden soll. + Die Wartezeit während der kanarischen Phase, bevor der verbleibende Verkehr auf die neue Serviceversion umgestellt wird. + CloudWatch Alarme für automatisches Rollback + Hooks für den Bereitstellungslebenszyklus (dies sind Lambda-Funktionen, die in bestimmten Bereitstellungsphasen ausgeführt werden) ## Best Practices Folgen Sie diesen bewährten Methoden für erfolgreiche Amazon ECS Cleanary-Bereitstellungen: + **Stellen Sie sicher, dass Ihre Anwendung beide 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.** + 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. + Beginnen Sie mit kleinen prozentualen Werten (5-10%), um die Auswirkungen bei auftretenden Problemen zu minimieren. + Legen Sie angemessene Bewertungszeiträume fest, die ausreichend Zeit für die Erfassung aussagekräftiger Leistungsdaten bieten. + Implementieren Sie eine umfassende Überwachung mit CloudWatch Alarmen für automatische Rollback-Trigger. + Konfigurieren Sie Integritätsprüfungen, die die Bereitschaft und Funktionalität Ihrer Anwendung genau widerspiegeln. + Überwachen Sie bei der Evaluierung sowohl technische Kennzahlen (Reaktionszeit, Fehlerquote) als auch Geschäftskennzahlen. + Stellen Sie sicher, dass Ihre Anwendung die Aufteilung des Datenverkehrs ohne Sitzungs- oder Statusprobleme bewältigen kann. + Planen Sie Rollback-Verfahren und testen Sie sie regelmäßig, um sicherzustellen, dass sie bei Bedarf funktionieren. + Planen Sie die Implementierung von Canary während der Geschäftszeiten, damit die Teams alles überwachen und reagieren können. + Überprüfen Sie vor der Bereitstellung von Canary die Änderungen in den Staging-Umgebungen gründlich. + Dokumentieren Sie klare Verfahren für manuelle Eingriffe und Rollback-Entscheidungen. # Erstellen einer Amazon ECS-Canary-Bereitstellung Durch die Verwendung von Amazon ECS Canary-Bereitstellungen können Sie einen kleinen Teil des Datenverkehrs auf Ihre neue Service-Revision (die „Canary“) verlagern. Überprüfen Sie die Bereitstellung und verlagern Sie dann den verbleibenden Datenverkehr nach einem bestimmten Intervall auf einmal. Dieser Ansatz ermöglicht es Ihnen, neue Funktionen vor der vollständigen Bereitstellung mit minimalem Risiko zu testen. ## Voraussetzungen Führen Sie die folgenden Schritte durch, bevor Sie eine Bereitstellung auf Canary starten. 1. Konfigurieren Sie die entsprechenden Berechtigungen. + Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Weitere Informationen zu Lambda-Berechtigungen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). 1. Für Bereitstellungen von Amazon ECS Canary muss Ihr Service eine der folgenden Funktionen verwenden: 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). ## Verfahren Sie können die Konsole oder die verwenden AWS CLI , um einen Amazon ECS Canary-Bereitstellungsservice zu erstellen. ------ #### [ Console ] 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Bestimmen Sie die Ressource, von der aus Sie den Service starten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-canary-service.html) Die Seite **Service erstellen** wird angezeigt. 1. Führen Sie unter **Service-Details** die folgenden Schritte aus: 1. Wählen Sie für **Aufgabendefinitionsfamilie** die zu verwendende Aufgabendefinition aus. Geben Sie dann unter **Revision der Aufgabendefinition** die zu verwendende Revision ein. 1. Wählen Sie für **Service name** (Servicename) einen Namen für Ihren Service aus. 1. Um den Service in einem vorhandenen Cluster auszuführen, wählen Sie unter **Vorhandener Cluster** den Cluster aus. Um den Service in einem neuen Cluster auszuführen, wählen Sie **Cluster erstellen** aus 1. Wählen Sie aus, wie Ihre Aufgaben auf Ihre Cluster-Infrastruktur verteilt werden. Wählen Sie unter **Datenverarbeitungskonfiguration** Ihre Option aus. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. Führen Sie im Abschnitt **Bereitstellungskonfiguration** Folgendes aus: 1. Wählen Sie für **Service-Typ** die Option **Replikat** aus. 1. Geben Sie für **Desired tasks** (Gewünschte Aufgaben) die Anzahl der Aufgaben an, die im Service gestartet und aufrecht erhalten werden sollen. 1. Damit Amazon ECS die Verteilung der Aufgaben auf die Availability Zones überwacht und sie bei einem Ungleichgewicht neu verteilt, wählen Sie unter **Service-Neuausgleich der Availability Zone** die Option **Service-Neuausgleich der Availability Zone** aus. 1. Geben Sie für **Wartefrist der Zustandsprüfung** die Zeitspanne (in Sekunden) ein, die der Service Scheduler fehlerhafte Elastic-Load-Balancing-, VPC-Lattice- und Container-Zustandsprüfungen ignoriert, nachdem eine Aufgabe zum ersten Mal gestartet wurde. Wenn Sie keine Übergangsfrist für die Zustandsprüfung angeben, wird der Standardwert 0 verwendet. 1. Konfigurieren Sie unter **Bereitstellungskonfiguration** die Bereitstellungseinstellungen von Canary: 1. Wählen Sie als **Bereitstellungsstrategie** **Canary** aus. 1. Geben Sie für **Canary-Prozentsatz** den Prozentsatz des Traffics ein, der in der ersten Phase auf die Green Service-Version umgestellt werden soll (z. B. 10% für den anfänglichen Canary-Verkehr). 1. Geben Sie für **Canary Bake Time** die Wartezeit in Minuten ein, bis der verbleibende Traffic auf die Green-Service-Version umgestellt wird. 1. Geben Sie unter **Backzeit** die Anzahl der Minuten ein, für die sowohl die blaue als auch die grüne Version nach der letzten Verkehrsverlagerung gleichzeitig ausgeführt werden, bevor die blaue Version beendet wird. 1. (Optional) Führen Sie Lambda-Funktionen in bestimmten Phasen der Bereitstellung aus. Wählen Sie unter **Bereitstellungs-Lebenszyklus-Hooks** die Phasen aus, in denen die Lebenszyklus-Hooks ausgeführt werden sollen. So fügen Sie einen Lebenszyklus-Hook hinzu: 1. Wählen Sie **Hinzufügen** aus. 1. Geben Sie für **Lambda-Funktion** den Funktionsnamen oder ARN ein. 1. Wählen Sie für **Rolle** die IAM-Rolle aus, die berechtigt ist, die Lambda-Funktion aufzurufen. 1. Wählen Sie für **Lebenszyklusphasen** die Phasen aus, in denen die Lambda-Funktion ausgeführt werden soll. 1. Um zu konfigurieren, wie Amazon ECS Bereitstellungsfehler erkennt und behandelt, erweitern Sie **Deployment failure detection** (Erkennung von Bereitstellungsfehlern) und wählen Sie dann Ihre Optionen. 1. Um eine Bereitstellung anzuhalten, wenn die Aufgaben nicht gestartet werden können, wählen Sie **Use the Amazon ECS deployment circuit breaker** (Verwenden des Amazon-ECS-Bereitstellungsschutzschalters). Wenn Sie möchten, dass die Software die Bereitstellung automatisch auf den letzten abgeschlossenen Bereitstellungsstatus zurücksetzt, wenn der Bereitstellungs-Schutzschalter die Bereitstellung auf einen fehlgeschlagenen Status setzt, wählen Sie **Rollback bei Fehler** aus. 1. Um eine Bereitstellung auf der Grundlage von Anwendungsmetriken zu beenden, wählen Sie ** CloudWatch Alarm (en) verwenden** aus. Wählen Sie dann unter **CloudWatch Alarmname** die Alarme aus. Um einen neuen Alarm zu erstellen, gehen Sie zur CloudWatch Konsole. Damit die Software die Bereitstellung automatisch auf den Status der letzten abgeschlossenen Bereitstellung zurücksetzt, wenn ein CloudWatch Alarm die Bereitstellung in einen fehlgeschlagenen Zustand versetzt, wählen Sie **Rollback bei Fehlern** aus. 1. (Optional) Um Ihren Service mit Service Connect zu verbinden, erweitern Sie **Service Connect** und geben Sie dann Folgendes an: 1. Wählen Sie **Service Connect einschalten** aus. 1. Geben Sie unter **Service Connect configuration** (Service-Connect-Konfiguration) den Client-Modus an. + Wenn Ihr Service eine Netzwerk-Client-Anwendung ausführt, die nur eine Verbindung zu anderen Services im Namespace herstellen muss, wählen Sie **Nur Client-Seite** aus. + Wenn Ihr Service eine Netzwerk- oder Webservice-Anwendung ausführt und Endpunkte für diesen Service bereitstellen muss und eine Verbindung zu anderen Services im Namespace herstellt, wählen Sie **Client and server** (Client und Server) aus. 1. Um einen Namespace zu verwenden, der nicht der Standard-Cluster-Namespace ist, wählen Sie für **Namespace** den Service-Namespace aus. Dies kann ein Namespace sein, der separat in demselben AWS-Region in Ihrer AWS-Konto oder einem Namespace in derselben Region erstellt wurde und der mithilfe AWS Resource Access Manager von () mit Ihrem Konto geteilt wird.AWS RAM*Weitere Informationen zur gemeinsamen Nutzung von AWS Cloud Map Namespaces finden Sie unter [Kontenübergreifende gemeinsame Nutzung von AWS Cloud Map Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) im Entwicklerhandbuch.AWS Cloud Map * 1. (Optional) Konfigurieren Sie Test-Traffic-Header-Regeln für Canary-Bereitstellungen. Geben Sie unter **Test-Datenverkehrs-Routing** Folgendes an: 1. Wählen Sie **Header-Regeln für Test-Datenverkehr aktivieren** aus, um während des Tests bestimmte Anfragen an die grüne Service-Revision weiterzuleiten. 1. Konfigurieren Sie für **Regeln für den Header-Abgleich** die Kriterien für das Routing von Test-Datenverkehr: + **Header-Name**: Geben Sie den Namen des HTTP-Headers ein, dem der Abgleich entsprechen soll (z. B. `X-Test-Version` oder `User-Agent`). + **Übereinstimmungstyp**: Wählen Sie die Kriterien für den Abgleich aus: + **Exakte Übereinstimmung**: Leitet Anfragen weiter, bei denen der Header-Wert genau dem angegebenen Wert entspricht + **Header vorhanden**: Leitet Anfragen weiter, die den angegebenen Header enthalten, unabhängig vom Wert + **Musterübereinstimmung**: Leitet Anfragen weiter, bei denen der Header-Wert einem bestimmten Muster entspricht + **Header-Wert** (wenn „Exakte Übereinstimmung“ oder „Musterübereinstimmung“ verwendet wird): Geben Sie den Wert oder das Muster ein, mit dem abgeglichen werden soll. Sie können mehrere Header-Abgleichsregeln hinzufügen, um eine komplexe Routing-Logik zu erstellen. Anfragen, die einer der konfigurierten Regeln entsprechen, werden zum Testen an die grüne Service-Revision weitergeleitet. 1. Wählen Sie **Header-Regel hinzufügen**, um zusätzliche Bedingungen für den Header-Abgleich zu konfigurieren. **Anmerkung** Mithilfe von Header-Regeln für den Test-Datenverkehr können Sie neue Funktionen mit kontrolliertem Datenverkehr validieren, bevor Sie die vollständige Bereitstellung abschließen. Auf diese Weise können Sie die grüne Service-Revision mit spezifischen Anfragen (z. B. von internen Testtools oder Beta-Benutzern) testen und gleichzeitig den normalen Datenfluss zur blauen Service-Revision aufrechterhalten. 1. (Optional) Geben Sie eine Protokollkonfiguration an. Wählen Sie **Protokollsammlung verwenden** aus. Die Standardoption sendet Container-Logs an CloudWatch Logs. Die anderen Protokolltreiberoptionen werden mit konfiguriert AWS FireLens. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md). Im Folgenden wird jedes Container-Protokollziel ausführlicher beschrieben. + **Amazon CloudWatch** — Konfigurieren Sie die Aufgabe, um Container-Logs an CloudWatch Logs zu senden. Es werden die standardmäßigen Protokolltreiberoptionen bereitgestellt, mit denen in Ihrem Namen eine CloudWatch Protokollgruppe erstellt wird. Um einen anderen Protokollgruppen-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Data Firehose** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Firehose gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch die Protokolle an einen Bereitstellungsdatenstrom von Firehose gesendet werden. Um einen anderen Namen für den Bereitstellungsdatenstrom anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon Kinesis Data Streams** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an Kinesis Data Streams gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch Protokolle an einen Datenstrom von Kinesis Data Streams gesendet werden. Um einen anderen Datenstrom-Namen anzugeben, ändern Sie die Werte der Treiberoption. + **Amazon OpenSearch Service** — Konfigurieren Sie die Aufgabe, um Container-Logs an eine OpenSearch Service-Domain zu senden. Die Optionen für den Protokolltreiber müssen bereitgestellt werden. + **Amazon S3** – Konfigurieren Sie die Aufgabe, dass Container-Protokolle an einen Amazon-S3-Bucket gesendet werden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, Sie müssen jedoch einen gültigen Amazon-S3-Bucket-Namen angeben. 1. (Optional) Konfigurieren Sie den **Lastenausgleich** für die Bereitstellung auf Canary. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. (Optional) Um Ihren Service und Ihre Aufgaben besser identifizieren zu können, erweitern Sie den Bereich **Tags** (Tags) und konfigurieren Sie dann Ihre Tags. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clusternamen und den Aufgabendefinitions-Tags versieht, wählen Sie **Amazon ECS Managed Tags einschalten** und dann für **Tags verbreiten von** die Option **Aufgabendefinitionen**. Damit Amazon ECS alle neu gestarteten Aufgaben automatisch mit Tags für den Clustername und die Service-Tags versieht, wählen Sie **Amazon ECS Managed Tags** einschalten und dann für **Tags verbreiten von** die Option **Service**. Hinzufügen oder Entfernen eines Tag. + [Ein Tag hinzufügen] Wählen Sie **Add tag** (Tag hinzufügen) und führen Sie dann das Folgende aus: + Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein. + Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein. + [Tag entfernen] Wählen Sie neben dem Tag die Option **Remove tag (Tag löschen)** aus. 1. Wählen Sie **Erstellen** aus. ------ #### [ AWS CLI ] 1. Erstellen Sie eine Datei mit dem Namen `canary-service-definition.json` und dem folgenden Inhalt. Ersetzen Sie die durch Ihre *user-input* Werte. ``` { "serviceName": "myCanaryService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "CANARY", "maximumPercent": 200, "minimumHealthyPercent": 100, "canaryConfiguration" : { "canaryPercent" : 5.0, "canaryBakeTime" : 10 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Führen Sie `create-service`. ``` aws ecs create-service --cli-input-json file://canary-service-definition.json ``` ------ ## Nächste Schritte Gehen Sie nach der Konfiguration Ihrer Canary-Bereitstellung wie folgt vor: + Aktualisieren Sie den Service, um die Bereitstellung zu starten. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). + Überwachen Sie den Bereitstellungsprozess, um sicherzustellen, dass er dem Canary-Muster folgt: + Die grüne Service-Revision wurde erstellt und hochskaliert + Ein kleiner Teil des Traffics (Canary) wird auf die grüne Version umgestellt + Das System wartet auf das angegebene kanarische Intervall + Der restliche Verkehr wird auf einmal auf die grüne Version umgestellt + Nach Ablauf der Bake-Zeit wird die blaue Revision beendet ## Terminologie der Bereitstellung Die folgenden Begriffe werden in der gesamten Amazon ECS-Bereitstellungsdokumentation verwendet: Bereitstellung in Blaugrün Eine Bereitstellungsstrategie, bei der neben der vorhandenen Umgebung (blau) eine neue Umgebung (grün) erstellt wird und der Datenverkehr nach der Validierung von blau auf grün umgestellt wird. Bereitstellung auf Canary Eine Bereitstellungsstrategie, bei der ein kleiner Teil des Datenverkehrs an eine neue Version weitergeleitet wird, während der Großteil zur Validierung auf der stabilen Version bleibt. Lineare Bereitstellung Eine Bereitstellungsstrategie, bei der der Datenverkehr im Laufe der Zeit schrittweise von der alten Version auf die neue Version verlagert wird. Fortlaufende Bereitstellung Eine Bereitstellungsstrategie, bei der Instanzen der alten Version nacheinander durch Instanzen der neuen Version ersetzt werden. Aufgabensatz Eine Sammlung von Aufgaben, die während einer Bereitstellung dieselbe Aufgabendefinition innerhalb eines Dienstes ausführen. Zielgruppe Eine logische Gruppierung von Zielen, die bei Bereitstellungen Datenverkehr von einem Load Balancer empfangen. Bereitstellungscontroller Die Methode, die verwendet wird, um neue Versionen Ihres Service, wie Amazon ECS CodeDeploy, oder externe Controller bereitzustellen. Rollback Der Vorgang, bei dem Sie zu einer früheren Version Ihrer Anwendung zurückkehren, wenn bei der Bereitstellung Probleme festgestellt werden. # Amazon-ECS-Services mithilfe eines Drittanbieter-Controllers bereitstellen Der *external* (externe) Bereitstellungstyp erlaubt Ihnen, einen beliebigen Bereitstellungscontroller eines Drittanbieters zu verwenden, um die volle Kontrolle über den Bereitstellungsprozess für einen Amazon-ECS-Service zu haben. Die Details für Ihren Service werden entweder mit den API-Aktionen der Serviceverwaltung (`CreateService`, `UpdateService` und `DeleteService`) oder den API-Aktionen der Aufgabensatzverwaltung (`CreateTaskSet`, `UpdateTaskSet`, `UpdateServicePrimaryTaskSet` und `DeleteTaskSet`) verwaltet. Jede API-Aktion verwaltet eine Teilmenge der Servicedefinitions-Parameter. Die `UpdateService`-API-Aktion aktualisiert die Parameter für die gewünschte Anzahl und die Übergangsfrist der Zustandsprüfung für einen Service. Wenn Rechenoption, Plattformversion, Load Balancer-Details, Netzwerkkonfiguration oder Aufgabendefinition aktualisiert werden müssen, müssen Sie einen neuen Aufgabesatz erstellen. Die `UpdateTaskSet`-API-Aktion aktualisiert nur den Scale-Parameter für einen Aufgabensatz. Die `UpdateServicePrimaryTaskSet`-API-Aktion ändert, welcher Aufgabensatz in einem Service als primärer Aufgabensatz fungiert. Wenn Sie die API-Aktion `DescribeServices` aufrufen, gibt sie alle für den primären Aufgabensatz angegebenen Felder zurück. Wenn der primäre Aufgabensatz eines Service aktualisiert wird, werden alle Parameterwerte des neuen primären Aufgabensatzes, die von denen des alten primären Aufgabensatzes in einem Service abweichen, beim Definieren des neuen primären Aufgabensatzes auf den neuen Wert aktualisiert. Wenn für einen Service kein primärer Aufgabensatz definiert ist, sind die Werte der Aufgabensatzfelder beim Beschreiben des Service null. ## Überlegungen zur externen Bereitstellung Beachten Sie Folgendes, wenn Sie den externen Bereitstellungstyp verwenden: + Die unterstützten Load Balancer-Typen sind entweder ein Application Load Balancer oder ein Network Load Balancer. + Die Fargate- oder `EXTERNAL`-Controller-Typen unterstützen die `DAEMON`-Planungsstrategie nicht. + AutoScaling Die Anwendungsintegration mit Amazon ECS unterstützt nur den Amazon ECS-Service als Ziel. Die unterstützte skalierbare Dimension für Amazon ECS ist `ecs:service:DesiredCount` – die Anzahl der Aufgaben eines Amazon-ECS-Service. Es gibt keine direkte Integration zwischen Anwendungs AutoScaling - und Amazon ECS-Aufgabensätzen. Amazon-ECS-Aufgabensätze berechnen die `ComputedDesiredCount` auf der Grundlage des Amazon-ECS-Service `DesiredCount`. ## Workflow für externe Bereitstellung Im Folgenden wird der grundlegende Workflow zur Verwaltung einer externen Bereitstellung in Amazon ECS dargestellt. **So verwalten Sie einen Amazon-ECS-Service mithilfe eines externen Bereitstellungs-Controllers** 1. Erstellen Sie einen Amazon-ECS-Service. Der einzige erforderliche Parameter ist der Servicename. Wenn Sie einen Service mit einem externen Bereitstellungs-Controller erstellen, können Sie die folgenden Parameter angeben. Alle anderen Service-Parameter werden bei der Erstellung eines Aufgabesatzes innerhalb des Service festlegt. `serviceName` Typ: Zeichenfolge Erforderlich: Ja Der Name Ihres Service. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Zahlen, Bindestriche und Unterstriche sind zulässig. Servicenamen in einem Cluster müssen eindeutig sein. Sie können jedoch ähnlich benannte Services in mehreren Clustern innerhalb einer Region oder in mehreren Regionen haben. `desiredCount` Die Anzahl der Instanziierungen der angegebenen Aufgabensatzdefinition, die innerhalb des Service platziert und ausgeführt werden sollen. `deploymentConfiguration` Optionale Bereitstellungsparameter zur Steuerung, wie viele Aufgaben während einer Bereitstellung ausgeführt werden, und zur Steuerung der Reihenfolge beim Starten oder Stoppen von Aufgaben. `tags` Typ: Array von -Objekten Erforderlich: Nein Die Metadaten, die Sie auf den Service anwenden, um die Kategorisierung und Organisation zu erleichtern. Jeder Tag (Markierung) besteht aus einem Schlüssel und einem optionalen Wert, beides können Sie bestimmen. Wenn ein Service gelöscht wird, werden auch die Tags gelöscht. Es können maximal 50 Tags auf den Service angewendet werden. Weitere Informationen finden Sie unter [Markieren von Amazon-ECS-Ressourcen](ecs-using-tags.md). Wenn Sie einen Service aktualisieren, löst dieser Parameter keine neue Servicebereitstellung aus. `key` Typ: Zeichenfolge Längenbeschränkungen: Minimale Länge beträgt 1 Zeichen. Maximale Länge beträgt 128 Zeichen. Erforderlich: Nein Ein Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Schlüssel ist eine allgemeine Bezeichnung, die wie eine Kategorie für spezifischere Tag-Werte fungiert. `value` Typ: Zeichenfolge Längenbeschränkungen: Minimale Länge von 0. Maximale Länge beträgt 256 Zeichen. Erforderlich: Nein Der optionale Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Wert fungiert als Deskriptor in einer Tag-Kategorie (Schlüssel). `enableECSManagedTags` Gibt an, ob von Amazon ECS Managed Tags für Aufgaben im Service verwendet werden sollen. Weitere Informationen finden Sie unter [Verwenden von Tags für die Fakturierung](ecs-using-tags.md#tag-resources-for-billing). `propagateTags` Typ: Zeichenfolge Zulässige Werte: `TASK_DEFINITION` \$1 `SERVICE` Erforderlich: Nein Gibt an, ob die Tags von der Aufgabendefinition oder dem Service in die Aufgaben in dem Service kopiert werden sollen. Wenn kein Wert angegeben wird, werden die Tags nicht kopiert. Tags können nur während der Serviceerstellung in die Aufgaben in dem Service kopiert werden. Wenn Sie Tags nach der Service- oder Aufgabenerstellung einer Aufgabe hinzufügen möchten, verwenden Sie die API-Aktion `TagResource`. Wenn Sie einen Service aktualisieren, löst dieser Parameter keine neue Servicebereitstellung aus. `schedulingStrategy` Die Einplanungsstrategie, die verwendet werden soll. Services mit einem externen Deployment-Controller unterstützen nur die Planungsstrategie `REPLICA`. `placementConstraints` Ein Array von Platzierungseinschränkungsobjekten, die für Aufgaben in Ihrem Service verwendet werden sollen. Sie können maximal zehn Einschränkungen pro Aufgabe festlegen (dieses Limit enthält Einschränkungen in der Aufgabendefinition und solche, die während der Laufzeit festgelegt werden). Wenn Sie Fargate verwenden, werden keine Platzierungsbeschränkungen für Aufgaben unterstützt. `placementStrategy` Die Platzierungsstrategieobjekte, die für Aufgaben in Ihrem Service verwendet werden sollen. Sie können maximal vier Strategieregeln pro Service festlegen. Im Folgenden finden Sie ein Beispiel für eine Servicedefinition, mit der ein Service über einen externen Bereitstellungs-Controller erstellt wird. ``` { "cluster": "", "serviceName": "", "desiredCount": 0, "role": "", "deploymentConfiguration": { "maximumPercent": 0, "minimumHealthyPercent": 0 }, "placementConstraints": [ { "type": "distinctInstance", "expression": "" } ], "placementStrategy": [ { "type": "binpack", "field": "" } ], "schedulingStrategy": "REPLICA", "deploymentController": { "type": "EXTERNAL" }, "tags": [ { "key": "", "value": "" } ], "enableECSManagedTags": true, "propagateTags": "TASK_DEFINITION" } ``` 1. Erstellen Sie einen anfänglichen Aufgabensatz. Der Aufgabesatz enthält die folgenden Details zu Ihrem Service: `taskDefinition` Die zu verwendende Aufgabendefinition für die Aufgaben im Aufgabensatz. `launchType` Typ: Zeichenfolge Zulässige Werte: `EC2` \$1 `FARGATE` \$1 `EXTERNAL` Erforderlich: Nein Der Starttyp, der für die Ausführung Ihres Service verwendet wird. Ist kein Starttyp angegeben, wird standardmäßig `capacityProviderStrategy` verwendet. Wenn Sie einen Service aktualisieren, löst dieser Parameter eine neue Servicebereitstellung aus. Wenn eine `launchType` angegeben ist, muss der `capacityProviderStrategy`-Parameter weggelassen werden. `platformVersion` Typ: Zeichenfolge Erforderlich: Nein Die Plattformversion, auf der Ihre Aufgaben im Service ausgeführt werden. Eine Plattformversion ist nur für Aufgaben mit dem Starttyp Fargate vorgesehen. Ist kein solcher angegeben, wird standardmäßig die neueste Version (`LATEST`) verwendet. Wenn Sie einen Service aktualisieren, löst dieser Parameter eine neue Servicebereitstellung aus. AWS Fargate-Plattformversionen werden verwendet, um auf eine bestimmte Laufzeitumgebung für die Fargate-Task-Infrastruktur zu verweisen. Bei der Angabe der `LATEST`-Plattformversion bei Ausführung einer Aufgabe oder beim Erstellen eines Service erhalten Sie die aktuellste Plattformversion, die für Ihre Aufgaben zur Verfügung steht. Wenn Sie Ihren Service skalieren, erhalten diese Aufgaben die Plattformversion, die in der aktuellen Bereitstellung des Service angegeben wurde. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md). Plattformversionen werden nicht für Aufgaben angegeben, die den Starttyp EC2 verwenden. `loadBalancers` Ein Load Balancer-Objekt, das den Load Balancer angibt, der mit Ihrem Service verwendet werden soll. Wenn Sie einen externen Bereitstellungscontroller verwenden, werden nur Application Load Balancer und Network Load Balancer unterstützt. Wenn Sie einen Application Load Balancer verwenden, ist pro Aufgabensatz nur eine Application Load Balancer-Zielgruppe zulässig. Der folgende Ausschnitt zeigt ein `loadBalancer`-Beispielobjekt. ``` "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ] ``` Wenn Sie ein `loadBalancer`-Objekt angeben, müssen Sie einen `targetGroupArn` angeben und die Parameter `loadBalancerName` auslassen. `networkConfiguration` Die Netzwerkkonfiguration für den Service. Dieser Parameter ist erforderlich, damit Aufgabendefinitionen, die den Netzwerkmodus `awsvpc` verwenden, ihre eigene Elastic-Network-Schnittstelle erhalten. Für andere Netzwerkmodi wird er nicht unterstützt. Weitere Informationen über Netzwerke für Fargate finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für Fargate](fargate-task-networking.md). `serviceRegistries` Die Details der Serviceerkennung-Registrierungen, die diesem Service zugewiesen werden sollen. Weitere Informationen finden Sie unter [Die Serviceerkennung verwenden, um Amazon-ECS-Services mithilfe von DNS-Namen zu verbinden](service-discovery.md). `scale` Ein Gleitkomma-Prozentsatz der gewünschten Anzahl von Aufgaben, die im Aufgabensatz platziert und ausgeführt werden sollen. Der Wert wird als Gesamtprozentsatz des `desiredCount`-Wertes eines Services angegeben. Akzeptierte Werte sind Zahlen zwischen 0 und 100. Im Folgenden finden Sie ein JSON-Beispiel für die Erstellung eines Aufgabensatzes für einen externen Bereitstellungs-Controller. ``` { "service": "", "cluster": "", "externalId": "", "taskDefinition": "", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "" ], "securityGroups": [ "" ], "assignPublicIp": "DISABLED" } }, "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ], "serviceRegistries": [ { "registryArn": "", "port": 0, "containerName": "", "containerPort": 0 } ], "launchType": "EC2", "capacityProviderStrategy": [ { "capacityProvider": "", "weight": 0, "base": 0 } ], "platformVersion": "", "scale": { "value": null, "unit": "PERCENT" }, "clientToken": "" } ``` 1. Wenn Service-Änderungen erforderlich sind, verwenden Sie abhängig von den zu aktualisierenden Parametern die API-Aktion `UpdateService`, `UpdateTaskSet` oder `CreateTaskSet`. Wenn Sie eine Aufgabe erstellt haben, bestimmen Sie mithilfe des Parameters `scale` für jede Aufgabe in einem Service, wie viele Aufgaben im Service weiterhin ausgeführt werden sollen. Wenn ein Service beispielsweise `tasksetA` enthält und Sie `tasksetB` erstellen, können Sie zuerst die Gültigkeit von `tasksetB` testen, bevor Sie den Produktionsdatenverkehr darauf umstellen. Sie können als `scale`-Wert für beide Aufgabensätze `100` einstellen. Wenn Sie dann bereit sind, den gesamten Produktionsdatenverkehr auf `tasksetB` umzustellen, können Sie den `scale`-Wert für `tasksetA` auf `0` aktualisieren, um ihn nach unten zu skalieren. # CodeDeploy blaue/grüne Bereitstellungen für Amazon ECS Wir empfehlen Ihnen, die Amazon blue/green ECS-Bereitstellung zu verwenden. Weitere Informationen finden Sie unter [Eine Amazon blue/green ECS-Bereitstellung erstellen](deploy-blue-green-service.md). Der Bereitstellungstyp *Blau/Grün* verwendet das blue/green Bereitstellungsmodell, das von CodeDeploy gesteuert wird. Mit diesem Bereitstellungstyp können Sie eine neue Bereitstellung eines Service überprüfen, bevor Sie den Produktionsverkehr an ihn senden. Weitere Informationen finden Sie unter [Was ist CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) im *AWS CodeDeploy Benutzerhandbuch*. Überprüfen Sie den Status eines Amazon ECS-Service vor der Bereitstellung Es gibt drei Möglichkeiten, wie sich der Verkehr während einer blue/green Bereitstellung verlagern kann: + **Canary** – Der Datenverkehr wird in zwei Schritten verlagert. Sie können aus vordefinierten Canary-Optionen auswählen, die den Prozentsatz des Datenverkehrs, der im ersten Inkrementschritt zu Ihrem aktualisierten Aufgabensatz verschoben wird, sowie das Zeitintervall (in Minuten) angeben, das verstreichen soll, bevor der restliche Datenverkehr im zweiten Inkrementschritt verschoben wird. + **Linear** – Der Datenverkehr wird in gleich großen Schritten mit einer gleichen Anzahl von Minuten zwischen den Schritten verlagert. Sie können aus vordefinierten linearen Optionen auswählen, die den Prozentsatz des Datenverkehrs, der in den einzelnen Inkrementschritten verschoben wird, sowie das Zeitintervall (in Minuten) zwischen den einzelnen Inkrementschritten angeben. + **A ll-at-once** — Der gesamte Datenverkehr wird auf einmal vom ursprünglichen Task-Set auf das aktualisierte Task-Set umgestellt. Die folgenden Komponenten werden von Amazon ECS verwendet CodeDeploy , wenn ein Service den blue/green Bereitstellungstyp verwendet: **CodeDeploy Anwendung** Eine Sammlung von CodeDeploy Ressourcen. Sie besteht aus einer oder mehreren Bereitstellungsgruppen. **CodeDeploy Bereitstellungsgruppe** Die Bereitstellungseinstellungen. Diese bestehen aus: + Amazon-ECS-Cluster und -Service + Informationen zu Load-Balancer-Zielgruppen- und Listenern + Rollback-Strategie für die Bereitstellung + Einstellungen zur Umleitung des Datenverkehrs + Beendigungseinstellungen der ursprünglichen Version + Bereitstellungskonfiguration + CloudWatch Alarm-Konfiguration, die so eingerichtet werden kann, dass Bereitstellungen gestoppt werden + SNS- oder CloudWatch Events-Einstellungen für Benachrichtigungen Weitere Informationen finden Sie unter [Arbeiten mit Bereitstellungsgruppen](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) im *AWS CodeDeploy -Benutzerhandbuch*. **CodeDeploy Bereitstellungskonfiguration** Gibt an, wie CodeDeploy der Produktionsdatenverkehr während einer Bereitstellung an Ihren Ersatz-Tasksatz weitergeleitet wird. Die folgenden vordefinierten linearen und Canary-Bereitstellungskonfigurationen sind verfügbar. Sie können auch benutzerdefinierte lineare und Canary-Bereitstellungen erstellen. Weitere Informationen finden Sie unter [Arbeiten mit Bereitstellungskonfigurationen](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) im *AWS CodeDeploy -Benutzerhandbuch*. + **CodeDeployDefault. ECSAllAtOnce**: Verschiebt den gesamten Datenverkehr auf einmal in den aktualisierten Amazon ECS-Container + **CodeDeployDefault. ECSLinear10PercentEvery1 Minuten**: Verschiebt jede Minute 10 Prozent des Verkehrs, bis der gesamte Verkehr verlagert ist. + **CodeDeployDefault. ECSLinear10PercentEvery3 Minuten**: Verschiebt alle 3 Minuten 10 Prozent des Verkehrs, bis der gesamte Verkehr verlagert ist. + **CodeDeployDefault. ECSCanary10Percent5Minutes**: Verschiebt 10 Prozent des Traffics im ersten Schritt. Die restlichen 90 Prozent werden fünf Minuten später bereitgestellt. + **CodeDeployDefault. ECSCanary10Percent15Minutes**: Verschiebt 10 Prozent des Traffics im ersten Schritt. Die restlichen 90 Prozent werden 15 Minuten später bereitgestellt. **Revision** Eine Revision ist die CodeDeploy Anwendungsspezifikationsdatei (AppSpec Datei). In der AppSpec Datei geben Sie den vollständigen ARN der Aufgabendefinition sowie den Container und Port Ihres Ersatz-Tasksatzes an, an den der Datenverkehr weitergeleitet werden soll, wenn eine neue Bereitstellung erstellt wird. Der Containername muss einer der Containernamen sein, auf die in Ihrer Aufgabendefinition verwiesen wird. Wenn die Netzwerkkonfiguration oder die Plattformversion in der Dienstdefinition aktualisiert wurde, müssen Sie diese Details auch in der AppSpec Datei angeben. Sie können auch die Lambda-Funktionen angeben, die während des Bereitstellungs-Lebenszyklus ausgeführt werden sollen. Mit den Lambda-Funktionen können Sie während der Bereitstellung Tests durchführen und Metriken zurückgeben. Weitere Informationen finden Sie unter [AppSpec Dateireferenz](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html) im *AWS CodeDeploy Benutzerhandbuch*. ## Überlegungen Beachten Sie bei der Verwendung des blue/green Bereitstellungstyps Folgendes: + Wenn ein Amazon ECS-Service, der den blue/green Bereitstellungstyp verwendet, anfänglich erstellt wird, wird ein Amazon ECS-Aufgabensatz erstellt. + Sie müssen den Service für die Verwendung von entweder einem Application Load Balancer oder Network Load Balancer konfigurieren. Nachfolgend sind die Anforderungen an den Load Balancer aufgeführt: + Sie müssen dem Load Balancer, der zur Weiterleitung des Produktionsverkehrs verwendet wird, einen Produktions-Listener hinzufügen. + Dem Load Balancer, der zur Weiterleitung des Testverkehrs verwendet wird, kann ein optionaler Test-Listener hinzugefügt werden. Wenn Sie einen Test-Listener angeben, CodeDeploy leitet er Ihren Testdatenverkehr während einer Bereitstellung an den Ersatz-Aufgabensatz weiter. + Sowohl der Produktions- als auch der Test-Listener müssen demselben Load Balancer angehören. + Sie müssen für den Load Balancer eine Zielgruppe definieren. Die Zielgruppe leitet den Datenverkehr über den Produktions-Listener an die ursprüngliche Aufgabe weiter, die in einem Service festgelegt wurde. + Bei Verwendung eines Network Load Balancer wird nur die `CodeDeployDefault.ECSAllAtOnce`-Bereitstellungskonfiguration unterstützt. + Bei Services, die für die Verwendung des Auto Scaling des Services und der blau/grüne Bereitstellungstyp konfiguriert sind, wird das Auto Scaling während einer Bereitstellung nicht blockiert, die Bereitstellung kann jedoch unter Umständen fehlschlagen. Im Folgenden wird dieses Verhalten ausführlich beschrieben. + Wenn ein Service skaliert wird und eine Bereitstellung gestartet wird, wird das grüne Task-Set erstellt. Es CodeDeploy wird bis zu einer Stunde gewartet, bis das grüne Task-Set den stabilen Status erreicht hat. Bis dahin wird kein Traffic verlagert. + Wenn ein Dienst gerade blue/green bereitgestellt wird und ein Skalierungsereignis eintritt, verschiebt sich der Datenverkehr für weitere 5 Minuten. Wenn der Dienst nicht innerhalb von 5 Minuten den stabilen Status erreicht, CodeDeploy wird die Bereitstellung gestoppt und als fehlgeschlagen markiert. + Aufgaben, die die Controller-Typen Fargate oder `CODE_DEPLOY` verwenden, unterstützen die `DAEMON`-Planungsstrategie nicht. + Wenn Sie zum ersten Mal eine CodeDeploy Anwendung und eine Bereitstellungsgruppe erstellen, müssen Sie Folgendes angeben: + Sie müssen zwei Zielgruppen für den Load Balancer definieren. Eine Zielgruppe ist die ursprüngliche Zielgruppe, die für den Load Balancer beim Anlegen des Amazon-ECS-Service definiert wurde. Die einzige Anforderung der zweiten Zielgruppe besteht darin, dass sie nicht mit einem anderen Load Balancer als dem, den der Service verwendet, verknüpft werden darf. + Wenn Sie eine CodeDeploy Bereitstellung für einen Amazon ECS-Service erstellen, CodeDeploy wird in der Bereitstellung ein *Ersatzaufgabensatz* (oder ein *grüner Tasksatz*) erstellt. Wenn Sie dem Load Balancer einen Test-Listener hinzugefügt haben, CodeDeploy leitet er Ihren Testdatenverkehr an den Ersatz-Aufgabensatz weiter. Dies ist der Zeitpunkt, an dem Sie Validierungstests durchführen können. CodeDeploy leitet den Produktionsdatenverkehr dann vom ursprünglichen Aufgabensatz zum Ersatz-Aufgabensatz um. Dabei gelten die Einstellungen für die Datenverkehrsumleitung der Bereitstellungsgruppe. ## Erforderliche IAM-Berechtigungen Blue/green deployments are made possible by a combination of the Amazon ECS and CodeDeploy APIs. Users must have the appropriate permissions for these services before they can use Amazon ECS blue/greenBereitstellungen im AWS-Managementkonsole oder mit dem oder. AWS CLI SDKs Zusätzlich zu den IAM-Standardberechtigungen für das Erstellen und Aktualisieren von Services erfordert Amazon ECS folgende Berechtigungen. Diese Berechtigungen wurden der `AmazonECS_FullAccess`-IAM-Richtlinie hinzugefügt. Weitere Informationen finden Sie unter [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess). + `codedeploy:CreateApplication` + `codedeploy:CreateDeployment` + `codedeploy:CreateDeploymentGroup` + `codedeploy:GetApplication` + `codedeploy:GetDeployment` + `codedeploy:GetDeploymentGroup` + `codedeploy:ListApplications` + `codedeploy:ListDeploymentGroups` + `codedeploy:ListDeployments` + `codedeploy:StopDeployment` + `codedeploy:GetDeploymentTarget` + `codedeploy:ListDeploymentTargets` + `codedeploy:GetDeploymentConfig` + `codedeploy:GetApplicationRevision` + `codedeploy:RegisterApplicationRevision` + `codedeploy:BatchGetApplicationRevisions` + `codedeploy:BatchGetDeploymentGroups` + `codedeploy:BatchGetDeployments` + `codedeploy:BatchGetApplications` + `codedeploy:ListApplicationRevisions` + `codedeploy:ListDeploymentConfigs` + `codedeploy:ContinueDeployment` + `sns:ListTopics` + `cloudwatch:DescribeAlarms` + `lambda:ListFunctions` **Anmerkung** Zusätzlich zu den standardmäßigen Amazon-ECS-Berechtigungen, die zum Ausführen von Aufgaben und Services erforderlich sind, benötigen Benutzer auch `iam:PassRole`-Berechtigungen, um IAM-Rollen für Aufgaben zu verwenden. CodeDeploy benötigt Berechtigungen, um Amazon ECS aufzurufen APIs, Ihr Elastic Load Balancing zu ändern, Lambda-Funktionen aufzurufen und CloudWatch Alarme zu beschreiben, sowie Berechtigungen, um die von Ihrem Service gewünschte Anzahl in Ihrem Namen zu ändern. Bevor Sie einen Amazon ECS-Service erstellen, der den blue/green Bereitstellungstyp verwendet, müssen Sie eine IAM-Rolle (`ecsCodeDeployRole`) erstellen. Weitere Informationen finden Sie unter [Amazon ECS CodeDeploy IAM-Rolle](codedeploy_IAM_role.md). # Bereitstellungen migrieren CodeDeploy blue/green deployments to Amazon ECS blue/green CodeDeploy blue/green and Amazon ECS blue/greenBereitstellungen bieten ähnliche Funktionen, unterscheiden sich jedoch darin, wie Sie sie konfigurieren und verwalten. ## CodeDeploy Übersicht über die Bereitstellung in Blau/Grün Wenn Sie einen Amazon ECS-Service mit erstellen CodeDeploy, gehen Sie wie folgt vor: 1. Erstellen Sie einen Load Balancer mit einem Produktions-Listener und (optional) einem Test-Listener. Jeder Listener ist mit einer einzigen (Standard-) Regel konfiguriert, die den gesamten Datenverkehr an eine einzige Zielgruppe (die primäre Zielgruppe) weiterleitet. 1. Erstellen Sie einen Amazon-ECS-Service, der für die Verwendung des Listeners und der Zielgruppe konfiguriert ist und dessen `deploymentController`-Typ auf `CODE_DEPLOY` gestellt ist. Die Erstellung eines Services führt zur Erstellung eines (blauen) Aufgabensatzes, der bei der angegebenen Zielgruppe registriert ist. 1. Erstellen Sie eine CodeDeploy Bereitstellungsgruppe (als Teil einer CodeDeploy Anwendung) und konfigurieren Sie sie mit Details zum Amazon ECS-Cluster, dem Servicenamen, den Load Balancer-Listenern, zwei Zielgruppen (die primäre Zielgruppe, die in der Produktions-Listener-Regel verwendet wird, und einer sekundären Zielgruppe, die für Ersatzaufgaben verwendet wird), einer Servicerolle (zur Erteilung von CodeDeploy Berechtigungen zur Bearbeitung von Amazon ECS- und Elastic Load Balancing Balancing-Ressourcen) und verschiedenen Parametern, die das Bereitstellungsverhalten steuern. Mit CodeDeploy werden neue Versionen eines Dienstes unter Angabe des CodeDeploy Anwendungsnamens`CreateDeployment()`, des Namens der Bereitstellungsgruppe und einer AppSpec Datei bereitgestellt, die Details zur neuen Version und optionale Lifecycle-Hooks enthält. Bei der CodeDeploy Bereitstellung wird ein Ersatzaufgabensatz (grün) erstellt und dessen Aufgaben bei der sekundären Zielgruppe registriert. Sobald diese fehlerfrei wird, steht sie für Tests (optional) und für die Produktion zur Verfügung. In beiden Fällen wird das Routing dadurch erreicht, dass die jeweilige Listener-Regel so geändert wird, dass sie auf die sekundäre Zielgruppe verweist, die dem grünen Aufgabensatz zugeordnet ist. Ein Rollback wird erreicht, indem die Produktions-Listener-Regel wieder auf die primäre Zielgruppe zurückgesetzt wird. ## Überblick über die blue/green Bereitstellung von Amazon ECS Bei Amazon blue/green ECS-Bereitstellungen ist die Bereitstellungskonfiguration Teil des Amazon ECS-Service selbst: 1. Sie müssen den Produktions-Listener des Load Balancer mit einer Regel vorkonfigurieren, die zwei Zielgruppen mit den Gewichtungen 1 und 0 umfasst. 1. Sie müssen die folgenden Ressourcen angeben oder die Service-Ressourcen aktualisieren: + Der ARN dieser Listener-Regel + Die zwei Zielgruppen + Eine IAM-Rolle, um Amazon ECS die Erlaubnis zu erteilen, Elastic Load Balancing aufzurufen APIs + Eine optionale IAM-Rolle zur Ausführung von Lambda-Funktionen + Setzen Sie den `deploymentController`-Typ auf `ECS` und `deploymentConfiguration.strategy` auf `BLUE_GREEN`. Dadurch entsteht eine (blaue) Servicebereitstellung, deren Aufgaben bei der primären Zielgruppe registriert sind. Wenn Amazon ECS blau/grün ist, wird eine neue Service-Revision erstellt, indem Amazon ECS `UpdateService()` aufgerufen und die Details der neuen Revision übergeben werden. Bei der Servicebereitstellung werden neue Aufgaben der (grünen) Service-Revision erstellt und diese bei der sekundären Zielgruppe registriert. Amazon ECS führt Routing- und Rollback-Vorgänge aus, indem es die Gewichtungen der Listener-Regel ändert. ## Wichtige Unterschiede bei der Implementierung Beide Ansätze führen zwar zur Erstellung eines ersten Aufgabensatzes, die zugrunde liegende Implementierung unterscheidet sich jedoch: + CodeDeploy verwendet einen Tasksatz, während Amazon ECS eine Service-Revision verwendet. Amazon-ECS-Aufgabensätze sind ein älteres Konstrukt, das durch Revisionen und Bereitstellungen von Amazon-ECS-Services ersetzt wurde. Letztere bieten einen besseren Einblick in den Bereitstellungsprozess sowie in die Servicebereitstellung und den Verlauf der Service-Revisionen. + Mit CodeDeploy werden Lifecycle-Hooks als Teil der AppSpec Datei angegeben, an die geliefert wird`CreateDeployment()`. Das bedeutet, dass die Hooks von einer Bereitstellung zur nächsten geändert werden können. Bei Amazon-ECS-Blau/Grün-Bereitstellungen werden die Hooks als Teil der Service-Konfiguration angegeben, und für alle Aktualisierungen wäre ein `UpdateService()`-Aufruf erforderlich. + CodeDeploy Sowohl Amazon ECS als auch Amazon ECS blue/green verwenden Lambda für die Hook-Implementierung, aber die erwarteten Eingaben und Ausgaben unterscheiden sich. Bei muss die Funktion aufgerufen werden CodeDeploy, `PutLifecycleEventHookExecutionStatus()` um den Hook-Status zurückzugeben, der entweder `SUCCEEDED` oder `FAILED` sein kann. Bei Amazon ECS wird die Lambda-Antwort verwendet, um den Hook-Status anzuzeigen. + CodeDeploy ruft jeden Hook als einmaligen Aufruf auf und erwartet, dass innerhalb einer Stunde der endgültige Ausführungsstatus zurückgegeben wird. Amazon-ECS-Hooks sind insofern flexibler, als sie einen `IN_PROGRESS`-Indikator zurückgeben können, der signalisiert, dass der Hook wiederholt erneut aufgerufen werden muss, bis er zu `SUCCEEDED` oder `FAILED` führt. Weitere Informationen finden Sie unter [Lebenszyklus-Hooks für Amazon-ECS-Servicebereitstellungen](deployment-lifecycle-hooks.md). ## Migrationsansätze Es gibt drei Hauptansätze für die Migration von Bereitstellungen. CodeDeploy blue/green to Amazon ECS blue/green Jeder Ansatz weist unterschiedliche Merkmale in Bezug auf Komplexität, Risiko, Rollback-Fähigkeit und potenzielle Ausfallzeiten auf. ### Verwenden Sie dieselben Elastic Load Balancing Balancing-Ressourcen wieder, die für CodeDeploy Sie aktualisieren den vorhandenen Amazon ECS-Service, sodass er den Amazon ECS Deployment Controller mit blue/green Deployment Strategy anstelle des CodeDeploy Deployment Controllers verwendet. Berücksichtigen Sie bei diesem Ansatz Folgendes: + Das Migrationsverfahren ist einfacher, da Sie den vorhandenen Servicebereitstellungs-Controller von Amazon ECS und die Bereitstellungsstrategie aktualisieren. + Bei korrekter Konfiguration und Migration treten keine Ausfallzeiten auf. + Ein Rollback erfordert, dass Sie die Service-Revision rückgängig machen. + Das Risiko ist hoch, da es keine parallele Blau/Grün-Konfiguration gibt. Sie verwenden denselben Load Balancer-Listener und dieselben Zielgruppen, für die auch verwendet werden. CodeDeploy Wenn Sie es verwenden, finden Sie weitere Informationen CloudFormation unter. [Eine Vorlage migrieren CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md) 1. Ändern Sie die Standardregel der production/test Zuhörer so, dass sie die alternative Zielgruppe einbezieht, und legen Sie die Gewichtung der primären Zielgruppe auf 1 und der alternativen Zielgruppe auf 0 fest. Denn CodeDeploy die Listener des an den Service angeschlossenen Load Balancers sind mit einer einzigen (Standard-) Regel konfiguriert, die den gesamten Datenverkehr an eine einzige Zielgruppe weiterleitet. Für Amazon-ECS-Blau/Grün-Bereitstellungen müssen die Load-Balancer-Listener mit einer Regel vorkonfiguriert sein, die die beiden Zielgruppen mit Gewichtungen umfasst. Die primäre Zielgruppe muss mit 1 gewichtet werden und die alternative Zielgruppe muss mit 0 gewichtet werden. 1. Aktualisieren Sie den vorhandenen Amazon-ECS-Service, indem Sie die `UpdateService`-API aufrufen und den Parameter `deploymentController` auf `ECS` und den Parameter `deploymentStrategy` auf `BLUE_GREEN` setzen. Geben Sie ARNs die Zielgruppe, die alternative Zielgruppe, den Produktions-Listener und einen optionalen Test-Listener an. 1. Stellen Sie sicher, dass der Service wie erwartet funktioniert. 1. Löschen Sie das CodeDeploy Setup für diesen Amazon ECS-Service, da Sie jetzt Amazon ECS blau/grün verwenden. ### Neuer Service mit vorhandenem Load Balancer Bei diesem Ansatz wird die blue/green Strategie für die Migration verwendet. Berücksichtigen Sie bei diesem Ansatz Folgendes: + Es gibt nur minimale Störungen. Störungen treten nur während der Port-Auslagerung für Elastic Load Balancing auf. + Ein Rollback erfordert, dass Sie die Port-Auslagerung für Elastic Load Balancing rückgängig machen. + Das Risiko ist gering, da es parallele Konfigurationen gibt. Daher können Sie vor der Datenverkehrsverlagerung testen. 1. Lassen Sie die Zuhörer, die Zielgruppen und den Amazon ECS-Service für das CodeDeploy Setup intakt, sodass Sie bei Bedarf problemlos zu diesem Setup zurückkehren können. 1. Erstellen Sie neue Zielgruppen und neue Listener (mit anderen Ports als die ursprünglichen Listener) unter dem vorhandenen Load Balancer. Erstellen Sie dann einen neuen Amazon ECS-Service, der dem bestehenden Amazon ECS-Service entspricht, außer dass Sie ihn `ECS` als Deployment Controller, `BLUE_GREEN` als Bereitstellungsstrategie verwenden, und übergeben Sie die Regeln ARNs für die neuen Zielgruppen und die neuen Zuhörer. 1. Überprüfen Sie die neue Einrichtung, indem Sie HTTP-Datenverkehr manuell an den Service senden. Wenn alles gut geht, tauschen Sie die Ports der ursprünglichen Listener und der neuen Listener aus, um den Datenverkehr an die neue Einrichtung weiterzuleiten. 1. Überprüfen Sie das neue Setup, und wenn alles weiterhin wie erwartet funktioniert, löschen Sie das CodeDeploy Setup. ### Neuer Service mit neuem Load Balancer Wie der vorherige Ansatz verwendet auch dieser Ansatz die blue/green Strategie für die Migration. Der Hauptunterschied besteht darin, dass der Wechsel vom CodeDeploy Setup zum Amazon blue/green ECS-Setup auf einer Reverse-Proxy-Ebene über dem Load Balancer erfolgt. Beispielimplementierungen für die Reverse-Proxy-Schicht sind Route 53 und. CloudFront Dieser Ansatz eignet sich für Kunden, die bereits über diese Reverse-Proxyschicht verfügen und wenn die gesamte Kommunikation mit dem Service über sie erfolgt (z. B. keine direkte Kommunikation auf Load-Balancer-Ebene). Berücksichtigen Sie bei diesem Ansatz Folgendes: + Dies erfordert eine Reverse-Proxy-Schicht. + Das Migrationsverfahren ist komplizierter, da Sie den vorhandenen Servicebereitstellungs-Controller von Amazon ECS und die Bereitstellungsstrategie aktualisieren müssen. + Es gibt nur minimale Störungen. Störungen treten nur während der Port-Auslagerung für Elastic Load Balancing auf. + Ein Rollback erfordert, dass Sie die Änderungen an der Proxy-Konfiguration rückgängig machen. + Das Risiko ist gering, da es parallele Konfigurationen gibt. Daher können Sie vor der Datenverkehrsverlagerung testen. 1. Ändern Sie das bestehende CodeDeploy Setup nicht intakt (Load Balancer, Listener, Zielgruppen, Amazon ECS-Service und CodeDeploy Bereitstellungsgruppe). 1. Erstellen Sie einen neuen Load Balancer, Zielgruppen und Listener, die für Amazon blue/green ECS-Bereitstellungen konfiguriert sind. 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). 1. Erstellen Sie einen neuen Service mit `ECS` als Bereitstellungs-Controller und `BLUE_GREEN` als Bereitstellungsstrategie, die auf die neuen Load-Balancer-Ressourcen verweist. 1. Überprüfen Sie die neue Einrichtung, indem Sie sie mit dem neuen Load Balancer testen. 1. Aktualisieren Sie die Reverse-Proxy-Konfiguration, um den Datenverkehr an den neuen Load Balancer weiterzuleiten. 1. Beachten Sie die neue Service-Revision. Wenn alles weiterhin wie erwartet funktioniert, löschen Sie das Setup. CodeDeploy ## Nächste Schritte Nach der Migration zu Amazon blue/green ECS-Bereitstellungen: + Aktualisieren Sie Ihre Bereitstellungsskripte und CI/CD Pipelines, um die Amazon `UpdateService` ECS-API anstelle der CodeDeploy `CreateDeployment` API zu verwenden. + Aktualisieren Sie Ihre Überwachungs- und Warnmeldungen, um Amazon ECS-Servicebereitstellungen anstelle von CodeDeploy Bereitstellungen zu verfolgen. + Erwägen Sie die Implementierung automatisierter Tests Ihres neuen Bereitstellungsprozesses, um sicherzustellen, dass er wie erwartet funktioniert. # Migration von einer Servicebereitstellung CodeDeploy blue/green to an Amazon ECS blue/green Mithilfe von Amazon blue/green ECS-Bereitstellungen können Sie Serviceänderungen vornehmen und testen, bevor Sie sie in einer Produktionsumgebung implementieren. Sie müssen neue Lifecycle-Hooks für Ihre Amazon blue/green ECS-Bereitstellung erstellen. ## Voraussetzungen Führen Sie die folgenden Vorgänge aus, bevor Sie eine blue/green Bereitstellung starten. 1. Ersetzen Sie die Amazon CodeDeploy ECS-IAM-Rolle durch die folgenden Berechtigungen. + Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Weitere Informationen zu Lambda-Berechtigungen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). 1. Schalten Sie die CodeDeploy Automatisierung aus. Weitere Informationen finden Sie [ CodeDeployim *CodeDeploy Benutzerhandbuch* unter Arbeiten mit Bereitstellungsgruppen](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html). 1. Stellen Sie sicher, dass Sie über die folgenden Informationen aus Ihrer CodeDeploy blue/green deployment. You can reuse this information for the Amazon ECS blue/green Bereitstellung verfügen: + Die Produktionszielgruppe + Der Produktions-Listener + Die Produktionsregel + Die Test-Zielgruppe Das ist die Zielgruppe für die grüne Service-Revision. 1. Stellen Sie sicher, dass die Zielgruppen Ihres Application Load Balancer ordnungsgemäß mit den Listener-Regeln verknüpft sind: + Wenn Sie keine Test-Listener verwenden, müssen beide Zielgruppen (Produktion und Test) mit Produktions-Listener-Regeln verknüpft werden. + Wenn Sie Test-Listener verwenden, muss eine Zielgruppe mit Produktions-Listener-Regeln und die andere Zielgruppe mit Test-Listener-Regeln verknüpft sein. Wenn diese Anforderung nicht erfüllt ist, schlägt die Servicebereitstellung mit der folgenden Fehlermeldung fehl: `Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.` 1. Stellen Sie sicher, dass es keine laufenden Servicebereitstellungen für den Service gibt. Weitere Informationen finden Sie unter [Anzeigen des Service-Verlaufs mithilfe von Service-Bereitstellungen in Amazon ECS](service-deployment.md). 1. Amazon blue/green ECS-Bereitstellungen erfordern, dass Ihr Service eine der folgenden Funktionen verwendet: 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). 1. Entscheiden Sie, ob Sie Lambda-Funktionen für die Lebenszyklusphasen der Phasen der Amazon blue/green ECS-Bereitstellung ausführen möchten. + Vor dem Hochskalieren + Nach dem Hochskalieren + Verlagerung des Test-Datenverkehrs + Nach der Verlagerung des Test-Datenverkehrs + Verlagerung des Produktionsdatenverkehrs + Nach der Verlagerung des Produktionsdatenverkehrs Erstellen Sie Lambda-Funktionen für jede Lebenszyklusphase. Weitere Informationen finden Sie unter [Erstellen einer Lambda-Funktion mit der Konsole](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) im *Entwicklerhandbuch für AWS Lambda *. Weitere Informationen zum Aktualisieren des Bereitstellungs-Controllers eines Services finden Sie unter [Aktualisieren der Amazon-ECS-Serviceparameter](update-service-parameters.md). ## Verfahren 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version 2.](https://console.aws.amazon.com/ecs/v2) 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. Die Cluster-Detailseite wird angezeigt. 1. Wählen Sie auf der Registerkarte **Services** den Service aus. Die Seite mit den Service-Details wird angezeigt. 1. Wählen Sie im Banner **Typ des Bereitstellungs-Controllers aktualisieren** aus. Die Seite **Typ des Bereitstellungs-Controllers migrieren** wird angezeigt. 1. Erweitern Sie **Neu** und geben Sie dann die folgenden Parameter an. 1. Wählen Sie für **Typ des Bereitstellungs-Controllers** die Option **ECS** aus. 1. Wählen Sie für **Bereitstellungsstrategie** die Option **Blau/Grün** aus. 1. Geben Sie für **Bake-Zeit** die Zeit ein, zu der sowohl die blaue als auch die grüne Service-Revision ausgeführt werden. 1. Um Lambda-Funktionen für eine Lebenszyklusphase auszuführen, gehen Sie unter **Bereitstellungs-Lebenszyklus-Hooks** für jede einzelne Lambda-Funktion wie folgt vor: 1. Wählen Sie **Hinzufügen** aus. Wiederholen Sie den Prozess für jede einzelne Funktion, die Sie ausführen möchten. 1. Geben Sie für **Lambda-Funktion** den Funktionsnamen ein. 1. Wählen Sie für **Rolle** die Rolle aus, die Sie in den Voraussetzungen mit den blauen/grünen Berechtigungen erstellt haben. Weitere Informationen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). 1. Wählen Sie für **Lebenszyklusphasen** die Phasen aus, in denen die Lambda-Funktion ausgeführt wird. 1. (Optional) Geben Sie für **Hook-Details** ein Schlüssel-Wert-Paar ein, das Informationen über den Hook bereitstellt. 1. Erweitern Sie **Load Balancing** und konfigurieren Sie dann Folgendes: 1. Wählen Sie **unter Rolle** die Rolle aus, die Sie in den Voraussetzungen mit den blue/green entsprechenden Berechtigungen erstellt haben. Weitere Informationen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). 1. Wählen Sie für **Listener** den Produktions-Listener aus Ihrer CodeDeploy blauen/grünen Bereitstellung aus. 1. Wählen Sie für **Produktionsregel** die Produktionsregel aus Ihrer CodeDeploy blauen/grünen Bereitstellung aus. 1. Wählen Sie **unter Testregel** die Testregel aus Ihrer CodeDeploy blauen/grünen Bereitstellung aus. 1. Wählen Sie **unter Zielgruppe** die Produktionszielgruppe aus Ihrer CodeDeploy blauen/grünen Bereitstellung aus. 1. Wählen Sie **unter Alternative Zielgruppe** die Testzielgruppe aus Ihrer CodeDeploy blauen/grünen Bereitstellung aus. 1. Wählen Sie **Aktualisieren** aus. ## Nächste Schritte + Aktualisieren Sie den Service, um die Bereitstellung zu starten. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). + Überwachen Sie den Bereitstellungsprozess, um sicherzustellen, dass er dem Blau/Grün-Muster folgt: + Die grüne Service-Revision wurde erstellt und hochskaliert + Der Test-Datenverkehr wird an die grüne Revision weitergeleitet (falls konfiguriert) + Der Produktionsdatenverkehr verlagert sich auf die grüne Revision. + Nach Ablauf der Bake-Zeit wird die blaue Revision beendet # Eine Vorlage migrieren CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation Migrieren Sie eine CloudFormation Vorlage, die eine CodeDeploy blue/green deployments for Amazon ECS services to one that uses the native Amazon ECS blue/green Bereitstellungsstrategie verwendet. Die Migration folgt dem Ansatz „Dieselben Elastic Load Balancing Balancing-Ressourcen wiederverwenden, für die sie verwendet wurden CodeDeploy“. Weitere Informationen finden Sie unter [Bereitstellungen migrieren CodeDeploy blue/green deployments to Amazon ECS blue/green](migrate-codedeploy-to-ecs-bluegreen.md). ## Quellvorlage Diese Vorlage verwendet `AWS::CodeDeployBlueGreen` Transform und `AWS::CodeDeploy::BlueGreen` Hook, um blue/green Bereitstellungen für einen Amazon ECS-Service zu implementieren. ### Quelle Dies ist die vollständige CloudFormation Vorlage, die eine CodeDeploy blaue/grüne Bereitstellung verwendet. Weitere Informationen finden Sie im * AWS CloudFormation Benutzerhandbuch* unter [Beispiel für eine blaue/grüne Bereitstellungsvorlage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json): ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Transform": [ "AWS::CodeDeployBlueGreen" ], "Hooks": { "CodeDeployBlueGreenHook": { "Type": "AWS::CodeDeploy::BlueGreen", "Properties": { "TrafficRoutingConfig": { "Type": "TimeBasedCanary", "TimeBasedCanary": { "StepPercentage": 15, "BakeTimeMins": 5 } }, "Applications": [ { "Target": { "Type": "AWS::ECS::Service", "LogicalID": "ECSDemoService" }, "ECSAttributes": { "TaskDefinitions": [ "BlueTaskDefinition", "GreenTaskDefinition" ], "TaskSets": [ "BlueTaskSet", "GreenTaskSet" ], "TrafficRouting": { "ProdTrafficRoute": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "LogicalID": "ALBListenerProdTraffic" }, "TargetGroups": [ "ALBTargetGroupBlue", "ALBTargetGroupGreen" ] } } } ] } } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "EXTERNAL" } } }, "BlueTaskSet": { "Type": "AWS::ECS::TaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "LaunchType": "FARGATE", "NetworkConfiguration": { "AwsVpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "PlatformVersion": "1.4.0", "Scale": { "Unit": "PERCENT", "Value": 100 }, "Service": {"Ref": "ECSDemoService"}, "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"} } ] } }, "PrimaryTaskSet": { "Type": "AWS::ECS::PrimaryTaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "Service": {"Ref": "ECSDemoService"}, "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]} } } } } ``` ## Schritte zur Migration ### CodeDeploy-spezifische Ressourcen entfernen Sie benötigen die folgenden Eigenschaften nicht mehr: + `AWS::CodeDeployBlueGreen`-Transformation + `CodeDeployBlueGreenHook`-Hook + `GreenTaskDefinition`- und `GreenTaskSet`-Ressourcen (diese werden von Amazon ECS verwaltet) + `PrimaryTaskSet`-Ressource (Amazon ECS verwaltet Aufgabensätze intern) ### Neukonfiguration des Load Balancer-Listener Ändern Sie die `ALBListenerProdTraffic`-Ressource so, dass sie eine Weiterleitungsaktion mit zwei Zielgruppen verwendet: ``` { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ] } ``` ### Bereitstellungseigenschaften aktualisieren Folgendes aktualisieren und hinzufügen: + Ändern Sie die Eigenschaft `DeploymentController` von `EXTERNAL` auf `ECS`. + Fügen Sie die `Strategy`-Eigenschaft hinzu und setzen Sie sie auf BLUE\$1GREEN. + Fügen Sie die `BakeTimeInMinutes`-Eigenschaft hinzu. ``` { "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" } } ``` + Fügen Sie dem Service die Load-Balancer-Konfiguration hinzu: ``` { "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } ``` + Fügen Sie dem Service die Referenz zur Aufgabendefinition hinzu: ``` { "TaskDefinition": {"Ref": "BlueTaskDefinition"} } ``` ### Erstellen Sie die ECSInfrastructure RolePolicyForLoadBalancers Amazon-Rolle Fügen Sie eine neue IAM-Rolle hinzu, die es Amazon ECS ermöglicht, Load Balancer-Ressourcen zu verwalten. Weitere Informationen finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). ## Testen von Empfehlungen 1. Stellen Sie die migrierte Vorlage in einer Nicht-Produktionsumgebung bereit. 1. Stellen Sie sicher, dass der Service mit der Erstkonfiguration korrekt bereitgestellt wird. 1. Testen Sie eine Bereitstellung, indem Sie die Aufgabendefinition aktualisieren und den Blau/Grün-Bereitstellungsprozess beobachten. 1. Stellen Sie sicher, dass der Datenverkehr korrekt zwischen den blauen und grünen Bereitstellungen wechselt. 1. Testen Sie die Rollback-Funktion, indem Sie einen Bereitstellungsfehler erzwingen. ## Vorlage nach der Migration ### Endgültige Vorlage Dies ist die vollständige CloudFormation Vorlage, die eine Amazon blue/green ECS-Bereitstellung verwendet: ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "ECSInfrastructureRoleForLoadBalancers": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToECSForInfrastructureManagement", "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "ECS" }, "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" }, "NetworkConfiguration": { "AwsvpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "LaunchType": "FARGATE", "PlatformVersion": "1.4.0", "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } } } } ``` # Migration von einer Bereitstellung des fortlaufenden Aktualisierungsservices von CodeDeploy Blau/Grün zu Amazon ECS Sie können Ihre Servicebereitstellungen von einer CodeDeploy blauen/grünen Bereitstellung zu einer Bereitstellung fortlaufender Updates von Amazon ECS migrieren. Auf diese Weise können Sie nicht mehr abhängig sein CodeDeploy , sondern eine integrierte Bereitstellung verwenden. Der Amazon ECS Service Scheduler ersetzt die aktuell laufenden Aufgaben durch neue Aufgaben. Die Anzahl der Aufgaben, die Amazon ECS während einer fortlaufenden Aktualisierung für den Service hinzufügt oder entfernt, wird durch die Service-Bereitstellungskonfiguration gesteuert. ## Voraussetzungen Führen Sie die folgenden Vorgänge aus, bevor Sie eine blue/green Bereitstellung starten. 1. Sie benötigen die Amazon ECS CodeDeploy IAM-Rolle nicht mehr. 1. Schalten Sie die CodeDeploy Automatisierung aus. Weitere Informationen finden Sie [ CodeDeployim *CodeDeploy Benutzerhandbuch* unter Arbeiten mit Bereitstellungsgruppen](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html). 1. Stellen Sie sicher, dass es keine laufenden Servicebereitstellungen für den Service gibt. Weitere Informationen finden Sie unter [Anzeigen des Service-Verlaufs mithilfe von Service-Bereitstellungen in Amazon ECS](service-deployment.md). Weitere Informationen zum Aktualisieren des Bereitstellungs-Controllers eines Services finden Sie unter [Aktualisieren der Amazon-ECS-Serviceparameter](update-service-parameters.md). ## Verfahren 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. Die Cluster-Detailseite wird angezeigt. 1. Wählen Sie auf der Registerkarte **Services** den Service aus. Die Seite mit den Service-Details wird angezeigt. 1. Wählen Sie im Banner **Migrieren** aus. Die Seite **Bereitstellungskonfiguration aktualisieren** wird angezeigt. 1. Erweitern Sie **Bereitstellungsoptionen** und geben Sie dann die folgenden Parameter an 1. Wählen Sie für **Typ des Bereitstellungs-Controllers** die Option **ECS** aus. 1. Wählen Sie für **Bereitstellungsstrategie** die Option **Fortlaufende Aktualisierung** aus. 1. Für **Min running tasks** (Min. laufende Aufgaben) geben Sie die untere Grenze für die Anzahl der Aufgaben im Service an, die während eines Einsatzes in diesem `RUNNING`-Zustand verbleiben müssen, und zwar als Prozentsatz der gewünschten Anzahl von Aufgaben (aufgerundet auf die nächste ganze Zahl). Weitere Informationen finden Sie unter [Bereitstellungs-Konfiguration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration). 1. Geben Sie für **Max running tasks** (Max. laufende Aufgaben) die Obergrenze für die Anzahl der Aufgaben im Service ein, die sich während einer Bereitstellung im Status `RUNNING` oder `PENDING` befinden dürfen, und zwar als Prozentsatz der gewünschten Anzahl von Aufgaben (abgerundet auf die nächste Ganzzahl). 1. Erweitern Sie **Load Balancing** und konfigurieren Sie dann Folgendes: 1. Wählen Sie **unter Rolle** die Rolle aus, die Sie in den Voraussetzungen mit den blue/green entsprechenden Berechtigungen erstellt haben. Weitere Informationen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). 1. Wählen Sie für **Listener** den Produktions-Listener aus Ihrer CodeDeploy blauen/grünen Bereitstellung aus. 1. Wählen Sie **unter Zielgruppe** die Produktionszielgruppe aus Ihrer CodeDeploy blauen/grünen Bereitstellung aus. 1. Wählen Sie **Aktualisieren** aus. ## Nächste Schritte Sie müssen den Service aktualisieren, damit die Änderungen wirksam werden. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). # Die Amazon-ECS-Bereitstellungsstrategie aktualisieren Amazon ECS unterstützt mehrere Bereitstellungsstrategien für die Aktualisierung Ihrer Services. Sie können je nach Ihren Anwendungsanforderungen zwischen diesen Strategien migrieren. In diesem Thema wird erklärt, wie Sie zwischen fortlaufenden Bereitstellungen und blue/green Bereitstellungen migrieren. ## Amazon-ECS-Bereitstellungsstrategien im Überblick Bevor Sie zwischen den Bereitstellungsstrategien migrieren, ist es wichtig, zu verstehen, wie die einzelnen Strategien funktionieren und welche Hauptunterschiede sie haben: **Rollende Bereitstellungen** In einer fortlaufenden Bereitstellung ersetzt Amazon ECS die aktuell ausgeführte Version Ihrer Anwendung durch eine neue Version. Der Service Scheduler verwendet die Parameter minimaler und maximaler fehlerfreier Prozentsatz, um die Bereitstellungsstrategie zu ermitteln. Fortlaufende Bereitstellungen sind einfacher einzurichten, bieten jedoch weniger Kontrolle über den Bereitstellungsprozess und das Routing des Datenverkehrs. **Blau/Grün-Bereitstellungen** In einer blue/green Bereitstellung erstellt Amazon ECS neben der vorhandenen Version (blau) eine neue Version Ihres Service (grün). Auf diese Weise können Sie die neue Version überprüfen, bevor Sie den Produktionsdatenverkehr an sie weiterleiten. Blau/Grün-Bereitstellungen bieten mehr Kontrolle über den Bereitstellungsprozess, einschließlich Funktionen zur Verlagerung des Datenverkehrs, zum Testen und zum Rollback. ## Best Practices Folgen Sie diesen bewährten Methoden bei der Migration zwischen Bereitstellungsstrategien: + **In einer Nicht-Produktionsumgebung testen**: Testen Sie die Aktualisierung immer in einer Nicht-Produktionsumgebung, bevor Sie Änderungen an Produktions-Services vornehmen. + **Rollback planen**: Legen Sie einen Rollback-Plan für den Fall fest, dass die Aktualisierung nicht wie erwartet funktioniert. + **Überwachung während der Umstellung**: Überwachen Sie Ihren Service während und nach der Migration genau, um sicherzustellen, dass er weiterhin ordnungsgemäß funktioniert. + **Dokumentation aktualisieren**: Aktualisieren Sie Ihre Bereitstellungsdokumentation, um sie an die neue Bereitstellungsstrategie anzupassen. + **Die Auswirkungen auf den Datenverkehr berücksichtigen**: Machen Sie sich ein Bild davon, wie sich die Aktualisierung auf den Datenverkehr zu Ihrem Service auswirken könnte, und planen Sie entsprechend. # Aktualisierung der Bereitstellungsstrategie von fortlaufender Aktualisierung auf eine Amazon-ECS-Blau/Grün-Bereitstellung Sie können von einer Bereitstellung fortlaufender Updates zu einer Amazon blue/green ECS-Bereitstellung migrieren, wenn Sie Serviceänderungen vornehmen und testen möchten, bevor Sie sie in einer Produktionsumgebung implementieren. ## Voraussetzungen Bevor Sie Ihren Service von der Rolling-Version zur blue/green Bereitstellung migrieren, stellen Sie sicher, dass Sie über Folgendes verfügen: + Warten Sie, bis alle aktuellen Bereitstellungen abgeschlossen sind. + Ein vorhandener Amazon-ECS-Service, der die fortlaufende Bereitstellungsstrategie verwendet. + Wenn Sie mehrere Service-Revisionen haben, die Datenverkehr bereitstellen, versucht Amazon ECS, den Datenverkehr während der Migration auf eine einzige Version zu konsolidieren. Wenn dies fehlschlägt, müssen Sie Ihren Service vor der Migration möglicherweise manuell aktualisieren, sodass er eine einzige Version verwendet. + Konfigurieren Sie die entsprechenden Berechtigungen. + Weitere Informationen zu den erforderlichen Berechtigungen für Elastic Load Balancing finden Sie unter [Amazon-ECS-IAM-Infrastrukturrolle für Load Balancer](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Weitere Informationen zu Lambda-Berechtigungen finden Sie unter [Erforderliche Berechtigungen für Lambda-Funktionen in Amazon ECS-Bereitstellungen blue/green](blue-green-permissions.md). + Je nach Konfiguration müssen Sie einen der folgenden Schritte ausführen: + Wenn Ihr Service Elastic Load Balancing verwendet, aktualisieren Sie Ihren Service mit der neuen `advancedConfiguration` und starten Sie eine fortlaufende Bereitstellung. + Wenn Ihr Service Service Connect verwendet, aktualisieren Sie Ihren Service und starten Sie eine fortlaufende Bereitstellung. + Wenn Ihr Service sowohl Elastic Load Balancing als auch Service Connect verwendet, führen Sie beide oben genannten Schritte aus (Sie können eine einzige UpdateService Anfrage verwenden). + Wenn Ihr Service keine der oben genannten Optionen verwendet, ist kein zusätzlicher Vorgang erforderlich. + Amazon blue/green ECS-Bereitstellungen erfordern, dass Ihr Service eine der folgenden Funktionen verwendet. 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). ## Verfahren 1. Öffnen Sie die Amazon-ECS-Konsole unter [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Klicken Sie im Navigationsbereich auf **Cluster**. 1. Wählen Sie auf der Seite **Cluster** den Cluster aus, der den Service enthält, den Sie migrieren möchten. Die Cluster-Detailseite wird angezeigt. 1. Wählen Sie auf der Seite **Cluster-Details** die Registerkarte **Protokolle** aus. 1. Wählen Sie den Service und dann **Aktualisieren**. Die Seite Service aktualisieren wird angezeigt 1. Erweitern Sie **Bereitstellungsoptionen** und führen Sie dann die folgenden Schritte aus: 1. Wählen Sie für **Bereitstellungsstrategie** die Option **Blau/Grün** aus. 1. Konfigurieren Sie die blue/green Bereitstellungseinstellungen: 1. Geben Sie für **Bake-Zeit** die Anzahl der Minuten ein, für die sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden, bevor die blaue Revision beendet wird. Dadurch bleibt Zeit für die Verifizierung und das Testen. 1. (Optional) Konfigurieren Sie Lambda-Funktionen so, dass sie in bestimmten Phasen der Bereitstellung ausgeführt werden. Konfigurieren Sie unter **Bereitstellungs-Lebenszyklus-Hooks** Lambda-Funktionen für die folgenden Phasen: + **Vor dem Hochskalieren**: Wird ausgeführt, bevor die grüne Service-Revision hochskaliert wird + **Nach dem Hochskalieren**: Wird ausgeführt, nachdem die grüne Service-Revision hochskaliert wird + **Verlagerung des Test-Datenverkehrs**: Wird ausgeführt, wenn der Test-Datenverkehr mit dem Routing zur grünen Service-Revision beginnt. + **Nach der Verlagerung des Test-Datenverkehrs**: Wird ausgeführt, nachdem der Test-Datenverkehr zur grünen Service-Revision geleitet wurde. + **Verlagerung des Produktionsdatenverkehrs**: Wird ausgeführt, wenn der Produktionsdatenverkehr mit dem Routing zur grünen Service-Revision beginnt. + **Nach der Verlagerung des Produktionsdatenverkehrs**: Wird ausgeführt, nachdem der Produktionsdatenverkehr zur grünen Service-Revision geleitet wird. So fügen Sie einen Lebenszyklus-Hook hinzu: 1. Wählen Sie **Hinzufügen** aus. 1. Geben Sie für **Lambda-Funktion** den Funktionsnamen oder ARN ein. 1. Wählen Sie für **Rolle** die IAM-Rolle, die berechtigt ist, die Lambda-Funktion aufzurufen. 1. Wählen Sie für **Lebenszyklusphasen** die Phasen aus, in denen die Lambda-Funktion ausgeführt werden soll. 1. Optional: Geben Sie für **Hook-Details** Schlüssel-Wert-Paare ein, um zusätzliche Informationen an den Hook bereitzustellen. 1. Konfigurieren Sie die Load-Balancer-Einstellungen: 1. Stellen Sie unter **Load Balancing** sicher, dass Ihr Service für die Verwendung eines Load Balancers konfiguriert ist. 1. Wählen Sie für **Zielgruppe** die primäre Zielgruppe für Ihre Produktionsumgebung (blau) aus. 1. Wählen Sie für **Alternative Zielgruppe** die Zielgruppe für Ihre Testumgebung (grün) aus. 1. Wählen Sie für **Produktions-Listener-Regel** die Listener-Regel für das Routing von Produktionsdatenverkehr aus. 1. Optional: Wählen Sie unter **Listener-Regel testen** eine Listener-Regel für das Routing von Test-Datenverkehr an Ihre grüne Umgebung aus. 1. Wählen Sie für **Rolle** die IAM-Rolle aus, die es Amazon ECS erlaubt, Ihren Load Balancer zu verwalten. 1. Überprüfen Sie die Konfigurationsänderungen und wählen Sie dann **Aktualisieren**. ## Nächste Schritte + Aktualisieren Sie den Service, um die Bereitstellung zu starten. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). + Überwachen Sie den Bereitstellungsprozess, um sicherzustellen, dass er dem blue/green Muster folgt: + Die grüne Service-Revision wurde erstellt und hochskaliert + Der Test-Datenverkehr wird an die grüne Revision weitergeleitet (falls konfiguriert) + Der Produktionsdatenverkehr verlagert sich auf die grüne Revision. + Nach Ablauf der Bake-Zeit wird die blaue Revision beendet # Aktualisierung der Bereitstellungsstrategie von Amazon ECS blue/green auf ein fortlaufendes Update Sie können eine blue/green Bereitstellung zu einer Bereitstellung mit fortlaufenden Updates migrieren. Beachten Sie bei der Migration zu fortlaufenden Bereitstellungen die folgenden Überlegungen: + **Verwaltung des Datenverkehrs**: Bei fortlaufenden Bereitstellungen erhalten neue Aufgaben Datenverkehr, sobald sie die Zustandsprüfungen bestanden haben. Es gibt keine separate Testphase wie bei blue/green Bereitstellungen. + **Ressourceneffizienz**: Rollende Bereitstellungen verbrauchen in der Regel weniger Ressourcen als blue/green Bereitstellungen, da sie Aufgaben schrittweise ersetzen, anstatt eine komplette duplizierte Umgebung zu erstellen. + **Rollback-Komplexität**: Rollbacks sind im Vergleich zu Bereitstellungen komplexer. blue/green Wenn Sie ein Rollback durchführen müssen, müssen Sie eine neue Bereitstellung mit der vorherigen Aufgabendefinition starten. + **Geschwindigkeit der Bereitstellung**: Rollende Bereitstellungen können länger dauern als blue/green Bereitstellungen, insbesondere bei Diensten mit vielen Aufgaben. + **Load-Balancer-Konfiguration**: Ihre bestehende Load-Balancer-Konfiguration funktioniert weiterhin mit fortlaufenden Bereitstellungen, aber das Verhalten der Datenverkehrsverlagerung wird anders sein. ## Voraussetzungen Bevor Sie Ihren Service von blue/green zu rollierenden Bereitstellungen migrieren, stellen Sie sicher, dass Sie über Folgendes verfügen: + Ein vorhandener Amazon ECS-Service, der die blue/green Bereitstellungsstrategie verwendet + Keine laufenden Bereitstellungen für den Service (warten Sie, bis alle aktuellen Bereitstellungen abgeschlossen sind) + Ein klares Verständnis davon, wie sich Ihr Service bei fortlaufenden Bereitstellungen verhalten wird **Anmerkung** Sie können einen Service nicht auf eine fortlaufende Bereitstellung migrieren, wenn er fortlaufend bereitgestellt wird. Warten Sie, bis alle aktuellen Bereitstellungen abgeschlossen sind, bevor Sie fortfahren. ## Migrationsprozess Gehen Sie wie folgt vor, um Ihren Amazon ECS-Service von blue/green zu rollierenden Bereitstellungen zu migrieren: 1. Öffnen Sie die Amazon-ECS-Konsole unter [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Klicken Sie im Navigationsbereich auf **Cluster**. 1. Wählen Sie auf der Seite **Cluster** den Cluster aus, der den Service enthält, den Sie migrieren möchten. 1. Wählen Sie auf der Seite **Cluster-Details** die Registerkarte **Protokolle** aus. 1. Wählen Sie den Service aus, den Sie migrieren möchten, und wählen Sie dann **Aktualisieren**. 1. Navigieren Sie auf der Seite **Service aktualisieren** zum Abschnitt **Bereitstellungsoptionen** und erweitern Sie ihn bei Bedarf. 1. Wählen Sie für **Bereitstellungsstrategie** die Option **Fortlaufende Aktualisierung** aus. 1. Konfigurieren Sie die Einstellungen für die fortlaufende Bereitstellung: 1. Geben Sie für **Minimaler fehlerfreier Prozentsatz** die Untergrenze für die Anzahl der Aufgaben an, die während einer Bereitstellung im Zustand `RUNNING` bleiben müssen. Dieser Wert wird als Prozentsatz der gewünschten Anzahl von Aufgaben für den Service angegeben. 1. Geben Sie für **Maximaler Prozentsatz** den maximalen Prozentsatz der Aufgaben ein, die während einer Bereitstellung im Status `RUNNING` oder `PENDING` zulässig sind. Dieser Wert wird als Prozentsatz der gewünschten Anzahl von Aufgaben für den Service angegeben. 1. Optional: Konfigurieren Sie unter **Erkennung von Bereitstellungsfehlern**, wie Amazon ECS Bereitstellungsfehler erkennt und behandelt: 1. Um den Bereitstellungs-Schutzschalter zu verwenden, wählen Sie **Amazon-ECS-Bereitstellungs-Schutzschalter verwenden** aus. 1. Um fehlgeschlagene Bereitstellungen automatisch rückgängig zu machen, wählen Sie **Rollback bei Fehler**. 1. Überprüfen Sie Ihre Konfigurationsänderungen und wählen Sie dann **Aktualisieren**, um Ihre Änderungen zu speichern und den Service auf eine fortlaufende Bereitstellung zu migrieren. Amazon ECS aktualisiert Ihre Service-Konfiguration, um die fortlaufende Bereitstellungsstrategie zu verwenden. Wenn Sie Ihren Service das nächste Mal aktualisieren, wird der fortlaufende Bereitstellungsprozess verwendet. **Anmerkung** Wenn Sie von einer fortlaufenden Bereitstellung blue/green zu einer fortlaufenden Bereitstellung migrieren, wickelt Amazon ECS den Übergang wie folgt ab: Identifizierung der aktuellen aktiven Service-Revision, die den Datenverkehr bereitstellt. Beibehaltung der bestehenden Load-Balancer-Konfiguration, aber Änderung der Art und Weise, wie neue Bereitstellungen verarbeitet werden. Vorbereitung des Services für zukünftige fortlaufende Bereitstellungen. ## Nächste Schritte + Aktualisieren Sie den Service, um die Bereitstellung zu starten. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). # Fehlerbehebung bei Aktualisierungen der Amazon-ECS-Bereitstellungsstrategie In diesem Abschnitt finden Sie Lösungen für häufig auftretende Probleme, die bei der Migration von Bereitstellungsstrategien auftreten können. ## Mehrere Service-Revisionen oder Aufgabensätze Die folgenden Probleme beziehen sich auf mehrere Service-Revisionen für eine Bereitstellung. Mehrere Aufgabensätze bei der Aktualisierung des ECS-Bereitstellungs-Controllers *Fehlermeldung*: `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, den Bereitstellungs-Controller-Typ eines Services mit mehreren aktiven Aufgabensätzen zu ändern. So beheben Sie dieses Problem für den `CODE_DEPLOY`- oder `EXTERNAL`-Bereitstellungs-Controller: 1. Überprüfen Sie die aktuellen Aufgabensätze: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets" ``` 1. Warten Sie, bis alle laufenden Bereitstellungen abgeschlossen sind. 1. Erzwingen Sie eine neue Bereitstellung zum Bereinigen von Aufgabensätzen: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment ``` 1. Löschen Sie bei Bedarf zusätzliche Aufgabensätze manuell: ``` aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id ``` 1. Wenn nur noch ein Aufgabensatz übrig ist, versuchen Sie erneut, den Bereitstellungs-Controller zu aktualisieren. Weitere Informationen finden Sie unter [Controller und Strategien für die Bereitstellung von Amazon-ECS-Services](ecs_service-options.md). Fehlender primärer Aufgabensatz beim Aktualisieren des `ECS`-Bereitstellungs-Controllers *Fehlermeldung*: `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, den Bereitstellungs-Controller-Typ eines Services zu ändern, der keinen primären Aufgabensatz hat. So beheben Sie dieses Problem 1. Überprüfen Sie den Service-Status und die Aufgabensätze. ). Wenn ein Aufgabensatz im Service vorhanden ist, sollte er als `ACTIVE` markiert werden. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id] ``` Wenn der `ACTIVE`-Status keine Aufgabensätze enthält, migrieren Sie die Bereitstellung. Weitere Informationen finden Sie unter [Migrationsansätze](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths). 1. Wenn der Service keine laufenden Aufgaben hat, stellen Sie mindestens eine Aufgabe bereit, indem Sie den Service aktualisieren: ``` aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id ``` Dadurch wird der (zuvor `ACTIVE`) Aufgabensatz im Service als `PRIMARY`-Status markiert. 1. Warten Sie, bis die Aufgabe einen stabilen Betriebsstatus erreicht hat. Sie können den Status überprüfen mit: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments" ``` 1. Versuchen Sie erneut, den Bereitstellungs-Controller zu aktualisieren, nachdem für den Service ein primärer Aufgabensatz mit laufenden Aufgaben festgelegt wurde. Weitere Informationen finden Sie unter [Controller und Strategien für die Bereitstellung von Amazon-ECS-Services](ecs_service-options.md). ## Nichtübereinstimmung zwischen dem Typ der Erkennung von Bereitstellungsfehlern und dem Bereitstellungs-Controller Die folgenden Probleme beziehen sich auf eine Nichtübereinstimmung zwischen dem Typ der Erkennung von Bereitstellungsfehlern und dem Bereitstellungs-Controller. Bereitstellungs-Schutzschalter mit einem anderen Controller, als ECS *Fehlermeldung*: `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, das Bereitstellungs-Schutzschalter-Feature für einen Service zu aktivieren, der nicht den `ECS`-Bereitstellungs-Controller verwendet. Der Bereitstellungs-Schutzschalter ist nur mit dem `ECS`-Bereitstellungs-Controller kompatibel. 1. Überprüfen Sie den aktuellen Bereitstellungs-Controller Ihres Services: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Aktualisieren Sie Ihren Service so, dass er den `ECS`-Bereitstellungs-Controller verwendet: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Nachdem der Service den `ECS`-Bereitstellungs-Controller verwendet, aktivieren Sie den Bereitstellungs-Schutzschalter: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" ``` Weitere Informationen finden Sie unter [So erkennt der Schutzschalter in Amazon ECS fehlgeschlagene Bereitstellungen](deployment-circuit-breaker.md). Alarmbasiertes Rollback mit einem anderen Controller, als ECS *Fehlermeldung*: `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, ein alarmbasiertes Rollback für einen Service zu konfigurieren, der nicht den `ECS`-Bereitstellungs-Controller verwendet. Das alarmbasierte Rollback-Feature ist nur mit dem `ECS`-Bereitstellungs-Controller kompatibel. 1. Überprüfen Sie den aktuellen Bereitstellungs-Controller Ihres Services: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Aktualisieren Sie Ihren Service so, dass er den `ECS`-Bereitstellungs-Controller verwendet: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Nachdem der Service den `ECS`-Bereitstellungs-Controller verwendet, konfigurieren Sie das alarmbasierte Rollback: ``` aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}" ``` Weitere Informationen finden Sie unter [So erkennen CloudWatch Alarme Bereitstellungsfehler bei Amazon ECS](deployment-alarm-failure.md). ## Nichtübereinstimmung zwischen Service Connect und dem Bereitstellungs-Controller Die folgenden Probleme beziehen sich auf eine Nichtübereinstimmung zwischen Service Connect und dem Bereitstellungs-Controller. `EXTERNAL`-Controller mit Service Connect *Fehlermeldung*: `The EXTERNAL deployment controller type is not supported for services using Service Connect.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, den `EXTERNAL`Bereitstellungs-Controller mit einem Service zu verwenden, für den Service Connect aktiviert ist. Der `EXTERNAL`-Controller ist nicht mit Service Connect kompatibel. 1. Prüfen Sie, ob Service Connect für Ihren Service aktiviert ist: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration" ``` 1. Wenn Sie den `EXTERNAL`-Bereitstellungs-Controller verwenden müssen, deaktivieren Sie Service Connect, indem Sie Ihren Service aktualisieren: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}" ``` 1. Wenn Sie Service Connect verwenden müssen, verwenden Sie alternativ den `ECS`-Bereitstellungs-Controller: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Weitere Informationen finden Sie unter [Controller und Strategien für die Bereitstellung von Amazon-ECS-Services](ecs_service-options.md). Service Connect mit einem anderen Controller, als ECS *Fehlermeldung*: `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, Service Connect auf einem Service zu aktivieren, der nicht den `ECS`-Bereitstellungs-Controller verwendet. Das Service-Connect-Feature ist nur mit dem `ECS`-Bereitstellungs-Controller kompatibel. 1. Überprüfen Sie den aktuellen Bereitstellungs-Controller Ihres Services: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Aktualisieren Sie Ihren Service so, dass er den ECS-Bereitstellungs-Controller verwendet: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Sobald der Service den ECS-Bereitstellungs-Controller verwendet, aktivieren Sie Service Connect: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace" ``` Weitere Informationen finden Sie unter [Controller und Strategien für die Bereitstellung von Amazon-ECS-Services](ecs_service-options.md). ## Nichtübereinstimmung zwischen Controller-Typ und Planungsstrategie Die folgenden Probleme beziehen sich auf eine Nichtübereinstimmung zwischen dem Controller-Typ und der Planungsstrategie. `CODE_DEPLOY`-Controller mit `DAEMON`-Planungsstrategie *Fehlermeldung*: `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, den CODE\$1DEPLOY-Bereitstellungs-Controller mit einem Service zu verwenden, der die `DAEMON`-Planungsstrategie verwendet. Der `CODE_DEPLOY`-Controller ist nur mit der `REPLICA`-Planungsstrategie kompatibel. 1. Überprüfen Sie die aktuelle Planungsstrategie Ihres Services: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. Wenn Sie blue/green Bereitstellungen benötigen, ändern Sie Ihren Service so, dass er die `REPLICA` Planungsstrategie verwendet: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. Wenn Sie die `DAEMON`-Planungsstrategie verwenden müssen, können Sie alternativ stattdessen den `ECS`-Bereitstellungs-Controller verwenden: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Weitere Informationen finden Sie unter [Controller und Strategien für die Bereitstellung von Amazon-ECS-Services](ecs_service-options.md). EXTERNAL-Controller mit DAEMON-Planungsstrategie *Fehlermeldung*: `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, den EXTERNAL-Bereitstellungs-Controller mit einem ECS-Service zu verwenden, der die DAEMON-Planungsstrategie verwendet. Der EXTERNAL-Controller ist nur mit der REPLICA-Planungsstrategie kompatibel. 1. Überprüfen Sie die aktuelle Planungsstrategie Ihres Services: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. Wenn Sie den `EXTERNAL`-Bereitstellungs-Controller verwenden müssen, ändern Sie Ihren Service so, dass er die `REPLICA`-Planungsstrategie verwendet: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. Wenn Sie die `DAEMON`-Planungsstrategie verwenden müssen, können Sie alternativ stattdessen den `ECS`-Bereitstellungs-Controller verwenden: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Weitere Informationen finden Sie unter [Controller und Strategien für die Bereitstellung von Amazon-ECS-Services](ecs_service-options.md). Service-Registrys mit externem Starttyp *Fehlermeldung*: `Service registries are not supported for external launch type.` *Lösung*: Dieser Fehler tritt auf, wenn versucht wird, die Serviceerkennung (Service-Registrys) für einen Service zu konfigurieren, der den `EXTERNAL`-Starttyp verwendet. Die Serviceerkennung ist nicht mit dem `EXTERNAL`-Starttyp kompatibel. 1. Überprüfen Sie den aktuellen Starttyp Ihres Services: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType" ``` 1. Wenn Sie die Serviceerkennung benötigen, ändern Sie Ihren Service so, dass er entweder den Starttyp `EC2` oder `FARGATE` verwendet: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE ``` 1. Wenn Sie den `EXTERNAL`-Starttyp verwenden müssen, können Sie alternativ die Service-Registry-Konfiguration entfernen: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]" ``` Weitere Informationen finden Sie unter [Controller und Strategien für die Bereitstellung von Amazon-ECS-Services](ecs_service-options.md). ## Eine Bereitstellungs-Controller-Aktualisierung zurücksetzen Wenn Sie zum vorherigen Bereitstellungs-Controller zurückkehren möchten, können Sie eine der folgenden Aktionen durchführen: + Falls Sie diese verwendet haben CloudFormation, können Sie die vorherige Vorlage verwenden, um einen neuen Stack zu erstellen. Weitere Informationen finden Sie unter [Erstellen eines Stacks aus](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) im *Benutzerhandbuch für CloudFormation *. + Wenn Sie die Amazon ECS-Konsole oder die verwendet haben AWS CLI, können Sie den Service aktualisieren. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). Wenn Sie den Befehl update-service verwenden, verwenden Sie die Option `--deployment-controller` und setzen Sie sie auf den vorherigen Bereitstellungs-Controller. # Anzeigen des Service-Verlaufs mithilfe von Service-Bereitstellungen in Amazon ECS Servicebereitstellungen bieten einen umfassenden Überblick über Ihre Bereitstellungen. Servicebereitstellungen liefern die folgenden Informationen zum Service: + Die aktuell bereitgestellte Workload-Konfiguration (die Revision des Quell-Services) + Die Workload-Konfiguration, die bereitgestellt wird (die Revision des Ziel-Services) + Bereitstellungsstatus + Die Anzahl der fehlgeschlagenen Aufgaben, die der Schutzschalter erkannt hat + Die CloudWatch Alarme, bei denen ein Alarm ausgelöst wurde + Wann die Servicebereitstellung gestartet und abgeschlossen wurde + Die Einzelheiten eines Rollbacks, falls eines stattgefunden hat Weitere Informationen zu den Eigenschaften der Servicebereitstellung finden Sie unter [Eigenschaften, die in einer Amazon-ECS-Servicebereitstellung enthalten sind](service-deployment-property.md). Servicebereitstellungen sind schreibgeschützt und haben jeweils eine eindeutige ID. Es gibt drei Phasen der Servicebereitstellung: | Stage | Definition | Zugeordneter Status | | --- | --- | --- | | Ausstehend | Eine Servicebereitstellung wurde erstellt, jedoch nicht gestartet | PENDING | | Kontinuierlich | Eine Servicebereitstellung wird ausgeführt | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-deployment.html) | | Completed | Eine Servicebereitstellung wurde abgeschlossen (erfolgreich oder erfolglos) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-deployment.html) | Mithilfe von Servicebereitstellungen können Sie den Lebenszyklus Ihres Service nachvollziehen und ermitteln, ob Sie Maßnahmen ergreifen müssen. Wenn beispielsweise ein Rollback stattgefunden hat, müssen Sie möglicherweise die Servicebereitstellung untersuchen und sich die Service-Ereignisse ansehen. Sie können den aktuellen Verlauf der letzten 90 Tage für Bereitstellungen, die am oder nach dem 25. Oktober 2024 erstellt wurden, mithilfe der Konsole, der API und der AWS CLI anzeigen. Sie können eine Bereitstellung anhalten, die noch nicht abgeschlossen wurde. Weitere Informationen finden Sie unter [Anhalten von Amazon-ECS-Servicebereitstellungen](stop-service-deployment.md). ## Lebenszyklus der Servicebereitstellung Amazon ECS erstellt automatisch eine neue Servicebereitstellung, wenn eine der folgenden Aktionen stattfindet: + Ein Benutzer erstellt einen Service. + Ein Benutzer aktualisiert den Service und verwendet die Option Neue Bereitstellung erzwingen. + Ein Benutzer aktualisiert eine oder mehrere Service-Eigenschaften, für die eine Bereitstellung erforderlich ist. Während einer laufenden Bereitstellung aktualisiert Amazon ECS die folgenden Eigenschaften der Servicebereitstellung, um den Fortschritt der Servicebereitstellung widerzuspiegeln: + Zustand + Anzahl der laufenden Aufgaben Die in der Service-Revision angegebene Anzahl der laufenden Aufgaben entspricht möglicherweise nicht der tatsächlichen Anzahl der laufenden Aufgaben. Diese Zahl steht für die Anzahl der Aufgaben, die nach Abschluss der Bereitstellung ausgeführt wurden. Wenn Sie beispielsweise Aufgaben unabhängig von der Service-Bereitstellung gestartet haben, sind diese Aufgaben nicht in der Anzahl der ausgeführten Aufgaben für die Service-Version enthalten. + Erkennung von Schutzschalter-Fehlern: + Die Anzahl der Aufgaben, bei denen der Start fehlgeschlagen ist + CloudWatch Erkennung von Alarm-Ausfällen + Die Alarme, die aktiv sind + Rollback-Informationen: + Die Startzeit + Der Grund für den Rollback + Der ARN der Service-Revision, die für das Rollback verwendet wurde + Der Grund des Statuss Amazon ECS löscht die Servicebereitstellung, wenn Sie einen Service löschen. ## Status der Servicebereitstellung Eine Servicebereitstellung beginnt im `PENDING`-Status. Die folgende Abbildung zeigt die Status der Servicebereitstellung, die nach dem `PENDING`-Status auftreten können: `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_IN_PROGRESSS`, `ROLLBACK_FAILED`, `ROLLBACK_SUCCESSFUL` und `STOPPED`. ![\[Die Status STOP_REQUESTED, SUCCESSFUL und ROLLBACK_IN_PROGRESS für die Servicebereitstellung, die auch nach dem Status IN_PROGRESS auftreten können.\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/images/service-deployment-states.png) Die folgenden Informationen enthalten Einzelheiten zu den Status der Servicebereitstellung: + `PENDING` – Die Servicebereitstellung wurde erstellt, jedoch nicht gestartet Der Status kann zu `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `STOP_REQUESTED` oder `STOPPED` wechseln. + `IN_PROGRESS` – Die Servicebereitstellung ist noch nicht abgeschlossen. Der Status kann zu `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_REQUESTED`, `ROLLBACK_IN_PROGRESS` und `STOPPED` wechseln. + `STOP_REQUESTED` – Der Status der Servicebereitstellung wechselt in den `STOP_REQUESTED`-Status, wenn einer der folgenden Fälle eintritt: + Ein Benutzer startet eine neue Servicebereitstellung. + Die Rollback-Option wird nicht für den Fehler-Erkennungsmechanismus (Schutzschalter oder Alarme) verwendet, und der Service erreicht den Status `SUCCESSFUL` nicht. Der Status wechselt zu `STOPPED`. + `ROLLBACK_REQUESTED` – Der Status der Servicebereitstellung wechselt in den `ROLLBACK_REQUESTED`-Status, wenn ein Benutzer ein Rollback über die Konsole, API oder CLI anfordert. Der Status kann zu `SUCCESSFUL`, `ROLLBACK_IN_PROGRESS` und `STOPPED` wechseln. + `SUCCESSFUL` – Der Status der Servicebereitstellung wechselt in den `SUCCESSFUL`-Status, wenn die Servicebereitstellung erfolgreich abgeschlossen wurde. + `ROLLBACK_IN_PROGRESS` – Der Servicebereitstellungsstatus geht in `ROLLBACK_IN_PROGRESS` über, wenn die Rollback-Option für den Fehlererkennungsmechanismus (Schutzschalter oder Alarme) verwendet wird und der Service ausfällt. Der Status wechselt zu `ROLLBACK_SUCCESSFUL` oder `ROLLBACK_FAILED`. # Eigenschaften, die in einer Amazon-ECS-Servicebereitstellung enthalten sind Die folgenden Eigenschaften sind in einer Servicebereitstellung enthalten. | Property (Eigenschaft) | Description (Beschreibung) | | --- | --- | | ARN der Servicebereitstellung | Der ARN der Servicebereitstellung. | | Service-ARN | Der ARN des Services für diese Servicebereitstellung. | | Cluster-ARN | Der ARN für den Cluster, der den Service hostet. | | Erstellungszeitpunkt der Servicebereitstellung | Der Zeitpunkt, zu dem die Servicebereitstellung erstellt wurde. | | Startzeit der Servicebereitstellung | Der Zeitpunkt, zu dem die Servicebereitstellung gestartet wurde. | | Abschlusszeit der Servicebereitstellung | Der Zeitpunkt, zu dem die Servicebereitstellung abgeschlossen wurde. | | Anhaltezeit der Servicebereitstellung | Der Zeitpunkt, zu dem die Servicebereitstellung angehalten wurde. | | Aktualisierungszeit der Servicebereitstellung | Der Zeitpunkt, zu dem die Servicebereitstellung zuletzt aktualisiert wurde. | | Revisionen des Quell-Service | Die aktuell ausgeführten Service-Revisionen. Weitere Informationen zu den enthaltenen Eigenschaften finden Sie unter [Eigenschaften, die in einer Amazon-ECS-Service-Revision enthalten sind](service-revision-property.md). | | Bereitstellungskonfiguration | Die Bereitstellungsparameter, einschließlich der Konfiguration des Schutzschalters und der entsprechenden Alarme.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-deployment-property.html) | | Revision des Ziel-Services | Die bereitzustellende Service-Revision. Nach erfolgreichem Abschluss der Bereitstellung ist die Ziel-Service-Revision die laufende Service-Revision. | | Status der Servicebereitstellung | Der Status der Servicebereitstellung.Die gültigen Werte sind PENDING, SUCCESSFUL, STOPPED, STOP\$1REQUESTED, STOP\$1IN\$1PROGRESS, IN\$1PROGRESS, ROLLBACK\$1IN\$1PROGRESS, ROLLBACK\$1SUCCESSFUL und ROLLBACK\$1FAILED. | | Informationen zum Status der Servicebereitstellung | Informationen darüber, warum die Servicebereitstellung im aktuellen Status ist. Beispielsweise hat der Schutzschalter einen Fehler erkannt. | | Rollback-Informationen | Die Rollback-Optionen, die die Servicebereitstellung verwendet, wenn die Bereitstellung fehlschlägt. | | Schutzschalter-Optionen für die Servicebereitstellung | Der Schutzschalter, der feststellt, dass eine Servicebereitstellung fehlgeschlagen ist. | | CloudWatch Alarme für die Bereitstellung des Dienstes | Die CloudWatch Alarme, die bestimmen, wann eine Servicebereitstellung fehlschlägt. | # Die erforderlichen Berechtigungen für die Anzeige von Amazon-ECS-Servicebereitstellungen Wenn Sie die bewährte Methode der geringsten Berechtigung befolgen, müssen Sie zusätzliche Berechtigungen hinzufügen, um Servicebereitstellungen in der Konsole anzuzeigen. Sie benötigen Zugriff auf die folgenden Aktionen: + ListServiceDeployments + DescribeServiceDeployments + DescribeServiceRevisions Sie benötigen Zugriff auf die folgenden Ressourcen: + Service + Servicebereitstellung + Service-Version Die folgende Beispielsrichtlinie enthält die erforderlichen Berechtigungen und beschränkt die Aktionen auf einen bestimmten Service. Ersetzen Sie `account`, `cluster-name` und `service-name` durch Ihre eigenen Werte. ------ #### [ JSON ] **** ``` { "Statement": [ { "Effect": "Allow", "Action": [ "ecs:ListServiceDeployments", "ecs:DescribeServiceDeployments", "ecs:DescribeServiceRevisions" ], "Resource": [ "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name", "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*", "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*" ] } ] } ``` ------ # Anzeigen von Amazon-ECS-Servicebereitstellungen Sie können den aktuellen Verlauf der letzten 90 Tage für Bereitstellungen anzeigen, die am oder nach dem 25. Oktober 2024 erstellt wurden. Die Servicebereitstellungen können in einem der folgenden Status sein: + In Bearbeitung + Ausstehend + Completed Anhand dieser Informationen können Sie feststellen, ob Sie die Art und Weise, wie der Service bereitgestellt wird, oder die Service-Revision aktualisieren müssen. Weitere Informationen zu den enthaltenen Eigenschaften finden Sie unter [Eigenschaften, die in einer Amazon-ECS-Servicebereitstellung enthalten sind](service-deployment-property.md). Bevor Sie beginnen, konfigurieren Sie die erforderlichen Berechtigungen für die Anzeige von Servicebereitstellungen. Weitere Informationen finden Sie unter [Die erforderlichen Berechtigungen für die Anzeige von Amazon-ECS-Servicebereitstellungen](service-deployment-permissions.md). ------ #### [ Amazon ECS Console ] 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Seite mit den Service-Details wird angezeigt. 1. Wählen Sie auf der Seite mit den Service-Details die Option **Bereitstellungen**. 1. Wählen Sie die Servicebereitstellung aus, die Sie anzeigen möchten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/view-service-deployment.html) Die Detailseite zur Servicebereitstellung wird angezeigt. 1. (Optional) Vergleichen Sie die Service-Revisionen, um die Unterschiede zu sehen. Wählen Sie unter **Service-Revisionen** die Option **Revisionen vergleichen** aus und wählen Sie dann 2 Revisionen aus, um sie zu vergleichen. Die Serviceversionen werden side-by-side mit hervorgehobenen Unterschieden angezeigt. ------ #### [ AWS CLI ] 1. Führen Sie `list-service-deployments` aus, um den ARN für die Servicebereitstellung abzurufen. Ersetzen Sie die Variablen durch Ihre eigenen Werte. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` Notieren Sie sich die serviceDeploymentArn für die Bereitstellung, die Sie anzeigen möchten. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. Führen Sie `describe-service-deployments`. Verwenden Sie den von `list-service-deployments` zurückgegebenen `serviceDeploymentArn`. Ersetzen Sie die Variablen durch Ihre eigenen Werte. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` ------ ## Nächste Schritte Sie können die Details zu Service-Revisionen in der Bereitstellung anzeigen. Weitere Informationen finden Sie unter [Anzeigen der Details zur Amazon-ECS-Service-Revision](view-service-revision.md). # Service-Versionen in Amazon ECS Eine Service-Version enthält einen Datensatz mit der Workload-Konfiguration, die Amazon ECS bereitzustellen versucht. Wann immer Sie einen Service erstellen oder bereitstellen, erstellt und erfasst Amazon ECS automatisch die Konfiguration, die Sie in der Service-Version bereitzustellen versuchen. Service-Revisionen sind schreibgeschützt und haben eindeutige Identifikatoren. Weitere Informationen zu den enthaltenen Eigenschaften finden Sie unter [Eigenschaften, die in einer Amazon-ECS-Service-Revision enthalten sind](service-revision-property.md). Service-Revisionen bieten die folgenden Vorteile: + Während einer Servicebereitstellung können Sie die aktuell bereitgestellte Service-Revision (Quelle) mit der Version (Ziel) vergleichen, die bereitgestellt wird. + Wenn Sie die Rollback-Option für eine Servicebereitstellung verwenden, setzt Amazon ECS die Servicebereitstellung automatisch auf die letzte erfolgreich bereitgestellte Service-Revision zurück. + Service-Revisionen enthalten den Datensatz der Workload-Konfiguration in einer Ressource. ## Service-Revision-Lebenszyklus Amazon ECS erstellt automatisch eine neue Service-Revision, wenn Sie einen Service erstellen oder eine Service-Eigenschaft aktualisieren, die eine Bereitstellung startet. Amazon ECS erstellt keine neue Service-Revision für einen Rollback-Vorgang. Amazon ECS verwendet die letzte erfolgreiche Service-Revision für das Rollback. Eine Service-Revision ist unveränderlich. Amazon ECS löscht die Service-Revision, wenn Sie einen Service löschen. Sie können Service-Revisionen, die am oder nach dem 25. Oktober 2024 erstellt wurden, mithilfe der Konsole, der API und der CLI anzeigen. # Eigenschaften, die in einer Amazon-ECS-Service-Revision enthalten sind Die folgenden Eigenschaften sind in einer Service-Revision enthalten. | Ressource | Description | | --- | --- | | Service-ARN | Der ARN, der den Service identifiziert. | | Cluster-ARN | Der ARN für den Cluster, der den Service hostet. | | ARN der Aufgabendefinition | Den ARN der Aufgabendefinition, die für die Service-Aufgaben verwendet wird. | | Service-Registrys | Die Details der Service-Registrys, die für die Serviceerkennung verwendet werden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Kapazitätsanbieter | Die Details der Kapazitätsanbieter-Strategie. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Container-Images | Die Details zu den Container-Images. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Netzwerk | Die Netzwerkkonfiguration für den Service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Starttyp | Die für den Service verwendete Rechenoption. | | Fargate-spezifische Eigenschaften | Bei der Verwendung von Fargate handelt es sich hierbei um Informationen zur Fargate-Version. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Amazon-EBS-Volumes, die bei der Bereitstellung konfiguriert werden. | Die Konfiguration für ein Volume, das in der Aufgabendefinition als Volume angegeben ist, das beim Start konfiguriert wird. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Service Connect | Die Service-Connect-Konfiguration [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Service Load Balancer | Die Load Balancer, die den Service-Datenverkehr weiterleiten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-revision-property.html) | | Laufzeitüberwachung | Zeigt an, ob die Laufzeitüberwachung aktiviert ist. | | Erstellungsdatum | Das Datum, an dem die Service-Revision erstellt wurde. | | VPC-Gitter | Die VPC-Lattice-Konfiguration für die Service-Revision. | # Anzeigen der Details zur Amazon-ECS-Service-Revision Sie können Informationen zu den folgenden Service-Revisionstypen einsehen, die am oder nach dem 25. Oktober 2024 erstellt wurden: + Quelle – Die aktuell bereitgestellte Workload-Konfiguration + Ziel – Die Workload-Konfiguration, die bereitgestellt wird ------ #### [ Amazon ECS Console ] 1. [Öffnen Sie die Konsole auf Version 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2) 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Seite mit den Service-Details wird angezeigt. 1. Wählen Sie auf der Seite mit den Service-Details die Option **Bereitstellungen**. 1. Wählen Sie die anzuzeigende Service-Version aus. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/view-service-revision.html) ------ #### [ AWS CLI ] 1. Führen Sie `describe-service-deployments` aus, um den ARN der Service-Revision abzurufen. Ersetzen Sie die Variablen durch Ihre eigenen Werte. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` Notieren Sie sich das `arn` für `sourceServiceRevisions` oder `targetServiceRevisions`. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "updatedAt": "2024-09-10T16:49:35.572000+00:00", "sourceServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "targetServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": false, "rollback": false }, "maximumPercent": 200, "minimumHealthyPercent": 100 } } ], "failures": [] } ``` 1. Führen Sie `describe-service-revisions`. Verwenden Sie den von `describe-service-deployments` zurückgegebenen `arn`. Ersetzen Sie die Variablen durch Ihre eigenen Werte. ``` aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095 ``` ------ # Ausgleichen eines Amazon-ECS-Service über Availability Zones hinweg Ab dem 5. September 2025 ermöglicht Amazon ECS den Neuausgleich der Availability Zone für alle Services, die für dieses Feature in Frage kommen. Ein Service ist berechtigt, wenn die Verteilung auf Availability Zones die erste Strategie zur Aufgabenplatzierung ist oder wenn es keine Platzierungsstrategie gibt. Damit Ihre Anwendungen eine hohe Verfügbarkeit erreichen, empfehlen wir, Ihre Multi-Task-Services so zu konfigurieren, dass sie in mehreren Availability Zones ausgeführt werden. Bei Diensten, deren erste Platzierungsstrategie auf Availability Zone verteilt AWS ist, wird versucht, die Serviceaufgaben gleichmäßig auf die verfügbaren Availability Zones zu verteilen. Es kann jedoch vorkommen, dass die Anzahl der Aufgaben, die in einer Availability Zone ausgeführt werden, nicht mit der Anzahl der Aufgaben in anderen Availability Zones übereinstimmt, beispielsweise nach der Unterbrechung einer Availability Zone. Um dieses Aufgabenungleichgewicht zu beheben, können Sie das Feature zur Neuausrichtung von Availability Zones aktivieren. Bei Nutzung der Funktion zur Neuausrichtung von Availability Zones überwacht Amazon ECS für jeden Ihrer Services kontinuierlich die Verteilung der Aufgaben auf die Availability Zones. Wenn Amazon ECS eine ungleichmäßige Aufgabenverteilung feststellt, werden automatisch Maßnahmen zur Neuverteilung der Workload auf die Availability Zones ergriffen. In diesem Zuge werden neue Aufgaben in den Availability Zones mit den wenigsten Aufgaben gestartet und in den überlasteten Availability Zones werden Aufgaben beendet. Diese Neuverteilung verhindert, dass eine einzelne Availability Zone zu einer Fehlerquelle wird, und trägt dazu bei, die Gesamtverfügbarkeit Ihrer containerisierten Anwendungen aufrechtzuerhalten. Der automatisierte Prozess zur Neuausrichtung macht manuelle Eingriffe überflüssig, wodurch nach einem Vorfall eine schnellere Wiederherstellung möglich ist. Nachstehend finden Sie eine Übersicht über den Neuausgleich-Prozess der Availability Zone: 1. Amazon ECS beginnt mit der Überwachung eines Service, nachdem dieser den stabilen Status erreicht hat, und untersucht die Anzahl der Aufgaben, die in jeder Availability Zone ausgeführt werden. 1. Amazon ECS führt die folgenden Vorgänge durch, wenn es ein Ungleichgewicht in der Anzahl der in jeder Availability Zone ausgeführten Aufgaben feststellt: + Sendet ein Service-Ereignis, das darauf hinweist, dass der Neuausgleich der Availability Zone beginnt. + Startet Aufgaben in Availability Zones mit der geringsten Anzahl von ausgeführten Aufgaben + Stoppt Aufgaben in Availability Zones mit der größten Anzahl von ausgeführten Aufgaben + Der Scheduler wartet, bis die neu gestarteten Aufgaben `HEALTHY` und `RUNNING` sind, bevor er die Aufgaben in der überskalierten Availability Zone anhält. + Sendet ein Service-Ereignis mit dem Ergebnis des Neuausgleichs der Availability Zone. ## So erkennt Amazon ECS eine ungleichmäßige Aufgabenverteilung Amazon ECS ermittelt ein Ungleichgewicht in der Anzahl der Aufgaben, die in jeder Availability Zone ausgeführt werden, indem die Anzahl der gewünschten Aufgaben des Service durch die Anzahl der konfigurierten Availability Zones dividiert wird. Wenn sich die gewünschte Anzahl an Aufgaben nicht gleichmäßig verteilt, verteilt Amazon ECS die restlichen Aufgaben gleichmäßig auf die konfigurierten Availability Zones. Jede Availability Zone muss mindestens eine Aufgabe haben. Stellen Sie sich zum Beispiel einen Amazon-ECS-Service mit einer gewünschten Anzahl von zwei Aufgaben vor, die für zwei Availability Zones konfiguriert sind. In diesem Szenario verteilt sich die gewünschte Anzahl an Aufgaben gleichmäßig. Eine ausgewogene Verteilung würde aus einer Aufgabe pro Availability Zone bestehen. Wenn es zwei Aufgaben in Availability Zone 1 und keine Aufgaben in Availability Zone 2 gibt, würde Amazon ECS den Neuausgleich einleiten, indem es eine Aufgabe in Availability Zone 2 startet, bevor eine Aufgabe in Availability Zone 1 gestoppt wird. Stellen Sie sich nun einen Amazon-ECS-Service mit einer gewünschten Anzahl von drei Aufgaben vor, die für zwei Availability Zones konfiguriert sind. In diesem Szenario verteilt sich die gewünschte Anzahl an Aufgaben nicht gleichmäßig. Eine ausgewogene Verteilung würde aus einer Aufgabe in Availability Zone 1 und zwei Aufgaben in Availability Zone 2 bestehen, da jede Availability Zone über mindestens eine Aufgabe verfügt und die restliche Aufgabe in Availability Zone 2 platziert wird. Stellen Sie sich einen Amazon-ECS-Service vor, bei dem die gewünschte Anzahl von fünf Aufgaben für drei Availability Zones konfiguriert ist. In diesem Szenario verteilt sich die gewünschte Anzahl an Aufgaben nicht gleichmäßig. Eine ausgewogene Verteilung würde aus einer Aufgabe in der Availability Zone 1 und jeweils zwei Aufgaben in den Availability Zones 2 und 3 bestehen. Nach Berücksichtigung jeder Availability Zone mit jeweils einer Aufgabe werden die beiden verbleibenden Aufgaben gleichmäßig auf die Availability Zones verteilt. ## Überlegungen für die Konfiguration des Availability-Zone-Neuausgleichs Berücksichtigen Sie Folgendes, wenn Sie den Availability-Zone-Neuausgleich konfigurieren möchten: + Availability-Zone-Neuausgleich unterstüzt Fargate- und EC2-Kapazitätsanbieter und wird in Amazon ECS Managed Instances unterstützt. Für Fargate verteilt Amazon ECS die Aufgaben automatisch auf die verfügbaren Availability Zones, um das Gleichgewicht zu halten. Für EC2-Kapazitätsanbieter verteilt Amazon ECS die Aufgaben auf bestehende Container-Instances nach bestem Wissen und unter Berücksichtigung Ihrer definierten Platzierungsstrategien und -einschränkungen. Amazon ECS kann jedoch im Rahmen des Neuausgleich-Prozesses keine neuen Instances in nicht ausgelasteten Availability Zones starten, wodurch der Neuausgleich auf bestehende Container-Instances beschränkt wird. + Der Availability-Zone-Neuausgleich funktioniert in den folgenden Konfigurationen: + Services, die die `Replica`-Strategie verwenden + Services, die die Verteilung auf Availability Zones als erste Strategie für die Aufgabenverteilung angeben oder keine Platzierungsstrategie angeben. + Sie können den Availability-Zone-Neuausgleich nicht für Services verwenden, die eines der folgenden Kriterien erfüllen: + Verwendet die `Daemon`-Strategie + Verwendet den `EXTERNAL`-Starttyp (ECS Anywhere) + Verwendet 100 % für den `maximumPercent`-Wert + Verwendet einen Classic Load Balancer + Verwendet `attribute:ecs.availability-zone` als Einschränkung bei die Aufgabenplatzierung ## Platzierungsstrategien und Platzierungsbeschränkungen beim Availability-Zone-Neuausgleich Platzierungsstrategien bestimmen, wie Amazon ECS Container-Instances und Availability Zones für die Beendigung der Aufgabenplatzierung auswählt. Einschränkungen bei der Aufgabenplatzierung sind Regeln, die festlegen, ob eine Aufgabe auf einer bestimmten Container-Instance ausgeführt werden darf. Für EC2 können Sie Platzierungsstrategien und Platzierungsbeschränkungen in Verbindung mit dem Availability-Zone-Neuausgleich verwenden. Damit der Availability-Zone-Neuausgleich funktioniert, muss die Strategie zur Verteilung der Availability Zone jedoch als erste Strategie angegeben werden. Der Availability-Zone-Neuausgleich ist mit verschiedenen Kombinationen von Platzierungsstrategien kompatibel. Sie können beispielsweise eine Strategie erstellen, die zuerst Aufgaben gleichmäßig auf Availability Zones verteilt und anschließend basierend auf dem Arbeitsspeicher innerhalb der einzelnen Availability Zone Aufgaben in einem Bin verpackt. In diesem Fall funktioniert der Availability-Zone-Neuausgleich, weil zuerst die Verteilungsstrategie der Availability Zone festgelegt wird. Es ist wichtig zu beachten, dass der Availability-Zone-Neuausgleich nicht funktioniert, wenn es sich bei der ersten Strategie in der Platzierungsstrategie nicht um eine Verteilungskomponente für die Availability Zone handelt. Diese Anforderung stellt sicher, dass das Hauptaugenmerk der Aufgabenverteilung auf der Aufrechterhaltung des Gleichgewichts zwischen den Availability Zones liegt, was für eine hohe Verfügbarkeit von entscheidender Bedeutung ist. Weitere Informationen zu Aufgabenplatzierungs-Strategien und -Einschränkungen, finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md). Aufgabenplatzierungs-Strategien und -Beschränkungen werden für Aufgaben mit Fargate nicht unterstützt. Fargate wird sich bemühen, Aufgaben über zugängliche Availability Zones zu verteilen. Wenn der Kapazitätsanbieter sowohl Fargate als auch Fargate Spot umfasst, ist das Verteilungsverhalten für jeden Kapazitätsanbieter unabhängig. Im folgenden Beispiel werden Aufgaben gleichmäßig auf Availability Zones verteilt und anschließend basierend auf dem Arbeitsspeicher in jeder Availability Zone in einem Bin verpackt. Der Availability-Zone-Neuausgleich ist mit dem Service kompatibel, da die `spread`-Strategie an erster Stelle steht. ``` "placementStrategy": [ { "field": "attribute:ecs.availability-zone", "type": "spread" }, { "field": "memory", "type": "binpack" } ] ``` ## Availability-Zone-Neuausgleich aktivieren Sie müssen den Availability-Zone-Neuausgleich für neue und bestehende Services aktivieren. Sie können das Rebalancing der Availability Zone mithilfe der Konsole, APIs AWS CLI, und aktivieren und CloudFormation deaktivieren. Das Standardverhalten von `AvailabilityZoneRebalancing` unterscheidet sich zwischen Erstellungs- und Aktualisierungsanforderungen: + Wenn bei Service-Erstellungsanforderungen kein Wert für `AvailabilityZoneRebalancing` angegeben ist, setzt Amazon ECS den Wert standardmäßig auf `ENABLED`. + Wenn bei Service-Aktualisierungsanforderungen kein Wert für `AvailabilityZoneRebalancing` angegeben ist, setzt Amazon ECS den Wert standardmäßig auf den `AvailabilityZoneRebalancing`-Wert des vorhandenen Service. Wenn für den Service nie ein `AvailabilityZoneRebalancing`-Wert festgelegt wurde, behandelt Amazon ECS diesen als `DISABLED`. | Servicetyp | API | Konsole | CLI | | --- | --- | --- | --- | | Vorhandene | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) | [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md) | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | | Neu | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) | [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md) | [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | Im folgenden Beispiel wird gezeigt, wie der Service-Neuausgleich beim Erstellen eines neuen Services aktiviert wird: ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-definition:1 \ --desired-count 6 \ --availability-zone-rebalancing ENABLED ``` # Nachverfolgung des Availability-Zone-Neuausgleichs von Amazon ECS Sie können überprüfen, ob der Availability-Zone-Neuausgleich für einen Service aktiviert ist, indem Sie die Konsole oder `describe-services` aufrufen. Das folgende Beispiel kann verwendet werden, um den Status mit der CLI zu sehen. Die Antwort lautet entweder `ENABLED` oder `DISABLED`. ``` aws ecs describe-services \ --services service-name \ --cluster cluster-name \ --query services[0].availabilityZoneRebalancing ``` ## Service-Ereignisse Amazon ECS sendet Service-Aktionsereignisse, um Ihnen einen Überblick über den Neuausgleich-Lebenszyklus der Availability Zone zu geben. | Veranstaltung | Szenario | Typ | Weitere Informationen | | --- | --- | --- | --- | | SERVICE\$1REBALANCING\$1STARTED | Amazon ECS startet einen Vorgang zum Availability-Zone-Neuausgleich. | INFO | [service (*service-name*) ist nicht ausgewogen mit *number-tasks* Aufgaben in, in und in*Availability Zone 1*. *number-tasks* *Availability Zone 2* *number-tasks* *Availability Zone 3* Der AZ-Neuausgleich wird ausgeführt.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | | SERVICE\$1REBALANCING\$1COMPLETED | Der Vorgang zum Availability-Zone-Neuausgleich wird abgeschlossen. | INFO | [service (*service-name*) ist AZ-ausgewogen mit *number-tasks* Aufgaben in*Availability Zone 1*, *number-tasks* Aufgaben in *Availability Zone 2* und *number-tasks* Aufgaben in*Availability Zone 3*.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | | TASKS\$1STARTED | Amazon ECS startet erfolgreich Aufgaben im Rahmen des Vorgangs zum Availability-Zone-Neuausgleich. | INFO | [*service-name*hat *number-tasks* Aufgaben in *Availability Zone* AZ Rebalance: *task-ids* gestartet.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | | TASKS\$1STOPPED | Amazon ECS stoppt erfolgreich Aufgaben im Rahmen des Vorgangs zum Availability-Zone-Neuausgleich. | INFO | [*service-name*hat die *number-tasks* Ausführung von Aufgaben *Availability Zone* aufgrund eines AZ-Rebalancing beendet:. *task-id*](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | | SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS konnte eine Aufgabe im Rahmen des Vorgangs zum Availability-Zone-Neuausgleich nicht starten. | ERROR | Informationen zu EC2 finden Sie unter [service (*service-name*) kann eine Aufgabe nicht platzieren, *Availability Zone* da keine Container-Instance alle ihre Anforderungen erfüllt hat.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) Informationen zu Fargate finden Sie unter [service (*service-name*) kann eine Aufgabe nicht platzieren. *Availability Zone*](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) | | TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | Der Vorgang zum Availability-Zone-Neuausgleich wurde blockiert, da der Aufgabenschutz verwendet wird. | INFO | [service (*service-name*) konnte AZ Rebalance nicht durchführen, da aufgrund von nicht skaliert werden *task-set-name* konnte. *reason*](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | | SERVICE\$1REBALANCING\$1STOPPED | Der Vorgang zum Availability-Zone-Neuausgleich wurde angehalten. Amazon ECS sendet zusätzliche Ereignisse, die weitere Informationen liefern. | INFO | [service (*service-name*) hat AZ Rebalancing gestoppt.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | ## Änderungsereignisse des Aufgabenstatus Amazon ECS sendet für jede Aufgabe, die es im Rahmen des Neuausgleichs startet, ein Ereignis zur Änderung des Aufgabenstatus (`START`). Amazon ECS sendet für jede Aufgabe, die es im Rahmen des Neuausgleichs stoppt, ein Ereignis zur Änderung des Aufgabenstatus (`STOPPED`). Der Grund ist auf `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)` eingestellt. Weitere Informationen zu Ereignissen finden Sie unter [Statussänderungs-Ereignisse für Amazon-ECS-Aufgaben](ecs_task_events.md). ## Fehlerbehebung bei Service-Neuausgleich Wenn Sie Probleme mit dem Neuausgleich von Services haben, sollten Sie die folgenden Schritte zur Fehlerbehebung in Betracht ziehen: Der Neuausgleich startet nicht Vergewissern Sie sich, dass folgende Bedingungen erfüllt sind: + Der Service-Neuausgleich ist für Ihren Service aktiviert + Ihr Service verwendet eine unterstützte Konfiguration (siehe [Überlegungen für die Konfiguration des Availability-Zone-Neuausgleichs](#service-rebalancing-configurations)). + Ihr Service hat einen stabilen Status erreicht. Fehler bei der Aufgabenplatzierung beim Neuausgleich Wenn Sie `SERVICE_TASK_PLACEMENT_FAILURE`-Ereignisse sehen: + Für EC2: Prüfen Sie, ob Container-Instances in der Ziel-Availability-Zone verfügbar sind. + Für Fargate: Prüfen Sie, ob es Ressourcenbeschränkungen oder Service Quotas gibt, die die Aufgabenplatzierung einschränken + Überprüfen Sie Ihre Einschränkungen bei der Aufgabenplatzierung, um sicherzustellen, dass sie die ordentliche Aufgabenverteilung nicht verhindern Der Neuausgleich wird unerwartet angehalten Wenn Sie `SERVICE_REBALANCING_STOPPED`-Ereignisse sehen: + Suchen Sie nach einem Aufgabenschutz, der den Vorgang möglicherweise blockiert. + Halten Sie Ausschau nach gleichzeitigen Service-Bereitstellungen, die den Neuausgleich unterbrechen könnten. + Überprüfen Sie die Service-Ereignisse für weitere Informationen darüber, warum der Neuausgleich angehalten wurde ## Bewährte Methoden für den Service-Neuausgleich Befolgen Sie diese bewährten Methoden, um den Service-Neuausgleich optimal einzusetzen. + **Überwachung von Rebalancing-Vorgängen** — Richten Sie CloudWatch Alarme ein, um Serviceereignisse im Zusammenhang mit dem Rebalancing zu überwachen und Probleme schnell zu erkennen. + **Auswirkungen auf die Leistung berücksichtigen** – Seien Sie sich bewusst, dass Neuausgleichsvorgänge vorübergehend die Ressourcenauslastung erhöhen können, da neue Aufgaben gestartet werden, bevor alte beendet werden. + **Strategischer Einsatz von Aufgabenschutz** – Wenn Sie kritische Aufgaben haben, die beim Neuausgleich nicht beendet werden sollten, sollten Sie den Aufgabenschutz in Erwägung ziehen. + **EC2-Kapazität einplanen** – Stellen Sie für EC2 sicher, dass Sie über genügend Container-Instances in allen Availability Zones verfügen, um einen effektiven Neuausgleich zu unterstützen. + **Verhalten beim Neuausgleich testen** – Bevor Sie einen Neuausgleich in der Produktion einsetzen, sollten Sie testen, wie sich Ihre Services bei Neuausgleichsvorgängen in einer Nicht-Produktionsumgebung verhalten. # Verwenden von Load Balancing für die Verteilung des Service-Datenverkehrs in Amazon ECS Ihr Service kann optional zur Verwendung von Elastic Load Balancing konfiguriert werden, um Datenverkehr gleichmäßig auf die Aufgaben in Ihrem Service zu verteilen. **Anmerkung** Wenn Sie Aufgabensätze verwenden, müssen alle Aufgaben im Satz so konfiguriert sein, dass sie entweder Elastic Load Balancing verwenden oder Elastic Load Balancing nicht verwenden. Amazon ECS-Services, die auf gehostet werden, AWS Fargate unterstützen die Application Load Balancers, Network Load Balancers und Gateway Load Balancers. In der folgenden Tabelle erfahren Sie, welche Art von Load Balancer Sie verwenden sollten. | Load-Balancer-Typ | Verwenden Sie in diesen Fällen | | --- | --- | | Application Load Balancer | Leiten Sie den HTTP/HTTPS Verkehr weiter (oder auf Layer 7).Application Load Balancers bieten verschiedene Features an, die sie besonders attraktiv für die Verwendung mit Amazon-ECS-Services machen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/service-load-balancing.html) | | Network Load Balancer | Weiterleiten von TCP- oder UDP (oder Ebene 4)-Datenverkehr. | | Gateway Load Balancer | Weiterleiten von TCP- oder UDP (oder Ebene 4)-Datenverkehr. Verwenden Sie virtuelle Anwendungen wie Firewalls, Systeme zur Angriffserkennung und -Abwehr und Deep-Packet-Inspektionssysteme. | Wir empfehlen, dass Sie für Ihre Amazon-ECS-Services Application Load Balancers verwenden, damit Sie diese neuesten Features nutzen können, außer wenn Ihr Service ein Feature benötigt, das nur mit Network Load Balancers oder Gateway Load Balancers verfügbar ist. Weitere Informationen über Elastic Load Balancing und die Unterschiede zwischen den Load Balancer-Typen finden Sie unter [Benutzerhandbuch für Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/). Mit Ihrem Load Balancer zahlen Sie nur für das, was Sie auch tatsächlich nutzen. Weitere Informationen finden Sie unter [Elastic Load Balancing Pricing](https://aws.amazon.com/elasticloadbalancing/pricing/). # Optimieren der Parameter der Load-Balancer-Zustandsprüfung für Amazon ECS Jeder Load-Balancer-Knoten leitet Anfragen nur an die fehlerfreien Ziele in den Availability Zones des Load Balancer. Jedes Ziel ist bei einer Zielgruppe registriert. Der Load Balancer überprüft den Zustand jedes Ziels mit den Zustandsprüfungseinstellungen für die Zielgruppe. Nachdem Ihr Ziel registriert wurde, muss es eine Zustandsprüfung bestehen, um als fehlerfrei eingestuft zu werden. Amazon ECS überwacht den Load Balancer. Der Load Balancer sendet regelmäßig Zustandsprüfungen an den Amazon-ECS-Container. Der Amazon-ECS-Agent überwacht den Zustand des Containers und wartet darauf, dass der Load Balancer Bericht erstattet. Dies geschieht, bevor der Container als fehlerfrei eingestuft wird. Zwei Parameter der Zustandsprüfung für Elastic Load Balancing wirken sich auf die Bereitstellungsgeschwindigkeit aus: + Zustandsprüfungsintervall: Bestimmt das ungefähre Intervall in Sekunden zwischen den Zustandsprüfungen eines einzelnen Containers. Standardmäßig überprüft der Load Balancer alle 30 Sekunden. Dieser Parameter wird angegeben als: + `HealthCheckIntervalSeconds` in der Elastic Load Balancing API + **Intervall** in der Amazon-EC2-Konsole + Anzahl fehlerfreier Schwellenwerte: Bestimmt die Anzahl der erforderlichen aufeinanderfolgenden Zustandsprüfungen, bevor ein Container als fehlerfrei betrachtet wird. Standardmäßig benötigt der Load Balancer fünf bestandene Zustandsprüfungen, bevor er meldet, dass der Ziel-Container fehlerfrei ist. Dieser Parameter wird angegeben als: + `HealthyThresholdCount` in der Elastic Load Balancing API + **Fehlerfreier Schwellenwert** in der Amazon-EC2-Konsole **Wichtig:** Bei neu registrierten Zielen ist nur eine einzige erfolgreiche Zustandsprüfung erforderlich, um das Ziel als fehlerfrei zu bewerten, unabhängig von der Einstellung für die Anzahl fehlerfreier Schwellenwerte. Die Anzahl fehlerfreier Schwellenwerte gilt nur, wenn ein Ziel von einem fehlerhaften Zustand wieder in einen fehlerfreien Zustand übergeht. Mit den Standardeinstellungen beträgt die Gesamtzeit zur Bestimmung des Zustand eines Containers zwei Minuten und 30 Sekunden (`30 seconds * 5 = 150 seconds`), wenn ein Ziel fehlerhaft wird und sich dann wieder erholt. Sie können den Prozess der Zustandsprüfung beschleunigen, wenn Ihr Service in weniger als 10 Sekunden startet und sich stabilisiert. Um den Prozess zu beschleunigen, reduzieren Sie das Intervall für die Zustandsprüfung und die Anzahl der fehlerfreien Schwellenwerte. + `HealthCheckIntervalSeconds` (API-Name des Elastic Load Balancing) oder **Interval** (Name der Amazon-EC2-Konsole): 5 + `HealthyThresholdCount` (API-Name des Elastic Load Balancing) oder **Fehlerfreier Schwellenwert** (Name der Amazon-EC2-Konsole): 2 Mit dieser Einstellung dauert der Prozess der Zustandsprüfung 10 Sekunden im Vergleich zur Standardeinstellung von zwei Minuten und 30 Sekunden. Weitere Informationen zu den Parametern der Zustandsprüfungen für Elastic Load Balancing finden Sie unter [Zustandsprüfungen für Ihre Zielgruppen](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) im *Benutzerhandbuch für Elastic Load Balancing*. # Die Parameter des Connection Draining der Load Balancer für Amazon ECS optimieren Um eine Optimierung zu ermöglichen, halten die Clients eine permanente Verbindung zum Container-Service aufrecht. Auf diese Weise können nachfolgende Anfragen von diesem Client die bestehende Verbindung wiederverwenden. Wenn Sie den Datenverkehr zu einem Container anhalten möchten, benachrichtigen Sie den Load Balancer. Der Load Balancer überprüft regelmäßig, ob der Client die aufrechte Verbindung getrennt hat. Amazon ECS überwacht den Load Balancer und wartet darauf, dass der Load Balancer meldet, dass die aufrechte Verbindung getrennt ist (das Ziel befindet sich in einem `UNUSED`-Status). Die Zeitspanne, die der Load Balancer darauf wartet, das Ziel in den `UNUSED`-Status zu versetzen, entspricht der Verzögerung bei der Abmeldung. Sie können den folgenden Load-Balancer-Parameter konfigurieren, um Ihre Bereitstellungen zu beschleunigen. + `deregistration_delay.timeout_seconds`: 300 (Standard) Wenn Sie einen Service mit einer Antwortzeit unter 1 Sekunde haben, setzen Sie den Parameter auf den folgenden Wert, damit der Load Balancer nur 5 Sekunden wartet, bevor er die Verbindung zwischen dem Client und dem Backend-Service unterbricht: + `deregistration_delay.timeout_seconds`: 5 **Anmerkung** Setzen Sie den Wert nicht auf 5 Sekunden, wenn Sie einen Service mit lang anhaltenden Anfragen haben, wie z. B. langsame Datei-Uploads oder Streaming-Verbindungen. ## SIGTERM-Reaktionsfähigkeit Amazon ECS sendet zunächst ein Stoppsignal an die Aufgabe, um zu benachrichtigen, dass die Anwendung beendet und heruntergefahren werden muss. Dieses Signal kann in Ihrem Container-Image mit der STOPSIGNAL-Anweisung definiert werden und wird standardmäßig auf SIGTERM gesetzt. Dann sendet Amazon ECS eine SIGKILL-Nachricht. Wenn Anwendungen den SIGTERM ignorieren, muss der Amazon-ECS-Service warten, bis das SIGKILL-Signal gesendet wird, um den Prozess zu beenden. Wie lange Amazon ECS auf das Senden der SIGKILL-Nachricht wartet, wird durch die folgende Amazon-ECS-Agentenoption bestimmt: + `ECS_CONTAINER_STOP_TIMEOUT`: 30 (Standard) Weitere Informationen zum Container-Agent-Parameter finden Sie unter [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) on GitHub. Um die Wartezeit zu verkürzen, setzen Sie den Amazon-ECS-Agentenparameter auf den folgenden Wert: + `ECS_CONTAINER_STOP_TIMEOUT`: 2 Wenn Ihre Anwendung länger als 1 Sekunde benötigt, multiplizieren Sie den Wert mit 2 und verwenden Sie diese Zahl als Wert. In diesem Fall wartet Amazon ECS 2 Sekunden, bis der Container heruntergefahren wird, und Amazon ECS sendet dann eine SIGKILL-Nachricht, wenn die Anwendung nicht gestoppt wurde. Sie können den Anwendungscode auch ändern, um das SIGTERM-Signal abzufangen und darauf zu reagieren. Das Folgende ist ein Beispiel in JavaScript: ``` process.on('SIGTERM', function() { server.close(); }) ``` Dieser Code veranlasst den HTTP-Server, nicht mehr auf neue Anfragen zu lauschen und alle laufenden Anfragen zu beantworten. Dann wird der Prozess Node.js beendet, weil die Ereignisschleife nichts zu tun hat. Wenn der Prozess also nur 500 ms benötigt, um seine laufenden Anfragen abzuschließen, wird er vorzeitig beendet, ohne dass der Stop-Timeout abgewartet und ein SIGKILL gesendet werden muss. # Einen Application Load Balancer für Amazon ECS verwenden Ein Application Load Balancer trifft Routing-Entscheidungen auf Anwendungsebene (HTTP/HTTPS), unterstützt pfadbasiertes Routing und kann Anfragen an einen oder mehrere Ports jeder Container-Instance in Ihrem Cluster weiterleiten. Application Load Balancer unterstützen dynamische Host-Port-Zuweisung. Wenn die Containerdefinition Ihrer Aufgabe beispielsweise Port 80 als NGINX-Container-Port and Port 0 als Host-Port angibt, wird der Host-Port dynamisch aus dem flüchtigen Port-Bereich der Container-Instance ausgewählt (z. B. 32768 bis 61000 beim aktuellen Amazon-ECS-optimierten AMI). Beim Start der Aufgabe wird der NGINX-Container bei dem Application Load Balancer als Instance-ID und Port-Kombination registriert, und der Datenverkehr wird an die Instance-ID und den Port verteilt, die diesem Container entsprechen. Aufgrund dieser dynamischen Zuordnung können Sie mehrere Aufgaben über einen einzelnen Service auf derselben Container-Instance durchführen. Weitere Informationen finden Sie im [Benutzerhandbuch für Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/). Informationen zu den bewährten Methoden für die Festlegung von Parametern zur Beschleunigung Ihrer Bereitstellungen finden Sie unter: + [Optimieren der Parameter der Load-Balancer-Zustandsprüfung für Amazon ECS](load-balancer-healthcheck.md) + [Die Parameter des Connection Draining der Load Balancer für Amazon ECS optimieren](load-balancer-connection-draining.md) Berücksichtigen Sie Folgendes, wenn Sie Application Load Balancer mit Amazon ECS verwenden: + Amazon ECS erfordert die service-verknüpfte IAM-Rolle, die die Berechtigungen bietet, die erforderlich sind, um Ziele bei Ihrem Load Balancer zu registrieren und abzumelden, wenn Aufgaben erstellt und gestoppt werden. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md). + Für Dienste in einer IPv6 Nur-Konfiguration müssen Sie den Zielgruppen-IP-Adresstyp des Application Load Balancer auf `dualstack` oder setzen. `dualstack-without-public-ipv4` + Für Services mit Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, müssen Sie beim Erstellen einer Zielgruppe für Ihren Service `ip` als Zieltyp auswählen, nicht `instance`. Das liegt daran, dass Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, mit einer Elastic-Network-Schnittstelle verknüpft sind, und nicht mit einer Amazon-EC2-Instance. + Wenn Ihr Dienst Zugriff auf mehrere Ports mit Lastenausgleich benötigt, z. B. Port 80 und Port 443 für einen HTTP/HTTPS Dienst, können Sie zwei Listener konfigurieren. Ein Listener ist für HTTPS verantwortlich, sodass die Anforderung an den Service weitergeleitet wird, und ein anderer Listener für die Umleitung von HTTP-Anforderungen an den entsprechenden HTTPS-Port. Weitere Informationen finden Sie [Erstellen eines Listeners für Ihren Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html) im *Benutzerhandbuch für Application Load Balancers*. + Die Subnetzkonfiguration Ihres Load Balancers muss alle Availability Zones enthalten, in denen sich Ihre Container-Instances befinden. + Nachdem Sie einen Dienst erstellt haben, kann die Load Balancer-Konfiguration von AWS-Managementkonsole nicht mehr geändert werden. Sie können den AWS Copilot AWS CLI oder das SDK verwenden AWS CloudFormation, um die Load Balancer-Konfiguration nur für den `ECS` Rolling Deployment Controller zu ändern, nicht AWS CodeDeploy für blau/grün oder extern. Wenn Sie eine Konfiguration für den Load Balancer hinzufügen, aktualisieren oder entfernen, startet Amazon ECS eine neue Bereitstellung mit der aktualisierten Konfiguration Elastic Load Balancing. Dies führt dazu, dass sich Aufgaben bei Load Balancern registrieren und von diesen abmelden. Wir empfehlen, dass Sie dies in einer Testumgebung überprüfen, bevor Sie die Konfiguration Elastic Load Balancing Balancing aktualisieren. Informationen zum Ändern der Konfiguration finden Sie [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*. + Wenn die Aufgabe eines Services die Zustandsprüfungskriterien des Load Balancers nicht besteht, wird die Aufgabe angehalten und neu gestartet. Dieser Prozess wird fortgesetzt, bis Ihr Service die Anzahl der gewünschten ausgeführten Aufgaben erreicht. + Informationen zu Problemen mit Services, für die ein Load Balancer aktiviert ist, finden Sie unter [Fehlerbehebung bei Service-Load Balancers in Amazon ECS](troubleshoot-service-load-balancers.md). + Wenn Sie den `instance`-Zieltyp verwenden, müssen sich Ihre Aufgaben und Ihr Load Balancer in derselben VPC befinden. Wenn Sie den `ip`-Zieltyp verwenden, wird die VPC-übergreifende Konnektivität unterstützt. + Verwenden Sie für jeden Service eine eindeutige Zielgruppe. Die Verwendung derselben Zielgruppe für mehrere Services kann zu Problemen bei der Servicebereitstellung führen. + Sie müssen Zielgruppen angeben, die einem Application Load Balancer zugeordnet sind. Weitere Informationen zum Erstellen eines Application Load Balancers finden Sie unter [Erstellen eines Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) in *Application Load Balancers*. # Einen Network Load Balancer für Amazon ECS verwenden Ein Network Load Balancer trifft Routing-Entscheidungen auf der Transportebene (TCP/SSL). Es können Millionen von Anfragen pro Sekunde verarbeitet werden. Nachdem der Load Balancer eine Verbindung erhalten hat, wählt er mithilfe eines Flow-Hash-Routing-Algorithmus ein Ziel aus der Zielgruppe für die Standardregel aus. Er versucht, eine TCP-Verbindung zu dem ausgewählten Ziel auf dem in der Listener-Konfiguration angegebenen Port zu öffnen. Es leitet die Anforderung ohne Ändern der Headers weiter. Network Load Balancer unterstützen dynamische Host-Port-Zuweisung. Wenn die Containerdefinition Ihrer Aufgabe beispielsweise Port 80 als NGINX-Container-Port and Port 0 als Host-Port angibt, wird der Host-Port dynamisch aus dem flüchtigen Port-Bereich der Container-Instance ausgewählt (z. B. 32768 bis 61000 beim aktuellen Amazon-ECS-optimierten AMI). Beim Start der Aufgabe wird der NGINX-Container bei dem Network Load Balancer als Instance-ID- und Port-Kombination registriert, und der Datenverkehr wird an die Instance-ID und den Port verteilt, die diesem Container entsprechen. Aufgrund dieser dynamischen Zuordnung können Sie mehrere Aufgaben über einen einzelnen Service auf derselben Container-Instance durchführen. Weitere Informationen finden Sie im [Benutzerhandbuch für Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/). Informationen zu den bewährten Methoden für die Festlegung von Parametern zur Beschleunigung Ihrer Bereitstellungen finden Sie unter: + [Optimieren der Parameter der Load-Balancer-Zustandsprüfung für Amazon ECS](load-balancer-healthcheck.md) + [Die Parameter des Connection Draining der Load Balancer für Amazon ECS optimieren](load-balancer-connection-draining.md) Beachten Sie Folgendes, wenn Sie Network Load Balancers mit Amazon ECS verwenden: + Amazon ECS erfordert die service-verknüpfte IAM-Rolle, die die Berechtigungen bietet, die erforderlich sind, um Ziele bei Ihrem Load Balancer zu registrieren und abzumelden, wenn Aufgaben erstellt und gestoppt werden. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md). + Sie können nicht mehr als fünf Zielgruppen an einen Service anhängen. + Für Dienste in einer IPv6 Nur-Konfiguration müssen Sie den Zielgruppen-IP-Adresstyp des Network Load Balancer auf einstellen. `dualstack` + Für Services mit Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, müssen Sie beim Erstellen einer Zielgruppe für Ihren Service `ip` als Zieltyp auswählen, nicht `instance`. Das liegt daran, dass Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, mit einer Elastic-Network-Schnittstelle verknüpft sind, und nicht mit einer Amazon-EC2-Instance. + Die Subnetzkonfiguration Ihres Load Balancers muss alle Availability Zones enthalten, in denen sich Ihre Container-Instances befinden. + Nachdem Sie einen Dienst erstellt haben, kann die Load Balancer-Konfiguration von AWS-Managementkonsole nicht mehr geändert werden. Sie können den AWS Copilot AWS CLI oder das SDK verwenden AWS CloudFormation, um die Load Balancer-Konfiguration nur für den `ECS` Rolling Deployment Controller zu ändern, nicht für blau/grün oder extern. AWS CodeDeploy Wenn Sie eine Konfiguration für den Load Balancer hinzufügen, aktualisieren oder entfernen, startet Amazon ECS eine neue Bereitstellung mit der aktualisierten Konfiguration Elastic Load Balancing. Dies führt dazu, dass sich Aufgaben bei Load Balancern registrieren und von diesen abmelden. Wir empfehlen, dass Sie dies in einer Testumgebung überprüfen, bevor Sie die Konfiguration Elastic Load Balancing Balancing aktualisieren. Informationen zum Ändern der Konfiguration finden Sie [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*. + Wenn die Aufgabe eines Services die Zustandsprüfungskriterien des Load Balancers nicht besteht, wird die Aufgabe angehalten und neu gestartet. Dieser Prozess wird fortgesetzt, bis Ihr Service die Anzahl der gewünschten ausgeführten Aufgaben erreicht. + Wenn Sie einen Gateway Load Balancer verwenden, bei dem IP-Adressen als Ziele konfiguriert sind und die Client IP Preservation deaktiviert ist, werden die Anfragen als von der privaten IP-Adresse des Gateway Load Balancers stammend angesehen. Das bedeutet, dass Services hinter einem Gateway Load Balancer effektiv für die Welt offen sind, sobald Sie eingehende Anforderungen und Zustandsprüfungen in der Sicherheitsgruppe des Ziels zulassen. + Für Fargate-Aufgaben müssen Sie die Plattformversion `1.4.0` (Linux) oder `1.0.0` (Windows) verwenden. + Informationen zu Problemen mit Services, für die ein Load Balancer aktiviert ist, finden Sie unter [Fehlerbehebung bei Service-Load Balancers in Amazon ECS](troubleshoot-service-load-balancers.md). + Wenn Sie den `instance`-Zieltyp verwenden, müssen sich Ihre Aufgaben und Ihr Load Balancer in derselben VPC befinden. Wenn Sie den `ip`-Zieltyp verwenden, wird die VPC-übergreifende Konnektivität unterstützt. + Die Erhaltung der Client-IP-Adresse des Network Load Balancer ist mit Fargate-Zielen kompatibel. + Verwenden Sie für jeden Service eine eindeutige Zielgruppe. Die Verwendung derselben Zielgruppe für mehrere Services kann zu Problemen bei der Servicebereitstellung führen. + Sie müssen Zielgruppen angeben, die einem Network Load Balancer zugeordnet sind. Informationen zum Erstellen eines Network Load Balancer finden Sie unter [Erstellen eines Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) in *Network Load Balancers*. **Wichtig** Wenn Ihre Service-Aufgabendefinition den Netzwerkmodus `awsvpc` verwendet (der für Fargate erforderlich ist), müssen Sie `ip` als Zieltyp verwenden, und nicht `instance`. Das liegt daran, dass Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, mit einer Elastic-Network-Schnittstelle verknüpft sind, und nicht mit einer Amazon-EC2-Instance. Sie können Instances nicht anhand der Instanz-ID registrieren, wenn sie die folgenden Instance-Typen haben: C1, CC1, CC2, CG1, CG2,, CR1, Instance-Typen haben: C1, HI1, HS1,,,, M2, M3 und T1. Sie können Instances dieser Arten nach IP-Adresse registrieren. # Einen Gateway Load Balancer für Amazon ECS verwenden Ein Gateway Load Balancer arbeitet auf der dritten Ebene des Open Systems Interconnection (OSI) -Modells, der Netzwerkschicht. Es überwacht alle IP-Pakete über alle Ports und leitet den Datenverkehr an die Zielgruppe weiter, die in der Listener-Regel angegeben ist. Mithilfe von 5-Tupeln (für Datenflüsse) oder 3-Tupeln (für TCP/UDP Nicht-TCP/UDP-Datenflüsse) wird die Bindung der Datenflüsse an eine bestimmte Ziel-Appliance aufrechterhalten. Wenn die Containerdefinition Ihrer Aufgabe beispielsweise Port 80 als NGINX-Container-Port and Port 0 als Host-Port angibt, wird der Host-Port dynamisch aus dem flüchtigen Port-Bereich der Container-Instance ausgewählt (z. B. 32768 bis 61000 beim aktuellen Amazon-ECS-optimierten AMI). Beim Start der Aufgabe wird der NGINX-Container bei dem Gateway Load Balancer als Instance-ID- und Port-Kombination registriert, und der Datenverkehr wird an die Instance-ID und den Port verteilt, die diesem Container entsprechen. Aufgrund dieser dynamischen Zuordnung können Sie mehrere Aufgaben über einen einzelnen Service auf derselben Container-Instance durchführen. Weitere Informationen finden Sie unter [Was ist ein Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) in *Gateway Load Balancers*. Informationen zu den bewährten Methoden für die Festlegung von Parametern zur Beschleunigung Ihrer Bereitstellungen finden Sie unter: + [Optimieren der Parameter der Load-Balancer-Zustandsprüfung für Amazon ECS](load-balancer-healthcheck.md) + [Die Parameter des Connection Draining der Load Balancer für Amazon ECS optimieren](load-balancer-connection-draining.md) Beachten Sie Folgendes, wenn Sie Gateway Load Balancers mit Amazon ECS verwenden: + Amazon ECS erfordert die service-verknüpfte IAM-Rolle, die die Berechtigungen bietet, die erforderlich sind, um Ziele bei Ihrem Load Balancer zu registrieren und abzumelden, wenn Aufgaben erstellt und gestoppt werden. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md). + Für Dienste in einer IPv6 Nur-Konfiguration müssen Sie den Zielgruppen-IP-Adresstyp des Gateway Load Balancer auf einstellen. `dualstack` + Für Services mit Aufgaben, die einen anderen Netzwerkmodus als `awsvpc` verwenden, werden Gateway Load Balancers nicht unterstützt. + Die Subnetzkonfiguration Ihres Load Balancers muss alle Availability Zones enthalten, in denen sich Ihre Container-Instances befinden. + Nachdem Sie einen Dienst erstellt haben, kann die Load Balancer-Konfiguration von AWS-Managementkonsole nicht mehr geändert werden. Sie können den AWS Copilot AWS CLI oder das SDK verwenden AWS CloudFormation, um die Load Balancer-Konfiguration nur für den `ECS` Rolling Deployment Controller zu ändern, nicht für blau/grün oder extern. AWS CodeDeploy Wenn Sie eine Konfiguration für den Load Balancer hinzufügen, aktualisieren oder entfernen, startet Amazon ECS eine neue Bereitstellung mit der aktualisierten Konfiguration Elastic Load Balancing. Dies führt dazu, dass sich Aufgaben bei Load Balancern registrieren und von diesen abmelden. Wir empfehlen, dass Sie dies in einer Testumgebung überprüfen, bevor Sie die Konfiguration Elastic Load Balancing Balancing aktualisieren. Informationen zum Ändern der Konfiguration finden Sie [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*. + Wenn die Aufgabe eines Services die Zustandsprüfungskriterien des Load Balancers nicht besteht, wird die Aufgabe angehalten und neu gestartet. Dieser Prozess wird fortgesetzt, bis Ihr Service die Anzahl der gewünschten ausgeführten Aufgaben erreicht. + Wenn Sie einen Gateway Load Balancer verwenden, bei dem IP-Adressen als Ziele konfiguriert sind, werden die Anfragen als von der privaten IP-Adresse des Gateway Load Balancers stammend angesehen. Das bedeutet, dass Services hinter einem Gateway Load Balancer effektiv für die Welt offen sind, sobald Sie eingehende Anforderungen und Zustandsprüfungen in der Sicherheitsgruppe des Ziels zulassen. + Für Fargate-Aufgaben müssen Sie die Plattformversion `1.4.0` (Linux) oder `1.0.0` (Windows) verwenden. + Informationen zu Problemen mit Services, für die ein Load Balancer aktiviert ist, finden Sie unter [Fehlerbehebung bei Service-Load Balancers in Amazon ECS](troubleshoot-service-load-balancers.md). + Wenn Sie den `instance`-Zieltyp verwenden, müssen sich Ihre Aufgaben und Ihr Load Balancer in derselben VPC befinden. Wenn Sie den `ip`-Zieltyp verwenden, wird die VPC-übergreifende Konnektivität unterstützt. + Verwenden Sie für jeden Service eine eindeutige Zielgruppe. Die Verwendung derselben Zielgruppe für mehrere Services kann zu Problemen bei der Servicebereitstellung führen. + Sie müssen Zielgruppen angeben, die einem Gateway Load Balancer zugeordnet sind. Informationen zum Erstellen eines Gateway Load Balancers finden Sie unter [Erste Schritte mit Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) in *Gateway Load Balancers*. **Wichtig** Wenn Ihre Service-Aufgabendefinition den Netzwerkmodus `awsvpc` verwendet (der für Fargate erforderlich ist), müssen Sie `ip` als Zieltyp verwenden, und nicht `instance`. Das liegt daran, dass Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, mit einer Elastic-Network-Schnittstelle verknüpft sind, und nicht mit einer Amazon-EC2-Instance. Sie können Instances nicht anhand der Instanz-ID registrieren, wenn sie die folgenden Instance-Typen haben: C1, CC1, CC2,, CG1, CG2, CR1,, Instance-Typen haben: C1 HI1,, HS1,,,, M2, M3 und T1. Sie können Instances dieser Arten nach IP-Adresse registrieren. # Registrierung mehrerer Zielgruppen bei einem Amazon-ECS-Service Ihr Amazon-ECS-Service kann den Datenverkehr von mehreren Load Balancern abwickeln und mehrere Ports mit Lastenausgleich festlegen, wenn Sie mehrere Zielgruppen in einer Servicedefinition angeben. Um einen Service mit mehreren Zielgruppen zu erstellen, müssen Sie den Service mithilfe der Amazon ECS-API, des SDK oder einer CloudFormation Vorlage erstellen. AWS CLI Nachdem der Service erstellt wurde, können Sie den Service und die Zielgruppen anzeigen, die in der AWS-Managementkonsole registriert sind. Sie müssen `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` verwenden, um die Load Balancer-Konfiguration eines vorhandenen Service zu ändern. Mehrere Zielgruppen können in einer Servicedefinition angegeben werden, die das folgende Format verwendet. Die vollständige Syntax einer Servicedefinition finden Sie unter [Servicedefinitionsvorlage](sd-template.md). ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"container_name", "containerPort":container_port }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"container_name", "containerPort":container_port } ] ``` ## Überlegungen Folgendes sollte berücksichtigt werden, wenn Sie mehrere Zielgruppen in einer Servicedefinition angeben: + Für Services, die einen Application Load Balancer oder einen Network Load Balancer verwenden, können Sie nicht mehr als fünf Zielgruppen an einen Service anfügen. + Das Festlegen mehrerer Zielgruppen in einer Servicedefinition wird nur unter folgenden Bedingungen unterstützt: + Der Service muss entweder einen Application Load Balancer oder Network Load Balancer verwenden. + Der Service muss den (`ECS`) Bereitstellungs-Controller-Typ verwenden. Dabei kann es sich entweder um die native/blue grüne Bereitstellung von Amazon ECS oder um die Bereitstellung fortlaufender Updates handeln. + Die Angabe mehrerer Zielgruppen wird für Services mit Aufgaben unterstützt, die die Starttypen Fargate und EC2 verwenden. + Wenn Sie einen Service erstellen, der mehrere Zielgruppen angibt, muss die serviceverknüpfte Amazon-ECS-Rolle erstellt werden. Die Rolle wird erstellt, indem der Parameter `role` in API-Anfragen oder die Eigenschaft `Role` in CloudFormation weggelassen wird. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md). ## Beispiel für Service-Definitionen Nachfolgend finden Sie einige Beispiel-Anwendungsfälle für das Festlegen mehrerer Zielgruppen in einer Servicedefinition. Die vollständige Syntax einer Servicedefinition finden Sie unter [Servicedefinitionsvorlage](sd-template.md). ### Separate Load Balancer für internen und externen Datenverkehr Im folgenden Anwendungsfall verwendet ein Service zwei separate Load Balancer, einen für internen Datenverkehr und einen zweiten für Datenverkehr mit dem Internet für denselben Container und Port. ``` "loadBalancers":[ //Internal ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"nginx", "containerPort":8080 }, //Internet-facing ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"nginx", "containerPort":8080 } ] ``` ### Bereitstellen mehrerer Ports aus demselben Container Im folgenden Anwendungsfall verwendet ein Service einen Load Balancer, stellt jedoch mehrere Ports vom selben Container bereit. Beispiel: Ein Jenkins-Container stellt Port 8080 für die Jenkins Web-Schnittstelle und Port 50000 für die API bereit. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"jenkins", "containerPort":8080 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"jenkins", "containerPort":50000 } ] ``` ### Beispiel: Bereitstellen von Ports aus mehreren Containern Im folgenden Anwendungsfall verwendet ein Service einen Load Balancer und zwei Zielgruppen zur Bereitstellung aus separaten Container-Ports. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"webserver", "containerPort":80 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"database", "containerPort":3306 } ] ``` # Automatisches Skalieren Ihres Amazon-ECS-Service *Automatische Skalierung* ist die Fähigkeit, die gewünschte Anzahl von Aufgaben in Ihrem Amazon-ECS-Service automatisch zu erhöhen oder zu verringern. Amazon ECS nutzt den Application Auto Scaling-Service, um diese Funktionalität bereitzustellen. Weitere Informationen finden Sie im [Benutzerhandbuch zum Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Amazon ECS veröffentlicht CloudWatch Metriken mit der durchschnittlichen CPU- und Speicherauslastung Ihres Services. Weitere Informationen finden Sie unter [Amazon-ECS-Serviceauslastungsmetriken](service_utilization.md). Sie können diese und andere CloudWatch Kennzahlen verwenden, um Ihren Service zu skalieren (mehr Aufgaben hinzufügen), um der hohen Nachfrage in Spitzenzeiten gerecht zu werden, und Ihren Service zu skalieren (weniger Aufgaben ausführen), um die Kosten in Zeiten geringer Auslastung zu senken. Amazon-ECS-Service-Auto-Scaling unterstützt die folgenden Typen des Auto Scalings: + [Verwenden Sie eine Zielmetrik, um Amazon ECS-Services zu skalieren](service-autoscaling-targettracking.md) – Erhöhen oder verringern Sie die Anzahl der Aufgaben, die von Ihrem Service ausgeführt werden, auf Grundlage eines Zielwerts für eine bestimmte Metrik. Dies ähnelt der Art und Weise, wie ein Thermostat die Temperatur in Ihrem Zuhause konstant hält. Sie wählen eine Temperatur aus und der Thermostat erledigt den Rest. + [Verwenden Sie vordefinierte Inkremente, die auf CloudWatch Alarmen basieren, um Amazon ECS-Services zu skalieren](service-autoscaling-stepscaling.md) – Erhöhen oder verringern Sie die Anzahl der Aufgaben, die von Ihrem Service ausgeführt werden, auf Grundlage einer Gruppe von Skalierungsanpassungen, die als Schrittanpassungen bezeichnet werden und je nach Ausmaß der Alarmüberschreitung variieren. + [Verwenden Sie geplante Aktionen, um Amazon ECS-Services zu skalieren](service-autoscaling-schedulescaling.md) – Erhöhen oder verringern der Anzahl der Aufgaben, die Ihr Service ausführt, basierend auf Datum und Uhrzeit. + [Verwenden Sie historische Muster, um Amazon ECS-Services mit vorausschauender Skalierung zu skalieren](predictive-auto-scaling.md) – Die Anzahl der Aufgaben, die Ihr Service ausführt, basierend auf historischenr Last-Datenanalytik erhöhen oder verringern, um tägliche oder wöchentliche Muster in den Datenverkehrsflüssen zu erkennen. ## Überlegungen Beachten Sie bei Verwendung von Skalierungsrichtlinien die folgenden Überlegungen: + Amazon ECS sendet Metriken in 1-Minuten-Intervallen an CloudWatch. Metriken sind erst verfügbar, wenn die Cluster und Services die Metriken an sie senden CloudWatch, und Sie können keine CloudWatch Alarme für Metriken erstellen, die nicht existieren. + Die Skalierungsrichtlinien unterstützen eine Ruhephase. Das ist die Anzahl Sekunden, für die darauf gewartet wird, dass eine vorherige Skalierungsaktivität wirksam wird. + Bei Scale-out-Ereignissen wird eine kontinuierliche (jedoch nicht übermäßige) horizontale Skalierung nach oben angestrebt. Nachdem Service Auto Scaling unter Verwendung einer Skalierungsrichtlinie erfolgreich horizontal nach oben skaliert hat, beginnt es mit der Berechnung der Ruhezeit. Die Skalierungsrichtlinie erhöht die gewünschte Kapazität nicht erneut, es sei denn, es wird eine größere Aufskalierung ausgelöst oder die Ruhephase endet. Während die Scale-Out-Ruhephase wirksam ist, wird die durch die initiierende horizontale Skalierung nach oben (Scale-Out) hinzugefügte Kapazität als Teil der gewünschten Kapazität für die nächste horizontale Skalierung nach oben berechnet. + Bei Scale-In-Ereignissen wird eine vorsichtige horizontale Skalierung nach unten angestrebt, um die Verfügbarkeit Ihrer Anwendung aufrechtzuerhalten, sodass horizontale Skalierungen nach unten blockiert werden, bis die Ruhephase abgelaufen ist. Wenn jedoch während der Abskalierungs-Ruhephase ein anderer Alarm eine Aufskalierungs-Aktivität auslöst, skaliert Service Auto Scaling das Ziel auf. In diesem Fall wird die Scale-In-Ruhephase angehalten und nicht abgeschlossen. + Der Serviceplaner respektiert die gewünschte Anzahl zu jeder Zeit, aber solange Sie aktive Skalierungsrichtlinien und Alarme für einen Service haben, könnte Service Auto Scaling eine gewünschte Anzahl, die von Ihnen manuell festgelegt wurde, ändern. + Wenn die gewünschte Anzahl eines Service unter seinem minimalen Kapazitätswert eingestellt ist und ein Alarm ein Aufskalieren auslöst, skaliert Service-Auto-Scaling die gewünschte Anzahl bis zu dem minimalen Kapazitätswert auf und führt dann die Aufskalierung wie gefordert fort, basierend auf der Skalierungsrichtlinie, die dem Alarm zugeordneten ist. Eine Herunterskalierung wird jedoch die gewünschte Anzahl nicht anpassen, da der Wert bereits unter dem Wert für die minimale Kapazität liegt. + Wenn die gewünschte Anzahl eines Service über seinem maximalen Kapazitätswert eingestellt ist und ein Alarm ein Abskalieren auslöst, skaliert Service-Auto-Scaling die gewünschte Anzahl bis zu dem minimalen Kapazitätswert ab und führt dann die Abskalierung wie gefordert fort, basierend auf der Skalierungsrichtlinie, die dem Alarm zugeordnet ist. Eine Aufwärtsskalierung passt jedoch die gewünschte Anzahl nicht an, da der Wert bereits über dem Wert für die maximale Kapazität liegt. + Während der Skalierungsaktivitäten ist die tatsächliche Anzahl der laufenden Aufgaben in einem Service der Wert, den Service Auto Scaling als Ausgangspunkt verwendet, im Gegensatz zu der gewünschten Anzahl. Dies ist, was die Verarbeitungskapazität sein soll. Dies verhindert eine übermäßige (unkontrollierte) Skalierung, die z. B. nicht erfüllt werden könnte, wenn nicht genügend Ressourcen für die Container Instances vorhanden sind, um die zusätzlichen Aufgaben zu platzieren. Wenn die Container-Instance-Kapazität später verfügbar ist, kann die ausstehende Skalierung möglicherweise gelingen, und weitere Skalierungen können nach der Ruhephase erfolgen. + Wenn Sie möchten, dass die Anzahl der Aufgaben auf Null skaliert wird, wenn es keine Arbeit zu erledigen gibt, legen Sie eine Mindestkapazität von 0 fest. Wenn die tatsächliche Kapazität 0 ist und die Metrik darauf hinweist, dass Workload-Bedarf besteht, wartet Service Auto Scaling, bis ein Datenpunkt gesendet wird, bevor die Skalierung ausgeführt wird. In diesem Fall skaliert es um den minimal möglichen Betrag als Startpunkt und setzt dann die Skalierung basierend auf der tatsächlichen Anzahl der laufenden Tasks fort. + Application Auto Scaling deaktiviert Abskalierungsprozesse, während Amazon-ECS-Bereitstellungen ausgeführt werden. Scale-Out-Prozesse werden während einer Bereitstellung jedoch weiterhin ausgeführt, es sei denn, sie werden angehalten. Dieses Verhalten gilt nicht für Amazon-ECS-Services, die den externen Bereitstellungs-Controller verwenden. Weitere Informationen finden Sie unter [Auto Scaling und Bereitstellung von Services](#service-auto-scaling-deployments). + Sie haben mehrere Application-Auto-Scaling-Optionen für Amazon-ECS-Aufgaben. Die Zielverfolgung ist der am einfachsten zu verwendende Modus. Damit müssen Sie lediglich einen Zielwert für eine Metrik festlegen, z. B. die durchschnittliche CPU-Auslastung. Anschließend verwaltet der Autoscaler automatisch die Anzahl der Aufgaben, die erforderlich sind, um diesen Wert zu erreichen. Mit der schrittweisen Skalierung können Sie schneller auf Bedarfsänderungen reagieren, da Sie die spezifischen Schwellenwerte für Ihre Skalierungsmetriken definieren und festlegen, wie viele Aufgaben hinzugefügt oder entfernt werden müssen, wenn die Schwellenwerte überschritten werden. Und was noch wichtiger ist: Sie können sehr schnell auf Änderungen der Nachfrage reagieren, indem Sie die Zeitspanne, in der ein Schwellenwertalarm überschritten wird, auf ein Minimum reduzieren. Weitere Informationen zu bewährten Methoden für Service-Auto-Scaling finden Sie unter [Optimierung von Service-Auto-Scaling von Amazon ECS](capacity-autoscaling-best-practice.md). ## Auto Scaling und Bereitstellung von Services Application Auto Scaling deaktiviert Abskalierungsprozesse, während Amazon-ECS-Bereitstellungen ausgeführt werden. Scale-Out-Prozesse werden während einer Bereitstellung jedoch weiterhin ausgeführt, es sei denn, sie werden angehalten. Dieses Verhalten gilt nicht für Amazon-ECS-Services, die den externen Bereitstellungs-Controller verwenden. Wenn Sie Scale-Out-Prozesse anhalten möchten, während Bereitstellungen ausgeführt werden, führen Sie die folgenden Schritte aus. 1. Rufen Sie den [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html)Befehl auf und geben Sie die Ressourcen-ID des Dienstes an, der dem skalierbaren Ziel in Application Auto Scaling zugeordnet ist (Beispiel:`service/default/sample-webapp`). Zeichnen Sie die Ausgabe auf. Sie werden diese benötigen, wenn Sie den nächsten Befehl aufrufen. 1. Rufen Sie den [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehl auf und geben Sie die Ressourcen-ID, den Namespace und die skalierbare Dimension an. Geben Sie `true` für sowohl `DynamicScalingInSuspended` als auch `DynamicScalingOutSuspended` an. 1. Nach Abschluss der Bereitstellung können Sie den [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehl aufrufen, um die Skalierung fortzusetzen. Weitere Informationen finden Sie unter [Unterbrechen und Wiederaufnehmen der Skalierung für Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html). # Verwenden Sie eine Zielmetrik, um Amazon ECS-Services zu skalieren Mit Skalierungsrichtlinien für die Zielverfolgung wählen Sie eine Metrik aus und legen einen Zielwert fest. Amazon ECS Service Auto Scaling erstellt und verwaltet die CloudWatch Alarme, die die Skalierungsrichtlinie steuern, und berechnet die Skalierungsanpassung auf der Grundlage der Metrik und des Zielwerts. Durch die Skalierungsrichtlinie werden so viele Service-Aufgaben wie erforderlich hinzugefügt oder entfernt, damit die Metrik auf oder nahe an dem Zielwert gehalten wird. Abgesehen davon, dass eine Skalierungsrichtlinie für die Ziel-Nachverfolgung die Metrik nahe an dem Zielwert hält, passt sie sich auch an die Schwankungen in der Metrik aufgrund eines schwankenden Lastmusters an und verringert schnelle Schwankungen der Anzahl der Aufgaben, die in Ihrem Service ausgeführt werden. Richtlinien zur Zielverfolgung machen die manuelle Definition von CloudWatch Alarmen und Skalierungsanpassungen überflüssig. Amazon ECS erledigt dies automatisch auf der Grundlage des von Ihnen festgelegten Ziels. Berücksichtigen Sie bei der Verwendung von Zielverfolgungsrichtlinien Folgendes: + Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung geht davon aus, dass sie eine horizontale Skalierung nach oben vornehmen soll, wenn die angegebene Metrik über dem Zielwert liegt. Sie können keine Skalierungsrichtlinie für die Ziel-Nachverfolgung verwenden, um eine horizontale Skalierung nach oben vorzunehmen, wenn die angegebene Metrik unter dem Zielwert liegt. + Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung nimmt keine Skalierung vor, wenn die angegebene Metrik unzureichende Daten aufweist. Es wird keine horizontale Skalierung nach unten vorgenommen, da unzureichende Daten nicht als geringe Auslastung interpretiert werden. + Möglicherweise werden Lücken zwischen den Datenpunkten für den Zielwert und die aktuelle Metrik angezeigt. Der Grund hierfür ist, dass Service Auto Scaling stets vorsichtig agiert, indem beim Ermitteln der hinzuzufügenden oder zu entfernenden Kapazität Auf- oder Abrundungen vorgenommen werden. Dadurch wird verhindert, dass zu wenig Kapazität hinzufügt oder zu viel Kapazität entfernt wird. + Um die Verfügbarkeit der Anwendung sicherzustellen, wird der Service schnellstmöglich proportional zur Metrik hochskaliert, jedoch etwas langsamer herunterskaliert. + Application Auto Scaling deaktiviert Abskalierungsprozesse, während Amazon-ECS-Bereitstellungen ausgeführt werden. Scale-Out-Prozesse werden während einer Bereitstellung jedoch weiterhin ausgeführt, es sei denn, sie werden angehalten. Dieses Verhalten gilt nicht für Amazon-ECS-Services, die den externen Bereitstellungs-Controller verwenden. Weitere Informationen finden Sie unter [Auto Scaling und Bereitstellung von Services](service-auto-scaling.md#service-auto-scaling-deployments). + Sie können mehrere Skalierungsrichtlinien für die Ziel-Nachverfolgung für einen Amazon-ECS-Service erstellen, vorausgesetzt, dass diese alle verschiedene Metriken verwenden. Da Service Auto Scaling immer darauf ausgerichtet ist, Verfügbarkeit zu priorisieren, ist sein Verhalten davon abhängig, ob die Richtlinien für die Ziel-Nachverfolgung für die horizontale Skalierung nach oben oder nach unten bereit sind. Sofern Richtlinien für die Ziel-Nachverfolgung für die Aufskalierung bereit sind, findet eine Aufskalierung des Services statt. Eine Abskalierung wird jedoch nur durchgeführt, wenn alle Richtlinien für die Ziel-Nachverfolgung (mit aktivierter Abskalierung) zur Abskalierung bereit sind. + Bearbeiten oder löschen Sie nicht die CloudWatch Alarme, die Service Auto Scaling für eine Skalierungsrichtlinie zur Zielverfolgung verwaltet. Service Auto Scaling löscht die Alarme automatisch, wenn Sie die Skalierungsrichtlinie löschen. + Die `ALBRequestCountPerTarget` Metrik für Skalierungsrichtlinien zur Zielverfolgung wird für den blue/green Bereitstellungstyp nicht unterstützt. Weitere Informationen zu Skalierungsrichtlinien für die Ziel-Nachverfolgung finden Sie unter [Skalierungsrichtlinien für die Ziel-Nachverfolgung](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) im *Benutzerhandbuch zum Auto Scaling von Anwendungen*. # Eine Ziel-Nachverfolgungs-Skalierungsrichtlinie für Service-Auto-Scaling von Amazon ECS erstellen Erstellen Sie eine Skalierungsrichtlinie für die Ziel-Nachverfolgung, damit Amazon ECS die gewünschte Anzahl an Aufgaben in Ihrem Service automatisch erhöht oder verringert. Die Ziel-Nachverfolgung basiert auf einem Ziel-Metrikwert. ## Konsole 1. Zusätzlich zu den IAM-Standardberechtigungen für das Erstellen und Aktualisieren von Services benötigen Sie zusätzliche Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche IAM-Berechtigungen für Service-Auto-Scaling von Amazon ECS](auto-scaling-IAM.md). 1. Ermitteln Sie die Metriken, die für die Richtlinie verwendet werden sollen. Die folgenden Metriken sind verfügbar: + **ECSServiceDurchschnitt CPUUtilization** — Die durchschnittliche CPU-Auslastung, die der Service verwenden sollte. + **ECSServiceAverageMemoryUtilization**— Durchschnittliche Speicherauslastung, die der Service verwenden sollte. + **ALBRequestCountPerTarget**— Die durchschnittliche Anzahl von Anfragen pro Minute, die diese Aufgabe idealerweise erhalten sollte. 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Anzahl der Aufgaben festlegen** aus. 1. Wählen Sie unter **Anzahl der Aufgaben für den Amazon-ECS-Service** die Option **Auto Scaling verwenden** aus. Der Abschnitt **Anzahl der Aufgaben** wird angezeigt. 1. Geben Sie unter **Mindestanzahl an Aufgaben**, die Untergrenze der Anzahl der Aufgaben an, die das Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht unterschreiten. 1. Geben Sie unter **Maximum** die Höchstanzahl der Aufgaben an, die Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht überschreiten. 1. Wählen Sie **Speichern**. Die Richtlinien-Seite wird angezeigt. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. Die Seite **Richtlinie erstellen** wird angezeigt. 1. Wählen Sie für **Scaling policy type** (Typ der Skalierungsrichtlinie) **Target tracking** (Ziel-Nachverfolgung) aus. 1. Geben Sie unter **Policy name** (Richtlinienname) einen Namen für diese Richtlinie ein. 1. Wählen Sie für **Metriktypen** Ihre Metriken aus der Liste der Optionen aus. 1. Geben Sie für **Zielauslastung** den Zielwert für den Prozentsatz der Aufgaben ein, die Amazon ECS aufrechterhalten soll. Service-Auto-Scaling skaliert Ihre Kapazität auf, bis die durchschnittliche Auslastung der Zielauslastung entspricht oder bis sie die von Ihnen angegebene maximale Anzahl von Aufgaben erreicht. 1. Gehen Sie unter **Weitere Einstellungen** wie folgt vor: 1. Geben Sie für **Ruhephase vor dem Abskalieren** die Zeitspanne in Sekunden ein, nach der eine Abskalierungsaktion abgeschlossen sein muss, bevor eine weitere Abskalierungsaktion gestartet werden kann. 1. Geben Sie für **Ruhephase vor dem Aufskalieren** die Zeitspanne in Sekunden ein, für die darauf gewartet wird, dass eine vorherige Aufskalierungsaktion wirksam wird. 1. Wählen Sie **Abskalierung deaktivieren**, um nur eine Richtlinie für die Aufskalierung zu erstellen. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. ## AWS CLI 1. Registrieren Sie Ihren Amazon ECS-Service mithilfe des [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehls als skalierbares Ziel. 1. Erstellen Sie mit dem [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)Befehl eine Skalierungsrichtlinie. # Verwenden Sie vordefinierte Inkremente, die auf CloudWatch Alarmen basieren, um Amazon ECS-Services zu skalieren Mit Richtlinien zur schrittweisen Skalierung erstellen und verwalten Sie die CloudWatch Alarme, die den Skalierungsprozess auslösen. Wenn ein Alarm verletzt wird, initiiert Amazon ECS die mit diesem Alarm verknüpfte Skalierungsrichtlinie. Die Richtlinie zur schrittweisen Skalierung skaliert die Kapazität anhand einer Reihe von Anpassungen, die als schrittweise Anpassungen bezeichnet werden. Die Größe der Anpassung richtet sich nach dem Ausmaß der Alarmüberschreitung. + Wenn der Verstoß den ersten Schwellenwert überschreitet, wendet Amazon ECS die erste schrittweise Anpassung an. + Wenn der Verstoß den zweiten Schwellenwert überschreitet, wendet Amazon ECS die zweite schrittweise Anpassung an, und so weiter. Es wird dringend empfohlen, eine Skalierungsrichtlinie für die Ziel-Nachverfolgung zu verwenden, um auf der Grundlage einer Metrik zu skalieren, z. B. der durchschnittlichen CPU-Auslastung oder der durchschnittlichen Anzahl an Anforderungen pro Ziel. Metriken, die sich verringern, wenn die Kapazität zunimmt, und zunehmen, wenn die Kapazität abnimmt, können zur proportionalen Auf- oder Abskalierung der Anzahl der Aufgaben verwendet werden, welche die Ziel-Nachverfolgung verwenden. Dadurch wird sichergestellt, dass Amazon ECS die Bedarfskurve für Ihre Anwendungen genau einhält. # Eine Richtlinie für die schrittweise Skalierung für Service-Auto-Scaling von Amazon ECS erstellen Erstellen Sie eine schrittweise Skalierungsrichtlinie, damit Amazon ECS die gewünschte Anzahl von Aufgaben in Ihrem Service automatisch erhöht oder verringert. Die schrittweise Skalierung basiert auf einer Reihe von Skalierungsanpassungen, die als schrittweise Anpassungen bekannt sind. Diese variieren je nach Ausmaß der Alarmüberschreitung. ## Konsole 1. Zusätzlich zu den IAM-Standardberechtigungen für das Erstellen und Aktualisieren von Services benötigen Sie zusätzliche Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche IAM-Berechtigungen für Service-Auto-Scaling von Amazon ECS](auto-scaling-IAM.md). 1. Ermitteln Sie die Metriken, die für die Richtlinie verwendet werden sollen. Die folgenden Metriken sind verfügbar: + **ECSServiceDurchschnitt CPUUtilization** — Die durchschnittliche CPU-Auslastung, die der Service verwenden sollte. + **ECSServiceAverageMemoryUtilization**— Durchschnittliche Speicherauslastung, die der Service verwenden sollte. + **ALBRequestCountPerTarget**— Die durchschnittliche Anzahl von Anfragen pro Minute, die diese Aufgabe idealerweise erhalten sollte. 1. Erstellen Sie die CloudWatch Alarme für die Metriken. Weitere Informationen finden Sie unter [Erstellen eines CloudWatch Alarms auf der Grundlage eines statischen Schwellenwerts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) im * CloudWatch Amazon-Benutzerhandbuch*. 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Anzahl der Aufgaben festlegen** aus. 1. Wählen Sie unter **Anzahl der Aufgaben für den Amazon-ECS-Service** die Option **Auto Scaling verwenden** aus. Der Abschnitt **Anzahl der Aufgaben** wird angezeigt. 1. Geben Sie unter **Mindestanzahl an Aufgaben**, die Untergrenze der Anzahl der Aufgaben an, die das Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht unterschreiten. 1. Geben Sie unter **Maximum** die Höchstanzahl der Aufgaben an, die Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht überschreiten. 1. Wählen Sie **Speichern**. Die Richtlinien-Seite wird angezeigt. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. Die Seite **Richtlinie erstellen** wird angezeigt. 1. Wählen Sie für **Typ der Skalierungsrichtlinie** die Option **Schrittweise Skalierung** aus. 1. Konfigurieren Sie die Eigenschaften der Aufskalierung. Gehen Sie unter **Schritte zum Hinzufügen von Aufgaben** wie folgt vor: 1. Geben Sie unter **Policy name** (Richtlinienname) einen Namen für diese Richtlinie ein. 1. Wählen Sie als **Namen des CloudWatch CloudWatch Alarms** den Alarm aus. 1. Wählen Sie für **Metrik-Aggregationstyp** aus, wie die ausgewählte Metrik mit dem definierten Schwellenwert verglichen werden soll. 1. Wählen Sie für **Anpassungstypen** aus, ob die Anpassung auf einer Änderung der Anzahl der Aufgaben oder einer Änderung des Prozentsatzes der Aufgaben basiert. 1. Geben Sie für **Zu ergreifende Aktionen** die Werte für die auszuführende Aktion ein. Wählen Sie **Schritt hinzufügen**, um weitere Aktionen hinzuzufügen. 1. Konfigurieren Sie die Eigenschaften der Abskalierung. Gehen Sie unter **Schritte zum Entfernen von Aufgaben** wie folgt vor: 1. Geben Sie unter **Policy name** (Richtlinienname) einen Namen für diese Richtlinie ein. 1. Wählen Sie als **Namen des CloudWatch CloudWatch Alarms** den Alarm aus. 1. Wählen Sie für **Metrik-Aggregationstyp** aus, wie die ausgewählte Metrik mit dem definierten Schwellenwert verglichen werden soll. 1. Wählen Sie für **Anpassungstypen** aus, ob die Anpassung auf einer Änderung der Anzahl der Aufgaben oder einer Änderung des Prozentsatzes der Aufgaben basiert. 1. Geben Sie für **Zu ergreifende Aktionen** die Werte für die auszuführende Aktion ein. Wählen Sie **Schritt hinzufügen**, um weitere Aktionen hinzuzufügen. 1. Geben Sie für **Ruhephase** die Zeitspanne in Sekunden ein, für die darauf gewartet wird, dass eine vorherige Skalierungsaktion wirksam wird. Bei einer Richtlinie zum Hinzufügen ist dies die Zeit nach einer Aufskalierungsaktion, in der die Skalierungsrichtlinie Abskalierungsaktionen blockiert und begrenzt, wie viele Aufgaben gleichzeitig aufskaliert werden können. Bei einer Entfernungsrichtlinie ist dies die Zeit nach einer Abskalierungsaktion, die verstreichen muss, bevor eine weitere Abskalierungsaktion gestartet werden kann. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. ## AWS CLI 1. Registrieren Sie Ihren Amazon ECS-Service mithilfe des [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehls als skalierbares Ziel. 1. Erstellen Sie mit dem [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)Befehl eine Skalierungsrichtlinie. # Verwenden Sie geplante Aktionen, um Amazon ECS-Services zu skalieren Mit der geplanten Skalierung können Sie eine automatische Skalierung für Ihre Anwendung auf der Grundlage vorhersehbarer Laständerungen einrichten, indem Sie geplante Aktionen erstellen, mit denen die Anzahl der Aufgaben zu bestimmten Zeiten erhöht oder verringert wird. So können Sie Ihre Anwendung proaktiv skalieren, um sie an vorhersehbare Laständerungen anzupassen. Mit diesen geplanten Skalierungsaktionen können Sie Kosten und Leistung optimieren. Ihre Anwendung verfügt über eine ausreichend Anzahl an Aufgaben, um die Hauptverkehrsspitzen unter der Woche zu bewältigen, ohne dass zu anderen Zeiten unnötige Kapazitäten bereitgestellt werden. Sie können geplante Skalierung und Skalierungsrichtlinien zusammen verwenden, um die Vorteile von proaktiven und reaktiven Skalierungsansätzen zu nutzen. Nachdem eine geplante Skalierungsaktion ausgeführt wurde, kann die Skalierungsrichtlinie weiterhin Entscheidungen darüber treffen, ob die Anzahl der Aufgaben weiter skaliert werden soll. So können Sie sicherstellen, dass Sie über eine ausreichende Anzahl an Aufgaben verfügen, um die Last für Ihre Anwendung zu bewältigen. Während Ihre Anwendung der Nachfrage entsprechend skaliert, muss die aktuelle Kapazität innerhalb der minimalen und maximalen Anzahl an Aufgaben liegen, die durch Ihre geplante Aktion festgelegt wurde. Sie können die geplante Skalierung mit der AWS CLI konfigurieren. Weitere Informationen über die geplante Skalierung finden Sie unter [Geplante Skalierung](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) im *Benutzerhandbuch für Application Auto Scaling*. # Eine geplante Aktion für Service-Auto-Scaling von Amazon ECS erstellen Erstellen Sie eine geplante Aktion, damit Amazon ECS die Anzahl der Aufgaben, die Ihr Service ausführt, basierend auf Datum und Uhrzeit erhöht oder verringert. ## Konsole 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** aus. Die Seite Service-Auto-Scaling wird angezeigt. 1. Wenn Sie Service-Auto-Scaling nicht konfiguriert haben, wählen Sie **Anzahl der Aufgaben festlegen** aus. Der Abschnitt **Anzahl der Amazon-ECS-Serviceaufgaben** wird angezeigt. Wählen Sie unter **Anzahl der Amazon-ECS-Serviceaufgaben** die Option **Service-Auto-Scaling verwenden** aus, um die gewünschte Anzahl von Aufgaben für Ihren Service anzupassen. Der Abschnitt **Anzahl der Aufgaben** wird angezeigt. 1. Geben Sie unter **Mindestanzahl an Aufgaben**, die Untergrenze der Anzahl der Aufgaben an, die das Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht unterschreiten. 1. Geben Sie unter **Maximum** die Höchstanzahl der Aufgaben an, die Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht überschreiten. 1. Wählen Sie **Speichern**. Die Richtlinien-Seite wird angezeigt. 1. Wählen Sie **Geplante Aktionen** und dann **Erstellen** aus. Die Seite **Geplante Aktion erstellen** wird angezeigt. 1. Geben Sie für **Aktionsname** einen eindeutigen Namen ein. 1. Wählen Sie für **Zeitzone** eine Zeitzone aus. Alle aufgelisteten Zeitzonen stammen aus der IANA-Zeitzonendatenbank. Weitere Informationen finden Sie unter [Liste der Zeitzonen der TZ-Datenbank](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 1. Geben Sie als **Startzeit** das **Datum** und die **Uhrzeit** ein, zu der die Aktion gestartet wird. Wenn Sie einen wiederkehrenden Zeitplan gewählt haben, legt die Startzeit fest, wann die erste geplante Aktion in der wiederkehrenden Reihe ausgeführt wird. 1. Wählen Sie für **Recurrence (Wiederholung)** eine der verfügbaren Optionen aus. + Wählen Sie aus, wie oft Amazon ECS die geplante Aktion ausführt, um nach einem wiederkehrenden Zeitplan zu skalieren. + Wenn Sie eine Option auswählen, die mit **Rate** beginnt, wird der Cron-Ausdruck für Sie erstellt. + Wenn Sie **Cron** auswählen, geben Sie einen Cron-Ausdruck ein, der angibt, wann die Aktion ausgeführt werden soll. + Wenn Sie nur einmal skalieren möchten, wählen Sie **Einmalig** aus. 1. Gehen Sie unter **Aufgabenanpassungen** wie folgt vor: + Geben Sie für **Minimum** die Mindestanzahl von Aufgaben ein, die der Service ausführen soll. + Geben Sie für **Maximum** die maximale von Aufgaben ein, die der Service ausführen soll. 1. Wählen Sie **Geplante Aktion erstellen**. ## CLI Gehen Sie AWS CLI wie folgt vor, um geplante Skalierungsrichtlinien für Ihren Service zu konfigurieren. Ersetzen Sie jeden *user input placeholder* durch Ihre Informationen. **Beispiel: Einmalige Skalierung** Verwenden Sie den folgenden [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)Befehl mit den Optionen `--start-time "YYYY-MM-DDThh:mm:ssZ"` und und und oder mit einer oder beiden `--MaxCapacity` Optionen. `--MinCapacity` ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-one-time-schedule \ --start-time 2021-01-30T12:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` **Beispiel: So planen Sie die Skalierung im Rahmen eines sich wiederholenden Zeitplans** Verwenden Sie den folgenden [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)-Befehl. Ersetzen Sie die *user input* durch Ihre Werte. ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-recurring-action \ --schedule "rate(5 hours)" \ --start-time 2021-01-30T12:00:00 \ --end-time 2021-01-31T22:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` Der angegebene Wiederholungszeitplan läuft auf der Grundlage der UTC-Zeitzone. Um eine andere Zeitzone anzugeben, schließen Sie die `--time-zone`-Option und den Namen der IANA-Zeitzone an, wie im folgenden Beispiel. ``` --time-zone "America/New_York" ``` Weitere Informationen finden Sie unter [Liste der Zeitzonen der TZ-Datenbank](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). # Verwenden Sie historische Muster, um Amazon ECS-Services mit vorausschauender Skalierung zu skalieren Die prädiktive Skalierung betrachtet vergangene Lastdaten aus Datenverkehrsströmen, um tägliche oder wöchentliche Muster zu analysieren. Anschließend verwendet sie diese Analyse, um zukünftige Bedürfnisse vorherzusehen und die Aufgaben in Ihrem Service nach Bedarf proaktiv zu erhöhen. Prädiktives Auto Scaling ist in den folgenden Situationen am nützlichsten: + Zyklischer Datenverkehr – Erhöhte Auslastung von Ressourcen während der normalen Geschäftszeiten und niedrige Auslastung von Ressourcen am Abend und am Wochenende + Wiederkehrende on-and-off Workload-Muster — Beispiele hierfür sind Batch-Verarbeitung, Tests oder regelmäßige Datenanalysen. + Anwendungen mit langen Startzeiten – Dies kann eine spürbare Latenzauswirkung auf die Anwendungsleistung bei Aufskalierungsereignissen haben. Sie sollten die prädiktive Skalierung in Betracht ziehen, wenn Sie regelmäßige Datenverkehrszuwächse haben und Anwendungen nutzen, deren Initialisierung lange dauert. Die prädiktive Skalierung hilft Ihnen, schneller zu skalieren, indem sie proaktiv die Anzahl der Aufgaben für prognostizierte Lasten erhöht, anstatt ausschließlich dynamische Skalierungsrichtlinien wie die Ziel-Nachverfolgung oder die schrittweise Skalierung zu verwenden. Durch prädiktive Skalierung können Sie die Möglichkeit einer Überbereitstellung der Anzahl an Aufgaben vermeiden, und Sie können möglicherweise auch Geld sparen. Nehmen wir als Beispiel eine Anwendung, die eine hohe Auslastung während der Geschäftszeiten und eine geringe Nutzung über Nacht aufweist. Zu Beginn eines jeden Werktages kann die prädiktive Skalierung vor dem ersten Zustrom des Datenverkehrs die Aufgaben aufskalieren. Auf diese Weise kann Ihre Anwendung eine hohe Verfügbarkeit und Leistung aufrechterhalten, wenn sie von einer geringeren Auslastung zu einem Zeitraum mit höherer Auslastung übergeht. Sie müssen nicht warten, bis die dynamische Skalierung auf sich ändernden Datenverkehr reagiert. Sie müssen auch keine Zeit damit verbringen, die Lastmuster Ihrer Anwendung zu überprüfen und mithilfe der geplanten Skalierung die richtige Kapazität zu planen. Prädiktive Skalierung ist eine Funktion auf Service-Ebene, die die Aufgabe Ihres Services unabhängig von der Skalierung der zugrunde liegenden Rechenkapazität (z. B. EC2 oder Fargate) skaliert. AWS Verwaltet und skaliert für Fargate die zugrunde liegende Kapazität automatisch auf der Grundlage der Aufgabenanforderungen. Für EC2-Kapazität können Sie Auto-Scaling-Gruppenkapazitätsanbieter verwenden, um die zugrunde liegenden EC2-Instances automatisch auf der Grundlage der Skalierungsanforderungen Ihrer Aufgaben zu skalieren. **Topics** + [Überblick über die prädiktive Skalierung](#predictive-auto-scaling-overview) + [Eine Richtlinie für die prädiktive Skalierung erstellen](predictive-scaling-create-policy.md) + [Auswertung Ihrer Richtlinien für prädiktive Skalierung](predictive-scaling-graphs.md) + [Prognose überschreiben](predictive-scaling-overriding-forecast-capacity.md) + [Verwenden benutzerdefinierter Metriken](predictive-scaling-custom-metrics.md) ## So funktioniert die prädiktive Skalierung in Amazon ECS Hier erfahren Sie mehr über Überlegungen zur Verwendung der prädiktiven Skalierung, wie sie funktioniert und wo die Grenzen liegen. ### Überlegungen zur Verwendung der prädiktiven Skalierung + Sie sollten sicherstellen, dass die prädiktive Skalierung für Ihren Workload geeignet ist. Sie können dies überprüfen, indem Sie Skalierungsrichtlinien im Modus **Nur Prognosen** konfigurieren und herausfinden, was die Konsole empfiehlt. Bevor Sie mit der prädiktiven Skalierung beginnen, sollten Sie die Prognose und die Empfehlungen auswerten. + Bevor die prädiktive Skalierung Prognosen erstellen kann, werden mindestens 24 Stunden an historischen Daten benötigt. Je mehr historische Daten verfügbar sind, desto effektiver ist die Prognose, wobei zwei Wochen ideal sind. Außerdem müssen Sie 24 Stunden warten, bis die prädiktive Skalierung neue Prognosen generieren kann, wenn Sie einen Amazon-ECS-Service löschen und einen neuen erstellen. Eine Möglichkeit, dies zu beschleunigen, besteht darin, benutzerdefinierte Metriken zu verwenden, um Metriken über den alten und neuen Amazon-ECS-Service hinweg zu aggregieren. + Wählen Sie eine Lastmetrik, die die volle Auslastung Ihrer Anwendung genau wiedergibt und den Aspekt Ihrer Anwendung darstellt, der für die Skalierung am wichtigsten ist. + Dynamische Skalierung mit prädiktiver Skalierung hilft Ihnen, die Nachfrage nach Ihrer Anwendung genau zu verfolgen, sodass Sie in Ruhephasen skalieren und bei unerwartetem Anstieg des Datenverkehrs aufskalieren können. Wenn mehrere Skalierungsrichtlinien aktiv sind, bestimmt jede Richtlinie die gewünschte Anzahl an Aufgaben unabhängig, und die gewünschte Anzahl an Aufgaben wird auf das Maximum dieser Richtlinien festgelegt. + Sie können prädiktive Skalierung zusammen mit Ihren dynamischen Skalierungsrichtlinien wie Ziel-Nachverfolgung oder schrittweise Skalierung verwenden, sodass Ihre Anwendungen sowohl auf Echtzeit- als auch auf historischen Mustern skaliert werden. Prädiktive Skalierung allein skaliert Ihre Aufgaben nicht ab. + Wenn Sie beim Aufrufen der `register-scalable-target`-API eine benutzerdefinierte Rolle verwenden, wird möglicherweise eine Fehlermeldung angezeigt, die besagt, dass die Richtlinie zur prädiktiven Skalierung nur funktionieren kann, wenn SLR aktiviert ist. In diesem Fall sollten Sie `register-scalable-target` erneut aufrufen, jedoch ohne role-arn. Verwenden Sie SLR, wenn Sie das skalierbare Ziel registrieren und die `put-scaling-policy`-API aufrufen. ### So funktioniert Auto Scaling Sie verwenden Predictive Scaling, indem Sie eine Predictive Scaling-Richtlinie erstellen, die die zu überwachende und zu analysierende CloudWatch Metrik festlegt. Die prädiktive Skalierung muss mindestens 24 Stunden an Daten enthalten, um mit der Prognose von zukünftigen Werten zu beginnen. Nachdem Sie die Richtlinie erstellt haben, beginnt die prädiktive Skalierung mit der Analyse von Metrikdaten der letzten 14 Tage, um Muster zu identifizieren. Diese Analyse wird verwendet, um stündliche Prognosen für die Anforderungen der nächsten 48 Stunden zu generieren. Die neuesten CloudWatch Daten werden verwendet, um die Prognose alle sechs Stunden zu aktualisieren. Wenn neue Daten eintreffen, verbessert die prädiktive Skalierung kontinuierlich die Genauigkeit zukünftiger Prognosen. Wenn Sie die prädiktive Skalierung zum ersten Mal aktivieren, wird sie im Modus *nur Prognose* ausgeführt. In diesem Modus werden Prognosen generiert, Ihr Amazon-ECS-Service wird jedoch nicht auf der Grundlage dieser Prognosen skaliert. Das bedeutet, dass Sie die Genauigkeit und Eignung der Prognose bewerten können. Sie können Prognosedaten mithilfe des `GetPredictiveScalingForecast`-API-Vorgangs oder der AWS-Managementkonsole anzeigen. Wenn Sie sich entscheiden, prädiktive Skalierung zu verwenden, schalten Sie die Skalierungsrichtlinie in den Modus *Prognose und Skalierung* um. In diesem Modus passiert Folgendes. Ihr Amazon-ECS-Service wird standardmäßig zu Beginn jeder Stunde auf der Grundlage der Prognose für diese Stunde skaliert. Sie können wählen, ob Sie früher beginnen möchten, indem Sie die `SchedulingBufferTime`-Eigenschaft im `PutScalingPolicy`-API-Vorgang verwenden. Dadurch werden neue Aufgaben vor dem prognostizierten Bedarf gestartet und sie haben Zeit, den Vorgang zu starten und für den Datenverkehr bereit zu sein. ### Maximale Grenze für Aufgaben Wenn Sie Amazon-ECS-Services für die Skalierung registrieren, definieren Sie eine maximale Anzahl von Aufgaben, die pro Service gestartet werden können. Wenn Skalierungsrichtlinien festgelegt sind, können sie die Anzahl der Aufgaben standardmäßig nicht über die Höchstgrenze bringen. Alternativ können Sie zulassen, dass die maximale Anzahl von Aufgaben des Service automatisch erhöht wird, wenn sich die Prognose der maximalen Anzahl von Aufgaben des Amazon-ECS-Service nähert oder diese überschreitet. **Warnung** Seien Sie vorsichtig, wenn Sie zulassen, dass die maximale Anzahl von Aufgaben automatisch erhöht wird. Dies kann dazu führen, dass mehr Aufgaben als vorgesehen gestartet werden, wenn die erhöhte maximale Anzahl von Aufgaben nicht überwacht und verwaltet wird. Die erhöhte maximale Anzahl von Aufgaben wird dann zur neuen normalen Höchstanzahl von Aufgaben für den Amazon-ECS-Service, bis Sie sie manuell aktualisieren. Die maximale Anzahl von Aufgaben wird nicht automatisch auf das ursprüngliche Maximum zurückgesetzt. ### Unterstützte -Regionen + USA Ost (Nord-Virginia) + USA Ost (Ohio) + USA West (Nordkalifornien) + USA West (Oregon) + Africa (Cape Town) + Asia Pacific (Hongkong) + Asien-Pazifik (Jakarta) + Asien-Pazifik (Mumbai) + Asien-Pazifik (Osaka) + Asien-Pazifik (Seoul) + Asien-Pazifik (Singapur) + Asien-Pazifik (Sydney) + Asien-Pazifik (Tokio) + Canada (Central) + China (Peking) + China (Ningxia) + Europe (Frankfurt) + Europa (Irland) + Europa (London) + Europa (Milan) + Europe (Paris) + Europe (Stockholm) + Middle East (Bahrain) + Südamerika (São Paulo) + AWS GovCloud (US-Ost) + AWS GovCloud (US-West) # Eine Richtlinie für die prädiktive Skalierung für Service-Auto-Scaling von Amazon ECS erstellen Erstellen Sie eine Richtlinie für die prädiktive Skalierung, damit Amazon ECS die Anzahl der Aufgaben, die von Ihrem Service ausgeführt werden, auf Grundlage historischer Daten erhöht oder verringert. **Anmerkung** Ein neuer Service muss Daten für mindestens 24 Stunden bereitstellen, bevor eine Prognose generiert werden kann. ## Konsole 1. Zusätzlich zu den IAM-Standardberechtigungen für das Erstellen und Aktualisieren von Services benötigen Sie zusätzliche Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche IAM-Berechtigungen für Service-Auto-Scaling von Amazon ECS](auto-scaling-IAM.md). 1. Ermitteln Sie die Metriken, die für die Richtlinie verwendet werden sollen. Die folgenden Metriken sind verfügbar: + **ECSServiceDurchschnitt CPUUtilization** — Die durchschnittliche CPU-Auslastung, die der Service verwenden sollte. + **ECSServiceAverageMemoryUtilization**— Durchschnittliche Speicherauslastung, die der Service verwenden sollte. + **ALBRequestCountPerTarget**— Die durchschnittliche Anzahl von Anfragen pro Minute, die diese Aufgabe idealerweise erhalten sollte. Sie können alternativ eine benutzerdefinierte Metrik verwenden. Sie müssen die folgenden Werte definieren: + Auslastung – eine Metrik, die die volle Auslastung Ihrer Anwendung genau wiedergibt und den Aspekt Ihrer Anwendung darstellt, der für die Skalierung am wichtigsten ist. + Skalierungsmetrik – der beste Indikator dafür, wie viel Auslastung für Ihre Anwendung ideal ist. 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** und dann **Anzahl der Aufgaben festlegen** aus. 1. Wählen Sie unter **Anzahl der Aufgaben für den Amazon-ECS-Service** die Option **Auto Scaling verwenden** aus. Der Abschnitt **Anzahl der Aufgaben** wird angezeigt. 1. Geben Sie unter **Mindestanzahl an Aufgaben**, die Untergrenze der Anzahl der Aufgaben an, die das Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht unterschreiten. 1. Geben Sie unter **Maximum** die Höchstanzahl der Aufgaben an, die Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht überschreiten. 1. Wählen Sie **Speichern**. Die Richtlinien-Seite wird angezeigt. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. Die Seite **Richtlinie erstellen** wird angezeigt. 1. Wählen Sie für **Typ der Skalierungsrichtlinie** die Option **Prädiktive Skalierung** aus. 1. Geben Sie unter **Policy name** (Richtlinienname) einen Namen für diese Richtlinie ein. 1. Für **Metrikpaar** wählen Sie Ihre Metriken aus der Liste der Optionen aus. Wenn Sie **Anzahl der Application Load Balancer pro Ziel** auswählen, wählen Sie anschließend in **Zielgruppe** eine Zielgruppe aus. **Anzahl and Anforderungen pro Ziel für Application Load Balancer** wird nur unterstützt, wenn Sie eine Zielgruppe für Application Load Balancer an Ihren Service angehängt haben. Wenn Sie **Benutzerdefiniertes Metrikpaar** auswählen, wählen Sie dann aus den Listen individuelle Metriken für **Lastmetrik** und **Skalierungsmetrik** aus. 1. Geben Sie für **Zielauslastung** den Zielwert für den Prozentsatz der Aufgaben ein, die Amazon ECS aufrechterhalten soll. Service-Auto-Scaling skaliert Ihre Kapazität auf, bis die durchschnittliche Auslastung der Zielauslastung entspricht oder bis sie die von Ihnen angegebene maximale Anzahl von Aufgaben erreicht. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. ## AWS CLI Gehen Sie AWS CLI wie folgt vor, um Richtlinien für die vorausschauende Skalierung für Ihren Amazon ECS-Service zu konfigurieren. Ersetzen Sie jeden *user input placeholder* durch Ihre Informationen. Weitere Informationen zu den CloudWatch Metriken, die Sie angeben können, finden Sie [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)in der *Amazon EC2 Auto Scaling API-Referenz.* ### Beispiel 1: Eine Richtlinie für die prädiktive Skalierung mit vordefiniertem Arbeitsspeicher. Nachstehend finden Sie eine Beispielrichtlinie mit einer vordefinierten Speicherkonfiguration. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceMemoryUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` Das folgende Beispiel veranschaulicht die Erstellung der Richtlinie, indem der [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)Befehl mit der angegebenen Konfigurationsdatei ausgeführt wird. ``` aws application-autoscaling put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Wenn der Befehl erfolgreich ausgeführt wurde, gibt er den ARN der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` ### Beispiel 2: Eine Richtlinie für die prädiktive Skalierung mit vordefiniertem CPU. Folgendes ist eine Beispielrichtlinie mit einer vordefinierten CPU-Konfiguration. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 0.00000004, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceCPUUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` Das folgende Beispiel zeigt, wie die Richtlinie erstellt wird, indem der [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)Befehl mit der angegebenen Konfigurationsdatei ausgeführt wird. ``` aws aas put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Wenn der Befehl erfolgreich ausgeführt wurde, gibt er den ARN der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` # Auswertung Ihrer Richtlinien für prädiktive Skalierung für Amazon ECS Bevor Sie eine Richtlinie für die prädiktive Skalierung Ihrer Services verwenden, überprüfen Sie die Empfehlungen und andere Daten zu Ihrer Richtlinie in der Amazon-ECS-Konsole. Dies ist wichtig, denn eine Richtlinie für prädiktive Skalierung soll Ihre tatsächliche Kapazität erst dann skalieren, wenn Sie wissen, dass die Prognosen korrekt sind. Wenn der Service neu ist, kann es 24 Stunden dauern, bis die erste Prognose erstellt wird. Bei AWS der Erstellung einer Prognose werden historische Daten verwendet. Wenn Ihr Service noch nicht über ausreichend aktuelle Verlaufsdaten verfügt, füllt die prädiktive Skalierung die Prognose möglicherweise vorübergehend mit Aggregaten auf, die aus den aktuell verfügbaren Verlaufsaggregaten erstellt wurden. Prognosen werden bis zu zwei Wochen vor dem Erstellungsdatum einer Richtlinie aufgefüllt. ## Anzeigen Ihrer Richtlinien für prädiktive Skalierung Für eine effektive Analyse sollte Service-Auto-Scaling über mindestens zwei Richtlinien für prädiktive Skalierung zum Vergleich verfügen. (Sie können die Ergebnisse jedoch weiterhin für eine einzelne Richtlinie überprüfen.) Wenn Sie mehrere Richtlinien erstellen, können Sie eine Richtlinie, die eine Metrik verwendet, gegen eine Richtlinie auswerten, die eine andere Metrik verwendet. Sie können auch die Auswirkungen verschiedener Zielwert- und Metrikkombinationen bewerten. Nachdem Richtlinien für die prädiktive Skalierung erstellt wurden, beginnt Amazon ECS sofort mit der Auswertung, welche Richtlinie für die Skalierung Ihrer Gruppe besser geeignet wäre. **So zeigen Sie Empfehlungen in der Amazon-ECS-Konsole an** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** aus. 1. Wählen Sie die Richtlinie für die prädiktive Skalierung und dann **Aktionen**, **Prädiktive Skalierung**, **Empfehlungen anzeigen** aus. Sie können Details zu einer Richtlinie sowie unsere Empfehlung anzeigen. In der Empfehlung erfahren Sie, ob es besser wäre, die Richtlinie für prädiktive Skalierung zu verwenden, oder nicht. Wenn Sie sich nicht sicher sind, ob eine prädiktive Skalierungsrichtlinie für Ihre Gruppe geeignet ist, prüfen Sie die Spalten **Auswirkungen auf die Verfügbarkeit** und **Auswirkungen auf die Kosten**, um die richtige Richtlinie auszuwählen. Die Informationen in den einzelnen Spalten geben Aufschluss über die Auswirkungen der jeweiligen Richtlinie. + **Auswirkungen auf die Verfügbarkeit**: Beschreibt, ob die Richtlinie negative Auswirkungen auf die Verfügbarkeit vermeiden würde, indem genügend Aufgaben zur Bewältigung des Workloads bereitgestellt werden, und zieht einen Vergleich für den Fall, dass die Richtlinie nicht verwendet wird. + **Auswirkungen auf die Kosten**: Beschreibt, ob die Richtlinie negative Auswirkungen auf Ihre Kosten vermeiden würde, indem Aufgaben nicht übermäßig bereitgestellt werden, und zieht einen Vergleich für den Fall, dass die Richtlinie nicht verwendet wird. Eine zu hohe Bereitstellung führt dazu, dass Ihre Services nicht ausgelastet sind oder sich im Leerlauf befinden, was die Kosten nur noch weiter erhöht. Wenn Sie über mehrere Richtlinien verfügen, wird neben dem Namen der Richtlinie, die die meisten Verfügbarkeitsvorteile zu geringeren Kosten bietet, ein Tag für die **Beste Prognose** angezeigt. Die Auswirkungen auf die Verfügbarkeit werden stärker gewichtet. 1. (Optional) Um den gewünschten Zeitraum für die Empfehlungsergebnisse auszuwählen, wählen Sie den gewünschten Wert aus der Dropdown-Liste **Auswertungszeitraum**: **2 Tage**, **1 Woche** oder **2 Wochen**. Standardmäßig wird der Auswertungszeitraum auf die letzten zwei Wochen festgelegt. Ein längerer Auswertungszeitraum liefert mehr Datenpunkte für die Empfehlungsergebnisse. Das Hinzufügen weiterer Datenpunkte verbessert die Ergebnisse jedoch möglicherweise nicht, wenn sich Ihre Lastmuster geändert haben, z. B. nach einer Phase außergewöhnlich hoher Nachfrage. In diesem Fall können Sie eine gezieltere Empfehlung erhalten, indem Sie sich aktuellere Daten ansehen. **Anmerkung** Empfehlungen werden nur für Richtlinien generiert, die sich im Modus **Nur Prognose** befinden. Das Empfehlungs-Feature liefert bessere Ergebnisse, wenn sich eine Richtlinie während des gesamten Bewertungszeitraums im Modus **Nur Prognose** befindet. Wenn Sie eine Richtlinie im **Prognose- und Skalierungsmodus** starten und diese später in den Modus **Nur Prognose** wechselt, sind die Ergebnisse für diese Richtlinie wahrscheinlich verzerrt. Dies liegt daran, dass die Richtlinie bereits zur tatsächlichen Kapazität beigetragen hat. ## Anzeigen von Diagrammen zur Überwachung der prädiktiven Skalierung In der Konsole können Sie die Prognose der vergangenen Tage, Wochen oder Monate überprüfen, um zu visualisieren, wie gut die Richtlinie im Laufe der Zeit funktioniert. Sie können diese Informationen auch zur Auswertung der Genauigkeit von Vorhersagen verwenden, wenn Sie entscheiden, ob die tatsächliche Anzahl an Aufgaben durch eine Richtlinie skalieren lassen möchten. **So überprüfen Sie Überwachungsdiagramme für die prädiktive Skalierung in der Amazon-ECS-Konsole** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** aus. 1. Wählen Sie die Richtlinie für die prädiktive Skalierung und dann **Aktionen**, **Prädiktive Skalierung**, **Diagramm anzeigen** aus. 1. Im Abschnitt **Überwachung** können Sie die vergangenen und zukünftigen Prognosen Ihrer Richtlinie für Last und Kapazität im Vergleich zu tatsächlichen Werten anzeigen. Das Diagramm für **Last** zeigt Auslastungsprognosen und tatsächliche Werte für die ausgewählte Auslastungsmetrik. Das Diagramm zur **Kapazität** zeigt die Anzahl der von der Richtlinie vorhergesagten Aufgaben. Es enthält auch die tatsächliche Anzahl der gestarteten Aufgaben. Die vertikale Linie trennt Verlaufswerte von zukünftigen Prognosen. Diese Diagramme stehen kurz nach der Erstellung der Richtlinie zur Verfügung. 1. (Optional) Um die Menge der im Diagramm angezeigten Verlaufsdaten zu ändern, wählen Sie Ihren bevorzugten Wert aus der Dropdown-Liste **Auswertungszeitraum** oben auf der Seite aus. Der Auswertungszeitraum verändert die Daten auf dieser Seite in keiner Weise. Er ändert nur die Menge der angezeigten Verlaufsdaten. **Vergleichen von Daten im Diagramm für **Last**** Jede horizontale Linie stellt einen anderen Satz von Datenpunkten dar, die in einstündigen Intervallen gemeldet werden: 1. **Tatsächliche beobachtete Last** verwendet die SUM-Statistik für die von Ihnen gewählte Lastmetrik, um die gesamte stündliche Last im Verlauf anzuzeigen. 1. **Von der Richtlinie prognostizierte Last** zeigt die stündliche Lastprognose. Diese Prognose basiert auf den tatsächlichen Lastbeobachtungen der letzten zwei Wochen. **Vergleichen von Daten im Diagramm zur **Kapazität**** Jede horizontale Linie stellt einen anderen Satz von Datenpunkten dar, die in einstündigen Intervallen gemeldet werden: 1. **Tatsächliche beobachtete Anzahl an Aufgaben** zeigt die tatsächliche Kapazität Ihres Amazon-ECS-Service in der Vergangenheit an, die von Ihren anderen Skalierungsrichtlinien und der für den ausgewählten Zeitraum geltenden Mindestgruppengröße abhängt. 1. **Von der Richtlinie prognostizierte Kapazität** zeigt die Basiskapazität an, die Sie zu Beginn jeder Stunde erwarten können, wenn sich die Richtlinie im Modus **Prognose und Skalierung** befindet. 1. **Abgeleitete erforderliche Anzahl an Aufgaben** zeigt die ideale Anzahl von Aufgaben in Ihrem Service, um die Skalierungsmetrik auf dem von Ihnen gewählten Zielwert zu halten. 1. **Mindestanzahl an Aufgaben** gibt die Mindestanzahl von Aufgaben in Ihrem Service an. 1. **Maximale Kapazität** gibt die maximale Anzahl von Aufgaben in Ihrem Service an. Um die abgeleitete erforderliche Kapazität zu berechnen, gehen wir zunächst davon aus, dass jede Aufgabe bei einem bestimmten Zielwert gleichmäßig ausgelastet ist. In der Praxis wird die Anzahl der Aufgaben nicht gleichmäßig ausgelastet. Wenn wir jedoch davon ausgehen, dass die Auslastung gleichmäßig auf die Aufgaben verteilt ist, können wir eine wahrscheinliche Schätzung der benötigten Kapazität vornehmen. Der erforderliche Anzahl an Aufgaben wird dann umgekehrt proportional zu der Skalierungsmetrik berechnet, die Sie für Ihre Richtlinie für prädiktive Skalierung verwendet haben. Mit anderen Worten heißt das: Wenn die Anzahl an Aufgaben zunimmt, nimmt die Skalierungsmetrik im gleichen Maß ab. Wenn sich beispielsweise die Anzahl an Aufgaben verdoppelt, muss die Skalierungsmetrik um die Hälfte verringert werden. Die Formel für die abgeleitete erforderliche Kapazität lautet wie folgt: `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)` Als Beispiel nehmen wir den `actualServiceUnits` (`10`) und den `scalingMetricValue` (`30`) für eine bestimmte Stunde her. Wir nehmen dann die `targetUtilization`, die Sie in Ihrer Richtlinie für prädiktive Skalierung (`60`) angegeben haben, und berechnen die abgeleitete erforderliche Kapazität für dieselbe Stunde. Dies gibt den Wert `5` zurück. Das bedeutet, dass fünf die abgeleitete Kapazität ist, die erforderlich ist, um die Kapazität im direkt umgekehrten Verhältnis zum Zielwert der Skalierungsmetrik zu erhalten. **Anmerkung** Es stehen Ihnen verschiedene Möglichkeiten zur Verfügung, mit denen Sie die Kosteneinsparungen und die Verfügbarkeit Ihrer Anwendung verbessern können. Sie verwenden die prädiktive Skalierung für die Basiskapazität und die dynamische Skalierung für den Umgang mit zusätzlicher Kapazität. Die dynamische Skalierung funktioniert unabhängig von der prädiktiven Skalierung, indem sie basierend auf der aktuellen Auslastung ab- und aufskaliert. Zunächst berechnet Amazon ECS die empfohlene Anzahl an Aufgaben für jede nicht geplante Skalierungsrichtlinie. Anschließend skaliert die Lösung basierend auf der Richtlinie, die die größte Anzahl von Aufgaben bereitstellt. Damit bei sinkender Last eine Abskalierung erfolgen kann, sollte Ihr Service immer über mindestens eine dynamische Skalierungsrichtlinie verfügen, bei der das Abskalieren aktiviert ist. Sie können die Skalierungsleistung verbessern, indem Sie sicherstellen, dass Ihre Mindest- und Höchstkapazität nicht zu restriktiv ist. Eine Richtlinie mit einer empfohlenen Anzahl von Aufgaben, die nicht innerhalb des Mindest- und Höchstkapazitätsbereichs liegt, wird an der Ab- und Aufskalierung gehindert. # Überwachen Sie prädiktive Skalierungsmetriken für Amazon ECS mit CloudWatch Sie können Amazon verwenden CloudWatch , um Ihre Daten im Hinblick auf eine vorausschauende Skalierung zu überwachen. Eine Richtlinie für die prädiktive Skalierung sammelt Daten, um Ihre zukünftige Last zu prognostizieren. Die gesammelten Daten werden automatisch in regelmäßigen CloudWatch Abständen gespeichert und können verwendet werden, um zu visualisieren, wie gut die Richtlinie im Laufe der Zeit abschneidet. Sie können auch CloudWatch Alarme einrichten, um Sie zu benachrichtigen, wenn sich Leistungsindikatoren über die von Ihnen definierten Grenzwerte hinaus ändern. ## Visualisieren historischer Prognosedaten Ladeprognosedaten für eine Richtlinie zur vorausschauenden Skalierung können in eingesehen werden CloudWatch und können nützlich sein, wenn Prognosen im Vergleich zu anderen CloudWatch Metriken in einem einzigen Diagramm visualisiert werden. Sie können auch einen größeren Zeitraum anzeigen, um Trends im Zeitverlauf zu erkennen. Ihnen stehen historische Metriken von bis zu 15 Monaten zur Verfügung, um die Leistung Ihrer Richtlinie besser analysieren zu können. **Um historische Prognosedaten mit der Konsole anzuzeigen CloudWatch** 1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Wählen Sie im Navigationsbereich **Metrics** (Metriken) und dann **All metrics** (Alle Metriken) aus. 1. Wählen Sie den Metrik-Namespace für **Application Auto Scaling** aus. 1. Wählen Sie **Prädiktive Skalierung: Lastprognosen** aus. 1. Geben Sie im Suchfeld den Namen der Richtlinie für die prädiktive Skalierung oder den Namen der Amazon–ECS-Servicegruppe ein, und drücken Sie dann die Eingabetaste, um die Ergebnisse zu filtern. 1. Um eine Metrik grafisch darzustellen, müssen Sie das Kontrollkästchen neben der Metrik aktivieren. Wenn Sie den Namen des Diagramms ändern möchten, wählen Sie das Bleistiftsymbol. Wenn Sie den Zeitraum ändern möchten, müssen Sie einen der vordefinierten Werte oder **custom (benutzerdefiniert)** auswählen. Weitere Informationen finden Sie unter [Grafische Darstellung einer Metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html) im * CloudWatch Amazon-Benutzerhandbuch*. 1. Wenn Sie die Statistik ändern möchten, wählen Sie die Registerkarte **Graphed metrics** aus. Wählen Sie die Spaltenüberschrift oder einen einzelnen Wert und anschließend eine andere Statistik aus. Sie können zwar für jede Metrik eine beliebige Statistik wählen, aber nicht alle Statistiken sind für **PredictiveScalingLoadForecast**Metriken nützlich. So sind zum Beispiel die Statistiken **Durchschnitt**, **Minimum** und **Maximum** hilfreich, die Statistik **Summe** jedoch nicht. 1. Wenn Sie dem Diagramm eine weitere Metrik hinzufügen möchten, wählen Sie unter **Browse** (Durchsuchen) die Option **All** (Alle) aus, suchen Sie nach der spezifischen Metrik, und aktivieren Sie dann das zugehörige Kontrollkästchen. Sie können bis zu 10 Metriken hinzufügen. 1. (Optional) Um das Diagramm zu einem CloudWatch Dashboard hinzuzufügen, wählen Sie **Aktionen**, **Zum Dashboard hinzufügen** aus. ## Erstellen von Genauigkeitsmetriken mithilfe von Metrikberechnungen Mit metrischer Mathematik können Sie mehrere CloudWatch Metriken abfragen und mathematische Ausdrücke verwenden, um neue Zeitreihen auf der Grundlage dieser Metriken zu erstellen. Sie können die resultierenden Zeitreihen auf der CloudWatch Konsole visualisieren und sie zu Dashboards hinzufügen. Weitere Informationen zur metrischen Mathematik finden Sie unter [Verwenden von metrischer Mathematik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) im * CloudWatch Amazon-Benutzerhandbuch*. Mithilfe von Metrikberechnungen können Sie die Daten, die Service-Auto-Scaling für die prädiktive Skalierung generiert, auf unterschiedliche Weise grafisch darstellen. So können Sie die Leistung von Richtlinien im Zeitverlauf überwachen und erkennen, ob Ihre Kombination von Metriken möglicherweise verbessert werden kann. Sie können beispielsweise einen Metrikberechnungsausdruck verwenden, um den [Mean Absolute Percentage Error](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE) zu überwachen. Die MAPE-Metrik hilft bei der Überwachung der Differenz zwischen den prognostizierten Werten und den tatsächlichen Werten eines bestimmten Prognosefensters. Änderungen des MAPE-Werts können Aufschluss darüber geben, ob sich die Leistung der Richtlinie im Laufe der Zeit verschlechtert, wenn sich Ihre Anwendung verändert. Eine Erhöhung des MAPE-Werts bedeutet eine größere Diskrepanz zwischen prognostizierten und tatsächlichen Werten. **Beispiel: Metrikberechnungsausdruck** Für die ersten Schritte mit dieser Art von Diagramm können Sie beispielsweise den Metrikberechnungsausdruck aus dem folgenden Beispiel erstellen. Anstelle einer einzelnen Metrik gibt es für `MetricDataQueries` ein Array von Abfragestrukturen für Metrikdaten. Jedes Element in `MetricDataQueries` ruft eine Metrik ab oder wendet einen mathematischen Ausdruck an. Das erste Element (`e1`) ist der mathematische Ausdruck. Der angegebene Ausdruck legt den Parameter `ReturnData` auf `true` fest, was letztendlich eine einzelne Zeitreihe generiert. Für alle anderen Metriken hat `ReturnData` den Wert `false`. In diesem Beispiel verwendet der angegebene Ausdruck die tatsächlichen und prognostizierten Werte als Eingabe und gibt die neue Metrik (MAPE) zurück. `m1`ist die CloudWatch Metrik, die die tatsächlichen Lastwerte enthält (vorausgesetzt, die CPU-Auslastung ist die Lastmetrik, die ursprünglich für die genannte `my-predictive-scaling-policy` Richtlinie angegeben wurde). `m2`ist die CloudWatch Metrik, die die prognostizierten Lastwerte enthält. Die mathematische Syntax für die MAPE-Metrik lautet wie folgt: *Durchschnitt von (abs ((tatsächlicher Wert - prognostizierter Wert)/(tatsächlichen Wert)))* ### Visualisieren Ihrer Genauigkeitsmetriken und Festlegen von Alarmen Um die Genauigkeitsmetrikdaten zu visualisieren, wählen Sie in der CloudWatch Konsole die Registerkarte **Metriken** aus. Von dort aus können Sie die Daten grafisch darstellen. Weitere Informationen finden Sie unter [Hinzufügen eines mathematischen Ausdrucks zu einem CloudWatch Diagramm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console) im * CloudWatch Amazon-Benutzerhandbuch*. Im Abschnitt **Metrics** (Metriken) können Sie auch einen Alarm für eine von Ihnen überwachte Metrik festlegen. Wählen Sie auf der Registerkarte **Graphed metrics** (Grafisch dargestellte Metriken) unter der Spalte **Actions** (Aktionen) das Symbol **Create alarm** (Alarm erstellen) aus. Das Symbol **Create alarm** (Alarm erstellen) wird als kleine Glocke dargestellt. Weitere Informationen und Benachrichtigungsoptionen finden Sie unter [Erstellen eines CloudWatch Alarms auf der Grundlage eines metrischen mathematischen Ausdrucks](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) und [Benachrichtigung von Benutzern über Alarmänderungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html) im * CloudWatch Amazon-Benutzerhandbuch*. Alternativ können Sie [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)und verwenden, [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)um Berechnungen mithilfe metrischer Mathematik durchzuführen und Alarme auf der Grundlage der Ausgabe zu erstellen. # Geplante Aktionen verwenden, um Prognosewerte für Amazon ECS zu überschreiben Manchmal haben Sie möglicherweise zusätzliche Informationen zu Ihren zukünftigen Anwendungsanforderungen, die bei der Prognoseberechnung nicht berücksichtigt werden können. Prognoseberechnungen können beispielsweise die Aufgaben unterschätzen, die für ein bevorstehendes Marketing-Ereignis benötigt wird. Sie können geplante Aktionen verwenden, um die Prognose in zukünftigen Zeiträumen vorübergehend zu überschreiben. Die geplanten Aktionen können auf einer wiederkehrenden Basis oder zu einem bestimmten Zeitpunkt ausgeführt werden, wenn einmalige Nachfrageschwankungen auftreten. Sie können beispielsweise eine geplante Aktion mit einer höheren Anzahl an Aufgaben als die prognostizierte erstellen. Zur Laufzeit aktualisiert Amazon ECS die Mindestanzahl von Aufgaben in Ihrem Service. Da die prädiktive Skalierung die Anzahl der Aufgaben optimiert, wird eine geplante Aktion mit einer minimalen Anzahl an Aufgaben, die höher als die Prognosewerte ist, berücksichtigt. Dadurch wird verhindert, dass die Anzahl der Aufgaben geringer ist als erwartet. Um das Überschreiben der Prognose zu stoppen, setzen Sie über eine zweite geplante Aktion die minimale Anzahl an Aufgaben auf ihre ursprüngliche Einstellung zurück. Im folgenden Verfahren werden die Schritte zum Überschreiben der Prognose in zukünftigen Zeiträumen erläutert. **Topics** + [Schritt 1: (Optional) Analysieren von Zeitreihendaten](#analyzing-time-series-data) + [Schritt 2: Erstellen von zwei geplanten Aktionen](#scheduling-capacity) **Wichtig** In diesem Thema wird davon ausgegangen, dass Sie versuchen, die Prognose zu überschreiben, um auf eine höhere Kapazität als die prognostizierte zu skalieren. Wenn Sie die Anzahl der Aufgaben vorübergehend verringern müssen, ohne dass dies durch eine Richtlinie zur prädiktiven Skalierung beeinträchtigt wird, verwenden Sie stattdessen den Modus *Nur Prognose*. Im Modus Nur Prognose generiert die prädiktive Skalierung zwar weiterhin Prognosen, die Anzahl der Aufgaben wird jedoch nicht automatisch erhöht. Anschließend können Sie die Ressourcennutzung überwachen und die Anzahl der Aufgaben nach Bedarf manuell verringern. ## Schritt 1: (Optional) Analysieren von Zeitreihendaten Beginnen Sie mit der Analyse der Prognose-Zeitreihendaten. Dies ist ein optionaler Schritt, aber es ist hilfreich, wenn Sie die Details der Prognose verstehen möchten. 1. **Rufen Sie die Prognose ab** Nachdem die Prognose erstellt wurde, können Sie einen bestimmten Zeitraum in der Prognose abfragen. Ziel der Abfrage ist es, einen vollständigen Überblick über die Zeitreihendaten für einen bestimmten Zeitraum zu erhalten. Ihre Abfrage kann Prognosedaten bis zwei Tage in die Zukunft enthalten. Wenn Sie die prädiktive Skalierung eine Weile verwenden, können Sie auch auf Ihre früheren Prognosedaten zugreifen. Der maximale Zeitraum zwischen der Start- und Endzeit beträgt jedoch 30 Tage. Um die Prognose mithilfe des [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI Befehls abzurufen, geben Sie im Befehl die folgenden Parameter an: + Geben Sie den Namen des Clusters im Parameter `resource-id` an. + Geben Sie den Namen der Richtlinie im `--policy-name`-Parameter an. + Geben Sie die Startzeit im `--start-time`-Parameter an, um nur prognostizierte Daten für den angegebenen Zeitpunkt oder danach zurückzugeben. + Geben Sie die Endzeit im `--end-time`-Parameter an, um nur prognostizierte Daten für den angegebenen Zeitpunkt oder davor zurückzugeben. ``` aws application-autoscaling get-predictive-scaling-forecast \ --service-namespace ecs \ --resource-id service/MyCluster/test \ --policy-name cpu40-predictive-scaling-policy \ --scalable-dimension ecs:service:DesiredCount \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` Bei erfolgreicher Ausführung gibt der Befehl Daten zurück, die in etwa wie folgt aussehen: ``` { "LoadForecast": [ { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 153.0655799339254, 128.8288551285919, 107.1179447150675, 197.3601844551528, 626.4039934516954, 596.9441277518481, 677.9675713779869 ], "MetricSpecification": { "TargetValue": 40.0, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } } } ], "CapacityForecast": { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 2.0, 2.0, 2.0, 2.0, 4.0, 4.0, 4.0 ] }, "UpdateTime": "2021-05-19T01:52:50.118000+00:00" } ``` Die Antwort enthält zwei Prognosen: `LoadForecast` und `CapacityForecast`. `LoadForecast` zeigt die stündliche Lastprognose an. `CapacityForecast` zeigt Prognosewerte für die Kapazität an, die stündlich benötigt wird, um die prognostizierte Last zu verarbeiten, während ein `TargetValue` von 40,0 (40 % durchschnittliche CPU-Auslastung) aufrechterhalten bleibt. 1. **Identifizieren des Zielzeitraums** Ermitteln Sie die Stunde oder die Stunden, zu der/zu denen die einmalige Nachfrageschwankung stattfinden soll. Denken Sie daran, dass die in der Prognose angezeigten Datumsangaben und Uhrzeiten in UTC angegeben sind. ## Schritt 2: Erstellen von zwei geplanten Aktionen Erstellen Sie als Nächstes zwei geplante Aktionen für einen bestimmten Zeitraum, in dem Ihre Anwendung eine höhere Last aufweist als die prognostizierte Last. Wenn Sie beispielsweise während eines Marketing-Ereignisses für einen begrenzten Zeitraum ein erhöhtes Daten-Volume erwarten, können Sie eine einmalige Aktion planen, um die Mindestkapazität bei deren Beginn zu aktualisieren. Planen Sie dann eine weitere Aktion, um die Mindestkapazität auf die ursprüngliche Einstellung zurückzusetzen, wenn das Ereignis endet. 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** aus. Die Richtlinien-Seite wird angezeigt. 1. Wählen Sie **Geplante Aktionen** und dann **Erstellen** aus. Die Seite **Geplante Aktion erstellen** wird angezeigt. 1. Geben Sie für **Aktionsname** einen eindeutigen Namen ein. 1. Wählen Sie für **Zeitzone** eine Zeitzone aus. Alle aufgelisteten Zeitzonen stammen aus der IANA-Zeitzonendatenbank. Weitere Informationen finden Sie unter [Liste der Zeitzonen der TZ-Datenbank](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 1. Geben Sie als **Startzeit** das **Datum** und die **Uhrzeit** ein, zu der die Aktion gestartet wird. 1. Wählen Sie für **Recurrence (Wiederholung)** **Once (Einmal)** aus. 1. Geben Sie unter **Aufgabenanpassungen** für Minimum einen Wert ein, der kleiner oder gleich der maximalen Anzahl von Aufgaben ist. 1. Wählen Sie **Geplante Aktion erstellen**. Die Richtlinien-Seite wird angezeigt. 1. Konfigurieren Sie eine zweite geplante Aktion, um die Mindestanzahl an Aufgaben am Ende des Ereignisses wieder auf die ursprüngliche Einstellung zurückzustellen. Die prädiktive Skalierung kann die Kapazität nur skalieren, wenn der Wert, den Sie für **Minimum** angeben, niedriger ist als die Prognosewerte. **Erstellen von zwei geplanten Aktionen für einmalige Ereignisse (AWS CLI)** Verwenden Sie den Befehl [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html), AWS CLI um die geplanten Aktionen zu erstellen. Lassen Sie uns als Beispiel einen Zeitplan definieren, der am 19. Mai um 17:00 Uhr acht Stunden lang eine Mindestkapazität von drei Instances beibehält. Die folgenden Befehle veranschaulichen die Implementierung dieses Szenarios. Der erste Befehl [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) weist Amazon EC2 Auto Scaling an, die Mindestkapazität der angegebenen Auto Scaling-Gruppe am 19. Mai 2021 um 17:00 Uhr UTC zu aktualisieren. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \ --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3 ``` Der zweite Befehl weist Amazon EC2 Auto Scaling an, die Mindestkapazität der Gruppe am 20. Mai 2021 um 1:00 Uhr UTC auf eins zu setzen. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \ --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1 ``` Nachdem Sie der Auto-Scaling-Gruppe diese geplanten Aktionen hinzugefügt haben, führt Amazon EC2 Auto Scaling folgende Schritte aus: + Um 17:00 Uhr UTC am 19. Mai 2021 wird die erste geplante Aktion ausgeführt. Wenn die Gruppe derzeit weniger als drei Instances hat, wird die Gruppe auf drei Instances skaliert. Während dieser Zeit und für die Dauer der nächsten acht Stunden kann Amazon EC2 Auto Scaling weiterhin skaliert werden, wenn die prognostizierte Kapazität höher als die tatsächliche Kapazität ist oder wenn eine Richtlinie für dynamische Skalierung in Kraft ist. + Um 1:00 Uhr UTC am 20. Mai 2021 wird die zweite geplante Aktion ausgeführt. Dadurch wird die Mindestkapazität am Ende des Ereignisses auf die ursprüngliche Einstellung zurückgesetzt. ### Skalierung basierend auf wiederkehrenden Zeitplänen Um die Prognose jede Woche während des gleichen Zeitraums zu überschreiben, erstellen Sie zwei geplante Aktionen und stellen die Zeit- und Datumslogik mithilfe eines Cron-Ausdrucks bereit. Der Cron-Ausdruck besteht aus fünf Feldern, getrennt durch Leerzeichen: [Minute] [Stunde] [Tag\$1des\$1Monats] [Monat\$1des\$1Jahres] [Wochentag]. Felder können alle zulässigen Werte enthalten, einschließlich Sonderzeichen. Beispielsweise führt der folgende Cron-Ausdruck jeden Dienstag um 6:30 Uhr die Aktion aus. Das Sternchen wird als Platzhalter verwendet, um alle Werte für ein Feld abzugleichen. ``` 30 6 * * 2 ``` ### Weitere Informationen finden Sie auch unter Weitere Informationen zur Verwaltung von geplanten Aktionen finden Sie unter [Verwenden Sie geplante Aktionen, um Amazon ECS-Services zu skalieren](service-autoscaling-schedulescaling.md). # Erweiterte prädiktive Skalierungsrichtlinie mit benutzerdefinierten Metriken für Amazon ECS In einer prädiktiven Skalierungsrichtlinie können Sie vordefinierte oder benutzerdefinierte Metriken verwenden. Benutzerdefinierte Metriken sind nützlich, wenn die vordefinierten Metriken (z. B. CPU, Arbeitsspeicher usw.) nicht ausreichen, um Ihre Anwendungslast ausreichend zu beschreiben. Wenn Sie eine Richtlinie für vorausschauende Skalierung mit benutzerdefinierten Metriken erstellen, können Sie andere Metriken angeben, die von bereitgestellt werden. CloudWatch AWS Alternativ können Sie Metriken angeben, die Sie selbst definieren und veröffentlichen. Sie können auch metrische Mathematik verwenden, um bestehende Metriken zu aggregieren und in eine neue Zeitreihe umzuwandeln, die AWS nicht automatisch erfasst wird. Wenn Sie beispielsweise Werte in Ihren Daten kombinieren, indem Sie neue Summen oder Durchschnittswerte berechnen, nennt man das *Aggregieren*. Die resultierenden Daten werden als *Aggregat* bezeichnet. Der folgende Abschnitt enthält bewährte Verfahren und Beispiele für die Erstellung der JSON-Struktur für die Richtlinie. ## Voraussetzungen Um benutzerdefinierte Metriken zu Ihrer prädiktiven Skalierungsrichtlinie hinzuzufügen, müssen Sie über entsprechende `cloudwatch:GetMetricData`-Berechtigungen verfügen. Wenn Sie Ihre eigenen Kennzahlen anstelle der bereitgestellten Metriken angeben möchten, müssen Sie Ihre Metriken zunächst auf veröffentlichen CloudWatch. AWS Weitere Informationen finden Sie unter [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) im * CloudWatch Amazon-Benutzerhandbuch*. Sollten Sie Ihre eigenen Metriken veröffentlichen, achten Sie darauf, dass Sie die Datenpunkte mindestens alle fünf Minuten veröffentlichen. Datenpunkte werden CloudWatch basierend auf der Länge des benötigten Zeitraums abgerufen. In der Lastmetrikspezifikation werden beispielsweise stündliche Messwerte verwendet, um die Auslastung Ihrer Anwendung zu messen. CloudWatch verwendet Ihre veröffentlichten Metrikdaten, um einen einzelnen Datenwert für einen beliebigen Zeitraum von einer Stunde bereitzustellen, indem alle Datenpunkte mit Zeitstempeln aggregiert werden, die in jeden Zeitraum von einer Stunde fallen. ## Best Practices Die folgenden bewährten Methoden können Ihnen helfen, benutzerdefinierte Metriken effektiver zu nutzen: + Bei der Angabe der Lastmetrik ist die sinnvollste Metrik eine, die die Last einer Auto-Scaling-Gruppe als Ganzes darstellt. + Bei der Angabe der Skalierungsmetrik ist die sinnvollste Metrik für die Skalierung ein durchschnittlicher Durchsatz oder eine durchschnittliche Auslastung pro Aufgabe. + Die Zielauslastung muss mit der Art der Skalierungsmetrik übereinstimmen. Bei einer Richtlinienkonfiguration, die die CPU-Auslastung verwendet, ist dies beispielsweise ein Zielprozentsatz. + Wenn diese Empfehlungen nicht befolgt werden, werden die prognostizierten zukünftigen Werte der Zeitreihen wahrscheinlich falsch sein. Um zu überprüfen, ob die Daten korrekt sind, können Sie die prognostizierten Werte in der Konsole einsehen. Sie können auch nach der Erstellung Ihrer Richtlinie für vorausschauende Skalierung die `LoadForecast` Objekte überprüfen, die durch einen API-Aufruf zurückgegeben wurden. [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) + Wir empfehlen Ihnen dringend, die prädiktive Skalierung im Modus Nur Prognose zu konfigurieren, damit Sie die Prognose auswerten können, bevor die prädiktive Skalierung mit der aktiven Skalierung beginnt. ## Einschränkungen + Sie können Datenpunkte von bis zu 10 Metriken in einer Metrikspezifikation abfragen. + Für die Zwecke dieses Limits zählt ein Ausdruck als eine Metrik. ## Fehlerbehebung einer Richtlinie für die prädiktive Skalierung mit benutzerdefinierten Metriken Wenn bei der Verwendung von benutzerdefinierten Metriken ein Problem auftritt, empfehlen wir Ihnen, wie folgt vorzugehen: + Wenn bei einer blue/green Bereitstellung bei der Verwendung eines Suchausdrucks ein Problem auftritt, stellen Sie sicher, dass Sie einen Suchausdruck erstellt haben, der nach einer teilweisen und nicht nach einer exakten Übereinstimmung sucht. Vergewissern Sie sich außerdem, dass Ihre Anfrage nur die Auto-Scaling-Gruppen findet, in denen die betreffende Anwendung ausgeführt wird. Weitere Informationen zur Syntax von Suchausdrücken finden Sie unter [Syntax von CloudWatch Suchausdrücken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html) im * CloudWatch Amazon-Benutzerhandbuch*. + Der [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)Befehl validiert einen Ausdruck, wenn Sie Ihre Skalierungsrichtlinie erstellen. Es besteht jedoch die Möglichkeit, dass dieser Befehl die genaue Ursache der erkannten Fehler nicht identifizieren kann. Um die Probleme zu beheben, beheben Sie die Fehler, die Sie als Antwort auf eine Anfrage auf den [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)Befehl erhalten. Sie können den Ausdruck auch von der CloudWatch Konsole aus beheben. + Sie müssen `false` für `ReturnData` angeben, wenn `MetricDataQueries` die Funktion SEARCH() allein ohne eine mathematische Funktion wie SUM() angibt. Das liegt daran, dass Suchausdrücke mehrere Zeitreihen zurückgeben können, während eine auf einem Ausdruck basierende Metrikspezifikation nur eine Zeitreihe zurückgeben kann. + Alle an einem Suchausdruck beteiligten Metriken sollten die gleiche Auflösung haben. # Erstellen der JSON für benutzerdefinierte Metriken für die prädiktive Skalierung mit Amazon ECS Der folgende Abschnitt enthält Beispiele für die Konfiguration der prädiktiven Skalierung für die Abfrage von Daten von CloudWatch. Es gibt zwei verschiedene Methoden, um diese Option zu konfigurieren, und die von Ihnen gewählte Methode wirkt sich darauf aus, welches Format Sie verwenden, um den JSON für Ihre prädiktive Skalierungsrichtlinie zu erstellen. Wenn Sie metrische Berechnungen verwenden, variiert das Format von JSON je nach der durchgeführten metrischen Berechnung weiter. 1. Informationen zum Erstellen einer Richtlinie, mit der Daten direkt aus anderen CloudWatch Metriken abgerufen werden, die von bereitgestellt werden AWS oder für die Sie Daten veröffentlichen CloudWatch, finden [Beispiel für eine Richtlinie zur vorausschauenden Skalierung mit benutzerdefinierten Last- und Skalierungsmetriken unter Verwendung von AWS CLI](#predictive-scaling-custom-metrics-example1) Sie unter. ## Beispiel für eine Richtlinie zur vorausschauenden Skalierung mit benutzerdefinierten Last- und Skalierungsmetriken unter Verwendung von AWS CLI Um eine Richtlinie für vorausschauende Skalierung mit benutzerdefinierten Last- und Skalierungsmetriken mit dem zu erstellen AWS CLI, speichern Sie die Argumente für `--predictive-scaling-configuration` in einer JSON-Datei mit dem Namen. `config.json` Sie beginnen mit dem Hinzufügen benutzerdefinierter Metriken, indem Sie die ersetzbaren Werte im folgenden Beispiel durch die Werte Ihrer Metriken und Ihrer Zielauslastung ersetzen. ``` { "MetricSpecifications": [ { "TargetValue": 50, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "scaling_metric", "MetricStat": { "Metric": { "MetricName": "MyUtilizationMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Average" } } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "MyLoadMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Sum" } } ] } } ] } ``` Weitere Informationen finden Sie [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)in der *Amazon EC2 Auto Scaling API-Referenz.* **Anmerkung** Im Folgenden finden Sie einige zusätzliche Ressourcen, die Ihnen bei der Suche nach Metriknamen, Namespaces, Dimensionen und Statistiken für Metriken helfen können: CloudWatch Informationen zu den verfügbaren Metriken für AWS Services finden Sie im * CloudWatch Amazon-Benutzerhandbuch* unter [AWS Services, die CloudWatch Metriken veröffentlichen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html). Den genauen Metriknamen, den Namespace und die Dimensionen (falls zutreffend) für eine CloudWatch Metrik mit dem finden Sie unter AWS CLI[list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html). Um diese Richtlinie zu erstellen, führen Sie den [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)Befehl mit der JSON-Datei als Eingabe aus, wie im folgenden Beispiel gezeigt. ``` aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json ``` Wenn der Befehl erfolgreich ausgeführt wurde, gibt er den Amazon-Ressourcennamen (ARN) der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy", "Alarms": [] } ``` # Metrikberechnungs-Ausdrücke verwenden Der folgende Abschnitt enthält Informationen zur Verwendung von Metrikberechnungen mit Richtlinien zur prädiktiven Skalierung in Ihrer Richtlinie. ## Metrikberechnung verstehen Wenn Sie lediglich vorhandene Metrikdaten aggregieren möchten, erspart Ihnen CloudWatch Metric Math den Aufwand und die Kosten für die Veröffentlichung einer weiteren Metrik in CloudWatch. Sie können jede verfügbare Metrik verwenden AWS , und Sie können auch Metriken verwenden, die Sie als Teil Ihrer Anwendungen definieren. Weitere Informationen finden Sie unter [Verwenden von metrischer Mathematik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) im * CloudWatch Amazon-Benutzerhandbuch*. Wenn Sie sich für die Verwendung eines metrischen mathematischen Ausdrucks in Ihrer prädiktiven Skalierungsrichtlinie entscheiden, sollten Sie die folgenden Punkte beachten: + Metrische mathematische Operationen verwenden die Datenpunkte der eindeutigen Kombination aus Metriknamen, Namespace und keys/value Dimensionspaaren von Metriken. + Sie können einen beliebigen arithmetischen Operator (\$1 - \$1/^), jede statistische Funktion (wie AVG oder SUM) oder eine andere Funktion verwenden, die diese Funktion unterstützt. CloudWatch + Sie können sowohl Metriken als auch die Ergebnisse anderer mathematischer Ausdrücke in den Formeln des mathematischen Ausdrucks verwenden. + Ihre metrischen mathematischen Ausdrücke können aus verschiedenen Aggregationen zusammengesetzt sein. Für das endgültige Aggregationsergebnis ist es jedoch eine bewährte Methode, `Average` für die Skalierungsmetrik und `Sum` für die Lastmetrik zu verwenden. + Alle Ausdrücke, die in einer metrischen Spezifikation verwendet werden, müssen letztendlich eine einzige Zeitreihe ergeben. Um metrische Mathematik zu verwenden, gehen Sie wie folgt vor: + Wählen Sie eine oder mehrere CloudWatch Metriken aus. Erstellen Sie dann den Ausdruck. Weitere Informationen finden Sie unter [Verwenden von metrischer Mathematik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) im * CloudWatch Amazon-Benutzerhandbuch*. + Stellen Sie mithilfe der CloudWatch Konsole oder der CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API sicher, dass der metrische mathematische Ausdruck gültig ist. ## Beispiel für eine prädiktive Skalierungspolitik, die Metriken mit metrischer Mathematik kombiniert (AWS CLI) Manchmal müssen Sie die Metrik nicht direkt angeben, sondern die Daten erst auf irgendeine Weise verarbeiten. Sie könnten zum Beispiel eine Anwendung haben, die Arbeit aus einer Amazon SQS-Warteschlange abruft, und Sie könnten die Anzahl der Objekte in der Warteschlange als Kriterium für die prädiktive Skalierung verwenden wollen. Die Anzahl der Nachrichten in der Warteschlange bestimmt nicht allein die Anzahl der Instances, die Sie benötigen. Daher ist weitere Arbeit erforderlich, um eine Metrik zu erstellen, die zur Berechnung des Rückstands pro Instance verwendet werden kann. Im Folgenden finden Sie ein Beispiel für eine prädiktive Skalierungsrichtlinie für dieses Szenario. Sie legt Skalierungs- und Auslastungsmetriken fest, die auf der Amazon SQS `ApproximateNumberOfMessagesVisible`-Metrik basieren, d.h. der Anzahl der Nachrichten, die für den Abruf aus der Warteschlange verfügbar sind. Es verwendet auch die Amazon EC2 Auto Scaling `GroupInServiceInstances`-Metrik und einen mathematischen Ausdruck, um den Rückstand pro Instance für die Skalierungsmetrik zu berechnen. ``` aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \ --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json --service-namespace ecs \ --resource-id service/MyCluster/test \ "MetricSpecifications": [ { "TargetValue": 100, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Label": "Get the queue size (the number of messages waiting to be processed)", "Id": "queue_size", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Get the group size (the number of running instances)", "Id": "running_capacity", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Calculate the backlog per instance", "Id": "scaling_metric", "Expression": "queue_size / running_capacity", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ], }, "Stat": "Sum" }, "ReturnData": true } ] } } ] } ``` Das Beispiel gibt den ARN der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy", "Alarms": [] } ``` # Amazon-ECS-Services verbinden Anwendungen, die in Amazon-ECS-Aufgaben ausgeführt werden, müssen häufig Verbindungen aus dem Internet empfangen oder eine Verbindung zu anderen Anwendungen, die in Amazon-ECS-Services ausgeführt werden, herstellen. Wenn Sie externe Verbindungen aus dem Internet benötigen, empfehlen wir die Verwendung von Elastic Load Balancing. Weitere Informationen zu integriertem Load Balancing finden Sie unter [Verwenden von Load Balancing für die Verteilung des Service-Datenverkehrs in Amazon ECS](service-load-balancing.md). Wenn Sie eine Anwendung benötigen, um eine Verbindung zu anderen Anwendungen herzustellen, die in Amazon-ECS-Services ausgeführt werden, bietet Amazon ECS die folgenden Möglichkeiten, dies ohne einen Load Balancer zu tun: + *Amazon ECS Service Connect* Wir empfehlen Service Connect, das eine Amazon-ECS-Konfiguration für Serviceerkennung, Konnektivität und Verkehrsüberwachung bietet. Mit Service Connect können Ihre Anwendungen Kurznamen und Standardports verwenden, um eine Verbindung zu Amazon ECS-Services im selben Cluster, anderen Clustern, einschließlich Across VPCs im selben, herzustellen AWS-Region. Wenn Sie Service Connect verwenden, verwaltet Amazon ECS alle Teile der Serviceerkennung: die Erstellung der Namen, die erkannt werden können, die dynamische Verwaltung von Einträgen für jede Aufgabe, wenn die Aufgaben gestartet und beendet werden, das Ausführen eines Agenten in jeder Aufgabe, der für die Erkennung der Namen konfiguriert ist. Ihre Anwendung kann die Namen mithilfe der Standardfunktionen für DNS-Namen und das Herstellen von Verbindungen nachschlagen. Wenn Ihre Anwendung dies bereits tut, müssen Sie Ihre Anwendung nicht ändern, um Service Connect zu verwenden. Sie stellen die vollständige Konfiguration in jedem Service und jeder Aufgabendefinition bereit. Amazon ECS verwaltet Änderungen an dieser Konfiguration in jeder Servicebereitstellung, um sicherzustellen, dass sich alle Aufgaben in einer Bereitstellung auf die gleiche Weise verhalten. Ein häufiges Problem bei DNS als Serviceerkennung ist beispielsweise die Steuerung einer Migration. Wenn Sie einen DNS-Namen so ändern, dass er auf die neuen Ersatz-IP-Adressen verweist, kann es die maximale TTL-Zeit dauern, bis alle Clients den neuen Service verwenden. Mit Service Connect aktualisiert die Client-Bereitstellung die Konfiguration, indem sie die Client-Aufgaben ersetzt. Sie können den Bereitstellungs-Schutzschalter und andere Bereitstellungskonfigurationen so konfigurieren, dass sie Service-Connect-Änderungen genauso beeinflussen wie jede andere Bereitstellung. Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md). + *Amazon-ECS-Serviceerkennung* Ein weiterer service-to-service Kommunikationsansatz ist die direkte Kommunikation mithilfe von Service Discovery. Bei diesem Ansatz können Sie die Integration der AWS Cloud Map -Serviceerkennung mit Amazon ECS verwenden. Mithilfe von Service Discovery synchronisiert Amazon ECS die Liste der gestarteten Aufgaben mit AWS Cloud Map, das einen DNS-Hostnamen verwaltet, der in die internen IP-Adressen einer oder mehrerer Aufgaben von diesem bestimmten Service aufgelöst wird. Andere Services in der Amazon VPC können diesen DNS-Hostnamen verwenden, um Datenverkehr unter Verwendung der internen IP-Adresse direkt an einen anderen Container zu senden. Dieser service-to-service Kommunikationsansatz bietet eine geringe Latenz. Zwischen den Containern befinden sich keine zusätzlichen Komponenten. Der Datenverkehr wird direkt von einem Container zum anderen Container geleitet. Dieser Ansatz eignet sich für den `awsvpc`-Netzwerkmodus, in dem jede Aufgabe ihre eigene eindeutige IP-Adresse hat. Die meiste Software unterstützt nur die Verwendung von DNS-`A`-Einträgen, die direkt in IP-Adressen aufgelöst werden. Bei Verwendung des `awsvpc`-Netzwerkmodus handelt es sich bei den IP-Adressen für jede Aufgabe um einen `A`-Datensatz. Wenn Sie jedoch den `bridge`-Netzwerkmodus verwenden, können sich mehrere Container dieselbe IP-Adresse teilen. Darüber hinaus führen dynamische Port-Zuordnungen dazu, dass den Containern nach dem Zufallsprinzip Port-Nummern für diese einzelne IP-Adresse zugewiesen werden. Zu diesem Zeitpunkt reicht ein `A`-Datensatz für die Serviceerkennung nicht mehr aus. Sie müssen auch einen `SRV`-Datensatz verwenden. Dieser Datensatztyp kann sowohl IP-Adressen als auch Port-Nummern nachverfolgen, erfordert jedoch, dass Sie die Anwendungen entsprechend konfigurieren. Einige vorgefertigte Anwendungen, die Sie verwenden, unterstützen möglicherweise keine `SRV`-Datensätze. Ein weiterer Vorteil des `awsvpc`-Netzwerkmodus besteht darin, dass Sie für jeden Service eine eigene Sicherheitsgruppe haben. Sie können diese Sicherheitsgruppe so konfigurieren, dass eingehende Verbindungen nur von den spezifischen vorgelagerten Services zugelassen werden, die mit diesem Service kommunizieren müssen. Der Hauptnachteil der direkten service-to-service Kommunikation mithilfe der Diensterkennung besteht darin, dass Sie zusätzliche Logik implementieren müssen, um Wiederholungsversuche durchzuführen und Verbindungsfehler zu beheben. DNS-Einträge haben einen Zeitraum time-to-live (TTL), der bestimmt, wie lange sie zwischengespeichert werden. Es dauert einige Zeit, bis der DNS-Datensatz aktualisiert ist und der Cache abläuft, sodass Ihre Anwendungen die neueste Version des DNS-Datensatz abrufen können. Es kann also sein, dass Ihre Anwendung den DNS-Datensatz so auflöst, dass er auf einen anderen Container verweist, der nicht mehr vorhanden ist. Ihre Anwendung muss Wiederholungsversuche verarbeiten und über eine Logik verfügen, um fehlerhafte Backends zu ignorieren. Weitere Informationen finden Sie unter [Die Serviceerkennung verwenden, um Amazon-ECS-Services mithilfe von DNS-Namen zu verbinden](service-discovery.md). + *Amazon VPC Lattice* Amazon VPC Lattice ist ein verwalteter Anwendungsnetzwerkservice, mit dem Amazon ECS-Kunden Anwendungen beobachten, sichern und überwachen können, die auf AWS Rechendiensten und Konten basieren VPCs, ohne ihren Code ändern zu müssen. VPC Lattice verwendet Zielgruppen, bei denen es sich um eine Sammlung von Rechenressourcen handelt. Diese Ziele führen Ihre Anwendung oder Ihren Service aus und können Amazon EC2 EC2-Instances, IP-Adressen, Lambda-Funktionen und Application Load Balancer sein. Durch die Zuordnung ihrer Amazon ECS-Services zu einer VPC Lattice-Zielgruppe können Kunden jetzt Amazon ECS-Aufgaben als IP-Ziele in VPC Lattice aktivieren. Amazon ECS registriert Aufgaben automatisch für die Zielgruppe von VPC Lattice, wenn Aufgaben für den registrierten Service gestartet werden. Weitere Informationen finden Sie unter [Verwenden Sie Amazon VPC Lattice, um Ihre Amazon ECS-Services zu verbinden, zu beobachten und zu sichern](ecs-vpc-lattice.md). ## Kompatibilitätstabelle für den Netzwerkmodus In der folgenden Tabelle wird die Kompatibilität zwischen diesen Optionen und den Aufgaben-Netzwerkmodi beschrieben. In der Tabelle bezieht sich „Client“ auf die Anwendung, die die Verbindungen innerhalb einer Amazon-ECS-Aufgabe herstellt. **** | Verbindungsoptionen | Überbrückt | `awsvpc` | Host | | --- | --- | --- | --- | | Serviceerkennung | Ja, setzt jedoch voraus, dass Clients die SRV-Einträge im DNS ohne hostPort kennen. | Ja | Ja, setzt jedoch voraus, dass Clients die SRV-Einträge im DNS ohne hostPort kennen. | | Service Connect | Ja | Ja | Nein | | VPC-Gitter | Ja | Ja | Ja | # Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden Amazon ECS Service Connect ermöglicht die Verwaltung der service-to-service Kommunikation als Amazon ECS-Konfiguration. Es erstellt sowohl die Serviceerkennung, als auch ein Service Mesh in Amazon ECS. Dies stellt die vollständige Konfiguration in jedem Service bereit, den Sie mithilfe von Servicebereitstellungen verwalten, eine einheitliche Methode zum Verweisen auf Ihre Services in Namespaces, die nicht von der VPC-DNS-Konfiguration abhängt, sowie standardisierte Metriken und Protokolle zur Überwachung aller Ihrer Anwendungen. Service Connect verbindet nur Services miteinander. Das folgende Diagramm zeigt ein Beispiel für ein Service-Connect-Netzwerk mit 2 Subnetzen in der VPC und 2 Services. Ein Client-Service, der WordPress mit einer Aufgabe in jedem Subnetz ausgeführt wird. Ein Serverservice, der MySQL mit 1 Aufgabe in jedem Subnetz ausführt. Beide Services sind hochverfügbar und widerstandsfähig gegenüber Aufgaben- und Availability-Zone-Problemen, da jeder Service mehrere Aufgaben ausführt, die auf zwei Subnetze verteilt sind. Die durchgezogenen Pfeile zeigen eine Verbindung von WordPress zu MySQL. Zum Beispiel ein `mysql --host=mysql` CLI-Befehl, der innerhalb des WordPress Containers in der Aufgabe mit der IP-Adresse ausgeführt wird`172.31.16.1`. Der Befehl verwendet den Kurznamen `mysql` auf dem Standardport für MySQL. Dieser Name und dieser Port stellen eine Verbindung zum Service-Connect-Proxy in derselben Aufgabe her. Der Proxy in der WordPress Aufgabe verwendet Round-Robin-Load Balancing und alle früheren Fehlerinformationen bei der Ausreißererkennung, um auszuwählen, zu welcher MySQL-Aufgabe eine Verbindung hergestellt werden soll. Wie die ausgefüllten Pfeile im Diagramm zeigen, stellt der Proxy eine Verbindung mit dem zweiten Proxy in der MySQL-Aufgabe mit der IP-Adresse `172.31.16.2` her. Der zweite Proxy stellt in derselben Aufgabe eine Verbindung zum lokalen MySQL-Server her. Beide Proxys melden die Verbindungsleistung, die in Diagrammen in den Amazon ECS- und CloudWatch Amazon-Konsolen sichtbar ist, sodass Sie Leistungskennzahlen von allen Arten von Anwendungen auf dieselbe Weise abrufen können. ![\[Beispiel für ein Service-Connect-Netzwerk mit minimalen HA-Services\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/images/serviceconnect.png) Die folgenden Begriffe werden mit Service Connect verwendet. **Port-Name** Die Konfiguration der Amazon-ECS-Aufgabendefinition, die einer bestimmten Portzuordnung einen Namen zuweist. Diese Konfiguration wird nur von Amazon ECS Service Connect verwendet. **Client-Alias** Die Amazon-ECS-Service-Konfiguration, die die im Endpunkt verwendete Portnummer zuweist. Darüber hinaus kann der Client-Alias den DNS-Namen des Endpunkts zuweisen und den Erkennungsnamen überschreiben. Wenn im Amazon-ECS-Service kein Erkennungsname angegeben ist, überschreibt der Client-Aliasname den Portnamen als Endpunktnamen. Beispiele für Endpunkte finden Sie in der Definition von *Endpunkt*. Einem Amazon-ECS-Service können mehrere Client-Aliase zugewiesen werden. Diese Konfiguration wird nur von Amazon ECS Service Connect verwendet. **Erkennungsname** Der optionale Zwischenname, den Sie für einen bestimmten Port aus der Aufgabendefinition erstellen können. Dieser Name wird verwendet, um einen AWS Cloud Map Service zu erstellen. Wenn dieser Name nicht angegeben wird, wird der Portname aus der Aufgabendefinition verwendet. Einem bestimmten Port und Amazon-ECS-Service können mehrere Erkennungsnamen zugewiesen werden. Diese Konfiguration wird nur von Amazon ECS Service Connect verwendet. AWS Cloud Map Dienstnamen müssen innerhalb eines Namespaces eindeutig sein. Aufgrund dieser Einschränkung können Sie für eine bestimmte Aufgabendefinition in jedem Namespace nur eine Service-Connect-Konfiguration ohne Erkennungsnamen haben. **Endpunkt** Die URL zum Herstellen einer Verbindung mit einer API oder Website. Die URL enthält das Protokoll, einen DNS-Namen und den Port. Für weitere Informationen über Endpunkte im Allgemeinen siehe [Endpunkt](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint) im *AWS -Glossary* in der Allgemeine Amazon Web Services-Referenz. Service Connect erstellt Endpunkte, die eine Verbindung zu Amazon-ECS-Services herstellen, und konfiguriert die Aufgaben in Amazon-ECS-Services, um eine Verbindung zu den Endpunkten herzustellen. Die URL enthält das Protokoll, einen DNS-Namen und den Port. Sie wählen das Protokoll und den Portnamen in der Aufgabendefinition aus, da der Port mit der Anwendung übereinstimmen muss, die sich im Container-Image befindet. Im Service wählen Sie jeden Port nach Namen aus und können den DNS-Namen zuweisen. Wenn Sie in der Amazon-ECS-Servicekonfiguration keinen DNS-Namen angeben, wird standardmäßig der Portname aus der Aufgabendefinition verwendet. Ein Service-Connect-Endpunkt könnte beispielsweise `http://blog:80`, `grpc://checkout:8080` oder `http://_db.production.internal:99` sein. **Service-Connect-Service** Die Konfiguration eines einzelnen Endpunkts in einem Amazon-ECS-Service. Dies ist ein Teil der Service Connect-Konfiguration, bestehend aus einer einzelnen Zeile in der **Service Connect and discovery name configuration** (Service-Connect- und Erkennungsnamen-Konfiguration) in der Konsole oder einem Objekt in der `services`-Liste in der JSON-Konfiguration eines Amazon ECS-Service. Diese Konfiguration wird nur von Amazon ECS Service Connect verwendet. Weitere Informationen finden Sie [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)in der Amazon Elastic Container Service API-Referenz. **Namespace** Der Kurzname oder der vollständige Amazon Resource Name (ARN) des AWS Cloud Map Namespaces zur Verwendung mit Service Connect. Der Namespace muss mit dem Amazon ECS-Service und -Cluster identisch AWS-Region sein. Der Typ des AWS Cloud Map Namespaces in hat keinen Einfluss auf Service Connect. Bei dem Namespace kann es sich um einen Namespace handeln, der AWS-Konto mit AWS Resource Access Manager Ihnen gemeinsam genutzt AWS RAM wird und in AWS-Regionen verfügbar AWS RAM ist. Weitere Informationen über geteilte Namespaces finden Sie unter [Kontoübergreifende Freigabe von AWS Cloud Map -Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) im *Entwicklerhandbuch für AWS Cloud Map *. Service Connect verwendet den AWS Cloud Map Namespace als logische Gruppierung von Amazon ECS-Aufgaben, die miteinander kommunizieren. Jeder Amazon-ECS-Service kann nur einem Namespace angehören. Die Services innerhalb eines Namespaces können auf verschiedene Amazon-ECS-Cluster innerhalb derselben AWS-Region verteilt werden. Wenn es sich bei dem Namespace um einen gemeinsam genutzten Namespace handelt, können die Services auf die AWS-Konten des Namespace-Besitzers und des Namespace-Verbrauchers verteilt werden. Sie können Services nach beliebigen Kriterien frei organisieren. **Client-Service** Ein Service, der eine Netzwerk-Client-Anwendung ausführt. Für diesen Service muss ein Namespace konfiguriert sein. Jede Aufgabe im Service kann alle Endpunkte im Namespace über einen Service-Connect-Proxy-Container erkennen und eine Verbindung zu diesen herstellen. Wenn einer Ihrer Container in der Aufgabe sich mit dem Endpunkt eines Services in einem Namespace verbinden muss, wählen Sie einen Client-Service. Wenn eine Frontend-, Reverse-Proxy- oder Load-Balancer-Anwendung externen Datenverkehr über andere Methoden empfängt, z. B. von Elastic Load Balancing, könnte sie diese Art von Service-Connect-Konfiguration verwenden. **Client-Server-Service** Ein Amazon-ECS-Service, der eine Netzwerk- oder Webservice-Anwendung ausführt. Für diesen Service müssen ein Namespace und mindestens ein Endpunkt konfiguriert sein. Jede Aufgabe im Service ist über die Endpunkte erreichbar. Der Service-Connect-Proxy-Container überwacht den Namen und Port des Endpunkts, um Datenverkehr an die App-Container in der Aufgabe weiterzuleiten. Wenn einer der Container einen Port für Netzwerkdatenverkehr bereitstellt und überwacht, wählen Sie einen Client-Server-Service aus. Diese Anwendungen müssen keine Verbindung zu anderen Client-Server-Services im selben Namespace herstellen, aber die Client-Konfiguration ist erforderlich. Ein Backend, eine Middleware, eine Unternehmensebene oder die meisten Microservices würden diesen Typ von Service-Connect-Konfiguration verwenden. Wenn Sie möchten, dass eine Frontend-, Reverse Proxy- oder Load-Balancer-Anwendung Datenverkehr von anderen Services empfängt, die mit Service Connect im selben Namespace konfiguriert sind, sollten diese Services diese Art der Service-Connect-Konfiguration verwenden. Das Service-Connect-Feature erstellt ein virtuelles Netzwerk verwandter Services. Die gleiche Service-Konfiguration kann über mehrere verschiedene Namespaces hinweg verwendet werden, um unabhängige, aber identische Anwendungssätze auszuführen. Service Connect definiert den Proxy-Container im Amazon-ECS-Service. Auf diese Weise kann dieselbe Aufgabendefinition verwendet werden, um identische Anwendungen in unterschiedlichen Namespaces mit unterschiedlichen Service-Connect-Konfigurationen auszuführen. Jede Aufgabe, die der Service erstellt, führt in der Aufgabe einen Proxy-Container aus. Service Connect ist für Verbindungen zwischen Amazon-ECS-Services innerhalb desselben Namespaces geeignet. Für die folgenden Anwendungen müssen Sie eine zusätzliche Verbindungsmethode verwenden, um eine Verbindung zu einem Amazon-ECS-Service herzustellen, der mit Service Connect konfiguriert ist: + Aufgaben, die in anderen Namespaces konfiguriert sind + Aufgaben, die nicht für Service Connect konfiguriert sind + Andere Anwendungen außerhalb von Amazon ECS Diese Anwendungen können eine Verbindung über den Service-Connect-Proxy herstellen, aber keine Service-Connect-Endpunktnamen auflösen. Damit diese Anwendungen die IP-Adressen von Amazon-ECS-Aufgaben auflösen können, müssen Sie eine andere Verbindungsmethode verwenden. **Topics** + [Preisgestaltung](#service-connect-pricing) + [Komponenten von Amazon ECS Service Connect](service-connect-concepts-deploy.md) + [Überblick über die Konfiguration von Amazon ECS Service Connect](service-connect-concepts.md) + [Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces](service-connect-shared-namespaces.md) + [Amazon ECS Service Connect-Zugriffsprotokolle](service-connect-envoy-access-logs.md) + [Datenverkehr von Amazon ECS Service Connect verschlüsseln](service-connect-tls.md) + [Konfiguration von Amazon ECS Service Connect mit dem AWS CLI](create-service-connect.md) ## Preisgestaltung + Die Preise für Amazon ECS Service Connect hängen davon ab, ob Sie Amazon EC2 EC2-Infrastruktur zum Hosten Ihrer containerisierten Workloads verwenden AWS Fargate . Bei Verwendung von Amazon ECS auf AWS Outposts folgt die Preisgestaltung demselben Modell, das verwendet wird, wenn Sie Amazon EC2 direkt verwenden. Weitere Informationen finden Sie unter [Amazon-ECS-Preise](https://aws.amazon.com/ecs/pricing). + Für die Nutzung von Amazon ECS Service Connect fallen keine zusätzlichen Gebühren an. + Für die AWS Cloud Map Nutzung durch Service Connect fallen keine zusätzlichen Gebühren an. + Kunden zahlen für Rechenressourcen, die von Amazon ECS Service Connect genutzt werden, einschließlich vCPU und Arbeitsspeicher. Da der Agent von Amazon ECS Service Connect innerhalb einer Kundenaufgabe ausgeführt wird, fallen für dessen Ausführung keine zusätzlichen Gebühren an. Die Aufgabenressourcen werden zwischen dem Kunden-Workload und dem Agenten von Amazon ECS Service Connect aufgeteilt. + Bei der Nutzung der Datenverkehrsverschlüsselungsfunktion von Amazon ECS Service Connect zahlen Kunden für die von ihnen erstellte private Zertifizierungsstelle und für jedes ausgestellte TLS-Zertifikat. AWS Private CA Weitere Details finden Sie unter [AWS Private Certificate Authority -Preise](https://aws.amazon.com/private-ca/pricing/). Um die monatlichen Kosten von TLS-Zertifikaten abzuschätzen, müssen Kunden die Anzahl der Amazon-ECS-Services kennen, für die TLS aktiviert ist, diese Zahl mit den Zertifikatskosten multiplizieren und dann mit sechs multiplizieren. Da Amazon ECS Service Connect TLS-Zertifikate automatisch alle fünf Tage rotiert, werden pro Amazon-ECS-Service im Durchschnitt sechs Zertifikate pro Monat ausgestellt. # Komponenten von Amazon ECS Service Connect Bei der Verwendung von Amazon ECS Service Connect konfigurieren Sie jeden Amazon-ECS-Service entweder so, dass er eine Serveranwendung ausführt, die Netzwerkanfragen empfängt (Client-Server-Service), oder dass er eine Client-Anwendung ausführt, die die Anfragen stellt (Client-Service). Wenn Sie sich auf die Verwendung von Service Connect vorbereiten, beginnen Sie mit einem Client-Server-Service. Sie können eine Service-Connect-Konfiguration zu einem neuen Service oder einem vorhandenen Service hinzufügen. Amazon ECS erstellt einen Service-Connect-Endpunkt im Namespace. Amazon ECS erstellt außerdem eine neue Bereitstellung im Service, um die derzeit ausgeführten Aufgaben zu ersetzen. Vorhandene Aufgaben und andere Anwendungen können weiterhin eine Verbindung zu vorhandenen Endpunkten und externen Anwendungen herstellen. Wenn ein Client-Server-Service Aufgaben durch Aufskalieren hinzufügt, werden neue Verbindungen von Clients sofort zwischen allen Aufgaben verteilt. Wenn ein Client-Server-Service aktualisiert wird, werden neue Verbindungen von Clients sofort zwischen allen Aufgaben der neuen Version verteilt. Vorhandene Aufgaben können nicht aufgelöst werden und keine Verbindung zum neuen Endpunkt herstellen. Nur neue Aufgaben, die über eine Service-Connect-Konfiguration im selben Namespace verfügen und die nach dieser Bereitstellung ausgeführt werden, können diesen Endpunkt auflösen und eine Verbindung zu ihm herstellen. Das bedeutet, dass der Betreiber der Client-Anwendung bestimmt, wann sich die Konfiguration seiner Anwendung ändert. Allerdings kann der Betreiber der Server-Anwendung seine Konfiguration jederzeit ändern. Die Liste der Endpunkte im Namespace kann sich jedes Mal ändern, wenn ein Service im Namespace bereitgestellt wird. Bestehende Aufgaben und Ersatzaufgaben verhalten sich weiterhin genauso wie nach der letzten Bereitstellung. Betrachten Sie die folgenden Beispiele: Gehen Sie zunächst davon aus, dass Sie eine Anwendung erstellen, die in einer einzigen AWS CloudFormation Vorlage und einem einzigen CloudFormation Stapel für das öffentliche Internet verfügbar ist. Die öffentliche Erkennung und Erreichbarkeit sollte zuletzt erstellt werden CloudFormation, einschließlich des Frontend-Client-Dienstes. Die Services müssen in dieser Reihenfolge erstellt werden, um einen Zeitraum zu verhindern, in dem der Frontend-Client-Service ausgeführt wird und öffentlich verfügbar ist, ein Backend jedoch nicht. Dadurch wird verhindert, dass während dieses Zeitraums Fehlermeldungen an die Öffentlichkeit gesendet werden. In müssen Sie das verwenden AWS CloudFormation, `dependsOn` um darauf hinzuweisen CloudFormation , dass mehrere Amazon ECS-Services nicht parallel oder gleichzeitig ausgeführt werden können. Sie sollten das `dependsOn` zum Frontend-Client-Service für jeden Backend-Client-Server-Service hinzufügen, mit dem die Client-Aufgaben eine Verbindung herstellen. Nehmen Sie zweitens an, dass ein Frontend-Service ohne Service-Connect-Konfiguration vorhanden ist. Die Aufgaben stellen eine Verbindung zu einem vorhandenen Backend-Service her. Fügen Sie dem Backend-Service zuerst eine Client-Server-Service-Connect-Konfiguration hinzu, und verwenden Sie denselben Namen im **DNS** oder `clientAlias`, den das Frontend verwendet. Dadurch wird eine neue Bereitstellung erstellt, d. h. alle Bereitstellungs-Rollback-Erkennung oder andere Methoden AWS-Managementkonsole AWS CLI, AWS SDKs um den Backend-Service rückgängig zu machen und auf die vorherige Bereitstellung und Konfiguration zurückzusetzen. Wenn Sie mit der Leistung und dem Verhalten des Backend-Service zufrieden sind, fügen Sie dem Frontend-Service eine Client- oder Client-Server-Service-Connect-Konfiguration hinzu. Nur die Aufgaben in der neuen Bereitstellung verwenden den Service-Connect-Proxy, der diesen neuen Aufgaben hinzugefügt wurde. Wenn Sie Probleme mit dieser Konfiguration haben, können Sie ein Rollback durchführen und zu Ihrer vorherigen Konfiguration zurückkehren, indem Sie die Rollback-Erkennung für die Bereitstellung oder AWS-Managementkonsole, AWS SDKs und andere Methoden verwenden AWS CLI, um den Back-End-Dienst rückgängig zu machen und auf die vorherige Bereitstellung und Konfiguration zurückzusetzen. Wenn Sie anstelle von Service Connect ein anderes Serviceerkennungssystem verwenden, das auf DNS basiert, beginnen alle Frontend- oder Client-Anwendungen mit der Verwendung neuer Endpunkte und geänderter Endpunktkonfigurationen, nachdem der lokale DNS-Cache abgelaufen ist, was normalerweise mehrere Stunden dauert. ## Netzwerk In der Standardkonfiguration lauscht der Service-Connect-Proxy auf dem `containerPort` aus der Port-Zuordnung in der Aufgabendefinition. Ihre Sicherheitsgruppenregeln müssen eingehenden (ingress) Datenverkehr zu diesem Port von den Subnetzen zulassen, in denen Clients ausgeführt werden. Auch wenn Sie in der Service-Connect-Service-Konfiguration eine Portnummer festlegen, ändert sich dadurch nicht der Port für den Client-Server-Service, den der Service-Connect-Proxy überwacht. Wenn Sie diese Portnummer festlegen, ändert Amazon ECS den Port des Endpunkts, mit dem die Client-Services eine Verbindung herstellen, auf dem Service-Connect-Proxy innerhalb dieser Aufgaben. Der Proxy im Client-Service stellt über den `containerPort` eine Verbindung mit dem Proxy im Client-Server-Service her. Wenn Sie den Port ändern möchten, den der Service-Connect-Proxy überwacht, ändern Sie den `ingressPortOverride` in der Service-Connect-Konfiguration des Client-Server-Service. Wenn Sie diese Portnummer ändern, müssen Sie eingehenden Datenverkehr auf diesem Port zulassen, der vom Datenverkehr zu diesem Service verwendet wird. Datenverkehr, den Ihre Anwendungen an Amazon-ECS-Services senden, die für Service Connect konfiguriert sind, erfordern, dass die Amazon VPC und die Subnetze über Routing-Tabellenregeln und Netzwerk-ACL-Regeln verfügen, die die von Ihnen verwendeten `containerPort`- und `ingressPortOverride`-Portnummern zulassen. Sie können Service Connect verwenden, um Datenverkehr zwischen diesen zu senden VPCs. Für beide gelten dieselben Anforderungen für Routingtabellen ACLs, Regeln, Netzwerk und Sicherheitsgruppen VPCs. Beispielsweise erstellen zwei Cluster Aufgaben auf unterschiedlichen Ebenen VPCs. Ein Service in jedem Cluster ist so konfiguriert, dass er denselben Namespace verwendet. Die Anwendungen in diesen beiden Services können jeden Endpunkt im Namespace ohne VPC-DNS-Konfiguration auflösen. Die Proxys können jedoch keine Verbindung herstellen, es sei denn, die VPC-Peering-, VPC- oder Subnetz-Routentabellen und das VPC-Netzwerk ACLs lassen den Verkehr auf den und den Portnummern zu. `containerPort` `ingressPortOverride` Für Aufgaben, die den `bridge`-Netzwerkmodus verwenden, müssen Sie eine Sicherheitsgruppe mit einer Regel für eingehenden Datenverkehr erstellen, die Datenverkehr im oberen dynamischen Portbereich zulässt. Weisen Sie dann die Sicherheitsgruppe allen EC2-Instances im Service-Connect-Cluster zu. ## Service-Connect-Proxy Wenn Sie einen Service mit Service-Connect-Konfiguration erstellen oder aktualisieren, fügt Amazon ECS jeder neuen Aufgabe einen neuen Container hinzu, wenn diese gestartet wird. Dieses Nutzungsmuster eines separaten Containers wird als `sidecar` bezeichnet. Dieser Container ist in der Aufgabendefinition nicht enthalten und Sie können ihn nicht konfigurieren. Amazon ECS verwaltet die Konfiguration dieses Containers im Service. Dadurch können Sie dieselben Aufgabendefinitionen für mehrere Services, Namespaces und Aufgaben ohne Service Connect wiederverwenden. **Proxyressourcen** + Für Aufgabendefinitionen müssen Sie die Parameter für CPU und Arbeitsspeicher festlegen. Wir empfehlen, die Aufgaben-CPU und den Arbeitsspeicher für den Service-Connect-Proxy-Container um 256 CPU-Einheiten und mindestens 64 MiB Arbeitsspeicher zu erweitern. Auf AWS -Fargate beträgt die niedrigste Speichermenge, die Sie einstellen können, 512 MB Speicher. In Amazon EC2 ist Arbeitsspeicher für die Aufgabendefinition erforderlich. + Für den Service legen Sie die Protokollkonfiguration in der Service-Connect-Konfiguration fest. + Wenn Sie erwarten, dass die Aufgaben in diesem Service bei ihrer Spitzenlast mehr als 500 Anfragen pro Sekunde erhalten, empfehlen wir, Ihre Aufgaben-CPU in dieser Aufgabendefinition für den Service-Connect-Proxy-Container um 512 CPU-Einheiten zu erweitern. + Wenn Sie mehr als 100 Service-Connect-Services im Namespace oder insgesamt 2 000 Aufgaben für alle Amazon-ECS-Services im Namespace erstellen möchten, empfehlen wir, den Aufgabenspeicher für den Service-Connect-Proxy-Container um 128 MiB zu erweitern. Sie sollten dies in jeder Aufgabendefinition tun, die von allen Amazon-ECS-Services im Namespace verwendet wird. **Proxykonfiguration** Ihre Anwendungen verbinden sich mit dem Proxy im Beiwagen-Container in derselben Aufgabe, in der sich die Anwendung befindet. Amazon ECS konfiguriert die Aufgabe und die Container so, dass Anwendungen nur dann eine Verbindung zum Proxy herstellen, wenn die Anwendung mit den Endpunktnamen im selben Namespace verbunden ist. Der gesamte verbleibende Datenverkehr verwendet den Proxy nicht. Der andere Datenverkehr umfasst IP-Adressen in derselben VPC, AWS Dienstendpunkte und externen Datenverkehr. **Lastausgleich** Service Connect konfiguriert den Proxy so, dass er die Round-Robin-Strategie für das Load Balancing zwischen den Aufgaben in einem Service-Connect-Endpunkt verwendet. Der lokale Proxy, der sich in der Aufgabe befindet, von der die Verbindung stammt, wählt eine der Aufgaben im Client-Server-Service aus, der den Endpunkt bereitstellt. *Stellen Sie sich zum Beispiel eine Aufgabe vor, die WordPress in einem Dienst ausgeführt wird, der als *Client-Dienst* in einem Namespace namens local konfiguriert ist.* Es gibt einen weiteren Service mit 2 Aufgaben, die die MySQL-Datenbank ausführen. Dieser Service ist so konfiguriert, dass er einen Endpunkt namens `mysql` bereitstellt, der über Service Connect im selben Namespace aufgerufen wird. In der WordPress Aufgabe stellt die WordPress Anwendung mithilfe des Endpunktnamens eine Verbindung zur Datenbank her. Verbindungen zu diesem Namen werden an den Proxy weitergeleitet, der in einem Sidecar-Container in derselben Aufgabe ausgeführt wird. Anschließend kann der Proxy mithilfe der Round-Robin-Strategie eine Verbindung zu einer der MySQL-Aufgaben herstellen. Strategien für das Load Balancing: Round-Robin **Ausreißererkennung** Dieses Feature verwendet Daten, die dem Proxy über frühere fehlgeschlagene Verbindungen vorliegen, um zu verhindern, dass neue Verbindungen an die Hosts gesendet werden, bei denen Verbindungen fehlgeschlagen sind. Service Connect konfiguriert das Feature zur Erkennung von Ausreißern des Proxys für passive Zustandsprüfungen. Anhand des vorigen Beispiels kann der Proxy eine Verbindung zu beiden der MySQL-Aufgaben herstellen. Wenn der Proxy mehrere Verbindungen zu einer bestimmten MySQL-Aufgabe hergestellt hat und 5 oder mehr der Verbindungen in den letzten 30 Sekunden fehlgeschlagen sind, vermeidet der Proxy diese MySQL-Aufgabe für 30 bis 300 Sekunden. **Erneute Versuche** Service Connect konfiguriert den Proxy so, dass Verbindungen, die den Proxy passieren und fehlschlagen, erneut versucht werden, und beim zweiten Versuch wird vermieden, den Host der vorherigen Verbindung zu verwenden. Dadurch wird sichergestellt, dass jede Verbindung über Service Connect nicht aus einmaligen Gründen fehlschlägt. Anzahl der Wiederholungen: 2 **Zeitüberschreitung** Service Connect konfiguriert den Proxy so, dass er eine maximale Zeitspanne auf die Antwort Ihrer Client-Server-Anwendungen wartet. Der Standardwert für das Timeout beträgt 15 Sekunden, kann jedoch aktualisiert werden. Optionale Parameter **idleTimeout** – Die Zeit in Sekunden, für die eine Verbindung aktiv bleibt, wenn sie sich im Leerlauf befindet. Ein Wert von `0` deaktiviert `idleTimeout`. Der Standard-`idleTimeout` für `HTTP`/`HTTP2`/`GRPC` beträgt 5 Minuten. Der Standard-`idleTimeout` für `TCP` beträgt 1 Stunde. **perRequestTimeout**‐ Die Wartezeit, bis der Upstream pro Anfrage mit einer vollständigen Antwort antwortet. Ein Wert von `0` schaltet `perRequestTimeout` aus. Dies kann nur festgelegt werden, wenn das `appProtocol` für Anwendungs-Container `HTTP`/`HTTP2`/`GRPC` ist. Die Standardeinstellung ist 15 Sekunden. Wenn `idleTimeout` auf eine Zeit festgelegt ist, die kürzer als `perRequestTimeout` ist, wird die Verbindung geschlossen, wenn `idleTimeout` und nicht `perRequestTimeout` erreicht ist. ## Überlegungen Beachten Sie Folgendes, wenn Sie Service Connect verwenden. + Aufgaben, die in Fargate ausgeführt werden, müssen Fargate Linux Plattformversion `1.4.0` oder höher verwenden, um Service Connect verwenden zu können. + Die Amazon-ECS-Agentenversion auf der Container-Instance muss `1.67.2` oder höher sein. + Container Instances müssen die Amazon-ECS-optimierte AMI-Version für Amazon Linux 2023 `20230428` oder höher oder die Amazon-ECS-optimierte AMI-Version für Amazon Linux 2 `2.0.20221115` ausführen, um Service Connect nutzen zu können. Diese Versionen verfügen zusätzlich zum Amazon-ECS-Container-Agenten über den Service-Connect-Agenten. Weitere Informationen zum Service Connect-Agenten finden Sie unter [Amazon ECS Service Connect Agent](https://github.com/aws/amazon-ecs-service-connect-agent) unter GitHub. + Container-Instances müssen über die `ecs:Poll`-Berechtigung für die Ressource `arn:aws:ecs:region:0123456789012:task-set/cluster/*` verfügen. Wenn Sie die `ecsInstanceRole` verwenden, müssen Sie keine zusätzlichen Berechtigungen hinzufügen. Die `AmazonEC2ContainerServiceforEC2Role`-verwaltete Richtlinie verfügt über die erforderlichen Berechtigungen. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md). + Aufgaben, die den `bridge`-Netzwerkmodus verwenden und Service Connect verwenden, unterstützen den Container-Definitionsparameter `hostname` nicht. + Aufgabendefinitionen müssen das zu verwendende Speicherlimit für Service Connect festlegen. Weitere Informationen finden Sie unter [Service-Connect-Proxy](#service-connect-concepts-proxy). + Aufgabendefinitionen, die Container-Speicherlimits festlegen, werden nicht unterstützt. Sie können Container-Speicherlimits für Ihre Container festlegen, aber Sie müssen das Aufgaben-Speicherlimit auf eine Zahl festlegen, die größer ist als die Summe der Container-Speicherlimits. Die zusätzliche CPU und der zusätzliche Arbeitsspeicher in den Aufgabenlimits, die nicht in den Containerlimits zugewiesen sind, werden vom Service-Connect-Proxy-Container und anderen Containern verwendet, die keine Containerlimits festlegen. Weitere Informationen finden Sie unter [Service-Connect-Proxy](#service-connect-concepts-proxy). + Sie können Service Connect so konfigurieren, dass jeder AWS Cloud Map Namespace in derselben Region verwendet wird, der sich entweder in derselben Region befindet AWS-Konto oder von Ihnen AWS-Konto gemeinsam genutzt wird. AWS Resource Access Manager Weitere Informationen zur Verwendung von geteilten Namespaces finden Sie unter [Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces](service-connect-shared-namespaces.md). + Jeder Service kann nur zu einem Namespace gehören. + Nur die Aufgaben, die Services erstellen, werden unterstützt. + Alle Endpunkte müssen innerhalb eines Namespace eindeutig sein. + Alle Erkennungsnamen müssen in einem Namespace eindeutig sein. + Sie müssen bestehende Services neu bereitstellen, bevor die Anwendungen neue Endpunkte auflösen können. Neue Endpunkte, die dem Namespace nach der letzten Bereitstellung hinzugefügt werden, werden nicht zur Aufgabenkonfiguration hinzugefügt. Weitere Informationen finden Sie unter [Komponenten von Amazon ECS Service Connect](#service-connect-concepts-deploy). + Service Connect löscht keine Namespaces, wenn Cluster gelöscht werden. Sie müssen Namespaces in löschen. AWS Cloud Map + Der Application-Load-Balancer-Datenverkehr wird standardmäßig im `awsvpc`-Netzwerkmodus über den Service-Connect-Agent weitergeleitet. Wenn Sie möchten, dass Datenverkehr, der nicht von Services stammt, den Service-Connect-Agenten umgeht, verwenden Sie den `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)`-Parameter in Ihrer Service-Konfiguration für Service-Connect. + Service Connect mit TLS unterstützt den `bridge`-Netzwerkmodus nicht. Nur der Netzwerkmodus `awsvpc` wird unterstützt. + Im `awsvpc` Modus leitet der Service Connect-Proxy den Datenverkehr `127.0.0.1` für Dienste in IPv4 Nur-Only- und Dual-Stack-Konfigurationen an den IPv4 Localhost weiter. Bei Diensten in der IPv6 Nur-Konfiguration leitet der Proxy den Datenverkehr an den Localhost weiter. IPv6 `::1` Wir empfehlen, Ihre Anwendungen so zu konfigurieren, dass beide Localhosts empfangen werden, um ein reibungsloses Erlebnis zu gewährleisten, wenn ein Dienst von der Konfiguration „Nur“ oder einer IPv4 Dual-Stack-Konfiguration auf „Nur“ aktualisiert wird. IPv6 Weitere Informationen erhalten Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für EC2](task-networking.md) und [Netzwerkoptionen für Amazon-ECS-Aufgaben für Fargate](fargate-task-networking.md). **Service Connect unterstützt Folgendes nicht:** + Windows-Container + HTTP 1.0 + Eigenständige Aufgaben + Dienste, die die Bereitstellungstypen „ blue/green Powered by“ und „Extern“ verwenden CodeDeploy + `External`-Container-Instances für Amazon ECS Anywhere werden nicht in Service Connect unterstützt. + PPv2 + FIPS-Modus # Überblick über die Konfiguration von Amazon ECS Service Connect Wenn Sie Service Connect verwenden, müssen Sie Parameter in Ihren Ressourcen konfigurieren. Die folgende Tabelle beschreibt die Konfigurationsparameter für die Amazon-ECS-Ressourcen. | Parameter-Speicherort | Anwendungstyp | Description | Erforderlich | | --- | --- | --- | --- | | Aufgabendefinition | Client | Für Service Connect in Client-Aufgabendefinitionen sind keine Änderungen verfügbar. | – | | Aufgabendefinition | Client-Server | Server müssen name-Felder zu Ports in den portMappings von Containern hinzufügen. Weitere Informationen finden Sie unter [portMappings](task_definition_parameters.md#ContainerDefinition-portMappings). | Ja | | Aufgabendefinition | Client-Server | Server können optional ein Anwendungsprotokoll (z. B. HTTP) bereitstellen, um protokollspezifische Metriken für ihre Serveranwendungen zu erhalten (z. B. HTTP 5xx). | Nein | | Service-Definition | Client | Client-Services müssen eine serviceConnectConfiguration hinzufügen, um den beizutretenden Namespace zu konfigurieren. Dieser Namespace muss alle Server-Services enthalten, die dieser Service erkennen muss. Weitere Informationen finden Sie unter [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Ja | | Service-Definition | Client-Server | Server-Services müssen eine serviceConnectConfiguration hinzufügen, um die DNS-Namen, Portnummern und den Namespace zu konfigurieren, über den der Service verfügbar ist. Weitere Informationen finden Sie unter [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Ja | | Cluster | Client | Cluster können einen standardmäßigen Service-Connect-Namespace hinzufügen. Neue Services im Cluster erben den Namespace, wenn Service Connect in einem Service konfiguriert ist. | Nein | | Cluster | Client-Server | Für Service Connect in Clustern gibt es keine Änderungen, die sich auf Server-Services beziehen. Server-Aufgabendefinitionen und -Services müssen die entsprechende Konfiguration festlegen. | – | **Übersicht der Schritte zum Konfigurieren von Service Connect** Die folgenden Schritte liefern einen Überblick über die Konfiguration von Service Connect. **Wichtig** Service Connect erstellt AWS Cloud Map Dienste in Ihrem Konto. Das Ändern dieser AWS Cloud Map Ressourcen durch manuelles Ändern von registering/deregistering Instanzen, Ändern von Instanzattributen oder Löschen eines Dienstes kann zu unerwartetem Verhalten bei Ihrem Anwendungsdatenverkehr oder nachfolgenden Bereitstellungen führen. Service Connect unterstützt keine Links in der Aufgabendefinition. 1. Fügen Sie Portnamen zu den Portzuordnungen in Ihren Aufgabendefinitionen hinzu. Außerdem können Sie das Layer-7-Protokoll der Anwendung identifizieren, um zusätzliche Metriken zu erhalten. 1. Erstellen Sie einen Cluster mit einem AWS Cloud Map Namespace, verwenden Sie einen gemeinsam genutzten Namespace oder erstellen Sie den Namespace separat. Für eine einfache Organisation erstellen Sie einen Cluster mit dem Namen, den Sie für den Namespace möchten, und geben Sie den gleichen Namen für den Namespace an. In diesem Fall erstellt Amazon ECS einen neuen HTTP-Namespace mit der erforderlichen Konfiguration. Service Connect verwendet oder erstellt keine DNS-gehosteten Zonen in Amazon Route 53. 1. Konfigurieren Sie Services, um Service-Connect-Endpunkte innerhalb des Namespace zu erstellen. 1. Stellen Sie Services bereit, um die Endpunkte zu erstellen. Amazon ECS fügt jeder Aufgabe einen Service-Connect-Proxy-Container hinzu und erstellt die Service-Connect-Endpunkte in AWS Cloud Map. Dieser Container ist in der Aufgabendefinition nicht konfiguriert, und die Aufgabendefinition kann ohne Änderung wiederverwendet werden, um mehrere Services im selben Namespace oder in mehreren Namespaces zu erstellen. 1. Stellen Sie Client-Anwendungen als Services bereit, um eine Verbindung zu den Endpunkten herzustellen. Amazon ECS verbindet diese mit den Service-Connect-Endpunkten über den Service-Connect-Proxy in jeder Aufgabe. Anwendungen verwenden den Proxy nur, um sich mit Service-Connect-Endpunkten zu verbinden. Es gibt keine zusätzliche Konfiguration für die Verwendung des Proxys. Der Proxy führt Round-Robin-Load-Balancing, die Erkennung von Ausreißern und Wiederholungsversuche durch. Weitere Informationen zum Proxy finden Sie unter [Service-Connect-Proxy](service-connect-concepts-deploy.md#service-connect-concepts-proxy). 1. Überwachen Sie den Verkehr über den Service Connect-Proxy in Amazon CloudWatch. ## Cluster-Konfiguration Sie können einen Standard-Namespace für Service Connect festlegen wenn Sie den Cluster erstellen oder aktualisieren. Der Namespace-Name, den Sie standardmäßig angeben, kann sich entweder im selben AWS-Region AND-Konto oder im selben Namen befinden AWS-Region und von einem anderen AWS-Konto Benutzer gemeinsam genutzt werden. AWS Resource Access Manager Wenn Sie einen Cluster erstellen und einen Standard-Service-Connect-Namespace angeben, wartet der Cluster im `PROVISIONING`-Status, während Amazon ECS den Namespace erstellt. Im Status des Clusters sehen Sie einen `attachment`, der den Status des Namespace anzeigt. Anlagen werden standardmäßig nicht in der angezeigt. Sie müssen sie hinzufügen AWS CLI, um sie `--include ATTACHMENTS` zu sehen. Wenn Sie einen Namespace verwenden möchten, der mit Ihnen gemeinsam genutzt wird AWS RAM, geben Sie den Amazon-Ressourcennamen (ARN) des Namespaces in der Cluster-Konfiguration an. AWS-Konto Weitere Informationen zu gemeinsam genutzten AWS Cloud Map Namespaces finden Sie unter. [Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces](service-connect-shared-namespaces.md) ## Service-Konfiguration Service Connect ist so konzipiert, dass nur ein Minimum an Konfiguration erforderlich ist. Sie müssen für jede Portzuordnung, die Sie mit Service Connect verwenden möchten, in der Aufgabendefinition einen Namen festlegen. Im Dienst müssen Sie Service Connect aktivieren und entweder einen Namespace in Ihrem AWS-Konto oder einen gemeinsam genutzten Namespace auswählen, um einen Client-Dienst einzurichten. Um einen Client-Server-Service zu erstellen, müssen Sie eine einzelne Service-Connect-Service-Konfiguration hinzufügen, die dem Namen einer der Portzuordnungen entspricht. Amazon ECS verwendet die Portnummer und den Portnamen aus der Aufgabendefinition erneut, um den Service-Connect-Service und -Endpunkt zu definieren. Um diese Werte zu überschreiben, können Sie die anderen Parameter **Discovery** (Erkennung), **DNS** und **Port** in der Konsole oder `discoveryName` bzw. `clientAliases` in der Amazon-ECS-API verwenden. ## Erstkonfiguration des Health Checks Service Connect stellt sicher, dass die Aufgaben ordnungsgemäß funktionieren, bevor der Datenverkehr an sie weitergeleitet wird. Wenn eine Aufgabe gestartet wird (während der Bereitstellung, Skalierung oder Ersetzung), überwacht Service Connect den Zustand Ihrer Aufgabe, um sicherzustellen, dass sie bereit ist, Datenverkehr anzunehmen. Sie müssen in Ihrer Aufgabendefinition Integritätsprüfungen für den Essential-Container definieren, um dieses Verhalten zu aktivieren. Das Verhalten der ersten Zustandsprüfung berücksichtigt mögliche Verzögerungen beim Erreichen des Status, in dem eine Aufgabe bereit ist, Datenverkehr anzunehmen: + Wenn es sich bei einer Aufgabe um eine solche handelt`HEALTHY`, ist sie sofort für den Traffic verfügbar. + Wenn der Zustand einer Aufgabe zutrifft`UNKNOWN`, folgt Service Connect der Konfiguration der Container-Integritätsprüfung (siehe[Gesundheitscheck](task_definition_parameters.md#container_definition_healthcheck)) der wesentlichen Container der Aufgabe, um ein Timeout zu berechnen, bis zu`8 minutes`, bevor sie für den Verkehr verfügbar gemacht wird, auch wenn sie bestehen bleibt`UNKNOWN`. + Wenn es sich bei einer Aufgabe um eine Aufgabe handelt`UNHEALTHY`, kann Amazon ECS Ersatzaufgaben starten. Wenn keine fehlerfreien Aufgaben verfügbar sind, wird Ihre Bereitstellung je nach Konfiguration Ihres Dienstes möglicherweise zurückgesetzt. Für den gesamten laufenden Verkehr verwendet Service Connect passive Zustandsprüfungen, die auf der Erkennung von Ausreißern basieren, um den Verkehr effizient weiterzuleiten. # Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces Amazon ECS Service Connect unterstützt die Verwendung gemeinsam genutzter AWS Cloud Map Namespaces für mehrere AWS-Konten innerhalb desselben. AWS-Region Mit dieser Funktion können Sie verteilte Anwendungen erstellen, in denen Dienste, die auf verschiedenen Geräten ausgeführt werden, sich gegenseitig erkennen und über Service Connect miteinander kommunizieren AWS-Konten können. Gemeinsam genutzte Namespaces werden mithilfe von AWS Resource Access Manager (AWS RAM) verwaltet, was eine sichere kontenübergreifende gemeinsame Nutzung von Ressourcen ermöglicht. *Weitere Informationen zu gemeinsam genutzten Namespaces finden Sie unter [Kontenübergreifende Namespaces Sharing im AWS Cloud Map Developer](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) Guide.AWS Cloud Map * **Wichtig** Sie müssen die `AWSRAMPermissionCloudMapECSFullPermission`-verwaltete Berechtigung verwenden, um den Namespace gemeinsam zu nutzen, damit Service Connect ordnungsgemäß mit dem Namespace funktioniert. Wenn Sie gemeinsam genutzte AWS Cloud Map Namespaces mit Service Connect verwenden, AWS-Konten können Dienste von mehreren am selben Dienstnamespace teilnehmen. Dies ist besonders nützlich für Organisationen mit mehreren Benutzern AWS-Konten , die die service-to-service Kommunikation über Kontogrenzen hinweg aufrechterhalten und gleichzeitig Sicherheit und Isolation wahren müssen. **Anmerkung** Um mit Diensten zu kommunizieren, die sich in verschiedenen Versionen befinden VPCs, müssen Sie die Inter-VPC-Konnektivität konfigurieren. Dies kann mithilfe einer VPC-Peering-Verbindung erreicht werden. Weitere Informationen finden Sie unter [Erstellen oder Löschen einer VPC-Peering-Verbindung](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) im *VPC-Peering-Handbuch für Amazon Virtual Private Cloud*. # Verwenden von gemeinsam genutzten AWS Cloud Map Namespaces mit Amazon ECS Service Connect Das Einrichten von gemeinsam genutzten AWS Cloud Map Namespaces für Service Connect umfasst die folgenden Schritte: Namespace-Besitzer erstellt den Namespace, Besitzer teilt ihn über AWS Resource Access Manager (AWS RAM), Verbraucher akzeptiert die Ressourcenfreigabe und Consumer konfiguriert Service Connect für die Verwendung des gemeinsam genutzten Namespaces. ## Schritt 1: Erstellen Sie den Namespace AWS Cloud Map Der Namespace-Besitzer erstellt einen AWS Cloud Map Namespace, der mit anderen Konten geteilt wird. **Um einen Namespace für die gemeinsame Nutzung mit dem zu erstellen AWS-Managementkonsole** 1. Öffnen Sie die AWS Cloud Map Konsole unter. [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/) 1. Wählen Sie **Create namespace (Namespace erstellen)** aus. 1. Geben Sie einen **Namespace-Namen** ein. Dieser Name wird von den Services aller teilnehmenden Konten verwendet. 1. Wählen Sie für **Namespace-Typ** den für Ihren Anwendungsfall geeigneten Typ aus: + **API-Aufrufe** – HTTP-Namespaces für die Serviceerkennung ohne DNS-Funktionalität. + **API-Aufrufe und DNS-Abfragen in VPCs** ‐ Private DNS-Namespaces zur Serviceerkennung mit privaten DNS-Abfragen in einer VPC. + **API-Aufrufe und öffentliche DNS-Abfragen** – Öffentliche DNS-Namespaces für die Serviceerkennung mit öffentlichen DNS-Abfragen. 1. Wählen Sie **Create namespace (Namespace erstellen)** aus. ## Schritt 2: Teilen Sie den Namespace mit AWS RAM Der Namespace-Besitzer verwendet AWS RAM , um den Namespace mit anderen zu teilen. AWS-Konten **Um einen Namespace über die Konsole gemeinsam zu nutzen AWS RAM** 1. Öffnen Sie die AWS RAM Konsole unter. [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/) 1. Wählen Sie **Create resource share (Ressourcenfreigabe erstellen)** aus. 1. Geben Sie für **Name** einen beschreibenden Namen für die Ressourcenfreigabe ein. 1. Gehen Sie im Abschnitt **Ressourcen** wie folgt vor: 1. Wählen Sie für **Ressourcentyp** die Option **Cloud Map Namespaces** aus. 1. Wählen Sie den Namespace aus, den Sie im vorherigen Schritt erstellt haben. 1. Geben Sie im Abschnitt **Verwaltete Berechtigungen** die Option **AWSRAMPermissionCloudMapECSFullPermission** an. **Wichtig** Sie müssen die `AWSRAMPermissionCloudMapECSFullPermission`-verwaltete Berechtigung verwenden, um den Namespace gemeinsam zu nutzen, damit Service Connect ordnungsgemäß mit dem Namespace funktioniert. 1. Geben Sie im Abschnitt **Prinzipale** die AWS-Konten an, mit denen Sie den Namespace teilen möchten. Sie können ein Konto IDs oder eine Organisationseinheit eingeben IDs. 1. Wählen Sie **Create resource share (Ressourcenfreigabe erstellen)** aus. ## Schritt 3: Die Ressourcenfreigabe akzeptieren Namespace-Verbraucherkonten müssen die Einladung zur Ressourcenfreigabe annehmen, um den gemeinsam genutzten Namespace verwenden zu können. **Um eine Einladung zur gemeinsamen Nutzung von Ressourcen über die AWS RAM Konsole anzunehmen** 1. Öffnen Sie im Kundenkonto die AWS RAM Konsole unter [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/). 1. Wählen Sie im Navigationsbereich **Für mich freigegeben** und dann **Ressourcenfreigaben**. 1. Wählen Sie die Einladung zur Ressourcenfreigabe aus und dann **Ressourcenfreigabe akzeptieren**. 1. Notieren Sie sich nach dem Akzeptieren den gemeinsamen Namespace-ARN aus den Ressourcendetails. Sie verwenden diesen ARN bei der Konfiguration von Service-Connect-Services. ## Schritt 4: Konfigurieren Sie einen Amazon-ECS-Service mit dem gemeinsamen Namespace Nachdem der Namespace-Verbraucher den gemeinsam genutzten Namespace akzeptiert hat, kann er Amazon-ECS-Services so konfigurieren, dass sie den gemeinsam genutzten Namespace verwenden. Die Konfiguration ähnelt der Verwendung eines regulären Namespaces, Sie müssen jedoch den Namespace-ARN anstelle des Namens angeben. Ein detailliertes Verfahren zur Service-Erstellung finden Sie unter [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md). **Um einen Dienst mit einem gemeinsamen Namespace zu erstellen, verwenden Sie AWS-Managementkonsole** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version 2.](https://console.aws.amazon.com/ecs/v2) 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus, in dem Sie den Service erstellen möchten. 1. Wählen Sie unter **Services** die Option **Erstellen** aus. 1. Nachdem Sie je nach Arbeitslast weitere Details eingegeben haben, wählen Sie im Abschnitt **Service Connect** die Option **Service Connect verwenden** aus. 1. Geben Sie für **Namespace** den vollständigen ARN des gemeinsam genutzten Namespace ein. Das ARN-Format ist: `arn:aws:servicediscovery:region:account-id:namespace/namespace-id` 1. Konfigurieren Sie die übrigen Service Connect-Einstellungen nach Bedarf für Ihren Service-Typ (Client oder Client-Server). 1. Schließen Sie den Service-Erstellungsprozess ab. Sie können Dienste auch mithilfe AWS SDKs von AWS CLI oder konfigurieren, indem Sie den gemeinsamen Namespace-ARN im `namespace` Parameter von angeben. `serviceConnectConfiguration` ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-def \ --service-connect-configuration '{ "enabled": true, "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890", "services": [{ "portName": "web", "discoveryName": "my-service", "clientAliases": [{ "port": 80, "dnsName": "my-service" }] }] }' ``` ## Überlegungen Beachten Sie Folgendes, wenn Sie gemeinsam genutzte AWS Cloud Map Namespaces mit Service Connect verwenden: + AWS RAM muss an dem Ort verfügbar sein, AWS-Region an dem Sie den gemeinsam genutzten Namespace verwenden möchten. + Der gemeinsam genutzte Namespace muss sich in demselben befinden AWS-Region wie Ihre Amazon ECS-Services und -Cluster. + Sie müssen den Namespace-ARN und nicht die ID verwenden, wenn Sie Service Connect mit einem gemeinsam genutzten Namespace konfigurieren. + Alle Namespace-Typen werden unterstützt: HTTP-, Private DNS- und Öffentliche DNS-Namespaces. + Wenn der Zugriff auf einen gemeinsam genutzten Namespace gesperrt wird, schlagen Amazon-ECS-Vorgänge fehl, die eine Interaktion mit dem Namespace erfordern (wie `CreateService`, `UpdateService` und `ListServicesByNamespace`). Weitere Informationen zur Fehlerbehebung bei gemeinsam genutzten Namespaces finden Sie unter [Fehlerbehebung bei Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces](service-connect-shared-namespaces-troubleshooting.md). + Informationen zur Serviceerkennung mithilfe von DNS-Abfragen in einem gemeinsam genutzten privaten DNS-Namespace: + Der Namespace-Besitzer muss `create-vpc-association-authorization` mit der ID der privaten gehosteten Zone, die dem Namespace zugeordnet ist, und der VPC des Verbrauchers aufrufen. ``` aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + Der Namespace-Besitzer muss `associate-vpc-with-hosted-zone` mit der ID der privaten gehosteten Zone aufrufen. ``` aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + Nur der Namespace-Besitzer kann die Ressourcenfreigabe verwalten. + Namespace-Benutzer können Services innerhalb des gemeinsam genutzten Namespaces erstellen und verwalten, den Namespace selbst jedoch nicht ändern. + Erkennungsnamen müssen innerhalb des gemeinsam genutzten Namespaces eindeutig sein, unabhängig davon, welches Konto den Service erstellt. + Dienste im gemeinsam genutzten Namespace können Dienste von anderen AWS Konten, die Zugriff auf den Namespace haben, erkennen und eine Verbindung zu ihnen herstellen. + Wenn TLS für Service Connect aktiviert und ein gemeinsam genutzter Namespace verwendet wird, ist die AWS Private CA Zertifizierungsstelle (CA) auf den Namespace beschränkt. Wenn der Zugriff auf den gemeinsam genutzten Namespace gesperrt wird, wird der Zugriff auf die CA gestoppt. + Bei der Arbeit mit einem gemeinsam genutzten Namespace haben Namespace-Besitzer und -Verbraucher standardmäßig keinen Zugriff auf kontoübergreifende CloudWatch Amazon-Metriken. Target-Metriken werden nur für Konten veröffentlicht, die Kundenservices besitzen. Ein Konto, dem Kundendienste gehören, hat keinen Zugriff auf Messwerte, die von einem Konto empfangen wurden, das Client-Server-Dienste besitzt, und umgekehrt. Um kontoübergreifenden Zugriff auf Messwerte zu ermöglichen, richten Sie die kontenübergreifende Beobachtbarkeit ein. CloudWatch *Weitere Informationen zur Konfiguration der kontoübergreifenden Observability finden Sie unter [CloudWatch Accountübergreifende Observability](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) im Amazon-Benutzerhandbuch. CloudWatch * Weitere Informationen zu den CloudWatch Metriken für Service Connect finden Sie unter[Amazon CloudWatch ECS-Metriken](available-metrics.md). # Fehlerbehebung bei Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces Verwenden Sie die folgenden Informationen, um Probleme mit gemeinsam genutzten AWS Cloud Map Namespaces und Service Connect zu beheben. Weitere Informationen zum Auffinden von Fehlermeldungen finden Sie unter [Amazon-ECS-Fehlerbehebung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html). Fehlermeldungen im Zusammenhang mit Berechtigungsproblemen werden angezeigt, wenn Berechtigungen fehlen oder der Zugriff auf den Namespace gesperrt wurde. **Wichtig** Sie müssen die `AWSRAMPermissionCloudMapECSFullPermission`-verwaltete Berechtigung verwenden, um den Namespace gemeinsam zu nutzen, damit Service Connect ordnungsgemäß mit dem Namespace funktioniert. Die Fehlermeldung wird in einem der folgenden Formate angezeigt: Beim Aufrufen der Operation < OperationName > ist ein Fehler aufgetreten (ClientException): Der Benutzer: arn:aws:iam: :user/ ist nicht berechtigt,: < > für die Ressource: < > auszuführen, da keine ressourcenbasierte Richtlinie die Aktion < > ActionName zulässt ResourceArn ActionName
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
For online documentation and support please refer to
nginx.org.
Commercial support is available at
nginx.com.
Thank you for using nginx.
``` **So zeigen Sie Service-Connect-Metriken an** Der Service Connect-Proxy erstellt Anwendungsmetriken (HTTP- HTTP2, gRPC- oder TCP-Verbindung) in CloudWatch Metriken. Wenn Sie die CloudWatch Konsole verwenden, sehen Sie sich die zusätzlichen metrischen Dimensionen von **DiscoveryName**, (**DiscoveryName, ServiceName, ClusterName**) **TargetDiscoveryName**, und (**TargetDiscoveryName, ServiceName, ClusterName**) unter dem Amazon ECS-Namespace an. Weitere Informationen zu diesen Metriken und den Dimensionen finden Sie unter [Verfügbare Metriken anzeigen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) im Amazon CloudWatch Logs-Benutzerhandbuch. # Die Serviceerkennung verwenden, um Amazon-ECS-Services mithilfe von DNS-Namen zu verbinden Ihr Amazon-ECS-Service kann optional so konfiguriert werden, dass er die Amazon-ECS-Serviceerkennung verwendet. Service Discovery verwendet AWS Cloud Map API-Aktionen, um HTTP- und DNS-Namespaces für Ihre Amazon ECS-Services zu verwalten. Weitere Informationen finden Sie unter [Was ist AWS Cloud Map?](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html) im *AWS Cloud Map -Entwicklerhandbuch*. Service Discovery ist in den folgenden Regionen verfügbar: AWS | Name der Region | Region | | --- | --- | | USA Ost (Nord-Virginia) | us-east-1 | | USA Ost (Ohio) | us-east-2 | | USA West (Nordkalifornien) | us-west-1 | | USA West (Oregon) | us-west-2 | | Afrika (Kapstadt) | af-south-1 | | Asien-Pazifik (Hongkong) | ap-east-1 | | Asien-Pazifik (Taipeh) | ap-east-2 | | Asien-Pazifik (Mumbai) | ap-south-1 | | Asien-Pazifik (Hyderabad) | ap-south-2 | | Asien-Pazifik (Tokio) | ap-northeast-1 | | Asien-Pazifik (Seoul) | ap-northeast-2 | | Asia Pacific (Osaka) | ap-northeast-3 | | Asien-Pazifik (Singapur) | ap-southeast-1 | | Asien-Pazifik (Sydney) | ap-southeast-2 | | Asien-Pazifik (Jakarta) | ap-southeast-3 | | Asien-Pazifik (Melbourne) | ap-southeast-4 | | Asien-Pazifik (Malaysia) | ap-southeast-5 | | Asien-Pazifik (Neuseeland) | ap-southeast-6 | | Asien-Pazifik (Thailand) | ap-southeast-7 | | Kanada (Zentral) | ca-central-1 | | Kanada West (Calgary) | ca-west-1 | | China (Beijing) | cn-north-1 | | China (Ningxia) | cn-northwest-1 | | Europe (Frankfurt) | eu-central-1 | | Europa (Zürich) | eu-central-2 | | Europa (Irland) | eu-west-1 | | Europa (London) | eu-west-2 | | Europa (Paris) | eu-west-3 | | Europa (Milan) | eu-south-1 | | Europa (Stockholm) | eu-north-1 | | Israel (Tel Aviv) | il-central-1 | | Europa (Spain) | eu-south-2 | | Naher Osten (VAE) | me-central-1 | | Mexiko (Zentral) | mx-central-1 | | Naher Osten (Bahrain) | me-south-1 | | Südamerika (São Paulo) | sa-east-1 | | AWS GovCloud (US-Ost) | us-gov-east-1 | | AWS GovCloud (US-West) | us-gov-west-1 | ## Konzepte für Serviceerkennung Die Serviceerkennung umfasst folgende Komponenten: + **Serviceerkennungs-Namespace**: Eine logische Gruppe von Serviceerkennungs-Services, die den gleichen Domain-Namen haben, zum Beispiel `example.com`, wo Sie den Datenverkehr hinleiten möchten. Sie können einen Namespace mit einem Aufruf des `aws servicediscovery create-private-dns-namespace`-Befehls oder in der Amazon-ECS-Konsole erstellen. Sie können den `aws servicediscovery list-namespaces`-Befehl zum Anzeigen der zusammenfassenden Informationen über die Namespaces, die vom aktuellen Konto erstellt wurden, verwenden. Weitere Informationen zu den Service Discovery-Befehlen finden Sie unter `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` und `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)` im * AWS CLI Referenzhandbuch AWS Cloud Map (Service Discovery)*. + **Serviceerkennung Service**: Ist im Service Discover-Namespace vorhanden und besteht aus dem Servicenamen und der DNS-Konfiguration für den Namespace. Er stellt die folgende Kernkomponente bereit: + **Dienstregistrierung**: Ermöglicht es Ihnen, über DNS- oder AWS Cloud Map API-Aktionen nach einem Dienst zu suchen und einen oder mehrere verfügbare Endpunkte wiederherzustellen, die für die Verbindung mit dem Dienst verwendet werden können. + **Serviceerkennung-Instance**: Existiert innerhalb des Serviceerkennung-Service und besteht aus den Attributen, die jedem Amazon-ECS-Service im Serviceverzeichnis zugeordnet sind. + **Instance-Attribute**: Die folgenden Metadaten werden als benutzerdefinierte Attribute für jeden Amazon-ECS-Service hinzugefügt, der für die Verwendung von Serviceerkennung konfiguriert ist: + **`AWS_INSTANCE_IPV4`**— Für einen `A` Datensatz die IPv4 Adresse, die Route 53 als Antwort auf DNS-Abfragen AWS Cloud Map zurückgibt und die zurückgibt, wenn beispielsweise Instanzdetails entdeckt werden. `192.0.2.44` + **`AWS_INSTANCE_IPV6`**— Für einen `AAAA` Datensatz die IPv6 Adresse, die Route 53 als Antwort auf DNS-Abfragen AWS Cloud Map zurückgibt und die zurückgibt, wenn Instanzdetails gefunden ` 2001:0db8:85a3:0000:0000:abcd:0001:2345` werden, z. B. Sowohl `AWS_INSTANCE_IPv4` und `AWS_INSTANCE_IPv6` werden für Amazon-ECS-DualStack-Services hinzugefügt. Nur `AWS_INSTANCE_IPv6` wird für Dienste hinzugefügt, die IPv6 nur Amazon ECS anbieten. + **`AWS_INSTANCE_PORT`**: Der Port-Wert, der dem Serviceerkennung-Service zugeordnet ist. + **`AVAILABILITY_ZONE`**: Die Availability Zone, in der die Aufgabe gestartet wurde. Bei Aufgaben, die EC2 verwenden, ist dies die Availability Zone, in der die Container-Instance besteht. Bei Aufgaben, die Fargate verwenden, ist dies die Availability Zone, in der die Elastic-Network-Schnittstelle besteht. + **`REGION`**: Die Region, in der sich die Aufgabe befindet. + **`ECS_SERVICE_NAME`**: Der Name des Amazon-ECS-Services, zu dem die Aufgabe gehört. + **`ECS_CLUSTER_NAME`**: Der Name des Amazon ECS-Clusters, zu dem die Aufgabe gehört. + **`EC2_INSTANCE_ID`**: Die ID der Container-Instance, in der die Aufgabe platziert wurde. Dieses benutzerdefinierte Attribut wird nicht hinzugefügt, wenn die Aufgabe Fargate verwendet. + **`ECS_TASK_DEFINITION_FAMILY`**: Die Aufgabendefinitionsfamilie, die die Aufgabe verwendet. + **`ECS_TASK_SET_EXTERNAL_ID`**: Wenn eine Aufgabe für eine externe Bereitstellung erstellt und einer Serviceerkennung-Registrierung zugeordnet wird, dann enthält das Attribut `ECS_TASK_SET_EXTERNAL_ID` die externe ID des Aufgabensatzes. + **Amazon ECS-Zustandsprüfungen**: Amazon ECS führt regelmäßige Zustandsprüfungen auf Container-Ebene durch. Wenn ein Endpunkt die Zustandsprüfung nicht besteht, wird er aus dem DNS-Routing entfernt und als fehlerhaft markiert. ## Überlegungen zu Serviceerkennung Bei der Verwendung der Serviceerkennung sollte Folgendes berücksichtigt werden: + Serviceerkennung wird für Aufgaben auf Fargate unterstützt, die Plattform-Version v1.1.0 oder höher verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md). + Services, die für die Verwendung von Serviceerkennung konfiguriert sind, haben ein Limit von 1000 Aufgaben pro Service. Dies ist auf eine Service-Quote der Route 53 zurückzuführen. + Der Create Service-Workflow in der Amazon ECS-Konsole unterstützt nur die Registrierung von Services in private DNS-Namespaces. Wenn ein AWS Cloud Map privater DNS-Namespace erstellt wird, wird automatisch eine private gehostete Route 53-Zone erstellt. + Die VPC DNS-Attribute müssen für eine erfolgreiche DNS-Auflösung konfiguriert werden. Weitere Informationen zum Konfigurieren der Attribute finden Sie unter [DNS-Support für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support) im *Amazon VPC-Benutzerhandbuch*. + Amazon ECS unterstützt die Registrierung von Services in gemeinsam genutzten AWS Cloud Map Namespaces nicht. + Die für einen Serviceerkennung-Service erstellten DNS-Datensätze werden auch bei Verwendung von öffentlichen Namespaces immer mit der privaten IP-Adresse für die Aufgabe anstelle der öffentlichen IP-Adresse registriert. + Serviceerkennung erfordert, dass Aufgaben entweder Netzwerkmodus `awsvpc`, `bridge` oder `host` angeben (`none` wird nicht unterstützt). + Wenn die Service-Aufgabendefinition den `awsvpc`-Netzwerkmodus verwendet, können Sie für jede Service-Aufgabe eine beliebige Kombination aus `A`- oder `SRV`-Datensätzen erstellen. Wenn Sie `SRV`-Datensätze verwenden, ist ein Port erforderlich. Sie können zusätzlich `AAAA`-Datensätze erstellen, wenn der Service Dual-Stack-Subnetze verwendet. Wenn der Service IPv6 nur Subnetze verwendet, können Sie keine Datensätze erstellen. `A` + Wenn die Service-Aufgabendefinition den Netzwerkmodus `bridge` oder `host` verwendet, wird nur der SRV-Datensatz als DNS-Datensatztyp unterstützt. Erstellen Sie einen SRV-Datensatz für jede Serviceaufgabe. Der SRV-Datensatz muss eine Kombination aus Containername und Container-Port aus der Aufgabendefinition angeben. + DNS-Datensätze für einen Service zur Serviceerkennung können innerhalb Ihrer VPC abgefragt werden. Sie verwenden das folgende Format: `Your application is now running on a container in Amazon ECS.