Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Casi d'uso della definizione dell'attività di Amazon ECS
<a name="use-cases"></a>

Scopri di più su come scrivere le definizioni delle attività per vari AWS servizi e funzionalità.

A seconda del carico di lavoro, è necessario impostare determinati parametri di definizione delle attività. Inoltre, per EC2, è necessario scegliere istanze specifiche progettate per il carico di lavoro.

**Topics**
+ [Definizioni di attività Amazon ECS per carichi di lavoro GPU](ecs-gpu.md)
+ [Definizioni di attività Amazon ECS per carichi di lavoro di transcodifica video](ecs-vt1.md)
+ [Definizioni delle attività di Amazon ECS per i carichi di lavoro di machine learning di AWS Neuron](ecs-inference.md)
+ [Definizioni delle attività di Amazon ECS per le istanze di deep learning](ecs-dl1.md)
+ [Definizioni di attività Amazon ECS per carichi di lavoro ARM a 64 bit](ecs-arm64.md)
+ [Invia i log di Amazon ECS a CloudWatch](using_awslogs.md)
+ [Inviare i log di Amazon ECS a un servizio o AWS AWS Partner](using_firelens.md)
+ [Utilizzo di immagini non AWS containerizzate in Amazon ECS](private-auth.md)
+ [Riavviare singoli container nelle attività Amazon ECS con policy di riavvio dei container](container-restart-policy.md)
+ [Trasferimento di dati sensibili a un container Amazon ECS](specifying-sensitive-data.md)

# Definizioni di attività Amazon ECS per carichi di lavoro GPU
<a name="ecs-gpu"></a>

Amazon ECS supporta carichi di lavoro che utilizzano le GPU, quando crei cluster con istanze di container che supportano le GPU. Le istanze di container basate su GPU di Amazon EC2 che utilizzano i tipi di istanze p2, p3, p5, g3, g4 e g5 forniscono l'accesso a NVIDIA. GPUs Per maggiori informazioni, consultare [Linux Accelerated Computing Instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) nella *Guida ai tipi di istanze Amazon EC2*.

Amazon ECS fornisce un'AMI ottimizzata per GPU che dispone di driver del kernel NVIDIA pre-configurati e un runtime del GPU Docker. Per ulteriori informazioni, consulta [Linux ottimizzato per Amazon ECS AMIs](ecs-optimized_AMI.md).

Nella definizione delle attività è possibile designarne alcune da prendere GPUs in considerazione a livello di contenitore. Amazon ECS pianifica le istanze di container disponibili che supportano GPUs e collegano contenitori fisici GPUs a contenitori appropriati per prestazioni ottimali. 

Sono supportati i seguenti tipi di istanza Amazon EC2 basati su GPU. Per ulteriori informazioni, consultare [Istanze Amazon EC2 P2](https://aws.amazon.com/ec2/instance-types/p2/), [Istanze Amazon EC2 P3](https://aws.amazon.com/ec2/instance-types/p3/), [Istanze Amazon EC2 P4d](https://aws.amazon.com/ec2/instance-types/p4/), [Istanze Amazon EC2 P5](https://aws.amazon.com/ec2/instance-types/p5/), [Istanze Amazon EC2 G3](https://aws.amazon.com/ec2/instance-types/g3/), [Amazon EC2 G4 Instances](https://aws.amazon.com/ec2/instance-types/g4/), [Istanze Amazon EC2 G5](https://aws.amazon.com/ec2/instance-types/g5/), [Amazon EC2 G6 Instances](https://aws.amazon.com/ec2/instance-types/g6/) e [Amazon EC2 G6e Instances](https://aws.amazon.com/ec2/instance-types/g6e/).


|  Tipo di istanza  |  GPUs  |  Memoria GPU (GiB)  |  v CPUs  |  Memoria (GiB)  | 
| --- | --- | --- | --- | --- | 
|  p3.2xlarge  |  1  |  16  |  8  |  61  | 
|  p3.8xlarge  |  4  |  64  |  32  |  244  | 
|  p3.16xlarge  |  8  |  128  |  64  |  488  | 
|  p3dn.24xlarge  |  8  |  256  |  96  |  768  | 
|  p4d.24xlarge  | 8 | 320 | 96 | 1152 | 
| p5.48xlarge | 8 | 640 | 192 | 2048 | 
|  g3s.xlarge  |  1  |  8  |  4  |  30,5  | 
|  g3.4xlarge  |  1  |  8  |  16  |  122  | 
|  g3.8xlarge  |  2  |  16  |  32  |  244  | 
|  g3.16xlarge  |  4  |  32  |  64  |  488  | 
|  g4dn.xlarge  |  1  |  16  |  4  |  16  | 
|  g4dn.2xlarge  |  1  |  16  |  8  |  32  | 
|  g4dn.4xlarge  |  1  |  16  |  16  |  64  | 
|  g4dn.8xlarge  |  1  |  16  |  32  |  128  | 
|  g4dn.12xlarge  |  4  |  64  |  48  |  192  | 
|  g4dn.16xlarge  |  1  |  16  |  64  |  256  | 
|  g5.xlarge  |  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.x grande | 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 | 

Puoi recuperare l'ID Amazon Machine Image (AMI) per Amazon ECS ottimizzato per Amazon ECS AMIs interrogando l' AWS Systems Manager API Parameter Store. Utilizzando questo parametro, non è necessario cercare manualmente le AMI ottimizzate per Amazon ECS. IDs Per ulteriori informazioni sull'API Systems Manager Parameter Store, vedere [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Il principale IAM che utilizzi deve disporre dell'autorizzazione IAM `ssm:GetParameter` per recuperare i metadati dell'AMI ottimizzata per Amazon ECS.

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

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

Istanze gestite da Amazon ECS supporta l'elaborazione accelerata da GPU per carichi di lavoro come machine learning, elaborazione ad alte prestazioni ed elaborazione video tramite i seguenti tipi di istanze Amazon EC2. Per ulteriori informazioni sui tipi di istanza supportati da Istanze gestite da Amazon ECS, consultare [Tipi di Istanze gestite da Amazon ECS](managed-instances-instance-types.md).

Di seguito è riportato un sottoinsieme di tipi di istanze basate su GPU supportato su istanze gestite da Amazon ECS:
+ `g4dn`: con tecnologia NVIDIA T4 GPUs, adatto per inferenza di machine learning, visione artificiale e applicazioni a uso intensivo di grafica.
+ `g5`: con tecnologia NVIDIA A10G GPUs, offre prestazioni più elevate per applicazioni a uso intensivo di grafica e carichi di lavoro di machine learning.
+ `p3`: con tecnologia NVIDIA V100 GPUs, progettato per l'elaborazione ad alte prestazioni e l'apprendimento deep learning.
+ `p4d`: con tecnologia NVIDIA A100 GPUs, offre le massime prestazioni per l'apprendimento di machine learning e l'elaborazione ad alte prestazioni.

Quando utilizzi tipi di istanze abilitati per GPU con Istanze gestite da Amazon ECS, i driver NVIDIA e il toolkit CUDA sono preinstallati sull'istanza, semplificando l'esecuzione di carichi di lavoro accelerati da GPU.

## Selezione di istanze abilitate per GPU
<a name="managed-instances-gpu-instance-selection"></a>

Per selezionare i tipi di istanza abilitati alla GPU per i carichi di lavoro di Istanze gestite da Amazon ECS, utilizzare l'oggetto `instanceRequirements` nel modello di lancio del provider di capacità. Il seguente frammento mostra gli attributi che possono essere utilizzati per selezionare istanze abilitate per GPU.

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

Il seguente frammento mostra gli attributi che possono essere utilizzati per specificare i tipi di istanza abilitati per GPU nel modello di avvio.

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

## Immagini di container abilitati per GPU
<a name="managed-instances-gpu-container-images"></a>

Per utilizzarle GPUs nei contenitori, è necessario utilizzare immagini di container che contengano le librerie e gli strumenti GPU necessari. NVIDIAfornisce diverse immagini di container predefinite che puoi utilizzare come base per i carichi di lavoro della GPU, tra cui:
+ `nvidia:cuda`: immagini di base con il toolkit CUDA per l'elaborazione tramite GPU.
+ `tensorflow/tensorflow:latest-gpu`: TensorFlow con supporto GPU.
+ `pytorch/pytorch:latest-cuda`: PyTorch con supporto GPU.

Per un esempio di definizione di attività per Amazon ECS su Amazon ECS Managed Instances che prevede l'uso di GPUs, consulta. [Specificazione GPUs in una definizione di attività Amazon ECS](ecs-gpu-specifying.md)

## Considerazioni
<a name="gpu-considerations"></a>

**Nota**  
Il supporto per il tipo di famiglia di istanze g2 è obsoleto.  
La famiglia di istanze p2 è supportata solo nelle versioni precedenti a `20230912` dell'AMI Amazon ECS ottimizzata per GPU. Per continuare a utilizzare le istanze p2, consulta [Operazioni da eseguire per utilizzare un'istanza P2](#p2-instance).  
Gli aggiornamenti immediati dei NVIDIA/CUDA driver su entrambi questi tipi di famiglie di istanze causeranno potenziali guasti del carico di lavoro della GPU.

Ti consigliamo di considerare quanto segue prima di iniziare a lavorare GPUs su Amazon ECS.
+ I cluster possono contenere una combinazione di istanze di container GPU e non GPU.
+ Puoi eseguire carichi di lavoro GPU su istanze esterne. Durante la registrazione di un'istanza esterna nel tuo cluster, assicurati che il flag `--enable-gpu` sia incluso nello script di installazione. Per ulteriori informazioni, consulta [Registrazione di un'istanza esterna in un cluster Amazon ECS](ecs-anywhere-registration.md).
+ È necessario impostare `ECS_ENABLE_GPU_SUPPORT` su `true` nel file di configurazione dell'agente. Per ulteriori informazioni, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).
+ Durante l'esecuzione di un'attività o la creazione di un servizio, puoi utilizzare gli attributi del tipo di istanza quando configuri i vincoli di posizionamento delle attività per garantire su quali istanze di container verrà avviata l'attività. In questo modo, puoi utilizzare in modo più efficiente le risorse. Per ulteriori informazioni, consulta [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

  L'esempio seguente avvia un'attività su un'istanza di container `g4dn.xlarge` nel cluster predefinito.

  ```
  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
  ```
+ Per ogni container che ha un requisito di risorsa GPU specificato nella definizione di container, Amazon ECS imposta il runtime del container in modo che sia il runtime del container NVIDIA.
+ Il runtime del container NVIDIA richiede per poter funzionare l'impostazione di alcune variabili di ambiente nel container. Per un elenco di queste variabili di ambiente, consultare [Specialized Configurations with Docker](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable). Amazon ECS imposta il valore della variabile di `NVIDIA_VISIBLE_DEVICES` ambiente in modo che sia un elenco dei dispositivi GPU assegnati da IDs Amazon ECS al contenitore. Le altre variabili di ambiente richieste non vengono impostate da, Amazon ECS. Quindi, assicurati che siano impostate dall'immagine del container o nella definizione di quest'ultimo.
+ La famiglia del tipo di istanza p5 è supportata nella versione `20230929` e successive dell'AMI Amazon ECS ottimizzata per GPU. 
+ La famiglia del tipo di istanza g4 è supportata nella versione `20230913` e successive dell'AMI Amazon ECS ottimizzata per GPU. Per ulteriori informazioni, consulta [Linux ottimizzato per Amazon ECS AMIs](ecs-optimized_AMI.md). Non è supportata nel flusso di lavoro Crea cluster nella console Amazon ECS. Per utilizzare questi tipi di istanze, devi utilizzare la console o l'API di Amazon EC2 e registrare manualmente le istanze nel cluster. AWS CLI
+ Il tipo di istanza p4d.24xlarge funziona solo con CUDA 11 o versioni successive.
+ L'AMI Amazon ECS ottimizzata per GPU IPv6 è abilitata, il che causa problemi durante l'utilizzo. `yum` Questo problema può essere risolto configurandolo per l'uso IPv4 con `yum` il seguente comando.

  ```
  echo "ip_resolve=4" >> /etc/yum.conf
  ```
+  Quando create un'immagine del contenitore che non utilizza le immagini di NVIDIA/CUDA base, dovete impostare la variabile di runtime del `NVIDIA_DRIVER_CAPABILITIES` contenitore su uno dei seguenti valori:
  + `utility,compute`
  + `all`

  Per informazioni su come impostare la variabile, consulta [Controllo del runtime del container NVIDIA](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime) sul sito Web di NVIDIA.
+ GPUs non sono supportati nei contenitori Windows.

# Avvio di un'istanza di container GPU per Amazon ECS
<a name="gpu-launch"></a>

Per utilizzare un'istanza GPU su Amazon ECS su Amazon EC2, è necessario creare un modello di avvio, un file di dati utente e avviare l'istanza.

È quindi possibile eseguire un'attività che utilizza una definizione di attività configurata per la GPU.

## Utilizzo di un modello di avvio
<a name="gpu-launch-template"></a>

È possibile creare un modello di avvio.
+ Creare un modello di avvio che utilizzi l'ID AMI GPU ottimizzato per Amazon ECS per l'AMI. Per informazioni su come creare un modello di avvio, consultare [Create a new launch template using parameters you define](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters) nella *Guida dell'utente di Amazon EC2*.

  Utilizzare l'ID AMI ottenuto nel passaggio precedente per l'**immagine Amazon Machine**. Per informazioni su come specificare l'ID AMI con il parametro Systems Manager, consultare [Specify a Systems Manager parameter in a launch template](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id) nella *Guida dell'utente di Amazon EC2*.

  Aggiungere quanto segue ai **dati utente** nel modello di avvio. Sostituisci *cluster-name* con il nome del cluster.

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

## Usa il AWS CLI
<a name="gpu-launch-cli"></a>

È possibile utilizzare il AWS CLI per avviare l'istanza del contenitore.

1. Crea un file denominato `userdata.toml`. Questo file viene utilizzato per i dati utente dell'istanza. Sostituisci *cluster-name* con il nome del cluster.

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

1. Eseguire questo comando per ottenere l'ID AMI GPU. Ti servirà per la fase successiva.

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

1. Eseguire il comando seguente per avviare l'istanza GPU. Ricordati di sostituire i seguenti parametri:
   + Sostituiscilo *subnet* con l'ID della sottorete privata o pubblica in cui verrà avviata l'istanza.
   + Sostituisci *gpu\$1ami* con l'ID AMI del passaggio precedente.
   + Sostituisci *t3.large* con il tipo di istanza che desideri utilizzare.
   + Sostituisci *region* con il codice regionale.

   ```
   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. Esegui il comando seguente per verificare che l'istanza di container sia registrata nel cluster. Quando esegui questo comando, ricordati di sostituire i parametri seguenti:
   + Sostituisci *cluster* con il nome del cluster.
   + Sostituisci *region* con il tuo codice regionale.

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

# Specificazione GPUs in una definizione di attività Amazon ECS
<a name="ecs-gpu-specifying"></a>

Per utilizzare l'istanza GPUs on a container e il runtime Docker GPU, assicurati di aver indicato il numero di componenti richiesti dal contenitore nella definizione dell' GPUs attività. Man mano che GPUs vengono posizionati i contenitori che supportano il supporto, l'agente container di Amazon ECS aggiunge il numero desiderato di elementi fisici GPUs al contenitore appropriato. Il numero di contenitori GPUs riservati per tutti i contenitori di un'attività non può superare il numero di quelli disponibili GPUs sull'istanza del contenitore su cui viene avviata l'attività. Per ulteriori informazioni, consulta [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md).

**Importante**  
Se i requisiti della GPU non sono specificati nella definizione di attività, il processo utilizzerà il runtime del Docker di default.

Di seguito viene visualizzato il formato JSON per i requisiti GPU in una definizione di attività:

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

L'esempio seguente mostra la sintassi per un container Docker che specifica un requisito GPU. Questo contenitore ne utilizza due GPUs, esegue l'`nvidia-smi`utilità e quindi esce.

```
{
  "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"
}
```

La seguente definizione di attività di esempio mostra un TensorFlow contenitore che stampa il numero di elementi disponibili GPUs. L'attività viene eseguita su Istanze gestite da Amazon ECS, richiede una GPU e utilizza un'istanza `g4dn.xlarge`.

```
{
  "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",
}
```

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

Quando vuoi condividere GPUs, devi configurare quanto segue.

1. Rimuovi i requisiti di risorse GPU dalle definizioni delle tue attività in modo che Amazon ECS non riservi quelle GPUs che devono essere condivise.

1. Aggiungi i seguenti dati utente alle tue istanze quando desideri condividerli. GPUs Ciò renderà nvidia il runtime del contenitore Docker predefinito sull'istanza del contenitore in modo che tutti i contenitori Amazon ECS possano utilizzare il. GPUs Per ulteriori informazioni, consultare [Run commands when you launch an EC2 instance with user data input](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) nella *Guida per l'utente di Amazon EC2*.

   ```
   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. Impostare la variabile di ambiente `NVIDIA_VISIBLE_DEVICES` sul container. È possibile eseguire questa operazione specificando la variabile di ambiente nella definizione dell'attività. Per informazioni sui valori validi, consultare [GPU Enumeration](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration) sul sito di documentazione di NVIDIA.

