Unterschiede bei der Amazon ECS-Aufgabendefinition für den Fargate-Starttyp - Amazon Elastic Container Service
AufgabendefinitionsparameterBetriebssysteme und ArchitekturenCPU und Arbeitsspeicher der AufgabeAufgabenvernetzungAufgabenressourcenlimitsProtokollierungAufgabenspeicherLazy Loading von SOCI-Container-Images

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.

Unterschiede bei der Amazon ECS-Aufgabendefinition für den Fargate-Starttyp

Um Fargate verwenden zu können, müssen Sie Ihre Aufgabendefinition so konfigurieren, dass sie den Fargate-Starttyp verwendet. Bei der Verwendung von Fargate müssen zusätzliche Überlegungen angestellt werden.

Aufgabendefinitionsparameter

Aufgaben, die den Fargate-Starttyp verwenden, unterstützen nicht alle verfügbaren Amazon-ECS-Aufgabendefinitionsparameter. Einige Parameter werden generell nicht unterstützt, bei anderen weicht deren Verhalten für Fargate-Aufgaben ab.

Die folgenden Aufgabendefinitionsparameter sind in Fargate-Aufgaben nicht gültig:

  • disableNetworking

  • dnsSearchDomains

  • dnsServers

  • dockerSecurityOptions

  • extraHosts

  • gpu

  • ipcMode

  • links

  • placementConstraints

  • privileged

  • maxSwap

  • swappiness

Die folgenden Aufgabendefinitionsparameter sind in Fargate-Aufgaben gültig, weisen jedoch Einschränkungen auf, die zu beachten sind:

  • linuxParameters – Bei der Angabe von Linux-spezifischen Optionen, die auf den Container angewendet werden, ist CAP_SYS_PTRACE die einzige Kapazität für capabilities, die Sie hinzufügen können. Die Parameter devices, sharedMemorySize und tmpfs werden nicht unterstützt. Weitere Informationen finden Sie unter Linux-Parameter.

  • volumes – Fargate-Aufgaben unterstützen nur Bind-Mount-Host-Volumes, der dockerVolumeConfiguration-Parameter wird daher nicht unterstützt. Weitere Informationen finden Sie unter Datenträger.

  • cpu- Für Windows-Container auf AWS Fargate, der Wert darf nicht kleiner als 1 vCPU sein.

  • networkConfiguration- Fargate-Aufgaben verwenden immer den awsvpc Netzwerkmodus.

Um sicherzustellen, dass die Aufgabendefinition für Fargate validiert wird, können Sie beim Registrieren der Aufgabendefinition Folgendes angeben:

  • Geben Sie AWS Management Console im Feld Erfordert Kompatibilitäten an. FARGATE

  • Geben Sie im AWS CLI die --requires-compatibilities Option an.

  • Legen Sie in der Amazon ECS API das Flag requiresCompatibilities fest.

Betriebssysteme und Architekturen

Wenn Sie eine Aufgaben- und Containerdefinition für konfigurieren AWS Fargate, müssen Sie das Betriebssystem angeben, auf dem der Container ausgeführt wird. Die folgenden Betriebssysteme werden unterstützt für AWS Fargate:

  • Amazon Linux 2

    Anmerkung

    Linux-Container verwenden nur den Kernel und die Kernelkonfiguration des Host-Betriebssystems. Die Kernel-Konfiguration umfasst beispielsweise die sysctl-Systemsteuerelemente. Ein Linux-Container-Image kann aus einem Basis-Image erstellt werden, das die Dateien und Programme aus jeder Linux-Verteilung enthält. Wenn die CPU-Architektur übereinstimmt, können Sie Container von jedem Linux-Container-Image auf jedem Betriebssystem aus ausführen.

  • Windows Server 2019 Voll

  • Windows Server 2019 Kern

  • Windows Server 2022 Voll

  • Windows Server 2022 Kern

Wenn Sie Windows-Container ausführen auf AWS Fargate, Sie müssen über die X86_64-CPU-Architektur verfügen.

Wenn Sie Linux-Container ausführen auf AWS Fargate, können Sie die X86_64-CPU-Architektur oder die ARM64 Architektur für Ihre ARM-basierten Anwendungen verwenden. Weitere Informationen finden Sie unter Amazon ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads.

CPU und Arbeitsspeicher der Aufgabe

