Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Anwendungsfälle für Amazon-ECS-Aufgabendefinitionen
<a name="use-cases"></a>

Erfahren Sie mehr darüber, wie Sie Aufgabendefinitionen für verschiedene AWS Dienste und Funktionen schreiben.

Abhängig von Ihrem Workload müssen bestimmte Aufgabendefinitionsparameter festgelegt werden. Außerdem müssen Sie für EC2 bestimmte Instances auswählen, die für den Workload entwickelt wurden.

**Topics**
+ [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md)
+ [Amazon-ECS-Aufgabendefinitionen für Workloads zur Video-Transkodierung](ecs-vt1.md)
+ [Amazon ECS-Aufgabendefinitionen für AWS Neuron-Workloads für maschinelles Lernen](ecs-inference.md)
+ [Amazon-ECS-Aufgabendefinitionen für Deep-Learning-Instances](ecs-dl1.md)
+ [Amazon-ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads](ecs-arm64.md)
+ [Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md)
+ [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md)
+ [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md)
+ [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md)
+ [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md)

# Amazon-ECS-Aufgabendefinitionen für GPU-Workloads
<a name="ecs-gpu"></a>

Amazon ECS unterstützt Workloads, die GPUs verwenden, wenn Sie Cluster mit Container-Instances erstellen, die GPUs unterstützen. GPU-basierte Amazon EC2 EC2-Container-Instances, die die Instance-Typen p2, p3, p5, g3, g4 und g5 verwenden, bieten Zugriff auf NVIDIA. GPUs Weitere Informationen finden Sie unter [Linux-beschleunigte Computing-Instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) im *Benutzerhandbuch für Instance-Typen von Amazon EC2*.

Amazon ECS bietet eine GPU-optimierte AMI, die mit vorkonfigurierten NVIDIA-Kernel-Treibern und einer Docker-GPU-Laufzeitumgebung ausgestattet ist. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md).

Sie können GPUs in Ihrer Aufgabendefinition eine Reihe von angeben, die bei der Platzierung von Aufgaben auf Containerebene berücksichtigt werden sollen. Amazon ECS plant für verfügbare Container-Instances, die für eine optimale Leistung physische Container unterstützen GPUs und GPUs an die richtigen Container anbinden. 

