# Casos de uso de definição de tarefa do Amazon ECS
<a name="use-cases"></a>

Saiba mais sobre como escrever definições de tarefas para vários serviços e recursos da AWS.

Dependendo da workload, há certos parâmetros de definição de tarefa que precisam ser definidos. Além disso, no EC2, você precisa escolher instâncias específicas projetadas para a workload.

**Topics**
+ [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md)
+ [Definições de tarefas do Amazon ECS para workloads de transcodificação de vídeo](ecs-vt1.md)
+ [Definições de tarefa do Amazon ECS para workloads de machine learning do AWS Neuron](ecs-inference.md)
+ [Definições de tarefa do Amazon ECS para instâncias de aprendizado profundo](ecs-dl1.md)
+ [Definições de tarefa do Amazon ECS para workloads do ARM de 64 bits](ecs-arm64.md)
+ [Envio de logs do Amazon ECS para o CloudWatch](using_awslogs.md)
+ [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md)
+ [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md)
+ [Reiniciar contêineres individuais em tarefas do Amazon ECS com políticas de reinicialização de contêineres](container-restart-policy.md)
+ [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md)

# Definições de tarefa do Amazon ECS para workloads de GPU
<a name="ecs-gpu"></a>

O Amazon ECS é compatível com workloads que utilizam GPUs quando você cria clusters com instâncias de contêiner compatíveis com GPU. As instâncias de contêiner baseadas em GPU do Amazon EC2 que usam os tipos de instância p2, p3, p5, g3, g4 e g5 fornecem acesso a GPUs NVIDIA. Para obter mais informações, consulte [Instâncias com computação acelerada do Linux](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) no *Guia de tipos de instância do Amazon EC2*.

O Amazon ECS fornece uma AMI otimizada para GPU que é fornecida com drivers de kernel NVIDIA pré-configurados e um runtime de GPU do Docker. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md).

É possível designar várias GPUs na sua definição de tarefa para consideração do posicionamento de tarefas em um nível de contêiner. O Amazon ECS programa instâncias de contêineres disponíveis compatíveis com GPU, atribuindo GPUs físicas a contêineres adequados para proporcionar a performance ideal. 

Os seguintes tipos de instância do Amazon EC2 baseados em GPU são compatíveis. Para obter mais informações, consulte [Instâncias P2 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/p2/), [Instâncias P3 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/p3/), [Instâncias P4d do Amazon EC2](https://aws.amazon.com/ec2/instance-types/p4/), [Instâncias P5 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/p5/), [Instâncias G3 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/g3/), [Instâncias G4 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/g4/), [Instâncias G5 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/g5/), [Instâncias G6 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/g6/) e [Instâncias G6e do Amazon EC2](https://aws.amazon.com/ec2/instance-types/g6e/).


|  Tipo de instância  |  GPUs  |  Memória da GPU (GiB)  |  vCPUs  |  Memória (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.xlarge | 1 | 24 | 64 | 256 | 
| g6.12xlarge | 4 | 96 | 48 | 192 | 
| g6.24xlarge | 4 | 96 | 96 | 384 | 
| g6.48xlarge | 8 | 192 | 192 | 768 | 
| g6.metal | 8 | 192 | 192 | 768 | 
| gr6.4xlarge | 1 | 24 | 16 | 128 | 
| g6e.xlarge | 1 | 48 | 4 | 32 | 
| g6e.2xlarge | 1 | 48 | 8 | 64 | 
| g6e.4xlarge | 1 | 48 | 16 | 128 | 
| g6e.8xlarge | 1 | 48 | 32 | 256 | 
| g6e16.xlarge | 1 | 48 | 64 | 512 | 
| g6e12.xlarge | 4 | 192 | 48 | 384 | 
| g6e24.xlarge | 4 | 192 | 96 | 768 | 
| g6e48.xlarge | 8 | 384 | 192 | 1536 | 
| gr6.8xlarge | 1 | 24 | 32 | 256 | 

É possível recuperar o ID da imagem de máquina da Amazon (AMI) para AMIs otimizadas para o Amazon ECS consultando a API Parameter Store do AWS Systems Manager. Ao usar esse parâmetro, não será necessário pesquisar manualmente IDs de AMIs otimizadas para o Amazon ECS. Para obter mais informações sobre a API Systems Manager Parameter Store, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). O usuário que você usou deve ter a permissão `ssm:GetParameter` do IAM para recuperar os metadados da AMI otimizada para o Amazon ECS.

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

# Usar GPUs com instâncias gerenciadas do Amazon ECS
<a name="managed-instances-gpu"></a>

As instâncias gerenciadas do Amazon ECS oferecem suporte à computação acelerada por GPU para workloads como machine learning, computação de alta performance e processamento de vídeo por meio dos tipos de instância a seguir do Amazon EC2. Para obter mais informações sobre os tipos de instância compatíveis com as instâncias gerenciadas do Amazon ECS, consulte [Tipos de instâncias gerenciadas do Amazon ECS](managed-instances-instance-types.md).

Este é um subconjunto dos tipos de instância baseados em GPU compatíveis com as instâncias gerenciadas do Amazon ECS:
+ `g4dn`: desenvolvido com NVIDIA T4 GPUs, adequado para inferência de machine learning, visão computacional e aplicações com uso intensivo de gráficos.
+ `g5`: desenvolvido com NVIDIA A10G GPUs, oferecendo maior performance para aplicações com uso intensivo de gráficos e workloads de machine learning.
+ `p3`: desenvolvido com NVIDIA V100 GPUs, projetado para computação de alta performance e treinamento em aprendizado profundo.
+ `p4d`: desenvolvido com NVIDIA A100 GPUs, oferecendo a mais alta performance para treinamento em machine learning e computação de alta performance.

Quando você usa tipos de instância habilitados para GPU com instâncias gerenciadas do Amazon ECS, os drivers NVIDIA e o kit de ferramentas CUDA são pré-instalados na instância, facilitando a execução de workloads aceleradas por GPU.

## Seleção de instância habilitada para GPU
<a name="managed-instances-gpu-instance-selection"></a>

Para selecionar tipos de instância habilitados para GPU para suas workloads de instâncias gerenciadas do Amazon ECS, use o objeto `instanceRequirements` no modelo de inicialização do provedor de capacidade. O trecho a seguir mostra os atributos que podem ser usados para selecionar instâncias habilitadas para GPU.

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

O trecho a seguir mostra os atributos que podem ser usados para especificar tipos de instância habilitados para GPU no modelo de inicialização.

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

## Imagens de contêiner habilitado para GPU
<a name="managed-instances-gpu-container-images"></a>

Para usar GPUs em seus contêineres, você precisa usar imagens de contêiner que tenham as bibliotecas e ferramentas de GPU necessárias. A NVIDIA fornece várias imagens de contêiner pré-criadas que você pode usar como base para suas workloads de GPU, incluindo as seguintes:
+ `nvidia:cuda`: imagens básicas com o kit de ferramentas CUDA para computação em GPU.
+ `tensorflow/tensorflow:latest-gpu`: TensorFlow com suporte de GPU.
+ `pytorch/pytorch:latest-cuda`: PyTorch com suporte de GPU.

Para obter um exemplo de definição de tarefa para o Amazon ECS em instâncias gerenciadas do Amazon ECS que envolve o uso de GPUs, consulte [Especificar GPUs em uma definição de tarefa do Amazon ECS](ecs-gpu-specifying.md).

## Considerações
<a name="gpu-considerations"></a>

**nota**  
O suporte para o tipo de família de instâncias g2 foi descontinuado.  
Há suporte para o tipo da família de instâncias p2 somente em versões anteriores à `20230912` da AMI otimizada para GPU do Amazon ECS. Se você precisar continuar usando instâncias p2, consulte [O que fazer se você precisar de uma instância P2](#p2-instance).  
As atualizações locais dos drivers NVIDIA/CUDA nesses dois tipos de família de instâncias causarão possíveis falhas na workload da GPU.

Convém considerar as observações a seguir antes de iniciar o trabalho com GPUs no Amazon ECS.
+ Seus clusters podem conter uma combinação de instâncias de contêiner de GPU e não GPU.
+ É possível executar workloads de GPU em instâncias externas. Ao registrar uma instância externa no cluster, certifique-se de que o sinalizador `--enable-gpu` esteja incluído no script de instalação. Para obter mais informações, consulte [Registro de uma instância externa para um cluster do Amazon ECS](ecs-anywhere-registration.md).
+ É necessário definir `ECS_ENABLE_GPU_SUPPORT` como `true` no seu arquivo de configuração do agente. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md).
+ Ao executar uma tarefa ou criar um serviço, você pode usar atributos de tipo de instância ao configurar restrições de posicionamento de tarefas para determinar em quais instâncias de contêiner a tarefa deve ser inicada. Ao fazer isso, você pode usar seus recursos com mais eficiência. Para obter mais informações, consulte [Como o Amazon ECS posiciona tarefas em instâncias de contêineres](task-placement.md).

  O exemplo a seguir executa uma tarefa em uma instância de contêiner `g4dn.xlarge` em seu cluster padrão.

  ```
  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
  ```
+ Para cada contêiner que tenha um requisito de recurso de GPU especificado na definição do contêiner, o Amazon ECS define o runtime do contêiner como o runtime do contêiner NVIDIA.
+ O runtime do contêiner NVIDIA requer que algumas variáveis de ambiente sejam definidas no contêiner para funcionar corretamente. Para obter uma lista dessas variáveis de ambiente, consulte [Specialized Configurations with Docker](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable). O Amazon ECS define o valor da variável de ambiente `NVIDIA_VISIBLE_DEVICES` como uma lista dos IDs de dispositivo de GPU que o Amazon ECS atribui ao contêiner. O Amazon ECS não define as outras variáveis de ambiente necessárias. Por isso, certifique-se de que a imagem de contêiner as defina ou que elas sejam especificadas na definição de contêiner.
+ A família de tipos de instância p5 tem suporte na versão `20230929` e posterior da AMI otimizada para GPU do Amazon ECS. 
+ A família de tipos de instância g4 tem suporte na versão `20230913` e posterior da AMI otimizada para GPU do Amazon ECS. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). Ela é compatível com o fluxo de trabalho Create Cluster (Criar cluster) no console do Amazon ECS. Para usar esses tipos de instância, é necessário usar o console do Amazon EC2, a AWS CLI ou a API e registrar manualmente as instâncias no cluster.
+ O tipo de instância p4d.24xlarge só funciona com CUDA 11 ou posterior.
+ A AMI otimizada para GPU do Amazon ECS tem IPv6 habilitado, o que causa problemas ao usar `yum`. Isso pode ser resolvido configurando `yum` para usar o IPv4 com o seguinte comando.

  ```
  echo "ip_resolve=4" >> /etc/yum.conf
  ```
+  Quando você criar uma imagem de contêiner que não usa as imagens de base NVIDIA/CUDA, deverá definir a variável do runtime do contêiner `NVIDIA_DRIVER_CAPABILITIES` em um dos seguintes valores:
  + `utility,compute`
  + `all`

  Para obter informações sobre como definir a variável, consulte [Controlar o runtime do contêiner NVIDIA](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime) no site da NVIDIA.
+ Não há suporte para GPUs em contêineres do Windows.

# Iniciar uma instância de contêiner de GPU para o Amazon ECS
<a name="gpu-launch"></a>

Para usar uma instância de GPU no Amazon ECS no Amazon EC2, você precisa criar um modelo de inicialização, um arquivo de dados do usuário e inicializar a instância.

Em seguida, você pode executar uma tarefa que usa uma definição de tarefa configurada para GPU.

## Usar um modelo de execução
<a name="gpu-launch-template"></a>

Você pode criar um modelo de execução.
+ Crie um modelo de execução que use o ID da AMI de GPU otimizada para o Amazon ECS para a AMI. Para obter informações sobre como criar um modelo de inicialização, consulte [Criar um novo modelo de inicialização usando parâmetros definidos por você](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters) no *Manual do usuário do Amazon EC2*.

  Use o ID da AMI da etapa anterior na **Imagem da máquina da Amazon**. Para obter informações sobre como especificar o ID da AMI com o parâmetro do Systems Manager, consulte [Especificar um parâmetro do Systems Manager em um modelo de inicialização](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id) no *Manual do usuário do Amazon EC2*.

  Adicione os itens a seguir aos **Dados do usuário** no modelo de execução. Substitua *cluster-name* pelo nome do seu cluster.

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

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

É possível executar uma instância de contêiner usando a AWS CLI.

1. Crie um arquivo chamado `userdata.toml`. Esse arquivo será usado para dados do usuário da instância. Substitua *cluster-name* pelo nome do seu cluster.

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

1. Execute o comando a seguir para obter o ID da AMI de GPU. Você usará isso na etapa a seguir.

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