## Operazioni da eseguire per utilizzare un'istanza P2
<a name="p2-instance"></a>

Per continuare a lavorare con le istanze P2, puoi utilizzare una delle seguenti opzioni.

È necessario modificare i dati utente dell'istanza per entrambe le opzioni. Per ulteriori informazioni, consultare [Run commands when you launch an EC2 instance with user data input](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) nella *Guida per l'utente di Amazon EC2*.

**Usa l'ultima AMI ottimizzata per GPU supportata**

Puoi utilizzare la versione `20230906` dell'AMI ottimizzata per GPU e aggiungere quanto segue ai dati utente dell'istanza.

Sostituire cluster-name con il nome del cluster.

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

**Usa l'AMI ottimizzata per GPU più recente e aggiorna i dati utente**

Puoi aggiungere i comandi seguenti ai dati utente dell'istanza. Questa operazione consente di disinstallare i driver Nvidia 535/Cuda12.2 e installare i driver Nvidia 470/Cuda11.4, correggendo la versione.

```
#!/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
```

**Crea la tua AMI ottimizzata per GPU compatibile con P2**

Puoi creare un'AMI Amazon ECS ottimizzata per GPU personalizzata e compatibile con le istanze P2, quindi avviare le istanze P2 utilizzando l'AMI.

1. Esegui il comando seguente per clonare `amazon-ecs-ami repo`.

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

1. Imposta l'agente Amazon ECS richiesto e le versioni dell'AMI Amazon Linux di origine in `release.auto.pkrvars.hcl` o `overrides.auto.pkrvars.hcl`.

1. Esegui il comando seguente per creare un'AMI EC2 privata compatibile con P2.

   Sostituisci la regione con la regione dell'istanza.

   ```
   REGION=region make al2keplergpu
   ```

1. Utilizza l'AMI con i seguenti dati utente dell'istanza per connetterti al cluster Amazon ECS.

   Sostituire cluster-name con il nome del cluster.

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

# Definizioni di attività Amazon ECS per carichi di lavoro di transcodifica video
<a name="ecs-vt1"></a>