Die folgenden GPU-basierten Instance-Typen von Amazon EC2 werden unterstützt. Weitere Informationen finden Sie unter [Amazon-EC2-P2-Instances](https://aws.amazon.com/ec2/instance-types/p2/), [Amazon-EC2-P3-Instances](https://aws.amazon.com/ec2/instance-types/p3/), [Amazon-EC2-P4d-Instances](https://aws.amazon.com/ec2/instance-types/p4/), [Amazon-EC2-P5-Instances](https://aws.amazon.com/ec2/instance-types/p5/), [Amazon-EC2-G3-Instances](https://aws.amazon.com/ec2/instance-types/g3/), [Amazon-EC2-G4-Instances](https://aws.amazon.com/ec2/instance-types/g4/), [Amazon-EC2-G5-Instances](https://aws.amazon.com/ec2/instance-types/g5/), [Amazon-EC2-G6-Instances](https://aws.amazon.com/ec2/instance-types/g6/) und [Amazon-EC2-G6e-Instances](https://aws.amazon.com/ec2/instance-types/g6e/).


|  Instance-Typ  |  GPUs  |  GPU-Speicher (GiB)  |  v CPUs  |  Arbeitsspeicher (GiB)  | 
| --- | --- | --- | --- | --- | 
|  p3.2xgroß  |  1  |  16  |  8  |  61  | 
|  p3.8xgroß  |  4  |  64  |  32  |  244  | 
|  p3.16xgroß  |  8  |  128  |  64  |  488  | 
|  p3dn.24xgroß  |  8  |  256  |  96  |  768  | 
|  p4d.24xgroß  | 8 | 320 | 96 | 1 152 | 
| p5.48xlarge | 8 | 640 | 192 | 2048 | 
|  g3s.xgroß  |  1  |  8  |  4  |  30,5  | 
|  g3.4xgroß  |  1  |  8  |  16  |  122  | 
|  g3.8xgroß  |  2  |  16  |  32  |  244  | 
|  g3.16xgroß  |  4  |  32  |  64  |  488  | 
|  g4dn.xgroß  |  1  |  16  |  4  |  16  | 
|  g4dn.2xgroß  |  1  |  16  |  8  |  32  | 
|  g4dn.4xgroß  |  1  |  16  |  16  |  64  | 
|  g4dn.8xgroß  |  1  |  16  |  32  |  128  | 
|  g4dn.12xgroß  |  4  |  64  |  48  |  192  | 
|  g4dn.16xgroß  |  1  |  16  |  64  |  256  | 
|  g5.xgroß  |  1  |  24  |  4  |  16  | 
|  g5.2xlarge  |  1  |  24  |  8  |  32  | 
|  g5.4xlarge  |  1  |  24  |  16  |  64  | 
|  g5.8xlarge  |  1  |  24  |  32  |  128  | 
|  g5.16xlarge  |  1  |  24  |  64  |  256  | 
|  g5.12xlarge  |  4  |  96  |  48  |  192  | 
|  g5.24xlarge  |  4  |  96  |  96  |  384  | 
|  g5.48xlarge  |  8  |  192  |  192  |  768  | 
| g6.xlarge | 1 | 24 | 4 | 16 | 
| g6.2xlarge | 1 | 24 | 8 | 32 | 
| g6.4xlarge | 1 | 24 | 16 | 64 | 
| g6.8xlarge | 1 | 24 | 32 | 128 | 
| g6.16.xlarge | 1 | 24 | 64 | 256 | 
| g6.12xlarge | 4 | 96 | 48 | 192 | 
| g6.24xlarge | 4 | 96 | 96 | 384 | 
| g6.48xlarge | 8 | 192 | 192 | 768 | 
| g6.metal | 8 | 192 | 192 | 768 | 
| gr6.4xlarge | 1 | 24 | 16 | 128 | 
| g6e.xlarge | 1 | 48 | 4 | 32 | 
| g6e.2xlarge | 1 | 48 | 8 | 64 | 
| g6e.4xlarge | 1 | 48 | 16 | 128 | 
| g6e.8xlarge | 1 | 48 | 32 | 256 | 
| g6e16.xlarge | 1 | 48 | 64 | 512 | 
| g6e12.xlarge | 4 | 192 | 48 | 384 | 
| g6e24.xlarge | 4 | 192 | 96 | 768 | 
| g6e48.xlarge | 8 | 384 | 192 | 1536 | 
| gr6.8xlarge | 1 | 24 | 32 | 256 | 

Sie können die Amazon Machine Image (AMI) -ID für Amazon ECS-Optimized abrufen, AMIs indem Sie die AWS Systems Manager Parameter Store-API abfragen. Mit diesem Parameter müssen Sie Amazon ECS-optimiertes AMI nicht manuell suchen. IDs Weitere Informationen zur Systems Manager Parameter Store-API finden Sie unter [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Der von Ihnen verwendete Benutzer muss über die `ssm:GetParameter`-IAM-Berechtigung zum Abrufen der Amazon-EKS-optimierten AMI-Metadaten verfügen.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```

# Verwendung GPUs mit Amazon ECS Managed Instances
<a name="managed-instances-gpu"></a>

Amazon ECS Managed Instances unterstützt GPU-beschleunigte Datenverarbeitung für Workloads wie Machine Learning, Hochleistungsrechnen und Videoverarbeitung über die folgenden Instance-Typen von Amazon EC2. Weitere Informationen zu den von Amazon ECS Managed Instances unterstützten Instance-Typen finden Sie unter [Instance-Typen von Amazon ECS Managed Instances](managed-instances-instance-types.md).

Im Folgenden finden Sie eine Teilmenge der GPU-basierten Instance-Typen, die in Amazon ECS Managed Instances unterstützt werden:
+ `g4dn`: Unterstützt von NVIDIA T4 GPUs, geeignet für Machine Learning, Inferenz, Computer Vision und grafikintensive Anwendungen.
+ `g5`: Unterstützt von NVIDIA A10G GPUs, bietet höhere Leistung für grafikintensive Anwendungen und Workloads für Machine Learning.
+ `p3`: Unterstützt von NVIDIA V100 GPUs, konzipiert für Hochleistungscomputer und Deep-Learning-Training.
+ `p4d`: Unterstützt von NVIDIA A100 GPUs, bietet die höchste Leistung für Training für Machine Learning und Hochleistungs-Datenverarbeitung.

Wenn Sie GPU-fähige Instance-Typen mit Amazon ECS Managed Instances verwenden, sind die NVIDIA-Treiber und das CUDA-Toolkit auf der Instance vorinstalliert, sodass GPU-beschleunigte Workloads einfacher ausgeführt werden können.

## Auswahl GPU-fähiger Instances
<a name="managed-instances-gpu-instance-selection"></a>

Verwenden Sie das `instanceRequirements`-Objekt in der Startvorlage des Kapazitätsanbieters, um GPU-fähige Instance-Typen für Ihre Workloads von Amazon ECS Managed Instances auszuwählen. Der folgende Ausschnitt zeigt die Attribute, die für die Auswahl GPU-fähiger Instances verwendet werden können.

```
{
  "instanceRequirements": {
    "acceleratorTypes": "gpu",
    "acceleratorCount": 1,
    "acceleratorManufacturers": ["nvidia"]
  }
}
```

Der folgende Ausschnitt zeigt die Attribute, die verwendet werden können, um GPU-fähige Instance-Typen in der Startvorlage anzugeben.

```
{
  "instanceRequirements": {
    "allowedInstanceTypes": ["g4dn.xlarge", "p4de.24xlarge"]
  }
}
```

## GPU-fähige Container-Images
<a name="managed-instances-gpu-container-images"></a>

Für die Verwendung GPUs in Ihren Containern müssen Sie Container-Images verwenden, die die erforderlichen GPU-Bibliotheken und -Tools enthalten. NVIDIAstellt mehrere vorgefertigte Container-Images bereit, die Sie als Basis für Ihre GPU-Workloads verwenden können, darunter die folgenden:
+ `nvidia:cuda`: Basis-Images mit dem CUDA-Toolkit für GPU-Datenverarbeitung.
+ `tensorflow/tensorflow:latest-gpu`: TensorFlow mit GPU-Unterstützung.
+ `pytorch/pytorch:latest-cuda`: PyTorch mit GPU-Unterstützung.

Ein Beispiel für eine Aufgabendefinition für Amazon ECS auf Amazon ECS Managed Instances, die die Verwendung von beinhaltet GPUs, finden Sie unter[GPUs In einer Amazon ECS-Aufgabendefinition angeben](ecs-gpu-specifying.md).

## Überlegungen
<a name="gpu-considerations"></a>

**Anmerkung**  
Die Unterstützung für den g2-Instance-Familientyp ist veraltet.  
Der Instance-Familientyp p2 wird nur von Versionen vor `20230912` des Amazon-ECS-GPU-optimierten AMI unterstützt. Wenn Sie weiterhin P2-Instances verwenden müssen, finden Sie weitere Informationen unter [Was tun, wenn Sie eine P2-Instance benötigen](#p2-instance).  
Direkte Aktualisierungen der NVIDIA/CUDA Treiber für diese beiden Instance-Familientypen können zu potenziellen Ausfällen der GPU-Arbeitslast führen.

Wir empfehlen Ihnen, Folgendes zu berücksichtigen, bevor Sie mit der Arbeit GPUs an Amazon ECS beginnen.
+ Ihre Cluster können eine Mischung aus GPU- und Nicht-GPU-Container-Instances enthalten.
+ Sie können GPU-Workloads auf externen Instances ausführen. Stellen Sie beim Anmelden einer externen Instance bei Ihrem Cluster sicher, dass das `--enable-gpu`-Flag im Installationsskript enthalten ist. Weitere Informationen finden Sie unter [Registrieren einer externen Instance in einem Amazon-ECS-Cluster](ecs-anywhere-registration.md).
+ Sie müssen in Ihrer Agenten-Konfigurationsdatei `ECS_ENABLE_GPU_SUPPORT` auf `true` setzen. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
+ Wenn Sie eine Aufgabe ausführen oder einen Service erstellen, können Sie beim Konfigurieren der Platzierungsbedingungen mithilfe von Attributen des Instance-Typs festlegen, für welche Ihrer Container-Instances die Aufgabe gestartet wird. Auf diese Weise können Sie Ihre Ressourcen effektiver verwenden. Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).

  Das folgende Beispiel startet eine Aufgabe auf einer `g4dn.xlarge`-Container-Instance in Ihrem Standard-Cluster.

  ```
  aws ecs run-task --cluster default --task-definition ecs-gpu-task-def \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type ==  g4dn.xlarge" --region us-east-2
  ```
+ Für jeden Container, der eine in der Container-Definition festgelegte GPU-Ressourcenanforderung hat, legt Amazon ECS fest, dass die Container-Laufzeitumgebung die NVIDIA-Container-Laufzeitumgebung ist.
+ Die NVIDIA Container-Laufzeitumgebung erfordert, dass einige Umgebungsvariablen im Container festgelegt werden, damit sie korrekt funktioniert. Eine Liste dieser Umgebungsvariablen finden Sie unter [Spezialisierte Konfigurationen mit Docker](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable). Amazon ECS legt als Wert der `NVIDIA_VISIBLE_DEVICES` Umgebungsvariablen eine Liste des GPU-Geräts fest IDs , das Amazon ECS dem Container zuweist. Die anderen erforderlichen Umgebungsvariablen legt Amazon ECS nicht fest. Stellen Sie daher sicher, dass Ihr Container-Image sie festlegt oder dass sie in der Container-Definition festgelegt sind.
+ Die p5-Instance-Typ-Familie wird auf Version `20230929` und höher des Amazon-ECS GPU-optimierten AMI unterstützt. 
+ Die g4-Instance-Typ-Familie wird auf Version `20230913` und höher des Amazon ECS GPU-optimierten AMI unterstützt. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md). Sie wird im Workflow „Cluster erstellen“ in der Amazon-ECS-Konsole nicht unterstützt. Um diese Instance-Typen zu verwenden, müssen Sie entweder die Amazon EC2 EC2-Konsole oder die API verwenden und die Instances manuell in Ihrem Cluster registrieren. AWS CLI
+ Der Instance-Typ p4d.24xlarge funktioniert nur mit CUDA 11 oder höher.
+ Das GPU-optimierte AMI von Amazon ECS wurde IPv6 aktiviert, was zu Problemen bei der Verwendung führt. `yum` Dieses Problem kann durch die Konfiguration für die Verwendung IPv4 mit `yum` dem folgenden Befehl behoben werden.

  ```
  echo "ip_resolve=4" >> /etc/yum.conf
  ```
+  Wenn Sie ein Container-Image erstellen, das die NVIDIA/CUDA Basis-Images nicht verwendet, müssen Sie die `NVIDIA_DRIVER_CAPABILITIES` Container-Laufzeitvariable auf einen der folgenden Werte setzen:
  + `utility,compute`
  + `all`

  Informationen zum Festlegen der Variablen finden Sie unter [Steuern der NVIDIA Container Runtime](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime) auf der NVIDIA-Website.
+ GPUs werden in Windows-Containern nicht unterstützt.

# Eine GPU-Container-Instance für Amazon ECS starten
<a name="gpu-launch"></a>

Um eine GPU-Instance mit Amazon ECS in Amazon EC2 zu verwenden, müssen Sie eine Startvorlage und eine Benutzerdatendatei erstellen und die Instance starten.

Anschließend können Sie eine Aufgabe ausführen, die eine für GPU konfigurierte Aufgabendefinition verwendet.

## Verwenden einer Startvorlage
<a name="gpu-launch-template"></a>

Sie können eine Startvorlage erstellen
+ Erstellen Sie eine Startvorlage, die die Amazon-ECS-optimierte GPU-AMI-ID für das AMI verwendet. Informationen zum Erstellen einer Startvorlage finden Sie unter [Erstellen einer neuen Startvorlage mithilfe von Parametern, die Sie definieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters) im *Amazon-EC2-Benutzerhandbuch*.

  Verwenden Sie die AMI-ID aus dem vorherigen Schritt für das **Amazon Machine Image**. Informationen zur Angabe der AMI-ID mit dem Systems-Manager-Parameter finden Sie unter [Spezifizieren eines Systems-Manager-Parameters in einer Startvorlage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id) im *Amazon-EC2-Benutzerhandbuch*.

  Fügen Sie den **Benutzerdaten** in der Startvorlage Folgendes hinzu. Ersetzen Sie *cluster-name* mit dem Namen Ihres Clusters.

  ```
  #!/bin/bash
  echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
  echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
  ```

## Verwenden Sie die AWS CLI
<a name="gpu-launch-cli"></a>

Sie können den verwenden AWS CLI , um die Container-Instance zu starten.

1. Erstellen Sie eine Datei mit dem Namen `userdata.toml`. Diese Datei wird für Instance-Benutzerdaten verwendet. Ersetzen Sie *cluster-name* mit dem Namen Ihres Clusters.

   ```
   #!/bin/bash
   echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
   echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
   ```

1. Führen Sie den folgenden Befehl aus, um die GPU-AMI-ID zu erhalten. Sie verwenden dies im folgenden Schritt.

   ```
   aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
   ```

1. Führen Sie den folgenden Befehl aus, um die GPU-Instance zu starten. Denken Sie daran, die folgenden Parameter zu ersetzen:
   + *subnet*Ersetzen Sie es durch die ID des privaten oder öffentlichen Subnetzes, in dem Ihre Instance gestartet wird.
   + *gpu\$1ami*Ersetzen Sie durch die AMI-ID aus dem vorherigen Schritt.
   + *t3.large*Ersetzen Sie durch den Instance-Typ, den Sie verwenden möchten.
   + *region*Ersetzen Sie durch den Regionalcode.

   ```
   aws ec2 run-instances --key-name ecs-gpu-example \
      --subnet-id subnet \
      --image-id gpu_ami \
      --instance-type t3.large \
      --region region \
      --tag-specifications 'ResourceType=instance,Tags=[{Key=GPU,Value=example}]' \
      --user-data file://userdata.toml \
      --iam-instance-profile Name=ecsInstanceRole
   ```

1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Container-Instance im Cluster registriert ist. Denken Sie beim Ausführen dieses Befehls daran, die folgenden Parameter zu ersetzen:
   + Ersetzen Sie *cluster* mit Ihrem Clusternamen.
   + *region*Ersetzen Sie es durch Ihren Regionalcode.

   ```
   aws ecs list-container-instances --cluster cluster-name --region region
   ```

# GPUs In einer Amazon ECS-Aufgabendefinition angeben
<a name="ecs-gpu-specifying"></a>

Um die GPUs On-a-Container-Instance und die Docker-GPU-Laufzeit zu verwenden, stellen Sie sicher, dass Sie in der Aufgabendefinition die Anzahl angeben, die GPUs Ihr Container benötigt. Wenn Container, die Unterstützung bieten, platziert GPUs werden, heftet der Amazon ECS-Container-Agent die gewünschte Anzahl GPUs an physischen Containern an den entsprechenden Container. Die Anzahl der für alle Container in einer Aufgabe GPUs reservierten Container darf die Anzahl der verfügbaren Container auf der Container-Instance, GPUs auf der die Aufgabe gestartet wird, nicht überschreiten. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).

**Wichtig**  
Wenn Ihre GPU-Anforderungen in der Aufgabendefinition nicht angegeben werden, verwendet die Aufgabe die Standard-Docker-Laufzeit.

Das folgende Beispiel zeigt das JSON-Format für die GPU-Anforderungen in einer Aufgabendefinition:

```
{
  "containerDefinitions": [
     {
        ...
        "resourceRequirements" : [
            {
               "type" : "GPU", 
               "value" : "2"
            }
        ],
     },
...
}
```

Das folgende Beispiel veranschaulicht die Syntax eines Docker-Containers, der eine GPU-Anforderung angibt. Dieser Container verwendet zwei GPUs, führt das `nvidia-smi` Hilfsprogramm aus und wird dann beendet.

```
{
  "containerDefinitions": [
    {
      "memory": 80,
      "essential": true,
      "name": "gpu",
      "image": "nvidia/cuda:11.0.3-base",
      "resourceRequirements": [
         {
           "type":"GPU",
           "value": "2"
         }
      ],
      "command": [
        "sh",
        "-c",
        "nvidia-smi"
      ],
      "cpu": 100
    }
  ],
  "family": "example-ecs-gpu"
}
```

Die folgende Beispielaufgabendefinition zeigt einen TensorFlow Container, der die Anzahl der verfügbaren GPUs Objekte ausgibt. Die Aufgabe wird in Amazon ECS Managed Instances ausgeführt, benötigt eine GPU und verwendet eine `g4dn.xlarge`-Instance.

```
{
  "family": "tensorflow-gpu",
  "networkMode": "awsvpc",
  "executionRoleArn": "arn:aws:iam::account-id:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "tensorflow",
      "image": "tensorflow/tensorflow:latest-gpu",
      "essential": true,
      "command": [
        "python",
        "-c",
        "import tensorflow as tf; print('Num GPUs Available: ', len(tf.config.list_physical_devices('GPU')))"
      ],
      "resourceRequirements": [
        {
          "type": "GPU",
          "value": "1"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/tensorflow-gpu",
          "awslogs-region": "region",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "requiresCompatibilities": [
    "MANAGED_INSTANCES"
  ],
  "cpu": "4096",
  "memory": "8192",
}
```

## Teilen GPUs
<a name="share-gpu"></a>

Wenn Sie teilen möchten GPUs, müssen Sie Folgendes konfigurieren.

1. Entfernen Sie GPU-Ressourcenanforderungen aus Ihren Aufgabendefinitionen, sodass Amazon ECS keine Ressourcen reserviert GPUs , die gemeinsam genutzt werden sollten.

1. Fügen Sie Ihren Instances die folgenden Benutzerdaten hinzu, wenn Sie sie teilen möchten GPUs. Dadurch wird nvidia zur standardmäßigen Docker-Container-Laufzeit auf der Container-Instance, sodass alle Amazon ECS-Container die GPUs verwenden können. Weitere Informationen finden Sie unter [Ausführen von Befehlen beim Start einer EC2-Instance mit Benutzer-Dateneingabe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) im *Amazon-EC2-Benutzerhandbuch*.

   ```
   const userData = ec2.UserData.forLinux();
    userData.addCommands(
    'sudo rm /etc/sysconfig/docker',
    'echo DAEMON_MAXFILES=1048576 | sudo tee -a /etc/sysconfig/docker',
    'echo OPTIONS="--default-ulimit nofile=32768:65536 --default-runtime nvidia" | sudo tee -a /etc/sysconfig/docker',
    'echo DAEMON_PIDFILE_TIMEOUT=10 | sudo tee -a /etc/sysconfig/docker',
    'sudo systemctl restart docker',
   );
   ```

1. Legen Sie die `NVIDIA_VISIBLE_DEVICES`-Umgebungsvariable in Ihrem Container fest. Dazu können Sie die Umgebungsvariable in Ihrer Aufgabendefinition festlegen. Informationen zu den gültigen Werten finden Sie unter [GPU-Nummerierung](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration) auf der NVIDIA-Dokumentationsseite.

## Was tun, wenn Sie eine P2-Instance benötigen
<a name="p2-instance"></a>

Wenn Sie die P2-Instance verwenden müssen, können Sie eine der folgenden Optionen verwenden, um die Instances weiterhin zu verwenden.

Sie müssen die Benutzerdaten der Instance für beide Optionen ändern. Weitere Informationen finden Sie unter [Ausführen von Befehlen beim Start einer EC2-Instance mit Benutzer-Dateneingabe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) im *Amazon-EC2-Benutzerhandbuch*.

**Verwenden der zuletzt unterstützten GPU-optimierten AMI**

Sie können die `20230906`-Version des GPU-optimierten AMI verwenden und den Instance-Benutzerdaten Folgendes hinzufügen.

Ersetzen Sie cluster-name durch den Namen Ihres Clusters.

```
#!/bin/bash
echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf
echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
```

**Die aktuellsten GPU-optimierten AMI verwenden und die Benutzerdaten aktualisieren**

Sie können den Benutzerdaten der Instance Folgendes hinzufügen. Dadurch werden die Nvidia 535/Cuda12.2-Treiber deinstalliert und anschließend die Nvidia 470/Cuda11.4-Treiber installiert und die Version repariert.

```
#!/bin/bash
yum remove -y cuda-toolkit* nvidia-driver-latest-dkms*
tmpfile=$(mktemp)
cat >$tmpfile <<EOF
[amzn2-nvidia]
name=Amazon Linux 2 Nvidia repository
mirrorlist=\$awsproto://\$amazonlinux.\$awsregion.\$awsdomain/\$releasever/amzn2-nvidia/latest/\$basearch/mirror.list
priority=20
gpgcheck=1
gpgkey=https://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/7fa2af80.pub
enabled=1
exclude=libglvnd-*
EOF

mv $tmpfile /etc/yum.repos.d/amzn2-nvidia-tmp.repo
yum install -y system-release-nvidia cuda-toolkit-11-4 nvidia-driver-latest-dkms-470.182.03
yum install -y libnvidia-container-1.4.0 libnvidia-container-tools-1.4.0 nvidia-container-runtime-hook-1.4.0 docker-runtime-nvidia-1

echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf
nvidia-smi
```

**Ihr eigenes P2-kompatibles und GPU-optimiertes AMI erstellen**

Sie können Ihr eigenes benutzerdefiniertes GPU-optimiertes Amazon-ECS-AMI erstellen, das mit P2-Instances kompatibel ist, und dann P2-Instances mithilfe des AMI starten.

1. Führen Sie den folgenden Befehl aus, um das `amazon-ecs-ami repo` zu klonen.

   ```
   git clone https://github.com/aws/amazon-ecs-ami
   ```

1. Stellen Sie die erforderlichen Amazon-ECS-Agent- und Amazon-Linux-AMI-Quellversionen in `release.auto.pkrvars.hcl` oder `overrides.auto.pkrvars.hcl` ein.

1. Führen Sie den folgenden Befehl aus, um ein privates P2-kompatibles EC2-AMI zu erstellen.

   Ersetzen Sie Region durch die Region mit der Instance-Region.

   ```
   REGION=region make al2keplergpu
   ```

1. Verwenden Sie das AMI mit den folgenden Instance-Benutzerdaten, um eine Verbindung zum Amazon-ECS-Cluster herzustellen.

   Ersetzen Sie cluster-name durch den Namen Ihres Clusters.

   ```
   #!/bin/bash
   echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
   ```

# Amazon-ECS-Aufgabendefinitionen für Workloads zur Video-Transkodierung
<a name="ecs-vt1"></a>

Um Videotranskodierungs-Workloads auf Amazon ECS zu verwenden, registrieren Sie [Amazon](https://aws.amazon.com/ec2/instance-types/vt1/) EC2 EC2-Instances. VT1 Nachdem Sie diese Instances registriert haben, können Sie Live- und vorab gerenderte Video-Transcodierungs-Workloads als Aufgaben auf Amazon ECS ausführen. Amazon EC2 VT1 EC2-Instances verwenden Xilinx U30-Medientranscodierungskarten, um die Transcodierung von Live- und vorgerenderten Videos zu beschleunigen.

**Anmerkung**  
Anleitungen für das Ausführen von Workloads zur Video-Transcodierung in anderen Containern als Amazon ECS finden Sie in der [Xilinx-Dokumentation](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1).

## Überlegungen
<a name="ecs-vt1-considerations"></a>

Bevor Sie mit VT1 der Bereitstellung auf Amazon ECS beginnen, sollten Sie Folgendes beachten:
+ Ihre Cluster können eine Mischung aus VT1 und VT1 Nicht-Instances enthalten.
+ Sie benötigen eine Linux-Anwendung, die Xilinx U30-Medientranscodierungskarten mit beschleunigten H.264/AVC- und H.265/HEVC-Codecs verwendet.
**Wichtig**  
Anwendungen, die andere Codecs verwenden, weisen möglicherweise keine verbesserte Leistung auf Instances auf VT1 .
+ Nur eine Transcodierungsaufgabe kann auf einer U30-Karte ausgeführt werden. Jede Karte hat zwei Geräte, die damit verbunden sind. Sie können so viele Transcodierungsaufgaben ausführen, wie für jede Ihrer Instances Karten verfügbar sind. VT1 
+ Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie beim Konfigurieren der Aufgabenplatzierungbedingungen Attribute des Instance-Typs verwenden. Dadurch wird sichergestellt, dass die Aufgabe auf der von Ihnen angegebenen Container-Instance gestartet wird. Auf diese Weise können Sie sicherstellen, dass Sie Ihre Ressourcen effektiv nutzen und dass Ihre Aufgaben für Videotranskodierungs-Workloads auf Ihren Instances liegen. VT1 Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).

  Im folgenden Beispiel wird eine Aufgabe auf einer `vt1.3xlarge`-Instance auf Ihrem `default`-Cluster ausgeführt.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition vt1-3xlarge-xffmpeg-processor \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == vt1.3xlarge"
  ```
+ Sie können einen Container so konfigurieren, dass er die spezifische U30-Karte verwendet, die auf der Host-Container-Instance verfügbar ist. Sie können dazu den `linuxParameters`-Parameter nutzen und die Geräteinformationen angeben. Weitere Informationen finden Sie unter [Anforderungen an die Aufgabendefinition](#ecs-vt1-requirements).

## Verwenden eines VT1 AMI
<a name="ecs-vt1-ami"></a>

Sie haben zwei Möglichkeiten, ein AMI auf Amazon EC2 für Amazon-ECS-Container-Instances auszuführen. Die erste Option besteht darin, das offizielle Xilinx-AMI auf AWS Marketplace zu verwenden. Die zweite Option besteht darin, Ihr eigenes AMI aus dem Beispiel-Repository zu erstellen.
+ [Xilinx bietet AMIs ](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6) auf der. AWS Marketplace
+ Amazon ECS stellt ein Beispiel-Repository bereit, mit dem Sie ein AMI für Video-Transcodierungs-Workloads erstellen können. Dieses AMI wird mit Xilinx U30-Treibern geliefert. Sie finden das Repository, das Packer-Skripte enthält, auf. [GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline) Weitere Informationen zu Packer finden Sie in der [Packer-Dokumentation](https://developer.hashicorp.com/packer/docs).

## Anforderungen an die Aufgabendefinition
<a name="ecs-vt1-requirements"></a>

Um Video-Transcodierungscontainer auf Amazon ECS auszuführen, muss Ihre Aufgabendefinition eine Video-Transcodierungsanwendung enthalten, die die beschleunigten H.264/AVC- und H.265/HEVC-Codecs verwendet. Sie können ein Container-Image erstellen, indem Sie den Schritten auf dem [ GitHubXilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage) folgen.

Die Aufgabendefinition muss für den Instance-Typ spezifisch sein. Die Instance-Typen sind 3xlarge, 6xlarge und 24xlarge. Sie müssen einen Container so konfigurieren, dass er spezifische Xilinx U30-Geräte verwendet, die auf der Host-Container-Instance verfügbar sind. Dazu können Sie den `linuxParameters`-Parameter verwenden. In der folgenden Tabelle sind die Karten und Geräte aufgeführt SoCs , die für jeden Instance-Typ spezifisch sind.


| Instance-Typ | v CPUs | RAM (GiB) | U30 Accelerator-Karten | Adressierbare XCU30 SoC-Geräte | Gerätepfade | 
| --- | --- | --- | --- | --- | --- | 
| vt1.3xlarge | 12 | 24 | 1 | 2 | /dev/dri/renderD128,/dev/dri/renderD129 | 
| vt1.6xlarge | 24 | 48 | 2 | 4 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131 | 
| vt1.24xlarge | 96 | 182 | 8 | 16 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131,/dev/dri/renderD132,/dev/dri/renderD133,/dev/dri/renderD134,/dev/dri/renderD135,/dev/dri/renderD136,/dev/dri/renderD137,/dev/dri/renderD138,/dev/dri/renderD139,/dev/dri/renderD140,/dev/dri/renderD141,/dev/dri/renderD142,/dev/dri/renderD143 | 

**Wichtig**  
Wenn die Aufgabendefinition Geräte auflistet, die die EC2-Instance nicht hat, kann die Aufgabe nicht ausgeführt werden. Wenn die Aufgabe fehlschlägt, wird die folgende Fehlermeldung in `stoppedReason` angezeigt: `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory`.

# Angeben von Video-Transkodierung in einer Amazon-ECS-Aufgabendefinition
<a name="task-def-video-transcode"></a>

Im folgenden Beispiel sehen Sie die Syntax, die für eine Aufgabendefinition eines Linux-Containers auf Amazon EC2 verwendet wird. Diese Aufgabendefinition gilt für Container-Images, die gemäß dem Verfahren erstellt werden, das in der [Xilinx-Dokumentation](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage) beschrieben ist. Wenn Sie dieses Beispiel verwenden, ersetzen Sie `image` durch Ihr eigenes Image und kopieren Sie Ihre Videodateien in die Instance im `/home/ec2-user`-Verzeichnis.

------
#### [ vt1.3xlarge ]

1. Erstellen Sie eine Textdatei mit dem Namen `vt1-3xlarge-ffmpeg-linux.json` und dem folgenden Inhalt.

   ```
   {
       "family": "vt1-3xlarge-xffmpeg-processor",
       "requiresCompatibilities": ["EC2"],
       "placementConstraints": [
           {
               "type": "memberOf",
               "expression": "attribute:ecs.os-type == linux"
           },
           {
               "type": "memberOf",
               "expression": "attribute:ecs.instance-type == vt1.3xlarge"
           }
       ],
       "containerDefinitions": [
           {
               "entryPoint": [
                   "/bin/bash",
                   "-c"
               ],
               "command": ["/video/ecs_ffmpeg_wrapper.sh"],
               "linuxParameters": {
                   "devices": [
                       {
                           "containerPath": "/dev/dri/renderD128",
                           "hostPath": "/dev/dri/renderD128",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD129",
                           "hostPath": "/dev/dri/renderD129",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       }
                   ]
               },
               "mountPoints": [
                   {
                       "containerPath": "/video",
                       "sourceVolume": "video_file"
                   }
               ],
               "cpu": 0,
               "memory": 12000,
               "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
               "essential": true,
               "name": "xilinix-xffmpeg"
           }
       ],
       "volumes": [
           {
               "name": "video_file",
               "host": {"sourcePath": "/home/ec2-user"}
           }
       ]
   }
   ```

1. Registrieren Sie die Aufgabendefinition.

   ```
   aws ecs register-task-definition --family vt1-3xlarge-xffmpeg-processor --cli-input-json file://vt1-3xlarge-xffmpeg-linux.json --region us-east-1
   ```

------
#### [ vt1.6xlarge ]

1. Erstellen Sie eine Textdatei mit dem Namen `vt1-6xlarge-ffmpeg-linux.json` und dem folgenden Inhalt.

   ```
   {
       "family": "vt1-6xlarge-xffmpeg-processor",
       "requiresCompatibilities": ["EC2"],
       "placementConstraints": [
           {
               "type": "memberOf",
               "expression": "attribute:ecs.os-type == linux"
           },
           {
               "type": "memberOf",
               "expression": "attribute:ecs.instance-type == vt1.6xlarge"
           }
       ],
       "containerDefinitions": [
           {
               "entryPoint": [
                   "/bin/bash",
                   "-c"
               ],
               "command": ["/video/ecs_ffmpeg_wrapper.sh"],
               "linuxParameters": {
                   "devices": [
                       {
                           "containerPath": "/dev/dri/renderD128",
                           "hostPath": "/dev/dri/renderD128",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD129",
                           "hostPath": "/dev/dri/renderD129",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD130",
                           "hostPath": "/dev/dri/renderD130",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD131",
                           "hostPath": "/dev/dri/renderD131",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       }
                   ]
               },
               "mountPoints": [
                   {
                       "containerPath": "/video",
                       "sourceVolume": "video_file"
                   }
               ],
               "cpu": 0,
               "memory": 12000,
               "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
               "essential": true,
               "name": "xilinix-xffmpeg"
           }
       ],
       "volumes": [
           {
               "name": "video_file",
               "host": {"sourcePath": "/home/ec2-user"}
           }
       ]
   }
   ```

1. Registrieren Sie die Aufgabendefinition.

   ```
   aws ecs register-task-definition --family vt1-6xlarge-xffmpeg-processor --cli-input-json file://vt1-6xlarge-xffmpeg-linux.json --region us-east-1
   ```

------
#### [ vt1.24xlarge ]

1. Erstellen Sie eine Textdatei mit dem Namen `vt1-24xlarge-ffmpeg-linux.json` und dem folgenden Inhalt.

   ```
   {
       "family": "vt1-24xlarge-xffmpeg-processor",
       "requiresCompatibilities": ["EC2"],
       "placementConstraints": [
           {
               "type": "memberOf",
               "expression": "attribute:ecs.os-type == linux"
           },
           {
               "type": "memberOf",
               "expression": "attribute:ecs.instance-type == vt1.24xlarge"
           }
       ],
       "containerDefinitions": [
           {
               "entryPoint": [
                   "/bin/bash",
                   "-c"
               ],
               "command": ["/video/ecs_ffmpeg_wrapper.sh"],
               "linuxParameters": {
                   "devices": [
                       {
                           "containerPath": "/dev/dri/renderD128",
                           "hostPath": "/dev/dri/renderD128",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD129",
                           "hostPath": "/dev/dri/renderD129",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD130",
                           "hostPath": "/dev/dri/renderD130",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD131",
                           "hostPath": "/dev/dri/renderD131",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD132",
                           "hostPath": "/dev/dri/renderD132",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD133",
                           "hostPath": "/dev/dri/renderD133",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD134",
                           "hostPath": "/dev/dri/renderD134",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD135",
                           "hostPath": "/dev/dri/renderD135",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD136",
                           "hostPath": "/dev/dri/renderD136",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD137",
                           "hostPath": "/dev/dri/renderD137",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD138",
                           "hostPath": "/dev/dri/renderD138",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD139",
                           "hostPath": "/dev/dri/renderD139",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD140",
                           "hostPath": "/dev/dri/renderD140",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD141",
                           "hostPath": "/dev/dri/renderD141",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD142",
                           "hostPath": "/dev/dri/renderD142",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD143",
                           "hostPath": "/dev/dri/renderD143",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       }
                   ]
               },
               "mountPoints": [
                   {
                       "containerPath": "/video",
                       "sourceVolume": "video_file"
                   }
               ],
               "cpu": 0,
               "memory": 12000,
               "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
               "essential": true,
               "name": "xilinix-xffmpeg"
           }
       ],
       "volumes": [
           {
               "name": "video_file",
               "host": {"sourcePath": "/home/ec2-user"}
           }
       ]
   }
   ```

1. Registrieren Sie die Aufgabendefinition.

   ```
   aws ecs register-task-definition --family vt1-24xlarge-xffmpeg-processor --cli-input-json file://vt1-24xlarge-xffmpeg-linux.json --region us-east-1
   ```

------

# Amazon ECS-Aufgabendefinitionen für AWS Neuron-Workloads für maschinelles Lernen
<a name="ecs-inference"></a>

Sie können [Amazon EC2 Trn1-, Amazon EC2 Trn2](https://aws.amazon.com/ec2/instance-types/trn1/) -, [Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn2/) [Inf1- und [Amazon EC2 Inf2-Instances](https://aws.amazon.com/ec2/instance-types/inf2/)](https://aws.amazon.com/ec2/instance-types/inf1/) in Ihren Clustern für maschinelles Lernen registrieren.

[Amazon EC2 Trn1- und Trn2-Instances werden mit Trainium-Chips betrieben.AWS](https://aws.amazon.com/ai/machine-learning/trainium/) Diese Instances bieten leistungsstarkes und kostengünstiges Training für Machine Learning in der Cloud. Sie können ein Inferenzmodell für maschinelles Lernen mithilfe eines Frameworks für maschinelles Lernen mit AWS Neuron auf einer Trn1- oder Trn2-Instance trainieren. Anschließend können Sie das Modell auf einer Inf1-Instanz oder einer Inf2-Instanz ausführen, um die Beschleunigung der Inferentia-Chips zu nutzen. AWS 

Die Amazon-EC2-Instances Inf1 und Inf2 werden von [AWS -Inferentia-Chips](https://aws.amazon.com/ai/machine-learning/inferentia/) angetrieben. Sie bieten hohe Leistung und niedrigste Kosten für Inferenzen in der Cloud.

Machine-Learning-Modelle werden auf Containern mit [AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/) bereitgestellt, einem spezialisierten Software Developer Kit (SDK). Das SDK besteht aus einem Compiler, Runtime- und Profiling-Tools, die die Leistung von Machine-Learning-Chips für maschinelles Lernen optimieren. AWS AWS Neuron unterstützt beliebte Frameworks für maschinelles Lernen wie TensorFlow PyTorch, und Apache. MXNet

## Überlegungen
<a name="ecs-inference-considerations"></a>

Berücksichtigen Sie Folgendes, bevor Sie mit der Bereitstellung von Neuron auf Amazon ECS beginnen:
+ Ihre Cluster können eine Mischung aus Trn1, Trn2, Inf1, Inf2 und anderen Instances enthalten.
+ Sie benötigen eine Linux-Anwendung in einem Container, der ein Framework für maschinelles Lernen verwendet, das Neuron unterstützt. AWS 
**Wichtig**  
Anwendungen, die andere Frameworks verwenden, weisen möglicherweise keine verbesserte Leistung auf Trn1-, Trn2-, Inf1- und Inf2-Instances auf.
+ Auf jedem [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)- oder [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)-Chip kann nur eine Inferenz- oder Inferenztrainingsaufgabe ausgeführt werden. Bei Inf1 hat jeder Chip 4. NeuronCores Für Trn1, Trn2 und Inf2 hat jeder Chip 2. NeuronCores Sie können so viele Aufgaben ausführen, wie Chips für jede Ihrer Trn1-, Trn2-, Inf1- und Inf2-Instances vorhanden sind.
+ Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie beim Konfigurieren der Aufgabenplatzierungbedingungen Attribute des Instance-Typs verwenden. Dadurch wird sichergestellt, dass die Aufgabe auf der von Ihnen angegebenen Container-Instance gestartet wird. Auf diese Weise können Sie die allgemeine Ressourcennutzung optimieren und sicherstellen, dass Aufgaben für Inferenz-Workloads auf Ihren Trn1-, Trn2-, Inf1- und Inf2-Instances ausgeführt werden. Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).

  Im folgenden Beispiel wird eine Aufgabe auf einer `Inf1.xlarge`-Instance auf Ihrem `default`-Cluster ausgeführt.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition ecs-inference-task-def \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == Inf1.xlarge"
  ```
+ Ressourcenanforderungen für Neuron können in einer Aufgabendefinition nicht definiert werden. Stattdessen konfigurieren Sie einen Container so, dass er bestimmte AWS Trainium- oder Inferentia-Chips verwendet, die auf der Host-Container-Instance verfügbar sind. AWS Nutzen Sie dazu den `linuxParameters`-Parameter und geben Sie die Geräteinformationen an. Weitere Informationen finden Sie unter [Anforderungen an die Aufgabendefinition](#ecs-inference-requirements).

## Das Amazon-ECS-optimierte AMI für Amazon Linux 2023 (Neuron) verwenden
<a name="ecs-inference-ami2023"></a>

Amazon ECS bietet ein für Amazon ECS optimiertes AMI, das auf Amazon Linux 2023 für AWS Trainium- und AWS Inferentia-Workloads basiert. Es wird mit den AWS Neuron-Treibern und der Laufzeit für Docker geliefert. Dieses AMI erleichtert das Ausführen von Machine Learning Inferenz-Workloads auf Amazon ECS.

Wir empfehlen, das Amazon-ECS-optimierte AMI für Amazon Linux 2023 (Neuron) zu verwenden, wenn Sie Ihre Amazon-EC2-Trn1-, -Inf1- und -Inf2-Instances starten. 

Sie können das aktuelle Amazon ECS-optimierte Amazon Linux 2023 (Neuron) AMI AWS CLI mit dem folgenden Befehl abrufen.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended
```

## Anforderungen an die Aufgabendefinition
<a name="ecs-inference-requirements"></a>

Um Neuron auf Amazon ECS bereitzustellen, muss Ihre Aufgabendefinition die Container-Definition für einen vorgefertigten Container enthalten, für den das Inferenzmodell verwendet wird. TensorFlow Es wird von AWS Deep Learning Containers bereitgestellt. Dieser Container enthält die AWS Neuron-Runtime und die TensorFlow Serving-Anwendung. Beim Start ruft dieser Container Ihr Modell von Amazon S3 ab, startet Neuron TensorFlow Serving mit dem gespeicherten Modell und wartet auf Vorhersageanfragen. Im folgenden Beispiel hat das Container-Image TensorFlow 1.15 und Ubuntu 18.04. Eine vollständige Liste vorgefertigter Deep Learning Containers, die für Neuron optimiert sind, wird auf geführt. GitHub Weitere Informationen finden Sie unter [AWS Neuron TensorFlow Serving verwenden](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-inferentia-tf-neuron-serving.html).

```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04
```

Alternativ können Sie Ihr eigenes Neuron Seitenwagen Container-Image erstellen. Weitere Informationen finden Sie unter [Tutorial: Neuron TensorFlow Serving](https://github.com/aws-neuron/aws-neuron-sdk/blob/master/frameworks/tensorflow/tensorflow-neuron/tutorials/tutorials-tensorflow-utilizing-neuron-capabilities.rst) im *AWS Deep Learning AMIs Entwicklerhandbuch*.

Die Aufgabendefinition muss für den einzelnen Instance-Typ spezifisch sein. Sie müssen einen Container so konfigurieren, dass er bestimmte AWS Trainium- oder AWS Inferentia-Geräte verwendet, die auf der Host-Container-Instance verfügbar sind. Dazu können Sie den `linuxParameters`-Parameter verwenden. Ein Beispiel für eine Aufgabendefinition finden Sie unter. [Spezifizierung des maschinellen Lernens mit AWS Neuron in einer Amazon ECS-Aufgabendefinition](ecs-inference-task-def.md) In der folgenden Tabelle sind die Chips aufgeführt, die für jeden Instance-Typ spezifisch sind.


| Instance-Typ | v CPUs | RAM (GiB) | AWS ML-Beschleunigerchips | Gerätepfade | 
| --- | --- | --- | --- | --- | 
| trn1.2xlarge | 8 | 32 | 1 | /dev/neuron0 | 
| trn1.32xlarge | 128 | 512 | 16 |  /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15  | 
| trn2.48xlarge | 192 | 1536 | 16 |  /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15  | 
| inf1.xlarge | 4 | 8 | 1 | /dev/neuron0 | 
| inf1.2xlarge | 8 | 16 | 1 | /dev/neuron0 | 
| inf1.6xlarge | 24 | 48 | 4 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3 | 
| inf1.24xlarge | 96 | 192 | 16 |  /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15  | 
| inf2.xlarge | 8 | 16 | 1 | /dev/neuron0 | 
| inf2.8xlarge | 32 | 64 | 1 | /dev/neuron0 | 
| inf2.24xlarge | 96 | 384 | 6 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5,  | 
| inf2.48xlarge | 192 | 768 | 12 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11 | 

# Spezifizierung des maschinellen Lernens mit AWS Neuron in einer Amazon ECS-Aufgabendefinition
<a name="ecs-inference-task-def"></a>

Nachfolgend finden Sie ein Beispiel der Linux-Aufgabendefinition für `inf1.xlarge`, das die zu verwendende Syntax anzeigt.

```
{
    "family": "ecs-neuron",
    "requiresCompatibilities": ["EC2"],
    "placementConstraints": [
        {
            "type": "memberOf",
            "expression": "attribute:ecs.os-type == linux"
        },
        {
            "type": "memberOf",
            "expression": "attribute:ecs.instance-type == inf1.xlarge"
        }
    ],
    "executionRoleArn": "${YOUR_EXECUTION_ROLE}",
    "containerDefinitions": [
        {
            "entryPoint": [
                "/usr/local/bin/entrypoint.sh",
                "--port=8500",
                "--rest_api_port=9000",
                "--model_name=resnet50_neuron",
                "--model_base_path=s3://amzn-s3-demo-bucket/resnet50_neuron/"
            ],
            "portMappings": [
                {
                    "hostPort": 8500,
                    "protocol": "tcp",
                    "containerPort": 8500
                },
                {
                    "hostPort": 8501,
                    "protocol": "tcp",
                    "containerPort": 8501
                },
                {
                    "hostPort": 0,
                    "protocol": "tcp",
                    "containerPort": 80
                }
            ],
            "linuxParameters": {
                "devices": [
                    {
                        "containerPath": "/dev/neuron0",
                        "hostPath": "/dev/neuron0",
                        "permissions": [
                            "read",
                            "write"
                        ]
                    }
                ],
                "capabilities": {
                    "add": [
                        "IPC_LOCK"
                    ]
                }
            },
            "cpu": 0,
            "memoryReservation": 1000,
            "image": "763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04",
            "essential": true,
            "name": "resnet50"
        }
    ]
}
```

# Amazon-ECS-Aufgabendefinitionen für Deep-Learning-Instances
<a name="ecs-dl1"></a>

Um Deep-Learning-Workloads auf Amazon ECS zu verwenden, registrieren Sie [Amazon EC2 DL1 EC2-Instances](https://aws.amazon.com/ec2/instance-types/dl1/) in Ihren Clustern. Amazon EC2 DL1 EC2-Instances werden von Gaudi-Beschleunigern von Habana Labs (einem Unternehmen von Intel) unterstützt. Verwenden Sie das Habana SynapSeai SDK, um eine Verbindung zu den Habana Gaudi-Accelerators herzustellen. Das SDK unterstützt die beliebten Frameworks für maschinelles Lernen und. TensorFlow PyTorch

## Überlegungen
<a name="ecs-dl1-considerations"></a>

Bevor Sie mit DL1 der Bereitstellung auf Amazon ECS beginnen, sollten Sie Folgendes beachten:
+ Ihre Cluster können eine Mischung aus DL1 und DL1 Nicht-Instances enthalten.
+ Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie insbesondere beim Konfigurieren der Aufgabenplatzierungsbedingungen sicherstellen, dass Ihre Aufgabe auf der von Ihnen angegebenen Container-Instance gestartet wird. Dadurch wird sichergestellt, dass Ihre Ressourcen effektiv genutzt werden und dass Ihre Aufgaben für Deep-Learning-Workloads auf Ihren DL1 Instanzen liegen. Weitere Informationen finden Sie unter [So platziert Amazon ECS Aufgaben in Container-Instances](task-placement.md).

  Im folgenden Beispiel wird eine Aufgabe für eine `dl1.24xlarge`-Instance auf Ihrem `default`-Cluster ausgeführt.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition ecs-dl1-task-def \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == dl1.24xlarge"
  ```

## Verwenden eines DL1 AMI
<a name="ecs-dl1-ami"></a>

Sie haben drei Möglichkeiten, ein AMI auf Amazon EC2 DL1 EC2-Instances für Amazon ECS auszuführen:
+ AWS Marketplace AMIs [die von Habana hier bereitgestellt werden.](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq)
+ Habana Deep Learning AMIs , die von Amazon Web Services bereitgestellt werden. Weil er nicht enthalten ist, müssen Sie den Amazon-ECS-Container-Agent separat installieren.
+ Verwenden Sie Packer, um ein benutzerdefiniertes AMI zu erstellen, das vom [GitHubRepo](https://github.com/aws-samples/aws-habana-baseami-pipeline) bereitgestellt wird. Weitere Informationen finden Sie in der [Packer-Dokumentation](https://developer.hashicorp.com/packer/docs).

# Angeben von Deep Learning in einer Amazon-ECS-Aufgabendefinition
<a name="ecs-dl1-requirements"></a>

Um beschleunigte Deep Learning-Container von Habana Gaudi auf Amazon ECS auszuführen, muss Ihre Aufgabendefinition die Containerdefinition für einen vorgefertigten Container enthalten, der das Deep-Learning-Modell für TensorFlow oder PyTorch mithilfe von Habana SynapseAI bedient, das von Deep Learning Containers bereitgestellt wird. AWS 

Das folgende Container-Image hat 2.7.0 und Ubuntu 20.04. TensorFlow Eine vollständige Liste vorgefertigter Deep Learning Containers, die für die Gaudi-Beschleuniger von Habana optimiert sind, wird auf geführt. GitHub Weitere Informationen finden Sie unter [Habana Training Containers](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers).

```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-training-habana:2.7.0-hpu-py38-synapseai1.2.0-ubuntu20.04
```

Nachfolgend finden Sie ein Beispiel für eine Aufgabendefinition für Linux-Container auf Amazon EC2, das die zu verwendende Syntax veranschaulicht. In diesem Beispiel wird ein Image verwendet, das das Habana Labs System Management Interface Tool (HL-SMI) enthält, das hier zu finden ist: `vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614`

```
{
    "family": "dl-test",
    "requiresCompatibilities": ["EC2"],
    "placementConstraints": [
        {
            "type": "memberOf",
            "expression": "attribute:ecs.os-type == linux"
        },
        {
            "type": "memberOf",
            "expression": "attribute:ecs.instance-type == dl1.24xlarge"
        }
    ],
    "networkMode": "host",
    "cpu": "10240",
    "memory": "1024",
    "containerDefinitions": [
        {
            "entryPoint": [
                "sh",
                "-c"
            ],
            "command": ["hl-smi"],
            "cpu": 8192,
            "environment": [
                {
                    "name": "HABANA_VISIBLE_DEVICES",
                    "value": "all"
                }
            ],
            "image": "vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614",
            "essential": true,
            "name": "tensorflow-installer-tf-hpu"
        }
    ]
}
```

# Amazon-ECS-Aufgabendefinitionen für 64-Bit-ARM-Workloads
<a name="ecs-arm64"></a>

Amazon ECS unterstützt die Verwendung von 64-Bit-ARM-Anwendungen. Sie können Ihre Anwendungen auf der Plattform ausführen, die von [AWS -Graviton-Prozessoren](https://aws.amazon.com/ec2/graviton/) unterstützt wird. Sie ist für eine Vielzahl von Workloads geeignet. Dazu gehören Workloads wie Anwendungsserver, Microservices, Hochleistungs-Computing, CPU-basierte Machine Learning-Inferenz, Videocodierung, elektronische Designautomatisierung, Spiele, Open-Source-Datenbanken und In-Memory-Caches.

## Überlegungen
<a name="ecs-arm64-considerations"></a>

Beachten Sie die Folgendes, bevor Sie damit beginnen, Aufgabendefinitionen bereitzustellen, die die 64-Bit-ARM-Architektur verwenden:
+ Die Anwendungen können das Fargate oder EC2s verwenden.
+ Die Anwendungen können nur das Linux-Betriebssystem verwenden.
+ Für den Fargate-Typ müssen die Anwendungen die Fargate-Plattformversion `1.4.0` oder höher verwenden.
+ Die Anwendungen können Fluent Bit oder CloudWatch zur Überwachung verwenden.
+ Für Fargate unterstützen die folgenden Programme AWS-Regionen keine 64-Bit-ARM-Workloads:
  + USA Ost (Nord-Virginia), die `use1-az3` Availability Zone
+  Für EC2, beachten Sie Folgendes, um zu überprüfen, ob die Region, in der Sie sich befinden, den gewünschten Instance-Typ unterstützt:
  + [Amazon-EC2-M6g-Instances](https://aws.amazon.com/ec2/instance-types/m6)
  +  [Amazon-EC2-T4g-Instances](https://aws.amazon.com/ec2/instance-types/t4/)
  +  [Amazon-EC2-C6g-Instances](https://aws.amazon.com/ec2/instance-types/c6g/)
  +  [Amazon-EC2-R6gd-Instances](https://aws.amazon.com/ec2/instance-types/r6/)
  +  [Amazon-EC2-X2gd-Instances](https://aws.amazon.com/ec2/instance-types/x2/)

  Sie können auch den Amazon-EC2-Befehl `describe-instance-type-offerings` mit einem Filter verwenden, um das Instance-Angebot für Ihre Region anzuzeigen. 

  ```
  aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=instance-type --region region
  ```

  Im folgenden Beispiel wird die Verfügbarkeit des M6-Instance-Typs in der Region USA Ost (Nord-Virginia) (us-east-1) überprüft.

  ```
  aws ec2 describe-instance-type-offerings --filters "Name=instance-type,Values=m6*" --region us-east-1
  ```

  Weitere Informationen finden Sie [describe-instance-type-offerings ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)in der *Amazon EC2 EC2-Befehlszeilenreferenz.*

# Angeben der ARM-Architektur in einer Amazon-ECS-Aufgabendefinition
<a name="ecs-arm-specifying"></a>

Um die ARM-Architektur zu verwenden, geben Sie `ARM64` für den Aufgabendefinitions-Parameter `cpuArchitecture` an. 

Im folgenden Beispiel wird die ARM-Architektur in einer Aufgabendefinition angegeben. Sie ist im JSON-Format.

```
{
    "runtimePlatform": {
        "operatingSystemFamily": "LINUX",
        "cpuArchitecture": "ARM64"
    },
...
}
```

Im folgenden Beispiel zeigt eine Aufgabendefinition für die ARM-Architektur „Hallo Welt“ an.

```
{
 "family": "arm64-testapp",
 "networkMode": "awsvpc",
 "containerDefinitions": [
    {
        "name": "arm-container",
        "image": "public.ecr.aws/docker/library/busybox:latest",
        "cpu": 100,
        "memory": 100,
        "essential": true,
        "command": [ "echo hello world" ],
        "entryPoint": [ "sh", "-c" ]
    }
 ],
 "requiresCompatibilities": [ "EC2" ],
 "cpu": "256",
 "memory": "512",
 "runtimePlatform": {
        "operatingSystemFamily": "LINUX",
        "cpuArchitecture": "ARM64"
  },
 "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```

# Amazon ECS-Protokolle senden an CloudWatch
<a name="using_awslogs"></a>

Sie können die Container in Ihren Aufgaben so konfigurieren, dass Protokollinformationen an CloudWatch Logs gesendet werden. Wenn Sie Fargate für Ihre Aufgaben verwenden, können Sie die Protokolle von Ihren Containern anzeigen. Wenn Sie EC2 verwenden, können Sie verschiedene Protokolle Ihrer Container bequem an einem Ort aufrufen und es wird verhindert, dass Ihre Container-Protokolle Speicherplatz in Ihren Container-Instances belegen.

**Anmerkung**  
Der Typ der Informationen, die von den Containern in Ihrer Aufgabe protokolliert werden, hängt sehr stark von ihrem `ENTRYPOINT`-Befehl ab. Standardmäßig zeigen die erfassten Protokolle die Befehlsausgabe an, die Sie normalerweise in einem interaktiven Terminal sehen würden, wenn Sie den Container lokal ausführen. Dabei handelt es sich um die `STDOUT`- und `STDERR`-E/A-Streams. Der `awslogs` Protokolltreiber leitet diese Protokolle einfach von Docker an CloudWatch Logs weiter. Weitere Informationen dazu, wie Docker-Protokolle verarbeitet werden, einschließlich alternativer Möglichkeiten zum Erfassen unterschiedlicher Dateidaten oder Streams, finden Sie unter [Anzeigen von Protokollen für einen Container oder Service](https://docs.docker.com/engine/logging/) in der Docker-Dokumentation.

Informationen zum Senden von Systemprotokollen von Ihren Amazon ECS-Container-Instances an CloudWatch Logs finden Sie unter [Überwachung von Protokolldateien](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) und [CloudWatch Protokollkontingenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.

## Fargate
<a name="enable_awslogs"></a>

Wenn Sie Fargate für Ihre Aufgaben verwenden, müssen Sie für die Aktivierung des `awslogs`-Protokolltreibers die erforderlichen `logConfiguration`-Parameter in Ihre Aufgabendefinition einfügen. Weitere Informationen finden Sie unter [Beispiel für eine Amazon ECS-Aufgabendefinition: Protokolle weiterleiten an CloudWatch](specify-log-config.md).

Führen Sie für Windows-Container in uf Fargate eine der folgenden Optionen aus, wenn einer Ihrer Aufgabendefinitions-Parameter Sonderzeichen wie `& \ < > ^ |` enthält:
+ Fügen Sie ein Escape-Zeichen (`\`) mit doppelten Anführungszeichen um die gesamte Parameterzeichenfolge.

  Beispiel

  ```
  "awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"",
  ```
+ Fügen Sie ein Escape-Zeichen (`^`) vor und nach jedem Sonderzeichen hinzu.

  Beispiel

  ```
  "awslogs-multiline-pattern": "^^[^|DEBUG^|INFO^|WARNING^|ERROR",
  ```

## EC2
<a name="ec2-considerations"></a>

Wenn Sie EC2 für Ihre Aufgaben verwenden und den Protokolltreiber `awslogs` aktivieren möchten, benötigen Ihre Amazon-ECS-Container-Instances mindestens Version 1.9.0 des Container-Agenten. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).

**Anmerkung**  
Sie müssen entweder ein Amazon-ECS-optimiertes AMI oder ein benutzerdefiniertes AMI mit mindestens einer Version `1.9.0-1` des `ecs-init` Pakets verwenden. Wenn Sie ein benutzerdefiniertes AMI verwenden, müssen Sie angeben, dass der `awslogs`-Protokolltreiber auf der Amazon-EC2-Instance verfügbar ist, wenn Sie den Agenten starten, indem Sie die folgende Umgebungsvariable in Ihrer **docker run**-Anweisung oder Umgebungsvariablendatei verwenden.  

```
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
```

Ihre Amazon-ECS-Container-Instances benötigen auch eine `logs:CreateLogStream`- und `logs:PutLogEvents`-Berechtigung für die IAM-Rolle, mit der Sie Ihre Container-Instances starten. Wenn Sie die Amazon-ECS-Container-Instance-Rolle erstellt haben, bevor die Unterstützung des Protokolltreibers `awslogs` in Amazon ECS aktiviert war, müssen Sie diese Berechtigung eventuell hinzufügen. Die `ecsTaskExecutionRole` wird verwendet, wenn sie der Aufgabe zugewiesen ist und wahrscheinlich die richtigen Berechtigungen enthält. Weitere Informationen zur Aufgabenausführungsrolle finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md). Wenn Ihre Container-Instances die verwaltete IAM-Richtlinie für Container-Instances verwenden, verfügen sie wahrscheinlich über die korrekten Berechtigungen. Informationen zu der verwalteten IAM-Richtlinie für Container-Instances finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).

# Beispiel für eine Amazon ECS-Aufgabendefinition: Protokolle weiterleiten an CloudWatch
<a name="specify-log-config"></a>

Bevor Ihre Container Protokolle an senden können CloudWatch, müssen Sie den `awslogs` Protokolltreiber für Container in Ihrer Aufgabendefinition angeben. Weitere Informationen zu den Protokollparametern finden Sie unter [Speicher und Protokollierung](task_definition_parameters.md#container_definition_storage).

Bei der unten gezeigten Aufgabendefinition JSON wurde ein `logConfiguration`-Objekt für jeden Container festgelegt. Einer davon ist für den WordPress Container, der Protokolle an eine Protokollgruppe namens sendet`awslogs-wordpress`. Das andere für einen MySQL-Container, der Protokolle an eine Protokollgruppe mit dem Namen `awslogs-mysql` sendet. Beide Container verwenden den Protokoll-Stream-Präfix `awslogs-example`.

```
{
    "containerDefinitions": [
        {
            "name": "wordpress",
            "links": [
                "mysql"
            ],
            "image": "public.ecr.aws/docker/library/wordpress:latest",
            "essential": true,
            "portMappings": [
                {
                    "containerPort": 80,
                    "hostPort": 80
                }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-create-group": "true",
                    "awslogs-group": "awslogs-wordpress",
                    "awslogs-region": "us-west-2",
                    "awslogs-stream-prefix": "awslogs-example"
                }
            },
            "memory": 500,
            "cpu": 10
        },
        {
            "environment": [
                {
                    "name": "MYSQL_ROOT_PASSWORD",
                    "value": "password"
                }
            ],
            "name": "mysql",
            "image": "public.ecr.aws/docker/library/mysql:latest",
            "cpu": 10,
            "memory": 500,
            "essential": true,
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-create-group": "true",
                    "awslogs-group": "awslogs-mysql",
                    "awslogs-region": "us-west-2",
                    "awslogs-stream-prefix": "awslogs-example",
                    "mode": "non-blocking", 
                    "max-buffer-size": "25m" 
                }
            }
        }
    ],
    "family": "awslogs-example"
}
```

## Nächste Schritte
<a name="specify-log-config-next-steps"></a>
+ Sie können optional mithilfe der API CloudWatch AWS CLI oder eine Aufbewahrungsrichtlinie für die Protokollgruppe festlegen. Weitere Informationen finden Sie unter [put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) in der *AWS Command Line Interface -Referenz*.
+ Nachdem Sie eine Aufgabendefinition mit dem `awslogs` Protokolltreiber in einer Protokollkonfiguration für Containerdefinitionen registriert haben, können Sie eine Aufgabe ausführen oder einen Dienst mit dieser Aufgabendefinition erstellen, um mit dem Senden von Protokollen an Logs zu CloudWatch beginnen. Weitere Informationen erhalten Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md) und [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md).

# Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner
<a name="using_firelens"></a>

Sie können Amazon ECS verwenden FireLens , um Aufgabendefinitionsparameter zu verwenden, um Protokolle zur Protokollspeicherung und Analyse an ein AWS Service- oder AWS Partner Network (APN-) Ziel weiterzuleiten. The AWS Partner Network ist eine globale Partnergemeinschaft, die Programme, Fachwissen und Ressourcen nutzt, um Kundenangebote aufzubauen, zu vermarkten und zu verkaufen. Weitere Informationen finden Sie unter [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens arbeitet mit [Fluentd](https://www.fluentd.org/) und [Fluent Bit](https://fluentbit.io/). Wir stellen AWS für das Fluent Bit-Image bereit oder Sie können Ihr eigenes Fluentd- oder Fluent Bit-Image verwenden.

Standardmäßig konfiguriert Amazon ECS die Container-Abhängigkeit so, dass der Firelens-Container vor jedem Container gestartet wird, der ihn verwendet. Der Firelens-Container stoppt auch, nachdem alle Container, die ihn verwenden, angehalten sind.

Um diese Funktion nutzen zu können, müssen Sie eine IAM-Rolle für Ihre Aufgaben erstellen, die für die Nutzung aller AWS Dienste erforderlich sind, die für die Aufgaben erforderlich sind. Wenn ein Container beispielsweise Protokolle an Firehose weiterleitet, erfordert die Aufgabe die Berechtigung zum Aufrufen der `firehose:PutRecordBatch`-API. Informationen finden Sie im Abschnitt [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.

Unter den folgenden Bedingungen kann für Ihre Aufgabe auch die Amazon-ECS-Aufgabenausführungsrolle erforderlich sein. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
+ Wenn Ihre Aufgabe auf Fargate gehostet wird und Sie Container-Images aus Amazon ECR abrufen oder sensible Daten aus AWS Secrets Manager Ihrer Protokollkonfiguration referenzieren, müssen Sie die IAM-Rolle für die Aufgabenausführung angeben.
+ Wenn Sie eine benutzerdefinierte Konfigurationsdatei verwenden, die in Amazon S3 gehostet wird, muss Ihre IAM-Rolle für die Aufgabenausführung die `s3:GetObject`-Berechtigung enthalten.

Beachten Sie bei der Verwendung FireLens für Amazon ECS Folgendes:
+ Wir empfehlen, dass Sie dem Protokoll `my_service_` den Namen des Protokoll-Containers hinzufügen, damit Sie die Container-Namen in der Konsole leicht unterscheiden können.
+ Amazon ECS fügt standardmäßig eine Start-Abhängigkeit zwischen den Anwendungs-Containern und dem FireLens-Container hinzu. Wenn Sie eine Container-Reihenfolge zwischen den Anwendungscontainern und dem FireLens-Container angeben, wird die standardmäßige Reihenfolge der Startcontainer außer Kraft gesetzt.
+ FireLens für Amazon ECS wird für Aufgaben unterstützt, die sowohl auf AWS Fargate unter Linux als auch auf Amazon EC2 unter Linux gehostet werden. Windows-Container unterstützen FireLens nicht.

  Informationen zur Konfiguration der zentralen Protokollierung für Windows-Container finden Sie unter [Zentralisierte Protokollierung für Windows-Container auf Amazon ECS mit Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/).
+ Sie können CloudFormation Vorlagen zur Konfiguration FireLens für Amazon ECS verwenden. Weitere Informationen finden Sie [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)im *AWS CloudFormation Benutzerhandbuch*
+ FireLensüberwacht den Port. Um also sicherzustellen`24224`, dass der FireLens Log Router außerhalb der Aufgabe nicht erreichbar ist, dürfen Sie keinen eingehenden Verkehr über den Port `24224` in der Sicherheitsgruppe zulassen, die Ihre Aufgabe verwendet. Für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, ist dies die der Aufgabe zugeordnete Sicherheitsgruppe. Für Aufgaben, die den `host`-Netzwerkmodus verwenden, ist dies die Sicherheitsgruppe, die der Amazon-EC2-Instance zugeordnet ist, die die Aufgabe hostet. Für Aufgaben, die den `bridge`-Netzwerkmodus verwenden, erstellen Sie keine Portzuordnungen, die Port `24224` verwenden.
+ Bei Aufgaben, die den `bridge` Netzwerkmodus verwenden, muss der Container mit der FireLens Konfiguration vor allen Anwendungscontainern, die darauf angewiesen sind, gestartet werden. Um die Startreihenfolge Ihrer Container zu steuern, verwenden Sie Abhängigkeitsbedingungen in der Aufgabendefinition. Weitere Informationen finden Sie unter [Container-Abhängigkeit](task_definition_parameters.md#container_definition_dependson).
**Anmerkung**  
Wenn Sie Parameter für Abhängigkeitsbedingungen in Containerdefinitionen mit einer FireLens Konfiguration verwenden, stellen Sie sicher, dass für jeden Container eine `START` `HEALTHY` Oder-Bedingung erforderlich ist.
+ FireLensFügt standardmäßig den Namen der Cluster- und Aufgabendefinition sowie den Amazon-Ressourcennamen (ARN) des Clusters als Metadatenschlüssel zu Ihren stdout/stderr Container-Logs hinzu. Nachfolgend ist ein Beispiel für das Metadatenformat.

  ```
  "ecs_cluster": "cluster-name",
  "ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE",
  "ecs_task_definition": "task-def-name:revision",
  ```

  Wenn Sie die Metadaten nicht in Ihren Protokollen haben möchten, setzen Sie `enable-ecs-log-metadata` zu `false` im `firelensConfiguration`-Abschnitt der Aufgabendefinition.

  ```
  "firelensConfiguration":{
     "type":"fluentbit",
     "options":{
        "enable-ecs-log-metadata":"false",
        "config-file-type":"file",
        "config-file-value":"/extra.conf"
  }
  ```

Sie können den FireLens Container so konfigurieren, dass er als Benutzer ausgeführt wird, der kein Root-Benutzer ist. Berücksichtigen Sie dabei Folgendes:
+  Um den FireLens Container so zu konfigurieren, dass er als Nicht-Root-Benutzer ausgeführt wird, müssen Sie den Benutzer in einem der folgenden Formate angeben:
  + `uid`
  + `uid:gid`
  + `uid:group`

  Weitere Informationen zur Angabe eines Benutzers in einer Container-Definition finden Sie [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)in der *Amazon Elastic Container Service API-Referenz*.

  Der FireLens Container empfängt Anwendungsprotokolle über einen UNIX Socket. Der Amazon ECS-Agent verwendet den`uid`, um dem FireLens Container den Besitz des Socket-Verzeichnisses zuzuweisen.
+ Die Konfiguration des FireLens Containers für die Ausführung als Nicht-Root-Benutzer wird in der Amazon ECS-Agent-Version `1.96.0` und höher sowie in der Amazon ECS-optimierten AMI-Version `v20250716` und höher unterstützt.
+ Wenn Sie einen Benutzer für den FireLens Container angeben, muss dieser eindeutig sein und `uid` darf nicht für andere Prozesse verwendet werden, die zu anderen Containern in der Aufgabe oder der Container-Instance gehören.

Informationen zur Verwendung mehrerer Konfigurationsdateien mit Amazon ECS, einschließlich Dateien, die Sie hosten, oder Dateien in Amazon S3, finden Sie unter [Init-Prozess für Fluent Bit in ECS, Unterstützung für mehrfache Konfigurationen](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit).

Informationen zu Beispielkonfigurationen finden Sie unter[Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten](firelens-taskdef.md).

Weitere Informationen zur Konfiguration von Protokollen für hohen Durchsatz finden Sie unter[Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).

# Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz
<a name="firelens-docker-buffer-limit"></a>

Für Szenarien mit hohem Protokolldurchsatz empfehlen wir, den `awsfirelens` Protokolltreiber mit FireLens und zu verwenden. Fluent Bit Fluent Bitist ein leichter Protokollprozessor, der effizient mit Ressourcen umgeht und Millionen von Protokolldatensätzen verarbeiten kann. Um eine optimale Leistung im großen Maßstab zu erreichen, ist jedoch eine Anpassung der Konfiguration erforderlich.

In diesem Abschnitt werden fortgeschrittene Fluent Bit Optimierungstechniken für den Umgang mit hohem Protokolldurchsatz bei gleichzeitiger Wahrung der Systemstabilität und Vermeidung von Datenverlusten behandelt.

Hinweise zur Verwendung von benutzerdefinierten Konfigurationsdateien mit FireLens finden Sie unter[Eine benutzerdefinierte Konfigurationsdatei verwenden](firelens-taskdef.md#firelens-taskdef-customconfig). Weitere Beispiele finden Sie unter [Amazon FireLens ECS-Beispiele](https://github.com/aws-samples/amazon-ecs-firelens-examples) unter GitHub.

**Anmerkung**  
Einige Konfigurationsoptionen in diesem Abschnitt, wie z. B. `workers` und`threaded`, sind AWS für Fluent Bit Version 3 oder höher erforderlich. Informationen zu verfügbaren Versionen finden Sie unter [AWS Fluent Bit-Versionen](https://github.com/aws/aws-for-fluent-bit/releases).

## Chunks verstehen
<a name="firelens-understanding-chunks"></a>

Fluent Bit*verarbeitet Daten in Einheiten, die als Chunks bezeichnet werden.* Wenn ein INPUT-Plugin Daten empfängt, erstellt die Engine einen Block, der im Speicher oder im Dateisystem gespeichert wird, bevor er an OUTPUT-Ziele gesendet wird.

Das Pufferverhalten hängt von der `storage.type` Einstellung in Ihren INPUT-Abschnitten ab. Fluent BitVerwendet standardmäßig die Speicherpufferung. Bei Hochdurchsatz- oder Produktionsszenarien bietet die Dateisystempufferung eine bessere Stabilität.

[Weitere Informationen finden Sie in der Fluent Bit Dokumentation unter [Chunks](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) und Was ist ein Chunk?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) im Repository AWS für Fluent Bit Beispiele.

## Speicherpufferung (Standard)
<a name="firelens-memory-buffering"></a>

Fluent BitVerwendet standardmäßig Speicherpufferung ()`storage.type memory`. Mit dem `Mem_Buf_Limit` Parameter können Sie die Speichernutzung pro INPUT-Plugin einschränken.

Das folgende Beispiel zeigt eine speichergepufferte Eingabekonfiguration:

```
[INPUT]
    Name          tcp
    Tag           ApplicationLogs
    Port          5170
    storage.type  memory
    Mem_Buf_Limit 5MB
```

**Wichtig**  
Wenn `Mem_Buf_Limit` der Wert für ein Plugin überschritten wird, wird die Eingabe Fluent Bit unterbrochen und neue Datensätze gehen verloren. Dies kann zu Gegendruck führen und Ihre Anwendung verlangsamen. Die folgende Warnung wird in den Fluent Bit Protokollen angezeigt:  

```
[input] tcp.1 paused (mem buf overlimit)
```

Die Speicherpufferung eignet sich für einfache Anwendungsfälle mit geringem bis moderatem Protokolldurchsatz. Verwenden Sie für Szenarien mit hohem Durchsatz oder Produktionsszenarien, in denen Datenverlust ein Problem darstellt, stattdessen die Dateisystempufferung.

Weitere Informationen finden Sie unter [Buffering and Memory in der Fluent Bit Dokumentation und Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) [Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) im Repository for examples. AWS Fluent Bit

## Pufferung von Dateisystemen
<a name="firelens-filesystem-buffering"></a>

Für Szenarien mit hohem Durchsatz empfehlen wir die Verwendung der Dateisystempufferung. Weitere Informationen zur Fluent Bit Verwaltung von Pufferung und Speicherung finden Sie in der Dokumentation unter [Pufferung und](https://docs.fluentbit.io/manual/administration/buffering-and-storage) Speicherung. Fluent Bit

Die Pufferung von Dateisystemen bietet die folgenden Vorteile:
+ **Größere Pufferkapazität** — Festplattenspeicher ist in der Regel umfangreicher als Arbeitsspeicher.
+ **Persistenz** — Gepufferte Daten Fluent Bit überstehen Neustarts.
+ **Graduelle Verschlechterung** — Bei Ausgabeausfällen sammeln sich Daten auf der Festplatte an, anstatt zu einer Speichererschöpfung zu führen.

Um die Dateisystempufferung zu aktivieren, stellen Sie eine benutzerdefinierte Konfigurationsdatei bereit. Fluent Bit Das folgende Beispiel zeigt die empfohlene Konfiguration:

```
[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G
```

Die wichtigsten Konfigurationsparameter:

`storage.path`  
Das Verzeichnis, in dem gepufferte Chunks auf der Festplatte Fluent Bit gespeichert werden.

`storage.backlog.flush_on_shutdown`  
Wenn diese Option aktiviert ist, wird Fluent Bit versucht, beim Herunterfahren alle Backlog-Dateisystem-Chunks an ihre Ziele zu leeren. Dies trägt dazu bei, die Datenzustellung zu gewährleisten, bevor sie Fluent Bit unterbrochen wird, kann jedoch die Zeit für das Herunterfahren verlängern.

`storage.max_chunks_up`  
Die Anzahl der Chunks, die im Speicher verbleiben. Die Standardeinstellung ist 128 Chunks, was mehr als 500 MB Speicher beanspruchen kann, da jeder Chunk bis zu 4—5 MB belegen kann. In Umgebungen mit eingeschränktem Speicher sollten Sie diesen Wert verringern. Wenn Sie beispielsweise 50 MB für die Pufferung zur Verfügung haben, legen Sie diesen Wert auf 8—10 Blöcke fest.

`storage.type filesystem`  
Aktiviert den Dateisystemspeicher für das Eingabe-Plugin. Wird trotz des Namens Fluent Bit verwendet, `mmap` um Chunks sowohl dem Arbeitsspeicher als auch der Festplatte zuzuordnen, wodurch Persistenz ohne Leistungseinbußen gewährleistet wird.

`storage.total_limit_size`  
Der maximale Festplattenspeicher für gepufferte Daten für ein bestimmtes OUTPUT-Plugin. Wenn dieses Limit erreicht ist, werden die ältesten Datensätze für diese Ausgabe gelöscht. Weitere Informationen zur Größenbestimmung finden Sie unter[`storage.total_limit_size` verstehen](#firelens-storage-sizing).

`threaded true`  
Führt die Eingabe in einem eigenen Thread aus, getrennt von Fluent Bit der Hauptereignisschleife. Dadurch wird verhindert, dass langsame Eingaben die gesamte Pipeline blockieren.

Weitere Informationen finden Sie unter [Dateisystem-Pufferung](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) in der Fluent Bit Dokumentation und [Dateisystem- und Speicherpufferung im AWS Beispiel-Repository](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem). Fluent Bit

## `storage.total_limit_size` verstehen
<a name="firelens-storage-sizing"></a>

Der `storage.total_limit_size` Parameter jedes OUTPUT-Plug-ins steuert den maximalen Speicherplatz für gepufferte Daten für diese Ausgabe. Wenn dieses Limit erreicht ist, werden die ältesten Datensätze für diese Ausgabe gelöscht, um Platz für neue Daten zu schaffen. Wenn der Festplattenspeicher vollständig erschöpft ist, können Datensätze Fluent Bit nicht in die Warteschlange gestellt werden und sie gehen verloren.

Verwenden Sie die folgende Formel, um den entsprechenden Wert auf der `storage.total_limit_size` Grundlage Ihrer Protokollrate und des gewünschten Wiederherstellungsfensters zu berechnen:

```
If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000

storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)
```

Die folgende Tabelle zeigt Beispielberechnungen für gängige Protokollraten und Wiederherstellungsfenster:


| Protokollierungsrate | 1 Stunde | 6 Stunden | 12 Stunden | 24 Stunden | 
| --- | --- | --- | --- | --- | 
| 0,25 MB/s | 0,9 GB | 5,4 GB | 10,8 GB | 21,6 GB | 
| 0,5 MB/s | 1,8 GB | 10,8 GB | 21,6 GB | 43,2 GB | 
| 1 MB/s | 3,6 GB | 21,6 GB | 43,2 GB | 86,4 GB | 
| 5 MB/s | 18 GB | 108 GB | 216 GB | 432 GB | 
| 10 MB/s | 36 GB | 216 GB | 432 GB | 864 GB | 

Um den Spitzendurchsatz zu beobachten und geeignete Puffergrößen auszuwählen, verwenden Sie die [Messdurchsatzprobe. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)

Verwenden Sie die Formel, die Beispielberechnungen und das Benchmarking, um eine geeignete Lösung auszuwählen, die bei einem `storage.total_limit_size` Ausfall die Startbahn für eine optimale Wiederherstellung bietet.

## Speicheranforderungen für Amazon ECS-Aufgaben
<a name="firelens-storage-task-requirements"></a>

Summieren Sie alle `storage.total_limit_size` Werte der OUTPUT-Abschnitte und fügen Sie Puffer für Overhead hinzu. Diese Summe bestimmt den Speicherplatz, der in Ihrer Amazon ECS-Aufgabendefinition benötigt wird. Zum Beispiel 3 Ausgänge × jeweils 10 GB = 30 GB \$1 Puffer (5—10 GB) = insgesamt 35—40 GB erforderlich. Wenn die Summe den verfügbaren Speicherplatz übersteigt, Fluent Bit können Datensätze möglicherweise nicht in die Warteschlange gestellt werden und sie gehen verloren.

Die folgenden Speicheroptionen sind verfügbar:

Bind-Mounts (kurzlebiger Speicher)  
+ Für AWS Fargate ist die Standardeinstellung 20 GB flüchtiger Speicher (max. 200 GB). Konfigurieren Sie die Verwendung `ephemeralStorage` in der Aufgabendefinition. Weitere Informationen finden Sie unter [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) im *AWS CloudFormation -Benutzerhandbuch*.
+ Für EC2 ist die Standardeinstellung 30 GB, wenn das Amazon ECS-optimierte AMI verwendet wird (gemeinsam vom Betriebssystem und Docker genutzt). Erhöhen Sie den Wert, indem Sie die Größe des Root-Volumes ändern.

Amazon-EBS-Volumes  
+ Bietet hochverfügbaren, langlebigen und leistungsstarken Blockspeicher.
+ Erfordert die Volume-Konfiguration und das Verweisen auf `storage.path` (Standard:`/var/log/flb-storage/`) `mountPoint` in der Aufgabendefinition.
+ Weitere Informationen finden Sie unter [Die Volume-Konfiguration auf die Startzeit in einer Amazon-ECS-Aufgabendefinition verschieben](specify-ebs-config.md).

Amazon EFS-Volumes  
+ Bietet einfachen, skalierbaren Dateispeicher.
+ Erfordert die Volume-Konfiguration und das Verweisen auf `storage.path` (Standard:`/var/log/flb-storage/`) `mountPoint` in der Aufgabendefinition.
+ Weitere Informationen finden Sie unter [Ein Amazon-EFS-Dateisystems in einer Amazon-ECS-Aufgabendefinition angeben](specify-efs-config.md).

Weitere Hinweise zu Datenvolumen finden Sie unter[Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).

## Optimieren Sie die Ausgabekonfiguration
<a name="firelens-output-optimization"></a>

Netzwerkprobleme, Dienstausfälle und Drosselung von Zielen können die Übermittlung von Protokollen verhindern. Die richtige Ausgangskonfiguration gewährleistet Ausfallsicherheit ohne Datenverlust.

Wenn ein Output-Flush fehlschlägt, Fluent Bit kann der Vorgang erneut versucht werden. Die folgenden Parameter steuern das Verhalten bei Wiederholungsversuchen:

`retry_limit`  
Die maximale Anzahl von Wiederholungen nach dem ersten Versuch vor dem Löschen von Datensätzen. Der Standardwert ist 1. `retry_limit 3`Bedeutet beispielsweise insgesamt 4 Versuche (1 erster Versuch \$1 3 Wiederholungen). Für Produktionsumgebungen empfehlen wir 15 oder mehr, was einen Ausfall von mehreren Minuten mit exponentiellem Backoff abdeckt.  
Auf `no_limits` oder `False` für unendliche Wiederholungsversuche setzen:  
+ Bei der Speicherpufferung führen unendliche Wiederholungen dazu, dass das Eingabe-Plugin pausiert, wenn die Speichergrenzen erreicht sind.
+ Bei der Dateisystempufferung werden die ältesten Datensätze gelöscht, wenn sie erreicht sind. `storage.total_limit_size`
Wenn alle Wiederholungsversuche ausgeschöpft sind (1 anfänglich \$1 `retry_limit` Wiederholungen), werden die Datensätze gelöscht. AWS Plugins mit `auto_retry_requests true` (Standard) bieten vor Fluent Bit dem Wiederholungsmechanismus eine zusätzliche Wiederholungsebene. Weitere Informationen finden Sie in der Dokumentation unter [Konfigurieren von Wiederholungen](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries). Fluent Bit  
`retry_limit 3`Mit den Standardeinstellungen bietet (, `scheduler.base 5``scheduler.cap 2000`,`net.connect_timeout 10s`) beispielsweise etwa 70 Sekunden Wartezeit im Scheduler (10 s \$1 20 s \$1 40 s), 40 Sekunden Timeouts für Netzwerkverbindungen (4 Versuche × 10 s) sowie AWS Plugin-Wiederholungen — insgesamt etwa 2—10 Minuten, abhängig von den Netzwerkbedingungen und den TCP-Timeouts des Betriebssystems.

`scheduler.base`  
Die Basissekunden zwischen Wiederholungen (Standard: 5). Wir empfehlen 10 Sekunden.

`scheduler.cap`  
Die maximale Anzahl von Sekunden zwischen Wiederholungen (Standard: 2000). Wir empfehlen 60 Sekunden.

Bei der Wartezeit zwischen Wiederholungen wird ein exponentieller Backoff mit Jitter verwendet:

```
wait_time = random(base, min(base × 2^retry_number, cap))
```

Zum Beispiel mit und: `scheduler.base 10` `scheduler.cap 60`
+ Erster Versuch: zufällige Wartezeit zwischen 10 und 20 Sekunden
+ Zweiter Wiederholungsversuch: zufällige Wartezeit zwischen 10—40 Sekunden
+ Dritter Wiederholungsversuch und später: zufällige Wartezeit zwischen 10—60 Sekunden (begrenzt)

[Weitere Informationen finden Sie in der Dokumentation unter [Wartezeit für Wiederholungsversuche konfigurieren und Netzwerk](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry).](https://docs.fluentbit.io/manual/administration/networking) Fluent Bit

`workers`  
Die Anzahl der Threads für die parallel Ausgangsverarbeitung. Mehrere Worker ermöglichen gleichzeitige Löschvorgänge, wodurch der Durchsatz bei der Verarbeitung vieler Blöcke verbessert wird.

`auto_retry_requests`  
Eine AWS Plugin-spezifische Einstellung, die vor dem integrierten Wiederholungsmechanismus eine zusätzliche Wiederholungsebene bietet. Fluent Bit Der Standardwert ist `true`. Wenn diese Option aktiviert ist, wiederholt das AWS Ausgabe-Plug-In intern fehlgeschlagene Anfragen erneut, bevor die Anfrage als fehlgeschlagener Flush betrachtet wird und von der Konfiguration abhängt. `retry_limit`

Der `Grace` Parameter in `[SERVICE]` diesem Abschnitt legt fest, wie lange es dauert, bis die gepufferten Fluent Bit Daten geleert werden, wenn das System heruntergefahren wird. Der `Grace` Zeitraum muss mit dem des Containers abgestimmt werden. `stopTimeout` Stellen Sie sicher, dass der `Grace` Zeitraum `stopTimeout` überschritten wird, Fluent Bit damit der Spülvorgang vor dem Empfang `SIGKILL` abgeschlossen werden kann. Wenn der Wert beispielsweise 120 Sekunden `Grace` beträgt, stellen Sie ihn `stopTimeout` auf 150 Sekunden ein.

Das folgende Beispiel zeigt eine vollständige Fluent Bit Konfiguration mit allen empfohlenen Einstellungen für Szenarien mit hohem Durchsatz:

```
[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On
    # Minimum seconds between retries
    scheduler.base           10
    # Maximum seconds between retries (exponential backoff cap)
    scheduler.cap            60

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G
```

## Datenverlustszenarien verstehen
<a name="firelens-record-loss-scenarios"></a>

Bei längeren Ausfällen oder Problemen mit Ausgabezielen können Datensätze verloren gehen. Bei den Konfigurationsempfehlungen in diesem Handbuch handelt es sich um Methoden zur Minimierung von Datenverlusten, es kann jedoch nicht garantiert werden, dass bei längeren Ausfällen kein Datenverlust auftritt. Das Verständnis dieser Szenarien hilft Ihnen bei der KonfigurationFluent Bit, um die Ausfallsicherheit zu maximieren.

Datensätze können auf zwei Arten verloren gehen: Die ältesten Datensätze werden gelöscht, wenn der Speicher voll ist, oder die neuesten Datensätze werden zurückgewiesen, wenn das System keine weiteren Daten akzeptieren kann.

### Die ältesten Datensätze wurden gelöscht
<a name="firelens-record-loss-oldest-dropped"></a>

Die ältesten gepufferten Datensätze werden gelöscht, wenn die Wiederholungsversuche erschöpft sind oder wenn sie `storage.total_limit_size` voll sind und Platz für neue Daten geschaffen werden muss.

Das Limit für Wiederholungsversuche wurde überschritten  
Tritt auf, nachdem AWS das Plugin erneut versucht hat (wenn`auto_retry_requests true`) plus einem ersten Fluent Bit Versuch plus `retry_limit` Wiederholungen. Um dies zu vermeiden, legen Sie `retry_limit no_limits` pro OUTPUT-Plugin eine unendliche Anzahl von Wiederholungsversuchen fest:  

```
[OUTPUT]
    Name                        cloudwatch_logs
    Match                       ApplicationLogs
    retry_limit                 no_limits
    auto_retry_requests         true
```
Unendliche Wiederholungsversuche verhindern, dass Datensätze gelöscht werden, weil die Wiederholungsversuche erschöpft sind, können aber dazu führen, dass sie voll werden. `storage.total_limit_size`

Speicherlimit erreicht (Dateisystem-Pufferung)  
Tritt auf, wenn das Ausgabeziel länger nicht verfügbar ist, als Ihr konfigurierter Puffer speichern `storage.total_limit_size` kann. Ein Puffer von 10 GB bei einer MB/s Protokollrate von 1 bietet beispielsweise eine Pufferung von etwa 2,7 Stunden. Um dies zu vermeiden, erhöhen Sie die Anzahl `storage.total_limit_size` pro OUTPUT-Plugin und stellen Sie ausreichend Amazon ECS-Aufgabenspeicher bereit:  

```
[OUTPUT]
    Name                        cloudwatch_logs
    Match                       ApplicationLogs
    storage.total_limit_size    10G
```

### Die neuesten Datensätze wurden zurückgewiesen
<a name="firelens-record-loss-newest-rejected"></a>

Die neuesten Datensätze werden gelöscht, wenn der Festplattenspeicher erschöpft ist oder wenn die Eingabe aufgrund von unterbrochen wird. `Mem_Buf_Limit`

Festplattenspeicher erschöpft (Dateisystem-Pufferung)  
Tritt auf, wenn der Festplattenspeicher vollständig erschöpft ist. Fluent Bitkann neue Datensätze nicht in die Warteschlange stellen und sie gehen verloren. Um dies zu vermeiden, summieren Sie alle `storage.total_limit_size` Werte und stellen Sie einen angemessenen Amazon ECS-Aufgabenspeicher bereit. Weitere Informationen finden Sie unter [Speicheranforderungen für Amazon ECS-Aufgaben](#firelens-storage-task-requirements).

Speicherlimit erreicht (Speicherpufferung)  
Tritt auf, wenn das Ausgabeziel nicht verfügbar ist und der Speicherpuffer voll ist. Pausierte Eingabe-Plugins akzeptieren keine neuen Datensätze mehr. Zur Minderung, zur Erhöhung der Widerstandsfähigkeit oder `storage.type filesystem` zur Erhöhung der Widerstandsfähigkeit verwenden. `Mem_Buf_Limit`

### Bewährte Methoden zur Minimierung von Datenverlusten
<a name="firelens-record-loss-best-practices"></a>

Beachten Sie die folgenden bewährten Methoden zur Minimierung von Datenverlusten:
+ **Dateisystem-Pufferung verwenden — Diese** Option sorgt `storage.type filesystem` für eine bessere Ausfallsicherheit bei Ausfällen.
+ **Speicher angemessen dimensionieren** — Die Berechnung `storage.total_limit_size` basiert auf der Protokollrate und dem gewünschten Wiederherstellungsfenster.
+ Stellen **Sie eine angemessene Festplatte** bereit — Stellen Sie sicher, dass die Amazon ECS-Aufgabe über ausreichend kurzlebigen Speicher, Amazon EBS oder Amazon EFS verfügt.
+ **Wiederholungsverhalten konfigurieren — Ausgewogen zwischen `retry_limit` (löscht Datensätze nach anstrengenden Wiederholungsversuchen**) und `no_limits` (Wiederholungen auf unbestimmte Zeit, können aber Speicherplatz füllen).

## Verwenden Sie aus Gründen der Zuverlässigkeit die Protokollierung für mehrere Ziele
<a name="firelens-multi-destination"></a>

Durch das Senden von Protokollen an mehrere Ziele werden einzelne Fehlerquellen vermieden. Wenn CloudWatch Logs beispielsweise ausfällt, erreichen die Protokolle immer noch Amazon S3.

Die Protokollierung mehrerer Ziele bietet die folgenden Vorteile. Das Amazon S3 S3-Ausgabe-Plugin unterstützt auch Komprimierungsoptionen wie Gzip und Parquet-Format, wodurch die Speicherkosten gesenkt werden können. Weitere Informationen finden Sie in der Fluent Bit Dokumentation unter [S3-Komprimierung](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression).

Die Protokollierung mehrerer Ziele kann die folgenden Vorteile bieten:
+ **Redundanz** — Wenn ein Ziel ausfällt, erreichen die Protokolle immer noch das andere.
+ **Wiederherstellung** — Rekonstruieren Sie Lücken in einem System vom anderen.
+ **Haltbarkeit** — Archivieren Sie Protokolle zur langfristigen Aufbewahrung in Amazon S3.
+ **Kostenoptimierung** — Bewahren Sie aktuelle Protokolle in einem schnellen Abfrageservice wie CloudWatch Logs mit kürzerer Aufbewahrung auf und archivieren Sie gleichzeitig alle Protokolle zur langfristigen Aufbewahrung auf kostengünstigerem Amazon S3 S3-Speicher.

Die folgende Fluent Bit Konfiguration sendet CloudWatch Protokolle sowohl an Logs als auch an Amazon S3:

```
[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    workers 2
    retry_limit 15

[OUTPUT]
    Name s3
    Match *
    bucket my-logs-bucket
    region us-west-2
    total_file_size 100M
    s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
    upload_timeout 10m
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 5G
```

Beide Ausgaben verwenden dasselbe `Match *` Muster, sodass alle Datensätze unabhängig voneinander an beide Ziele gesendet werden. Während eines Ausfalls eines Ziels fließen die Protokolle weiter zum anderen, während sich fehlgeschlagene Leerungen im Dateisystempuffer ansammeln, sodass sie es später erneut versuchen können.

## Verwenden Sie die dateibasierte Protokollierung mit dem Tail-Input-Plugin
<a name="firelens-tail-input"></a>

Für Szenarien mit hohem Durchsatz, in denen der Verlust von Protokollen ein kritisches Problem darstellt, können Sie einen alternativen Ansatz verwenden: Lassen Sie Ihre Anwendung Protokolle in Dateien auf der Festplatte schreiben und konfigurieren Sie sie so, dass sie mithilfe des Fluent Bit `tail` Eingabe-Plug-ins gelesen werden. Bei diesem Ansatz wird die Treiberschicht für die Docker-Protokollierung vollständig umgangen.

Die dateibasierte Protokollierung mit dem Tail-Plugin bietet die folgenden Vorteile:
+ **Offset-Tracking** — Das Tail-Plugin kann Datei-Offsets in einer Datenbankdatei speichern (mit der `DB` Option) und sorgt so für Stabilität bei Neustarts. Fluent Bit Dies trägt dazu bei, den Verlust von Protokollen bei Container-Neustarts zu verhindern.
+ **Pufferung auf Eingabeebene** — Sie können die Speicherpuffergrenzen direkt im Eingabe-Plugin konfigurieren`Mem_Buf_Limit`, sodass Sie die Speichernutzung genauer steuern können.
+ **Vermeidet Docker-Overhead** — Protokolle werden direkt von Datei zu Datei übertragen, Fluent Bit ohne die Protokollpuffer von Docker zu durchlaufen.

Um diesen Ansatz zu verwenden, muss Ihre Anwendung Protokolle statt in Dateien schreiben. `stdout` Sowohl der Anwendungscontainer als auch der Fluent Bit Container mounten ein gemeinsam genutztes Volume, auf dem die Protokolldateien gespeichert werden.

Das folgende Beispiel zeigt eine Konfiguration mit Tail-Eingaben mit bewährten Methoden:

```
[INPUT]
    Name tail
    # File path or glob pattern to tail
    Path /var/log/app.log
    # Database file for storing file offsets (enables resuming after restart)
    DB /var/log/flb_tail.db
    # when true, controls that only fluent-bit will access the database (improves performance)
    DB.locking true
    # Skip long lines instead of skipping the entire file
    Skip_Long_Lines On
    # How often (in seconds) to check for new files matching the glob pattern
    Refresh_Interval 10
    # Extra seconds to monitor a file after rotation to account for pending flush
    Rotate_Wait 30
    # Maximum size of the buffer for a single line
    Buffer_Max_Size 10MB
    # Initial allocation size for reading file data
    Buffer_Chunk_Size 1MB
    # Maximum memory buffer size (tail pauses when full)
    Mem_Buf_Limit 75MB
```

Beachten Sie bei der Verwendung des Tail-Input-Plug-ins Folgendes:
+ Implementieren Sie die Protokollrotation für Ihre Anwendungsprotokolle, um eine Überlastung der Festplatte zu verhindern. Überwachen Sie die zugrunde liegenden Volumenmetriken, um die Leistung zu messen.
+ Erwägen Sie Einstellungen wie `Ignore_Older``Read_from_Head`, und mehrzeilige Parser, die auf Ihrem Protokollformat basieren.

Weitere Informationen finden Sie in der Dokumentation unter [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail). Fluent Bit Bewährte Methoden finden Sie unter [Tail-Konfiguration mit bewährten Methoden](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) im Leitfaden AWS zur Fluent Bit Fehlerbehebung.

## Loggen Sie sich direkt ein bei FireLens
<a name="firelens-environment-variables"></a>

Wenn der `awsfirelens`-Protokolltreiber in einer Aufgabendefinition angegeben wird, injiziert der Amazon ECS Container-Agent die folgenden Umgebungsvariablen in den Container:

`FLUENT_HOST`  
Die IP-Adresse, die dem FireLens Container zugewiesen ist.  
Wenn Sie EC2 im `bridge` Netzwerkmodus verwenden, kann die `FLUENT_HOST` Umgebungsvariable in Ihrem Anwendungscontainer nach einem Neustart des FireLens Log-Router-Containers (des Containers mit dem `firelensConfiguration` Objekt in seiner Containerdefinition) ungenau werden. Das liegt daran, dass `FLUENT_HOST` eine dynamische IP-Adresse ist, die sich nach einem Neustart ändern kann. Die direkte Protokollierung vom Anwendungs-Container zur `FLUENT_HOST` IP-Adresse kann nach einer Adressänderung fehlschlagen. Weitere Informationen zum Neustart einzelner Container finden Sie unter [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md).

`FLUENT_PORT`  
Der Port, über den das Fluent Forward-Protokoll kommuniziert.

Sie können diese Umgebungsvariablen verwenden, um sich direkt von Ihrem Anwendungscode aus mit dem Fluent Forward-Protokoll Fluent Bit beim Log Router anzumelden, anstatt in diesen zu schreiben. `stdout` Bei diesem Ansatz wird die Treiberschicht für die Docker-Protokollierung umgangen, was die folgenden Vorteile bietet:
+ **Geringere Latenz** — Protokolle werden direkt an die Protokollierungsinfrastruktur von Docker weitergeleitet, Fluent Bit ohne sie zu passieren.
+ **Strukturierte Protokollierung** — Senden Sie strukturierte Protokolldaten nativ ohne zusätzlichen Aufwand für die JSON-Codierung.
+ **Bessere Kontrolle** — Ihre Anwendung kann ihre eigene Pufferungs- und Fehlerbehandlungslogik implementieren.

Die folgenden Fluent-Logger-Bibliotheken unterstützen das Fluent Forward-Protokoll und können verwendet werden, um Protokolle direkt an zu senden: Fluent Bit
+ **Go** – [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python** – [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Java** – [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js** – [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby** – [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)

## Konfigurieren Sie das Docker-Pufferlimit
<a name="firelens-buffer-limit"></a>

Wenn Sie eine Aufgabendefinition erstellen, können Sie die Anzahl der Protokollzeilen angeben, die im Speicher gepuffert werden, indem Sie den Wert in angeben. `log-driver-buffer-limit` Dies steuert den Puffer zwischen Docker und. Fluent Bit Weitere Informationen finden Sie unter [Fluentd-Protokollierungstreiber](https://docs.docker.com/engine/logging/drivers/fluentd/) in der Docker-Dokumentation.

Verwenden Sie diese Option bei hohem Durchsatz, da Docker möglicherweise der Pufferspeicher ausgeht und Puffermeldungen verworfen werden, damit neue Nachrichten hinzugefügt werden können.

Beachten Sie bei der Verwendung dieser Option Folgendes:
+ Diese Option wird in EC2 und Fargate mit Plattformversion `1.4.0` oder höher unterstützt.
+ Die Option ist nur gültig, wenn `logDriver` auf `awsfirelens` gesetzt ist.
+ Das Standard-Pufferlimit ist `1048576` Protokollzeilen.
+ Das Pufferlimit muss größer oder gleich `0` und kleiner als `536870912`-Protokollzeilen sein.
+ Die maximale Menge an Arbeitsspeicher, die für diesen Puffer verwendet wird, ist die Summe der Größe jeder Protokollzeile und der Größe des Puffers. Wenn die Protokollzeilen der Anwendung beispielsweise im Durchschnitt `2` KiB betragen, würde ein Pufferlimit von 4096 höchstens `8` MiB verbrauchen. Die Gesamtmenge des auf Aufgabenebene zugewiesenen Arbeitsspeichers muss zusätzlich zum Arbeitsspeicher-Puffer des Protokolltreibers größer sein als die für alle Container zugewiesene Menge an Arbeitsspeicher.

Die folgende Aufgabendefinition zeigt, wie die Konfiguration erfolgt: `log-driver-buffer-limit`

```
{
    "containerDefinitions": [
        {
            "name": "my_service_log_router",
            "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
            "cpu": 0,
            "memoryReservation": 51,
            "essential": true,
            "firelensConfiguration": {
                "type": "fluentbit"
            }
        },
        {
            "essential": true,
            "image": "public.ecr.aws/docker/library/httpd:latest",
            "name": "app",
            "logConfiguration": {
                "logDriver": "awsfirelens",
                "options": {
                    "Name": "firehose",
                    "region": "us-west-2",
                    "delivery_stream": "my-stream",
                    "log-driver-buffer-limit": "52428800"
                }
            },
            "dependsOn": [
                {
                    "containerName": "my_service_log_router",
                    "condition": "START"
                }
            ],
            "memoryReservation": 100
        }
    ]
}
```

# AWS für Fluent Bit Bild-Repositorys für Amazon ECS
<a name="firelens-using-fluentbit"></a>

AWS bietet ein Fluent Bit Image mit Plugins für CloudWatch Logs und Firehose. Es wird empfohlen, Fluent Bit als Protokoll-Router zu verwenden, da es eine geringere Ressourcenauslastung aufweist als Fluentd. Weitere Informationen finden Sie unter [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) und [Amazon Kinesis Firehose for](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) Fluent Bit.

Das **AWS for Fluent Bit-Bild** ist auf Amazon ECR sowohl in der Amazon ECR Public Gallery als auch in einem Amazon ECR-Repository für hohe Verfügbarkeit verfügbar.

## Öffentliche Galerie Amazon ECR
<a name="firelens-image-ecrpublic"></a>

Das Fluent Bit Bild AWS für ist in der Amazon ECR Public Gallery verfügbar. Dies ist der empfohlene Ort, um das Fluent Bit Bild AWS für herunterzuladen, da es sich um ein öffentliches Repository handelt, das von allen AWS-Regionen genutzt werden kann. Weitere Informationen finden Sie in der [aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)Amazon ECR Public Gallery.

### Linux
<a name="firelens-image-ecrpublic-linux"></a>

Das AWS Fluent Bit For-Bild in der Amazon ECR Public Gallery unterstützt das Amazon Linux-Betriebssystem mit der `ARM64` `x86-64` OR-Architektur.

Sie können das AWS Fluent Bit For-Bild aus der Amazon ECR Public Gallery abrufen, indem Sie die Repository-URL mit dem gewünschten Image-Tag angeben. Die verfügbaren Image-Tags finden Sie in der Registerkarte **Image-Tags** auf der Amazon ECR Public Gallery.

Nachfolgend finden Sie die für die Docker-CLI zu verwendende Syntax.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```

Mit diesem Docker-CLI-Befehl können Sie beispielsweise das neueste Image der „3.x“ -Familie AWS für Fluent Bit Releases abrufen.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```

**Anmerkung**  
Nicht authentifizierte Pulls sind zulässig, haben jedoch eine niedrigere Rate als authentifizierte Pulls. Verwenden Sie den folgenden Befehl, um sich vor dem Abrufen mit Ihrem AWS Konto zu authentifizieren.  

```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```

#### AWS für 3.0.0 Fluent Bit
<a name="firelens-image-ecrpublic-linux-3.0.0"></a>

Zusätzlich zu den vorhandenen Fluent Bit Versionen AWS `2.x` für Fluent Bit unterstützt AWS for eine neue Hauptversion`3.x`. Die neue Hauptversion beinhaltet das Upgrade von Images von Amazon Linux 2 auf Amazon Linux 2023 und Fluent Bit Version `1.9.10` auf`4.1.1`. Weitere Informationen finden Sie im [AWSFluent BitFor-Repository](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) unterGitHub.

Die folgenden Beispiele zeigen aktualisierte Tags AWS für Fluent Bit `3.x` Bilder:

Sie können Multiarchitektur-Tags AWS für das Fluent Bit FOR-Bild verwenden.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```

### Windows
<a name="firelens-image-ecrpublic-windows"></a>

Das Fluent Bit Bild AWS for in der Amazon ECR Public Gallery unterstützt die `AMD64` Architektur mit den folgenden Betriebssystemen:
+ Windows Server 2022 Voll
+ Windows Server 2022 Kern
+ Windows Server 2019 Voll
+ Windows Server 2019 Kern

Windows-Container, die sich auf AWS Fargate befinden, werden nicht unterstützt FireLens.

Sie können das AWS Fluent Bit For-Bild aus der Amazon ECR Public Gallery abrufen, indem Sie die Repository-URL mit dem gewünschten Image-Tag angeben. Die verfügbaren Image-Tags finden Sie in der Registerkarte **Image-Tags** auf der Amazon ECR Public Gallery.

Nachfolgend finden Sie die für die Docker-CLI zu verwendende Syntax.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```

Mit diesem Docker-CLI-Befehl können Sie beispielsweise den neuesten Stable AWS for Fluent Bit Image abrufen.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable
```

**Anmerkung**  
Nicht authentifizierte Pulls sind zulässig, haben jedoch eine niedrigere Rate als authentifizierte Pulls. Verwenden Sie den folgenden Befehl, um sich vor dem Abrufen mit Ihrem AWS Konto zu authentifizieren.  

```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```

## Amazon ECR
<a name="firelens-image-ecr"></a>

Das AWS for Fluent Bit-Bild ist auf Amazon ECR für hohe Verfügbarkeit verfügbar. Die folgenden Befehle können verwendet werden, um ein Bild abzurufen URIs und die Verfügbarkeit eines Bilds für ein bestimmtes Bild festzulegen. AWS-Region

### Linux
<a name="firelens-image-ecr-linux"></a>

Der neueste stabile Bild-URI AWS für Fluent Bit kann mit dem folgenden Befehl abgerufen werden.

```
aws ssm get-parameters \
      --names /aws/service/aws-for-fluent-bit/stable \
      --region us-east-1
```

Alle Versionen des AWS for Fluent Bit-Images können mit dem folgenden Befehl aufgelistet werden, um den Systems Manager Parameter Store-Parameter abzufragen.

```
aws ssm get-parameters-by-path \
      --path /aws/service/aws-for-fluent-bit \
      --region us-east-1
```

Das neueste stabile Bild AWS für Fluent Bit kann in einer CloudFormation Vorlage referenziert werden, indem auf den Namen des Systems Manager Manager-Parameterspeichers verwiesen wird. Im Folgenden wird ein Beispiel gezeigt:

```
Parameters:
  FireLensImage:
    Description: Fluent Bit image for the FireLens Container
    Type: AWS::SSM::Parameter::Value<String>
    Default: /aws/service/aws-for-fluent-bit/stable
```

**Anmerkung**  
Wenn der Befehl fehlschlägt oder keine Ausgabe erfolgt, ist das Bild in der Datei, AWS-Region in der der Befehl aufgerufen wurde, nicht verfügbar.

### Windows
<a name="firelens-image-ecr-windows"></a>

Die neueste stabile Bild-URI AWS für Fluent Bit kann mit dem folgenden Befehl abgerufen werden.

```
aws ssm get-parameters \
      --names /aws/service/aws-for-fluent-bit/windowsservercore-stable \
      --region us-east-1
```

Alle Versionen des AWS for Fluent Bit-Images können mit dem folgenden Befehl aufgelistet werden, um den Systems Manager Parameter Store-Parameter abzufragen.

```
aws ssm get-parameters-by-path \
      --path /aws/service/aws-for-fluent-bit/windowsservercore \
      --region us-east-1
```

Das neueste stabile Bild AWS für Fluent Bit kann in einer CloudFormation Vorlage referenziert werden, indem auf den Namen des Systems Manager Manager-Parameterspeichers verwiesen wird. Im Folgenden wird ein Beispiel gezeigt:

```
Parameters:
  FireLensImage:
    Description: Fluent Bit image for the FireLens Container
    Type: AWS::SSM::Parameter::Value<String>
    Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable
```

# Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten
<a name="firelens-taskdef"></a>

Um ein benutzerdefiniertes Protokoll-Routing mit FireLens zu verwenden, müssen Sie Folgendes in der Aufgabendefinition angeben:
+ Ein Protokoll-Router-Container, der eine FireLens-Konfiguration enthält. Wir empfehlen, dass der Container als `essential` markiert wird.
+ Ein oder mehrere Anwendungscontainer, die eine Protokollkonfiguration enthalten, die den `awsfirelens`-Protokolltreiber angibt.
+ Ein Aufgaben-IAM-Rollen-Amazon-Ressourcenname (ARN), der die Berechtigungen enthält, die für die Aufgabe zum Weiterleiten der Protokolle erforderlich sind.

Beim Erstellen einer neuen Aufgabendefinition mithilfe von gibt es einen FireLens Integrationsbereich AWS-Managementkonsole, der das Hinzufügen eines Protokoll-Router-Containers erleichtert. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).

Amazon ECS konvertiert die Protokollkonfiguration und generiert die Fluentd- oder Fluent Bit-Ausgabekonfiguration. Die Ausgabekonfiguration ist in dem Protokoll-Routing-Container unter `/fluent-bit/etc/fluent-bit.conf` für Fluent Bit und `/fluentd/etc/fluent.conf` für Fluentd eingebaut.

**Wichtig**  
FireLens überwacht Port `24224`. Um sicherzustellen, dass der FireLens Log Router außerhalb der Aufgabe nicht erreichbar ist, dürfen Sie daher keinen eingehenden Datenverkehr über den Port `24224` in der Sicherheitsgruppe zulassen, die Ihre Aufgabe verwendet. Für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, ist dies die der Aufgabe zugeordnete Sicherheitsgruppe. Für Aufgaben, die den `host`-Netzwerkmodus verwenden, ist dies die Sicherheitsgruppe, die der Amazon-EC2-Instance zugeordnet ist, die die Aufgabe hostet. Für Aufgaben, die den `bridge`-Netzwerkmodus verwenden, erstellen Sie keine Portzuordnungen, die Port `24224` verwenden.

In den Protokolleinträgen werden standardmäßig zusätzliche Felder von Amazon ECS hinzugefügt, mit denen die Quelle der Protokolle identifiziert werden kann. 
+ `ecs_cluster` – Der Name des Clusters, zu dem die Aufgabe gehört.
+ `ecs_task_arn` – Der vollständige Amazon-Ressourcenname (ARN) der Aufgabe, zu der der Container gehört.
+ `ecs_task_definition` – Der Name und die Revision der Aufgabendefinition, die die Aufgabe verwendet.
+ `ec2_instance_id` – Die Amazon-EC2-Instance-ID, auf der der Container gehostet wird. Dieses Feld ist nur für Aufgaben mit dem Starttyp EC2 gültig.

Sie können `enable-ecs-log-metadata` auf `false` setzen, wenn Sie die Metadaten nicht benötigen.

Das folgende Beispiel für eine Aufgabendefinition definiert einen Log Router-Container, der Fluent Bit verwendet, um seine Protokolle an Logs CloudWatch weiterzuleiten. Außerdem wird ein Anwendungs-Container definiert, der eine Protokollkonfiguration verwendet, um Protokolle an Amazon Data Firehose weiterzuleiten, und legt den zum Puffern von Ereignissen verwendeten Arbeitsspeicher auf 2 MiB fest.

**Anmerkung**  
Weitere Beispielaufgabendefinitionen finden Sie unter [Amazon FireLens ECS-Beispiele](https://github.com/aws-samples/amazon-ecs-firelens-examples) unter GitHub.

```
{
  "family": "firelens-example-firehose",
  "taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
  "containerDefinitions": [
    {
            "name": "log_router",
            "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
            "cpu": 0,
            "memoryReservation": 51,
            "portMappings": [],
            "essential": true,
            "environment": [],
            "mountPoints": [],
            "volumesFrom": [],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/ecs-aws-firelens-sidecar-container",
                    "mode": "non-blocking",
                    "awslogs-create-group": "true",
                    "max-buffer-size": "25m",
                    "awslogs-region": "us-east-1",
                    "awslogs-stream-prefix": "firelens"
                },
                "secretOptions": []
            },
            "systemControls": [],
            "firelensConfiguration": {
                "type": "fluentbit"
            }
        },
    {
      "essential": true,
      "image": "public.ecr.aws/docker/library/httpd:latest",
      "name": "app",
      "logConfiguration": {
        "logDriver": "awsfirelens",
        "options": {
          "Name": "firehose",
          "region": "us-west-2",
          "delivery_stream": "my-stream",
          "log-driver-buffer-limit": "1048576"
        }
      },
      "memoryReservation": 100
    }
  ]
}
```

Die Schlüsselwertpaare, die als Optionen im `logConfiguration`-Objekt angegeben werden, werden verwendet, um die Fluentd- oder Fluent Bit-Ausgabekonfiguration zu generieren. Im Folgenden finden Sie ein Codebeispiel aus einer Fluent Bit-Ausgabedefinition.

```
[OUTPUT]
    Name   firehose
    Match  app-firelens*
    region us-west-2
    delivery_stream my-stream
```

**Anmerkung**  
FireLens verwaltet die `match` Konfiguration. Die `match`-Konfiguration ist in der Aufgabendefinition nicht festgelegt. 

## Eine benutzerdefinierte Konfigurationsdatei verwenden
<a name="firelens-taskdef-customconfig"></a>

Sie können eine benutzerdefinierte Konfigurationsdatei angeben Das Konfigurationsdateiformat ist das native Format für den verwendeten Protokoll-Router. Weitere Informationen finden Sie unter [Syntax der Fluentd-Konfigurationsdatei](https://docs.fluentd.org/configuration/config-file) und [YAML-Konfiguration](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml).

In Ihrer benutzerdefinierten Konfigurationsdatei sollten Sie für Aufgaben, die den `bridge`- oder `awsvpc`-Netzwerkmodus verwenden, keine Fluentd- oder Fluent-Bit-Weiterleitungseingabe über TCP festlegen, da FireLens diese zur Eingabekonfiguration hinzufügt.

Ihre FireLens-Konfiguration muss die folgenden Optionen enthalten, um eine benutzerdefinierte Konfigurationsdatei anzugeben:

`config-file-type`  
Den Quellspeicherort der benutzerdefinierten Konfigurationsdatei. Die verfügbaren Optionen sind `s3` oder `file`.  
Aufgaben, die auf gehostet werden, unterstützen AWS Fargate nur den `file` Konfigurationsdateityp. Sie können jedoch Konfigurationsdateien verwenden, die in Amazon S3 auf AWS Fargate gehostet werden, indem Sie den AWS for Fluent Bit init-Container verwenden. Weitere Informationen finden Sie unter [Init-Prozess für Fluent Bit auf ECS, Unterstützung mehrerer Konfigurationen auf](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub

`config-file-value`  
Die Quelle für die benutzerdefinierte Konfigurationsdatei. Wenn der `s3`-Konfigurationsdateityp verwendet wird, ist der Wert der Konfigurationsdatei der vollständige ARN des Amazon S3-Buckets und der Datei. Wenn der `file`-Konfigurationsdateityp verwendet wird, ist der Wert der Konfigurationsdatei der vollständige Pfad der Konfigurationsdatei, die entweder im Container-Image oder auf einem Volume vorhanden ist, das im Container bereitgestellt wird.  
Wenn Sie eine benutzerdefinierte Konfigurationsdatei verwenden, müssen Sie einen anderen Pfad als den von FireLens verwendeten angeben. Amazon ECS behält den `/fluent-bit/etc/fluent-bit.conf`-Dateipfad für Fluent Bit und `/fluentd/etc/fluent.conf` für Fluentd.

Das folgende Beispiel zeigt die Syntax, die erforderlich ist, wenn eine benutzerdefinierte Konfiguration angegeben wird.

**Wichtig**  
Um eine benutzerdefinierte Konfigurationsdatei anzugeben, die in Amazon S3 gehostet wird, stellen Sie sicher, dass Sie eine IAM-Aufgabenausführungsrolle mit den entsprechenden Berechtigungen erstellt haben. 

Im Folgenden wird die Syntax gezeigt, die für die Angabe einer benutzerdefinierten Konfiguration erforderlich ist.

```
{
  "containerDefinitions": [
    {
      "essential": true,
      "image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:3",
      "name": "log_router",
      "firelensConfiguration": {
        "type": "fluentbit",
        "options": {
          "config-file-type": "s3 | file",
          "config-file-value": "arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf | filepath"
        }
      }
    }
  ]
}
```

**Anmerkung**  
Aufgaben, die auf gehostet werden, unterstützen AWS Fargate nur den `file` Konfigurationsdateityp. Sie können jedoch Konfigurationsdateien verwenden, die in Amazon S3 auf AWS Fargate gehostet werden, indem Sie den AWS for Fluent Bit init-Container verwenden. Weitere Informationen finden Sie unter [Init-Prozess für Fluent Bit auf ECS, Unterstützung mehrerer Konfigurationen auf](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub

# Verwenden von AWS Nicht-Container-Images in Amazon ECS
<a name="private-auth"></a>

Verwenden Sie die private Registrierung, um Ihre Anmeldeinformationen darin zu speichern AWS Secrets Manager, und verweisen Sie dann in Ihrer Aufgabendefinition darauf. Auf diese Weise können Sie in Ihren Aufgabendefinitionen auf Container-Images verweisen, die in privaten Registern existieren und für AWS die eine Authentifizierung erforderlich ist. Dieses Feature wird durch Aufgaben unterstützt, die auf Fargate, Amazon-EC2-Instances und externen Instances mit Amazon ECS Anywhere gehostet werden.

**Wichtig**  
Wenn Ihre Aufgabendefinition auf ein im Amazon ECR gespeichertes Image verweist, trifft dieses Thema nicht zu. Weitere Informationen finden Sie unter [Amazon ECR-Images mit Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) im *Amazon Elastic Container-Registry-Benutzerhandbuch*.

Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, erfordert dieses Feature Version `1.19.0` oder höher des Container-Agenten. Wir empfehlen jedoch, die neueste Version des Container-Agents zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).

Für Aufgaben, die auf Fargate gehostet werden, erfordert dieses Feature die Plattformversion `1.2.0` oder höher. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).

Geben Sie in Ihrer Containerdefinition das Objekt `repositoryCredentials` mit den Details des von Ihnen erstellten Geheimnisses an. Das referenzierte Geheimnis kann von einem anderen AWS-Region oder einem anderen Konto stammen als die Aufgabe, die es verwendet.

**Anmerkung**  
Wenn Sie die Amazon ECS-API oder das AWS SDK verwenden und das Geheimnis in derselben AWS-Region Aufgabe enthalten ist, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Geheimnisses verwenden. AWS CLI Wenn das Geheimnis in einem anderen Konto vorhanden ist, muss der vollständige ARN des Geheimnisses angegeben werden. Bei Verwendung von muss immer der vollständige ARN des Geheimnisses angegeben werden. AWS-Managementkonsole

Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition, welche die erforderlichen Parameter zeigt:

Ersetzen Sie die folgenden Parameter:
+ *private-repo*mit dem Hostnamen des privaten Repositorys 
+ *private-image*mit dem Bildnamen
+ *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name*mit dem geheimen Amazon-Ressourcennamen (ARN)

```
"containerDefinitions": [
    {
        "image": "private-repo/private-image",
        "repositoryCredentials": {
            "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
        }
    }
]
```

**Anmerkung**  
Eine weitere Methode zur Aktivierung der privaten Registrierungsauthentifikation verwendet Umgebungsvariablen von Amazon-ECS-Container-Agenten für die Authentifizierung bei privaten Registrierungen. Diese Methode wird nur für Aufgaben unterstützt, die auf Amazon-EC2-Instances gehostet werden. Weitere Informationen finden Sie unter [Konfiguration von Amazon-ECS-Container-Instances für private Docker-Images](private-auth-container-instances.md).

**So verwenden Sie eine private Registry**

1. Die Aufgabendefinition muss über eine Aufgaben-Ausführungsrolle verfügen. Auf diese Weise kann der Container-Agent das Container-Image abrufen. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).

   Die private Registrierungsauthentifizierung ermöglicht es Ihren Amazon ECS-Aufgaben, Container-Images von privaten Registern außerhalb von AWS (wie Docker Hub, Quay.io oder Ihrer eigenen privaten Registrierung) abzurufen, für die Authentifizierungsdaten erforderlich sind. Dieses Feature verwendet Secrets Manager, um Ihre Registry-Anmeldeinformationen sicher zu speichern, auf die dann in Ihrer Aufgabendefinition mithilfe des `repositoryCredentials`-Parameters verwiesen wird.

   Weitere Informationen zur Konfiguration der privaten Registrierungsauthentifizierung finden Sie unter [Verwenden von AWS Non-Container-Images in Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).

   Um Zugriff auf die Geheimnisse zu gewähren, die Ihre privaten Registry-Anmeldeinformationen enthalten, fügen Sie die folgenden Berechtigungen als Inline-Richtlinie zur Aufgaben-Ausführungsrolle hinzu. Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
   + `secretsmanager:GetSecretValue` – Erforderlich, um die privaten Registry-Anmeldeinformationen von Secrets Manager abzurufen.
   + `kms:Decrypt` – Nur erforderlich, wenn Ihr Geheimnis einen benutzerdefinierten KMS-Schlüssel verwendet und nicht den Standardschlüssel. Der Amazon-Ressourcenname (ARN) für Ihren benutzerdefinierten Schlüssel muss als Ressource hinzugefügt werden.

   Das folgende Beispiel einer Inline-Richtlinie fügt die Berechtigungen hinzu:

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "kms:Decrypt",
                   "secretsmanager:GetSecretValue"
               ],
               "Resource": [
                   "arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name",
                   "arn:aws:kms:us-east-1:111122223333:key/key_id"
               ]
           }
       ]
   }
   ```

------

1. Wird verwendet AWS Secrets Manager , um ein Geheimnis für Ihre privaten Registrierungsdaten zu erstellen. Informationen zum Erstellen eines Geheimnisses finden Sie unter [Erstellen eines AWS Secrets Manager -Geheimnisses](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *Benutzerhandbuch für AWS Secrets Manager *.

   Geben Sie Ihre privaten Registry-Anmeldeinformationen in folgendem Format ein:

   ```
   {
     "username" : "privateRegistryUsername",
     "password" : "privateRegistryPassword"
   }
   ```

1. Eine Aufgabendefinition registrieren. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).

# Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten
<a name="container-restart-policy"></a>

Sie können für jeden in Ihrer Aufgabendefinition definierten essenziellen und nicht essenziellen Container eine Neustart-Richtlinie aktivieren, um vorübergehende Ausfälle schneller zu beheben und die Verfügbarkeit der Aufgaben aufrechtzuerhalten. Wenn Sie eine Neustart-Richtlinie für einen Container aktivieren, kann Amazon ECS den Container neu starten, wenn er beendet wird, ohne dass die Aufgabe ersetzt werden muss.

Neustart-Richtlinien sind standardmäßig nicht für Container aktiviert. Wenn Sie eine Neustart-Richtlinie für einen Container aktivieren, können Sie Beendigungs-Codes angeben, auf denen der Container nicht neu gestartet wird. Dies können Exit-Codes sein, die auf Erfolg hinweisen, wie Exit-Code `0`, für die kein Neustart erforderlich ist. Sie können auch angeben, wie lange ein Container erfolgreich ausgeführt werden muss, bevor ein Neustart versucht werden kann. Weitere Informationen zu diesen Parametern finden Sie unter [Neustartrichtlinie](task_definition_parameters.md#container_definition_restart_policy). Eine Beispiel-Aufgabendefinition, die diese Werte spezifiziert, finden Sie unter [Angeben einer Container-Neustart-Richtlinie in einer Amazon-ECS-Aufgabendefinition](container-restart-policy-example.md).

Sie können den Amazon ECS-Endpunkt für Aufgabenmetadaten oder CloudWatch Container Insights verwenden, um zu überwachen, wie oft ein Container neu gestartet wurde. Weitere Informationen zu den Aufgabenmetadaten-Endpunkt finden Sie unter [Amazon-ECS-Aufgabenmetadaten-Endpunkt Version 4](task-metadata-endpoint-v4.md) und [Amazon-ECS-Aufgabenmetaden-Endpunkt Version 4 für Aufgaben in Fargate](task-metadata-endpoint-v4-fargate.md). Weitere Informationen zu Container Insights-Metriken für Amazon ECS finden Sie unter [Amazon ECS Container Insights-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) im * CloudWatch Amazon-Benutzerhandbuch*.

Container-Neustart-Richtlinien werden von Aufgaben unterstützt, die auf Fargate, Amazon-EC2-Instances und externen Instances mit Amazon ECS Anywhere gehostet werden.

## Überlegungen
<a name="container-restart-policy-considerations"></a>

Berücksichtigen Sie Folgendes, bevor Sie eine Neustart-Richtlinie für Ihren Container aktivieren:
+ Neustart-Richtlinien werden für Windows-Container auf Fargate nicht unterstützt.
+ Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, erfordert dieses Feature Version `1.86.0` oder höher des Container-Agenten. Wir empfehlen jedoch, die neueste Version des Container-Agenten zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
+ Wenn Sie EC2 im `bridge` Netzwerkmodus verwenden, kann die `FLUENT_HOST` Umgebungsvariable in Ihrem Anwendungscontainer nach einem Neustart des FireLens Log Router-Containers (des Containers mit dem `firelensConfiguration` Objekt in seiner Containerdefinition) ungenau werden. Das liegt daran, dass `FLUENT_HOST` eine dynamische IP-Adresse ist, die sich nach einem Neustart ändern kann. Die direkte Protokollierung vom Anwendungs-Container zur `FLUENT_HOST` IP-Adresse kann nach einer Adressänderung fehlschlagen. Mehr über `FLUENT_HOST` erfahren Sie unter [Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).
+ Der Amazon-ECS-Agent kümmert sich um die Container-Neustart-Richtlinien. Wenn der Amazon-ECS-Agent aus einem unerwarteten Grund ausfällt oder nicht mehr läuft, wird der Container nicht neu gestartet.
+  Der in Ihrer Richtlinie definierte Zeitraum für Neustartversuche bestimmt den Zeitraum (in Sekunden), für den der Container ausgeführt werden muss, bevor Amazon ECS einen Container neu startet.

# Angeben einer Container-Neustart-Richtlinie in einer Amazon-ECS-Aufgabendefinition
<a name="container-restart-policy-example"></a>

Um eine Neustart-Richtlinie für einen Container in einer Aufgabendefinition anzugeben, geben Sie in der Container-Definition das `restartPolicy`-Objekt an. Weitere Informationen über das `restartPolicy`-Objekt finden Sie unter [Neustartrichtlinie](task_definition_parameters.md#container_definition_restart_policy).

Nachfolgend finden sehen Sie eine Aufgabendefinition mit Linux-Containern in Fargate, die einen Webserver einrichtet: Die Container-Definition umfasst das `restartPolicy`-Objekt, wobei `enabled` auf „true“ gesetzt ist, um eine Neustart-Richtlinie für den Container zu aktivieren. Der Container muss 180 Sekunden lang laufen, bevor er neu gestartet werden kann. Er wird nicht neu gestartet, wenn er mit dem Exit-Code `0` beendet wird, der auf Erfolg hinweist.

```
{
  "containerDefinitions": [
    {
      "command": [
        "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
      ],
      "entryPoint": ["sh", "-c"],
      "essential": true,
      "image": "public.ecr.aws/docker/library/httpd:2.4",
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/fargate-task-definition",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "name": "sample-fargate-app",
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ],
      "restartPolicy": {
        "enabled": true,
        "ignoredExitCodes": [0],
        "restartAttemptPeriod": 180
      }
    }
  ],
  "cpu": "256",
  "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
  "family": "fargate-task-definition",
  "memory": "512",
  "networkMode": "awsvpc",
  "runtimePlatform": {
    "operatingSystemFamily": "LINUX"
  },
  "requiresCompatibilities": ["FARGATE"]
}
```

Nachdem Sie mit eine Aufgabendefinition mit dem `restartPolicy`-Objekt in einer Container-Definition registriert haben, können Sie mit dieser Aufgabendefinition eine Aufgabe ausführen oder einen Service erstellen. Weitere Informationen erhalten Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md) und [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md).

# Sensible Daten an einen Amazon-ECS-Container übergeben
<a name="specifying-sensitive-data"></a>

Sie können vertrauliche Daten, wie z. B. Anmeldeinformationen für eine Datenbank, sicher in Ihren Container übergeben. 

Secrets, wie API-Schlüssel und Datenbankanmeldeinformationen, werden häufig von Anwendungen verwendet, um auf andere Systeme zuzugreifen. Sie bestehen häufig aus einem Benutzernamen und einem Passwort, einem Zertifikat oder einem API-Schlüssel. Der Zugriff auf diese Secrets sollte auf bestimmte IAM-Prinzipale beschränkt werden, die IAM verwenden und zur Laufzeit in Container eingespeist werden.

Secrets können nahtlos aus AWS Secrets Manager einem Amazon EC2 Systems Manager Parameter Store in Container eingefügt werden. Auf diese Secrets kann in Ihrer Aufgabe wie folgt verwiesen werden.

1. Sie werden als Umgebungsvariablen referenziert, die den `secrets`-Container-Definitionsparameter verwenden.

1. Sie werden als `secretOptions` bezeichnet, wenn Ihre Protokollierungsplattform eine Authentifizierung erfordert. Weitere Informationen finden Sie unter [Konfigurationsoptionen für die Protokollierung](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents).

1. Sie werden als Secrets bezeichnet, die von Images abgerufen werden, die den `repositoryCredentials`-Container-Definitionsparameter verwenden, wenn die Registrierung, aus der der Container abgerufen wird, eine Authentifizierung erfordert. Verwenden Sie diese Methode, wenn Sie Images aus Amazon ECR Public Gallery abrufen. Weitere Informationen finden Sie unter [Private Registrierungsauthentifizierung für Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).

Wir empfehlen Ihnen, bei der Einrichtung der Verwaltung von Secrets wie folgt vorzugehen.

## Verwenden Sie AWS Secrets Manager unseren AWS Systems Manager Parameter Store zum Speichern geheimer Materialien
<a name="security-secrets-management-recommendations-storing-secret-materials"></a>

Sie sollten API-Schlüssel, Datenbank-Anmeldeinformationen und andere geheime Materialien sicher in Secrets Manager oder als verschlüsselte Parameter im Systems Manager Parameter Store speichern. Diese Dienste ähneln sich, da es sich bei beiden um verwaltete Schlüsselwertspeicher handelt, die AWS KMS zur Verschlüsselung sensibler Daten verwendet werden. Secrets Manager bietet jedoch auch die Möglichkeit, Geheimnisse automatisch zu rotieren, Zufalls-Geheimnisse zu generieren und Geheimnisse über Konten hinweg freizugeben. Verwenden Sie Secrets Manager, um diese Features zu nutzen. Verwenden Sie andernfalls verschlüsselte Parameter im Systems Manager Parameter Store.

**Wichtig**  
Wenn sich Ihr Secret ändert, müssen Sie eine neue Bereitstellung erzwingen oder eine neue Aufgabe starten, um den neuesten Secret-Wert abzurufen. Weitere Informationen finden Sie unter den folgenden Themen:  
Aufgaben – Stoppen Sie die Aufgabe und starten Sie sie dann. Weitere Informationen erhalten Sie unter [Beenden einer Amazon-ECS-Aufgabe](standalone-task-stop.md) und [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).
Service – Aktualisieren Sie den Service und verwenden Sie die Option Neue Bereitstellung erzwingen. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon ECS-Service](update-service-console-v2.md).

## Daten aus einem verschlüsselten Amazon-S3-Bucket abrufen
<a name="security-secrets-management-recommendations-encrypted-s3-buckets"></a>

Sie sollten Geheimnisse in einem verschlüsselten Amazon-S3-Bucket speichern und Aufgabenrollen verwenden, um den Zugriff auf diese Geheimnisse zu beschränken. Dadurch wird verhindert, dass die Werte von Umgebungsvariablen versehentlich in die Protokolle gelangen und bei der Ausführung von `docker inspect` aufgedeckt werden. Wenn Sie dies tun, muss Ihre Anwendung so geschrieben werden, dass sie das Secret aus dem Amazon-S3-Bucket liest. Anweisungen dazu finden Sie unter [Festlegen des standardmäßigen serverseitigen Verschlüsselungsverhaltens für Amazon-S3-Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html).

## Das Secret mit Hilfe eines Beiwagen-Containers in ein Volume mounten
<a name="security-secrets-management-recommendations-mount-secret-volumes"></a>

Da bei Umgebungsvariablen ein erhöhtes Risiko von Datenlecks besteht, sollten Sie einen Sidecar-Container verwenden, der Ihre geheimen Daten liest AWS Secrets Manager und auf ein gemeinsam genutztes Volume schreibt. Dieser Container kann vor dem Anwendungscontainer ausgeführt und beendet werden, indem Sie [Amazon-ECS-Container-Anordnungen](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) verwenden. Wenn Sie dies tun, mountet der Anwendungscontainer anschließend das Volume, auf dem das Secret geschrieben wurde. Wie bei der Amazon-S3-Bucket-Methode muss Ihre Anwendung so geschrieben werden, dass sie das Secret aus dem gemeinsam genutzten Volume liest. Da das Volume auf die Aufgabe beschränkt ist, wird das Volume nach dem Beenden der Aufgabe automatisch gelöscht. Ein Beispiel finden Sie im Projekt [task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json).

In Amazon EC2 kann das Volume, auf welches das Secret geschrieben wird, mit einem vom Kunden verwalteten AWS KMS -Schlüssel verschlüsselt werden. Bei aktivierter AWS Fargate Option wird der Datenträgerspeicher automatisch mithilfe eines vom Service verwalteten Schlüssels verschlüsselt. 

# Eine einzelne Umgebungsvariable an einen Amazon-ECS-Container übergeben
<a name="taskdef-envfiles"></a>

**Wichtig**  
Wir empfehlen, Ihre sensiblen Daten entweder in AWS Secrets Manager Secrets- oder AWS Systems Manager Parameter Store-Parametern zu speichern. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).  
Die in der Aufgabendefinition angegebenen Umgebungsvariablen sind für alle Benutzer und Rollen lesbar, die die `DescribeTaskDefinition`-Aktion für die Aufgabendefinition durchführen dürfen.

Sie können Umgebungsvariablen auf folgende Weise an Ihre Container übergeben:
+ Individuell mit dem `environment`-Containerdefinitionsparameter. Dies wird auf die Option `--env` abgebildet, um auf die [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) zu verweisen.
+ Verwenden Sie den Container-Definitionsparameter `environmentFiles`, um eine oder mehrere Dateien aufzulisten, die die Umgebungsvariablen enthalten. Die Datei muss in Amazon S3 gehostet werden. Dies wird auf die Option `--env-file` abgebildet, um auf die [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) zu verweisen.

Im Folgenden finden Sie ein Ausschnitt aus einer Aufgabendefinition, in dem gezeigt wird, wie einzelne Umgebungsvariablen angegeben werden.

```
{
    "family": "",
    "containerDefinitions": [
        {
            "name": "",
            "image": "",
            ...
            "environment": [
                {
                    "name": "variable",
                    "value": "value"
                }
            ],
            ...
        }
    ],
    ...
}
```

# Umgebungsvariablen an einen Amazon-ECS-Container übergeben
<a name="use-environment-file"></a>

**Wichtig**  
Wir empfehlen, Ihre sensiblen Daten entweder in AWS Secrets Manager Secrets- oder AWS Systems Manager Parameter Store-Parametern zu speichern. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).  
Umgebungsvariablen-Dateien sind Objekte in Amazon S3, und es gelten alle Sicherheitsüberlegungen von Amazon S3.   
Sie können den `environmentFiles`-Parameter nicht für Windows-Container und Windows-Container in Fargate verwenden.

Sie können eine Umgebungsvariablendatei erstellen und in Amazon S3 speichern, um Umgebungsvariablen an Ihren Container zu übergeben.

Durch das Angeben von Umgebungsvariablen in einer Datei können Sie Umgebungsvariablen gesammelt einfügen. Geben Sie innerhalb der Containerdefinition das Objekt `environmentFiles` mit einer Liste von Amazon S3-Buckets an, die Ihre Umgebungsvariablendateien enthalten.

Amazon ECS erzwingt keine Größenbeschränkung für die Umgebungsvariablen, aber eine große Umgebungsvariablendatei kann den Speicherplatz auffüllen. Jede Aufgabe, die eine Umgebungsvariablendatei verwendet, bewirkt, dass eine Kopie der Datei auf den Datenträger heruntergeladen wird. Amazon ECS entfernt die Datei als Teil der Aufgabenbereinigung.

Informationen zu den unterstützten Umgebungsvariablen finden Sie unter [Erweiterte Container-Definitionsparameter – Umgebung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment).

Berücksichtigen Sie Folgendes, wenn eine Umgebungsvariablendatei in einer Containerdefinition angegeben wird.
+ Für Amazon-ECS-Aufgaben auf Amazon EC2 benötigen Ihre Container-Instances die Container-Agenten-Version `1.39.0` oder höher, um dieses Feature verwenden zu können. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
+ Für Amazon ECS-Aufgaben auf AWS Fargate müssen Ihre Aufgaben die Plattformversion `1.4.0` oder höher (Linux) verwenden, um diese Funktion nutzen zu können. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).

  Stellen Sie sicher, dass die Variable für die Betriebssystem-Plattform unterstützt wird. Weitere Informationen erhalten Sie unter [Containerdefinitionen](task_definition_parameters.md#container_definitions) und [Andere Parameter der Aufgabendefinition](task_definition_parameters.md#other_task_definition_params).
+ Die Datei muss die `.env`-Dateierweiterung und die UTF-8-Kodierung verwenden.
+ Die Aufgabenausführungsrolle ist erforderlich, um dieses Feature mit den zusätzlichen Berechtigungen für Amazon S3 zu verwenden. Auf diese Weise kann der Container-Agent die Umgebungsvariablendatei von Amazon S3 abrufen. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
+ Es gibt ein Limit von 10 Dateien pro Aufgabendefinition.
+ Jede Zeile in einer Umgebungsdatei muss eine Umgebungsvariable im Format `VARIABLE=VALUE` enthalten. Leerzeichen oder Anführungszeichen **werden** als Teil der Werte für Amazon-ECS-Dateien einbezogen. Zeilen, die mit `#` beginnen, werden als Kommentare behandelt und ignoriert. Weitere Informationen zur Syntax der Umgebungsvariablendatei finden Sie unter [Setzen von Umgebungsvariablen (-e, --env, --env-file)](https://docs.docker.com/reference/cli/docker/container/run/#env) in der Docker-Dokumentation.

  Im Folgenden finden Sie die entsprechende Syntax.

  ```
  #This is a comment and will be ignored
  VARIABLE=VALUE
  ENVIRONMENT=PRODUCTION
  ```
+ Wenn Umgebungsvariablen mit dem `environment`-Parameter in einer Containerdefinition angegeben sind, haben sie Vorrang vor den Variablen, die in einer Umgebungsdatei enthalten sind.
+ Wenn mehrere Umgebungsdateien angegeben sind und sie dieselbe Variable enthalten, werden sie in der Reihenfolge ihres Eintrags verarbeitet. Dies bedeutet, dass der erste Wert der Variablen verwendet wird und nachfolgende Werte doppelter Variablen ignoriert werden. Es wird empfohlen, eindeutige Variablennamen zu verwenden.
+ Wenn eine Umgebungsdatei als Container-Überschreibung angegeben wird, wird sie verwendet. Darüber hinaus werden alle anderen Umgebungsdateien ignoriert, die in der Containerdefinition angegeben sind.
+ Die folgenden Regeln gelten für Fargate:
  + Die Datei wird wie eine native env.file-Docker-Datei behandelt.
  + Container-Definitionen, die auf Umgebungsvariablen verweisen, die leer sind und in Amazon S3 gespeichert sind, werden nicht im Container angezeigt.
  + Es gibt keine Unterstützung für Shell-Escape-Handling.
  + Der Container-Einstiegspunkt interpretiert die `VARIABLE`-Werte.

## Beispiel
<a name="environment-file-example"></a>

Im Folgenden finden Sie ein Ausschnitt aus einer Aufgabendefinition, in dem gezeigt wird, wie eine Umgebungsvariablendatei angegeben wird.

```
{
    "family": "",
    "containerDefinitions": [
        {
            "name": "",
            "image": "",
            ...
            "environmentFiles": [
                {
                    "value": "arn:aws:s3:::amzn-s3-demo-bucket/envfile_object_name.env",
                    "type": "s3"
                }
            ],
            ...
        }
    ],
    ...
}
```

# Secrets-Manager-Geheimnisse programmgesteuert in Amazon ECS weitergeben
<a name="secrets-app-secrets-manager"></a>

Anstatt sensible Daten in Ihrer Anwendung im Klartext fest zu kodieren, können Sie Secrets Manager verwenden, um die sensiblen Daten zu speichern.

Wir empfehlen diese Methode zum Abrufen vertraulicher Daten, da die Anwendung automatisch die neueste Version des Secrets-Manager-Geheimnisses abruft, wenn das Secrets-Manager-Geheimnis anschließend aktualisiert wird.

Erstellen Sie ein Geheimnis in Secrets Manager. Nachdem Sie ein Secrets-Manager-Geheimnis erstellt haben, aktualisieren Sie Ihren Anwendungscode, um das Geheimnis abzurufen.

Lesen Sie die folgenden Überlegungen, bevor Sie vertrauliche Daten in Secrets Manager sichern.
+ Es werden nur Geheimnisse unterstützt, die Textdaten speichern, bei denen es sich um Geheimnisse handelt, die mit dem `SecretString` [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API-Parameter erstellt wurden. Geheimnisse, die Binärdaten speichern, bei denen es sich um Geheimnisse handelt, die mit dem `SecretBinary` [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API-Parameter erstellt wurden, werden nicht unterstützt.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern. Sie müssen die Schnittstellen-VPC-Endpunkte für den Secrets Manager erstellen. Informationen über den VPC-Endpunkt finden Sie unter [VPC-Endpunkte erstellen](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) im *AWS Secrets Manager -Benutzerhandbuch*.
+ Die von Ihrer Aufgabe verwendete VPC muss die DNS-Auflösung verwenden.
+ Ihre Aufgabendefinition muss eine Aufgabenrolle mit den zusätzlichen Berechtigungen für Secrets Manager verwenden. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).

## Erstellen des Secrets-Manager-Geheimnisses
<a name="secrets-app-secrets-manager-create-secret"></a>

Sie können die Secrets Manager-Konsole verwenden, um ein Secret für Ihre sensiblen Daten zu erstellen. Informationen zum Erstellen von Geheimnissen finden Sie unter [Erstellen eines AWS Secrets Manager -Geheimnisses](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *AWS Secrets Manager -Benutzerhandbuch*.

## Aktualisieren Sie Ihre Anwendung, um Secrets-Manager-Geheimnisse programmgesteuert abzurufen
<a name="secrets-app-secrets-manager-update-app"></a>

Sie können Secrets mit einem Aufruf des Secrets Manager APIs direkt aus Ihrer Anwendung abrufen. Weitere Informationen finden Sie unter [Abrufen von Geheimnissen aus AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) im *Benutzerhandbuch für AWS Secrets Manager *.

Informationen zum Abrufen der in der AWS Secrets Manager gespeicherten vertraulichen Daten finden Sie unter [Codebeispiele zur AWS Secrets Manager Verwendung AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html) in der *AWS SDK-Codebeispiel-Codebibliothek*.

# Geheimnisse von Systems Manager Parameter Store programmgesteuert in Amazon ECS übergeben
<a name="secrets-app-ssm-paramstore"></a>

Systems Manager Parameter Store ermöglicht die sichere Speicherung und Verwaltung von Geheimnissen. Sie können Daten wie Passwörter, Datenbankzeichenfolgen, EC2-Instance IDs und AMI IDs sowie Lizenzcodes als Parameterwerte speichern, anstatt diese Informationen in Ihrer Anwendung fest zu codieren. Sie können Werte als Klartext oder als verschlüsselte Daten speichern.

Wir empfehlen diese Methode zum Abrufen sensible Daten, da die Anwendung automatisch die neueste Version abruft, wenn der Parameter für Secrets Manager Parameter Store danach aktualisiert wird.

Lesen Sie die folgenden Überlegungen, bevor Sie sensible Daten im Systems Manager Parameter Store sichern.
+ Es werden nur Geheimnisse unterstützt, die Textdaten speichern. Geheimnisse zum Speichern von Binärdaten werden nicht unterstützt.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern.
+ Die von Ihrer Aufgabe verwendete VPC muss die DNS-Auflösung verwenden.
+ Für Aufgaben, die EC2 verwenden, müssen Sie die Amazon-ECS-Agent-Konfigurationsvariable `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` verwenden, um dieses Feature verwenden zu können. Sie können sie während der Erstellung der Container-Instance zur Datei `/etc/ecs/ecs.config` hinzufügen oder sie zu einer vorhandenen Instance hinzufügen und dann den ECS-Agenten neu starten. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
+ Ihre Aufgabendefinition muss eine Aufgabenrolle mit den zusätzlichen Berechtigungen für Systems Manager Parameter Store verwenden. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).

## Erstellen des -Parameters
<a name="secrets-app-ssm-paramstore-create-secret"></a>

Sie können die Systems-Manager-Konsole verwenden, um einen Parameter des Systems Manager Parameter Stores für Ihre sensiblen Daten zu erstellen. Weitere Informationen finden Sie im *AWS Systems Manager -Benutzerhandbuch* unter [Erstellen eines Systems-Manager-Parameters (Konsole)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) oder [Erstellen eines Systems-Manager-Parameters (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html).

## Aktualisieren Sie Ihre Anwendung, um die Geheimnisse des Systems-Manager-Parameter-Speichers programmgesteuert abzurufen
<a name="secrets-app-ssm-paramstore-update-app"></a>

Informationen zum Abrufen der sensiblen Daten, die im Parameter Store-Parameter von Systems Manager gespeichert sind, finden Sie unter [Codebeispiele für die Verwendung durch Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) in der *AWS SDK-Codebeispiel-Codebibliothek*.

# Secrets-Manager-Geheimnisse über Amazon-ECS-Umgebungsvariablen weitergeben
<a name="secrets-envvar-secrets-manager"></a>

Wenn Sie ein Geheimnis als Umgebungsvariable einfügen, können Sie den vollständigen Inhalt eines Geheimnisses oder eines bestimmten JSON-Schlüssels innerhalb eines Secrets Geheimnisses angeben. Das hilft Ihnen, die sensiblen Daten zu steuern, die Ihrem Container zur Verfügung gestellt werden. Weitere Informationen zur Geheimnis-Versionsverwaltung finden Sie unter [Was ist in einem Secrets-Manager-Geheimnis enthalten?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version) im *Benutzerhandbuch für AWS Secrets Manager *.

Folgendes sollte bei der Injektion eines Secrets-Manager-Geheimnisses in einen Container mit einer Umgebungsvariable berücksichtigt werden.
+ Sensible Daten werden beim ersten Start des Containers an diesen übergeben. Wenn das Secret anschließend aktualisiert oder rotiert wird, erhält der Container nicht automatisch den aktualisierten Wert. Sie müssen eine neue Aufgabe starten. Alternativ können Sie, wenn Ihre Aufgabe Teil eines Services ist, den Service aktualisieren und die Option **Force new deployment (Neue Bereitstellung erzwingen)** auswählen, um den Service zu zwingen, eine neue Aufgabe zu starten.
+ Anwendungen, die auf dem Container ausgeführt werden sowie Container-Protokolle und Debugging-Tools haben Zugriff auf die Umgebungsvariablen.
+ Beachten Sie bei Amazon ECS-Aufgaben Folgendes: AWS Fargate
  + Um den vollständigen Inhalt eines Secrets als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.3.0` oder höher verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
  + Um einen bestimmten JSON-Schlüssel oder eine Version eines Geheimnisses als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` (Windows) verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
+ Bei Amazon ECS-Aufgaben auf EC2 sollte Folgendes berücksichtigt werden:
  + Um einen geheimen Schlüssel mithilfe eines bestimmten JSON-Schlüssels oder einer Secret-Version einzufügen, muss Ihre Container-Instance Version `1.37.0` oder höher des Container-Agenten haben. Wir empfehlen jedoch, die neueste Version des Container-Agenten zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).

    Um den vollständigen Inhalt eines Secrets als Umgebungsvariable einzufügen oder ein Secret in eine Protokollkonfiguration einzufügen, muss Ihre Container-Instance Version `1.22.0` oder höher des Container-Agenten haben.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern und über ein privates Subnetz eine Verbindung zu Secrets Manager herzustellen. Sie müssen die Schnittstellen-VPC-Endpunkte für den Secrets Manager erstellen. Informationen über den VPC-Endpunkt finden Sie unter [VPC-Endpunkte erstellen](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) im *AWS Secrets Manager -Benutzerhandbuch*. Weitere Informationen zur Verwendung von Secrets Manager und Amazon VPC finden Sie unter [So stellen Sie in einer Amazon-VPC eine Verbindung zu Secrets Manager her](https://aws.amazon.com/blogs//security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual-private-cloud/).
+ Für Windows-Aufgaben, die für die Verwendung des `awslogs`-Protokolltreibers konfiguriert sind, müssen Sie auch die `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE`-Umgebungsvariable für die Container-Instance festlegen. Verwenden Sie die folgende Syntax:

  ```
  <powershell>
  [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
  Initialize-ECSAgent -Cluster <cluster name> -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
  </powershell>
  ```
+ Ihre Aufgabendefinition muss eine Aufgabenausführungsrolle mit den zusätzlichen Berechtigungen für Secrets Manager verwenden. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).

## Erstellen Sie das AWS Secrets Manager Geheimnis
<a name="secrets-envvar-secrets-manager-create-secret"></a>

Sie können die Secrets Manager-Konsole verwenden, um ein Secret für Ihre sensiblen Daten zu erstellen. Weitere Informationen finden Sie im *AWS Secrets Manager Benutzerhandbuch* unter [Create an AWS Secrets Manager Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).

## Fügen Sie die Umgebungsvariable zur Container-Definition hinzu
<a name="secrets-envvar-secrets-manager-update-container-definition"></a>

Innerhalb der Containerdefinition können Sie Folgendes angeben:
+ Das `secrets`-Objekt, das den Namen der Umgebungsvariablen enthält, die im Container festgelegt werden soll
+ Der Amazon-Ressourcenname (ARN) des Secrets Manager-Secrets
+ Zusätzliche Parameter, die die sensiblen Daten enthalten, die dem Container angezeigt werden sollen

Das folgende Beispiel zeigt die vollständige Syntax, die für das Secrets Manager-Secret angegeben werden muss.

```
arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key:version-stage:version-id
```

Im folgenden Abschnitt werden die zusätzlichen Parameter beschrieben. Diese Parameter sind optional, aber wenn Sie sie nicht verwenden, müssen Sie die Doppelpunkte einschließen, damit `:` die Standardwerte verwendet. Beispiele finden Sie unten für weiteren Kontext.

`json-key`  
Gibt den Namen des Schlüssels in einem Schlüssel-Wert-Paar mit dem Wert an, den Sie als Umgebungsvariablenwert festlegen möchten. Nur Werte im JSON-Format werden unterstützt. Wenn Sie keinen JSON-Schlüssel angeben, wird der vollständige Inhalt des Secrets verwendet.

`version-stage`  
Gibt die Phasenbeschriftung der Version eines Secrets an, die Sie verwenden möchten. Wenn eine Versionsphasenbeschriftung angegeben ist, können Sie keine Versions-ID angeben. Wenn keine Versionsphase angegeben wird, besteht das Standardverhalten darin, das Secret Schlüssel mit der `AWSCURRENT`-Phasenbeschriftung abzurufen.  
Phasenbeschriftungen werden verwendet, um verschiedene Versionen eines Secrets zu verfolgen, wenn sie aktualisiert oder rotiert werden. Jede Version eines Secrets hat eine oder mehrere Phasenbeschriftungen und eine ID.

`version-id`  
Gibt die eindeutige ID der Version des Secrets an, die Sie verwenden möchten. Wenn eine Versions-ID angegeben wird, können Sie keine Versionsphasenbeschriftung angeben. Wenn keine Versions-ID angegeben wird, besteht das Standardverhalten darin, den geheimen Schlüssel mit der `AWSCURRENT`-Phasenbeschriftung abzurufen.  
Versionen IDs werden verwendet, um den Überblick über verschiedene Versionen eines Geheimnisses zu behalten, wenn sie entweder aktualisiert oder ausgetauscht werden. Jede Version eines Secrets hat eine ID. Weitere Informationen erhalten Sie unter [Zentrale Begriffe und Konzepte für AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret) im *AWS Secrets Manager -Benutzerhandbuch*.

### Beispiel-Containerdefinitionen
<a name="secrets-examples"></a>

Die folgenden Beispiele zeigen, wie Sie auf Secrets Manager-Secrets in Ihren Containerdefinitionen verweisen können.

**Example Verweisen auf ein vollständiges Secret**  
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf den vollständigen Text eines Secrets Manager-Secret.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
    }]
  }]
}
```
Um innerhalb des Containers auf den Wert dieses Geheimnisses zuzugreifen, müssten Sie den `$environment_variable_name` aufrufen.

**Example Verweisen auf vollständige Secrets**  
Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf den vollständigen Text mehrerer Secrets-Manager-Geheimnisse.  

```
{
  "containerDefinitions": [{
     "secrets": [
      {
        "name": "environment_variable_name1",
         "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
      },
      {
        "name": "environment_variable_name2",
         "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-abcdef"
      },
      {
        "name": "environment_variable_name3",
        "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-ABCDEF"
      }
    ]
  }]
}
```
Um innerhalb des Containers auf den Wert dieses Geheimnisses zuzugreifen, müssten Sie `$environment_variable_name1`, `$environment_variable_name2`, und `$environment_variable_name3` aufrufen.

**Example Verweisen auf einen bestimmten Schlüssel innerhalb eines Secrets**  
Im Folgenden wird ein Beispiel für die Ausgabe eines [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)Befehls gezeigt, der den Inhalt eines Secrets zusammen mit der zugehörigen Staging-Bezeichnung der Version und der zugehörigen Versions-ID anzeigt.  

```
{
    "ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
    "Name": "appauthexample",
    "VersionId": "871d9eca-18aa-46a9-8785-981ddEXAMPLE",
    "SecretString": "{\"username1\":\"password1\",\"username2\":\"password2\",\"username3\":\"password3\"}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": 1581968848.921
}
```
Verweisen Sie auf einen bestimmten Schlüssel aus der vorherigen Ausgabe in einer Containerdefinition, indem Sie den Schlüsselnamen am Ende des ARN angeben.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::"
    }]
  }]
}
```

**Example Verweisen auf eine bestimmte Secret-Version**  
Im Folgenden wird eine Beispielausgabe eines [describe-secret ](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html)-Befehls gezeigt, der den unverschlüsselten Inhalt eines Secrets zusammen mit den Metadaten für alle Versionen des Secrets anzeigt.  

```
{
    "ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
    "Name": "appauthexample",
    "Description": "Example of a secret containing application authorization data.",
    "RotationEnabled": false,
    "LastChangedDate": 1581968848.926,
    "LastAccessedDate": 1581897600.0,
    "Tags": [],
    "VersionIdsToStages": {
        "871d9eca-18aa-46a9-8785-981ddEXAMPLE": [
            "AWSCURRENT"
        ],
        "9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE": [
            "AWSPREVIOUS"
        ]
    }
}
```
Verweisen Sie auf eine bestimmte Versionsphasenbeschriftung aus der vorherigen Ausgabe in einer Containerdefinition, indem Sie den Schlüsselnamen am Ende des ARN angeben.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:"
    }]
  }]
}
```
Verweisen Sie auf eine bestimmte Versions-ID der vorherigen Ausgabe in einer Containerdefinition, indem Sie den Schlüsselnamen am Ende des ARN angeben.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
    }]
  }]
}
```

**Example Verweisen auf einen bestimmten Schlüssel und eine Versionsphasenbeschriftung eines Secrets**  
Im Folgenden wird gezeigt, wie Sie sowohl auf einen bestimmten Schlüssel innerhalb eines Secrets als auch auf eine bestimmte Versionsphasenbeschriftung verweisen.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:"
    }]
  }]
}
```
Verwenden Sie die folgende Syntax, um einen bestimmten Schlüssel und eine Versions-ID anzugeben.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
    }]
  }]
}
```