1. Execute o comando a seguir para executar a instância de GPU. Lembre-se de substituir os parâmetros a seguir:
   + Substitua *sub-rede* pelo ID da sub-rede pública ou privada na qual sua instância será iniciada.
   + Substitua *gpu\$1ami* pelo ID da AMI da etapa anterior.
   + Substitua *t3.large* pelo tipo de instância que você deseja usar.
   + Substitua *região* pelo código da região.

   ```
   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. Execute o comando a seguir para verificar se a instância de contêiner está registrada no cluster. Ao executar esse comando, lembre-se de substituir os parâmetros a seguir:
   + Substitua *cluster* pelo nome do seu cluster.
   + Substitua *região* pelo código da sua região.

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

# Especificar GPUs em uma definição de tarefa do Amazon ECS
<a name="ecs-gpu-specifying"></a>

Para usar as GPUs em uma instância de contêiner e o runtime da GPU do Docker, certifique-se de designar, na definição de tarefa, o número de GPUs que o seu contêiner requer. O agente de contêiner do Amazon ECS atribui o número desejado de GPUs físicas ao contêiner adequado conforme os contêineres compatíveis com GPU são posicionados. O número de GPUs reservadas para todos os contêineres em uma tarefa não deve exceder o número de GPUs disponíveis na instância de contêiner na qual a tarefa é executada. Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md).

**Importante**  
Se seus requisitos de GPU não forem especificados na definição de tarefa, a tarefa usará o runtime padrão do Docker.

Veja a seguir o formato JSON para os requisitos de GPU em uma definição de tarefa.

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

O exemplo a seguir demonstra a sintaxe para um contêiner do Docker que especifica um requisito de GPU. Esse contêiner usa duas GPUs, executa o utilitário `nvidia-smi` e, em seguida, é encerrado.

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

O exemplo de definição de tarefa a seguir mostra um contêiner TensorFlow que imprime o número de GPUs disponíveis. A tarefa é executada em instâncias gerenciadas do Amazon ECS, exige uma GPU e usa uma instância `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",
}
```

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

Para compartilhar GPUs, você precisará configurar as opções a seguir.

1. Remova os requisitos de recursos de GPU das suas definições de tarefas para que o Amazon ECS não reserve nenhuma GPU que deveria ser compartilhada.

1. Adicione os dados de usuário a seguir às suas instâncias quando desejar compartilhar GPUs. Isso tornará nvidia o runtime padrão do contêiner do Docker na instância do contêiner para que todos os contêineres do Amazon ECS possam usar as GPUs. Para obter mais informações, consulte [Executar comandos ao executar uma instância do EC2 com entrada de dados do usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) no *Guia do usuário do 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. Defina a variável de ambiente `NVIDIA_VISIBLE_DEVICES` em seu contêiner. Você pode fazer isso especificando a variável de ambiente na definição da sua tarefa. Para obter informações sobre os valores válidos, consulte [Enumeração de GPUs](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration) no site de documentação da NVIDIA.

## O que fazer se você precisar de uma instância P2
<a name="p2-instance"></a>

Se você precisar usar a instância P2, poderá usar uma das opções a seguir para continuar usando as instâncias.

Será preciso modificar os dados do usuário da instância para ambas as opções. Para obter mais informações, consulte [Executar comandos ao executar uma instância do EC2 com entrada de dados do usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) no *Guia do usuário do Amazon EC2*.

**Use a última AMI otimizada para GPU com suporte**

É possível usar a versão `20230906` da AMI otimizada para GPU e adicionar o seguinte aos dados do usuário da instância.

Substitua cluster-name pelo nome do seu cluster.

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

**Use a AMI otimizada para GPU mais recente e atualize os dados do usuário**

É possível adicionar o seguinte aos dados do usuário da instância. Isso desinstala os drivers Nvidia 535/Cuda12.2 e, em seguida, instala os drivers Nvidia 470/Cuda11.4 e corrige a versão.

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

**Criar sua própria AMI otimizada para GPU compatível com P2**

É possível criar sua própria AMI personalizada otimizada para GPU do Amazon ECS que seja compatível com instâncias P2 e, em seguida, executar instâncias P2 usando a AMI.

1. Execute o comando a seguir para clonar a `amazon-ecs-ami repo`.

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

1. Defina o agente do Amazon ECS necessário e as versões de origem do Amazon Linux AMI em `release.auto.pkrvars.hcl` ou `overrides.auto.pkrvars.hcl`.

1. Execute o comando a seguir para criar uma AMI do EC2 privada compatível com P2.

   Substitua região pela Região com a instância Região.

   ```
   REGION=region make al2keplergpu
   ```

1. Use a AMI com os dados de usuário da instância a seguir para se conectar ao cluster do Amazon ECS.

   Substitua cluster-name pelo nome do seu cluster.

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

# Definições de tarefas do Amazon ECS para workloads de transcodificação de vídeo
<a name="ecs-vt1"></a>

Para usar workloads de transcodificação de vídeo no Amazon ECS, registre instâncias [VT1 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/vt1/). Após registrar essas instâncias, será possível executar workloads de transcodificação de vídeo em tempo real e pré-renderizadas como tarefas no Amazon ECS. Instâncias VT1 do Amazon EC2 utilizam placas de transcodificação de mídia Xilinx U30 para acelerar workloads de transcodificação de vídeo em tempo real e pré-renderizadas.

**nota**  
Para obter instruções sobre como executar workloads de transcodificação de vídeo em outros contêineres que não os do Amazon ECS, consulte a [documentação da Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1).

## Considerações
<a name="ecs-vt1-considerations"></a>

Antes de começar a implantar a VT1 no Amazon ECS, considere o seguinte:
+ Seus clusters podem conter uma combinação de instâncias VT1 e não VT1.
+ Você precisa de uma aplicação Linux que utilize placas de transcodificação de mídia Xilinx U30 com codecs AVC (H.264) e HEVC (H.265) acelerados.
**Importante**  
Aplicações que utilizam outros codecs podem não ter performance aprimorada em instâncias VT1.
+ Apenas uma tarefa de transcodificação pode ser executada em uma placa U30. Cada placa tem dois dispositivos associados. É possível executar tarefas de transcodificação na medida em que houver placas para cada instância VT1.
+ Ao criar um serviço ou executar uma tarefa autônoma, você pode usar atributos de tipo de instância ao configurar as restrições de posicionamento de tarefas. Assim, você se certifica de que a tarefa será iniciada na instância de contêiner que você especificar. Isso ajuda a garantir que você use seus recursos de maneira eficaz e que suas tarefas para workloads de transcodificação de vídeo estejam em suas instâncias VT1. Para obter mais informações, consulte [Como o Amazon ECS posiciona tarefas em instâncias de contêineres](task-placement.md).

  No exemplo a seguir, uma tarefa é executada em uma instância `vt1.3xlarge` do 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"
  ```
+ Você configura um contêiner para usar a placa U30 específica disponível na instância de contêiner host. É possível fazer isso utilizando o parâmetro `linuxParameters` e especificando os detalhes do dispositivo. Para obter mais informações, consulte [Requisitos de definição de tarefa](#ecs-vt1-requirements).

## Usar uma AMI VT1
<a name="ecs-vt1-ami"></a>

Existem duas opções para executar uma AMI no Amazon EC2 para instâncias de contêiner do Amazon ECS. A primeira é usar a AMI oficial da Xilinx no AWS Marketplace. A segunda é criar a sua própria AMI do repositório de amostra.
+ [A Xilinx oferece AMIs no AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6).
+ O Amazon ECS fornece um repositório de amostra que pode ser usado para criar uma AMI para workloads de transcodificação de vídeo. Essa AMI acompanha drivers Xilinx U30. O repositório que contém os scripts do Packer pode ser encontrado no [GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline). Para obter mais informações sobre o Packer, consulte a [documentação do Packer](https://developer.hashicorp.com/packer/docs).

## Requisitos de definição de tarefa
<a name="ecs-vt1-requirements"></a>

Para executar contêiners de transcodificação de vídeo no Amazon ECS, sua definição de tarefa precisa conter uma aplicação de transcodificação de vídeo que utilize codecs H.264/AVC e H.265/HEVC acelerados. É possível criar uma imagem de contêiner seguindo as etapas no [repositório da Xilinx no GitHub](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage).

A definição de tarefa deve ser específica do tipo de instância. Os tipos de instância são: 3xlarge, 6xlarge e 24xlarge. É necessário configurar um contêiner para usar dispositivos Xilinx U30 específicos disponíveis na instância de contêiner host. Para isso, use o parâmetro `linuxParameters`. A tabela a seguir fornece detalhes sobre as placas e SoCs de dispositivo específicos de cada tipo de instância.


| Tipo de instância | vCPUs | RAM (GiB) | Placas aceleradoras U30 | Dispositivos SoC XCU30 endereçáveis | Caminhos de dispositivos | 
| --- | --- | --- | --- | --- | --- | 
| 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 a definição de tarefa indicar dispositivos ausentes na instância do EC2, a tarefa não será executada. Quando a tarefa falhar, a mensagem de erro a seguir aparecerá no `stoppedReason`: `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory`.

# Especificar transcodificação de vídeo em uma definição de tarefa do Amazon ECS
<a name="task-def-video-transcode"></a>

No exemplo abaixo, é fornecida a sintaxe utilizada para uma definição de tarefa de um contêiner Linux no Amazon EC2. Essa definição de tarefa refere-se a imagens de contêiner criadas de acordo com o procedimento fornecido na [documentação da Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage). Se você utilizar esse exemplo, substitua `image` por sua própria imagem e copie seus arquivos de vídeo para a instância no diretório `/home/ec2-user`.

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

1. Crie um arquivo de texto denominado `vt1-3xlarge-ffmpeg-linux.json`, com o seguinte conteúdo.

   ```
   {
       "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. Registre a definição de tarefa.

   ```
   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. Crie um arquivo de texto denominado `vt1-6xlarge-ffmpeg-linux.json`, com o seguinte conteúdo.

   ```
   {
       "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. Registre a definição de tarefa.

   ```
   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. Crie um arquivo de texto denominado `vt1-24xlarge-ffmpeg-linux.json`, com o seguinte conteúdo.

   ```
   {
       "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. Registre a definição de tarefa.

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

------

# Definições de tarefa do Amazon ECS para workloads de machine learning do AWS Neuron
<a name="ecs-inference"></a>

É possível registrar instâncias [Amazon EC2 Trn1](https://aws.amazon.com/ec2/instance-types/trn1/), [Amazon EC2 Trn2](https://aws.amazon.com/ec2/instance-types/trn2/), [Amazon EC2 Inf1](https://aws.amazon.com/ec2/instance-types/inf1/) e [Amazon EC2 Inf2](https://aws.amazon.com/ec2/instance-types/inf2/) em seus clusters para workloads de machine learning.

As instâncias Trn1 e Trn2 do Amazon EC2 são executadas em chips [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/). Essas instâncias oferecem treinamento de alta performance e baixo custo para machine learning na nuvem. É possível treinar um modelo de inferência de machine learning usando um framework de machine learning com o AWS Neuron em uma instância Trn1 ou Trn2. Em seguida, é possível executar o modelo em uma instância Inf1 ou uma instância Inf2 para usar a aceleração dos chips AWS Inferentia.

As instâncias Inf1 e as instâncias Inf2 do Amazon EC2 são executadas em chips [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Eles fornecem alta performance e inferência de menor custo na nuvem.

Modelos de machine learning são implantados em contêineres com o uso do [AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/), um kit de desenvolvimento de software (SDK)especializado. O SDK consiste em um compilador, runtime e ferramentas de criação de perfil que otimizam a performance de machine learning dos chips de machine learning da AWS. AWS O Neuron é compatível com frameworks de machine learning conhecidos, como TensorFlow, PyTorch e Apache MXNet.

## Considerações
<a name="ecs-inference-considerations"></a>

Antes de começar a implantar o Neuron no Amazon ECS, considere o seguinte:
+ Seus clusters podem conter uma combinação de instâncias Trn1, Trn2, Inf1, Inf2 e outras.
+ Você precisa de uma aplicação do Linux em um contêiner que use um framework de machine learning compatível com o AWS Neuron.
**Importante**  
Aplicações que usem outros frameworks podem não apresentar uma melhoria de performance nas instâncias Trn1, Trn2, Inf1 e Inf2.
+ Apenas uma tarefa de inferência ou de treinamento de inferência pode ser executada em cada chip [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) ou [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Para a Inf1, cada chip possui 4 NeuronCores. Para Trn1, Trn2 e Inf2, cada chip possui 2 NeuronCores. Você pode executar tantas tarefas quantos forem os chips disponíveis para cada uma de suas instâncias Trn1, Trn2, Inf1 e Inf2.
+ Ao criar um serviço ou executar uma tarefa autônoma, você pode usar atributos de tipo de instância ao configurar as restrições de posicionamento de tarefas. Assim, você se certifica de que a tarefa será iniciada na instância de contêiner que você especificar. Isso pode ajudar você a otimizar o uso dos recursos em geral e garantir que as tarefas para workloads de inferência ocorram nas instâncias Trn1, Trn2, Inf1 e Inf2. Para obter mais informações, consulte [Como o Amazon ECS posiciona tarefas em instâncias de contêineres](task-placement.md).

  No exemplo a seguir, uma tarefa é executada em uma instância `Inf1.xlarge` do 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"
  ```
+ Os requisitos de recursos do Neuron não podem ser definidos em uma definição de tarefa. Em vez disso, você configura um contêiner para usar os chips AWS Trainium ou AWS Inferentia específicos, disponíveis na instância de contêiner host. É possível fazer isso usando o parâmetro `linuxParameters` e especificando os detalhes do dispositivo. Para obter mais informações, consulte [Requisitos de definição de tarefa](#ecs-inference-requirements).

## Usar a AMI do Amazon Linux 2023 (Neuron) otimizada para o Amazon ECS
<a name="ecs-inference-ami2023"></a>

O Amazon ECS fornece uma AMI otimizada para o Amazon ECS que se baseia no Amazon Linux 2023 para workloads do AWS Trainium e do AWS Inferentia. Ela vem com drivers do AWS Neuron e runtime para Docker. Essa AMI facilita a execução de workloads de inferência de machine learning no Amazon ECS.

Recomendamos usar a AMI do Amazon Linux 2023 (Neuron) otimizada para o Amazon ECS ao iniciar as instâncias Trn1, Inf1 e Inf2 do Amazon EC2. 

É possível recuperar a AMI atual do Amazon Linux 2023 (Neuron) otimizada para o Amazon ECS ao usar a AWS CLI com o comando a seguir.

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

## Requisitos de definição de tarefa
<a name="ecs-inference-requirements"></a>

Para implantar o Neuron no Amazon ECS, sua definição de tarefa deve conter a definição do contêiner para um contêiner pré-criado servindo o modelo de inferência do TensorFlow. Além disso, é fornecido por contêiners do AWS Deep Learning. O contêiner possui o runtime do AWS Neuron e a aplicação TensorFlow Serving. No startup, esse container busca o modelo no Amazon S3, inicia o serviço do Neuron TensorFlow com o modelo salvo e aguarda as solicitações de previsão. No exemplo a seguir, a imagem de contêiner tem o TensorFlow 1.15 e o Ubuntu 18.04. Uma lista completa de Deep Learning Containers pré-criados otimizados para Neuron é mantida no GitHub. Para obter mais informações, consulte [Uso do AWS Neuron TensorFlow Serving](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-inferentia-tf-neuron-serving.html).

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

Como alternativa, é possível criar sua própria imagem de contêiner de arquivo associado do Neuron. Para obter mais informações, consulte [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) no *Guia do desenvolvedor do AMIs de deep learning da AWS*.

A definição de tarefa deve ser específica de um único tipo de instância. É necessário configurar um contêiner para usar os dispositivos AWS Trainium ou AWS Inferentia específicos, disponíveis na instância de contêiner host. Para isso, use o parâmetro `linuxParameters`. Para ver um exemplo de definição de tarefa, consulte [Especificar machine learning do AWS Neuron em uma definição de tarefa do Amazon ECS](ecs-inference-task-def.md). A tabela a seguir detalha os chips específicos de cada tipo de instância.


| Tipo de instância | vCPUs | RAM (GiB) | Chips aceleradores de ML AWS | Caminhos de dispositivos | 
| --- | --- | --- | --- | --- | 
| 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 | 

# Especificar machine learning do AWS Neuron em uma definição de tarefa do Amazon ECS
<a name="ecs-inference-task-def"></a>

Veja a seguir um exemplo de definição de tarefa do Linux para `inf1.xlarge`, mostrando a sintaxe a ser usada.

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

# Definições de tarefa do Amazon ECS para instâncias de aprendizado profundo
<a name="ecs-dl1"></a>

Para utilizar workloads de aprendizado profundo no Amazon ECS, registre instâncias [DL1 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/dl1/) nos seus clusters. Instâncias DL1 do Amazon EC2 contam com a tecnologia dos aceleradores Gaudi da Habana Labs (uma empresa Intel). Utilize o Habana SynapseAI SDK para se conectar aos aceleradores Habana Gaudi. O SDK é compatível com frameworks de machine learning populares, como TensorFlow e PyTorch.

## Considerações
<a name="ecs-dl1-considerations"></a>

Antes de começar a implantar a DL1 no Amazon ECS, considere o seguinte:
+ Seus clusters podem conter uma combinação de instâncias DL1 e não DL1.
+ Ao criar um serviço ou executar uma tarefa autônoma, você pode usar atributos de tipo de instância especificamente ao configurar restrições de posicionamento de tarefas para garantir que sua tarefa seja iniciada na instância de contêiner que você especificar. Isso garante que seus recursos sejam usados com eficiência e que suas tarefas para workloads de aprendizado profundo estejam em suas instâncias DL1. Para obter mais informações, consulte [Como o Amazon ECS posiciona tarefas em instâncias de contêineres](task-placement.md).

  O exemplo a seguir executa uma tarefa em uma instância `dl1.24xlarge` do 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"
  ```

## Utilizar uma AMI DL1
<a name="ecs-dl1-ami"></a>

Existem três opções para executar uma AMI em instâncias DL1 do Amazon EC2 para o Amazon ECS:
+ AMIs do AWS Marketplace que são fornecidas pela Habana [aqui](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq).
+ AMIs do Habana Deep Learning que são fornecidas pela Amazon Web Services. Como isso não está incluído, é necessário instalar o agente de contêiner do Amazon ECS separadamente.
+ Use o Packer para criar uma AMI personalizada que é fornecida pelo [repositório do GitHub](https://github.com/aws-samples/aws-habana-baseami-pipeline). Para obter mais informações, consulte [a documentação do Packer](https://developer.hashicorp.com/packer/docs).

# Especificar aprendizado profundo em uma definição de tarefa do Amazon ECS
<a name="ecs-dl1-requirements"></a>

Para executar contêineres acelerados de aprendizado profundo do Habana Gaudi no Amazon ECS, sua definição de tarefa precisa conter a definição de um contêiner pré-criado que serve o modelo de aprendizado profundo para o TensorFlow ou PyTorch utilizando o Habana SynapseAI fornecido por contêiners do AWS Deep Learning.

A imagem de contêiner a seguir tem o TensorFlow 2.7.0 e o Ubuntu 20.04. Uma lista completa de contêineres de aprendizado profundo pré-construídos otimizados para os aceleradores Habana Gaudi é mantida no GitHub. Para saber mais, consulte [Contêiners de treinamento da Habana](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers).

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

O exemplo a seguir é uma definição de tarefa para contêineres do Linux no Amazon EC2, exibindo a sintaxe a ser usada. Este exemplo utiliza uma imagem que contém a Habana Labs System Management Interface Tool (HL-SMI), disponível aqui: `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"
        }
    ]
}
```

# Definições de tarefa do Amazon ECS para workloads do ARM de 64 bits
<a name="ecs-arm64"></a>

O Amazon ECS suporta o uso de aplicações ARM de 64 bits. É possível executar aplicações na plataforma baseada em [processadores AWS Graviton](https://aws.amazon.com/ec2/graviton/). Ela é adequada para uma ampla variedade de workloads. Isso inclui workloads como servidores de aplicações, microsserviços, computação de alta performance, inferência de machine learning com base em CPU, codificação de vídeo, automação de design eletrônico, jogos, bancos de dados de código aberto e caches na memória.

## Considerações
<a name="ecs-arm64-considerations"></a>

Antes de começar a implantar definições de tarefa que usem a arquitetura ARM de 64 bits, considere o seguinte:
+ As aplicações podem usar o Fargate ou o EC2.
+ As aplicações só podem usar o sistema operacional Linux.
+ Para o tipo Fargate, as aplicações devem usar a versão da plataforma Fargate `1.4.0` ou posterior.
+ As aplicações podem usar Fluent Bit ou CloudWatch para monitoramento.
+ Para o Fargate, as seguintes Regiões da AWS não oferecem suporte a workloads ARM de 64 bits:
  + Leste dos EUA (Norte da Virgínia), a zona de disponibilidade `use1-az3`
+  No EC2, consulte o seguinte para verificar se a região em que você está oferece suporte ao tipo de instância desejado:
  + [Instâncias M6g do Amazon EC2](https://aws.amazon.com/ec2/instance-types/m6)
  +  [Instâncias T4g do Amazon EC2](https://aws.amazon.com/ec2/instance-types/t4/)
  +  [Instâncias C6g do Amazon EC2](https://aws.amazon.com/ec2/instance-types/c6g/)
  +  [Instâncias R6gd do Amazon EC2](https://aws.amazon.com/ec2/instance-types/r6/)
  +  [Instâncias X2gd do Amazon EC2](https://aws.amazon.com/ec2/instance-types/x2/)

  Também é possível usar o comando `describe-instance-type-offerings` do Amazon EC2 com um filtro para exibir a oferta de instâncias para sua região. 

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

  O exemplo a seguir verifica a disponibilidade do tipo de instância M6 na região Leste dos EUA (N. da Virgínia) (us-east-1).

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

  Para obter mais informações, consulte [describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html) na *Referência de linha de comando do Amazon EC2*.

# Especificar a arquitetura ARM em uma definição de tarefa do Amazon ECS
<a name="ecs-arm-specifying"></a>

Para usar a arquitetura ARM, especifique `ARM64` para o parâmetro de definição de tarefa `cpuArchitecture`. 

No exemplo abaixo, a arquitetura do ARM é especificada em uma definição de tarefa. Ele é no formato JSON.

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

No exemplo a seguir, uma definição de tarefa para a arquitetura ARM exibe “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"
}
```

