Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# 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
}
]
```