Informationen zum Erstellen einer Aufgabendefinition mit dem in einer Umgebungsvariable angegebenen Geheimnis finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md). 

# Systems-Manager-Parameter über Amazon-ECS-Umgebungsvariablen weitergeben
<a name="secrets-envvar-ssm-paramstore"></a>

Amazon ECS ermöglicht es Ihnen, vertrauliche Daten in Ihre Container einzufügen, indem Sie Ihre sensiblen Daten in AWS Systems Manager Parameter Store-Parametern speichern und sie dann in Ihrer Container-Definition referenzieren.

Folgendes sollte beachtet werden, wenn eine Umgebungsvariable zum Einfügen eines System-Manager-Geheimnisses in einen Container verwendet wird.
+ Sensible Daten werden beim ersten Start des Containers an diesen übergeben. Wenn das Secret anschließend aktualisiert oder rotiert wird, erhält der Container nicht automatisch den aktualisierten Wert. Sie müssen eine neue Aufgabe starten. Alternativ können Sie, wenn Ihre Aufgabe Teil eines Services ist, den Service aktualisieren und die Option **Force new deployment (Neue Bereitstellung erzwingen)** auswählen, um den Service zu zwingen, eine neue Aufgabe zu starten.
+ Bei Amazon ECS-Aufgaben sollte Folgendes beachtet werden: AWS Fargate
  + Um den vollständigen Inhalt eines Secrets als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.3.0` oder höher verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
  + Um einen bestimmten JSON-Schlüssel oder eine Version eines Geheimnisses als Umgebungsvariable oder in eine Protokollkonfiguration einzufügen, müssen Sie die Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` (Windows) verwenden. Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