# Envio de logs do Amazon ECS para o CloudWatch
<a name="using_awslogs"></a>

É possível configurar os contêineres das tarefas para enviar informações de log ao CloudWatch Logs. Se estiver usando o Fargate para suas tarefas, você poderá visualizar os logs dos seus contêineres. Se você estiver usando o EC2, poderá visualizar diferentes logs de contêineres em um local conveniente e evitar que esses logs ocupem espaço em disco nas instâncias de contêiner. 

**nota**  
O tipo de informações registradas em log pelos contêineres em sua tarefa depende principalmente do comando `ENTRYPOINT`. Por padrão, os logs capturados mostram a saída do comando que você normalmente veria em um terminal interativo, se executasse o contêiner localmente, que são os fluxos de E/S `STDOUT` e `STDERR`. O driver de log `awslogs` simplesmente envia esses logs do Docker para o CloudWatch Logs. Para obter mais informações sobre como os logs do Docker são processados, incluindo maneiras alternativas de capturar fluxos ou dados de arquivos diferentes, consulte [Visualizar logs de um contêiner ou serviço](https://docs.docker.com/engine/logging/) na documentação do Docker.

Para enviar logs do sistema de instâncias de contêiner do Amazon ECS para o CloudWatch Logs, consulte [Monitoração de arquivos de log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) e [Cotas de logs do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) no *Guia do usuário do Amazon CloudWatch Logs*.

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

Se você estiver usando o Fargate para suas tarefas, precisará adicionar os parâmetros `logConfiguration` necessários à sua definição de tarefa para ativar o driver de log `awslogs`. Para obter mais informações, consulte [Exemplo de definição de tarefa do Amazon ECS: rotear logs para o CloudWatch](specify-log-config.md).

No contêiner do Windows no Fargate, execute uma das seguintes opções quando qualquer um dos parâmetros de definição de tarefa tiver caracteres especiais, como :, `& \ < > ^ |`:
+ Adicione um escape (`\`) com aspas duplas em torno de toda a string do parâmetro

  Exemplo

  ```
  "awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"",
  ```
+ Adicione um caractere de escape (`^`) em torno de cada caractere especial

  Exemplo

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

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

Se você estiver usando o EC2 para suas tarefas e quer ativar o driver de log `awslogs`, suas instâncias de contêiner do Amazon ECS precisarão pelo menos da versão 1.9.0 do agente de contêiner. Para obter informações sobre como verificar a versão do agente e atualizar para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).

**nota**  
Você deve usar uma AMI otimizada para o Amazon ECS ou uma AMI personalizada com pelo menos a versão `1.9.0-1` do pacote `ecs-init`. Ao usar uma AMI personalizada, você deve especificar que o driver de registro em log `awslogs` está disponível na instância do Amazon EC2 ao iniciar o agente, usando a variável de ambiente a seguir na instrução **docker run** ou arquivo de variável de ambiente.  

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

As instâncias de contêiner do Amazon ECS também exigem permissão de `logs:CreateLogStream` e `logs:PutLogEvents` na função do IAM com a qual você inicia as instâncias de contêiner. Caso você tenha criado a função de instância de contêiner do Amazon ECS antes que o suporte ao driver de log `awslogs` tenha sido habilitado no Amazon ECS, talvez seja necessário adicionar essa permissão. A `ecsTaskExecutionRole` é usada quando é atribuída à tarefa e provavelmente contém as permissões corretas. Para obter informações sobre o perfil de execução de tarefas, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md). Se as instâncias de contêiner usarem a política do IAM gerenciada para instâncias de contêiner, as instâncias de contêiner terão provavelmente as permissões corretas. Para obter informações sobre a política do IAM gerenciada para instâncias de contêiner, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md).

# Exemplo de definição de tarefa do Amazon ECS: rotear logs para o CloudWatch
<a name="specify-log-config"></a>

Para os contêineres enviarem logs ao CloudWatch, você deve especificar o driver de log `awslogs` para contêineres na definição de tarefa. Para obter mais informações sobre os parâmetros de log, consulte [Armazenamento e registro](task_definition_parameters.md#container_definition_storage).

A definição de tarefa JSON a seguir tem um objeto `logConfiguration` especificado para cada contêiner. Um deles é para o contêiner do WordPress que envia logs a um grupo de logs denominado `awslogs-wordpress`. O outro é para um contêiner MySQL que envia logs a um grupo de logs denominado `awslogs-mysql`. Ambos os contêineres usam o prefixo de fluxo de log `awslogs-example`.

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

## Próximas etapas
<a name="specify-log-config-next-steps"></a>
+ Você também pode definir uma política de retenção para o grupo de logs usando a AWS CLI ou a API do CloudWatch. Para obter mais informações, consulte [put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) na *Referência da AWS Command Line Interface*.
+ Depois que tiver registrado uma definição de tarefa com o driver de log `awslogs` em uma configuração de log de definição de contêiner, será possível executar uma tarefa ou criar um serviço com essa definição de tarefa para começar a enviar logs ao CloudWatch Logs. Para obter mais informações, consulte [Execução de uma aplicação como uma tarefa do Amazon ECS](standalone-task-create.md) e [Criação de uma implantação de atualização contínua do Amazon ECS](create-service-console-v2.md).

# Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner
<a name="using_firelens"></a>

É possível usar o FireLens para Amazon ECS para usar parâmetros de definição de tarefa para encaminhar logs para um serviço da AWS ou um destino da AWS Partner Network (APN) para o armazenamento e analytics de logs. O AWS Partner Network é uma comunidade global de parceiros que utiliza programas, experiência e recursos para criar, comercializar e vender ofertas aos clientes. Para obter mais informações, consulte [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). O FireLens funciona com o [Fluentd](https://www.fluentd.org/) e o [Fluent Bit](https://fluentbit.io/). Fornecemos a imagem da AWS for Fluent Bit, ou é possível usar sua própria imagem do Fluentd ou Fluent Bit.

Por padrão, o Amazon ECS configura a dependência do contêiner para que o contêiner do Firelens comece antes de qualquer contêiner que o utiliza. O contêiner do Firelens também é interrompido depois que todos os contêineres que o usam são interrompidos.

Para usar esse recurso, é necessário criar uma função do IAM para suas tarefas que forneça as permissões necessárias para usar todos os serviços da AWS necessários para as tarefas. Por exemplo, se um contêiner estiver encaminhando logs para o Firehose, a tarefa exigirá permissão para chamar a API `firehose:PutRecordBatch`. Para obter mais informações, consulte [Adicionar e remover permissões de identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) no *Guia do usuário do IAM*.

Além disso, a tarefa pode requerer o perfil de execução de tarefas do Amazon ECS nas condições apresentadas a seguir. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md).
+ Se a tarefa for hospedada no Fargate e você estiver extraindo imagens de contêiner do Amazon ECR ou fazendo referência a dados sigilosos do AWS Secrets Manager na sua configuração de log, deverá incluir a função do IAM de execução de tarefas.
+ Ao usar um arquivo de configuração personalizado hospedado no Amazon S3, o perfil do IAM de execução de tarefas deve incluir a permissão `s3:GetObject`.

Considere o seguinte ao usar o FireLens para Amazon ECS:
+ Recomendamos adicionar `my_service_` ao nome do contêiner de log para distinguir facilmente os nomes dos contêineres no console.
+ Por padrão, o Amazon ECS adiciona uma dependência de ordem inicial de contêiner entre os contêineres da aplicação e o contêiner do FireLens. Quando você especifica uma ordem de contêiner entre os contêineres da aplicação e o contêiner do FireLens, a ordem inicial padrão do contêiner é substituída.
+ O FireLens para Amazon ECS é compatível com tarefas hospedadas no AWS Fargate no Linux e no Amazon EC2 no Linux. Os contêineres do Windows não são compatíveis com o FireLens.

  Para obter informações sobre como configurar o log centralizado para contêineres do Windows, consulte [Centralized logging for Windows containers on Amazon ECS using Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/) (Logs centralizados para contêineres do Windows no Amazon ECS usando o FluentBit).
+ É possível usar modelos do CloudFormation para configurar o FireLens para o Amazon ECS. Para obter mais informações, consulte [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html) no *Guia do usuário do AWS CloudFormation*
+ O FireLens escuta na porta `24224`. Portanto, para garantir que o roteador de log do FireLens não seja acessível fora da tarefa, você não deve permitir o tráfego de entrada na porta `24224` no grupo de segurança que a tarefa usa. Para as tarefas que usam o modo de rede `awsvpc` esse é o grupo de segurança associado à tarefa. Para as tarefas que usam o modo de rede `host` esse é o grupo de segurança associado à instância do Amazon EC2 que hospeda a tarefa. Para as tarefas que usam o modo de rede `bridge`, não crie qualquer mapeamento de porta que use porta `24224`.
+ Para tarefas que usam o modo de rede `bridge`, o contêiner com a configuração do FireLens deve ser iniciado antes que um contêiner de aplicativo que dependa dele seja iniciado. Para controlar a ordem inicial dos contêineres, use as condições de dependência na definição de tarefa. Para obter mais informações, consulte [Dependência de contêiner](task_definition_parameters.md#container_definition_dependson).
**nota**  
Se você usar parâmetros de condição de dependência em definições de contêiner com uma configuração do FireLens, verifique se cada contêiner tem um requisito de condição `START` ou `HEALTHY`.
+ Por padrão, o FireLens adiciona o nome de definição de cluster e o nome do recurso da Amazon (ARN) do cluster como chaves de metadados aos seus logs de contêiner stdout/stderr. O exemplo a seguir é do formato de metadados.

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

  Se não quiser os metadados nos seus logs, defina `enable-ecs-log-metadata` como `false`na seção `firelensConfiguration` da definição de tarefa.

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

Você pode configurar o contêiner FireLens para ser executado como usuário não raiz. Considere o seguinte:
+  Para configurar o contêiner FireLens para ser executado como usuário não raiz, você deve especificar o usuário em um dos seguintes formatos:
  + `uid`
  + `uid:gid`
  + `uid:group`

  Para obter mais informações sobre como especificar um usuário em uma definição de contêiner, consulte [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html) na *Referência de API do Amazon Elastic Container Service*.

  O contêiner FireLens recebe logs da aplicação por meio de um soquete UNIX. O agente do Amazon ECS usa o `uid` para atribuir a propriedade do diretório de soquetes ao contêiner FireLens.
+ A configuração do contêiner FireLens para ser executado como usuário não raiz é compatível com o Amazon ECS Agent versão `1.96.0` e posterior e com a AMI versão `v20250716` e posterior otimizada para o Amazon ECS.
+ Quando você especifica um usuário para o contêiner FireLens, o `uid` deve ser exclusivo e não ser usado para outros processos pertencentes a outros contêineres na tarefa ou na instância de contêiner.

Para obter informações sobre como usar vários arquivos de configuração com o Amazon ECS, incluindo arquivos hospedados por você ou arquivos no Amazon S3, consulte [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).

Para obter informações sobre configurações de exemplo, consulte [Exemplo de definição de tarefa do Amazon ECS: rotear logs para o FireLens](firelens-taskdef.md).

Para obter mais informações sobre como configurar logs para alto throughput, consulte [Configuração de logs do Amazon ECS para obtenção de alto throughput](firelens-docker-buffer-limit.md).

# Configuração de logs do Amazon ECS para obtenção de alto throughput
<a name="firelens-docker-buffer-limit"></a>

Para cenários com alto throughput de logs, recomendamos o uso do driver de log `awsfirelens` com o FireLens e o Fluent Bit. O Fluent Bit é um processador de log leve que é eficiente com recursos e capaz de lidar com milhões de registros de log. Porém, atingir o desempenho ideal em grande escala requer ajustar sua configuração.

Esta seção aborda técnicas avançadas de otimização de Fluent Bit para lidar com a alto throughput de logs e, ao mesmo tempo, manter a estabilidade do sistema e garantir que não haja perda de dados.

Para obter informações sobre como usar arquivos de configuração personalizados com o FireLens, consulte [Uso de um arquivo de configuração personalizado](firelens-taskdef.md#firelens-taskdef-customconfig). Para receber exemplos adicionais, consulte [Exemplos do FireLens do Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) no GitHub.

**nota**  
Algumas opções de configuração nesta seção, como `workers` e `threaded`, exigem o AWS para Fluent Bit versão 3 ou posterior. Para obter informações sobre versões disponíveis, consulte [Versões do AWS para Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases).

## Usar o processo de buffer do sistema de arquivos
<a name="firelens-filesystem-buffering"></a>

Por padrão, o Fluent Bit armazena em buffer todos os dados na memória. Quando os dados são inseridos mais rapidamente do que podem ser enviados para as saídas, o buffer fica cheio. Uma vez cheio, o plug-in de entrada faz uma pausa até que haja espaço disponível no buffer, o que pode causar contrapressão e tornar sua aplicação mais lenta.

Para cenários de alto throughput, recomendamos o uso do processo de buffer do sistema de arquivos. Para obter mais informações sobre como o Fluent Bit gerencia o processo de buffer e o armazenamento, consulte [Processo de buffer e armazenamento](https://docs.fluentbit.io/manual/administration/buffering-and-storage) na documentação do Fluent Bit.

O processo de buffer do sistema de arquivos oferece as seguintes vantagens:
+ **Maior capacidade de buffer**: o espaço em disco geralmente é mais abundante do que a memória.
+ **Persistência**: os dados armazenados em buffer persistem após as reinicializações do Fluent Bit.
+ **Degradação normal**: durante falhas de saída, os dados se acumulam no disco em vez de causarem esgotamento da memória.

Para habilitar o buffer do sistema de arquivos, forneça um arquivo de configuração personalizado do Fluent Bit. O exemplo a seguir mostra a configuração recomendada:

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

Principais parâmetros de configuração:

`storage.path`  
O diretório em que o Fluent Bit armazena os blocos armazenados em buffer no disco.

`storage.backlog.flush_on_shutdown`  
Quando habilitado, o Fluent Bit tenta liberar todos os blocos do sistema de arquivos de backlog para seus respectivos destinos durante o desligamento. Isso ajuda a garantir a entrega dos dados antes que o Fluent Bit pare, mas pode prolongar o tempo de desligamento.

`storage.max_chunks_up`  
O número de blocos que permanecem na memória. O padrão é 128 blocos, que podem consumir mais de 500 MB de memória, pois cada bloco pode usar até 4–5 MB. Em ambientes com memória limitada, reduza esse valor. Por exemplo, se você tiver 50 MB disponíveis para buffer, defina isso como 8–10 blocos.

`storage.type filesystem`  
Habilita o armazenamento do sistema de arquivos para o plug-in de entrada. Apesar do nome, o Fluent Bit usa `mmap` para mapear fragmentos na memória e no disco, fornecendo persistência sem sacrificar o desempenho.

`threaded true`  
Executa a entrada em seu próprio thread, separado do loop de eventos principal do Fluent Bit. Isso evita que entradas lentas bloqueiem todo o pipeline.

## Otimizar a configuração de saída
<a name="firelens-output-optimization"></a>

Problemas de rede, interrupções no serviço e controle de utilização de destino podem impedir a entrega dos logs. A configuração adequada da saída garante resiliência sem perda de dados.

Quando uma descarga de saída falha, o Fluent Bit pode repetir a operação. Os seguintes parâmetros controlam o comportamento de novas tentativas:

`retry_limit`  
O número máximo de novas tentativas antes de descartar registros. O padrão é 1. Para ambientes de produção, recomendamos 15 ou mais, o que cobre vários minutos de interrupção com recuo exponencial.

`scheduler.base`  
O mínimo de segundos entre novas tentativas. Recomendamos 10 segundos.

`scheduler.cap`  
O máximo de segundos entre novas tentativas ao usar o recuo exponencial. Recomendamos 60 segundos.

`workers`  
O número de threads para processamento de saída paralelo. Vários operadores permitem descargas simultâneas, melhorando o throughput ao processar muitos blocos.

O parâmetro `Grace` na seção `[SERVICE]` define o tempo de espera do Fluent Bit durante o desligamento para limpar os dados em buffer. O período de `Grace` deve ser coordenado com o `stopTimeout` do contêiner. Certifique-se de que `stopTimeout` exceda o período de `Grace` para permitir que o Fluent Bit faça a descarga completa antes de receber `SIGKILL`. Por exemplo, se `Grace` for 120 segundos, defina `stopTimeout` como 150 segundos.

O exemplo a seguir mostra uma configuração completa de Fluent Bit com todas as definições recomendadas para cenários de alto throughput:

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

## Usar o registro em log em vários destinos para confiabilidade
<a name="firelens-multi-destination"></a>

O envio de logs para vários destinos elimina pontos únicos de falha. Por exemplo, se o Amazon CloudWatch Logs sofrer uma interrupção, os logs ainda chegarão ao Amazon S3.

O registro em log em vários destinos oferece os seguintes benefícios. O plug-in de saída do Amazon S3 também oferece suporte a opções de compactação, como gzip e formato Parquet, que podem reduzir os custos de armazenamento. Para mais informações, consulte [Compactação do S3](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) na documentação do Fluent Bit.

O registro em log em vários destinos pode oferecer os seguintes benefícios:
+ **Redundância**: se um destino falhar, os logs ainda chegarão ao outro.
+ **Recuperação**: reconstrua lacunas em um sistema a partir do outro.
+ **Durabilidade**: arquive logs no Amazon S3 para retenção de longo prazo.
+ **Otimização de custos**: mantenha logs recentes em um serviço de consulta rápida, como o Amazon CloudWatch Logs, com retenção mais curta, enquanto arquiva todos os logs no armazenamento do Amazon S3 de baixo custo para retenção de longo prazo.

A configuração do Fluent Bit a seguir envia logs ao Amazon CloudWatch Logs e ao 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
```

Como ambas as saídas usam o mesmo padrão `Match *`, todos os registros são enviados aos dois destinos de maneira independente. Durante uma interrupção em um destino, os logs continuam fluindo para o outro, enquanto as descargas com falha se acumulam no buffer do sistema de arquivos para uma nova tentativa posterior.

## Usar o log com base em arquivo com o plug-in de entrada tail
<a name="firelens-tail-input"></a>

Para cenários de alto throughput em que a perda de logs é uma preocupação crítica, é possível usar uma abordagem alternativa: fazer com que sua aplicação grave os logs em arquivos no disco e configurar o Fluent Bit para lê-los usando o plug-in de entrada `tail`. Essa abordagem ignora completamente a camada do driver de log do Docker.

O registro em log baseado em arquivo com o plug-in tail oferece os seguintes benefícios:
+ **Rastreamento de deslocamento**: o plug-in tail pode armazenar deslocamentos de arquivos em um arquivo de banco de dados (usando a opção `DB`), proporcionando durabilidade entre reinicializações do Fluent Bit. Isso ajuda a evitar a perda de logs durante a reinicialização do contêiner.
+ **Processo de buffer em nível de entrada**: é possível configurar limites de buffer de memória diretamente no plug-in de entrada usando `Mem_Buf_Limit`, fornecendo um controle mais granular sobre o uso da memória.
+ **Evita a sobrecarga do Docker**: os logs vão diretamente do arquivo para o Fluent Bit sem passarem pelos buffers de log do Docker.

Para usar essa abordagem, sua aplicação deve gravar logs em arquivos em vez de `stdout`. Tanto o contêiner da aplicação quanto o contêiner do Fluent Bit montam um volume compartilhado onde os arquivos de log são armazenados.

O exemplo a seguir mostra uma configuração de entrada de cauda com práticas recomendadas:

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

Ao usar o plug-in de entrada tail, considere o seguinte:
+ Implemente a alternância de logs para os logs da sua aplicação para evitar o esgotamento do disco. Monitore as métricas de volume subjacentes para avaliar a performance.
+ Considere configurações como `Ignore_Older`, `Read_from_Head` e analisadores multilinha com base no formato do seu log.

Para mais informações, consulte [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail) na documentação do Fluent Bit. Para conhecer as práticas recomendadas, consulte [Configuração do Tail com práticas recomendadas](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices), no guia de solução de problemas da AWS para Fluent Bit.

## Registrar em log diretamente no FireLens
<a name="firelens-environment-variables"></a>

Quando o driver de log `awsfirelens` for especificado em uma definição de tarefa, o agente do Amazon ECS injetará as seguintes variáveis de ambiente no contêiner:

`FLUENT_HOST`  
O endereço IP atribuído ao contêiner do FireLens.  
Se você estiver usando o EC2 com o modo de rede `bridge`, a variável de ambiente `FLUENT_HOST` no contêiner da aplicação poderá se tornar imprecisa após uma reinicialização do contêiner do roteador de log do FireLens (o contêiner com o objeto `firelensConfiguration` na definição de contêiner). Isso ocorre porque o `FLUENT_HOST` é um endereço IP dinâmico e pode mudar após uma reinicialização. O registro em log diretamente do contêiner da aplicação para o endereço IP do `FLUENT_HOST` pode começar a falhar após a alteração do endereço. Para obter mais informações sobre como reiniciar contêineres individuais, consulte [Reiniciar contêineres individuais em tarefas do Amazon ECS com políticas de reinicialização de contêineres](container-restart-policy.md).

`FLUENT_PORT`  
A porta em que o protocolo Fluent Forward está escutando.

Você pode usar essas variáveis de ambiente para registrar diretamente no roteador de log do Fluent Bit a partir do código da sua aplicação usando o protocolo Fluent Forward, em vez de gravar no `stdout`. Essa abordagem ignora a camada do driver de log do Docker, o que oferece os seguintes benefícios:
+ **Menor latência**: os logs vão diretamente para o Fluent Bit sem passarem pela infraestrutura de registro em log do Docker.
+ **Registro em log estruturado**: envie dados de log estruturados de maneira nativa sem sobrecarga de codificação JSON.
+ **Melhor controle**: sua aplicação pode implementar sua própria lógica de buffer e tratamento de erros.

As seguintes bibliotecas de agente de log Fluent são compatíveis com o protocolo Fluent Forward e podem ser usadas para enviar logs diretamente para o 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)

## Configurar o limite de buffer do Docker
<a name="firelens-buffer-limit"></a>

Ao criar uma definição de tarefa, você pode especificar o número de linhas de log que são armazenadas em buffer na memória especificando o valor em `log-driver-buffer-limit`. Isso controla o buffer entre o Docker e o Fluent Bit. Para obter mais informações, consulte [Driver de registro do Fluentd](https://docs.docker.com/engine/logging/drivers/fluentd/) na documentação do Docker.

Use essa opção quando houver throughput alto, porque o Docker pode ficar sem memória buffer e descartar mensagens de buffer para que ele possa adicionar novas mensagens.

Considere o seguinte ao usar essa opção:
+ Essa opção é compatível com o tipo EC2 e Fargate com a versão da plataforma `1.4.0` ou posterior.
+ A opção só é válida quando `logDriver` estiver definido como `awsfirelens`.
+ O limite de buffer padrão é de `1048576` linhas de log.
+ O limite de buffer deve ser maior ou igual a `0` ou menor que as linhas de log `536870912`.
+ A quantidade máxima de memória usada para esse buffer é o produto do tamanho de cada linha de log pelo tamanho do buffer. Por exemplo, se as linhas de log da aplicação tivessem em média `2` KiB, um limite de buffer de 4096 usaria no máximo `8` MiB. A quantidade total de memória alocada no nível da tarefa deve ser maior que a quantidade de memória alocada para todos os contêineres, mais o limite de buffer da memória.

A seguinte definição de tarefa mostra como configurar `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
        }
    ]
}
```

# Repositórios de imagens da AWS para Fluent Bit para Amazon ECS
<a name="firelens-using-fluentbit"></a>

A AWS fornece uma imagem do Fluent Bit com plug-ins para o CloudWatch Logs e o Firehose. Recomendamos usar o Fluent Bit como seu roteador de log porque ele tem uma taxa de utilização de recursos mais baixa do que o Fluentd. Para obter mais informações, consulte [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) e [Amazon Kinesis Firehose for Fluent Bit](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit).

A imagem da **AWS para Fluent Bit** está disponível no Amazon ECR na Galeria Pública do Amazon ECR e em um repositório do Amazon ECR para alta disponibilidade.

## Galeria pública do Amazon ECR
<a name="firelens-image-ecrpublic"></a>

A imagem do AWS for Fluent Bit está disponível na Galeria Pública do Amazon ECR. Esse é o local recomendado para baixar a imagem da AWS for Fluent Bit, uma vez que é um repositório público e está disponível para ser usado em todas as Regiões da AWS. Para obter mais informações, consulte [aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit) na Galeria Pública do Amazon ECR.

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

A imagem da AWS para Fluent Bit na Galeria Pública do Amazon ECR é compatível com o sistema operacional Amazon Linux com a arquitetura `ARM64` ou `x86-64`.

É possível extrair a imagem do AWS for Fluent Bit da Galeria Pública do Amazon ECR especificando o URL do repositório com a etiqueta de imagem desejada. As etiquetas de imagem disponíveis podem ser encontradas na guia **Image tags** (Etiquetas de imagem) na Galeria Pública do Amazon ECR.

Veja a seguir a sintaxe a ser usada para a CLI do Docker.

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

Por exemplo, você pode obter a imagem mais recente da família “3.x” de versões do AWS para Fluent Bit usando este comando da CLI do Docker.

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

**nota**  
Extrações não autenticadas são permitidas, mas têm um limite de taxa mais baixo do que as extrações autenticadas. Para autenticar usando a conta da AWS antes da extração, use o seguinte comando.  

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

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

Além das versões existentes da AWS para Fluent Bit `2.x`, a AWS para Fluent Bit oferece suporte a uma nova versão principal `3.x`. A nova versão principal inclui a atualização do Amazon Linux 2 para o Amazon Linux 2023 e do Fluent Bit versão `1.9.10` para `4.1.1`. Para obter mais informações, consulte [Repositório da AWS para Fluent Bit](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) no GitHub.

Os exemplos a seguir demonstram tags atualizadas para imagens da AWS para Fluent Bit `3.x`:

Você pode usar tags de várias arquiteturas para a imagem da AWS para Fluent Bit.

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

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

A imagem do Fluent Bit para AWS na Galeria pública do Amazon ECR é compatível com a arquitetura `AMD64` dos seguintes sistemas operacionais:
+ Windows Server 2022 Full
+ Windows Server 2022 Core
+ Windows Server 2019 Full
+ Windows Server 2019 Core

Contêineres do Windows que estão na AWS não oferecem suporte ao FireLens.

É possível extrair a imagem do AWS for Fluent Bit da Galeria Pública do Amazon ECR especificando o URL do repositório com a etiqueta de imagem desejada. As etiquetas de imagem disponíveis podem ser encontradas na guia **Image tags** (Etiquetas de imagem) na Galeria Pública do Amazon ECR.

Veja a seguir a sintaxe a ser usada para a CLI do Docker.

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

Por exemplo, você pode extrair a imagem estável mais recente do AWS para Fluent Bit usando este comando da CLI do Docker.

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

**nota**  
Extrações não autenticadas são permitidas, mas têm um limite de taxa mais baixo do que as extrações autenticadas. Para autenticar usando a conta da AWS antes da extração, use o seguinte 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>

A imagem da AWS for Fluent Bit está disponível no Amazon ECR para a obtenção de alta disponibilidade. Os comandos a seguir podem ser usados para recuperar URIs de imagem e estabelecer a disponibilidade da imagem em uma determinada Região da AWS.

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

O URI da imagem estável mais recente do AWS for Fluent Bit pode ser recuperado por meio do seguinte comando.

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

Todas as versões da imagem da AWS for Fluent Bit podem ser listadas por meio do seguinte comando para consultar o parâmetro do Systems Manager Parameter Store.

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

A imagem estável mais recente do AWS para Fluent Bit pode ser especificada em um modelo do CloudFormation mediante a menção do nome de armazenamento de parâmetros do Systems Manager. Este é um exemplo:

```
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 o comando falhar ou não houver saída, a imagem não estará disponível na Região da AWS em que o comando é chamado.

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

O URI da imagem estável mais recente do AWS for Fluent Bit pode ser recuperado por meio do seguinte comando.

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

Todas as versões da imagem da AWS for Fluent Bit podem ser listadas por meio do seguinte comando para consultar o parâmetro do Systems Manager Parameter Store.

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

A imagem estável mais recente do AWS for Fluent Bit pode ser especificada em um modelo do CloudFormation ao fazer referência ao nome de armazenamento de parâmetros do Systems Manager. Veja um exemplo a seguir.

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

# Exemplo de definição de tarefa do Amazon ECS: rotear logs para o FireLens
<a name="firelens-taskdef"></a>

Para usar o roteamento de log personalizado com o FireLens, é necessário especificar o seguinte em sua definição de tarefa:
+ Um contêiner de roteador de log com uma configuração do FireLens. Recomendamos que o contêiner seja marcado como `essential`.
+ Um ou mais contêineres de aplicativo que contêm uma configuração de log especificando o driver de log `awsfirelens`.
+ Um nome do recurso da Amazon (ARN) de perfil do IAM que contém as permissões necessárias para que a tarefa roteie os logs.

Ao criar uma nova definição de tarefa usando o Console de gerenciamento da AWS, há uma seção de integração do FireLens que facilita a adição de um contêiner de roteador de log. Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md).

O Amazon ECS converte a configuração de log e gera a configuração de saída do Fluentd ou Fluent Bit. A configuração de saída é montada no contêiner de roteamento de log em `/fluent-bit/etc/fluent-bit.conf` para o Fluent Bit e `/fluentd/etc/fluent.conf` para o Fluentd.

**Importante**  
O FireLens escuta na porta `24224`. Portanto, para garantir que o roteador de log do FireLens não seja acessível fora da tarefa, você não deve permitir tráfego de entrada na porta `24224` no grupo de segurança usado por essa tarefa. Para tarefas que usam o modo de rede `awsvpc`, esse é o grupo de segurança associado à tarefa. Para as tarefas que usam o modo de rede `host` esse é o grupo de segurança associado à instância do Amazon EC2 que hospeda a tarefa. Para as tarefas que usam o modo de rede `bridge`, não crie qualquer mapeamento de porta que use porta `24224`.

Por padrão, o Amazon ECS adiciona campos às entradas de log que ajudam a identificar a fonte dos logs. 
+ `ecs_cluster`: o nome do cluster do qual a tarefa faz parte.
+ `ecs_task_arn`: o nome do recurso da Amazon (ARN) da tarefa da qual o contêiner faz parte.
+ `ecs_task_definition`: o nome da definição de tarefa e a revisão que a tarefa está usando.
+ `ec2_instance_id`: o ID da instância do Amazon EC2 na qual o contêiner está hospedado. Esse campo só é válido para tarefas que usam o tipo de inicialização do EC2.

Você pode definir os `enable-ecs-log-metadata` como `false` se não quiser os metadados.

O exemplo de definição de tarefa a seguir define um contêiner de roteador de log que usa o Fluent para encaminhar seus logs para o CloudWatch Logs. Ele também define um contêiner de aplicação que usa uma configuração de log para encaminhar logs ao Amazon Data Firehose e definir a memória usada para eventos de buffer como 2 MiB.

**nota**  
Para obter exemplos de definições de tarefas, consulte [Exemplos do FireLens do Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) no 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
    }
  ]
}
```

Os pares de chave/valor especificados como opções no objeto `logConfiguration` são usados para gerar a configuração de saída do Fluentd ou do Fluent Bit. Veja a seguir um exemplo de código de uma definição de saída do Fluent Bit.

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

**nota**  
O FireLens gerencia a configuração `match`. Você não especifica a configuração `match` na definição de tarefa. 

## Uso de um arquivo de configuração personalizado
<a name="firelens-taskdef-customconfig"></a>

É possível especificar um arquivo de configuração personalizado. O formato do arquivo de configuração é o formato nativo do roteador de log que você está usando. Para obter mais informações, consulte [Sintaxe do arquivo de configuração do Fluentd](https://docs.fluentd.org/configuration/config-file) e [Configuração YAML](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml).

Em seu arquivo de configuração personalizado, para tarefas que usam o modo de rede `bridge` ou `awsvpc`, não defina uma entrada de encaminhamento do Fluentd ou Fluent Bit por TCP porque o FireLens a adiciona à configuração de entrada.

Sua configuração do FireLens deve conter as seguintes opções para especificar um arquivo de configuração personalizado:

`config-file-type`  
O local de origem do arquivo de configuração personalizado. As opções disponíveis são `s3` ou `file`.  
Tarefas hospedadas no AWS Fargate só são compatíveis com o tipo de arquivo de configuração `file`. No entanto, você pode usar arquivos de configuração hospedados no Amazon S3 no AWS Fargate usando o contêiner init do AWS para Fluent Bit. Para obter mais informações, consulte [Processo Init para o Fluent Bit no ECS, suporte para várias configurações](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md), no GitHub.

`config-file-value`  
A origem do arquivo de configuração personalizado. Se for usado o tipo de arquivo de configuração `s3`, o valor do arquivo de configuração será o ARN completo do arquivo e do bucket do Amazon S3. Se o tipo de arquivo de configuração `file` for usado, o valor do arquivo de configuração será o caminho completo do arquivo de configuração que existe na imagem do contêiner ou em um volume montado no contêiner.  
Quando você usa um arquivo de configuração personalizado, precisa especificar um caminho diferente do que o FireLens usa. O Amazon ECS reserva o caminho de arquivo `/fluent-bit/etc/fluent-bit.conf` para o Fluent Bit e `/fluentd/etc/fluent.conf` para o Fluentd.

O exemplo a seguir mostra a sintaxe necessária ao especificar uma configuração personalizada.

**Importante**  
Para especificar um arquivo de configuração personalizado hospedado no Amazon S3, verifique se criou uma função do IAM de execução de tarefas com as permissões apropriadas. 

Veja a seguir a sintaxe necessária ao especificar uma configuração personalizada.

```
{
  "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**  
Tarefas hospedadas no AWS Fargate só são compatíveis com o tipo de arquivo de configuração `file`. No entanto, você pode usar arquivos de configuração hospedados no Amazon S3 no AWS Fargate usando o contêiner init do AWS para Fluent Bit. Para obter mais informações, consulte [Processo Init para o Fluent Bit no ECS, suporte para várias configurações](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md), no GitHub.

# Uso de imagens de contêiner que não são da AWS no Amazon ECS
<a name="private-auth"></a>

Use o registro privado para armazenar suas credenciais no AWS Secrets Manager e referenciá-las na definição de tarefa. Isso fornece uma maneira de fazer referência a imagens de contêiner que existem em registros privados fora da AWS que exijam autenticação em suas definições de tarefa. Há suporte para esse recurso em tarefas hospedadas no Fargate, instâncias do Amazon EC2 e instâncias externas usando o Amazon ECS Anywhere.

**Importante**  
Se a definição de tarefa faz referência a uma imagem armazenada no Amazon ECR, esse tópico não se aplica. Para obter mais informações, consulte [Usar imagens do Amazon ECR com o Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) no *Guia do usuário do Amazon Elastic Container Registry*.

Para tarefas hospedadas em instâncias do Amazon EC2, sesse recurso requer a versão `1.19.0` ou posterior do agente de contêiner. Recomendamos usar a versão mais recente do atendente de contêiner. Para obter informações sobre como verificar a versão do agente e atualizar para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).

Para tarefas hospedadas no Fargate, esse recurso requer a versão da plataforma `1.2.0` ou posterior. Para mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).

Em sua definição do contêiner, especifique o objeto `repositoryCredentials` com os detalhes do segredo que você criou. O segredo referenciado pode estar em uma Região da AWS diferente ou em uma conta distinta daquela que o utiliza para a tarefa.

**nota**  
Quando você usar a API do Amazon ECS, a AWS CLI ou o AWS SDK, se o segredo existir na mesma Região da AWS da tarefa que estiver sendo inicializada, será possível usar o ARN completo ou o nome do segredo. Se o segredo existir em outra conta, o ARN completo do segredo deve ser especificado. Ao usar o Console de gerenciamento da AWS, o ARN completo do segredo deve ser sempre especificado.

Veja a seguir um trecho de uma definição de tarefa que mostra os parâmetros necessários.

Substitua os seguintes parâmetros:
+ *private-repo* pelo nome do host do repositório privado 
+ *private-image* pelo nome da imagem
+ *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name* com o nome do recurso da Amazon (ARN) secreto

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

**nota**  
Outro método para habilitar a autenticação de registro privado usa variáveis de ambiente do atendente de contêiner do Amazon ECS para autenticar registros privados. Só há suporte para esse método para tarefas hospedadas em instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração de instâncias de contêiner do Amazon ECS para imagens do Docker privadas](private-auth-container-instances.md).

**Para usar o registro privado**

1. A definição de tarefa deve ter um perfil de execução de tarefas. Isso permite que o atendente de contêiner obtenha a imagem do contêiner. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md).

   A autenticação de registro privado permite que suas tarefas do Amazon ECS extraiam imagens de contêiner de registros privados fora da AWS (como Docker Hub, Quay.io ou seu próprio registro privado) que exijam credenciais de autenticação. Esse recurso usa o Secrets Manager para armazenar com segurança suas credenciais de registro, que serão mencionadas na definição da tarefa usando o parâmetro `repositoryCredentials`.

   Para obter mais informações sobre como configurar a autenticação de registro privado, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).

   Para fornecer acesso aos segredos que contêm suas credenciais de registro privado, adicione as permissões a seguir como uma política em linha à função de execução da tarefa. Para obter mais informações, consulte [Adicionar e remover políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
   + `secretsmanager:GetSecretValue`: obrigatório para recuperar as credenciais do registro privado do Secrets Manager.
   + `kms:Decrypt`: obrigatório somente se o segredo usar uma chave personalizada KMS e não a chave padrão. O nome do recurso da Amazon (ARN) da chave personalizada deve ser adicionado como um recurso.

   Veja a seguir um exemplo de política em linha que adiciona as permissões.

------
#### [ 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. Use o AWS Secrets Manager para criar um segredo para suas credenciais de registro privado. Para obter informações sobre como criar segredos, consulte [Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) no *Guia do usuário do AWS Secrets Manager*.

   Insira suas credenciais de registro privado usando o seguinte formato:

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

1. Registre uma definição de tarefa. Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md).

# Reiniciar contêineres individuais em tarefas do Amazon ECS com políticas de reinicialização de contêineres
<a name="container-restart-policy"></a>

Você pode habilitar uma política de reinicialização para cada contêiner essencial e não essencial definido na sua definição de tarefa, para superar falhas transitórias mais rapidamente e manter a disponibilidade da tarefa. Quando você habilita uma política de reinicialização para um contêiner, o Amazon ECS pode reiniciar o contêiner se ele sair, sem precisar substituir a tarefa.

Por padrão, as políticas de reinicialização não estão habilitadas para contêineres. Ao habilitar uma política de reinicialização para um contêiner, você pode especificar códigos de saída nos quais o contêiner não será reiniciado. Eles podem ser códigos de saída que indicam sucesso, como o código de saída `0`, que não exige reinicialização. Você também pode especificar por quanto tempo um contêiner deve ser executado com sucesso antes que uma reinicialização possa ser tentada. Para mais informações sobre esses parâmetros, consulte [Política de reinicialização](task_definition_parameters.md#container_definition_restart_policy). Para obter um exemplo de definição de tarefa que especifica esses valores, consulte [Especificar a política de reinicialização de contêiner em uma definição de tarefa do Amazon ECS](container-restart-policy-example.md).

Você pode usar o endpoint de metadados de tarefas do Amazon ECS ou o CloudWatch Container Insights para monitorar o número de vezes que um contêiner foi reiniciado. Para obter mais informações sobre o endpoint de metadados de tarefa, consulte [Endpoint de metadados de tarefas do Amazon ECS versão 4](task-metadata-endpoint-v4.md) e [Endpoint de metadados de tarefas do Amazon ECS versão 4 para tarefas no Fargate](task-metadata-endpoint-v4-fargate.md). Para obter informações sobre métricas do Container Insights para o Amazon ECS, consulte [Métricas Amazon ECS Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) no *Guia de Usuário do Amazon CloudWatch*.

Há suporte para políticas de reinicialização de contêiner em tarefas hospedadas no Fargate, instâncias do Amazon EC2 e instâncias externas usando o Amazon ECS Anywhere.

## Considerações
<a name="container-restart-policy-considerations"></a>

Considere o seguinte antes de habilitar uma política de reinicialização para seu contêiner:
+ As políticas de reinicialização não são compatíveis com contêineres do Windows no Fargate.
+ Para tarefas hospedadas em instâncias do Amazon EC2, sesse recurso requer a versão `1.86.0` ou posterior do agente de contêiner. Recomendamos usar a versão mais recente do atendente de contêiner. Para obter informações sobre como verificar a versão do agente e atualizar para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).
+ Se você estiver usando o EC2 com o modo de rede `bridge`, a variável de ambiente `FLUENT_HOST` no contêiner da aplicação poderá se tornar imprecisa após uma reinicialização do contêiner do roteador de log do FireLens (o contêiner com o objeto `firelensConfiguration` na definição de contêiner). Isso ocorre porque o `FLUENT_HOST` é um endereço IP dinâmico e pode mudar após uma reinicialização. O registro em log diretamente do contêiner da aplicação para o endereço IP do `FLUENT_HOST` pode começar a falhar após a alteração do endereço. Para obter mais informações sobre o `FLUENT_HOST`, consulte [Configuração de logs do Amazon ECS para obtenção de alto throughput](firelens-docker-buffer-limit.md).
+ O agente do Amazon ECS gerencia as políticas de reinicialização do contêiner. Se, por algum motivo inesperado, o agente do Amazon ECS falhar ou não estiver mais em execução, o contêiner não será reiniciado.
+  O período de tentativa de reinicialização definido em sua política determina o período de tempo (em segundos) durante o qual o contêiner deve funcionar antes que o Amazon ECS reinicie um contêiner.

# Especificar a política de reinicialização de contêiner em uma definição de tarefa do Amazon ECS
<a name="container-restart-policy-example"></a>

Para especificar uma política de reinicialização para um contêiner em uma definição de tarefa, na definição do contêiner, especifique o objeto `restartPolicy`. Para obter mais informações sobre o objeto `restartPolicy`, consulte [Política de reinicialização](task_definition_parameters.md#container_definition_restart_policy).

Veja a seguir uma definição de tarefa usando os contêineres do Linux no Fargate que configura um servidor web. A definição do contêiner inclui o objeto `restartPolicy`, com `enabled` definido como true para permitir uma política de reinicialização para o contêiner. O contêiner deve ser executado por 180 segundos antes de poder ser reiniciado e não será reiniciado se sair com o código de saída `0`, o que indica sucesso.

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

Depois que tiver registrado uma definição de tarefa com o objeto `restartPolicy` em uma definição de contêiner, você poderá executar uma tarefa ou criar um serviço com a definição de tarefa. Para obter mais informações, consulte [Execução de uma aplicação como uma tarefa do Amazon ECS](standalone-task-create.md) e [Criação de uma implantação de atualização contínua do Amazon ECS](create-service-console-v2.md).

# Transferência de dados confidenciais para um contêiner do Amazon ECS
<a name="specifying-sensitive-data"></a>

É possível transmitir dados confidenciais (p. ex., credenciais de um banco de dados) para seu contêiner com segurança. 

Os segredos, como as chaves de API e as credenciais de banco de dados, são frequentemente usados por aplicações para obter acesso a outros sistemas. Eles geralmente consistem em um nome de usuário e senha, um certificado ou uma chave de API. O acesso a esses segredos deve ser restrito a entidades principais específicas do IAM que estejam usando o IAM, e injetados em contêineres no runtime.

Os segredos podem ser injetados perfeitamente nos contêineres a partir do AWS Secrets Manager e do Systems Manager Parameter Store do Amazon EC2. Esses segredos podem ser referenciados em sua tarefa como qualquer um dos seguintes.

1. Eles são referenciadas como variáveis de ambiente que usam o parâmetro de definição de contêiner `secrets`.

1. Eles são referenciados como `secretOptions` se sua plataforma de registro em log exigir autenticação. Para obter mais informações, consulte [opções de configuração de logs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents).

1. Eles são referenciados como segredos extraídos por imagens que usam o parâmetro de definição do contêiner `repositoryCredentials` se o registro de onde o contêiner está sendo retirado exigir autenticação. Use esse método ao extrair imagens da Galeria Pública do Amazon ECR. Para obter mais informações, consulte [Autenticação de registro privado para tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).

Recomendamos fazer o seguinte ao configurar o gerenciamento de segredos.

## Usar o AWS Secrets Manager ou o AWS Systems Manager Parameter Store para armazenar materiais secretos
<a name="security-secrets-management-recommendations-storing-secret-materials"></a>

Você deve armazenar com segurança chaves de API, credenciais de banco de dados e outros materiais secretos no Secrets Manager ou como um parâmetro criptografado no Systems Manager Parameter Store. Esses serviços são semelhantes porque ambos são armazenamentos gerenciados de chave-valor que usam AWS KMS para criptografar dados sigilosos. O Secrets Manager, entretanto, também inclui a capacidade de alternar segredos automaticamente, gerar segredos aleatórios e compartilhar segredos entre contas. Para utilizar esses recursos, use o Secrets Manager. Caso contrário, use parâmetros criptografados no Systems Manager Parameter Store.

**Importante**  
Se seu segredo mudar, você deverá forçar uma nova implantação ou iniciar uma nova tarefa para recuperar o valor secreto mais recente. Para saber mais, consulte os seguintes tópicos:  
Tarefas: pare a tarefa e, em seguida, inicie-a. Para obter mais informações, consulte [Interrupção de uma tarefa do Amazon ECS](standalone-task-stop.md) e [Execução de uma aplicação como uma tarefa do Amazon ECS](standalone-task-create.md).
Serviço: atualize o serviço e use a opção forçar nova implantação. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md).

## Recuperação de dados de um bucket criptografado do Amazon S3
<a name="security-secrets-management-recommendations-encrypted-s3-buckets"></a>

Você deve armazenar os segredos em um bucket criptografado do Amazon S3 e usar perfis de tarefa para restringir o acesso a esses segredos. Isso evita que os valores das variáveis de ambiente vazem inadvertidamente nos logs e sejam revelados durante a execução do `docker inspect`. Ao fazer isso, sua aplicação deve ser gravada para ler o segredo do bucket do Amazon S3. Para obter instruções, consulte [Definição do comportamento padrão da criptografia do lado do servidor para buckets do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html).

## Monte o segredo em um volume usando um contêiner auxiliar
<a name="security-secrets-management-recommendations-mount-secret-volumes"></a>

Como há um risco elevado de vazamento de dados com variáveis de ambiente, você deve usar um contêiner auxiliar que leia seus segredos do AWS Secrets Manager e os grave em um volume compartilhado. Esse contêiner pode ser executado e sair antes do contêiner da aplicação usando o [pedido de contêineres do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html). Quando você faz isso, o contêiner da aplicação monta posteriormente o volume em que o segredo foi gravado. Assim como o método de bucket do Amazon S3, sua aplicação deve ser gravada para ler o segredo do volume compartilhado. Como o volume tem como escopo a tarefa, o volume será excluído automaticamente após a interrupção da tarefa. Para obter um exemplo, consulte o projeto [task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json).

No Amazon EC2, o volume no qual o segredo é gravado pode ser criptografado com uma chave gerenciada pelo cliente AWS KMS. No AWS Fargate, o armazenamento em volume é criptografado automaticamente usando uma chave gerenciada pelo serviço. 

# Transferência de uma variável de ambiente individual para um contêiner do Amazon ECS
<a name="taskdef-envfiles"></a>

**Importante**  
Recomendamos armazenar seus dados sigilosos em segredos do AWS Secrets Manager ou parâmetros do AWS Systems Manager Parameter Store. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md).  
As variáveis de ambiente especificadas na definição de tarefa podem ser legíveis por todos os usuários e perfis a quem são permitidos a ação `DescribeTaskDefinition` para a definição de tarefa.

É possível transmitir variáveis de ambiente aos seus contêineres das maneiras a seguir:
+ Individualmente usando o parâmetro de definição de contêiner `environment`. Isso é mapeado para a opção `--env` para [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/).
+ Em massa, usando o parâmetro de definição de contêiner `environmentFiles` para listar um ou mais arquivos que contêm as variáveis de ambiente. O arquivo deve estar hospedado no Amazon S3. Isso é mapeado para a opção `--env-file` para [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/).

Veja a seguir um trecho de uma definição de tarefa que mostra como especificar variáveis de ambiente individuais.

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

# Transferência de variáveis ​​de ambiente para um contêiner do Amazon ECS
<a name="use-environment-file"></a>

**Importante**  
Recomendamos armazenar seus dados sigilosos em segredos do AWS Secrets Manager ou parâmetros do AWS Systems Manager Parameter Store. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md).  
Arquivos de variáveis de ambiente são objetos no Amazon S3 e todas as considerações de segurança do Amazon S3 se aplicam.   
Não é possível usar o parâmetro `environmentFiles` em contêineres do Windows e em contêineres do Windows no Fargate.

Você pode criar um arquivo de variável de ambiente e armazená-lo no Amazon S3 para passar variáveis de ambiente ao contêiner.

Ao especificar variáveis de ambiente em um arquivo, é possível injetar variáveis de ambiente em massa. Na definição do contêiner, especifique o objeto `environmentFiles` com uma lista de buckets do Amazon S3 que contêm seus arquivos de variáveis de ambiente.

O Amazon ECS não impõe um limite de tamanho às variáveis de ambiente, mas um arquivo de variáveis de ambiente grande pode ocupar o espaço em disco. Cada tarefa que usa um arquivo de variáveis de ambiente faz com que uma cópia do arquivo seja baixada no disco. O Amazon ECS remove o arquivo como parte da limpeza da tarefa.

Para obter informações sobre as variáveis de ambiente com suporte, consulte [Parâmetros avançados de definição de contêiner - Ambiente](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment).

Considere o seguinte ao especificar um arquivo de variáveis de ambiente em uma definição de contêiner.
+ Para tarefas do Amazon ECS no Amazon EC2, suas instâncias de contêiner exigem que o agente seja da versão `1.39.0` ou posterior para usar esse recurso. Para obter informações sobre como verificar a versão do agente e atualizar para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).
+ Para tarefas do Amazon ECS no AWS Fargate, as tarefas devem usar a versão `1.4.0` ou posterior (Linux) da plataforma para usar este recurso. Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).

  Verifique se há suporte para a variável para a plataforma do sistema operacional. Para obter mais informações, consulte [Definições de contêiner](task_definition_parameters.md#container_definitions) e [Outros parâmetros de definição de tarefa](task_definition_parameters.md#other_task_definition_params).
+ O arquivo deve usar a extensão `.env` e a codificação UTF-8.
+ O perfil de execução da tarefa é necessário para usar esse recurso com as permissões adicionais para o Amazon S3. Isso permite que o agente de contêiner extraia o arquivo de variáveis de ambiente do Amazon S3. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md).
+ Há um limite de dez arquivos por definição de tarefa.
+ Cada linha em um arquivo de ambiente deve conter uma variável de ambiente no formato `VARIABLE=VALUE`. Espaços ou aspas **são** incluídos como parte dos valores para arquivos do Amazon ECS. As linhas que começam com `#` são tratadas como comentários e são ignoradas. Para obter mais informações sobre a sintaxe de arquivos de variáveis de ambiente, consulte [Definir variáveis de ambiente (-e, --env, --env-file](https://docs.docker.com/reference/cli/docker/container/run/#env)) na documentação do Docker.

  Confira a sintaxe apropriada a seguir.

  ```
  #This is a comment and will be ignored
  VARIABLE=VALUE
  ENVIRONMENT=PRODUCTION
  ```
+ Se houver variáveis de ambiente especificadas usando o parâmetro `environment` em uma definição de contêiner, elas terão precedência sobre as variáveis contidas em um arquivo de ambiente.
+ Se forem especificados vários arquivos de ambiente que contenham a mesma variável, elas serão processadas na ordem de entrada. Isso significa que o primeiro valor da variável é usado e os valores subsequentes de variáveis duplicadas são ignorados. Recomendamos usar nomes de variáveis exclusivos.
+ Se um arquivo de ambiente for especificado como substituição de contêiner, ele será utilizado. Além disso, quaisquer outros arquivos de ambiente especificados na definição de contêiner são ignorados.
+ As regras a seguir se aplicam ao Fargate:
  + O arquivo é tratado de forma semelhante a um arquivo env nativo do Docker.
  + As definições de contêiner que fazem referência a variáveis de ambiente que estão em branco e armazenadas no Amazon S3 não aparecem no contêiner.
  + Não há suporte para o tratamento de escape de shell.
  + O ponto de entrada do contêiner interpreta os valores `VARIABLE`.

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

Veja a seguir um trecho de uma definição de tarefa que mostra como especificar um arquivo de variável de ambiente.

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

# Transmissão de segredos do Secrets Manager de forma programática no Amazon ECS
<a name="secrets-app-secrets-manager"></a>

Em vez de codificar informações confidenciais em texto simples na aplicação, você pode usar o Secrets Manager para armazenar os dados confidenciais.

Recomendamos esse método de recuperação de dados confidenciais porque a aplicação recuperará automaticamente a versão mais recente do segredo se o segredo do Secrets Manager for atualizado posteriormente.

Crie um segredo no Secrets Manager. Após criar um segredo do Secrets Manager, atualize o código da aplicação para recuperá-lo.

Antes de proteger dados confidenciais no Secrets Manager, analise os seguintes fatores.
+ Somente segredos que armazenem dados de texto, criados com parâmetro `SecretString` API [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html), são compatíveis. Segredos que armazenam dados binários, criados com o parâmetro `SecretBinary` da API [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html), não são compatíveis.
+ Use os endpoints da VPC de interface para aprimorar os controles de segurança. É necessário criar endpoints da VPC de interface para o Secrets Manager. Para obter informações o endpoint da VPC, consulte [Criar endpoints da VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) no *Guia do usuário do AWS Secrets Manager*.
+ A VPC usada por sua tarefa deve usar resolução de DNS.
+ A definição de tarefa deve usar um perfil de tarefa com as permissões adicionais para o Secrets Manager. Para obter mais informações, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md).

## Criar o segredo do Secrets Manager
<a name="secrets-app-secrets-manager-create-secret"></a>

É possível usar o console do Secrets Manager para criar um segredo para seus dados sigilosos. Para obter informações sobre como criar segredos, consulte [Criar um segredo do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) no *Guia do usuário do AWS Secrets Manager*.

## Atualizar sua aplicação para recuperar programaticamente segredos do Secrets Manager
<a name="secrets-app-secrets-manager-update-app"></a>

É possível recuperar segredos com uma chamada diretamente da sua aplicação para as APIs do Secrets Manager. Para obter informações, consulte [Retrieve secrets from AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) no *Guia do usuário do AWS Secrets Manager*.

Para recuperar os dados confidenciais armazenados no AWS Secrets Manager, consulte [Exemplos de código para AWS Secrets Manager usando AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html) na *Biblioteca de códigos de exemplos de códigos do AWS SDK*.

# Transmissão de segredos do Systems Manager Parameter Store de forma programática no Amazon ECS
<a name="secrets-app-ssm-paramstore"></a>

O Systems Manager Parameter Store fornece armazenamento e gerenciamento seguros de segredos. É possível armazenar dados como senhas, strings de banco de dados, IDs da instância do EC2 e IDs da AMI, e códigos de licença como valores de parâmetros, em vez de codificar essa informação em sua aplicação. É possível armazenar valores como texto sem formatação ou dados criptografados.

Recomendamos esse método de recuperação de dados confidenciais porque a aplicação recuperará automaticamente a versão mais recente se o parâmetro do Systems Manager Parameter Store for atualizado posteriormente.

Antes de proteger dados confidenciais no Systems Manager Parameter Store, analise os seguintes fatores.
+ Só há compatibilidade com segredos que armazenam dados de texto. Não há compatibilidade com segredos que armazenam dados binários.
+ Use os endpoints da VPC de interface para aprimorar os controles de segurança.
+ A VPC usada por sua tarefa deve usar resolução de DNS.
+ Para tarefas que usam o EC2, você deve usar a variável de configuração `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` do agente do Amazon ECS para usar esse recurso. É possível adicioná-lo ao arquivo `/etc/ecs/ecs.config` durante a criação da instância de contêiner ou adicioná-lo a uma instância existente e reiniciar o agente do ECS. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md).
+ A definição da tarefa deve usar um perfil de tarefa com as permissões adicionais para o Systems Manager Parameter Store. Para obter mais informações, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md).

