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-Aufgabendefinitionen für Fargate
Um Fargate verwenden zu können, müssen Sie Ihre Aufgabendefinition so konfigurieren, dass sie den Fargate-Starttyp verwendet. Es gibt weitere Überlegungen zur Verwendung von Fargate.
## Aufgabendefinitionsparameter
Aufgaben, die Fargate 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](task_definition_parameters.md#container_definition_linuxparameters).
+ `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](task_definition_parameters.md#volumes).
+ `cpu` – Für Windows-Container auf AWS Fargate kann der Wert 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 `FARGATE` Sie AWS-Managementkonsole im Feld **Erfordert Kompatibilitäten** an.
+ 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 AWS Fargate konfigurieren, müssen Sie das Betriebssystem angeben, das der Container ausführt. Die folgenden Betriebssysteme werden für AWS Fargate unterstützt:
+ 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 auf AWS Fargate ausführen, benötigen Sie eine X86\$164-CPU-Architektur.
Wenn Sie Linux-Container auf ausführenAWS Fargate, können Sie die X86\$164-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](ecs-arm64.md).
## CPU und Arbeitsspeicher der Aufgabe
Amazon-ECS-Aufgabendefinitionen für AWS Fargate erfordern, dass Sie CPU und Speicher auf Aufgabenebene angeben. 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 als `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 (v) angeben. CPUs CPUs Sie können beispielsweise einen CPU-Wert entweder `1024` in CPU-Einheiten oder `1 vCPU` in v angebenCPUs.
| CPU-Wert | Speicherwert | Für AWS Fargate unterstützte Betriebssysteme |
| --- | --- | --- |
| 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) 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) 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 setzen den `awsvpc`-Netzwerkmodus voraus, der für jede Aufgabe eine Elastic-Network-Schnittstelle 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)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) im *Amazon Elastic Container-Registry-Benutzerhandbuch*.
Im Folgenden finden Sie ein Beispiel für den `networkConfiguration`-Abschnitt für einen Fargate-Service:
```
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [ "sg-12345678" ],
"subnets": [ "subnet-12345678" ]
}
}
```
## Aufgabenressourcenlimits
Amazon-ECS-Aufgabendefinitionen für Linux-Container auf AWS Fargate unterstützen den Parameter `ulimits` zum Definieren der Ressourcenlimits, die für einen Container festgelegt werden sollen.
Amazon-ECS-Aufgabendefinitionen für Windows auf AWS Fargate unterstützen den Parameter `ulimits` zum Definieren der Ressourcenlimits, die für einen Container eingestellt werden sollen, 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](task_definition_parameters.md#container_definition_limits).
## 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](cloudwatch_event_stream.md).
### 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-Managementkonsole 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 Container-Images in Amazon ECS](container-considerations.md).
### Anwendungsprotokollierung
Amazon-ECS-Aufgabendefinitionen für AWS Fargate unterstützen die Protokolltreiber `awslogs`, `splunk` und `awsfirelens` 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](using_awslogs.md)
Weitere Informationen zum `awsfirelens`-Protokolltreiber in einer Aufgabendefinition finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md).
Weitere Informationen zur Verwendung des Protokolltreibers `splunk` in einer Aufgabendefinition finden Sie unter [`splunk`-Protokolltreiber](example_task_definitions.md#example_task_definition-splunk).
## Aufgabenspeicher
Für Amazon-ECS-Aufgaben, die auf Fargate gehostet werden, werden die folgenden Speichertypen unterstützt:
+ Amazon-EBS-Volumes bieten kostengünstigen, dauerhaften und leistungsstarken Blockspeicher für datenintensive containerisierte Workloads. Weitere Informationen finden Sie unter [Amazon-EBS-Volumes mit Amazon ECS verwenden](ebs-volumes.md).
+ Amazon EFS-Volumes für persistenten Speicher. Weitere Informationen finden Sie unter [Amazon-EFS-Volumes mit Amazon ECS verwenden](efs-volumes.md).
+ Bind-Mounts für flüchtigen Speicher. Weitere Informationen finden Sie unter [Bind-Mounts mit Amazon ECS verwenden](bind-mounts.md).
## 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-EC2 Instances gleich.
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](https://aws.amazon.com/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images/) von Container-Images.
Kunden, die SOCI verwenden möchten, können nur das SOCI Index Manifest v2 verwenden. Bestehende Kunden, die SOCI zuvor auf Fargate verwendet haben, können das SOCI Index Manifest v1 weiterhin verwenden. Wir empfehlen diesen Kunden jedoch dringend, auf SOCI Index Manifest v2 zu migrieren. Das SOCI Index Manifest v2 stellt eine explizite Beziehung zwischen Container-Images und ihren SOCI-Indizes her, um konsistente Bereitstellungen sicherzustellen.
**Ü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 auf X86\$164- oder ARM64-CPU-Architektur ausgeführt werden, werden unterstützt.
+ 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.
+ Es werden nur Container-Images unterstützt, die gzip-Komprimierung verwenden oder nicht komprimiert sind. Container-Images, die zstd-Komprimierung verwenden, werden nicht unterstützt.
+ Für das SOCI-Index-Manifest v2 ändert die Generierung eines SOCI-Index-Manifests das Container-Image-Manifest, wenn wir eine Anmerkung für den SOCI-Index hinzufügen. Dies führt zu einem neuen Container-Image-Digest. Der Inhalt der Dateisystemebenen für Container-Images ändert sich nicht.
+ Wenn bei SOCI Index Manifest v2 das Container-Image bereits im Container-Image-Repository gespeichert wurde, müssen Sie das Container-Image erneut übertragen, nachdem ein SOCI-Index generiert wurde. Durch erneutes Pushen eines Container-Images werden die Speicherkosten nicht durch das Duplizieren der Dateisystemebenen erhöht. Es wird lediglich eine neue Manifestdatei hochgeladen.
+ Wir empfehlen Ihnen, verzögertes Laden mit Container-Images zu versuchen, deren Größe größer als 250 MiB komprimiert ist. 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, muss das Container-Image erneut übertragen werden, ohne dass ein SOCI-Index angehängt ist.
**Erstellen eines Seekable-OCI-Indexes**
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-CLI-Tool [soci-snapshotter](https://github.com/awslabs/soci-snapshotter) verwenden. GitHub Oder Sie können den SOCI Index Builder bereitstellen. CloudFormation AWS Dies ist eine Serverless-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](https://awslabs.github.io/cfn-ecr-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 Image erstellt werden kann, muss das Image im containerd-Imagespeicher des `soci-snapshotter` ausführenden Computers vorhanden sein. Wenn sich das Image im Docker-Bildspeicher befindet, kann das Bild Image 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 ist `overlayfs`, und dieses Feld ist auf `soci` gesetzt, wenn SOCI verwendet wird. Um zu überprüfen, ob an ein Container-Image ein SOCI Index Manifest v2 angehängt ist, können Sie den Image-Index von Amazon ECR abrufen, indem Sie die AWS CLI verwenden.
```
IMAGE_REPOSITORY=r
IMAGE_TAG=latest
aws ecr batch-get-image \
--repository-name=$IMAGE_REPOSITORY \
--image-ids imageTag=$IMAGE_TAG \
--query 'images[0].imageManifest' --output text | jq -r '.manifests[] | select(.artifactType=="application/vnd.amazon.soci.index.v2+json")'
```
Um zu überprüfen, ob an ein Container-Image ein SOCI Index Manifest v1 angehängt ist, können Sie die OCI-Referrers-API verwenden.
```
ACCOUNT_ID=111222333444
AWS_REGION=us-east-1
IMAGE_REPOSITORY=nginx-demo
IMAGE_TAG=latest
IMAGE_DIGEST=$(aws ecr describe-images --repository-name $IMAGE_REPOSITORY --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[0].imageDigest' --output text)
ECR_PASSWORD=$(aws ecr get-login-password)
curl \
--silent \
--user AWS:$ECR_PASSWORD \
https://$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/v2/$IMAGE_REPOSITORY/referrers/$IMAGE_DIGEST?artifactType=application%2Fvnd.amazon.soci.index.v1%2Bjson | jq -r '.'
```