+ Bei Amazon ECS-Aufgaben auf EC2 sollte Folgendes berücksichtigt werden:
  + Um einen geheimen Schlüssel mithilfe eines bestimmten JSON-Schlüssels oder einer Secret-Version einzufügen, muss Ihre Container-Instance Version `1.37.0` oder höher des Container-Agenten haben. Wir empfehlen jedoch, die neueste Version des Container-Agenten zu verwenden. Informationen zum Überprüfen Ihrer Agenten-Version und zum Aktualisieren auf die neueste Version finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).

    Um den vollständigen Inhalt eines Secrets als Umgebungsvariable einzufügen oder ein Secret in eine Protokollkonfiguration einzufügen, muss Ihre Container-Instance Version `1.22.0` oder höher des Container-Agenten haben.
+ Verwenden Sie Schnittstellen-VPC-Endpunkte, um die Sicherheitskontrollen zu verbessern. Sie müssen die Schnittstellen-VPC-Endpunkte für Systems Manager erstellen. Weitere Informationen über den VPC-Endpunkt finden Sie unter [Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager verbessern](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) im *Benutzerhandbuch für AWS Systems Manager *.
+ Ihre Aufgabendefinition muss eine Aufgabenausführungsrolle mit den zusätzlichen Berechtigungen für Systems Manager Parameter Store verwenden. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
+ Für Windows-Aufgaben, die für die Verwendung des `awslogs`-Protokolltreibers konfiguriert sind, müssen Sie auch die `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE`-Umgebungsvariable für die Container-Instance festlegen. Verwenden Sie die folgende Syntax:

  ```
  <powershell>
  [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
  Initialize-ECSAgent -Cluster <cluster name> -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
  </powershell>
  ```

