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.
Pull-Verhalten von Linux-Containern auf Fargate-Container-Images für Amazon ECS
Jede Fargate-Aufgabe wird auf einer eigenen Single-Use-, Single-Tenant-Instance ausgeführt. Wenn Sie Linux-Container auf Fargate ausführen, werden Container-Images oder Container-Image-Ebenen nicht auf der Instance zwischengespeichert. Daher muss für jedes in der Aufgabe definierte Container-Image für jede Fargate-Aufgabe das gesamte Container-Image aus der Container-Image-Registry abgerufen werden. Die Zeit, die zum Abrufen der Bilder benötigt wird, steht in direktem Zusammenhang mit der Zeit, die zum Starten einer Fargate-Aufgabe benötigt wird.
Berücksichtigen Sie Folgendes, um die Abrufzeit von Bildern zu optimieren.
- Nähe zum Container-Bild
-
Um den Zeitaufwand für das Herunterladen von Container-Images zu reduzieren, sollten Sie die Daten so nah wie möglich am Computer platzieren. Das Abrufen eines Container-Images über das Internet oder über das Internet AWS-Regionen kann sich auf die Download-Zeit auswirken. Es wird empfohlen, das Container-Image in derselben Region zu speichern, in der die Aufgabe ausgeführt wird. Wenn Sie das Container-Image in Amazon ECR speichern, verwenden Sie einen VPC-Schnittstellenendpunkt, um die Abrufzeit des Images weiter zu reduzieren. Weitere Informationen finden Sie unter VPC-Endpunkte der Amazon ECR-Schnittstelle (AWS PrivateLink) im Amazon ECR-Benutzerhandbuch.
- Reduzierung der Größe von Container-Bildern
-
Die Größe eines Container-Images wirkt sich direkt auf die Download-Zeit aus. Durch die Reduzierung der Größe des Container-Images oder der Anzahl der Container-Image-Ebenen kann die Zeit reduziert werden, die für das Herunterladen eines Images benötigt wird. Lightweight-Basis-Images (wie das minimale Container-Image von Amazon Linux 2023) können erheblich kleiner sein als solche, die auf herkömmlichen Betriebssystem-Basis-Images basieren. Weitere Informationen zum Minimal-Image finden Sie unter AL2023 Minimal Container Image im Amazon Linux 2023 User Guide.
- Alternative Komprimierungsalgorithmen
-
Container-Image-Ebenen werden häufig komprimiert, wenn sie in eine Container-Image-Registry übertragen werden. Durch die Komprimierung der Container-Image-Ebene wird die Datenmenge reduziert, die über das Netzwerk übertragen und in der Container-Image-Registry gespeichert werden muss. Nachdem eine Container-Image-Ebene von der Container-Runtime auf eine Instanz heruntergeladen wurde, wird diese Ebene dekomprimiert. Der verwendete Komprimierungsalgorithmus und die Menge an v, die der Laufzeit CPUs zur Verfügung steht, wirken sich auf die Zeit aus, die zum Dekomprimieren des Container-Images benötigt wird. Auf Fargate können Sie die Größe der Aufgabe erhöhen oder den leistungsfähigeren zstd-Komprimierungsalgorithmus nutzen, um die für die Dekomprimierung benötigte Zeit zu reduzieren. Weitere Informationen finden Sie unter zstd on.
GitHub Informationen zur Implementierung der Images für Fargate finden Sie unter Reducing AWS Fargate Startup Times with zstd Compressed Container Images. - Container-Images werden verzögert geladen
-
Bei großen Container-Images (> 250 MB) kann es optimal sein, ein Container-Image verzögert zu laden, anstatt das gesamte Container-Image herunterzuladen. Auf Fargate können Sie Seekable OCI (SOCI) verwenden, um ein Container-Image verzögert aus einer Container-Image-Registry zu laden. Weitere Informationen finden Sie unter soci-snapshotter
on GitHub und Lazy loading container images using Seekable OCI (SOCI).