## Criar o parâmetro
<a name="secrets-app-ssm-paramstore-create-secret"></a>

É possível usar o console do Systems Manager para criar um parâmetro do Systems Manager Parameter Store para seus dados confidenciais. Para obter mais informações, consulte [Criar um parâmetro do Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) ou [Criar um parâmetro do Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) no *Guia do usuário do AWS Systems Manager*.

## Atualizar sua aplicação para recuperar programaticamente segredos do Systems Manager Parameter Store
<a name="secrets-app-ssm-paramstore-update-app"></a>

Para recuperar os dados confidenciais armazenados no parâmetro do Systems Manager Parameter Store, consulte [Exemplos de código para Systems Manager usando AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) na *Biblioteca de códigos de exemplos de códigos do AWS SDK*.

# Transmissão de segredos do Secrets Manager por meio de variáveis ​​de ambiente do Amazon ECS
<a name="secrets-envvar-secrets-manager"></a>

Ao injetar um segredo como uma variável de ambiente, você pode especificar o conteúdo completo de um segredo, uma chave JSON específica em um segredo. Isso ajuda você a controlar os dados sigilosos expostos ao seu contêiner. Para obter mais informações sobre versionamento de segredos, consulte ‭[Qual é o conteúdo de um segredo do Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version)‭‬ no *Guia do usuário‭ do AWS Secrets Manager*.