[Per utilizzare i carichi di lavoro di transcodifica video su Amazon ECS, registra le istanze Amazon EC2. VT1](https://aws.amazon.com/ec2/instance-types/vt1/) Dopo aver registrato queste istanze, puoi eseguire carichi di lavoro di transcodifica video live e pre-renderizzati come attività su Amazon ECS. VT1 Le istanze Amazon EC2 utilizzano schede di transcodifica multimediale Xilinx U30 per accelerare i carichi di lavoro di transcodifica video live e pre-renderizzati.

**Nota**  
Per istruzioni su come eseguire carichi di lavoro di transcodifica video in container diversi da Amazon ECS, consulta la [documentazione di Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1).

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

Prima di iniziare la distribuzione VT1 su Amazon ECS, considera quanto segue:
+ I tuoi cluster possono contenere un mix di VT1 e non istanze. VT1 
+ Hai bisogno di un'applicazione Linux che utilizzi schede di transcodifica multimediale Xilinx U30 con codec accelerati AVC (H.264) e HEVC (H.265).
**Importante**  
Le applicazioni che utilizzano altri codec potrebbero non avere prestazioni migliorate sulle istanze. VT1 
+ Solo un'attività di transcodifica può essere eseguita su una scheda U30. Ogni scheda ha due dispositivi ad essa associati. È possibile eseguire tante attività di transcodifica quante sono le schede disponibili per ciascuna istanza. VT1 
+ Durante l'esecuzione di un servizio o di un'attività autonoma, puoi utilizzare gli attributi del tipo di istanza quando configuri i vincoli di posizionamento delle attività. Ciò garantisce che l'attività venga avviata sull'istanza di container specificata. In questo modo è possibile utilizzare le risorse in modo efficace e che le attività relative ai carichi di lavoro di transcodifica video siano affidate alle istanze. VT1 Per ulteriori informazioni, consulta [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

  Nell'esempio seguente viene eseguita un'attività su una istanza `vt1.3xlarge` sul cluster `default`.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition vt1-3xlarge-xffmpeg-processor \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == vt1.3xlarge"
  ```
+ Puoi configurare un container per utilizzare la scheda U30 specifica disponibile nell'istanza di container host. Puoi farlo usando il parametro `linuxParameters` e specificando i dettagli del dispositivo. Per ulteriori informazioni, consulta [Requisiti di definizione di attività](#ecs-vt1-requirements).

## Utilizzo di un VT1 AMI
<a name="ecs-vt1-ami"></a>

Sono disponibili due opzioni per l'esecuzione di un'AMI su Amazon EC2 per istanze di container Amazon ECS. La prima opzione è quella di utilizzare l'AMI ufficiale Xilinx su Marketplace AWS. La seconda opzione è quella di creare la propria AMI dal repository di esempio.
+ [Offerte AMIs Xilinx](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6) su. Marketplace AWS
+ Amazon ECS fornisce un repository di esempio che è possibile utilizzare per creare un'AMI per carichi di lavoro di transcodifica video. Questa AMI è dotata di driver Xilinx U30. Puoi trovare il repository che contiene gli script di Packer su. [GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline) Per ulteriori informazioni su Packer, consulta la [documentazione di Packer](https://developer.hashicorp.com/packer/docs).

## Requisiti di definizione di attività
<a name="ecs-vt1-requirements"></a>

Per eseguire container di transcodifica video su Amazon ECS, la definizione di attività deve contenere un'applicazione di transcodifica video che utilizza i codec accelerati H.264/AVC e H.265/HEVC. [È possibile creare un'immagine del contenitore seguendo i passaggi su Xilinx. GitHub](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage)

La definizione dell'attività deve essere specifica per il tipo di istanza. I tipi di istanza sono 3xlarge, 6xlarge e 24xlarge. Per utilizzare i dispositivi Xilinx U30 specifici disponibili nell'istanza di container host, è necessario configurare un container. Puoi farlo usando il parametro `linuxParameters`. La tabella seguente descrive in dettaglio le schede e i dispositivi SoCs specifici per ogni tipo di istanza.


| Tipo di istanza | v CPUs | RAM (GiB) | Schede acceleratore U30 | Dispositivi SoC indirizzabili XCU30  | Percorsi dispositivi | 
| --- | --- | --- | --- | --- | --- | 
| 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 | 

**Importante**  
Se la definizione di attività elenca dispositivi di cui l'istanza EC2 non dispone, l'attività non viene eseguita. Quando l'attività ha esito negativo, viene visualizzato il seguente messaggio di errore in `stoppedReason`: `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory`.

# Specifica della transcodifica video in una definizione attività Amazon ECS
<a name="task-def-video-transcode"></a>

Nell'esempio seguente viene fornita la sintassi utilizzata per una definizione di attività di un container Linux su Amazon EC2. Questa definizione di attività viene utilizzata per le immagini del container create seguendo la procedura fornita nella [documentazione di Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage). Se utilizzi questo esempio, sostituisci `image` con la tua immagine e copia i tuoi file video nell'istanza della directory `/home/ec2-user`.

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

1. Crea un file di testo denominato `vt1-3xlarge-ffmpeg-linux.json` con il seguente contenuto.

   ```
   {
       "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. Registra la definizione dell'attività.

   ```
   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. Crea un file di testo denominato `vt1-6xlarge-ffmpeg-linux.json` con il seguente contenuto.

   ```
   {
       "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. Registra la definizione dell'attività.

   ```
   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. Crea un file di testo denominato `vt1-24xlarge-ffmpeg-linux.json` con il seguente contenuto.

   ```
   {
       "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. Registra la definizione dell'attività.

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

------

# Definizioni delle attività di Amazon ECS per i carichi di lavoro di machine learning di AWS Neuron
<a name="ecs-inference"></a>

Puoi registrare istanze [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 e [Amazon EC2](https://aws.amazon.com/ec2/instance-types/inf2/) Inf2 nei](https://aws.amazon.com/ec2/instance-types/inf1/) tuoi cluster per carichi di lavoro di machine learning.

[Le istanze Amazon EC2 Trn1 e Trn2 sono alimentate da chip Trainium.AWS](https://aws.amazon.com/ai/machine-learning/trainium/) Queste istanze offrono addestramento ad alte prestazioni e a basso costo per il machine learning nel cloud. Puoi addestrare un modello di inferenza di machine learning utilizzando un framework di machine learning con AWS Neuron su un'istanza Trn1 o Trn2. Quindi, puoi eseguire il modello su un'istanza Inf1 o un'istanza Inf2 per utilizzare l'accelerazione dei chip Inferentia. AWS 

Le istanze Inf1 e Inf2 di Amazon EC2 si basano sui chip [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/), che offrono prestazioni elevate e inferenze a costi contenuti nel cloud.

I modelli di machine learning vengono implementati in container utilizzando [AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/), ovvero un Software Developer Kit (SDK) specializzato. L'SDK è composto da un compilatore, un runtime e strumenti di profilazione che ottimizzano le prestazioni di apprendimento automatico dei chip di apprendimento automatico. AWS AWS Neuron supporta i più diffusi framework di machine learning come, e Apache. TensorFlow PyTorch MXNet

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

Prima di iniziare a implementare Neuron su Amazon ECS, tieni presente quanto segue:
+ I tuoi cluster possono contenere un mix di Trn1, Trn2, Inf1, Inf2 e altre istanze.
+ È necessaria un'applicazione Linux in un contenitore che utilizzi un framework di apprendimento automatico che supporti Neuron. AWS 
**Importante**  
Le applicazioni che utilizzano altri framework potrebbero non avere prestazioni migliorate sulle istanze Trn1, Trn2, Inf1 e Inf2.
+ Puoi eseguire soltanto un'attività di inferenza o di addestramento all'inferenza su ogni chip [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) o [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Per Inf1, ogni chip ne ha 4. NeuronCores Per Trn1, Trn2 e Inf2 ogni chip ne ha 2. NeuronCores Puoi eseguire tante attività quanti sono i chip disponibili per ciascuna delle tue istanze Trn1, Trn2, Inf1 e Inf2.
+ Durante l'esecuzione di un servizio o di un'attività autonoma, puoi utilizzare gli attributi del tipo di istanza quando configuri i vincoli di posizionamento dell'attività. Ciò garantisce che l'attività venga avviata sull'istanza di container specificata. In questo modo è possibile ottimizzare l'utilizzo complessivo delle risorse e garantire che le attività per i carichi di lavoro di inferenza si trovino sulle istanze Trn1, Trn2, Inf1 e Inf2. Per ulteriori informazioni, consulta [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

  Nell'esempio seguente viene eseguita un'attività su una istanza `Inf1.xlarge` sul cluster `default`.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition ecs-inference-task-def \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == Inf1.xlarge"
  ```
+ I requisiti di risorse Neuron non possono essere definiti in una definizione di attività. Invece, configurate un contenitore per utilizzare chip AWS Trainium o Inferentia specifici disponibili sull'istanza del contenitore host. AWS Puoi farlo usando il parametro `linuxParameters` e specificando i dettagli del dispositivo. Per ulteriori informazioni, consulta [Requisiti di definizione di attività](#ecs-inference-requirements).

## Utilizzare l'AMI Amazon Linux 2023 (Neuron) ottimizzata per Amazon ECS
<a name="ecs-inference-ami2023"></a>

Amazon ECS fornisce un'AMI ottimizzata per Amazon ECS basata su Amazon Linux 2023 per carichi di lavoro AWS Trainium e AWS Inferentia. Viene fornito con i driver AWS Neuron e il runtime per Docker. Questa AMI semplifica l'esecuzione dei carichi di lavoro di inferenza di machine learning su Amazon ECS.

Consigliamo di utilizzare l'AMI Amazon Linux 2023 (Neuron) ottimizzata per Amazon ECS quando si avviano le istanze Trn1, Inf1 e Inf2 di Amazon EC2. 

Puoi recuperare l'attuale AMI Amazon Linux 2023 (Neuron) ottimizzata per Amazon ECS AWS CLI utilizzando il comando seguente.

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

## Requisiti di definizione di attività
<a name="ecs-inference-requirements"></a>

Per distribuire Neuron su Amazon ECS, la definizione dell'attività deve contenere la definizione del contenitore per un contenitore predefinito che serve il modello di inferenza per. TensorFlow È fornito da AWS Deep Learning Containers. Questo contenitore contiene il runtime AWS Neuron e l'applicazione TensorFlow Serving. All'avvio, questo contenitore recupera il modello da Amazon S3, avvia TensorFlow Neuron Serving con il modello salvato e attende le richieste di previsione. Nell'esempio seguente, l'immagine del contenitore ha 1.15 e Ubuntu 18.04. TensorFlow È disponibile un elenco completo di Deep Learning Containers predefiniti ottimizzati per Neuron. GitHub Per ulteriori informazioni, consulta [Using AWS TensorFlow Neuron](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-inferentia-tf-neuron-serving.html) Serving.

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

In alternativa, puoi creare la tua immagine di container sidecar di Neuron. Per ulteriori informazioni, vedere [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) nella Guida per gli *AWS Deep Learning AMIs sviluppatori*.

La definizione di attività deve essere specifica per il tipo di istanza. È necessario configurare un contenitore per utilizzare dispositivi AWS Trainium o AWS Inferentia specifici disponibili sull'istanza del contenitore host. Puoi farlo usando il parametro `linuxParameters`. Per una definizione di attività di esempio, vedere. [Specificare l'apprendimento automatico di AWS Neuron in una definizione di attività Amazon ECS](ecs-inference-task-def.md) Nella tabella seguente vengono descritti in dettaglio i chip specifici per ogni tipo di istanza.


| Tipo di istanza | v CPUs | RAM (GiB) | AWS chip acceleratori ML | Percorsi dispositivi | 
| --- | --- | --- | --- | --- | 
| 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 | 

# Specificare l'apprendimento automatico di AWS Neuron in una definizione di attività Amazon ECS
<a name="ecs-inference-task-def"></a>

Di seguito è riportato un esempio di definizione di attività Linux per `inf1.xlarge` che riporta la sintassi da utilizzare.

```
{
    "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"
        }
    ]
}
```

# Definizioni delle attività di Amazon ECS per le istanze di deep learning
<a name="ecs-dl1"></a>

Per utilizzare carichi di lavoro di deep learning su Amazon ECS, registra le istanze [Amazon DL1 EC2](https://aws.amazon.com/ec2/instance-types/dl1/) nei tuoi cluster. Le DL1 istanze Amazon EC2 sono alimentate dagli acceleratori Gaudi di Habana Labs (una società Intel). Usa l'SDK Habana SynapseAI per connetterti agli acceleratori Habana Gaudi. L'SDK supporta i più diffusi framework di machine learning e. TensorFlow PyTorch

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

Prima di iniziare la distribuzione DL1 su Amazon ECS, considera quanto segue:
+ I tuoi cluster possono contenere un mix di DL1 e non istanze. DL1 
+ Durante la creazione di un servizio o l'esecuzione di un'attività autonoma, puoi utilizzare gli attributi del tipo di istanza quando configuri i vincoli di posizionamento delle attività per assicurarti che l'attività venga avviata sull'istanza di container specificata. In questo modo si garantisce che le risorse vengano utilizzate in modo efficace e che le attività per i carichi di lavoro di deep learning si svolgano sulle istanze. DL1 Per ulteriori informazioni, consulta [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

  Nell'esempio seguente viene eseguito un processo su una istanza `dl1.24xlarge` sul cluster `default`.

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

## Utilizzo di un DL1 AMI
<a name="ecs-dl1-ami"></a>

Sono disponibili tre opzioni per eseguire un'AMI su DL1 istanze Amazon EC2 per Amazon ECS:
+ Marketplace AWS AMIs [che sono fornite da Habana qui.](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq)
+ Habana Deep Learning AMIs fornito da Amazon Web Services. Poiché non è incluso, è necessario installare l'agente container Amazon ECS separatamente.
+ Usa Packer per creare un'AMI personalizzata fornita dal [GitHubrepository](https://github.com/aws-samples/aws-habana-baseami-pipeline). Per ulteriori informazioni, consulta [la documentazione di Packer](https://developer.hashicorp.com/packer/docs).

# Specifica del deep learning in una definizione di attività Amazon ECS
<a name="ecs-dl1-requirements"></a>

Per eseguire i contenitori di deep learning accelerato di Habana Gaudi su Amazon ECS, la definizione dell'attività deve contenere la definizione del contenitore per un contenitore predefinito che serve il modello di deep learning per TensorFlow o che PyTorch utilizza Habana SynapseAI fornito da Deep Learning Containers. AWS 

L'immagine seguente del contenitore ha 2.7.0 e Ubuntu 20.04. TensorFlow Viene mantenuto un elenco completo di Deep Learning Containers predefiniti ottimizzati per gli acceleratori Habana Gaudi. GitHub Per ulteriori informazioni, consulta [Habana Training Containers](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers) (Container di training Habana).

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

Di seguito è riportata una definizione di attività di esempio per container Linux su Amazon EC2, che riporta la sintassi da utilizzare. In questo esempio viene utilizzata un'immagine contenente l'Habana Labs System Management Interface Tool (HL-SMI) che trovi qui: `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"
        }
    ]
}
```

# Definizioni di attività Amazon ECS per carichi di lavoro ARM a 64 bit
<a name="ecs-arm64"></a>

Amazon ECS supporta l'utilizzo di applicazioni ARM a 64 bit. È possibile eseguire le applicazioni sulla piattaforma con tecnologia [Processori AWS Graviton](https://aws.amazon.com/ec2/graviton/). adatti per un'ampia varietà di carichi di lavoro, tra cui server applicativi, micro-servizi, elaborazione ad alte prestazioni, inferenza di machine learning basata su CPU, codifica video, automazione della progettazione elettronica, giochi, database open-source e cache in memoria.

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

Prima di iniziare a implementare le definizioni di attività che utilizzano l'architettura ARM a 64 bit, tieni in considerazione quanto segue:
+ Le applicazioni possono utilizzare Fargate o. EC2s
+ Le applicazioni possono utilizzare solo il sistema operativo Linux.
+ Per il tipo Fargate, le applicazioni devono utilizzare la versione `1.4.0` o versione successiva della piattaforma Fargate.
+ Le applicazioni possono essere utilizzate Fluent Bit o CloudWatch per il monitoraggio.
+ Per Fargate, quanto segue Regioni AWS non supporta i carichi di lavoro ARM a 64 bit:
  + Stati Uniti orientali (Virginia settentrionale), la zona di disponibilità `use1-az3`
+  Per EC2, consultare quanto segue per verificare che la propria regione supporti il tipo di istanza che si desidera utilizzare:
  + [Istanze Amazon EC2 M6g](https://aws.amazon.com/ec2/instance-types/m6)
  +  [Istanze Amazon EC2 T4g](https://aws.amazon.com/ec2/instance-types/t4/)
  +  [Istanze Amazon EC2 C6g](https://aws.amazon.com/ec2/instance-types/c6g/)
  +  [Istanze Amazon EC2 R6gd](https://aws.amazon.com/ec2/instance-types/r6/)
  +  [Istanze Amazon EC2 X2gd](https://aws.amazon.com/ec2/instance-types/x2/)

  Puoi anche utilizzare il comando `describe-instance-type-offerings` di Amazon EC2 con un filtro per visualizzare l'offerta di istanze per la tua regione. 

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

  Nell'esempio seguente viene verificata la disponibilità del tipo di istanza M6 nella regione Stati Uniti orientali (Virginia settentrionale) (us-east-1).

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

  Per ulteriori informazioni, consulta [describe-instance-type-offerings ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)*Amazon EC2 Command Line* Reference.

# Specifica dell'architettura ARM in una definizione di attività Amazon ECS
<a name="ecs-arm-specifying"></a>

Per utilizzare l'architettura ARM, specifica `ARM64` per il parametro di definizione di attività `cpuArchitecture`. 

Nell'esempio seguente, l'architettura ARM viene specificata in una definizione di attività. È in formato JSON.

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

Nell'esempio seguente, viene riportata una definizione di attività per l'architettura ARM che visualizza "hello world".

```
{
 "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"
}
```

# Invia i log di Amazon ECS a CloudWatch
<a name="using_awslogs"></a>

È possibile configurare i contenitori delle attività per inviare informazioni di registro ai CloudWatch registri. Se si utilizza Fargate per le attività, è possibile visualizzare i log provenienti dai container. Se si utilizza EC2, è possibile visualizzare diversi log dei container in un'unica comoda posizione, evitando inoltre che i log dei container occupino spazio su disco nelle istanze di container.

**Nota**  
Il tipo di informazioni registrate dai container nell'attività dipende per lo più dal relativo comando `ENTRYPOINT`. Per impostazione predefinita, i log acquisiti mostrano l'output di comando che normalmente viene visualizzato in un terminale interattivo se si esegue il container in locale, ovvero i flussi I/O `STDOUT` e `STDERR`. Il driver di `awslogs` registro passa semplicemente questi log da Docker a Logs. CloudWatch Per ulteriori informazioni su come vengono elaborati i log Docker, inclusi metodi alternativi per acquisire diversi flussi o dati di file, consulta l'articolo relativo alla [visualizzazione di log per un container o servizio](https://docs.docker.com/engine/logging/) nella documentazione di Docker.

*Per inviare i log di sistema dalle istanze di container Amazon ECS a CloudWatch Logs, consulta [Monitoring Log Files](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) e [CloudWatch Logs quote nella Amazon Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) User Guide. CloudWatch *

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

Se si utilizza Fargate per le tue attività, per attivare il driver di log `logConfiguration` è necessario aggiungere i parametri `awslogs` richiesti alla definizione di attività. Per ulteriori informazioni, consulta [Esempio di definizione di attività Amazon ECS: indirizza i log verso CloudWatch](specify-log-config.md).

Per il container Windows su Fargate, eseguire una delle seguenti opzioni quando uno dei parametri di definizione dell'attività contiene caratteri speciali come `& \ < > ^ |`:
+ Aggiungere un carattere escape (`\`) con virgolette doppie attorno all'intera stringa del parametro

  Esempio

  ```
  "awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"",
  ```
+ Aggiungere un carattere escape (`^`) attorno a ogni carattere speciale

  Esempio

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

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

Se si utilizza EC2 per le attività e si desidera attivare il driver di log `awslogs`, è necessario che le istanze di container Amazon ECS dispongano almeno della versione 1.9.0 dell'agente del container. Per informazioni sulla verifica della versione dell'agente e sull'aggiornamento alla versione più recente, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

**Nota**  
È necessario utilizzare un'AMI ottimizzata per Amazon ECS o una personalizzata con almeno la versione `1.9.0-1` del pacchetto `ecs-init`. Quando si utilizza un'AMI personalizzata, è necessario specificare che il driver di registrazione `awslogs` è disponibile sull'istanza Amazon EC2 all'avvio dell'agente utilizzando la seguente variabile di ambiente nell'istruzione **docker run** o nel file della variabile di ambiente.  

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

Le istanze di container di Amazon ECS richiedono inoltre l'autorizzazione `logs:CreateLogStream` e `logs:PutLogEvents` nel ruolo IAM con cui avvii le istanze di container. Se hai creato il ruolo dell'istanza di container di Amazon ECS prima che fosse abilitato il supporto per il driver di log `awslogs` in Amazon ECS, potrebbe essere necessario aggiungere questa autorizzazione. `ecsTaskExecutionRole` viene utilizzato quando viene assegnato all'attività e deve contenere le autorizzazioni corrette. Per informazioni sul ruolo di esecuzione delle attività, consultare [Ruolo IAM di esecuzione di attività Amazon ECS](task_execution_IAM_role.md). Se nelle istanze di container viene utilizzata l'apposita policy IAM gestita, le tue istanze di container dispongono delle autorizzazioni corrette. Per informazioni sulla policy IAM gestita per le istanze di container, consultare [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).

# Esempio di definizione di attività Amazon ECS: indirizza i log verso CloudWatch
<a name="specify-log-config"></a>

Prima che i contenitori possano inviare i log a CloudWatch, è necessario specificare il driver di `awslogs` registro per i contenitori nella definizione dell'attività. Per ulteriori informazioni sui parametri di log, consultare [Archiviazione e registrazione](task_definition_parameters.md#container_definition_storage)

La definizione di attività JSON che segue ha un oggetto `logConfiguration` specificato per ogni container. Uno è per il WordPress contenitore che invia i log a un gruppo di log chiamato. `awslogs-wordpress` L'altro è per un container MySQL che invia i log a un gruppo di log chiamato `awslogs-mysql`. Entrambi i container utilizzano il prefisso `awslogs-example` per il flusso di log.

```
{
    "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"
}
```

## Fasi successive
<a name="specify-log-config-next-steps"></a>
+ Facoltativamente, puoi impostare una politica di conservazione per il gruppo di log utilizzando l'API CloudWatch AWS CLI o. Per ulteriori informazioni, consulta [put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) nella *documentazione di riferimento AWS Command Line Interface *.
+ Dopo aver registrato una definizione di attività con il driver di `awslogs` registro in una configurazione di registro delle definizioni dei contenitori, è possibile eseguire un'attività o creare un servizio con tale definizione di attività per iniziare a inviare i log ai CloudWatch registri. Per ulteriori informazioni, consultare [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md) e [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md).

# Inviare i log di Amazon ECS a un servizio o AWS AWS Partner
<a name="using_firelens"></a>

Puoi utilizzare Amazon ECS FireLens per utilizzare i parametri di definizione delle attività per indirizzare i log verso un AWS servizio o una destinazione AWS Partner Network (APN) per l'archiviazione e l'analisi dei log. AWS Partner Network È una comunità globale di partner che sfrutta programmi, competenze e risorse per creare, commercializzare e vendere offerte ai clienti. Per ulteriori informazioni, consulta [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens funziona con [Fluentd](https://www.fluentd.org/) e [Fluent Bit](https://fluentbit.io/). Forniamo l'immagine AWS for Fluent Bit oppure puoi utilizzare la tua immagine Fluentd o Fluent Bit.

Per impostazione predefinita, Amazon ECS configura la dipendenza del container in modo che il container Firelens si avvii prima di qualsiasi container che lo utilizza. Inoltre, il container Firelens si ferma dopo che tutti i container che lo utilizzano si fermano.

Per utilizzare questa funzionalità, devi creare un ruolo IAM per le tue attività che fornisca le autorizzazioni necessarie per utilizzare tutti AWS i servizi richiesti dalle attività. Ad esempio, se un container esegue il routing dei log a Firehose, allora l'attività richiede l'autorizzazione per chiamare l'API `firehose:PutRecordBatch`. Per ulteriori informazioni, consulta [Aggiunta e rimozione di autorizzazioni per identità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l'utente di IAM*.

Il processo potrebbe richiedere anche il ruolo di esecuzione del processo di Amazon ECS nelle seguenti condizioni. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione di attività Amazon ECS](task_execution_IAM_role.md).
+ Se la tua attività è ospitata su Fargate e stai estraendo immagini di container da Amazon ECR o stai facendo riferimento Gestione dei segreti AWS a dati sensibili dalla tua configurazione di registro, devi includere il ruolo IAM di esecuzione dell'attività.
+ Quando si utilizza un file di configurazione personalizzato ospitato in Amazon S3, il ruolo IAM per l'esecuzione dell'attività deve includere l'autorizzazione `s3:GetObject`.

Considera quanto segue quando utilizzi FireLens Amazon ECS:
+ Consigliamo di aggiungere `my_service_` al log del nome del container in modo da poter distinguere facilmente i nomi dei container nella console.
+ Per impostazione predefinita, Amazon ECS aggiunge una dipendenza dall'ordine iniziale del container tra i container dell'applicazione e il container FireLens. Quando si specifica un ordine del container tra i container dell'applicazione e il container FireLens, l'ordine di avvio predefinito del container viene sovrascritto.
+ FireLens per Amazon ECS è supportato per le attività ospitate sia su AWS Fargate su Linux che su Amazon EC2 su Linux. I container di Windows non supportano FireLens.

  Per informazioni su come configurare la registrazione centralizzata per i container di Windows, consulta [Registrazione centralizzata per container di Windows su Amazon ECS tramite Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/).
+ Puoi utilizzare CloudFormation modelli FireLens per configurare Amazon ECS. Per ulteriori informazioni, consulta la [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)Guida per l'*AWS CloudFormation utente*
+ FireLensascolta sulla porta`24224`, quindi per garantire che il FireLens log router non sia raggiungibile al di fuori dell'operazione, non devi consentire il traffico `24224` in entrata sulla porta del gruppo di sicurezza utilizzato dall'attività. Per attività che utilizzano la modalità di rete `awsvpc`, questo è il gruppo di sicurezza associato all'attività. Per attività che utilizzano la modalità di rete `host`, questo è il gruppo di sicurezza associato all'istanza Amazon EC2 che ospita l'attività. Per attività che utilizzano la modalità di rete `bridge`, non creare mappature di porte che utilizzano la porta `24224`.
+ Per le attività che utilizzano la modalità di `bridge` rete, il contenitore con la FireLens configurazione deve avviarsi prima dell'avvio di qualsiasi contenitore di applicazioni che si basa su di essa. Per controllare l'ordine di avvio dei container, utilizza le condizioni di dipendenza nella definizione di attività. Per ulteriori informazioni, consulta [Dipendenze per i container](task_definition_parameters.md#container_definition_dependson).
**Nota**  
Se utilizzi i parametri delle condizioni di dipendenza nelle definizioni dei contenitori con una FireLens configurazione, assicurati che ogni contenitore abbia un requisito di `HEALTHY` condizione `START` or.
+ Per impostazione predefinita, FireLens aggiunge il nome del cluster e della definizione dell'attività e l'Amazon Resource Name (ARN) del cluster come chiavi di metadati ai stdout/stderr log del contenitore. Di seguito è riportato un esempio del formato dei metadati.

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

  Se non desideri i metadati nei tuoi log, imposta `enable-ecs-log-metadata` su `false` nella sezione `firelensConfiguration` della definizione di attività.

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

Puoi configurare il FireLens contenitore in modo che venga eseguito come utente non root. Considera i seguenti aspetti:
+  Per configurare il FireLens contenitore in modo che venga eseguito come utente non root, è necessario specificare l'utente in uno dei seguenti formati:
  + `uid`
  + `uid:gid`
  + `uid:group`

  Per ulteriori informazioni sulla specificazione di un utente in una definizione di contenitore, consulta [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)*Amazon Elastic Container Service API Reference*.

  Il FireLens contenitore riceve i log delle applicazioni tramite un UNIX socket. L'agente Amazon ECS utilizza il `uid` per assegnare la proprietà della directory socket al FireLens contenitore.
+ La configurazione del FireLens contenitore per l'esecuzione come utente non root è supportata nelle versioni di Amazon ECS Agent `1.96.0` e successive e nelle versioni AMI ottimizzate per Amazon ECS e successive. `v20250716`
+ Quando si specifica un utente per il FireLens contenitore, questo `uid` deve essere univoco e non deve essere utilizzato per altri processi appartenenti ad altri contenitori nell'attività o nell'istanza del contenitore.

Per informazioni su come utilizzare più file di configurazione con Amazon ECS, inclusi i file ospitati o i file in Amazon S3, consultare [Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit).

Per informazioni sulle configurazioni di esempio, vedere[Esempio di definizione dell'attività Amazon ECS: indirizzare i log a FireLens](firelens-taskdef.md).

Per ulteriori informazioni sulla configurazione dei log per un throughput elevato, vedere. [Configurazione dei log di Amazon ECS per un throughput elevato](firelens-docker-buffer-limit.md)

# Configurazione dei log di Amazon ECS per un throughput elevato
<a name="firelens-docker-buffer-limit"></a>

Per scenari con elevata velocità di trasmissione dei log, consigliamo di utilizzare il driver di registro con and. `awsfirelens` FireLens Fluent Bit Fluent Bitè un processore di log leggero, efficiente in termini di risorse e in grado di gestire milioni di record di log. Tuttavia, per ottenere prestazioni ottimali su larga scala è necessario ottimizzarne la configurazione.

Questa sezione illustra le tecniche di Fluent Bit ottimizzazione avanzate per gestire un elevato throughput di log, mantenendo al contempo la stabilità del sistema e garantendo l'assenza di perdita di dati.

Per informazioni su come utilizzare i file di configurazione personalizzati con FireLens, vedere[Utilizzo di un file di configurazione personalizzato](firelens-taskdef.md#firelens-taskdef-customconfig). Per ulteriori esempi, consulta gli [ FireLens esempi di Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) su GitHub.

**Nota**  
Alcune opzioni di configurazione in questa sezione, come `workers` e`threaded`, richiedono AWS la Fluent Bit versione 3 o successiva. Per informazioni sulle versioni disponibili, vedere le versioni [AWS di Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases).

## Comprendere i blocchi
<a name="firelens-understanding-chunks"></a>

Fluent Bit*elabora i dati in unità chiamate blocchi.* Quando un plug-in INPUT riceve dati, il motore crea un blocco che viene archiviato in memoria o sul filesystem prima di essere inviato alle destinazioni OUTPUT.

Il comportamento del buffering dipende dall'`storage.type`impostazione nelle sezioni INPUT. Per impostazione predefinita, Fluent Bit utilizza il buffering della memoria. Per scenari di produzione o ad alta velocità, il buffering del file system offre una migliore resilienza.

[Per ulteriori informazioni, consulta [Chunks nella documentazione e What is a Chunk](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks)? Fluent Bit](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) nel repository AWS for examplesFluent Bit.

## Buffering della memoria (impostazione predefinita)
<a name="firelens-memory-buffering"></a>

Per impostazione predefinita, Fluent Bit utilizza il buffering della memoria ()`storage.type memory`. È possibile limitare l'utilizzo della memoria per il plug-in INPUT utilizzando il `Mem_Buf_Limit` parametro.

L'esempio seguente mostra una configurazione di input con buffer di memoria:

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

**Importante**  
Quando `Mem_Buf_Limit` viene superato per un plugin, mette in Fluent Bit pausa l'input e i nuovi record vengono persi. Ciò può causare una contropressione e rallentare l'applicazione. Nei Fluent Bit registri viene visualizzato il seguente avviso:  

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

Il buffering della memoria è adatto per casi d'uso semplici con una velocità di trasmissione dei log da bassa a moderata. Per scenari ad alta produttività o di produzione in cui la perdita di dati è un problema, utilizzate invece il buffering del file system.

Per ulteriori informazioni, vedere [Buffering and Memory nella Fluent Bit documentazione e Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) [Buffering](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) Only nel repository for examples. AWS Fluent Bit

## Buffering del file system
<a name="firelens-filesystem-buffering"></a>

Per scenari con throughput elevato, consigliamo di utilizzare il buffering del file system. [Per ulteriori informazioni su come Fluent Bit gestire il buffering e lo storage, consulta Buffering and Storage nella documentazione.](https://docs.fluentbit.io/manual/administration/buffering-and-storage) Fluent Bit

Il buffering del file system offre i seguenti vantaggi:
+ **Maggiore capacità del buffer**: lo spazio su disco è in genere più abbondante della memoria.
+ **Persistenza**: i dati memorizzati nel buffer sopravvivono ai riavvii. Fluent Bit
+ **Degrado graduale: in caso di errori di** output, i dati si accumulano sul disco anziché causare l'esaurimento della memoria.

Per abilitare il buffering del file system, fornite un file di configurazione personalizzato. Fluent Bit L'esempio seguente mostra la configurazione consigliata:

```
[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
```

Parametri di configurazione chiave:

`storage.path`  
La directory in cui Fluent Bit memorizza i blocchi bufferizzati sul disco.

`storage.backlog.flush_on_shutdown`  
Se abilitata, Fluent Bit tenta di riportare tutti i blocchi del file system backlog verso le rispettive destinazioni durante l'arresto. Ciò aiuta a garantire la consegna dei dati prima delle interruzioni, ma può aumentare i tempi di spegnimento. Fluent Bit

`storage.max_chunks_up`  
Il numero di blocchi che rimangono in memoria. L'impostazione predefinita è 128 blocchi, che possono consumare più di 500 MB di memoria perché ogni blocco può utilizzare fino a 4-5 MB. In ambienti con limiti di memoria, riduci questo valore. Ad esempio, se hai a disposizione 50 MB per il buffering, impostalo su 8-10 blocchi.

`storage.type filesystem`  
Abilita l'archiviazione del filesystem per il plug-in di input. Nonostante il nome, Fluent Bit viene utilizzato `mmap` per mappare blocchi sia sulla memoria che sul disco, garantendo la persistenza senza compromettere le prestazioni.

`storage.total_limit_size`  
Lo spazio massimo su disco per i dati memorizzati nel buffer per uno specifico plug-in OUTPUT. Quando viene raggiunto questo limite, i record più vecchi relativi a quell'output vengono eliminati. Per ulteriori informazioni sul dimensionamento, vedere[Comprendere `storage.total_limit_size`](#firelens-storage-sizing).

`threaded true`  
Esegue l'input nel proprio thread, separato dal ciclo Fluent Bit di eventi principale. Ciò impedisce che gli input lenti blocchino l'intera pipeline.

Per ulteriori informazioni, vedere [Filesystem Buffering nella Fluent Bit documentazione e [Filesystem](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) and Memory Buffering](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) nel repository for examples. AWS Fluent Bit

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

Il `storage.total_limit_size` parametro su ogni plugin OUTPUT controlla lo spazio massimo su disco per i dati memorizzati nel buffer per quell'output. Quando viene raggiunto questo limite, i record più vecchi relativi a quell'output vengono eliminati per fare spazio a nuovi dati. Quando lo spazio su disco è completamente esaurito, i record Fluent Bit non vengono messi in coda e vengono persi.

Utilizzate la formula seguente per calcolare quella appropriata in `storage.total_limit_size` base alla frequenza di registro e alla finestra di ripristino desiderata:

```
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)
```

La tabella seguente mostra esempi di calcoli per le frequenze di registro e le finestre di ripristino comuni:


| Frequenza di registro | 1 ora | 6 ore | 12 ore | 24 ore | 
| --- | --- | --- | --- | --- | 
| 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 | 

[Per osservare il rendimento di picco e scegliere le dimensioni del buffer appropriate, utilizzate il campione di misurazione della produttività. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)

Utilizzate la formula, i calcoli di esempio e l'analisi comparativa per scegliere un modello adatto `storage.total_limit_size` che fornisca la pista ideale per un recupero ottimale durante un'interruzione.

## Requisiti di archiviazione delle attività di Amazon ECS
<a name="firelens-storage-task-requirements"></a>

Somma tutti i `storage.total_limit_size` valori nelle sezioni OUTPUT e aggiungi il buffer per il sovraccarico. Questo totale determina lo spazio di archiviazione necessario nella definizione delle attività di Amazon ECS. Ad esempio, 3 uscite × 10 GB ciascuna = 30 GB\$1 buffer (5-10 GB) = 35-40 GB totali richiesti. Se il totale supera lo spazio di archiviazione disponibile, è possibile che i record non Fluent Bit vengano messi in coda e che vadano persi.

Sono disponibili le seguenti opzioni di archiviazione:

Bind mount (archiviazione temporanea)  
+ Per AWS Fargate, l'impostazione predefinita è 20 GB di spazio di archiviazione temporaneo (massimo 200 GB). Configurare l'utilizzo `ephemeralStorage` nella definizione dell'attività. Per ulteriori informazioni, consulta [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) nella *Guida per l'utente di AWS CloudFormation *.
+ Per EC2, l'impostazione predefinita è 30 GB quando si utilizza l'AMI ottimizzata per Amazon ECS (condivisa tra il sistema operativo e Docker). Aumenta modificando la dimensione del volume principale.

Volumi Amazon EBS  
+ Fornisce storage a blocchi ad alta disponibilità, duraturo e ad alte prestazioni.
+ Richiede la configurazione del volume e `mountPoint` nella definizione dell'attività indica `storage.path` (impostazione predefinita:`/var/log/flb-storage/`).
+ Per ulteriori informazioni, consulta [Rimanda la configurazione del volume all'ora di avvio nella definizione di un'attività di Amazon ECS](specify-ebs-config.md).

Volumi Amazon EFS  
+ Fornisce uno storage di file semplice e scalabile.
+ Richiede la configurazione del volume e `mountPoint` nella definizione dell'attività l'indicazione `storage.path` (impostazione predefinita:`/var/log/flb-storage/`).
+ Per ulteriori informazioni, consulta [Specificare di un file system Amazon EFS nella definizione di un'attività Amazon ECS](specify-efs-config.md).

Per ulteriori informazioni sui volumi di dati, vedere[Opzioni di archiviazione per le attività di Amazon ECS](using_data_volumes.md).

## Ottimizza la configurazione dell'output
<a name="firelens-output-optimization"></a>

Problemi di rete, interruzioni del servizio e limitazione della destinazione possono impedire la consegna dei log. Una corretta configurazione dell'output garantisce la resilienza senza perdita di dati.

Quando un flusso di uscita fallisce, è Fluent Bit possibile riprovare l'operazione. I seguenti parametri controllano il comportamento dei tentativi di ripetizione:

`retry_limit`  
Il numero massimo di tentativi dopo il tentativo iniziale prima di eliminare i record. Il valore di default è 1. Ad esempio, `retry_limit 3` significa 4 tentativi totali (1 tentativo iniziale\$13 tentativi). Per gli ambienti di produzione, ne consigliamo 15 o più, che coprono diversi minuti di interruzione con un backoff esponenziale.  
Impostato su `no_limits` o per un numero infinito di tentativi`False`:  
+ Con il buffering della memoria, infiniti tentativi fanno sì che il plugin di input si interrompa quando vengono raggiunti i limiti di memoria.
+ Con il buffering del filesystem, i record più vecchi vengono eliminati quando vengono raggiunti. `storage.total_limit_size`
Dopo aver esaurito tutti i tentativi (1 tentativo iniziale \$1), i record vengono `retry_limit` eliminati. AWS i plugin con `auto_retry_requests true` (impostazione predefinita) forniscono un livello di riprova aggiuntivo prima del meccanismo di ritentativo. Fluent Bit Per ulteriori informazioni, consulta [Configurare i tentativi](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) nella documentazione. Fluent Bit  
Ad esempio, `retry_limit 3` con le impostazioni predefinite (`scheduler.base 5`,`scheduler.cap 2000`,`net.connect_timeout 10s`) fornisce circa 70 secondi di tempo di attesa dello scheduler (10s \$1 20s \$1 40 s), 40 secondi di timeout di connessione di rete (4 tentativi × 10 secondi), più nuovi tentativi di AWS plug-in, per un totale di circa 2-10 minuti a seconda delle condizioni di rete e dei timeout TCP del sistema operativo.

`scheduler.base`  
I secondi base tra i tentativi (impostazione predefinita: 5). Consigliamo 10 secondi.

`scheduler.cap`  
Il numero massimo di secondi tra un tentativo e l'altro (impostazione predefinita: 2000). Consigliamo 60 secondi.

Il tempo di attesa tra un tentativo e l'altro utilizza il backoff esponenziale con jitter:

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

Ad esempio, con e: `scheduler.base 10` `scheduler.cap 60`
+ Primo tentativo: attesa casuale tra 10 e 20 secondi
+ Secondo tentativo: attesa casuale tra 10 e 40 secondi
+ Terzo tentativo e successivo: attesa casuale compresa tra 10 e 60 secondi (limite)

[Per ulteriori informazioni, consulta [Configurazione del tempo di attesa per un nuovo tentativo e Rete](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) nella documentazione.](https://docs.fluentbit.io/manual/administration/networking) Fluent Bit

`workers`  
Il numero di thread per l'elaborazione parallela dell'output. Più operatori consentono lavaggi simultanei, migliorando la produttività quando si elaborano più blocchi.

`auto_retry_requests`  
Un'impostazione AWS specifica del plug-in che fornisce un livello di riprova aggiuntivo prima del meccanismo di ritentativo integrato. Fluent Bit Il valore predefinito è `true`. Se abilitato, il plugin AWS di output riprova internamente le richieste non riuscite prima che la richiesta venga considerata fallita e soggetta alla configurazione. `retry_limit`

Il `Grace` parametro nella `[SERVICE]` sezione imposta il tempo di Fluent Bit attesa durante l'arresto per lo svuotamento dei dati memorizzati nel buffer. Il `Grace` periodo deve essere coordinato con quello del contenitore. `stopTimeout` Assicurarsi che `stopTimeout` superi il `Grace` periodo di tempo necessario per consentire il Fluent Bit completamento del lavaggio prima del ricevimento. `SIGKILL` Ad esempio, se `Grace` è 120 secondi, impostato su `stopTimeout` 150 secondi.

L'esempio seguente mostra una Fluent Bit configurazione completa con tutte le impostazioni consigliate per scenari con throughput elevato:

```
[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
```

## Comprensione degli scenari di perdita di dati
<a name="firelens-record-loss-scenarios"></a>

I record possono andare persi durante interruzioni prolungate o problemi con le destinazioni di output. Le raccomandazioni di configurazione contenute in questa guida rappresentano gli approcci migliori per ridurre al minimo la perdita di dati, ma non possono garantire l'assenza di perdite in caso di guasti prolungati. La comprensione di questi scenari aiuta a configurare Fluent Bit per massimizzare la resilienza.

I record possono essere persi in due modi: i record più vecchi vengono eliminati quando lo spazio di archiviazione si esaurisce, oppure i record più recenti vengono rifiutati quando il sistema non può accettare più dati.

### I record più vecchi vengono eliminati
<a name="firelens-record-loss-oldest-dropped"></a>

I record memorizzati nel buffer più vecchi vengono eliminati quando i tentativi di riprova sono esauriti o quando `storage.total_limit_size` si esaurisce e occorre fare spazio a nuovi dati.

Limite di tentativi superato  
Si verifica dopo un nuovo tentativo del AWS plug-in (se`auto_retry_requests true`) più 1 Fluent Bit tentativo iniziale più nuovi tentativi. `retry_limit` Per mitigare la situazione, impostate un numero infinito di `retry_limit no_limits` tentativi per ogni plugin OUTPUT:  

```
[OUTPUT]
    Name                        cloudwatch_logs
    Match                       ApplicationLogs
    retry_limit                 no_limits
    auto_retry_requests         true
```
I tentativi infiniti impediscono la perdita dei record a causa dell'esaurimento dei tentativi, ma possono causare il riempimento. `storage.total_limit_size`

Limite di archiviazione raggiunto (buffering del file system)  
Si verifica quando la destinazione di output non è disponibile per un periodo superiore al buffer CAN configurato. `storage.total_limit_size` Ad esempio, un buffer da 10 GB a una frequenza di MB/s registro fornisce circa 2,7 ore di buffering. Per mitigare, aumenta `storage.total_limit_size` per ogni plug-in OUTPUT e fornisci uno spazio di archiviazione delle attività Amazon ECS adeguato:  

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

### Record più recenti rifiutati
<a name="firelens-record-loss-newest-rejected"></a>

I record più recenti vengono eliminati quando lo spazio su disco è esaurito o quando l'input viene sospeso a causa di. `Mem_Buf_Limit`

Spazio su disco esaurito (buffering del file system)  
Si verifica quando lo spazio su disco è completamente esaurito. Fluent Bitnon riesce a mettere in coda i nuovi record e questi vengono persi. Per mitigare, somma tutti i `storage.total_limit_size` valori e fornisci uno storage di attività Amazon ECS adeguato. Per ulteriori informazioni, consulta [Requisiti di archiviazione delle attività di Amazon ECS](#firelens-storage-task-requirements).

Limite di memoria raggiunto (buffering della memoria)  
Si verifica quando la destinazione di output non è disponibile e il buffer di memoria si riempie. I plugin di input in pausa smettono di accettare nuovi record. Per mitigare, usali `storage.type filesystem` per una migliore resilienza o per aumentare. `Mem_Buf_Limit`

### Le migliori pratiche per ridurre al minimo la perdita di dati
<a name="firelens-record-loss-best-practices"></a>

Prendi in considerazione le seguenti best practice per ridurre al minimo la perdita di dati:
+ **Usa il buffering del file system: impostato `storage.type filesystem` per una migliore resilienza durante** le interruzioni.
+ **Dimensioni dello storage appropriate**: calcola in `storage.total_limit_size` base alla frequenza di registro e alla finestra di ripristino desiderata.
+ Esegui il **provisioning di un disco adeguato**: assicurati che l'attività Amazon ECS disponga di uno storage temporaneo sufficiente, Amazon EBS o Amazon EFS.
+ **Configura il comportamento dei tentativi**: equilibrio tra `retry_limit` (elimina i record dopo aver esaurito i tentativi) e (riprova all'infinito ma può riempire lo spazio di archiviazione`no_limits`).

## Utilizza la registrazione a più destinazioni per garantire l'affidabilità
<a name="firelens-multi-destination"></a>

L'invio di registri a più destinazioni elimina i singoli punti di errore. Ad esempio, se CloudWatch Logs subisce un'interruzione, i log continuano a raggiungere Amazon S3.

La registrazione multidestinazione offre i seguenti vantaggi. Il plug-in di output Amazon S3 supporta anche opzioni di compressione come gzip e il formato Parquet, che possono ridurre i costi di archiviazione. Per ulteriori informazioni, consulta la sezione [Compressione S3 nella documentazione.](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) Fluent Bit

La registrazione multidestinazione può offrire i seguenti vantaggi:
+ **Ridondanza**: se una destinazione fallisce, i log raggiungono comunque l'altra.
+ **Ripristino**: ricostruisci le lacune in un sistema rispetto all'altro.
+ **Durabilità**: archivia i log in Amazon S3 per la conservazione a lungo termine.
+ **Ottimizzazione dei costi**: conserva i log recenti in un servizio di query veloce come CloudWatch Logs con conservazione più breve, mentre archivia tutti i log su uno storage Amazon S3 a basso costo per una conservazione a lungo termine.

La seguente Fluent Bit configurazione invia i log sia a Logs che ad CloudWatch 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
```

Entrambi gli output utilizzano lo stesso `Match *` schema, quindi tutti i record vengono inviati a entrambe le destinazioni in modo indipendente. Durante l'interruzione di una destinazione, i log continuano a fluire verso l'altra, mentre i flush non riusciti si accumulano nel buffer del file system per riprovare in un secondo momento.

## Usa la registrazione basata su file con il plugin tail input
<a name="firelens-tail-input"></a>

Per scenari ad alta velocità in cui la perdita di log è un problema fondamentale, puoi utilizzare un approccio alternativo: fare in modo che l'applicazione scriva i log sui file su disco e configuri Fluent Bit per leggerli utilizzando il plug-in di input. `tail` Questo approccio aggira completamente il livello dei driver di registrazione Docker.

La registrazione basata su file con il plugin tail offre i seguenti vantaggi:
+ **Tracciamento degli offset**: il plug-in tail può memorizzare gli offset dei file in un file di database (utilizzando l'`DB`opzione), garantendo la durabilità durante i riavvii. Fluent Bit Questo aiuta a prevenire la perdita di log durante il riavvio del contenitore.
+ **Buffering a livello di input**: è possibile configurare i limiti del buffer di memoria direttamente sul plug-in di input utilizzando, in questo modo`Mem_Buf_Limit`, un controllo più granulare sull'utilizzo della memoria.
+ **Evita il sovraccarico di Docker**: i log passano direttamente dal file all'altro senza passare attraverso i buffer di registro di Docker. Fluent Bit

Per utilizzare questo approccio, l'applicazione deve scrivere i log nei file anziché. `stdout` Sia il contenitore dell'applicazione che il Fluent Bit contenitore montano un volume condiviso in cui sono archiviati i file di registro.

L'esempio seguente mostra una configurazione di input di tipo tail con le migliori pratiche:

```
[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
```

Quando usi il plugin tail input, considera quanto segue:
+ Implementate la rotazione dei log per i log delle applicazioni per prevenire l'esaurimento del disco. Monitora le metriche di volume sottostanti per valutare le prestazioni.
+ Prendi in considerazione impostazioni come `Ignore_Older``Read_from_Head`, e parser multilinea in base al formato del registro.

Per ulteriori informazioni, consulta [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail) nella Fluent Bit documentazione. Per le migliori pratiche, consulta [Tail config with best practice](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) nella guida AWS per la Fluent Bit risoluzione dei problemi.

## Accedi direttamente a FireLens
<a name="firelens-environment-variables"></a>

Quando il driver di log `awsfirelens` è specificato in una definizione di attività, l'agente Amazon ECS inserisce le seguenti variabili di ambiente nel container:

`FLUENT_HOST`  
L'indirizzo IP assegnato al FireLens contenitore.  
Se utilizzi EC2 con la modalità di `bridge` rete, la variabile di `FLUENT_HOST` ambiente nel contenitore dell'applicazione può diventare imprecisa dopo il riavvio del contenitore del FireLens log router (il contenitore con l'`firelensConfiguration`oggetto nella definizione del contenitore). Questo perché `FLUENT_HOST` è un indirizzo IP dinamico e può cambiare dopo un riavvio. La registrazione diretta dal container dell'applicazione all'indirizzo IP `FLUENT_HOST` può iniziare a fallire dopo la modifica dell'indirizzo. Per ulteriori informazioni sul riavvio di singoli container, consultare [Riavviare singoli container nelle attività Amazon ECS con policy di riavvio dei container](container-restart-policy.md).

`FLUENT_PORT`  
La porta su cui il protocollo Fluent Forward è in ascolto.

Puoi utilizzare queste variabili di ambiente per accedere direttamente al Fluent Bit log router dal codice dell'applicazione utilizzando il protocollo Fluent Forward, anziché scrivere su. `stdout` Questo approccio aggira il livello dei driver di registrazione Docker, che offre i seguenti vantaggi:
+ **Latenza inferiore**: i log vengono inviati direttamente all'infrastruttura di registrazione di Docker Fluent Bit senza passare attraverso l'infrastruttura di registrazione.
+ **Registrazione strutturata: invia dati di** registro strutturati in modo nativo senza sovraccarico di codifica JSON.
+ **Controllo migliore**: l'applicazione può implementare la propria logica di buffering e gestione degli errori.

Le seguenti librerie di logger Fluent supportano il protocollo Fluent Forward e possono essere utilizzate per inviare i log direttamente a: 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)

## Configura il limite del buffer Docker
<a name="firelens-buffer-limit"></a>

Quando si crea una definizione di attività, è possibile specificare il numero di righe di registro memorizzate nel buffer in memoria specificando il valore in. `log-driver-buffer-limit` Questo controlla il buffer tra Docker e. Fluent Bit Per ulteriori informazioni, consulta la pagina [Driver di registro di Fluentd](https://docs.docker.com/engine/logging/drivers/fluentd/) nella documentazione Docker.

Utilizza questa opzione in caso di velocità di trasmissione effettiva elevata, perché Docker potrebbe esaurire la memoria buffer e scartare i messaggi buffer in modo da poter aggiungere nuovi messaggi.

Considerate quanto segue quando utilizzate questa opzione:
+ Questa opzione è supportata nei tipi EC2 e Fargate con versione della piattaforma `1.4.0` o successiva.
+ L'opzione è valida solo quando `logDriver` è impostato su `awsfirelens`.
+ Il limite di buffer di default è `1048576` righe di log.
+ Il limite del buffer deve essere maggiore o uguale a `0` e inferiore a `536870912` righe di log.
+ La quantità massima di memoria utilizzata per questo buffer è il prodotto della dimensione di ogni riga di log e della dimensione del buffer. Ad esempio, se le righe di registro dell'applicazione sono in media `2` KB, un limite di buffer di 4096 utilizzerebbe al massimo `8` MiB. La quantità totale di memoria allocata a livello di attività deve essere superiore a quella allocata per tutti i container oltre al driver di log del buffer di memoria.

La seguente definizione di attività mostra come configurare: `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 per gli archivi di Fluent Bit immagini per Amazon ECS
<a name="firelens-using-fluentbit"></a>

AWS fornisce un'Fluent Bitimmagine con i plugin sia per CloudWatch Logs che per Firehose. Si consiglia di utilizzare Fluent Bit come router di log perché dispone di un tasso di utilizzo delle risorse inferiore a Fluentd. Per ulteriori informazioni, consulta [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) e [Amazon Kinesis Firehose](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) for Fluent Bit.

L'immagine **AWS per Fluent Bit** è disponibile su Amazon ECR sia nella Amazon ECR Public Gallery che in un repository Amazon ECR per l'alta disponibilità.

## Galleria pubblica di Amazon ECR
<a name="firelens-image-ecrpublic"></a>

L'Fluent Bitimmagine AWS per è disponibile nella Amazon ECR Public Gallery. Questa è la posizione consigliata per scaricare l'Fluent Bitimmagine AWS for perché è un archivio pubblico e può essere utilizzato da tutti. Regioni AWS Per ulteriori informazioni, consulta la [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>

L'Fluent Bitimmagine AWS for nella galleria pubblica di Amazon ECR supporta il sistema operativo Amazon Linux con `x86-64` architettura `ARM64` or.

Puoi estrarre l'Fluent Bitimmagine AWS for dalla Amazon ECR Public Gallery specificando l'URL del repository con il tag immagine desiderato. I tag immagine disponibili sono disponibili nella scheda **Tag immagine** nella galleria pubblica di Amazon ECR.

Di seguito è mostrata la sintassi da utilizzare per la CLI di Docker.

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

Ad esempio, puoi estrarre l'immagine più recente della famiglia «3.x» di AWS quattro Fluent Bit versioni utilizzando questo comando CLI Docker.

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

**Nota**  
I pull non autenticati sono consentiti, ma hanno un limite di velocità inferiore rispetto ai pull autenticati. Per autenticarti utilizzando il tuo AWS account prima di estrarlo, usa il seguente comando.  

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

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

Oltre alle Fluent Bit versioni AWS for esistenti`2.x`, AWS for Fluent Bit supporta una nuova versione principale. `3.x` La nuova versione principale include l'aggiornamento delle immagini da Amazon Linux 2 ad Amazon Linux 2023 e dalla Fluent Bit versione `1.9.10` a. `4.1.1` Per ulteriori informazioni, consulta il [Fluent Bitrepository AWS for](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) su. GitHub

Gli esempi seguenti mostrano i tag aggiornati AWS per Fluent Bit `3.x` le immagini:

È possibile utilizzare tag multiarchitettura per l'Fluent Bitimmagine AWS for.

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

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

L'Fluent Bitimmagine AWS for nella Amazon ECR Public Gallery supporta l'`AMD64`architettura con i seguenti sistemi operativi:
+ Windows Server 2022 Full
+ Windows Server 2022 Core
+ Windows Server 2019 Full
+ Windows Server 2019 Core

I contenitori Windows che si trovano su AWS Fargate non supportano. FireLens

Puoi estrarre l'Fluent Bitimmagine AWS for dalla Amazon ECR Public Gallery specificando l'URL del repository con il tag immagine desiderato. I tag immagine disponibili sono disponibili nella scheda **Tag immagine** nella galleria pubblica di Amazon ECR.

Di seguito è mostrata la sintassi da utilizzare per la CLI di Docker.

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

Ad esempio, puoi estrarre la più recente stable AWS for Fluent Bit image usando questo comando Docker CLI.

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

**Nota**  
I pull non autenticati sono consentiti, ma hanno un limite di velocità inferiore rispetto ai pull autenticati. Per autenticarti utilizzando il tuo AWS account prima di estrarlo, usa il seguente comando.  

```
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>

L'immagine AWS for Fluent Bit è disponibile su Amazon ECR per un'elevata disponibilità. I seguenti comandi possono essere utilizzati per recuperare un'immagine URIs e stabilire la disponibilità dell'immagine in una determinata area. Regione AWS

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

L'ultima versione stabile AWS dell'URI dell'immagine Fluent Bit può essere recuperata utilizzando il seguente comando.

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

Tutte le versioni dell'immagine AWS for Fluent Bit possono essere elencate utilizzando il comando seguente per interrogare il parametro Systems Manager Parameter Store.

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

È possibile fare riferimento all'immagine stabile più recente AWS per Fluent Bit in un CloudFormation modello facendo riferimento al nome dell'archivio dei parametri di Systems Manager. Di seguito è riportato un esempio:

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

**Nota**  
Se il comando fallisce o non viene generato alcun output, l'immagine non è disponibile nella cartella Regione AWS in cui viene chiamato il comando.

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

L'ultima versione stabile dell'URI AWS di immagine Fluent Bit può essere recuperata utilizzando il seguente comando.

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

Tutte le versioni dell'immagine AWS for Fluent Bit possono essere elencate utilizzando il comando seguente per interrogare il parametro Systems Manager Parameter Store.

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

È possibile fare riferimento all'ultima immagine stabile AWS per Fluent Bit in un CloudFormation modello facendo riferimento al nome dell'archivio dei parametri di Systems Manager. Di seguito è riportato un esempio:

```
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
```

# Esempio di definizione dell'attività Amazon ECS: indirizzare i log a FireLens
<a name="firelens-taskdef"></a>

Per utilizzare il routing di log personalizzato con FireLens, è necessario specificare quanto segue nella definizione di attività:
+ Un container router di log contenente una configurazione FireLens. Si consiglia di contrassegnare il container come `essential`.
+ Uno o più container dell'applicazione contenenti una configurazione del log che specifica il driver di log `awsfirelens`.
+ Un nome della risorsa Amazon (ARN) del ruolo IAM dell'attività contenente le autorizzazioni richieste dall'attività per instradare i log.

Quando si crea una nuova definizione di attività utilizzando il Console di gestione AWS, è disponibile una sezione di FireLens integrazione che semplifica l'aggiunta di un contenitore di log router. Per ulteriori informazioni, consulta [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md).

Amazon ECS converte la configurazione del log e genera la configurazione di output Fluentd o Fluent Bit. La configurazione di output è montata nel container di routing dei log in corrispondenza di `/fluent-bit/etc/fluent-bit.conf` for Fluent Bit e `/fluentd/etc/fluent.conf` for Fluentd.

**Importante**  
FireLens è in ascolto sulla porta `24224`. Pertanto, per garantire che il FireLens log router non sia raggiungibile al di fuori dell'operazione, non è necessario consentire il traffico `24224` in ingresso sulla porta del gruppo di sicurezza utilizzato dall'attività. Per attività che utilizzano la modalità di rete `awsvpc`, questo è il gruppo di sicurezza associato all'attività. Per attività che utilizzano la modalità di rete `host`, questo è il gruppo di sicurezza associato all'istanza Amazon EC2 che ospita l'attività. Per attività che utilizzano la modalità di rete `bridge`, non creare mappature di porte che utilizzano la porta `24224`.

Di default, Amazon ECS aggiunge ulteriori campi nelle voci di log che consentono di identificare l'origine dei log. 
+ `ecs_cluster`: il nome del cluster di cui fa parte il processo.
+ `ecs_task_arn`: il nome della risorsa Amazon (ARN) completo dell'attività a cui appartiene il container.
+ `ecs_task_definition`: il nome della definizione di attività e la revisione che il processo sta utilizzando.
+ `ec2_instance_id`: l'ID dell'istanza Amazon EC2 su cui il container è ospitato. Questo campo è valido solo per processi che utilizzano il tipo di avvio EC2.

È possibile impostare `enable-ecs-log-metadata` su `false` se non si desiderano i metadati.

Il seguente esempio di definizione di attività definisce un contenitore di log router che utilizza Fluent Bit per indirizzare i log verso Logs. CloudWatch Definisce inoltre un container di applicazioni che utilizza una configurazione di log per instradare i log ad Amazon Data Firehose e imposta la memoria usata per il buffer degli eventi a 2 MiB.

**Nota**  
Per ulteriori esempi di definizioni di attività, consulta gli [ FireLensesempi di Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) su 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
    }
  ]
}
```

Le coppie chiave/valore specificate come opzioni nell'oggetto `logConfiguration` vengono utilizzate per generare la configurazione di output Fluentd o Fluent Bit. Di seguito è riportato un esempio di codice da una definizione di output Fluent Bit.

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

**Nota**  
FireLens gestisce la `match` configurazione. Non specificare la configurazione `match` nella definizione dell'attività. 

## Utilizzo di un file di configurazione personalizzato
<a name="firelens-taskdef-customconfig"></a>

È possibile utilizzare un file di configurazione personalizzato. Il formato del file di configurazione è il formato nativo per il router di log in uso. Per ulteriori informazioni, consultare [Fluentd Config File Syntax](https://docs.fluentd.org/configuration/config-file) e [YAML Configuration](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml).

Nel file di configurazione personalizzato, per le attività che utilizzano la modalità di rete `bridge` o `awsvpc`, non è necessario impostare un input di inoltro Fluentd o Fluent Bit su TCP perché FireLens lo aggiunge alla configurazione di input.

La configurazione di FireLens deve contenere le seguenti opzioni per specificare un file di configurazione personalizzato:

`config-file-type`  
Il percorso di origine del file di configurazione personalizzato. Le opzioni disponibili sono `s3` o `file`.  
Le attività ospitate su supportano AWS Fargate solo il tipo `file` di file di configurazione. Tuttavia, puoi utilizzare i file di configurazione ospitati in Amazon S3 su AWS Fargate utilizzando il AWS contenitore for init. Fluent Bit Per ulteriori informazioni, consulta [Processo di inizializzazione per Fluent Bit su ECS, supporto multi-config su](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub

`config-file-value`  
L'origine del file di configurazione personalizzato. Se viene utilizzato il tipo di file di configurazione `s3`, il valore del file di configurazione è l'ARN completo del file e del bucket Amazon S3. Se viene utilizzato il tipo di file di configurazione `file`, il valore del file di configurazione è il percorso completo del file di configurazione presente nell'immagine del container o in un volume montato nel container.  
Quando si utilizza un file di configurazione personalizzato, è necessario specificare un percorso diverso da quello utilizzato da FireLens. Amazon ECS riserva il percorso file `/fluent-bit/etc/fluent-bit.conf` for Fluent Bit e `/fluentd/etc/fluent.conf` for Fluentd.

L'esempio seguente mostra la sintassi richiesta quando si specifica una configurazione personalizzata.

**Importante**  
Per specificare un file di configurazione personalizzato ospitato in Amazon S3, assicurati di aver creato un ruolo IAM di esecuzione dell'attività con le autorizzazioni appropriate. 

Di seguito viene illustrata la sintassi richiesta quando si specifica una configurazione personalizzata.

```
{
  "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"
        }
      }
    }
  ]
}
```

**Nota**  
Le attività ospitate su supportano AWS Fargate solo il tipo di file di configurazione. `file` Tuttavia, puoi utilizzare i file di configurazione ospitati in Amazon S3 su AWS Fargate utilizzando il AWS contenitore for init. Fluent Bit Per ulteriori informazioni, consulta [Processo di inizializzazione per Fluent Bit su ECS, supporto multi-config su](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub

# Utilizzo di immagini non AWS containerizzate in Amazon ECS
<a name="private-auth"></a>

Utilizzate il registro privato per memorizzare le vostre credenziali e Gestione dei segreti AWS quindi fate riferimento ad esse nella definizione dell'attività. In questo modo è possibile fare riferimento alle immagini dei contenitori presenti in registri privati AWS che non richiedono l'autenticazione nelle definizioni delle attività. Questa funzionalità è supportata da processi ospitati su istanze Fargate, Amazon EC2 e istanze esterne che utilizzano Amazon ECS Anywhere.

**Importante**  
Le informazioni di questo argomento non sono applicabili se la definizione di attività fa riferimento a un'immagine memorizzata in Amazon ECR. Per ulteriori informazioni, consulta [Utilizzo di immagini Amazon ECR con Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) nella *Guida per l'utente di Amazon Elastic Container Registry*.

Per le attività ospitate su istanze Amazon EC2, questa funzione richiede la versione `1.19.0` o successiva dell'agente del container. Tuttavia, ti consigliamo di utilizzare la versione più recente dell’agente container. Per informazioni sulla verifica della versione dell'agente e sull'aggiornamento alla versione più recente, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

Per i processi ospitati su Fargate, questa funzione richiede la versione `1.2.0`o successiva della piattaforma. Per informazioni, consulta [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).

All'interno della definizione del container, specifica l'oggetto `repositoryCredentials` con i dettagli del segreto che hai creato. Il segreto a cui si fa riferimento può provenire da un account diverso Regione AWS o diverso da quello dell'attività che lo utilizza.

**Nota**  
Quando utilizzi l'API o l' AWS SDK di Amazon ECS, se il segreto esiste nella Regione AWS stessa attività che stai avviando, puoi utilizzare l'ARN completo o il nome del segreto. AWS CLI Se il segreto esiste in un altro account, occorre specificare l'ARN completo del segreto. Quando si utilizza Console di gestione AWS, è necessario specificare sempre l'ARN completo del segreto.

Di seguito viene riportato un frammento di una definizione di attività che mostra i parametri obbligatori:

Sostituire i seguenti parametri:
+ *private-repo*con il nome host del repository privato 
+ *private-image*con il nome dell'immagine
+ *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name*con il nome segreto Amazon Resource Name (ARN)

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

**Nota**  
Un altro metodo per abilitare l'autenticazione di registri privati utilizza le variabili di ambiente dell'agente del container di Amazon ECS per effettuare l'autenticazione a registri privati. Questo metodo è supportato solo per i processi ospitati su istanze Amazon EC2. Per ulteriori informazioni, consulta [Configurare istanze di container Amazon ECS per immagini Docker private](private-auth-container-instances.md).

**Per utilizzare il registro privato**

1. La definizione dell'attività deve avere un ruolo per l'esecuzione dell'attività. In questo modo l'agente container può recuperare l'immagine del container. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione di attività Amazon ECS](task_execution_IAM_role.md).

   L'autenticazione del registro privato consente alle attività di Amazon ECS di estrarre immagini di container da registri privati esterni AWS (come Docker Hub, Quay.io o il tuo registro privato) che richiedono credenziali di autenticazione. Questa funzionalità utilizza Secrets Manager per archiviare in modo sicuro le credenziali del tuo registro, a cui viene poi fatto riferimento nella definizione dell'attività utilizzando il parametro `repositoryCredentials`.

   Per ulteriori informazioni sulla configurazione dell'autenticazione del registro privato, consulta [Utilizzo di immagini non AWS container in Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).

   Le autorizzazioni seguenti devono essere aggiunte manualmente come policy inline al ruolo per l'esecuzione di attività, per fornire l'accesso ai segreti che contengono credenziali del tuo registro privato. Per ulteriori informazioni, consulta [Aggiunta e rimozione delle policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
   + `secretsmanager:GetSecretValue`: necessario per recuperare le credenziali del registro privato da Secrets Manager.
   + `kms:Decrypt`: obbligatorio solo se il segreto utilizza una chiave KMS personalizzata e non quella di default. Il nome della risorsa Amazon (ARN) per la chiave personalizzata deve essere aggiunto come risorsa.

   Di seguito viene riportata una policy inline che aggiunge le autorizzazioni.

------
#### [ 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. Utilizzalo Gestione dei segreti AWS per creare un segreto per le credenziali del tuo registro privato. Per ulteriori informazioni sulla creazione di un segreto, consultare [Create an Gestione dei segreti AWS secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *.

   Inserire le credenziali del registro privato utilizzando il formato seguente:

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

1. Registra una definizione di attività. Per ulteriori informazioni, consulta [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md).

# Riavviare singoli container nelle attività Amazon ECS con policy di riavvio dei container
<a name="container-restart-policy"></a>

È possibile abilitare una politica di riavvio per ogni container essenziale e non essenziale indicato nella definizione dell'attività per superare più rapidamente i guasti temporanei e mantenere la disponibilità delle attività. Quando si abilita una politica di riavvio per un container, Amazon ECS può riavviare il container se esce, senza dover sostituire l'attività.

Per impostazione predefinita, le policy di riavvio non sono abilitate per i container. Quando abiliti una politica di riavvio per un container, è possibile specificare i codici di uscita in base ai quali il container non verrà riavviato. Questi possono essere codici di uscita che indicano l'esito positivo, come il codice di uscita `0`, che non richiede un riavvio. È inoltre possibile specificare per quanto tempo un container deve funzionare correttamente prima di tentare il riavvio. Per ulteriori informazioni su questi parametri, consultare [Politica di riavvio](task_definition_parameters.md#container_definition_restart_policy). Per un esempio di definizione dell'attività che specifica questi valori, vedere [Specifica di una politica di riavvio dei container in una definizione di attività Amazon ECS](container-restart-policy-example.md).

Puoi utilizzare l'endpoint dei metadati delle attività Amazon ECS o CloudWatch Container Insights per monitorare il numero di riavvii di un container. Per ulteriori informazioni sugli endpoint dei metadati dell'attività, consultare [Versione 4 degli endpoint dei metadati delle attività di Amazon ECS](task-metadata-endpoint-v4.md) e [Endpoint metadati delle attività Amazon ECS versione 4 per le attività su Fargate](task-metadata-endpoint-v4-fargate.md). *Per ulteriori informazioni sui parametri di Container Insights per Amazon ECS, consulta i parametri di [Amazon ECS Container Insights nella](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) Amazon User Guide. CloudWatch *

Le politiche di riavvio dei container sono supportate da attività ospitate su istanze Fargate, Amazon EC2 e istanze esterne che utilizzano Amazon ECS Anywhere.

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

Considera quanto segue prima di abilitare una politica di riavvio per il container:
+ Le politiche di riavvio non sono supportate per i container Windows su Fargate.
+ Per le attività ospitate su istanze Amazon EC2, questa funzione richiede la versione `1.86.0` o successiva dell'agente del container. Tuttavia, ti consigliamo di utilizzare la versione più recente dell’agente container. Per informazioni sulla verifica della versione dell'agente e sull'aggiornamento alla versione più recente, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).
+ Se utilizzi EC2 con la modalità di `bridge` rete, la variabile di `FLUENT_HOST` ambiente nel contenitore dell'applicazione può diventare imprecisa dopo il riavvio del contenitore del FireLens log router (il contenitore con l'`firelensConfiguration`oggetto nella definizione del contenitore). Questo perché `FLUENT_HOST` è un indirizzo IP dinamico e può cambiare dopo un riavvio. La registrazione diretta dal container dell'applicazione all'indirizzo IP `FLUENT_HOST` può iniziare a fallire dopo la modifica dell'indirizzo. Per ulteriori informazioni su `FLUENT_HOST`, consultare [Configurazione dei log di Amazon ECS per un throughput elevato](firelens-docker-buffer-limit.md).
+ L'agente Amazon ECS gestisce le politiche di riavvio dei container. Se per qualche motivo imprevisto l'agente Amazon ECS viene meno o non è più in esecuzione, il container non verrà riavviato.
+  Il periodo di tentativo di riavvio definito nella politica determina il periodo di tempo (in secondi) per cui il container deve essere eseguito prima che Amazon ECS riavvii un container.

# Specifica di una politica di riavvio dei container in una definizione di attività Amazon ECS
<a name="container-restart-policy-example"></a>

Per specificare una politica di riavvio per un container in una definizione di attività, specificare l'oggetto `restartPolicy` all'interno della definizione del container. Per ulteriori informazioni sull'oggetto `restartPolicy`, consultare [Politica di riavvio](task_definition_parameters.md#container_definition_restart_policy).

Di seguito è riportata una definizione di attività usando i container Linux su Fargate per configurare un server Web. La definizione del container include l'oggetto `restartPolicy`, con `enabled` su true per abilitare una politica di riavvio per il container. Il container deve funzionare per 180 secondi prima di poter essere riavviato e non verrà riavviato se esce con il codice di uscita `0`, che indica l'esito positivo.

```
{
  "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"]
}
```

Dopo aver registrato una definizione dell'attività con l'oggetto `restartPolicy` nella definizione di un container, puoi eseguire un'attività o creare un servizio con tale definizione dell'attività. Per ulteriori informazioni, consultare [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md) e [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md).

# Trasferimento di dati sensibili a un container Amazon ECS
<a name="specifying-sensitive-data"></a>

Puoi inviare in sicurezza dati sensibili, come le credenziali di un database, al tuo container. 

I segreti, come ad esempio chiavi API e credenziali di database, vengono spesso utilizzati dalle applicazioni per accedere ad altri sistemi. In molti casi sono costituiti da un nome utente e una password, un certificato o una chiave API. L'accesso a tali segreti dovrebbe essere limitati a principali IAM specifici che utilizzano IAM e inseriti nei container durante il runtime.

I segreti possono essere inseriti senza problemi nei contenitori da Gestione dei segreti AWS Amazon EC2 Systems Manager Parameter Store. È possibile fare riferimento a questi segreti nell'attività in qualsiasi dei modi seguenti.

1. Come variabili di ambiente che utilizzano il parametro di definizione di container `secrets`.

1. Come `secretOptions` se la piattaforma per la registrazione di log richiede l'autenticazione. Per ulteriori informazioni, consulta le [opzioni di configurazione della registrazione di log](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents).

1. Come segreti estratti da immagini che utilizzano il parametro di definizione di container `repositoryCredentials` se il registro da cui viene estratto il container richiede l'autenticazione. Utilizza questo metodo quando estrai immagini da Amazon ECR Public Gallery. Per ulteriori informazioni, consulta [Autenticazione del registro privato per le attività](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).

Consigliamo di completare la procedura seguente quando configuri la gestione dei segreti.

## Usa il Gestione dei segreti AWS nostro AWS Systems Manager Parameter Store per archiviare materiali segreti
<a name="security-secrets-management-recommendations-storing-secret-materials"></a>

È consigliabile archiviare in modo sicuro le chiavi API, le credenziali di database e altri materiali segreti in Secrets Manager o come parametri crittografati in Systems Manager Parameter Store Questi servizi sono simili perché sono entrambi archivi chiave-valore gestiti che vengono utilizzati AWS KMS per crittografare i dati sensibili. Tuttavia, Secrets Manager offre anche la possibilità di ruotare in automatico i segreti, di generare segreti casuali e di condividere i segreti tra account. Per utilizzare queste funzionalità, usa Secrets Manager. In caso contrario, utilizzare i parametri crittografati in Systems Manager Parameter Store.

**Importante**  
Se il segreto cambia, devi forzare una nuova implementazione o avviare una nuova attività per recuperare l'ultimo valore segreto. Per ulteriori informazioni, consulta i seguenti argomenti:  
Attività: interrompere l'attività, quindi avviarla. Per ulteriori informazioni, consultare [Interruzione di un'attività di Amazon ECS](standalone-task-stop.md) e [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md).
Servizio: aggiornare il servizio e utilizzare la nuova opzione di implementazione forzata. Per ulteriori informazioni, consultare [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).

## Recuperare i dati da un bucket Amazon S3 crittografato
<a name="security-secrets-management-recommendations-encrypted-s3-buckets"></a>

È consigliabile archiviare i segreti in un bucket Amazon S3 crittografato e utilizzare i ruoli di attività per limitare l'accesso a tali segreti. In questo modo si evita che i valori delle variabili di ambiente vengano inavvertitamente pubblicati nei log e rivelati durante l'esecuzione di `docker inspect`. Quando esegui questa operazione, l'applicazione deve essere scritta in modo tale da leggere il segreto dal bucket Amazon S3. Per ricevere istruzioni, consulta [Impostazione del comportamento predefinito della crittografia lato server per i bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html).

## Montaggio del segreto in un volume con un container sidecar
<a name="security-secrets-management-recommendations-mount-secret-volumes"></a>

Poiché esiste un rischio elevato di fuga di dati a causa delle variabili di ambiente, è consigliabile utilizzare un contenitore secondario che legga i segreti e li scriva su un volume condiviso. Gestione dei segreti AWS Questo container può essere eseguito e terminato prima del container dell'applicazione utilizzando l'[ordinamento di container Amazon di ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html). Quando esegui questa operazione, il container dell'applicazione monta successivamente il volume in cui il segreto è stato scritto. Analogamente al metodo bucket Amazon S3, l'applicazione deve essere scritta per leggere il segreto dal volume condiviso. Poiché il suo ambito è limitato all'attività, il volume viene eliminato in automatico dopo l'interruzione dell'attività. Per un esempio, consultare il progetto [task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json).

In Amazon EC2, il volume su cui il segreto viene scritto può essere crittografato con una chiave AWS KMS gestita dal cliente. Attivato AWS Fargate, lo storage di volumi viene crittografato automaticamente utilizzando una chiave gestita dal servizio. 

# Passare una singola variabile di ambiente a un container Amazon ECS
<a name="taskdef-envfiles"></a>

**Importante**  
Ti consigliamo di archiviare i dati sensibili nei parametri Gestione dei segreti AWS segreti o in AWS Systems Manager Parameter Store. Per ulteriori informazioni, consulta [Trasferimento di dati sensibili a un container Amazon ECS](specifying-sensitive-data.md).  
Le variabili di ambiente specificate nella definizione di attività sono leggibili da tutti gli utenti IAM e i ruoli per i quali è consentita l'operazione `DescribeTaskDefinition` per la definizione di attività.

Puoi passare le variabili di ambiente ai container nei seguenti modi:
+ Individualmente utilizzando il parametro di definizione del container `environment`. Questo viene mappato all'opzione `--env` su [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/).
+ In blocco, utilizzando il parametro di definizione del container `environmentFiles` per elencare uno o più file contenenti le variabili di ambiente. Il file deve essere ospitato in Amazon S3. Questo viene mappato all'opzione `--env-file` su [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/).

Di seguito è riportato uno snippet di una definizione di attività che mostra come specificare singole variabili di ambiente.

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

# Passare le variabili di ambiente a un container Amazon ECS
<a name="use-environment-file"></a>

**Importante**  
Ti consigliamo di archiviare i dati sensibili nei Gestione dei segreti AWS segreti o nei parametri del AWS Systems Manager Parameter Store. Per ulteriori informazioni, consulta [Trasferimento di dati sensibili a un container Amazon ECS](specifying-sensitive-data.md).  
I file variabili di ambiente sono oggetti in Amazon S3 e si applicano tutte le considerazioni sulla sicurezza di Amazon S3.   
Non è possibile utilizzare il parametro `environmentFiles` su container Windows e Windows su Fargate.

È possibile creare un file di variabili di ambiente e archiviarlo in Amazon S3 per passare le variabili di ambiente al proprio container.

Specificando le variabili di ambiente in un file, puoi inserire in blocco le variabili di ambiente. All'interno della definizione del container, specifica l'oggetto `environmentFiles` con un elenco di bucket Amazon S3 contenenti i file delle variabili di ambiente.

Amazon ECS non applica un limite di dimensione alle variabili di ambiente, ma un file di variabili di ambiente di grandi dimensioni potrebbe riempire lo spazio su disco. Ogni processo che utilizza un file di variabili di ambiente fa sì che una copia del file venga scaricata sul disco. Amazon ECS rimuove il file come parte della pulizia del processo.

Per informazioni sulle variabili di ambiente supportate, consulta [Parametri avanzati di definizione del container - Ambiente](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment).

Quando si specifica un file di variabili di ambiente in una definizione di container, considera quanto segue.
+ Per le attività Amazon ECS su Amazon EC2, per utilizzare questa funzione le istanze del container richiedono la versione `1.39.0` o successiva dell'agente del container. Per informazioni sulla verifica della versione dell'agente e sull'aggiornamento alla versione più recente, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).
+ Per le attività di Amazon ECS su AWS Fargate, le attività devono utilizzare la `1.4.0` versione della piattaforma o successiva (Linux) per utilizzare questa funzionalità. Per ulteriori informazioni, consulta [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).

  Verifica che la variabile sia supportata per la piattaforma del sistema operativo. Per ulteriori informazioni, consultare [Definizioni del container](task_definition_parameters.md#container_definitions) e [Altri parametri di definizione di attività](task_definition_parameters.md#other_task_definition_params).
+ Il file deve utilizzare l'estensione del file `.env` e la codifica UTF-8.
+ Per utilizzare questa funzionalità con le autorizzazioni aggiuntive per Amazon S3, è necessario il ruolo di esecuzione dell'attività. Ciò consente all'agente del container di estrarre il file della variabile di ambiente da Amazon S3. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione di attività Amazon ECS](task_execution_IAM_role.md).
+ È previsto un limite di 10 file per definizione di attività.
+ Ogni riga di un file di ambiente deve contenere una variabile di ambiente nel formato `VARIABLE=VALUE`. Spazi o virgolette **sono** inclusi come parte dei valori per i file Amazon ECS. Le righe che iniziano con `#` vengono trattate come commenti e vengono ignorate. Per ulteriori informazioni sulla sintassi del file delle variabili di ambiente, consultare [Set environment variables (-e, --env, --env-file)](https://docs.docker.com/reference/cli/docker/container/run/#env) nella documentazione Docker.

  Di seguito è riportata la sintassi appropriata.

  ```
  #This is a comment and will be ignored
  VARIABLE=VALUE
  ENVIRONMENT=PRODUCTION
  ```