Amazon ECS-Aufgabendefinitionen für AWS Fargate erfordern, dass Sie CPU und Speicher auf Aufgabenebene angeben. Sie können CPU- und Speicherauslastung zwar für Fargate-Aufgaben auch auf Container-Ebene festlegen, dies ist jedoch optional. In den meisten Fällen reicht es aus, diese Ressourcen nur auf Aufgabenebene festzulegen. Die folgende Tabelle zeigt die gültigen Kombinationen von CPU- und Speicherauslastung auf Aufgabenebene. Sie können Speicherwerte in der Aufgabendefinition als Zeichenfolge in MiB oder GB angeben. Sie können beispielsweise einen Speicherwert entweder 3072 in MiB oder 3 GB in GB angeben. Sie können CPU-Werte in der JSON-Datei als Zeichenfolge in CPU-Einheiten oder virtuell CPUs (vCPUs) angeben. Sie können beispielsweise einen CPU-Wert entweder 1024 in CPU-Einheiten oder 1 vCPU in v angebenCPUs.

CPU-Wert Speicherwert Unterstützte Betriebssysteme für AWS Fargate
256 (0,25 vCPU) 512 MiB, 1 GB, 2 GB Linux
512 (0,5 vCPU) 1 GB, 2 GB, 3 GB, 4 GB Linux
1024 (1 vCPU) 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB Linux, Windows
2048 (2 vCPU) Zwischen 4 GB und 16 GB in 1-GB-Schritten Linux, Windows
4096 (4 vCPU) Zwischen 8 GB und 30 GB in 1-GB-Schritten Linux, Windows
8 192 (8 vCPU)
Anmerkung

Diese Option erfordert die Linux-Plattform 1.4.0 oder höher.

 Zwischen 16 GB und 60 GB in 4-GB-Schritten Linux
16 384 (16 vCPU)
Anmerkung

Diese Option erfordert die Linux-Plattform 1.4.0 oder höher.

 Zwischen 32 GB und 120 GB in 8-GB-Schritten Linux

Aufgabenvernetzung

Amazon ECS-Aufgaben für AWS Fargate erfordern den awsvpc Netzwerkmodus, der für jede Aufgabe eine elastic network interface bereitstellt. Wenn Sie mit diesem Netzwerkmodus eine Aufgabe ausführen oder einen Service erstellen, müssen Sie mindestens ein Subnetz und mindestens eine Sicherheitsgruppe für die Netzwerkschnittstelle festlegen.

Wenn Sie keine öffentlichen Subnetze verwenden, legen Sie fest, ob Sie eine öffentliche IP-Adresse für die Netzwerkschnittstelle bereitstellen möchten. Damit die Fargate-Aufgabe in einem öffentlichen Subnetz Container-Images abrufen kann, muss der Elastic-Network-Schnittstelle der Aufgabe eine öffentliche IP-Adresse sowie eine Route zum Internet oder einem NAT-Gateway zugewiesen werden, um Anfragen an das Internet weiterzuleiten. Damit eine Fargate-Aufgabe in einem privaten Subnetz Container-Images abrufen kann, benötigen Sie ein NAT-Gateway im Subnetz zur Weiterleitung von Anforderungen an das Internet. Wenn Sie Ihre Container-Images in Amazon ECR hosten, können Sie Amazon ECR so konfigurieren, dass ein Interface-VPC-Endpunkt verwendet wird. In diesem Fall wird die private IPv4 Adresse der Aufgabe für den Image-Pull verwendet. Weitere Informationen zu Amazon ECR-Schnittstellen-Endpunkten finden Sie unter Amazon ECR-Schnittstellen-VPC Endpunkte (AWS PrivateLink) im Amazon Elastic Container-Registry-Benutzerhandbuch.

Im Folgenden finden Sie ein Beispiel für den networkConfiguration Abschnitt für einen Fargate-Dienst:

"networkConfiguration": { 
   "awsvpcConfiguration": { 
      "assignPublicIp": "ENABLED",
      "securityGroups": [ "sg-12345678" ],
      "subnets": [ "subnet-12345678" ]
   }
}

Aufgabenressourcenlimits

Amazon ECS-Aufgabendefinitionen für Linux-Container auf AWS Fargate unterstützt den ulimits Parameter zur Definition der Ressourcenlimits, die für einen Container festgelegt werden sollen.

Amazon ECS-Aufgabendefinitionen für Windows auf AWS Fargate unterstützen den ulimits Parameter zur Definition der für einen Container festzulegenden Ressourcenlimits nicht.

Amazon-ECS-Aufgaben, die auf Fargate gehosted werden, verwenden die Standardwerte für Ressourcenlimits, die vom Betriebssystem gesetzt wurden. Ausgenommen ist der Ressourcenlimitparameter nofile. Das Ressourcenlimit nofile beschränkt die Anzahl der geöffneten Dateien, die ein Container verwenden kann. Auf Fargate ist die nofile-Standardeinstellung für die weiche Grenze 65535 und die harte Grenze 65535. Sie können die Werte beider Grenzwerte auf bis zu 1048576 festlegen.