## Den Systems-Manager-Parameter erstellen
<a name="secrets-envvar-ssm-paramstore-create-parameter"></a>

Sie können die Systems-Manager-Konsole verwenden, um einen Parameter des Systems Manager Parameter Stores für Ihre sensiblen Daten zu erstellen. Weitere Informationen finden Sie im *AWS Systems Manager -Benutzerhandbuch* unter [Erstellen eines Systems-Manager-Parameters (Konsole)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) oder [Erstellen eines Systems-Manager-Parameters (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html).

## Fügen Sie die Umgebungsvariable zur Container-Definition hinzu
<a name="secrets-ssm-paramstore-update-container-definition"></a>

Geben Sie innerhalb Ihrer Container-Definition in der Aufgabendefinition `secrets` an, und geben Sie dabei den Namen der im Container einzustellenden Umgebungsvariable und den vollständigen ARN des Parameters von Systems Manager Parameter Store an, der die sensiblen Daten enthält, die dem Container präsentiert werden sollen. Weitere Informationen finden Sie unter [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf einen Systems Manager Parameter Store-Parameter. Wenn sich der Systems Manager Parameter Store-Parameter in der gleichen Region wie die Aufgabe befindet, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Parameters verwenden. Wenn der Parameter in einer anderen Region existiert, geben Sie den vollen ARN an.

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
    }]
  }]
}
```

Informationen zum Erstellen einer Aufgabendefinition mit dem in einer Umgebungsvariable angegebenen Geheimnis finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).

## Aktualisieren Sie Ihre Anwendung, um die Geheimnisse des Systems-Manager-Parameter-Speichers programmgesteuert abzurufen
<a name="secrets-ssm-paramstore-update-app"></a>

Informationen zum Abrufen der sensiblen Daten, die im Parameter Store-Parameter von Systems Manager gespeichert sind, finden Sie unter [Codebeispiele für die Verwendung durch Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) in der *AWS SDK-Codebeispiel-Codebibliothek*.

# Geheimnisse für die Amazon-ECS-Protokollierungskonfiguration weitergeben
<a name="secrets-logconfig"></a>

Sie können den `secretOptions`-Parameter in `logConfiguration` verwenden, um sensible Daten zu übergeben, die für die Protokollierung verwendet werden.

Sie können das Geheimnis in Secrets Manager oder Systems Manager speichern.

## Secrets Manager verwenden
<a name="secrets-logconfig-secrets-manager"></a>

Bei der Angabe von `logConfiguration` können Sie `secretOptions` in Ihrer Containerdefinition mit dem Namen der im Container festzulegenden Protokolltreiberoption und dem vollständigen ARN des Secrets Manager-Secrets angeben, in dem die sensiblen Daten enthalten sind, die dem Container zur Verfügung gestellt werden sollen. Weitere Informationen zum Erstellen von Geheimnissen finden Sie unter [Erstellen eines AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).

Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf ein Secrets Manager-Secret.

```
{
  "containerDefinitions": [{
    "logConfiguration": [{
      "logDriver": "splunk",
      "options": {
        "splunk-url": "https://your_splunk_instance:8088"
      },
      "secretOptions": [{
        "name": "splunk-token",
        "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
      }]
    }]
  }]
}
```

## Fügen Sie die Umgebungsvariable zur Container-Definition hinzu
<a name="secrets-envvar-ssm-paramstore-update-container-definition"></a>

Geben Sie in Ihrer Containerdefinition `secrets` mit dem Namen der im Container zu setzenden Umgebungsvariablen und dem Namen oder dem ARN des Systems Manager-Parameter Store-Parameters an, der die sensiblen Daten enthält, die dem Container präsentiert werden sollen. Weitere Informationen finden Sie unter [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf einen Systems Manager Parameter Store-Parameter. Wenn sich der Systems Manager Parameter Store-Parameter in der gleichen Region wie die Aufgabe befindet, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Parameters verwenden. Wenn der Parameter in einer anderen Region existiert, geben Sie den vollen ARN an.

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
    }]
  }]
}
```