+ Se sono specificate variabili di ambiente utilizzando il parametro `environment` in una definizione di container, queste hanno la precedenza sulle variabili contenute in un file di ambiente.
+ Se vengono specificati più file di ambiente che contengono la stessa variabile, vengono elaborati in ordine di inserimento. Ciò significa che viene utilizzato il primo valore della variabile e i valori successivi delle variabili duplicate vengono ignorati. Consigliamo di utilizzare nomi di variabili univoci.
+ Se un file di ambiente viene specificato come override di container, viene utilizzato. Inoltre, tutti gli altri file di ambiente specificati nella definizione del container vengono ignorati.
+ Le seguenti regole si applicano a Fargate:
  + Il file viene gestito in maniera simile a un file env Docker nativo.
  + Le definizioni dei container che fanno riferimento a variabili di ambiente vuote e archiviate in Amazon S3 non vengono visualizzate nel container.
  + Non è disponibile alcun supporto per la gestione dell'escape della shell (interprete di comandi).
  + Il punto di ingresso del container interpreta i valori `VARIABLE`.

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

Di seguito è riportato uno snippet di una definizione di attività che mostra come specificare un file di variabile di ambiente.

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

# Passare i segreti di Secrets Manager in modo programmatico in Amazon ECS
<a name="secrets-app-secrets-manager"></a>