As informações a seguir devem ser consideradas ao usar uma variável de ambiente para injetar um segredo do Secrets Manager em um contêiner.
+ Os dados sigilosos são injetados no contêiner inicialmente quando o contêiner é iniciado. Se o segredo for posteriormente atualizado ou modificado, o contêiner não receberá o valor atualizado automaticamente. Você deve executar uma nova tarefa ou se a tarefa for parte de um serviço, será possível atualizar o serviço e usar a opção **Force new deployment (Forçar nova implantação)** para forçar o serviço a iniciar uma nova tarefa.
+ Os aplicativos executados no contêiner, os logs do contêiner e as ferramentas de depuração têm acesso às variáveis ​​de ambiente.
+ Para tarefas do Amazon ECS no AWS Fargate, considere o seguinte:
  + Para injetar o conteúdo completo de um segredo como uma variável de ambiente ou em uma configuração de log, você deve usar a versão `1.3.0` ou posterior da plataforma. Para mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).
  + Para injetar uma chave JSON ou uma versão específica de um segredo como uma variável de ambiente ou em uma configuração de log, você deve usar a versão `1.4.0` ou posterior (Linux) ou `1.0.0` (windows) da plataforma. Para mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).
+ Para tarefas do Amazon ECS no EC2, é necessário considerar o seguinte:
  + Para injetar um segredo usando uma chave JSON ou uma versão específica de um segredo, sua instância de contêiner deve ter a versão `1.37.0` ou posterior do agente de contêiner. Recomendamos usar a versão mais recente do atendente de contêiner. Para obter informações sobre como verificar a versão do agente e atualizar para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).

    Para injetar o conteúdo completo de um segredo como uma variável de ambiente ou injetar um segredo em uma configuração de log, sua instância de contêiner deve ter a versão `1.22.0` ou posterior do agente de contêiner.
