# Diferenças de definição de tarefa do Amazon ECS para o Fargate
Para usar o Fargate, você precisa configurar a definição de tarefa para usar o tipo de execução do Fargate. Há considerações adicionais ao usar o Fargate.
## Parâmetros de definição de tarefa
As tarefas que usam o Fargate não são compatíveis com todos os parâmetros de definição de tarefa do Amazon ECS que estão disponíveis. Alguns parâmetros são totalmente incompatíveis e outros se comportam de maneira diferente nas tarefas do Fargate.
Os seguintes parâmetros de definição de tarefa não são válidos nas tarefas do Fargate:
+ `disableNetworking`
+ `dnsSearchDomains`
+ `dnsServers`
+ `dockerSecurityOptions`
+ `extraHosts`
+ `gpu`
+ `ipcMode`
+ `links`
+ `placementConstraints`
+ `privileged`
+ `maxSwap`
+ `swappiness`
Os seguintes parâmetros de definição de tarefa são válidos em tarefas do Fargate, mas têm limitações que devem ser observadas:
+ `linuxParameters`: ao definir opções específicas do Linux que são aplicadas ao contêiner, para `capabilities`, o único recurso possível de ser adicionado é `CAP_SYS_PTRACE`. Os parâmetros `devices`, `sharedMemorySize` e `tmpfs` não têm suporte. Para obter mais informações, consulte [Parâmetros do Linux](task_definition_parameters.md#container_definition_linuxparameters).
+ `volumes`: as tarefas do Fargate só oferecem suporte aos volumes do host de montagem bind e, portanto, não há suporte para o parâmetro `dockerVolumeConfiguration`. Para obter mais informações, consulte [Volumes](task_definition_parameters.md#volumes).
+ `cpu`: para contêineres do Windows no AWS Fargate, o valor não pode ser menor que 1 vCPU.
+ `networkConfiguration`: as tarefas do Fargate sempre usam o modo de rede `awsvpc`.
Para garantir que sua definição de tarefa seja válida para uso com o Fargate, é possível especificar o seguinte quando você registrar a definição de tarefa:
+ No Console de gerenciamento da AWS, para o campo **Requires Compatibilities (Requer compatibilidades)**, especifique `FARGATE`.
+ Na AWS CLI, especifique a opção `--requires-compatibilities`.
+ Na API do Amazon ECS, especifique o sinalizador `requiresCompatibilities`.
## Arquiteturas e sistemas operacionais
Quando você configura uma definição de tarefa e de contêiner para AWS Fargate, você deve especificar o sistema operacional que o contêiner executa. Há suporte para os seguintes sistemas operacionais para AWS Fargate:
+ Amazon Linux 2
**nota**
Os contêineres do Linux usam apenas o kernel e a configuração do kernel do sistema operacional do host. Por exemplo, a configuração do kernel inclui os controles do sistema `sysctl`. Uma imagem de contêiner de Linux pode ser criada a partir de uma imagem base que contenha os arquivos e programas de qualquer distribuição do Linux. Se a arquitetura da CPU corresponder, será possível executar contêineres a partir de qualquer imagem de contêiner de Linux em qualquer sistema operacional.
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
Quando você executar contêineres do Windows no AWS Fargate, você deverá ter uma arquitetura de CPU X86\$164.
Quando você executar contêineres do Linux no AWS Fargate, você pode usar a arquitetura de CPU X86\$164 ou a arquitetura ARM64 para suas aplicações baseadas em ARM. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads do ARM de 64 bits](ecs-arm64.md).
## CPU e memória da tarefa
As definições de tarefa do Amazon ECS para AWS Fargate exigem que você especifique a CPU e a memória no nível da tarefa. A maioria dos casos de uso são atendidos com a especificação desses recursos somente no nível de tarefa. A tabela a seguir mostra as combinações válidas para CPU e memória em nível de tarefa. É possível especificar valores de memória na definição de tarefa como uma string em MiB ou GB. Por exemplo, você pode especificar um valor de memória como `3072` em MiB ou `3 GB` em GB. Você pode especificar valores de CPU no arquivo JSON como uma string em unidades de CPU ou em CPUs virtuais (vCPUs). Por exemplo, você pode especificar um valor de CPU como `1024` em unidades de CPU ou `1 vCPU` em vCPUs.
| Valor de CPU | Valor de memória | Sistemas operacionais com suporte para o AWS Fargate |
| --- | --- | --- |
| 256 (0,25 vCPU) | 512 MiB, 1 GB, 2 GB | Linux |
| 512 (0,5 vCPU) | 1 GB, 2 GB, 3 GB, 4 GB | Linux |
| 1024 (1 vCPU) | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB | Linux, Windows |
| 2048 (2 vCPU) | Entre 4 GB e 16 GB em incrementos de 1 GB | Linux, Windows |
| 4096 (4 vCPU) | Entre 8 GB e 30 GB em incrementos de 1 GB | Linux, Windows |
| 8192 (8 vCPU) Essa opção requer a plataforma Linux `1.4.0` ou posterior. | Entre 16 GB e 60 GB em incrementos de 4 GB | Linux |
| 16384 (16 vCPU) Essa opção requer a plataforma Linux `1.4.0` ou posterior. | Entre 32 GB e 120 GB em incrementos de 8 GB | Linux |
## Redes de tarefas
As tarefas do Amazon ECS para AWS Fargate exigem o modo de rede `awsvpc`, que fornece uma interface de rede elástica para cada tarefa. Ao executar uma tarefa ou criar um serviço com esse modo de rede, você deve especificar uma ou mais sub-redes para anexar à interface de rede e um ou mais security groups para aplicar à interface de rede.
Se você estiver usando sub-redes públicas, decida se um endereço IP público será fornecido à interface de rede. Para uma tarefa do Fargate em uma sub-rede pública, para extrair imagens do contêiner, será preciso que um endereço IP público seja atribuído à interface de rede elástica da tarefa, com uma rota para a Internet ou um gateway NAT que possa encaminhar as solicitações para a Internet. Para que uma tarefa do Fargate em uma sub-rede privada extraia imagens de contêiner, é necessário um gateway NAT na sub-rede para encaminhar solicitações para a Internet. Ao hospedar imagens de contêiner no Amazon ECR, você pode configurar o Amazon ECR para usar um endpoint da VPC de interface. Nesse caso, o endereço IPv4 privado da tarefa é usado para a extração da imagem. Para obter mais informações sobre endpoints de interface do Amazon ECR, consulte [Endpoints da VPC de interface do Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) no *Guia do usuário do Amazon Elastic Container Registry*.
Este é um exemplo da seção `networkConfiguration` para um serviço do Fargate:
```
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [ "sg-12345678" ],
"subnets": [ "subnet-12345678" ]
}
}
```
## Limites de recursos de tarefa
As definições de tarefa do Amazon ECS para contêineres do Linux no AWS Fargate oferecem suporte ao parâmetro `ulimits` para definir os limites de recursos a serem estabelecidos para um contêiner.
As definições de tarefa do Amazon ECS para Windows no AWS Fargate não oferecem suporte ao parâmetro `ulimits` para definir os limites de recursos a serem estabelecidos para um contêiner.
As tarefas do Amazon ECS hospedadas no Fargate usam os valores de limite de recursos padrão limitados pelo sistema operacional, com exceção do parâmetro de limite de recursos `nofile`. O limite de recursos `nofile` define uma restrição sobre o número de arquivos abertos que um contêiner pode usar. No Fargate, o limite flexível padrão de `nofile` é ` 65535`, e o limite rígido é `65535`. É possível definir os valores de ambos os limites até `1048576`.
Veja a seguir um exemplo de trecho de definição de tarefa que mostra como definir um limite `nofile` personalizado que tenha sido duplicado:
```
"ulimits": [
{
"name": "nofile",
"softLimit": 2048,
"hardLimit": 8192
}
]
```
Para obter mais informações sobre os outros limites de recursos que podem ser ajustados, consulte [Limites de recurso](task_definition_parameters.md#container_definition_limits).
## Registro em log
### Registro em log de eventos
O Amazon ECS registra em log as ações que realiza no EventBridge. É possível usar os eventos do Amazon ECS para o Eventbridge receber notificações quase em tempo real quanto ao estado atual dos clusters, serviços e tarefas do Amazon ECS. Além disso, é possível automatizar ações para responder a esses eventos. Para obter mais informações, consulte [Automatização de respostas a erros do Amazon ECS usando o EventBridge](cloudwatch_event_stream.md).
### Registro em log do ciclo de vida da tarefa
As tarefas executadas no Fargate publicam registros de data e hora para rastrear a tarefa nos estados do ciclo de vida da tarefa. É possível ver os registros de data e hora nos detalhes da tarefa no Console de gerenciamento da AWS, e com a descrição da tarefa na AWS CLI e nos SDKs. Por exemplo, é possível usar os carimbos de data/hora para avaliar quanto tempo a tarefa gastou baixando as imagens do contêiner e decidir se você deve otimizar o tamanho da imagem do contêiner ou usar índices Seekable OCI. Para obter mais informações sobre práticas de imagens de contêiner, consulte [Práticas recomendadas para imagens de contêiner do Amazon ECS](container-considerations.md).
### Registro em log de aplicações
As definições de tarefa do Amazon ECS para AWS Fargate oferecem suporte aos drivers de log `awslogs`, `splunk` e `awsfirelens` para a configuração do log.
O driver de log `awslogs` configura as tarefas do Fargate para enviar informações de log ao Amazon CloudWatch Logs. A tabela a seguir mostra um trecho de uma definição de tarefa em que o driver de log `awslogs` está configurado:
```
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group" : "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
}
```
Para obter mais informações sobre como usar o driver de log `awslogs` em uma definição de tarefa para enviar os logs de contêiner para o CloudWatch Logs, consulte [Envio de logs do Amazon ECS para o CloudWatch](using_awslogs.md).
Para obter mais informações sobre o driver de log `awsfirelens` em uma definição de tarefa, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md).
Para obter mais informações sobre como usar o driver de log `splunk` em uma definição de tarefa, consulte [Driver de log do `splunk`](example_task_definitions.md#example_task_definition-splunk).
## Armazenamento de tarefas
Para tarefas do Amazon ECS hospedadas no Fargate, os seguintes tipos de armazenamento são compatíveis:
+ Os volumes do Amazon EBS fornecem armazenamento em blocos econômico, durável e de alto desempenho para workloads em contêineres com uso intenso de dados. Para obter mais informações, consulte [Uso de volumes do Amazon EBS com o Amazon ECS](ebs-volumes.md).
+ Os volumes do Amazon EFS para armazenamento persistente. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md).
+ Montagens bind para armazenamento temporário. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md).
## Carregamento lento de imagens de contêiner usando Seekable OCI (SOCI)
As tarefas do Amazon ECS no Fargate que usam a versão da plataforma Linux `1.4.0` podem usar o Seekable OCI (SOCI) para ajudar a iniciar tarefas mais rapidamente. Com o SOCI, os contêineres gastam apenas alguns segundos na extração da imagem antes de serem iniciados, fornecendo tempo para a configuração do ambiente e a instanciação da aplicação enquanto a imagem é baixada em segundo plano. Isso é chamado de *carregamento lento*. Quando o Fargate inicia uma tarefa do Amazon ECS, o Fargate detecta automaticamente se existe um índice SOCI para uma imagem na tarefa e inicia o contêiner sem esperar que a imagem inteira seja baixada.
Para contêineres executados sem índices SOCI, as imagens do contêiner são baixadas completamente antes de o contêiner ser iniciado. Esse comportamento é o mesmo em todas as outras versões da plataforma do Fargate e na AMI otimizada para Amazon ECS em instâncias do Amazon EC2.
O Seekable OCI (SOCI) é uma tecnologia de código aberto desenvolvida pela AWS que pode iniciar contêineres mais rapidamente carregando lentamente a imagem do contêiner. O SOCI funciona criando um índice (Índice SOCI) dos arquivos em uma imagem de contêiner existente. Esse índice ajuda a iniciar contêineres mais rapidamente, fornecendo a capacidade de extrair um arquivo individual de uma imagem de contêiner antes de baixar a imagem inteira. O índice SOCI deve ser armazenado como um artefato no mesmo repositório da imagem no registro do contêiner. Você só deve usar índices SOCI de fontes confiáveis, pois o índice é a fonte autorizada do conteúdo da imagem. Para obter mais informações, consulte [Introdução ao Seekable OCI para o carregamento lento de imagens de contêiner](https://aws.amazon.com/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images/).
Os clientes que quiserem usar o SOCI só poderão usar o SOCI Index Manifest v2. Os clientes existentes que já tiverem usado o SOCI no Fargate poderão continuar usando o SOCI Index Manifest v1, no entanto, recomendamos fortemente que esses clientes migrem para o SOCI Index Manifest v2. O SOCI Index Manifest v2 cria uma relação explícita entre imagens de contêiner e seus índices SOCI para garantir implantações consistentes.
**Considerações**
Se você quiser que o Fargate use um índice SOCI para carregar imagens de contêiner lentamente em uma tarefa, considere o seguinte:
+ Somente tarefas executadas na versão da plataforma Linux `1.4.0` podem usar índices SOCI. Não há suporte para tarefas executadas em contêineres do Windows no Fargate.
+ Não há suporte para tarefas executadas nas arquitetura de CPU X86\$164 ou ARM64.
+ As imagens de contêiner na definição da tarefa devem ser armazenadas em um registro de imagens compatível. A seguir, são listados os registros compatíveis:
+ Registros privados do Amazon ECR.
+ Só há suporte para as imagens de contêiner que usem compactação gzip ou não sejam compactadas. Não há suporte para imagens de contêiner que usem compactação zstd.
+ Para o SOCI Index Manifest v2, a geração de um manifesto do índice SOCI modifica o manifesto da imagem do contêiner conforme adicionamos uma anotação ao índice SOCI. Isso resulta em um novo resumo da imagem do contêiner. O conteúdo das camadas do sistema de arquivos das imagens do contêiner não muda.
+ Para o SOCI Index Manifest v2, quando a imagem do contêiner já tiver sido armazenada no repositório de imagens do contêiner, depois que um índice SOCI tiver sido gerado, você precisará reenviar a imagem do contêiner. O reenvio de uma imagem de contêiner não aumentará os custos de armazenamento ao duplicar as camadas do sistema de arquivos, apenas carregará um novo arquivo de manifesto.
+ Recomendamos que você experimente o carregamento lento com imagens de contêiner maiores que 250 MiB compactadas em tamanho. É menos provável que você veja uma redução no tempo de carregamento de imagens menores.
+ Como o carregamento lento pode alterar o tempo de início das tarefas, talvez seja necessário alterar vários tempos limite, como o período de carência da verificação de integridade do Elastic Load Balancing.
+ Se você quiser evitar que uma imagem de contêiner seja carregada lentamente, a imagem do contêiner precisará ser reenviada sem um índice SOCI anexado.
**Criação de um índice Seekable OCI**
Para que uma imagem de contêiner seja carregada lentamente, ela precisa de um índice SOCI (um arquivo de metadados) criado e armazenado no repositório de imagens do contêiner com a imagem do contêiner. Para criar e fazer push de um índice SOCI, é possível usar a [ferramenta de CLI soci-snapshotter](https://github.com/awslabs/soci-snapshotter) de código aberto no GitHub. Você também pode implantar o AWS SOCI Index Builder do CloudFormation. Essa é uma solução sem servidor que cria e faz push de um índice SOCI automaticamente quando uma imagem de contêiner é enviada por push para o Amazon ECR. Para obter mais informações sobre a solução e as etapas de instalação, consulte [CloudFormation AWS SOCI Index Builder](https://awslabs.github.io/cfn-ecr-aws-soci-index-builder/) no GitHub. O AWS SOCI Index Builder do CloudFormation é uma maneira de automatizar a introdução ao SOCI, enquanto a ferramenta SOCI de código aberto tem mais flexibilidade na geração de índices e a capacidade de integrar a geração de índices nos pipelines de integração contínua e entrega contínua (CI/CD).
**nota**
Para que o índice SOCI seja criado para uma imagem, a imagem deve existir no armazenamento de imagens do containerd no computador com o `soci-snapshotter` em execução. Se a imagem estiver no armazenamento de imagens do Docker, ela não poderá ser encontrada.
**Verificação se uma tarefa usou carregamento lento**
Para verificar se uma tarefa foi carregada lentamente usando o SOCI, verifique o endpoint de metadados da tarefa de dentro da tarefa. Quando você consulta o endpoint de metadados de tarefa versão 4, há um campo `Snapshotter` no caminho padrão do contêiner do qual você está consultando. Além disso, há campos `Snapshotter` para cada contêiner no caminho `/task`. O valor padrão para esse campo é `overlayfs`, e esse campo será definido como `soci` se o SOCI for usado. Para verificar se uma imagem de contêiner tem um SOCI Index Manifest v2 anexado, você pode recuperar o índice de imagem do Amazon ECR usando o AWS CLI.
```
IMAGE_REPOSITORY=r
IMAGE_TAG=latest
aws ecr batch-get-image \
--repository-name=$IMAGE_REPOSITORY \
--image-ids imageTag=$IMAGE_TAG \
--query 'images[0].imageManifest' --output text | jq -r '.manifests[] | select(.artifactType=="application/vnd.amazon.soci.index.v2+json")'
```
Para verificar se uma imagem de contêiner tem um SOCI Index Manifest v1 anexado, você pode usar a API OCI Referrers.
```
ACCOUNT_ID=111222333444
AWS_REGION=us-east-1
IMAGE_REPOSITORY=nginx-demo
IMAGE_TAG=latest
IMAGE_DIGEST=$(aws ecr describe-images --repository-name $IMAGE_REPOSITORY --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[0].imageDigest' --output text)
ECR_PASSWORD=$(aws ecr get-login-password)
curl \
--silent \
--user AWS:$ECR_PASSWORD \
https://$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/v2/$IMAGE_REPOSITORY/referrers/$IMAGE_DIGEST?artifactType=application%2Fvnd.amazon.soci.index.v1%2Bjson | jq -r '.'
```