Invece di eseguire la codifica fissa delle informazioni sensibili in testo normale nell'applicazione, è possibile utilizzare Secrets Manager per archiviare i dati sensibili.

Consigliamo questo metodo di recupero dei dati sensibili perché, se il segreto di Gestione dei segreti verrà aggiornato in futuro, l'applicazione recupererà automaticamente l'ultima versione del segreto.

Creazione di un segreto in Secrets Manager. Dopo aver creato un segreto di Gestione dei segreti, aggiorna il codice dell'applicazione per recuperarlo.

Prima di proteggere i dati sensibili in Gestione dei segreti, considera i seguenti aspetti.
+ Sono supportati solo i segreti che memorizzano dati di testo, ovvero segreti creati con il `SecretString` parametro dell'[CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API. I segreti che memorizzano dati binari, ovvero segreti creati con il `SecretBinary` parametro dell'[CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API, non sono supportati.
+ Utilizza gli endpoint VPC dell'interfaccia per migliorare i controlli di sicurezza. È necessario creare gli endpoint VPC di interfaccia per Gestione dei segreti. Per informazioni sull'endpoint VPC, consulta [Creazione di endpoint VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) nella *Guida per l'utente di Gestione dei segreti AWS *.
+ Il VPC utilizzato dalla tua attività deve utilizzare la risoluzione DNS.
+ La definizione dell'attività deve utilizzare un ruolo di attività con autorizzazioni aggiuntive per Secrets Manager. Per ulteriori informazioni, consulta [Ruolo IAM dell'attività Amazon ECS](task-iam-roles.md).

