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": 443, "containerPort": 80, "protocol": "tcp" } ], "mountPoints": [ { "sourceVolume": "myEBSVolume", "containerPath": "drive:\ebs", "readOnly": true } ] } ], "volumes": [ { "name": "myEBSVolume", "configuredAtLaunch": true } ], "requiresCompatibilities": [ "FARGATE", "EC2" ], "cpu": "1024", "memory": "3072", "networkMode": "awsvpc" } ``` `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. `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. `configuredAtLaunch` Typ: Boolescher Wert Erforderlich: Ja, wenn Sie ein EBS-Volume direkt an eine Aufgabe anhängen möchten. 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 `false` gesetzt ist, können Sie keine andere Volume-Konfiguration in der Aufgabendefinition angeben. Dieser Parameter muss bereitgestellt und auf `true` gesetzt werden, um ein Amazon-EBS-Volume für das Anhängen an eine Aufgabe zu konfigurieren. # Verschlüsseln von Daten, die in Amazon-EBS-Volumes gespeichert sind, die Amazon-ECS-Aufgaben angehängt sind Sie können AWS Key Management Service (AWS KMS) verwenden, um kryptografische Schlüssel zu erstellen und zu verwalten, die Ihre Daten schützen. Amazon EBS-Volumes werden im Ruhezustand mithilfe AWS KMS keys von verschlüsselt. Die folgenden Datentypen werden verschlüsselt: + Daten, die im Ruhezustand auf dem Volume gespeichert sind + Festplatten-IO + Alle Snapshots, die von dem Volume erstellt werden + Neue Volumes, die aus verschlüsselten Snapshots erstellt wurden Amazon-EBS-Volumes, die an Aufgaben angehängt sind, können verschlüsselt werden, indem entweder ein Standard Von AWS verwalteter Schlüssel mit dem Alias `alias/aws/ebs` oder ein symmetrischer, vom Kunden verwalteter Schlüssel verwendet wird, der in der Volume-Konfiguration angegeben ist. Von AWS verwaltete Schlüssel Standardwerte sind für jeden Benutzer AWS-Konto einzigartig AWS-Region und werden automatisch erstellt. Befolgen zum Erstellen eines symmetrischen, kundenverwalteten Schlüssels die Schritte unter [Erstellen symmetrischer KMS-Verschlüsselungsschlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) im *AWS KMS -Entwicklerhandbuch*. Sie können die Amazon EBS-Verschlüsselung standardmäßig so konfigurieren, dass alle neuen Volumes, die in einem bestimmten Bereich erstellt und an eine Aufgabe angehängt AWS-Region werden, mithilfe des KMS-Schlüssels, den Sie für Ihr Konto angeben, verschlüsselt werden. Weitere Informationen über die (standardmäßige) Verschlüsselung in Amazon EBS finden Sie unter [Amazon-EBS-Verschlüsselung](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) im *Amazon-EBS-Benutzerhandbuch*. ## Verhalten von Amazon ECS Managed Instances Sie verschlüsseln Amazon-EBS-Volumes, indem Sie die Verschlüsselung aktivieren. Hierzu verwenden Sie entweder die standardmäßige Verschlüsselung oder aktivieren die Verschlüsselung beim Erstellen eines Volumes, das Sie verschlüsseln möchten. Weitere Informationen zur standardmäßigen Aktivierung der Verschlüsselung (auf Kontoebene) finden Sie unter [Standardverschlüsselung](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) im *Amazon-EBS-Benutzerhandbuch*. Sie können eine beliebige Kombination dieser Schlüssel konfigurieren. Die Rangfolge der KMS-Schlüssel ist wie folgt: 1. Der in der Volume-Konfiguration angegebene KMS-Schlüssel. Wenn Sie in der Volume-Konfiguration einen KMS-Schlüssel angeben, überschreibt dieser den Amazon-EBS-Standard und alle KMS-Schlüssel, die auf Kontoebene angegeben sind. 1. Der auf Kontoebene angegebene KMS-Schlüssel. Wenn Sie einen KMS-Schlüssel für die Verschlüsselung von Amazon ECS Managed Storage auf Cluster-Ebene angeben, überschreibt er die Amazon-EBS-Standardverschlüsselung, jedoch keinen KMS-Schlüssel, der in der Volume-Konfiguration angegeben ist. 1. Amazon-EBS-Standardverschlüsselung. Die Standardverschlüsselung gilt, wenn Sie in der Volume-Konfiguration weder einen KMS-Schlüssel auf Kontoebene noch einen Schlüssel angeben. Wenn Sie die Amazon-EBS-Verschlüsselung standardmäßig aktivieren, ist die Standardeinstellung der KMS-Schlüssel, den Sie standardmäßig für die Verschlüsselung angeben. Andernfalls ist die Standardeinstellung Von AWS verwalteter Schlüssel mit dem Alias `alias/aws/ebs`. **Anmerkung** Wenn Sie `false` in Ihrer Volume-Konfiguration auf `encrypted` festgelegt haben, keinen KMS-Schlüssel auf Kontoebene angeben und die Amazon-EBS-Verschlüsselung standardmäßig aktivieren, wird das Volume weiterhin standardmäßig mit dem für die Amazon-EBS-Verschlüsselung angegebenen Schlüssel verschlüsselt. ## Verhalten nicht von Amazon ECS Managed Instances Sie können auch die Amazon-ECS-Verschlüsselung auf Cluster-Ebene für Amazon ECS Managed Storage einrichten, wenn Sie einen Cluster erstellen oder aktualisieren. Die Verschlüsselung auf Cluster-Ebene wird auf Aufgabenebene wirksam und kann verwendet werden, um die Amazon-EBS-Volumes, die jeder Aufgabe zugeordnet sind, die in einem bestimmten Cluster ausgeführt wird, mithilfe des angegebenen KMS-Schlüssels zu verschlüsseln. Weitere Informationen zur Konfiguration der Verschlüsselung auf Cluster-Ebene für jede Aufgabe finden Sie [ManagedStorageConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedStorageConfiguration.html)in der *Amazon ECS-API-Referenz*. Sie können eine beliebige Kombination dieser Schlüssel konfigurieren. Die Rangfolge der KMS-Schlüssel ist wie folgt: 1. Der in der Volume-Konfiguration angegebene KMS-Schlüssel. Wenn Sie in der Volume-Konfiguration einen KMS-Schlüssel angeben, überschreibt er den Amazon-EBS-Standard und alle KMS-Schlüssel, die auf Cluster-Ebene angegeben sind. 1. Der auf Cluster-Ebene angegebene KMS-Schlüssel. Wenn Sie einen KMS-Schlüssel für die Verschlüsselung von Amazon ECS Managed Storage auf Cluster-Ebene angeben, überschreibt er die Amazon-EBS-Standardverschlüsselung, jedoch keinen KMS-Schlüssel, der in der Volume-Konfiguration angegeben ist. 1. Amazon-EBS-Standardverschlüsselung. Die Standardverschlüsselung gilt, wenn Sie weder einen KMS-Schlüssel auf Cluster-Ebene noch einen Schlüssel in der Volume-Konfiguration angeben. Wenn Sie die Amazon-EBS-Verschlüsselung standardmäßig aktivieren, ist die Standardeinstellung der KMS-Schlüssel, den Sie standardmäßig für die Verschlüsselung angeben. Andernfalls ist die Standardeinstellung Von AWS verwalteter Schlüssel mit dem Alias`alias/aws/ebs`. **Anmerkung** Wenn Sie `false` in Ihrer Volume-Konfiguration auf `encrypted` festgelegt haben, keinen KMS-Schlüssel auf Cluster-Ebene angeben und die Amazon-EBS-Verschlüsselung standardmäßig aktivieren, wird das Volume weiterhin standardmäßig mit dem für die Amazon-EBS-Verschlüsselung angegebenen Schlüssel verschlüsselt. ## Kundenverwaltete KMS-Schlüsselrichtlinie Um ein EBS-Volume, das an Ihre Aufgabe angehängt ist, mithilfe eines vom Kunden verwalteten Schlüssels zu verschlüsseln, müssen Sie Ihre KMS-Schlüsselrichtlinie so konfigurieren, dass die IAM-Rolle, die Sie für die Volume-Konfiguration verwenden, über die erforderlichen Berechtigungen zur Verwendung des Schlüssels verfügt. Die Schlüsselrichtlinie muss die Berechtigungen `kms:CreateGrant` und `kms:GenerateDataKey*` enthalten. Die Berechtigungen `kms:ReEncryptTo` und `kms:ReEncryptFrom` sind für die Verschlüsselung von Volumes erforderlich, die mithilfe von Snapshots erstellt wurden. Wenn Sie nur neue, leere Volumes für das Anhängen konfigurieren und verschlüsseln möchten, können Sie die Berechtigungen `kms:ReEncryptTo` und `kms:ReEncryptFrom` ausschließen. Der folgende JSON-Ausschnitt zeigt wichtige Richtlinienanweisungen, die Sie Ihrer KMS-Schlüsselrichtlinie anfügen können. Mithilfe dieser Anweisungen erhält Amazon ECS Zugriff auf die Verwendung des Schlüssels für die Verschlüsselung des EBS-Volumes. Wenn Sie diese Beispiels-Richtlinienanweisungen verwenden möchten, ersetzen Sie die `user input placeholders` durch Ihre eigenen Informationen. Konfigurieren Sie wie immer nur die Berechtigungen, die Sie benötigen. ``` { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:DescribeKey", "Resource":"*" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": [ "kms:GenerateDataKey*", "kms:ReEncryptTo", "kms:ReEncryptFrom" ], "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:CreateGrant", "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" }, "Bool": { "kms:GrantIsForAWSResource": true } } } ``` Weitere Informationen zu wichtigen Richtlinien und Berechtigungen finden Sie unter [Wichtige Richtlinien AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) und [AWS KMS -Berechtigungen](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html) im *AWS KMS -Entwicklerhandbuch*. Informationen zur Behebung von Problemen mit dem Anhängen von EBS-Volumes im Zusammenhang mit Schlüsselberechtigungen finden Sie unter [Fehlerbehebung bei Amazon-EBS-Volume-Anhängen an Amazon-ECS-Aufgaben](troubleshoot-ebs-volumes.md). # Die Amazon-EBS-Volume-Konfiguration bei der Amazon-ECS-Bereitstellung angeben Nachdem Sie eine Aufgabendefinition mit dem `configuredAtLaunch`-Parameter auf `true` registriert haben, können Sie ein Amazon-EBS-Volume bei der Bereitstellung konfigurieren, wenn Sie eine eigenständige Aufgabe ausführen oder wenn Sie einen Service erstellen oder aktualisieren. Weitere Informationen zum Verschieben der Volume-Konfiguration auf die Startzeit mithilfe des `configuredAtLaunch`-Parameters finden Sie unter [Die Volume-Konfiguration auf die Startzeit in einer Amazon-ECS-Aufgabendefinition verschieben](specify-ebs-config.md). Um ein Volume zu konfigurieren, können Sie Amazon ECS APIs verwenden oder eine JSON-Datei als Eingabe für die folgenden AWS CLI Befehle übergeben: + `[run-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)`, um eine eigenständige ECS-Aufgabe auszuführen. + `[start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html)`, um eine eigenständige ECS-Aufgabe in einer bestimmten Container-Instance auszuführen. Dieser Befehl gilt nicht für Fargate-Aufgaben. + `[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)`, um einen neuen ECS-Service zu erstellen. + `[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)`, um einen bestehenden Service zu aktualisieren. **Anmerkung** Damit ein Container in Ihrer Aufgabe auf das bereitgestellte Amazon EBS-Volume schreiben kann, muss der Container über die entsprechenden Dateisystemberechtigungen verfügen. Wenn Sie in Ihrer Container-Definition einen Nicht-Root-Benutzer angeben, konfiguriert Amazon ECS das Volume automatisch mit gruppenbasierten Berechtigungen, die es dem angegebenen Benutzer ermöglichen, auf das Volume zu lesen und zu schreiben. Wenn kein Benutzer angegeben ist, wird der Container als Root ausgeführt und hat vollen Zugriff auf das Volume. Sie können ein Amazon-EBS-Volume auch mit der AWS-Managementkonsole konfigurieren. Weitere Informationen finden Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md), [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md) und [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md). Der folgende JSON-Ausschnitt zeigt alle Parameter eines Amazon-EBS-Volumes, die bei der Bereitstellung konfiguriert werden können. Um diese Parameter für die Volume-Konfiguration zu verwenden, ersetzen Sie `user input placeholders` durch Ihre eigenen Informationen. Weitere Informationen zu diesen Parametern finden Sie unter [Volume-Konfigurationen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-volumeConfigurations). ``` "volumeConfigurations": [ { "name": "ebs-volume", "managedEBSVolume": { "encrypted": true, "kmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "volumeType": "gp3", "sizeInGiB": 10, "snapshotId": "snap-12345", "volumeInitializationRate":100, "iops": 3000, "throughput": 125, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn": "arn:aws:iam::1111222333:role/ecsInfrastructureRole", "terminationPolicy": { "deleteOnTermination": true//can't be configured for service-managed tasks, always true }, "filesystemType": "ext4" } } ] ``` **Wichtig** Stellen Sie sicher, dass der `volumeName`, den Sie in der Konfiguration angeben, derselbe ist, wie der `volumeName`, den Sie in Ihrer Aufgabendefinition angeben. Weitere Informationen zum Überprüfen des Statuss eines Volume-Anhangs finden Sie unter [Fehlerbehebung bei Amazon-EBS-Volume-Anhängen an Amazon-ECS-Aufgaben](troubleshoot-ebs-volumes.md). Informationen zur Amazon ECS-Infrastrukturrolle AWS Identity and Access Management (IAM), die für das Anhängen von EBS-Volumes erforderlich ist, finden Sie unter. [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md) Im Folgenden finden Sie Beispiele für JSON-Ausschnitte, die die Konfiguration von Amazon-EBS-Volumes zeigen. Diese Beispiele können verwendet werden, indem die Snippets in JSON-Dateien gespeichert und die Dateien als Parameter (unter Verwendung des `--cli-input-json file://filename` Parameters) für Befehle übergeben werden. AWS CLI Ersetzen Sie `user input placeholders` durch Ihre Informationen. ## Ein Volume für eine eigenständige Aufgabe konfigurieren Der folgende Ausschnitt zeigt die Syntax für die Konfiguration von Amazon-EBS-Volumes für den Anhang an eine eigenständige Aufgabe. Der folgende JSON-Ausschnitt zeigt die Syntax für die Konfiguration der Einstellungen `volumeType`, `sizeInGiB`, `encrypted` und `kmsKeyId`. Die in der JSON-Datei angegebene Konfiguration wird verwendet, um ein EBS-Volume zu erstellen und an die eigenständige Aufgabe anzuhängen. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` ## Ein Volume bei der Service-Erstellung konfigurieren Der folgende Ausschnitt zeigt die Syntax für die Konfiguration von Amazon-EBS-Volumes für den Anhang an Aufgaben, die von einem Service verwaltet werden. Die Volumes stammen aus dem mit dem `snapshotId`-Parameter angegebenen Snapshot mit einer Geschwindigkeit von 200 MiB/s. Die in der JSON-Datei angegebene Konfiguration wird verwendet, um ein EBS-Volume zu erstellen und an jede Aufgabe anzuhängen, die vom Service verwaltet wird. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "snapshotId": "snap-12345", "volumeInitializationRate": 200 } } ] } ``` ## Ein Volume bei der Service-Aktualisierung konfigurieren Der folgende JSON-Ausschnitt zeigt die Syntax für die Aktualisierung eines Services, für den zuvor keine Amazon-EBS-Volumes für das Anhängen an Aufgaben konfiguriert waren. Sie müssen den ARN einer Aufgabendefinitionsrevision angeben, bei dem `configuredAtLaunch` auf `true` gestellt ist. Der folgende JSON-Ausschnitt zeigt die Syntax für die Konfiguration der Einstellungen `volumeType`, `sizeInGiB`, `throughput`, `iops` und `filesystemType`. Diese Konfiguration wird verwendet, um ein EBS-Volume zu erstellen und an jede vom Service verwaltete Aufgabe anzuhängen. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "volumeType": "gp3", "sizeInGiB": 100, "iops": 3000, "throughput": 125, "filesystemType": "ext4" } } ] } ``` ### Einen Service so konfigurieren, dass er Amazon-EBS-Volumes nicht mehr nutzt Der folgende JSON-Ausschnitt zeigt die Syntax für die Aktualisierung eines Service, sodass er keine Amazon-EBS-Volumes mehr verwendet. Sie müssen den ARN einer Aufgabendefinition mit `configuredAtLaunch` auf `false` gestellt oder eine Aufgabendefinition ohne den `configuredAtLaunch`-Parameter angeben. Sie müssen auch ein leeres `volumeConfigurations`-Objekt angeben. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [] } ``` ## Beendigungsrichtlinie für Amazon-EBS-Volumes Wenn eine Amazon-ECS-Aufgabe beendet wird, bestimmt Amazon ECS anhand des `deleteOnTermination`-Werts, ob das Amazon-EBS-Volume, das der beendeten Aufgabe zugeordnet ist, gelöscht werden soll. Standardmäßig werden EBS-Volumes, die an Aufgaben angehängt sind, gelöscht, wenn die Aufgabe beendet wird. Bei eigenständigen Aufgaben können Sie diese Einstellung ändern, sodass das Volume beim Beenden der Aufgabe erhalten bleibt. **Anmerkung** Volumes, die an Aufgaben angehängt sind, die von einem Service verwaltet werden, bleiben nicht erhalten und werden bei Beendigung der Aufgabe immer gelöscht. ## Markieren von Amazon-EBS-Volumes Sie können Amazon-EBS-Volumes mithilfe des `tagSpecifications`-Objekts markieren. Mithilfe des Objekts können Sie Ihre eigenen Tags angeben und die Weitergabe von Tags aus der Aufgabendefinition oder dem Service festlegen, je nachdem, ob das Volume an eine eigenständige Aufgabe oder eine Aufgabe in einem Service angehängt ist. Die maximale Anzahl von Tags, die an ein Volume angehängt werden können, ist 50. **Wichtig** Amazon ECS fügt die reservierten Tags `AmazonECSCreated` und `AmazonECSManaged` automatisch an ein Amazon-EBS-Volume an. Das bedeutet, dass Sie das Anhängen von maximal 48 zusätzlichen Tags an ein Volume steuern können. Bei diesen zusätzlichen Tags kann es sich um benutzerdefinierte, von ECS verwaltete oder weitergegebene Tags handeln. Wenn Sie Ihrem Volume Amazon ECS Managed Tags hinzufügen möchten, müssen Sie `enableECSManagedTags` in Ihrem`UpdateService`-, `CreateService`-, `RunTask`- oder `StartTask`-Aufruf auf `true` einstellen. Wenn Sie Amazon ECS Managed Tags aktivieren, markiert Amazon ECS das Volume automatisch mit Cluster- und Serviceinformationen (`aws:ecs:clusterName` und `aws:ecs:serviceName`). Weitere Informationen zum Markieren von Amazon-ECS-Ressourcen finden Sie unter [Markieren von Amazon-ECS-Ressourcen mit Tags](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html). Der folgende JSON-Ausschnitt zeigt die Syntax für die Markierung jedes Amazon-EBS-Volumes, das an jede Aufgabe in einem Service angehängt ist, mit einem benutzerdefinierten Tag. Um dieses Beispiel zum Erstellen eines Services zu verwenden, ersetzen Sie `user input placeholders` durch Ihre eigenen Informationen. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "enableECSManagedTags": true, "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn":"arn:aws:iam:1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` **Wichtig** Sie müssen einen `volume`-Ressourcentyp angeben, um Amazon-EBS-Volumes zu markieren. # Leistung von Amazon-EBS-Volumes für Fargate-On-Demand-Aufgaben Die für eine Fargate-On-Demand-Aufgabe verfügbaren Amazon-EBS-Volume-Basis-IOPS und der entsprechende Durchsatz hängen von der Gesamtzahl der CPU-Einheiten ab, die Sie für die Aufgabe anfordern. Wenn Sie 0,25, 0,5 oder 1 virtuelle CPU-Einheit (vCPU) für Ihre Fargate-Aufgabe anfordern, empfehlen wir Ihnen, ein Allzweck-SSD-Volume (`gp2` oder `gp3`) oder ein Festplattenlaufwerk (HDD)-Volume (`st1` oder `sc1`) zu konfigurieren. Wenn Sie mehr als 1 vCPU für Ihre Fargate-Aufgabe anfordern, gelten die folgenden Basis-Leistungsgrenzen für ein Amazon-EBS-Volume, das der Aufgabe zugeordnet ist. Möglicherweise erhalten Sie vorübergehend eine höhere EBS-Leistung als die folgenden Grenzwerte. Es wird jedoch empfohlen, Ihre Workload auf der Grundlage dieser Grenzwerte zu planen. | Angeforderte CPU-Einheiten (in v) CPUs | Basis-IOPS für Amazon EBS (16 KiB I/O) | Amazon EBS-Basisdurchsatz (in MiBps, 128 KiB I/O) | Baseline-Bandbreite (Mbit/s) | | --- | --- | --- | --- | | 2 | 3,000 | 75 | 360 | | 4 | 5,000 | 120 | 1.150 | | 8 | 10.000 | 250 | 2.300 | | 16 | 15 000 | 500 | 4.500 | **Anmerkung** Wenn Sie ein Amazon-EBS-Volume für das Anhängen an eine Fargate-Aufgabe konfigurieren, wird das Amazon-EBS-Leistungslimit für Fargate-Aufgaben zwischen dem flüchtigen Speicher der Aufgabe und dem angehängten Volume gemeinsam genutzt. # Leistung von Amazon-EBS-Volumes für EC2-Aufgaben Amazon EBS bietet die folgenden Volume-Typen, die sich bei den Leistungsmerkmalen und im Preis unterscheiden, sodass Sie die Speicherleistung und -kosten an die Anforderungen Ihrer Anwendungen anpassen können. Informationen zur Leistung, einschließlich IOPS pro Volume und Durchsatz pro Volume, finden Sie unter [Volume-Typen in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) im *Benutzerhandbuch für Amazon Elastic Block Store*. # Leistung von Amazon-EBS-Volumes für Aufgaben von Amazon ECS Managed Instances Amazon EBS bietet die folgenden Volume-Typen, die sich bei den Leistungsmerkmalen und im Preis unterscheiden, sodass Sie die Speicherleistung und -kosten an die Anforderungen Ihrer Anwendungen anpassen können. Informationen zur Leistung, einschließlich IOPS pro Volume und Durchsatz pro Volume, finden Sie unter [Volume-Typen in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) im *Benutzerhandbuch für Amazon Elastic Block Store*. # Fehlerbehebung bei Amazon-EBS-Volume-Anhängen an Amazon-ECS-Aufgaben Möglicherweise müssen Sie das Anhängen von Amazon-EBS-Volumes an Amazon-ECS-Aufgaben beheben oder überprüfen. ## Überprüfen des Statuss eines Volume-Anhangs Sie können den verwenden AWS-Managementkonsole , um den Status des Anhangs eines Amazon EBS-Volumes an eine Amazon ECS-Aufgabe anzuzeigen. Wenn die Aufgabe gestartet wird und der Anhang fehlschlägt, wird Ihnen auch ein Statussgrund angezeigt, den Sie zur Fehlerbehebung verwenden können. Das erstellte Volume wird gelöscht und die Aufgabe wird gestoppt. Weitere Hinweise über Statussgründe finden Sie unter [Statussgründe für den Anhang von Amazon-EBS-Volumes an Amazon-ECS-Aufgaben](troubleshoot-ebs-volumes-scenarios.md). **So können Sie den Anhangsstatus und den Grund für den Status eines Volumes in der Konsole anzeigen** 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 auf der Seite **Cluster** den Cluster aus, in dem Ihre Aufgabe ausgeführt wird. Die Cluster-Detailseite wird angezeigt. 1. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte **Aufgaben**. 1. Wählen Sie die Aufgabe, für die Sie den Volume-Anhangsstatus anzeigen möchten. Wenn die Aufgabe, die Sie untersuchen möchten, angehalten wurde, müssen Sie möglicherweise **Nach gewünschtem Status filtern** und **Angehalten** auswählen. 1. Wählen Sie auf der Detailseite der Aufgabe die Registerkarte **Volumes**. Sie können den Anhangsstatus des Amazon-EBS-Volumes unter **Anhangsstatus** sehen. Wenn das Volume nicht an die Aufgabe angehängt werden kann, können Sie den Status unter **Anhangsstatus** auswählen, um die Ursache des Fehlers anzuzeigen. Mithilfe der [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)API können Sie auch den Status des Volumen-Anhangs einer Aufgabe und den Grund für den zugehörigen Status einsehen. ## Service- und Aufgabenfehler Möglicherweise treten Fehler bei Services oder Aufgaben auf, die nicht spezifisch für Amazon-EBS-Volumes sind und sich auf den Volume-Anhang auswirken können. Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format). + [Service-Ereignismeldungen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-event-messages.html) + [Fehlercodes Aufgabe-Beendet-Fehlern](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html) + [Gründe für API-Fehler](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/api_failures_messages.html) # Container kann nicht auf das Amazon EBS-Volume schreiben Benutzer ohne Root-Rechte Wenn Sie in Ihrer Container-Definition einen Nicht-Root-Benutzer angeben, konfiguriert Amazon ECS das Volume automatisch mit gruppenbasierten Berechtigungen, um Schreibzugriff zu ermöglichen. Wenn Sie jedoch immer noch Probleme mit den Berechtigungen haben: + Stellen Sie anhand des Formats sicher, dass der `user` Parameter in Ihrer Containerdefinition korrekt angegeben ist `uid:gid` (z. B.`1001:1001`). + Stellen Sie sicher, dass Ihr Container-Image die Benutzerberechtigungen nicht überschreibt, nachdem das Volume bereitgestellt wurde. + Überprüfen Sie, ob Ihre Anwendung mit der erwarteten Benutzer-ID ausgeführt wird, indem Sie die Container-Protokolle untersuchen oder Amazon ECS Exec verwenden, um den laufenden Container zu überprüfen. Root-Benutzer mit Berechtigungsproblemen Wenn in Ihrer Container-Definition kein Benutzer angegeben ist, wird der Container als Root-Benutzer ausgeführt und sollte vollen Zugriff auf das Volume haben. Wenn Sie Probleme haben: + Stellen Sie sicher, dass das Volume ordnungsgemäß gemountet ist, indem Sie die Bereitstellungspunkte im Container überprüfen. + Stellen Sie sicher, dass das Volume in Ihrer Mount-Point-Konfiguration nicht als schreibgeschützt konfiguriert ist. Aufgaben mit mehreren Containern und unterschiedlichen Benutzern Bei Aufgaben mit mehreren Containern, die als unterschiedliche Benutzer ausgeführt werden, verwaltet Amazon ECS automatisch Gruppenberechtigungen, sodass alle angegebenen Benutzer auf das Volume schreiben können. Wenn Container nicht schreiben können: + Stellen Sie sicher, dass der `user` Parameter für alle Container, die Schreibzugriff benötigen, richtig konfiguriert ist. + Vergewissern Sie sich, dass das Volume in allen Containern installiert ist, die Zugriff darauf benötigen. Weitere Informationen zur Konfiguration von Benutzern in Containerdefinitionen finden Sie unter [Amazon ECS-Aufgabendefinitionsparameter für Fargate](https://docs.aws.amazon.com/./task_definition_parameters.html). # Statussgründe für den Anhang von Amazon-EBS-Volumes an Amazon-ECS-Aufgaben Verwenden Sie die folgende Referenz, um Probleme zu beheben, die in Form von Statusgründen AWS-Managementkonsole bei der Konfiguration von Amazon EBS-Volumes für das Anhängen an Amazon ECS-Aufgaben auftreten können. Weitere Informationen zum Auffinden dieser Statussgründe in der Konsole finden Sie unter [Überprüfen des Statuss eines Volume-Anhangs](troubleshoot-ebs-volumes.md#troubleshoot-ebs-volumes-location). ECS konnte die konfigurierte ECS-Infrastrukturrolle 'arn:aws:iam: ::role/ 'nicht annehmen. *111122223333* *ecsInfrastructureRole* Bitte stellen Sie sicher, dass für die übergebene Rolle die richtige Vertrauensbeziehung zu Amazon ECS besteht. Dieser Statussgrund tritt in den folgenden Szenarien auf. + Sie geben eine IAM-Rolle an, ohne dass die erforderliche Vertrauensrichtlinie angehängt ist. Amazon ECS kann nicht auf die von Ihnen angegebene Infrastruktur-IAM-Rolle für Amazon ECS zugreifen, wenn die Rolle nicht über die erforderliche Vertrauensrichtlinie verfügt. Die Aufgabe kann im `DEPROVISIONING`-Status hängen bleiben. Weitere Informationen zur notwendigen Vertrauensrichtlinie finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md). + Ihr IAM-Benutzer ist nicht berechtigt, die Amazon-ECS-Infrastrukturrolle an Amazon ECS weiterzugeben. Die Aufgabe kann im `DEPROVISIONING`-Status hängen bleiben. Um dieses Problem zu vermeiden, können Sie die `PassRole`-Berechtigung an Ihren Benutzer anhängen. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md). + Ihre IAM-Rolle verfügt nicht über die erforderlichen Berechtigungen für das Anhängen von Amazon-EBS-Volumes. Die Aufgabe kann im `DEPROVISIONING`-Status hängen bleiben. Weitere Informationen zu den spezifischen Berechtigungen, die für das Anhängen von Amazon-EBS-Volumes an Aufgaben erforderlich sind, finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md). Möglicherweise wird Ihnen diese Fehlermeldung auch aufgrund einer Verzögerung bei der Rollenübertragung angezeigt. Wenn der erneute Versuch, die Rolle nach einigen Minuten zu verwenden, das Problem nicht behebt, haben Sie möglicherweise die Vertrauensrichtlinie für die Rolle falsch konfiguriert. ECS konnte das EBS-Volume nicht einrichten. Es ist aufgetreten IdempotentParameterMismatch „; „Das von Ihnen angegebene Client-Token ist mit einer Ressource verknüpft, die bereits gelöscht wurde. Bitte verwenden Sie ein anderes Client-Token. Die folgenden AWS KMS wichtigen Szenarien können dazu führen, dass eine `IdempotentParameterMismatch` Meldung angezeigt wird: + Sie geben einen ARN, eine ID oder einen Alias für KMS an, der nicht gültig ist. In diesem Szenario scheint die Aufgabe erfolgreich gestartet zu werden, aber die Aufgabe schlägt irgendwann fehl, weil der KMS-Schlüssel asynchron AWS authentifiziert wird. Weitere Informationen finden Sie unter [Amazon-EBS-Verschlüsselung](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) im *Amazon-EC2-Benutzerhandbuch*. + Sie stellen einen vom Kunden verwalteten Schlüssel bereit, dem die Berechtigungen fehlen, die es der IAM-Infrastrukturrolle für Amazon ECS ermöglichen, den Schlüssel für die Verschlüsselung zu verwenden. Informationen zur Vermeidung von Problemen mit Schlüsselrichtlinien finden Sie in der AWS KMS Beispielschlüsselrichtlinie unter [Datenverschlüsselung für Amazon EBS-Volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html#ebs-kms-encryption). Sie können Amazon so einrichten EventBridge , dass Amazon EBS-Volumenereignisse und Amazon ECS-Ereignisse zur Änderung des Aufgabenstatus an ein Ziel, z. B. CloudWatch Amazon-Gruppen, gesendet werden. Sie können diese Ereignisse dann verwenden, um das spezifische Problem mit dem kundenverwalteten Schlüssel zu identifizieren, das sich auf den Volume-Anhang ausgewirkt hat. Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format). + [Wie kann ich eine CloudWatch Protokollgruppe erstellen, die als Ziel für eine EventBridge Regel verwendet werden soll?](https://repost.aws/knowledge-center/cloudwatch-log-group-eventbridge) auf AWS re:POST. + [Änderungsereignisse des Aufgabenstatus](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html#ecs_task_events) + [ EventBridge Amazon-Veranstaltungen für Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html) im *Amazon EBS-Benutzerhandbuch*. ECS hat bei der Konfiguration des EBS-Volume-Anhangs an Ihre Aufgabe eine Zeitüberschreitung erlitten. Die folgenden Probleme mit dem Dateisystemformat können zu dieser Fehlermeldung führen: + Das Dateisystemformat, das Sie bei der Konfiguration angeben, ist nicht mit dem [Betriebssystem der Aufgabe](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RuntimePlatform.html) kompatibel. + Sie konfigurieren ein Amazon-EBS-Volume so, dass es aus einem Snapshot erstellt wird, und das Dateisystemformat des Snapshots ist nicht mit dem Betriebssystem der Aufgabe kompatibel. Für Volumes, die aus einem Snapshot erstellt wurden, müssen Sie denselben Dateisystemtyp angeben, den das Volume bei der Erstellung des Snapshots verwendet hat. Sie können die Container-Agent-Protokolle von Amazon ECS verwenden, um diese Fehlermeldung für EC2-Aufgaben zu beheben. Weitere Informationen finden Sie unter [Speicherorte von Amazon-ECS-Protokolldateien](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html) und [Amazon ECS Log Collector](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-logs-collector.html). # Amazon-EFS-Volumes mit Amazon ECS verwenden Amazon Elastic File System (Amazon EFS) stellt einen einfachen, skalierbaren Dateispeicher für die Verwendung mit Ihren Amazon-ECS-Aufgaben bereit. Mit Amazon EFS ist die Speicherkapazität elastisch. Sie wird automatisch erweitert oder verkleinert, wenn Sie Dateien hinzufügen oder entfernen. Ihre Anwendungen verfügen jederzeit über den jeweils erforderlichen Speicherplatz. Sie können Amazon EFS-Dateisysteme mit Amazon ECS verwenden, um Dateisystemdaten in Ihre gesamte Flotte von Container-Instances zu exportieren. Auf diese Weise haben alle Ihre Aufgaben Zugriff auf denselben persistenten Speicher, unabhängig von der Instance, auf der sie landen. Ihre Aufgabendefinitionen müssen auf Volume-Mounts auf der Container-Instance verweisen, um das Dateisystem verwenden zu können. Ein Tutorial finden Sie unter [Konfiguration von Amazon-EFS-Dateisystemen für Amazon ECS mit der Konsole](tutorial-efs-volumes.md). ## Überlegungen Bei der Verwendung von Amazon-EFS-Volumes sollte Folgendes berücksichtigt werden: + Bei Aufgaben, die in EC2 ausgeführt werden, wurde Unterstützung für das Amazon-EFS-Dateisystem als öffentliche Vorschau mit Amazon-ECS-optimierter AMI-Version `20191212` mit Container-Agent Version 1.35.0 hinzugefügt. Die Amazon-EFS-Dateisystemunterstützung erreichte jedoch die allgemeine Verfügbarkeit mit Amazon-ECS-optimierter AMI-Version `20200319` mit Containeragent Version 1.38.0, die die Amazon-EFS-Zugangspunkt- und IAM-Autorisierungsfeatures enthielt. Wir empfehlen die Verwendung der Amazon-ECS-optimierten AMI-Version `20200319` oder höher, um diese Features zu nutzen. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md). **Anmerkung** Wenn Sie Ihr eigenes AMI erstellen, müssen Sie den Containeragent 1.38.0 oder höher, `ecs-init`-Version 1.38.0-1 oder höher verwenden und die folgenden Befehle für Ihre Amazon-EC2-Instance ausführen, um das Amazon-ECS-Volume-Plugin zu aktivieren. Die Befehle hängen davon ab, ob Sie Amazon Linux 2 oder Amazon Linux als Basis-Image verwenden. Amazon Linux 2 ``` yum install amazon-efs-utils systemctl enable --now amazon-ecs-volume-plugin ``` Amazon Linux ``` yum install amazon-efs-utils sudo shutdown -r now ``` + Bei Aufgaben, die auf Fargate gehostet werden, werden Amazon-EFS-Dateisysteme von Plattformversion 1.4.0 oder höher (Linux) unterstützt. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md). + Bei der Verwendung von Amazon EFS Volumes für Aufgaben, die auf Fargate gehostet werden, erstellt Fargate einen Supervisor-Container erstellt, der für die Verwaltung des Amazon EFS Volumes zuständig ist. Der Supervisor-Container beansprucht nur eine kleine Menge des Arbeitsspeichers und CPU der Aufgabe. Der Supervisor-Container ist beim Abfragen des Endpunkts der Aufgabenmetadaten Version 4 sichtbar. Darüber hinaus ist er in CloudWatch Container Insights als Containername sichtbar. `aws-fargate-supervisor` Weitere Informationen zur Verwendung von EC2 finden Sie unter [Amazon-ECS-Aufgabenmetadaten-Endpunkt Version 4](task-metadata-endpoint-v4.md). Weitere Informationen zur Verwendung von Fargate finden Sie unter [Amazon-ECS-Aufgabenmetaden-Endpunkt Version 4 für Aufgaben in Fargate](task-metadata-endpoint-v4-fargate.md). + Verwenden von Amazon-EFS-Volumes oder Angeben eines `EFSVolumeConfiguration` wird auf externen Instances nicht unterstützt. + Die Verwendung von Amazon-EFS-Volumes wird für Aufgaben unterstützt, die in Amazon ECS Managed Instances ausgeführt werden. + Es wird empfohlen, den `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`-Parameter in der Agentenkonfigurationsdatei auf einen Wert festzulegen, der kleiner als der Standardwert ist (ca. 1 Stunde). Diese Änderung verhindert, dass die EFS-Mount-Anmeldeinformationen ablaufen, und ermöglicht die Bereinigung von Mounts, die nicht verwendet werden. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md). ## Amazon-EFS-Zugangspunkte verwenden Amazon EFS Access Points sind anwendungsspezifische Einstiegspunkte in ein EFS-Dateisystem, um den Anwendungszugriff auf freigegebene Datensätze zu verwalten. Weitere Informationen zu Amazon EFS Access Points und zur Steuerung des Zugriffs auf diese finden Sie unter [Arbeiten mit Amazon EFS Access Points](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) im *Amazon Elastic File System-Benutzerhandbuch*. Zugangspunkte können eine Benutzeridentität, einschließlich der POSIX-Gruppen des Benutzers, für alle Dateisystemanforderungen erzwingen, die über den Zugangspunkt erfolgen. Zugriffspunkte können auch ein anderes Stammverzeichnis für das Dateisystem erzwingen. Auf diese Weise können Clients nur auf Daten im angegebenen Verzeichnis oder in den dazugehörigen Unterverzeichnissen zugreifen. **Anmerkung** Beim Erstellen eines EFS-Zugriffspunkts geben Sie einen Pfad im Dateisystem an, der als Stammverzeichnis dienen soll. Wenn Sie auf das EFS-Dateisystem mit einer Zugriffspunkt-ID in Ihrer Amazon-ECS-Aufgabendefinition verweisen, muss das Stammverzeichnis ausgelassen oder auf `/` festgelegt sein. Das erzwingt den auf dem EFS Zugriffspunkt festgelegten Pfad. Mithilfe einer Amazon-ECS-Aufgaben-IAM-Rolle können Sie erzwingen, dass bestimmte Anwendungen einen bestimmten Zugriffspunkt verwenden. Durch die Kombination von IAM-Richtlinien mit Zugriffspunkten können Sie einen sicheren Zugriff auf bestimmte Datensätze für Ihre Anwendungen bereitstellen. Weitere Informationen zum Verwenden von Aufgaben-IAM-Rollen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md). # Bewährte Methoden für die Verwendung von Amazon-EFS-Volumes mit Amazon ECS Beachten Sie die folgenden Empfehlungen für bewährte Methoden, wenn Sie Amazon EFS mit Amazon ECS verwenden. ## Sicherheits- und Zugriffskontrollen für Amazon-EFS-Volumes Amazon EFS bietet Features zur Zugriffskontrolle, mit denen Sie sicherstellen können, dass die in einem Amazon-EFS-Dateisystem gespeicherten Daten sicher sind und nur für Anwendungen zugänglich sind, die sie benötigen. Sie können Daten schützen, indem Sie die Verschlüsselung im Ruhezustand und bei der Übertragung aktivieren. Weitere Informationen finden Sie unter [Datenverschlüsselung in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) im *Benutzerhandbuch zu Amazon Elastic File System*. Neben der Datenverschlüsselung können Sie Amazon EFS auch verwenden, um den Zugriff auf ein Dateisystem einzuschränken. Es gibt drei Möglichkeiten, die Zugriffskontrolle in EFS zu implementieren. + **Sicherheitsgruppen** – Mit Amazon-EFS-Mount-Zielen können Sie eine Sicherheitsgruppe konfigurieren, die verwendet wird, um Netzwerkdatenverkehr zuzulassen und abzulehnen. Sie können die an Amazon EFS angehängte Sicherheitsgruppe so konfigurieren, dass NFS-Datenverkehr (Port 2049) von der Sicherheitsgruppe zugelassen wird, die an Ihre Amazon-ECS-Instances angehängt ist bzw. der Amazon-ECS-Aufgabe, wenn Sie den `awsvpc`-Netzwerkmodus verwenden. + **IAM** – Sie können den Zugriff auf ein Amazon-EFS-Dateisystem mithilfe von IAM einschränken. Wenn sie konfiguriert sind, benötigen Amazon-ECS-Aufgaben eine IAM-Rolle für den Dateisystemzugriff, um ein EFS-Dateisystem einzubinden. Weitere Informationen finden Sie unter [IAM zur Steuerung des Datenzugriffs auf Dateisysteme](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html) im *Benutzerhandbuch für Amazon Elastic File System*. IAM-Richtlinien können auch vordefinierte Bedingungen erzwingen, z. B. die Anforderung, dass ein Client TLS verwendet, wenn er sich mit einem Amazon-EFS-Dateisystem verbindet. Weitere Informationen finden Sie unter [Amazon-EFS-Bedingungsschlüssel für Clients](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#efs-condition-keys-for-nfs) im *Benutzerhandbuch für Amazon Elastic File System*. + **Amazon-EFS-Zugangspunkte** – Amazon-EFS-Zugangspunkte sind anwendungsspezifische Einstiegspunkt in ein Amazon-EFS-Dateisystem. Sie können Zugangspunkte verwenden, um eine Benutzeridentität, einschließlich der POSIX-Gruppen des Benutzers, für alle Dateisystemanforderungen erzwingen, die über den Zugangspunkt erfolgen. Zugriffspunkte können auch ein anderes Stammverzeichnis für das Dateisystem erzwingen. Auf diese Weise können Clients nur auf Daten im angegebenen Verzeichnis oder in den dazugehörigen Unterverzeichnissen zugreifen. ### IAM-Richtlinien Sie können IAM-Richtlinien verwenden, um den Zugriff auf das Amazon-EFS-Dateisystem zu kontrollieren. Sie können die folgenden Aktionen für Clients festlegen, die über eine Dateisystemrichtlinie auf ein Dateisystem zugreifen. | Action | Description | | --- | --- | | `elasticfilesystem:ClientMount` | Ermöglicht den Nur-Lese-Zugriff auf ein Dateisystem. | | `elasticfilesystem:ClientWrite` | Bietet Schreibrechte für ein Dateisystem. | | `elasticfilesystem:ClientRootAccess` | Ermöglicht die Verwendung des Root-Benutzers beim Zugriff auf ein Dateisystem. | Sie müssen jede Aktion in einer Richtlinie angeben. Die Richtlinien können wie folgt definiert werden: + Clientbasiert – Fügen Sie die Richtlinie der Aufgabenrolle an Legen Sie die Option **IAM-Autorisierung** fest, wenn Sie die Aufgabendefinition erstellen. + Ressourcenbasiert – Hängen Sie die Richtlinie an das Amazon-EFS-Dateisystem an Wenn die ressourcenbasierte Richtlinie nicht existiert, wird bei der Erstellung des Dateisystems standardmäßig allen Prinzipalen (\$1) Zugriff gewährt. Wenn Sie die Option **IAM-Autorisierung** festlegen, führen wir die der Aufgabenrolle zugeordnete Richtlinie und die ressourcenbasierte Amazon-EFS-Richtlinie zusammen. Die Option **IAM-Autorisierung** übergibt die Aufgabenidentität (die Aufgabenrolle) mit der Richtlinie an Amazon EFS. Dadurch kann die ressourcenbasierte Amazon-EFS-Richtlinie einen Kontext für den in der Richtlinie angegebenen IAM-Benutzer oder die IAM-Rolle haben. Wenn Sie die Option nicht festlegen, identifiziert die Amazon-EFS-Richtlinie auf Ressourcenebene den IAM-Benutzer als „anonym“. Erwägen Sie die Implementierung aller drei Zugriffskontrollen in einem Amazon-EFS-Dateisystem, um maximale Sicherheit zu gewährleisten. Sie können beispielsweise die Sicherheitsgruppe, die einem Amazon-EFS-Mounting-Punkt zugeordnet ist, so konfigurieren, dass nur eingehender NFS-Datenverkehr von einer Sicherheitsgruppe zugelassen wird, die Ihrer Container-Instance oder Amazon-ECS-Aufgabe zugeordnet ist. Darüber hinaus können Sie Amazon EFS so konfigurieren, dass für den Zugriff auf das Dateisystem eine IAM-Rolle erforderlich ist, auch wenn die Verbindung aus einer zugelassenen Sicherheitsgruppe stammt. Schließlich können Sie Amazon-EFS-Zugangspunkte verwenden, um POSIX-Benutzerberechtigungen durchzusetzen und Stammverzeichnisse für Anwendungen anzugeben. Der folgende Ausschnitt aus der Aufgabendefinition zeigt, wie ein Amazon-EFS-Dateisystem mithilfe eines Zugangspunkts bereitgestellt wird. ``` "volumes": [ { "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" }, "transitEncryption": "ENABLED", "rootDirectory": "" }, "name": "my-filesystem" } ] ``` ## Leistung von Amazon-EBS-Volumes Amazon EFS bietet zwei Leistungsmodi: Die I/O. General Purpose is suitable for latency-sensitive applications such as content management systems and CI/CD tools. In contrast, Max I/O Dateisysteme General Purpose und Max eignen sich für Workloads wie Datenanalyse, Medienverarbeitung und maschinelles Lernen. Diese Workloads müssen parallel Vorgänge von Hunderten oder sogar Tausenden von Containern aus ausführen und erfordern den höchstmöglichen Gesamtdurchsatz und die höchstmöglichen IOPS. Weitere Informationen finden Sie unter [Amazon-EFS-Leistungsmodi](https://docs.aws.amazon.com/efs/latest/ug/performance.html#performancemodes) im *Benutzerhandbuch für Amazon Elastic File System*. Einige latenzempfindliche Workloads erfordern sowohl die höheren I/O Stufen, die der I/O Max-Performance-Modus bietet, als auch die niedrigere Latenz, die der Allzweck-Leistungsmodus bietet. Für diese Art von Workload empfehlen wir, mehrere Allzweck-Leistungsmodus-Dateisysteme zu erstellen. Auf diese Weise können Sie die Workload der Anwendung auf alle diese Dateisysteme verteilen, solange die Workload und die Anwendungen dies unterstützen können. ## Amazon-EFS-Volume-Durchsatz Allen Amazon-EFS-Dateisystemen ist ein gemessener Durchsatz zugeordnet, der entweder durch die unter *Bereitgestelltem Durchsatz* angegebene Menge des bereitgestellten Durchsatzes für Dateisysteme oder durch die unter *Bursting-Durchsatz* angegebene Menge der in der EFS-Speicherklasse Standard oder One Zone gespeicherten Daten für Dateisysteme bestimmt wird. Weitere Informationen finden Sie unter [Getakteter Durchsatz im Überblick](https://docs.aws.amazon.com/efs/latest/ug/performance.html#read-write-throughput) im *Benutzerhandbuch für Amazon Elastic File System*. Der Standard-Durchsatzmodus für Amazon-EFS-Dateisysteme ist der Bursting-Modus. Im Bursting-Modus wird der Durchsatz, der einem Dateisystem zur Verfügung steht, anhand des Wachstums des Dateisystems auf- oder abskaliert. Da dateibasierte Workloads typischerweise Spitzen haben, d. h. über kurze Zeiträume hohe Durchsatzraten und während der restlichen Zeit niedrige Durchsatzraten aufweisen, wurde Amazon EFS dafür entwickelt, über bestimmte Zeiträume Spitzenlasten zu hohen Durchsatzraten zu verarbeiten. Da viele Workloads sehr leseintensiv sind, werden Lesevorgänge außerdem im Verhältnis 1:3 zu anderen NFS-Vorgängen (wie Schreibvorgängen) gemessen. Alle Amazon EFS-Dateisysteme bieten eine konsistente Basisleistung von 50 MB/s für jedes TB Amazon EFS Standard- oder Amazon EFS One Zone-Speicher. Alle Dateisysteme (unabhängig von ihrer Größe) können MB/s. File systems with more than 1TB of EFS Standard or EFS One Zone storage can burst to 100 MB/s for each TB. Because read operations are metered at a 1:3 ratio, you can drive up to 300 MiBs/s für jedes TiB Lesedurchsatz auf 100 ansteigen. Wenn Sie Ihrem Dateisystem Daten hinzufügen, wird der maximale Durchsatz, der für das Dateisystem verfügbar ist, linear und automatisch mit Ihrem Speicher in der Speicherklasse Amazon EFS Standard skaliert. Wenn Sie mehr Durchsatz benötigen, als Sie mit Ihrer gespeicherten Datenmenge erreichen können, können Sie den bereitgestellten Durchsatz auf die spezifische Menge konfigurieren, die Ihre Workload benötigt. Der Dateisystemdurchsatz wird von allen Amazon-EC2-Instances, die mit einem Dateisystem verbunden sind, geteilt. Beispielsweise kann ein 1-TB-Dateisystem, das einen Durchsatz MB/s von 100% erreichen kann, MB/s aus einer einzigen Amazon EC2 EC2-Instance 100 Laufwerke mit jeweils 10 MB/s erzeugen. Weitere Informationen finden Sie unter [Amazon-EFS-Leistung](https://docs.aws.amazon.com/efs/latest/ug/performance.html) im *Benutzerhandbuch für Amazon Elastic File System*. ## Optimierung der Kosten für Amazon-EFS-Volumes Amazon EFS vereinfacht die Speicherskalierung für Sie. Amazon-EFS-Dateisysteme wachsen automatisch, wenn Sie mehr Daten hinzufügen. Besonders beim Amazon-EFS-*Bursting-Durchsatz*-Modus wird der Durchsatz in Amazon EFS skaliert, wenn die Größe Ihres Dateisystems in der Standardspeicherklasse zunimmt. Um den Durchsatz zu verbessern, ohne zusätzliche Kosten für den bereitgestellten Durchsatz auf einem EFS-Dateisystem zu zahlen, können Sie ein Amazon-EFS-Dateisystem mit mehreren Anwendungen gemeinsam nutzen. Mit Amazon-EFS-Zugangspunkten können Sie die Speicherisolierung in freigegebenen Amazon-EFS-Dateisystemen implementieren. Auf diese Weise können die Anwendungen, obwohl sie immer noch dasselbe Dateisystem verwenden, nicht auf Daten zugreifen, es sei denn, Sie autorisieren sie. Während Ihre Daten wachsen, hilft Ihnen Amazon EFS dabei, Dateien, auf die selten zugegriffen wird, automatisch in eine niedrigere Speicherklasse zu verschieben. Die Amazon EFS Standard-Infrequent Access (IA)-Speicherklasse reduziert die Speicherkosten für Dateien, auf die nicht täglich zugegriffen wird. Dies erfolgt, ohne die hohe Verfügbarkeit, hohe Zuverlässigkeit, Elastizität und POSIX-Dateisystemzugriffe von Amazon EFS zu beeinträchtigen. Weitere Informationen finden Sie unter [EFS-Speicherklassen](https://docs.aws.amazon.com/efs/latest/ug/features.html) im *Benutzerhandbuch für Amazon Elastic File System*. Erwägen Sie die Verwendung von Amazon-EFS-Lebenszyklusrichtlinien, um automatisch Geld zu sparen, indem Sie selten aufgerufene Dateien in den Amazon-EFS-IA-Speicher verschieben. Weitere Informationen finden Sie unter [Amazon-EFS-Lebenszyklusverwaltung](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) im *Benutzerhandbuch zu Amazon Elastic File System*. Bei der Erstellung eines Amazon-EFS-Dateisystems können Sie wählen, ob Amazon EFS Ihre Daten über mehrere Availability Zones (Standard) hinweg repliziert oder Ihre Daten redundant in einer einzigen Availability Zone speichert. Die Speicherklasse Amazon EFS One Zone kann die Speicherkosten im Vergleich zur Speicherklasse Amazon EFS Standard erheblich senken. Erwägen Sie die Verwendung der Speicherklasse Amazon EFS One Zone für Workloads, die keine Multi-AZ-Resilienz erfordern. Sie können die Speicherkosten für Amazon EFS One Zone weiter senken, indem Sie Dateien, auf die selten zugegriffen wird, nach Amazon EFS One Zone-Infrequent Access verschieben. Weitere Informationen finden Sie unter [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/). ## Datenschutz mit Amazon-EFS-Volumes Amazon EFS speichert für Dateisysteme, die Standard-Speicherklassen verwenden, Ihre Daten redundant über mehrere Availability Zones hinweg. Wenn Sie Amazon-EFS-One-Zone-Speicherklassen auswählen, werden Ihre Daten redundant in einer einzigen Availability Zone gespeichert. Darüber hinaus ist Amazon EFS so konzipiert, dass es über einen Zeitraum von einem Jahr eine Haltbarkeit von 99,999999999 % (11 9er) bietet. Wie in jeder Umgebung ist es eine bewährte Methode, ein Backup zu erstellen und Schutzmaßnahmen gegen versehentliches Löschen zu treffen. Für Amazon EFS-Daten umfasst diese bewährte Methode ein funktionierendes, regelmäßig getestetes Backup mit AWS Backup. Dateisysteme, die die Speicherklasse Amazon EFS One Zone verwenden, sind so konfiguriert, dass Dateien bei der Erstellung des Dateisystems standardmäßig automatisch gesichert werden, sofern Sie diese Funktion nicht deaktivieren. Weitere Informationen finden Sie unter [Sichern von EFS-Dateisystemen](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) im *Benutzerhandbuch für Amazon Elastic File System*. # Ein Amazon-EFS-Dateisystems in einer Amazon-ECS-Aufgabendefinition angeben Um Amazon EFS-Dateisystem-Volumes für Ihre Container zu verwenden, müssen Sie die Volume- und Mounting-Punkt-Konfigurationen in der Aufgabendefinition angeben. Das folgende JSON-Codefragment der Aufgabendefinition zeigt die Syntax für die Objekte `volumes` und `mountPoints` für einen Container. ``` { "containerDefinitions": [ { "name": "container-using-efs", "image": "public.ecr.aws/amazonlinux/amazonlinux:latest", "entryPoint": [ "sh", "-c" ], "command": [ "ls -la /mount/efs" ], "mountPoints": [ { "sourceVolume": "myEfsVolume", "containerPath": "/mount/efs", "readOnly": true } ] } ], "volumes": [ { "name": "myEfsVolume", "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "rootDirectory": "/path/to/my/data", "transitEncryption": "ENABLED", "transitEncryptionPort": integer, "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" } } } ] } ``` `efsVolumeConfiguration` Typ: Objekt 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-Zugriffspunkt in `authorizationConfig` angegeben ist, muss der Stammverzeichnis-Parameter entweder weggelassen oder auf `/` festgelegt werden, was erzwingt, dass der Pfad für den EFS-Zugriffspunkt festgelegt wird. `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 Transit-Verschlüsselungsport angeben, wird die Port-Auswahlstrategie verwendet, die der Amazon EFS-Mount-Helfer 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: Objekt 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). # Konfiguration von Amazon-EFS-Dateisystemen für Amazon ECS mit der Konsole Erfahren Sie, wie Sie Amazon Elastic File System (Amazon EFS)-Dateisysteme mit Amazon ECS verwenden. ## Schritt 1: Erstellen eines Amazon-ECS-Clusters Führen Sie die folgenden Schritte aus, um einen Amazon-ECS-Cluster zu erstellen. **So erstellen Sie einen neuen Cluster (Amazon ECS-Konsole)** Bevor Sie beginnen, weisen Sie die entsprechende IAM-Berechtigung zu. Weitere Informationen finden Sie unter [Beispiele für Amazon-ECS-Cluster](security_iam_id-based-policy-examples.md#IAM_cluster_policies). 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 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** `EFS-tutorial` für den Cluster-Namen ein. 1. (Optional) Um die VPC und Subnetze zu ändern, in denen Ihre Aufgaben und Services gelauncht werden, führen Sie unter **Networking** (Netzwerk) einen der folgenden Vorgänge aus: + Um ein Subnetz zu entfernen, wählen Sie unter **Subnets** (Subnetze) **X** für jedes Subnetz, das Sie entfernen möchten. + Um zu einer anderen VPC als der **Standard**-VPC zu wechseln, wählen Sie unter **VPC** eine vorhandene **VPC** und dann unter **Subnets** (Subnetze) jedes Subnetz aus. 1. Um Ihrem Cluster Amazon-EC2-Instances hinzuzufügen, erweitern Sie **Infrastruktur** und wählen Sie dann **Amazon-EC2-Instances** aus. Konfigurieren Sie als Nächstes die Auto-Scaling-Gruppe, die als Kapazitätsanbieter fungiert: 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** die Option Amazon Linux 2 aus. + Wählen Sie unter **EC2 instance type (EC2-Instance-Typ)** die Option`t2.micro` aus. Wählen Sie für **SSH key pair** (SSH-Schlüsselpaar) das Paar aus, das Ihre Identität nachweist, wenn Sie eine Verbindung zur Instance herstellen. + Geben Sie für **Kapazität** den Wert `1` ein. 1. Wählen Sie **Erstellen** aus. ## Schritt 2: Eine Sicherheitsgruppe für Amazon-EC2-Instances und das Amazon-EFS-Dateisystem erstellen In diesem Schritt erstellen Sie eine Sicherheitsgruppe für Ihre Amazon-EC2-Instances, die eingehenden Netzwerkverkehr auf Port 80 zulässt, und Ihr Amazon-EFS-Dateisystem, das den eingehenden Zugriff von Ihren Container-Instances erlaubt. Erstellen Sie eine Sicherheitsgruppe für Ihre Amazon-EC2-Instances mit den folgenden Optionen: + **Sicherheitsgruppenname** – Ein eindeutiger Name für Ihre Sicherheitsgruppe. + **VPC** – Die VPC, die Sie zuvor für Ihr Cluster festgelegt haben. + **Regel für eingehenden Datenverkehr** + **Typ** – **HTTP** + **Quelle** – **0.0.0.0/0**. Erstellen Sie eine Sicherheitsgruppe für Ihr Amazon-EFS-Dateisystem mit den folgenden Optionen: + **Sicherheitsgruppenname** – Ein eindeutiger Name für Ihre Sicherheitsgruppe. Beispiel, `EFS-access-for-sg-dc025fa2`. + **VPC** – Die VPC, die Sie zuvor für Ihr Cluster festgelegt haben. + **Regel für eingehenden Datenverkehr** + **Typ** – **NFS** + **Quelle** – **Benutzerdefiniert** mit der ID der Sicherheitsgruppe, die Sie für Ihre Instances erstellt haben. Informationen zum Erstellen einer Sicherheitsgruppe finden Sie unter [Erstellen einer Sicherheitsgruppe für Ihre Amazon-EC2-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html) im *Benutzerhandbuch für Amazon EC2*. ## Schritt 3: Erstellen eines Amazon EFS-Dateisystems In diesem Schritt erstellen Sie ein Amazon EFS-Dateisystem. **Erstellen eines Amazon EFS Dateisystems für Amazon-ECS-Aufgaben.** 1. Öffnen Sie die Amazon Elastic File System-Konsole unter [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/). 1. Wählen Sie **Create file system (Dateisystem erstellen)** aus. 1. Geben Sie einen Namen für Ihr Dateisystem ein und wählen Sie dann die VPC aus, in der Ihre Container-Instances gehostet werden. Standmäßig erhält jedes Subnetz in der angegebenen VPC ein Mountingziel, das die Standardsicherheitsgruppe für diese VPC verwendet. Wählen Sie dann **Anpassen** aus. **Anmerkung** Dieses Tutorial geht davon aus, dass Ihr Amazon-EFS-Dateisystem, Ihr Amazon-ECS-Cluster, Ihre Container-Instances und Ihre Aufgaben sich in derselben VPC befinden. Weitere Informationen zum Mounten eines Dateisystems von einer anderen VPC finden Sie unter [Schrittweise Anleitung: Mounten eines Dateisystems aus einer anderen VPC](https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html) im *Amazon-EFS-Benutzerhandbuch*. 1. Konfigurieren Sie auf der Seite mit den **Dateisystemeinstellungen** optionale Einstellungen und wählen Sie dann unter **Leistungseinstellungen** den **Bursting-Durchsatzmodus** für Ihr Dateisystem aus. Nachdem Sie die Einstellungen konfiguriert haben, wählen Sie **Weiter** aus. 1. (Optional) Fügen Sie Tags für Ihr Dateisystem hinzu. Sie können beispielweise einen eindeutigen Namen für das Dateisystem angeben, indem Sie den entsprechenden Namen in der Spalte **Value** neben dem Schlüssel **Name** eingeben. 1. (Optional) Aktivieren Sie die Lebenszyklusverwaltung, um Kosten bei selten genutztem Speicher zu sparen. Weitere Informationen finden Sie unter [EFS lifecycle management (EFS-Lebenszyklusverwaltung)](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) im *Amazon Elastic File System-Benutzerhandbuch*. 1. (Optional) Aktivieren Sie die Verschlüsselung. Wählen Sie das Kontrollkästchen aus, um die Verschlüsselung Ihres Amazon EFS-Dateisystems im Ruhezustand zu aktivieren. 1. Ersetzen Sie auf der Seite **Netzwerkzugriff** unter **Mount-Ziele** die bestehende Sicherheitsgruppenkonfiguration für jede Availability Zone durch die Sicherheitsgruppe, die Sie für das Dateisystem in [Schritt 2: Eine Sicherheitsgruppe für Amazon-EC2-Instances und das Amazon-EFS-Dateisystem erstellen](#efs-security-group) erstellt haben, und wählen Sie dann **Weiter** aus. 1. Sie müssen für dieses Tutorial keine **Dateisystemrichtlinie** konfigurieren, sodass Sie den Abschnitt überspringen können, indem Sie **Weiter** wählen. 1. Überprüfen Sie die Dateisystemoptionen und wählen Sie **Erstellen**, um den Prozess abzuschließen. 1. Notieren Sie sich auf dem Bildschirm **Dateisysteme** die **Dateisystem-ID**. Im nächsten Schritt referenzieren Sie diesen Wert in der Amazon-ECS-Aufgabendefinition. ## Schritt 4: Hinzufügen von Inhalten zum Amazon EFS-Dateisystem In diesem Schritt mounten Sie das Amazon EFS-Dateisystem einer Amazon-EC2-Instance und fügen Inhalte hinzu. Dies ist für Testzwecke in diesem Tutorial gedacht, um die persistente Natur der Daten zu veranschaulichen. Wenn Sie dieses Feature verwenden, verwenden Sie normalerweise Ihre Anwendung oder eine andere Methode, mit der Sie Daten in Ihr Amazon-EFS-Dateisystem schreiben. **So erstellen Sie eine Amazon-EC2-Instance und stellen das Amazon EFS-Dateisystem bereit** 1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Wählen Sie **Launch Instance** aus. 1. Wählen Sie unter **Anwendungs- und Betriebssystem-Images (Amazon Machine Image)** das **Amazon Linux 2 AMI (HVM)**. 1. Behalten Sie unter **Instance-Typ** den Standard-Instance-Typ, `t2.micro` bei. 1. Wählen Sie unter **Schlüsselpaar (Anmeldung)** ein Schlüsselpaar für den SSH-Zugriff auf die Instance aus. 1. Wählen Sie unter **Netzwerkeinstellungen**, die VPC aus, die Sie für Ihr Amazon-EFS-Dateisystem und Ihren Amazon-ECS-Cluster angegeben haben. Wählen Sie ein Subnetz und die Instance-Sicherheitsgruppe aus, die in [Schritt 2: Eine Sicherheitsgruppe für Amazon-EC2-Instances und das Amazon-EFS-Dateisystem erstellen](#efs-security-group) erstellt wurde. Konfigurieren Sie die Sicherheitsgruppe der Instance. Vergewissern Sie sich, dass **Öffentliche IP automatisch zuweisen** aktiviert ist. 1. Wählen Sie unter **Speicher konfigurieren** die Schaltfläche **Bearbeiten** für Dateisysteme und wählen Sie dann **EFS**. Wählen Sie das Dateisystem aus, das Sie in [Schritt 3: Erstellen eines Amazon EFS-Dateisystems](#efs-create-filesystem) erstellt haben. Sie können optional den Mounting-Punkt ändern oder den Standardwert belassen. **Wichtig** Sie müssen ein Subnetz auswählen, bevor Sie ein Dateisystem zur Instance hinzufügen können. 1. Deaktivieren Sie die Option **Sicherheitsgruppen automatisch erstellen und anhängen**. Lassen Sie das andere Kontrollkästchen aktiviert. Wählen Sie **Add shared file system** (Freigegebenes Dateisystem hinzufügen) aus. 1. Stellen Sie unter **Advanced Details** (Erweiterte Details) sicher, dass das Benutzerdatenskript automatisch mit den Mounting-Schritten des Amazon EFS-Dateisystems gefüllt wird. 1. Stellen Sie unter **Zusammenfassung** sicher, dass die **Anzahl der Instances** **1** beträgt. Wählen Sie **Launch Instance (Instance starten)** aus. 1. Wählen Sie auf der Seite **Eine Instance starten** die Option **Alle Instances anzeigen**, um den Status Ihrer Instances zu sehen. Anfänglich ist der **Instance-Zustand** `PENDING`. Nachdem sich der Status auf `RUNNING` geändert hat und die Instance alle Statusprüfungen bestanden hat, ist die Instance einsatzbereit. Stellen Sie jetzt eine Verbindung zur Amazon-EC2-Instance her und fügen dem Amazon EFS Dateisystem Inhalt hinzu. **So stellen Sie eine Verbindung zur Amazon-EC2-Instance her und fügen dem Amazon EFS Dateisystem Inhalt hinzu** 1. Sie SSH auf die von Ihnen erstellte Amazon-EC2-Instance. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer Linux-Instance mit SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html) im *Amazon-EC2-Benutzerhandbuch*. 1. Führen Sie im Terminalfenster den Befehl **df -T** aus, um zu überprüfen, ob das Amazon-EFS-Dateisystem gemountet wurde. In der folgenden Ausgabe haben wir das Mounting des Amazon EFS-Dateisystems hervorgehoben. ``` $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on devtmpfs devtmpfs 485468 0 485468 0% /dev tmpfs tmpfs 503480 0 503480 0% /dev/shm tmpfs tmpfs 503480 424 503056 1% /run tmpfs tmpfs 503480 0 503480 0% /sys/fs/cgroup /dev/xvda1 xfs 8376300 1310952 7065348 16% / 127.0.0.1:/ nfs4 9007199254739968 0 9007199254739968 0% /mnt/efs/fs1 tmpfs tmpfs 100700 0 100700 0% /run/user/1000 ``` 1. Navigieren Sie zu dem Verzeichnis, in dem das Amazon EFS-Dateisystem eingehängt ist. Im obigen Beispiel ist es `/mnt/efs/fs1`. 1. Erstellen Sie eine Datei mit dem Namen `index.html` und dem folgenden Inhalt: ```You are using an Amazon EFS file system for persistent container storage.
``` ## Schritt 5: Erstellen einer Aufgabendefinition Die folgende Aufgabendefinition erstellt ein Daten-Volume mit dem Namen `efs-html`. Der `nginx`-Container mountet das Host-Daten-Volume im NGINX-Stammverzeichnis, `/usr/share/nginx/html`. **So erstellen Sie eine neue Aufgabendefinition mithilfe der 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 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. Kopieren Sie im Feld JSON-Editor den folgenden JSON-Text und fügen Sie ihn ein, wobei Sie das `fileSystemId` durch die ID Ihres Amazon-EFS-Dateisystems ersetzen. ``` { "containerDefinitions": [ { "memory": 128, "portMappings": [ { "hostPort": 80, "containerPort": 80, "protocol": "tcp" } ], "essential": true, "mountPoints": [ { "containerPath": "/usr/share/nginx/html", "sourceVolume": "efs-html" } ], "name": "nginx", "image": "public.ecr.aws/docker/library/nginx:latest" } ], "volumes": [ { "name": "efs-html", "efsVolumeConfiguration": { "fileSystemId": "fs-1324abcd", "transitEncryption": "ENABLED" } } ], "family": "efs-tutorial", "executionRoleArn":"arn:aws:iam::111122223333:role/ecsTaskExecutionRole" } ``` **Anmerkung** Für die IAM-Rolle zur Ausführung von Amazon-ECS-Aufgaben sind keine speziellen Amazon-EFS-bezogenen Berechtigungen erforderlich, um ein Amazon-EFS-Dateisystem zu mounten. Wenn keine ressourcenbasierte Amazon-EFS-Richtlinie existiert, wird bei der Erstellung des Dateisystems standardmäßig allen Prinzipalen (\$1) Zugriff gewährt. Die Amazon-ECS-Aufgabenrolle ist nur erforderlich, wenn „EFS-IAM-Autorisierung“ in der Amazon-ECS-Aufgabendefinition aktiviert ist. Wenn diese Option aktiviert ist, muss der Identität der Aufgabenrolle in der ressourcenbasierten Amazon-EFS-Richtlinie Zugriff auf das Amazon-EFS-Dateisystem gewährt werden, und der anonyme Zugriff sollte deaktiviert sein. 1. Wählen Sie **Erstellen** aus. ## Schritt 6: Eine Aufgabe ausführen und die Ergebnisse anzeigen Nachdem Ihr Amazon EFS-Dateisystem erstellt wurde und Webinhalte für den NGINX-Container bereitgestellt werden können, können Sie eine Aufgabe mithilfe der von Ihnen erstellten Aufgabendefinition ausführen. Der NGINX-Webserver stellt eine einfache HTML-Seite bereit. Wenn Sie den Inhalt in Ihrem Amazon EFS-Dateisystem aktualisieren, werden diese Änderungen an alle weiteren Container weitergegeben, auf denen dieses Dateisystem ebenfalls gemountet ist. Die Aufgabe wird in dem Subnetz ausgeführt, das Sie für den Cluster definiert haben. **So führen Sie eine Aufgabe aus und zeigen die Ergebnisse mit der Konsole an** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Wählen Sie auf der Seite **Clusters** den Cluster aus, der die eigenständige Aufgabe ausführen soll. Bestimmen Sie die Ressource, von der aus Sie den Service starten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. (Optional) Wählen Sie aus, wie Ihre geplante Aufgabe auf Ihre Cluster-Infrastruktur aufgeteilt ist. Erweitern Sie die **Compute configuration** (Datenverarbeitungskonfiguration) und tun Sie folgendes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. Für **Anwendungstyp**, wählen Sie **Aufgabe** aus. 1. Wählen Sie für **Aufgabendefinition** die `efs-tutorial`-Aufgabendefinition aus, die Sie zuvor erstellt haben. 1. Geben Sie für **Gewünschte Aufgaben** `1` ein. 1. Wählen Sie **Erstellen** aus. 1. Wählen Sie auf der Seite **Cluster** die Registerkarte **Infrastruktur**. 1. Wählen Sie unter **Container-Instances** die Container-Instance aus, zu der Sie eine Verbindung herstellen möchten. 1. Notieren Sie auf der Seite **Container-Instance** unter **Netzwerk** die **öffentliche IP-Adresse** für Ihre Instance. 1. Öffnen Sie einen Browser und geben Sie die öffentliche IP-Adresse ein. Sie sollten folgende Meldung sehen: ``` It works! You are using an Amazon EFS file system for persistent container storage. ``` **Anmerkung** Wenn Sie die Meldung nicht sehen, vergewissern Sie sich, dass die Sicherheitsgruppe für Ihre Container-Instance den eingehenden Netzwerkverkehr auf Port 80 und die Sicherheitsgruppe für Ihr Dateisystem den eingehenden Zugriff von der Container-Instance erlaubt. # FSx Für Windows-Dateiserver-Volumes mit Amazon ECS verwenden FSx for Windows File Server bietet vollständig verwaltete Windows-Dateiserver, die von einem Windows-Dateisystem unterstützt werden. Wenn Sie den Dateiserver FSx für Windows zusammen mit ECS verwenden, können Sie Ihre Windows-Aufgaben mit persistentem, verteiltem, gemeinsam genutztem, statischem Dateispeicher ausstatten. Weitere Informationen finden Sie unter [Was ist FSx für Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) . **Anmerkung** EC2-Instances, die das Amazon ECS-optimierte Windows Server 2016 Full AMI verwenden, unterstützen Windows File Server FSx ECS-Task-Volumes nicht. Sie können nicht FSx für Windows File Server-Volumes in einer Windows-Container-On-Fargate-Konfiguration verwenden. Stattdessen können Sie [Container so ändern, dass sie beim Startup gemounted werden](https://aws.amazon.com/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/). Sie können FSx Windows File Server verwenden, um Windows-Workloads bereitzustellen, die Zugriff auf gemeinsam genutzten externen Speicher, hochverfügbaren regionalen Speicher oder Speicher mit hohem Durchsatz erfordern. Sie können ein oder mehrere Dateisystem-Volumes FSx für Windows File Server in einen Amazon ECS-Container einbinden, der auf einer Amazon ECS-Windows-Instance ausgeführt wird. Sie können Dateisystem-Volumes FSx für Windows File Server zwischen mehreren Amazon ECS-Containern innerhalb einer einzigen Amazon ECS-Aufgabe gemeinsam nutzen. Um die Verwendung von FSx für Windows File Server mit ECS zu ermöglichen, fügen Sie die Dateisystem-ID FSx für Windows File Server und die zugehörigen Informationen in eine Aufgabendefinition ein. Das wird im folgenden JSON-Snippet-Beispiel für Aufgabendefinition veranschaulicht. Bevor Sie eine Aufgabendefinition erstellen und ausführen, benötigen Sie Folgendes. + Eine ECS-Windows EC2-Instance, die mit einer gültigen Domain verbunden ist. Diese kann von einem [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), On-Premises-Active-Directory oder selbstgehosteten Active Directory in Amazon EC2 gehostet werden. + Ein AWS Secrets Manager geheimer oder Systems Manager Manager-Parameter, der die Anmeldeinformationen enthält, die verwendet werden, um der Active Directory-Domäne beizutreten und das Dateisystem FSx für Windows File Server anzuhängen. Bei den Anmeldeinformationswerten handelt es sich um den Namen und das Kennwort, die Sie beim Erstellen von Active Directory eingegeben haben. Ein dazugehöriges Tutorial finden Sie unter [Erfahren Sie, wie Sie Dateisysteme FSx für Windows File Server für Amazon ECS konfigurieren](tutorial-wfsx-volumes.md). ## Überlegungen Beachten Sie bei der Verwendung von Volumes FSx für Windows-Dateiserver Folgendes: + FSx for Windows File Server Server-Volumes werden von Amazon ECS auf Windows Amazon EC2-Instances nativ unterstützt — Amazon ECS verwaltet den Mount automatisch über die Aufgabendefinitionskonfiguration. Auf Amazon EC2 EC2-Linux-Instances kann Amazon ECS FSx for Windows File Server Server-Volumes nicht automatisch über Aufgabendefinitionen mounten. Sie können jedoch manuell eine FSx for Windows File Server Server-Dateifreigabe auf einer Linux EC2-Instance auf Host-Ebene mounten und diesen Pfad dann per Bind-Mounten in Ihre Amazon ECS-Container einbinden. Weitere Informationen finden Sie unter Mounten [von FSx Amazon-Dateifreigaben unter Linux](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/map-shares-linux.html). **Wichtig** Dies ist eine selbstverwaltete Konfiguration. Anleitungen zum Mounten und Verwalten von FSx Windows File Server-Dateifreigaben unter Linux finden Sie in der [Dokumentation FSx für Windows-Dateiserver](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/). **Wichtig** Wenn Sie eine manuell gemountete FSx for Windows File Server Server-Freigabe auf Linux EC2-Instances verwenden, arbeiten Amazon ECS und FSx für Windows File Server unabhängig voneinander — Amazon ECS überwacht den FSx Amazon-Mount nicht und FSx für Windows File Server werden keine Amazon ECS-Aufgabenplatzierung oder Lebenszyklusereignisse verfolgt. Sie sind dafür verantwortlich, die Netzwerkerreichbarkeit zwischen Ihren Amazon ECS-Container-Instances und dem FSx Amazon-Dateisystem sicherzustellen, Mount-Integritätsprüfungen zu implementieren und die Logik für die Wiederverbindung zu handhaben, um Failover-Ereignisse zu tolerieren. + FSx für Windows File Server mit Amazon ECS wird nicht unterstützt AWS Fargate. + FSx für Windows File Server mit Amazon ECS wird auf Amazon ECS Managed Instances nicht unterstützt. + FSx für Windows File Server mit Amazon ECS mit `awsvpc` Netzwerkmodus ist Version `1.54.0` oder höher des Container-Agents erforderlich. + Die maximale Anzahl von Laufwerksbuchstaben, die für eine Amazon-ECS-Aufgabe verwendet werden können, beträgt 23. Jeder Aufgabe mit einem Volume FSx für Windows File Server wird ein Laufwerksbuchstabe zugewiesen. + Die Bereinigungszeit der Aufgabenressource beträgt standardmäßig 3 Stunden nach Beendigung der Aufgabe. Eine Dateizuordnung, die von einer Aufgabe erstellt wurde, bleibt für 3 Stunden bestehen, selbst wenn keine Aufgaben sie verwenden. Die standardmäßige Bereinigungszeit kann mithilfe der Amazon-ECS-Umgebungsvariablen `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` konfiguriert werden. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md). + Aufgaben werden normalerweise nur in derselben VPC ausgeführt wie das Dateisystem FSx für Windows File Server. Eine VPC-übergreifende Unterstützung ist jedoch möglich, wenn über VPC-Peering eine Netzwerkkonnektivität zwischen der Amazon ECS-Cluster-VPC und dem FSx Dateisystem für Windows File Server besteht. + Sie steuern den Zugriff auf ein FSx for Windows File Server-Dateisystem auf Netzwerkebene, indem Sie die VPC-Sicherheitsgruppen konfigurieren. Nur Aufgaben, die auf EC2-Instances gehostet werden, die zur Active Directory-Domäne mit korrekt konfigurierten Active Directory-Sicherheitsgruppen gehören, können auf die Dateifreigabe für Windows File Server zugreifen. FSx Wenn die Sicherheitsgruppen falsch konfiguriert sind, kann Amazon ECS die Aufgabe nicht starten und folgende Fehlermeldung wird angezeigt: `unable to mount file system fs-id`. + FSx for Windows File Server ist in AWS Identity and Access Management (IAM) integriert, um die Aktionen zu steuern, die Ihre IAM-Benutzer und -Gruppen speziell FSx für Windows-Dateiserver-Ressourcen ausführen können. Mit der Client-Autorisierung können Kunden IAM-Rollen definieren, die den Zugriff auf bestimmte Dateisysteme FSx für Windows File Server zulassen oder verweigern, optional nur Lesezugriff erfordern und optional den Root-Zugriff auf das Dateisystem vom Client aus zulassen oder verbieten. Weitere Informationen finden Sie unter [Sicherheit](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/security.html) im Amazon FSx Windows-Benutzerhandbuch. # Bewährte Methoden für FSx die Verwendung von Windows File Server mit Amazon ECS Beachten Sie die folgenden Best-Practice-Empfehlungen, wenn Sie FSx Windows File Server mit Amazon ECS verwenden. ## Sicherheits- und Zugriffskontrollen FSx für Windows File Server FSx Der Dateiserver für Windows bietet die folgenden Funktionen zur Zugriffskontrolle, mit denen Sie sicherstellen können, dass die in einem Dateisystem FSx für Windows File Server gespeicherten Daten sicher sind und nur für Anwendungen zugänglich sind, die sie benötigen. ### Datenverschlüsselung FSx für Windows File Server-Volumes FSx für Windows File Server unterstützt zwei Formen der Verschlüsselung für Dateisysteme. Diese sind die Verschlüsselung von Daten während der Übertragung und im Ruhezustand. Die Verschlüsselung von Daten während der Übertragung wird auf Dateifreigaben unterstützt, die einer Container-Instance zugeordnet sind, die das SMB-Protokoll 3.0 oder neuer unterstützt. Die Verschlüsselung von Daten im Ruhezustand wird automatisch aktiviert, wenn ein FSx Amazon-Dateisystem erstellt wird. Amazon verschlüsselt Daten während der Übertragung FSx automatisch mithilfe der SMB-Verschlüsselung, wenn Sie auf Ihr Dateisystem zugreifen, ohne dass Sie Ihre Anwendungen ändern müssen. Weitere Informationen finden Sie unter [Datenverschlüsselung FSx in Amazon](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html) im *Amazon FSx for Windows File Server-Benutzerhandbuch*. ### Verwenden Sie Windows ACLs für die Zugriffskontrolle auf Ordnerebene Die Windows Amazon EC2-Instance greift mithilfe von Active Directory-Anmeldeinformationen auf FSx Amazon-Dateifreigaben zu. Sie verwendet standardmäßige Windows-Zugriffskontrolllisten (ACLs) für eine detaillierte Zugriffskontrolle auf Datei- und Ordnerebene. Sie können mehrere Anmeldeinformationen erstellen, jeweils für einen bestimmten Ordner innerhalb der Freigabe, der einer bestimmten Aufgabe zugeordnet ist. Im folgenden Beispiel hat die Aufgabe mithilfe einer in Secrets Manager gespeicherten Anmeldeinformationen Zugriff auf den Ordner `App01`. Der Amazon-Ressourcenname (ARN) ist `1234`. ``` "rootDirectory": "\\path\\to\\my\\data\App01", "credentialsParameter": "arn-1234", "domain": "corp.fullyqualified.com", ``` In einem anderen Beispiel hat eine Aufgabe mithilfe eines im Secrets Manager gespeicherten Anmeldeinformationen Zugriff auf den Ordner `App02`. Ihr ARN lautet `6789`. ``` "rootDirectory": "\\path\\to\\my\\data\App02", "credentialsParameter": "arn-6789", "domain": "corp.fullyqualified.com", ``` # Geben Sie ein Dateisystem FSx für Windows File Server in einer Amazon ECS-Aufgabendefinition an Um Dateisystemvolumes FSx für Ihre Container für Windows File Server zu verwenden, geben Sie die Volume- und Bereitstellungspunktkonfigurationen in Ihrer Aufgabendefinition an. Das folgende JSON-Codefragment der Aufgabendefinition zeigt die Syntax für die Objekte `volumes` und `mountPoints` für einen Container. ``` { "containerDefinitions": [ { "entryPoint": [ "powershell", "-Command" ], "portMappings": [], "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value '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. ```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).