+ Use os endpoints da VPC de interface para aprimorar os controles de segurança e se conectar ao Secrets Manager por meio de uma sub-rede privada. É necessário criar endpoints da VPC de interface para o Secrets Manager. Para obter informações o endpoint da VPC, consulte [Criar endpoints da VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) no *Guia do usuário do AWS Secrets Manager*. Para obter mais informações sobre como usar o Secrets Manager e a Amazon VPC, consulte [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/).
+ Para tarefas do Windows configuradas para usar o driver de log `awslogs`, também é necessário definir a variável de ambiente `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` na instância de contêiner. Use a seguinte sintaxe:

  ```
  <powershell>
  [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
  Initialize-ECSAgent -Cluster <cluster name> -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
  </powershell>
  ```
+ A definição de tarefa deve usar um perfil de execução de tarefa com as permissões adicionais para o Secrets Manager. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md).

## Criar o segredo do AWS Secrets Manager
<a name="secrets-envvar-secrets-manager-create-secret"></a>

É possível usar o console do Secrets Manager para criar um segredo para seus dados sigilosos. Para obter mais informações, consulte [Criar um segredo do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) no *Guia do usuário do AWS Secrets Manager*.

## Adicionar a variável de ambiente à definição de contêiner
<a name="secrets-envvar-secrets-manager-update-container-definition"></a>