Informationen zum Erstellen einer Aufgabendefinition mit dem in einer Umgebungsvariable angegebenen Geheimnis finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).

## Verwenden von Systems Manager
<a name="secrets-logconfig-ssm-paramstore"></a>

Sie können vertrauliche Daten in eine Protokollkonfiguration einfügen. Beim Angeben von `logConfiguration` können Sie `secretOptions` in Ihrer Containerdefinition mit dem Namen der im Container festzulegenden Protokolltreiberoption und dem vollständigen ARN des Systems Manager-Parameter Store-Parameters angeben, in denen die sensiblen Daten enthalten sind, die dem Container präsentiert werden sollen.

**Wichtig**  
Wenn sich der Systems Manager Parameter Store-Parameter in der gleichen Region wie die Aufgabe befindet, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Parameters verwenden. Wenn der Parameter in einer anderen Region existiert, geben Sie den vollen ARN an.

Im Folgenden finden Sie einen Ausschnitt einer Aufgabendefinition mit dem Format beim Verweisen auf einen Systems Manager Parameter Store-Parameter.

```
{
  "containerDefinitions": [{
    "logConfiguration": [{
      "logDriver": "fluentd",
      "options": {
        "tag": "fluentd demo"
      },
      "secretOptions": [{
        "name": "fluentd-address",
        "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter:/parameter_name"
      }]
    }]
  }]
}
```

