You are using Amazon FSx for Windows File Server file system for persistent container storage.
' -Force"],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": false,
"name": "container1",
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
]
},
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [
{
"hostPort": 443,
"protocol": "tcp",
"containerPort": 80
}
],
"command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"],
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": true,
"name": "container2"
}
],
"family": "fsx-windows",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"volumes": [
{
"name": "fsx-windows-dir",
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "fs-0eeb5730b2EXAMPLE",
"authorizationConfig": {
"domain": "example.com",
"credentialsParameter": "arn:arn-1234"
},
"rootDirectory": "share"
}
}
]
}
```
`FSxWindowsFileServerVolumeConfiguration`
Typ: Objekt
Erforderlich: Nein
Dieser Parameter wird angegeben, wenn Sie das Dateisystem [FSx für den Windows-Dateiserver](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) als Aufgabenspeicher verwenden.
`fileSystemId`
Typ: Zeichenfolge
Erforderlich: Ja
Die FSx für das Windows-Dateiserver zu verwendende Dateisystem-ID.
`rootDirectory`
Typ: Zeichenfolge
Erforderlich: Ja
Das Verzeichnis innerhalb des Dateisystems FSx für Windows File Server, das als Stammverzeichnis auf dem Host bereitgestellt werden soll.
`authorizationConfig`
`credentialsParameter`
Typ: Zeichenfolge
Erforderlich: Ja
Die Optionen für Autorisierungsanmeldeinformationen:
+ Amazon-Ressourcenname (ARN) eines [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)-Secrets.
+ Amazon-Ressourcenname (ARN) eines [Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html)-Parameters.
`domain`
Typ: Zeichenfolge
Erforderlich: Ja
Ein vollqualifizierter Domain-Name, der von einem [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD)-Verzeichnis oder einem selbst gehosteten EC2-Active-Directory gehostet wird.
## Methoden zum Speichern von Anmeldeinformationen FSx für das Windows-Dateiserver-Volume
Es gibt zwei verschiedene Methoden zum Speichern von Anmeldeinformationen für die Verwendung mit dem Anmeldeinformationen-Parameter.
+ **AWS Secrets Manager geheim**
Diese Anmeldeinformationen können in der AWS Secrets Manager Konsole mithilfe der Kategorie *Andere geheime Daten* erstellt werden. Sie fügen für jedes key/value Paar eine Zeile username/admin und *password* password/ hinzu.
+ **Systems Manager-Parameter**
Diese Anmeldeinformationen können in der Systems Manager-Parameterkonsole erstellt werden, indem Sie Text in das Formular eingeben, das im folgenden Codeausschnitt gezeigt wird.
```
{
"username": "admin",
"password": "password"
}
```
`credentialsParameter` im Aufgabendefinitions-Parameter `FSxWindowsFileServerVolumeConfiguration` enthält entweder den geheimen ARN oder den Systems Manager Parameter ARN. Weitere Informationen finden Sie unter [Was ist AWS -Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) im *Secrets Manager-Benutzerhandbuch* und [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) aus dem *Systems Manager-Benutzerhandbuch*.
# Erfahren Sie, wie Sie Dateisysteme FSx für Windows File Server für Amazon ECS konfigurieren
Erfahren Sie, wie Sie eine Amazon ECS-optimierte Windows-Instance starten, die ein Dateisystem FSx für Windows File Server und Container hostet, die auf das Dateisystem zugreifen können. Dazu erstellen Sie zunächst ein Directory Service AWS verwaltetes Microsoft Active Directory. Anschließend erstellen Sie ein Dateisystem und einen Cluster für Amazon FSx für Windows File Server mit einer Amazon-EC2-Instance und einer Aufgabendefinition. Sie konfigurieren die Aufgabendefinition für Ihre Container so, dass sie das Dateisystem FSx für Windows File Server verwenden. Zum Schluss testen Sie das Dateisystem.
Jedes Mal, wenn Sie das Active Directory-Dateisystem oder das Dateisystem FSx für Windows File Server starten oder löschen, dauert es 20 bis 45 Minuten. Seien Sie bereit, mindestens 90 Minuten zu reservieren, um das Tutorial abzuschließen oder das Tutorial über ein paar Sitzungen abzuschließen.
## Voraussetzungen für das Tutorial
+ Ein Administratorbenutzer. Siehe [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md).
+ (Optional) Ein `PEM`-Schlüsselpaar für die Verbindung mit Ihrer EC2-Windows-Instance über RDP-Zugriff. Weitere Informationen zum Erstellen von Schlüsselpaaren finden Sie unter [Amazon-EC2-Schlüsselpaare und Amazon-EC2-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*.
+ Eine VPC mit mindestens einem öffentlichen und einem privaten Subnetz sowie einer Sicherheitsgruppe. Sie können Ihre Standard-VPC verwenden. Sie benötigen kein NAT-Gateway oder -Gerät. Directory Service unterstützt nicht Network Address Translation (NAT) mit Active Directory. Damit dies funktioniert, müssen sich das Active Directory, das Dateisystem für FSx für Windows File Server, der ECS-Cluster und die EC2-Instance in Ihrer VPC befinden. Weitere Informationen zu Active VPCs Directorys finden Sie unter [Erstellen einer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) und [Voraussetzungen für die Erstellung eines AWS verwalteten Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_prereqs).
+ Die IAM ecsInstanceRole - und ecsTaskExecution Rollenberechtigungen sind mit Ihrem Konto verknüpft. Diese serviceverknüpften Rollen ermöglichen es Services, API-Aufrufe durchzuführen und in Ihrem Namen auf Container, Secrets, Verzeichnisse und Dateiserver zuzugreifen.
## Schritt 1: Erstellen von IAM-Zugriffsrollen
**Erstellen Sie einen Cluster mit AWS-Managementkonsole.**
1. Prüfen [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md) Sie, ob Sie über ein Konto verfügen, ecsInstanceRole und finden Sie heraus, wie Sie eines erstellen können, falls Sie noch keines haben.
1. Es wird empfohlen, Rollenrichtlinien für Mindestberechtigungen in einer tatsächlichen Produktionsumgebung anzupassen. Stellen Sie zum Durcharbeiten dieses Tutorials sicher, dass die folgende AWS verwaltete Richtlinie an Ihre angehängt istecsInstanceRole. Fügen Sie die Richtlinie hinzu, wenn sie noch nicht angehängt ist.
+ EC2ContainerServiceforEC2Rolle bei Amazon
+ Amazon SSMManaged InstanceCore
+ Amazon SSMDirectory ServiceAccess
Um AWS verwaltete Richtlinien anzuhängen.
1. Öffnen Sie die [IAM-Konsole](https://console.aws.amazon.com//iam/).
1. Wählen Sie im Navigationsbereich **Roles** aus.
1. Wählen Sie eine **AWS -verwaltete Rolle**.
1. Wählen Sie **Berechtigungen, Richtlinien anfügen**.
1. Um die verfügbaren Richtlinien zum Anfügen einzugrenzen, verwenden Sie **Filter**.
1. Wählen Sie die entsprechende Richtlinie aus und wählen Sie dann **Attach Policy (Richtlinie anfügen)**.
1. Weitere Informationen finden Sie unter, [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md) um zu überprüfen, ob Sie über eine ecsTaskExecution Rolle verfügen, und wie Sie eine erstellen können, falls Sie noch keine haben.
Es wird empfohlen, Rollenrichtlinien für Mindestberechtigungen in einer tatsächlichen Produktionsumgebung anzupassen. Stellen Sie beim Durcharbeiten dieses Tutorials sicher, dass die folgenden AWS verwalteten Richtlinien mit Ihrer ecsTaskExecution Rolle verknüpft sind. Fügen Sie die Richtlinien hinzu, wenn sie noch nicht angehängt sind. Gehen Sie wie im vorherigen Abschnitt beschrieben vor, um die AWS verwalteten Richtlinien anzuhängen.
+ SecretsManagerReadWrite
+ Amazon FSx ReadOnlyAccess
+ Amazon SSMRead OnlyAccess
+ Amazon ECSTask ExecutionRolePolicy
## Schritt 2: Erstellen von Windows Active Directory (AD)
1. Folgen Sie den unter [Creating Your AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory) im AWS *Directory Service Administration Guide* beschriebenen Schritten. Verwenden Sie die VPC, die Sie für dieses Lernprogramm festgelegt haben. Speichern Sie in Schritt 3 der *Erstellung Ihres AWS verwalteten Microsoft AD* den Benutzernamen und das Administratorkennwort für die Verwendung in einem folgenden Schritt. Notieren Sie auch den vollqualifizierten Directory-DNS-Namen für zukünftige Schritte. Sie können den folgenden Schritt ausführen, während das Active Directory erstellt wird.
1. Erstellen Sie ein AWS Secrets Manager Manager-Geheimnis, das Sie in den folgenden Schritten verwenden können. Weitere Informationen finden [Sie unter Erste Schritte mit Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#get-started) im AWS *Secrets Manager Manager-Benutzerhandbuch*.
1. Öffnen Sie die [Secrets Manager-Konsole](https://console.aws.amazon.com//secretsmanager/).
1. Klicken Sie auf **Speichern eines neuen Secrets**.
1. Wählen Sie **Andere Art von Secrets** aus.
1. Erstellen Sie für **Secret key/value** in der ersten Zeile einen Schlüssel **username** mit Wert **admin**. Klicken Sie auf das Symbol **\$1 Zeile hinzufügen**.
1. Erstellen Sie in der neuen Zeile einen Schlüssel **password**. Geben Sie als Wert das Passwort ein, das Sie in Schritt 3 von *Create Your AWS Managed AD Directory* eingegeben haben.
1. Klicken Sie auf die Schaltfläche **Weiter**.
1. Geben Sie einen Namen und eine Beschreibung des Secrets ein. Klicken Sie auf **Weiter**.
1. Klicken Sie auf **Weiter**. Klicken Sie auf **Speichern**.
1. Klicken Sie auf der Seite der **Secrets** auf das Secret, das Sie gerade erstellt haben.
1. Speichern Sie den ARN des neuen Secrets für die Verwendung in den folgenden Schritten.
1. Sie können mit dem nächsten Schritt fortfahren, während Ihr Active Directory erstellt wird.
## Schritt 3: Überprüfen und aktualisieren Sie Ihre Sicherheitsgruppe
In diesem Schritt überprüfen und aktualisieren Sie die Regeln für die Sicherheitsgruppe, die Sie verwenden. Sie können die Standardsicherheitsgruppe, die für Ihre VPC erstellt wurde, verwenden.
**Überprüfen und aktualisieren Sie die Sicherheitsgruppe.**
Sie müssen Ihre Sicherheitsgruppe erstellen oder bearbeiten, um Daten von und zu den Ports zu senden. Diese sind unter [Amazon VPC Security Groups](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/limit-access-security-groups.html#fsx-vpc-security-groups) im *Benutzerhandbuch FSx für Windows File Server* beschrieben. Sie können dies tun, indem Sie die Sicherheitsgruppenregel erstellen, die in der ersten Zeile der folgenden Tabelle mit eingehenden Regeln angezeigt wird. Diese Regel lässt eingehenden Datenverkehr von Netzwerkschnittstellen (und den zugehörigen Instances) zu, die derselben Sicherheitsgruppe zugewiesen sind. Alle von Ihnen erstellten Cloud-Ressourcen befinden sich in derselben VPC und derselben Sicherheitsgruppe zugeordnet. Daher ermöglicht diese Regel das Senden von Datenverkehr zum und vom Dateisystem FSx für Windows File Server, Active Directory und ECS-Instance nach Bedarf. Mit den anderen eingehenden Regeln kann der Datenverkehr die Website bereitstellen und den RDP-Zugriff für die Verbindung mit Ihrer ECS-Instance herstellen.
Die folgende Tabelle zeigt, welche Sicherheitsgruppeneingangsregeln für dieses Lernprogramm erforderlich sind.
| Typ | Protocol (Protokoll) | Port-Bereich | Quelle |
| --- | --- | --- | --- |
| Gesamter Datenverkehr | Alle | Alle | *sg-securitygroup* |
| HTTPS | TCP | 443 | 0.0.0.0/0 |
| RDP | TCP | 3389 | Ihre Laptop-IP-Adresse |
Die folgende Tabelle zeigt, welche Regeln für ausgehende Sicherheitsgruppen für dieses Lernprogramm erforderlich sind.
| Typ | Protocol (Protokoll) | Port-Bereich | Ziel |
| --- | --- | --- | --- |
| Gesamter Datenverkehr | Alle | Alle | 0.0.0.0/0 |
1. Öffnen Sie [EC2-Konsole](https://console.aws.amazon.com//ec2/) und wählen Sie dann **Sicherheitsgruppen** vom Menü links.
1. Aktivieren Sie in der Liste der jetzt angezeigten Sicherheitsgruppen das Kontrollkästchen links neben der Sicherheitsgruppe, die Sie für dieses Tutorial verwenden.
Die Details Ihrer Sicherheitsgruppe werden angezeigt.
1. Bearbeiten Sie die ein- und ausgehenden Regeln, indem Sie die Registerkarten **Inbound rules** (Regeln für eingehenden Datenverkehr) oder **Outbound rules** (Regeln für ausgehenden Datenverkehr) auswählen und die Schaltflächen **Edit inbound rules** (Bearbeiten von Regeln für eingehenden Datenverkehr) oder **Edit outbound rules** (Bearbeiten von Regeln für ausgehenden Datenverkehr) auswählen. Bearbeiten Sie die Regeln so, dass sie mit den in den vorhergehenden Tabellen angezeigten Regeln übereinstimmen. Nachdem Sie später in diesem Tutorial Ihre EC2-Instance erstellt haben, bearbeiten Sie die RDP-Quelle für eingehende Regeln mit der öffentlichen IP-Adresse Ihrer EC2-Instance, wie unter [Herstellen einer Verbindung mit Ihrer Windows-Instance mit RDP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html) im *Amazon-EC2-Benutzerhandbuch* beschrieben.
## Schritt 4: Erstellen Sie ein Dateisystem FSx für Windows File Server
Nachdem Ihre Sicherheitsgruppe verifiziert und aktualisiert wurde und Ihr Active Directory erstellt wurde und sich im aktiven Status befindet, erstellen Sie das Dateisystem FSx für Windows File Server in derselben VPC wie Ihr Active Directory. Gehen Sie wie folgt vor, um ein Dateisystem FSx für Windows File Server für Ihre Windows-Aufgaben zu erstellen.
**Erstellen Sie Ihr erstes Dateisystem.**
1. Öffnen Sie die [ FSx Amazon-Konsole](https://console.aws.amazon.com//fsx/).
1. Klicken Sie auf dem Dashboard auf **Create file system (Dateisystem erstellen)**, um den Erstellungsassistenten für Dateisysteme zu starten.
1. **Wählen Sie auf der Seite Dateisystemtyp** auswählen FSx die Option **Windows-Dateiserver** aus und klicken Sie dann auf **Weiter**. Die Seite **Create file system (Dateisystem erstellen)** wird angezeigt.
1. Geben Sie im Abschnitt **Details zum Dateisystem** einen Namen für Ihr Dateisystem an. Die Benennung Ihrer Dateisysteme erleichtert die Suche und Verwaltung Ihrer Dateisysteme. Sie können bis zu 256 Unicode-Zeichen verwenden. Erlaubt sind Buchstaben, Zahlen, Leerzeichen sowie die Sonderzeichen (\$1). Minuszeichen (-), Gleichheitszeichen (=), Punkt (.), Unterstrich (\$1), Doppelpunkt (:), und Schrägstrich (/).
1. Wählen Sie für **Deployment type (Bereitstellungstyp)** **Single-AZ**, um ein Dateisystem bereitzustellen, das in einer einzelnen Availability Zone bereitgestellt wird. *Single-AZ 2* ist die neueste Generation einzelner Availability Zone-Dateisysteme und unterstützt SSD- und HDD-Speicher.
1. Wählen Sie unter **Storage type (Speichertyp)** die Option **HDD** aus.
1. Geben Sie für **Speicherkapazität** die Mindestspeicherkapazität ein.
1. Behalten Sie die **Durchsatzkapazität** auf ihrer Standardeinstellung.
1. Wählen Sie im Bereich **Netzwerk und Sicherheit** dieselbe Amazon VPC aus, die Sie für Ihr Directory Service Verzeichnis ausgewählt haben.
1. Wählen Sie für **VPC-Sicherheitsgruppen** die Sicherheitsgruppe aus, die Sie in *Schritt 3: Überprüfen und Aktualisieren der Sicherheitsgruppe* geprüft haben.
1. Wählen Sie für **Windows-Authentifizierung** **Von AWS verwaltetes Microsoft Active Directory** und wählen Sie dann Ihr Directory Service -Verzeichnis aus der Liste.
1. Behalten Sie für **Verschlüsselung** die Standardeinstellung **Verschlüsselungsschlüssel** von **aws/fsx (Standard)** bei.
1. Behalten Sie die Standardeinstellungen für **Einstellungen für Wartung** bei.
1. Klicken Sie auf die Schaltfläche **Weiter**.
1. Prüfen Sie die Dateisystemkonfiguration, die auf der Seite **Create File System (Dateisystem erstellen)** angezeigt wird. Beachten Sie, welche Dateisystemeinstellungen Sie nach dem Erstellen des Dateisystems ändern können. Wählen Sie **Create file system (Dateisystem erstellen)** aus.
1. Notieren Sie sich die File system ID (Dateisystem-ID). Sie werden sie in einem späteren Schritt verwenden müssen.
Sie können mit den nächsten Schritten fortfahren, um einen Cluster und eine EC2-Instance zu erstellen, während das Dateisystem FSx für Windows File Server erstellt wird.
## Schritt 5: Erstellen eines Amazon-ECS-Clusters
**Einen Cluster mit der Amazon-ECS-Konsole erstellen**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version 2.](https://console.aws.amazon.com/ecs/v2)
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Clusters** die Option **Create cluster** (Cluster erstellen) aus.
1. Geben Sie unter **Cluster-Konfiguration** für **Cluster-Name** **windows-fsx-cluster** ein.
1. Erweitern Sie **Infrastruktur**, löschen Sie AWS Fargate (serverlos) und wählen Sie dann **Amazon EC2 EC2-Instances** aus.
1. Um eine Auto-Scaling-Gruppe zu erstellen, wählen Sie in der **Auto-Scaling-Gruppe (ASG)** **Create new group** (Neue Gruppe erstellen) und geben Sie dann die folgenden Details zur Gruppe an:
+ Wählen Sie für **Betriebssystem/Architektur** **Windows Server 2019 Core** aus.
+ Wählen Sie unter **EC2-Instance-Typ** t2.medium oder t2.micro.
1. Wählen Sie **Erstellen** aus.
## Schritt 6: Eine Amazon-ECS-optimierte Amazon-EC2-Instance erstellen
Erstellen Sie eine Windows-Container-Instance für Amazon ECS.
**So erstellen Sie eine Amazon-ECS-Instance**
1. Verwenden Sie den `aws ssm get-parameters`-Befehl, um den AMI-Namen für die Region abzurufen, in der Ihre VPC gehostet wird. Weitere Informationen finden Sie unter [Abrufen von Amazon-ECS-optimierten AMI-Metadaten](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html).
1. Verwenden Sie die Amazon-EC2-Konsole, um die Instance zu starten.
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Wählen Sie im **EC2-Dashboard** **Launch Instance (Instance starten)** aus.
1. Geben Sie für **Name** einen eindeutigen Namen ein.
1. Für **Anwendungs- und Betriebssystem-Images (Amazon Machine Image)** geben Sie in das **Suchfeld** den Namen des AMI ein, das Sie abgerufen haben.
1. Wählen Sie unter **Instance-Typ** t2.medium oder t2.micro.
1. Wählen Sie für **Key pair (login)** (Schlüsselpaar (Anmeldung)) ein Schlüsselpaar aus. Wenn Sie kein Schlüsselpaar angeben, werden Sie
1. Wählen Sie unter **Netzwerkeinstellungen** für **VPC** und **Subnetz** Ihre VPC und ein öffentliches Subnetz.
1. Wählen Sie unter **Network settings** (Netzwerkeinstellungen) für **Security group** (Sicherheitsgruppe) eine vorhandene Sicherheitsgruppe aus oder erstellen Sie eine neue. Stellen Sie sicher, dass für die von Ihnen gewählte Sicherheitsgruppe die Regeln für eingehenden und ausgehenden Datenverkehr in [Voraussetzungen für das Tutorial](#wfsx-prerequisites) definiert sind
1. Wählen Sie unter **Network settings** (Netzwerkeinstellungen), für **Auto-assign Public IP** (Öffentliche IP automatisch zuweisen), die Option **Enable** (Aktivieren) aus.
1. Erweitern Sie **Erweiterte Details** und wählen Sie dann für **Domain-Beitrittsverzeichnis** die ID des Active Directory, das Sie erstellt haben. Diese Options-Domain tritt Ihrem AD bei, wenn die EC2-Instance gestartet wird.
1. Wählen Sie unter **Erweiterte Details** für das **IAM-Instance-Profil** die Option. **ecsInstanceRole**
1. Konfigurieren Sie Ihre Amazon-ECS-Container-Instance mit den folgenden Benutzerdaten. Fügen Sie unter **Erweiterte Details** das folgende Skript in das Feld **Benutzerdaten** ein und *cluster\$1name* ersetzen Sie es durch den Namen Ihres Clusters.
```
```
1. Wenn Sie bereit sind, wählen Sie das Bestätigungsfeld und danach **Launch Instances** aus.
1. Auf einer Bestätigungsseite wird Ihnen mitgeteilt, dass die Instance gestartet wird. Wählen Sie **View Instances** aus, um die Bestätigungsseite zu schließen und zur Konsole zurückzukehren.
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Clusters** und anschließend aus **windows-fsx-cluster**.
1. Wählen Sie die Registerkarte **Infrastruktur** und vergewissern Sie sich, dass Ihre Instance im **windows-fsx-cluster**Cluster registriert wurde.
## Schritt 7: Registrieren einer Windows-Aufgabendefinition
Bevor Sie in Ihrem Amazon-ECS-Cluster Windows-Container ausführen können, müssen Sie eine Aufgabendefinition registrieren. Das folgende Beispiel für eine Aufgabendefinition zeigt eine einfache Webseite. Die Aufgabe startet zwei Container, die Zugriff auf das FSx Dateisystem haben. Der erste Container schreibt eine HTML-Datei in das Dateisystem. Der zweite Container lädt die HTML-Datei aus dem Dateisystem herunter und bedient die Webseite.
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie **Create new task definition** (Neue Aufgabendefinition erstellen), **Create new task definition with JSON** (Neue Aufgabendefinition mit JSON) erstellen.
1. Ersetzen Sie im Feld JSON-Editor die Werte für Ihre Aufgabenausführungsrolle und die Details zu Ihrem FSx Dateisystem und wählen Sie dann **Speichern**.
```
{
"containerDefinitions": [
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [],
"command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value '
Amazon ECS Sample App
It Works!
You are using Amazon FSx for Windows File Server file system for persistent container storage.
' -Force"],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": false,
"name": "container1",
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
]
},
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [
{
"hostPort": 443,
"protocol": "tcp",
"containerPort": 80
}
],
"command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"],
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": true,
"name": "container2"
}
],
"family": "fsx-windows",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"volumes": [
{
"name": "fsx-windows-dir",
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "fs-0eeb5730b2EXAMPLE",
"authorizationConfig": {
"domain": "example.com",
"credentialsParameter": "arn:arn-1234"
},
"rootDirectory": "share"
}
}
]
}
```
## Schritt 8: Eine Aufgabe ausführen und die Ergebnisse anzeigen
Bevor Sie die Aufgabe ausführen, überprüfen Sie, ob der Status Ihres Dateisystems FSx für Windows File Server **verfügbar** ist. Nachdem sie verfügbar ist, können Sie eine Aufgabe mithilfe der Aufgabendefinition ausführen, die Sie erstellt haben. Die Aufgabe beginnt mit dem Erstellen von Containern, die eine HTML-Datei zwischen ihnen mithilfe des Dateisystems mischen. Nach dem Shuffle bedient ein Webserver die einfache HTML-Seite.
**Anmerkung**
Möglicherweise können Sie keine Verbindung zu der Website innerhalb eines VPN herstellen.
**Führen Sie eine Aufgabe aus und zeigen die Ergebnisse mit der Amazon-ECS-Konsole an.**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Clusters** und anschließend aus **windows-fsx-cluster**.
1. Wählen Sie die Registerkarte **Aufgaben** und dann **Neue Aufgabe ausführen**.
1. Wählen Sie unter **Launch Type** **EC2** aus.
1. Wählen Sie unter Bereitstellungskonfiguration für **Aufgabendefinition** den Eintrag **fsx-windows** und wählen Sie dann **Erstellen**.
1. Wenn Ihr Aufgabenstatus **WIRD AUSGEFÜHRT** ist, wählen Sie die Aufgaben-ID aus.
1. Wählen Sie unter **Container**, wenn der Status von Container1 auf **ANGEHALTEN** steht, Container2, um die Details des Containers anzuzeigen.
1. Wählen Sie unter **Container-Details für Container2** die Option **Netzwerkbindungen** aus und klicken Sie dann auf die externe IP-Adresse, die dem Container zugeordnet ist. Ihr Browser wird geöffnet und die folgende Meldung wird angezeigt.
```
Amazon ECS Sample App
It Works!
You are using Amazon FSx for Windows File Server file system for persistent container storage.
```
**Anmerkung**
Es kann einige Minuten dauern, bis die Meldung angezeigt wird. Wenn Sie diese Meldung nach einigen Minuten nicht angezeigt wird, stellen Sie sicher, dass Sie nicht in einem VPN ausgeführt wird, und stellen Sie sicher, dass die Sicherheitsgruppe für Ihre Container-Instance eingehenden Netzwerk-HTTP-Datenverkehr auf Port 443 zulässt.
## Schritt 9: Bereinigen
**Anmerkung**
Das Löschen des Dateisystems FSx für Windows File Server oder AD dauert 20 bis 45 Minuten. Sie müssen warten, bis die Löschvorgänge FSx für das Dateisystem für den Windows-Dateiserver abgeschlossen sind, bevor Sie die AD-Löschvorgänge starten.
**Löschen Sie FSx das Dateisystem für Windows File Server.**
1. Öffnen Sie die [ FSx Amazon-Konsole](https://console.aws.amazon.com//fsx/)
1. Wählen Sie das Optionsfeld links neben dem Dateisystem FSx für Windows File Server, das Sie gerade erstellt haben.
1. Wählen Sie **Aktionen**.
1. Wählen Sie **Dateisystem löschen**.
**Löschen Sie die AD.**
1. Öffnen Sie die [Directory Service -Konsole](https://console.aws.amazon.com//directoryservicev2/).
1. Wählen Sie das Optionsfeld links neben dem gerade erstellten AD.
1. Wählen Sie **Aktionen**.
1. Wählen Sie **Löschen eines Verzeichnisses** aus.
**Löschen Sie den Cluster.**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Clusters** und anschließend aus **windows-fsx-cluster**.
1. Wählen Sie **Delete cluster (Cluster löschen)** aus.
1. Geben Sie die Phrase ein und wählen Sie dann **Löschen**.
**Beenden Sie die EC2-Instance.**
1. Öffnen Sie die [Amazon EC2-Konsole](https://console.aws.amazon.com//ec2/).
1. Wählen Sie im linken Menü die Option **Instances** aus.
1. Markieren Sie das Kästchen links neben der EC2-Instance, die Sie erstellt haben.
1. Klicken Sie auf **Instance-Zustand**, **Beenden der Instance**.
**Löschen Sie das Secret.**
1. Öffnen Sie die [Secrets Manager-Konsole](https://console.aws.amazon.com//secretsmanager/).
1. Wählen Sie das Secret aus, das Sie für diesen Walkthrough erstellt haben.
1. Klicken Sie auf **Aktionen**.
1. Wählen Sie **Secret löschen** aus.
# Docker-Volumes mit Amazon ECS verwenden
Bei der Verwendung von Docker-Volumes kann der integrierte `local`-Treiber oder ein Drittanbieter-Volume-Treiber verwendet werden. Docker-Volumes werden von Docker verwaltet und es wird ein Verzeichnis in `/var/lib/docker/volumes` auf der Container-Instance erstellt, die die Volume-Daten enthält.
Um Docker-Volumes zu verwenden, geben Sie eine `dockerVolumeConfiguration` in Ihrer Aufgabendefinition an. Weitere Informationen finden Sie unter [Volumes](https://docs.docker.com/engine/storage/volumes/) in der Docker-Dokumentation.
Einige häufige Anwendungsfälle für Docker-Volumes sind folgende:
+ Das Bereitstellen von persistenten Daten-Volumes für die Nutzung mit Containern
+ Die gemeinsame Verwendung eines definierten Daten-Volumes an unterschiedlichen Orten auf verschiedenen Containern auf derselben Container-Instance
+ Das Definieren eines leeren, nicht persistenten Daten-Volumes und dessen Mounten auf mehreren Containern innerhalb der gleichen Aufgabe
+ Um Ihrer Aufgabe ein Datenvolumen zur Verfügung zu stellen, das von einem Drittanbietertreiber verwaltet wird
## Überlegungen zur Verwendung von Docker-Volumes
Bei der Verwendung von Docker-Volumes sollte Folgendes berücksichtigt werden:
+ Docker-Volumes werden nur unterstützt, wenn der EC2-Launchtyp oder externe Instances verwendet werden.
+ Windows-Container unterstützen nur die Verwendung des `local`-Treibers.
+ Wenn ein Drittanbieter-Treiber verwendet wird, stellen Sie sicher, dass dieser installiert und auf der Container-Instance aktiv ist, bevor der Container-Agent gestartet wird. Wenn der Drittanbieter-Treiber nicht aktiv ist, bevor Sie den Agenten starten, können Sie den Container-Agenten neu starten, indem Sie einen der folgenden Befehle verwenden:
+ Für das Amazon-ECS-optimierte Amazon Linux 2-AMI:
```
sudo systemctl restart ecs
```
+ Für das Amazon-ECS-optimierte Amazon Linux AMI:
```
sudo stop ecs && sudo start ecs
```
Informationen zur Angabe eines Docker-Volumes in einer Aufgabendefinition finden Sie unter [Ein Docker-Volume in einer Amazon-ECS-Aufgabendefinition angeben](specify-volume-config.md).
# Ein Docker-Volume in einer Amazon-ECS-Aufgabendefinition angeben
Bevor Ihre Container Daten-Volumes verwenden können, müssen Sie das Volume und die Konfigurationen der Mounting-Punkte in Ihrer Aufgabendefinition angeben. Dieser Abschnitt beschreibt die Volume-Konfiguration für einen Container. Für Aufgaben, die ein Docker-Volume verwenden, geben Sie eine `dockerVolumeConfiguration` an. Für Aufgaben, die ein Bind-Mount-Host-Volume verwenden, geben Sie einen `host` und optionalen `sourcePath` an.
Das folgende JSON-Codefragment der Aufgabendefinition zeigt die Syntax für die Objekte `volumes` und `mountPoints` für einen Container.
```
{
"containerDefinitions": [
{
"mountPoints": [
{
"sourceVolume": "string",
"containerPath": "/path/to/mount_volume",
"readOnly": boolean
}
]
}
],
"volumes": [
{
"name": "string",
"dockerVolumeConfiguration": {
"scope": "string",
"autoprovision": boolean,
"driver": "string",
"driverOpts": {
"key": "value"
},
"labels": {
"key": "value"
}
}
}
]
}
```
`name`
Typ: Zeichenfolge
Erforderlich: Nein
Der Name des Volumes. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche (`-`) und Unterstriche (`_`) sind erlaubt. Auf diesen Namen wird im Parameter `sourceVolume` des `mountPoints`-Objekts der Container-Definition verwiesen.
`dockerVolumeConfiguration`
Typ: [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html)Objekt
Erforderlich: Nein
Dieser Parameter wird nur bei der Verwendung von Docker-Volumes angegeben. Docker-Volumes werden nur unterstützt, wenn Aufgaben auf EC2-Instances ausgeführt werden. Windows-Container unterstützen nur die Verwendung des `local`-Treibers. Um Bind-Mounts zu verwenden, geben Sie stattdessen einen `host` an.
`scope`
Typ: Zeichenfolge
Zulässige Werte: `task` \$1 `shared`
Erforderlich: Nein
Der Bereich für das Docker-Volume, der den Lebenszyklus bestimmt. Docker-Volumes, die auf eine `task` beschränkt sind, werden automatisch beim Starten der Aufgabe bereitgestellt und beim Stoppen dieser vernichtet. Docker-Volumes, die als `shared` angewendet werden, bleiben erhalten, nachdem die Aufgabe gestoppt wird.
`autoprovision`
Typ: Boolescher Wert
Standardwert: `false`
Erforderlich: Nein
Wenn dieser Wert `true` lautet, wird das Docker-Volume erstellt, wenn es nicht bereits vorhanden ist. Dieses Feld wird nur verwendet, wenn `scope` den Wert `shared` aufweist. Wenn `scope`-Wert `task` ist, muss dieser Parameter weggelassen werden.
`driver`
Typ: Zeichenfolge
Erforderlich: Nein
Der zu verwendende Docker-Volume-Treiber. Der Treiberwert muss mit dem von Docker bereitgestellten Treibernamen übereinstimmen, da dieser Name für die Aufgabenplatzierung verwendet wird. Wenn der Treiber mit der Docker-Plug-In-CLI installiert wurde, rufen Sie mit `docker plugin ls` den Treibernamen aus der Container-Instance ab. Wenn der Treiber mit einem anderen Verfahren installiert wurde, rufen Sie den Treibernamen mit der Docker-Plug-In-Erkennung ab.
`driverOpts`
Typ: Zeichenfolge
Erforderlich: Nein
Eine Zuordnung von Docker-Treiber-spezifischen Optionen für die Übergabe. Dieser Parameter ist im Bereich Ein Volume erstellen von Docker der Option `DriverOpts` zugeordnet.
`labels`
Typ: Zeichenfolge
Erforderlich: Nein
Benutzerdefinierte Metadaten, die Ihrem Docker-Volume hinzugefügt werden sollen.
`mountPoints`
Typ: Objekt-Array
Erforderlich: Nein
Die Mounting-Punkte für die Daten-Volumes in Ihrem Container. Dieser Parameter ist in der create-container-Docker-API der Option `Volumes` zugeordnet und die Option `--volume` ist der Docker-Ausführung zugeordnet.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden. Windows-Container können keine Verzeichnisse auf einem anderen Laufwerk mounten, und es ist kein laufwerksübergreifender Mounting-Punkt möglich. Sie müssen Mounting-Punkte angeben, um ein Amazon-EBS-Volume direkt an eine Amazon-ECS-Aufgabe anzuhängen.
`sourceVolume`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Name des einzubindenden Volumes.
`containerPath`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Pfad in dem Container, in dem das Volume eingebunden wird.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
Behalten Sie für Aufgaben, die auf EC2-Instances unter dem Windows-Betriebssystem ausgeführt werden, den Standardwert von `false` bei.
# Besipiel-Docker-Volumes für Amazon ECS
Die folgenden Beispiele zeigen, wie kurzlebigen Speicher für einen Container und ein gemeinsam genutztes Volume für mehrere Container bereitgestellt wird und wie persistenter NFS-Speicher für einen Container bereitgestellt wird.
**So stellen Sie flüchtigen Speicher für einen Container mit einem Docker-Volume bereit**
In diesem Beispiel verwendet ein Container ein leeres Daten-Volume, das nach Beendigung der Aufgabe entsorgt wird. Ein Beispielanwendungsfall ist, dass Sie z. B. einen Container besitzen, der während einer Aufgabe auf irgendeinen Scratch-Dateispeicherort zugreifen muss. Diese Aufgabe kann mit einem Docker-Volume gelöst werden.
1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Daten-Volume mit `name`- und `DockerVolumeConfiguration`-Werten. In diesem Beispiel geben wir den Umfang als `task` an, sodass das Volume gelöscht wird, nachdem die Aufgabe angehalten wurde. Zudem wird der `local`-Treiber verwendet.
```
"volumes": [
{
"name": "scratch",
"dockerVolumeConfiguration" : {
"scope": "task",
"driver": "local",
"labels": {
"scratch": "space"
}
}
}
]
```
1. Definieren Sie im Abschnitt `containerDefinitions` einen Container mit `mountPoints`-Werten, die auf den Namen des definierten Volumes und den Wert `containerPath` verweisen, um das Volume auf den Container zu mounten.
```
"containerDefinitions": [
{
"name": "container-1",
"mountPoints": [
{
"sourceVolume": "scratch",
"containerPath": "/var/scratch"
}
]
}
]
```
**So stellen Sie persistenten Speicher für mehrere Container mit einem Docker-Volume bereit**
In diesem Beispiel möchten Sie, dass ein freigegebenes Volume für mehrere Container verwendet werden soll und es soll bestehen bleiben, nachdem jede einzelne Aufgabe gestoppt wurde, die es verwendet. Der integrierte `local`-Treiber wird verwendet, damit das Volume weiterhin mit dem Lebenszyklus der Container-Instance verknüpft ist.
1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Daten-Volume mit `name`- und `DockerVolumeConfiguration`-Werten. In diesem Beispiel geben Sie einen `shared`-Geltungsbereich an, damit das Volume bestehen bleibt. Legen Sie die automatische Bereitstellung auf `true` fest, damit das Volume zur Verwendung erstellt wird. Verwenden Sie dann auch den integrierten `local`-Treiber.
```
"volumes": [
{
"name": "database",
"dockerVolumeConfiguration" : {
"scope": "shared",
"autoprovision": true,
"driver": "local",
"labels": {
"database": "database_name"
}
}
}
]
```
1. Definieren Sie im Abschnitt `containerDefinitions` einen Container mit `mountPoints`-Werten, die auf den Namen des definierten Volumes und den Wert `containerPath` verweisen, um das Volume auf den Container zu mounten.
```
"containerDefinitions": [
{
"name": "container-1",
"mountPoints": [
{
"sourceVolume": "database",
"containerPath": "/var/database"
}
]
},
{
"name": "container-2",
"mountPoints": [
{
"sourceVolume": "database",
"containerPath": "/var/database"
}
]
}
]
```
**So stellen Sie NFS-persistenten Speicher für einen Container mit einem Docker-Volume bereit**
In diesem Beispiel verwendet ein Container ein NFS-Daten-Volume, das beim Start der Aufgabe automatisch gemountet und beim Beenden der Aufgabe automatisch getrennt wird. Dies verwendet den in Docker integrierten `local`-Treiber. Ein Beispiel für einen Anwendungsfall ist, dass Sie möglicherweise über einen lokalen NFS-Speicher verfügen und von einer ECS-Anywhere-Aufgabe aus darauf zugreifen müssen. Dies kann mit einem Docker-Volume mit NFS-Treiberoption erreicht werden.
1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Daten-Volume mit `name`- und `DockerVolumeConfiguration`-Werten. Geben Sie in diesem Beispiel einen `task`-Bereich an, damit das Volume nach Beendigung der Aufgabe getrennt wird. Verwenden Sie den `local`-Treiber und konfigurieren Sie `driverOpts` mit den `type`-, `device`-, and `o`-Optionen entsprechend. Ersetzen Sie `NFS_SERVER` durch den NFS-Serverendpunkt.
```
"volumes": [
{
"name": "NFS",
"dockerVolumeConfiguration" : {
"scope": "task",
"driver": "local",
"driverOpts": {
"type": "nfs",
"device": "$NFS_SERVER:/mnt/nfs",
"o": "addr=$NFS_SERVER"
}
}
}
]
```
1. Definieren Sie im `containerDefinitions`-Abschnitt einen Container mit `mountPoints`-Werten, die auf den Namen des definierten Volumes und den `containerPath`-Wert verweisen, um das Volume im Container bereitzustellen.
```
"containerDefinitions": [
{
"name": "container-1",
"mountPoints": [
{
"sourceVolume": "NFS",
"containerPath": "/var/nfsmount"
}
]
}
]
```
# Bind-Mounts mit Amazon ECS verwenden
Bei Bind-Mounts wird eine Datei oder ein Verzeichnis auf einem Host wie einer Amazon-EC2-Instance in einem Container gemountet. Bind-Mounts werden für Aufgaben unterstützt, die auf Fargate und Amazon-EC2-Instances gehostet werden. Bind-Mounts sind an den Lebenszyklus des Containers gebunden, in dem sie verwendet werden. Nachdem alle Container, die ein Bind-Mount verwenden, gestoppt wurden, z. B. wenn eine Aufgabe gestoppt wird, werden die Daten entfernt. Bei Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können die Daten an den Lebenszyklus der Host-Amazon-EC2-Instance gebunden werden, indem ein `host` und optional ein `sourcePath`-Wert in der Aufgabendefinition festgelegt werden. Weitere Informationen finden Sie unter [Bind-Mounts](https://docs.docker.com/engine/storage/bind-mounts/) in der Docker-Dokumentation.
Die folgenden Szenarien sind gängige Anwendungsfälle für Bind-Mounts.
+ So stellen Sie ein leeres Daten-Volume bereit, das in einem oder mehreren Containern bereitgestellt werden soll.
+ So stellen Sie ein Host-Daten-Volume in einem oder mehreren Containern bereit.
+ So geben Sie ein Daten-Volume aus einem Quell-Container für andere Container in derselben Aufgabe frei.
+ Um einen Pfad und seinen Inhalt aus einer Dockerdatei für einen oder mehrere Container verfügbar zu machen.
## Überlegungen zur Verwendung von Bind-Mounts
Bei der Verwendung von Bind-Mounts sollte Folgendes berücksichtigt werden.
+ Standardmäßig erhalten Aufgaben, die auf der AWS Fargate Plattformversion `1.4.0` oder höher (Linux) `1.0.0` oder höher (Windows) gehostet werden, mindestens 20 GiB flüchtigen Speicher für Bind-Mounts. Sie können die Gesamtmenge des flüchtigen Speichers bis zu einem Maximum von 200 GiB erhöhen, indem Sie den `ephemeralStorage`-Parameter in Ihrer Aufgabendefinition angeben.
+ Um Dateien aus einer Docker-Datei auf einem Daten-Volume verfügbar zu machen, wenn eine Aufgabe ausgeführt wird, sucht die Amazon-ECS-Datenebene nach einer `VOLUME`-Richtlinie. Wenn der absolute Pfad, der in der `VOLUME`-Richtlinie angegeben ist der gleiche wie `containerPath` ist, die in der Aufgabendefinition angegeben sind, werden die Daten im `VOLUME`-Richtlinienpfad auf das Daten-Volume kopiert. Im folgenden Dockerfile-Beispiel wird eine Datei mit dem Namen `examplefile` im `/var/log/exported`-Verzeichnis auf den Host geschrieben und dann innerhalb des Containers gemountet.
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN mkdir -p /var/log/exported
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
Standardmäßig sind die Volume-Berechtigungen auf `0755` und der Besitzer als `root` festgelegt. Sie können diese Berechtigungen in der Dockerfile anpassen. Das folgende Beispiel definiert den Eigentümer des Verzeichnisses als `node`.
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN yum install -y shadow-utils && yum clean all
RUN useradd node
RUN mkdir -p /var/log/exported && chown node:node /var/log/exported
RUN touch /var/log/exported/examplefile
USER node
VOLUME ["/var/log/exported"]
```
+ Bei Aufgaben, die auf Amazon-EC2-Instances gehostet werden, wenn ein `host`- und `sourcePath`-Wert nicht angegeben ist, verwaltet der Docker-Daemon das Bind-Mount für Sie. Wenn keine Container auf dieses Bind-Mount verweisen, löscht der Aufgabenbereinigungsservice des Amazon-ECS-Container-Agenten es letztendlich. Standardmäßig geschieht dies drei Stunden nach dem Stoppen des Containers. Die Zeitspanne kann aber mit der Agenten-Variable `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` konfiguriert werden. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md). Wenn Sie diese Daten länger als den Lebenszyklus des Containers beibehalten möchten, geben Sie für den Bind-Mount einen `sourcePath`-Wert an.
+ Bei Aufgaben, die auf Amazon ECS Managed Instances gehostet werden, sind Teile des Root-Dateisystems schreibgeschützt. Read/write Bind-Mounts müssen beschreibbare Verzeichnisse verwenden, z. B. `/var` für persistente Daten oder für temporäre Daten. `/tmp` Der Versuch, read/write Bind-Mounts für andere Verzeichnisse zu erstellen, führt dazu, dass die Aufgabe nicht gestartet werden kann und ein Fehler ähnlich dem folgenden angezeigt wird:
```
error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system
```
Schreibgeschützte Bind-Mounts (mit `"readOnly": true` im `mountPoints` Parameter konfiguriert) können auf jedes beliebige Verzeichnis auf dem Host verweisen, auf das zugegriffen werden kann.
Um eine vollständige Liste der beschreibbaren Pfade anzuzeigen, können Sie eine Aufgabe auf einer Amazon ECS Managed Instance ausführen und damit die Mount-Tabelle der Instance überprüfen. Erstellen Sie eine Aufgabendefinition mit den folgenden Einstellungen, um auf das Host-Dateisystem zuzugreifen:
```
{
"pidMode": "host",
"containerDefinitions": [{
"privileged": true,
...
}]
}
```
Führen Sie dann die folgenden Befehle innerhalb des Containers aus:
```
# List writable mounts
cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^rw,/ || $4 == "rw" {print $2}' | sort
# List read-only mounts
cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^ro,/ || $4 == "ro" {print $2}' | sort
```
**Wichtig**
Die `privileged` Einstellung gewährt dem Container erweiterte Funktionen auf dem Host, was dem Root-Zugriff entspricht. In diesem Beispiel wird sie verwendet, um die Mount-Tabelle des Hosts zu Diagnosezwecken zu überprüfen. Weitere Informationen finden Sie unter [Vermeiden, Container als privilegiert auszuführen (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers).
Weitere Hinweise zur interaktiven Ausführung von Befehlen in Containern finden Sie unter[Überwachen von Amazon-ECS-Containern mit ECS Exec](ecs-exec.md).
# Ein Bind-Mount in einer Amazon-ECS-Aufgabendefinition angeben
Für Amazon-ECS-Aufgaben, die entweder in Fargate oder auf Amazon-EC2-Instances gehostet sind, zeigt der folgende JSON-Ausschnitt einer Aufgabendefinition die Syntax für die `volumes`-, `mountPoints`-, und `ephemeralStorage`-Objekte für eine Aufgabendefinition.
```
{
"family": "",
...
"containerDefinitions" : [
{
"mountPoints" : [
{
"containerPath" : "/path/to/mount_volume",
"sourceVolume" : "string"
}
],
"name" : "string"
}
],
...
"volumes" : [
{
"name" : "string"
}
],
"ephemeralStorage": {
"sizeInGiB": integer
}
}
```
Für Amazon-ECS-Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können Sie den optionalen `host`-Parameter und `sourcePath` nutzen, wenn Sie die Details des Aufgaben-Volumes angeben. Sind diese angegeben, wird das Bind-Mount an den Lebenszyklus der Aufgabe und nicht an den Container gebunden.
```
"volumes" : [
{
"host" : {
"sourcePath" : "string"
},
"name" : "string"
}
]
```
Im Folgenden finden Sie weitere detaillierte Beschreibungen der einzelnen Aufgabendefinitionsparameter.
`name`
Typ: Zeichenfolge
Erforderlich: Nein
Der Name des Volumes. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche (`-`) und Unterstriche (`_`) sind erlaubt. Auf diesen Namen wird im Parameter `sourceVolume` des `mountPoints`-Objekts der Container-Definition verwiesen.
`host`
Erforderlich: Nein
Der `host`-Parameter wird verwendet, um den Lebenszyklus des Bind-Mounts an die Amazon-EC2-Host-Instance und nicht an die Aufgabe zu binden und dort zu speichern. Wenn der Parameter `host` leer ist, weist der Docker-Daemon einen Host-Pfad für Ihr Daten-Volume zu, es wird aber nicht gewährleistet, dass die Daten beibehalten werden, nachdem die damit verknüpften Container nicht mehr ausgeführt werden.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden.
Der `sourcePath` Parameter wird nur unterstützt, wenn Aufgaben verwendet werden, die auf Amazon EC2-Instances oder Amazon ECS Managed Instances gehostet werden.
`sourcePath`
Typ: Zeichenfolge
Erforderlich: Nein
Wenn der Parameter `host` verwendet wird, geben Sie einen `sourcePath` an, um den Pfad auf der Amazon-EC2-Host-Instance zu deklarieren, die dem Container bereitgestellt wird. Wenn dieser Parameter leer ist, weist der Docker-Daemon einen Host-Pfad für Sie zu. Wenn der Parameter `host` den Speicherort `sourcePath` enthält, bleibt das Daten-Volume an der angegebenen Position der Amazon-EC2-Host-Instance erhalten, bis Sie es manuell löschen. Wenn der Wert `sourcePath` auf der Amazon-EC2-Host-Instance nicht vorhanden ist, wird er vom Docker-Daemon erstellt. Wenn der Speicherort nicht vorhanden ist, wird der Inhalt des Quellpfadordners exportiert.
`mountPoints`
Typ: Objekt-Array
Erforderlich: Nein
Die Mounting-Punkte für die Daten-Volumes in Ihrem Container. Dieser Parameter ist in der create-container-Docker-API der Option `Volumes` zugeordnet und die Option `--volume` ist der Docker-Ausführung zugeordnet.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden. Windows-Container können keine Verzeichnisse auf einem anderen Laufwerk mounten, und es ist kein laufwerksübergreifender Mounting-Punkt möglich. Sie müssen Mounting-Punkte angeben, um ein Amazon-EBS-Volume direkt an eine Amazon-ECS-Aufgabe anzuhängen.
`sourceVolume`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Name des einzubindenden Volumes.
`containerPath`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Pfad in dem Container, in dem das Volume eingebunden wird.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
Behalten Sie für Aufgaben, die auf EC2-Instances unter dem Windows-Betriebssystem ausgeführt werden, den Standardwert von `false` bei.
`ephemeralStorage`
Typ: Objekt
Erforderlich: Nein
Die Menge des flüchtigen Speichers, der für die Aufgabe zugewiesen werden soll. Dieser Parameter wird verwendet, um die Gesamtmenge an verfügbarem temporärem Speicher für Aufgaben, die auf der AWS Fargate verwendeten Plattformversion `1.4.0` oder höher (Linux) `1.0.0` oder höher (Windows) gehostet werden, über die Standardmenge hinaus zu erweitern.
Sie können die Copilot-CLI, das AWS SDK oder die CLI verwenden CloudFormation, um kurzlebigen Speicher für einen Bind-Mount anzugeben.
# Beispiele für Bind-Mounts für Amazon ECS
In den folgenden Beispielen werden häufige Anwendungsfälle für die Verwendung eines Bind-Mounts für Ihre Container behandelt.
**So weisen Sie einer Fargate-Aufgabe einen erhöhten flüchtigen Speicher zu**
Für Amazon-ECS-Aufgaben, die auf Fargate mit Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` (Windows) gehostet werden können Sie mehr als die Standardmenge des flüchtigen Speichers für die zu verwendenden Container in Ihrer Aufgabe zuweisen. Dieses Beispiel kann in die anderen Beispiele integriert werden, um flüchtigen Speicher für Ihre Fargate-Aufgaben zuzuweisen.
+ Definieren Sie in der Aufgabendefinition ein `ephemeralStorage`-Objekt. `sizeInGiB` muss eine Ganzzahl zwischen den Werten von `21` und `200` sein und wird in GiB ausgedrückt.
```
"ephemeralStorage": {
"sizeInGiB": integer
}
```
**So stellen Sie ein leeres Daten-Volume für einen oder mehrere Container bereit**
In einigen Fällen möchten Sie den Containern in einer Aufgabe einen Scratchspace bereitstellen. Möglicherweise besitzen Sie z. B. zwei Datenbank-Container, die während einer Aufgabe auf denselben Scratch-Dateispeicherort zugreifen müssen. Dies kann mit einem Bind-Mount erreicht werden.
1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Bind-Mount mit dem Namen `database_scratch`.
```
"volumes": [
{
"name": "database_scratch"
}
]
```
1. Erstellen Sie im Abschnitt `containerDefinitions` die Datenbank-Containerdefinitionen, damit sie das Volume mounten.
```
"containerDefinitions": [
{
"name": "database1",
"image": "my-repo/database",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "database_scratch",
"containerPath": "/var/scratch"
}
]
},
{
"name": "database2",
"image": "my-repo/database",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "database_scratch",
"containerPath": "/var/scratch"
}
]
}
]
```
**So stellen Sie einen Pfad und seinen Inhalt in einer Dockerdatei einem Container zur Verfügung**
In diesem Beispiel haben Sie eine Dockerdatei, die Daten schreibt, die Sie in einem Container mounten möchten. Dieses Beispiel funktioniert für Aufgaben, die auf Fargate oder Amazon-EC2-Instances gehostet werden.
1. Erstellen Sie eine Docker-Datei. Im folgenden Beispiel wird das öffentliche Amazon Linux 2-Container-Image verwendet und eine Datei mit dem Namen `examplefile` im `/var/log/exported`-Verzeichnis, das wir innerhalb des Containers einhängen möchten. Die `VOLUME`-Direktive sollte einen absoluten Pfad angeben.
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN mkdir -p /var/log/exported
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
Standardmäßig sind die Volume-Berechtigungen auf `0755` und der Besitzer als `root` festgelegt. Diese Berechtigungen können in der Dockerdatei geändert werden. Im folgenden Beispiel wird der Besitzer des `/var/log/exported`-Verzeichnis auf `node` festgelegt.
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN yum install -y shadow-utils && yum clean all
RUN useradd node
RUN mkdir -p /var/log/exported && chown node:node /var/log/exported
USER node
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Volume mit dem Namen `application_logs`.
```
"volumes": [
{
"name": "application_logs"
}
]
```
1. Erstellen Sie im Abschnitt `containerDefinitions` die Containerdefinitionen der Anwendung, damit sie den Speicher mounten. Der `containerPath`-Wert muss mit dem absoluten Pfad übereinstimmen, der in der `VOLUME`-Richtlinie aus der Dockerfile angegeben ist.
```
"containerDefinitions": [
{
"name": "application1",
"image": "my-repo/application",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "application_logs",
"containerPath": "/var/log/exported"
}
]
},
{
"name": "application2",
"image": "my-repo/application",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "application_logs",
"containerPath": "/var/log/exported"
}
]
}
]
```
**So stellen Sie ein leeres Daten-Volume für einen Container bereit, der mit dem Lebenszyklus der Host-Amazon-EC2-Instance verknüpft ist**
Bei Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können Sie Bind-Mounts verwenden und die Daten an den Lebenszyklus der Host-Amazon-EC2-Instance binden. Das geschieht mithilfe des `host`-Parameters und durch Angeben eines `sourcePath`-Werts. Alle Dateien, die im `sourcePath` vorhanden sind, werden den Containern im `containerPath`-Wert angezeigt. Alle Dateien, die in den `containerPath`-Wert geschrieben werden, werden in den `sourcePath`-Wert auf der Host-Amazon-EC2-Instance geschrieben.
**Wichtig**
Amazon ECS synchronisiert Ihren Speicher nicht über Amazon-EC2-Instances hinweg. Aufgaben, die persistenten Speicher nutzen, können auf eine beliebige Amazon-EC2-Instance in Ihrem Cluster mit verfügbarer Kapazität platziert werden. Wenn Ihre Aufgaben nach dem Stoppen und Neustarten persistenten Speicher benötigen, geben Sie beim Start der Aufgabe immer dieselbe Amazon EC2 EC2-Instance mit dem Befehl AWS CLI [start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) an. Sie können Amazon EFS Volumes auch für persistenten Speicher verwenden. Weitere Informationen finden Sie unter [Amazon-EFS-Volumes mit Amazon ECS verwenden](efs-volumes.md).
1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Bind-Mount mit `name`- und `sourcePath`-Werten. Im folgenden Beispiel enthält die Host-Amazon-EC2-Instance Daten unter`/ecs/webdata`, die Sie im Container montieren möchten.
```
"volumes": [
{
"name": "webdata",
"host": {
"sourcePath": "/ecs/webdata"
}
}
]
```
1. Definieren Sie im Abschnitt `containerDefinitions` einen Container mit einem `mountPoints`-Wert, der auf den Namen des definierten Bind-Mounts verweist, und mit dem `containerPath`-Wert, auf dem das Bind-Mount auf dem Container gemountet werden soll.
```
"containerDefinitions": [
{
"name": "web",
"image": "public.ecr.aws/docker/library/nginx:latest",
"cpu": 99,
"memory": 100,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"essential": true,
"mountPoints": [
{
"sourceVolume": "webdata",
"containerPath": "/usr/share/nginx/html"
}
]
}
]
```
**So mounten Sie ein definiertes Volume auf mehreren Containern an verschiedenen Standorten**
Sie können ein Daten-Volume in einer Aufgabendefinition definieren und das Volume an verschiedenen Speicherorten auf verschiedenen Containern mounten. Angenommen, Ihr Host-Container besitzt einen Website-Datenordner in `/data/webroot`. Möglicherweise möchten Sie dieses Daten-Volume schreibgeschützt auf zwei verschiedenen Web-Servern mounten, die über verschiedene Basis-Verzeichnisse verfügen.
1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Daten-Volume mit dem Namen `webroot` und dem Quellpfad `/data/webroot`.
```
"volumes": [
{
"name": "webroot",
"host": {
"sourcePath": "/data/webroot"
}
}
]
```
1. Definieren Sie im Abschnitt `containerDefinitions` für jeden Webserver einen Container mit `mountPoints`-Werten, die das `webroot`-Volume dem `containerPath`-Wert zuordnen, der auf das Basisverzeichnis des betreffenden Containers verweist.
```
"containerDefinitions": [
{
"name": "web-server-1",
"image": "my-repo/ubuntu-apache",
"cpu": 100,
"memory": 100,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"essential": true,
"mountPoints": [
{
"sourceVolume": "webroot",
"containerPath": "/var/www/html",
"readOnly": true
}
]
},
{
"name": "web-server-2",
"image": "my-repo/sles11-apache",
"cpu": 100,
"memory": 100,
"portMappings": [
{
"containerPort": 8080,
"hostPort": 8080
}
],
"essential": true,
"mountPoints": [
{
"sourceVolume": "webroot",
"containerPath": "/srv/www/htdocs",
"readOnly": true
}
]
}
]
```
**So mounten Sie mit `volumesFrom` Volumes aus einem anderen Container**
Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können Sie ein oder mehrere Volumes in einem Container definieren und dann den `volumesFrom`-Parameter in einer anderen Containerdefinition innerhalb derselben Aufgabe verwenden, um einer Mounting für alle Volumes von `sourceContainer` an ihrem ursprünglich definierten Mounting-Punkt herzustellen. Der Parameter `volumesFrom` gilt für alle Volumes, die in der Aufgabendefinition definiert sind, und für solche Volumes, die im Image mit einer Dockerfile integriert sind.
1. (Optional) Um ein Volume freizugeben, das in ein Image integriert ist, verwenden Sie die `VOLUME`-Anweisung in der Dockerfile. Im folgenden Beispiel verwendet die Dockerfile ein `httpd`-Image, fügt ein Volume hinzu und mountet es unter `dockerfile_volume` im Stammverzeichnis von Apache. Es ist der Ordner, der vom `httpd`-Webserver verwendet wird.
```
FROM httpd
VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"]
```
Sie können ein Image mit dieser Dockerfile erstellen und direkt in ein Repository, wie z. B. den Docker-Hub, übertragen und in Ihrer Aufgabendefinition verwenden. Das in den folgenden Schritten verwendete `my-repo/httpd_dockerfile_volume`-Beispiel-Image wurde mit der oben genannten Dockerfile erstellt.
1. Erstellen Sie eine Aufgabendefinition, die Ihre Volumes und Mounting-Punkte für die Container definiert. In diesem `volumes`-Beispielabschnitt erstellen Sie ein leeres Volume namens `empty`, das vom Docker-Daemon verwaltet wird. Auch ein Host-Volume namens `host_etc` ist definiert. Es exportiert den `/etc`-Ordner auf der Host-Container-Instance.
```
{
"family": "test-volumes-from",
"volumes": [
{
"name": "empty",
"host": {}
},
{
"name": "host_etc",
"host": {
"sourcePath": "/etc"
}
}
],
```
Erstellen Sie im Abschnitt der Containerdefinitionen einen Container, der die zuvor definierten Volumes mountet. In diesem Beispiel mountet der `web`-Container die Volumes `empty` und `host_etc`. Dies ist der Container, der das mit einem Volume in der Dockerfile erstellte Image verwendet.
```
"containerDefinitions": [
{
"name": "web",
"image": "my-repo/httpd_dockerfile_volume",
"cpu": 100,
"memory": 500,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"mountPoints": [
{
"sourceVolume": "empty",
"containerPath": "/usr/local/apache2/htdocs/empty_volume"
},
{
"sourceVolume": "host_etc",
"containerPath": "/usr/local/apache2/htdocs/host_etc"
}
],
"essential": true
},
```
Erstellen Sie einen anderen Container, der mit `volumesFrom` alle Volumes mountet, die dem Container `web` zugeordnet sind. Alle Volumes im `web`-Container werden ebenfalls im `busybox`-Container gemountet. Das schließt das in der Dockerfile angegebene Volume ein, das zum Erstellen des `my-repo/httpd_dockerfile_volume`-Images verwendet wurde.
```
{
"name": "busybox",
"image": "busybox",
"volumesFrom": [
{
"sourceContainer": "web"
}
],
"cpu": 100,
"memory": 500,
"entryPoint": [
"sh",
"-c"
],
"command": [
"echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date"
],
"essential": false
}
]
}
```
Wenn diese Aufgabe ausgeführt wird, mounten die beiden Container die Volumes, und der `command` im `busybox`-Container schreibt das Datum und die Uhrzeit in eine Datei. Diese Datei heißt `date` in jedem der Volume-Ordner. Die Ordner sind dann auf der Website sichtbar, die durch den Container `web` angezeigt wird.
**Anmerkung**
Da der `busybox`-Container einen Kurzbefehl ausführt und dann beendet wird, muss er in der Containerdefinition auf `"essential": false` gesetzt werden. Andernfalls wird die gesamte Aufgabe gestoppt, wenn er beendet wird.
# Verwaltung des Container-Auslagerungsspeicherplatzes in Amazon ECS
Mit Amazon ECS können Sie die Nutzung des Auslagerungsspeicherplatzes auf Ihren Linux-basierten Amazon-EC2-Instances auf Containerebene steuern. Bei der Verwendung einer Auslagerungskonfiguration pro Container kann die Auslagerung für jeden Container innerhalb einer Aufgabendefinition aktiviert oder deaktiviert sein. Für diejenigen, für die sie aktiviert ist, kann die maximale Menge des verwendeten Auslagerungsbereichs begrenzt sein. Beispielsweise kann die Auslagerung bei latenzkritischen Containern deaktiviert sein. Im Gegensatz dazu kann bei Containern mit hohem transienten Speicherbedarf Swap aktiviert sein, um die Wahrscheinlichkeit von out-of-memory Fehlern zu verringern, wenn der Container ausgelastet ist.
Die Auslagerungskonfiguration für einen Container wird mit den folgenden Container-Definitionsparametern verwaltet.
`maxSwap`
Die Gesamtmenge des Auslagerungsspeichers (in MiB), den ein Container verwenden kann. Dieser Parameter ist in die Option `--memory-swap` zur Docker-Ausführung übersetzt, wobei der Wert die Summe aus dem Container-Speicher und dem Wert `maxSwap` ist.
Wenn als `maxSwap`-Wert `0` angegeben wird, verwendet der Container keine Auslagerung. Zulässige Werte sind `0` oder eine beliebige positive Ganzzahl. Wenn der Parameter `maxSwap` weggelassen wird, verwendet der Container die Swap-Konfiguration für die Container-Instance, auf der er ausgeführt wird. Es muss ein Wert für `maxSwap` festgelegt werden, damit der Parameter `swappiness` verwendet werden kann.
`swappiness`
Auf diese Weise können Sie das Speicherauslagerungsverhalten eines Containers optimieren. Ein `swappiness`-Wert von `0` führt dazu, dass keine Auslagerung stattfindet, es sei denn, dies ist absolut notwendig. Ein `swappiness`-Wert von `100` führt dazu, dass Seiten aggressiv ausgelagert werden. Akzeptierte Werte sind Ganzzahlen zwischen `0` und `100`. Wenn der Parameter `swappiness` nicht angegeben wird, wird der Standardwert `60` verwendet. Wenn kein Wert für `maxSwap` angegeben ist, wird dieser Parameter ignoriert. Dieser Parameter ist der Option `--memory-swappiness` für die Docker-Ausführung zugeordnet.
Im folgenden Beispiel wird die JSON-Syntax bereitgestellt.
```
"containerDefinitions": [{
...
"linuxParameters": {
"maxSwap": integer,
"swappiness": integer
},
...
}]
```
## Überlegungen
Beachten Sie Folgendes, wenn Sie eine Auslagerungskonfiguration pro Container verwenden.
+ Der Auslagerungsbereich muss auf der Amazon-EC2-Instance, die Ihre Aufgaben hostet, aktiviert und zugewiesen werden, damit die Container verwendet werden können. Standardmäßig ist bei Amazon AMIs ECS-Optimierungen Swap nicht aktiviert. Sie müssen die Auslagerung auf der Instance aktivieren, um dieses Feature verwenden zu können. Weitere Informationen finden Sie unter [Instance-Speicher-Swap-Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-swap-volumes.html) im *Amazon-EC2-Benutzerhandbuch* oder [Wie weise ich Arbeitsspeicher als Swap Space in einer Amazon-EC2-Instance zu?](https://repost.aws/knowledge-center/ec2-memory-swap-file).
+ Die Container-Definitionsparameter für den Auslagerungsbereich werden nur für Aufgabendefinitionen unterstützt, die EC2 angeben. Diese Parameter werden nicht für Aufgabendefinitionen unterstützt, die nur für die Verwendung von Amazon ECS auf Fargate bestimmt sind.
+ Dieses Feature wird nur für Linux-Container unterstützt. Windows-Container werden derzeit nicht unterstützt.
+ Wenn die Container-Definitionsparameter `maxSwap` und `swappiness` in einer Aufgabendefinition weggelassen werden, hat jeder Container den `swappiness`-Standardwert `60`. Darüber hinaus ist die gesamte Auslagerungsnutzung auf das Zweifache der Speicherreservierung des Containers begrenzt.
+ Wenn Sie Aufgaben auf Amazon Linux 2023 verwenden, wird der `swappiness`-Parameter nicht unterstützt.
# Unterschiede bei der Amazon-ECS-Aufgabendefinition für Amazon ECS Managed Instances
Um Amazon ECS Managed Instances verwenden zu können, müssen Sie Ihre Aufgabendefinition so konfigurieren, dass sie den Starttyp von Amazon ECS Managed Instances verwendet. Es gibt weitere Überlegungen bei der Verwendung von Amazon ECS Managed Instances.
## Aufgabendefinitionsparameter
Aufgaben, die Amazon ECS Managed Instances verwenden, unterstützen die meisten verfügbaren Parameter für die Amazon-ECS-Aufgabendefinition. Einige Parameter haben jedoch spezifische Verhaltensweisen oder Einschränkungen, wenn sie mit Aufgaben von Amazon ECS Managed Instances verwendet werden.
Die folgenden Aufgabendefinitionsparameter sind in Aufgaben von Amazon ECS Managed Instances nicht gültig:
+ `disableNetworking`
+ `dnsSearchDomains`
+ `dnsServers`
+ `dockerLabels`
+ `dockerSecurityOptions`
+ `dockerVolumeConfiguration`
+ `ephemeralStorage`
+ `extraHosts`
+ `fsxWindowsFileServerVolumeConfiguration`
+ `hostname`
+ `inferenceAccelerator`
+ `ipcMode`
+ `links`
+ `maxSwap`
+ `proxyConfiguration`
+ `sharedMemorySize`
+ `sourcepath`-Volumes
+ `swappiness`
+ `tmpfs`
Die folgenden Aufgabendefinitionsparameter sind in Aufgaben von Amazon ECS Managed Instances gültig, weisen jedoch Einschränkungen auf, die zu beachten sind:
+ `networkConfiguration` – Aufgaben von Amazon ECS Managed Instances verwenden den `awsvpc`- oder `host`-Netzwerkmodus.
+ `placementConstraints` – Die folgenden Beschränkungsattribute werden unterstützt.
+ `ecs.subnet-id`
+ `ecs.availability-zone`
+ `ecs.instance-type`
+ `ecs.cpu-architecture`
+ `requiresCompatibilities` – Muss `MANAGED_INSTANCES` enthalten, um sicherzustellen, dass die Aufgabendefinition mit Amazon ECS Managed Instances kompatibel ist.
+ `resourceRequirement` – `InferenceAccelerator` wird nicht unterstützt.
+ `operatingSystemFamily` – Amazon ECS Managed Instances verwendet `LINUX`.
+ `volumes`— Wenn Sie Bind-Mounts mit a verwenden`sourcePath`, muss der Pfad auf ein beschreibbares Verzeichnis auf dem Host verweisen. Teile des Amazon ECS Managed Instance-Dateisystems sind schreibgeschützt. Zu den beschreibbaren Verzeichnissen gehören und. `/var` `/tmp` Weitere Informationen finden Sie unter [Bind-Mounts mit Amazon ECS verwenden](bind-mounts.md).
Um sicherzustellen, dass die Aufgabendefinition für die Verwendung mit Amazon ECS Managed Instances validiert wird, können Sie beim Registrieren der Aufgabendefinition Folgendes angeben:
+ Geben Sie AWS-Managementkonsole im Feld **Erfordert Kompatibilitäten** an. `MANAGED_INSTANCES`
+ Geben Sie im AWS CLI die `--requires-compatibilities` Option an.
+ Legen Sie in der Amazon ECS API das Flag `requiresCompatibilities` fest.
# 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 '.'
```
# Unterschiede bei der Amazon-ECS-Aufgabendefinition für EC2-Instances, auf denen Windows ausgeführt wird
Aufgaben, die auf EC2-Windows-Instances ausgeführt werden, unterstützen nicht alle verfügbaren Amazon-ECS-Aufgabendefinitionsparameter. Einige Parameter werden überhaupt nicht unterstützt und andere verhalten sich abweichend.
Die folgenden Aufgabendefnitionsparameter werden für Amazon-EC2-Windows-Aufgabendefinitionen nicht unterstützt:
+ `containerDefinitions`
+ `disableNetworking`
+ `dnsServers`
+ `dnsSearchDomains`
+ `extraHosts`
+ `links`
+ `linuxParameters`
+ `privileged`
+ `readonlyRootFilesystem`
+ `user`
+ `ulimits`
+ `volumes`
+ `dockerVolumeConfiguration`
+ `cpu`
Es wird empfohlen, für Windows-Container eine CPU auf Container-Ebene festzulegen.
+ `memory`
Es wird empfohlen, für Windows-Container einen Arbeitsspeicher auf Container-Ebene festzulegen.
+ `proxyConfiguration`
+ `ipcMode`
+ `pidMode`
+ `taskRoleArn`
Die IAM-Rollen für Aufgaben in Features von EC2-Windows-Instances erfordern eine zusätzliche Konfiguration, aber ein Großteil dieser Konfiguration ähnelt der Konfiguration von IAM-Rollen für Aufgaben auf Linux-Container-Instances. Weitere Informationen finden Sie unter [Zusätzliche Konfiguration der Amazon-EC2-Windows-Instances](task-iam-roles.md#windows_task_IAM_roles).
# Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole
Sie erstellen eine Aufgabendefinition, damit Sie die Anwendung definieren können, die Sie als Aufgabe oder Service ausführen.
Wenn Sie eine Aufgabendefinition für den externen Starttyp erstellen, müssen Sie die Aufgabendefinition mit dem JSON-Editor erstellen und den `requireCapabilities`-Parameter auf `EXTERNAL` setzen.
Sie können eine Aufgabendefinition mithilfe der Konsolenoberfläche oder durch Angabe einer JSON-Datei erstellen. Sie können Amazon Q Empfehlungen geben lassen, wenn Sie den JSON-Editor verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon Q Developer zur Bereitstellung von Empfehlungen zur Aufgabendefinition in der Amazon-ECS-Konsole](using-amazon-q.md).
## JSON-Validierung
Der JSON-Editor der Amazon ECS-Konsole validiert Folgendes in der JSON-Datei:
+ Die Datei ist eine gültige JSON-Datei
+ Die Datei enthält keine überflüssigen Schlüssel
+ Die Datei enthält den `familyName`-Parameter
+ Unter `containerDefinitions` ist mindestens ein Eintrag vorhanden.
## CloudFormation Stapel
Das folgende Verhalten gilt für Aufgabendefinitionen, die vor dem 12. Januar 2023 in der neuen Amazon-ECS-Konsole erstellt wurden.
Wenn Sie eine Aufgabendefinition erstellen, erstellt die Amazon ECS-Konsole automatisch einen CloudFormation Stack, dessen Name mit beginnt`ECS-Console-V2-TaskDefinition-`. Wenn Sie das AWS CLI oder ein AWS SDK verwendet haben, um die Registrierung der Aufgabendefinition aufzuheben, müssen Sie den Aufgabendefinitionsstapel manuell löschen. Weitere Informationen finden Sie unter [Löschen eines Stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) im *CloudFormation -Benutzerhandbuch*.
Für Aufgabendefinitionen, die nach dem 12. Januar 2023 erstellt wurden, wird kein CloudFormation Stapel automatisch für sie erstellt.
## Verfahren
------
#### [ Amazon ECS console ]
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie im Menü **Neue Aufgabendefinition erstellen** die Option **Neue Aufgabendefinition erstellen** aus.
1. Geben Sie für **Task definition family** (Aufgabendefinitions-Familie) einen eindeutigen Namen für die Aufgabendefinition an.
1. Wählen Sie als **Starttyp** die Anwendungsumgebung aus. Die Standardeinstellung der Konsole ist **AWS Fargate** (serverless). Amazon ECS führt eine Validierung mit diesem Wert durch, um sicherzustellen, dass die Aufgabendefinitions-Parameter für den Infrastrukturtyp gültig sind.
1. Wählen Sie für **Operating system/architecture** (Betriebssystem/Architektur) das Betriebssystem und die CPU-Architektur für die Aufgabe aus.
Um Ihre Aufgabe auf einer 64-Bit-ARM-Architektur auszuführen, wählen Sie **Linux/ ARM64**. Weitere Informationen finden Sie unter [Laufzeit-Plattform](task_definition_parameters.md#runtime-platform).
Um Ihre **AWS Fargate**-Aufgaben auf Windows-Containern auszuführen, wählen Sie ein unterstütztes Windows-Betriebssystem aus. Weitere Informationen finden Sie unter [Betriebssysteme und Architekturen](fargate-tasks-services.md#fargate-task-os).
1. Wählen Sie für **Task size** (Aufgabengröße) die CPU- und Arbeitsspeicherwerte aus, die für die Aufgabe reserviert werden sollen. Der CPU-Wert ist als v CPUs und der Arbeitsspeicher als GB angegeben.
Für Aufgaben, die auf Fargate gehostet werden, zeigt die folgende Tabelle die gültigen CPU- und Arbeitsspeicher-Kombinationen.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-task-definition.html)
Für Aufgaben, die EC2-Instances oder externe Instances verwenden, liegen die unterstützten Task-CPU-Werte zwischen 128 CPU-Einheiten (0,125 VCPUs) und 196608 CPU-Einheiten (192 V). CPUs
Um den Speicherwert in GB anzugeben, geben Sie nach dem Wert **GB** ein. Um beispielsweise den **Speicherwert** auf 3 GB festzulegen, geben Sie **3GB** ein.
**Anmerkung**
CPU- und Speicherparameter auf Aufgabenebene werden für Windows-Container ignoriert.
1. Wählen Sie für **Network mode** (Netzwerkmodus) den zu verwendenden Netzwerkmodus aus. Der Standardmodus ist **awsvpc**. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabenvernetzung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html).
Wenn Sie unter **Port-Zuordnungen** für **Host-Port** die Option **Bridge** wählen, geben Sie die Portnummer der Container-Instance ein, die Sie für Ihren Container reservieren möchten.
1. (Optional) Erweitern Sie den Abschnitt **Aufgabenrollen**, um die AWS Identity and Access Management (IAM-) Rollen für die Aufgabe zu konfigurieren:
1. Wählen Sie für **Task role** (Aufgabenrolle) die IAM-Rolle aus, die Sie der Aufgabe zuweisen möchten. Eine Task-IAM-Rolle gewährt den Containern in einer Aufgabe die Berechtigungen, AWS API-Operationen aufzurufen.
1. Wählen Sie für die **Aufgabenausführungsrolle** die Rolle aus.
Informationen darüber, wann Sie eine Aufgabenausführungsrolle verwenden sollten, finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md). Wenn Sie die Rolle nicht benötigen, wählen Sie **Keine** aus.
1. (Optional) Erweitern Sie den Abschnitt **Aufgabenplatzierung**, um Platzierungsbeschränkungen hinzuzufügen. Aufgabenplatzierungs-Beschränkungen ermöglichen es Ihnen, die Container-Instances, die für die Platzierung Ihrer Aufgaben verwendet werden, mithilfe integrierter oder benutzerdefinierter Attribute zu filtern.
1. (Optional) Erweitern Sie den Abschnitt **Fehlerinjektion**, um Fehlerinjektion zu aktivieren. Mit der Fehlerinjektion können Sie testen, wie Ihre Anwendung auf bestimmte Beeinträchtigungsszenarien reagiert.
1. Führen Sie für jeden in Ihrer Aufgabendefinition zu definierenden Container die folgenden Schritte aus.
1. Geben Sie unter **Name** einen Namen für den Container ein.
1. Geben Sie für **Image URI** (Image-URI) das Image an, das zum Starten eines Containers verwendet werden soll. Images in der Amazon ECR Public Gallery Registry können nur mithilfe des öffentlichen Amazon-ECR-Registry-Namens angegeben werden. Wenn beispielsweise `public.ecr.aws/ecs/amazon-ecs-agent:latest` angegeben ist, wird der auf Amazon ECR Public Gallery gehostete Amazon-Linux-Container verwendet. Geben Sie für alle anderen Repositorys das Repository im `repository-url/image:tag`- oder `repository-url/image@digest`-Format an.
1. Wenn sich Ihr Image in einer privaten Registrierung außerhalb von Amazon ECR befindet, aktivieren Sie unter **Private Registrierung** die **Authentifizierung mit privater Registrierung**. Geben Sie dann unter **Secrets-Manager-ARN oder -Name** den Amazon-Ressourcennamen (ARN) des Secrets ein.
1. Wenn für Ihre Aufgabendefinition zwei oder mehr Container definiert sind, können Sie für **Essenzieller Container** angeben, ob der Container als Essenziell betrachtet werden soll. Wenn ein Container als **Essenziell** markiert ist und dieser Container angehalten wird, wird die Aufgabe angehalten. Jede Aufgabendefinition muss mindestens einen essenziellen Container enthalten.
1. Ein Port-Mapping erlaubt es dem Container, auf Ports auf dem Host zuzugreifen, um Datenverkehr zu senden oder zu empfangen. Führen Sie unter **Port-Mappings** einen der folgenden Schritte aus:
+ Wenn Sie den **awsvpc**-Netzwerkmodus verwenden, geben Sie für **Container port** (Container-Port) und **Protocol** (Protokoll) das Port-Mapping an, das für den Container verwendet werden soll.
+ Wenn Sie den **bridge**-Netzwerkmodus verwenden, wählen Sie für **Container port** (Container-Port) und **Protocol** (Protokoll) die Port-Zuweisung, die für den Container verwendet werden soll.
Wählen Sie **Add more port mappings** (Weitere Port-Mappings hinzufügen) aus, um zusätzliche Container-Port-Mappings anzugeben.
1. Wenn Sie dem Container schreibgeschützten Zugriff auf das Root-Dateisystem gewähren möchten, wählen Sie für **Schreibgeschütztes Root-Dateisystem** die Option **Schreibgeschützter Zugriff**.
1. (Optional) Gehen Sie wie folgt vor, um die Limits für CPU, GPU und Arbeitsspeicher auf Container-Ebene zu definieren, die sich von den Werten auf Aufgabenebene unter **Limits für die Ressourcenzuweisung** unterscheiden:
+ Geben Sie für **CPU** die Anzahl der CPU-Einheiten ein, die der Amazon-ECS-Container-Agent für den Container reserviert.
+ Geben Sie für **GPU** die Anzahl der GPU-Einheiten für die Container-Instance ein.
Eine Amazon-EC2-Instance mit GPU-Unterstützung hat 1 GPU-Einheit für jede GPU. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md).
+ Geben Sie unter **festes Arbeitsspeicher-Limit** die Speichermenge in GB ein, die dem Container zur Verfügung stehen soll. Wenn der Container versucht, die harte Grenze zu überschreiten, stoppt der Container.
+ Der Daemon für Docker 20.10.0 oder höher reserviert mindestens 6 Mebibytes (MiB) Arbeitsspeicher für einen Container, deshalb sollten Sie nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container angeben.
Der Daemon für Docker 19.03.13 oder früher reserviert mindestens 4 MiB Arbeitsspeicher für einen Container, deshalb sollten Sie nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container angeben.
+ Geben Sie unter **Memory Soft Limit** die weiche Grenze (in GB) des Speichers ein, der für den Container reserviert werden soll.
Wenn der Systemspeicher strittig ist, versucht Docker den Arbeitsspeicher des Containers innerhalb der weichen Grenze zu halten. Wenn Sie keinen Speicher auf Aufgabenebene angeben, müssen Sie eine Ganzzahl ungleich Null für einen oder beide Werte von **Memory Hard Limit** und **Memory Soft Limit** angeben. Wenn Sie beide angeben, muss **Memory Hard Limit** größer sein als **Memory Soft Limit**.
Dieses Feature wird auf Windows-Containern nicht unterstützt.
1. (Optional) Erweitern Sie den Abschnitt **Umgebungsvariablen**, um Umgebungsvariablen anzugeben, die in den Container eingefügt werden sollen. Sie können Umgebungsvariablen entweder einzeln mit Schlüssel-Wert-Paaren oder in großen Mengen angeben, indem Sie eine Umgebungsvariablen-Datei angeben, die in einem Amazon-S3-Bucket gehostet wird. Weitere Informationen zum Formatieren einer Umgebungsvariablen-Datei finden Sie unter [Eine einzelne Umgebungsvariable an einen Amazon-ECS-Container übergeben](taskdef-envfiles.md).
Wenn Sie eine Umgebungsvariable für den geheimen Speicher angeben, geben Sie unter **Schlüssel** den geheimen Namen ein. Geben Sie **ValueFrom**dann für den vollständigen ARN des Systems Manager Parameter Store Secret oder Secrets Manager Secret ein
1. (Optional) Wählen Sie die Option **Use log collection** (Protokollerfassung verwenden), um eine Protokollkonfiguration anzugeben. Für jeden verfügbaren Protokolltreiber gibt es Protokolltreiberoptionen, die angegeben werden müssen. Die Standardoption sendet Container-Logs an Amazon CloudWatch Logs. Die anderen Optionen für den Protokolltreiber werden mithilfe von konfiguriert AWS FireLens. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md).
Im Folgenden wird jedes Container-Protokollziel ausführlicher beschrieben.
+ **Amazon CloudWatch** — Konfigurieren Sie die Aufgabe, um Container-Logs an CloudWatch Logs zu senden. Es werden die standardmäßigen Protokolltreiberoptionen bereitgestellt, mit denen in Ihrem Namen eine CloudWatch Protokollgruppe erstellt wird. Um einen anderen Protokollgruppen-Namen anzugeben, ändern Sie die Werte der Treiberoption.
+ **Protokolle nach Splunk exportieren** – Konfigurieren Sie die Aufgabe so, dass Container-Protokolle an den Splunk-Treiber gesendet werden, der die Protokolle an einen Remote-Service sendet. Sie müssen die URL zu Ihrem Splunk-Webservice eingeben. Der Splunk-Token wird als geheime Option angegeben, da er als sensible Daten behandelt werden kann.
+ **Protokolle nach Amazon Data Firehose exportieren** – Konfigurieren Sie die Aufgabe, um Container-Protokolle an Firehose zu senden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch die Protokolle an einen Bereitstellungsdatenstrom von Firehose gesendet werden. Um einen anderen Namen für den Bereitstellungsdatenstrom anzugeben, ändern Sie die Werte der Treiberoption.
+ **Protokolle nach Amazon Kinesis Data Streams exportieren** – Konfigurieren Sie die Aufgabe, um Container-Protokolle an Kinesis-Datenströme zu senden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, wodurch Protokolle an einen Kinesis-Datenstrom gesendet werden. Um einen anderen Datenstrom-Namen anzugeben, ändern Sie die Werte der Treiberoption.
+ **Protokolle nach Amazon OpenSearch Service exportieren** — Konfigurieren Sie die Aufgabe so, dass Container-Protokolle an eine OpenSearch Service-Domain gesendet werden. Die Optionen für den Protokolltreiber müssen bereitgestellt werden.
+ **Protokolle nach Amazon S3 exportieren** – Konfigurieren Sie die Aufgabe, um Container-Protokolle an einen Amazon-S3-Bucket zu senden. Die Standardoptionen für den Protokolltreiber werden bereitgestellt, Sie müssen jedoch einen gültigen Amazon-S3-Bucket-Namen angeben.
1. (Optional) Konfigurieren Sie zusätzliche Container-Parameter.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-task-definition.html)
1. (Optional) Wählen Sie **Add more containers** (Weiterer Container hinzufügen) aus, um der Aufgabendefinition zusätzliche Container hinzuzufügen.
1. (Optional) Der Abschnitt **Speicher** wird verwendet, um die Menge an flüchtigem Speicher für auf Fargate gehostete Aufgaben zu erweitern. Sie können diesen Abschnitt auch verwenden, um eine Daten-Volume-Konfiguration für die Aufgabe hinzuzufügen.
1. Geben Sie für **Amount** (Menge) einen Wert bis zu 200 GiB an, um den verfügbaren flüchtigen Speicher über den Standardwert von 20 gibibytes (GiB) für Ihre Fargate-Aufgaben zu erweitern.
1. (Optional) Um eine Daten-Volume-Konfiguration für die Aufgabendefinition hinzuzufügen, wählen Sie **Volume hinzufügen** und führen Sie dann die folgenden Schritte aus.
1. Geben Sie unter **Volume-Name** einen Namen für das Daten-Volume an. Der Daten-Volume-Name wird beim Erstellen eines Container-Mounting-Punkts verwendet.
1. Wählen Sie für **Volume-Konfiguration** aus, ob Sie Ihr Volume bei der Erstellung der Aufgabendefinition oder während der Bereitstellung konfigurieren möchten.
**Anmerkung**
Zu den Volumes, die bei der Erstellung einer Aufgabendefinition konfiguriert werden können, gehören Bind MountDocker, Amazon EFS und Amazon FSx for Windows File Server. Zu den Volumes, die bei der Bereitstellung konfiguriert werden können, wenn eine Aufgabe ausgeführt wird oder wenn ein Service erstellt oder aktualisiert wird, gehört Amazon EBS.
1. Wählen Sie unter **Volume-Typ** einen Volume-Typ aus, der mit dem ausgewählten Konfigurationstyp kompatibel ist, und konfigurieren Sie dann den Volume-Typ.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/create-task-definition.html)
1. Um ein Volume aus einem anderen Container hinzuzufügen, wählen Sie **Volume hinzufügen aus** und konfigurieren Sie dann Folgendes:
+ Wählen Sie für **Container** den Container aus.
+ Wählen Sie unter **Quelle** den Container aus, der das Volume enthält, das Sie mounten möchten.
+ Wählen Sie für **Schreibgeschützt**, ob der Container nur schreibgeschützten Zugriff auf das Volume hat.
1. (Optional) Um Ihre Einstellungen für Anwendungsverfolgung und Metrikerfassung mithilfe der AWS Distro for OpenTelemetry Integration zu konfigurieren, erweitern Sie **Überwachung** und wählen Sie dann **Metrikerfassung verwenden, um Metriken** für Ihre Aufgaben zu sammeln und an Amazon CloudWatch oder Amazon Managed Service for Prometheus zu senden aus. Wenn diese Option ausgewählt ist, erstellt Amazon ECS einen AWS Distro for OpenTelemetry Container-Sidecar, der für das Senden der Anwendungsmetriken vorkonfiguriert ist. Weitere Informationen finden Sie unter [Amazon-ECS-Anwendungsleistung mithilfe von Anwendungsmetriken korrelieren](metrics-data.md).
1. Wenn **Amazon** ausgewählt CloudWatch ist, werden Ihre benutzerdefinierten Anwendungsmetriken CloudWatch als benutzerdefinierte Metriken weitergeleitet. Weitere Informationen finden Sie unter [Anwendungsmetriken nach Amazon exportieren CloudWatch](application-metrics-cloudwatch.md).
**Wichtig**
Wenn Sie Anwendungsmetriken nach Amazon exportieren CloudWatch, erfordert Ihre Aufgabendefinition eine Task-IAM-Rolle mit den erforderlichen Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche IAM-Berechtigungen für AWS Distro für die OpenTelemetry Integration mit Amazon CloudWatch](application-metrics-cloudwatch.md#application-metrics-cloudwatch-iam).
1. Wenn Sie **Amazon Managed Service for Prometheus (Prometheus libraries instrumentation)** (Amazon Managed Service for Prometheus (Instrumentierung der Prometheus-Bibliotheken)) ausgewählt ist, werden Ihre CPU-, Arbeitsspeicher-, Netzwerk- und Speichermetriken auf Aufgabenebene sowie Ihre benutzerdefinierten Anwendungsmetriken an Amazon Managed Service for Prometheus weitergeleitet. Geben Sie für **Workspace-Remote-Schreibendpunkt** die URL des Remote-Schreibendpunkts für Ihren Prometheus-Workspace ein. Geben Sie für **Scraping-Ziel** den Host und Port ein, den der Collector von AWS Distro for OpenTelemetry verwenden kann, um Metrikdaten zu extrahieren. Weitere Informationen finden Sie unter [Exportieren von Anwendungsmetriken an Amazon Managed Service for Prometheus](application-metrics-prometheus.md).
**Wichtig**
Beim Exportieren von Anwendungsmetriken nach Amazon Managed Service for Prometheus erfordert Ihre Aufgabendefinition eine Aufgaben-IAM-Rolle Aufgabe mit den erforderlichen Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche IAM-Berechtigungen für AWS Distro für die OpenTelemetry Integration mit Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam).
1. Wenn Sie **Amazon Managed Service for Prometheus (OpenTelemetryInstrumentierung)** auswählen, werden Ihre CPU-, Arbeitsspeicher-, Netzwerk- und Speichermetriken auf Taskebene sowie Ihre benutzerdefinierten Anwendungsmetriken an Amazon Managed Service for Prometheus weitergeleitet. Geben Sie für **Workspace-Remote-Schreibendpunkt** die URL des Remote-Schreibendpunkts für Ihren Prometheus-Workspace ein. Weitere Informationen finden Sie unter [Exportieren von Anwendungsmetriken an Amazon Managed Service for Prometheus](application-metrics-prometheus.md).
**Wichtig**
Beim Exportieren von Anwendungsmetriken nach Amazon Managed Service for Prometheus erfordert Ihre Aufgabendefinition eine Aufgaben-IAM-Rolle Aufgabe mit den erforderlichen Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche IAM-Berechtigungen für AWS Distro für die OpenTelemetry Integration mit Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam).
1. (Optional) Erweitern Sie den Abschnitt **Tags** zum Hinzufügen von Tags als Schlüssel-Wert-Paare zur Aufgabendefinition.
+ [Ein Tag hinzufügen] Wählen Sie **Add tag** (Tag hinzufügen) und führen Sie dann das Folgende aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
+ [Tag entfernen] Wählen Sie neben dem Tag die Option **Remove tag (Tag löschen)** aus.
1. Wählen Sie **Erstellen**, um die Aufgabendefinition zu registrieren.
------
#### [ Amazon ECS console JSON editor ]
1. [https://console.aws.amazon.com/ecs/Öffnen](https://console.aws.amazon.com/ecs/v2) Sie die Konsole auf Version 2.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie im Menü **Neue Aufgabendefinition erstellen** die Option **Neue Aufgabendefinition mit JSON erstellen** aus.
1. Bearbeiten Sie im JSON-Editorfeld Ihre JSON-Datei,
Der JSON muss die in [JSON-Validierung](#json-validate-for-create) angegebenen Validierungsprüfungen bestehen.
1. Wählen Sie **Erstellen** aus.
------
# Verwenden von Amazon Q Developer zur Bereitstellung von Empfehlungen zur Aufgabendefinition in der Amazon-ECS-Konsole
Wenn Sie den JSON-Editor in der Amazon-ECS-Konsole verwenden, um eine Aufgabendefinition zu erstellen, können Sie Amazon Q Developer verwenden, um KI-generierte Codevorschläge für Ihre Aufgabendefinitionen bereitzustellen.
Sie können die Inline-Chat-Funktion verwenden, um Amazon Q Developer zu bitten, JSON für Aufgabendefinitionen mit einer Konversationsoberfläche zu generieren, zu erklären oder Faktorwechsel durchzuführen. Sie können generierte Vorschläge an jeder beliebigen Stelle in die Aufgabendefinition einfügen und die vorgeschlagenen Änderungen akzeptieren oder ablehnen. Amazon ECS hat auch das bestehende Feature für Inline-Vorschläge verbessert, um Amazon Q Developer zu nutzen.
Wenn Sie eine Aufgabendefinition mit dem JSON-Editor erstellen, können Sie sich von Amazon Q Developer Empfehlungen geben lassen, die Ihnen helfen, eine Aufgabendefinition schneller zu erstellen. Sie können eigenschaftsbasierte Inline-Vorschläge haben oder die Vorschläge von Amazon Q Developer verwenden, um ganze Beispiel-Codeblöcke automatisch zu vervollständigen.
Sie können dieses Feature in Regionen verwenden, in denen Amazon Q Developer unterstützt wird. Weitere Informationen finden Sie unter [AWS -Services nach Region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
## Voraussetzungen
Dies sind die Voraussetzungen:
+ Zusätzlich zu den Konsolenberechtigungen muss der Benutzer, der die Aufgabendefinition in der Konsole erstellt, über die `codewhisperer:GenerateRecommendations`-Berechtigung für die Empfehlungen und `q:SendMessage` für die Verwendung des Inline-Chats verfügen. Weitere Informationen finden Sie unter [Erforderliche Berechtigungen für die Verwendung von Amazon Q Developer zur Bereitstellung von Empfehlungen in der Konsole](console-permissions.md#amazon-q-permission).
## Verfahren
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie im Menü **Neue Aufgabendefinition erstellen** die Option **Neue Aufgabendefinition mit JSON erstellen** aus.
Die Seite **Aufgabendefinition erstellen** wird angezeigt.
Die Konsole bietet die folgende Standardvorlage.
```
{
"requiresCompatibilities": [
"FARGATE"
],
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
"essential": true
}
],
"volumes": [],
"networkMode": "awsvpc",
"memory": "3 GB",
"cpu": "1 vCPU",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```
1. Wählen Sie im Popup-Fenster mit Inline-Vorschlägen von Amazon Q die Option **Zulassen** aus.
Wenn Sie das Popup-Fenster schließen, können Sie Amazon Q unter dem Zahnradsymbol aktivieren.
1. Bearbeiten Sie im JSON-Editorfeld das JSON-Dokument.
Damit Amazon Q die Parameter erstellt und auffüllt, geben Sie einen Kommentar mit dem ein, was Sie hinzufügen möchten. Im folgenden Beispiel veranlasst der Kommentar Amazon Q, die fett gedruckten Zeilen zu generieren.
```
{
"requiresCompatibilities": [
"FARGATE"
],
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
"essential": true
},
// add an nginx container using an image from Public ECR, with port 80 open, and send logs to CloudWatch log group "myproxy"
{
"name": "nginx",
"image": "public.ecr.aws/nginx/nginx:latest",
"essential": true,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "myproxy",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "nginx"
}
}
}
],
"volumes": [],
"networkMode": "awsvpc",
"memory": "3 GB",
"cpu": "1 vCPU",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```
1. Um das Inline-Chat-Feature zu verwenden, können Sie die Zeilen markieren und dann das Sternsymbol auswählen.
Das Chat-Feld für Amazon Q Developer wird angezeigt.
Geben Sie Ihre Anfrage ein.
Amazon Q Developer generiert die JSON-Datei und aktualisiert sie anschließend.
Um die Änderungen zu akzeptieren, wählen Sie **Alle akzeptieren**
1. Wählen Sie **Erstellen** aus.
# Aktualisieren einer Amazon-ECS-Aufgabendefinition mithilfe der Konsole
Eine *Revision der Aufgabendefinition* ist eine Kopie der aktuellen Aufgabendefinition mit den neuen Parameterwerten, die die vorhandenen ersetzen. Alle Parameter, die Sie nicht ändern, befinden sich in der neuen Revision.
Um eine Aufgabendefinition zu aktualisieren, erstellen Sie eine Revision der Aufgabendefinition. Wenn die Aufgabendefinition in einem Service verwendet wird, aktualisieren diesen Service, sodass er die aktualisierte Aufgabendefinition verwendet.
Wenn Sie eine Revision erstellen, können Sie die folgenden Containereigenschaften und Umgebungseigenschaften ändern.
+ Container-Image-URI
+ Portzuordnungen
+ Umgebungsvariablen
+ Anforderungen an die Infrastruktur
+ Aufgabengröße
+ Größe des Containers
+ -Rolle für Aufgabe
+ -Rolle für die Aufgabenausführung
+ Volumes und Mounting-Punkte für Container
+ Private Registrierung
Sie können Amazon Q Empfehlungen geben lassen, wenn Sie den JSON-Editor verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon Q Developer zur Bereitstellung von Empfehlungen zur Aufgabendefinition in der Amazon-ECS-Konsole](using-amazon-q.md).
## JSON-Validierung
Der JSON-Editor der Amazon-ECS-Konsole validiert Folgendes in der JSON-Datei:
+ Die Datei ist eine gültige JSON-Datei
+ Die Datei enthält keine irrelevanten Schlüssel
+ Die Datei enthält den `familyName`-Parameter
+ Unter `containerDefinitions` ist mindestens ein Eintrag vorhanden
## Verfahren
------
#### [ Amazon ECS console ]
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Ihre Aufgabendefinition enthalten ist.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie die Aufgabendefinition.
1. Markieren Sie die Aufgabendefinitionsversion und wählen Sie dann **Neue Version erstellen**, **Neue Version erstellen**.
1. Nehmen Sie auf der Seite **Create new task definition revision** (Neue Revision der Aufgabendefinition erstellen) die Änderungen vor. Wenn Sie beispielsweise die vorhandenen Containerdefinitionen ändern möchten (wie z. B. das Container-Image, die Arbeitsspeicher-Limits oder Port-Mappings), wählen Sie den Container aus, um die Änderungen vorzunehmen. Sie können die Kompatibilität der Aufgabendefinitionen auf eine für **AWS Fargate**, **Managed Instances** oder **Amazon-EC2-Instances** aktualisieren.
1. Verifizieren Sie die Informationen und wählen Sie dann **Aktualisieren**.
1. Wenn Ihre Aufgabendefinition in einem Service verwendet wird, aktualisieren Sie Ihren Service mit der aktualisierten Aufgabendefinition. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md).
------
#### [ Amazon ECS console JSON editor ]
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie **Create new revision** (Neue Revision erstellen), **Create new revision with JSON** (Neue Revision mit JSON) erstellen.
1. Bearbeiten Sie im JSON-Editorfeld Ihre JSON-Datei,
Der JSON muss die in [JSON-Validierung](#json-validate-for-update) angegebenen Validierungsprüfungen bestehen.
1. Wählen Sie **Erstellen** aus.
------
# Abmelden einer Revision der Amazon-ECS-Aufgabendefinition mithilfe der Konsole
Sie können die Registrierung einer Revision der Aufgabendefinition aufheben, sodass sie nicht mehr in Ihren `ListTaskDefinition`-API-Aufrufen oder in der Konsole angezeigt wird, wenn Sie eine Aufgabe ausführen oder einen Service aktualisieren möchten.
Wenn Sie die Registrierung einer Revision einer Aufgabendefinition aufheben, wird diese sofort als `INACTIVE` gekennzeichnet. Vorhandene Aufgaben und Dienste, die auf eine `INACTIVE`-Taskdefinitionsrevision verweisen werden weiterhin ohne Unterbrechung ausgeführt. Bestehende Dienste, die auf eine `INACTIVE`-Revision der Aufgabendefinition verweisen, können durch Änderung der gewünschten Anzahl des Service weiterhin nach oben oder unten skaliert werden.
Sie können keine `INACTIVE`-Taskdefinitionsrevision verwenden, um neue Aufgaben auszuführen oder neue Dienste zu erstellen. Sie können einen vorhandenen Service auch nicht dahingehend aktualisieren, dass er auf eine `INACTIVE`-Revision einer Aufgabendefinition verweist (Obwohl nach Aufheben der Registrierung ein Zeitfenster von bis zu 10 Minuten bestehen kann, in dem diese Einschränkungen noch nicht wirksam sind).
**Anmerkung**
Wenn Sie die Registrierung aller Revisionen in einer Aufgabenfamilie aufheben, wird die Aufgabendefinitionsfamilie in die `INACTIVE`-Liste verschoben. Das Hinzufügen einer neuen Version einer `INACTIVE`-Aufgabendefinition verschiebt die Aufgabendefinitionsfamilie zurück in die `ACTIVE`-Liste.
Zu diesem Zeitpunkt bleiben Überarbeitungen von `INACTIVE`-Aufgabendefinitionen in Ihrem Konto unbegrenzt erkennbar. Dieses Verhalten kann sich jedoch in Zukunft ändern. Daher sollten Sie sich nicht darauf verlassen, dass Überarbeitungen von `INACTIVE`-Aufgabendefinitionen über den Lebenszyklus der zugeordneten Aufgaben und Services hinaus bestehen.
## CloudFormation stapelt
Das folgende Verhalten gilt für Aufgabendefinitionen, die vor dem 12. Januar 2023 in der neuen Amazon-ECS-Konsole erstellt wurden.
Wenn Sie eine Aufgabendefinition erstellen, erstellt die Amazon ECS-Konsole automatisch einen CloudFormation Stack, dessen Name mit beginnt`ECS-Console-V2-TaskDefinition-`. Wenn Sie das AWS CLI oder ein AWS SDK verwendet haben, um die Registrierung der Aufgabendefinition aufzuheben, müssen Sie den Aufgabendefinitionsstapel manuell löschen. Weitere Informationen finden Sie unter [Löschen eines Stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) im *CloudFormation -Benutzerhandbuch*.
Für Aufgabendefinitionen, die nach dem 12. Januar 2023 erstellt wurden, wird kein CloudFormation Stapel automatisch für sie erstellt.
## Verfahren
**So melden Sie eine neue Aufgabendefinition ab (Amazon-ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Ihre Aufgabendefinition enthalten ist.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie auf der Seite **Task Definitions** (Aufgabendefinitionen) die Aufgabendefinitionsfamilie aus, die eine oder mehrere Revisionen enthält, deren Registrierung Sie aufheben möchten.
1. Wählen Sie auf der Seite mit dem **Namen der Aufgabendefinition** die zu löschenden Revisionen aus, und klicken Sie dann auf **Aktionen**, **Registrierung aufheben**.
1. Überprüfen Sie die Informationen im Fenster **Deregister** (Abmelden) und wählen Sie dann **Deregister** (Abmelden), um den Vorgang abzuschließen.
# Löschen einer Revision der Amazon-ECS-Aufgabendefinition mit der Konsole
Wenn Sie eine bestimmte Revision der Aufgabendefinition in Amazon ECS nicht mehr benötigen, können Sie die Revision der Aufgabendefinition löschen.
Wenn Sie eine Aufgabendefinitionsrevision löschen, wechselt sie sofort von `INACTIVE` zu `DELETE_IN_PROGRESS`. Vorhandene Aufgaben und Dienste, die auf eine `DELETE_IN_PROGRESS`-Aufgabendefinitionsrevision verweisen werden weiterhin ohne Unterbrechung ausgeführt.
Sie können keine `DELETE_IN_PROGRESS`-Aufgabendefinitionsrevision verwenden, um neue Aufgaben auszuführen oder neue Dienste zu erstellen. Sie können einen vorhandenen Service auch nicht dahingehend aktualisieren, dass er auf eine `DELETE_IN_PROGRESS`-Revision einer Aufgabendefinition verweist.
Wenn Sie alle Versionen der `INACTIVE`-Aufgabendefinition löschen, wird der Name der Aufgabendefinition nicht in der Konsole angezeigt und nicht in der API zurückgegeben. Wenn sich eine Revision der Aufgabendefinition im Status `DELETE_IN_PROGRESS` befindet, wird der Name der Aufgabendefinition in der Konsole angezeigt und in der API zurückgegeben. Der Name der Aufgabendefinition wird von Amazon ECS beibehalten und die Version wird erhöht, wenn Sie das nächste Mal eine Aufgabendefinition mit diesem Namen erstellen.
## Amazon-ECS-Ressourcen, die einen Löschvorgang blockieren können
Eine Anfrage zum Löschen einer Aufgabendefinition kann nicht abgeschlossen werden, wenn Amazon-ECS-Ressourcen vorhanden sind, die von der Revision der Aufgabendefinition abhängen. Die folgenden Ressourcen können verhindern, dass eine Aufgabendefinition gelöscht wird:
+ Eigenständige Amazon-ECS-Aufgaben – Die Aufgabendefinition ist erforderlich, damit die Aufgabe fehlerfrei bleibt.
+ Amazon-ECS-Serviceaufgaben – Die Aufgabendefinition ist erforderlich, damit die Aufgabe fehlerfrei bleibt.
+ Amazon-ECS-Servicebereitstellungen und Aufgabensätze – Die Aufgabendefinition ist erforderlich, wenn ein Skalierungsereignis für eine Amazon-ECS-Bereitstellung oder einen Aufgabensatz ausgelöst wird.
Bleibt Ihre Aufgabendefinition im `DELETE_IN_PROGRESS` Status, können Sie die Konsole oder die verwenden, AWS CLI um die Ressourcen zu identifizieren und dann zu beenden, die das Löschen der Aufgabendefinition blockieren.
### Löschen der Aufgabendefinition, nachdem die blockierende Ressource entfernt wurde
Die folgenden Regeln gelten, nachdem Sie die Ressourcen entfernt haben, die das Löschen der Aufgabendefinition blockieren:
+ Amazon-ECS-Aufgaben – Nach dem Beenden der Aufgabe kann es bis zu 1 Stunde dauern, bis das Löschen der Aufgabendefinition abgeschlossen ist.
+ Amazon-ECS-Bereitstellungen und Aufgabensätze – Es kann bis zu 24 Stunden dauern, bis das Löschen der Aufgabendefinition abgeschlossen ist, nachdem die Bereitstellung oder der Aufgabensatz gelöscht wurde.
## Verfahren
**So löschen Sie Aufgabendefinitionen (Amazon-ECS-Konsole)**
Sie müssen die Registrierung einer Revision der Aufgabendefinition aufheben, bevor Sie sie löschen. Weitere Informationen finden Sie unter [Abmelden einer Revision der Amazon-ECS-Aufgabendefinition mithilfe der Konsole](deregister-task-definition-v2.md).
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Ihre Aufgabendefinition enthalten ist.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie auf der Seite **Aufgabendefinitionen** die Aufgabendefinitionsfamilie aus, die eine oder mehrere Revisionen enthält, die Sie löschen möchten.
1. Wählen Sie auf der Seite mit dem **Namen der Aufgabendefinition** die zu löschenden Revisionen aus, und dann **Aktionen**, **Löschen**.
Wenn **Löschen** nicht verfügbar ist, müssen Sie die Registrierung der Aufgabendefinition aufheben.
1. Überprüfen Sie die Informationen im Bestätigungsfenster **Löschen** und wählen Sie dann **Löschen**, um den Vorgang abzuschließen.
# Anwendungsfälle für Amazon-ECS-Aufgabendefinitionen
Erfahren Sie mehr darüber, wie Sie Aufgabendefinitionen für verschiedene AWS Dienste und Funktionen schreiben.
Abhängig von Ihrem Workload müssen bestimmte Aufgabendefinitionsparameter festgelegt werden. Außerdem müssen Sie für EC2 bestimmte Instances auswählen, die für den Workload entwickelt wurden.
**Topics**
+ [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md)
+ [Amazon-ECS-Aufgabendefinitionen für Workloads zur Video-Transkodierung](ecs-vt1.md)
+ [Amazon ECS-Aufgabendefinitionen für AWS Neuron-Workloads für maschinelles Lernen](ecs-inference.md)
+ [Amazon-ECS-Aufgabendefinitionen für Deep-Learning-Instances](ecs-dl1.md)
+ [Amazon-ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads](ecs-arm64.md)
+ [Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md)
+ [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md)
+ [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md)
+ [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md)
+ [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md)
# Amazon-ECS-Aufgabendefinitionen für GPU-Workloads
Amazon ECS unterstützt Workloads, die GPUs verwenden, wenn Sie Cluster mit Container-Instances erstellen, die GPUs unterstützen. GPU-basierte Amazon EC2 EC2-Container-Instances, die die Instance-Typen p2, p3, p5, g3, g4 und g5 verwenden, bieten Zugriff auf NVIDIA. GPUs Weitere Informationen finden Sie unter [Linux-beschleunigte Computing-Instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) im *Benutzerhandbuch für Instance-Typen von Amazon EC2*.
Amazon ECS bietet eine GPU-optimierte AMI, die mit vorkonfigurierten NVIDIA-Kernel-Treibern und einer Docker-GPU-Laufzeitumgebung ausgestattet ist. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md).
Sie können GPUs in Ihrer Aufgabendefinition eine Reihe von angeben, die bei der Platzierung von Aufgaben auf Containerebene berücksichtigt werden sollen. Amazon ECS plant für verfügbare Container-Instances, die für eine optimale Leistung physische Container unterstützen GPUs und GPUs an die richtigen Container anbinden.
Die folgenden GPU-basierten Instance-Typen von Amazon EC2 werden unterstützt. Weitere Informationen finden Sie unter [Amazon-EC2-P2-Instances](https://aws.amazon.com/ec2/instance-types/p2/), [Amazon-EC2-P3-Instances](https://aws.amazon.com/ec2/instance-types/p3/), [Amazon-EC2-P4d-Instances](https://aws.amazon.com/ec2/instance-types/p4/), [Amazon-EC2-P5-Instances](https://aws.amazon.com/ec2/instance-types/p5/), [Amazon-EC2-G3-Instances](https://aws.amazon.com/ec2/instance-types/g3/), [Amazon-EC2-G4-Instances](https://aws.amazon.com/ec2/instance-types/g4/), [Amazon-EC2-G5-Instances](https://aws.amazon.com/ec2/instance-types/g5/), [Amazon-EC2-G6-Instances](https://aws.amazon.com/ec2/instance-types/g6/) und [Amazon-EC2-G6e-Instances](https://aws.amazon.com/ec2/instance-types/g6e/).
| Instance-Typ | GPUs | GPU-Speicher (GiB) | v CPUs | Arbeitsspeicher (GiB) |
| --- | --- | --- | --- | --- |
| p3.2xgroß | 1 | 16 | 8 | 61 |
| p3.8xgroß | 4 | 64 | 32 | 244 |
| p3.16xgroß | 8 | 128 | 64 | 488 |
| p3dn.24xgroß | 8 | 256 | 96 | 768 |
| p4d.24xgroß | 8 | 320 | 96 | 1 152 |
| p5.48xlarge | 8 | 640 | 192 | 2048 |
| g3s.xgroß | 1 | 8 | 4 | 30,5 |
| g3.4xgroß | 1 | 8 | 16 | 122 |
| g3.8xgroß | 2 | 16 | 32 | 244 |
| g3.16xgroß | 4 | 32 | 64 | 488 |
| g4dn.xgroß | 1 | 16 | 4 | 16 |
| g4dn.2xgroß | 1 | 16 | 8 | 32 |
| g4dn.4xgroß | 1 | 16 | 16 | 64 |
| g4dn.8xgroß | 1 | 16 | 32 | 128 |
| g4dn.12xgroß | 4 | 64 | 48 | 192 |
| g4dn.16xgroß | 1 | 16 | 64 | 256 |
| g5.xgroß | 1 | 24 | 4 | 16 |
| g5.2xlarge | 1 | 24 | 8 | 32 |
| g5.4xlarge | 1 | 24 | 16 | 64 |
| g5.8xlarge | 1 | 24 | 32 | 128 |
| g5.16xlarge | 1 | 24 | 64 | 256 |
| g5.12xlarge | 4 | 96 | 48 | 192 |
| g5.24xlarge | 4 | 96 | 96 | 384 |
| g5.48xlarge | 8 | 192 | 192 | 768 |
| g6.xlarge | 1 | 24 | 4 | 16 |
| g6.2xlarge | 1 | 24 | 8 | 32 |
| g6.4xlarge | 1 | 24 | 16 | 64 |
| g6.8xlarge | 1 | 24 | 32 | 128 |
| g6.16.xlarge | 1 | 24 | 64 | 256 |
| g6.12xlarge | 4 | 96 | 48 | 192 |
| g6.24xlarge | 4 | 96 | 96 | 384 |
| g6.48xlarge | 8 | 192 | 192 | 768 |
| g6.metal | 8 | 192 | 192 | 768 |
| gr6.4xlarge | 1 | 24 | 16 | 128 |
| g6e.xlarge | 1 | 48 | 4 | 32 |
| g6e.2xlarge | 1 | 48 | 8 | 64 |
| g6e.4xlarge | 1 | 48 | 16 | 128 |
| g6e.8xlarge | 1 | 48 | 32 | 256 |
| g6e16.xlarge | 1 | 48 | 64 | 512 |
| g6e12.xlarge | 4 | 192 | 48 | 384 |
| g6e24.xlarge | 4 | 192 | 96 | 768 |
| g6e48.xlarge | 8 | 384 | 192 | 1536 |
| gr6.8xlarge | 1 | 24 | 32 | 256 |
Sie können die Amazon Machine Image (AMI) -ID für Amazon ECS-Optimized abrufen, AMIs indem Sie die AWS Systems Manager Parameter Store-API abfragen. Mit diesem Parameter müssen Sie Amazon ECS-optimiertes AMI nicht manuell suchen. IDs Weitere Informationen zur Systems Manager Parameter Store-API finden Sie unter [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Der von Ihnen verwendete Benutzer muss über die `ssm:GetParameter`-IAM-Berechtigung zum Abrufen der Amazon-EKS-optimierten AMI-Metadaten verfügen.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```
# Verwendung GPUs mit Amazon ECS Managed Instances
Amazon ECS Managed Instances unterstützt GPU-beschleunigte Datenverarbeitung für Workloads wie Machine Learning, Hochleistungsrechnen und Videoverarbeitung über die folgenden Instance-Typen von Amazon EC2. Weitere Informationen zu den von Amazon ECS Managed Instances unterstützten Instance-Typen finden Sie unter [Instance-Typen von Amazon ECS Managed Instances](managed-instances-instance-types.md).
Im Folgenden finden Sie eine Teilmenge der GPU-basierten Instance-Typen, die in Amazon ECS Managed Instances unterstützt werden:
+ `g4dn`: Unterstützt von NVIDIA T4 GPUs, geeignet für Machine Learning, Inferenz, Computer Vision und grafikintensive Anwendungen.
+ `g5`: Unterstützt von NVIDIA A10G GPUs, bietet höhere Leistung für grafikintensive Anwendungen und Workloads für Machine Learning.
+ `p3`: Unterstützt von NVIDIA V100 GPUs, konzipiert für Hochleistungscomputer und Deep-Learning-Training.
+ `p4d`: Unterstützt von NVIDIA A100 GPUs, bietet die höchste Leistung für Training für Machine Learning und Hochleistungs-Datenverarbeitung.
Wenn Sie GPU-fähige Instance-Typen mit Amazon ECS Managed Instances verwenden, sind die NVIDIA-Treiber und das CUDA-Toolkit auf der Instance vorinstalliert, sodass GPU-beschleunigte Workloads einfacher ausgeführt werden können.
## Auswahl GPU-fähiger Instances
Verwenden Sie das `instanceRequirements`-Objekt in der Startvorlage des Kapazitätsanbieters, um GPU-fähige Instance-Typen für Ihre Workloads von Amazon ECS Managed Instances auszuwählen. Der folgende Ausschnitt zeigt die Attribute, die für die Auswahl GPU-fähiger Instances verwendet werden können.
```
{
"instanceRequirements": {
"acceleratorTypes": "gpu",
"acceleratorCount": 1,
"acceleratorManufacturers": ["nvidia"]
}
}
```
Der folgende Ausschnitt zeigt die Attribute, die verwendet werden können, um GPU-fähige Instance-Typen in der Startvorlage anzugeben.
```
{
"instanceRequirements": {
"allowedInstanceTypes": ["g4dn.xlarge", "p4de.24xlarge"]
}
}
```
## GPU-fähige Container-Images
Für die Verwendung GPUs in Ihren Containern müssen Sie Container-Images verwenden, die die erforderlichen GPU-Bibliotheken und -Tools enthalten. NVIDIAstellt mehrere vorgefertigte Container-Images bereit, die Sie als Basis für Ihre GPU-Workloads verwenden können, darunter die folgenden:
+ `nvidia:cuda`: Basis-Images mit dem CUDA-Toolkit für GPU-Datenverarbeitung.
+ `tensorflow/tensorflow:latest-gpu`: TensorFlow mit GPU-Unterstützung.
+ `pytorch/pytorch:latest-cuda`: PyTorch mit GPU-Unterstützung.
Ein Beispiel für eine Aufgabendefinition für Amazon ECS auf Amazon ECS Managed Instances, die die Verwendung von beinhaltet GPUs, finden Sie unter[GPUs In einer Amazon ECS-Aufgabendefinition angeben](ecs-gpu-specifying.md).
## Überlegungen
**Anmerkung**
Die Unterstützung für den g2-Instance-Familientyp ist veraltet.
Der Instance-Familientyp p2 wird nur von Versionen vor `20230912` des Amazon-ECS-GPU-optimierten AMI unterstützt. Wenn Sie weiterhin P2-Instances verwenden müssen, finden Sie weitere Informationen unter [Was tun, wenn Sie eine P2-Instance benötigen](#p2-instance).
Direkte Aktualisierungen der NVIDIA/CUDA Treiber für diese beiden Instance-Familientypen können zu potenziellen Ausfällen der GPU-Arbeitslast führen.
Wir empfehlen Ihnen, Folgendes zu berücksichtigen, bevor Sie mit der Arbeit GPUs an Amazon ECS beginnen.
+ Ihre Cluster können eine Mischung aus GPU- und Nicht-GPU-Container-Instances enthalten.
+ Sie können GPU-Workloads auf externen Instances ausführen. Stellen Sie beim Anmelden einer externen Instance bei Ihrem Cluster sicher, dass das `--enable-gpu`-Flag im Installationsskript enthalten ist. Weitere Informationen finden Sie unter [Registrieren einer externen Instance in einem Amazon-ECS-Cluster](ecs-anywhere-registration.md).
+ Sie müssen in Ihrer Agenten-Konfigurationsdatei `ECS_ENABLE_GPU_SUPPORT` auf `true` setzen. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
+ Wenn Sie eine Aufgabe ausführen oder einen Service erstellen, können Sie beim Konfigurieren der Platzierungsbedingungen mithilfe von Attributen des Instance-Typs festlegen, für welche Ihrer Container-Instances die Aufgabe gestartet wird. Auf diese Weise können Sie Ihre Ressourcen effektiver verwenden. Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).
Das folgende Beispiel startet eine Aufgabe auf einer `g4dn.xlarge`-Container-Instance in Ihrem Standard-Cluster.
```
aws ecs run-task --cluster default --task-definition ecs-gpu-task-def \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == g4dn.xlarge" --region us-east-2
```
+ Für jeden Container, der eine in der Container-Definition festgelegte GPU-Ressourcenanforderung hat, legt Amazon ECS fest, dass die Container-Laufzeitumgebung die NVIDIA-Container-Laufzeitumgebung ist.
+ Die NVIDIA Container-Laufzeitumgebung erfordert, dass einige Umgebungsvariablen im Container festgelegt werden, damit sie korrekt funktioniert. Eine Liste dieser Umgebungsvariablen finden Sie unter [Spezialisierte Konfigurationen mit Docker](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable). Amazon ECS legt als Wert der `NVIDIA_VISIBLE_DEVICES` Umgebungsvariablen eine Liste des GPU-Geräts fest IDs , das Amazon ECS dem Container zuweist. Die anderen erforderlichen Umgebungsvariablen legt Amazon ECS nicht fest. Stellen Sie daher sicher, dass Ihr Container-Image sie festlegt oder dass sie in der Container-Definition festgelegt sind.
+ Die p5-Instance-Typ-Familie wird auf Version `20230929` und höher des Amazon-ECS GPU-optimierten AMI unterstützt.
+ Die g4-Instance-Typ-Familie wird auf Version `20230913` und höher des Amazon ECS GPU-optimierten AMI unterstützt. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md). Sie wird im Workflow „Cluster erstellen“ in der Amazon-ECS-Konsole nicht unterstützt. Um diese Instance-Typen zu verwenden, müssen Sie entweder die Amazon EC2 EC2-Konsole oder die API verwenden und die Instances manuell in Ihrem Cluster registrieren. AWS CLI
+ Der Instance-Typ p4d.24xlarge funktioniert nur mit CUDA 11 oder höher.
+ Das GPU-optimierte AMI von Amazon ECS wurde IPv6 aktiviert, was zu Problemen bei der Verwendung führt. `yum` Dieses Problem kann durch die Konfiguration für die Verwendung IPv4 mit `yum` dem folgenden Befehl behoben werden.
```
echo "ip_resolve=4" >> /etc/yum.conf
```
+ Wenn Sie ein Container-Image erstellen, das die NVIDIA/CUDA Basis-Images nicht verwendet, müssen Sie die `NVIDIA_DRIVER_CAPABILITIES` Container-Laufzeitvariable auf einen der folgenden Werte setzen:
+ `utility,compute`
+ `all`
Informationen zum Festlegen der Variablen finden Sie unter [Steuern der NVIDIA Container Runtime](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime) auf der NVIDIA-Website.
+ GPUs werden in Windows-Containern nicht unterstützt.
# Eine GPU-Container-Instance für Amazon ECS starten
Um eine GPU-Instance mit Amazon ECS in Amazon EC2 zu verwenden, müssen Sie eine Startvorlage und eine Benutzerdatendatei erstellen und die Instance starten.
Anschließend können Sie eine Aufgabe ausführen, die eine für GPU konfigurierte Aufgabendefinition verwendet.
## Verwenden einer Startvorlage
Sie können eine Startvorlage erstellen
+ Erstellen Sie eine Startvorlage, die die Amazon-ECS-optimierte GPU-AMI-ID für das AMI verwendet. Informationen zum Erstellen einer Startvorlage finden Sie unter [Erstellen einer neuen Startvorlage mithilfe von Parametern, die Sie definieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters) im *Amazon-EC2-Benutzerhandbuch*.
Verwenden Sie die AMI-ID aus dem vorherigen Schritt für das **Amazon Machine Image**. Informationen zur Angabe der AMI-ID mit dem Systems-Manager-Parameter finden Sie unter [Spezifizieren eines Systems-Manager-Parameters in einer Startvorlage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id) im *Amazon-EC2-Benutzerhandbuch*.
Fügen Sie den **Benutzerdaten** in der Startvorlage Folgendes hinzu. Ersetzen Sie *cluster-name* mit dem Namen Ihres Clusters.
```
#!/bin/bash
echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
```
## Verwenden Sie die AWS CLI
Sie können den verwenden AWS CLI , um die Container-Instance zu starten.
1. Erstellen Sie eine Datei mit dem Namen `userdata.toml`. Diese Datei wird für Instance-Benutzerdaten verwendet. Ersetzen Sie *cluster-name* mit dem Namen Ihres Clusters.
```
#!/bin/bash
echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
```
1. Führen Sie den folgenden Befehl aus, um die GPU-AMI-ID zu erhalten. Sie verwenden dies im folgenden Schritt.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```
1. Führen Sie den folgenden Befehl aus, um die GPU-Instance zu starten. Denken Sie daran, die folgenden Parameter zu ersetzen:
+ *subnet*Ersetzen Sie es durch die ID des privaten oder öffentlichen Subnetzes, in dem Ihre Instance gestartet wird.
+ *gpu\$1ami*Ersetzen Sie durch die AMI-ID aus dem vorherigen Schritt.
+ *t3.large*Ersetzen Sie durch den Instance-Typ, den Sie verwenden möchten.
+ *region*Ersetzen Sie durch den Regionalcode.
```
aws ec2 run-instances --key-name ecs-gpu-example \
--subnet-id subnet \
--image-id gpu_ami \
--instance-type t3.large \
--region region \
--tag-specifications 'ResourceType=instance,Tags=[{Key=GPU,Value=example}]' \
--user-data file://userdata.toml \
--iam-instance-profile Name=ecsInstanceRole
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Container-Instance im Cluster registriert ist. Denken Sie beim Ausführen dieses Befehls daran, die folgenden Parameter zu ersetzen:
+ Ersetzen Sie *cluster* mit Ihrem Clusternamen.
+ *region*Ersetzen Sie es durch Ihren Regionalcode.
```
aws ecs list-container-instances --cluster cluster-name --region region
```
# GPUs In einer Amazon ECS-Aufgabendefinition angeben
Um die GPUs On-a-Container-Instance und die Docker-GPU-Laufzeit zu verwenden, stellen Sie sicher, dass Sie in der Aufgabendefinition die Anzahl angeben, die GPUs Ihr Container benötigt. Wenn Container, die Unterstützung bieten, platziert GPUs werden, heftet der Amazon ECS-Container-Agent die gewünschte Anzahl GPUs an physischen Containern an den entsprechenden Container. Die Anzahl der für alle Container in einer Aufgabe GPUs reservierten Container darf die Anzahl der verfügbaren Container auf der Container-Instance, GPUs auf der die Aufgabe gestartet wird, nicht überschreiten. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
**Wichtig**
Wenn Ihre GPU-Anforderungen in der Aufgabendefinition nicht angegeben werden, verwendet die Aufgabe die Standard-Docker-Laufzeit.
Das folgende Beispiel zeigt das JSON-Format für die GPU-Anforderungen in einer Aufgabendefinition:
```
{
"containerDefinitions": [
{
...
"resourceRequirements" : [
{
"type" : "GPU",
"value" : "2"
}
],
},
...
}
```
Das folgende Beispiel veranschaulicht die Syntax eines Docker-Containers, der eine GPU-Anforderung angibt. Dieser Container verwendet zwei GPUs, führt das `nvidia-smi` Hilfsprogramm aus und wird dann beendet.
```
{
"containerDefinitions": [
{
"memory": 80,
"essential": true,
"name": "gpu",
"image": "nvidia/cuda:11.0.3-base",
"resourceRequirements": [
{
"type":"GPU",
"value": "2"
}
],
"command": [
"sh",
"-c",
"nvidia-smi"
],
"cpu": 100
}
],
"family": "example-ecs-gpu"
}
```
Die folgende Beispielaufgabendefinition zeigt einen TensorFlow Container, der die Anzahl der verfügbaren GPUs Objekte ausgibt. Die Aufgabe wird in Amazon ECS Managed Instances ausgeführt, benötigt eine GPU und verwendet eine `g4dn.xlarge`-Instance.
```
{
"family": "tensorflow-gpu",
"networkMode": "awsvpc",
"executionRoleArn": "arn:aws:iam::account-id:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"name": "tensorflow",
"image": "tensorflow/tensorflow:latest-gpu",
"essential": true,
"command": [
"python",
"-c",
"import tensorflow as tf; print('Num GPUs Available: ', len(tf.config.list_physical_devices('GPU')))"
],
"resourceRequirements": [
{
"type": "GPU",
"value": "1"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/tensorflow-gpu",
"awslogs-region": "region",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"requiresCompatibilities": [
"MANAGED_INSTANCES"
],
"cpu": "4096",
"memory": "8192",
}
```
## Teilen GPUs
Wenn Sie teilen möchten GPUs, müssen Sie Folgendes konfigurieren.
1. Entfernen Sie GPU-Ressourcenanforderungen aus Ihren Aufgabendefinitionen, sodass Amazon ECS keine Ressourcen reserviert GPUs , die gemeinsam genutzt werden sollten.
1. Fügen Sie Ihren Instances die folgenden Benutzerdaten hinzu, wenn Sie sie teilen möchten GPUs. Dadurch wird nvidia zur standardmäßigen Docker-Container-Laufzeit auf der Container-Instance, sodass alle Amazon ECS-Container die GPUs verwenden können. Weitere Informationen finden Sie unter [Ausführen von Befehlen beim Start einer EC2-Instance mit Benutzer-Dateneingabe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) im *Amazon-EC2-Benutzerhandbuch*.
```
const userData = ec2.UserData.forLinux();
userData.addCommands(
'sudo rm /etc/sysconfig/docker',
'echo DAEMON_MAXFILES=1048576 | sudo tee -a /etc/sysconfig/docker',
'echo OPTIONS="--default-ulimit nofile=32768:65536 --default-runtime nvidia" | sudo tee -a /etc/sysconfig/docker',
'echo DAEMON_PIDFILE_TIMEOUT=10 | sudo tee -a /etc/sysconfig/docker',
'sudo systemctl restart docker',
);
```
1. Legen Sie die `NVIDIA_VISIBLE_DEVICES`-Umgebungsvariable in Ihrem Container fest. Dazu können Sie die Umgebungsvariable in Ihrer Aufgabendefinition festlegen. Informationen zu den gültigen Werten finden Sie unter [GPU-Nummerierung](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration) auf der NVIDIA-Dokumentationsseite.
## Was tun, wenn Sie eine P2-Instance benötigen
Wenn Sie die P2-Instance verwenden müssen, können Sie eine der folgenden Optionen verwenden, um die Instances weiterhin zu verwenden.
Sie müssen die Benutzerdaten der Instance für beide Optionen ändern. Weitere Informationen finden Sie unter [Ausführen von Befehlen beim Start einer EC2-Instance mit Benutzer-Dateneingabe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) im *Amazon-EC2-Benutzerhandbuch*.
**Verwenden der zuletzt unterstützten GPU-optimierten AMI**
Sie können die `20230906`-Version des GPU-optimierten AMI verwenden und den Instance-Benutzerdaten Folgendes hinzufügen.
Ersetzen Sie cluster-name durch den Namen Ihres Clusters.
```
#!/bin/bash
echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf
echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
```
**Die aktuellsten GPU-optimierten AMI verwenden und die Benutzerdaten aktualisieren**
Sie können den Benutzerdaten der Instance Folgendes hinzufügen. Dadurch werden die Nvidia 535/Cuda12.2-Treiber deinstalliert und anschließend die Nvidia 470/Cuda11.4-Treiber installiert und die Version repariert.
```
#!/bin/bash
yum remove -y cuda-toolkit* nvidia-driver-latest-dkms*
tmpfile=$(mktemp)
cat >$tmpfile <
> /etc/yum.conf
nvidia-smi
```
**Ihr eigenes P2-kompatibles und GPU-optimiertes AMI erstellen**
Sie können Ihr eigenes benutzerdefiniertes GPU-optimiertes Amazon-ECS-AMI erstellen, das mit P2-Instances kompatibel ist, und dann P2-Instances mithilfe des AMI starten.
1. Führen Sie den folgenden Befehl aus, um das `amazon-ecs-ami repo` zu klonen.
```
git clone https://github.com/aws/amazon-ecs-ami
```
1. Stellen Sie die erforderlichen Amazon-ECS-Agent- und Amazon-Linux-AMI-Quellversionen in `release.auto.pkrvars.hcl` oder `overrides.auto.pkrvars.hcl` ein.
1. Führen Sie den folgenden Befehl aus, um ein privates P2-kompatibles EC2-AMI zu erstellen.
Ersetzen Sie Region durch die Region mit der Instance-Region.
```
REGION=region make al2keplergpu
```
1. Verwenden Sie das AMI mit den folgenden Instance-Benutzerdaten, um eine Verbindung zum Amazon-ECS-Cluster herzustellen.
Ersetzen Sie cluster-name durch den Namen Ihres Clusters.
```
#!/bin/bash
echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
```
# Amazon-ECS-Aufgabendefinitionen für Workloads zur Video-Transkodierung
Um Videotranskodierungs-Workloads auf Amazon ECS zu verwenden, registrieren Sie [Amazon](https://aws.amazon.com/ec2/instance-types/vt1/) EC2 EC2-Instances. VT1 Nachdem Sie diese Instances registriert haben, können Sie Live- und vorab gerenderte Video-Transcodierungs-Workloads als Aufgaben auf Amazon ECS ausführen. Amazon EC2 VT1 EC2-Instances verwenden Xilinx U30-Medientranscodierungskarten, um die Transcodierung von Live- und vorgerenderten Videos zu beschleunigen.
**Anmerkung**
Anleitungen für das Ausführen von Workloads zur Video-Transcodierung in anderen Containern als Amazon ECS finden Sie in der [Xilinx-Dokumentation](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1).
## Überlegungen
Bevor Sie mit VT1 der Bereitstellung auf Amazon ECS beginnen, sollten Sie Folgendes beachten:
+ Ihre Cluster können eine Mischung aus VT1 und VT1 Nicht-Instances enthalten.
+ Sie benötigen eine Linux-Anwendung, die Xilinx U30-Medientranscodierungskarten mit beschleunigten H.264/AVC- und H.265/HEVC-Codecs verwendet.
**Wichtig**
Anwendungen, die andere Codecs verwenden, weisen möglicherweise keine verbesserte Leistung auf Instances auf VT1 .
+ Nur eine Transcodierungsaufgabe kann auf einer U30-Karte ausgeführt werden. Jede Karte hat zwei Geräte, die damit verbunden sind. Sie können so viele Transcodierungsaufgaben ausführen, wie für jede Ihrer Instances Karten verfügbar sind. VT1
+ Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie beim Konfigurieren der Aufgabenplatzierungbedingungen Attribute des Instance-Typs verwenden. Dadurch wird sichergestellt, dass die Aufgabe auf der von Ihnen angegebenen Container-Instance gestartet wird. Auf diese Weise können Sie sicherstellen, dass Sie Ihre Ressourcen effektiv nutzen und dass Ihre Aufgaben für Videotranskodierungs-Workloads auf Ihren Instances liegen. VT1 Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).
Im folgenden Beispiel wird eine Aufgabe auf einer `vt1.3xlarge`-Instance auf Ihrem `default`-Cluster ausgeführt.
```
aws ecs run-task \
--cluster default \
--task-definition vt1-3xlarge-xffmpeg-processor \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == vt1.3xlarge"
```
+ Sie können einen Container so konfigurieren, dass er die spezifische U30-Karte verwendet, die auf der Host-Container-Instance verfügbar ist. Sie können dazu den `linuxParameters`-Parameter nutzen und die Geräteinformationen angeben. Weitere Informationen finden Sie unter [Anforderungen an die Aufgabendefinition](#ecs-vt1-requirements).
## Verwenden eines VT1 AMI
Sie haben zwei Möglichkeiten, ein AMI auf Amazon EC2 für Amazon-ECS-Container-Instances auszuführen. Die erste Option besteht darin, das offizielle Xilinx-AMI auf AWS Marketplace zu verwenden. Die zweite Option besteht darin, Ihr eigenes AMI aus dem Beispiel-Repository zu erstellen.
+ [Xilinx bietet AMIs ](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6) auf der. AWS Marketplace
+ Amazon ECS stellt ein Beispiel-Repository bereit, mit dem Sie ein AMI für Video-Transcodierungs-Workloads erstellen können. Dieses AMI wird mit Xilinx U30-Treibern geliefert. Sie finden das Repository, das Packer-Skripte enthält, auf. [GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline) Weitere Informationen zu Packer finden Sie in der [Packer-Dokumentation](https://developer.hashicorp.com/packer/docs).
## Anforderungen an die Aufgabendefinition
Um Video-Transcodierungscontainer auf Amazon ECS auszuführen, muss Ihre Aufgabendefinition eine Video-Transcodierungsanwendung enthalten, die die beschleunigten H.264/AVC- und H.265/HEVC-Codecs verwendet. Sie können ein Container-Image erstellen, indem Sie den Schritten auf dem [ GitHubXilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage) folgen.
Die Aufgabendefinition muss für den Instance-Typ spezifisch sein. Die Instance-Typen sind 3xlarge, 6xlarge und 24xlarge. Sie müssen einen Container so konfigurieren, dass er spezifische Xilinx U30-Geräte verwendet, die auf der Host-Container-Instance verfügbar sind. Dazu können Sie den `linuxParameters`-Parameter verwenden. In der folgenden Tabelle sind die Karten und Geräte aufgeführt SoCs , die für jeden Instance-Typ spezifisch sind.
| Instance-Typ | v CPUs | RAM (GiB) | U30 Accelerator-Karten | Adressierbare XCU30 SoC-Geräte | Gerätepfade |
| --- | --- | --- | --- | --- | --- |
| vt1.3xlarge | 12 | 24 | 1 | 2 | /dev/dri/renderD128,/dev/dri/renderD129 |
| vt1.6xlarge | 24 | 48 | 2 | 4 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131 |
| vt1.24xlarge | 96 | 182 | 8 | 16 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131,/dev/dri/renderD132,/dev/dri/renderD133,/dev/dri/renderD134,/dev/dri/renderD135,/dev/dri/renderD136,/dev/dri/renderD137,/dev/dri/renderD138,/dev/dri/renderD139,/dev/dri/renderD140,/dev/dri/renderD141,/dev/dri/renderD142,/dev/dri/renderD143 |
**Wichtig**
Wenn die Aufgabendefinition Geräte auflistet, die die EC2-Instance nicht hat, kann die Aufgabe nicht ausgeführt werden. Wenn die Aufgabe fehlschlägt, wird die folgende Fehlermeldung in `stoppedReason` angezeigt: `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory`.
# Angeben von Video-Transkodierung in einer Amazon-ECS-Aufgabendefinition
Im folgenden Beispiel sehen Sie die Syntax, die für eine Aufgabendefinition eines Linux-Containers auf Amazon EC2 verwendet wird. Diese Aufgabendefinition gilt für Container-Images, die gemäß dem Verfahren erstellt werden, das in der [Xilinx-Dokumentation](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage) beschrieben ist. Wenn Sie dieses Beispiel verwenden, ersetzen Sie `image` durch Ihr eigenes Image und kopieren Sie Ihre Videodateien in die Instance im `/home/ec2-user`-Verzeichnis.
------
#### [ vt1.3xlarge ]
1. Erstellen Sie eine Textdatei mit dem Namen `vt1-3xlarge-ffmpeg-linux.json` und dem folgenden Inhalt.
```
{
"family": "vt1-3xlarge-xffmpeg-processor",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == vt1.3xlarge"
}
],
"containerDefinitions": [
{
"entryPoint": [
"/bin/bash",
"-c"
],
"command": ["/video/ecs_ffmpeg_wrapper.sh"],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/dri/renderD128",
"hostPath": "/dev/dri/renderD128",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD129",
"hostPath": "/dev/dri/renderD129",
"permissions": [
"read",
"write"
]
}
]
},
"mountPoints": [
{
"containerPath": "/video",
"sourceVolume": "video_file"
}
],
"cpu": 0,
"memory": 12000,
"image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
"essential": true,
"name": "xilinix-xffmpeg"
}
],
"volumes": [
{
"name": "video_file",
"host": {"sourcePath": "/home/ec2-user"}
}
]
}
```
1. Registrieren Sie die Aufgabendefinition.
```
aws ecs register-task-definition --family vt1-3xlarge-xffmpeg-processor --cli-input-json file://vt1-3xlarge-xffmpeg-linux.json --region us-east-1
```
------
#### [ vt1.6xlarge ]
1. Erstellen Sie eine Textdatei mit dem Namen `vt1-6xlarge-ffmpeg-linux.json` und dem folgenden Inhalt.
```
{
"family": "vt1-6xlarge-xffmpeg-processor",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == vt1.6xlarge"
}
],
"containerDefinitions": [
{
"entryPoint": [
"/bin/bash",
"-c"
],
"command": ["/video/ecs_ffmpeg_wrapper.sh"],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/dri/renderD128",
"hostPath": "/dev/dri/renderD128",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD129",
"hostPath": "/dev/dri/renderD129",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD130",
"hostPath": "/dev/dri/renderD130",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD131",
"hostPath": "/dev/dri/renderD131",
"permissions": [
"read",
"write"
]
}
]
},
"mountPoints": [
{
"containerPath": "/video",
"sourceVolume": "video_file"
}
],
"cpu": 0,
"memory": 12000,
"image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
"essential": true,
"name": "xilinix-xffmpeg"
}
],
"volumes": [
{
"name": "video_file",
"host": {"sourcePath": "/home/ec2-user"}
}
]
}
```
1. Registrieren Sie die Aufgabendefinition.
```
aws ecs register-task-definition --family vt1-6xlarge-xffmpeg-processor --cli-input-json file://vt1-6xlarge-xffmpeg-linux.json --region us-east-1
```
------
#### [ vt1.24xlarge ]
1. Erstellen Sie eine Textdatei mit dem Namen `vt1-24xlarge-ffmpeg-linux.json` und dem folgenden Inhalt.
```
{
"family": "vt1-24xlarge-xffmpeg-processor",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == vt1.24xlarge"
}
],
"containerDefinitions": [
{
"entryPoint": [
"/bin/bash",
"-c"
],
"command": ["/video/ecs_ffmpeg_wrapper.sh"],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/dri/renderD128",
"hostPath": "/dev/dri/renderD128",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD129",
"hostPath": "/dev/dri/renderD129",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD130",
"hostPath": "/dev/dri/renderD130",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD131",
"hostPath": "/dev/dri/renderD131",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD132",
"hostPath": "/dev/dri/renderD132",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD133",
"hostPath": "/dev/dri/renderD133",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD134",
"hostPath": "/dev/dri/renderD134",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD135",
"hostPath": "/dev/dri/renderD135",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD136",
"hostPath": "/dev/dri/renderD136",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD137",
"hostPath": "/dev/dri/renderD137",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD138",
"hostPath": "/dev/dri/renderD138",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD139",
"hostPath": "/dev/dri/renderD139",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD140",
"hostPath": "/dev/dri/renderD140",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD141",
"hostPath": "/dev/dri/renderD141",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD142",
"hostPath": "/dev/dri/renderD142",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD143",
"hostPath": "/dev/dri/renderD143",
"permissions": [
"read",
"write"
]
}
]
},
"mountPoints": [
{
"containerPath": "/video",
"sourceVolume": "video_file"
}
],
"cpu": 0,
"memory": 12000,
"image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
"essential": true,
"name": "xilinix-xffmpeg"
}
],
"volumes": [
{
"name": "video_file",
"host": {"sourcePath": "/home/ec2-user"}
}
]
}
```
1. Registrieren Sie die Aufgabendefinition.
```
aws ecs register-task-definition --family vt1-24xlarge-xffmpeg-processor --cli-input-json file://vt1-24xlarge-xffmpeg-linux.json --region us-east-1
```
------
# Amazon ECS-Aufgabendefinitionen für AWS Neuron-Workloads für maschinelles Lernen
Sie können [Amazon EC2 Trn1-, Amazon EC2 Trn2](https://aws.amazon.com/ec2/instance-types/trn1/) -, [Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn2/) [Inf1- und [Amazon EC2 Inf2-Instances](https://aws.amazon.com/ec2/instance-types/inf2/)](https://aws.amazon.com/ec2/instance-types/inf1/) in Ihren Clustern für maschinelles Lernen registrieren.
[Amazon EC2 Trn1- und Trn2-Instances werden mit Trainium-Chips betrieben.AWS](https://aws.amazon.com/ai/machine-learning/trainium/) Diese Instances bieten leistungsstarkes und kostengünstiges Training für Machine Learning in der Cloud. Sie können ein Inferenzmodell für maschinelles Lernen mithilfe eines Frameworks für maschinelles Lernen mit AWS Neuron auf einer Trn1- oder Trn2-Instance trainieren. Anschließend können Sie das Modell auf einer Inf1-Instanz oder einer Inf2-Instanz ausführen, um die Beschleunigung der Inferentia-Chips zu nutzen. AWS
Die Amazon-EC2-Instances Inf1 und Inf2 werden von [AWS -Inferentia-Chips](https://aws.amazon.com/ai/machine-learning/inferentia/) angetrieben. Sie bieten hohe Leistung und niedrigste Kosten für Inferenzen in der Cloud.
Machine-Learning-Modelle werden auf Containern mit [AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/) bereitgestellt, einem spezialisierten Software Developer Kit (SDK). Das SDK besteht aus einem Compiler, Runtime- und Profiling-Tools, die die Leistung von Machine-Learning-Chips für maschinelles Lernen optimieren. AWS AWS Neuron unterstützt beliebte Frameworks für maschinelles Lernen wie TensorFlow PyTorch, und Apache. MXNet
## Überlegungen
Berücksichtigen Sie Folgendes, bevor Sie mit der Bereitstellung von Neuron auf Amazon ECS beginnen:
+ Ihre Cluster können eine Mischung aus Trn1, Trn2, Inf1, Inf2 und anderen Instances enthalten.
+ Sie benötigen eine Linux-Anwendung in einem Container, der ein Framework für maschinelles Lernen verwendet, das Neuron unterstützt. AWS
**Wichtig**
Anwendungen, die andere Frameworks verwenden, weisen möglicherweise keine verbesserte Leistung auf Trn1-, Trn2-, Inf1- und Inf2-Instances auf.
+ Auf jedem [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)- oder [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)-Chip kann nur eine Inferenz- oder Inferenztrainingsaufgabe ausgeführt werden. Bei Inf1 hat jeder Chip 4. NeuronCores Für Trn1, Trn2 und Inf2 hat jeder Chip 2. NeuronCores Sie können so viele Aufgaben ausführen, wie Chips für jede Ihrer Trn1-, Trn2-, Inf1- und Inf2-Instances vorhanden sind.
+ Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie beim Konfigurieren der Aufgabenplatzierungbedingungen Attribute des Instance-Typs verwenden. Dadurch wird sichergestellt, dass die Aufgabe auf der von Ihnen angegebenen Container-Instance gestartet wird. Auf diese Weise können Sie die allgemeine Ressourcennutzung optimieren und sicherstellen, dass Aufgaben für Inferenz-Workloads auf Ihren Trn1-, Trn2-, Inf1- und Inf2-Instances ausgeführt werden. Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).
Im folgenden Beispiel wird eine Aufgabe auf einer `Inf1.xlarge`-Instance auf Ihrem `default`-Cluster ausgeführt.
```
aws ecs run-task \
--cluster default \
--task-definition ecs-inference-task-def \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == Inf1.xlarge"
```
+ Ressourcenanforderungen für Neuron können in einer Aufgabendefinition nicht definiert werden. Stattdessen konfigurieren Sie einen Container so, dass er bestimmte AWS Trainium- oder Inferentia-Chips verwendet, die auf der Host-Container-Instance verfügbar sind. AWS Nutzen Sie dazu den `linuxParameters`-Parameter und geben Sie die Geräteinformationen an. Weitere Informationen finden Sie unter [Anforderungen an die Aufgabendefinition](#ecs-inference-requirements).
## Das Amazon-ECS-optimierte AMI für Amazon Linux 2023 (Neuron) verwenden
Amazon ECS bietet ein für Amazon ECS optimiertes AMI, das auf Amazon Linux 2023 für AWS Trainium- und AWS Inferentia-Workloads basiert. Es wird mit den AWS Neuron-Treibern und der Laufzeit für Docker geliefert. Dieses AMI erleichtert das Ausführen von Machine Learning Inferenz-Workloads auf Amazon ECS.
Wir empfehlen, das Amazon-ECS-optimierte AMI für Amazon Linux 2023 (Neuron) zu verwenden, wenn Sie Ihre Amazon-EC2-Trn1-, -Inf1- und -Inf2-Instances starten.
Sie können das aktuelle Amazon ECS-optimierte Amazon Linux 2023 (Neuron) AMI AWS CLI mit dem folgenden Befehl abrufen.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended
```
## Anforderungen an die Aufgabendefinition
Um Neuron auf Amazon ECS bereitzustellen, muss Ihre Aufgabendefinition die Container-Definition für einen vorgefertigten Container enthalten, für den das Inferenzmodell verwendet wird. TensorFlow Es wird von AWS Deep Learning Containers bereitgestellt. Dieser Container enthält die AWS Neuron-Runtime und die TensorFlow Serving-Anwendung. Beim Start ruft dieser Container Ihr Modell von Amazon S3 ab, startet Neuron TensorFlow Serving mit dem gespeicherten Modell und wartet auf Vorhersageanfragen. Im folgenden Beispiel hat das Container-Image TensorFlow 1.15 und Ubuntu 18.04. Eine vollständige Liste vorgefertigter Deep Learning Containers, die für Neuron optimiert sind, wird auf geführt. GitHub Weitere Informationen finden Sie unter [AWS Neuron TensorFlow Serving verwenden](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-inferentia-tf-neuron-serving.html).
```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04
```
Alternativ können Sie Ihr eigenes Neuron Seitenwagen Container-Image erstellen. Weitere Informationen finden Sie unter [Tutorial: Neuron TensorFlow Serving](https://github.com/aws-neuron/aws-neuron-sdk/blob/master/frameworks/tensorflow/tensorflow-neuron/tutorials/tutorials-tensorflow-utilizing-neuron-capabilities.rst) im *AWS Deep Learning AMIs Entwicklerhandbuch*.
Die Aufgabendefinition muss für den einzelnen Instance-Typ spezifisch sein. Sie müssen einen Container so konfigurieren, dass er bestimmte AWS Trainium- oder AWS Inferentia-Geräte verwendet, die auf der Host-Container-Instance verfügbar sind. Dazu können Sie den `linuxParameters`-Parameter verwenden. Ein Beispiel für eine Aufgabendefinition finden Sie unter. [Spezifizierung des maschinellen Lernens mit AWS Neuron in einer Amazon ECS-Aufgabendefinition](ecs-inference-task-def.md) In der folgenden Tabelle sind die Chips aufgeführt, die für jeden Instance-Typ spezifisch sind.
| Instance-Typ | v CPUs | RAM (GiB) | AWS ML-Beschleunigerchips | Gerätepfade |
| --- | --- | --- | --- | --- |
| trn1.2xlarge | 8 | 32 | 1 | /dev/neuron0 |
| trn1.32xlarge | 128 | 512 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 |
| trn2.48xlarge | 192 | 1536 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 |
| inf1.xlarge | 4 | 8 | 1 | /dev/neuron0 |
| inf1.2xlarge | 8 | 16 | 1 | /dev/neuron0 |
| inf1.6xlarge | 24 | 48 | 4 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3 |
| inf1.24xlarge | 96 | 192 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 |
| inf2.xlarge | 8 | 16 | 1 | /dev/neuron0 |
| inf2.8xlarge | 32 | 64 | 1 | /dev/neuron0 |
| inf2.24xlarge | 96 | 384 | 6 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, |
| inf2.48xlarge | 192 | 768 | 12 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11 |
# Spezifizierung des maschinellen Lernens mit AWS Neuron in einer Amazon ECS-Aufgabendefinition
Nachfolgend finden Sie ein Beispiel der Linux-Aufgabendefinition für `inf1.xlarge`, das die zu verwendende Syntax anzeigt.
```
{
"family": "ecs-neuron",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == inf1.xlarge"
}
],
"executionRoleArn": "${YOUR_EXECUTION_ROLE}",
"containerDefinitions": [
{
"entryPoint": [
"/usr/local/bin/entrypoint.sh",
"--port=8500",
"--rest_api_port=9000",
"--model_name=resnet50_neuron",
"--model_base_path=s3://amzn-s3-demo-bucket/resnet50_neuron/"
],
"portMappings": [
{
"hostPort": 8500,
"protocol": "tcp",
"containerPort": 8500
},
{
"hostPort": 8501,
"protocol": "tcp",
"containerPort": 8501
},
{
"hostPort": 0,
"protocol": "tcp",
"containerPort": 80
}
],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/neuron0",
"hostPath": "/dev/neuron0",
"permissions": [
"read",
"write"
]
}
],
"capabilities": {
"add": [
"IPC_LOCK"
]
}
},
"cpu": 0,
"memoryReservation": 1000,
"image": "763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04",
"essential": true,
"name": "resnet50"
}
]
}
```
# Amazon-ECS-Aufgabendefinitionen für Deep-Learning-Instances
Um Deep-Learning-Workloads auf Amazon ECS zu verwenden, registrieren Sie [Amazon EC2 DL1 EC2-Instances](https://aws.amazon.com/ec2/instance-types/dl1/) in Ihren Clustern. Amazon EC2 DL1 EC2-Instances werden von Gaudi-Beschleunigern von Habana Labs (einem Unternehmen von Intel) unterstützt. Verwenden Sie das Habana SynapSeai SDK, um eine Verbindung zu den Habana Gaudi-Accelerators herzustellen. Das SDK unterstützt die beliebten Frameworks für maschinelles Lernen und. TensorFlow PyTorch
## Überlegungen
Bevor Sie mit DL1 der Bereitstellung auf Amazon ECS beginnen, sollten Sie Folgendes beachten:
+ Ihre Cluster können eine Mischung aus DL1 und DL1 Nicht-Instances enthalten.
+ Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie insbesondere beim Konfigurieren der Aufgabenplatzierungsbedingungen sicherstellen, dass Ihre Aufgabe auf der von Ihnen angegebenen Container-Instance gestartet wird. Dadurch wird sichergestellt, dass Ihre Ressourcen effektiv genutzt werden und dass Ihre Aufgaben für Deep-Learning-Workloads auf Ihren DL1 Instanzen liegen. Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).
Im folgenden Beispiel wird eine Aufgabe für eine `dl1.24xlarge`-Instance auf Ihrem `default`-Cluster ausgeführt.
```
aws ecs run-task \
--cluster default \
--task-definition ecs-dl1-task-def \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == dl1.24xlarge"
```
## Verwenden eines DL1 AMI
Sie haben drei Möglichkeiten, ein AMI auf Amazon EC2 DL1 EC2-Instances für Amazon ECS auszuführen:
+ AWS Marketplace AMIs [die von Habana hier bereitgestellt werden.](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq)
+ Habana Deep Learning AMIs , die von Amazon Web Services bereitgestellt werden. Weil er nicht enthalten ist, müssen Sie den Amazon-ECS-Container-Agent separat installieren.
+ Verwenden Sie Packer, um ein benutzerdefiniertes AMI zu erstellen, das vom [GitHubRepo](https://github.com/aws-samples/aws-habana-baseami-pipeline) bereitgestellt wird. Weitere Informationen finden Sie in der [Packer-Dokumentation](https://developer.hashicorp.com/packer/docs).
# Angeben von Deep Learning in einer Amazon-ECS-Aufgabendefinition
Um beschleunigte Deep Learning-Container von Habana Gaudi auf Amazon ECS auszuführen, muss Ihre Aufgabendefinition die Containerdefinition für einen vorgefertigten Container enthalten, der das Deep-Learning-Modell für TensorFlow oder PyTorch mithilfe von Habana SynapseAI bedient, das von Deep Learning Containers bereitgestellt wird. AWS
Das folgende Container-Image hat 2.7.0 und Ubuntu 20.04. TensorFlow Eine vollständige Liste vorgefertigter Deep Learning Containers, die für die Gaudi-Beschleuniger von Habana optimiert sind, wird auf geführt. GitHub Weitere Informationen finden Sie unter [Habana Training Containers](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers).
```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-training-habana:2.7.0-hpu-py38-synapseai1.2.0-ubuntu20.04
```
Nachfolgend finden Sie ein Beispiel für eine Aufgabendefinition für Linux-Container auf Amazon EC2, das die zu verwendende Syntax veranschaulicht. In diesem Beispiel wird ein Image verwendet, das das Habana Labs System Management Interface Tool (HL-SMI) enthält, das hier zu finden ist: `vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614`
```
{
"family": "dl-test",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == dl1.24xlarge"
}
],
"networkMode": "host",
"cpu": "10240",
"memory": "1024",
"containerDefinitions": [
{
"entryPoint": [
"sh",
"-c"
],
"command": ["hl-smi"],
"cpu": 8192,
"environment": [
{
"name": "HABANA_VISIBLE_DEVICES",
"value": "all"
}
],
"image": "vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614",
"essential": true,
"name": "tensorflow-installer-tf-hpu"
}
]
}
```
# Amazon-ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads
Amazon ECS unterstützt die Verwendung von 64-Bit-ARM-Anwendungen. Sie können Ihre Anwendungen auf der Plattform ausführen, die von [AWS -Graviton-Prozessoren](https://aws.amazon.com/ec2/graviton/) unterstützt wird. Sie ist für eine Vielzahl von Workloads geeignet. Dazu gehören Workloads wie Anwendungsserver, Microservices, Hochleistungs-Computing, CPU-basierte Machine Learning-Inferenz, Videocodierung, elektronische Designautomatisierung, Spiele, Open-Source-Datenbanken und In-Memory-Caches.
## Überlegungen
Beachten Sie die Folgendes, bevor Sie damit beginnen, Aufgabendefinitionen bereitzustellen, die die 64-Bit-ARM-Architektur verwenden:
+ Die Anwendungen können das Fargate oder EC2s verwenden.
+ Die Anwendungen können nur das Linux-Betriebssystem verwenden.
+ Für den Fargate-Typ müssen die Anwendungen die Fargate-Plattformversion `1.4.0` oder höher verwenden.
+ Die Anwendungen können Fluent Bit oder CloudWatch zur Überwachung verwenden.
+ Für Fargate unterstützen die folgenden Programme AWS-Regionen keine 64-Bit-ARM-Workloads:
+ USA Ost (Nord-Virginia), die `use1-az3` Availability Zone
+ Für EC2, beachten Sie Folgendes, um zu überprüfen, ob die Region, in der Sie sich befinden, den gewünschten Instance-Typ unterstützt:
+ [Amazon-EC2-M6g-Instances](https://aws.amazon.com/ec2/instance-types/m6)
+ [Amazon-EC2-T4g-Instances](https://aws.amazon.com/ec2/instance-types/t4/)
+ [Amazon-EC2-C6g-Instances](https://aws.amazon.com/ec2/instance-types/c6g/)
+ [Amazon-EC2-R6gd-Instances](https://aws.amazon.com/ec2/instance-types/r6/)
+ [Amazon-EC2-X2gd-Instances](https://aws.amazon.com/ec2/instance-types/x2/)
Sie können auch den Amazon-EC2-Befehl `describe-instance-type-offerings` mit einem Filter verwenden, um das Instance-Angebot für Ihre Region anzuzeigen.
```
aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=instance-type --region region
```
Im folgenden Beispiel wird die Verfügbarkeit des M6-Instance-Typs in der Region USA Ost (Nord-Virginia) (us-east-1) überprüft.
```
aws ec2 describe-instance-type-offerings --filters "Name=instance-type,Values=m6*" --region us-east-1
```
Weitere Informationen finden Sie [describe-instance-type-offerings ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)in der *Amazon EC2 EC2-Befehlszeilenreferenz.*
# Angeben der ARM-Architektur in einer Amazon-ECS-Aufgabendefinition
Um die ARM-Architektur zu verwenden, geben Sie `ARM64` für den Aufgabendefinitions-Parameter `cpuArchitecture` an.
Im folgenden Beispiel wird die ARM-Architektur in einer Aufgabendefinition angegeben. Sie ist im JSON-Format.
```
{
"runtimePlatform": {
"operatingSystemFamily": "LINUX",
"cpuArchitecture": "ARM64"
},
...
}
```
Im folgenden Beispiel zeigt eine Aufgabendefinition für die ARM-Architektur „Hallo Welt“ an.
```
{
"family": "arm64-testapp",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "arm-container",
"image": "public.ecr.aws/docker/library/busybox:latest",
"cpu": 100,
"memory": 100,
"essential": true,
"command": [ "echo hello world" ],
"entryPoint": [ "sh", "-c" ]
}
],
"requiresCompatibilities": [ "EC2" ],
"cpu": "256",
"memory": "512",
"runtimePlatform": {
"operatingSystemFamily": "LINUX",
"cpuArchitecture": "ARM64"
},
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```
# Amazon ECS-Protokolle senden an CloudWatch
Sie können die Container in Ihren Aufgaben so konfigurieren, dass Protokollinformationen an CloudWatch Logs gesendet werden. Wenn Sie Fargate für Ihre Aufgaben verwenden, können Sie die Protokolle von Ihren Containern anzeigen. Wenn Sie EC2 verwenden, können Sie verschiedene Protokolle Ihrer Container bequem an einem Ort aufrufen und es wird verhindert, dass Ihre Container-Protokolle Speicherplatz in Ihren Container-Instances belegen.
**Anmerkung**
Der Typ der Informationen, die von den Containern in Ihrer Aufgabe protokolliert werden, hängt sehr stark von ihrem `ENTRYPOINT`-Befehl ab. Standardmäßig zeigen die erfassten Protokolle die Befehlsausgabe an, die Sie normalerweise in einem interaktiven Terminal sehen würden, wenn Sie den Container lokal ausführen. Dabei handelt es sich um die `STDOUT`- und `STDERR`-E/A-Streams. Der `awslogs` Protokolltreiber leitet diese Protokolle einfach von Docker an CloudWatch Logs weiter. Weitere Informationen dazu, wie Docker-Protokolle verarbeitet werden, einschließlich alternativer Möglichkeiten zum Erfassen unterschiedlicher Dateidaten oder Streams, finden Sie unter [Anzeigen von Protokollen für einen Container oder Service](https://docs.docker.com/engine/logging/) in der Docker-Dokumentation.
Informationen zum Senden von Systemprotokollen von Ihren Amazon ECS-Container-Instances an CloudWatch Logs finden Sie unter [Überwachung von Protokolldateien](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) und [CloudWatch Protokollkontingenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
## Fargate
Wenn Sie Fargate für Ihre Aufgaben verwenden, müssen Sie für die Aktivierung des `awslogs`-Protokolltreibers die erforderlichen `logConfiguration`-Parameter in Ihre Aufgabendefinition einfügen. Weitere Informationen finden Sie unter [Beispiel für eine Amazon ECS-Aufgabendefinition: Protokolle weiterleiten an CloudWatch](specify-log-config.md).
Führen Sie für Windows-Container in uf Fargate eine der folgenden Optionen aus, wenn einer Ihrer Aufgabendefinitions-Parameter Sonderzeichen wie `& \ < > ^ |` enthält:
+ Fügen Sie ein Escape-Zeichen (`\`) mit doppelten Anführungszeichen um die gesamte Parameterzeichenfolge.
Beispiel
```
"awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"",
```
+ Fügen Sie ein Escape-Zeichen (`^`) vor und nach jedem Sonderzeichen hinzu.
Beispiel
```
"awslogs-multiline-pattern": "^^[^|DEBUG^|INFO^|WARNING^|ERROR",
```
## EC2
Wenn Sie EC2 für Ihre Aufgaben verwenden und den Protokolltreiber `awslogs` aktivieren möchten, benötigen Ihre Amazon-ECS-Container-Instances mindestens Version 1.9.0 des Container-Agenten. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
**Anmerkung**
Sie müssen entweder ein Amazon-ECS-optimiertes AMI oder ein benutzerdefiniertes AMI mit mindestens einer Version `1.9.0-1` des `ecs-init` Pakets verwenden. Wenn Sie ein benutzerdefiniertes AMI verwenden, müssen Sie angeben, dass der `awslogs`-Protokolltreiber auf der Amazon-EC2-Instance verfügbar ist, wenn Sie den Agenten starten, indem Sie die folgende Umgebungsvariable in Ihrer **docker run**-Anweisung oder Umgebungsvariablendatei verwenden.
```
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
```
Ihre Amazon-ECS-Container-Instances benötigen auch eine `logs:CreateLogStream`- und `logs:PutLogEvents`-Berechtigung für die IAM-Rolle, mit der Sie Ihre Container-Instances starten. Wenn Sie die Amazon-ECS-Container-Instance-Rolle erstellt haben, bevor die Unterstützung des Protokolltreibers `awslogs` in Amazon ECS aktiviert war, müssen Sie diese Berechtigung eventuell hinzufügen. Die `ecsTaskExecutionRole` wird verwendet, wenn sie der Aufgabe zugewiesen ist und wahrscheinlich die richtigen Berechtigungen enthält. Weitere Informationen zur Aufgabenausführungsrolle finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md). Wenn Ihre Container-Instances die verwaltete IAM-Richtlinie für Container-Instances verwenden, verfügen sie wahrscheinlich über die korrekten Berechtigungen. Informationen zu der verwalteten IAM-Richtlinie für Container-Instances finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
# Beispiel für eine Amazon ECS-Aufgabendefinition: Protokolle weiterleiten an CloudWatch
Bevor Ihre Container Protokolle an senden können CloudWatch, müssen Sie den `awslogs` Protokolltreiber für Container in Ihrer Aufgabendefinition angeben. Weitere Informationen zu den Protokollparametern finden Sie unter [Speicher und Protokollierung](task_definition_parameters.md#container_definition_storage).
Bei der unten gezeigten Aufgabendefinition JSON wurde ein `logConfiguration`-Objekt für jeden Container festgelegt. Einer davon ist für den WordPress Container, der Protokolle an eine Protokollgruppe namens sendet`awslogs-wordpress`. Das andere für einen MySQL-Container, der Protokolle an eine Protokollgruppe mit dem Namen `awslogs-mysql` sendet. Beide Container verwenden den Protokoll-Stream-Präfix `awslogs-example`.
```
{
"containerDefinitions": [
{
"name": "wordpress",
"links": [
"mysql"
],
"image": "public.ecr.aws/docker/library/wordpress:latest",
"essential": true,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "awslogs-wordpress",
"awslogs-region": "us-west-2",
"awslogs-stream-prefix": "awslogs-example"
}
},
"memory": 500,
"cpu": 10
},
{
"environment": [
{
"name": "MYSQL_ROOT_PASSWORD",
"value": "password"
}
],
"name": "mysql",
"image": "public.ecr.aws/docker/library/mysql:latest",
"cpu": 10,
"memory": 500,
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "awslogs-mysql",
"awslogs-region": "us-west-2",
"awslogs-stream-prefix": "awslogs-example",
"mode": "non-blocking",
"max-buffer-size": "25m"
}
}
}
],
"family": "awslogs-example"
}
```
## Nächste Schritte
+ Sie können optional mithilfe der API CloudWatch AWS CLI oder eine Aufbewahrungsrichtlinie für die Protokollgruppe festlegen. Weitere Informationen finden Sie unter [put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) in der *AWS Command Line Interface -Referenz*.
+ Nachdem Sie eine Aufgabendefinition mit dem `awslogs` Protokolltreiber in einer Protokollkonfiguration für Containerdefinitionen registriert haben, können Sie eine Aufgabe ausführen oder einen Dienst mit dieser Aufgabendefinition erstellen, um mit dem Senden von Protokollen an Logs zu CloudWatch beginnen. Weitere Informationen erhalten Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md) und [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md).
# Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner
Sie können Amazon ECS verwenden FireLens , um Aufgabendefinitionsparameter zu verwenden, um Protokolle zur Protokollspeicherung und Analyse an ein AWS Service- oder AWS Partner Network (APN-) Ziel weiterzuleiten. The AWS Partner Network ist eine globale Partnergemeinschaft, die Programme, Fachwissen und Ressourcen nutzt, um Kundenangebote aufzubauen, zu vermarkten und zu verkaufen. Weitere Informationen finden Sie unter [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens arbeitet mit [Fluentd](https://www.fluentd.org/) und [Fluent Bit](https://fluentbit.io/). Wir stellen AWS für das Fluent Bit-Image bereit oder Sie können Ihr eigenes Fluentd- oder Fluent Bit-Image verwenden.
Standardmäßig konfiguriert Amazon ECS die Container-Abhängigkeit so, dass der Firelens-Container vor jedem Container gestartet wird, der ihn verwendet. Der Firelens-Container stoppt auch, nachdem alle Container, die ihn verwenden, angehalten sind.
Um diese Funktion nutzen zu können, müssen Sie eine IAM-Rolle für Ihre Aufgaben erstellen, die für die Nutzung aller AWS Dienste erforderlich sind, die für die Aufgaben erforderlich sind. Wenn ein Container beispielsweise Protokolle an Firehose weiterleitet, erfordert die Aufgabe die Berechtigung zum Aufrufen der `firehose:PutRecordBatch`-API. Informationen finden Sie im Abschnitt [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
Unter den folgenden Bedingungen kann für Ihre Aufgabe auch die Amazon-ECS-Aufgabenausführungsrolle erforderlich sein. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
+ Wenn Ihre Aufgabe auf Fargate gehostet wird und Sie Container-Images aus Amazon ECR abrufen oder sensible Daten aus AWS Secrets Manager Ihrer Protokollkonfiguration referenzieren, müssen Sie die IAM-Rolle für die Aufgabenausführung angeben.
+ Wenn Sie eine benutzerdefinierte Konfigurationsdatei verwenden, die in Amazon S3 gehostet wird, muss Ihre IAM-Rolle für die Aufgabenausführung die `s3:GetObject`-Berechtigung enthalten.
Beachten Sie bei der Verwendung FireLens für Amazon ECS Folgendes:
+ Wir empfehlen, dass Sie dem Protokoll `my_service_` den Namen des Protokoll-Containers hinzufügen, damit Sie die Container-Namen in der Konsole leicht unterscheiden können.
+ Amazon ECS fügt standardmäßig eine Start-Abhängigkeit zwischen den Anwendungs-Containern und dem FireLens-Container hinzu. Wenn Sie eine Container-Reihenfolge zwischen den Anwendungscontainern und dem FireLens-Container angeben, wird die standardmäßige Reihenfolge der Startcontainer außer Kraft gesetzt.
+ FireLens für Amazon ECS wird für Aufgaben unterstützt, die sowohl auf AWS Fargate unter Linux als auch auf Amazon EC2 unter Linux gehostet werden. Windows-Container unterstützen FireLens nicht.
Informationen zur Konfiguration der zentralen Protokollierung für Windows-Container finden Sie unter [Zentralisierte Protokollierung für Windows-Container auf Amazon ECS mit Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/).
+ Sie können CloudFormation Vorlagen zur Konfiguration FireLens für Amazon ECS verwenden. Weitere Informationen finden Sie [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)im *AWS CloudFormation Benutzerhandbuch*
+ FireLensüberwacht den Port. Um also sicherzustellen`24224`, dass der FireLens Log Router außerhalb der Aufgabe nicht erreichbar ist, dürfen Sie keinen eingehenden Verkehr über den Port `24224` in der Sicherheitsgruppe zulassen, die Ihre Aufgabe verwendet. Für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, ist dies die der Aufgabe zugeordnete Sicherheitsgruppe. Für Aufgaben, die den `host`-Netzwerkmodus verwenden, ist dies die Sicherheitsgruppe, die der Amazon-EC2-Instance zugeordnet ist, die die Aufgabe hostet. Für Aufgaben, die den `bridge`-Netzwerkmodus verwenden, erstellen Sie keine Portzuordnungen, die Port `24224` verwenden.
+ Bei Aufgaben, die den `bridge` Netzwerkmodus verwenden, muss der Container mit der FireLens Konfiguration vor allen Anwendungscontainern, die darauf angewiesen sind, gestartet werden. Um die Startreihenfolge Ihrer Container zu steuern, verwenden Sie Abhängigkeitsbedingungen in der Aufgabendefinition. Weitere Informationen finden Sie unter [Container-Abhängigkeit](task_definition_parameters.md#container_definition_dependson).
**Anmerkung**
Wenn Sie Parameter für Abhängigkeitsbedingungen in Containerdefinitionen mit einer FireLens Konfiguration verwenden, stellen Sie sicher, dass für jeden Container eine `START` `HEALTHY` Oder-Bedingung erforderlich ist.
+ FireLensFügt standardmäßig den Namen der Cluster- und Aufgabendefinition sowie den Amazon-Ressourcennamen (ARN) des Clusters als Metadatenschlüssel zu Ihren stdout/stderr Container-Logs hinzu. Nachfolgend ist ein Beispiel für das Metadatenformat.
```
"ecs_cluster": "cluster-name",
"ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE",
"ecs_task_definition": "task-def-name:revision",
```
Wenn Sie die Metadaten nicht in Ihren Protokollen haben möchten, setzen Sie `enable-ecs-log-metadata` zu `false` im `firelensConfiguration`-Abschnitt der Aufgabendefinition.
```
"firelensConfiguration":{
"type":"fluentbit",
"options":{
"enable-ecs-log-metadata":"false",
"config-file-type":"file",
"config-file-value":"/extra.conf"
}
```
Sie können den FireLens Container so konfigurieren, dass er als Benutzer ausgeführt wird, der kein Root-Benutzer ist. Berücksichtigen Sie dabei Folgendes:
+ Um den FireLens Container so zu konfigurieren, dass er als Nicht-Root-Benutzer ausgeführt wird, müssen Sie den Benutzer in einem der folgenden Formate angeben:
+ `uid`
+ `uid:gid`
+ `uid:group`
Weitere Informationen zur Angabe eines Benutzers in einer Container-Definition finden Sie [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)in der *Amazon Elastic Container Service API-Referenz*.
Der FireLens Container empfängt Anwendungsprotokolle über einen UNIX Socket. Der Amazon ECS-Agent verwendet den`uid`, um dem FireLens Container den Besitz des Socket-Verzeichnisses zuzuweisen.
+ Die Konfiguration des FireLens Containers für die Ausführung als Nicht-Root-Benutzer wird in der Amazon ECS-Agent-Version `1.96.0` und höher sowie in der Amazon ECS-optimierten AMI-Version `v20250716` und höher unterstützt.
+ Wenn Sie einen Benutzer für den FireLens Container angeben, muss dieser eindeutig sein und `uid` darf nicht für andere Prozesse verwendet werden, die zu anderen Containern in der Aufgabe oder der Container-Instance gehören.
Informationen zur Verwendung mehrerer Konfigurationsdateien mit Amazon ECS, einschließlich Dateien, die Sie hosten, oder Dateien in Amazon S3, finden Sie unter [Init-Prozess für Fluent Bit in ECS, Unterstützung für mehrfache Konfigurationen](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit).
Informationen zu Beispielkonfigurationen finden Sie unter[Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten](firelens-taskdef.md).
Weitere Informationen zur Konfiguration von Protokollen für hohen Durchsatz finden Sie unter[Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).
# Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz
Für Szenarien mit hohem Protokolldurchsatz empfehlen wir, den `awsfirelens` Protokolltreiber mit FireLens und zu verwenden. Fluent Bit Fluent Bitist ein leichter Protokollprozessor, der effizient mit Ressourcen umgeht und Millionen von Protokolldatensätzen verarbeiten kann. Um eine optimale Leistung im großen Maßstab zu erreichen, ist jedoch eine Anpassung der Konfiguration erforderlich.
In diesem Abschnitt werden fortgeschrittene Fluent Bit Optimierungstechniken für den Umgang mit hohem Protokolldurchsatz bei gleichzeitiger Wahrung der Systemstabilität und Vermeidung von Datenverlusten behandelt.
Hinweise zur Verwendung von benutzerdefinierten Konfigurationsdateien mit FireLens finden Sie unter[Eine benutzerdefinierte Konfigurationsdatei verwenden](firelens-taskdef.md#firelens-taskdef-customconfig). Weitere Beispiele finden Sie unter [Amazon FireLens ECS-Beispiele](https://github.com/aws-samples/amazon-ecs-firelens-examples) unter GitHub.
**Anmerkung**
Einige Konfigurationsoptionen in diesem Abschnitt, wie z. B. `workers` und`threaded`, sind AWS für Fluent Bit Version 3 oder höher erforderlich. Informationen zu verfügbaren Versionen finden Sie unter [AWS Fluent Bit-Versionen](https://github.com/aws/aws-for-fluent-bit/releases).
## Chunks verstehen
Fluent Bit*verarbeitet Daten in Einheiten, die als Chunks bezeichnet werden.* Wenn ein INPUT-Plugin Daten empfängt, erstellt die Engine einen Block, der im Speicher oder im Dateisystem gespeichert wird, bevor er an OUTPUT-Ziele gesendet wird.
Das Pufferverhalten hängt von der `storage.type` Einstellung in Ihren INPUT-Abschnitten ab. Fluent BitVerwendet standardmäßig die Speicherpufferung. Bei Hochdurchsatz- oder Produktionsszenarien bietet die Dateisystempufferung eine bessere Stabilität.
[Weitere Informationen finden Sie in der Fluent Bit Dokumentation unter [Chunks](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) und Was ist ein Chunk?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) im Repository AWS für Fluent Bit Beispiele.
## Speicherpufferung (Standard)
Fluent BitVerwendet standardmäßig Speicherpufferung ()`storage.type memory`. Mit dem `Mem_Buf_Limit` Parameter können Sie die Speichernutzung pro INPUT-Plugin einschränken.
Das folgende Beispiel zeigt eine speichergepufferte Eingabekonfiguration:
```
[INPUT]
Name tcp
Tag ApplicationLogs
Port 5170
storage.type memory
Mem_Buf_Limit 5MB
```
**Wichtig**
Wenn `Mem_Buf_Limit` der Wert für ein Plugin überschritten wird, wird die Eingabe Fluent Bit unterbrochen und neue Datensätze gehen verloren. Dies kann zu Gegendruck führen und Ihre Anwendung verlangsamen. Die folgende Warnung wird in den Fluent Bit Protokollen angezeigt:
```
[input] tcp.1 paused (mem buf overlimit)
```
Die Speicherpufferung eignet sich für einfache Anwendungsfälle mit geringem bis moderatem Protokolldurchsatz. Verwenden Sie für Szenarien mit hohem Durchsatz oder Produktionsszenarien, in denen Datenverlust ein Problem darstellt, stattdessen die Dateisystempufferung.
Weitere Informationen finden Sie unter [Buffering and Memory in der Fluent Bit Dokumentation und Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) [Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) im Repository for examples. AWS Fluent Bit
## Pufferung von Dateisystemen
Für Szenarien mit hohem Durchsatz empfehlen wir die Verwendung der Dateisystempufferung. Weitere Informationen zur Fluent Bit Verwaltung von Pufferung und Speicherung finden Sie in der Dokumentation unter [Pufferung und](https://docs.fluentbit.io/manual/administration/buffering-and-storage) Speicherung. Fluent Bit
Die Pufferung von Dateisystemen bietet die folgenden Vorteile:
+ **Größere Pufferkapazität** — Festplattenspeicher ist in der Regel umfangreicher als Arbeitsspeicher.
+ **Persistenz** — Gepufferte Daten Fluent Bit überstehen Neustarts.
+ **Graduelle Verschlechterung** — Bei Ausgabeausfällen sammeln sich Daten auf der Festplatte an, anstatt zu einer Speichererschöpfung zu führen.
Um die Dateisystempufferung zu aktivieren, stellen Sie eine benutzerdefinierte Konfigurationsdatei bereit. Fluent Bit Das folgende Beispiel zeigt die empfohlene Konfiguration:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
Die wichtigsten Konfigurationsparameter:
`storage.path`
Das Verzeichnis, in dem gepufferte Chunks auf der Festplatte Fluent Bit gespeichert werden.
`storage.backlog.flush_on_shutdown`
Wenn diese Option aktiviert ist, wird Fluent Bit versucht, beim Herunterfahren alle Backlog-Dateisystem-Chunks an ihre Ziele zu leeren. Dies trägt dazu bei, die Datenzustellung zu gewährleisten, bevor sie Fluent Bit unterbrochen wird, kann jedoch die Zeit für das Herunterfahren verlängern.
`storage.max_chunks_up`
Die Anzahl der Chunks, die im Speicher verbleiben. Die Standardeinstellung ist 128 Chunks, was mehr als 500 MB Speicher beanspruchen kann, da jeder Chunk bis zu 4—5 MB belegen kann. In Umgebungen mit eingeschränktem Speicher sollten Sie diesen Wert verringern. Wenn Sie beispielsweise 50 MB für die Pufferung zur Verfügung haben, legen Sie diesen Wert auf 8—10 Blöcke fest.
`storage.type filesystem`
Aktiviert den Dateisystemspeicher für das Eingabe-Plugin. Wird trotz des Namens Fluent Bit verwendet, `mmap` um Chunks sowohl dem Arbeitsspeicher als auch der Festplatte zuzuordnen, wodurch Persistenz ohne Leistungseinbußen gewährleistet wird.
`storage.total_limit_size`
Der maximale Festplattenspeicher für gepufferte Daten für ein bestimmtes OUTPUT-Plugin. Wenn dieses Limit erreicht ist, werden die ältesten Datensätze für diese Ausgabe gelöscht. Weitere Informationen zur Größenbestimmung finden Sie unter[`storage.total_limit_size` verstehen](#firelens-storage-sizing).
`threaded true`
Führt die Eingabe in einem eigenen Thread aus, getrennt von Fluent Bit der Hauptereignisschleife. Dadurch wird verhindert, dass langsame Eingaben die gesamte Pipeline blockieren.
Weitere Informationen finden Sie unter [Dateisystem-Pufferung](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) in der Fluent Bit Dokumentation und [Dateisystem- und Speicherpufferung im AWS Beispiel-Repository](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem). Fluent Bit
## `storage.total_limit_size` verstehen
Der `storage.total_limit_size` Parameter jedes OUTPUT-Plug-ins steuert den maximalen Speicherplatz für gepufferte Daten für diese Ausgabe. Wenn dieses Limit erreicht ist, werden die ältesten Datensätze für diese Ausgabe gelöscht, um Platz für neue Daten zu schaffen. Wenn der Festplattenspeicher vollständig erschöpft ist, können Datensätze Fluent Bit nicht in die Warteschlange gestellt werden und sie gehen verloren.
Verwenden Sie die folgende Formel, um den entsprechenden Wert auf der `storage.total_limit_size` Grundlage Ihrer Protokollrate und des gewünschten Wiederherstellungsfensters zu berechnen:
```
If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000
storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)
```
Die folgende Tabelle zeigt Beispielberechnungen für gängige Protokollraten und Wiederherstellungsfenster:
| Protokollierungsrate | 1 Stunde | 6 Stunden | 12 Stunden | 24 Stunden |
| --- | --- | --- | --- | --- |
| 0,25 MB/s | 0,9 GB | 5,4 GB | 10,8 GB | 21,6 GB |
| 0,5 MB/s | 1,8 GB | 10,8 GB | 21,6 GB | 43,2 GB |
| 1 MB/s | 3,6 GB | 21,6 GB | 43,2 GB | 86,4 GB |
| 5 MB/s | 18 GB | 108 GB | 216 GB | 432 GB |
| 10 MB/s | 36 GB | 216 GB | 432 GB | 864 GB |
Um den Spitzendurchsatz zu beobachten und geeignete Puffergrößen auszuwählen, verwenden Sie die [Messdurchsatzprobe. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)
Verwenden Sie die Formel, die Beispielberechnungen und das Benchmarking, um eine geeignete Lösung auszuwählen, die bei einem `storage.total_limit_size` Ausfall die Startbahn für eine optimale Wiederherstellung bietet.
## Speicheranforderungen für Amazon ECS-Aufgaben
Summieren Sie alle `storage.total_limit_size` Werte der OUTPUT-Abschnitte und fügen Sie Puffer für Overhead hinzu. Diese Summe bestimmt den Speicherplatz, der in Ihrer Amazon ECS-Aufgabendefinition benötigt wird. Zum Beispiel 3 Ausgänge × jeweils 10 GB = 30 GB \$1 Puffer (5—10 GB) = insgesamt 35—40 GB erforderlich. Wenn die Summe den verfügbaren Speicherplatz übersteigt, Fluent Bit können Datensätze möglicherweise nicht in die Warteschlange gestellt werden und sie gehen verloren.
Die folgenden Speicheroptionen sind verfügbar:
Bind-Mounts (kurzlebiger Speicher)
+ Für AWS Fargate ist die Standardeinstellung 20 GB flüchtiger Speicher (max. 200 GB). Konfigurieren Sie die Verwendung `ephemeralStorage` in der Aufgabendefinition. Weitere Informationen finden Sie unter [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) im *AWS CloudFormation -Benutzerhandbuch*.
+ Für EC2 ist die Standardeinstellung 30 GB, wenn das Amazon ECS-optimierte AMI verwendet wird (gemeinsam vom Betriebssystem und Docker genutzt). Erhöhen Sie den Wert, indem Sie die Größe des Root-Volumes ändern.
Amazon-EBS-Volumes
+ Bietet hochverfügbaren, langlebigen und leistungsstarken Blockspeicher.
+ Erfordert die Volume-Konfiguration und das Verweisen auf `storage.path` (Standard:`/var/log/flb-storage/`) `mountPoint` in der Aufgabendefinition.
+ Weitere Informationen finden Sie unter [Die Volume-Konfiguration auf die Startzeit in einer Amazon-ECS-Aufgabendefinition verschieben](specify-ebs-config.md).
Amazon EFS-Volumes
+ Bietet einfachen, skalierbaren Dateispeicher.
+ Erfordert die Volume-Konfiguration und das Verweisen auf `storage.path` (Standard:`/var/log/flb-storage/`) `mountPoint` in der Aufgabendefinition.
+ Weitere Informationen finden Sie unter [Ein Amazon-EFS-Dateisystems in einer Amazon-ECS-Aufgabendefinition angeben](specify-efs-config.md).
Weitere Hinweise zu Datenvolumen finden Sie unter[Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).
## Optimieren Sie die Ausgabekonfiguration
Netzwerkprobleme, Dienstausfälle und Drosselung von Zielen können die Übermittlung von Protokollen verhindern. Die richtige Ausgangskonfiguration gewährleistet Ausfallsicherheit ohne Datenverlust.
Wenn ein Output-Flush fehlschlägt, Fluent Bit kann der Vorgang erneut versucht werden. Die folgenden Parameter steuern das Verhalten bei Wiederholungsversuchen:
`retry_limit`
Die maximale Anzahl von Wiederholungen nach dem ersten Versuch vor dem Löschen von Datensätzen. Der Standardwert ist 1. `retry_limit 3`Bedeutet beispielsweise insgesamt 4 Versuche (1 erster Versuch \$1 3 Wiederholungen). Für Produktionsumgebungen empfehlen wir 15 oder mehr, was einen Ausfall von mehreren Minuten mit exponentiellem Backoff abdeckt.
Auf `no_limits` oder `False` für unendliche Wiederholungsversuche setzen:
+ Bei der Speicherpufferung führen unendliche Wiederholungen dazu, dass das Eingabe-Plugin pausiert, wenn die Speichergrenzen erreicht sind.
+ Bei der Dateisystempufferung werden die ältesten Datensätze gelöscht, wenn sie erreicht sind. `storage.total_limit_size`
Wenn alle Wiederholungsversuche ausgeschöpft sind (1 anfänglich \$1 `retry_limit` Wiederholungen), werden die Datensätze gelöscht. AWS Plugins mit `auto_retry_requests true` (Standard) bieten vor Fluent Bit dem Wiederholungsmechanismus eine zusätzliche Wiederholungsebene. Weitere Informationen finden Sie in der Dokumentation unter [Konfigurieren von Wiederholungen](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries). Fluent Bit
`retry_limit 3`Mit den Standardeinstellungen bietet (, `scheduler.base 5``scheduler.cap 2000`,`net.connect_timeout 10s`) beispielsweise etwa 70 Sekunden Wartezeit im Scheduler (10 s \$1 20 s \$1 40 s), 40 Sekunden Timeouts für Netzwerkverbindungen (4 Versuche × 10 s) sowie AWS Plugin-Wiederholungen — insgesamt etwa 2—10 Minuten, abhängig von den Netzwerkbedingungen und den TCP-Timeouts des Betriebssystems.
`scheduler.base`
Die Basissekunden zwischen Wiederholungen (Standard: 5). Wir empfehlen 10 Sekunden.
`scheduler.cap`
Die maximale Anzahl von Sekunden zwischen Wiederholungen (Standard: 2000). Wir empfehlen 60 Sekunden.
Bei der Wartezeit zwischen Wiederholungen wird ein exponentieller Backoff mit Jitter verwendet:
```
wait_time = random(base, min(base × 2^retry_number, cap))
```
Zum Beispiel mit und: `scheduler.base 10` `scheduler.cap 60`
+ Erster Versuch: zufällige Wartezeit zwischen 10 und 20 Sekunden
+ Zweiter Wiederholungsversuch: zufällige Wartezeit zwischen 10—40 Sekunden
+ Dritter Wiederholungsversuch und später: zufällige Wartezeit zwischen 10—60 Sekunden (begrenzt)
[Weitere Informationen finden Sie in der Dokumentation unter [Wartezeit für Wiederholungsversuche konfigurieren und Netzwerk](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry).](https://docs.fluentbit.io/manual/administration/networking) Fluent Bit
`workers`
Die Anzahl der Threads für die parallel Ausgangsverarbeitung. Mehrere Worker ermöglichen gleichzeitige Löschvorgänge, wodurch der Durchsatz bei der Verarbeitung vieler Blöcke verbessert wird.
`auto_retry_requests`
Eine AWS Plugin-spezifische Einstellung, die vor dem integrierten Wiederholungsmechanismus eine zusätzliche Wiederholungsebene bietet. Fluent Bit Der Standardwert ist `true`. Wenn diese Option aktiviert ist, wiederholt das AWS Ausgabe-Plug-In intern fehlgeschlagene Anfragen erneut, bevor die Anfrage als fehlgeschlagener Flush betrachtet wird und von der Konfiguration abhängt. `retry_limit`
Der `Grace` Parameter in `[SERVICE]` diesem Abschnitt legt fest, wie lange es dauert, bis die gepufferten Fluent Bit Daten geleert werden, wenn das System heruntergefahren wird. Der `Grace` Zeitraum muss mit dem des Containers abgestimmt werden. `stopTimeout` Stellen Sie sicher, dass der `Grace` Zeitraum `stopTimeout` überschritten wird, Fluent Bit damit der Spülvorgang vor dem Empfang `SIGKILL` abgeschlossen werden kann. Wenn der Wert beispielsweise 120 Sekunden `Grace` beträgt, stellen Sie ihn `stopTimeout` auf 150 Sekunden ein.
Das folgende Beispiel zeigt eine vollständige Fluent Bit Konfiguration mit allen empfohlenen Einstellungen für Szenarien mit hohem Durchsatz:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
# Minimum seconds between retries
scheduler.base 10
# Maximum seconds between retries (exponential backoff cap)
scheduler.cap 60
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
## Datenverlustszenarien verstehen
Bei längeren Ausfällen oder Problemen mit Ausgabezielen können Datensätze verloren gehen. Bei den Konfigurationsempfehlungen in diesem Handbuch handelt es sich um Methoden zur Minimierung von Datenverlusten, es kann jedoch nicht garantiert werden, dass bei längeren Ausfällen kein Datenverlust auftritt. Das Verständnis dieser Szenarien hilft Ihnen bei der KonfigurationFluent Bit, um die Ausfallsicherheit zu maximieren.
Datensätze können auf zwei Arten verloren gehen: Die ältesten Datensätze werden gelöscht, wenn der Speicher voll ist, oder die neuesten Datensätze werden zurückgewiesen, wenn das System keine weiteren Daten akzeptieren kann.
### Die ältesten Datensätze wurden gelöscht
Die ältesten gepufferten Datensätze werden gelöscht, wenn die Wiederholungsversuche erschöpft sind oder wenn sie `storage.total_limit_size` voll sind und Platz für neue Daten geschaffen werden muss.
Das Limit für Wiederholungsversuche wurde überschritten
Tritt auf, nachdem AWS das Plugin erneut versucht hat (wenn`auto_retry_requests true`) plus einem ersten Fluent Bit Versuch plus `retry_limit` Wiederholungen. Um dies zu vermeiden, legen Sie `retry_limit no_limits` pro OUTPUT-Plugin eine unendliche Anzahl von Wiederholungsversuchen fest:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
Unendliche Wiederholungsversuche verhindern, dass Datensätze gelöscht werden, weil die Wiederholungsversuche erschöpft sind, können aber dazu führen, dass sie voll werden. `storage.total_limit_size`
Speicherlimit erreicht (Dateisystem-Pufferung)
Tritt auf, wenn das Ausgabeziel länger nicht verfügbar ist, als Ihr konfigurierter Puffer speichern `storage.total_limit_size` kann. Ein Puffer von 10 GB bei einer MB/s Protokollrate von 1 bietet beispielsweise eine Pufferung von etwa 2,7 Stunden. Um dies zu vermeiden, erhöhen Sie die Anzahl `storage.total_limit_size` pro OUTPUT-Plugin und stellen Sie ausreichend Amazon ECS-Aufgabenspeicher bereit:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### Die neuesten Datensätze wurden zurückgewiesen
Die neuesten Datensätze werden gelöscht, wenn der Festplattenspeicher erschöpft ist oder wenn die Eingabe aufgrund von unterbrochen wird. `Mem_Buf_Limit`
Festplattenspeicher erschöpft (Dateisystem-Pufferung)
Tritt auf, wenn der Festplattenspeicher vollständig erschöpft ist. Fluent Bitkann neue Datensätze nicht in die Warteschlange stellen und sie gehen verloren. Um dies zu vermeiden, summieren Sie alle `storage.total_limit_size` Werte und stellen Sie einen angemessenen Amazon ECS-Aufgabenspeicher bereit. Weitere Informationen finden Sie unter [Speicheranforderungen für Amazon ECS-Aufgaben](#firelens-storage-task-requirements).
Speicherlimit erreicht (Speicherpufferung)
Tritt auf, wenn das Ausgabeziel nicht verfügbar ist und der Speicherpuffer voll ist. Pausierte Eingabe-Plugins akzeptieren keine neuen Datensätze mehr. Zur Minderung, zur Erhöhung der Widerstandsfähigkeit oder `storage.type filesystem` zur Erhöhung der Widerstandsfähigkeit verwenden. `Mem_Buf_Limit`
### Bewährte Methoden zur Minimierung von Datenverlusten
Beachten Sie die folgenden bewährten Methoden zur Minimierung von Datenverlusten:
+ **Dateisystem-Pufferung verwenden — Diese** Option sorgt `storage.type filesystem` für eine bessere Ausfallsicherheit bei Ausfällen.
+ **Speicher angemessen dimensionieren** — Die Berechnung `storage.total_limit_size` basiert auf der Protokollrate und dem gewünschten Wiederherstellungsfenster.
+ Stellen **Sie eine angemessene Festplatte** bereit — Stellen Sie sicher, dass die Amazon ECS-Aufgabe über ausreichend kurzlebigen Speicher, Amazon EBS oder Amazon EFS verfügt.
+ **Wiederholungsverhalten konfigurieren — Ausgewogen zwischen `retry_limit` (löscht Datensätze nach anstrengenden Wiederholungsversuchen**) und `no_limits` (Wiederholungen auf unbestimmte Zeit, können aber Speicherplatz füllen).
## Verwenden Sie aus Gründen der Zuverlässigkeit die Protokollierung für mehrere Ziele
Durch das Senden von Protokollen an mehrere Ziele werden einzelne Fehlerquellen vermieden. Wenn CloudWatch Logs beispielsweise ausfällt, erreichen die Protokolle immer noch Amazon S3.
Die Protokollierung mehrerer Ziele bietet die folgenden Vorteile. Das Amazon S3 S3-Ausgabe-Plugin unterstützt auch Komprimierungsoptionen wie Gzip und Parquet-Format, wodurch die Speicherkosten gesenkt werden können. Weitere Informationen finden Sie in der Fluent Bit Dokumentation unter [S3-Komprimierung](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression).
Die Protokollierung mehrerer Ziele kann die folgenden Vorteile bieten:
+ **Redundanz** — Wenn ein Ziel ausfällt, erreichen die Protokolle immer noch das andere.
+ **Wiederherstellung** — Rekonstruieren Sie Lücken in einem System vom anderen.
+ **Haltbarkeit** — Archivieren Sie Protokolle zur langfristigen Aufbewahrung in Amazon S3.
+ **Kostenoptimierung** — Bewahren Sie aktuelle Protokolle in einem schnellen Abfrageservice wie CloudWatch Logs mit kürzerer Aufbewahrung auf und archivieren Sie gleichzeitig alle Protokolle zur langfristigen Aufbewahrung auf kostengünstigerem Amazon S3 S3-Speicher.
Die folgende Fluent Bit Konfiguration sendet CloudWatch Protokolle sowohl an Logs als auch an Amazon S3:
```
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
workers 2
retry_limit 15
[OUTPUT]
Name s3
Match *
bucket my-logs-bucket
region us-west-2
total_file_size 100M
s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
upload_timeout 10m
# Maximum disk space for buffered data for this output
storage.total_limit_size 5G
```
Beide Ausgaben verwenden dasselbe `Match *` Muster, sodass alle Datensätze unabhängig voneinander an beide Ziele gesendet werden. Während eines Ausfalls eines Ziels fließen die Protokolle weiter zum anderen, während sich fehlgeschlagene Leerungen im Dateisystempuffer ansammeln, sodass sie es später erneut versuchen können.
## Verwenden Sie die dateibasierte Protokollierung mit dem Tail-Input-Plugin
Für Szenarien mit hohem Durchsatz, in denen der Verlust von Protokollen ein kritisches Problem darstellt, können Sie einen alternativen Ansatz verwenden: Lassen Sie Ihre Anwendung Protokolle in Dateien auf der Festplatte schreiben und konfigurieren Sie sie so, dass sie mithilfe des Fluent Bit `tail` Eingabe-Plug-ins gelesen werden. Bei diesem Ansatz wird die Treiberschicht für die Docker-Protokollierung vollständig umgangen.
Die dateibasierte Protokollierung mit dem Tail-Plugin bietet die folgenden Vorteile:
+ **Offset-Tracking** — Das Tail-Plugin kann Datei-Offsets in einer Datenbankdatei speichern (mit der `DB` Option) und sorgt so für Stabilität bei Neustarts. Fluent Bit Dies trägt dazu bei, den Verlust von Protokollen bei Container-Neustarts zu verhindern.
+ **Pufferung auf Eingabeebene** — Sie können die Speicherpuffergrenzen direkt im Eingabe-Plugin konfigurieren`Mem_Buf_Limit`, sodass Sie die Speichernutzung genauer steuern können.
+ **Vermeidet Docker-Overhead** — Protokolle werden direkt von Datei zu Datei übertragen, Fluent Bit ohne die Protokollpuffer von Docker zu durchlaufen.
Um diesen Ansatz zu verwenden, muss Ihre Anwendung Protokolle statt in Dateien schreiben. `stdout` Sowohl der Anwendungscontainer als auch der Fluent Bit Container mounten ein gemeinsam genutztes Volume, auf dem die Protokolldateien gespeichert werden.
Das folgende Beispiel zeigt eine Konfiguration mit Tail-Eingaben mit bewährten Methoden:
```
[INPUT]
Name tail
# File path or glob pattern to tail
Path /var/log/app.log
# Database file for storing file offsets (enables resuming after restart)
DB /var/log/flb_tail.db
# when true, controls that only fluent-bit will access the database (improves performance)
DB.locking true
# Skip long lines instead of skipping the entire file
Skip_Long_Lines On
# How often (in seconds) to check for new files matching the glob pattern
Refresh_Interval 10
# Extra seconds to monitor a file after rotation to account for pending flush
Rotate_Wait 30
# Maximum size of the buffer for a single line
Buffer_Max_Size 10MB
# Initial allocation size for reading file data
Buffer_Chunk_Size 1MB
# Maximum memory buffer size (tail pauses when full)
Mem_Buf_Limit 75MB
```
Beachten Sie bei der Verwendung des Tail-Input-Plug-ins Folgendes:
+ Implementieren Sie die Protokollrotation für Ihre Anwendungsprotokolle, um eine Überlastung der Festplatte zu verhindern. Überwachen Sie die zugrunde liegenden Volumenmetriken, um die Leistung zu messen.
+ Erwägen Sie Einstellungen wie `Ignore_Older``Read_from_Head`, und mehrzeilige Parser, die auf Ihrem Protokollformat basieren.
Weitere Informationen finden Sie in der Dokumentation unter [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail). Fluent Bit Bewährte Methoden finden Sie unter [Tail-Konfiguration mit bewährten Methoden](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) im Leitfaden AWS zur Fluent Bit Fehlerbehebung.
## Loggen Sie sich direkt ein bei FireLens
Wenn der `awsfirelens`-Protokolltreiber in einer Aufgabendefinition angegeben wird, injiziert der Amazon ECS Container-Agent die folgenden Umgebungsvariablen in den Container:
`FLUENT_HOST`
Die IP-Adresse, die dem FireLens Container zugewiesen ist.
Wenn Sie EC2 im `bridge` Netzwerkmodus verwenden, kann die `FLUENT_HOST` Umgebungsvariable in Ihrem Anwendungscontainer nach einem Neustart des FireLens Log-Router-Containers (des Containers mit dem `firelensConfiguration` Objekt in seiner Containerdefinition) ungenau werden. Das liegt daran, dass `FLUENT_HOST` eine dynamische IP-Adresse ist, die sich nach einem Neustart ändern kann. Die direkte Protokollierung vom Anwendungs-Container zur `FLUENT_HOST` IP-Adresse kann nach einer Adressänderung fehlschlagen. Weitere Informationen zum Neustart einzelner Container finden Sie unter [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md).
`FLUENT_PORT`
Der Port, über den das Fluent Forward-Protokoll kommuniziert.
Sie können diese Umgebungsvariablen verwenden, um sich direkt von Ihrem Anwendungscode aus mit dem Fluent Forward-Protokoll Fluent Bit beim Log Router anzumelden, anstatt in diesen zu schreiben. `stdout` Bei diesem Ansatz wird die Treiberschicht für die Docker-Protokollierung umgangen, was die folgenden Vorteile bietet:
+ **Geringere Latenz** — Protokolle werden direkt an die Protokollierungsinfrastruktur von Docker weitergeleitet, Fluent Bit ohne sie zu passieren.
+ **Strukturierte Protokollierung** — Senden Sie strukturierte Protokolldaten nativ ohne zusätzlichen Aufwand für die JSON-Codierung.
+ **Bessere Kontrolle** — Ihre Anwendung kann ihre eigene Pufferungs- und Fehlerbehandlungslogik implementieren.
Die folgenden Fluent-Logger-Bibliotheken unterstützen das Fluent Forward-Protokoll und können verwendet werden, um Protokolle direkt an zu senden: Fluent Bit
+ **Go** – [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python** – [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Java** – [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js** – [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby** – [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)
## Konfigurieren Sie das Docker-Pufferlimit
Wenn Sie eine Aufgabendefinition erstellen, können Sie die Anzahl der Protokollzeilen angeben, die im Speicher gepuffert werden, indem Sie den Wert in angeben. `log-driver-buffer-limit` Dies steuert den Puffer zwischen Docker und. Fluent Bit Weitere Informationen finden Sie unter [Fluentd-Protokollierungstreiber](https://docs.docker.com/engine/logging/drivers/fluentd/) in der Docker-Dokumentation.
Verwenden Sie diese Option bei hohem Durchsatz, da Docker möglicherweise der Pufferspeicher ausgeht und Puffermeldungen verworfen werden, damit neue Nachrichten hinzugefügt werden können.
Beachten Sie bei der Verwendung dieser Option Folgendes:
+ Diese Option wird in EC2 und Fargate mit Plattformversion `1.4.0` oder höher unterstützt.
+ Die Option ist nur gültig, wenn `logDriver` auf `awsfirelens` gesetzt ist.
+ Das Standard-Pufferlimit ist `1048576` Protokollzeilen.
+ Das Pufferlimit muss größer oder gleich `0` und kleiner als `536870912`-Protokollzeilen sein.
+ Die maximale Menge an Arbeitsspeicher, die für diesen Puffer verwendet wird, ist die Summe der Größe jeder Protokollzeile und der Größe des Puffers. Wenn die Protokollzeilen der Anwendung beispielsweise im Durchschnitt `2` KiB betragen, würde ein Pufferlimit von 4096 höchstens `8` MiB verbrauchen. Die Gesamtmenge des auf Aufgabenebene zugewiesenen Arbeitsspeichers muss zusätzlich zum Arbeitsspeicher-Puffer des Protokolltreibers größer sein als die für alle Container zugewiesene Menge an Arbeitsspeicher.
Die folgende Aufgabendefinition zeigt, wie die Konfiguration erfolgt: `log-driver-buffer-limit`
```
{
"containerDefinitions": [
{
"name": "my_service_log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"essential": true,
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "52428800"
}
},
"dependsOn": [
{
"containerName": "my_service_log_router",
"condition": "START"
}
],
"memoryReservation": 100
}
]
}
```
# AWS für Fluent Bit Bild-Repositorys für Amazon ECS
AWS bietet ein Fluent Bit Image mit Plugins für CloudWatch Logs und Firehose. Es wird empfohlen, Fluent Bit als Protokoll-Router zu verwenden, da es eine geringere Ressourcenauslastung aufweist als Fluentd. Weitere Informationen finden Sie unter [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) und [Amazon Kinesis Firehose for](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) Fluent Bit.
Das **AWS for Fluent Bit-Bild** ist auf Amazon ECR sowohl in der Amazon ECR Public Gallery als auch in einem Amazon ECR-Repository für hohe Verfügbarkeit verfügbar.
## Öffentliche Galerie Amazon ECR
Das Fluent Bit Bild AWS für ist in der Amazon ECR Public Gallery verfügbar. Dies ist der empfohlene Ort, um das Fluent Bit Bild AWS für herunterzuladen, da es sich um ein öffentliches Repository handelt, das von allen AWS-Regionen genutzt werden kann. Weitere Informationen finden Sie in der [aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)Amazon ECR Public Gallery.
### Linux
Das AWS Fluent Bit For-Bild in der Amazon ECR Public Gallery unterstützt das Amazon Linux-Betriebssystem mit der `ARM64` `x86-64` OR-Architektur.
Sie können das AWS Fluent Bit For-Bild aus der Amazon ECR Public Gallery abrufen, indem Sie die Repository-URL mit dem gewünschten Image-Tag angeben. Die verfügbaren Image-Tags finden Sie in der Registerkarte **Image-Tags** auf der Amazon ECR Public Gallery.
Nachfolgend finden Sie die für die Docker-CLI zu verwendende Syntax.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
Mit diesem Docker-CLI-Befehl können Sie beispielsweise das neueste Image der „3.x“ -Familie AWS für Fluent Bit Releases abrufen.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
**Anmerkung**
Nicht authentifizierte Pulls sind zulässig, haben jedoch eine niedrigere Rate als authentifizierte Pulls. Verwenden Sie den folgenden Befehl, um sich vor dem Abrufen mit Ihrem AWS Konto zu authentifizieren.
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
#### AWS für 3.0.0 Fluent Bit
Zusätzlich zu den vorhandenen Fluent Bit Versionen AWS `2.x` für Fluent Bit unterstützt AWS for eine neue Hauptversion`3.x`. Die neue Hauptversion beinhaltet das Upgrade von Images von Amazon Linux 2 auf Amazon Linux 2023 und Fluent Bit Version `1.9.10` auf`4.1.1`. Weitere Informationen finden Sie im [AWSFluent BitFor-Repository](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) unterGitHub.
Die folgenden Beispiele zeigen aktualisierte Tags AWS für Fluent Bit `3.x` Bilder:
Sie können Multiarchitektur-Tags AWS für das Fluent Bit FOR-Bild verwenden.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
### Windows
Das Fluent Bit Bild AWS for in der Amazon ECR Public Gallery unterstützt die `AMD64` Architektur mit den folgenden Betriebssystemen:
+ Windows Server 2022 Voll
+ Windows Server 2022 Kern
+ Windows Server 2019 Voll
+ Windows Server 2019 Kern
Windows-Container, die sich auf AWS Fargate befinden, werden nicht unterstützt FireLens.
Sie können das AWS Fluent Bit For-Bild aus der Amazon ECR Public Gallery abrufen, indem Sie die Repository-URL mit dem gewünschten Image-Tag angeben. Die verfügbaren Image-Tags finden Sie in der Registerkarte **Image-Tags** auf der Amazon ECR Public Gallery.
Nachfolgend finden Sie die für die Docker-CLI zu verwendende Syntax.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
Mit diesem Docker-CLI-Befehl können Sie beispielsweise den neuesten Stable AWS for Fluent Bit Image abrufen.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable
```
**Anmerkung**
Nicht authentifizierte Pulls sind zulässig, haben jedoch eine niedrigere Rate als authentifizierte Pulls. Verwenden Sie den folgenden Befehl, um sich vor dem Abrufen mit Ihrem AWS Konto zu authentifizieren.
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
## Amazon ECR
Das AWS for Fluent Bit-Bild ist auf Amazon ECR für hohe Verfügbarkeit verfügbar. Die folgenden Befehle können verwendet werden, um ein Bild abzurufen URIs und die Verfügbarkeit eines Bilds für ein bestimmtes Bild festzulegen. AWS-Region
### Linux
Der neueste stabile Bild-URI AWS für Fluent Bit kann mit dem folgenden Befehl abgerufen werden.
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/stable \
--region us-east-1
```
Alle Versionen des AWS for Fluent Bit-Images können mit dem folgenden Befehl aufgelistet werden, um den Systems Manager Parameter Store-Parameter abzufragen.
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit \
--region us-east-1
```
Das neueste stabile Bild AWS für Fluent Bit kann in einer CloudFormation Vorlage referenziert werden, indem auf den Namen des Systems Manager Manager-Parameterspeichers verwiesen wird. Im Folgenden wird ein Beispiel gezeigt:
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/stable
```
**Anmerkung**
Wenn der Befehl fehlschlägt oder keine Ausgabe erfolgt, ist das Bild in der Datei, AWS-Region in der der Befehl aufgerufen wurde, nicht verfügbar.
### Windows
Die neueste stabile Bild-URI AWS für Fluent Bit kann mit dem folgenden Befehl abgerufen werden.
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/windowsservercore-stable \
--region us-east-1
```
Alle Versionen des AWS for Fluent Bit-Images können mit dem folgenden Befehl aufgelistet werden, um den Systems Manager Parameter Store-Parameter abzufragen.
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit/windowsservercore \
--region us-east-1
```
Das neueste stabile Bild AWS für Fluent Bit kann in einer CloudFormation Vorlage referenziert werden, indem auf den Namen des Systems Manager Manager-Parameterspeichers verwiesen wird. Im Folgenden wird ein Beispiel gezeigt:
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable
```
# Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten
Um ein benutzerdefiniertes Protokoll-Routing mit FireLens zu verwenden, müssen Sie Folgendes in der Aufgabendefinition angeben:
+ Ein Protokoll-Router-Container, der eine FireLens-Konfiguration enthält. Wir empfehlen, dass der Container als `essential` markiert wird.
+ Ein oder mehrere Anwendungscontainer, die eine Protokollkonfiguration enthalten, die den `awsfirelens`-Protokolltreiber angibt.
+ Ein Aufgaben-IAM-Rollen-Amazon-Ressourcenname (ARN), der die Berechtigungen enthält, die für die Aufgabe zum Weiterleiten der Protokolle erforderlich sind.
Beim Erstellen einer neuen Aufgabendefinition mithilfe von gibt es einen FireLens Integrationsbereich AWS-Managementkonsole, der das Hinzufügen eines Protokoll-Router-Containers erleichtert. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
Amazon ECS konvertiert die Protokollkonfiguration und generiert die Fluentd- oder Fluent Bit-Ausgabekonfiguration. Die Ausgabekonfiguration ist in dem Protokoll-Routing-Container unter `/fluent-bit/etc/fluent-bit.conf` für Fluent Bit und `/fluentd/etc/fluent.conf` für Fluentd eingebaut.
**Wichtig**
FireLens überwacht Port `24224`. Um sicherzustellen, dass der FireLens Log Router außerhalb der Aufgabe nicht erreichbar ist, dürfen Sie daher keinen eingehenden Datenverkehr über den Port `24224` in der Sicherheitsgruppe zulassen, die Ihre Aufgabe verwendet. Für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, ist dies die der Aufgabe zugeordnete Sicherheitsgruppe. Für Aufgaben, die den `host`-Netzwerkmodus verwenden, ist dies die Sicherheitsgruppe, die der Amazon-EC2-Instance zugeordnet ist, die die Aufgabe hostet. Für Aufgaben, die den `bridge`-Netzwerkmodus verwenden, erstellen Sie keine Portzuordnungen, die Port `24224` verwenden.
In den Protokolleinträgen werden standardmäßig zusätzliche Felder von Amazon ECS hinzugefügt, mit denen die Quelle der Protokolle identifiziert werden kann.
+ `ecs_cluster` – Der Name des Clusters, zu dem die Aufgabe gehört.
+ `ecs_task_arn` – Der vollständige Amazon-Ressourcenname (ARN) der Aufgabe, zu der der Container gehört.
+ `ecs_task_definition` – Der Name und die Revision der Aufgabendefinition, die die Aufgabe verwendet.
+ `ec2_instance_id` – Die Amazon-EC2-Instance-ID, auf der der Container gehostet wird. Dieses Feld ist nur für Aufgaben mit dem Starttyp EC2 gültig.
Sie können `enable-ecs-log-metadata` auf `false` setzen, wenn Sie die Metadaten nicht benötigen.
Das folgende Beispiel für eine Aufgabendefinition definiert einen Log Router-Container, der Fluent Bit verwendet, um seine Protokolle an Logs CloudWatch weiterzuleiten. Außerdem wird ein Anwendungs-Container definiert, der eine Protokollkonfiguration verwendet, um Protokolle an Amazon Data Firehose weiterzuleiten, und legt den zum Puffern von Ereignissen verwendeten Arbeitsspeicher auf 2 MiB fest.
**Anmerkung**
Weitere Beispielaufgabendefinitionen finden Sie unter [Amazon FireLens ECS-Beispiele](https://github.com/aws-samples/amazon-ecs-firelens-examples) unter GitHub.
```
{
"family": "firelens-example-firehose",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
"containerDefinitions": [
{
"name": "log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"portMappings": [],
"essential": true,
"environment": [],
"mountPoints": [],
"volumesFrom": [],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ecs-aws-firelens-sidecar-container",
"mode": "non-blocking",
"awslogs-create-group": "true",
"max-buffer-size": "25m",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "firelens"
},
"secretOptions": []
},
"systemControls": [],
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "1048576"
}
},
"memoryReservation": 100
}
]
}
```
Die Schlüsselwertpaare, die als Optionen im `logConfiguration`-Objekt angegeben werden, werden verwendet, um die Fluentd- oder Fluent Bit-Ausgabekonfiguration zu generieren. Im Folgenden finden Sie ein Codebeispiel aus einer Fluent Bit-Ausgabedefinition.
```
[OUTPUT]
Name firehose
Match app-firelens*
region us-west-2
delivery_stream my-stream
```
**Anmerkung**
FireLens verwaltet die `match` Konfiguration. Die `match`-Konfiguration ist in der Aufgabendefinition nicht festgelegt.
## Eine benutzerdefinierte Konfigurationsdatei verwenden
Sie können eine benutzerdefinierte Konfigurationsdatei angeben Das Konfigurationsdateiformat ist das native Format für den verwendeten Protokoll-Router. Weitere Informationen finden Sie unter [Syntax der Fluentd-Konfigurationsdatei](https://docs.fluentd.org/configuration/config-file) und [YAML-Konfiguration](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml).
In Ihrer benutzerdefinierten Konfigurationsdatei sollten Sie für Aufgaben, die den `bridge`- oder `awsvpc`-Netzwerkmodus verwenden, keine Fluentd- oder Fluent-Bit-Weiterleitungseingabe über TCP festlegen, da FireLens diese zur Eingabekonfiguration hinzufügt.
Ihre FireLens-Konfiguration muss die folgenden Optionen enthalten, um eine benutzerdefinierte Konfigurationsdatei anzugeben:
`config-file-type`
Den Quellspeicherort der benutzerdefinierten Konfigurationsdatei. Die verfügbaren Optionen sind `s3` oder `file`.
Aufgaben, die auf gehostet werden, unterstützen AWS Fargate nur den `file` Konfigurationsdateityp. Sie können jedoch Konfigurationsdateien verwenden, die in Amazon S3 auf AWS Fargate gehostet werden, indem Sie den AWS for Fluent Bit init-Container verwenden. Weitere Informationen finden Sie unter [Init-Prozess für Fluent Bit auf ECS, Unterstützung mehrerer Konfigurationen auf](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub
`config-file-value`
Die Quelle für die benutzerdefinierte Konfigurationsdatei. Wenn der `s3`-Konfigurationsdateityp verwendet wird, ist der Wert der Konfigurationsdatei der vollständige ARN des Amazon S3-Buckets und der Datei. Wenn der `file`-Konfigurationsdateityp verwendet wird, ist der Wert der Konfigurationsdatei der vollständige Pfad der Konfigurationsdatei, die entweder im Container-Image oder auf einem Volume vorhanden ist, das im Container bereitgestellt wird.
Wenn Sie eine benutzerdefinierte Konfigurationsdatei verwenden, müssen Sie einen anderen Pfad als den von FireLens verwendeten angeben. Amazon ECS behält den `/fluent-bit/etc/fluent-bit.conf`-Dateipfad für Fluent Bit und `/fluentd/etc/fluent.conf` für Fluentd.
Das folgende Beispiel zeigt die Syntax, die erforderlich ist, wenn eine benutzerdefinierte Konfiguration angegeben wird.
**Wichtig**
Um eine benutzerdefinierte Konfigurationsdatei anzugeben, die in Amazon S3 gehostet wird, stellen Sie sicher, dass Sie eine IAM-Aufgabenausführungsrolle mit den entsprechenden Berechtigungen erstellt haben.
Im Folgenden wird die Syntax gezeigt, die für die Angabe einer benutzerdefinierten Konfiguration erforderlich ist.
```
{
"containerDefinitions": [
{
"essential": true,
"image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:3",
"name": "log_router",
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"config-file-type": "s3 | file",
"config-file-value": "arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf | filepath"
}
}
}
]
}
```
**Anmerkung**
Aufgaben, die auf gehostet werden, unterstützen AWS Fargate nur den `file` Konfigurationsdateityp. Sie können jedoch Konfigurationsdateien verwenden, die in Amazon S3 auf AWS Fargate gehostet werden, indem Sie den AWS for Fluent Bit init-Container verwenden. Weitere Informationen finden Sie unter [Init-Prozess für Fluent Bit auf ECS, Unterstützung mehrerer Konfigurationen auf](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub
# Verwenden von AWS Nicht-Container-Images in Amazon ECS
Verwenden Sie die private Registrierung, um Ihre Anmeldeinformationen darin zu speichern AWS Secrets Manager, und verweisen Sie dann in Ihrer Aufgabendefinition darauf. Auf diese Weise können Sie in Ihren Aufgabendefinitionen auf Container-Images verweisen, die in privaten Registern existieren und für AWS die eine Authentifizierung erforderlich ist. Dieses Feature wird durch Aufgaben unterstützt, die auf Fargate, Amazon-EC2-Instances und externen Instances mit Amazon ECS Anywhere gehostet werden.
**Wichtig**
Wenn Ihre Aufgabendefinition auf ein im Amazon ECR gespeichertes Image verweist, trifft dieses Thema nicht zu. Weitere Informationen finden Sie unter [Amazon ECR-Images mit Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) im *Amazon Elastic Container-Registry-Benutzerhandbuch*.
Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, erfordert dieses Feature Version `1.19.0` oder höher des Container-Agenten. Wir empfehlen jedoch, die neueste Version des Container-Agents zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
Für Aufgaben, die auf Fargate gehostet werden, erfordert dieses Feature die Plattformversion `1.2.0` oder höher. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
Geben Sie in Ihrer Containerdefinition das Objekt `repositoryCredentials` mit den Details des von Ihnen erstellten Geheimnisses an. Das referenzierte Geheimnis kann von einem anderen AWS-Region oder einem anderen Konto stammen als die Aufgabe, die es verwendet.
**Anmerkung**
Wenn Sie die Amazon ECS-API oder das AWS SDK verwenden und das Geheimnis in derselben AWS-Region Aufgabe enthalten ist, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Geheimnisses verwenden. AWS CLI Wenn das Geheimnis in einem anderen Konto vorhanden ist, muss der vollständige ARN des Geheimnisses angegeben werden. Bei Verwendung von muss immer der vollständige ARN des Geheimnisses angegeben werden. AWS-Managementkonsole
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition, welche die erforderlichen Parameter zeigt:
Ersetzen Sie die folgenden Parameter:
+ *private-repo*mit dem Hostnamen des privaten Repositorys
+ *private-image*mit dem Bildnamen
+ *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name*mit dem geheimen Amazon-Ressourcennamen (ARN)
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
**Anmerkung**
Eine weitere Methode zur Aktivierung der privaten Registrierungsauthentifikation verwendet Umgebungsvariablen von Amazon-ECS-Container-Agenten für die Authentifizierung bei privaten Registrierungen. Diese Methode wird nur für Aufgaben unterstützt, die auf Amazon-EC2-Instances gehostet werden. Weitere Informationen finden Sie unter [Konfiguration von Amazon-ECS-Container-Instances für private Docker-Images](private-auth-container-instances.md).
**So verwenden Sie eine private Registry**
1. Die Aufgabendefinition muss über eine Aufgaben-Ausführungsrolle verfügen. Auf diese Weise kann der Container-Agent das Container-Image abrufen. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
Die private Registrierungsauthentifizierung ermöglicht es Ihren Amazon ECS-Aufgaben, Container-Images von privaten Registern außerhalb von AWS (wie Docker Hub, Quay.io oder Ihrer eigenen privaten Registrierung) abzurufen, für die Authentifizierungsdaten erforderlich sind. Dieses Feature verwendet Secrets Manager, um Ihre Registry-Anmeldeinformationen sicher zu speichern, auf die dann in Ihrer Aufgabendefinition mithilfe des `repositoryCredentials`-Parameters verwiesen wird.
Weitere Informationen zur Konfiguration der privaten Registrierungsauthentifizierung finden Sie unter [Verwenden von AWS Non-Container-Images in Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).
Um Zugriff auf die Geheimnisse zu gewähren, die Ihre privaten Registry-Anmeldeinformationen enthalten, fügen Sie die folgenden Berechtigungen als Inline-Richtlinie zur Aufgaben-Ausführungsrolle hinzu. Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ `secretsmanager:GetSecretValue` – Erforderlich, um die privaten Registry-Anmeldeinformationen von Secrets Manager abzurufen.
+ `kms:Decrypt` – Nur erforderlich, wenn Ihr Geheimnis einen benutzerdefinierten KMS-Schlüssel verwendet und nicht den Standardschlüssel. Der Amazon-Ressourcenname (ARN) für Ihren benutzerdefinierten Schlüssel muss als Ressource hinzugefügt werden.
Das folgende Beispiel einer Inline-Richtlinie fügt die Berechtigungen hinzu:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name",
"arn:aws:kms:us-east-1:111122223333:key/key_id"
]
}
]
}
```
------
1. Wird verwendet AWS Secrets Manager , um ein Geheimnis für Ihre privaten Registrierungsdaten zu erstellen. Informationen zum Erstellen eines Geheimnisses finden Sie unter [Erstellen eines AWS Secrets Manager -Geheimnisses](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *Benutzerhandbuch für AWS Secrets Manager *.
Geben Sie Ihre privaten Registry-Anmeldeinformationen in folgendem Format ein:
```
{
"username" : "privateRegistryUsername",
"password" : "privateRegistryPassword"
}
```
1. Eine Aufgabendefinition registrieren. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
# Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten
Sie können für jeden in Ihrer Aufgabendefinition definierten essenziellen und nicht essenziellen Container eine Neustart-Richtlinie aktivieren, um vorübergehende Ausfälle schneller zu beheben und die Verfügbarkeit der Aufgaben aufrechtzuerhalten. Wenn Sie eine Neustart-Richtlinie für einen Container aktivieren, kann Amazon ECS den Container neu starten, wenn er beendet wird, ohne dass die Aufgabe ersetzt werden muss.
Neustart-Richtlinien sind standardmäßig nicht für Container aktiviert. Wenn Sie eine Neustart-Richtlinie für einen Container aktivieren, können Sie Beendigungs-Codes angeben, auf denen der Container nicht neu gestartet wird. Dies können Exit-Codes sein, die auf Erfolg hinweisen, wie Exit-Code `0`, für die kein Neustart erforderlich ist. Sie können auch angeben, wie lange ein Container erfolgreich ausgeführt werden muss, bevor ein Neustart versucht werden kann. Weitere Informationen zu diesen Parametern finden Sie unter [Neustartrichtlinie](task_definition_parameters.md#container_definition_restart_policy). Eine Beispiel-Aufgabendefinition, die diese Werte spezifiziert, finden Sie unter [Angeben einer Container-Neustart-Richtlinie in einer Amazon-ECS-Aufgabendefinition](container-restart-policy-example.md).
Sie können den Amazon ECS-Endpunkt für Aufgabenmetadaten oder CloudWatch Container Insights verwenden, um zu überwachen, wie oft ein Container neu gestartet wurde. Weitere Informationen zu den Aufgabenmetadaten-Endpunkt finden Sie unter [Amazon-ECS-Aufgabenmetadaten-Endpunkt Version 4](task-metadata-endpoint-v4.md) und [Amazon-ECS-Aufgabenmetaden-Endpunkt Version 4 für Aufgaben in Fargate](task-metadata-endpoint-v4-fargate.md). Weitere Informationen zu Container Insights-Metriken für Amazon ECS finden Sie unter [Amazon ECS Container Insights-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) im * CloudWatch Amazon-Benutzerhandbuch*.
Container-Neustart-Richtlinien werden von Aufgaben unterstützt, die auf Fargate, Amazon-EC2-Instances und externen Instances mit Amazon ECS Anywhere gehostet werden.
## Überlegungen
Berücksichtigen Sie Folgendes, bevor Sie eine Neustart-Richtlinie für Ihren Container aktivieren:
+ Neustart-Richtlinien werden für Windows-Container auf Fargate nicht unterstützt.
+ Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, erfordert dieses Feature Version `1.86.0` oder höher des Container-Agenten. Wir empfehlen jedoch, die neueste Version des Container-Agenten zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
+ Wenn Sie EC2 im `bridge` Netzwerkmodus verwenden, kann die `FLUENT_HOST` Umgebungsvariable in Ihrem Anwendungscontainer nach einem Neustart des FireLens Log Router-Containers (des Containers mit dem `firelensConfiguration` Objekt in seiner Containerdefinition) ungenau werden. Das liegt daran, dass `FLUENT_HOST` eine dynamische IP-Adresse ist, die sich nach einem Neustart ändern kann. Die direkte Protokollierung vom Anwendungs-Container zur `FLUENT_HOST` IP-Adresse kann nach einer Adressänderung fehlschlagen. Mehr über `FLUENT_HOST` erfahren Sie unter [Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).
+ Der Amazon-ECS-Agent kümmert sich um die Container-Neustart-Richtlinien. Wenn der Amazon-ECS-Agent aus einem unerwarteten Grund ausfällt oder nicht mehr läuft, wird der Container nicht neu gestartet.
+ Der in Ihrer Richtlinie definierte Zeitraum für Neustartversuche bestimmt den Zeitraum (in Sekunden), für den der Container ausgeführt werden muss, bevor Amazon ECS einen Container neu startet.
# Angeben einer Container-Neustart-Richtlinie in einer Amazon-ECS-Aufgabendefinition
Um eine Neustart-Richtlinie für einen Container in einer Aufgabendefinition anzugeben, geben Sie in der Container-Definition das `restartPolicy`-Objekt an. Weitere Informationen über das `restartPolicy`-Objekt finden Sie unter [Neustartrichtlinie](task_definition_parameters.md#container_definition_restart_policy).
Nachfolgend finden sehen Sie eine Aufgabendefinition mit Linux-Containern in Fargate, die einen Webserver einrichtet: Die Container-Definition umfasst das `restartPolicy`-Objekt, wobei `enabled` auf „true“ gesetzt ist, um eine Neustart-Richtlinie für den Container zu aktivieren. Der Container muss 180 Sekunden lang laufen, bevor er neu gestartet werden kann. Er wird nicht neu gestartet, wenn er mit dem Exit-Code `0` beendet wird, der auf Erfolg hinweist.
```
{
"containerDefinitions": [
{
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"entryPoint": ["sh", "-c"],
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:2.4",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"name": "sample-fargate-app",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"restartPolicy": {
"enabled": true,
"ignoredExitCodes": [0],
"restartAttemptPeriod": 180
}
}
],
"cpu": "256",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"family": "fargate-task-definition",
"memory": "512",
"networkMode": "awsvpc",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"requiresCompatibilities": ["FARGATE"]
}
```
Nachdem Sie mit eine Aufgabendefinition mit dem `restartPolicy`-Objekt in einer Container-Definition registriert haben, können Sie mit dieser Aufgabendefinition eine Aufgabe ausführen oder einen Service erstellen. Weitere Informationen erhalten Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md) und [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md).
# Sensible Daten an einen Amazon-ECS-Container übergeben
Sie können vertrauliche Daten, wie z. B. Anmeldeinformationen für eine Datenbank, sicher in Ihren Container übergeben.
Secrets, wie API-Schlüssel und Datenbankanmeldeinformationen, werden häufig von Anwendungen verwendet, um auf andere Systeme zuzugreifen. Sie bestehen häufig aus einem Benutzernamen und einem Passwort, einem Zertifikat oder einem API-Schlüssel. Der Zugriff auf diese Secrets sollte auf bestimmte IAM-Prinzipale beschränkt werden, die IAM verwenden und zur Laufzeit in Container eingespeist werden.
Secrets können nahtlos aus AWS Secrets Manager einem Amazon EC2 Systems Manager Parameter Store in Container eingefügt werden. Auf diese Secrets kann in Ihrer Aufgabe wie folgt verwiesen werden.
1. Sie werden als Umgebungsvariablen referenziert, die den `secrets`-Container-Definitionsparameter verwenden.
1. Sie werden als `secretOptions` bezeichnet, wenn Ihre Protokollierungsplattform eine Authentifizierung erfordert. Weitere Informationen finden Sie unter [Konfigurationsoptionen für die Protokollierung](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents).
1. Sie werden als Secrets bezeichnet, die von Images abgerufen werden, die den `repositoryCredentials`-Container-Definitionsparameter verwenden, wenn die Registrierung, aus der der Container abgerufen wird, eine Authentifizierung erfordert. Verwenden Sie diese Methode, wenn Sie Images aus Amazon ECR Public Gallery abrufen. Weitere Informationen finden Sie unter [Private Registrierungsauthentifizierung für Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).
Wir empfehlen Ihnen, bei der Einrichtung der Verwaltung von Secrets wie folgt vorzugehen.
## Verwenden Sie AWS Secrets Manager unseren AWS Systems Manager Parameter Store zum Speichern geheimer Materialien
Sie sollten API-Schlüssel, Datenbank-Anmeldeinformationen und andere geheime Materialien sicher in Secrets Manager oder als verschlüsselte Parameter im Systems Manager Parameter Store speichern. Diese Dienste ähneln sich, da es sich bei beiden um verwaltete Schlüsselwertspeicher handelt, die AWS KMS zur Verschlüsselung sensibler Daten verwendet werden. Secrets Manager bietet jedoch auch die Möglichkeit, Geheimnisse automatisch zu rotieren, Zufalls-Geheimnisse zu generieren und Geheimnisse über Konten hinweg freizugeben. Verwenden Sie Secrets Manager, um diese Features zu nutzen. Verwenden Sie andernfalls verschlüsselte Parameter im Systems Manager Parameter Store.
**Wichtig**
Wenn sich Ihr Secret ändert, müssen Sie eine neue Bereitstellung erzwingen oder eine neue Aufgabe starten, um den neuesten Secret-Wert abzurufen. Weitere Informationen finden Sie unter den folgenden Themen:
Aufgaben – Stoppen Sie die Aufgabe und starten Sie sie dann. Weitere Informationen erhalten Sie unter [Beenden einer Amazon-ECS-Aufgabe](standalone-task-stop.md) und [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).
Service – Aktualisieren Sie den Service und verwenden Sie die Option Neue Bereitstellung erzwingen. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md).
## Daten aus einem verschlüsselten Amazon-S3-Bucket abrufen
Sie sollten Geheimnisse in einem verschlüsselten Amazon-S3-Bucket speichern und Aufgabenrollen verwenden, um den Zugriff auf diese Geheimnisse zu beschränken. Dadurch wird verhindert, dass die Werte von Umgebungsvariablen versehentlich in die Protokolle gelangen und bei der Ausführung von `docker inspect` aufgedeckt werden. Wenn Sie dies tun, muss Ihre Anwendung so geschrieben werden, dass sie das Secret aus dem Amazon-S3-Bucket liest. Anweisungen dazu finden Sie unter [Festlegen des standardmäßigen serverseitigen Verschlüsselungsverhaltens für Amazon-S3-Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html).
## Das Secret mit Hilfe eines Beiwagen-Containers in ein Volume mounten
Da bei Umgebungsvariablen ein erhöhtes Risiko von Datenlecks besteht, sollten Sie einen Sidecar-Container verwenden, der Ihre geheimen Daten liest AWS Secrets Manager und auf ein gemeinsam genutztes Volume schreibt. Dieser Container kann vor dem Anwendungscontainer ausgeführt und beendet werden, indem Sie [Amazon-ECS-Container-Anordnungen](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) verwenden. Wenn Sie dies tun, mountet der Anwendungscontainer anschließend das Volume, auf dem das Secret geschrieben wurde. Wie bei der Amazon-S3-Bucket-Methode muss Ihre Anwendung so geschrieben werden, dass sie das Secret aus dem gemeinsam genutzten Volume liest. Da das Volume auf die Aufgabe beschränkt ist, wird das Volume nach dem Beenden der Aufgabe automatisch gelöscht. Ein Beispiel finden Sie im Projekt [task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json).
In Amazon EC2 kann das Volume, auf welches das Secret geschrieben wird, mit einem vom Kunden verwalteten AWS KMS -Schlüssel verschlüsselt werden. Bei aktivierter AWS Fargate Option wird der Datenträgerspeicher automatisch mithilfe eines vom Service verwalteten Schlüssels verschlüsselt.
# Eine einzelne Umgebungsvariable an einen Amazon-ECS-Container übergeben
**Wichtig**
Wir empfehlen, Ihre sensiblen Daten entweder in AWS Secrets Manager Secrets- oder AWS Systems Manager Parameter Store-Parametern zu speichern. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
Die in der Aufgabendefinition angegebenen Umgebungsvariablen sind für alle Benutzer und Rollen lesbar, die die `DescribeTaskDefinition`-Aktion für die Aufgabendefinition durchführen dürfen.
Sie können Umgebungsvariablen auf folgende Weise an Ihre Container übergeben:
+ Individuell mit dem `environment`-Containerdefinitionsparameter. Dies wird auf die Option `--env` abgebildet, um auf die [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) zu verweisen.
+ Verwenden Sie den Container-Definitionsparameter `environmentFiles`, um eine oder mehrere Dateien aufzulisten, die die Umgebungsvariablen enthalten. Die Datei muss in Amazon S3 gehostet werden. Dies wird auf die Option `--env-file` abgebildet, um auf die [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) zu verweisen.
Im Folgenden finden Sie ein Ausschnitt aus einer Aufgabendefinition, in dem gezeigt wird, wie einzelne Umgebungsvariablen angegeben werden.
```
{
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
...
"environment": [
{
"name": "variable",
"value": "value"
}
],
...
}
],
...
}
```
# Umgebungsvariablen an einen Amazon-ECS-Container übergeben
**Wichtig**
Wir empfehlen, Ihre sensiblen Daten entweder in AWS Secrets Manager Secrets- oder AWS Systems Manager Parameter Store-Parametern zu speichern. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
Umgebungsvariablen-Dateien sind Objekte in Amazon S3, und es gelten alle Sicherheitsüberlegungen von Amazon S3.
Sie können den `environmentFiles`-Parameter nicht für Windows-Container und Windows-Container in Fargate verwenden.
Sie können eine Umgebungsvariablendatei erstellen und in Amazon S3 speichern, um Umgebungsvariablen an Ihren Container zu übergeben.
Durch das Angeben von Umgebungsvariablen in einer Datei können Sie Umgebungsvariablen gesammelt einfügen. Geben Sie innerhalb der Containerdefinition das Objekt `environmentFiles` mit einer Liste von Amazon S3-Buckets an, die Ihre Umgebungsvariablendateien enthalten.
Amazon ECS erzwingt keine Größenbeschränkung für die Umgebungsvariablen, aber eine große Umgebungsvariablendatei kann den Speicherplatz auffüllen. Jede Aufgabe, die eine Umgebungsvariablendatei verwendet, bewirkt, dass eine Kopie der Datei auf den Datenträger heruntergeladen wird. Amazon ECS entfernt die Datei als Teil der Aufgabenbereinigung.
Informationen zu den unterstützten Umgebungsvariablen finden Sie unter [Erweiterte Container-Definitionsparameter – Umgebung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment).
Berücksichtigen Sie Folgendes, wenn eine Umgebungsvariablendatei in einer Containerdefinition angegeben wird.
+ Für Amazon-ECS-Aufgaben auf Amazon EC2 benötigen Ihre Container-Instances die Container-Agenten-Version `1.39.0` oder höher, um dieses Feature verwenden zu können. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
+ Für Amazon ECS-Aufgaben auf AWS Fargate müssen Ihre Aufgaben die Plattformversion `1.4.0` oder höher (Linux) verwenden, um diese Funktion nutzen zu können. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
Stellen Sie sicher, dass die Variable für die Betriebssystem-Plattform unterstützt wird. Weitere Informationen erhalten Sie unter [Containerdefinitionen](task_definition_parameters.md#container_definitions) und [Andere Parameter der Aufgabendefinition](task_definition_parameters.md#other_task_definition_params).
+ Die Datei muss die `.env`-Dateierweiterung und die UTF-8-Kodierung verwenden.
+ Die Aufgabenausführungsrolle ist erforderlich, um dieses Feature mit den zusätzlichen Berechtigungen für Amazon S3 zu verwenden. Auf diese Weise kann der Container-Agent die Umgebungsvariablendatei von Amazon S3 abrufen. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
+ Es gibt ein Limit von 10 Dateien pro Aufgabendefinition.
+ Jede Zeile in einer Umgebungsdatei muss eine Umgebungsvariable im Format `VARIABLE=VALUE` enthalten. Leerzeichen oder Anführungszeichen **werden** als Teil der Werte für Amazon-ECS-Dateien einbezogen. Zeilen, die mit `#` beginnen, werden als Kommentare behandelt und ignoriert. Weitere Informationen zur Syntax der Umgebungsvariablendatei finden Sie unter [Setzen von Umgebungsvariablen (-e, --env, --env-file)](https://docs.docker.com/reference/cli/docker/container/run/#env) in der Docker-Dokumentation.
Im Folgenden finden Sie die entsprechende Syntax.
```
#This is a comment and will be ignored
VARIABLE=VALUE
ENVIRONMENT=PRODUCTION
```
+ Wenn Umgebungsvariablen mit dem `environment`-Parameter in einer Containerdefinition angegeben sind, haben sie Vorrang vor den Variablen, die in einer Umgebungsdatei enthalten sind.
+ Wenn mehrere Umgebungsdateien angegeben sind und sie dieselbe Variable enthalten, werden sie in der Reihenfolge ihres Eintrags verarbeitet. Dies bedeutet, dass der erste Wert der Variablen verwendet wird und nachfolgende Werte doppelter Variablen ignoriert werden. Es wird empfohlen, eindeutige Variablennamen zu verwenden.
+ Wenn eine Umgebungsdatei als Container-Überschreibung angegeben wird, wird sie verwendet. Darüber hinaus werden alle anderen Umgebungsdateien ignoriert, die in der Containerdefinition angegeben sind.
+ Die folgenden Regeln gelten für Fargate:
+ Die Datei wird wie eine native env.file-Docker-Datei behandelt.
+ Container-Definitionen, die auf Umgebungsvariablen verweisen, die leer sind und in Amazon S3 gespeichert sind, werden nicht im Container angezeigt.
+ Es gibt keine Unterstützung für Shell-Escape-Handling.
+ Der Container-Einstiegspunkt interpretiert die `VARIABLE`-Werte.
## Beispiel
Im Folgenden finden Sie ein Ausschnitt aus einer Aufgabendefinition, in dem gezeigt wird, wie eine Umgebungsvariablendatei angegeben wird.
```
{
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
...
"environmentFiles": [
{
"value": "arn:aws:s3:::amzn-s3-demo-bucket/envfile_object_name.env",
"type": "s3"
}
],
...
}
],
...
}
```
# Secrets-Manager-Geheimnisse programmgesteuert in Amazon ECS weitergeben
Anstatt sensible Daten in Ihrer Anwendung im Klartext fest zu kodieren, können Sie Secrets Manager verwenden, um die sensiblen Daten zu speichern.
Wir empfehlen diese Methode zum Abrufen vertraulicher Daten, da die Anwendung automatisch die neueste Version des Secrets-Manager-Geheimnisses abruft, wenn das Secrets-Manager-Geheimnis anschließend aktualisiert wird.
Erstellen Sie ein Geheimnis in Secrets Manager. Nachdem Sie ein Secrets-Manager-Geheimnis erstellt haben, aktualisieren Sie Ihren Anwendungscode, um das Geheimnis abzurufen.
Lesen Sie die folgenden Überlegungen, bevor Sie vertrauliche Daten in Secrets Manager sichern.
+ Es werden nur Geheimnisse unterstützt, die Textdaten speichern, bei denen es sich um Geheimnisse handelt, die mit dem `SecretString` [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API-Parameter erstellt wurden. Geheimnisse, die Binärdaten speichern, bei denen es sich um Geheimnisse handelt, die mit dem `SecretBinary` [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API-Parameter erstellt wurden, werden nicht unterstützt.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern. Sie müssen die Schnittstellen-VPC-Endpunkte für den Secrets Manager erstellen. Informationen über den VPC-Endpunkt finden Sie unter [VPC-Endpunkte erstellen](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) im *AWS Secrets Manager -Benutzerhandbuch*.
+ Die von Ihrer Aufgabe verwendete VPC muss die DNS-Auflösung verwenden.
+ Ihre Aufgabendefinition muss eine Aufgabenrolle mit den zusätzlichen Berechtigungen für Secrets Manager verwenden. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).
## Erstellen des Secrets-Manager-Geheimnisses
Sie können die Secrets Manager-Konsole verwenden, um ein Secret für Ihre sensiblen Daten zu erstellen. Informationen zum Erstellen von Geheimnissen finden Sie unter [Erstellen eines AWS Secrets Manager -Geheimnisses](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *AWS Secrets Manager -Benutzerhandbuch*.
## Aktualisieren Sie Ihre Anwendung, um Secrets-Manager-Geheimnisse programmgesteuert abzurufen
Sie können Secrets mit einem Aufruf des Secrets Manager APIs direkt aus Ihrer Anwendung abrufen. Weitere Informationen finden Sie unter [Abrufen von Geheimnissen aus AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) im *Benutzerhandbuch für AWS Secrets Manager *.
Informationen zum Abrufen der in der AWS Secrets Manager gespeicherten vertraulichen Daten finden Sie unter [Codebeispiele zur AWS Secrets Manager Verwendung AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html) in der *AWS SDK-Codebeispiel-Codebibliothek*.
# Geheimnisse von Systems Manager Parameter Store programmgesteuert in Amazon ECS übergeben
Systems Manager Parameter Store ermöglicht die sichere Speicherung und Verwaltung von Geheimnissen. Sie können Daten wie Passwörter, Datenbankzeichenfolgen, EC2-Instance IDs und AMI IDs sowie Lizenzcodes als Parameterwerte speichern, anstatt diese Informationen in Ihrer Anwendung fest zu codieren. Sie können Werte als Klartext oder als verschlüsselte Daten speichern.
Wir empfehlen diese Methode zum Abrufen sensible Daten, da die Anwendung automatisch die neueste Version abruft, wenn der Parameter für Secrets Manager Parameter Store danach aktualisiert wird.
Lesen Sie die folgenden Überlegungen, bevor Sie sensible Daten im Systems Manager Parameter Store sichern.
+ Es werden nur Geheimnisse unterstützt, die Textdaten speichern. Geheimnisse zum Speichern von Binärdaten werden nicht unterstützt.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern.
+ Die von Ihrer Aufgabe verwendete VPC muss die DNS-Auflösung verwenden.
+ Für Aufgaben, die EC2 verwenden, müssen Sie die Amazon-ECS-Agent-Konfigurationsvariable `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` verwenden, um dieses Feature verwenden zu können. Sie können sie während der Erstellung der Container-Instance zur Datei `/etc/ecs/ecs.config` hinzufügen oder sie zu einer vorhandenen Instance hinzufügen und dann den ECS-Agenten neu starten. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
+ Ihre Aufgabendefinition muss eine Aufgabenrolle mit den zusätzlichen Berechtigungen für Systems Manager Parameter Store verwenden. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).
## Erstellen des -Parameters
Sie können die Systems-Manager-Konsole verwenden, um einen Parameter des Systems Manager Parameter Stores für Ihre sensiblen Daten zu erstellen. Weitere Informationen finden Sie im *AWS Systems Manager -Benutzerhandbuch* unter [Erstellen eines Systems-Manager-Parameters (Konsole)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) oder [Erstellen eines Systems-Manager-Parameters (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html).
## Aktualisieren Sie Ihre Anwendung, um die Geheimnisse des Systems-Manager-Parameter-Speichers programmgesteuert abzurufen
Informationen zum Abrufen der sensiblen Daten, die im Parameter Store-Parameter von Systems Manager gespeichert sind, finden Sie unter [Codebeispiele für die Verwendung durch Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) in der *AWS SDK-Codebeispiel-Codebibliothek*.
# Secrets-Manager-Geheimnisse über Amazon-ECS-Umgebungsvariablen weitergeben
Wenn Sie ein Geheimnis als Umgebungsvariable einfügen, können Sie den vollständigen Inhalt eines Geheimnisses oder eines bestimmten JSON-Schlüssels innerhalb eines Secrets Geheimnisses angeben. Das hilft Ihnen, die sensiblen Daten zu steuern, die Ihrem Container zur Verfügung gestellt werden. Weitere Informationen zur Geheimnis-Versionsverwaltung finden Sie unter [Was ist in einem Secrets-Manager-Geheimnis enthalten?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version) im *Benutzerhandbuch für AWS Secrets Manager *.
Folgendes sollte bei der Injektion eines Secrets-Manager-Geheimnisses in einen Container mit einer Umgebungsvariable berücksichtigt werden.
+ Sensible Daten werden beim ersten Start des Containers an diesen übergeben. Wenn das Secret anschließend aktualisiert oder rotiert wird, erhält der Container nicht automatisch den aktualisierten Wert. Sie müssen eine neue Aufgabe starten. Alternativ können Sie, wenn Ihre Aufgabe Teil eines Services ist, den Service aktualisieren und die Option **Force new deployment (Neue Bereitstellung erzwingen)** auswählen, um den Service zu zwingen, eine neue Aufgabe zu starten.
+ Anwendungen, die auf dem Container ausgeführt werden sowie Container-Protokolle und Debugging-Tools haben Zugriff auf die Umgebungsvariablen.
+ Beachten Sie bei Amazon ECS-Aufgaben Folgendes: AWS Fargate
+ Um den vollständigen Inhalt eines Secrets als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.3.0` oder höher verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
+ Um einen bestimmten JSON-Schlüssel oder eine Version eines Geheimnisses als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` (Windows) verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
+ Bei Amazon ECS-Aufgaben auf EC2 sollte Folgendes berücksichtigt werden:
+ Um einen geheimen Schlüssel mithilfe eines bestimmten JSON-Schlüssels oder einer Secret-Version einzufügen, muss Ihre Container-Instance Version `1.37.0` oder höher des Container-Agenten haben. Wir empfehlen jedoch, die neueste Version des Container-Agenten zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
Um den vollständigen Inhalt eines Secrets als Umgebungsvariable einzufügen oder ein Secret in eine Protokollkonfiguration einzufügen, muss Ihre Container-Instance Version `1.22.0` oder höher des Container-Agenten haben.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern und über ein privates Subnetz eine Verbindung zu Secrets Manager herzustellen. Sie müssen die Schnittstellen-VPC-Endpunkte für den Secrets Manager erstellen. Informationen über den VPC-Endpunkt finden Sie unter [VPC-Endpunkte erstellen](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) im *AWS Secrets Manager -Benutzerhandbuch*. Weitere Informationen zur Verwendung von Secrets Manager und Amazon VPC finden Sie unter [So stellen Sie in einer Amazon-VPC eine Verbindung zu Secrets Manager her](https://aws.amazon.com/blogs//security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual-private-cloud/).
+ Für Windows-Aufgaben, die für die Verwendung des `awslogs`-Protokolltreibers konfiguriert sind, müssen Sie auch die `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE`-Umgebungsvariable für die Container-Instance festlegen. Verwenden Sie die folgende Syntax:
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
```
+ Ihre Aufgabendefinition muss eine Aufgabenausführungsrolle mit den zusätzlichen Berechtigungen für Secrets Manager verwenden. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
## Erstellen Sie das AWS Secrets Manager Geheimnis
Sie können die Secrets Manager-Konsole verwenden, um ein Secret für Ihre sensiblen Daten zu erstellen. Weitere Informationen finden Sie im *AWS Secrets Manager Benutzerhandbuch* unter [Create an AWS Secrets Manager Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).
## Fügen Sie die Umgebungsvariable zur Container-Definition hinzu
Innerhalb der Containerdefinition können Sie Folgendes angeben:
+ Das `secrets`-Objekt, das den Namen der Umgebungsvariablen enthält, die im Container festgelegt werden soll
+ Der Amazon-Ressourcenname (ARN) des Secrets Manager-Secrets
+ Zusätzliche Parameter, die die sensiblen Daten enthalten, die dem Container angezeigt werden sollen
Das folgende Beispiel zeigt die vollständige Syntax, die für das Secrets Manager-Secret angegeben werden muss.
```
arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key:version-stage:version-id
```
Im folgenden Abschnitt werden die zusätzlichen Parameter beschrieben. Diese Parameter sind optional, aber wenn Sie sie nicht verwenden, müssen Sie die Doppelpunkte einschließen, damit `:` die Standardwerte verwendet. Beispiele finden Sie unten für weiteren Kontext.
`json-key`
Gibt den Namen des Schlüssels in einem Schlüssel-Wert-Paar mit dem Wert an, den Sie als Umgebungsvariablenwert festlegen möchten. Nur Werte im JSON-Format werden unterstützt. Wenn Sie keinen JSON-Schlüssel angeben, wird der vollständige Inhalt des Secrets verwendet.
`version-stage`
Gibt die Phasenbeschriftung der Version eines Secrets an, die Sie verwenden möchten. Wenn eine Versionsphasenbeschriftung angegeben ist, können Sie keine Versions-ID angeben. Wenn keine Versionsphase angegeben wird, besteht das Standardverhalten darin, das Secret Schlüssel mit der `AWSCURRENT`-Phasenbeschriftung abzurufen.
Phasenbeschriftungen werden verwendet, um verschiedene Versionen eines Secrets zu verfolgen, wenn sie aktualisiert oder rotiert werden. Jede Version eines Secrets hat eine oder mehrere Phasenbeschriftungen und eine ID.
`version-id`
Gibt die eindeutige ID der Version des Secrets an, die Sie verwenden möchten. Wenn eine Versions-ID angegeben wird, können Sie keine Versionsphasenbeschriftung angeben. Wenn keine Versions-ID angegeben wird, besteht das Standardverhalten darin, den geheimen Schlüssel mit der `AWSCURRENT`-Phasenbeschriftung abzurufen.
Versionen IDs werden verwendet, um den Überblick über verschiedene Versionen eines Geheimnisses zu behalten, wenn sie entweder aktualisiert oder ausgetauscht werden. Jede Version eines Secrets hat eine ID. Weitere Informationen erhalten Sie unter [Zentrale Begriffe und Konzepte für AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret) im *AWS Secrets Manager -Benutzerhandbuch*.
### Beispiel-Containerdefinitionen
Die folgenden Beispiele zeigen, wie Sie auf Secrets Manager-Secrets in Ihren Containerdefinitionen verweisen können.
**Example Verweisen auf ein vollständiges Secret**
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf den vollständigen Text eines Secrets Manager-Secret.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
}]
}]
}
```
Um innerhalb des Containers auf den Wert dieses Geheimnisses zuzugreifen, müssten Sie den `$environment_variable_name` aufrufen.
**Example Verweisen auf vollständige Secrets**
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf den vollständigen Text mehrerer Secrets-Manager-Geheimnisse.
```
{
"containerDefinitions": [{
"secrets": [
{
"name": "environment_variable_name1",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
},
{
"name": "environment_variable_name2",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-abcdef"
},
{
"name": "environment_variable_name3",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-ABCDEF"
}
]
}]
}
```
Um innerhalb des Containers auf den Wert dieses Geheimnisses zuzugreifen, müssten Sie `$environment_variable_name1`, `$environment_variable_name2`, und `$environment_variable_name3` aufrufen.
**Example Verweisen auf einen bestimmten Schlüssel innerhalb eines Secrets**
Im Folgenden wird ein Beispiel für die Ausgabe eines [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)Befehls gezeigt, der den Inhalt eines Secrets zusammen mit der zugehörigen Staging-Bezeichnung der Version und der zugehörigen Versions-ID anzeigt.
```
{
"ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
"Name": "appauthexample",
"VersionId": "871d9eca-18aa-46a9-8785-981ddEXAMPLE",
"SecretString": "{\"username1\":\"password1\",\"username2\":\"password2\",\"username3\":\"password3\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1581968848.921
}
```
Verweisen Sie auf einen bestimmten Schlüssel aus der vorherigen Ausgabe in einer Containerdefinition, indem Sie den Schlüsselnamen am Ende des ARN angeben.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::"
}]
}]
}
```
**Example Verweisen auf eine bestimmte Secret-Version**
Im Folgenden wird eine Beispielausgabe eines [describe-secret ](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html)-Befehls gezeigt, der den unverschlüsselten Inhalt eines Secrets zusammen mit den Metadaten für alle Versionen des Secrets anzeigt.
```
{
"ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
"Name": "appauthexample",
"Description": "Example of a secret containing application authorization data.",
"RotationEnabled": false,
"LastChangedDate": 1581968848.926,
"LastAccessedDate": 1581897600.0,
"Tags": [],
"VersionIdsToStages": {
"871d9eca-18aa-46a9-8785-981ddEXAMPLE": [
"AWSCURRENT"
],
"9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE": [
"AWSPREVIOUS"
]
}
}
```
Verweisen Sie auf eine bestimmte Versionsphasenbeschriftung aus der vorherigen Ausgabe in einer Containerdefinition, indem Sie den Schlüsselnamen am Ende des ARN angeben.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:"
}]
}]
}
```
Verweisen Sie auf eine bestimmte Versions-ID der vorherigen Ausgabe in einer Containerdefinition, indem Sie den Schlüsselnamen am Ende des ARN angeben.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
}]
}]
}
```
**Example Verweisen auf einen bestimmten Schlüssel und eine Versionsphasenbeschriftung eines Secrets**
Im Folgenden wird gezeigt, wie Sie sowohl auf einen bestimmten Schlüssel innerhalb eines Secrets als auch auf eine bestimmte Versionsphasenbeschriftung verweisen.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:"
}]
}]
}
```
Verwenden Sie die folgende Syntax, um einen bestimmten Schlüssel und eine Versions-ID anzugeben.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
}]
}]
}
```
Informationen zum Erstellen einer Aufgabendefinition mit dem in einer Umgebungsvariable angegebenen Geheimnis finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
# Systems-Manager-Parameter über Amazon-ECS-Umgebungsvariablen weitergeben
Amazon ECS ermöglicht es Ihnen, vertrauliche Daten in Ihre Container einzufügen, indem Sie Ihre sensiblen Daten in AWS Systems Manager Parameter Store-Parametern speichern und sie dann in Ihrer Container-Definition referenzieren.
Folgendes sollte beachtet werden, wenn eine Umgebungsvariable zum Einfügen eines System-Manager-Geheimnisses in einen Container verwendet wird.
+ Sensible Daten werden beim ersten Start des Containers an diesen übergeben. Wenn das Secret anschließend aktualisiert oder rotiert wird, erhält der Container nicht automatisch den aktualisierten Wert. Sie müssen eine neue Aufgabe starten. Alternativ können Sie, wenn Ihre Aufgabe Teil eines Services ist, den Service aktualisieren und die Option **Force new deployment (Neue Bereitstellung erzwingen)** auswählen, um den Service zu zwingen, eine neue Aufgabe zu starten.
+ Bei Amazon ECS-Aufgaben sollte Folgendes beachtet werden: AWS Fargate
+ Um den vollständigen Inhalt eines Secrets als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.3.0` oder höher verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
+ Um einen bestimmten JSON-Schlüssel oder eine Version eines Geheimnisses als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` (Windows) verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
+ Bei Amazon ECS-Aufgaben auf EC2 sollte Folgendes berücksichtigt werden:
+ Um einen geheimen Schlüssel mithilfe eines bestimmten JSON-Schlüssels oder einer Secret-Version einzufügen, muss Ihre Container-Instance Version `1.37.0` oder höher des Container-Agenten haben. Wir empfehlen jedoch, die neueste Version des Container-Agenten zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
Um den vollständigen Inhalt eines Secrets als Umgebungsvariable einzufügen oder ein Secret in eine Protokollkonfiguration einzufügen, muss Ihre Container-Instance Version `1.22.0` oder höher des Container-Agenten haben.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern. Sie müssen die Schnittstellen-VPC-Endpunkte für Systems Manager erstellen. Weitere Informationen über den VPC-Endpunkt finden Sie unter [Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager verbessern](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) im *Benutzerhandbuch für AWS Systems Manager *.
+ Ihre Aufgabendefinition muss eine Aufgabenausführungsrolle mit den zusätzlichen Berechtigungen für Systems Manager Parameter Store verwenden. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
+ Für Windows-Aufgaben, die für die Verwendung des `awslogs`-Protokolltreibers konfiguriert sind, müssen Sie auch die `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE`-Umgebungsvariable für die Container-Instance festlegen. Verwenden Sie die folgende Syntax:
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
```
## Den Systems-Manager-Parameter erstellen
Sie können die Systems-Manager-Konsole verwenden, um einen Parameter des Systems Manager Parameter Stores für Ihre sensiblen Daten zu erstellen. Weitere Informationen finden Sie im *AWS Systems Manager -Benutzerhandbuch* unter [Erstellen eines Systems-Manager-Parameters (Konsole)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) oder [Erstellen eines Systems-Manager-Parameters (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html).
## Fügen Sie die Umgebungsvariable zur Container-Definition hinzu
Geben Sie innerhalb Ihrer Container-Definition in der Aufgabendefinition `secrets` an, und geben Sie dabei den Namen der im Container einzustellenden Umgebungsvariable und den vollständigen ARN des Parameters von Systems Manager Parameter Store an, der die sensiblen Daten enthält, die dem Container präsentiert werden sollen. Weitere Informationen finden Sie unter [secrets](task_definition_parameters.md#ContainerDefinition-secrets).
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf einen Systems Manager Parameter Store-Parameter. Wenn sich der Systems Manager Parameter Store-Parameter in der gleichen Region wie die Aufgabe befindet, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Parameters verwenden. Wenn der Parameter in einer anderen Region existiert, geben Sie den vollen ARN an.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}]
}]
}
```
Informationen zum Erstellen einer Aufgabendefinition mit dem in einer Umgebungsvariable angegebenen Geheimnis finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
## Aktualisieren Sie Ihre Anwendung, um die Geheimnisse des Systems-Manager-Parameter-Speichers programmgesteuert abzurufen
Informationen zum Abrufen der sensiblen Daten, die im Parameter Store-Parameter von Systems Manager gespeichert sind, finden Sie unter [Codebeispiele für die Verwendung durch Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) in der *AWS SDK-Codebeispiel-Codebibliothek*.
# Geheimnisse für die Amazon-ECS-Protokollierungskonfiguration weitergeben
Sie können den `secretOptions`-Parameter in `logConfiguration` verwenden, um sensible Daten zu übergeben, die für die Protokollierung verwendet werden.
Sie können das Geheimnis in Secrets Manager oder Systems Manager speichern.
## Secrets Manager verwenden
Bei der Angabe von `logConfiguration` können Sie `secretOptions` in Ihrer Containerdefinition mit dem Namen der im Container festzulegenden Protokolltreiberoption und dem vollständigen ARN des Secrets Manager-Secrets angeben, in dem die sensiblen Daten enthalten sind, die dem Container zur Verfügung gestellt werden sollen. Weitere Informationen zum Erstellen von Geheimnissen finden Sie unter [Erstellen eines AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf ein Secrets Manager-Secret.
```
{
"containerDefinitions": [{
"logConfiguration": [{
"logDriver": "splunk",
"options": {
"splunk-url": "https://your_splunk_instance:8088"
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
}]
}]
}]
}
```
## Fügen Sie die Umgebungsvariable zur Container-Definition hinzu
Geben Sie in Ihrer Containerdefinition `secrets` mit dem Namen der im Container zu setzenden Umgebungsvariablen und dem Namen oder dem ARN des Systems Manager-Parameter Store-Parameters an, der die sensiblen Daten enthält, die dem Container präsentiert werden sollen. Weitere Informationen finden Sie unter [secrets](task_definition_parameters.md#ContainerDefinition-secrets).
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf einen Systems Manager Parameter Store-Parameter. Wenn sich der Systems Manager Parameter Store-Parameter in der gleichen Region wie die Aufgabe befindet, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Parameters verwenden. Wenn der Parameter in einer anderen Region existiert, geben Sie den vollen ARN an.
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}]
}]
}
```
Informationen zum Erstellen einer Aufgabendefinition mit dem in einer Umgebungsvariable angegebenen Geheimnis finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
## Verwenden von Systems Manager
Sie können vertrauliche Daten in eine Protokollkonfiguration einfügen. Beim Angeben von `logConfiguration` können Sie `secretOptions` in Ihrer Containerdefinition mit dem Namen der im Container festzulegenden Protokolltreiberoption und dem vollständigen ARN des Systems Manager-Parameter Store-Parameters angeben, in denen die sensiblen Daten enthalten sind, die dem Container präsentiert werden sollen.
**Wichtig**
Wenn sich der Systems Manager Parameter Store-Parameter in der gleichen Region wie die Aufgabe befindet, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Parameters verwenden. Wenn der Parameter in einer anderen Region existiert, geben Sie den vollen ARN an.
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf einen Systems Manager Parameter Store-Parameter.
```
{
"containerDefinitions": [{
"logConfiguration": [{
"logDriver": "fluentd",
"options": {
"tag": "fluentd demo"
},
"secretOptions": [{
"name": "fluentd-address",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter:/parameter_name"
}]
}]
}]
}
```
# Angeben sensibler Daten mithilfe von Secrets-Manager-Geheimnissen in Amazon ECS
Amazon ECS ermöglicht es Ihnen, vertrauliche Daten in Ihre Container einzufügen, indem Sie Ihre sensiblen Daten in AWS Secrets Manager Geheimnissen speichern und dann in Ihrer Container-Definition auf sie verweisen. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
Das folgende Tutorial zeigt, wie Sie ein Secrets-Manager-Geheimnis erstellen, in einer Amazon-ECS-Aufgabendefinition auf das Geheimnis verweisen und es dann überprüfen, indem Sie die Umgebungsvariable in einem Container abfragen, um den Inhalt des Geheimnisses anzuzeigen.
## Voraussetzungen
In diesem Tutorial wird davon ausgegangen, dass die folgenden Voraussetzungen erfüllt wurden:
+ Die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) wurden ausgeführt.
+ Ihr Benutzer hat die erforderlichen IAM-Berechtigungen zum Erstellen der Secrets-Manager- und Amazon-ECS-Ressourcen.
## Schritt 1: Erstellen eines Secrets Manager-Secrets
Sie können die Secrets Manager-Konsole verwenden, um ein Secret für Ihre sensiblen Daten zu erstellen. In diesem Tutorial erstellen wir ein grundlegendes Secret zum Speichern eines Benutzernamens und eines Passworts zum späteren Verweisen in einem Container. Weitere Informationen finden Sie unter [Create an AWS Secrets Manager Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *AWS Secrets Manager Benutzerhandbuch*.
Die ** key/value Paare, die in diesem Secret gespeichert werden sollen**, entsprechen dem Wert der Umgebungsvariablen in Ihrem Container am Ende des Tutorials.
Speichern Sie den **Secret ARN** (Geheimen ARN), um ihn in späteren Schritten in Ihrer IAM-Richtlinie für die Aufgabenausführung und der Aufgabendefinition zu verwenden.
## Schritt 2: Hinzufügen der Geheimnis-Berechtigungen zur Aufgabenausführungsrolle
Damit Amazon ECS sensible Daten aus Ihrem Secrets-Manager-Geheimnis abrufen kann, benötigen Sie die Geheimnis-Berechtigungen für die Aufgabenausführungsrolle. Weitere Informationen finden Sie unter [Berechtigungen für Secrets Manager oder Systems Manager](task_execution_IAM_role.md#task-execution-secrets).
## Schritt 3: Erstellen einer Aufgabendefinition
Sie können die Amazon-ECS-Konsole verwenden, um eine Aufgabendefinition zu erstellen, die auf ein Secrets Manager-Secret verweist.
**So erstellen Sie eine Aufgabendefinition, die ein Secret angibt**
Verwenden Sie die IAM-Konsole zum Aktualisieren Ihrer Aufgabenausführungsrolle mit den erforderlichen Berechtigungen.
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie **Create new task definition** (Neue Aufgabendefinition erstellen), **Create new task definition with JSON** (Neue Aufgabendefinition mit JSON) erstellen.
1. Geben Sie in das JSON-Editor-Feld den folgenden JSON-Text für die Aufgabendefinition ein. Achten Sie darauf, dass Sie den vollständigen ARN des Secrets-Manager-Geheimnisses, das Sie in Schritt 1 erstellt haben, und die Aufgabenausführungsrolle, die Sie im Schritt 2 aktualisiert haben, angeben. Wählen Sie **Speichern**.
1.
```
{
"executionRoleArn": "arn:aws:iam::aws_account_id:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"entryPoint": [
"sh",
"-c"
],
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
],
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"cpu": 10,
"secrets": [
{
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:username_value",
"name": "username_value"
}
],
"memory": 300,
"image": "public.ecr.aws/docker/library/httpd:2.4",
"essential": true,
"name": "ecs-secrets-container"
}
],
"family": "ecs-secrets-tutorial"
}
```
1. Wählen Sie **Erstellen** aus.
## Schritt 4: Erstellen eines Clusters
Verwenden Sie die Amazon-ECS-Konsole zum Erstellen eines Clusters, der eine Container-Instance zum Ausführen der Aufgabe enthält. Wenn Sie bereits über einen Cluster mit mindestens einer registrierten Container-Instance und den Ressourcen zum Ausführen einer Instance der für dieses Tutorial erstellten Aufgabendefinition verfügen, können Sie direkt zum nächsten Schritt gehen.
Für dieses Tutorial erstellen wir einen Cluster mit einer `t2.micro`-Container-Instance unter Verwendung des Amazon-ECS-optimierten Amazon Linux 2-AMI.
Informationen zum Erstellen eines Clusters für EC2 finden Sie unter [Erstellen eines Amazon-ECS-Clusters für Amazon-EC2-Workloads](create-ec2-cluster-console-v2.md).
## Schritt 5: Führen Sie eine Aufgabe aus
Sie können die Amazon-ECS-Konsole verwenden, um eine Aufgabe mithilfe der Aufgabendefinition auszuführen, die Sie erstellt haben. In diesem Tutorial führen wir eine Aufgabe mit EC2 aus und verwenden dazu den Cluster, den wir im vorherigen Schritt erstellt haben.
Informationen zum Ausführen einer Aufgabe finden Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).
## Schritt 6: Überprüfen
Anhand folgender Schritte können Sie überprüfen, ob alle Schritte erfolgreich abgeschlossen wurden und die Umgebungsvariable in Ihrem Container ordnungsgemäß erstellt wurde.
**Überprüfen, ob die Umgebungsvariable erstellt wurde**
1. Suchen Sie nach der öffentlichen IP-Adresse oder DNS-Adresse für Ihre Container-Instance.
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Cluster** und dann den von Ihnen erstellten Cluster aus.
1. Wählen Sie **Infrastruktur** und dann die Container-Instance aus.
1. Zeichnen Sie die **öffentliche IP** oder das **öffentliche DNS** für Ihre Instance auf.
1. Stellen Sie auf einem macOS- oder Linux-Computer mit dem folgenden Befehl eine Verbindung mit Ihrer Instance her und ersetzen Sie den Pfad zu Ihrem privaten Schlüssel und die öffentliche Adresse für Ihre Instance:
```
$ ssh -i /path/to/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com
```
Weitere Informationen zur Verwendung eines Windows-Computers finden Sie unter [Herstellen einer Verbindung mit Ihrer Linux-Instance mit PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html) im *Amazon-EC2-Benutzerhandbuch*.
**Wichtig**
Weitere Informationen zu Problemen beim Herstellen der Verbindung mit Ihrer Instance finden Sie unter [Beheben von Verbindungsproblemen mit Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) im *Benutzerhandbuch für Amazon EC2*.
1. Erstellen Sie eine Liste der Container, die auf der Instance ausgeführt werden. Notieren Sie die Container-ID für `ecs-secrets-tutorial`-Container.
```
docker ps
```
1. Stellen Sie mithilfe der Container-ID aus der Ausgabe des vorherigen Schritts eine Verbindung mit dem `ecs-secrets-tutorial`-Container her.
```
docker exec -it container_ID /bin/bash
```
1. Verwenden Sie den `echo`-Befehl, um den Wert der Umgebungsvariable zu drucken.
```
echo $username_value
```
Wenn das Tutorial erfolgreich war, sollten Sie die folgende Meldung sehen:
```
password_value
```
**Anmerkung**
Alternativ können Sie alle Umgebungsvariablen in Ihrem Container mithilfe des Befehls `env` (oder `printenv`) auflisten.
## Schritt 7: Bereinigen
Wenn Sie mit diesem Tutorial fertig sind, sollten Sie die zugehörigen Ressourcen bereinigen, um zu vermeiden, dass Gebühren für ungenutzte Ressourcen anfallen.
**So bereinigen Sie die Ressourcen**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie **Delete Cluster** (Cluster löschen) aus.
1. Geben Sie im Bestätigungsfeld **Löschen *cluster name*** ein und wählen Sie dann **Löschen** aus.
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich **Rollen**.
1. Durchsuchen Sie die Liste der Rollen für `ecsTaskExecutionRole` und wählen Sie diese aus.
1. Wähle „**Berechtigungen**“ und dann das **X** neben „**ECSSecretsTutorial**“. Wählen Sie **Remove (Entfernen)** aus.
1. Öffnen Sie die Secrets Manager Manager-Konsole unter [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).
1. Wählen Sie das von Ihnen erstellte **username\$1value**-Secret und **Actions (Aktionen)**, **Delete secret (Secret löschen)**.
# Amazon-ECS-Aufgabendefinitionsparameter für Amazon ECS Managed Instances
Aufgabendefinitionen sind in verschiedene Teile aufgeteilt: die Aufgabenfamilie, die AWS Identity and Access Management (IAM-) Aufgabenrolle, den Netzwerkmodus, Containerdefinitionen, Volumes und Kapazität. Die Familien- und Container-Definitionen sind in einer Aufgabendefinition obligatorisch. Im Gegensatz dazu sind Aufgabenrolle, Netzwerkmodus, Volumes und Kapazität optional.
Sie können diese Parameter in einer JSON-Datei verwenden, um Ihre Aufgabendefinition zu konfigurieren.
Im Folgenden finden Sie detaillierte Beschreibungen für jeden Aufgabendefinitionsparameter für Amazon ECS Managed Instances
## Familie
`family`
Typ: Zeichenfolge
Erforderlich: Ja
Wenn Sie eine Aufgabendefinition registrieren, vergeben Sie eine Familie, ähnlich einem Namen für mehrere Versionen der Aufgabendefinition, die mit einer Revisionsnummer angegeben ist. Die erste Aufgabendefinition, die in einer bestimmten Familie registriert wird, erhält die Revision 1 und alle danach registrierten Definitionen erhalten eine sequenzielle Revisionsnummer.
## Capacity (Kapazität)
Wenn Sie eine Aufgabendefinition registrieren, können Sie die Kapazität angeben, anhand der Amazon ECS die Aufgabendefinition validieren soll. Eine Client-Ausnahme wird zurückgegeben, wenn die Aufgabendefinition nicht anhand der angegebenen Kompatibilitäten validiert. Weitere Informationen finden Sie unter [Amazon-ECS-Starttypen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html).
Der folgende Parameter ist in einer Aufgabendefinition zulässig.
`requiresCompatibilities`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Zulässige Werte: `MANAGED_INSTANCES`
Die Kapazität, anhand der die Aufgabendefinition validiert wird. Dies leitet eine Prüfung ein, um sicherzustellen, dass alle in der Aufgabendefinition verwendeten Parameter den Anforderungen für Amazon ECS Managed Instances entsprechen.
## -Rolle für Aufgabe
`taskRoleArn`
Typ: Zeichenfolge
Erforderlich: Nein
Wenn Sie eine Aufgabendefinition registrieren, können Sie eine Aufgabenrolle für eine IAM-Rolle angeben, die es den Containern in der Aufgabe ermöglicht AWS APIs , die in den zugehörigen Richtlinien angegebenen Aufgaben in Ihrem Namen aufzurufen. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).
## -Rolle für die Aufgabenausführung
`executionRoleArn`
Typ: Zeichenfolge
Required: Conditional
Der Amazon-Ressourcenname (ARN) der Aufgabenausführungsrolle, die dem Amazon ECS-Container-Agenten die Erlaubnis erteilt, AWS API-Aufrufe in Ihrem Namen durchzuführen. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
Die IAM-Rolle für die Aufgabenausführung ist je nach den Anforderungen Ihrer Aufgabe erforderlich. Die Rolle ist für private ECR-Image-Abrufe und die Verwendung des `awslogs` Log-Treibers erforderlich.
## Netzwerkmodus
`networkMode`
Typ: Zeichenfolge
Erforderlich: Nein
Standard: `awsvpc`
Der Netzwerkmodus, der für die Container in der Aufgabe verwendet werden soll. Für Amazon-ECS-Aufgaben, die in Amazon ECS Managed Instances gehostet werden, sind die gültigen Werte `awsvpc` und `host`. Wenn kein Netzwerkmodus angegeben ist, ist der Standard-Netzwerkmodus`awsvpc`.
Wenn der Netzwerkmodus ist`host`, umgeht die Aufgabe die Netzwerkisolierung und Container verwenden den Netzwerkstapel des Hosts direkt.
Wenn Sie Aufgaben im Netzwerkmodus `host` ausführen, sollten Sie aus Sicherheitsgründen Container nicht über den Root-Benutzer (UID 0) ausführen. Verwenden Sie als bewährte Sicherheitsmethode immer einen Nicht-Root-Benutzer.
Für den Netzwerkmodus `awsvpc` wird die Aufgabe einer Elastic-Network-Schnittstelle zugeordnet und Sie müssen eine `NetworkConfiguration` angeben, wenn Sie mit der Aufgabendefinition einen Service erstellen oder eine Aufgabe ausführen wollen. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabenvernetzung für Amazon ECS Managed Instances](managed-instance-networking.md).
Die Netzwerkmodi `host` und `awsvpc` bieten die höchste Netzwerkleistung für Container, da sie den Amazon EC2-Netzwerkstapel verwenden. Für die Netzwerkmodi `host` und `awsvpc` sind die freigegebenen Container-Ports direkt auf den entsprechenden Host-Port (für den Netzwerkmodus `host`) oder den angehängten Elastic-Network-Schnittstellenanschluss (für den Netzwerkmodus `awsvpc`) abgebildet. Aus diesem Grund können Sie keine dynamischen Host-Port-Zuordnungen nutzen.
## Laufzeit-Plattform
`operatingSystemFamily`
Typ: Zeichenfolge
Erforderlich: Nein
Standard: LINUX
Wenn Sie eine Aufgabendefinition anmelden, geben Sie die Betriebssystemfamilie an.
Der gültige Wert für dieses Feld ist `LINUX`.
Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.
Wenn eine Aufgabendefinition Teil eines Services ist, muss dieser Wert mit dem `platformFamily`-Wert des Services übereinstimmen.
`cpuArchitecture`
Typ: Zeichenfolge
Required: Conditional
Wenn Sie eine Aufgabendefinition anmelden, geben Sie die CPU-Architektur an. Die gültigen Werte sind `X86_64` und `ARM64`.
Wenn Sie keinen Wert angeben, versucht Amazon ECS, Aufgaben auf der verfügbaren CPU-Architektur basierend auf der Konfiguration des Kapazitätsanbieters zu platzieren. Um sicherzustellen, dass Aufgaben auf einer bestimmten CPU-Architektur platziert werden, geben Sie `cpuArchitecture` in der Aufgabendefinition einen Wert für an.
Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.
Mehr über `ARM64` erfahren Sie unter [Amazon-ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads](ecs-arm64.md).
## Aufgabengröße
Wenn Sie eine Aufgabendefinition registrieren, können Sie den gesamten CPU- und Arbeitsspeicher für die Aufgabe angeben. Dies erfolgt separat von den Werten `cpu` und `memory` bei der Containerdefinition. Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, sind diese Felder optional.
**Anmerkung**
CPU- und Speicherparameter auf Aufgabenebene werden für Windows-Container ignoriert. Es wird empfohlen, für Windows-Container Ressourcen auf Container-Ebene festzulegen.
`cpu`
Typ: Zeichenfolge
Required: Conditional
Das harte Limit der CPU-Einheiten, die für die Aufgabe vorhanden sind. 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. Wenn die Aufgabendefinition registriert ist, wird ein vCPU-Wert in eine Ganzzahl umgewandelt, die die CPU-Einheiten angibt.
Dies ist ein optionales Feld. Wenn in Ihrem Cluster keine registrierten Container-Instances mit den angeforderten verfügbaren CPU-Einheiten vorhanden sind, schlägt die Aufgabe fehl. Unterstützte Werte liegen zwischen `0.125` `10` v CPUs und CPUs v.
`memory`
Typ: Zeichenfolge
Required: Conditional
Die harte Arbeitsspeichergrenze, die für die Aufgabe zur Verfügung steht. Sie können Speicherwerte in der Aufgabendefinition als Zeichenfolge in Mebibyte (MiB) oder Gigabyte (GB) angeben. Sie können beispielsweise einen Speicherwert entweder als `3072` in MiB oder `3 GB` in GB angeben. Wenn die Aufgabendefinition registriert ist, wird ein GB-Wert in eine Ganzzahl umgewandelt, die die MiB angibt.
Dieses Feld ist optional und ein beliebiger Wert kann verwendet werden. Wenn ein Speicherwert auf Aufgabenebene angegeben wird, ist der Speicherwert auf Container-Ebene optional. Wenn Ihr Cluster keine registrierten Container-Instances mit dem erforderlichen Arbeitsspeicher hat, schlägt die Aufgabe fehl. Sie können Ihre Ressourcennutzung maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen. Weitere Informationen finden Sie unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
## Andere Parameter der Aufgabendefinition
Die folgenden Parameter für die Aufgabendefinition können beim Registrieren von Aufgabendefinitionen in der Amazon-ECS-Konsole mit der Option **Configure via JSON (Über JSON konfigurieren)** verwendet werden. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
**Topics**
+ [Flüchtiger Speicher](#task_definition_ephemeralStorage-managed-instances)
+ [IPC-Modus](#task_definition_ipcmode-managed-instances)
+ [PID-Modus](#task_definition_pidmode-managed-instances)
+ [Proxykonfiguration](#proxyConfiguration-managed-instances)
+ [Tags (Markierungen)](#tags-managed-instances)
+ [Elastic Inference Accelerator (veraltet)](#elastic-Inference-accelerator-managed-instances)
+ [Platzierungsbeschränkungen](#constraints-managed-instances)
+ [Datenträger](#volumes-managed-instances)
### Flüchtiger Speicher
`ephemeralStorage`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Objekt
Erforderlich: Nein
Die Menge des flüchtigen Speichers (in GB), der für die Aufgabe zugewiesen werden soll. Dieser Parameter wird verwendet, um die Gesamtmenge des flüchtigen Speichers über den Standardbetrag hinaus für Aufgaben zu erweitern, die auf AWS Fargate gehostet werden. Weitere Informationen finden Sie unter [Bind-Mounts mit Amazon ECS verwenden](bind-mounts.md).
### IPC-Modus
`ipcMode`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Zeichenfolge
Erforderlich: Nein
Der IPC-Ressourcen-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind `host`, `task` oder `none`. Wenn `host` angegeben ist, dann teilen sich alle Container innerhalb der Aufgaben, die den IPC-Modus `host` auf derselben Container-Instance angegeben haben, die gleichen IPC-Ressourcen mit der Amazon EC2-Host-Instance. Wenn `task` angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe die gleichen IPC-Ressourcen. Wenn `none` angegeben ist, dann sind die IPC-Ressourcen innerhalb der Container einer Aufgabe privat und werden nicht mit anderen Containern einer Aufgabe oder der Container-Instance geteilt. Wenn kein Wert angegeben ist, hängt die gemeinsame Nutzung des IPC-Ressourcennamespaces von der Konfiguration der Container-Laufzeit ab.
### PID-Modus
`pidMode`
Typ: Zeichenfolge
Erforderlich: Nein
Der Prozess-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind `host` und `task`. Wenn `host` angegeben ist, dann teilen sich alle Container innerhalb der Aufgaben, die den `host`-PID-Modus auf derselben Container-Instance angegeben haben, denselben Prozess-Namespace mit der Amazon-EC2-Host-Instance. Wenn `task` angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe den gleichen Prozess-Namespace. Wenn kein Wert angegeben wird, ist der Standard ein privater Namespace.
Wenn der PID-Modus `host` verwendet wird, ist das Risiko einer unerwünschten Exposition des Prozess-Namespace erhöht.
### Proxykonfiguration
`proxyConfiguration`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Objekt
Erforderlich: Nein
Die Konfigurationsdetails für den App Mesh-Proxy.
### Tags (Markierungen)
Die Metadaten, die Sie auf die Aufgabendefinition anwenden, um die Kategorisierung und Organisation zu erleichtern. Jedes Tag (Markierung) besteht aus einem Schlüssel und einem optionalen Wert. Sie können beide definieren.
Die folgenden grundlegenden Einschränkungen gelten für Tags (Markierungen):
+ Die maximale Anzahl an Tags pro Ressource beträgt 50.
+ Jeder Tag (Markierung) muss für jede Ressource eindeutig sein. Jeder Tag (Markierung) kann nur einen Wert haben.
+ Maximale Schlüssellänge: 128 Unicode-Zeichen in UTF-8
+ Maximale Wertlänge: 256 Unicode-Zeichen in UTF-8
+ Wenn Ihr Markierungsschema für mehrere -Services und -Ressourcen verwendet wird, denken Sie daran, dass andere Services möglicherweise Einschränkungen für zulässige Zeichen haben. Allgemein zulässige Zeichen sind: Buchstaben, Zahlen und Leerzeichen, die in UTF-8 dargestellt werden können, sowie die folgenden Zeichen: \$1 - =. \$1:/@.
+ Bei Tag-Schlüsseln und -Werten wird zwischen Groß- und Kleinschreibung unterschieden.
+ Verwenden `aws:` Sie weder für Schlüssel noch für Werte eine Kombination aus Groß- oder Kleinbuchstaben, z. B. ein Präfix, da es für die Verwendung reserviert ist. `AWS:` AWS Sie können keine Tag-Schlüssel oder -Werte mit diesem Präfix bearbeiten oder löschen. Tags mit diesem Präfix werden nicht als Ihre Tags pro Ressourcenlimit angerechnet.
`key`
Typ: Zeichenfolge
Erforderlich: Nein
Ein Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Schlüssel ist eine allgemeine Bezeichnung, die wie eine Kategorie für spezifischere Tag-Werte fungiert.
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der optionale Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Wert fungiert als Deskriptor in einer Tag-Kategorie (Schlüssel).
### Elastic Inference Accelerator (veraltet)
**Anmerkung**
Amazon Elastic Inference (EI) ist für Kunden nicht mehr verfügbar.
`inferenceAccelerator`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: [InferenceAccelerator](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_InferenceAccelerator.html) Objekt
Erforderlich: Nein
Die Elastic Inference-Beschleuniger, die für die Container in der Aufgabe verwendet werden sollen.
### Platzierungsbeschränkungen
`placementConstraints`
Typ: Array von [TaskDefinitionPlacementConstraint](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskDefinitionPlacementConstraint.html)-Objekten
Erforderlich: Nein
Ein Array von Platzierungs-Einschränkungs-Objekten, die für die Aufgabe verwendet werden sollen. Sie können maximal zehn Einschränkungen pro Aufgabe festlegen (dieses Limit enthält Einschränkungen in der Aufgabendefinition und solche, die während der Laufzeit festgelegt werden).
Amazon ECS unterstützt die Platzierungsbeschränkungen `distinctInstace` und `memberOf` für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden. Die folgenden Attribute werden für Aufgaben unterstützt, die die Platzierungsbeschränkung `memberOf` verwenden:
+ `ecs.subnet-id`
+ `ecs.availability-zone`
+ `ecs.cpu-architecture`
+ `ecs.instance-type`
Weitere Informationen über Platzierungsbeschränkungen finden Sie unter [Definieren der Container-Instances, die Amazon ECS für Aufgaben verwendet](task-placement-constraints.md).
### Datenträger
Wenn Sie eine Aufgabendefinition registrieren, können Sie optional eine Liste von Volumes für Ihre Aufgaben angeben. Auf diese Weise können Sie Daten-Volumes in Ihren Aufgaben verwenden.
Weitere Informationen über Volume-Typen und anderen Parametern finden Sie unter [Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Name des Volumes. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern und Unterstriche sind zulässig. Auf diesen Namen wird im Parameter `sourceVolume` der Containerdefinition `mountPoints` verwiesen.
`host`
Typ: [HostVolumeProperties](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HostVolumeProperties.html) Objekt
Erforderlich: Nein
Dieser Parameter wird angegeben, wenn Sie Bind-Mount-Host-Volumes verwenden. Die Inhalte des `host`-Parameters bestimmen, ob Ihr Bind-Mount-Host-Volume auf der Host-Container-Instance erhalten bleibt und wo es gespeichert wird. Wenn der `host` Parameter leer ist, weist das System Ihrem Datenvolume einen Hostpfad zu. Es ist jedoch nicht garantiert, dass die Daten erhalten bleiben, wenn die ihnen zugeordneten Container nicht mehr laufen.
`sourcePath`
Typ: Zeichenfolge
Erforderlich: Nein
Wenn der `host` Parameter verwendet wird, geben Sie a an, `sourcePath` um den Pfad auf der Host-Instance zu deklarieren, der dem Container präsentiert wird. Wenn dieser Parameter leer ist, weist Ihnen das System einen Hostpfad zu. Wenn der `host` Parameter einen `sourcePath` Dateispeicherort enthält, verbleibt das Datenvolume am angegebenen Speicherort auf der Host-Instance, bis Sie es manuell löschen. Wenn der `sourcePath` Wert auf der Host-Instance nicht vorhanden ist, wird er vom System erstellt. Wenn der Speicherort nicht vorhanden ist, wird der Inhalt des Quellpfadordners exportiert.
Auf Amazon ECS Managed Instances sind Teile des Host-Dateisystems schreibgeschützt. Das `sourcePath` muss auf ein beschreibbares Verzeichnis wie oder verweisen. `/var` `/tmp` Weitere Informationen finden Sie unter [Bind-Mounts mit Amazon ECS verwenden](bind-mounts.md).
`dockerVolumeConfiguration`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Objekt
Erforderlich: Nein
Dieser Parameter wird angegeben, wenn Sie Docker-Volumes verwenden.
`efsVolumeConfiguration`
Typ: [EFSVolumeKonfigurationsobjekt](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html)
Erforderlich: Nein
Dieser Parameter wird angegeben, wenn Sie ein Amazon-EFS-Dateisystem für die Aufgabenspeicherung verwenden.
`fsxWindowsFileServerVolumeConfiguration`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Objekt
Erforderlich: Nein
Dieser Parameter wird angegeben, wenn Sie das Dateisystem Amazon FSx for Windows File Server für die Aufgabenspeicherung verwenden.
`configuredAtLaunch`
Typ: Boolesch
Erforderlich: Nein
Gibt an, ob das Volume beim Start konfiguriert werden soll. Dieser Parameter wird verwendet, um Amazon-EBS-Volumes für eigenständige Aufgaben oder Aufgaben, die als Teil eines Service erstellt wurden, zu erstellen. Für jede Revision der Aufgabendefinition darf beim Start nur ein Volume in der Volume-Konfiguration konfiguriert sein.
## Containerdefinitionen
Wenn Sie eine Aufgabendefinition registrieren, müssen Sie eine Liste der Containerdefinitionen angeben, die an den Docker-Daemon auf einer Container-Instance übergeben werden. Die folgenden Parameter sind in einer Containerdefinition zulässig.
**Topics**
+ [Name](#container_definition_name-managed-instances)
+ [Image](#container_definition_image-managed-instances)
+ [Arbeitsspeicher](#container_definition_memory-managed-instances)
+ [CPU](#container_definition_cpu-managed-instances)
+ [Port-Zuordnungen](#container_definition_portmappings-managed-instances)
+ [Private-Repository-Daten](#container_definition_repositoryCredentials-managed-instances)
+ [Essenziell](#container_definition_essential-managed-instances)
+ [Einstiegspunkt](#container_definition_entrypoint-managed-instances)
+ [Befehl](#container_definition_command-managed-instances)
+ [Arbeitsverzeichnis](#container_definition_workingdirectory-managed-instances)
+ [Erweiterte Parameter für Containerdefinitionen](#advanced_container_definition_params-managed-instances)
+ [Linux-Parameter](#container_definition_linuxparameters-managed-instances)
### Name
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Name eines Containers. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Zahlen, Bindestriche und Unterstriche sind zulässig. Wenn Sie mehrere Container in einer Aufgabedefinition verknüpfen, kann der `name` eines Containers in die `links` eines anderen Containers eingefügt werden. Das dient dazu, die Container zu verbinden.
### Image
`image`
Typ: Zeichenfolge
Erforderlich: Ja
Das Image zum Starten eines Containers. Diese Zeichenfolge wird direkt an den Docker-Daemon übergeben. Images in der Docker Hub-Registrierung sind standardmäßig verfügbar. Sie können entweder mit `repository-url/image:tag` oder mit `repository-url/image@digest` auch andere Repositorys angeben. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche, Unterstriche, Doppelpunkte, Punkte und Schrägstriche sind zulässig. Dieser Parameter ist im Docker-Befehl create-container und im `IMAGE`-Parameter des Docker-Befehls run der Option `Image` zugeordnet.
+ Wenn eine neue Aufgabe gestartet wird, ruft der Amazon-ECS-Container-Agent die neueste Version des angegebenen Image und das Tag für den Container ab, der verwendet werden soll. Allerdings werden nachfolgende Aktualisierungen eines Repository-Images nicht an Aufgaben übertragen, die bereits ausgeführt werden.
+ Wenn Sie im Image-Pfad in der Aufgabendefinition kein Tag oder Digest angeben, verwendet der Amazon ECS-Container-Agent das `latest` Tag, um das angegebene Bild abzurufen.
+ Nachfolgende Aktualisierungen eines Repository-Images werden nicht an bereits ausgeführte Aufgaben weitergegeben.
+ Images in privaten Registrierungen werden unterstützt. Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
+ Images in Amazon ECR-Repositorys können entweder mit der vollständigen `registry/repository:tag`- oder der `registry/repository@digest`-Namenskonvention angegeben werden (beispielsweise `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` oder `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`).
+ Images in offiziellen Repositorys in Docker Hub verwenden einen einzelnen Namen (z. B. `ubuntu` oder `mongo`).
+ Images in anderen Repositorys in Docker Hub sind mit einem Organisationsnamen qualifiziert (z. B `amazon/amazon-ecs-agent`).
+ Image in anderen Online-Repositorys sind durch einen Domain-Namen zusätzlich qualifiziert (z. B. `quay.io/assemblyline/ubuntu`).
`versionConsistency`
Typ: Zeichenfolge
Gültige Werte: `enabled`\$1`disabled`
Erforderlich: Nein
Gibt an, ob Amazon ECS das in der Container-Definition angegebene Container-Image-Tag in einen Image-Digest auflöst. Das Standardverhalten ist `enabled`. Wenn Sie den Wert für einen Container auf `disabled` festlegen, löst Amazon ECS das Container-Image-Tag nicht in einen Digest auf und verwendet den in der Container-Definition angegebenen ursprünglichen Image-URI für die Bereitstellung. Weitere Informationen zu r Auflösung von Container-Images finden Sie unter [Container-Image-Auflösung](deployment-type-ecs.md#deployment-container-image-stability).
### Arbeitsspeicher
`memory`
Typ: Ganzzahl
Erforderlich: Nein
Die Menge des Arbeitsspeichers (in MiB), die dem Container bereitgestellt wird. Wenn Ihr Container versucht, das hier angegebene Limit zu überschreiten, wird der Container beendet. Die gesamte Speicherkapazität, die für alle Container reserviert ist, muss niedriger sein als der Aufgabenwert `memory`, sofern angegeben. Dieser Parameter ist im Docker-Befehl create-container der Option `Memory` und die Option `--memory` ist der Docker-Ausführung zugeordnet.
Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.
Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
`memoryReservation`
Typ: Ganzzahl
Erforderlich: Nein
Die weiche Arbeitsspeichergrenze (in MiB) für die Reservierung für den Container. Wenn der Systemspeicher strittig ist, versucht Docker den Arbeitsspeicher des Containers innerhalb der weichen Grenze zu halten. Ihr Container kann jedoch bei Bedarf mehr Speicher verwenden. Der Container kann bis zu der mit dem Parameter `memory` angegebenen harten Grenze (falls zutreffend) oder bis zum gesamten verfügbaren Speicher der Container-Instance verwendet werden, je nachdem, was zuerst eintritt. Dieser Parameter ist im Docker-Befehl create-container der Option `MemoryReservation` und die Option `--memory-reservation` ist der Docker-Ausführung zugeordnet.
Wenn kein Speicherwert auf Aufgabenebene angegeben ist, müssen Sie eine Ganzzahl ungleich Null für einen oder beide Werte von `memory` oder `memoryReservation` in einer Container-Definition angeben. Wenn Sie beide angeben, muss `memory` größer als `memoryReservation` sein. Wenn Sie `memoryReservation` angeben, wird dieser Wert von den verfügbaren Speicherressourcen für die Container-Instance abgezogen, auf der der Container platziert ist. Andernfalls wird der Wert `memory` verwendet.
Nehmen wir zum Beispiel an, dass Ihr Container normalerweise 128 MiB Arbeitsspeicher verwendet, aber gelegentlich kurzzeitig auf 256 MiB Arbeitsspeicher expandiert. Sie können einen `memoryReservation` von 128 MiB und einen festen `memory`-Grenzwert von 300 MiB festlegen. Mit dieser Konfiguration kann der Container nur 128 MiB Arbeitsspeicher von den verbleibenden Ressourcen auf der Container-Instance reservieren. Gleichzeitig ermöglicht die Konfiguration auch, dass der Container bei Bedarf mehr Speicherressourcen verwenden kann.
Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.
Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
### CPU
`cpu`
Typ: Ganzzahl
Erforderlich: Nein
Die Anzahl der `cpu`-Einheiten, die für den Container reserviert sind. Dieser Parameter ist im Docker-Befehl create-container der Option `CpuShares` und die Option `--cpu-shares` ist der Docker-Ausführung zugeordnet.
Dieses Feld ist optional für Aufgaben, die EC2-Kapazitätsanbieter verwenden. Die einzige Anforderung ist, dass die gesamte reservierte CPU-Kapazität für alle Container in einer Aufgabe unter dem Wert `cpu` auf der Aufgabenebene liegt.
Sie können die Anzahl der CPU-Einheiten ermitteln, die pro EC2-Instance-Typ verfügbar sind, indem Sie das v, das für diesen Instance-Typ auf der [Amazon EC2 EC2-Instance-Detailseite CPUs ](https://aws.amazon.com/ec2/instance-types/) aufgeführt ist, mit 1.024 multiplizieren.
Linux-Container teilen sich nicht zugewiesene CPU-Einheiten mit anderen Containern auf der Container-Instance im gleichen Verhältnis wie die ihnen zugewiesene Menge. Wenn Sie beispielsweise eine Aufgabe mit einem einzelnen Container auf einem Single-Core-Instance-Typ mit 512 CPU-Einheiten für diesen Container ausführen und dies die einzige Aufgabe ist, die auf der Container-Instance ausgeführt wird, könnte dieser Container jederzeit den vollen Anteil von 1 024 CPU-Einheiten nutzen. Wenn Sie jedoch auf dieser Container-Instance eine weitere Kopie der gleichen Aufgabe starten würden, würde jede Aufgabe bei Bedarf eine garantierte Menge von mindestens 512 CPU-Einheiten erhalten. Darüber hinaus könnte jeder der Container automatisch mehr CPU-Einheiten nutzen, wenn diese vom anderen Container nicht verwendet werden. Wenn jedoch beide Aufgaben die ganze Zeit 100 % aktiv sind, stünden ihnen nur 512 CPU-Einheiten zur Verfügung.
Auf Linux-Container-Instances verwendet der Docker-Daemon auf der Container-Instance den CPU-Wert, um das relative CPU-Anteilsverhältnis für die laufenden Container zu berechnen. Weitere Informationen finden Sie unter [CPU share constraint](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) in der Docker-Dokumentation. Der kleinste gültige CPU-Freigabe wert, den der Linux-Kernel zulässt, ist 2. Der CPU-Parameter ist jedoch nicht erforderlich und Sie können CPU-Werte unter 2 in Ihren Container-Definitionen verwenden. Bei CPU-Werten unter 2 (einschließlich 0) variiert das Verhalten je nach Version Ihres Amazon ECS-Container-Agenten:
+ **Agentenversionen kleiner oder gleich 1.1.0**: Null-CPU-Werte werden an Docker als 0 übergeben, die von Docker dann in 1 024 CPU-Anteile konvertiert werden. CPU-Werte von 1 werden an Docker als 1 übergeben, die der Linux-Kernel in zwei CPU-Freigaben konvertiert.
+ **Agenten-Versionen größer oder gleich 1.2.0:** Null-CPU-Werte und CPU-Werte von 1 werden an Docker als 2 übergeben.
Auf Windows-Container-Instances wird der CPU-Grenzwert als absolutes Limit oder als Kontingent festgelegt. Windows-Container haben nur auf die angegebene CPU-Menge Zugriff, die in der Aufgabendefinition beschrieben wird. Ein CPU-Wert mit dem Wert „NULL“ oder „null“ wird als `0` an Docker übergeben, die von Windows als 1 % einer CPU interpretiert wird.
### Port-Zuordnungen
`portMappings`
Typ: Objekt-Array
Erforderlich: Nein
Port-Zuordnungen machen die Netzwerk-Ports Ihres Containers der Außenwelt zugänglich. Dadurch können Clients auf Ihre Anwendung zugreifen. Port-Zuordnungen werden auch für die Kommunikation zwischen Containern innerhalb derselben Aufgabe verwendet.
Legen Sie für Aufgabendefinitionen, die den Netzwerkmodus `awsvpc` verwenden, nur `containerPort` fest. Der `hostPort` wird immer ignoriert, und der Container-Port wird automatisch einem zufälligen Port mit hoher Nummer auf dem Host zugeordnet.
Die meisten Felder dieses Parameters (inklusive `containerPort`, `hostPort`, `protocol`) werden im Docker-Befehl create-container der Option `PortBindings` zugeordnet, und die Option `--publish` wird dem Docker-Befehl run zugeordnet. Wenn der Netzwerkmodus einer Aufgabendefinition auf `host` festgelegt ist, müssen die Host-Ports entweder undefiniert sein oder mit dem Container-Port in der Port-Zuweisung übereinstimmen.
Nachdem eine Aufgabe den Status `RUNNING` erreicht hat, sind manuelle und automatische Host- und Container-Port-Zuordnungen an den folgenden Orten sichtbar:
+ Konsole: Abschnitt **Network Bindings** (Netzwerk-Bindungen) einer Container-Beschreibung für eine bestimmte Aufgabe.
+ AWS CLI: Der Abschnitt `networkBindings` der Befehlsausgabe **describe-tasks**.
+ API: `DescribeTasks`-Antwort.
+ Metadaten: Der Endpunkt der Aufgabenmetadaten.
`appProtocol`
Typ: Zeichenfolge
Erforderlich: Nein
Das Anwendungsprotokoll, das für die Portzuordnung verwendet wird. Dieser Parameter gilt nur für Service Connect. Wir empfehlen Ihnen, diesen Parameter so festzulegen, dass er mit dem von Ihrer Anwendung verwendeten Protokoll konsistent ist. Wenn Sie diesen Parameter festlegen, fügt Amazon ECS dem Service-Connect-Proxy eine protokollspezifische Verbindungsbehandlung hinzu. Wenn Sie diesen Parameter festlegen, fügt Amazon ECS protokollspezifische Telemetrie in der Amazon ECS-Konsole und hinzu. CloudWatch
Wenn Sie keinen Wert für diesen Parameter festlegen, wird TCP verwendet. Amazon ECS fügt jedoch keine protokollspezifische Telemetrie für TCP hinzu.
Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md).
Gültige Protokollwerte: `"HTTP" | "HTTP2" | "GRPC" `
`containerPort`
Typ: Ganzzahl
Erforderlich: Ja, wenn `portMappings` verwendet werden
Die Port-Nummer auf dem Container, der an den vom Benutzer angegebenen oder automatisch zugewiesenen Host-Port gebunden ist.
Bei Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, geben Sie die verfügbaren Ports mit `containerPort` an.
`containerPortRange`
Typ: Zeichenfolge
Erforderlich: Nein
Der Portnummernbereich des Containers, der an den dynamisch zugeordneten Host-Portbereich gebunden ist.
Sie können diesen Parameter nur mithilfe der `register-task-definition`-API festlegen. Die Option ist im `portMappings`-Parameter verfügbar. Weitere Informationen finden Sie unter [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) in der *AWS Command Line Interface -Referenz*.
Die folgenden Regeln gelten, wenn Sie ein `containerPortRange` angeben :
+ Sie müssen den `awsvpc`-Netzwerkmodus verwenden.
+ Die Container-Instance muss mindestens über Version 1.67.0 des Container-Agenten und mindestens über Version 1.67.0-1 des `ecs-init`-Pakets verfügen.
+ Sie können bis zu 100 Portbereiche für jeden Container angeben.
+ Sie geben keine `hostPortRange` an. Der Wert von `hostPortRange` ist wie folgt festgelegt:
+ Für Container in einer Aufgabe mit dem `awsvpc`-Netzwerkmodus wird `hostPort` auf denselben Wert wie `containerPort` festgelegt. Dies ist eine statische Zuordnungsstrategie.
+ Gültige Werte für `containerPortRange` liegen zwischen 1 and 65 535.
+ Ein Port kann nur in einer Portzuordnung für jeden Container enthalten sein.
+ Sie können keine überlappenden Portbereiche angeben.
+ Die erste Port im Bereich muss kleiner als der letzte Port im Bereich sein.
+ Docker empfiehlt, den Docker-Proxy in der Konfigurationsdatei des Docker-Daemons zu deaktivieren, wenn Sie eine große Anzahl von Ports haben.
[Weitere Informationen finden Sie in Ausgabe \$111185 unter.](https://github.com/moby/moby/issues/11185) GitHub
Informationen zum Deaktivieren des Docker-Proxy in der Docker-Daemon-Konfigurationsdatei finden Sie unter [Docker-Daemon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) im *Amazon-ECS-Entwicklerhandbuch*.
Sie können [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) aufrufen, um die `hostPortRange` anzuzeigen, bei denen es sich um die Host-Ports handelt, die an die Container-Ports gebunden sind.
Die Portbereiche sind nicht in den Amazon ECS-Aufgabenereignissen enthalten, die an gesendet werden EventBridge. Weitere Informationen finden Sie unter [Automatisieren Sie Antworten auf Amazon ECS-Fehler mit EventBridge](cloudwatch_event_stream.md).
`hostPortRange`
Typ: Zeichenfolge
Erforderlich: Nein
Der Portnummernbereich auf dem Host, der mit der Netzwerkbindung verwendet wird. Dieser wird von Docker zugewiesen und vom Amazon-ECS-Agenten bereitgestellt.
`hostPort`
Typ: Ganzzahl
Erforderlich: Nein
Die Port-Nummer auf der Container-Instance, die für Ihren Container reserviert werden soll.
Der `hostPort` kann leer bleiben oder den gleichen Wert wie der `containerPort` haben.
Der standardmäßige flüchtige Port-Bereich für Docker-Version 1.6.0 und später wird in der Instance unter `/proc/sys/net/ipv4/ip_local_port_range` aufgelistet. Wenn dieser Kernel-Parameter nicht verfügbar ist, wird der standardmäßige flüchtige Port-Bereich von `49153–65535` verwendet. Versuchen Sie nicht, einen Host-Port im flüchtigen Portbereich anzugeben. Das liegt daran, dass diese für die automatische Zuweisung reserviert sind. Im Allgemeinen zählen Ports unter `32768` nicht zum flüchtigen Port-Bereich.
Die standardmäßigen reservierten Ports sind `22` für SSH, die Docker-Ports, `2375` und `2376` und der Amazon-ECS-Container-Agenten-Port `51678-51680`. Jeder Host-Port, der zuvor vom Benutzer für eine laufende Aufgabe festgelegt wurde, ist auch während der Ausführung der Aufgabe reserviert. Nach dem Beenden einer Aufgabe wird der Host-Port freigegeben. Die aktuell reservierten Ports werden in der `remainingResources` der **describe-container-instances**-Ausgabe angezeigt. Eine Container-Instance kann bis zu 100 reservierte Ports gleichzeitig haben, einschließlich der standardmäßig reservierten Ports. Automatisch zugewiesene Ports werden nicht auf das Kontingent von 100 reservierten Ports angerechnet.
`name`
Typ: Zeichenfolge
Erforderlich: Nein, erforderlich für die Konfiguration von Service Connect und VPC Lattice in einem Service
Der Name, der für die Portzuordnung verwendet wird. Dieser Parameter gilt nur für Service Connect und VPC Lattice. Dieser Parameter ist der Name, den Sie in der Service-Connect- und VPC-Lattice-Konfiguration eines Services verwenden.
Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md).
Im folgenden Beispiel werden beide erforderlichen Felder für Service Connect und VPC Lattice verwendet.
```
"portMappings": [
{
"name": string,
"containerPort": integer
}
]
```
`protocol`
Typ: Zeichenfolge
Erforderlich: Nein
Das für die Port-Zuweisung verwendete Protokoll. Gültige Werte sind `tcp` und `udp`. Der Standardwert ist `tcp`.
Nur `tcp` wird für Service Connect unterstützt. Denken Sie daran, dass `tcp` impliziert ist, wenn dieses Feld nicht festgelegt ist.
Verwenden Sie die folgende Syntax, um einen Host-Port anzugeben.
```
"portMappings": [
{
"containerPort": integer,
"hostPort": integer
}
...
]
```
Verwenden Sie die folgende Syntax, um einen Host-Port automatisch zuzuweisen.
```
"portMappings": [
{
"containerPort": integer
}
...
]
```
### Private-Repository-Daten
`repositoryCredentials`
Typ: [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Objekt
Erforderlich: Nein
Die Repository-Anmeldeinformationen für die Authentifizierung bei privaten Registrierungen.
Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
`credentialsParameter`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `repositoryCredentials` verwendet werden
Der Amazon-Ressourcenname (ARN) des Secrets mit den Anmeldeinformationen für das private Repository.
Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
Wenn Sie die Amazon ECS-API verwenden AWS CLI, oder AWS SDKs, falls der geheime Schlüssel in derselben Region wie die Aufgabe existiert, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Geheimnisses verwenden. Wenn Sie den verwenden AWS-Managementkonsole, müssen Sie den vollständigen ARN des Geheimnisses angeben.
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition, welche die erforderlichen Parameter zeigt:
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
### Essenziell
`essential`
Typ: Boolesch
Erforderlich: Nein
Wenn der Parameter `essential` eines Containers als `true` gekennzeichnet ist und dieser Container ausfällt oder aus irgendeinem Grund beendet wird, werden auch alle anderen Container in der Aufgabe beendet. Wenn der `essential`-Parameter eines Containers als `false` gekennzeichnet ist, wirkt sich ein Ausfall dieses Containers nicht auf die anderen Container in der Aufgabe aus. Wenn dieser Parameter ausgelassen wird, wird davon ausgegangen, dass ein Container „essential“ (entscheidend) ist.
Alle Aufgaben müssen über mindestens einen entscheidenden Container verfügen. Wenn eine Anwendung aus mehreren Containern besteht, gruppieren Sie die Container, die für einen gemeinsamen Zweck verwendet werden, in Komponenten und trennen Sie die verschiedenen Komponenten in mehrere Aufgabendefinitionen. Weitere Informationen finden Sie unter [Entwerfen Ihrer Anwendung für Amazon ECS](application_architecture.md).
### Einstiegspunkt
`entryPoint`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Eintrittspunkt, der an den Container übergeben wird. Dieser Parameter ist im Docker-Befehl create-container der Option `Entrypoint` und die Option `--entrypoint` ist der Docker-Ausführung zugeordnet.
```
"entryPoint": ["string", ...]
```
### Befehl
`command`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Befehl, der an den Container übergeben wird. Dieser Parameter ist im Docker-Befehl create-container der Option `Cmd` und der `COMMAND`-Parameter ist der Docker-Ausführung zugeordnet. Wenn mehrere Argumente vorhanden sind, ist jedes Argument eine getrennte Zeichenfolge im Array.
```
"command": ["string", ...]
```
### Arbeitsverzeichnis
`workingDirectory`
Typ: Zeichenfolge
Erforderlich: Nein
Das Arbeitsverzeichnis, in dem Befehle im Container ausgeführt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `WorkingDir` und die Option `--workdir` ist der Docker-Ausführung zugeordnet.
### Erweiterte Parameter für Containerdefinitionen
Die folgenden erweiterten Parameter für Container-Definitionen bieten erweiterte Funktionen für den Docker-Befehl run, der verwendet wird, um Container auf Ihren Amazon-ECS-Container-Instances zu starten.
**Topics**
+ [Neustartrichtlinie](#container_definition_restart_policy-managed-instances)
+ [Gesundheitscheck](#container_definition_healthcheck-managed-instances)
+ [Umgebung](#container_definition_environment-managed-instances)
+ [Sicherheit](#container_definition_security-managed-instances)
+ [Netzwerkeinstellungen](#container_definition_network-managed-instances)
+ [Speicher und Protokollierung](#container_definition_storage-managed-instances)
+ [Ressourcenanforderungen](#container_definition_resourcerequirements-managed-instances)
+ [Container-Timeouts](#container_definition_timeout-managed-instances)
+ [Container-Abhängigkeit](#container_definition_dependency-managed-instances)
+ [Systemkontrollen](#container_definition_systemcontrols-managed-instances)
+ [Interactive](#container_definition_interactive-managed-instances)
+ [Pseudo-Terminal](#container_definition_pseudoterminal-managed-instances)
#### Neustartrichtlinie
`restartPolicy`
Die Container-Neustart-Richtlinie und die zugehörigen Konfigurationsparameter. Wenn Sie eine Neustart-Richtlinie für einen Container aktivieren, kann Amazon ECS den Container neu starten, ohne dass die Aufgabe ersetzt werden muss. Weitere Informationen finden Sie unter [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md).
`enabled`
Typ: Boolescher Wert
Erforderlich: Ja
Gibt an, ob eine Neustart-Richtlinie für den Container aktiviert ist.
`ignoredExitCodes`
Typ: Ganzzahl-Array
Erforderlich: Nein
Eine Liste von Exit-Codes, die Amazon ECS ignoriert und nicht versucht, neu zu starten. Sie können bis zu 50 Container-Exit-Codes angeben. Standardmäßig ignoriert Amazon ECS keine Exit-Codes.
`restartAttemptPeriod`
Typ: Ganzzahl
Erforderlich: Nein
Ein Zeitraum (in Sekunden), den der Container ausgeführt werden muss, bevor ein Neustart versucht werden kann. Ein Container kann nur einmal alle `restartAttemptPeriod` Sekunden neu gestartet werden. Wenn ein Container für diesen Zeitraum nicht ausgeführt werden kann und vorzeitig beendet wird, wird er nicht neu gestartet. Sie können eine Minimum-`restartAttemptPeriod` von 60 Sekunden und eine Maximum-`restartAttemptPeriod` von 1 800 Sekunden angeben. Standardmäßig muss ein Container 300 Sekunden lang ausgeführt werden, bevor er neu gestartet werden kann.
#### Gesundheitscheck
`healthCheck`
Der Befehl für die Container-Zustandsprüfung und die zugehörigen Konfigurationsparameter für den Container. Weitere Informationen finden Sie unter [Ermitteln des Zustands von Amazon-ECS-Aufgaben mithilfe von Container-Zustandsprüfungen](healthcheck.md).
`command`
Ein Zeichenfolgen-Array, das den Befehl darstellt, den der Container ausführt, um festzustellen, ob er fehlerfrei ist. Das Zeichenfolge-Array kann mit `CMD` beginnen, um die Befehlsargumente direkt auszuführen, oder mit `CMD-SHELL`, um den Befehl mit der Standard-Shell des Containers auszuführen. Ist nichts davon angegeben, wird `CMD` verwendet.
Verwenden Sie beim Registrieren einer Aufgabendefinition in eine durch Kommas getrennte Liste von Befehlen. AWS-Managementkonsole Diese Befehle werden in eine Zeichenfolge konvertiert, nachdem die Aufgabendefinition erstellt wurde. Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.
```
CMD-SHELL, curl -f http://localhost/ || exit 1
```
Wenn Sie eine Aufgabendefinition mithilfe des AWS-Managementkonsole JSON-Bedienfelds registrieren APIs, schließen Sie die Befehlsliste mit dem oder dem in Klammern ein. AWS CLI Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.
```
[ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ]
```
Ein Beendigungscode von 0 ohne `stderr`-Ausgabe zeigt einen Erfolg an, und der Beendigungscode ungleich Null zeigt einen Fehler an.
`interval`
Der Zeitraum (in Sekunden) zwischen den Zustandsprüfungen. Sie können zwischen 5 und 300 Sekunden angeben. Der Standardwert ist 30 Sekunden.
`timeout`
Der Zeitraum (in Sekunden), der angibt, wie lange gewartet wird, bis eine Zustandsprüfung erfolgreich ist, bevor sie als fehlerhaft betrachtet wird. Sie können zwischen 2 und 60 Sekunden angeben. Der Standardwert ist 5 Sekunden.
`retries`
Die Anzahl, wie oft eine fehlgeschlagene Zustandsprüfung wiederholt wird, bevor der Container als fehlerhaft betrachtet wird. Sie können zwischen 1 und 10 Wiederholungen angeben. Der Standardwert ist drei Wiederholungsversuche.
`startPeriod`
Der optionale Übergangszeitraum, der angibt, wie lange der Container Zeit für einen Bootstrap hat, bevor fehlgeschlagene Zustandsprüfungen der maximalen Anzahl an Wiederholungen angerechnet werden. Sie können einen Wert zwischen 0 und 300 Sekunden angeben. Standardmäßig ist `startPeriod` deaktiviert.
Wenn eine Zustandsprüfung innerhalb der `startPeriod` erfolgreich ist, wird die Container als fehlerfrei betrachtet und alle nachfolgenden Ausfälle werden bei der maximal zulässigen Anzahl von Wiederholungen berücksichtigt.
#### Umgebung
`cpu`
Typ: Ganzzahl
Erforderlich: Nein
Die Anzahl der physischen `cpu`-Einheiten, die der Amazon-ECS-Container-Agent für den Container reserviert. Unter Linux ist dieser Parameter im Abschnitt [Container erstellen](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) der Option `CpuShares` zugeordnet.
Dieses Feld ist optional für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden. Die Gesamtmenge an CPU, die für alle Container innerhalb einer Aufgabe reserviert ist, muss niedriger sein als der `cpu`-Wert auf Aufgabenebene.
Linux-Container teilen sich nicht zugewiesene CPU-Einheiten mit anderen Containern auf der Container-Instance im gleichen Verhältnis wie die ihnen zugewiesene Menge. Nehmen Sie zum Beispiel an, dass Sie eine Aufgabe für einen einzelnen Container auf einer Instance mit einem Kern und 512 CPU-Einheiten für diesen Container ausführen. Außerdem ist diese Aufgabe die einzige Aufgabe, die auf der Container-Instance läuft. In diesem Beispiel kann der Container jederzeit die gesamte Menge von 1 024 CPU-Einheiten nutzen. Angenommen, Sie haben jedoch auf dieser Container-Instance eine weitere Kopie der gleichen Aufgabe gestartet. Jede Aufgabe würde bei Bedarf eine garantierte Menge von mindestens 512 CPU-Einheiten erhalten. Ebenso kann jeder Container zu einer höheren CPU-Auslastung übergehen, wenn der andere Container die verbleibende CPU nicht nutzt. Wenn jedoch beide Aufgaben die ganze Zeit 100 % aktiv sind, stünden ihnen jeweils nur 512 CPU-Einheiten zur Verfügung.
Auf Linux-Container-Instances verwendet der Docker-Daemon auf der Container-Instance den CPU-Wert, um das relative CPU-Anteilsverhältnis für die laufenden Container zu berechnen. Der kleinste gültige CPU-Freigabewert, den der Linux-Kernel zulässt, ist 2 und der maximale gültige CPU-Freigabewert, den der Linux-Kernel zulässt, ist 262 144. Der CPU-Parameter ist jedoch nicht erforderlich und Sie können CPU-Werte unter 2 und höher als 262 144 in Ihren Container-Definitionen verwenden. Bei CPU-Werten unter 2 (einschließlich 0) und höher als 262 144 variiert das Verhalten je nach Version Ihres Amazon-ECS-Container-Agenten:
Weitere Beispiele finden Sie unter [So verwaltet Amazon ECS CPU- und Arbeitsspeicher-Ressourcen](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/).
`gpu`
Typ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Objekt
Erforderlich: Nein
Die Anzahl der physischen `GPUs`, die der Amazon-ECS-Container-Agent für den Container reserviert. Die Anzahl der für alle Container in einer Aufgabe GPUs reservierten Container darf die Anzahl der GPUs auf der Container-Instance verfügbaren Container nicht überschreiten, auf der die Aufgabe gestartet wird. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md).
`Elastic Inference accelerator`
Dieser Parameter wird nicht für Container unterstützt, die in Amazon ECS Managed Instances gehostet werden.
Typ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Objekt
Erforderlich: Nein
Für den `InferenceAccelerator`-Typ stimmt der `value` mit dem `deviceName` für einen `InferenceAccelerator` überein, der in einer Aufgabendefinition angegeben ist. Weitere Informationen finden Sie unter [Name des Elastic Inference Accelerators (veraltet)](task_definition_parameters.md#elastic-Inference-accelerator).
`essential`
Typ: Boolesch
Erforderlich: Nein
Nehmen wir an, der `essential`-Parameter eines Containers ist als `true` gekennzeichnet und dieser Container schlägt fehl oder wird aus irgendeinem Grund beendet. Dann werden alle anderen Container beendet, die Teil der Aufgabe sind. Wenn der Parameter `essential` eines Containers als `false` gekennzeichnet ist, wirkt sich ein Ausfall dieses Containers nicht auf die anderen Container in der Aufgabe aus. Wenn dieser Parameter ausgelassen wird, wird davon ausgegangen, dass ein Container „essential“ (entscheidend) ist.
Alle Aufgaben müssen über mindestens einen entscheidenden Container verfügen. Angenommen, Sie haben eine Anwendung, die aus mehreren Containern besteht. Dann gruppieren Sie Container, die für einen gemeinsamen Zweck verwendet werden, in Komponenten und teilen die verschiedenen Komponenten in mehrere Aufgabendefinitionen auf. Weitere Informationen finden Sie unter [Entwerfen Ihrer Anwendung für Amazon ECS](application_architecture.md).
```
"essential": true|false
```
`entryPoint`
Von frühen Versionen des Amazon-ECS-Container-Agenten werden die `entryPoint`-Parameter nicht korrekt verarbeitet. Wenn Sie Probleme bei der Verwendung von `entryPoint` haben, aktualisieren Sie Ihren Container-Agenten oder geben Sie Ihre Befehle und Argumente stattdessen als `command`-Array-Objekte an.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Eintrittspunkt, der an den Container übergeben wird.
```
"entryPoint": ["string", ...]
```
`command`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Befehl, der an den Container übergeben wird. Dieser Parameter ist im Befehl create-container der Option `Cmd` und der `COMMAND`-Parameter ist der Docker-Ausführung zugeordnet. Wenn mehrere Argumente vorhanden sind, stellen Sie sicher, dass jedes Argument eine getrennte Zeichenfolge im Array ist.
```
"command": ["string", ...]
```
`workingDirectory`
Typ: Zeichenfolge
Erforderlich: Nein
Das Arbeitsverzeichnis, in dem Befehle im Container ausgeführt werden sollen. Dieser Parameter ordnet zu `WorkingDir` im Bereich [Erstellen eines Containers](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) der [Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) und der Option `--workdir` für die [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) zu.
```
"workingDirectory": "string"
```
`environmentFiles`
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste von Dateien, die die Umgebungsvariablen enthalten, die an einen Container übergeben werden sollen. Dieser Parameter ist im Docker-Befehl run der Option `--env-file` zugeordnet.
Sie können bis zu 10 Umgebungsdateien angeben. Die Datei muss eine `.env` Dateierweiterung haben. Jede Zeile in einer Umgebungsdatei enthält eine Umgebungsvariable im Format `VARIABLE=VALUE`. Zeilen, die mit `#` beginnen, werden als Kommentare behandelt und ignoriert.
Wenn in der Containerdefinition einzelne Umgebungsvariablen angegeben sind, haben sie Vorrang vor den Variablen, die in einer Umgebungsdatei enthalten sind. Wenn mehrere Umgebungsdateien angegeben werden, die dieselbe Variable enthalten, werden sie von oben nach unten verarbeitet. Es wird empfohlen, eindeutige Variablennamen zu verwenden. Weitere Informationen finden Sie unter [Eine einzelne Umgebungsvariable an einen Amazon-ECS-Container übergeben](taskdef-envfiles.md).
`value`
Typ: Zeichenfolge
Erforderlich: Ja
Der Amazon-Ressourcenname (ARN) des Amazon S3-Objekts, das die Umgebungsvariablendatei enthält.
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Dateityp, der verwendet werden muss. Der einzige unterstützte Wert ist `s3`.
`environment`
Typ: Objekt-Array
Erforderlich: Nein
Die Umgebungsvariablen, die an einen Container übergeben werden. Dieser Parameter ist im Docker-Befehl create-container der Option `Env` und die Option `--env` ist der Docker-Ausführung zugeordnet.
Die Verwendung von Klartext-Umgebungsvariablen für sensitive Informationen (wie etwa Zugangsdaten) wird nicht empfohlen.
`name`
Typ: Zeichenfolge
Erforderlich: ja, wenn `environment` verwendet wird
Der Name der Umgebungsvariable.
`value`
Typ: Zeichenfolge
Erforderlich: ja, wenn `environment` verwendet wird
Der Wert der Umgebungsvariable.
```
"environment" : [
{ "name" : "string", "value" : "string" },
{ "name" : "string", "value" : "string" }
]
```
`secrets`
Typ: Objekt-Array
Erforderlich: Nein
Ein Objekt, durch das das Secret dargestellt wird, das dem Container zur Verfügung gestellt werden soll. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.
`valueFrom`
Typ: Zeichenfolge
Erforderlich: Ja
Das Geheimnis, das dem Container exponiert werden muss. Die unterstützten Werte sind entweder der vollständige Amazon Resource Name (ARN) des AWS Secrets Manager Secrets oder der vollständige ARN des Parameters im AWS Systems Manager Parameter Store.
Wenn der Systems Manager Parameter Store-Parameter oder der Secrets Manager Manager-Parameter in derselben AWS-Region Datei wie die Aufgabe, die Sie starten, vorhanden ist, können Sie entweder den vollständigen ARN oder den Namen des Secrets verwenden. Wenn der Parameter in einer anderen Region existiert, muss der volle ARN angegeben werden.
```
"secrets": [
{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}
]
```
#### Sicherheit
`privileged`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` ist, erhält der Container erhöhte Berechtigungen auf der Host-Container-Instance (ähnlich wie der `root`-Benutzer). Dieser Parameter ist im Docker-Befehl create-container der Option `Privileged` und die Option `--privileged` ist der Docker-Ausführung zugeordnet.
`user`
Typ: Zeichenfolge
Erforderlich: Nein
Der Benutzer, der im Container verwendet werden soll. Dieser Parameter ist im Docker-Befehl create-container der Option `User` und die Option `--user` ist der Docker-Ausführung zugeordnet.
Wenn Sie Aufgaben im `host`-Netzwerkmodus ausführen, sollten Sie Container nicht über den Root-Benutzer (UID 0) ausführen. Wir empfehlen für verbesserte Sicherheit einen Benutzer zu verwenden, der nicht Root-Benutzer ist.
Sie können den `user` mit den folgenden Formaten angeben. Wenn Sie eine User Identifier (UID, Benutzerbezeichner) und Group Identifier (GID, Gruppenbezeichner) angeben, müssen Sie sie als positive Ganzzahl angeben.
+ `user`
+ `user:group`
+ `uid`
+ `uid:gid`
+ `user:gid`
+ `uid:group`
`readonlyRootFilesystem`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` ist, erhält der Container ein schreibgeschütztes Root-Dateisystem. Dieser Parameter ist im Docker-Befehl create-container der Option `ReadonlyRootfs` und die Option `--read-only` ist der Docker-Ausführung zugeordnet.
`dockerSecurityOptions`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Eine Liste von Zeichenketten zur Bereitstellung benutzerdefinierter Bezeichnungen für Sicherheitssysteme SELinux und AppArmor mehrstufige Sicherheitssysteme. Dieses Feld ist für Container in Aufgaben, die Fargate verwenden, nicht gültig.
`ulimits`
Typ: Array von [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html)-Objekten
Erforderlich: Nein
Eine Liste der `ulimits`, die im Container festgelegt werden sollen. Wenn in einer Aufgabendefinition ein ulimit-Wert angegeben ist, überschreibt er die von Docker festgelegten Standardwerte. Dieser Parameter ist im Docker-Befehl create-container der Option `Ulimits` und die Option `--ulimit` ist der Docker-Ausführung zugeordnet. Gültige Werte für die Benennung werden im [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html)-Datentyp angezeigt.
Amazon-ECS-Aufgaben, die in Fargate gehosted werden, verwenden die Standardwerte für Ressourcenlimits, die vom Betriebssystem gesetzt wurden. Ausgenommen ist der Ressourcenlimit-Parameter `nofile`, den Fargate überschreibt. Das Ressourcenlimit `nofile` beschränkt die Anzahl der geöffneten Dateien, die ein Container verwenden kann. Standardmäßig ist das weiche `nofile`-Limit `1024` und das harte Limit `65535`.
Dieser Parameter erfordert Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance. Um die Docker Remote API-Version auf Ihrer Container-Instance zu überprüfen, melden Sie sich an Ihrer Container-Instance an und führen Sie den folgenden Befehl aus: `sudo docker version --format '{{.Server.APIVersion}}'`
`dockerLabels`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Eine key/value Karte mit Labels, die dem Container hinzugefügt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `Labels` und die Option `--label` ist der Docker-Ausführung zugeordnet.
Dieser Parameter erfordert Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance.
```
"dockerLabels": {"string": "string"
...}
```
#### Netzwerkeinstellungen
`disableNetworking`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter den Wert „true“ aufweist, ist die Netzwerkfunktion innerhalb des Containers deaktiviert.
Der Standardwert ist `false`.
```
"disableNetworking": true|false
```
`links`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Über den Parameter `link` können Container miteinander kommunizieren, ohne dass Port-Zuweisungen nötig sind. Dieser Parameter wird nur unterstützt, wenn der Netzwerkmodus einer Aufgabendefinition auf `bridge` gesetzt ist. Das Konstrukt `name:internalName` ist analog zu `name:alias` in Docker-Verbindungen. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche und Unterstriche sind zulässig.
Container, die sich auf derselben Container-Instance befinden, können miteinander kommunizieren, ohne dass Verbindungen oder Host-Port-Zuweisungen erforderlich sind. Die Netzwerkisolierung auf einer Container-Instance wird durch Sicherheitsgruppen und VPC-Einstellungen gesteuert.
```
"links": ["name:internalName", ...]
```
`hostname`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Zeichenfolge
Erforderlich: Nein
Der Hostname, der für Ihren Container verwendet werden soll. Dieser Parameter ist im Docker-Befehl create-container der Option `Hostname` und die Option `--hostname` ist der Docker-Ausführung zugeordnet.
```
"hostname": "string"
```
`dnsServers`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Eine List der DNS-Server, die dem Container bereitgestellt werden.
```
"dnsServers": ["string", ...]
```
`extraHosts`
Dieser Parameter wird für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, nicht unterstützt.
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste der Hostnamen und IP-Adresszuordnungen, die an die Datei `/etc/hosts` auf dem Container angefügt werden.
Dieser Parameter ist im Docker-Befehl create-container der Option `ExtraHosts` und die Option `--add-host` ist der Docker-Ausführung zugeordnet.
```
"extraHosts": [
{
"hostname": "string",
"ipAddress": "string"
}
...
]
```
`hostname`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `extraHosts` verwendet werden
Der Hostname, der im Eintrag `/etc/hosts` verwendet werden soll.
`ipAddress`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `extraHosts` verwendet werden
Die IP-Adresse, die im Eintrag `/etc/hosts` verwendet werden soll.
#### Speicher und Protokollierung
`readonlyRootFilesystem`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter den Wert „true“ aufweist, erhält der Container Lesezugriff auf das Root-Dateisystem. Dieser Parameter ist im Docker-Befehl create-container der Option `ReadonlyRootfs` und die Option `--read-only` ist der Docker-Ausführung zugeordnet.
Der Standardwert ist `false`.
```
"readonlyRootFilesystem": true|false
```
`mountPoints`
Typ: Objekt-Array
Erforderlich: Nein
Die Mounting-Punkte für die Daten-Volumes in Ihrem Container. Dieser Parameter ist in der create-container-Docker-API der Option `Volumes` zugeordnet und die Option `--volume` ist der Docker-Ausführung zugeordnet.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden. Windows-Container können keine Verzeichnisse auf einem anderen Laufwerk mounten, und es ist kein laufwerksübergreifender Mounting-Punkt möglich. Sie müssen Mounting-Punkte angeben, um ein Amazon-EBS-Volume direkt an eine Amazon-ECS-Aufgabe anzuhängen.
`sourceVolume`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Name des einzubindenden Volumes.
`containerPath`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Pfad in dem Container, in dem das Volume eingebunden wird.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
Behalten Sie für Aufgaben, die auf EC2-Instances unter dem Windows-Betriebssystem ausgeführt werden, den Standardwert von `false` bei.
`volumesFrom`
Typ: Objekt-Array
Erforderlich: Nein
Die Daten-Volumes, die von einem anderen Container gemountet werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `VolumesFrom` und die Option `--volumes-from` ist der Docker-Ausführung zugeordnet.
`sourceContainer`
Typ: Zeichenfolge
Erforderlich: ja, wenn `volumesFrom` verwendet wird
Der Name des Containers, von dem die Volumes gemountet werden.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
```
"volumesFrom": [
{
"sourceContainer": "string",
"readOnly": true|false
}
]
```
`logConfiguration`
Typ: Objekt [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)
Erforderlich: Nein
Die Angabe der Protokollkonfiguration für den Container.
Beispiele für Aufgabendefinitionen, die eine Protokollkonfiguration verwenden, finden Sie unter [Beispiele für Amazon-ECS-Aufgabendefinitionen](example_task_definitions.md).
Dieser Parameter ist im Docker-Befehl create-container der Option `LogConfig` und die Option `--log-driver` ist der Docker-Ausführung zugeordnet. Standardmäßig verwenden Container den gleichen Protokolltreiber wie der Docker-Daemon. Allerdings kann der Container einen anderen Protokolltreiber als der Docker-Daemon verwenden, indem Sie einen Protokolltreiber mit diesem Parameter in der Container-Definition angeben. Um für einen Container einen anderen Protokolltreiber zu verwenden, muss das Protokollsystem auf der Container-Instance (oder einem anderen Protokollserver für die Remote-Protokollierung) ordnungsgemäß konfiguriert sein.
Beachten Sie die folgenden Punkte, wenn eine Protokollkonfiguration für Ihre Container angegeben ist:
+ Amazon ECS unterstützt einen Teil der Protokolltreiber, die für den Docker-Daemon verfügbar sind.
+ Für diesen Parameter muss Ihre Docker Remote API Version 1.18 oder höher in Ihrer Container-Instance verwenden.
```
"logConfiguration": {
"logDriver": "awslogs",""splunk", "awsfirelens",
"options": {"string": "string"
...},
"secretOptions": [{
"name": "string",
"valueFrom": "string"
}]
}
```
`logDriver`
Typ: Zeichenfolge
Zulässige Werte: `"awslogs","splunk","awsfirelens"`
Erforderlich: ja, wenn `logConfiguration` verwendet wird
Der für den Container zu verwendende Protokolltreiber. Standardmäßig sind die zuvor aufgeführten gültigen Werte Protokolltreiber, mit denen der Amazon-ECS-Container-Agent kommunizieren kann.
Die unterstützten Protokolltreiber sind `awslogs`, `splunk` und `awsfirelens`.
Weitere Informationen zur Verwendung des `awslogs` Protokolltreibers in Aufgabendefinitionen zum Senden Ihrer Container-Logs an CloudWatch Logs finden Sie unter[Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md).
Weitere Informationen finden zur Verwendung des `awsfirelens`-Protokolltreibers finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md).
Wenn Sie einen benutzerdefinierten Treiber haben, der nicht aufgeführt ist, können Sie das Amazon ECS-Container-Agent-Projekt, das [verfügbar](https://github.com/aws/amazon-ecs-agent) ist, forken GitHub und es so anpassen, dass es mit diesem Treiber funktioniert. Wir möchten Sie bitten, uns eventuelle Änderungswünsche mitzuteilen. Allerdings unterstützen wir derzeit nicht die Ausführung modifizierter Kopien dieser Software.
Für diesen Parameter ist Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance erforderlich.
`options`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Die key/value Zuordnung der Konfigurationsoptionen, die an den Protokolltreiber gesendet werden sollen.
Die Optionen, die Sie angeben können, hängen vom Protokolltreiber ab. Zu den Optionen, die Sie angeben können, wenn Sie den `awslogs` Router zum Weiterleiten von Protokollen an Amazon verwenden, CloudWatch gehören die folgenden:
`awslogs-create-group`
Erforderlich: Nein
Geben Sie an, ob die Protokollgruppe automatisch erstellt werden soll. Wenn diese Option nicht angegeben ist, gilt standardmäßig `false`.
Ihre IAM-Richtlinie muss die `logs:CreateLogGroup`-Berechtigung umfassen, bevor Sie `awslogs-create-group` zu nutzen versuchen.
`awslogs-region`
Erforderlich: Ja
Geben Sie an AWS-Region , an `awslogs` wen der Protokolltreiber Ihre Docker-Protokolle senden soll. In Logs können Sie wählen, ob Sie alle Ihre Logs von Clustern in verschiedenen Regionen an eine einzige Region senden möchten. CloudWatch Dann sind alle an einem Standort sichtbar. Andernfalls können Sie sie nach Region aufteilen, um eine höhere Granularität zu erzielen. Vergewissern Sie sich, dass die angegebene Protokollgruppe in der Region vorhanden ist, die Sie mit dieser Option festlegen.
`awslogs-group`
Erforderlich: Ja
Sie müssen eine Protokollgruppe angeben, an die der `awslogs`-Protokolltreiber seine Protokoll-Streams sendet.
`awslogs-stream-prefix`
Erforderlich: Ja
Mit der `awslogs-stream-prefix`-Option können Sie einen Protokoll-Stream mit dem angegebenen Präfix, dem Containernamen und der ID der Amazon-ECS-Aufgabe verknüpfen, zu der der Container gehört. Wenn Sie einen Präfix mit dieser Option angeben, weist der Protokoll-Stream das folgende Format auf:
```
prefix-name/container-name/ecs-task-id
```
Wenn Sie keinen Präfix mit dieser Option angeben, wird der Protokoll-Stream nach der Container-ID benannt, die vom Docker-Daemon auf der Container-Instance zugewiesen wurde. Da es schwierig ist, Protokolle nur mit der Docker-Container-ID (die nur auf der Container-Instance verfügbar ist) zum Container zurückzuverfolgen, der sie gesendet hat, empfehlen wir, dass Sie einen Präfix mit dieser Option festlegen.
Für Amazon-ECS-Services können Sie den Servicenamen als Präfix verwenden. So können Sie Protokollstreams zu dem Service zurückverfolgen, zu dem der Container gehört, den Namen des Containers ermitteln, der sie gesendet hat, und die ID der Aufgabe, zu der der Container gehört.
Sie müssen ein Stream-Präfix für Ihre Protokolle angeben, damit Ihre Protokolle im Protokollfeld der Amazon-ECS-Konsole angezeigt werden.
`awslogs-datetime-format`
Erforderlich: Nein
Diese Option definiert einen mehrzeiliges Startmuster im `strftime`-Format von Python. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen. Die zugeordnete Zeile ist das Trennzeichen zwischen Protokollnachrichten.
Ein Beispiel für einen Anwendungsfall für die Nutzung dieses Formats ist die Ausgabenanalyse, z. B. einen Stack-Dump, der andernfalls möglicherweise mehrere Einträge protokolliert. Mit dem richtigen Muster kann es in nur einem Eintrag erfasst werden.
Weitere Informationen finden Sie unter [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format).
Sie können nicht sowohl die Optionen `awslogs-datetime-format` und `awslogs-multiline-pattern` konfigurieren.
Bei der mehrzeiligen Protokollierung wird eine regelmäßige Ausdrucksanalyse und die Übereinstimmung aller Protokollmeldungen ausgeführt. Dies kann negative Auswirkungen auf die Leistung der Protokollierung haben.
`awslogs-multiline-pattern`
Erforderlich: Nein
Diese Option definiert ein mehrzeiliges Startmuster mit einem regulären Ausdruck. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen. Die zugeordnete Zeile ist das Trennzeichen zwischen Protokollnachrichten.
Weitere Informationen finden Sie unter [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern).
Diese Option wird ignoriert, wenn `awslogs-datetime-format` ebenfalls konfiguriert ist.
Sie können nicht sowohl die Optionen `awslogs-datetime-format` und `awslogs-multiline-pattern` konfigurieren.
Bei der mehrzeiligen Protokollierung wird eine regelmäßige Ausdrucksanalyse und die Übereinstimmung aller Protokollmeldungen ausgeführt. Dies kann negative Auswirkungen auf die Leistung der Protokollierung haben.
`mode`
Erforderlich: Nein
Zulässige Werte: `non-blocking` \$1 `blocking`
Diese Option definiert den Zustellungsmodus von Protokollnachrichten von dem Container an den `awslogs`-Protokolltreiber. Der von Ihnen gewählte Zustellungsmodus wirkt sich auf die Anwendungsverfügbarkeit aus, wenn der Protokollfluss vom Container unterbrochen wird.
Wenn Sie diesen `blocking` Modus verwenden und der Fluss der Logs zu unterbrochen CloudWatch wird, werden Aufrufe vom Container-Code zum Schreiben in die `stdout` und `stderr` -Streams blockiert. Der Logging-Thread der Anwendung wird daraufhin blockiert. Dies kann dazu führen, dass die Anwendung nicht mehr reagiert und die Container-Zustandsprüfung fehlschlägt.
Wenn Sie den `non-blocking`-Modus verwenden, werden die Protokolle des Containers stattdessen in einem mit der Option `max-buffer-size` konfigurierten Zwischenpuffer im Arbeitsspeicher gespeichert. Dadurch wird verhindert, dass die Anwendung nicht mehr reagiert, wenn keine Protokolle gesendet CloudWatch werden können. Wir empfehlen, diesen Modus zu verwenden, wenn Sie die Verfügbarkeit des Services sicherstellen möchten und einen gewissen Protokollverlust in Kauf nehmen möchten. Weitere Informationen finden Sie unter [Verhinderung von Protokollverlusten im blockierungsfreien Modus im `awslogs`-Container-Protokolltreiber](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/).
`max-buffer-size`
Erforderlich: Nein
Standardwert: `1m`
Wenn der `non-blocking`-Modus verwendet wird, steuert die `max-buffer-size`-Protokolloption die Größe des Puffers, der für die Zwischenspeicherung von Nachrichten verwendet wird. Stellen Sie sicher, dass Sie eine für Ihre Anwendung angemessene Puffergröße angeben. Wenn der Puffer voll ist, können keine weiteren Protokolle gespeichert werden. Protokolle, die nicht gespeichert werden können, gehen verloren.
Um Protokolle mithilfe des `splunk`-Protokollrouters weiterzuleiten, müssen Sie ein `splunk-token` und eine `splunk-url` angeben.
Wenn Sie den `awsfirelens` Protokollrouter verwenden, um Protokolle zur Protokollspeicherung und Analyse an ein AWS-Service AWS Partner Network OD-Ziel weiterzuleiten, können Sie die `log-driver-buffer-limit` Option so einstellen, dass die Anzahl der Ereignisse begrenzt wird, die im Speicher zwischengespeichert werden, bevor sie an den Log-Router-Container gesendet werden. Es kann helfen, ein potenzielles Problem mit dem Verlust von Protokollen zu beheben, da ein hoher Durchsatz dazu führen könnte, dass der Speicher für Puffer innerhalb von Docker ausgeht. Weitere Informationen finden Sie unter [Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).
Andere Optionen, die Sie beim Weiterleiten von Protokollen mithilfe von `awsfirelens` angeben können, hängen vom Ziel ab. Wenn Sie Protokolle nach Amazon Data Firehose exportieren, können Sie das AWS-Region mit `region` und einen Namen für den Protokollstream mit `delivery_stream` angeben.
Wenn Sie Protokolle nach Amazon Kinesis Data Streams exportieren, können Sie eine AWS-Region mit `region` und einen Datenstrom-Namen mit `stream` angeben.
Wenn Sie Protokolle nach Amazon OpenSearch Service exportieren, können Sie Optionen wie `Name` `Host` (OpenSearch Service-Endpunkt ohne Protokoll),`Port`,`Index`,`Type`,`Aws_auth`, `Aws_region``Suppress_Type_Name`, und angeben`tls`.
Wenn Sie Protokolle nach Amazon S3 exportieren, können Sie den Bucket mit der `bucket`-Option angeben. Sie können auch `region`, `total_file_size`, `upload_timeout` und `use_put_object` als Optionen angeben.
Für diesen Parameter muss Ihre Docker Remote API Version 1.19 oder höher in Ihrer Container-Instance verwenden.
`secretOptions`
Typ: Objekt-Array
Erforderlich: Nein
Ein Objekt, welches das Secret darstellt, der an die Protokollkonfiguration übergeben werden soll. Zu den Secrets, die in der Protokollkonfiguration verwendet werden, können ein Authentifizierungs-Token, ein Zertifikat oder ein Verschlüsselungsschlüssel gehören. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.
`valueFrom`
Typ: Zeichenfolge
Erforderlich: Ja
Das Geheimnis zur Bereitstellung der Protokollkonfiguration des Containers.
```
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"splunk-token": "...",
"tag": "...",
...
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "/ecs/logconfig/splunkcred"
}]
}
```
`firelensConfiguration`
Typ: [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html)Objekt
Erforderlich: Nein
Die FireLens Konfiguration für den Container. Dies wird verwendet, um einen Protokollrouter für Container-Protokolle anzugeben und zu konfigurieren. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md).
```
{
"firelensConfiguration": {
"type": "fluentd",
"options": {
"KeyName": ""
}
}
}
```
`options`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Die key/value Übersicht der Optionen, die bei der Konfiguration des Log-Routers verwendet werden sollen. Dieses Feld ist optional und kann verwendet werden, um eine benutzerdefinierte Konfigurationsdatei anzugeben oder dem Protokollereignis zusätzliche Metadaten hinzuzufügen, z. B. Aufgaben-, Aufgabendefinitions-, Cluster- und Container-Instance-Details. Wenn angegeben, ist die zu verwendende Syntax `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Weitere Informationen finden Sie unter [Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten](firelens-taskdef.md).
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Der zu verwendende Protokollrouter. Die gültigen Werte sind `fluentd` und `fluentbit`.
#### Ressourcenanforderungen
`resourceRequirements`
Typ: Array von [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html)-Objekten
Erforderlich: Nein
Die Art und Menge einer Ressource, die einem Container zugewiesen werden soll. Die einzige unterstützte Ressource ist eine GPU.
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Die Art einer Ressource, die einem Container zugewiesen werden soll. Der unterstützte Wert ist `GPU`.
`value`
Typ: Zeichenfolge
Erforderlich: Ja
Der Wert für den angegebenen Ressourcentyp.
Wenn der `GPU`-Typ verwendet wird, ist der Wert die Anzahl der physischen `GPUs`, die der Amazon-ECS-Container-Agent für den Container reserviert. Die Anzahl der Container GPUs , die für alle Container in einer Aufgabe reserviert sind, darf die Anzahl der verfügbaren Container auf der Container-Instance, GPUs auf der die Aufgabe gestartet wird, nicht überschreiten.
GPUs sind nicht für Aufgaben verfügbar, die auf Fargate ausgeführt werden.
#### Container-Timeouts
`startTimeout`
Typ: Ganzzahl
Erforderlich: Nein
Beispielwerte: `120`
Zeitdauer (in Sekunden), die gewartet wird, bevor die Auflösung von Abhängigkeiten für einen Container aufgegeben wird.
Angenommen, Sie geben zwei Container in einer Aufgabendefinition an und `containerA` ist abhängig davon, dass `containerB` den Status `COMPLETE`, `SUCCESS` oder `HEALTHY` erreicht. Wenn ein `startTimeout`-Wert für `containerB` angegeben ist und es den gewünschten Status nicht innerhalb dieses Zeitraums erreicht, wird `containerA` nicht gestartet.
Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.
Der Höchstwert beträgt 600 Sekunden (10 Minuten).
`stopTimeout`
Typ: Ganzzahl
Erforderlich: Nein
Beispielwerte: `120`
Dauer (in Sekunden), die gewartet werden soll, bevor der Container zwangsweise beendet wird, wenn er nicht normal beendet wird.
Wenn der Parameter nicht angegeben wird, wird der Standardwert 30 Sekunden verwendet. Der Höchstwert beträgt 86 400 Sekunden (24 Stunden).
#### Container-Abhängigkeit
`dependsOn`
Typ: Array von [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html)-Objekten
Erforderlich: Nein
Die für das Startup und Herunterfahren des Containers definierten Abhängigkeiten. Ein Container kann mehrere Abhängigkeiten enthalten. Wenn eine Abhängigkeit für das Startup und das Herunterfahren des Containers definiert ist, ist sie reserviert. Ein Beispiel finden Sie unter [Container-Abhängigkeit](example_task_definitions.md#example_task_definition-containerdependency).
Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.
Dieser Parameter erfordert, dass die Aufgabe oder der Service die Plattformversion `1.3.0` oder höher verwendet (Linux) oder `1.0.0` (Windows).
```
"dependsOn": [
{
"containerName": "string",
"condition": "string"
}
]
```
`containerName`
Typ: Zeichenfolge
Erforderlich: Ja
Der Container-Name, der die angegebene Bedingung erfüllen muss.
`condition`
Typ: Zeichenfolge
Erforderlich: Ja
Die Abhängigkeitsbedingung des Containers. Der folgenden Tabelle sind die verfügbaren Bedingungen und deren Verhalten zu entnehmen:
+ `START` – Diese Bedingung emuliert das heutige Verhalten von Links und Volumes. Die Bedingung überprüft, ob ein abhängiger Container gestartet wurde, bevor das Starten anderer Container zugelassen wird.
+ `COMPLETE` – Diese Bedingung überprüft, ob ein abhängiger Container vollständig ausgeführt (beendet) wurde, bevor das Starten anderer Container zugelassen wird. Dies kann für nicht benötigte Container hilfreich sein, die ein Skript ausführen und dann beendet werden. Diese Bedingung kann nicht für einen essentiellen Container festgelegt werden.
+ `SUCCESS` – Diese Bedingung ist mit `COMPLETE` identisch, erfordert aber auch, dass der Container mit dem Status `zero` beendet wird. Diese Bedingung kann nicht für einen essenziellen Container festgelegt werden.
+ `HEALTHY` – Diese Bedingung überprüft, ob der abhängige Container seine Zustandsprüfung bestanden hat, bevor das Starten anderer Container zugelassen wird. Dies setzt voraus, das für den abhängigen Container Zustandsprüfungen in der Aufgabendefinition konfiguriert wurden. Diese Bedingung wird nur beim Startup der Aufgabe bestätigt.
#### Systemkontrollen
`systemControls`
Typ: [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Objekt
Erforderlich: Nein
Eine Liste der Namespace-Kernel-Parameter, die im Container festgelegt werden Dieser Parameter ist im Docker-Befehl create-container der Option `Sysctls` und die Option `--sysctl` ist der Docker-Ausführung zugeordnet. Beispielsweise können Sie die `net.ipv4.tcp_keepalive_time`-Einstellung konfigurieren, um Verbindungen mit einer längeren Lebensdauer aufrechtzuerhalten.
Wir empfehlen nicht, netzwerkbezogene `systemControls`-Parameter für mehrere Container in einer einzelnen Aufgabe festzulegen, die auch entweder den `awsvpc`- oder `host`-Netzwerkmodus verwendet. Dies hat die folgenden Nachteile:
+ Wenn Sie `systemControls` für einen beliebigen Container festlegen, werden diese auf alle Container in der Aufgabe angewendet. Wenn Sie unterschiedliche `systemControls` für mehrere Container innerhalb einer einzelnen Aufgabe festlegen, werden die `systemControls` des zuletzt gestarteten Containers für alle Container übernommen.
Wenn Sie einen IPC-Ressourcen-Namespace für die Container in der Aufgabe einrichten, gelten folgende Bedingungen für Ihre Systemsteuerungen. Weitere Informationen finden Sie unter [IPC-Modus](task_definition_parameters.md#task_definition_ipcmode).
+ Für Aufgaben, die den IPC-Modus `host` verwenden, wird der IPC-Namespace `systemControls` nicht unterstützt.
+ Für Aufgaben, die den IPC-Modus `task` verwenden, gelten die Werte des IPC-Namespace `systemControls` für alle Container innerhalb einer Aufgabe.
```
"systemControls": [
{
"namespace":"string",
"value":"string"
}
]
```
`namespace`
Typ: Zeichenfolge
Erforderlich: Nein
Der Namespace-Kernel-Parameter, für den ein `value` festgelegt wird.
Gültige IPC-Namespace-Werte: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` und `Sysctls`, die mit `"fs.mqueue.*"` beginnen
Gültige Netzwerk-Namespace-Werte: `Sysctls` beginnend mit `"net.*"` In Fargate werden nur `Sysctls` mit Namespace akzeptiert, die innerhalb des Containers existieren.
Alle diese Werte werden von Fargate unterstützt.
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der Wert für den Namespace-Kernel-Parameter, der in `namespace` angegeben ist.
#### Interactive
`interactive`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` ist, können Sie Container-Anwendungen bereitstellen, für die `stdin` oder `tty` zugeordnet werden muss. Dieser Parameter ist im Docker-Befehl create-container der Option `OpenStdin` und die Option `--interactive` ist der Docker-Ausführung zugeordnet.
Der Standardwert ist `false`.
#### Pseudo-Terminal
`pseudoTerminal`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` lautet, wird ein TTY zugeordnet. Dieser Parameter ist im Docker-Befehl create-container der Option `Tty` und die Option `--tty` ist der Docker-Ausführung zugeordnet.
Der Standardwert ist `false`.
### Linux-Parameter
`linuxParameters`
Typ: [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Objekt
Erforderlich: Nein
Linux-spezifische Änderungen, die auf den Container angewendet werden, wie z. B. Linux-Kernel-Funktionen.
`capabilities`
Typ: [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Objekt
Erforderlich: Nein
Die Linux-Funktionen für den Container, die zur von Docker bereitgestellten Standardkonfiguration hinzugefügt oder daraus entfernt werden.
`devices`
Typ: Array von [Device](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html)-Objekten
Erforderlich: Nein
Alle Host-Geräte, die dem Container zur Verfügung gestellt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `Devices` und die Option `--device` ist der Docker-Ausführung zugeordnet.
`initProcessEnabled`
Typ: Boolesch
Erforderlich: Nein
Führen Sie einen `init`-Prozess innerhalb des Containers aus, der Signalen weiterleitet und Prozesse aufnimmt. Dieser Parameter ist der Option `--init` für die Docker-Ausführung zugeordnet.
`maxSwap`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Ganzzahl
Erforderlich: Nein
Die Gesamtmenge des Auslagerungsspeichers (in MiB), den ein Container verwenden kann. Dieser Parameter ist in die Option `--memory-swap` zur Docker-Ausführung übersetzt, wobei der Wert die Summe aus dem Container-Speicher und dem Wert `maxSwap` ist.
`swappiness`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Ganzzahl
Erforderlich: Nein
Auf diese Weise können Sie das Speicherauslagerungsverhalten eines Containers optimieren. Ein `swappiness`-Wert von `0` führt dazu, dass ein Auslagern nicht erfolgt, wenn dies nicht unbedingt erforderlich ist. Ein `swappiness`-Wert von `100` führt dazu, dass Seiten sehr aggressiv ausgelagert werden. Gültige Werte sind Ganzzahlen zwischen `0` und `100`. Wenn der Parameter `swappiness` nicht angegeben wird, wird der Standardwert `60` verwendet. Wenn kein Wert für `maxSwap` angegeben ist, wird dieser Parameter ignoriert. Dieser Parameter ist der Option `--memory-swappiness` für die Docker-Ausführung zugeordnet.
`sharedMemorySize`
Dieser Parameter wird für Aufgaben, die in Amazon ECS Managed Instances ausgeführt werden, nicht unterstützt.
Typ: Ganzzahl
Erforderlich: Nein
Die Größe des `/dev/shm`-Volumes (in MB). Dieser Parameter ist der Option `--shm-size` für die Docker-Ausführung zugeordnet.
`tmpfs`
Typ: Array von [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html)-Objekten
Erforderlich: Nein
Der Container-Pfad, Mount-Optionen und Größe (in MiB) des tmpfs-Mounts. Dieser Parameter ist der Option `--tmpfs` für die Docker-Ausführung zugeordnet.
# Amazon-ECS-Aufgabendefinitionsparameter für Fargate
Aufgabendefinitionen sind in verschiedene Teile unterteilt: die Aufgabenfamilie, die AWS Identity and Access Management (IAM-) Aufgabenrolle, den Netzwerkmodus, Containerdefinitionen, Volumes und Starttypen. Die Familien- und Container-Definitionen sind in einer Aufgabendefinition obligatorisch. Im Gegensatz dazu sind Aufgabenrolle, Netzwerkmodus, Volumes und Starttyp optional.
Sie können diese Parameter in einer JSON-Datei verwenden, um Ihre Aufgabendefinition zu konfigurieren.
Im Folgenden finden Sie weitere detaillierte Beschreibungen der einzelnen Aufgabendefinitionsparameter für Fargate.
## Familie
`family`
Typ: Zeichenfolge
Erforderlich: Ja
Wenn Sie eine Aufgabendefinition registrieren, vergeben Sie eine Familie, ähnlich einem Namen für mehrere Versionen der Aufgabendefinition, die mit einer Revisionsnummer angegeben ist. Die erste Aufgabendefinition, die in einer bestimmten Familie registriert wird, erhält die Revision 1 und alle danach registrierten Definitionen erhalten eine sequenzielle Revisionsnummer.
## Capacity (Kapazität)
Wenn Sie eine Aufgabendefinition registrieren, können Sie die Kapazität angeben, anhand der Amazon ECS die Aufgabendefinition validieren soll. Eine Client-Ausnahme wird zurückgegeben, wenn die Aufgabendefinition nicht anhand der angegebenen Kompatibilitäten validiert.
Der folgende Parameter ist in einer Aufgabendefinition zulässig.
`requiresCompatibilities`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Zulässige Werte: `FARGATE`
Die Kapazität, anhand der die Aufgabendefinition validiert wird. Dabei wird überprüft, ob alle in der Aufgabendefinition verwendeten Parameter den Anforderungen von Fargate entsprechen.
## -Rolle für Aufgabe
`taskRoleArn`
Typ: Zeichenfolge
Erforderlich: Nein
Wenn Sie eine Aufgabendefinition registrieren, können Sie eine Aufgabenrolle für eine IAM-Rolle angeben, die es den Containern in der Aufgabe ermöglicht AWS APIs , die in den zugehörigen Richtlinien angegebenen Aufgaben in Ihrem Namen aufzurufen. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).
## -Rolle für die Aufgabenausführung
`executionRoleArn`
Typ: Zeichenfolge
Required: Conditional
Der Amazon-Ressourcenname (ARN) der Aufgabenausführungsrolle, die dem Amazon ECS-Container-Agenten die Erlaubnis erteilt, AWS API-Aufrufe in Ihrem Namen durchzuführen.
Die IAM-Rolle für die Aufgabenausführung ist je nach den Anforderungen Ihrer Aufgabe erforderlich. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
## Netzwerkmodus
`networkMode`
Typ: Zeichenfolge
Erforderlich: Ja
Der Docker-Netzwerkmodus, der für die Container in der Aufgabe verwendet werden soll. Für Amazon ECS-Aufgaben, die auf Fargate gehostet werden, ist der `awsvpc` Netzwerkmodus erforderlich.
## Laufzeit-Plattform
`operatingSystemFamily`
Typ: Zeichenfolge
Required: Conditional
Standard: LINUX
Dieser Parameter ist für Amazon-ECS-Aufgaben erforderlich, die auf Fargate gehostet werden.
Wenn Sie eine Aufgabendefinition anmelden, geben Sie die Betriebssystemfamilie an.
Die gültigen Werte sind `LINUX`, `WINDOWS_SERVER_2025_FULL`, `WINDOWS_SERVER_2025_CORE`, `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_2019_FULL` und `WINDOWS_SERVER_2019_CORE`.
Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.
Wenn eine Aufgabendefinition Teil eines Services ist, muss dieser Wert mit dem `platformFamily`-Wert des Services übereinstimmen.
`cpuArchitecture`
Typ: Zeichenfolge
Required: Conditional
Standard: X86\$164
Wenn der Parameter unverändert `null` bleibt, wird der Standardwert bei der Initiierung einer auf Fargate gehosteten Aufgabe automatisch zugewiesen.
Wenn Sie eine Aufgabendefinition anmelden, geben Sie die CPU-Architektur an. Die gültigen Werte sind `X86_64` und `ARM64`.
Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.
Wenn Sie Linux-Aufgaben haben, können Sie den Wert auf `ARM64` festlegen. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads](ecs-arm64.md).
## Aufgabengröße
Wenn Sie eine Aufgabendefinition registrieren, können Sie den gesamten CPU- und Arbeitsspeicher für die Aufgabe angeben. Dies erfolgt separat von den Werten `cpu` und `memory` bei der Containerdefinition. Für Aufgaben, die auf Fargate (Linux und Windows) gehostet werden, sind diese Felder erforderlich und es gibt für spezifische Werte für `cpu` und `memory`, die unterstützt werden.
Der folgende Parameter ist in einer Aufgabendefinition zulässig:
`cpu`
Typ: Zeichenfolge
Erforderlich: Ja
CPU- und Speicherparameter auf Aufgabenebene sind erforderlich und werden verwendet, um den Typ und die Größe der Instance zu bestimmen, auf der Aufgaben ausgeführt werden. Bei Windows-Aufgaben werden diese Werte zur Laufzeit nicht erzwungen, da Windows nicht über einen systemeigenen Mechanismus verfügt, mit dem auf einfache Weise kollektive Ressourcenbeschränkungen für eine Gruppe von Containern durchgesetzt werden können. Wenn Sie Ressourcenbeschränkungen durchsetzen möchten, empfehlen wir, die Ressourcen auf Container-Ebene für Windows-Container zu verwenden.
Das harte Limit der CPU-Einheiten, die für die Aufgabe vorhanden sind. 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. Wenn die Aufgabendefinition registriert ist, wird ein vCPU-Wert in eine Ganzzahl umgewandelt, die die CPU-Einheiten angibt.
Dies ist ein Plichtfeld und Sie müssen einen der folgenden Werte verwenden, die den Bereich der unterstützten Werte für den `memory`-Parameter bestimmen: Die folgende Tabelle zeigt die gültigen Kombinationen von CPU- und Speicherauslastung auf Aufgabenebene.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/task_definition_parameters.html)
`memory`
Typ: Zeichenfolge
Erforderlich: Ja
CPU- und Speicherparameter auf Aufgabenebene sind erforderlich und werden verwendet, um den Typ und die Größe der Instance zu bestimmen, auf der Aufgaben ausgeführt werden. Bei Windows-Aufgaben werden diese Werte zur Laufzeit nicht erzwungen, da Windows nicht über einen systemeigenen Mechanismus verfügt, mit dem auf einfache Weise kollektive Ressourcenbeschränkungen für eine Gruppe von Containern durchgesetzt werden können. Wenn Sie Ressourcenbeschränkungen durchsetzen möchten, empfehlen wir, die Ressourcen auf Container-Ebene für Windows-Container zu verwenden.
Die harte Arbeitsspeichergrenze, die für die Aufgabe zur Verfügung steht. Sie können Speicherwerte in der Aufgabendefinition als Zeichenfolge in Mebibyte (MiB) oder Gigabyte (GB) angeben. Sie können beispielsweise einen Speicherwert entweder als `3072` in MiB oder `3 GB` in GB angeben. Wenn die Aufgabendefinition registriert ist, wird ein GB-Wert in eine Ganzzahl umgewandelt, die die MiB angibt.
Dies ist ein Plichtfeld und Sie müssen einen der folgenden Werte verwenden, die den Bereich der unterstützten Werte für den `cpu`-Parameter bestimmen:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/task_definition_parameters.html)
## Containerdefinitionen
Wenn Sie eine Aufgabendefinition registrieren, müssen Sie eine Liste der Containerdefinitionen angeben, die an den Docker-Daemon auf einer Container-Instance übergeben werden. Die folgenden Parameter sind in einer Containerdefinition zulässig.
**Topics**
+ [Standardparameter für Containerdefinition](#standard_container_definition_params)
+ [Erweiterte Parameter für Containerdefinitionen](#advanced_container_definition_params)
+ [Andere Parameter für die Containerdefinition](#other_container_definition_params)
### Standardparameter für Containerdefinition
Die folgenden Aufgabendefinitionsparameter sind in Containerdefinitionen entweder erforderlich oder werden meistens verwendet.
**Topics**
+ [Name](#container_definition_name)
+ [Image](#container_definition_image)
+ [Arbeitsspeicher](#container_definition_memory)
+ [Port-Zuordnungen](#container_definition_portmappings)
+ [Private-Repository-Daten](#container_definition_repositoryCredentials)
#### Name
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Name eines Containers. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Zahlen, Bindestriche und Unterstriche sind zulässig. Wenn Sie mehrere Container in einer Aufgabedefinition verknüpfen, kann der `name` eines Containers in die `links` eines anderen Containers eingefügt werden. Das dient dazu, die Container zu verbinden.
#### Image
`image`
Typ: Zeichenfolge
Erforderlich: Ja
Das Image zum Starten eines Containers. Diese Zeichenfolge wird direkt an den Docker-Daemon übergeben. Images in der Docker Hub-Registrierung sind standardmäßig verfügbar. Sie können entweder mit `repository-url/image:tag` oder mit `repository-url/image@digest` auch andere Repositorys angeben. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche, Unterstriche, Doppelpunkte, Punkte und Schrägstriche sind zulässig. Dieser Parameter ist im Docker-Befehl create-container und im `IMAGE`-Parameter des Docker-Befehls run der Option `Image` zugeordnet.
+ Wenn eine neue Aufgabe gestartet wird, ruft der Amazon-ECS-Container-Agent die neueste Version des angegebenen Image und das Tag für den Container ab, der verwendet werden soll. Allerdings werden nachfolgende Aktualisierungen eines Repository-Images nicht an Aufgaben übertragen, die bereits ausgeführt werden.
+ Wenn Sie im Image-Pfad in der Aufgabendefinition kein Tag oder Digest angeben, verwendet der Amazon ECS-Container-Agent das `latest` Tag, um das angegebene Bild abzurufen.
+ Nachfolgende Aktualisierungen eines Repository-Images werden nicht an bereits ausgeführte Aufgaben weitergegeben.
+ Images in privaten Registrierungen werden unterstützt. Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
+ Images in Amazon ECR-Repositorys können entweder mit der vollständigen `registry/repository:tag`- oder der `registry/repository@digest`-Namenskonvention angegeben werden (beispielsweise `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` oder `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`).
+ Images in offiziellen Repositorys in Docker Hub verwenden einen einzelnen Namen (z. B. `ubuntu` oder `mongo`).
+ Images in anderen Repositorys in Docker Hub sind mit einem Organisationsnamen qualifiziert (z. B `amazon/amazon-ecs-agent`).
+ Image in anderen Online-Repositorys sind durch einen Domain-Namen zusätzlich qualifiziert (z. B. `quay.io/assemblyline/ubuntu`).
`versionConsistency`
Typ: Zeichenfolge
Gültige Werte: `enabled`\$1`disabled`
Erforderlich: Nein
Gibt an, ob Amazon ECS das in der Container-Definition angegebene Container-Image-Tag in einen Image-Digest auflöst. Das Standardverhalten ist `enabled`. Wenn Sie den Wert für einen Container auf `disabled` festlegen, löst Amazon ECS das Container-Image-Tag nicht in einen Digest auf und verwendet den in der Container-Definition angegebenen ursprünglichen Image-URI für die Bereitstellung. Weitere Informationen zu r Auflösung von Container-Images finden Sie unter [Container-Image-Auflösung](deployment-type-ecs.md#deployment-container-image-stability).
#### Arbeitsspeicher
`memory`
Typ: Ganzzahl
Erforderlich: Nein
Die Menge des Arbeitsspeichers (in MiB), die dem Container bereitgestellt wird. Wenn Ihr Container versucht, das hier angegebene Limit zu überschreiten, wird der Container beendet. Die gesamte Speicherkapazität, die für alle Container reserviert ist, muss niedriger sein als der Aufgabenwert `memory`, sofern angegeben. Dieser Parameter ist im Docker-Befehl create-container der Option `Memory` und die Option `--memory` ist der Docker-Ausführung zugeordnet.
Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.
Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
`memoryReservation`
Typ: Ganzzahl
Erforderlich: Nein
Die weiche Arbeitsspeichergrenze (in MiB) für die Reservierung für den Container. Wenn der Systemspeicher strittig ist, versucht Docker den Arbeitsspeicher des Containers innerhalb der weichen Grenze zu halten. Ihr Container kann jedoch bei Bedarf mehr Speicher verwenden. Der Container kann bis zu der mit dem Parameter `memory` angegebenen harten Grenze (falls zutreffend) oder bis zum gesamten verfügbaren Speicher der Container-Instance verwendet werden, je nachdem, was zuerst eintritt. Dieser Parameter ist im Docker-Befehl create-container der Option `MemoryReservation` und die Option `--memory-reservation` ist der Docker-Ausführung zugeordnet.
Wenn kein Speicherwert auf Aufgabenebene angegeben ist, müssen Sie eine Ganzzahl ungleich Null für einen oder beide Werte von `memory` oder `memoryReservation` in einer Container-Definition angeben. Wenn Sie beide angeben, muss `memory` größer als `memoryReservation` sein. Wenn Sie `memoryReservation` angeben, wird dieser Wert von den verfügbaren Speicherressourcen für die Container-Instance abgezogen, auf der der Container platziert ist. Andernfalls wird der Wert `memory` verwendet.
Nehmen wir zum Beispiel an, dass Ihr Container normalerweise 128 MiB Arbeitsspeicher verwendet, aber gelegentlich kurzzeitig auf 256 MiB Arbeitsspeicher expandiert. Sie können einen `memoryReservation` von 128 MiB und einen festen `memory`-Grenzwert von 300 MiB festlegen. Mit dieser Konfiguration kann der Container nur 128 MiB Arbeitsspeicher von den verbleibenden Ressourcen auf der Container-Instance reservieren. Gleichzeitig ermöglicht die Konfiguration auch, dass der Container bei Bedarf mehr Speicherressourcen verwenden kann.
Dieser Parameter wird für Windows-Container nicht unterstützt.
Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.
Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
#### Port-Zuordnungen
`portMappings`
Typ: Objekt-Array
Erforderlich: Nein
Port-Zuordnungen machen die Netzwerk-Ports Ihres Containers der Außenwelt zugänglich. Dadurch können Clients auf Ihre Anwendung zugreifen. Port-Zuordnungen werden auch für die Kommunikation zwischen Containern innerhalb derselben Aufgabe verwendet.
Legen Sie für Aufgabendefinitionen, die den Netzwerkmodus `awsvpc` verwenden, nur `containerPort` fest. Der `hostPort` wird immer ignoriert, und der Container-Port wird automatisch einem zufälligen Port mit hoher Nummer auf dem Host zugeordnet.
Die Port-Zuweisungen unter Windows verwenden die Gateway-Adresse `NetNAT` und nicht `localhost`. Für Port-Zuweisungen unter Windows gibt es kein Loopback, daher können Sie auch nicht vom Host selbst auf den zugewiesenen Port eines Containers zugreifen.
Die meisten Felder dieses Parameters (inklusive `containerPort`, `hostPort`, `protocol`) werden im Docker-Befehl create-container der Option `PortBindings` zugeordnet, und die Option `--publish` wird dem Docker-Befehl run zugeordnet. Wenn der Netzwerkmodus einer Aufgabendefinition auf `host` festgelegt ist, müssen die Host-Ports entweder undefiniert sein oder mit dem Container-Port in der Port-Zuweisung übereinstimmen.
Nachdem eine Aufgabe den Status `RUNNING` erreicht hat, sind manuelle und automatische Host- und Container-Port-Zuordnungen an den folgenden Orten sichtbar:
+ Konsole: Abschnitt **Network Bindings** (Netzwerk-Bindungen) einer Container-Beschreibung für eine bestimmte Aufgabe.
+ AWS CLI: Der Abschnitt `networkBindings` der Befehlsausgabe **describe-tasks**.
+ API: `DescribeTasks`-Antwort.
+ Metadaten: Der Endpunkt der Aufgabenmetadaten.
`appProtocol`
Typ: Zeichenfolge
Erforderlich: Nein
Das Anwendungsprotokoll, das für die Portzuordnung verwendet wird. Dieser Parameter gilt nur für Service Connect. Wir empfehlen Ihnen, diesen Parameter so festzulegen, dass er mit dem von Ihrer Anwendung verwendeten Protokoll konsistent ist. Wenn Sie diesen Parameter festlegen, fügt Amazon ECS dem Service-Connect-Proxy eine protokollspezifische Verbindungsbehandlung hinzu. Wenn Sie diesen Parameter festlegen, fügt Amazon ECS protokollspezifische Telemetrie in der Amazon ECS-Konsole und hinzu. CloudWatch
Wenn Sie keinen Wert für diesen Parameter festlegen, wird TCP verwendet. Amazon ECS fügt jedoch keine protokollspezifische Telemetrie für TCP hinzu.
Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md).
Gültige Protokollwerte: `"http" | "http2" | "grpc" `
`containerPort`
Typ: Ganzzahl
Erforderlich: Ja, wenn `portMappings` verwendet werden
Die Port-Nummer auf dem Container, der an den vom Benutzer angegebenen oder automatisch zugewiesenen Host-Port gebunden ist.
Bei Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, geben Sie die verfügbaren Ports mit `containerPort` an.
Für Windows-Container auf Fargate können Sie Port 3150 nicht als `containerPort` verwenden. Das liegt daran, dass er reserviert ist.
`containerPortRange`
Typ: Zeichenfolge
Erforderlich: Nein
Der Portnummernbereich des Containers, der an den dynamisch zugeordneten Host-Portbereich gebunden ist.
Sie können diesen Parameter nur mithilfe der `register-task-definition`-API festlegen. Die Option ist im `portMappings`-Parameter verfügbar. Weitere Informationen finden Sie unter [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) in der *AWS Command Line Interface -Referenz*.
Die folgenden Regeln gelten, wenn Sie ein `containerPortRange` angeben :
+ Sie müssen den `awsvpc`-Netzwerkmodus verwenden.
+ Dieser Parameter ist sowohl für Windows- als auch für Linux-Betriebssysteme verfügbar.
+ Die Container-Instance muss mindestens über Version 1.67.0 des Container-Agenten und mindestens über Version 1.67.0-1 des `ecs-init`-Pakets verfügen.
+ Sie können bis zu 100 Portbereiche für jeden Container angeben.
+ Sie geben keine `hostPortRange` an. Der Wert von `hostPortRange` ist wie folgt festgelegt:
+ Für Container in einer Aufgabe mit dem `awsvpc`-Netzwerkmodus wird `hostPort` auf denselben Wert wie `containerPort` festgelegt. Dies ist eine statische Zuordnungsstrategie.
+ Gültige Werte für `containerPortRange` liegen zwischen 1 and 65 535.
+ Ein Port kann nur in einer Portzuordnung für jeden Container enthalten sein.
+ Sie können keine überlappenden Portbereiche angeben.
+ Die erste Port im Bereich muss kleiner als der letzte Port im Bereich sein.
+ Docker empfiehlt, den Docker-Proxy in der Konfigurationsdatei des Docker-Daemons zu deaktivieren, wenn Sie eine große Anzahl von Ports haben.
[Weitere Informationen finden Sie in Ausgabe \$111185 unter.](https://github.com/moby/moby/issues/11185) GitHub
Informationen zum Deaktivieren des Docker-Proxy in der Docker-Daemon-Konfigurationsdatei finden Sie unter [Docker-Daemon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) im *Amazon-ECS-Entwicklerhandbuch*.
Sie können [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) aufrufen, um die `hostPortRange` anzuzeigen, bei denen es sich um die Host-Ports handelt, die an die Container-Ports gebunden sind.
Die Portbereiche sind nicht in den Amazon ECS-Aufgabenereignissen enthalten, die an gesendet werden EventBridge. Weitere Informationen finden Sie unter [Automatisieren Sie Antworten auf Amazon ECS-Fehler mit EventBridge](cloudwatch_event_stream.md).
`hostPortRange`
Typ: Zeichenfolge
Erforderlich: Nein
Der Portnummernbereich auf dem Host, der mit der Netzwerkbindung verwendet wird. Dieser wird von Docker zugewiesen und vom Amazon-ECS-Agenten bereitgestellt.
`hostPort`
Typ: Ganzzahl
Erforderlich: Nein
Die Port-Nummer auf der Container-Instance, die für Ihren Container reserviert werden soll.
Der `hostPort` kann leer bleiben oder den gleichen Wert wie der `containerPort` haben.
Der standardmäßige flüchtige Port-Bereich für Docker-Version 1.6.0 und später wird in der Instance unter `/proc/sys/net/ipv4/ip_local_port_range` aufgelistet. Wenn dieser Kernel-Parameter nicht verfügbar ist, wird der standardmäßige flüchtige Port-Bereich von `49153–65535` verwendet. Versuchen Sie nicht, einen Host-Port im flüchtigen Portbereich anzugeben. Das liegt daran, dass diese für die automatische Zuweisung reserviert sind. Im Allgemeinen zählen Ports unter `32768` nicht zum flüchtigen Port-Bereich.
Die standardmäßigen reservierten Ports sind `22` für SSH, die Docker-Ports, `2375` und `2376` und der Amazon-ECS-Container-Agenten-Port `51678-51680`. Jeder Host-Port, der zuvor vom Benutzer für eine laufende Aufgabe festgelegt wurde, ist auch während der Ausführung der Aufgabe reserviert. Nach dem Beenden einer Aufgabe wird der Host-Port freigegeben. Die aktuell reservierten Ports werden in der `remainingResources` der **describe-container-instances**-Ausgabe angezeigt. Eine Container-Instance kann bis zu 100 reservierte Ports gleichzeitig haben, einschließlich der standardmäßig reservierten Ports. Automatisch zugewiesene Ports werden nicht auf das Kontingent von 100 reservierten Ports angerechnet.
`name`
Typ: Zeichenfolge
Erforderlich: Nein, erforderlich für die Konfiguration von Service Connect und VPC Lattice in einem Service
Der Name, der für die Portzuordnung verwendet wird. Dieser Parameter gilt nur für Service Connect und VPC Lattice. Dieser Parameter ist der Name, den Sie in der Service-Connect- und VPC-Lattice-Konfiguration eines Services verwenden.
Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md).
Im folgenden Beispiel werden beide erforderlichen Felder für Service Connect und VPC Lattice verwendet.
```
"portMappings": [
{
"name": string,
"containerPort": integer
}
]
```
`protocol`
Typ: Zeichenfolge
Erforderlich: Nein
Das für die Port-Zuweisung verwendete Protokoll. Gültige Werte sind `tcp` und `udp`. Der Standardwert ist `tcp`.
Nur `tcp` wird für Service Connect unterstützt. Denken Sie daran, dass `tcp` impliziert ist, wenn dieses Feld nicht festgelegt ist.
Verwenden Sie die folgende Syntax, um einen Host-Port anzugeben.
```
"portMappings": [
{
"containerPort": integer,
"hostPort": integer
}
...
]
```
Verwenden Sie die folgende Syntax, um einen Host-Port automatisch zuzuweisen.
```
"portMappings": [
{
"containerPort": integer
}
...
]
```
#### Private-Repository-Daten
`repositoryCredentials`
Typ: [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Objekt
Erforderlich: Nein
Die Repository-Anmeldeinformationen für die Authentifizierung bei privaten Registrierungen.
Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
`credentialsParameter`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `repositoryCredentials` verwendet werden
Der Amazon-Ressourcenname (ARN) des Secrets mit den Anmeldeinformationen für das private Repository.
Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
Wenn Sie die Amazon ECS-API verwenden AWS CLI, oder AWS SDKs, falls der geheime Schlüssel in derselben Region wie die Aufgabe existiert, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Geheimnisses verwenden. Wenn Sie den verwenden AWS-Managementkonsole, müssen Sie den vollständigen ARN des Geheimnisses angeben.
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition, welche die erforderlichen Parameter zeigt:
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
### Erweiterte Parameter für Containerdefinitionen
Die folgenden erweiterten Parameter für Container-Definitionen bieten erweiterte Funktionen für den Docker-Befehl run, der verwendet wird, um Container auf Ihren Amazon-ECS-Container-Instances zu starten.
**Topics**
+ [Neustartrichtlinie](#container_definition_restart_policy)
+ [Gesundheitscheck](#container_definition_healthcheck)
+ [Umgebung](#container_definition_environment)
+ [Netzwerkeinstellungen](#container_definition_network)
+ [Speicher und Protokollierung](#container_definition_storage)
+ [Sicherheit](#container_definition_security)
+ [Ressourcenlimits](#container_definition_limits)
+ [Docker-Bezeichnungen](#container_definition_labels)
#### Neustartrichtlinie
`restartPolicy`
Die Container-Neustart-Richtlinie und die zugehörigen Konfigurationsparameter. Wenn Sie eine Neustart-Richtlinie für einen Container aktivieren, kann Amazon ECS den Container neu starten, ohne dass die Aufgabe ersetzt werden muss. Weitere Informationen finden Sie unter [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md).
`enabled`
Typ: Boolescher Wert
Erforderlich: Ja
Gibt an, ob eine Neustart-Richtlinie für den Container aktiviert ist.
`ignoredExitCodes`
Typ: Ganzzahl-Array
Erforderlich: Nein
Eine Liste von Exit-Codes, die Amazon ECS ignoriert und nicht versucht, neu zu starten. Sie können bis zu 50 Container-Exit-Codes angeben. Standardmäßig ignoriert Amazon ECS keine Exit-Codes.
`restartAttemptPeriod`
Typ: Ganzzahl
Erforderlich: Nein
Ein Zeitraum (in Sekunden), den der Container ausgeführt werden muss, bevor ein Neustart versucht werden kann. Ein Container kann nur einmal alle `restartAttemptPeriod` Sekunden neu gestartet werden. Wenn ein Container für diesen Zeitraum nicht ausgeführt werden kann und vorzeitig beendet wird, wird er nicht neu gestartet. Sie können eine Minimum-`restartAttemptPeriod` von 60 Sekunden und eine Maximum-`restartAttemptPeriod` von 1 800 Sekunden angeben. Standardmäßig muss ein Container 300 Sekunden lang ausgeführt werden, bevor er neu gestartet werden kann.
#### Gesundheitscheck
`healthCheck`
Der Befehl für die Container-Zustandsprüfung und die zugehörigen Konfigurationsparameter für den Container. Weitere Informationen finden Sie unter [Ermitteln des Zustands von Amazon-ECS-Aufgaben mithilfe von Container-Zustandsprüfungen](healthcheck.md).
`command`
Ein Zeichenfolgen-Array, das den Befehl darstellt, den der Container ausführt, um festzustellen, ob er fehlerfrei ist. Das Zeichenfolge-Array kann mit `CMD` beginnen, um die Befehlsargumente direkt auszuführen, oder mit `CMD-SHELL`, um den Befehl mit der Standard-Shell des Containers auszuführen. Ist nichts davon angegeben, wird `CMD` verwendet.
Verwenden Sie beim Registrieren einer Aufgabendefinition in eine durch Kommas getrennte Liste von Befehlen. AWS-Managementkonsole Diese Befehle werden in eine Zeichenfolge konvertiert, nachdem die Aufgabendefinition erstellt wurde. Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.
```
CMD-SHELL, curl -f http://localhost/ || exit 1
```
Wenn Sie eine Aufgabendefinition mithilfe des AWS-Managementkonsole JSON-Bedienfelds registrieren APIs, schließen Sie die Befehlsliste mit dem oder dem in Klammern ein. AWS CLI Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.
```
[ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ]
```
Ein Beendigungscode von 0 ohne `stderr`-Ausgabe zeigt einen Erfolg an, und der Beendigungscode ungleich Null zeigt einen Fehler an.
`interval`
Der Zeitraum (in Sekunden) zwischen den Zustandsprüfungen. Sie können zwischen 5 und 300 Sekunden angeben. Der Standardwert ist 30 Sekunden.
`timeout`
Der Zeitraum (in Sekunden), der angibt, wie lange gewartet wird, bis eine Zustandsprüfung erfolgreich ist, bevor sie als fehlerhaft betrachtet wird. Sie können zwischen 2 und 60 Sekunden angeben. Der Standardwert ist 5 Sekunden.
`retries`
Die Anzahl, wie oft eine fehlgeschlagene Zustandsprüfung wiederholt wird, bevor der Container als fehlerhaft betrachtet wird. Sie können zwischen 1 und 10 Wiederholungen angeben. Der Standardwert ist drei Wiederholungsversuche.
`startPeriod`
Der optionale Übergangszeitraum, der angibt, wie lange der Container Zeit für einen Bootstrap hat, bevor fehlgeschlagene Zustandsprüfungen der maximalen Anzahl an Wiederholungen angerechnet werden. Sie können einen Wert zwischen 0 und 300 Sekunden angeben. Standardmäßig ist `startPeriod` deaktiviert.
Wenn eine Zustandsprüfung innerhalb der `startPeriod` erfolgreich ist, wird die Container als fehlerfrei betrachtet und alle nachfolgenden Ausfälle werden bei der maximal zulässigen Anzahl von Wiederholungen berücksichtigt.
#### Umgebung
`cpu`
Typ: Ganzzahl
Erforderlich: Nein
Die Anzahl der physischen `cpu`-Einheiten, die der Amazon-ECS-Container-Agent für den Container reserviert. Unter Linux ist dieser Parameter im Abschnitt [Container erstellen](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) der Option `CpuShares` zugeordnet.
Dieses Feld ist für Aufgaben, die Fargate verwenden, optional. Die Gesamtmenge an CPU, die für alle Container innerhalb einer Aufgabe reserviert ist, muss niedriger sein als der `cpu`-Wert auf Aufgabenebene.
Linux-Container teilen sich nicht zugewiesene CPU-Einheiten mit anderen Containern auf der Container-Instance im gleichen Verhältnis wie die ihnen zugewiesene Menge. Nehmen Sie zum Beispiel an, dass Sie eine Aufgabe für einen einzelnen Container auf einer Instance mit einem Kern und 512 CPU-Einheiten für diesen Container ausführen. Außerdem ist diese Aufgabe die einzige Aufgabe, die auf der Container-Instance läuft. In diesem Beispiel kann der Container jederzeit die gesamte Menge von 1 024 CPU-Einheiten nutzen. Angenommen, Sie haben jedoch auf dieser Container-Instance eine weitere Kopie der gleichen Aufgabe gestartet. Jede Aufgabe würde bei Bedarf eine garantierte Menge von mindestens 512 CPU-Einheiten erhalten. Ebenso kann jeder Container zu einer höheren CPU-Auslastung übergehen, wenn der andere Container die verbleibende CPU nicht nutzt. Wenn jedoch beide Aufgaben die ganze Zeit 100 % aktiv sind, stünden ihnen jeweils nur 512 CPU-Einheiten zur Verfügung.
Auf Linux-Container-Instances verwendet der Docker-Daemon auf der Container-Instance den CPU-Wert, um das relative CPU-Anteilsverhältnis für die laufenden Container zu berechnen. Der kleinste gültige CPU-Freigabewert, den der Linux-Kernel zulässt, ist 2 und der maximale gültige CPU-Freigabewert, den der Linux-Kernel zulässt, ist 262 144. Der CPU-Parameter ist jedoch nicht erforderlich und Sie können CPU-Werte unter 2 und höher als 262 144 in Ihren Container-Definitionen verwenden. Bei CPU-Werten unter 2 (einschließlich 0) und höher als 262 144 variiert das Verhalten je nach Version Ihres Amazon-ECS-Container-Agenten:
Auf Windows-Container-Instances wird das CPU-Kontingent als absolutes Kontingent durchgesetzt. Windows-Container haben nur Zugriff auf die in der Aufgabendefinition festgelegte Menge an CPU. Ein Nullwert oder ein CPU-Wert von Null wird an Docker als `0` übergeben. Windows interpretiert diesen Wert dann als 1 % einer CPU.
Weitere Beispiele finden Sie unter [So verwaltet Amazon ECS CPU- und Arbeitsspeicher-Ressourcen](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/).
`gpu`
Dieser Parameter wird nicht für Container unterstützt, die in Fargate gehostet werden.
Typ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Objekt
Erforderlich: Nein
Die Anzahl der physischen `GPUs`, die der Amazon-ECS-Container-Agent für den Container reserviert. Die Anzahl der für alle Container in einer Aufgabe GPUs reservierten Container darf die Anzahl der GPUs auf der Container-Instance verfügbaren Container nicht überschreiten, auf der die Aufgabe gestartet wird. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md).
`Elastic Inference accelerator`
Dieser Parameter wird nicht für Container unterstützt, die in Fargate gehostet werden.
Typ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Objekt
Erforderlich: Nein
Für den `InferenceAccelerator`-Typ stimmt der `value` mit dem `deviceName` für einen `InferenceAccelerator` überein, der in einer Aufgabendefinition angegeben ist. Weitere Informationen finden Sie unter [Name des Elastic Inference Accelerators (veraltet)](#elastic-Inference-accelerator).
`essential`
Typ: Boolesch
Erforderlich: Nein
Nehmen wir an, der `essential`-Parameter eines Containers ist als `true` gekennzeichnet und dieser Container schlägt fehl oder wird aus irgendeinem Grund beendet. Dann werden alle anderen Container beendet, die Teil der Aufgabe sind. Wenn der Parameter `essential` eines Containers als `false` gekennzeichnet ist, wirkt sich ein Ausfall dieses Containers nicht auf die anderen Container in der Aufgabe aus. Wenn dieser Parameter ausgelassen wird, wird davon ausgegangen, dass ein Container „essential“ (entscheidend) ist.
Alle Aufgaben müssen über mindestens einen entscheidenden Container verfügen. Angenommen, Sie haben eine Anwendung, die aus mehreren Containern besteht. Dann gruppieren Sie Container, die für einen gemeinsamen Zweck verwendet werden, in Komponenten und teilen die verschiedenen Komponenten in mehrere Aufgabendefinitionen auf. Weitere Informationen finden Sie unter [Entwerfen Ihrer Anwendung für Amazon ECS](application_architecture.md).
```
"essential": true|false
```
`entryPoint`
Von frühen Versionen des Amazon-ECS-Container-Agenten werden die `entryPoint`-Parameter nicht korrekt verarbeitet. Wenn Sie Probleme bei der Verwendung von `entryPoint` haben, aktualisieren Sie Ihren Container-Agenten oder geben Sie Ihre Befehle und Argumente stattdessen als `command`-Array-Objekte an.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Eintrittspunkt, der an den Container übergeben wird.
```
"entryPoint": ["string", ...]
```
`command`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Befehl, der an den Container übergeben wird. Dieser Parameter ist im Befehl create-container der Option `Cmd` und der `COMMAND`-Parameter ist der Docker-Ausführung zugeordnet. Wenn mehrere Argumente vorhanden sind, stellen Sie sicher, dass jedes Argument eine getrennte Zeichenfolge im Array ist.
```
"command": ["string", ...]
```
`workingDirectory`
Typ: Zeichenfolge
Erforderlich: Nein
Das Arbeitsverzeichnis, in dem Befehle im Container ausgeführt werden sollen. Dieser Parameter ordnet zu `WorkingDir` im Bereich [Erstellen eines Containers](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) der [Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) und der Option `--workdir` für die [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) zu.
```
"workingDirectory": "string"
```
`environmentFiles`
Diese Option ist für Windows-Container in Fargate nicht verfügbar.
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste von Dateien, die die Umgebungsvariablen enthalten, die an einen Container übergeben werden sollen. Dieser Parameter ist im Docker-Befehl run der Option `--env-file` zugeordnet.
Sie können bis zu 10 Umgebungsdateien angeben. Die Datei muss eine `.env` Dateierweiterung haben. Jede Zeile in einer Umgebungsdatei enthält eine Umgebungsvariable im Format `VARIABLE=VALUE`. Zeilen, die mit `#` beginnen, werden als Kommentare behandelt und ignoriert.
Wenn in der Containerdefinition einzelne Umgebungsvariablen angegeben sind, haben sie Vorrang vor den Variablen, die in einer Umgebungsdatei enthalten sind. Wenn mehrere Umgebungsdateien angegeben werden, die dieselbe Variable enthalten, werden sie von oben nach unten verarbeitet. Es wird empfohlen, eindeutige Variablennamen zu verwenden. Weitere Informationen finden Sie unter [Eine einzelne Umgebungsvariable an einen Amazon-ECS-Container übergeben](taskdef-envfiles.md).
`value`
Typ: Zeichenfolge
Erforderlich: Ja
Der Amazon-Ressourcenname (ARN) des Amazon S3-Objekts, das die Umgebungsvariablendatei enthält.
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Dateityp, der verwendet werden muss. Der einzige unterstützte Wert ist `s3`.
`environment`
Typ: Objekt-Array
Erforderlich: Nein
Die Umgebungsvariablen, die an einen Container übergeben werden. Dieser Parameter ist im Docker-Befehl create-container der Option `Env` und die Option `--env` ist der Docker-Ausführung zugeordnet.
Die Verwendung von Klartext-Umgebungsvariablen für sensitive Informationen (wie etwa Zugangsdaten) wird nicht empfohlen.
`name`
Typ: Zeichenfolge
Erforderlich: ja, wenn `environment` verwendet wird
Der Name der Umgebungsvariable.
`value`
Typ: Zeichenfolge
Erforderlich: ja, wenn `environment` verwendet wird
Der Wert der Umgebungsvariable.
```
"environment" : [
{ "name" : "string", "value" : "string" },
{ "name" : "string", "value" : "string" }
]
```
`secrets`
Typ: Objekt-Array
Erforderlich: Nein
Ein Objekt, durch das das Secret dargestellt wird, das dem Container zur Verfügung gestellt werden soll. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.
`valueFrom`
Typ: Zeichenfolge
Erforderlich: Ja
Das Geheimnis, das dem Container exponiert werden muss. Die unterstützten Werte sind entweder der vollständige Amazon Resource Name (ARN) des AWS Secrets Manager Secrets oder der vollständige ARN des Parameters im AWS Systems Manager Parameter Store.
Wenn der Systems Manager Parameter Store-Parameter oder der Secrets Manager Manager-Parameter in derselben AWS-Region Datei wie die Aufgabe, die Sie starten, vorhanden ist, können Sie entweder den vollständigen ARN oder den Namen des Secrets verwenden. Wenn der Parameter in einer anderen Region existiert, muss der volle ARN angegeben werden.
```
"secrets": [
{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}
]
```
#### Netzwerkeinstellungen
`disableNetworking`
Dieser Parameter wird nicht für Aufgaben unterstützt, die in Fargate ausgeführt werden.
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter den Wert „true“ aufweist, ist die Netzwerkfunktion innerhalb des Containers deaktiviert.
Der Standardwert ist `false`.
```
"disableNetworking": true|false
```
`links`
Dieser Parameter wird nicht für Aufgaben unterstützt, die den `awsvpc`-Netzwerkmodus verwenden.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Über den Parameter `link` können Container miteinander kommunizieren, ohne dass Port-Zuweisungen nötig sind. Dieser Parameter wird nur unterstützt, wenn der Netzwerkmodus einer Aufgabendefinition auf `bridge` gesetzt ist. Das Konstrukt `name:internalName` ist analog zu `name:alias` in Docker-Verbindungen. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche und Unterstriche sind zulässig.
Container, die sich auf derselben Container-Instance befinden, können miteinander kommunizieren, ohne dass Verbindungen oder Host-Port-Zuweisungen erforderlich sind. Die Netzwerkisolierung auf einer Container-Instance wird durch Sicherheitsgruppen und VPC-Einstellungen gesteuert.
```
"links": ["name:internalName", ...]
```
`hostname`
Typ: Zeichenfolge
Erforderlich: Nein
Der Hostname, der für Ihren Container verwendet werden soll. Dieser Parameter ist im Docker-Befehl create-container der Option `Hostname` und die Option `--hostname` ist der Docker-Ausführung zugeordnet.
Wenn Sie den Netzwerkmodus `awsvpc` verwenden, wird der Parameter `hostname` nicht unterstützt.
```
"hostname": "string"
```
`dnsServers`
Dieser Parameter wird nicht für Aufgaben unterstützt, die in Fargate ausgeführt werden.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Eine List der DNS-Server, die dem Container bereitgestellt werden.
```
"dnsServers": ["string", ...]
```
`extraHosts`
Dieser Parameter wird für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, nicht unterstützt.
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste der Hostnamen und IP-Adresszuordnungen, die an die Datei `/etc/hosts` auf dem Container angefügt werden.
Dieser Parameter ist im Docker-Befehl create-container der Option `ExtraHosts` und die Option `--add-host` ist der Docker-Ausführung zugeordnet.
```
"extraHosts": [
{
"hostname": "string",
"ipAddress": "string"
}
...
]
```
`hostname`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `extraHosts` verwendet werden
Der Hostname, der im Eintrag `/etc/hosts` verwendet werden soll.
`ipAddress`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `extraHosts` verwendet werden
Die IP-Adresse, die im Eintrag `/etc/hosts` verwendet werden soll.
#### Speicher und Protokollierung
`readonlyRootFilesystem`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter den Wert „true“ aufweist, erhält der Container Lesezugriff auf das Root-Dateisystem. Dieser Parameter ist im Docker-Befehl create-container der Option `ReadonlyRootfs` und die Option `--read-only` ist der Docker-Ausführung zugeordnet.
Dieser Parameter wird für Windows-Container nicht unterstützt.
Der Standardwert ist `false`.
```
"readonlyRootFilesystem": true|false
```
`mountPoints`
Typ: Objekt-Array
Erforderlich: Nein
Die Mounting-Punkte für die Daten-Volumes in Ihrem Container. Dieser Parameter ist in der create-container-Docker-API der Option `Volumes` zugeordnet und die Option `--volume` ist der Docker-Ausführung zugeordnet.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden. Windows-Container können keine Verzeichnisse auf einem anderen Laufwerk mounten, und es ist kein laufwerksübergreifender Mounting-Punkt möglich. Sie müssen Mounting-Punkte angeben, um ein Amazon-EBS-Volume direkt an eine Amazon-ECS-Aufgabe anzuhängen.
`sourceVolume`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Name des einzubindenden Volumes.
`containerPath`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Pfad in dem Container, in dem das Volume eingebunden wird.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
Behalten Sie für Aufgaben, die auf EC2-Instances unter dem Windows-Betriebssystem ausgeführt werden, den Standardwert von `false` bei.
`volumesFrom`
Typ: Objekt-Array
Erforderlich: Nein
Die Daten-Volumes, die von einem anderen Container gemountet werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `VolumesFrom` und die Option `--volumes-from` ist der Docker-Ausführung zugeordnet.
`sourceContainer`
Typ: Zeichenfolge
Erforderlich: ja, wenn `volumesFrom` verwendet wird
Der Name des Containers, von dem die Volumes gemountet werden.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
```
"volumesFrom": [
{
"sourceContainer": "string",
"readOnly": true|false
}
]
```
`logConfiguration`
Typ: [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)Objekt
Erforderlich: Nein
Die Angabe der Protokollkonfiguration für den Container.
Beispiele für Aufgabendefinitionen, die eine Protokollkonfiguration verwenden, finden Sie unter [Beispiele für Amazon-ECS-Aufgabendefinitionen](example_task_definitions.md).
Dieser Parameter ist im Docker-Befehl create-container der Option `LogConfig` und die Option `--log-driver` ist der Docker-Ausführung zugeordnet. Standardmäßig verwenden Container den gleichen Protokolltreiber wie der Docker-Daemon. Allerdings kann der Container einen anderen Protokolltreiber als der Docker-Daemon verwenden, indem Sie einen Protokolltreiber mit diesem Parameter in der Container-Definition angeben. Um für einen Container einen anderen Protokolltreiber zu verwenden, muss das Protokollsystem auf der Container-Instance (oder einem anderen Protokollserver für die Remote-Protokollierung) ordnungsgemäß konfiguriert sein.
Beachten Sie die folgenden Punkte, wenn eine Protokollkonfiguration für Ihre Container angegeben ist:
+ Amazon ECS unterstützt einen Teil der Protokolltreiber, die für den Docker-Daemon verfügbar sind.
+ Für diesen Parameter muss Ihre Docker Remote API Version 1.18 oder höher in Ihrer Container-Instance verwenden.
+ Sie müssen jegliche zusätzliche Software außerhalb der Aufgabe installieren. Beispiel: Die Fluentd-Ausgangsaggregatoren oder ein Remote-Host, auf dem Logstash ausgeführt wird, um Gelf-Protokolle dorthin zu senden.
```
"logConfiguration": {
"logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens",
"options": {"string": "string"
...},
"secretOptions": [{
"name": "string",
"valueFrom": "string"
}]
}
```
`logDriver`
Typ: Zeichenfolge
Zulässige Werte: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"`
Erforderlich: ja, wenn `logConfiguration` verwendet wird
Der für den Container zu verwendende Protokolltreiber. Standardmäßig sind die zuvor aufgeführten gültigen Werte Protokolltreiber, mit denen der Amazon-ECS-Container-Agent kommunizieren kann.
Die unterstützten Protokolltreiber sind `awslogs`, `splunk` und `awsfirelens`.
Weitere Informationen zur Verwendung des `awslogs` Protokolltreibers in Aufgabendefinitionen zum Senden Ihrer Container-Logs an CloudWatch Logs finden Sie unter[Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md).
Weitere Informationen zur Verwendung des Protokolltreibers `awsfirelens` finden Sie unter [Routing benutzerdefinierter Protokolle](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html).
Wenn Sie einen benutzerdefinierten Treiber haben, der nicht aufgeführt ist, können Sie das Amazon ECS-Container-Agent-Projekt, das [verfügbar](https://github.com/aws/amazon-ecs-agent) ist, forken GitHub und es so anpassen, dass es mit diesem Treiber funktioniert. Wir möchten Sie bitten, uns eventuelle Änderungswünsche mitzuteilen. Allerdings unterstützen wir derzeit nicht die Ausführung modifizierter Kopien dieser Software.
Für diesen Parameter ist Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance erforderlich.
`options`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Die key/value Zuordnung der Konfigurationsoptionen, die an den Protokolltreiber gesendet werden sollen.
Die Optionen, die Sie angeben können, hängen vom Protokolltreiber ab. Zu den Optionen, die Sie angeben können, wenn Sie den `awslogs` Router zum Weiterleiten von Protokollen an Amazon verwenden, CloudWatch gehören die folgenden:
`awslogs-create-group`
Erforderlich: Nein
Geben Sie an, ob die Protokollgruppe automatisch erstellt werden soll. Wenn diese Option nicht angegeben ist, gilt standardmäßig `false`.
Ihre IAM-Richtlinie muss die `logs:CreateLogGroup`-Berechtigung umfassen, bevor Sie `awslogs-create-group` zu nutzen versuchen.
`awslogs-region`
Erforderlich: Ja
Geben Sie an AWS-Region , an `awslogs` wen der Protokolltreiber Ihre Docker-Protokolle senden soll. In Logs können Sie wählen, ob Sie alle Ihre Logs von Clustern in verschiedenen Regionen an eine einzige Region senden möchten. CloudWatch Dann sind alle an einem Standort sichtbar. Andernfalls können Sie sie nach Region aufteilen, um eine höhere Granularität zu erzielen. Vergewissern Sie sich, dass die angegebene Protokollgruppe in der Region vorhanden ist, die Sie mit dieser Option festlegen.
`awslogs-group`
Erforderlich: Ja
Sie müssen eine Protokollgruppe angeben, an die der `awslogs`-Protokolltreiber seine Protokoll-Streams sendet.
`awslogs-stream-prefix`
Erforderlich: Ja
Mit der `awslogs-stream-prefix`-Option können Sie einen Protokoll-Stream mit dem angegebenen Präfix, dem Containernamen und der ID der Amazon-ECS-Aufgabe verknüpfen, zu der der Container gehört. Wenn Sie einen Präfix mit dieser Option angeben, weist der Protokoll-Stream das folgende Format auf:
```
prefix-name/container-name/ecs-task-id
```
Wenn Sie keinen Präfix mit dieser Option angeben, wird der Protokoll-Stream nach der Container-ID benannt, die vom Docker-Daemon auf der Container-Instance zugewiesen wurde. Da es schwierig ist, Protokolle nur mit der Docker-Container-ID (die nur auf der Container-Instance verfügbar ist) zum Container zurückzuverfolgen, der sie gesendet hat, empfehlen wir, dass Sie einen Präfix mit dieser Option festlegen.
Für Amazon-ECS-Services können Sie den Servicenamen als Präfix verwenden. So können Sie Protokollstreams zu dem Service zurückverfolgen, zu dem der Container gehört, den Namen des Containers ermitteln, der sie gesendet hat, und die ID der Aufgabe, zu der der Container gehört.
Sie müssen ein Stream-Präfix für Ihre Protokolle angeben, damit Ihre Protokolle im Protokollfeld der Amazon-ECS-Konsole angezeigt werden.
`awslogs-datetime-format`
Erforderlich: Nein
Diese Option definiert einen mehrzeiliges Startmuster im `strftime`-Format von Python. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen. Die zugeordnete Zeile ist das Trennzeichen zwischen Protokollnachrichten.
Ein Beispiel für einen Anwendungsfall für die Nutzung dieses Formats ist die Ausgabenanalyse, z. B. einen Stack-Dump, der andernfalls möglicherweise mehrere Einträge protokolliert. Mit dem richtigen Muster kann es in nur einem Eintrag erfasst werden.
Weitere Informationen finden Sie unter [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format).
Sie können nicht sowohl die Optionen `awslogs-datetime-format` und `awslogs-multiline-pattern` konfigurieren.
Bei der mehrzeiligen Protokollierung wird eine regelmäßige Ausdrucksanalyse und die Übereinstimmung aller Protokollmeldungen ausgeführt. Dies kann negative Auswirkungen auf die Leistung der Protokollierung haben.
`awslogs-multiline-pattern`
Erforderlich: Nein
Diese Option definiert ein mehrzeiliges Startmuster mit einem regulären Ausdruck. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen. Die zugeordnete Zeile ist das Trennzeichen zwischen Protokollnachrichten.
Weitere Informationen finden Sie unter [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern).
Diese Option wird ignoriert, wenn `awslogs-datetime-format` ebenfalls konfiguriert ist.
Sie können nicht sowohl die Optionen `awslogs-datetime-format` und `awslogs-multiline-pattern` konfigurieren.
Bei der mehrzeiligen Protokollierung wird eine regelmäßige Ausdrucksanalyse und die Übereinstimmung aller Protokollmeldungen ausgeführt. Dies kann negative Auswirkungen auf die Leistung der Protokollierung haben.
Die folgenden Optionen gelten für alle unterstützten Protokolltreiber.
`mode`
Erforderlich: Nein
Zulässige Werte: `non-blocking` \$1 `blocking`
Diese Option definiert den Zustellungsmodus von Protokollnachrichten von dem Container an den mit `logDriver` angegebenen Protokolltreiber. Der von Ihnen gewählte Zustellungsmodus wirkt sich auf die Anwendungsverfügbarkeit aus, wenn der Protokollfluss vom Container unterbrochen wird.
Wenn Sie den `blocking`-Modus verwenden und der Protokollfluss unterbrochen wird, werden Aufrufe von Container-Code zum Schreiben in die `stdout`- und `stderr`-Streams blockiert. Der Logging-Thread der Anwendung wird daraufhin blockiert. Dies kann dazu führen, dass die Anwendung nicht mehr reagiert und die Container-Zustandsprüfung fehlschlägt.
Wenn Sie den `non-blocking`-Modus verwenden, werden die Protokolle des Containers stattdessen in einem mit der Option `max-buffer-size` konfigurierten Zwischenpuffer im Arbeitsspeicher gespeichert. Dadurch wird verhindert, dass die Anwendung nicht mehr reagiert, wenn Protokolle nicht gesendet werden können. Wir empfehlen, diesen Modus zu verwenden, wenn Sie die Verfügbarkeit des Services sicherstellen möchten und einen gewissen Protokollverlust in Kauf nehmen möchten. Weitere Informationen finden Sie unter [Verhinderung von Protokollverlusten im blockierungsfreien Modus im `awslogs`-Container-Protokolltreiber](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/).
Mithilfe der Kontoeinstellung `defaultLogDriverMode` können Sie einen Standard-`mode` für alle Container in einer bestimmten AWS-Region festlegen. Wenn Sie die `mode`-Option nicht in `logConfiguration` angeben oder die Kontoeinstellung konfigurieren, verwendet Amazon ECS standardmäßig den `non-blocking`-Modus. Weitere Informationen über die Kontoeinstellung finden Sie unter [Standard-Protokolltreibermodus](ecs-account-settings.md#default-log-driver-mode).
Wenn der `non-blocking`-Modus verwendet wird, steuert die `max-buffer-size`-Protokolloption die Größe des Puffers, der für die Zwischenspeicherung von Nachrichten verwendet wird. Stellen Sie sicher, dass Sie eine für Ihre Anwendung angemessene Puffergröße angeben. Die Gesamtmenge des auf Aufgabenebene zugewiesenen Arbeitsspeichers muss zusätzlich zum Arbeitsspeicher-Puffer des Protokolltreibers größer sein als die für alle Container zugewiesene Menge an Arbeitsspeicher.
Am 25. Juni 2025 änderte Amazon ECS den Standard-Protokolltreibermodus von `blocking` auf `non-blocking`, um der Verfügbarkeit von Aufgaben Vorrang vor der Protokollierung einzuräumen. Führen Sie einen der folgenden Schritte aus, um den `blocking`-Modus nach dieser Änderung weiter zu verwenden:
+ Stellen Sie die `mode`-Option in `logConfiguration` in der Container-Definition als `blocking` ein.
+ Stellen Sie die Kontoeinstellung `defaultLogDriverMode` auf `blocking` ein.
`max-buffer-size`
Erforderlich: Nein
Standardwert: `10m`
Wenn der `non-blocking`-Modus verwendet wird, steuert die `max-buffer-size`-Protokolloption die Größe des Puffers, der für die Zwischenspeicherung von Nachrichten verwendet wird. Stellen Sie sicher, dass Sie eine für Ihre Anwendung angemessene Puffergröße angeben. Wenn der Puffer voll ist, können keine weiteren Protokolle gespeichert werden. Protokolle, die nicht gespeichert werden können, gehen verloren.
Um Protokolle mithilfe des `splunk`-Protokollrouters weiterzuleiten, müssen Sie ein `splunk-token` und eine `splunk-url` angeben.
Wenn Sie den `awsfirelens` Log-Router verwenden, um Logs zur Protokollspeicherung und Analyse an ein AWS-Service AWS Partner Network Oder-Ziel weiterzuleiten, können Sie die `log-driver-buffer-limit` Option so einstellen, dass die Anzahl der Log-Zeilen begrenzt wird, die im Speicher zwischengespeichert werden, bevor sie an den Log Router-Container gesendet werden. Es kann helfen, ein potenzielles Problem mit dem Verlust von Protokollen zu beheben, da ein hoher Durchsatz dazu führen könnte, dass der Speicher für Puffer innerhalb von Docker ausgeht. Weitere Informationen finden Sie unter [Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).
Andere Optionen, die Sie beim Weiterleiten von Protokollen mithilfe von `awsfirelens` angeben können, hängen vom Ziel ab. Wenn Sie Protokolle nach Amazon Data Firehose exportieren, können Sie das AWS-Region mit `region` und einen Namen für den Protokollstream mit `delivery_stream` angeben.
Wenn Sie Protokolle nach Amazon Kinesis Data Streams exportieren, können Sie eine AWS-Region mit `region` und einen Datenstrom-Namen mit `stream` angeben.
Wenn Sie Protokolle nach Amazon OpenSearch Service exportieren, können Sie Optionen wie `Name` `Host` (OpenSearch Service-Endpunkt ohne Protokoll),`Port`,`Index`,`Type`,`Aws_auth`, `Aws_region``Suppress_Type_Name`, und angeben`tls`.
Wenn Sie Protokolle nach Amazon S3 exportieren, können Sie den Bucket mit der `bucket`-Option angeben. Sie können auch `region`, `total_file_size`, `upload_timeout` und `use_put_object` als Optionen angeben.
Für diesen Parameter muss Ihre Docker Remote API Version 1.19 oder höher in Ihrer Container-Instance verwenden.
`secretOptions`
Typ: Objekt-Array
Erforderlich: Nein
Ein Objekt, welches das Secret darstellt, der an die Protokollkonfiguration übergeben werden soll. Zu den Secrets, die in der Protokollkonfiguration verwendet werden, können ein Authentifizierungs-Token, ein Zertifikat oder ein Verschlüsselungsschlüssel gehören. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.
`valueFrom`
Typ: Zeichenfolge
Erforderlich: Ja
Das Geheimnis zur Bereitstellung der Protokollkonfiguration des Containers.
```
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"splunk-token": "...",
"tag": "...",
...
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "/ecs/logconfig/splunkcred"
}]
}
```
`firelensConfiguration`
Typ: [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html)Objekt
Erforderlich: Nein
Die FireLens Konfiguration für den Container. Dies wird verwendet, um einen Protokollrouter für Container-Protokolle anzugeben und zu konfigurieren. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md).
```
{
"firelensConfiguration": {
"type": "fluentd",
"options": {
"KeyName": ""
}
}
}
```
`options`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Die key/value Übersicht der Optionen, die bei der Konfiguration des Log-Routers verwendet werden sollen. Dieses Feld ist optional und kann verwendet werden, um eine benutzerdefinierte Konfigurationsdatei anzugeben oder dem Protokollereignis zusätzliche Metadaten hinzuzufügen, z. B. Aufgaben-, Aufgabendefinitions-, Cluster- und Container-Instance-Details. Wenn angegeben, ist die zu verwendende Syntax `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Weitere Informationen finden Sie unter [Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten](firelens-taskdef.md).
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Der zu verwendende Protokollrouter. Die gültigen Werte sind `fluentd` und `fluentbit`.
#### Sicherheit
Weitere Informationen zur Container-Sicherheit finden Sie unter [Bewährte Methoden für die Sicherheit von Amazon-ECS-Aufgaben und -Containern](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html).
`credentialSpecs`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Eine Liste von ARNs in SSM oder Amazon S3 in einer Credential Spec (`CredSpec`) -Datei, die den Container für die Active Directory-Authentifizierung konfiguriert. Es wird empfohlen, diesen Parameter anstelle von `dockerSecurityOptions` zu verwenden. Die maximale Anzahl von ist 1. ARNs
Es gibt zwei Formate für jeden ARN.
credentialspecdomainless:MyARN
Sie verwenden `credentialspecdomainless:MyARN`, um `CredSpec` einen zusätzlichen Abschnitt für ein Secret in Secrets Manager bereitzustellen. Sie geben die Anmeldeinformationen für die Domain im Secret an.
Jede Aufgabe, die auf einer beliebigen Container-Instance ausgeführt wird, kann verschiedenen Domains beitreten.
Sie können dieses Format verwenden, ohne die Container-Instance mit einer Domain zu verbinden.
credentialspec:MyARN
Sie verwenden `credentialspec:MyARN`, um `CredSpec` für eine einzelne Domain bereitzustellen.
Sie müssen die Container-Instance mit der Domain verbinden, bevor Sie Aufgaben starten, die diese Aufgabendefinition verwenden.
Ersetzen Sie in beiden Formaten `MyARN` durch den ARN in SSM oder Amazon S3.
Die `credspec` muss im Secrets Manager einen ARN für ein Secret angeben, das den Benutzernamen, das Passwort und die Domain enthält, zu der eine Verbindung hergestellt werden soll. Aus Sicherheitsgründen ist die Instance bei der domainlosen Authentifizierung nicht mit der Domain verbunden. Andere Anwendungen auf der Instance können die domainlosen Anmeldeinformationen nicht verwenden. Sie können diesen Parameter verwenden, um Aufgaben auf derselben Instance auszuführen, auch wenn die Aufgaben mit verschiedenen Domains verbunden werden müssen. Weitere Informationen finden Sie unter [G MSAs für Windows-Container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) [verwenden und G MSAs für Linux-Container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html) verwenden.
`user`
Typ: Zeichenfolge
Erforderlich: Nein
Der Benutzer, der im Container verwendet werden soll. Dieser Parameter ist im Docker-Befehl create-container der Option `User` und die Option `--user` ist der Docker-Ausführung zugeordnet.
Wenn Sie Aufgaben im Netzwerkmodus `host` ausführen, sollten Sie Container nicht über den Root-Benutzer (UID 0) ausführen. Verwenden Sie als bewährte Sicherheitsmethode immer einen Nicht-Root-Benutzer.
Sie können den `user` mit den folgenden Formaten angeben. Wenn Sie eine User Identifier (UID, Benutzerbezeichner) und Group Identifier (GID, Gruppenbezeichner) angeben, müssen Sie sie als positive Ganzzahl angeben.
+ `user`
+ `user:group`
+ `uid`
+ `uid:gid`
+ `user:gid`
+ `uid:group`
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"user": "string"
```
#### Ressourcenlimits
`ulimits`
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste von `ulimit`-Werten, die für einen Container definiert werden sollen. Dieser Wert überschreibt die Standardeinstellung für das Ressourcenkontingent für das Betriebssystem. Dieser Parameter ist im Docker-Befehl create-container der Option `Ulimits` und die Option `--ulimit` ist der Docker-Ausführung zugeordnet.
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. Weitere Informationen finden Sie unter [Aufgabenressourcenlimits](fargate-tasks-services.md#fargate-resource-limits).
Dieser Parameter erfordert Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance.
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"ulimits": [
{
"name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack",
"softLimit": integer,
"hardLimit": integer
}
...
]
```
`name`
Typ: Zeichenfolge
Zulässige Werte: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"`
Erforderlich: Ja, wenn `ulimits` verwendet werden
Der `type` des `ulimit`-Werts.
`hardLimit`
Typ: Ganzzahl
Erforderlich: Ja, wenn `ulimits` verwendet werden
Das harte Limit für den `ulimit`-Typ. Der Wert kann je nach dem `type` des `ulimit` in Byte, Sekunden oder als Anzahl angegeben werden.
`softLimit`
Typ: Ganzzahl
Erforderlich: Ja, wenn `ulimits` verwendet werden
Das weiche Limit für den `ulimit`-Typ. Der Wert kann je nach dem `type` des `ulimit` in Byte, Sekunden oder als Anzahl angegeben werden.
#### Docker-Bezeichnungen
`dockerLabels`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Eine key/value Karte mit Labels, die dem Container hinzugefügt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `Labels` und die Option `--label` ist der Docker-Ausführung zugeordnet.
Dieser Parameter erfordert Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance.
```
"dockerLabels": {"string": "string"
...}
```
### Andere Parameter für die Containerdefinition
Die folgenden Parameter für die Containerdefinition können beim Registrieren von Aufgabendefinitionen in der Amazon-ECS-Konsole mit der Option **Configure via JSON** (Über JSON konfigurieren) verwendet werden. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
**Topics**
+ [Linux-Parameter](#container_definition_linuxparameters)
+ [Container-Abhängigkeit](#container_definition_dependson)
+ [Container-Timeouts](#container_definition_timeout)
+ [Systemkontrollen](#container_definition_systemcontrols)
+ [Interactive](#container_definition_interactive)
+ [Pseudo-Terminal](#container_definition_pseudoterminal)
#### Linux-Parameter
`linuxParameters`
Typ: [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Objekt
Erforderlich: Nein
Linux-spezifische Optionen, die auf den Container angewendet werden, wie z. [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html)
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"linuxParameters": {
"capabilities": {
"add": ["string", ...],
"drop": ["string", ...]
}
}
```
`capabilities`
Typ: [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Objekt
Erforderlich: Nein
Die Linux-Funktionen für den Container, die aus der von Docker bereitgestellten Standardkonfiguration entfernt werden. Weitere Informationen zu diesen Linux-Funktionen finden Sie auf der Linux-Handbuchseite [Funktionen (7)](http://man7.org/linux/man-pages/man7/capabilities.7.html).
`add`
Typ: Zeichenfolgen-Array
Zulässige Werte: `"SYS_PTRACE"`
Erforderlich: Nein
Die Linux-Funktionen für den Container, die zu der von Docker bereitgestellten Standardkonfiguration hinzugefügt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `CapAdd` und die Option `--cap-add` ist der Docker-Ausführung zugeordnet.
`drop`
Typ: Zeichenfolgen-Array
Zulässige Werte: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"`
Erforderlich: Nein
Die Linux-Funktionen für den Container, die aus der von Docker bereitgestellten Standardkonfiguration entfernt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `CapDrop` und die Option `--cap-drop` ist der Docker-Ausführung zugeordnet.
`devices`
Alle Host-Geräte, die dem Container zur Verfügung gestellt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `Devices` und die Option `--device` ist der Docker-Ausführung zugeordnet.
Der `devices`-Parameter wird nicht unterstützt, wenn Sie den Starttyp Fargate verwenden.
Typ: Array von [Device](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html)-Objekten
Erforderlich: Nein
`hostPath`
Der Gerätepfad auf der Hostcontainer-Instance.
Typ: Zeichenfolge
Erforderlich: Ja
`containerPath`
Der Pfad im Container, der dem Hostgerät verfügbar gemacht werden soll.
Typ: Zeichenfolge
Erforderlich: Nein
`permissions`
Die expliziten Berechtigungen, die dem Container für das Gerät bereitgestellt werden sollen. Standardmäßig hat der Container Berechtigungen für `read`, `write`und `mknod` auf dem Gerät.
Typ: Zeichenfolgen-Array
Zulässige Werte: `read` \$1 `write` \$1 `mknod`
`initProcessEnabled`
Führen Sie einen `init`-Prozess innerhalb des Containers aus, der Signalen weiterleitet und Prozesse aufnimmt. Dieser Parameter ist der Option `--init` für die Docker-Ausführung zugeordnet.
Für diesen Parameter muss Ihre Docker Remote API Version 1.25 oder höher in Ihrer Container-Instance verwenden.
`maxSwap`
Dieser Parameter wird nicht für Aufgaben unterstützt, die in Fargate ausgeführt werden.
Die Gesamtmenge des Auslagerungsspeichers (in MiB), den ein Container verwenden kann. Dieser Parameter ist in die Option `--memory-swap` zur Docker-Ausführung übersetzt, wobei der Wert die Summe aus dem Container-Speicher und dem Wert `maxSwap` ist.
Wenn als `maxSwap`-Wert `0` angegeben wird, verwendet der Container keine Auslagerung. Zulässige Werte sind `0` oder eine beliebige positive Ganzzahl. Wenn der Parameter `maxSwap` weggelassen wird, verwendet der Container die Swap-Konfiguration für die Container-Instance, auf der er ausgeführt wird. Es muss ein Wert für `maxSwap` festgelegt werden, damit der Parameter `swappiness` verwendet werden kann.
`sharedMemorySize`
Der Wert für die Größe des `/dev/shm`-Volumes (in MiB). Dieser Parameter ist der Option `--shm-size` für die Docker-Ausführung zugeordnet.
Wenn Sie Aufgaben verwenden, die Fargate verwenden, wird der Parameter `sharedMemorySize` nicht unterstützt.
Typ: Ganzzahl
`tmpfs`
Der Container-Pfad, Mount-Optionen und Maximalgröße (in MB) des tmpfs-Mounts. Dieser Parameter ist der Option `--tmpfs` für die Docker-Ausführung zugeordnet.
Typ: Array von [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html)-Objekten
Erforderlich: Nein
`containerPath`
Der absolute Dateipfad, unter dem die tmpfs-Volumes gemountet werden.
Typ: Zeichenfolge
Erforderlich: Ja
`mountOptions`
Die Liste der Mount-Optionen für das tmpfs-Volume.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Zulässige Werte: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"`
`size`
Die maximale Größe (in MiB) des tmpfs-Volumes.
Typ: Ganzzahl
Erforderlich: Ja
#### Container-Abhängigkeit
`dependsOn`
Typ: Array von [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html)-Objekten
Erforderlich: Nein
Die für das Startup und Herunterfahren des Containers definierten Abhängigkeiten. Ein Container kann mehrere Abhängigkeiten enthalten. Wenn eine Abhängigkeit für das Startup und das Herunterfahren des Containers definiert ist, ist sie reserviert. Ein Beispiel finden Sie unter [Container-Abhängigkeit](example_task_definitions.md#example_task_definition-containerdependency).
Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.
Dieser Parameter erfordert, dass die Aufgabe oder der Service die Plattformversion `1.3.0` oder höher verwendet (Linux) oder `1.0.0` (Windows).
```
"dependsOn": [
{
"containerName": "string",
"condition": "string"
}
]
```
`containerName`
Typ: Zeichenfolge
Erforderlich: Ja
Der Container-Name, der die angegebene Bedingung erfüllen muss.
`condition`
Typ: Zeichenfolge
Erforderlich: Ja
Die Abhängigkeitsbedingung des Containers. Der folgenden Tabelle sind die verfügbaren Bedingungen und deren Verhalten zu entnehmen:
+ `START` – Diese Bedingung emuliert das heutige Verhalten von Links und Volumes. Die Bedingung überprüft, ob ein abhängiger Container gestartet wurde, bevor das Starten anderer Container zugelassen wird.
+ `COMPLETE` – Diese Bedingung überprüft, ob ein abhängiger Container vollständig ausgeführt (beendet) wurde, bevor das Starten anderer Container zugelassen wird. Dies kann für nicht benötigte Container hilfreich sein, die ein Skript ausführen und dann beendet werden. Diese Bedingung kann nicht für einen essentiellen Container festgelegt werden.
+ `SUCCESS` – Diese Bedingung ist mit `COMPLETE` identisch, erfordert aber auch, dass der Container mit dem Status `zero` beendet wird. Diese Bedingung kann nicht für einen essenziellen Container festgelegt werden.
+ `HEALTHY` – Diese Bedingung überprüft, ob der abhängige Container seine Zustandsprüfung bestanden hat, bevor das Starten anderer Container zugelassen wird. Dies setzt voraus, das für den abhängigen Container Zustandsprüfungen in der Aufgabendefinition konfiguriert wurden. Diese Bedingung wird nur beim Startup der Aufgabe bestätigt.
#### Container-Timeouts
`startTimeout`
Typ: Ganzzahl
Erforderlich: Nein
Beispielwerte: `120`
Zeitdauer (in Sekunden), die gewartet wird, bevor die Auflösung von Abhängigkeiten für einen Container aufgegeben wird.
Angenommen, Sie geben zwei Container in einer Aufgabendefinition an und `containerA` ist abhängig davon, dass `containerB` den Status `COMPLETE`, `SUCCESS` oder `HEALTHY` erreicht. Wenn ein `startTimeout`-Wert für `containerB` angegeben ist und es den gewünschten Status nicht innerhalb dieses Zeitraums erreicht, wird `containerA` nicht gestartet.
Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.
Dieser Parameter erfordert, dass die Aufgabe oder der Service die Plattformversion `1.3.0` oder höher (Linux) verwendet. Der Höchstwert beträgt 120 Sekunden.
`stopTimeout`
Typ: Ganzzahl
Erforderlich: Nein
Beispielwerte: `120`
Dauer (in Sekunden), die gewartet werden soll, bevor der Container zwangsweise beendet wird, wenn er nicht normal beendet wird.
Dieser Parameter erfordert, dass die Aufgabe oder der Service die Plattformversion `1.3.0` oder höher (Linux) verwendet. Wenn der Parameter nicht angegeben wird, wird der Standardwert 30 Sekunden verwendet. Der Höchstwert beträgt 120 Sekunden.
#### Systemkontrollen
`systemControls`
Typ: [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Objekt
Erforderlich: Nein
Eine Liste der Namespace-Kernel-Parameter, die im Container festgelegt werden Dieser Parameter ist im Docker-Befehl create-container der Option `Sysctls` und die Option `--sysctl` ist der Docker-Ausführung zugeordnet. Beispielsweise können Sie die `net.ipv4.tcp_keepalive_time`-Einstellung konfigurieren, um Verbindungen mit einer längeren Lebensdauer aufrechtzuerhalten.
Wir empfehlen nicht, netzwerkbezogene `systemControls`-Parameter für mehrere Container in einer einzelnen Aufgabe festzulegen, die auch entweder den `awsvpc`- oder `host`-Netzwerkmodus verwendet. Dies hat die folgenden Nachteile:
+ Wenn Sie `systemControls` für einen beliebigen Container festlegen, werden diese auf alle Container in der Aufgabe angewendet. Wenn Sie unterschiedliche `systemControls` für mehrere Container innerhalb einer einzelnen Aufgabe festlegen, werden die `systemControls` des zuletzt gestarteten Containers für alle Container übernommen.
Wenn Sie einen IPC-Ressourcen-Namespace für die Container in der Aufgabe einrichten, gelten folgende Bedingungen für Ihre Systemsteuerungen. Weitere Informationen finden Sie unter [IPC-Modus](#task_definition_ipcmode).
+ Für Aufgaben, die den IPC-Modus `host` verwenden, wird der IPC-Namespace `systemControls` nicht unterstützt.
+ Für Aufgaben, die den IPC-Modus `task` verwenden, gelten die Werte des IPC-Namespace `systemControls` für alle Container innerhalb einer Aufgabe.
Dieser Parameter wird für Windows-Container nicht unterstützt.
Dieser Parameter wird nur für Aufgaben unterstützt, die auf AWS Fargate gehostet werden, wenn die Aufgaben die Plattformversion `1.4.0` oder höher (Linux) verwenden. Dies wird für Windows-Container auf Fargate nicht unterstützt.
```
"systemControls": [
{
"namespace":"string",
"value":"string"
}
]
```
`namespace`
Typ: Zeichenfolge
Erforderlich: Nein
Der Namespace-Kernel-Parameter, für den ein `value` festgelegt wird.
Gültige IPC-Namespace-Werte: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` und `Sysctls`, die mit `"fs.mqueue.*"` beginnen
Gültige Netzwerk-Namespace-Werte: `Sysctls` beginnend mit `"net.*"` In Fargate werden nur `Sysctls` mit Namespace akzeptiert, die innerhalb des Containers existieren.
Alle diese Werte werden von Fargate unterstützt.
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der Wert für den Namespace-Kernel-Parameter, der in `namespace` angegeben ist.
#### Interactive
`interactive`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` ist, können Sie Container-Anwendungen bereitstellen, für die `stdin` oder `tty` zugeordnet werden muss. Dieser Parameter ist im Docker-Befehl create-container der Option `OpenStdin` und die Option `--interactive` ist der Docker-Ausführung zugeordnet.
Der Standardwert ist `false`.
#### Pseudo-Terminal
`pseudoTerminal`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` lautet, wird ein TTY zugeordnet. Dieser Parameter ist im Docker-Befehl create-container der Option `Tty` und die Option `--tty` ist der Docker-Ausführung zugeordnet.
Der Standardwert ist `false`.
## Name des Elastic Inference Accelerators (veraltet)
Die Ressourcenanforderung des Elastic-Inference-Beschleunigers für Ihre Aufgabendefinition.
**Anmerkung**
Amazon Elastic Inference (EI) ist für Kunden nicht mehr verfügbar.
Die folgenden Parameter sind in einer Aufgabendefinition zulässig:
`deviceName`
Typ: Zeichenfolge
Erforderlich: Ja
Der Gerätename des Elastic Inference-Beschleunigers. Der `deviceName` muss auch in einer Containerdefinition referenziert werden, siehe [Elastic Inference accelerator](#ContainerDefinition-elastic-inference).
`deviceType`
Typ: Zeichenfolge
Erforderlich: Ja
Der zu verwendende Elastic-Inference-Beschleuniger.
## Proxykonfiguration
`proxyConfiguration`
Typ: [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Objekt
Erforderlich: Nein
Die Konfigurationsdetails für den App Mesh-Proxy.
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "string",
"properties": [
{
"name": "string",
"value": "string"
}
]
}
```
`type`
Typ: Zeichenfolge
Gültige Werte: `APPMESH`
Erforderlich: Nein
Der Proxy-Typ. Der einzige unterstützte Wert ist `APPMESH`.
`containerName`
Typ: Zeichenfolge
Erforderlich: Ja
Der Name des Containers, der als App Mesh-Proxy dient.
`properties`
Typ: Array von [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html)-Objekten
Erforderlich: Nein
Der dem Container Network Interface (CNI)-Plug-In bereitzustellende Satz von Netzwerkkonfigurationsparametern, die als Schlüssel-Wert-Paare angegeben werden.
+ `IgnoredUID` – (Erforderlich) Die Benutzer-ID (UID) des Proxy-Containers gemäß der Definition durch den `user`-Parameter in einer Containerdefinition. Dadurch wird sichergestellt, dass der Proxy eigenen Datenverkehr ignoriert. Wenn `IgnoredGID` angegeben wird, kann dieses Feld leer sein.
+ `IgnoredGID` – (Erforderlich) Die Gruppen-ID (GID) des Proxy-Containers gemäß der Definition durch den `user`-Parameter in einer Containerdefinition. Dadurch wird sichergestellt, dass der Proxy eigenen Datenverkehr ignoriert. Wenn `IgnoredUID` angegeben wird, kann dieses Feld leer sein.
+ `AppPorts` – (Erforderlich) Die Liste der Ports, welche die Anwendung verwendet. Der Netzwerkdatenverkehr zu diesen Ports wird an den `ProxyIngressPort` und den `ProxyEgressPort` weitergeleitet.
+ `ProxyIngressPort` – (Erforderlich) Gibt den Port an, an den eingehender Datenverkehr zu den `AppPorts` geleitet wird.
+ `ProxyEgressPort` – (Erforderlich) Gibt den Port an, an den ausgehender Datenverkehr zu den `AppPorts` geleitet wird.
+ `EgressIgnoredPorts` – (Erforderlich) Der ausgehende Datenverkehr zu diesen angegebenen Ports wird ignoriert und nicht an den `ProxyEgressPort` umgeleitet. Es kann sich um eine leere Liste handeln.
+ `EgressIgnoredIPs` – (Erforderlich) Der ausgehende Datenverkehr zu diesen angegebenen IP-Adressen wird ignoriert und nicht an den `ProxyEgressPort` umgeleitet. Es kann sich um eine leere Liste handeln.
`name`
Typ: Zeichenfolge
Erforderlich: Nein
Der Name des Schlüssel-Wert-Paares.
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der Wert des Schlüssel-Wert-Paares.
## Datenträger
Wenn Sie eine Aufgabendefinition registrieren, können Sie optional eine Liste von Volumes angeben, die an den Docker-Daemon auf einer Container-Instance übergeben werden sollen, die dann für den Zugriff durch andere Container auf derselben Container-Instance verfügbar ist.
Im Folgenden werden die Daten-Volume-Typen aufgeführt, die verwendet werden können:
+ Amazon-EBS-Volumes – Bieten kostengünstigen, dauerhaften und leistungsstarken Blockspeicher für datenintensive containerisierte Workloads. Sie können bei der Bereitstellung 1 Amazon-EBS-Volume pro Amazon-ECS-Aufgabe anfügen, wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen oder aktualisieren. Amazon-EBS-Volumes werden für Linux-Aufgaben unterstützt, die in Fargate gehostet werden. Weitere Informationen finden Sie unter [Amazon-EBS-Volumes mit Amazon ECS verwenden](ebs-volumes.md).
+ Amazon EFS Volumes: Bietet einen einfachen, skalierbaren und persistenten Dateispeicher für die Verwendung mit Amazon-ECS-Aufgaben. Mit Amazon EFS ist die Speicherkapazität elastisch. Sie wird automatisch erweitert oder verkleinert, wenn Sie Dateien hinzufügen oder entfernen. Ihren Anwendungen steht der Speicherplatz zur Verfügung, den sie benötigen, und zwar genau dann, wenn sie ihn benötigen. Amazon-EFS-Volumes werden für Aufgaben unterstützt, die in Fargate gehostet werden. Weitere Informationen finden Sie unter [Amazon-EFS-Volumes mit Amazon ECS verwenden](efs-volumes.md).
+ FSx für Windows-Dateiserver-Volumes — Stellt vollständig verwaltete Microsoft Windows-Dateiserver bereit. Diese Dateiserver werden von einem Windows-Dateisystem unterstützt. Wenn Sie FSx for Windows File Server zusammen mit Amazon ECS verwenden, können Sie Ihre Windows-Aufgaben mit persistentem, verteiltem, gemeinsam genutztem und statischem Dateispeicher bereitstellen. Weitere Informationen finden Sie unter [FSx Für Windows-Dateiserver-Volumes mit Amazon ECS verwenden](wfsx-volumes.md).
Windows-Container auf Fargate unterstützen diese Option nicht.
+ Bind-Mounts – Eine Datei oder ein Verzeichnis auf dem Host-Computer wird in einem Container eingebunden. Bind-Mount-Host-Volumes werden unterstützt, wenn Aufgaben ausgeführt werden. Um Bind-Mount-Host-Volumes zu verwenden, geben Sie einen `host` und optionalen `sourcePath`-Wert in Ihrer Aufgabendefinition an.
Weitere Informationen finden Sie unter [Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).
Die folgenden Parameter sind in einer Containerdefinition zulässig.
`name`
Typ: Zeichenfolge
Erforderlich: Nein
Der Name des Volumes. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche (`-`) und Unterstriche (`_`) sind erlaubt. Auf diesen Namen wird im Parameter `sourceVolume` des `mountPoints`-Objekts der Container-Definition verwiesen.
`host`
Erforderlich: Nein
Der `host`-Parameter wird verwendet, um den Lebenszyklus des Bind-Mounts an die Amazon-EC2-Host-Instance und nicht an die Aufgabe zu binden und dort zu speichern. Wenn der Parameter `host` leer ist, weist der Docker-Daemon einen Host-Pfad für Ihr Daten-Volume zu, es wird aber nicht gewährleistet, dass die Daten beibehalten werden, nachdem die damit verknüpften Container nicht mehr ausgeführt werden.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden.
Der `sourcePath` Parameter wird nur unterstützt, wenn Aufgaben verwendet werden, die auf Amazon EC2-Instances oder Amazon ECS Managed Instances gehostet werden.
`sourcePath`
Typ: Zeichenfolge
Erforderlich: Nein
Wenn der Parameter `host` verwendet wird, geben Sie einen `sourcePath` an, um den Pfad auf der Amazon-EC2-Host-Instance zu deklarieren, die dem Container bereitgestellt wird. Wenn dieser Parameter leer ist, weist der Docker-Daemon einen Host-Pfad für Sie zu. Wenn der Parameter `host` den Speicherort `sourcePath` enthält, bleibt das Daten-Volume an der angegebenen Position der Amazon-EC2-Host-Instance erhalten, bis Sie es manuell löschen. Wenn der Wert `sourcePath` auf der Amazon-EC2-Host-Instance nicht vorhanden ist, wird er vom Docker-Daemon erstellt. Wenn der Speicherort nicht vorhanden ist, wird der Inhalt des Quellpfadordners exportiert.
`configuredAtLaunch`
Typ: Boolesch
Erforderlich: Nein
Gibt an, ob ein Volume beim Start konfigurierbar ist. Wenn diese Option auf `true` gesetzt ist, können Sie das Volume konfigurieren, wenn Sie eine eigenständige Aufgabe ausführen oder wenn Sie einen Service erstellen oder aktualisieren. Wenn diese Option auf `true` gesetzt ist, können Sie keine andere Volume-Konfiguration in der Aufgabendefinition angeben. Dieser Parameter muss auf `true` gesetzt werden, um ein Amazon-EBS-Volume für das Anhängen an eine Aufgabe zu konfigurieren. Wenn Sie `configuredAtLaunch` auf `true` festlegen und die Volume-Konfiguration auf die Startphase verschieben, können Sie Aufgabendefinitionen erstellen, die nicht auf einen Volume-Typ oder auf bestimmte Volume-Einstellungen beschränkt sind. Auf diese Weise können Sie Ihre Aufgabendefinition in verschiedenen Ausführungsumgebungen wiederverwenden. Weitere Informationen finden Sie unter [Amazon-EBS-Volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html).
`dockerVolumeConfiguration`
Typ: Objekt [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html)
Erforderlich: Nein
Dieser Parameter wird nur bei der Verwendung von Docker-Volumes angegeben. Docker-Volumes werden nur unterstützt, wenn Aufgaben auf EC2-Instances ausgeführt werden. Windows-Container unterstützen nur die Verwendung des `local`-Treibers. Um Bind-Mounts zu verwenden, geben Sie stattdessen einen `host` an.
`scope`
Typ: Zeichenfolge
Zulässige Werte: `task` \$1 `shared`
Erforderlich: Nein
Der Bereich für das Docker-Volume, der den Lebenszyklus bestimmt. Docker-Volumes, die auf eine `task` beschränkt sind, werden automatisch beim Starten der Aufgabe bereitgestellt und beim Stoppen dieser vernichtet. Docker-Volumes, die als `shared` angewendet werden, bleiben erhalten, nachdem die Aufgabe gestoppt wird.
`autoprovision`
Typ: Boolescher Wert
Standardwert: `false`
Erforderlich: Nein
Wenn dieser Wert `true` lautet, wird das Docker-Volume erstellt, wenn es nicht bereits vorhanden ist. Dieses Feld wird nur verwendet, wenn `scope` den Wert `shared` aufweist. Wenn `scope`-Wert `task` ist, muss dieser Parameter weggelassen werden.
`driver`
Typ: Zeichenfolge
Erforderlich: Nein
Der zu verwendende Docker-Volume-Treiber. Der Treiberwert muss mit dem von Docker bereitgestellten Treibernamen übereinstimmen, da dieser Name für die Aufgabenplatzierung verwendet wird. Wenn der Treiber mit der Docker-Plug-In-CLI installiert wurde, rufen Sie mit `docker plugin ls` den Treibernamen aus der Container-Instance ab. Wenn der Treiber mit einem anderen Verfahren installiert wurde, rufen Sie den Treibernamen mit der Docker-Plug-In-Erkennung ab.
`driverOpts`
Typ: Zeichenfolge
Erforderlich: Nein
Eine Zuordnung von Docker-Treiber-spezifischen Optionen für die Übergabe. Dieser Parameter ist im Bereich Ein Volume erstellen von Docker der Option `DriverOpts` zugeordnet.
`labels`
Typ: Zeichenfolge
Erforderlich: Nein
Benutzerdefinierte Metadaten, die Ihrem Docker-Volume hinzugefügt werden sollen.
`efsVolumeConfiguration`
Typ: [EFSVolumeKonfigurationsobjekt](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html)
Erforderlich: Nein
Dieser Parameter wird nur bei der Verwendung von Amazon EFS-Volumes angegeben.
`fileSystemId`
Typ: Zeichenfolge
Erforderlich: Ja
Die zu verwendende Amazon EFS-Dateisystem-ID.
`rootDirectory`
Typ: Zeichenfolge
Erforderlich: Nein
Das Verzeichnis im Amazon-EFS-Dateisystem, das als Stammverzeichnis im Host eingebunden werden soll. Wenn dieser Parameter weggelassen wird, wird der Stamm des Amazon EFS-Volumes verwendet. Die Angabe von `/` hat denselben Effekt wie das Weglassen dieses Parameters.
Wenn ein EFS-Zugangspunkt in `authorizationConfig` angegeben ist, muss der Stammverzeichnis-Parameter entweder weggelassen oder auf `/` festgelegt werden, was den festgelegten Pfad für den EFS-Zugangspunkt erzwingt.
`transitEncryption`
Typ: Zeichenfolge
Zulässige Werte: `ENABLED` \$1 `DISABLED`
Erforderlich: Nein
Gibt an, ob die Verschlüsselung für Amazon-EFS-Daten während der Übertragung zwischen dem Amazon-ECS-Host und dem Amazon-EFS-Server aktiviert werden soll oder nicht. Wenn die Amazon-EFS-IAM-Autorisierung verwendet wird, muss die Transit-Verschlüsselung aktiviert sein. Wenn dieser Parameter nicht angegeben ist, wird der Standardwert `DISABLED` verwendet. Weitere Informationen finden Sie unter [Verschlüsseln von Daten während der Übertragung](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) im *Benutzerhandbuch für Amazon Elastic File System*.
`transitEncryptionPort`
Typ: Ganzzahl
Erforderlich: Nein
Der zu verwendende Port zum Senden verschlüsselter Daten zwischen dem Amazon-ECS-Host und dem Amazon EFS-Server. Wenn Sie keinen Port für die Verschlüsselung bei der Übertragung angeben, verwendet die Aufgabe die Port-Auswahlstrategie, die der Amazon EFS Mount Helper verwendet. Weitere Informationen finden Sie unter [EFS-Mount-Helfer](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) im *Benutzerhandbuch für Amazon Elastic File System*.
`authorizationConfig`
Typ: [EFSAuthorizationConfig-Objekt](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html)
Erforderlich: Nein
Die Autorisierungskonfigurationsdetails für das Amazon EFS-Dateisystem.
`accessPointId`
Typ: Zeichenfolge
Erforderlich: Nein
Die zu verwendende Zugriffspunkt-ID. Wenn ein Zugriffspunkt angegeben wird, muss der Stammverzeichniswert in `efsVolumeConfiguration` ausgelassen oder auf `/` festgelegt werden, was den auf dem EFS-Zugriffspunkt festgelegten Pfad erzwingt. Wenn ein Zugriffspunkt verwendet wird, muss in `EFSVolumeConfiguration` die Transitverschlüsselung aktiviert sein. Weitere Informationen finden Sie unter [Arbeiten mit Amazon EFS-Zugriffspunkten](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) im *Amazon Elastic File System-Benutzerhandbuch*.
`iam`
Typ: Zeichenfolge
Zulässige Werte: `ENABLED` \$1 `DISABLED`
Erforderlich: Nein
Gibt an, ob die in einer Aufgabendefinition definierte Amazon-ECS-Aufgaben-IAM-Rolle beim Mounten des Amazon-EFS-Dateisystems verwendet werden soll. Wenn diese Option aktiviert ist, muss die Transit-Verschlüsselung in `EFSVolumeConfiguration` aktiviert sein. Wenn dieser Parameter nicht angegeben ist, wird der Standardwert `DISABLED` verwendet. Weitere Informationen finden Sie unter [IAM-Rollen für Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html).
`FSxWindowsFileServerVolumeConfiguration`
Typ: [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html)Objekt
Erforderlich: Ja
Dieser Parameter wird angegeben, wenn Sie ein Dateisystem von [Amazon FSx für Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) zum Speichern von Aufgaben verwenden.
`fileSystemId`
Typ: Zeichenfolge
Erforderlich: Ja
Die FSx zu verwendende Dateisystem-ID für den Windows-Dateiserver.
`rootDirectory`
Typ: Zeichenfolge
Erforderlich: Ja
Das Verzeichnis innerhalb des Dateisystems FSx für Windows File Server, das als Stammverzeichnis auf dem Host bereitgestellt werden soll.
`authorizationConfig`
`credentialsParameter`
Typ: Zeichenfolge
Erforderlich: Ja
Die Optionen für Autorisierungsanmeldeinformationen.
**Optionen:**
+ Der Amazon-Ressourcenname (ARN) eines [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)-Geheimnisses.
+ ARN eines [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html)-Parameters.
`domain`
Typ: Zeichenfolge
Erforderlich: Ja
Ein vollqualifizierter Domain-Name, der von einem [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD)-Verzeichnis oder einem selbst gehosteten EC2-Active-Directory gehostet wird.
## Tags (Markierungen)
Wenn Sie eine Aufgabendefinition registrieren, können Sie optional Metadatentags angeben, die auf die Aufgabendefinition angewendet werden. Mithilfe von Tags können Sie Ihre Aufgabendefinition kategorisieren und organisieren. Jedes Tag (Markierung) besteht aus einem Schlüssel und einem optionalen Wert. Sie können beide definieren. Weitere Informationen finden Sie unter [Markieren von Amazon-ECS-Ressourcen](ecs-using-tags.md).
**Wichtig**
Fügen Sie keine personenbezogenen Daten (Personally Identifiable Information, PII) oder andere vertrauliche Informationen in Tags hinzu. Tags sind für viele AWS Dienste zugänglich, auch für die Abrechnung. Tags sind nicht für private oder vertrauliche Daten gedacht.
Die folgenden Parameter sind in einem Tag-Objekt zulässig.
`key`
Typ: Zeichenfolge
Erforderlich: Nein
Ein Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Schlüssel ist eine allgemeine Bezeichnung, die wie eine Kategorie für spezifischere Tag-Werte fungiert.
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der optionale Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Wert fungiert als Deskriptor in einer Tag-Kategorie (Schlüssel).
## Andere Parameter der Aufgabendefinition
Die folgenden Parameter für die Aufgabendefinition können beim Registrieren von Aufgabendefinitionen in der Amazon-ECS-Konsole mit der Option **Configure via JSON (Über JSON konfigurieren)** verwendet werden. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
**Topics**
+ [Flüchtiger Speicher](#task_definition_ephemeralStorage)
+ [IPC-Modus](#task_definition_ipcmode)
+ [PID-Modus](#task_definition_pidmode)
+ [Fehlerinjektion](#task_definition_faultInjection)
### Flüchtiger Speicher
`ephemeralStorage`
Typ: [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Objekt
Erforderlich: Nein
Die Menge des flüchtigen Speichers (in GB), der für die Aufgabe zugewiesen werden soll. Dieser Parameter wird verwendet, um die Gesamtmenge des flüchtigen Speichers über den Standardbetrag hinaus für Aufgaben zu erweitern, die auf AWS Fargate gehostet werden. Weitere Informationen finden Sie unter [Bind-Mounts mit Amazon ECS verwenden](bind-mounts.md).
Dieser Parameter wird nur für Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` oder höher (Windows) unterstützt.
### IPC-Modus
`ipcMode`
Dieser Parameter wird nicht für Aufgaben unterstützt, die in Fargate ausgeführt werden.
Typ: Zeichenfolge
Erforderlich: Nein
Der IPC-Ressourcen-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind `host`, `task` oder `none`. Wenn `host` angegeben ist, dann teilen sich alle Container innerhalb der Aufgaben, die den IPC-Modus `host` auf derselben Container-Instance angegeben haben, die gleichen IPC-Ressourcen mit der Amazon EC2-Host-Instance. Wenn `task` angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe die gleichen IPC-Ressourcen. Wenn `none` angegeben ist, dann sind die IPC-Ressourcen innerhalb der Container einer Aufgabe privat und werden nicht mit anderen Containern einer Aufgabe oder der Container-Instance geteilt. Wenn kein Wert angegeben ist, hängt die gemeinsame Nutzung des IPC-Ressourcen-Namespace von der Einstellung des Docker-Daemons in der Container-Instance ab.
Wenn der IPC-Modus `host` verwendet wird, ist das Risiko einer unerwünschten Exposition des IPC-Namespace erhöht.
Wenn Sie im Namespace bezogene Kernelparameter mit `systemControls` für die Container in der Aufgabe festlegen, gilt Folgendes für Ihren IPC-Ressourcen-Namespace.
+ Für Aufgaben, die den IPC-Modus `host` verwenden, werden IPC-Namespace bezogene `systemControls` nicht unterstützt.
+ Für Aufgaben, die den IPC-Modus `task` verwenden, gelten IPC-Namespace bezogene `systemControls` für alle Container innerhalb einer Aufgabe.
**Anmerkung**
Dieser Parameter wird für Windows-Container oder -Aufgaben mit dem Starttyp Fargate nicht unterstützt.
### PID-Modus
`pidMode`
Typ: Zeichenfolge
Zulässige Werte: `host` \$1 `task`
Erforderlich: Nein
Der Prozess-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind `host` und `task`. Für Linux-Container ist `task` der einzige gültige Wert. Für die Überwachung von Beiwagen benötigt `pidMode` möglicherweise Informationen über andere Container, die in der gleichen Aufgabe laufen.
Wenn `task` angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe den gleichen Prozess-Namespace.
Wenn kein Wert angegeben wird, ist der Standard ein privater Namespace für jeden Container.
**Anmerkung**
Dieser Parameter wird nur für Aufgaben unterstützt, die auf AWS Fargate gehostet werden, wenn die Aufgaben die Plattformversion `1.4.0` oder höher (Linux) verwenden. Dies wird für Windows-Container auf Fargate nicht unterstützt.
### Fehlerinjektion
`enableFaultInjection`
Typ: Boolescher Wert
Zulässige Werte: `true` \$1 `false`
Erforderlich: Nein
Wenn dieser Parameter in den Nutzdaten einer Aufgabe auf `true` gesetzt ist, akzeptieren Amazon ECS und Fargate Fehlerinjektionsanfragen von den Containern der Aufgabe. Dieser Parameter ist standardmäßig auf `false` festgelegt.
# Amazon-ECS-Aufgabendefinitionsparameter für Amazon EC2
Aufgabendefinitionen sind in verschiedene Teile unterteilt: die Aufgabenfamilie, die AWS Identity and Access Management (IAM-) Aufgabenrolle, den Netzwerkmodus, Containerdefinitionen, Volumen, Einschränkungen bei der Aufgabenplatzierung und Kapazität. Die Familien- und Container-Definitionen sind in einer Aufgabendefinition obligatorisch. Im Gegensatz dazu sind Aufgabenrolle, Netzwerkmodus, Volumes, Aufgabenplatzierungseinschränkungen und Starttyp optional.
Sie können diese Parameter in einer JSON-Datei verwenden, um Ihre Aufgabendefinition zu konfigurieren.
Im Folgenden finden Sie weitere detaillierte Beschreibungen der einzelnen Aufgabendefinitionsparameter für Amazon EC2.
## Familie
`family`
Typ: Zeichenfolge
Erforderlich: Ja
Wenn Sie eine Aufgabendefinition registrieren, vergeben Sie eine Familie, ähnlich einem Namen für mehrere Versionen der Aufgabendefinition, die mit einer Revisionsnummer angegeben ist. Die erste Aufgabendefinition, die in einer bestimmten Familie registriert wird, erhält die Revision 1 und alle danach registrierten Definitionen erhalten eine sequenzielle Revisionsnummer.
## Capacity (Kapazität)
Wenn Sie eine Aufgabendefinition registrieren, können Sie die Kapazität angeben, anhand der Amazon ECS die Aufgabendefinition validieren soll. Eine Client-Ausnahme wird zurückgegeben, wenn die Aufgabendefinition nicht anhand der angegebenen Kompatibilitäten validiert.
Der folgende Parameter ist in einer Aufgabendefinition zulässig.
`requiresCompatibilities`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Zulässige Werte: `EC2`
Die Kapazität, anhand der die Aufgabendefinition validiert wird. Dabei wird überprüft, ob alle in der Aufgabendefinition verwendeten Parameter den Anforderungen von Amazon EC2 entsprechen.
## -Rolle für Aufgabe
`taskRoleArn`
Typ: Zeichenfolge
Erforderlich: Nein
Wenn Sie eine Aufgabendefinition registrieren, können Sie eine Aufgabenrolle für eine IAM-Rolle angeben, die es den Containern in der Aufgabe ermöglicht AWS APIs , die in den zugehörigen Richtlinien angegebenen Aufgaben in Ihrem Namen aufzurufen. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).
IAM-Rollen für Aufgaben unter Windows erfordern, dass die Option `-EnableTaskIAMRole` beim Starten des Amazon-ECS-optimierten Windows Server-AMI festgelegt ist. Ihre Container müssen außerdem bestimmten Konfigurationscode ausführen, damit dieses Feature verwendet werden kann. Weitere Informationen finden Sie unter [Zusätzliche Konfiguration der Amazon-EC2-Windows-Instances](task-iam-roles.md#windows_task_IAM_roles).
## -Rolle für die Aufgabenausführung
`executionRoleArn`
Typ: Zeichenfolge
Required: Conditional
Der Amazon-Ressourcenname (ARN) der Aufgabenausführungsrolle, die dem Amazon ECS-Container-Agenten die Erlaubnis erteilt, AWS API-Aufrufe in Ihrem Namen durchzuführen.
Die IAM-Rolle für die Aufgabenausführung ist je nach den Anforderungen Ihrer Aufgabe erforderlich. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
## Netzwerkmodus
`networkMode`
Typ: Zeichenfolge
Erforderlich: Nein
Der Docker-Netzwerkmodus, der für die Container in der Aufgabe verwendet werden soll. Für Amazon-ECS-Aufgaben, die auf Amazon-EC2-Linux-Instances gehostet werden, sind die gültigen Werte `none`, `bridge`, `awsvpc` und `host`. Wenn kein Netzwerkmodus angegeben ist, ist der Standard-Netzwerkmodus`bridge`. Für Amazon ECS-Aufgaben, die auf Amazon EC2 EC2-Windows-Instances gehostet werden, sind die gültigen Werte`default`, und`awsvpc`. Wenn kein Netzwerkmodus angegeben ist, wird der `default` Netzwerkmodus verwendet.
Wenn der Netzwerkmodus auf `none` festgelegt ist, verfügen die Container der Aufgabe über keine externe Konnektivität und Port-Zuweisungen können nicht in der Container-Definition angegeben werden.
Im Netzwerkmodus `bridge` verwendet die Aufgabe das integrierte virtuelle Netzwerk von Docker unter Linux, das innerhalb jeder Amazon EC2-Instance ausgeführt wird, die die Aufgabe hostet. Das integrierte virtuelle Netzwerk unter Linux verwendet den `bridge` Docker-Netzwerktreiber.
Im Netzwerkmodus `host` verwendet die Aufgabe das Hostnetzwerk, das das integrierte virtuelle Netzwerk von Docker umgeht, indem es Container-Ports direkt der ENI der Amazon EC2-Instance zuweist, die die Aufgabe hostet. Dynamische Portzuordnungen können in diesem Netzwerkmodus nicht verwendet werden. Ein Container in einer Aufgabendefinition, der diesen Modus verwendet, muss eine bestimmte `hostPort`-Nummer angeben. Eine Portnummer auf einem Host kann nicht für mehrere Aufgaben verwendet werden. Daher können Sie nicht mehrere Aufgaben derselben Aufgabendefinition auf einer einzelnen Amazon EC2-Instance ausführen.
Wenn Sie Aufgaben im Netzwerkmodus `host` ausführen, sollten Sie aus Sicherheitsgründen Container nicht über den Root-Benutzer (UID 0) ausführen. Verwenden Sie als bewährte Sicherheitsmethode immer einen Nicht-Root-Benutzer.
Für den Netzwerkmodus `awsvpc` wird die Aufgabe einer Elastic-Network-Schnittstelle zugeordnet und Sie müssen eine `NetworkConfiguration` angeben, wenn Sie mit der Aufgabendefinition einen Service erstellen oder eine Aufgabe ausführen wollen. Weitere Informationen finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für EC2](task-networking.md).
Im Netzwerkmodus `default` verwendet die Aufgabe das integrierte virtuelle Netzwerk von Docker unter Windows, das innerhalb jeder Amazon EC2-Instance ausgeführt wird, die die Aufgabe hostet. Das integrierte virtuelle Netzwerk unter Windows verwendet den `nat` Docker-Netzwerktreiber.
Die Netzwerkmodi `host` und `awsvpc` bieten die höchste Netzwerkleistung für Container, da sie den Amazon EC2-Netzwerkstapel verwenden. Für die Netzwerkmodi `host` und `awsvpc` sind die freigegebenen Container-Ports direkt auf den entsprechenden Host-Port (für den Netzwerkmodus `host`) oder den angehängten Elastic-Network-Schnittstellenanschluss (für den Netzwerkmodus `awsvpc`) abgebildet. Aus diesem Grund können Sie keine dynamischen Host-Port-Zuordnungen nutzen.
Der zulässige Netzwerkmodus hängt vom zugrunde liegenden EC2-Instance-Betriebssystem ab. Unter Linux können beliebige Netzwerkmodi verwendet werden. Falls Windows, können Modi `default` und `awsvpc` verwendet werden.
## Laufzeit-Plattform
`operatingSystemFamily`
Typ: Zeichenfolge
Required: Conditional
Standard: LINUX
Wenn Sie eine Aufgabendefinition anmelden, geben Sie die Betriebssystemfamilie an.
Die gültigen Werte sind `LINUX`, `WINDOWS_SERVER_2025_FULL`, `WINDOWS_SERVER_2025_CORE`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2019_FULL` und `WINDOWS_SERVER_2019_CORE`, `WINDOWS_SERVER_2016_FULL`, `WINDOWS_SERVER_2004_CORE` und `WINDOWS_SERVER_20H2_CORE`.
Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.
Wenn eine Aufgabendefinition Teil eines Services ist, muss dieser Wert mit dem `platformFamily`-Wert des Services übereinstimmen.
`cpuArchitecture`
Typ: Zeichenfolge
Required: Conditional
Wenn Sie eine Aufgabendefinition registrieren, können Sie die CPU-Architektur angeben. Die gültigen Werte sind `X86_64` und `ARM64`. Wenn Sie keinen Wert angeben, versucht Amazon ECS, Aufgaben auf der verfügbaren CPU-Architektur basierend auf der Konfiguration des Kapazitätsanbieters zu platzieren. Um sicherzustellen, dass Aufgaben auf einer bestimmten CPU-Architektur platziert werden, geben Sie `cpuArchitecture` in der Aufgabendefinition einen Wert für an.
Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.
Wenn Sie Linux-Aufgaben haben, können Sie den Wert auf `ARM64` festlegen. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads](ecs-arm64.md).
## Aufgabengröße
Wenn Sie eine Aufgabendefinition registrieren, können Sie den gesamten CPU- und Arbeitsspeicher für die Aufgabe angeben. Dies erfolgt separat von den Werten `cpu` und `memory` bei der Containerdefinition. Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, sind diese Felder optional.
**Anmerkung**
CPU- und Speicherparameter auf Aufgabenebene werden für Windows-Container ignoriert. Es wird empfohlen, für Windows-Container Ressourcen auf Container-Ebene festzulegen.
`cpu`
Typ: Zeichenfolge
Required: Conditional
Dieser Parameter wird für Windows-Container nicht unterstützt.
Das harte Limit der CPU-Einheiten, die für die Aufgabe vorhanden sind. 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. Wenn die Aufgabendefinition registriert ist, wird ein vCPU-Wert in eine Ganzzahl umgewandelt, die die CPU-Einheiten angibt.
Dies ist ein optionales Feld. Wenn in Ihrem Cluster keine registrierten Container-Instances mit den angeforderten verfügbaren CPU-Einheiten vorhanden sind, schlägt die Aufgabe fehl. Unterstützte Werte liegen zwischen `0.125` `192` v CPUs und CPUs v.
`memory`
Typ: Zeichenfolge
Required: Conditional
Dieser Parameter wird für Windows-Container nicht unterstützt.
Die harte Arbeitsspeichergrenze, die für die Aufgabe zur Verfügung steht. Sie können Speicherwerte in der Aufgabendefinition als Zeichenfolge in Mebibyte (MiB) oder Gigabyte (GB) angeben. Sie können beispielsweise einen Speicherwert entweder als `3072` in MiB oder `3 GB` in GB angeben. Wenn die Aufgabendefinition registriert ist, wird ein GB-Wert in eine Ganzzahl umgewandelt, die die MiB angibt.
Dieses Feld ist optional und ein beliebiger Wert kann verwendet werden. Wenn ein Speicherwert auf Aufgabenebene angegeben wird, ist der Speicherwert auf Container-Ebene optional. Wenn Ihr Cluster keine registrierten Container-Instances mit dem erforderlichen Arbeitsspeicher hat, schlägt die Aufgabe fehl. Sie können Ihre Ressourcennutzung maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen. Weitere Informationen finden Sie unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
## Containerdefinitionen
Wenn Sie eine Aufgabendefinition registrieren, müssen Sie eine Liste der Containerdefinitionen angeben, die an den Docker-Daemon auf einer Container-Instance übergeben werden. Die folgenden Parameter sind in einer Containerdefinition zulässig.
**Topics**
+ [Standardparameter für Containerdefinition](#standard_container_definition_params_ec2)
+ [Erweiterte Parameter für Containerdefinitionen](#advanced_container_definition_params_ec2)
+ [Andere Parameter für die Containerdefinition](#other_container_definition_params_ec2)
### Standardparameter für Containerdefinition
Die folgenden Aufgabendefinitionsparameter sind in Containerdefinitionen entweder erforderlich oder werden meistens verwendet.
**Topics**
+ [Name](#container_definition_name_ec2)
+ [Image](#container_definition_image_ec2)
+ [Arbeitsspeicher](#container_definition_memory_ec2)
+ [Port-Zuordnungen](#container_definition_portmappings_ec2)
+ [Private-Repository-Daten](#container_definition_repositoryCredentials_ec2)
#### Name
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Name eines Containers. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Zahlen, Bindestriche und Unterstriche sind zulässig. Wenn Sie mehrere Container in einer Aufgabedefinition verknüpfen, kann der `name` eines Containers in die `links` eines anderen Containers eingefügt werden. Das dient dazu, die Container zu verbinden.
#### Image
`image`
Typ: Zeichenfolge
Erforderlich: Ja
Das Image zum Starten eines Containers. Diese Zeichenfolge wird direkt an den Docker-Daemon übergeben. Images in der Docker Hub-Registrierung sind standardmäßig verfügbar. Sie können entweder mit `repository-url/image:tag` oder mit `repository-url/image@digest` auch andere Repositorys angeben. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche, Unterstriche, Doppelpunkte, Punkte und Schrägstriche sind zulässig. Dieser Parameter ist im Docker-Befehl create-container und im `IMAGE`-Parameter des Docker-Befehls run der Option `Image` zugeordnet.
+ Wenn eine neue Aufgabe gestartet wird, ruft der Amazon-ECS-Container-Agent die neueste Version des angegebenen Image und das Tag für den Container ab, der verwendet werden soll. Allerdings werden nachfolgende Aktualisierungen eines Repository-Images nicht an Aufgaben übertragen, die bereits ausgeführt werden.
+ Wenn Sie im Image-Pfad in der Aufgabendefinition kein Tag oder Digest angeben, verwendet der Amazon ECS-Container-Agent das `latest` Tag, um das angegebene Bild abzurufen.
+ Nachfolgende Aktualisierungen eines Repository-Images werden nicht an bereits ausgeführte Aufgaben weitergegeben.
+ Images in privaten Registrierungen werden unterstützt. Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
+ Images in Amazon ECR-Repositorys können entweder mit der vollständigen `registry/repository:tag`- oder der `registry/repository@digest`-Namenskonvention angegeben werden (beispielsweise `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` oder `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`).
+ Images in offiziellen Repositorys in Docker Hub verwenden einen einzelnen Namen (z. B. `ubuntu` oder `mongo`).
+ Images in anderen Repositorys in Docker Hub sind mit einem Organisationsnamen qualifiziert (z. B `amazon/amazon-ecs-agent`).
+ Image in anderen Online-Repositorys sind durch einen Domain-Namen zusätzlich qualifiziert (z. B. `quay.io/assemblyline/ubuntu`).
`versionConsistency`
Typ: Zeichenfolge
Gültige Werte: `enabled`\$1`disabled`
Erforderlich: Nein
Gibt an, ob Amazon ECS das in der Container-Definition angegebene Container-Image-Tag in einen Image-Digest auflöst. Das Standardverhalten ist `enabled`. Wenn Sie den Wert für einen Container auf `disabled` festlegen, löst Amazon ECS das Container-Image-Tag nicht in einen Digest auf und verwendet den in der Container-Definition angegebenen ursprünglichen Image-URI für die Bereitstellung. Weitere Informationen zu r Auflösung von Container-Images finden Sie unter [Container-Image-Auflösung](deployment-type-ecs.md#deployment-container-image-stability).
#### Arbeitsspeicher
`memory`
Typ: Ganzzahl
Erforderlich: Nein
Die Menge des Arbeitsspeichers (in MiB), die dem Container bereitgestellt wird. Wenn Ihr Container versucht, das hier angegebene Limit zu überschreiten, wird der Container beendet. Die gesamte Speicherkapazität, die für alle Container reserviert ist, muss niedriger sein als der Aufgabenwert `memory`, sofern angegeben. Dieser Parameter ist im Docker-Befehl create-container der Option `Memory` und die Option `--memory` ist der Docker-Ausführung zugeordnet.
Sie müssen entweder einen Speicherwert auf Aufgabenebene oder einen Speicherwert auf Container-Ebene angeben. Wenn Sie sowohl einen Wert auf Containerebene `memory` und `memoryReservation` angeben, muss der Wert `memory` größer sein als der Wert `memoryReservation`. Wenn Sie `memoryReservation` angeben, wird dieser Wert von den verfügbaren Speicherressourcen für die Container-Instance abgezogen, auf der der Container platziert ist. Andernfalls wird der Wert `memory` verwendet.
Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.
Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
`memoryReservation`
Typ: Ganzzahl
Erforderlich: Nein
Die weiche Arbeitsspeichergrenze (in MiB) für die Reservierung für den Container. Wenn der Systemspeicher strittig ist, versucht Docker den Arbeitsspeicher des Containers innerhalb der weichen Grenze zu halten. Ihr Container kann jedoch bei Bedarf mehr Speicher verwenden. Der Container kann bis zu der mit dem Parameter `memory` angegebenen harten Grenze (falls zutreffend) oder bis zum gesamten verfügbaren Speicher der Container-Instance verwendet werden, je nachdem, was zuerst eintritt. Dieser Parameter ist im Docker-Befehl create-container der Option `MemoryReservation` und die Option `--memory-reservation` ist der Docker-Ausführung zugeordnet.
Wenn kein Speicherwert auf Aufgabenebene angegeben ist, müssen Sie eine Ganzzahl ungleich Null für einen oder beide Werte von `memory` oder `memoryReservation` in einer Container-Definition angeben. Wenn Sie beide angeben, muss `memory` größer als `memoryReservation` sein. Wenn Sie `memoryReservation` angeben, wird dieser Wert von den verfügbaren Speicherressourcen für die Container-Instance abgezogen, auf der der Container platziert ist. Andernfalls wird der Wert `memory` verwendet.
Nehmen wir zum Beispiel an, dass Ihr Container normalerweise 128 MiB Arbeitsspeicher verwendet, aber gelegentlich kurzzeitig auf 256 MiB Arbeitsspeicher expandiert. Sie können einen `memoryReservation` von 128 MiB und einen festen `memory`-Grenzwert von 300 MiB festlegen. Mit dieser Konfiguration kann der Container nur 128 MiB Arbeitsspeicher von den verbleibenden Ressourcen auf der Container-Instance reservieren. Gleichzeitig ermöglicht die Konfiguration auch, dass der Container bei Bedarf mehr Speicherressourcen verwenden kann.
Dieser Parameter wird für Windows-Container nicht unterstützt.
Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.
Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
#### Port-Zuordnungen
`portMappings`
Typ: Objekt-Array
Erforderlich: Nein
Port-Zuordnungen machen die Netzwerk-Ports Ihres Containers der Außenwelt zugänglich. Dadurch können Clients auf Ihre Anwendung zugreifen. Port-Zuordnungen werden auch für die Kommunikation zwischen Containern innerhalb derselben Aufgabe verwendet.
Legen Sie für Aufgabendefinitionen, die den Netzwerkmodus `awsvpc` verwenden, nur `containerPort` fest. Der `hostPort` wird immer ignoriert, und der Container-Port wird automatisch einem zufälligen Port mit hoher Nummer auf dem Host zugeordnet.
Die Port-Zuweisungen unter Windows verwenden die Gateway-Adresse `NetNAT` und nicht `localhost`. Für Port-Zuweisungen unter Windows gibt es kein Loopback, daher können Sie auch nicht vom Host selbst auf den zugewiesenen Port eines Containers zugreifen.
Die meisten Felder dieses Parameters (inklusive `containerPort`, `hostPort`, `protocol`) werden im Docker-Befehl create-container der Option `PortBindings` zugeordnet, und die Option `--publish` wird dem Docker-Befehl run zugeordnet. Wenn der Netzwerkmodus einer Aufgabendefinition auf `host` festgelegt ist, müssen die Host-Ports entweder undefiniert sein oder mit dem Container-Port in der Port-Zuweisung übereinstimmen.
Nachdem eine Aufgabe den Status `RUNNING` erreicht hat, sind manuelle und automatische Host- und Container-Port-Zuordnungen an den folgenden Orten sichtbar:
+ Konsole: Abschnitt **Network Bindings** (Netzwerk-Bindungen) einer Container-Beschreibung für eine bestimmte Aufgabe.
+ AWS CLI: Der Abschnitt `networkBindings` der Befehlsausgabe **describe-tasks**.
+ API: `DescribeTasks`-Antwort.
+ Metadaten: Der Endpunkt der Aufgabenmetadaten.
`appProtocol`
Typ: Zeichenfolge
Erforderlich: Nein
Das Anwendungsprotokoll, das für die Portzuordnung verwendet wird. Dieser Parameter gilt nur für Service Connect. Wir empfehlen Ihnen, diesen Parameter so festzulegen, dass er mit dem von Ihrer Anwendung verwendeten Protokoll konsistent ist. Wenn Sie diesen Parameter festlegen, fügt Amazon ECS dem Service-Connect-Proxy eine protokollspezifische Verbindungsbehandlung hinzu. Wenn Sie diesen Parameter festlegen, fügt Amazon ECS protokollspezifische Telemetrie in der Amazon ECS-Konsole und hinzu. CloudWatch
Wenn Sie keinen Wert für diesen Parameter festlegen, wird TCP verwendet. Amazon ECS fügt jedoch keine protokollspezifische Telemetrie für TCP hinzu.
Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md).
Gültige Protokollwerte: `"http" | "http2" | "grpc" `
`containerPort`
Typ: Ganzzahl
Erforderlich: Ja, wenn `portMappings` verwendet werden
Die Port-Nummer auf dem Container, der an den vom Benutzer angegebenen oder automatisch zugewiesenen Host-Port gebunden ist.
Bei Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, geben Sie die verfügbaren Ports mit `containerPort` an.
Angenommen, Sie verwenden Container in einer Aufgabe mit dem EC2-Kapazitätsanbieter und geben einen Container-Port und keinen Host-Port an. Dann erhält Ihr Container automatisch einen Host-Port im flüchtigen Port-Bereich. Weitere Informationen finden Sie unter `hostPort`. Port-Zuweisungen, die auf diese Weise automatisch zugewiesen werden, werden beim Kontingent der 100 reservierten Ports für eine Container-Instance nicht mitgezählt.
`containerPortRange`
Typ: Zeichenfolge
Erforderlich: Nein
Der Portnummernbereich des Containers, der an den dynamisch zugeordneten Host-Portbereich gebunden ist.
Sie können diesen Parameter nur mithilfe der `register-task-definition`-API festlegen. Die Option ist im `portMappings`-Parameter verfügbar. Weitere Informationen finden Sie unter [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) in der *AWS Command Line Interface -Referenz*.
Die folgenden Regeln gelten, wenn Sie ein `containerPortRange` angeben :
+ Sie müssen entweder den `bridge`-Netzwerkmodus oder den `awsvpc`-Netzwerkmodus verwenden.
+ Dieser Parameter ist sowohl für Windows- als auch für Linux-Betriebssysteme verfügbar.
+ Die Container-Instance muss mindestens über Version 1.67.0 des Container-Agenten und mindestens über Version 1.67.0-1 des `ecs-init`-Pakets verfügen.
+ Sie können bis zu 100 Portbereiche für jeden Container angeben.
+ Sie geben keine `hostPortRange` an. Der Wert von `hostPortRange` ist wie folgt festgelegt:
+ Für Container in einer Aufgabe mit dem `awsvpc`-Netzwerkmodus wird `hostPort` auf denselben Wert wie `containerPort` festgelegt. Dies ist eine statische Zuordnungsstrategie.
+ Für Container in einer Aufgabe mit dem `bridge`-Netzwerkmodus findet der Amazon-ECS-Agent offene Host-Ports aus dem flüchtigen Standardbereich und übergibt sie an Docker, um sie an die Container-Ports zu binden.
+ Gültige Werte für `containerPortRange` liegen zwischen 1 and 65 535.
+ Ein Port kann nur in einer Portzuordnung für jeden Container enthalten sein.
+ Sie können keine überlappenden Portbereiche angeben.
+ Die erste Port im Bereich muss kleiner als der letzte Port im Bereich sein.
+ Docker empfiehlt, den Docker-Proxy in der Konfigurationsdatei des Docker-Daemons zu deaktivieren, wenn Sie eine große Anzahl von Ports haben.
[Weitere Informationen finden Sie in Ausgabe \$111185 unter.](https://github.com/moby/moby/issues/11185) GitHub
Informationen zum Deaktivieren des Docker-Proxy in der Docker-Daemon-Konfigurationsdatei finden Sie unter [Docker-Daemon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) im *Amazon-ECS-Entwicklerhandbuch*.
Sie können [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) aufrufen, um die `hostPortRange` anzuzeigen, bei denen es sich um die Host-Ports handelt, die an die Container-Ports gebunden sind.
Die Portbereiche sind nicht in den Amazon ECS-Aufgabenereignissen enthalten, die an gesendet werden EventBridge. Weitere Informationen finden Sie unter [Automatisieren Sie Antworten auf Amazon ECS-Fehler mit EventBridge](cloudwatch_event_stream.md).
`hostPortRange`
Typ: Zeichenfolge
Erforderlich: Nein
Der Portnummernbereich auf dem Host, der mit der Netzwerkbindung verwendet wird. Dieser wird von Docker zugewiesen und vom Amazon-ECS-Agenten bereitgestellt.
`hostPort`
Typ: Ganzzahl
Erforderlich: Nein
Die Port-Nummer auf der Container-Instance, die für Ihren Container reserviert werden soll.
Sie können einen nicht reservierten Host-Port für Ihre Container-Port-Zuordnung angeben. Dies wird als *statische* Host-Port-Zuordnung bezeichnet. Sie können den `hostPort` auch weglassen (oder auf `0` setzen), während Sie einen `containerPort` angeben. Ihr Container erhält automatisch einen Port im kurzlebigen Portbereich für Ihr Container-Instance-Betriebssystem und Ihre Docker-Version. Dies wird als *dynamische* Host-Port-Zuordnung bezeichnet.
Der standardmäßige flüchtige Port-Bereich für Docker-Version 1.6.0 und später wird in der Instance unter `/proc/sys/net/ipv4/ip_local_port_range` aufgelistet. Wenn dieser Kernel-Parameter nicht verfügbar ist, wird der standardmäßige flüchtige Port-Bereich von `49153–65535` verwendet. Versuchen Sie nicht, einen Host-Port im flüchtigen Portbereich anzugeben. Das liegt daran, dass diese für die automatische Zuweisung reserviert sind. Im Allgemeinen zählen Ports unter `32768` nicht zum flüchtigen Port-Bereich. Sie können die `ECS_DYNAMIC_HOST_PORT_RANGE` Einstellung in der ECS-Container-Agent-Konfiguration verwenden, um einen benutzerdefinierten Bereich für dynamisch zugewiesene Host-Ports anzugeben. Dies kann hilfreich sein, wenn Ihre Aufgaben aufgrund von Portkonflikten mit anderen Prozessen auf der Container-Instance nicht gestartet werden können, z. B. bei ausgehenden Verbindungen, die ebenfalls Ports aus dem kurzlebigen Portbereich verwenden. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
Die standardmäßigen reservierten Ports sind `22` für SSH, die Docker-Ports, `2375` und `2376` und der Amazon-ECS-Container-Agenten-Port `51678-51680`. Jeder Host-Port, der zuvor vom Benutzer für eine laufende Aufgabe festgelegt wurde, ist auch während der Ausführung der Aufgabe reserviert. Nach dem Beenden einer Aufgabe wird der Host-Port freigegeben. Die aktuell reservierten Ports werden unter `remainingResources` der **describe-container-instances**-Ausgabe angezeigt. Eine Container-Instance kann bis zu 100 reservierte Ports gleichzeitig haben, einschließlich der standardmäßig reservierten Ports. Automatisch zugewiesene Ports werden nicht auf das Kontingent von 100 reservierten Ports angerechnet.
`name`
Typ: Zeichenfolge
Erforderlich: Nein, erforderlich für die Konfiguration von Service Connect und VPC Lattice in einem Service
Der Name, der für die Portzuordnung verwendet wird. Dieser Parameter gilt nur für Service Connect und VPC Lattice. Dieser Parameter ist der Name, den Sie in der Service-Connect- und VPC-Lattice-Konfiguration eines Services verwenden.
Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md).
Im folgenden Beispiel werden beide erforderlichen Felder für Service Connect und VPC Lattice verwendet.
```
"portMappings": [
{
"name": string,
"containerPort": integer
}
]
```
`protocol`
Typ: Zeichenfolge
Erforderlich: Nein
Das für die Port-Zuweisung verwendete Protokoll. Gültige Werte sind `tcp` und `udp`. Der Standardwert ist `tcp`.
Nur `tcp` wird für Service Connect unterstützt. Denken Sie daran, dass `tcp` impliziert ist, wenn dieses Feld nicht festgelegt ist.
UDP-Unterstützung ist nur auf Container-Instances verfügbar, die mit Version 1.2.0 des Amazon-ECS-Container-Agenten (z. B. `amzn-ami-2015.03.c-amazon-ecs-optimized`-AMI) oder höher gestartet wurden – oder mit Container-Agenten, die auf Version 1.3.0 oder höher aktualisiert wurden. Die neueste Version für Ihren Container-Agenten finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
Verwenden Sie die folgende Syntax, um einen Host-Port anzugeben.
```
"portMappings": [
{
"containerPort": integer,
"hostPort": integer
}
...
]
```
Verwenden Sie die folgende Syntax, um einen Host-Port automatisch zuzuweisen.
```
"portMappings": [
{
"containerPort": integer
}
...
]
```
#### Private-Repository-Daten
`repositoryCredentials`
Typ: [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Objekt
Erforderlich: Nein
Die Repository-Anmeldeinformationen für die Authentifizierung bei privaten Registrierungen.
Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
`credentialsParameter`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `repositoryCredentials` verwendet werden
Der Amazon-Ressourcenname (ARN) des Secrets mit den Anmeldeinformationen für das private Repository.
Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
Wenn Sie die Amazon ECS-API verwenden AWS CLI, oder AWS SDKs, falls der geheime Schlüssel in derselben Region wie die Aufgabe existiert, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Geheimnisses verwenden. Wenn Sie den verwenden AWS-Managementkonsole, müssen Sie den vollständigen ARN des Geheimnisses angeben.
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition, welche die erforderlichen Parameter zeigt:
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
### Erweiterte Parameter für Containerdefinitionen
Die folgenden erweiterten Parameter für Container-Definitionen bieten erweiterte Funktionen für den Docker-Befehl run, der verwendet wird, um Container auf Ihren Amazon-ECS-Container-Instances zu starten.
**Topics**
+ [Neustartrichtlinie](#container_definition_restart_policy_ec2)
+ [Gesundheitscheck](#container_definition_healthcheck_ec2)
+ [Umgebung](#container_definition_environment_ec2)
+ [Netzwerkeinstellungen](#container_definition_network_ec2)
+ [Speicher und Protokollierung](#container_definition_storage_ec2)
+ [Sicherheit](#container_definition_security_ec2)
+ [Ressourcenlimits](#container_definition_limits_ec2)
+ [Docker-Bezeichnungen](#container_definition_labels_ec2)
#### Neustartrichtlinie
`restartPolicy`
Die Container-Neustart-Richtlinie und die zugehörigen Konfigurationsparameter. Wenn Sie eine Neustart-Richtlinie für einen Container aktivieren, kann Amazon ECS den Container neu starten, ohne dass die Aufgabe ersetzt werden muss. Weitere Informationen finden Sie unter [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md).
`enabled`
Typ: Boolescher Wert
Erforderlich: Ja
Gibt an, ob eine Neustart-Richtlinie für den Container aktiviert ist.
`ignoredExitCodes`
Typ: Ganzzahl-Array
Erforderlich: Nein
Eine Liste von Exit-Codes, die Amazon ECS ignoriert und nicht versucht, neu zu starten. Sie können bis zu 50 Container-Exit-Codes angeben. Standardmäßig ignoriert Amazon ECS keine Exit-Codes.
`restartAttemptPeriod`
Typ: Ganzzahl
Erforderlich: Nein
Ein Zeitraum (in Sekunden), den der Container ausgeführt werden muss, bevor ein Neustart versucht werden kann. Ein Container kann nur einmal alle `restartAttemptPeriod` Sekunden neu gestartet werden. Wenn ein Container für diesen Zeitraum nicht ausgeführt werden kann und vorzeitig beendet wird, wird er nicht neu gestartet. Sie können eine Minimum-`restartAttemptPeriod` von 60 Sekunden und eine Maximum-`restartAttemptPeriod` von 1 800 Sekunden angeben. Standardmäßig muss ein Container 300 Sekunden lang ausgeführt werden, bevor er neu gestartet werden kann.
#### Gesundheitscheck
`healthCheck`
Der Befehl für die Container-Zustandsprüfung und die zugehörigen Konfigurationsparameter für den Container. Weitere Informationen finden Sie unter [Ermitteln des Zustands von Amazon-ECS-Aufgaben mithilfe von Container-Zustandsprüfungen](healthcheck.md).
`command`
Ein Zeichenfolgen-Array, das den Befehl darstellt, den der Container ausführt, um festzustellen, ob er fehlerfrei ist. Das Zeichenfolge-Array kann mit `CMD` beginnen, um die Befehlsargumente direkt auszuführen, oder mit `CMD-SHELL`, um den Befehl mit der Standard-Shell des Containers auszuführen. Ist nichts davon angegeben, wird `CMD` verwendet.
Verwenden Sie beim Registrieren einer Aufgabendefinition in eine durch Kommas getrennte Liste von Befehlen. AWS-Managementkonsole Diese Befehle werden in eine Zeichenfolge konvertiert, nachdem die Aufgabendefinition erstellt wurde. Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.
```
CMD-SHELL, curl -f http://localhost/ || exit 1
```
Wenn Sie eine Aufgabendefinition mithilfe des AWS-Managementkonsole JSON-Bedienfelds registrieren APIs, schließen Sie die Befehlsliste mit dem oder dem in Klammern ein. AWS CLI Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.
```
[ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ]
```
Ein Beendigungscode von 0 ohne `stderr`-Ausgabe zeigt einen Erfolg an, und der Beendigungscode ungleich Null zeigt einen Fehler an.
`interval`
Der Zeitraum (in Sekunden) zwischen den Zustandsprüfungen. Sie können zwischen 5 und 300 Sekunden angeben. Der Standardwert ist 30 Sekunden.
`timeout`
Der Zeitraum (in Sekunden), der angibt, wie lange gewartet wird, bis eine Zustandsprüfung erfolgreich ist, bevor sie als fehlerhaft betrachtet wird. Sie können zwischen 2 und 60 Sekunden angeben. Der Standardwert ist 5 Sekunden.
`retries`
Die Anzahl, wie oft eine fehlgeschlagene Zustandsprüfung wiederholt wird, bevor der Container als fehlerhaft betrachtet wird. Sie können zwischen 1 und 10 Wiederholungen angeben. Der Standardwert ist drei Wiederholungsversuche.
`startPeriod`
Der optionale Übergangszeitraum, der angibt, wie lange der Container Zeit für einen Bootstrap hat, bevor fehlgeschlagene Zustandsprüfungen der maximalen Anzahl an Wiederholungen angerechnet werden. Sie können zwischen 0 und 300 Sekunden angeben. Standardmäßig ist `startPeriod` deaktiviert.
Wenn eine Zustandsprüfung innerhalb der `startPeriod` erfolgreich ist, wird die Container als fehlerfrei betrachtet und alle nachfolgenden Ausfälle werden bei der maximal zulässigen Anzahl von Wiederholungen berücksichtigt.
#### Umgebung
`cpu`
Typ: Ganzzahl
Erforderlich: Nein
Die Anzahl der physischen `cpu`-Einheiten, die der Amazon-ECS-Container-Agent für den Container reserviert. Unter Linux ist dieser Parameter im Abschnitt [Container erstellen](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) der Option `CpuShares` zugeordnet.
Sie können die Anzahl der CPU-Einheiten bestimmen, die für jeden Amazon-EC2-Instance-Typ zur Verfügung stehen. Multiplizieren Sie dazu die Anzahl von v, die für diesen Instance-Typ auf der [Amazon EC2 EC2-Instance-Detailseite CPUs](https://aws.amazon.com/ec2/instance-types/) aufgeführt sind, mit 1.024.
Linux-Container teilen sich nicht zugewiesene CPU-Einheiten mit anderen Containern auf der Container-Instance im gleichen Verhältnis wie die ihnen zugewiesene Menge. Nehmen Sie zum Beispiel an, dass Sie eine Aufgabe für einen einzelnen Container auf einer Instance mit einem Kern und 512 CPU-Einheiten für diesen Container ausführen. Außerdem ist diese Aufgabe die einzige Aufgabe, die auf der Container-Instance läuft. In diesem Beispiel kann der Container jederzeit die gesamte Menge von 1 024 CPU-Einheiten nutzen. Angenommen, Sie haben jedoch auf dieser Container-Instance eine weitere Kopie der gleichen Aufgabe gestartet. Jede Aufgabe würde bei Bedarf eine garantierte Menge von mindestens 512 CPU-Einheiten erhalten. Ebenso kann jeder Container zu einer höheren CPU-Auslastung übergehen, wenn der andere Container die verbleibende CPU nicht nutzt. Wenn jedoch beide Aufgaben die ganze Zeit 100 % aktiv sind, stünden ihnen jeweils nur 512 CPU-Einheiten zur Verfügung.
Auf Linux-Container-Instances verwendet der Docker-Daemon auf der Container-Instance den CPU-Wert, um das relative CPU-Anteilsverhältnis für die laufenden Container zu berechnen. Der kleinste gültige CPU-Freigabewert, den der Linux-Kernel zulässt, ist 2 und der maximale gültige CPU-Freigabewert, den der Linux-Kernel zulässt, ist 262 144. Der CPU-Parameter ist jedoch nicht erforderlich und Sie können CPU-Werte unter 2 und höher als 262 144 in Ihren Container-Definitionen verwenden. Bei CPU-Werten unter 2 (einschließlich 0) und höher als 262 144 variiert das Verhalten je nach Version Ihres Amazon-ECS-Container-Agenten:
+ **Agent-Versionen <= 1.1.0:** Null-CPU-Werte werden an Docker als 0 übergeben, die von Docker dann in 1 024 CPU-Anteile konvertiert werden. CPU-Werte von 1 werden an Docker als 1 übergeben, die der Linux-Kernel in zwei CPU-Freigaben konvertiert.
+ **Agent-Versionen >= 1.2.0**: Null-CPU-Werte und CPU-Werte von 1 werden an Docker als zwei CPU-Anteile übergeben.
+ **Agentenversionen >= 1.84.0:** CPU-Werte über 256 vCPUs werden als 256 an Docker übergeben, was 262 144 CPU-Anteilen entspricht.
Auf Windows-Container-Instances wird das CPU-Kontingent als absolutes Kontingent durchgesetzt. Windows-Container haben nur Zugriff auf die in der Aufgabendefinition festgelegte Menge an CPU. Ein Nullwert oder ein CPU-Wert von Null wird an Docker als `0` übergeben. Windows interpretiert diesen Wert dann als 1 % einer CPU.
Weitere Beispiele finden Sie unter [So verwaltet Amazon ECS CPU- und Arbeitsspeicher-Ressourcen](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/).
`gpu`
Typ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Objekt
Erforderlich: Nein
Die Anzahl der physischen `GPUs`, die der Amazon-ECS-Container-Agent für den Container reserviert. Die Anzahl der für alle Container in einer Aufgabe GPUs reservierten Container darf die Anzahl der verfügbaren Container auf der Container-Instance, GPUs auf der die Aufgabe gestartet wird, nicht überschreiten. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md).
Dieser Parameter wird für Windows-Container nicht unterstützt.
`Elastic Inference accelerator`
Typ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Objekt
Erforderlich: Nein
Für den `InferenceAccelerator`-Typ stimmt der `value` mit dem `deviceName` für einen `InferenceAccelerator` überein, der in einer Aufgabendefinition angegeben ist. Weitere Informationen finden Sie unter [Name des Elastic Inference Accelerators (veraltet)](task_definition_parameters.md#elastic-Inference-accelerator).
Dieser Parameter wird für Windows-Container nicht unterstützt.
`essential`
Typ: Boolesch
Erforderlich: Nein
Nehmen wir an, der `essential`-Parameter eines Containers ist als `true` gekennzeichnet und dieser Container schlägt fehl oder wird aus irgendeinem Grund beendet. Dann werden alle anderen Container beendet, die Teil der Aufgabe sind. Wenn der Parameter `essential` eines Containers als `false` gekennzeichnet ist, wirkt sich ein Ausfall dieses Containers nicht auf die anderen Container in der Aufgabe aus. Wenn dieser Parameter ausgelassen wird, wird davon ausgegangen, dass ein Container „essential“ (entscheidend) ist.
Alle Aufgaben müssen über mindestens einen entscheidenden Container verfügen. Angenommen, Sie haben eine Anwendung, die aus mehreren Containern besteht. Dann gruppieren Sie Container, die für einen gemeinsamen Zweck verwendet werden, in Komponenten und teilen die verschiedenen Komponenten in mehrere Aufgabendefinitionen auf. Weitere Informationen finden Sie unter [Entwerfen Ihrer Anwendung für Amazon ECS](application_architecture.md).
```
"essential": true|false
```
`entryPoint`
Von frühen Versionen des Amazon-ECS-Container-Agenten werden die `entryPoint`-Parameter nicht korrekt verarbeitet. Wenn Sie Probleme bei der Verwendung von `entryPoint` haben, aktualisieren Sie Ihren Container-Agenten oder geben Sie Ihre Befehle und Argumente stattdessen als `command`-Array-Objekte an.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Eintrittspunkt, der an den Container übergeben wird.
```
"entryPoint": ["string", ...]
```
`command`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Der Befehl, der an den Container übergeben wird. Dieser Parameter ist im Befehl create-container der Option `Cmd` und der `COMMAND`-Parameter ist der Docker-Ausführung zugeordnet. Wenn mehrere Argumente vorhanden sind, stellen Sie sicher, dass jedes Argument eine getrennte Zeichenfolge im Array ist.
```
"command": ["string", ...]
```
`workingDirectory`
Typ: Zeichenfolge
Erforderlich: Nein
Das Arbeitsverzeichnis, in dem Befehle im Container ausgeführt werden sollen. Dieser Parameter ordnet zu `WorkingDir` im Bereich [Erstellen eines Containers](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) der [Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) und der Option `--workdir` für die [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) zu.
```
"workingDirectory": "string"
```
`environmentFiles`
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste von Dateien, die die Umgebungsvariablen enthalten, die an einen Container übergeben werden sollen. Dieser Parameter ist im Docker-Befehl run der Option `--env-file` zugeordnet.
Wenn FIPS aktiviert ist, werden Bucket-Namen, die Punkte (.) enthalten, (zum Beispiel amzn-s3-demo-bucket1.name.example) nicht unterstützt. Punkte (.) im Bucket-Namen verhindern, dass die Aufgabe gestartet wird, da der Agent die Umgebungsvariablendatei nicht aus Amazon S3 abrufen kann.
Dies ist für Windows-Container nicht verfügbar.
Sie können bis zu 10 Umgebungsdateien angeben. Die Datei muss eine `.env` Dateierweiterung haben. Jede Zeile in einer Umgebungsdatei enthält eine Umgebungsvariable im Format `VARIABLE=VALUE`. Zeilen, die mit `#` beginnen, werden als Kommentare behandelt und ignoriert.
Wenn in der Containerdefinition einzelne Umgebungsvariablen angegeben sind, haben sie Vorrang vor den Variablen, die in einer Umgebungsdatei enthalten sind. Wenn mehrere Umgebungsdateien angegeben werden, die dieselbe Variable enthalten, werden sie von oben nach unten verarbeitet. Es wird empfohlen, eindeutige Variablennamen zu verwenden. Weitere Informationen finden Sie unter [Eine einzelne Umgebungsvariable an einen Amazon-ECS-Container übergeben](taskdef-envfiles.md).
`value`
Typ: Zeichenfolge
Erforderlich: Ja
Der Amazon-Ressourcenname (ARN) des Amazon S3-Objekts, das die Umgebungsvariablendatei enthält.
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Dateityp, der verwendet werden muss. Der einzige unterstützte Wert ist `s3`.
`environment`
Typ: Objekt-Array
Erforderlich: Nein
Die Umgebungsvariablen, die an einen Container übergeben werden. Dieser Parameter ist im Docker-Befehl create-container der Option `Env` und die Option `--env` ist der Docker-Ausführung zugeordnet.
Die Verwendung von Klartext-Umgebungsvariablen für sensitive Informationen (wie etwa Zugangsdaten) wird nicht empfohlen.
`name`
Typ: Zeichenfolge
Erforderlich: ja, wenn `environment` verwendet wird
Der Name der Umgebungsvariable.
`value`
Typ: Zeichenfolge
Erforderlich: ja, wenn `environment` verwendet wird
Der Wert der Umgebungsvariable.
```
"environment" : [
{ "name" : "string", "value" : "string" },
{ "name" : "string", "value" : "string" }
]
```
`secrets`
Typ: Objekt-Array
Erforderlich: Nein
Ein Objekt, durch das das Secret dargestellt wird, das dem Container zur Verfügung gestellt werden soll. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.
`valueFrom`
Typ: Zeichenfolge
Erforderlich: Ja
Das Geheimnis, das dem Container exponiert werden muss. Die unterstützten Werte sind entweder der vollständige Amazon Resource Name (ARN) des AWS Secrets Manager Secrets oder der vollständige ARN des Parameters im AWS Systems Manager Parameter Store.
Wenn der Systems Manager Parameter Store-Parameter oder der Secrets Manager Manager-Parameter in derselben AWS-Region Datei wie die Aufgabe, die Sie starten, vorhanden ist, können Sie entweder den vollständigen ARN oder den Namen des Secrets verwenden. Wenn der Parameter in einer anderen Region existiert, muss der volle ARN angegeben werden.
```
"secrets": [
{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}
]
```
#### Netzwerkeinstellungen
`disableNetworking`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter den Wert „true“ aufweist, ist die Netzwerkfunktion innerhalb des Containers deaktiviert.
Dieser Parameter wird nicht für Windows-Container oder Aufgaben unterstützt, die den `awsvpc`-Netzwerkmodus verwenden.
Der Standardwert ist `false`.
```
"disableNetworking": true|false
```
`links`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Über den Parameter `link` können Container miteinander kommunizieren, ohne dass Port-Zuweisungen nötig sind. Dieser Parameter wird nur unterstützt, wenn der Netzwerkmodus einer Aufgabendefinition auf `bridge` gesetzt ist. Das Konstrukt `name:internalName` ist analog zu `name:alias` in Docker-Verbindungen. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche und Unterstriche sind zulässig.
Dieser Parameter wird nicht für Windows-Container oder Aufgaben unterstützt, die den `awsvpc`-Netzwerkmodus verwenden.
Container, die sich auf derselben Container-Instance befinden, können miteinander kommunizieren, ohne dass Verbindungen oder Host-Port-Zuweisungen erforderlich sind. Die Netzwerkisolierung auf einer Container-Instance wird durch Sicherheitsgruppen und VPC-Einstellungen gesteuert.
```
"links": ["name:internalName", ...]
```
`hostname`
Typ: Zeichenfolge
Erforderlich: Nein
Der Hostname, der für Ihren Container verwendet werden soll. Dieser Parameter ist im Docker-Befehl create-container der Option `Hostname` und die Option `--hostname` ist der Docker-Ausführung zugeordnet.
Wenn Sie den Netzwerkmodus `awsvpc` verwenden, wird der Parameter `hostname` nicht unterstützt.
```
"hostname": "string"
```
`dnsServers`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Eine List der DNS-Server, die dem Container bereitgestellt werden.
Dieser Parameter wird nicht für Windows-Container oder Aufgaben unterstützt, die den `awsvpc`-Netzwerkmodus verwenden.
```
"dnsServers": ["string", ...]
```
`dnsSearchDomains`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Muster: ^[a-zA-Z0-9-.]\$10,253\$1[a-zA-Z0-9]\$1
Eine List der DNS-Such-Domains, die dem Container bereitgestellt werden. Dieser Parameter ist im Docker-Befehl create-container der Option `DnsSearch` und die Option `--dns-search` ist der Docker-Ausführung zugeordnet.
Dieser Parameter wird für Windows-Container oder -Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, nicht unterstützt.
```
"dnsSearchDomains": ["string", ...]
```
`extraHosts`
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste der Hostnamen und IP-Adresszuordnungen, die an die Datei `/etc/hosts` auf dem Container angefügt werden.
Dieser Parameter ist im Docker-Befehl create-container der Option `ExtraHosts` und die Option `--add-host` ist der Docker-Ausführung zugeordnet.
Dieser Parameter wird für Windows-Container oder -Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, nicht unterstützt.
```
"extraHosts": [
{
"hostname": "string",
"ipAddress": "string"
}
...
]
```
`hostname`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `extraHosts` verwendet werden
Der Hostname, der im Eintrag `/etc/hosts` verwendet werden soll.
`ipAddress`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `extraHosts` verwendet werden
Die IP-Adresse, die im Eintrag `/etc/hosts` verwendet werden soll.
#### Speicher und Protokollierung
`readonlyRootFilesystem`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter den Wert „true“ aufweist, erhält der Container Lesezugriff auf das Root-Dateisystem. Dieser Parameter ist im Docker-Befehl create-container der Option `ReadonlyRootfs` und die Option `--read-only` ist der Docker-Ausführung zugeordnet.
Dieser Parameter wird für Windows-Container nicht unterstützt.
Der Standardwert ist `false`.
```
"readonlyRootFilesystem": true|false
```
`mountPoints`
Typ: Objekt-Array
Erforderlich: Nein
Die Mounting-Punkte für die Daten-Volumes in Ihrem Container. Dieser Parameter ist in der create-container-Docker-API der Option `Volumes` zugeordnet und die Option `--volume` ist der Docker-Ausführung zugeordnet.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden. Windows-Container können keine Verzeichnisse auf einem anderen Laufwerk mounten, und es ist kein laufwerksübergreifender Mounting-Punkt möglich. Sie müssen Mounting-Punkte angeben, um ein Amazon-EBS-Volume direkt an eine Amazon-ECS-Aufgabe anzuhängen.
`sourceVolume`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Name des einzubindenden Volumes.
`containerPath`
Typ: Zeichenfolge
Erforderlich: Ja, wenn `mountPoints` verwendet werden
Der Pfad in dem Container, in dem das Volume eingebunden wird.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
Behalten Sie für Aufgaben, die das Windows-Betriebssystem ausführen, den Standardwert von `false` bei.
`volumesFrom`
Typ: Objekt-Array
Erforderlich: Nein
Die Daten-Volumes, die von einem anderen Container gemountet werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `VolumesFrom` und die Option `--volumes-from` ist der Docker-Ausführung zugeordnet.
`sourceContainer`
Typ: Zeichenfolge
Erforderlich: ja, wenn `volumesFrom` verwendet wird
Der Name des Containers, von dem die Volumes gemountet werden.
`readOnly`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`.
```
"volumesFrom": [
{
"sourceContainer": "string",
"readOnly": true|false
}
]
```
`logConfiguration`
Typ: [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)Objekt
Erforderlich: Nein
Die Angabe der Protokollkonfiguration für den Container.
Beispiele für Aufgabendefinitionen, die eine Protokollkonfiguration verwenden, finden Sie unter [Beispiele für Amazon-ECS-Aufgabendefinitionen](example_task_definitions.md).
Dieser Parameter ist im Docker-Befehl create-container der Option `LogConfig` und die Option `--log-driver` ist der Docker-Ausführung zugeordnet. Standardmäßig verwenden Container den gleichen Protokolltreiber wie der Docker-Daemon. Allerdings kann der Container einen anderen Protokolltreiber als der Docker-Daemon verwenden, indem Sie einen Protokolltreiber mit diesem Parameter in der Container-Definition angeben. Um für einen Container einen anderen Protokolltreiber zu verwenden, muss das Protokollsystem auf der Container-Instance (oder einem anderen Protokollserver für die Remote-Protokollierung) ordnungsgemäß konfiguriert sein.
Beachten Sie die folgenden Punkte, wenn eine Protokollkonfiguration für Ihre Container angegeben ist:
+ Amazon ECS unterstützt einen Teil der Protokolltreiber, die für den Docker-Daemon verfügbar sind.
+ Für diesen Parameter muss Ihre Docker Remote API Version 1.18 oder höher in Ihrer Container-Instance verwenden.
+ Der auf einer Container-Instance ausgeführte Amazon-ECS-Container-Agent muss die auf dieser Instance verfügbaren Protokolltreiber mit der Umgebungsvariable `ECS_AVAILABLE_LOGGING_DRIVERS` registrieren, bevor in der Instance platzierte Container diese Protokollkonfigurationsoptionen verwenden können. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
```
"logConfiguration": {
"logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens",
"options": {"string": "string"
...},
"secretOptions": [{
"name": "string",
"valueFrom": "string"
}]
}
```
`logDriver`
Typ: Zeichenfolge
Zulässige Werte: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"`
Erforderlich: ja, wenn `logConfiguration` verwendet wird
Der für den Container zu verwendende Protokolltreiber. Standardmäßig sind die zuvor aufgeführten gültigen Werte Protokolltreiber, mit denen der Amazon-ECS-Container-Agent kommunizieren kann.
Die unterstützten Protokolltreiber sind `awslogs`, `fluentd`, `gelf`, `json-file`, `journald`, `syslog`, `splunk` und `awsfirelens`.
Weitere Informationen zur Verwendung des `awslogs` Protokolltreibers in Aufgabendefinitionen zum Senden Ihrer Container-Logs an CloudWatch Logs finden Sie unter[Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md).
Weitere Informationen zur Verwendung des Protokolltreibers `awsfirelens` finden Sie unter [Routing benutzerdefinierter Protokolle](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html).
Wenn Sie einen benutzerdefinierten Treiber haben, der nicht aufgeführt ist, können Sie das Amazon ECS-Container-Agent-Projekt, das [verfügbar](https://github.com/aws/amazon-ecs-agent) ist, forken GitHub und es so anpassen, dass es mit diesem Treiber funktioniert. Wir möchten Sie bitten, uns eventuelle Änderungswünsche mitzuteilen. Allerdings unterstützen wir derzeit nicht die Ausführung modifizierter Kopien dieser Software.
Für diesen Parameter ist Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance erforderlich.
`options`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Die key/value Zuordnung der Konfigurationsoptionen, die an den Protokolltreiber gesendet werden sollen.
Die Optionen, die Sie angeben können, hängen vom Protokolltreiber ab. Zu den Optionen, die Sie angeben können, wenn Sie den `awslogs` Router zum Weiterleiten von Protokollen an Amazon verwenden, CloudWatch gehören die folgenden:
`awslogs-create-group`
Erforderlich: Nein
Geben Sie an, ob die Protokollgruppe automatisch erstellt werden soll. Wenn diese Option nicht angegeben ist, gilt standardmäßig `false`.
Ihre IAM-Richtlinie muss die `logs:CreateLogGroup`-Berechtigung umfassen, bevor Sie `awslogs-create-group` zu nutzen versuchen.
`awslogs-region`
Erforderlich: Ja
Geben Sie an AWS-Region , an `awslogs` wen der Protokolltreiber Ihre Docker-Protokolle senden soll. In Logs können Sie wählen, ob Sie alle Ihre Logs von Clustern in verschiedenen Regionen an eine einzige Region senden möchten. CloudWatch Dann sind alle an einem Standort sichtbar. Andernfalls können Sie sie nach Region aufteilen, um eine höhere Granularität zu erzielen. Vergewissern Sie sich, dass die angegebene Protokollgruppe in der Region vorhanden ist, die Sie mit dieser Option festlegen.
`awslogs-group`
Erforderlich: Ja
Sie müssen eine Protokollgruppe angeben, an die der `awslogs`-Protokolltreiber seine Protokoll-Streams sendet.
`awslogs-stream-prefix`
Erforderlich: Optional
Mit der `awslogs-stream-prefix`-Option können Sie einen Protokoll-Stream mit dem angegebenen Präfix, dem Containernamen und der ID der Amazon-ECS-Aufgabe verknüpfen, zu der der Container gehört. Wenn Sie einen Präfix mit dieser Option angeben, weist der Protokoll-Stream das folgende Format auf:
```
prefix-name/container-name/ecs-task-id
```
Wenn Sie keinen Präfix mit dieser Option angeben, wird der Protokoll-Stream nach der Container-ID benannt, die vom Docker-Daemon auf der Container-Instance zugewiesen wurde. Da es schwierig ist, Protokolle nur mit der Docker-Container-ID (die nur auf der Container-Instance verfügbar ist) zum Container zurückzuverfolgen, der sie gesendet hat, empfehlen wir, dass Sie einen Präfix mit dieser Option festlegen.
Für Amazon-ECS-Services können Sie den Servicenamen als Präfix verwenden. So können Sie Protokollstreams zu dem Service zurückverfolgen, zu dem der Container gehört, den Namen des Containers ermitteln, der sie gesendet hat, und die ID der Aufgabe, zu der der Container gehört.
Sie müssen ein Stream-Präfix für Ihre Protokolle angeben, damit Ihre Protokolle im Protokollfeld der Amazon-ECS-Konsole angezeigt werden.
`awslogs-datetime-format`
Erforderlich: Nein
Diese Option definiert einen mehrzeiliges Startmuster im `strftime`-Format von Python. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen. Die zugeordnete Zeile ist das Trennzeichen zwischen Protokollnachrichten.
Ein Beispiel für einen Anwendungsfall für die Nutzung dieses Formats ist die Ausgabenanalyse, z. B. einen Stack-Dump, der andernfalls möglicherweise mehrere Einträge protokolliert. Mit dem richtigen Muster kann es in nur einem Eintrag erfasst werden.
Weitere Informationen finden Sie unter [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format).
Sie können nicht sowohl die Optionen `awslogs-datetime-format` und `awslogs-multiline-pattern` konfigurieren.
Bei der mehrzeiligen Protokollierung wird eine regelmäßige Ausdrucksanalyse und die Übereinstimmung aller Protokollmeldungen ausgeführt. Dies kann negative Auswirkungen auf die Leistung der Protokollierung haben.
`awslogs-multiline-pattern`
Erforderlich: Nein
Diese Option definiert ein mehrzeiliges Startmuster mit einem regulären Ausdruck. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen. Die zugeordnete Zeile ist das Trennzeichen zwischen Protokollnachrichten.
Weitere Informationen finden Sie unter [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern).
Diese Option wird ignoriert, wenn `awslogs-datetime-format` ebenfalls konfiguriert ist.
Sie können nicht sowohl die Optionen `awslogs-datetime-format` und `awslogs-multiline-pattern` konfigurieren.
Bei der mehrzeiligen Protokollierung wird eine regelmäßige Ausdrucksanalyse und die Übereinstimmung aller Protokollmeldungen ausgeführt. Dies kann negative Auswirkungen auf die Leistung der Protokollierung haben.
Die folgenden Optionen gelten für alle unterstützten Protokolltreiber.
`mode`
Erforderlich: Nein
Zulässige Werte: `non-blocking` \$1 `blocking`
Diese Option definiert den Zustellungsmodus von Protokollnachrichten von dem Container an den mit `logDriver` angegebenen Protokolltreiber. Der von Ihnen gewählte Zustellungsmodus wirkt sich auf die Anwendungsverfügbarkeit aus, wenn der Protokollfluss vom Container unterbrochen wird.
Wenn Sie den `blocking`-Modus verwenden und der Protokollfluss unterbrochen wird, werden Aufrufe von Container-Code zum Schreiben in die `stdout`- und `stderr`-Streams blockiert. Der Logging-Thread der Anwendung wird daraufhin blockiert. Dies kann dazu führen, dass die Anwendung nicht mehr reagiert und die Container-Zustandsprüfung fehlschlägt.
Wenn Sie den `non-blocking`-Modus verwenden, werden die Protokolle des Containers stattdessen in einem mit der Option `max-buffer-size` konfigurierten Zwischenpuffer im Arbeitsspeicher gespeichert. Dadurch wird verhindert, dass die Anwendung nicht mehr reagiert, wenn Protokolle nicht gesendet werden können. Wir empfehlen, diesen Modus zu verwenden, wenn Sie die Verfügbarkeit des Services sicherstellen möchten und einen gewissen Protokollverlust in Kauf nehmen möchten. Weitere Informationen finden Sie unter [Verhinderung von Protokollverlusten im blockierungsfreien Modus im `awslogs`-Container-Protokolltreiber](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/).
Mithilfe der Kontoeinstellung `defaultLogDriverMode` können Sie einen Standard-`mode` für alle Container in einer bestimmten AWS-Region festlegen. Wenn Sie die `mode`-Option nicht in `logConfiguration` angeben oder die Kontoeinstellung konfigurieren, verwendet Amazon ECS standardmäßig den `non-blocking`-Modus. Weitere Informationen über die Kontoeinstellung finden Sie unter [Standard-Protokolltreibermodus](ecs-account-settings.md#default-log-driver-mode).
Wenn der `non-blocking`-Modus verwendet wird, steuert die `max-buffer-size`-Protokolloption die Größe des Puffers, der für die Zwischenspeicherung von Nachrichten verwendet wird. Stellen Sie sicher, dass Sie eine für Ihre Anwendung angemessene Puffergröße angeben. Die Gesamtmenge des auf Aufgabenebene zugewiesenen Arbeitsspeichers muss zusätzlich zum Arbeitsspeicher-Puffer des Protokolltreibers größer sein als die für alle Container zugewiesene Menge an Arbeitsspeicher.
Am 25. Juni 2025 änderte Amazon ECS den Standard-Protokolltreibermodus von `blocking` auf `non-blocking`, um der Verfügbarkeit von Aufgaben Vorrang vor der Protokollierung einzuräumen. Führen Sie einen der folgenden Schritte aus, um den `blocking`-Modus nach dieser Änderung weiter zu verwenden:
+ Stellen Sie die `mode`-Option in `logConfiguration` in der Container-Definition als `blocking` ein.
+ Stellen Sie die Kontoeinstellung `defaultLogDriverMode` auf `blocking` ein.
`max-buffer-size`
Erforderlich: Nein
Standardwert: `10 m`
Wenn der `non-blocking`-Modus verwendet wird, steuert die `max-buffer-size`-Protokolloption die Größe des Puffers, der für die Zwischenspeicherung von Nachrichten verwendet wird. Stellen Sie sicher, dass Sie eine für Ihre Anwendung angemessene Puffergröße angeben. Wenn der Puffer voll ist, können keine weiteren Protokolle gespeichert werden. Protokolle, die nicht gespeichert werden können, gehen verloren.
Um Protokolle mithilfe des `splunk`-Protokollrouters weiterzuleiten, müssen Sie ein `splunk-token` und eine `splunk-url` angeben.
Wenn Sie den `awsfirelens` Log-Router verwenden, um Logs zur Protokollspeicherung und Analyse an ein AWS-Service AWS Partner Network Oder-Ziel weiterzuleiten, können Sie die `log-driver-buffer-limit` Option so einstellen, dass die Anzahl der Log-Zeilen begrenzt wird, die im Speicher zwischengespeichert werden, bevor sie an den Log Router-Container gesendet werden. Es kann helfen, ein potenzielles Problem mit dem Verlust von Protokollen zu beheben, da ein hoher Durchsatz dazu führen könnte, dass der Speicher für Puffer innerhalb von Docker ausgeht. Weitere Informationen finden Sie unter [Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).
Andere Optionen, die Sie beim Weiterleiten von Protokollen mithilfe von `awsfirelens` angeben können, hängen vom Ziel ab. Wenn Sie Protokolle nach Amazon Data Firehose exportieren, können Sie das AWS-Region mit `region` und einen Namen für den Protokollstream mit `delivery_stream` angeben.
Wenn Sie Protokolle nach Amazon Kinesis Data Streams exportieren, können Sie eine AWS-Region mit `region` und einen Datenstrom-Namen mit `stream` angeben.
Wenn Sie Protokolle nach Amazon OpenSearch Service exportieren, können Sie Optionen wie `Name` `Host` (OpenSearch Service-Endpunkt ohne Protokoll),`Port`,`Index`,`Type`,`Aws_auth`, `Aws_region``Suppress_Type_Name`, und angeben`tls`.
Wenn Sie Protokolle nach Amazon S3 exportieren, können Sie den Bucket mit der `bucket`-Option angeben. Sie können auch `region`, `total_file_size`, `upload_timeout` und `use_put_object` als Optionen angeben.
Für diesen Parameter muss Ihre Docker Remote API Version 1.19 oder höher in Ihrer Container-Instance verwenden.
`secretOptions`
Typ: Objekt-Array
Erforderlich: Nein
Ein Objekt, welches das Secret darstellt, der an die Protokollkonfiguration übergeben werden soll. Zu den Secrets, die in der Protokollkonfiguration verwendet werden, können ein Authentifizierungs-Token, ein Zertifikat oder ein Verschlüsselungsschlüssel gehören. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
`name`
Typ: Zeichenfolge
Erforderlich: Ja
Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.
`valueFrom`
Typ: Zeichenfolge
Erforderlich: Ja
Das Geheimnis zur Bereitstellung der Protokollkonfiguration des Containers.
```
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"splunk-token": "...",
"tag": "...",
...
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "/ecs/logconfig/splunkcred"
}]
}
```
`firelensConfiguration`
Typ: [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html)Objekt
Erforderlich: Nein
Die FireLens Konfiguration für den Container. Dies wird verwendet, um einen Protokollrouter für Container-Protokolle anzugeben und zu konfigurieren. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md).
```
{
"firelensConfiguration": {
"type": "fluentd",
"options": {
"KeyName": ""
}
}
}
```
`options`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Die key/value Übersicht der Optionen, die bei der Konfiguration des Log-Routers verwendet werden sollen. Dieses Feld ist optional und kann verwendet werden, um eine benutzerdefinierte Konfigurationsdatei anzugeben oder dem Protokollereignis zusätzliche Metadaten hinzuzufügen, z. B. Aufgaben-, Aufgabendefinitions-, Cluster- und Container-Instance-Details. Wenn angegeben, ist die zu verwendende Syntax `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Weitere Informationen finden Sie unter [Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten](firelens-taskdef.md).
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Der zu verwendende Protokollrouter. Die gültigen Werte sind `fluentd` und `fluentbit`.
#### Sicherheit
Weitere Informationen zur Container-Sicherheit finden Sie unter [Bewährte Methoden für die Sicherheit von Amazon-ECS-Aufgaben und -Containern](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html).
`credentialSpecs`
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Eine Liste von ARNs in SSM oder Amazon S3 in einer Credential Spec (`CredSpec`) -Datei, die den Container für die Active Directory-Authentifizierung konfiguriert. Es wird empfohlen, diesen Parameter anstelle von `dockerSecurityOptions` zu verwenden. Die maximale Anzahl von ist 1. ARNs
Es gibt zwei Formate für jeden ARN.
credentialspecdomainless:MyARN
Sie verwenden `credentialspecdomainless:MyARN`, um `CredSpec` einen zusätzlichen Abschnitt für ein Secret in Secrets Manager bereitzustellen. Sie geben die Anmeldeinformationen für die Domain im Secret an.
Jede Aufgabe, die auf einer beliebigen Container-Instance ausgeführt wird, kann verschiedenen Domains beitreten.
Sie können dieses Format verwenden, ohne die Container-Instance mit einer Domain zu verbinden.
credentialspec:MyARN
Sie verwenden `credentialspec:MyARN`, um `CredSpec` für eine einzelne Domain bereitzustellen.
Sie müssen die Container-Instance mit der Domain verbinden, bevor Sie Aufgaben starten, die diese Aufgabendefinition verwenden.
Ersetzen Sie in beiden Formaten `MyARN` durch den ARN in SSM oder Amazon S3.
Die `credspec` muss im Secrets Manager einen ARN für ein Secret angeben, das den Benutzernamen, das Passwort und die Domain enthält, zu der eine Verbindung hergestellt werden soll. Aus Sicherheitsgründen ist die Instance bei der domainlosen Authentifizierung nicht mit der Domain verbunden. Andere Anwendungen auf der Instance können die domainlosen Anmeldeinformationen nicht verwenden. Sie können diesen Parameter verwenden, um Aufgaben auf derselben Instance auszuführen, auch wenn die Aufgaben mit verschiedenen Domains verbunden werden müssen. Weitere Informationen finden Sie unter [G MSAs für Windows-Container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) [verwenden und G MSAs für Linux-Container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html) verwenden.
`privileged`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter den Wert „true“ aufweist, erhält der Container erhöhte Berechtigungen auf der Host-Container-Instance (ähnlich wie der `root`-Benutzer). Wir raten davon ab, Container mit `privileged` auszuführen. In den meisten Fällen können Sie die genauen Berechtigungen angeben, die Sie benötigen, indem Sie die spezifischen Parameter verwenden, anstatt `privileged` zu verwenden.
Dieser Parameter ist im Docker-Befehl create-container der Option `Privileged` und die Option `--privileged` ist der Docker-Ausführung zugeordnet.
Dieser Parameter wird für Windows-Container oder -Aufgaben mit dem Starttyp Fargate nicht unterstützt.
Der Standardwert ist `false`.
```
"privileged": true|false
```
`user`
Typ: Zeichenfolge
Erforderlich: Nein
Der Benutzer, der im Container verwendet werden soll. Dieser Parameter ist im Docker-Befehl create-container der Option `User` und die Option `--user` ist der Docker-Ausführung zugeordnet.
Wenn Sie Aufgaben im Netzwerkmodus `host` ausführen, sollten Sie Container nicht über den Root-Benutzer (UID 0) ausführen. Verwenden Sie als bewährte Sicherheitsmethode immer einen Nicht-Root-Benutzer.
Sie können den `user` mit den folgenden Formaten angeben. Wenn Sie eine User Identifier (UID, Benutzerbezeichner) und Group Identifier (GID, Gruppenbezeichner) angeben, müssen Sie sie als positive Ganzzahl angeben.
+ `user`
+ `user:group`
+ `uid`
+ `uid:gid`
+ `user:gid`
+ `uid:group`
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"user": "string"
```
`dockerSecurityOptions`
Typ: Zeichenfolgen-Array
Gültige Werte: "no-new-privileges" \$1 „AppArmor:Profile“ \$1 „label:*value*" \$1 „credentials spec:“ *CredentialSpecFilePath*
Erforderlich: Nein
Eine Liste von Zeichenfolgen für die Bereitstellung benutzerdefinierter Konfigurationen für mehrere Sicherheitssysteme.
Für Linux-Aufgaben kann dieser Parameter verwendet werden, um auf benutzerdefinierte Labels für mehrschichtige Sicherheitssysteme von SELinux und AppArmor zu verweisen.
Dieser Parameter kann verwendet werden, um auf eine Anmeldeinformations-Spezifikationsdatei zu verweisen, die einen Container für die Active-Directory-Authentifizierung konfiguriert. Weitere Informationen erhalten Sie unter [Erfahren Sie, wie Sie gMSAs für EC2-Windows-Containers für Amazon ECS verwenden.](windows-gmsa.md) und [Verwendung von gMSA für EC2-Linux-Container in Amazon ECS](linux-gmsa.md).
Dieser Parameter ist im Docker-Befehl create-container der Option `SecurityOpt` und die Option `--security-opt` ist der Docker-Ausführung zugeordnet.
```
"dockerSecurityOptions": ["string", ...]
```
Der auf einer Container-Instance ausgeführte Amazon-ECS-Container-Agent muss mit der Umgebungsvariablen `ECS_SELINUX_CAPABLE=true` oder `ECS_APPARMOR_CAPABLE=true` registriert werden, bevor in der Instance platzierte Container diese Sicherheitsoptionen verwenden können. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
#### Ressourcenlimits
`ulimits`
Typ: Objekt-Array
Erforderlich: Nein
Eine Liste von `ulimit`-Werten, die für einen Container definiert werden sollen. Dieser Wert überschreibt die Standardeinstellung für das Ressourcenkontingent für das Betriebssystem. Dieser Parameter ist im Docker-Befehl create-container der Option `Ulimits` und die Option `--ulimit` ist der Docker-Ausführung zugeordnet.
Dieser Parameter erfordert Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance.
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"ulimits": [
{
"name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack",
"softLimit": integer,
"hardLimit": integer
}
...
]
```
`name`
Typ: Zeichenfolge
Zulässige Werte: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"`
Erforderlich: Ja, wenn `ulimits` verwendet werden
Der `type` des `ulimit`-Werts.
`hardLimit`
Typ: Ganzzahl
Erforderlich: Ja, wenn `ulimits` verwendet werden
Das harte Limit für den `ulimit`-Typ. Der Wert kann je nach dem `type` des `ulimit` in Byte, Sekunden oder als Anzahl angegeben werden.
`softLimit`
Typ: Ganzzahl
Erforderlich: Ja, wenn `ulimits` verwendet werden
Das weiche Limit für den `ulimit`-Typ. Der Wert kann je nach dem `type` des `ulimit` in Byte, Sekunden oder als Anzahl angegeben werden.
#### Docker-Bezeichnungen
`dockerLabels`
Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge
Erforderlich: Nein
Eine key/value Karte mit Labels, die dem Container hinzugefügt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `Labels` und die Option `--label` ist der Docker-Ausführung zugeordnet.
Dieser Parameter erfordert Version 1.18 der Docker Remote API oder höher auf Ihrer Container-Instance.
```
"dockerLabels": {"string": "string"
...}
```
### Andere Parameter für die Containerdefinition
Die folgenden Parameter für die Containerdefinition können beim Registrieren von Aufgabendefinitionen in der Amazon-ECS-Konsole mit der Option **Configure via JSON** (Über JSON konfigurieren) verwendet werden. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
**Topics**
+ [Linux-Parameter](#container_definition_linuxparameters_ec2)
+ [Container-Abhängigkeit](#container_definition_dependson_ec2)
+ [Container-Timeouts](#container_definition_timeout_ec2)
+ [Systemkontrollen](#container_definition_systemcontrols_ec2)
+ [Interactive](#container_definition_interactive_ec2)
+ [Pseudo-Terminal](#container_definition_pseudoterminal_ec2)
#### Linux-Parameter
`linuxParameters`
Typ: [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Objekt
Erforderlich: Nein
Linux-spezifische Optionen, die auf den Container angewendet werden, wie z. [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html)
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"linuxParameters": {
"capabilities": {
"add": ["string", ...],
"drop": ["string", ...]
}
}
```
`capabilities`
Typ: [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities_ec2.html) Objekt
Erforderlich: Nein
Die Linux-Funktionen für den Container, die zur von Docker bereitgestellten Standardkonfiguration hinzugefügt oder daraus entfernt werden. Weitere Informationen zu diesen Linux-Funktionen finden Sie auf der Linux-Handbuchseite [Funktionen (7)](http://man7.org/linux/man-pages/man7/capabilities.7.html).
`add`
Typ: Zeichenfolgen-Array
Zulässige Werte: `"ALL" | "AUDIT_CONTROL" | "AUDIT_READ" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"`
Erforderlich: Nein
Die Linux-Funktionen für den Container, die zu der von Docker bereitgestellten Standardkonfiguration hinzugefügt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `CapAdd` und die Option `--cap-add` ist der Docker-Ausführung zugeordnet.
`add`
Typ: Zeichenfolgen-Array
Zulässige Werte: `"SYS_PTRACE"`
Erforderlich: Nein
Die Linux-Funktionen für den Container, die zu der von Docker bereitgestellten Standardkonfiguration hinzugefügt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `CapAdd` und die Option `--cap-add` ist der Docker-Ausführung zugeordnet.
`drop`
Typ: Zeichenfolgen-Array
Zulässige Werte: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"`
Erforderlich: Nein
Die Linux-Funktionen für den Container, die aus der von Docker bereitgestellten Standardkonfiguration entfernt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `CapDrop` und die Option `--cap-drop` ist der Docker-Ausführung zugeordnet.
`devices`
Alle Host-Geräte, die dem Container zur Verfügung gestellt werden sollen. Dieser Parameter ist im Docker-Befehl create-container der Option `Devices` und die Option `--device` ist der Docker-Ausführung zugeordnet.
Typ: Array von [Device](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html)-Objekten
Erforderlich: Nein
`hostPath`
Der Gerätepfad auf der Hostcontainer-Instance.
Typ: Zeichenfolge
Erforderlich: Ja
`containerPath`
Der Pfad im Container, der dem Hostgerät verfügbar gemacht werden soll.
Typ: Zeichenfolge
Erforderlich: Nein
`permissions`
Die expliziten Berechtigungen, die dem Container für das Gerät bereitgestellt werden sollen. Standardmäßig hat der Container Berechtigungen für `read`, `write`und `mknod` auf dem Gerät.
Typ: Zeichenfolgen-Array
Zulässige Werte: `read` \$1 `write` \$1 `mknod`
`initProcessEnabled`
Führen Sie einen `init`-Prozess innerhalb des Containers aus, der Signalen weiterleitet und Prozesse aufnimmt. Dieser Parameter ist der Option `--init` für die Docker-Ausführung zugeordnet.
Für diesen Parameter muss Ihre Docker Remote API Version 1.25 oder höher in Ihrer Container-Instance verwenden.
`maxSwap`
Die Gesamtmenge des Auslagerungsspeichers (in MiB), den ein Container verwenden kann. Dieser Parameter ist in die Option `--memory-swap` zur Docker-Ausführung übersetzt, wobei der Wert die Summe aus dem Container-Speicher und dem Wert `maxSwap` ist.
Wenn als `maxSwap`-Wert `0` angegeben wird, verwendet der Container keine Auslagerung. Zulässige Werte sind `0` oder eine beliebige positive Ganzzahl. Wenn der Parameter `maxSwap` weggelassen wird, verwendet der Container die Swap-Konfiguration für die Container-Instance, auf der er ausgeführt wird. Es muss ein Wert für `maxSwap` festgelegt werden, damit der Parameter `swappiness` verwendet werden kann.
`sharedMemorySize`
Der Wert für die Größe des `/dev/shm`-Volumes (in MiB). Dieser Parameter ist der Option `--shm-size` für die Docker-Ausführung zugeordnet.
Typ: Ganzzahl
`swappiness`
Auf diese Weise können Sie diesen Parameter verwenden, um Speicherauslagerungsverhalten eines Containers zu optimieren. Ein `swappiness`-Wert von `0` führt dazu, dass kein Auslagern erfolgt, sofern nicht erforderlich. Ein `swappiness`-Wert von `100` führt dazu, dass Seiten häufig ausgelagert werden. Akzeptierte Werte sind Ganzzahlen zwischen `0` und `100`. Wenn Sie keinen Wert angeben, wird der Standardwert `60` verwendet. Darüber hinaus wird dieser Parameter ignoriert, wenn Sie keinen Wert für `maxSwap` angeben. Dieser Parameter ist der Option `--memory-swappiness` für die Docker-Ausführung zugeordnet.
Wenn Sie Aufgaben auf Amazon Linux 2023 verwenden, wird der `swappiness`-Parameter nicht unterstützt.
`tmpfs`
Der Container-Pfad, Mount-Optionen und Maximalgröße (in MB) des tmpfs-Mounts. Dieser Parameter ist der Option `--tmpfs` für die Docker-Ausführung zugeordnet.
Typ: Array von [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html)-Objekten
Erforderlich: Nein
`containerPath`
Der absolute Dateipfad, unter dem die tmpfs-Volumes gemountet werden.
Typ: Zeichenfolge
Erforderlich: Ja
`mountOptions`
Die Liste der Mount-Optionen für das tmpfs-Volume.
Typ: Zeichenfolgen-Array
Erforderlich: Nein
Zulässige Werte: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"`
`size`
Die maximale Größe (in MiB) des tmpfs-Volumes.
Typ: Ganzzahl
Erforderlich: Ja
#### Container-Abhängigkeit
`dependsOn`
Typ: Array von [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html)-Objekten
Erforderlich: Nein
Die für das Startup und Herunterfahren des Containers definierten Abhängigkeiten. Ein Container kann mehrere Abhängigkeiten enthalten. Wenn eine Abhängigkeit für das Startup und das Herunterfahren des Containers definiert ist, ist sie reserviert. Ein Beispiel finden Sie unter [Container-Abhängigkeit](example_task_definitions.md#example_task_definition-containerdependency).
Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.
Die Instances benötigen mindestens Version `1.26.0` des Container-Agents, um Container-Abhängigkeiten zu aktivieren. Wir empfehlen jedoch, die neueste Version des Container-Agents zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md). Wenn Sie das Amazon-ECS-optimierte Amazon Linux-AMI verwenden, benötigt Ihre Instance mindestens Version `1.26.0-1` des `ecs-init`-Pakets. Wenn Ihre Container-Instances mit Version `20190301` oder höher gestartet werden, enthalten sie die erforderlichen Versionen des Container-Agenten und von `ecs-init`. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md).
```
"dependsOn": [
{
"containerName": "string",
"condition": "string"
}
]
```
`containerName`
Typ: Zeichenfolge
Erforderlich: Ja
Der Container-Name, der die angegebene Bedingung erfüllen muss.
`condition`
Typ: Zeichenfolge
Erforderlich: Ja
Die Abhängigkeitsbedingung des Containers. Der folgenden Tabelle sind die verfügbaren Bedingungen und deren Verhalten zu entnehmen:
+ `START` – Diese Bedingung emuliert das heutige Verhalten von Links und Volumes. Die Bedingung überprüft, ob ein abhängiger Container gestartet wurde, bevor das Starten anderer Container zugelassen wird.
+ `COMPLETE` – Diese Bedingung überprüft, ob ein abhängiger Container vollständig ausgeführt (beendet) wurde, bevor das Starten anderer Container zugelassen wird. Dies kann für nicht benötigte Container hilfreich sein, die ein Skript ausführen und dann beendet werden. Diese Bedingung kann nicht für einen essentiellen Container festgelegt werden.
+ `SUCCESS` – Diese Bedingung ist mit `COMPLETE` identisch, erfordert aber auch, dass der Container mit dem Status `zero` beendet wird. Diese Bedingung kann nicht für einen essenziellen Container festgelegt werden.
+ `HEALTHY` – Diese Bedingung überprüft, ob der abhängige Container seine Zustandsprüfung bestanden hat, bevor das Starten anderer Container zugelassen wird. Dies setzt voraus, das für den abhängigen Container Zustandsprüfungen in der Aufgabendefinition konfiguriert wurden. Diese Bedingung wird nur beim Startup der Aufgabe bestätigt.
#### Container-Timeouts
`startTimeout`
Typ: Ganzzahl
Erforderlich: Nein
Beispielwerte: `120`
Zeitdauer (in Sekunden), die gewartet wird, bevor die Auflösung von Abhängigkeiten für einen Container aufgegeben wird.
Angenommen, Sie geben zwei Container in einer Aufgabendefinition an und `containerA` ist abhängig davon, dass `containerB` den Status `COMPLETE`, `SUCCESS` oder `HEALTHY` erreicht. Wenn ein `startTimeout`-Wert für `containerB` angegeben ist und es den gewünschten Status nicht innerhalb dieses Zeitraums erreicht, wird `containerA` nicht gestartet.
Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.
Der Höchstwert beträgt 120 Sekunden.
`stopTimeout`
Typ: Ganzzahl
Erforderlich: Nein
Beispielwerte: `120`
Dauer (in Sekunden), die gewartet werden soll, bevor der Container zwangsweise beendet wird, wenn er nicht normal beendet wird.
Wenn der `stopTimeout`-Parameter nicht angegeben ist, wird der für die Konfigurationsvariable `ECS_CONTAINER_STOP_TIMEOUT` des Amazon-ECS-Container-Agenten festgelegte Wert verwendet. Wenn weder der Parameter `stopTimeout` noch die Agent-Konfigurationsvariable `ECS_CONTAINER_STOP_TIMEOUT` festgelegt ist, werden die Standardwerte von 30 Sekunden für Linux-Container und 30 Sekunden für Windows-Container verwendet. Container-Instances benötigen zur Aktivierung eines Timeout-Wertes für das Stoppen des Containers mindestens Version 1.26.0 des Container-Agenten. Wir empfehlen jedoch, die neueste Version des Container-Agents zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md). Wenn Sie das Amazon-ECS-optimierte Amazon Linux-AMI verwenden, benötigt Ihre Instance mindestens Version 1.26.0-1 des `ecs-init`-Pakets. Wenn Ihre Container-Instances mit Version `20190301` oder höher gestartet werden, enthalten sie die erforderlichen Versionen des Container-Agenten und von `ecs-init`. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md).
#### Systemkontrollen
`systemControls`
Typ: [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Objekt
Erforderlich: Nein
Eine Liste der Namespace-Kernel-Parameter, die im Container festgelegt werden Dieser Parameter ist im Docker-Befehl create-container der Option `Sysctls` und die Option `--sysctl` ist der Docker-Ausführung zugeordnet. Beispielsweise können Sie die `net.ipv4.tcp_keepalive_time`-Einstellung konfigurieren, um Verbindungen mit einer längeren Lebensdauer aufrechtzuerhalten.
Wir empfehlen nicht, netzwerkbezogene `systemControls`-Parameter für mehrere Container in einer einzelnen Aufgabe festzulegen, die auch entweder den `awsvpc`- oder `host`-Netzwerkmodus verwendet. Dies hat die folgenden Nachteile:
+ Wenn Sie für Aufgaben mit dem Netzwerkmodus `awsvpc` `systemControls` für einen Container festlegen, werden diese auf alle Container in der Aufgabe angewendet. Wenn Sie unterschiedliche `systemControls` für mehrere Container innerhalb einer einzelnen Aufgabe festlegen, werden die `systemControls` des zuletzt gestarteten Containers für alle Container übernommen.
+ Für Aufgaben, die den Netzwerkmodus `host` verwenden, wird der Netzwerk-Namespace `systemControls` nicht unterstützt.
Wenn Sie einen IPC-Ressourcen-Namespace für die Container in der Aufgabe einrichten, gelten folgende Bedingungen für Ihre Systemsteuerungen. Weitere Informationen finden Sie unter [IPC-Modus](task_definition_parameters.md#task_definition_ipcmode).
+ Für Aufgaben, die den IPC-Modus `host` verwenden, wird der IPC-Namespace `systemControls` nicht unterstützt.
+ Für Aufgaben, die den IPC-Modus `task` verwenden, gelten die Werte des IPC-Namespace `systemControls` für alle Container innerhalb einer Aufgabe.
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"systemControls": [
{
"namespace":"string",
"value":"string"
}
]
```
`namespace`
Typ: Zeichenfolge
Erforderlich: Nein
Der Namespace-Kernel-Parameter, für den ein `value` festgelegt wird.
Gültige IPC-Namespace-Werte: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` und `Sysctls`, die mit `"fs.mqueue.*"` beginnen
Gültige Netzwerk-Namespace-Werte: `Sysctls` beginnend mit `"net.*"`
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der Wert für den Namespace-Kernel-Parameter, der in `namespace` angegeben ist.
#### Interactive
`interactive`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` ist, können Sie Container-Anwendungen bereitstellen, für die `stdin` oder `tty` zugeordnet werden muss. Dieser Parameter ist im Docker-Befehl create-container der Option `OpenStdin` und die Option `--interactive` ist der Docker-Ausführung zugeordnet.
Der Standardwert ist `false`.
#### Pseudo-Terminal
`pseudoTerminal`
Typ: Boolesch
Erforderlich: Nein
Wenn dieser Parameter `true` lautet, wird ein TTY zugeordnet. Dieser Parameter ist im Docker-Befehl create-container der Option `Tty` und die Option `--tty` ist der Docker-Ausführung zugeordnet.
Der Standardwert ist `false`.
## Name des Elastic Inference Accelerators (veraltet)
Die Ressourcenanforderung des Elastic-Inference-Beschleunigers für Ihre Aufgabendefinition.
**Anmerkung**
Amazon Elastic Inference (EI) ist für Kunden nicht mehr verfügbar.
Die folgenden Parameter sind in einer Aufgabendefinition zulässig:
`deviceName`
Typ: Zeichenfolge
Erforderlich: Ja
Der Gerätename des Elastic Inference-Beschleunigers. Der `deviceName` muss auch in einer Containerdefinition referenziert werden, siehe [Elastic Inference accelerator](task_definition_parameters.md#ContainerDefinition-elastic-inference).
`deviceType`
Typ: Zeichenfolge
Erforderlich: Ja
Der zu verwendende Elastic-Inference-Beschleuniger.
## Aufgabenplatzierungbedingungen
Wenn Sie eine Aufgabendefinition registrieren, können Sie Aufgabenplatzierungsbedingungen angeben, die festlegen, wie Amazon-ECS-Aufgaben platziert.
Sie können Einschränkungen verwenden, um Aufgaben basierend auf der Availability Zone, dem Instance-Typ oder benutzerdefinierten Attributen zu platzieren. Weitere Informationen finden Sie unter [Definieren der Container-Instances, die Amazon ECS für Aufgaben verwendet](task-placement-constraints.md).
Die folgenden Parameter sind in einer Containerdefinition zulässig:
`expression`
Typ: Zeichenfolge
Erforderlich: Nein
Ein Ausdruck in Cluster-Abfragesprache, der auf die Einschränkung anzuwenden ist. Weitere Informationen finden Sie unter [Ausdrücke erstellen, um Container-Instances für Amazon-ECS-Aufgaben zu definieren](cluster-query-language.md).
`type`
Typ: Zeichenfolge
Erforderlich: Ja
Der Typ der Einschränkung. Verwenden Sie `memberOf`, um die Auswahl auf eine Gruppe gültiger Kandidaten zu beschränken.
## Proxykonfiguration
`proxyConfiguration`
Typ: [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Objekt
Erforderlich: Nein
Die Konfigurationsdetails für den App Mesh-Proxy.
Für Aufgaben, die EC2 verwenden, benötigen die Container-Instances mindestens Version 1.26.0 des Container-Agenten und mindestens Version 1.26.0-1 des `ecs-init`-Pakets zum Aktivieren einer Proxy-Konfiguration. Wenn Ihre Container-Instances über die Amazon-ECS-optimierte AMI-Version `20190301` oder höher gestartet werden, enthalten sie die erforderlichen Versionen des Container-Agenten und von `ecs-init`. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md).
Dieser Parameter wird für Windows-Container nicht unterstützt.
```
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "string",
"properties": [
{
"name": "string",
"value": "string"
}
]
}
```
`type`
Typ: Zeichenfolge
Gültige Werte: `APPMESH`
Erforderlich: Nein
Der Proxy-Typ. Der einzige unterstützte Wert ist `APPMESH`.
`containerName`
Typ: Zeichenfolge
Erforderlich: Ja
Der Name des Containers, der als App Mesh-Proxy dient.
`properties`
Typ: Array von [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html)-Objekten
Erforderlich: Nein
Der dem Container Network Interface (CNI)-Plug-In bereitzustellende Satz von Netzwerkkonfigurationsparametern, die als Schlüssel-Wert-Paare angegeben werden.
+ `IgnoredUID` – (Erforderlich) Die Benutzer-ID (UID) des Proxy-Containers gemäß der Definition durch den `user`-Parameter in einer Containerdefinition. Dadurch wird sichergestellt, dass der Proxy eigenen Datenverkehr ignoriert. Wenn `IgnoredGID` angegeben wird, kann dieses Feld leer sein.
+ `IgnoredGID` – (Erforderlich) Die Gruppen-ID (GID) des Proxy-Containers gemäß der Definition durch den `user`-Parameter in einer Containerdefinition. Dadurch wird sichergestellt, dass der Proxy eigenen Datenverkehr ignoriert. Wenn `IgnoredUID` angegeben wird, kann dieses Feld leer sein.
+ `AppPorts` – (Erforderlich) Die Liste der Ports, welche die Anwendung verwendet. Der Netzwerkdatenverkehr zu diesen Ports wird an den `ProxyIngressPort` und den `ProxyEgressPort` weitergeleitet.
+ `ProxyIngressPort` – (Erforderlich) Gibt den Port an, an den eingehender Datenverkehr zu den `AppPorts` geleitet wird.
+ `ProxyEgressPort` – (Erforderlich) Gibt den Port an, an den ausgehender Datenverkehr zu den `AppPorts` geleitet wird.
+ `EgressIgnoredPorts` – (Erforderlich) Der ausgehende Datenverkehr zu diesen angegebenen Ports wird ignoriert und nicht an den `ProxyEgressPort` umgeleitet. Es kann sich um eine leere Liste handeln.
+ `EgressIgnoredIPs` – (Erforderlich) Der ausgehende Datenverkehr zu diesen angegebenen IP-Adressen wird ignoriert und nicht an den `ProxyEgressPort` umgeleitet. Es kann sich um eine leere Liste handeln.
`name`
Typ: Zeichenfolge
Erforderlich: Nein
Der Name des Schlüssel-Wert-Paares.
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der Wert des Schlüssel-Wert-Paares.
## Datenträger
Wenn Sie eine Aufgabendefinition registrieren, können Sie optional eine Liste von Volumes angeben, die an den Docker-Daemon auf einer Container-Instance übergeben werden sollen, die dann für den Zugriff durch andere Container auf derselben Container-Instance verfügbar ist.
Im Folgenden werden die Daten-Volume-Typen aufgeführt, die verwendet werden können:
+ Amazon-EBS-Volumes – Bieten kostengünstigen, dauerhaften und leistungsstarken Blockspeicher für datenintensive containerisierte Workloads. Sie können bei der Bereitstellung 1 Amazon-EBS-Volume pro Amazon-ECS-Aufgabe anfügen, wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen oder aktualisieren. Amazon-EBS-Volumes werden für Linux-Aufgaben unterstützt. Weitere Informationen finden Sie unter [Amazon-EBS-Volumes mit Amazon ECS verwenden](ebs-volumes.md).
+ Amazon EFS Volumes: Bietet einen einfachen, skalierbaren und persistenten Dateispeicher für die Verwendung mit Amazon-ECS-Aufgaben. Mit Amazon EFS ist die Speicherkapazität elastisch. Sie wird automatisch erweitert oder verkleinert, wenn Sie Dateien hinzufügen oder entfernen. Ihren Anwendungen steht der Speicherplatz zur Verfügung, den sie benötigen, und zwar genau dann, wenn sie ihn benötigen. Amazon-EFS-Volumes werden unterstützt. Weitere Informationen finden Sie unter [Amazon-EFS-Volumes mit Amazon ECS verwenden](efs-volumes.md).
+ FSx für Windows-Dateiserver-Volumes — Stellt vollständig verwaltete Microsoft Windows-Dateiserver bereit. Diese Dateiserver werden von einem Windows-Dateisystem unterstützt. Wenn Sie FSx for Windows File Server zusammen mit Amazon ECS verwenden, können Sie Ihre Windows-Aufgaben mit persistentem, verteiltem, gemeinsam genutztem und statischem Dateispeicher bereitstellen. Weitere Informationen finden Sie unter [FSx Für Windows-Dateiserver-Volumes mit Amazon ECS verwenden](wfsx-volumes.md).
Windows-Container auf Fargate unterstützen diese Option nicht.
+ Docker-Volumes – Ein Docker-verwaltetes Volume, das unter `/var/lib/docker/volumes` auf der Amazon-EC2-Host-Instance erstellt wird. Docker-Volumetreiber (auch als Plugins bezeichnet) werden verwendet, um die Volumes in externe Speichersysteme wie Amazon EBS zu integrieren. Sie können den integrierten `local`-Volume-Treiber oder den Volume-Treiber eines Drittanbieters verwenden. Docker-Volumes werden nur unterstützt, wenn Aufgaben auf Amazon-EC2-Instances ausgeführt werden. Windows-Container unterstützen nur die Verwendung des `local`-Treibers. Um Docker-Volumes zu verwenden, geben Sie eine `dockerVolumeConfiguration` in Ihrer Aufgabendefinition an.
+ Bind-Mounts – Eine Datei oder ein Verzeichnis auf dem Host-Computer wird in einem Container eingebunden. Bind-Mount-Host-Volumes werden unterstützt. Um Bind-Mount-Host-Volumes zu verwenden, geben Sie einen `host` und optionalen `sourcePath`-Wert in Ihrer Aufgabendefinition an.
Weitere Informationen finden Sie unter [Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).
Die folgenden Parameter sind in einer Containerdefinition zulässig.
`name`
Typ: Zeichenfolge
Erforderlich: Nein
Der Name des Volumes. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche (`-`) und Unterstriche (`_`) sind erlaubt. Auf diesen Namen wird im Parameter `sourceVolume` des `mountPoints`-Objekts der Container-Definition verwiesen.
`host`
Erforderlich: Nein
Der `host`-Parameter wird verwendet, um den Lebenszyklus des Bind-Mounts an die Amazon-EC2-Host-Instance und nicht an die Aufgabe zu binden und dort zu speichern. Wenn der Parameter `host` leer ist, weist der Docker-Daemon einen Host-Pfad für Ihr Daten-Volume zu, es wird aber nicht gewährleistet, dass die Daten beibehalten werden, nachdem die damit verknüpften Container nicht mehr ausgeführt werden.
Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden.
Der `sourcePath` Parameter wird nur unterstützt, wenn Aufgaben verwendet werden, die auf Amazon EC2-Instances oder Amazon ECS Managed Instances gehostet werden.
`sourcePath`
Typ: Zeichenfolge
Erforderlich: Nein
Wenn der Parameter `host` verwendet wird, geben Sie einen `sourcePath` an, um den Pfad auf der Amazon-EC2-Host-Instance zu deklarieren, die dem Container bereitgestellt wird. Wenn dieser Parameter leer ist, weist der Docker-Daemon einen Host-Pfad für Sie zu. Wenn der Parameter `host` den Speicherort `sourcePath` enthält, bleibt das Daten-Volume an der angegebenen Position der Amazon-EC2-Host-Instance erhalten, bis Sie es manuell löschen. Wenn der Wert `sourcePath` auf der Amazon-EC2-Host-Instance nicht vorhanden ist, wird er vom Docker-Daemon erstellt. Wenn der Speicherort nicht vorhanden ist, wird der Inhalt des Quellpfadordners exportiert.
`configuredAtLaunch`
Typ: Boolesch
Erforderlich: Nein
Gibt an, ob ein Volume beim Start konfigurierbar ist. Wenn diese Option auf `true` gesetzt ist, können Sie das Volume konfigurieren, wenn Sie eine eigenständige Aufgabe ausführen oder wenn Sie einen Service erstellen oder aktualisieren. Wenn diese Option auf `true` gesetzt ist, können Sie keine andere Volume-Konfiguration in der Aufgabendefinition angeben. Dieser Parameter muss auf `true` gesetzt werden, um ein Amazon-EBS-Volume für das Anhängen an eine Aufgabe zu konfigurieren. Wenn Sie `configuredAtLaunch` auf `true` festlegen und die Volume-Konfiguration auf die Startphase verschieben, können Sie Aufgabendefinitionen erstellen, die nicht auf einen Volume-Typ oder auf bestimmte Volume-Einstellungen beschränkt sind. Auf diese Weise können Sie Ihre Aufgabendefinition in verschiedenen Ausführungsumgebungen wiederverwenden. Weitere Informationen finden Sie unter [Amazon-EBS-Volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html).
`dockerVolumeConfiguration`
Typ: Objekt [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html)
Erforderlich: Nein
Dieser Parameter wird nur bei der Verwendung von Docker-Volumes angegeben. Docker-Volumes werden nur unterstützt, wenn Aufgaben auf EC2-Instances ausgeführt werden. Windows-Container unterstützen nur die Verwendung des `local`-Treibers. Um Bind-Mounts zu verwenden, geben Sie stattdessen einen `host` an.
`scope`
Typ: Zeichenfolge
Zulässige Werte: `task` \$1 `shared`
Erforderlich: Nein
Der Bereich für das Docker-Volume, der den Lebenszyklus bestimmt. Docker-Volumes, die auf eine `task` beschränkt sind, werden automatisch beim Starten der Aufgabe bereitgestellt und beim Stoppen dieser vernichtet. Docker-Volumes, die als `shared` angewendet werden, bleiben erhalten, nachdem die Aufgabe gestoppt wird.
`autoprovision`
Typ: Boolescher Wert
Standardwert: `false`
Erforderlich: Nein
Wenn dieser Wert `true` lautet, wird das Docker-Volume erstellt, wenn es nicht bereits vorhanden ist. Dieses Feld wird nur verwendet, wenn `scope` den Wert `shared` aufweist. Wenn `scope`-Wert `task` ist, muss dieser Parameter weggelassen werden.
`driver`
Typ: Zeichenfolge
Erforderlich: Nein
Der zu verwendende Docker-Volume-Treiber. Der Treiberwert muss mit dem von Docker bereitgestellten Treibernamen übereinstimmen, da dieser Name für die Aufgabenplatzierung verwendet wird. Wenn der Treiber mit der Docker-Plug-In-CLI installiert wurde, rufen Sie mit `docker plugin ls` den Treibernamen aus der Container-Instance ab. Wenn der Treiber mit einem anderen Verfahren installiert wurde, rufen Sie den Treibernamen mit der Docker-Plug-In-Erkennung ab.
`driverOpts`
Typ: Zeichenfolge
Erforderlich: Nein
Eine Zuordnung von Docker-Treiber-spezifischen Optionen für die Übergabe. Dieser Parameter ist im Bereich Ein Volume erstellen von Docker der Option `DriverOpts` zugeordnet.
`labels`
Typ: Zeichenfolge
Erforderlich: Nein
Benutzerdefinierte Metadaten, die Ihrem Docker-Volume hinzugefügt werden sollen.
`efsVolumeConfiguration`
Typ: [EFSVolumeKonfigurationsobjekt](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html)
Erforderlich: Nein
Dieser Parameter wird nur bei der Verwendung von Amazon EFS-Volumes angegeben.
`fileSystemId`
Typ: Zeichenfolge
Erforderlich: Ja
Die zu verwendende Amazon EFS-Dateisystem-ID.
`rootDirectory`
Typ: Zeichenfolge
Erforderlich: Nein
Das Verzeichnis im Amazon-EFS-Dateisystem, das als Stammverzeichnis im Host eingebunden werden soll. Wenn dieser Parameter weggelassen wird, wird der Stamm des Amazon EFS-Volumes verwendet. Die Angabe von `/` hat denselben Effekt wie das Weglassen dieses Parameters.
Wenn ein EFS-Zugangspunkt in `authorizationConfig` angegeben ist, muss der Stammverzeichnis-Parameter entweder weggelassen oder auf `/` festgelegt werden, was den festgelegten Pfad für den EFS-Zugangspunkt erzwingt.
`transitEncryption`
Typ: Zeichenfolge
Zulässige Werte: `ENABLED` \$1 `DISABLED`
Erforderlich: Nein
Gibt an, ob die Verschlüsselung für Amazon-EFS-Daten während der Übertragung zwischen dem Amazon-ECS-Host und dem Amazon-EFS-Server aktiviert werden soll oder nicht. Wenn die Amazon-EFS-IAM-Autorisierung verwendet wird, muss die Transit-Verschlüsselung aktiviert sein. Wenn dieser Parameter nicht angegeben ist, wird der Standardwert `DISABLED` verwendet. Weitere Informationen finden Sie unter [Verschlüsseln von Daten während der Übertragung](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) im *Benutzerhandbuch für Amazon Elastic File System*.
`transitEncryptionPort`
Typ: Ganzzahl
Erforderlich: Nein
Der zu verwendende Port zum Senden verschlüsselter Daten zwischen dem Amazon-ECS-Host und dem Amazon EFS-Server. Wenn Sie keinen Port für die Verschlüsselung bei der Übertragung angeben, verwendet die Aufgabe die Port-Auswahlstrategie, die der Amazon EFS Mount Helper verwendet. Weitere Informationen finden Sie unter [EFS-Mount-Helfer](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) im *Benutzerhandbuch für Amazon Elastic File System*.
`authorizationConfig`
Typ: [EFSAuthorizationConfig-Objekt](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html)
Erforderlich: Nein
Die Autorisierungskonfigurationsdetails für das Amazon EFS-Dateisystem.
`accessPointId`
Typ: Zeichenfolge
Erforderlich: Nein
Die zu verwendende Zugriffspunkt-ID. Wenn ein Zugriffspunkt angegeben wird, muss der Stammverzeichniswert in `efsVolumeConfiguration` ausgelassen oder auf `/` festgelegt werden, was den auf dem EFS-Zugriffspunkt festgelegten Pfad erzwingt. Wenn ein Zugriffspunkt verwendet wird, muss in `EFSVolumeConfiguration` die Transitverschlüsselung aktiviert sein. Weitere Informationen finden Sie unter [Arbeiten mit Amazon EFS-Zugriffspunkten](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) im *Amazon Elastic File System-Benutzerhandbuch*.
`iam`
Typ: Zeichenfolge
Zulässige Werte: `ENABLED` \$1 `DISABLED`
Erforderlich: Nein
Gibt an, ob die in einer Aufgabendefinition definierte Amazon-ECS-Aufgaben-IAM-Rolle beim Mounten des Amazon-EFS-Dateisystems verwendet werden soll. Wenn diese Option aktiviert ist, muss die Transit-Verschlüsselung in `EFSVolumeConfiguration` aktiviert sein. Wenn dieser Parameter nicht angegeben ist, wird der Standardwert `DISABLED` verwendet. Weitere Informationen finden Sie unter [IAM-Rollen für Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html).
`FSxWindowsFileServerVolumeConfiguration`
Typ: [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html)Objekt
Erforderlich: Ja
Dieser Parameter wird angegeben, wenn Sie ein Dateisystem von [Amazon FSx für Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) zum Speichern von Aufgaben verwenden.
`fileSystemId`
Typ: Zeichenfolge
Erforderlich: Ja
Die FSx zu verwendende Dateisystem-ID für den Windows-Dateiserver.
`rootDirectory`
Typ: Zeichenfolge
Erforderlich: Ja
Das Verzeichnis innerhalb des Dateisystems FSx für Windows File Server, das als Stammverzeichnis auf dem Host bereitgestellt werden soll.
`authorizationConfig`
`credentialsParameter`
Typ: Zeichenfolge
Erforderlich: Ja
Die Optionen für Autorisierungsanmeldeinformationen.
**Optionen:**
+ Der Amazon-Ressourcenname (ARN) eines [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)-Geheimnisses.
+ ARN eines [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html)-Parameters.
`domain`
Typ: Zeichenfolge
Erforderlich: Ja
Ein vollqualifizierter Domain-Name, der von einem [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD)-Verzeichnis oder einem selbst gehosteten EC2-Active-Directory gehostet wird.
## Tags (Markierungen)
Wenn Sie eine Aufgabendefinition registrieren, können Sie optional Metadatentags angeben, die auf die Aufgabendefinition angewendet werden. Mithilfe von Tags können Sie Ihre Aufgabendefinition kategorisieren und organisieren. Jedes Tag (Markierung) besteht aus einem Schlüssel und einem optionalen Wert. Sie können beide definieren. Weitere Informationen finden Sie unter [Markieren von Amazon-ECS-Ressourcen](ecs-using-tags.md).
**Wichtig**
Fügen Sie keine personenbezogenen Daten (Personally Identifiable Information, PII) oder andere vertrauliche Informationen in Tags hinzu. Tags sind für viele AWS Dienste zugänglich, auch für die Abrechnung. Tags sind nicht für private oder vertrauliche Daten gedacht.
Die folgenden Parameter sind in einem Tag-Objekt zulässig.
`key`
Typ: Zeichenfolge
Erforderlich: Nein
Ein Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Schlüssel ist eine allgemeine Bezeichnung, die wie eine Kategorie für spezifischere Tag-Werte fungiert.
`value`
Typ: Zeichenfolge
Erforderlich: Nein
Der optionale Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Wert fungiert als Deskriptor in einer Tag-Kategorie (Schlüssel).
## Andere Parameter der Aufgabendefinition
Die folgenden Parameter für die Aufgabendefinition können beim Registrieren von Aufgabendefinitionen in der Amazon-ECS-Konsole mit der Option **Configure via JSON (Über JSON konfigurieren)** verwendet werden. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
**Topics**
+ [IPC-Modus](#task_definition_ipcmode_ec2)
+ [PID-Modus](#task_definition_pidmode_ec2)
+ [Fehlerinjektion](#task_definition_faultInjection_ec2)
### IPC-Modus
`ipcMode`
Typ: Zeichenfolge
Erforderlich: Nein
Der IPC-Ressourcen-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind `host`, `task` oder `none`. Wenn `host` angegeben ist, dann teilen sich alle Container innerhalb der Aufgaben, die den IPC-Modus `host` auf derselben Container-Instance angegeben haben, die gleichen IPC-Ressourcen mit der Amazon EC2-Host-Instance. Wenn `task` angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe die gleichen IPC-Ressourcen. Wenn `none` angegeben ist, dann sind die IPC-Ressourcen innerhalb der Container einer Aufgabe privat und werden nicht mit anderen Containern einer Aufgabe oder der Container-Instance geteilt. Wenn kein Wert angegeben ist, hängt die gemeinsame Nutzung des IPC-Ressourcen-Namespace von der Einstellung des Docker-Daemons in der Container-Instance ab.
Wenn der IPC-Modus `host` verwendet wird, ist das Risiko einer unerwünschten Exposition des IPC-Namespace erhöht.
Wenn Sie im Namespace bezogene Kernelparameter mit `systemControls` für die Container in der Aufgabe festlegen, gilt Folgendes für Ihren IPC-Ressourcen-Namespace.
+ Für Aufgaben, die den IPC-Modus `host` verwenden, werden IPC-Namespace bezogene `systemControls` nicht unterstützt.
+ Für Aufgaben, die den IPC-Modus `task` verwenden, gelten IPC-Namespace bezogene `systemControls` für alle Container innerhalb einer Aufgabe.
### PID-Modus
`pidMode`
Typ: Zeichenfolge
Zulässige Werte: `host` \$1 `task`
Erforderlich: Nein
Der Prozess-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind `host` und `task`. Für die Überwachung von Beiwagen benötigt `pidMode` möglicherweise Informationen über andere Container, die in der gleichen Aufgabe laufen.
Wenn `host` angegeben ist, teilen sich alle Container innerhalb der Aufgaben, die den PID-Modus `host` auf derselben Container-Instance angegeben haben, denselben Prozess-Namespace mit der Amazon EC2-Host-Instance.
Wenn `task` angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe den gleichen Prozess-Namespace.
Wenn kein Wert angegeben wird, ist der Standard ein privater Namespace für jeden Container.
Wenn der PID-Modus `host` verwendet wird, ist das Risiko einer unerwünschten Exposition des Prozess-Namespace erhöht.
**Anmerkung**
Dieser Parameter wird für Windows-Container nicht unterstützt.
### Fehlerinjektion
`enableFaultInjection`
Typ: Boolescher Wert
Zulässige Werte: `true` \$1 `false`
Erforderlich: Nein
Wenn dieser Parameter in den Nutzdaten einer Aufgabe auf `true` gesetzt ist, akzeptiert Amazon ECS Fehlerinjektionsanfragen von den Containern der Aufgabe. Dieser Parameter ist standardmäßig auf `false` festgelegt.
# Amazon-ECS-Aufgabendefinitionsvorlage
Nachfolgend wird eine leere Aufgabendefinitionsvorlage gezeigt. Sie können diese Vorlage verwenden, um Ihre Aufgabendefinition zu erstellen, die dann in den JSON-Eingabebereich der Konsole eingefügt oder in einer Datei gespeichert und mit der AWS CLI `--cli-input-json` Option verwendet werden kann. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionsparameter für Fargate](task_definition_parameters.md).
**EC2-Vorlage**
```
{
"family": "",
"taskRoleArn": "",
"executionRoleArn": "",
"networkMode": "none",
"containerDefinitions": [
{
"name": "",
"image": "",
"repositoryCredentials": {
"credentialsParameter": ""
},
"cpu": 0,
"memory": 0,
"memoryReservation": 0,
"links": [""],
"portMappings": [
{
"containerPort": 0,
"hostPort": 0,
"protocol": "tcp"
}
],
"restartPolicy": {
"enabled": true,
"ignoredExitCodes": [0],
"restartAttemptPeriod": 180
},
"essential": true,
"entryPoint": [""],
"command": [""],
"environment": [
{
"name": "",
"value": ""
}
],
"environmentFiles": [
{
"value": "",
"type": "s3"
}
],
"mountPoints": [
{
"sourceVolume": "",
"containerPath": "",
"readOnly": true
}
],
"volumesFrom": [
{
"sourceContainer": "",
"readOnly": true
}
],
"linuxParameters": {
"capabilities": {
"add": [""],
"drop": [""]
},
"devices": [
{
"hostPath": "",
"containerPath": "",
"permissions": ["read"]
}
],
"initProcessEnabled": true,
"sharedMemorySize": 0,
"tmpfs": [
{
"containerPath": "",
"size": 0,
"mountOptions": [""]
}
],
"maxSwap": 0,
"swappiness": 0
},
"secrets": [
{
"name": "",
"valueFrom": ""
}
],
"dependsOn": [
{
"containerName": "",
"condition": "COMPLETE"
}
],
"startTimeout": 0,
"stopTimeout": 0,
"hostname": "",
"user": "",
"workingDirectory": "",
"disableNetworking": true,
"privileged": true,
"readonlyRootFilesystem": true,
"dnsServers": [""],
"dnsSearchDomains": [""],
"extraHosts": [
{
"hostname": "",
"ipAddress": ""
}
],
"dockerSecurityOptions": [""],
"interactive": true,
"pseudoTerminal": true,
"dockerLabels": {
"KeyName": ""
},
"ulimits": [
{
"name": "nofile",
"softLimit": 0,
"hardLimit": 0
}
],
"logConfiguration": {
"logDriver": "splunk",
"options": {
"KeyName": ""
},
"secretOptions": [
{
"name": "",
"valueFrom": ""
}
]
},
"healthCheck": {
"command": [""],
"interval": 0,
"timeout": 0,
"retries": 0,
"startPeriod": 0
},
"systemControls": [
{
"namespace": "",
"value": ""
}
],
"resourceRequirements": [
{
"value": "",
"type": "InferenceAccelerator"
}
],
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"KeyName": ""
}
}
}
],
"volumes": [
{
"name": "",
"host": {
"sourcePath": ""
},
"configuredAtLaunch": true,
"dockerVolumeConfiguration": {
"scope": "shared",
"autoprovision": true,
"driver": "",
"driverOpts": {
"KeyName": ""
},
"labels": {
"KeyName": ""
}
},
"efsVolumeConfiguration": {
"fileSystemId": "",
"rootDirectory": "",
"transitEncryption": "DISABLED",
"transitEncryptionPort": 0,
"authorizationConfig": {
"accessPointId": "",
"iam": "ENABLED"
}
},
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "",
"rootDirectory": "",
"authorizationConfig": {
"credentialsParameter": "",
"domain": ""
}
}
}
],
"placementConstraints": [
{
"type": "memberOf",
"expression": ""
}
],
"requiresCompatibilities": ["EC2"],
"cpu": "",
"memory": "",
"tags": [
{
"key": "",
"value": ""
}
],
"pidMode": "task",
"ipcMode": "task",
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "",
"properties": [
{
"name": "",
"value": ""
}
]
},
"inferenceAccelerators": [
{
"deviceName": "",
"deviceType": ""
}
],
"ephemeralStorage": {
"sizeInGiB": 0
},
"runtimePlatform": {
"cpuArchitecture": "X86_64",
"operatingSystemFamily": "WINDOWS_SERVER_20H2_CORE"
}
}
```
**Fargate-Vorlage**
**Wichtig**
Für Fargate müssen Sie den `operatingSystemFamily`-Parameter mit einem der folgenden Werte einbeziehen:
`LINUX`
`WINDOWS_SERVER_2019_FULL`
`WINDOWS_SERVER_2019_CORE`
`WINDOWS_SERVER_2022_FULL`
`WINDOWS_SERVER_2022_CORE`
```
{
"family": "",
"runtimePlatform": {"operatingSystemFamily": ""},
"taskRoleArn": "",
"executionRoleArn": "",
"networkMode": "awsvpc",
"platformFamily": "",
"containerDefinitions": [
{
"name": "",
"image": "",
"repositoryCredentials": {"credentialsParameter": ""},
"cpu": 0,
"memory": 0,
"memoryReservation": 0,
"links": [""],
"portMappings": [
{
"containerPort": 0,
"hostPort": 0,
"protocol": "tcp"
}
],
"essential": true,
"entryPoint": [""],
"command": [""],
"environment": [
{
"name": "",
"value": ""
}
],
"environmentFiles": [
{
"value": "",
"type": "s3"
}
],
"mountPoints": [
{
"sourceVolume": "",
"containerPath": "",
"readOnly": true
}
],
"volumesFrom": [
{
"sourceContainer": "",
"readOnly": true
}
],
"linuxParameters": {
"capabilities": {
"add": [""],
"drop": [""]
},
"devices": [
{
"hostPath": "",
"containerPath": "",
"permissions": ["read"]
}
],
"initProcessEnabled": true,
"sharedMemorySize": 0,
"tmpfs": [
{
"containerPath": "",
"size": 0,
"mountOptions": [""]
}
],
"maxSwap": 0,
"swappiness": 0
},
"secrets": [
{
"name": "",
"valueFrom": ""
}
],
"dependsOn": [
{
"containerName": "",
"condition": "HEALTHY"
}
],
"startTimeout": 0,
"stopTimeout": 0,
"hostname": "",
"user": "",
"workingDirectory": "",
"disableNetworking": true,
"privileged": true,
"readonlyRootFilesystem": true,
"dnsServers": [""],
"dnsSearchDomains": [""],
"extraHosts": [
{
"hostname": "",
"ipAddress": ""
}
],
"dockerSecurityOptions": [""],
"interactive": true,
"pseudoTerminal": true,
"dockerLabels": {"KeyName": ""},
"ulimits": [
{
"name": "msgqueue",
"softLimit": 0,
"hardLimit": 0
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {"KeyName": ""},
"secretOptions": [
{
"name": "",
"valueFrom": ""
}
]
},
"healthCheck": {
"command": [""],
"interval": 0,
"timeout": 0,
"retries": 0,
"startPeriod": 0
},
"systemControls": [
{
"namespace": "",
"value": ""
}
],
"resourceRequirements": [
{
"value": "",
"type": "GPU"
}
],
"firelensConfiguration": {
"type": "fluentd",
"options": {"KeyName": ""}
}
}
],
"volumes": [
{
"name": "",
"host": {"sourcePath": ""},
"configuredAtLaunch":true,
"dockerVolumeConfiguration": {
"scope": "task",
"autoprovision": true,
"driver": "",
"driverOpts": {"KeyName": ""},
"labels": {"KeyName": ""}
},
"efsVolumeConfiguration": {
"fileSystemId": "",
"rootDirectory": "",
"transitEncryption": "ENABLED",
"transitEncryptionPort": 0,
"authorizationConfig": {
"accessPointId": "",
"iam": "ENABLED"
}
}
}
],
"requiresCompatibilities": ["FARGATE"],
"cpu": "",
"memory": "",
"tags": [
{
"key": "",
"value": ""
}
],
"ephemeralStorage": {"sizeInGiB": 0},
"pidMode": "task",
"ipcMode": "none",
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "",
"properties": [
{
"name": "",
"value": ""
}
]
},
"inferenceAccelerators": [
{
"deviceName": "",
"deviceType": ""
}
]
}
```
Sie können diese Aufgabendefinitionsvorlage mit dem folgenden AWS CLI -Befehl generieren.
```
aws ecs register-task-definition --generate-cli-skeleton
```
# Beispiele für Amazon-ECS-Aufgabendefinitionen
Sie können die Beispiele und Ausschnitte kopieren, um mit der Erstellung Ihrer eigenen Aufgabendefinitionen zu beginnen.
Sie können die Beispiele kopieren und dann einfügen, wenn Sie die Option **Über JSON konfigurieren** in der Konsole verwenden. Stellen Sie sicher, dass Sie die Beispiele anpassen, z. B. durch die Verwendung Ihrer Konto-ID. Sie können die Ausschnitte in Ihre JSON-Aufgabendefinition aufnehmen. Weitere Informationen erhalten Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md) und [Amazon-ECS-Aufgabendefinitionsparameter für Fargate](task_definition_parameters.md).
Weitere Beispiele für Aufgabendefinitionen finden Sie unter [AWS Beispiel-Aufgabendefinitionen](https://github.com/aws-samples/aws-containers-task-definitions) auf GitHub.
**Topics**
+ [Webserver](#example_task_definition-webserver)
+ [`splunk`-Protokolltreiber](#example_task_definition-splunk)
+ [`fluentd`-Protokolltreiber](#example_task_definition-fluentd)
+ [`gelf`-Protokolltreiber](#example_task_definition-gelf)
+ [Workloads auf externen Instances](#ecs-anywhere-runtask)
+ [Amazon-ECR-Image und Aufgabendefinitions-IAM-Rolle](#example_task_definition-iam)
+ [Einstiegspunkt mit Befehl](#example_task_definition-ping)
+ [Container-Abhängigkeit](#example_task_definition-containerdependency)
+ [Volumes in Aufgabendefinitionen](#volume_sample_task_defs)
+ [Beispiele für Windows-Aufgabendefinitionen](#windows_sample_task_defs)
## Webserver
Nachfolgend finden Sie ein Beispiel einer Aufgabendefinitionen mit Linux-Containern in Fargate zum Einrichten eines Webservers:
```
{
"containerDefinitions": [
{
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"entryPoint": [
"sh",
"-c"
],
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:2.4",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group" : "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"name": "sample-fargate-app",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
]
}
],
"cpu": "256",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"family": "fargate-task-definition",
"memory": "512",
"networkMode": "awsvpc",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"requiresCompatibilities": [
"FARGATE"
]
}
```
Nachfolgend finden Sie ein Beispiele einer Aufgabendefinitionen mit Windows-Containern in Fargate zum Einrichten eines Webservers:
```
{
"containerDefinitions": [
{
"command": ["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
'; C:\\ServiceMonitor.exe w3svc"],
"entryPoint": [
"powershell",
"-Command"
],
"essential": true,
"cpu": 2048,
"memory": 4096,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"name": "sample_windows_app",
"portMappings": [
{
"hostPort": 80,
"containerPort": 80,
"protocol": "tcp"
}
]
}
],
"memory": "4096",
"cpu": "2048",
"networkMode": "awsvpc",
"family": "windows-simple-iis-2019-core",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"runtimePlatform": {"operatingSystemFamily": "WINDOWS_SERVER_2019_CORE"},
"requiresCompatibilities": ["FARGATE"]
}
```
## `splunk`-Protokolltreiber
Im folgenden Ausschnitt wird gezeigt, wie Sie den `splunk`-Protokolltreiber in einer Aufgabendefinition verwenden, die die Protokolle an einen Remote-Service sendet. Der Splunk-Token-Parameter wird als geheime Option angegeben, da er als sensible Daten behandelt werden kann. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
```
"containerDefinitions": [{
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"tag": "tag_name",
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:splunk-token-KnrBkD"
}],
```
## `fluentd`-Protokolltreiber
Im folgenden Ausschnitt wird gezeigt, wie Sie den `fluentd`-Protokolltreiber in einer Aufgabendefinition verwenden, die die Protokolle an einen Remote-Service sendet. Der `fluentd-address`-Wert ist als geheime Option angegeben, da er als sensible Daten behandelt werden kann. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
```
"containerDefinitions": [{
"logConfiguration": {
"logDriver": "fluentd",
"options": {
"tag": "fluentd demo"
},
"secretOptions": [{
"name": "fluentd-address",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:fluentd-address-KnrBkD"
}]
},
"entryPoint": [],
"portMappings": [{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
},
{
"hostPort": 24224,
"protocol": "tcp",
"containerPort": 24224
}]
}],
```
## `gelf`-Protokolltreiber
Im folgenden Ausschnitt wird gezeigt, wie Sie den `gelf`-Protokolltreiber in einer Aufgabendefinition verwenden, die Protokolle an einen Remote-Host sendet, auf dem Logstash ausgeführt wird und Gelf-Protokolle als Eingang verwendet werden. Weitere Informationen finden Sie unter [logConfiguration](task_definition_parameters.md#ContainerDefinition-logConfiguration).
```
"containerDefinitions": [{
"logConfiguration": {
"logDriver": "gelf",
"options": {
"gelf-address": "udp://logstash-service-address:5000",
"tag": "gelf task demo"
}
},
"entryPoint": [],
"portMappings": [{
"hostPort": 5000,
"protocol": "udp",
"containerPort": 5000
},
{
"hostPort": 5000,
"protocol": "tcp",
"containerPort": 5000
}
]
}],
```
## Workloads auf externen Instances
Verwenden Sie bei der Registrierung einer Amazon-ECS-Aufgabendefinition den `requiresCompatibilities`-Parameter und geben Sie `EXTERNAL` an, der überprüft, ob die Aufgabendefinition kompatibel ist, wenn Amazon-ECS-Workloads auf Ihren externen Instances ausgeführt werden. Wenn Sie die Konsole für die Registrierung einer Aufgabendefinition verwenden, müssen Sie den JSON-Editor verwenden. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
**Wichtig**
Wenn für Ihre Aufgaben eine IAM-Rolle zur Aufgabenausführung erforderlich ist, stellen Sie sicher, dass diese in der Aufgabendefinition angegeben ist.
Wenn Sie Ihren Workload bereitstellen, verwenden Sie den `EXTERNAL`-Starttyp, wenn Sie Ihren Service erstellen oder Ihre eigenständige Aufgabe ausführen.
Im Folgenden finden Sie eine Beispielaufgabendefinition.
------
#### [ Linux ]
```
{
"requiresCompatibilities": [
"EXTERNAL"
],
"containerDefinitions": [{
"name": "nginx",
"image": "public.ecr.aws/nginx/nginx:latest",
"memory": 256,
"cpu": 256,
"essential": true,
"portMappings": [{
"containerPort": 80,
"hostPort": 8080,
"protocol": "tcp"
}]
}],
"networkMode": "bridge",
"family": "nginx"
}
```
------
#### [ Windows ]
```
{
"requiresCompatibilities": [
"EXTERNAL"
],
"containerDefinitions": [{
"name": "windows-container",
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"memory": 256,
"cpu": 512,
"essential": true,
"portMappings": [{
"containerPort": 80,
"hostPort": 8080,
"protocol": "tcp"
}]
}],
"networkMode": "bridge",
"family": "windows-container"
}
```
------
## Amazon-ECR-Image und Aufgabendefinitions-IAM-Rolle
Im folgenden Ausschnitt wird ein Amazon-ECR-Image namens `aws-nodejs-sample` mit dem Tag `v1` von der `123456789012.dkr.ecr.us-west-2.amazonaws.com`-Registrierung verwendet. Der Container in dieser Aufgabe erbt die IAM-Berechtigungen von der Rolle `arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole`. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).
```
{
"containerDefinitions": [
{
"name": "sample-app",
"image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/aws-nodejs-sample:v1",
"memory": 200,
"cpu": 10,
"essential": true
}
],
"family": "example_task_3",
"taskRoleArn": "arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole"
}
```
## Einstiegspunkt mit Befehl
Im folgenden Ausschnitt wird die Syntax eines Docker-Containers gezeigt, der einen Eintrittspunkt und ein Befehlsargument verwendet. Dieser Container führt viermal einen Ping für `example.com` aus und wird dann beendet.
```
{
"containerDefinitions": [
{
"memory": 32,
"essential": true,
"entryPoint": ["ping"],
"name": "alpine_ping",
"readonlyRootFilesystem": true,
"image": "alpine:3.4",
"command": [
"-c",
"4",
"example.com"
],
"cpu": 16
}
],
"family": "example_task_2"
}
```
## Container-Abhängigkeit
Dieser Ausschnitt veranschaulicht die Syntax einer Aufgabendefinition mit mehreren Containern, für die eine Container-Abhängigkeit angegeben ist. In der folgenden Aufgabendefinition muss der `envoy`-Container einen fehlerfreien Status erreichen. Dieser wird anhand der erforderlichen Container-Parameter für die Zustandsprüfung bestimmt, bevor der `app`-Container gestartet wird. Weitere Informationen finden Sie unter [Container-Abhängigkeit](task_definition_parameters.md#container_definition_dependson).
```
{
"family": "appmesh-gateway",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"proxyConfiguration":{
"type": "APPMESH",
"containerName": "envoy",
"properties": [
{
"name": "IgnoredUID",
"value": "1337"
},
{
"name": "ProxyIngressPort",
"value": "15000"
},
{
"name": "ProxyEgressPort",
"value": "15001"
},
{
"name": "AppPorts",
"value": "9080"
},
{
"name": "EgressIgnoredIPs",
"value": "169.254.170.2,169.254.169.254"
}
]
},
"containerDefinitions": [
{
"name": "app",
"image": "application_image",
"portMappings": [
{
"containerPort": 9080,
"hostPort": 9080,
"protocol": "tcp"
}
],
"essential": true,
"dependsOn": [
{
"containerName": "envoy",
"condition": "HEALTHY"
}
]
},
{
"name": "envoy",
"image": "840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.15.1.0-prod",
"essential": true,
"environment": [
{
"name": "APPMESH_VIRTUAL_NODE_NAME",
"value": "mesh/meshName/virtualNode/virtualNodeName"
},
{
"name": "ENVOY_LOG_LEVEL",
"value": "info"
}
],
"healthCheck": {
"command": [
"CMD-SHELL",
"echo hello"
],
"interval": 5,
"timeout": 2,
"retries": 3
}
}
],
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"networkMode": "awsvpc"
}
```
## Volumes in Aufgabendefinitionen
Im Folgenden erfahren Sie, wie Volumes in Aufgaben angegeben werden.
+ Informationen zur Konfiguration eines Amazon-EBS-Volumes finden Sie unter [Die Amazon-EBS-Volume-Konfiguration bei der Amazon-ECS-Bereitstellung angeben](configure-ebs-volume.md).
+ Informationen zur Konfiguration eines Amazon-EFS-Volumes finden Sie unter [Konfiguration von Amazon-EFS-Dateisystemen für Amazon ECS mit der Konsole](tutorial-efs-volumes.md).
+ Informationen zur Konfiguration eines Volumes FSx für Windows-Dateiserver finden Sie unter[Erfahren Sie, wie Sie Dateisysteme FSx für Windows File Server für Amazon ECS konfigurieren](tutorial-wfsx-volumes.md).
+ Informationen zur Konfiguration eines Docker-Volumes finden Sie unter [Besipiel-Docker-Volumes für Amazon ECS](docker-volume-examples.md).
+ Informationen zur Konfiguration eines Bind-Mounts finden Sie unter [Beispiele für Bind-Mounts für Amazon ECS](bind-mount-examples.md).
## Beispiele für Windows-Aufgabendefinitionen
Nachfolgend finden Sie eine exemplarische Aufgabendefinition, die Ihnen den Einstieg in die Verwendung von Windows-Containern auf Amazon ECS erleichtert.
**Example Amazon-ECS-Beispielkonsolenanwendung für Windows**
Die folgende Aufgabendefinition ist die Amazon-ECS-Beispielkonsolenanwendung, die im zuerst ausgeführten Assistenten für Amazon ECS erzeugt wird. Sie wurde portiert, um das `microsoft/iis` Windows-Container-Image zu verwenden.
```
{
"family": "windows-simple-iis",
"containerDefinitions": [
{
"name": "windows_sample_app",
"image": "mcr.microsoft.com/windows/servercore/iis",
"cpu": 1024,
"entryPoint":["powershell", "-Command"],
"command":["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value '
Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
'; C:\\ServiceMonitor.exe w3svc"],
"portMappings": [
{
"protocol": "tcp",
"containerPort": 80
}
],
"memory": 1024,
"essential": true
}
],
"networkMode": "awsvpc",
"memory": "1024",
"cpu": "1024"
}
```