Das folgende ist ein Beispiel-Snippet für Aufgabendefinitionen, das zeigt, wie eine benutzerdefinierte nofile-Grenze, die verdoppelt wurde:

"ulimits": [
    {
       "name": "nofile",
       "softLimit": 2048,
       "hardLimit": 8192
    }
]

Weitere Informationen zu den anderen Ressourcenlimits, die angepasst werden können, finden Sie unter Ressourcenlimits.

Protokollierung

Protokollieren von Ereignissen

Amazon ECS protokolliert die Aktionen, die es ausführt EventBridge. Sie können Amazon ECS-Ereignisse verwenden EventBridge , um nahezu in Echtzeit Benachrichtigungen über den aktuellen Status Ihrer Amazon ECS-Cluster, -Services und -Tasks zu erhalten. Darüber hinaus können Sie Aktionen zur Reaktion auf diese Ereignisse automatisieren. Weitere Informationen finden Sie unter Automatisieren Sie Antworten auf Amazon ECS-Fehler mit EventBridge.

Aufgabenlebenszyklus protokollieren

Aufgaben, die auf Fargate ausgeführt werden, veröffentlichen Zeitstempel, um die Aufgabe über die Status des Aufgabenlebenszyklus hinweg zu verfolgen. Sie können die Zeitstempel in den Aufgabendetails im AWS Management Console und sehen, indem Sie die Aufgabe im AWS CLI und SDKs beschreiben. Mithilfe der Zeitstempel können Sie beispielsweise auswerten, wie viel Zeit die Aufgabe für das Herunterladen der Container-Images aufgewendet hat, und entscheiden, ob Sie die Größe des Container-Images optimieren oder Seekable-OCI-Indizes verwenden sollten. Weitere Informationen über Container-Image-Verfahren finden Sie unter Bewährte Methoden für Amazon ECS-Container-Images.

Anwendungsprotokollierung

Amazon ECS-Aufgabendefinitionen für AWS Fargate unterstützt die awsfirelens Protokolltreiber awslogssplunk, und für die Protokollkonfiguration.

Der awslogs Protokolltreiber konfiguriert Ihre Fargate-Aufgaben so, dass Protokollinformationen an Amazon CloudWatch Logs gesendet werden. Das folgende Beispiel zeigt einen Ausschnitt einer Aufgabendefinition, in der der Protokolltreiber awslogs konfiguriert wurde:

"logConfiguration": { 
   "logDriver": "awslogs",
   "options": { 
      "awslogs-group" : "/ecs/fargate-task-definition",
      "awslogs-region": "us-east-1",
      "awslogs-stream-prefix": "ecs"
   }
}

Weitere Informationen zur Verwendung des awslogs Log-Treibers in einer Aufgabendefinition zum Senden Ihrer Container-Logs an CloudWatch Logs finden Sie unter. Amazon ECS-Protokolle senden an CloudWatch

Weitere Informationen zum awsfirelens-Protokolltreiber in einer Aufgabendefinition finden Sie unter Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner.

Weitere Informationen zur Verwendung des Protokolltreibers splunk in einer Aufgabendefinition finden Sie unter splunkProtokolltreiber.

Aufgabenspeicher

Für Amazon-ECS-Aufgaben, die auf Fargate gehostet werden, werden die folgenden Speichertypen unterstützt:

Lazy Loading von Container-Images mit Seekable OCI (SOCI)

Amazon-ECS-Aufgaben auf Fargate, welche die Linux-Plattformversion 1.4.0 verwenden, können Seekable OCI (SOCI) einsetzen, um Aufgaben schneller zu starten. Mit SOCI verbringen Container nur wenige Sekunden mit dem Abruf von Images, bevor sie starten können. So bleibt Zeit für die Einrichtung der Umgebung und die Instanziierung der Anwendung, während das Image im Hintergrund heruntergeladen wird. Dies wird als Lazy Loading bezeichnet. Wenn Fargate eine Amazon-ECS-Aufgabe startet, erkennt Fargate automatisch, ob ein SOCI-Index für ein Image in der Aufgabe vorhanden ist, und startet den Container, ohne darauf zu warten, dass das gesamte Image heruntergeladen wird.

Bei Containern, die ohne SOCI-Indizes ausgeführt werden, werden Container-Images vollständig heruntergeladen, bevor der Container gestartet wird. Dieses Verhalten ist auf allen anderen Plattformversionen von Fargate und auf dem Amazon ECS-optimierten AMI auf Amazon-Instances dasselbe. EC2

Seekable OCI Indexes