## Creazione del segreto di Gestione dei segreti
<a name="secrets-app-secrets-manager-create-secret"></a>

Puoi utilizzare la console Secrets Manager per creare un segreto per i dati sensibili. Per ulteriori informazioni sulla creazione dei segreti, consulta [Creazione di un segreto Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *.

## Aggiornamento dell'applicazione per il recupero programmatico dei segreti di Gestione dei segreti
<a name="secrets-app-secrets-manager-update-app"></a>

È possibile recuperare i segreti con una chiamata al Secrets Manager APIs direttamente dall'applicazione. Per informazioni, consultare [Retrieve secrets from Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) nella *Guida per l'utente di Gestione dei segreti AWS *.

Per recuperare i dati sensibili memorizzati in Gestione dei segreti AWS, consulta [Esempi di codice da Gestione dei segreti AWS utilizzare AWS SDKs nella libreria di](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html) codici *AWS SDK Code Examples*.

# Passare i segreti di Systems Manager Parameter Store in modo programmatico in Amazon ECS
<a name="secrets-app-ssm-paramstore"></a>

Archivio dei parametri Systems Manager fornisce l'archiviazione e la gestione sicure dei segreti. Puoi archiviare dati come password, stringhe di database, istanze EC2 e IDs AMI IDs e codici di licenza come valori dei parametri, invece di codificare queste informazioni nell'applicazione. È possibile memorizzare i valori in testo semplice o crittografati.

Consigliamo questo metodo di recupero dei dati sensibili perché, se il parametro di Systems Manager Parameter Store verrà aggiornato in futuro, l'applicazione recupererà automaticamente l'ultima versione.

Prima di proteggere i dati sensibili in Archivio dei parametri Systems Manager, considera i seguenti aspetti.
+ Sono supportati solo i segreti che archiviano dati di testo. I segreti che memorizzano dati binari non sono supportati.
+ Utilizza gli endpoint VPC dell'interfaccia per migliorare i controlli di sicurezza.
+ Il VPC utilizzato dalla tua attività deve utilizzare la risoluzione DNS.
+ Per i processi che utilizzano EC2, è necessario utilizzare la variabile di configurazione dell'agente Amazon ECS `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` per utilizzare questa funzionalità. Puoi aggiungerlo al file `/etc/ecs/ecs.config` durante la creazione dell'istanza di container oppure aggiungerlo a un'istanza esistente e quindi riavviare l'agente ECS. Per ulteriori informazioni, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).
+ La definizione dell'attività deve utilizzare un ruolo di attività con autorizzazioni aggiuntive per Systems Manager Parameter Store. Per ulteriori informazioni, consulta [Ruolo IAM dell'attività Amazon ECS](task-iam-roles.md).

