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.
# Architekt für EC2 Kapazitäten für Amazon ECS
Verwenden Sie EC2 Kapazität für große Workloads, die preisoptimiert werden müssen.
Wir empfehlen Ihnen, bei der Modellierung von Aufgabendefinitionen und Services zu berücksichtigen EC2, welche Prozesse zusammen ablaufen müssen und wie Sie die einzelnen Komponenten skalieren könnten.
Stellen Sie sich z. B. eine Anwendung vor, die aus folgenden Komponenten besteht:
+ Ein Frontend-Service, der Informationen auf einer Webseite anzeigt
+ Ein Back-End-Dienst, der den Frontend-Dienst bereitstellt APIs
+ Ein Datenspeicher
Erstellen Sie für dieses Beispiel Aufgabendefinitionen, die die Container gruppieren, die für einen gemeinsamen Zweck verwendet werden. Teilen Sie die verschiedenen Komponenten in mehrere Aufgabendefinitionen auf. Der folgende Beispielcluster verfügt über drei Container-Instances, in denen drei Frontend-Service-Container, zwei Backend-Service-Container und ein Datenspeicher-Service-Container ausgeführt werden.
Sie können verwandte Container in einer Aufgabendefinition gruppieren, z. B. verknüpfte Container, die gemeinsam ausgeführt werden müssen. Sie könnten beispielsweise einen Protokoll-Streaming-Container zu Ihrem Frontend-Service hinzufügen und dies in die gleiche Aufgabendefinition aufnehmen.
Nachdem Sie die Aufgabendefinitionen fertiggestellt haben, können Sie auf dieser Grundlage Services erstellen, um die Verfügbarkeit Ihrer gewünschten Aufgaben sicherzustellen. Weitere Informationen finden Sie unter [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md). In Ihren Services können Sie Container mit Elastic Load Balancing-Load Balancern verknüpfen. Weitere Informationen finden Sie unter [Verwenden von Load Balancing für die Verteilung des Service-Datenverkehrs in Amazon ECS](service-load-balancing.md). Wenn sich Ihre Anwendungsanforderungen ändern, können Sie Ihre Service aktualisieren, um die Anzahl der gewünschten Aufgaben nach oben oder unten zu skalieren. Oder Sie können Ihre Services aktualisieren, um neuere Versionen der Container in Ihren Aufgaben bereitzustellen. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md).
![\[Beispiel für eine Anwendungsarchitektur mit drei Instances. Instance 1 hat einen Frontend-Servicecontainer und einen Datenbankservicecontainer. Instance 2 und Instance 3 haben einen Frontend-Service-Container und einen Backend-Service-Container.\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/images/application.png)
# Pull-Verhalten von Container-Images für EC2 und externe Instances auf Amazon ECS
Die Zeit, die ein Container zum Starten benötigt, hängt vom zugrunde liegenden Container-Image ab. Zum Beispiel kann der Start eines dickeren Images (Vollversionen von Debian, Ubuntu und Amazon1/2) länger dauern, weil mehr Services in den Containern laufen als ihre jeweiligen schlanken Versionen (Debian-Slim, Ubuntu-Slim und Amazon-Slim) oder kleineren Basis-Images (Alpine).
Wenn der Amazon-ECS-Agent eine Aufgabe startet, ruft er das Docker-Image aus seiner Remote-Registry ab und speichert dann eine lokale Kopie im Zwischenspeicher. Wenn Sie für jede Version Ihrer Anwendung ein neues Image-Tag verwenden, ist dieses Verhalten unnötig.
Der Agentenparameter `ECS_IMAGE_PULL_BEHAVIOR` bestimmt das Verhalten beim Abrufen von Images. Die folgenden Optionen sind verfügbar:
+ `ECS_IMAGE_PULL_BEHAVIOR`: `default`
Das Image wird per Fernzugriff abgerufen. Schlägt der Abruf fehl, wird das zwischengespeicherte Image in der Instance verwendet.
+ `ECS_IMAGE_PULL_BEHAVIOR`: `always`
Das Image wird per Fernzugriff abgerufen. Wenn das Abrufen fehlschlägt, schlägt die Aufgabe fehl.
Um die Bereitstellung zu beschleunigen, legen Sie den Amazon-ECS-Agenten-Parameter auf einen der folgenden Werte fest:
+ `ECS_IMAGE_PULL_BEHAVIOR`: `once`
Das Image wird nur dann per Fernzugriff abgerufen, wenn es noch nicht von einer vorherigen Aufgabe in derselben Container-Instance abgerufen wurde, oder das zwischengespeicherte Image von der automatischen Bereinigungsfunktion entfernt wurde. Andernfalls wird das zwischengespeicherte Image in der Instance verwendet. Dadurch wird sichergestellt, dass keine unnötigen Image-Abrufversuche durchgeführt werden.
+ `ECS_IMAGE_PULL_BEHAVIOR`: `prefer-cached`
Das Image wird per Fernzugriff abgerufen, wenn es kein zwischengespeichertes Image gibt. Andernfalls wird das zwischengespeicherte Image in der Instance verwendet. Die automatische Image-Bereinigung wird für den Container deaktiviert, um sicherzustellen, dass das zwischengespeicherte Image nicht entfernt wird.
Wenn Sie den `ECS_IMAGE_PULL_BEHAVIOR`-Parameter auf einen der vorherigen Werte setzen, kann dies Zeit sparen, da der Amazon-ECS-Agent das vorhandene heruntergeladene Image verwendet. Bei größeren Docker-Images kann die Download-Zeit 10 bis 20 Sekunden dauern, bis sie über das Netzwerk abgerufen werden.