# Angeben sensibler Daten mithilfe von Secrets-Manager-Geheimnissen in Amazon ECS
<a name="specifying-sensitive-data-tutorial"></a>

Amazon ECS ermöglicht es Ihnen, vertrauliche Daten in Ihre Container einzufügen, indem Sie Ihre sensiblen Daten in AWS Secrets Manager Geheimnissen speichern und dann in Ihrer Container-Definition auf sie verweisen. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).

Das folgende Tutorial zeigt, wie Sie ein Secrets-Manager-Geheimnis erstellen, in einer Amazon-ECS-Aufgabendefinition auf das Geheimnis verweisen und es dann überprüfen, indem Sie die Umgebungsvariable in einem Container abfragen, um den Inhalt des Geheimnisses anzuzeigen.

## Voraussetzungen
<a name="specifying-sensitive-data-tutorial-prereqs"></a>

In diesem Tutorial wird davon ausgegangen, dass die folgenden Voraussetzungen erfüllt wurden:
+ Die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) wurden ausgeführt.
+ Ihr Benutzer hat die erforderlichen IAM-Berechtigungen zum Erstellen der Secrets-Manager- und Amazon-ECS-Ressourcen.

## Schritt 1: Erstellen eines Secrets Manager-Secrets
<a name="specifying-sensitive-data-tutorial-create-secret"></a>