Seekable OCI (SOCI) ist eine von entwickelte Open-Source-Technologie, mit der Container schneller gestartet werden können AWS , indem das Container-Image langsam geladen wird. SOCI erstellt einen Index (SOCI-Index) der Dateien in einem vorhandenen Container-Image. Dieser Index hilft dabei, Container schneller zu starten, indem er die Möglichkeit bietet, eine einzelne Datei aus einem Container-Image zu extrahieren, bevor das gesamte Image heruntergeladen wird. Der SOCI-Index muss als Artefakt im selben Repository wie das Image in der Container-Registrierung gespeichert werden. Sie sollten nur SOCI-Indizes aus vertrauenswürdigen Quellen verwenden, da der Index die autorisierende Quelle für den Inhalt des Images ist. Weitere Informationen finden Sie unter Einführen von Seekable OCI für Lazy Loading von Container-Images.

Überlegungen

Wenn Sie möchten, dass Fargate einen SOCI-Index verwendet, um Container-Images in einer Aufgabe verzögert zu laden, sollten Sie Folgendes berücksichtigen:

  • Nur Aufgaben, die auf Linux-Plattformversion 1.4.0 ausgeführt werden, können SOCI-Indizes verwenden. Aufgaben, die Windows-Container auf Fargate ausführen, werden nicht unterstützt.

  • Aufgaben, die ausgeführt werden auf X86_64 or ARM64 Die CPU-Architektur wird unterstützt.

  • Container-Images in der Aufgabendefinition müssen SOCI-Indizes in derselben Container-Registrierung wie das Image aufbewahren.

  • Container-Images in der Aufgabendefinition müssen in einer kompatiblen Image-Registry gespeichert werden. Im Folgenden sind die kompatiblen Registrys aufgeführt:

    • Private Amazon-ECR-Registrys.

  • Nur Container-Images, die Folgendes verwenden gzip Komprimierung oder Nichtkomprimierung werden unterstützt. Container-Images, die verwenden zstd Komprimierung wird nicht unterstützt.

  • Wir empfehlen Ihnen, Lazy Loading mit Container-Images zu versuchen, die größer sind als 250 MiB in der Größe komprimiert. Es ist weniger wahrscheinlich, dass die Zeit zum Laden kleinerer Image verkürzt werden kann.

  • Da Lazy Loading ändern kann, wie lange es dauert, bis Ihre Aufgaben gestartet werden, müssen Sie möglicherweise verschiedene Timeouts ändern, z. B. den Kulanzzeitraum für die Zustandsprüfung für Elastic Load Balancing.

  • Wenn Sie verhindern möchten, dass ein Container-Image verzögert geladen wird, löschen Sie den SOCI-Index aus der Container-Registrierung. Wenn ein Container-Image in der Aufgabe eine der Voraussetzungen nicht erfüllt, wird dieses Container-Image mit der Standardmethode heruntergeladen.

Erstellen eines Seekable-OCI-Indexes

Damit ein Container-Image verzögert geladen werden kann, benötigt es einen SOCI-Index (eine Metadatendatei), der erstellt und zusammen mit dem Container-Image im Container-Image-Repository gespeichert wird. Um einen SOCI-Index zu erstellen und zu pushen, können Sie das Open-Source-CLI-Tool soci-snapshotter verwenden. GitHub Oder Sie können den SOCI Index Builder bereitstellen. CloudFormation AWS Dies ist eine serverlose Lösung, die automatisch einen SOCI-Index erstellt und überträgt, wenn ein Container-Image an Amazon ECR übertragen wird. Weitere Informationen zur Lösung und den Installationsschritten finden Sie unter CloudFormation AWS SOCI Index Builder unter. GitHub Mit dem CloudFormation AWS SOCI Index Builder können Sie die ersten Schritte mit SOCI automatisieren, während das Open-Source-Tool SOCI mehr Flexibilität bei der Indexgenerierung bietet und die Indexgenerierung in Ihre CI/CD-Pipelines (Continuous Integration and Continuous Delivery) integrieren kann.

Anmerkung

Damit der SOCI-Index für ein Bild erstellt werden kann, muss das Bild im containerd Bildspeicher auf dem laufenden soci-snapshotter Computer. Wenn sich das Bild in der Docker Bildspeicher, das Bild kann nicht gefunden werden.

Überprüfen, ob eine Aufgabe Lazy Loading verwendet

Um zu überprüfen, ob eine Aufgabe mit Hilfe von SOCI verzögert geladen wurde, überprüfen Sie den Metadaten-Endpunkt der Aufgabe von innerhalb der Aufgabe. Wenn Sie den Aufgabenmetadaten-Endpunkt Version 4 abfragen, gibt es ein Snapshotter-Feld im Standardpfad für den Container, von dem aus Sie die Abfrage durchführen. Darüber hinaus gibt es Snapshotter-Felder für jeden Container im /task-Pfad. Der Standardwert für dieses Feld istoverlayfs, und dieses Feld ist auf gesetzt, soci wenn SOCI verwendet wird.