## Creazione del parametro di
<a name="secrets-app-ssm-paramstore-create-secret"></a>

Puoi utilizzare la console Systems Manager per creare un parametro di Archivio dei parametri Systems Manager per i dati sensibili. Per ulteriori informazioni, consulta [Creazione di un parametro Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) o [Creare un parametro Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) nella *Guida per l'utente di AWS Systems Manager *.

## Aggiornamento automatico dell'applicazione per recuperare in modo programmatico i segreti di Archivio dei parametri Systems Manager
<a name="secrets-app-ssm-paramstore-update-app"></a>

Per recuperare i dati sensibili memorizzati nel parametro Systems Manager Parameter Store, consulta [Esempi di codice per l'utilizzo di Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) nella libreria di codici *AWS SDK Code Examples.*

# Passare i segreti di Secrets Manager tramite le variabili di ambiente Amazon ECS
<a name="secrets-envvar-secrets-manager"></a>

Quando si inserisce un segreto come variabile di ambiente, è possibile specificare il contenuto completo di un segreto, una chiave JSON specifica all'interno di un segreto. Questo processo consente di controllare i dati sensibili esposti al container. Per ulteriori informazioni sul controllo delle versioni segrete, consultare [What's in a Secrets Manager secret?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version) nella *Guida per l'utente di Gestione dei segreti AWS *.

Quando si utilizza una variabile di ambiente per inserire un segreto di Gestione dei segreti in un container, è opportuno considerare quanto segue.
+ I dati sensibili vengono inseriti nel container quando viene inizialmente avviato. Se il segreto o parametro viene in seguito aggiornato o ruotato, il container non riceverà automaticamente il valore aggiornato. È necessario avviare una nuova attività o se l'attività è parte di un servizio, è possibile aggiornare il servizio e utilizzare la nuova opzione **Force new deployment (Forza nuova implementazione)** per forzare il servizio ad avviare una nuova attività.
+ Le applicazioni eseguite sul container, i log del container e gli strumenti di debug hanno accesso alle variabili di ambiente.
+ Per le attività di Amazon ECS su AWS Fargate, considera quanto segue:
  + Per inserire il contenuto completo di un segreto come variabile di ambiente o in una configurazione di log, è necessario utilizzare la versione della piattaforma `1.3.0` o successiva. Per informazioni, consulta [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).
  + Per inserire una chiave JSON specifica o la versione di un segreto come variabile di ambiente o in una configurazione di log, è necessario utilizzare la versione della piattaforma `1.4.0` o successiva (Linux) o `1.0.0` (Windows). Per informazioni, consulta [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).
+ Per i processi Amazon ECS su EC2, è necessario considerare quanto segue:
  + Per inserire un segreto utilizzando una chiave JSON specifica o una versione di un segreto, l'istanza del container deve avere la versione `1.37.0` o successiva dell'agente del container. Tuttavia, ti consigliamo di utilizzare la versione più recente dell'agente container. Per informazioni sulla verifica della versione dell'agente e sull'aggiornamento alla versione più recente, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

    Per inserire il contenuto completo di un segreto come variabile di ambiente o per inserire un segreto in una configurazione di log, l'istanza del container deve avere la versione `1.22.0` o successiva dell'agente del container.
+ Utilizzare gli endpoint VPC dell'interfaccia per migliorare i controlli di sicurezza e connettersi a Secrets Manager tramite una sottorete privata. È necessario creare gli endpoint VPC di interfaccia per Gestione dei segreti. Per informazioni sull'endpoint VPC, consulta [Creazione di endpoint VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) nella *Guida per l'utente di Gestione dei segreti AWS *. Per ulteriori informazioni sull'utilizzo di Secrets Manager e Amazon VPC, consultare [How to connect to Secrets Manager service within a Amazon VPC](https://aws.amazon.com/blogs//security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual-private-cloud/).
+ Per le attività di Windows configurate per utilizzare il driver di registrazione `awslogs`, è necessario impostare anche la variabile di ambiente `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` nell'istanza di container. Utilizzare la seguente sintassi:

  ```
  <powershell>
  [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
  Initialize-ECSAgent -Cluster <cluster name> -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
  </powershell>
  ```
+ La definizione dell'attività deve utilizzare l'esecuzione di un ruolo di attività con autorizzazioni aggiuntive per Secrets Manager. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione di attività Amazon ECS](task_execution_IAM_role.md).

## Crea il segreto Gestione dei segreti AWS
<a name="secrets-envvar-secrets-manager-create-secret"></a>

Puoi utilizzare la console Secrets Manager per creare un segreto per i dati sensibili. Per ulteriori informazioni, consulta [Creare un Gestione dei segreti AWS segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) nella *Guida Gestione dei segreti AWS per l'utente*.

## Aggiunta della variabile di ambiente alla definizione di container
<a name="secrets-envvar-secrets-manager-update-container-definition"></a>

All'interno della definizione del container, è possibile specificare quanto segue:
+ L'oggetto `secrets` contenente il nome della variabile di ambiente da impostare nel container
+ L'Amazon Resource Name (ARN) del segreto di Secrets Manager
+ Parametri aggiuntivi che contengono i dati sensibili da presentare al container

Nell'esempio seguente viene illustrata la sintassi completa che deve essere specificata per il segreto di Secrets Manager.

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

Nella sezione seguente vengono descritti i parametri aggiuntivi. Questi parametri sono facoltativi, ma se non li si utilizza, è necessario includere i due punti `:` per utilizzare i valori predefiniti. Esempi sono forniti di seguito per un maggiore contesto.

`json-key`  
Specificare il nome della chiave in una coppia chiave-valore con il valore che si desidera impostare come valore della variabile di ambiente. Sono supportati solo i valori in formato JSON. Se non si specifica una chiave JSON, viene utilizzato il contenuto completo del segreto.

`version-stage`  
Specificare l'etichetta di gestione temporanea della versione di un segreto che si desidera utilizzare. Se viene specificata un'etichetta di gestione temporanea della versione, non è possibile specificare un ID versione. Se non viene specificata alcuna fase di versione, il comportamento predefinito consiste nel recuperare il segreto con l'etichetta `AWSCURRENT` di gestione temporanea.  
Le etichette di gestione temporanea vengono utilizzate per tenere traccia di diverse versioni di un segreto quando vengono aggiornate o ruotate. Ogni versione di un segreto ha una o più etichette di gestione temporanea e un ID.

`version-id`  
Specifica l'identificatore univoco della versione del segreto che intendi utilizzare. Se viene specificato un ID versione, non è possibile specificare un'etichetta di gestione temporanea della versione. Se non viene specificato alcun ID versione, il comportamento predefinito consiste nel recuperare il segreto con l'etichetta `AWSCURRENT` di gestione temporanea.  
 IDs Le versioni vengono utilizzate per tenere traccia delle diverse versioni di un segreto quando vengono aggiornate o ruotate. Ogni versione di un segreto ha un ID. Per ulteriori informazioni, consulta [Termini e concetti chiave di Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret) nella *Guida per l'utente di Gestione dei segreti AWS *.

### Esempio di definizioni del container
<a name="secrets-examples"></a>