Sie können die Secrets Manager-Konsole verwenden, um ein Secret für Ihre sensiblen Daten zu erstellen. In diesem Tutorial erstellen wir ein grundlegendes Secret zum Speichern eines Benutzernamens und eines Passworts zum späteren Verweisen in einem Container. Weitere Informationen finden Sie unter [Create an AWS Secrets Manager Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *AWS Secrets Manager Benutzerhandbuch*.

Die ** key/value Paare, die in diesem Secret gespeichert werden sollen**, entsprechen dem Wert der Umgebungsvariablen in Ihrem Container am Ende des Tutorials.

Speichern Sie den **Secret ARN** (Geheimen ARN), um ihn in späteren Schritten in Ihrer IAM-Richtlinie für die Aufgabenausführung und der Aufgabendefinition zu verwenden.

## Schritt 2: Hinzufügen der Geheimnis-Berechtigungen zur Aufgabenausführungsrolle
<a name="specifying-sensitive-data-tutorial-update-iam"></a>

Damit Amazon ECS sensible Daten aus Ihrem Secrets-Manager-Geheimnis abrufen kann, benötigen Sie die Geheimnis-Berechtigungen für die Aufgabenausführungsrolle. Weitere Informationen finden Sie unter [Berechtigungen für Secrets Manager oder Systems Manager](task_execution_IAM_role.md#task-execution-secrets).

## Schritt 3: Erstellen einer Aufgabendefinition
<a name="specifying-sensitive-data-tutorial-create-taskdef"></a>

Sie können die Amazon-ECS-Konsole verwenden, um eine Aufgabendefinition zu erstellen, die auf ein Secrets Manager-Secret verweist.

**So erstellen Sie eine Aufgabendefinition, die ein Secret angibt**

Verwenden Sie die IAM-Konsole zum Aktualisieren Ihrer Aufgabenausführungsrolle mit den erforderlichen Berechtigungen.

1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.

1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.

1. Wählen Sie **Create new task definition** (Neue Aufgabendefinition erstellen), **Create new task definition with JSON** (Neue Aufgabendefinition mit JSON) erstellen.

1. Geben Sie in das JSON-Editor-Feld den folgenden JSON-Text für die Aufgabendefinition ein. Achten Sie darauf, dass Sie den vollständigen ARN des Secrets-Manager-Geheimnisses, das Sie in Schritt 1 erstellt haben, und die Aufgabenausführungsrolle, die Sie im Schritt 2 aktualisiert haben, angeben. Wählen Sie **Speichern**.

1. 

   ```
   {
       "executionRoleArn": "arn:aws:iam::aws_account_id:role/ecsTaskExecutionRole",
       "containerDefinitions": [
           {
               "entryPoint": [
                   "sh",
                   "-c"
               ],
               "portMappings": [
                   {
                       "hostPort": 80,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ],
               "command": [
                   "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
               ],
               "cpu": 10,
               "secrets": [
                   {
                       "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:username_value",
                       "name": "username_value"
                   }
               ],
               "memory": 300,
               "image": "public.ecr.aws/docker/library/httpd:2.4",
               "essential": true,
               "name": "ecs-secrets-container"
           }
       ],
       "family": "ecs-secrets-tutorial"
   }
   ```

1. Wählen Sie **Erstellen** aus.

## Schritt 4: Erstellen eines Clusters
<a name="specifying-sensitive-data-tutorial-create-cluster"></a>

Verwenden Sie die Amazon-ECS-Konsole zum Erstellen eines Clusters, der eine Container-Instance zum Ausführen der Aufgabe enthält. Wenn Sie bereits über einen Cluster mit mindestens einer registrierten Container-Instance und den Ressourcen zum Ausführen einer Instance der für dieses Tutorial erstellten Aufgabendefinition verfügen, können Sie direkt zum nächsten Schritt gehen.

Für dieses Tutorial erstellen wir einen Cluster mit einer `t2.micro`-Container-Instance unter Verwendung des Amazon-ECS-optimierten Amazon Linux 2-AMI.

Informationen zum Erstellen eines Clusters für EC2 finden Sie unter [Erstellen eines Amazon-ECS-Clusters für Amazon-EC2-Workloads](create-ec2-cluster-console-v2.md).

## Schritt 5: Führen Sie eine Aufgabe aus
<a name="specifying-sensitive-data-tutorial-run-task"></a>

Sie können die Amazon-ECS-Konsole verwenden, um eine Aufgabe mithilfe der Aufgabendefinition auszuführen, die Sie erstellt haben. In diesem Tutorial führen wir eine Aufgabe mit EC2 aus und verwenden dazu den Cluster, den wir im vorherigen Schritt erstellt haben. 

Informationen zum Ausführen einer Aufgabe finden Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).

## Schritt 6: Überprüfen
<a name="specifying-sensitive-data-tutorial-verify"></a>

Anhand folgender Schritte können Sie überprüfen, ob alle Schritte erfolgreich abgeschlossen wurden und die Umgebungsvariable in Ihrem Container ordnungsgemäß erstellt wurde.

**Überprüfen, ob die Umgebungsvariable erstellt wurde**

1. Suchen Sie nach der öffentlichen IP-Adresse oder DNS-Adresse für Ihre Container-Instance.

   1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.

   1. Wählen Sie im Navigationsbereich **Cluster** und dann den von Ihnen erstellten Cluster aus.

   1. Wählen Sie **Infrastruktur** und dann die Container-Instance aus.

   1. Zeichnen Sie die **öffentliche IP** oder das **öffentliche DNS** für Ihre Instance auf.

1. Stellen Sie auf einem macOS- oder Linux-Computer mit dem folgenden Befehl eine Verbindung mit Ihrer Instance her und ersetzen Sie den Pfad zu Ihrem privaten Schlüssel und die öffentliche Adresse für Ihre Instance:

   ```
   $ ssh -i /path/to/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com
   ```

   Weitere Informationen zur Verwendung eines Windows-Computers finden Sie unter [Herstellen einer Verbindung mit Ihrer Linux-Instance mit PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html) im *Amazon-EC2-Benutzerhandbuch*.
**Wichtig**  
Weitere Informationen zu Problemen beim Herstellen der Verbindung mit Ihrer Instance finden Sie unter [Beheben von Verbindungsproblemen mit Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) im *Benutzerhandbuch für Amazon EC2*.

1. Erstellen Sie eine Liste der Container, die auf der Instance ausgeführt werden. Notieren Sie die Container-ID für `ecs-secrets-tutorial`-Container.

   ```
   docker ps
   ```

1. Stellen Sie mithilfe der Container-ID aus der Ausgabe des vorherigen Schritts eine Verbindung mit dem `ecs-secrets-tutorial`-Container her.

   ```
   docker exec -it container_ID /bin/bash
   ```

1. Verwenden Sie den `echo`-Befehl, um den Wert der Umgebungsvariable zu drucken.

   ```
   echo $username_value
   ```

   Wenn das Tutorial erfolgreich war, sollten Sie die folgende Meldung sehen:

   ```
   password_value
   ```
**Anmerkung**  
Alternativ können Sie alle Umgebungsvariablen in Ihrem Container mithilfe des Befehls `env` (oder `printenv`) auflisten.

## Schritt 7: Bereinigen
<a name="specifying-sensitive-data-tutorial-cleanup"></a>

Wenn Sie mit diesem Tutorial fertig sind, sollten Sie die zugehörigen Ressourcen bereinigen, um zu vermeiden, dass Gebühren für ungenutzte Ressourcen anfallen.

**So bereinigen Sie die Ressourcen**

1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Klicken Sie im Navigationsbereich auf **Cluster**.

1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.

1. Wählen Sie **Delete Cluster** (Cluster löschen) aus. 

1. Geben Sie im Bestätigungsfeld **Löschen *cluster name*** ein und wählen Sie dann **Löschen** aus.

1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

1. Wählen Sie im Navigationsbereich **Rollen**. 

1. Durchsuchen Sie die Liste der Rollen für `ecsTaskExecutionRole` und wählen Sie diese aus.

1. Wähle „**Berechtigungen**“ und dann das **X** neben „**ECSSecretsTutorial**“. Wählen Sie **Remove (Entfernen)** aus.

1. Öffnen Sie die Secrets Manager Manager-Konsole unter [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).

1. Wählen Sie das von Ihnen erstellte **username\$1value**-Secret und **Actions (Aktionen)**, **Delete secret (Secret löschen)**.