Na definição de contêiner, você pode especificar o seguinte:
+ O objeto `secrets` contendo o nome da variável de ambiente a ser definida no contêiner
+ O nome do recurso da Amazon (ARN) do segredo do Secrets Manager
+ Parâmetros adicionais que contêm os dados confidenciais a serem apresentados ao contêiner

O exemplo a seguir mostra a sintaxe completa que deve ser especificada para o segredo do Secrets Manager.

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

A seção a seguir descreve os parâmetros adicionais. Esses parâmetros são opcionais, mas, se não usá-los, você deverá incluir os dois-pontos `:` para usar os valores padrão. Abaixo, exemplos provendo mais contexto.

`json-key`  
Especifica o nome da chave em um par de chave/ valor, com o valor que deseje definir como o valor da variável de ambiente. Somente valores formato JSON são compatíveis. Se você não especificar uma chave JSON, será usado o conteúdo completo do segredo.

`version-stage`  
Especifique o rótulo de preparação da versão do segredo que deseja usar. Se um rótulo de preparação de versão for especificado, você não poderá especificar um ID de versão. Se nenhum estágio de versão for especificado, o comportamento padrão será recuperar o segredo com o rótulo de preparação `AWSCURRENT`.  
Rótulos de preparação são usados para monitoramento de diferentes versões de um segredo quando eles forem atualizados ou alternados. Cada versão de um segredo tem um ou mais rótulos de preparação e uma ID.

`version-id`  
Especifica o identificador exclusivo da versão do segredo que você deseja usar. Se um ID de versão for especificado, você não poderá especificar um rótulo de preparação de versão. Se nenhuma ID de versão for especificada, o comportamento padrão será recuperar o segredo com o rótulo de preparação `AWSCURRENT`.  
IDs da versão são usadas para monitoramento de diferentes versões de um segredo quando atualizados ou alternados. Cada versão de um segredo tem uma ID. Para obter mais informações, consulte [Termos e conceitos principais do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret) no *Guia do usuário do AWS Secrets Manager*.

### Exemplo de definições de contêiner
<a name="secrets-examples"></a>

Os exemplos a seguir mostram maneiras como você pode fazer referência a segredos do Secrets Manager nas suas definições de contêiner.

**Example Referenciando um segredo completo**  
O seguinte é um trecho de definição de tarefa mostrando formato, ao fazer referência ao texto completo de um segredo Secrets Manager.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
    }]
  }]
}
```
Para acessar o valor desse segredo diretamente do contêiner, você precisaria chamar `$environment_variable_name`.

**Example referenciando segredos completos**  
Veja a seguir um trecho de uma definição de tarefa mostrando o formato ao fazer referência ao texto completo de vários segredos do 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"
      }
    ]
  }]
}
```
Para acessar o valor desse segredo diretamente do contêiner, você precisaria chamar `$environment_variable_name1`, `$environment_variable_name2` e `$environment_variable_name3`.

**Example Referenciando uma chave específica dentro de um segredo**  
O seguinte é um exemplo de saída de comando [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) exibe o conteúdo de um segredo junto ao rótulo de estágio da versão e ID da versão associada a ele.  

```
{
    "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
}
```
Faça referência a uma chave específica de saída anterior em uma definição de contêiner especificando o nome da chave no fim do ARN.  

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

**Example Referenciando uma versão secreta específica**  
O seguinte é um exemplo de saída de comando [describe-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html) exibindo o conteúdo não criptografado de um segredo junto aos metadados de todas as versões do segredo.  