Negli esempi seguenti vengono illustrati i modi in cui è possibile fare riferimento ai segreti di Secrets Manager nelle definizioni del container.

**Example riferimento a un segreto completo**  
Di seguito è riportato un frammento di una definizione di processo che mostra il formato quando si fa riferimento a un segreto di Secrets Manager.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
    }]
  }]
}
```
Per accedere al valore di questo segreto dall'interno del container, è necessario effettuare la chiamata a `$environment_variable_name`.

**Example fare riferimento a segreti completi**  
Di seguito è riportato un frammento di una definizione di processo che mostra il formato quando si fa riferimento a più segreti di Secrets Manager.  

```
{
  "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"
      }
    ]
  }]
}
```
Per accedere al valore di questo segreto dall'interno del container, è necessario effettuare la chiamata a `$environment_variable_name1`, `$environment_variable_name2` e `$environment_variable_name3`.

**Example fare riferimento a una chiave specifica all'interno di un segreto**  
Di seguito viene illustrato un esempio di output di un [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)comando che visualizza il contenuto di un segreto insieme all'etichetta temporanea della versione e all'ID di versione ad esso associati.  

```
{
    "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
}
```
Fare riferimento a una chiave specifica dell'output precedente in una definizione di container specificando il nome della chiave alla fine dell'ARN.  

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

**Example riferimento a una versione segreta specifica**  
Di seguito viene illustrato un output di esempio da un comando [describe-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html) che visualizza il contenuto non crittografato di un segreto insieme ai metadati per tutte le versioni del segreto.  

```
{
    "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"
        ]
    }
}
```
Fare riferimento a un'etichetta di gestione temporanea della versione specifica dall'output precedente in una definizione di container specificando il nome della chiave alla fine dell'ARN.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:"
    }]
  }]
}
```
Fare riferimento a un ID di versione specifico dall'output precedente in una definizione di container specificando il nome della chiave alla fine dell'ARN.  

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

**Example riferimento a una chiave specifica e un'etichetta di gestione temporanea della versione di un segreto**  
Di seguito viene illustrato come fare riferimento sia a una chiave specifica all'interno di un segreto che a una specifica etichetta di gestione temporanea della versione.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:"
    }]
  }]
}
```
Per specificare una chiave e un ID di versione specifici, utilizzare la seguente sintassi.  

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

Per informazioni sulla creazione di una definizione di attività con il segreto specificato in una variabile di ambiente, consultare [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md). 

# Passare i parametri di Systems Manager tramite le variabili di ambiente Amazon ECS
<a name="secrets-envvar-ssm-paramstore"></a>

Amazon ECS ti consente di iniettare dati sensibili nei tuoi contenitori memorizzando i dati sensibili nei AWS Systems Manager parametri di Parameter Store e quindi facendo riferimento ad essi nella definizione del contenitore.

Tenere in considerazione ciò che segue durante l'utilizzo di una variabile di ambiente per inserire un segreto di Systems Manager in un container.
+ I dati sensibili vengono inseriti nel container quando viene inizialmente avviato. Se il segreto o parametro viene in seguito aggiornato o ruotato, il container non riceverà automaticamente il valore aggiornato. È necessario avviare una nuova attività o se l'attività è parte di un servizio, è possibile aggiornare il servizio e utilizzare la nuova opzione **Force new deployment (Forza nuova implementazione)** per forzare il servizio ad avviare una nuova attività.
+ Per le attività di Amazon ECS su AWS Fargate, è necessario considerare quanto segue:
  + Per inserire il contenuto completo di un segreto come variabile di ambiente o in una configurazione di log, è necessario utilizzare la versione della piattaforma `1.3.0` o successiva. Per informazioni, consulta [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).
  + Per inserire una chiave JSON specifica o la versione di un segreto come variabile di ambiente o in una configurazione di log, è necessario utilizzare la versione della piattaforma `1.4.0` o successiva (Linux) o `1.0.0` (Windows). Per informazioni, consulta [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).
+ Per i processi Amazon ECS su EC2, è necessario considerare quanto segue:
  + Per inserire un segreto utilizzando una chiave JSON specifica o una versione di un segreto, l'istanza del container deve avere la versione `1.37.0` o successiva dell'agente del container. Tuttavia, ti consigliamo di utilizzare la versione più recente dell'agente container. Per informazioni sulla verifica della versione dell'agente e sull'aggiornamento alla versione più recente, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

    Per inserire il contenuto completo di un segreto come variabile di ambiente o per inserire un segreto in una configurazione di log, l'istanza del container deve avere la versione `1.22.0` o successiva dell'agente del container.
+ Utilizza gli endpoint VPC dell'interfaccia per migliorare i controlli di sicurezza. È necessario creare gli endpoint VPC di interfaccia per Systems Manager. Per informazioni sull'endpoint VPC, consultare [Improve the security of EC2 instances by using VPC endpoints for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) nella *Guida per l'utente di AWS Systems Manager *.
+ La definizione dell'attività deve utilizzare l'esecuzione di un ruolo di attività con autorizzazioni aggiuntive per Systems Manager Parameter Store. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione di attività Amazon ECS](task_execution_IAM_role.md).
+ Per le attività di Windows configurate per utilizzare il driver di registrazione `awslogs`, è necessario impostare anche la variabile di ambiente `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` nell'istanza di container. Utilizzare la seguente sintassi:

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

## Creare il parametro Systems Manager
<a name="secrets-envvar-ssm-paramstore-create-parameter"></a>

Puoi utilizzare la console Systems Manager per creare un parametro di Archivio dei parametri Systems Manager per i dati sensibili. Per ulteriori informazioni, consulta [Creazione di un parametro Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) o [Creare un parametro Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) nella *Guida per l'utente di AWS Systems Manager *.

## Aggiunta della variabile di ambiente alla definizione di container
<a name="secrets-ssm-paramstore-update-container-definition"></a>

Nella definizione del container all'interno della definizione dell'attività, specifica `secrets` con il nome della variabile di ambiente per impostare il container e l'ARN del parametro dell'archivio parametri di Systems Manager contenente i dati sensibili da presentare al container. Per ulteriori informazioni, consulta [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Di seguito è riportato un frammento di una definizione di processo che mostra il formato quando si fa riferimento a un parametro dell'archivio parametri di Systems Manager. Se il parametro dell'archivio parametri di Systems Manager esiste nella stessa regione del processo in fase di avvio, è possibile utilizzare l'ARN completo o il nome del parametro. Se il parametro si trova in una regione diversa, specifica l'ARN completo.

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

Per informazioni sulla creazione di una definizione di attività con il segreto specificato in una variabile di ambiente, consultare [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md).

## Aggiornamento automatico dell'applicazione per recuperare in modo programmatico i segreti di Archivio dei parametri Systems Manager
<a name="secrets-ssm-paramstore-update-app"></a>

Per recuperare i dati sensibili memorizzati nel parametro Systems Manager Parameter Store, consulta [Esempi di codice per l'utilizzo di Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) nella libreria di codici *AWS SDK Code Examples.*

# Passare i segreti per la configurazione di registrazione di Amazon ECS
<a name="secrets-logconfig"></a>

È possibile utilizzare il parametro `secretOptions` in `logConfiguration` per passare dati sensibili utilizzati per la registrazione.

È possibile archiviare il messaggio in Secrets Manager o Systems Manager.

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

Nella definizione del container, quando specifichi `logConfiguration` è possibile specificare `secretOptions` con il nome dell'opzione del driver di log per impostare il container e l'ARN completo del segreto di Secrets Manager contenente i dati riservati da presentare al container. Per ulteriori informazioni sulla creazione dei segreti, consultare [Create an Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).

Di seguito è riportato un frammento di una definizione di processo che mostra il formato quando si fa riferimento a un segreto Secrets Manager.

```
{
  "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"
      }]
    }]
  }]
}
```

## Aggiunta della variabile di ambiente alla definizione di container
<a name="secrets-envvar-ssm-paramstore-update-container-definition"></a>

Nella definizione del container specifica `secrets` con il nome della variabile di ambiente per impostare il container e l'ARN del parametro dell'archivio parametri di Systems Manager contenente i dati sensibili da presentare al container. Per ulteriori informazioni, consulta [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Di seguito è riportato un frammento di una definizione di processo che mostra il formato quando si fa riferimento a un parametro dell'archivio parametri di Systems Manager. Se il parametro dell'archivio parametri di Systems Manager esiste nella stessa regione del processo in fase di avvio, è possibile utilizzare l'ARN completo o il nome del parametro. Se il parametro si trova in una regione diversa, specifica l'ARN completo.

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

Per informazioni sulla creazione di una definizione di attività con il segreto specificato in una variabile di ambiente, consultare [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md).

## Utilizzo di Systems Manager
<a name="secrets-logconfig-ssm-paramstore"></a>

Puoi inserire dati sensibili in una configurazione di log. Nella definizione del container, quando specifichi un `logConfiguration` è possibile specificare `secretOptions` con il nome dell'opzione del driver di log per impostare il container e l'ARN completo del parametro dell'archivio parametri di Systems Manager contenente i dati sensibili da presentare al container.

**Importante**  
Se il parametro dell'archivio parametri di Systems Manager esiste nella stessa regione del processo in fase di avvio, è possibile utilizzare l'ARN completo o il nome del parametro. Se il parametro si trova in una regione diversa, specifica l'ARN completo.

Di seguito è riportato un frammento di una definizione di attività che mostra il formato quando si fa riferimento a un parametro dell'archivio parametri di Systems Manager.

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

# Specifica di dati sensibili utilizzando segreti di Secrets Manager in Amazon ECS
<a name="specifying-sensitive-data-tutorial"></a>

Amazon ECS ti consente di iniettare dati sensibili nei tuoi contenitori archiviando i dati sensibili in modo Gestione dei segreti AWS segreto e quindi facendone riferimento nella definizione del contenitore. Per ulteriori informazioni, consulta [Trasferimento di dati sensibili a un container Amazon ECS](specifying-sensitive-data.md).

Per scoprire come creare un segreto di Secrets Manager, fare riferimento al segreto in una definizione di attività di Amazon ECS e quindi verificarne il funzionamento eseguendo una query sulla variabile di ambiente all'interno di un container che mostra i contenuti del segreto.

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

Questo tutorial presuppone che siano stati soddisfatti i prerequisiti seguenti:
+ Hai completato le fasi descritte in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).
+ L'utente dispone delle autorizzazioni IAM necessarie per creare le risorse di Secrets Manager e Amazon ECS.

## Fase 1: Creazione di un segreto di Secrets Manager
<a name="specifying-sensitive-data-tutorial-create-secret"></a>

Puoi utilizzare la console Secrets Manager per creare un segreto per i dati sensibili. In questo tutorial creeremmo un segreto di base per l'archiviazione di un nome utente e una password cui fare riferimento in seguito in un container. *Per ulteriori informazioni, consulta [Creare un Gestione dei segreti AWS segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) nella Guida per l'Gestione dei segreti AWS utente.*

Le ** key/value coppie da memorizzare in questo segreto** sono il valore della variabile di ambiente nel contenitore alla fine del tutorial.

Salva l'**ARN del segreto** a cui fare riferimento nella policy IAM di esecuzione dell'attività e nella definizione dell'attività nelle fasi successive.

## Fase 2: aggiungere le autorizzazioni segrete al ruolo di esecuzione di attività
<a name="specifying-sensitive-data-tutorial-update-iam"></a>

Per consentire ad Amazon ECS di recuperare i dati sensibili dal segreto di Secrets Manager, è necessario disporre delle autorizzazioni dei segreti per il ruolo di esecuzione dell'attività. Per ulteriori informazioni, consulta [Autorizzazioni per Secrets Manager o Systems Manager](task_execution_IAM_role.md#task-execution-secrets).

## Fase 3: creazione di una definizione di attività
<a name="specifying-sensitive-data-tutorial-create-taskdef"></a>

Puoi utilizzare la console Amazon ECS per creare una definizione di attività che fa riferimento a un segreto di Secrets Manager.

**Per creare una definizione di attività che specifichi un segreto**

Utilizza la console IAM per aggiornare il ruolo di esecuzione del processo con le autorizzazioni richieste.

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione, scegli **Task Definitions** (Definizioni di processo).

1. Scegli **Create new task definition** (Crea nuova definizione di attività), **Create new task definition with JSON** (Crea nuova definizione di attività con JSON).

1. Nella casella dell'editor JSON, inserire il seguente testo JSON della definizione di attività, assicurandosi di specificare l'ARN completo del segreto di Secrets Manager creato nella fase 1 e il ruolo dell'esecuzione del processo aggiornato nella fase 2. Scegli **Salva**.

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. Scegli **Crea**.

## Fase 4: Creare un cluster
<a name="specifying-sensitive-data-tutorial-create-cluster"></a>

Puoi utilizzare la console Amazon ECS per creare un cluster che contiene un'istanza di container su cui eseguire il processo. Se disponi di un cluster esistente con almeno un'istanza di container registrata nello stesso con le risorse disponibili per eseguire un'istanza della definizione di attività creata per questo tutorial, puoi passare alla fase successiva.

Per questo tutorial creeremo un cluster con una istanza di container `t2.micro` utilizzando l'AMI Amazon Linux 2 ottimizzata per Amazon ECS.

Per informazioni sulla creazione di un cluster per EC2, consultare [Creazione di un cluster Amazon ECS per i carichi di lavoro di Amazon EC2](create-ec2-cluster-console-v2.md).

## Fase 5: Eseguire un'attività
<a name="specifying-sensitive-data-tutorial-run-task"></a>

Puoi utilizzare la console Amazon ECS per eseguire un processo utilizzando la definizione di attività creata. Per questo tutorial verrà eseguito un processo utilizzando EC2, mediante il cluster creato nella fase precedente. 

Per informazioni sulla modalità di esecuzione del comando, consulta [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md).

## Fase 6: verifica
<a name="specifying-sensitive-data-tutorial-verify"></a>

Puoi verificare che tutte le fasi sono state completate correttamente e che la variabile di ambiente è stata creata nel container utilizzando le fasi seguenti.

**Per verificare che la variabile di ambiente è stata creata**

1. Trova l'indirizzo DNS o IP pubblico per l'istanza di container.

   1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

   1. Nel riquadro di navigazione, selezionare **Cluster** e quindi il cluster che è stato creato.

   1. Seleziona **Infrastruttura** e quindi l'istanza di container.

   1. Registra l'**IP pubblico** o il **DNS pubblico** per l'istanza.

1. Se utilizzi un computer macOS o Linux, connettiti all'istanza con il comando seguente, sostituisci il percorso con la chiave privata e l'indirizzo pubblico dell'istanza:

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

   Per ulteriori informazioni sull'uso di un computer Windows, consultare [Connect to your Linux instance using PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html) nella *Guida per l'utente di Amazon EC2*.
**Importante**  
Per ulteriori informazioni sui problemi di connessione all'istanza, consultare [Troubleshooting Connecting to Your Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) nella *Guida per l'utente di Amazon EC2*.

1. Elencare i contenitori in esecuzione sull'istanza. Prendere nota dell'ID container per il container `ecs-secrets-tutorial`.

   ```
   docker ps
   ```

1. Eseguire il collegamento al container `ecs-secrets-tutorial` utilizzando l'ID container dell'output della fase precedente.

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

1. Utilizzare il comando `echo` per stampare il valore della variabile di ambiente.

   ```
   echo $username_value
   ```

   Se il tutorial è stato completato, viene visualizzato l'output seguente:

   ```
   password_value
   ```
**Nota**  
In alternativa, è possibile elencare tutte le variabili di ambiente nel container utilizzando il comando `env` (o `printenv`).

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

Una volta terminato questo tutorial, è necessario eliminare le risorse associate per evitare costi aggiuntivi per le risorse non utilizzate.

**Come ripulire le risorse**

1. Apri la console nella [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster.

1. Scegli **Elimina Cluster**. 

1. Nella casella di conferma, inserisci **delete *cluster name***, quindi scegli **Elimina**.

1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Nel riquadro di navigazione, seleziona **Ruoli**. 

1. Cercare l'elenco di ruoli per `ecsTaskExecutionRole` e selezionarlo.

1. Scegli **Autorizzazioni**, quindi scegli la **X** accanto a **ECSSecretsTutorial**. Scegli **Rimuovi**.

1. Apri la console Secrets Manager all'indirizzo [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).

1. Selezionare il segreto **username\$1value** creato e scegliere **Actions (Operazioni)**, **Delete secret (Elimina segreto)**.