Unterschiede bei der ECS Amazon-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 sind weitere Überlegungen zu beachten.

Aufgabendefinitionsparameter

Aufgaben, die den Starttyp Fargate verwenden, unterstützen nicht alle verfügbaren ECS Amazon-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 v seinCPU.

• 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 im AWS Management Console Feld Erfordert Kompatibilitäten an. FARGATE

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

• Geben Sie im Amazon ECS API die requiresCompatibilities Flagge an.

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 CPU X86_64-Architektur verfügen.

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

Aufgabe und Speicher CPU

ECSAmazon-Aufgabendefinitionen für AWS Fargate erfordern, dass Sie CPU den Speicher auf Aufgabenebene angeben. Sie können zwar auch Speicher auf Containerebene für Fargate-Aufgaben angebenCPU, 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 aus Aufgabenebene CPU und Speicher. 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 virtual CPUs (vCPUs) angeben. Sie können beispielsweise einen CPU Wert entweder 1024 in CPU Einheiten oder 1 vCPU in angebenvCPUs.

CPUWert	Speicherwert	Unterstützte Betriebssysteme für AWS Fargate
256 (2,5 vCPU)	512 MiB, 1 GB, 2 GB	Linux
512 V (2,5 V) CPU	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 V) CPU	Zwischen 8 GB und 30 GB in 1-GB-Schritten	Linux, Windows
8192 (8 V) CPU Anmerkung Diese Option erfordert die Linux-Plattform 1.4.0 oder höher.	Zwischen 16 GB und 60 GB in 4-GB-Schritten	Linux
16384 (16 V) CPU 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

ECSAmazon-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 eine Fargate-Aufgabe in einem öffentlichen Subnetz Container-Images abrufen kann, muss der elastic network interface der Aufgabe eine öffentliche IP-Adresse zugewiesen werden, mit einer Route zum Internet oder einem NAT Gateway, das Anfragen an das Internet weiterleiten kann. Damit eine Fargate-Aufgabe in einem privaten Subnetz Container-Images abrufen kann, benötigen Sie ein NAT Gateway im Subnetz, um Anfragen an das Internet weiterzuleiten. Wenn Sie Ihre Container-Images in Amazon hostenECR, können Sie Amazon so konfigurieren, ECR dass es einen VPC Schnittstellenendpunkt verwendet. In diesem Fall wird die private IPv4 Adresse der Aufgabe für den Image-Pull verwendet. Weitere Informationen zu ECR Amazon-Schnittstellenendpunkten finden Sie unter ECRVPCAmazon-Schnittstellenendpunkte (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

ECSAmazon-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.

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

ECSAmazon-Aufgaben, die auf Fargate gehostet werden, verwenden die vom Betriebssystem festgelegten Standardwerte für Ressourcengrenzwerte, mit Ausnahme des Parameters nofile Ressourcenlimit. 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 ergreift EventBridge. Sie können Amazon ECS Events verwenden EventBridge , um nahezu in Echtzeit Benachrichtigungen über den aktuellen Status Ihrer ECS Amazon-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 ECS Amazon-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. Anhand 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 OCI Seekable-Indizes verwenden sollten. Weitere Informationen über Container-Image-Verfahren finden Sie unter Bewährte Methoden für ECS Amazon-Container-Images.

Anwendungsprotokollierung

ECSAmazon-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. ECSAmazon-Logs senden an CloudWatch

Weitere Informationen zum awsfirelens-Protokolltreiber in einer Aufgabendefinition finden Sie unter ECSAmazon-Logs 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 ECS Amazon-Aufgaben, die auf Fargate gehostet werden, werden die folgenden Speichertypen unterstützt:

• EBSAmazon-Volumes bieten kostengünstigen, dauerhaften und leistungsstarken Blockspeicher für datenintensive containerisierte Workloads. Weitere Informationen finden Sie unter Verwenden Sie EBS Amazon-Volumes mit Amazon ECS.

• EFSAmazon-Volumes für persistenten Speicher. Weitere Informationen finden Sie unter Verwenden Sie EFS Amazon-Volumes mit Amazon ECS.

• Binden Sie Halterungen für den flüchtigen Speicher. Weitere Informationen finden Sie unter Verwenden Sie Bind Mounts mit Amazon ECS.

Verzögertes Laden von Container-Images mit Seekable OCI () SOCI

ECSAmazon-Aufgaben auf Fargate, die die Linux-Plattformversion verwenden, 1.4.0 können Seekable OCI (SOCI) verwenden, um Aufgaben schneller zu starten. Mit dieser SOCI Option benötigen Container nur wenige Sekunden für den Image-Pull, bevor sie starten können. So bleibt Zeit für die Einrichtung der Umgebung und die Anwendungsinstanziierung, während das Image im Hintergrund heruntergeladen wird. Dies wird als Lazy Loading bezeichnet. Wenn Fargate eine ECS Amazon-Aufgabe startet, erkennt Fargate automatisch, ob ein SOCI Index für ein Bild in der Aufgabe vorhanden ist, und startet den Container, ohne darauf zu warten, dass das gesamte Bild 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 Amazon ECS optimierten Instances AMI dasselbe. EC2

Suchbare Indizes OCI

Seekable OCI (SOCI) ist eine von Seekable () entwickelte Open-Source-Technologie, mit der Container schneller gestartet werden können AWS , indem das Container-Image langsam geladen wird. SOCIfunktioniert, indem es einen Index (SOCIIndex) der Dateien innerhalb eines vorhandenen Container-Images erstellt. 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 Bild in der Container-Registry gespeichert werden. Sie sollten nur SOCI Indizes aus vertrauenswürdigen Quellen verwenden, da der Index die maßgebliche Quelle für den Inhalt des Bildes ist. Weitere Informationen finden Sie unter Einführung von Seekable OCI für verzögertes Laden 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 einer Linux-Plattformversion ausgeführt werden, 1.4.0 können Indizes verwendenSOCI. Aufgaben, die Windows-Container auf Fargate ausführen, werden nicht unterstützt.

• Aufgaben, die auf ausgeführt werden X86_64 or ARM64 CPUArchitektur wird unterstützt.

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

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

  • ECRPrivate Register von Amazon.

• Nur Container-Images, die 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-Registry. Wenn ein Container-Image in der Aufgabe eine der Voraussetzungen nicht erfüllt, wird dieses Container-Image mit der Standardmethode heruntergeladen.

Einen OCI Seekable-Index erstellen

Damit ein Container-Image verzögert geladen werden kann, muss ein SOCI Index (eine Metadatendatei) erstellt und zusammen mit dem Container-Image im Container-Image-Repository gespeichert werden. Um einen SOCI Index zu erstellen und zu pushen, können Sie das Open-Source-Tool soci-snapshotter CLI verwenden. GitHub Oder Sie können den Index Builder bereitstellen. CloudFormation AWS SOCI Dies ist eine serverlose Lösung, die automatisch einen SOCI Index erstellt und überträgt, wenn ein Container-Image an Amazon übertragen wird. ECR Weitere Informationen zur Lösung und den Installationsschritten finden Sie unter CloudFormation AWS SOCIIndex Builder on. GitHub Mit dem CloudFormation AWS SOCI Index Builder können Sie den Einstieg automatisierenSOCI, 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 Computersoci-snapshotter. Wenn 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 mithilfe von verzögert geladen wurdeSOCI, überprüfen Sie den Endpunkt der Aufgabenmetadaten 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 soci if SOCI is used gesetzt.