```
{
    "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"
        ]
    }
}
```
Faça referência a um rótulo específico de preparação de versão de saída anterior em uma definição de contêiner especificando o nome da chave no fim do ARN.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:"
    }]
  }]
}
```
Faça referência a uma ID da versão específica da saída anterior em uma definição de contêiner especificando o nome da chave no final do ARN.  

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

**Example Referenciando uma chave específica e um rótulo de estágio de versão de um segredo**  
O seguinte é um exemplo de como fazer referência a uma chave específica dentro de um segredo e rótulo de estágio de versão específico.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:"
    }]
  }]
}
```
Para uma chave específica e ID da versão, use a sintaxe a seguir.  

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

Para obter informações sobre como criar uma definição de tarefa com o segredo especificado em uma variável de ambiente, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). 

# Transmissão de parâmetros do Systems Manager por meio de variáveis ​​de ambiente do Amazon ECS
<a name="secrets-envvar-ssm-paramstore"></a>

O Amazon ECS permite que você introduza dados confidenciais em contêineres, ao armazená-los nos parâmetros do AWS Systems Manager Parameter Store e, em seguida, referenciá-los na definição do contêiner.

Considere as informações apresentadas a seguir ao usar uma variável de ambiente para introduzir um segredo do Systems Manager em um contêiner.
+ Os dados sigilosos são injetados no contêiner inicialmente quando o contêiner é iniciado. Se o segredo for posteriormente atualizado ou modificado, o contêiner não receberá o valor atualizado automaticamente. Você deve executar uma nova tarefa ou se a tarefa for parte de um serviço, será possível atualizar o serviço e usar a opção **Force new deployment (Forçar nova implantação)** para forçar o serviço a iniciar uma nova tarefa.
+ Para tarefas do Amazon ECS no AWS Fargate, o seguinte deve ser considerado:
  + Para injetar o conteúdo completo de um segredo como uma variável de ambiente ou em uma configuração de log, você deve usar a versão `1.3.0` ou posterior da plataforma. Para mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).
  + Para injetar uma chave JSON ou uma versão específica de um segredo como uma variável de ambiente ou em uma configuração de log, você deve usar a versão `1.4.0` ou posterior (Linux) ou `1.0.0` (windows) da plataforma. Para mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).
+ Para tarefas do Amazon ECS no EC2, é necessário considerar o seguinte:
  + Para injetar um segredo usando uma chave JSON ou uma versão específica de um segredo, sua instância de contêiner deve ter a versão `1.37.0` ou posterior do agente de contêiner. Recomendamos usar a versão mais recente do atendente de contêiner. Para obter informações sobre como verificar a versão do agente e atualizar para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).

    Para injetar o conteúdo completo de um segredo como uma variável de ambiente ou injetar um segredo em uma configuração de log, sua instância de contêiner deve ter a versão `1.22.0` ou posterior do agente de contêiner.
+ Use os endpoints da VPC de interface para aprimorar os controles de segurança. Você deve criar os endpoints da VPC de interface para o Systems Manager. Para obter mais informações sobre o endpoint da VPC, consulte [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) no *Guia do usuário do AWS Systems Manager*.
+ A definição da tarefa deve usar um perfil de execução de tarefa com as permissões adicionais para o Systems Manager Parameter Store. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md).
+ Para tarefas do Windows configuradas para usar o driver de log `awslogs`, também é necessário definir a variável de ambiente `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` na instância de contêiner. Use a seguinte sintaxe:

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

## Criação do parâmetro do Systems Manager
<a name="secrets-envvar-ssm-paramstore-create-parameter"></a>

É possível usar o console do Systems Manager para criar um parâmetro do Systems Manager Parameter Store para seus dados confidenciais. Para obter mais informações, consulte [Criar um parâmetro do Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) ou [Criar um parâmetro do Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) no *Guia do usuário do AWS Systems Manager*.

## Adicionar a variável de ambiente à definição de contêiner
<a name="secrets-ssm-paramstore-update-container-definition"></a>

Na definição do contêiner na definição da tarefa, especifique `secrets` com o nome da variável de ambiente a ser definida no contêiner e o ARN completo do parâmetro Systems Manager Parameter Store contendo os dados sigilosos a serem apresentados. Para obter mais informações, consulte [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Veja a seguir um trecho de uma definição de tarefa mostrando o formato ao fazer referência a um parâmetro do Systems Manager Parameter Store. Se o parâmetro do Systems Manager Parameter Store existir na mesma região da tarefa que está sendo iniciada, será possível usar o ARN completo ou o nome do parâmetro. Se o parâmetro existir em uma região diferente, o ARN completo deverá ser especificado.

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

Para obter informações sobre como criar uma definição de tarefa com o segredo especificado em uma variável de ambiente, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md).

## Atualizar sua aplicação para recuperar programaticamente segredos do Systems Manager Parameter Store
<a name="secrets-ssm-paramstore-update-app"></a>

Para recuperar os dados confidenciais armazenados no parâmetro do Systems Manager Parameter Store, consulte [Exemplos de código para Systems Manager usando AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) na *Biblioteca de códigos de exemplos de códigos do AWS SDK*.

# Transmissão de segredos para a configuração do registro em log do Amazon ECS
<a name="secrets-logconfig"></a>

Você pode usar o parâmetro `secretOptions` em `logConfiguration` para passar dados confidenciais usados no registro em log.

É possível armazenar o segredo no Secrets Manager ou no Systems Manager.

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

Na sua definição de contêiner, ao especificar uma `logConfiguration`, você pode especificar `secretOptions` com o nome da opção de driver de log a ser definida no contêiner e o ARN completo do segredo do Secrets Manager que contém os dados sigilosos a serem apresentados ao contêiner. Para obter mais informações sobre a criação de segredos, consulte [Criar um AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).

Veja a seguir um trecho de uma definição de tarefa mostrando o formato ao fazer referência a um segredo do 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"
      }]
    }]
  }]
}
```

## Adicionar a variável de ambiente à definição de contêiner
<a name="secrets-envvar-ssm-paramstore-update-container-definition"></a>

Em sua definição de contêiner, especifique `secrets` com o nome da variável de ambiente a ser definida no contêiner e o ARN completo do parâmetro Systems Manager Parameter Store contendo os dados sigilosos a serem apresentados. Para obter mais informações, consulte [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Veja a seguir um trecho de uma definição de tarefa mostrando o formato ao fazer referência a um parâmetro do Systems Manager Parameter Store. Se o parâmetro do Systems Manager Parameter Store existir na mesma região da tarefa que está sendo iniciada, será possível usar o ARN completo ou o nome do parâmetro. Se o parâmetro existir em uma região diferente, o ARN completo deverá ser especificado.

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

Para obter informações sobre como criar uma definição de tarefa com o segredo especificado em uma variável de ambiente, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md).

## Usar o Systems Manager
<a name="secrets-logconfig-ssm-paramstore"></a>

É possível injetar dados confidenciais em uma configuração de log. Em sua definição de contêiner, ao especificar `logConfiguration`, será possível especificar `secretOptions` com o nome da opção de driver de log a ser definida no contêiner e o ARN completo do parâmetro do Systems Manager Parameter Store que contém os dados sigilosos a serem apresentados ao contêiner.

**Importante**  
Se o parâmetro do Systems Manager Parameter Store existir na mesma região da tarefa que está sendo iniciada, será possível usar o ARN completo ou o nome do parâmetro. Se o parâmetro existir em uma região diferente, o ARN completo deverá ser especificado.

Veja a seguir um trecho de uma definição de tarefa mostrando o formato ao fazer referência a um parâmetro do Systems Manager Parameter Store.

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

# Especificar dados confidenciais usando segredos do Secrets Manager no Amazon ECS
<a name="specifying-sensitive-data-tutorial"></a>

O Amazon ECS permite a injeção de dados confidenciais nos contêineres armazenando esses dados confidenciais em segredos do AWS Secrets Manager e depois referenciando-os na definição do contêiner. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md).

Saiba como criar um segredo do Secrets Manager, fazer referência ao segredo em uma definição de tarefa do Amazon ECS e, em seguida, verificar se isso funcionou ao consultar a variável de ambiente dentro de um contêiner que mostra o conteúdo do segredo.

## Pré-requisitos
<a name="specifying-sensitive-data-tutorial-prereqs"></a>

Este tutorial pressupõe que os seguintes pré-requisitos foram concluídos:
+ As etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md) foram concluídas.
+ Seu usuário tem as permissões do IAM necessárias para criar os recursos do Secrets Manager e do Amazon ECS.

## Etapa 1: Criar um segredo do Secrets Manager
<a name="specifying-sensitive-data-tutorial-create-secret"></a>

É possível usar o console do Secrets Manager para criar um segredo para seus dados sigilosos. Neste tutorial, vamos criar um segredo básico para armazenar um nome de usuário e uma senha para consulta posterior em um contêiner. Para obter mais informações, consulte [Criar um AWS Secrets Manager segredo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) no *Guia do usuário AWS Secrets Manager*.

Os **pares de chave/valor a serem armazenados nesse segredo** constituem o valor da variável de ambiente no contêiner no final do tutorial.

Salve o **Secret ARN** (ARN do segredo) para ser referenciado na política do IAM de execução de tarefa e a definição de tarefa em etapas posteriores.

## Etapa 2: adicionar as permissões de segredos ao perfil de execução da tarefa
<a name="specifying-sensitive-data-tutorial-update-iam"></a>

Para que o Amazon ECS recupere os dados sigilosos do seu segredo do Secrets Manager, é necessário ter as permissões de segredo para o perfil de execução da tarefa. Para obter mais informações, consulte [Permissões do Secrets Manager ou do Systems Manager](task_execution_IAM_role.md#task-execution-secrets).

## Etapa 3: criar uma definição de tarefa
<a name="specifying-sensitive-data-tutorial-create-taskdef"></a>

Você pode usar o console do Amazon ECS para criar uma definição de tarefa que faça referência a um segredo do Secrets Manager.

**Para criar uma definição de tarefa que especifica um segredo**

Use o console do IAM para atualizar a função de execução de tarefa com as permissões necessárias.

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. No painel de navegação, escolha **Task definitions** (Definições de tarefa).

1. Escolha **Create new task definition** (Criar nova definição de tarefa), **Create new task definition with JSON** (Criar nova definição de tarefa com JSON).

1. Na caixa do editor JSON, e insira o texto JSON de definição de tarefa a seguir, garantindo que você especifique o ARN completo do segredo do Secrets Manager criado na etapa 1 e o perfil de execução da tarefa atualizado na etapa 2. Escolha **Salvar**.

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. Escolha **Criar**.

## Etapa 4: criar um cluster
<a name="specifying-sensitive-data-tutorial-create-cluster"></a>

É possível usar o console do Amazon ECS para criar um cluster que contém uma instância de contêiner na qual a tarefa será executada. Se você tiver um cluster existente com pelo menos uma instância de contêiner registrada nele com os recursos disponíveis para executar uma instância da definição de tarefa criada para este tutorial, será possível pular para a próxima etapa.

Para este tutorial, vamos criar um cluster com uma instância de contêiner `t2.micro` usando a AMI do Amazon Linux 2 otimizada para o Amazon ECS.

Para obter informações sobre como criar um cluster no EC2, consulte [Criar um cluster do Amazon ECS para workloads do Amazon EC2](create-ec2-cluster-console-v2.md).

## Etapa 5: executar uma tarefa
<a name="specifying-sensitive-data-tutorial-run-task"></a>

É possível usar o console do Amazon ECS para executar uma tarefa usando a definição de tarefa que você criou. Neste tutorial, executaremos uma tarefa usando o EC2 e o cluster que criamos na etapa anterior. 

Para obter informações sobre como executar uma tarefa, consulte [Execução de uma aplicação como uma tarefa do Amazon ECS](standalone-task-create.md).

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

É possível verificar se todas as etapas foram concluídas com êxito e a variável de ambiente foi criada corretamente em seu contêiner usando as etapas a seguir.

**Para verificar se a variável de ambiente foi criada**

1. Encontre o endereço IP público ou DNS para sua instância de contêiner.

   1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

   1. No painel de navegação, escolha **Clusters** e selecione o cluster que você criou.

   1. Escolha **Infraestrutura** e, em seguida, escolha a instância de contêiner.

   1. Registre o **IP público** ou o **DNS público** para sua instância.

1. Se você estiver usando um computador Linux ou macOS, conecte-se à sua instância com o seguinte comando, substituindo o caminho para sua chave privada e o endereço público para sua instância:

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

   Para obter mais informações sobre como usar um computador com Windows, consulte [Conectar à instância do Linux usando PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html) no *Guia do usuário do Amazon EC2*.
**Importante**  
Para obter mais informações sobre problemas ao se conectar à instância, consulte [Solução de problemas para conectar-se à sua instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) no *Manual do usuário do Amazon EC2*.

1. Liste os contêineres em execução na instância. Anote o ID do contêiner `ecs-secrets-tutorial`.

   ```
   docker ps
   ```

1. Conecte-se ao contêiner `ecs-secrets-tutorial` usando o ID do contêiner da saída da etapa anterior.

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

1. Use o comando `echo` para imprimir o valor da variável de ambiente.

   ```
   echo $username_value
   ```

   Se o tutorial foi bem-sucedido, você deverá ver a saída a seguir.

   ```
   password_value
   ```
**nota**  
Como alternativa, você pode listar todas as variáveis de ambiente em seu contêiner usando o comando `env` (ou `printenv`).

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

Ao concluir este tutorial, você deve limpar os recursos associados para evitar cobranças por recursos não utilizados.

**Limpeza dos recursos**

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. No painel de navegação, escolha **Clusters**.

1. Na página **Clusters**, escolha o cluster.

1. Escolha **Delete Cluster**. 

1. Na caixa de confirmação, insira **excluir *nome do cluster*** e, em seguida, escolha **Excluir**.

1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. No painel de navegação, escolha **Perfis**. 

1. Procure por `ecsTaskExecutionRole` na lista de funções e selecione-a.

1. Escolha **Permissões** e escolha o **X** ao lado de **ECSSecretsTutorial**. Escolha **Remover**.

1. Abra o console do Secrets Manager em [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).

1. Selecione o segredo **username\$1value** que você criou e escolha **Actions (Ações)**, **Delete secret (Excluir segredo)**.