# Definições de tarefa do Amazon ECS Uma *definição de tarefa* é como um esquema para sua aplicação. É um arquivo de texto em formato JSON que descreve os parâmetros e um ou mais contêineres que formam sua aplicação. Veja a seguir alguns dos parâmetros que você pode especificar em uma definição de tarefa. + A capacidade a ser usada, que determina a infraestrutura na qual as tarefas são hospedadas + A imagem do Docker a ser usada com cada contêiner em sua tarefa + A CPU e a memória a serem usadas com cada tarefa ou cada contêiner dentro de uma tarefa + Os requisitos de memória e CPU + O sistema operacional do contêiner no qual a tarefa é executada + O modo de rede do Docker a ser usado para os contêineres na tarefa + A configuração de registro em log a ser usada para suas tarefas + Se a tarefa deve continuar sendo executada caso o contêiner seja concluído ou falhe + O comando que o contêiner executa quando é iniciado + Eventuais volumes de dados que são usados com os contêineres na tarefa + O perfil do IAM usado pelas suas tarefas Para obter uma lista completa de parâmetros de definição de tarefa, consulte [Parâmetros de definição de tarefa do Amazon ECS para o Fargate](task_definition_parameters.md). Depois de criar uma definição de tarefa, você pode executá-la como uma tarefa ou um serviço. + Uma *tarefa* é a instanciação de uma definição de tarefa dentro de um cluster. Depois de criar uma definição de tarefa para a aplicação no Amazon ECS, é possível especificar o número de tarefas que serão executadas no cluster. + Um *serviço* do Amazon ECS executa e mantém simultaneamente o número desejado de tarefas em um cluster do Amazon ECS. Ele funciona de forma que, se qualquer uma de suas tarefas falharem ou pararem por algum motivo, o programador de serviço do Amazon ECS iniciará outra instância com base na sua definição de tarefa. Ele faz isso para substituí-la e, assim, manter o número desejado de tarefas no serviço. **Topics** + [ # Estados de definição de tarefa do Amazon ECS ](task-definition-state.md) + [ # Projetar sua aplicação para o Amazon ECS ](application_architecture.md) + [ # Criar uma definição de tarefa do Amazon ECS usando o console ](create-task-definition.md) + [ # Usar o Amazon Q Developer para fornecer recomendações de definição de tarefa no console do Amazon ECS ](using-amazon-q.md) + [ # Atualizar uma definição de tarefa do Amazon ECS usando o console ](update-task-definition-console-v2.md) + [ # Cancelar registro de uma revisão de definição de tarefa do Amazon ECS usando o console ](deregister-task-definition-v2.md) + [ # Exclusão de uma revisão de definição de tarefa do Amazon ECS usando o console ](delete-task-definition-v2.md) + [ # Casos de uso de definição de tarefa do Amazon ECS ](use-cases.md) + [ # Parâmetros de definição de tarefa do Amazon ECS para instâncias gerenciadas do Amazon ECS ](task_definition_parameters-managed-instances.md) + [ # Parâmetros de definição de tarefa do Amazon ECS para o Fargate ](task_definition_parameters.md) + [ # Parâmetros de definição de tarefa do Amazon ECS para o Amazon EC2 ](task_definition_parameters_ec2.md) + [ # Modelo de definição de tarefa do Amazon ECS ](task-definition-template.md) + [ # Exemplos de definições de tarefa do Amazon ECS ](example_task_definitions.md) # Estados de definição de tarefa do Amazon ECS A definição de uma tarefa muda de estado ao criá-la, cancelar o registro ou exclui-la. É possível visualizar o estado da definição de tarefa no console ou usando `DescribeTaskDefinition`. Veja a seguir os estados possíveis para uma definição de tarefa: ACTIVE A definição de uma tarefa é `ACTIVE` após ser registrada no Amazon ECS. É possível usar as definições de tarefa no estado `ACTIVE` para executar tarefas ou criar serviços. INACTIVE Quando você cancela o registro de uma definição de tarefa, uma definição de tarefa passa do estado `ACTIVE` para o estado `INACTIVE`. É possível recuperar uma definição de tarefa `INACTIVE` chamando `DescribeTaskDefinition`. Não é possível executar novas tarefas ou criar novos serviços com uma definição de tarefa no estado `INACTIVE`. Não há impacto sobre os serviços ou tarefas existentes. DELETE\$1IN\$1PROGRESS Depois que você envia a definição da tarefa para exclusão, uma definição de tarefa passa do estado `INACTIVE` para o estado `DELETE_IN_PROGRESS`. Depois que a definição da tarefa estiver no estado `DELETE_IN_PROGRESS`, o Amazon ECS verificará periodicamente se a definição da tarefa de destino não está sendo mencionada por nenhuma tarefa ou implantação ativa e, em seguida, excluirá a definição da tarefa permanentemente. Não é possível executar novas tarefas ou criar novos serviços com uma definição de tarefa no estado `DELETE_IN_PROGRESS`. É possível enviar uma definição de tarefa para exclusão a qualquer momento sem afetar tarefas e serviços existentes. É possível visualizar no console as definições de tarefa que estão no estado `DELETE_IN_PROGRESS`, e a definição da tarefa pode ser recuperada chamando `DescribeTaskDefinition`. Quando você exclui todas as revisões de definição da tarefa `INACTIVE`, o nome da definição da tarefa não é exibido no console e não é retornado na API. Se uma revisão de definição de tarefa estiver no estado `DELETE_IN_PROGRESS`, o nome da definição de tarefa é exibido no console e retornado na API. O nome da definição da tarefa é mantido pelo Amazon ECS e a revisão será incrementada na próxima vez que você criar uma definição de tarefa com esse nome. Se você usar o AWS Config para gerenciar suas definições de tarefa, o AWS Config cobrará por todos os registros de definição de tarefa. Só haverá cobrança pelo cancelamento do registro da definição de tarefa `ACTIVE` mais recente. Não haverá cobrança pela exclusão de uma definição de tarefa. Para obter mais informações sobre definição de preço, consulte [Preços do AWS Config](https://aws.amazon.com/config/pricing/). ## Recursos do Amazon ECS que podem bloquear uma exclusão Uma solicitação de exclusão da definição de tarefa não será concluída se houver algum recurso do Amazon ECS que dependa da revisão da definição de tarefa. Os recursos a seguir podem impedir que uma definição de tarefa seja excluída: + Tarefas autônomas do Amazon ECS: a definição da tarefa é necessária para que a tarefa permaneça íntegra. + Tarefas de serviço do Amazon ECS: a definição da tarefa é necessária para que a tarefa permaneça íntegra. + Implantações e conjuntos de tarefas do serviço do Amazon ECS: a definição da tarefa é necessária quando um evento de escalabilidade é iniciado para uma implantação ou conjunto de tarefas do Amazon ECS. Se sua definição de tarefa permanecer no estado `DELETE_IN_PROGRESS`, será possível usar o console ou a AWS CLI para identificar e interromper os recursos que bloqueiem a exclusão da definição de tarefa. ### Exclusão da definição de tarefa após a remoção do recurso bloqueado As regras a seguir se aplicam depois que você remove os recursos que bloqueiam a exclusão da definição da tarefa: + Tarefas do Amazon ECS: a exclusão da definição da tarefa pode levar até uma hora para ser concluída após a interrupção da tarefa. + Implantações e conjuntos de tarefas do serviço do Amazon ECS: a exclusão da definição da tarefa pode levar até 24 horas para ser concluída após a exclusão da implantação ou do conjunto de tarefas. # Projetar sua aplicação para o Amazon ECS Você arquiteta a aplicação criando uma definição de tarefa para ela. A definição da tarefa contém os parâmetros que definem as informações sobre a aplicação, incluindo: + A capacidade a ser usada, que determina a infraestrutura na qual as tarefas são hospedadas. Ao usar o provedor de capacidade do EC2, você também escolhe o tipo de instância. Ao usar o provedor de capacidade de instâncias gerenciadas do Amazon ECS, você pode fornecer requisitos de instância para que o Amazon ECS gerencie a capacidade computacional. Em alguns tipos de instância, como GPU, é necessário definir parâmetros específicos. Para obter mais informações, consulte [Casos de uso de definição de tarefa do Amazon ECS](use-cases.md). + A imagem de contêiner, que contém o código da aplicação e todas as dependências que o código da aplicação requer para ser executado. + O modo de rede a ser usado para os contêineres na sua tarefa. O modo de rede determina como a tarefa se comunica pela rede. Em tarefas executadas nas instâncias do EC2 e nas instâncias gerenciadas do Amazon ECS, há várias opções, mas recomendamos usar o modo de rede `awsvpc`. O modo de rede `awsvpc` simplifica a rede de contêineres, oferecendo mais controle sobre como as aplicações se comunicam entre si e com outros serviços dentro das VPCs. Em tarefas executadas no Fargate, você deve usar o modo de rede `awsvpc`. + A configuração de registro em log a ser usada nas tarefas. + Quaisquer volumes de dados que são usados com os contêineres na tarefa. Para obter uma lista completa de parâmetros de definição de tarefa, consulte [Parâmetros de definição de tarefa do Amazon ECS para o Fargate](task_definition_parameters.md). Use as diretrizes a seguir ao criar suas definições de tarefas: + Use cada família de definição de tarefas para apenas uma finalidade comercial. Se você agrupar vários tipos de contêineres de aplicações na mesma definição de tarefa, não poderá escalar esses contêineres de forma independente. Por exemplo, um site e uma API normalmente exigem padrões de escalabilidade diferentes. À medida que o tráfego aumenta, você talvez vá precisar de um número diferente de contêineres da Web do que o de contêineres de API. Se esses dois contêineres forem implantados na mesma definição de tarefa, todas as tarefas executarão o mesmo número de contêineres da Web e contêineres de API. + Combine cada versão da aplicação com uma revisão de definição de tarefa dentro de uma família de definição de tarefa. Dentro de uma família de definições de tarefas, cada revisão de definição de tarefa representa um snapshot pontual das configurações de uma imagem de contêiner específica. Isso é semelhante à forma como o contêiner é um snapshot de todos os componentes que são necessários para executar uma versão específica do código da sua aplicação. Crie um mapeamento individual entre uma versão do código da aplicação, uma tag de imagem de contêiner e uma revisão da definição da tarefa. Um processo de lançamento típico envolve um git commit que é transformado em uma imagem de contêiner com tag atribuída do SHA do git commit. Em seguida, essa tag de imagem de contêiner recebe sua própria revisão de definição de tarefa do Amazon ECS. Por último, o serviço do Amazon ECS é atualizado para implantar a nova revisão da definição da tarefa. + Use perfis do IAM diferentes para cada família de definição de tarefa. Defina cada definição de tarefa com seu próprio perfil do IAM. Implemente essa prática e forneça a cada componente de negócio sua própria família de definições de tarefas. Ao implementar essas duas práticas recomendadas, é possível limitar o acesso que cada serviço tem aos recursos da sua conta da AWS. Por exemplo, é possível conceder acesso ao seu serviço de autenticação para se conectar ao seu banco de dados de senhas. Ao mesmo tempo, você também pode garantir que somente o serviço de pedidos tenha acesso às informações de pagamento do cartão de crédito. # Práticas recomendadas para tamanhos de tarefas do Amazon ECS Os tamanhos de contêineres e tarefas são essenciais para o planejamento de ajuste de escala e de capacidade. No Amazon ECS, CPU e memória são as duas métricas de recursos usadas para capacidade. A CPU é medida em unidades de 1/1024 de uma vCPU completa (1.024 unidades são iguais a 1 vCPU inteira). A memória é medida em mebibytes. Na definição da tarefa, é possível configurar reservas e limites de recursos. Ao configurar uma reserva, você está definindo a quantidade mínima de recursos que uma tarefa exige. Sua tarefa recebe, pelo menos, a quantidade de recursos solicitada. A aplicação pode conseguir usar mais CPU ou memória do que a reserva declarada. No entanto, isso está sujeito a quaisquer limites que também foram declarados. Usar mais do que a quantidade da reserva é conhecido como intermitência. No Amazon ECS, as reservas são garantidas. Por exemplo, se você usar instâncias do Amazon EC2 para fornecer capacidade, o Amazon ECS não coloca uma tarefa em uma instância em que a reserva não possa ser atendida. Um limite é a quantidade máxima de unidades de CPU ou memória que o contêiner ou a tarefa pode usar. Qualquer tentativa de usar mais CPU além desse limite resulta em controle de utilização. Qualquer tentativa de usar mais memória faz com que o contêiner seja interrompido. Escolher esses valores pode ser um desafio. Isso ocorre porque os valores mais adequados para a aplicação dependem muito dos requisitos de recursos da aplicação. Testar a carga da aplicação é a chave para um planejamento bem-sucedido dos requisitos de recursos e para uma melhor compreensão dos requisitos da aplicação. ## Aplicações sem estado Em aplicações sem estado que escalam horizontalmente, como uma aplicação por trás de um balanceador de carga, recomendamos primeiro determinar a quantidade de memória que a aplicação consome ao atender às solicitações. Para isso, você pode usar ferramentas tradicionais, como `ps` ou `top`, ou soluções de monitoramento, como o CloudWatch Container Insights. Ao determinar uma reserva de CPU, considere como você deseja escalar a aplicação para atender às suas necessidades de negócios. Você pode usar reservas de CPU menores, como 256 unidades de CPU (ou 1/4 de vCPU), para aumentar a escala horizontalmente de uma forma refinada que minimize os custos. Porém, elas podem não ser escaladas com rapidez suficiente para atender a picos significativos na demanda. Você pode usar reservas maiores de CPU para aumentar e reduzir a escala horizontalmente com mais rapidez e, portanto, atender aos picos de demanda com mais rapidez. No entanto, reservas maiores de CPU são mais caras. ## Outros aplicativos Em aplicações que não são escaláveis horizontalmente, como operadores únicos ou servidores de banco de dados, a capacidade disponível e o custo representam suas considerações mais importantes. Você deve escolher a quantidade de memória e CPU com base na necessidade indicada pelo teste de carga para fornecer um tráfego que atinja seu objetivo no nível de serviço. O Amazon ECS garante que a aplicação seja colocada em um host com capacidade adequada. # Rede de tarefas do Amazon ECS para instâncias gerenciadas do Amazon ECS O comportamento da rede das tarefas do Amazon ECS executadas em instâncias gerenciadas do Amazon ECS é determinado pelo *modo de rede* especificado na definição da tarefa. Especifique um modo de rede na definição da tarefa. Você não poderá executar tarefas nas instâncias gerenciadas do Amazon ECS usando uma definição de tarefa que não especifique um modo de rede. As instâncias gerenciadas do Amazon ECS oferecem suporte aos seguintes modos de rede, garantindo compatibilidade com versões anteriores para migrar workloads do Fargate ou do Amazon ECS no Amazon EC2: | Modo de rede | Descrição | | --- | --- | | `awsvpc` | Cada tarefa recebe sua própria interface de rede elástica (ENI) e endereço IPv4 privado. Isso fornece as mesmas propriedades de rede que as instâncias do Amazon EC2 e é compatível com as tarefas tradicionais do Fargate. Usa entroncamento ENI para alta densidade de tarefas. | | `host` | As tarefas compartilham diretamente o namespace de rede do host. A rede de contêineres está vinculada à instância host subjacente. | ## Usar uma VPC no modo somente IPv6 Em uma configuração somente IPv6, suas tarefas do Amazon ECS se comunicam exclusivamente via IPv6. Para configurar VPCs e sub-redes para uma configuração somente IPv6, adicione um bloco CIDR IPv6 à VPC e crie sub-redes que incluam apenas um bloco CIDR IPv6. Para obter mais informações, consulte [Adicionar suporte IPv6 para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) e [Criar uma sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) no *Guia do usuário da Amazon VPC*. Atualize também as tabelas de rotas com destinos IPv6 e configure grupos de segurança com regras IPv6. Para obter mais informações, consulte [Configurar tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) e [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Guia do usuário da Amazon VPC*. As seguintes considerações se aplicam: + Você pode atualizar um serviço somente IPv4 ou de pilha dupla do Amazon ECS para uma configuração somente IPv6 atualizando o serviço diretamente para usar sub-redes somente IPv6 ou criando um serviço somente IPv6 paralelo e usando implantações azul-verde do Amazon ECS para transferir o tráfego para o novo serviço. Para obter mais informações sobre implantações azul/verde do Amazon ECS, consulte [Implantações azuis/verdes do Amazon ECS](deployment-type-blue-green.md). + Um serviço somente IPv6 do Amazon ECS deve usar balanceadores de carga de pilha dupla com grupos-de destino IPv6. Se você estiver migrando um serviço do Amazon ECS existente que está por trás de um Application Load Balancer ou de um Network Load Balancer, será possível criar um novo balanceador de carga de pilha dupla e transferir o tráfego do balanceador de carga antigo ou atualizar o tipo de endereço IP do balanceador de carga existente. Para obter mais informações sobre Network Load Balancers consulte [Criar um Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) no *Guia do usuário para Network Load Balancers*. Para obter mais informações sobre Application Load Balancers, consulte [Criar um Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) no *Guia do usuário para Application Load Balancers*. + Para tarefas do Amazon ECS em uma configuração somente IPv6 para se comunicar com endpoints somente IPv4, você pode configurar DNS64 e NAT64 para converter endereços de rede de IPv6 para IPv4. Para obter mais informações, consulte [DNS64 e NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html), no *Guia do usuário da Amazon VPC*. + As workloads do Amazon ECS em uma configuração somente IPv6 devem usar endpoints de URI de imagem de pilha dupla do Amazon ECR ao extrair imagens do Amazon ECR. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*. **nota** O Amazon ECR não oferece suporte a endpoints da VPC de interface de pilha dupla que as tarefas de uma configuração somente IPv6 possam usar. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*. + Não há suporte para o Amazon ECS Exec em uma configuração somente IPv6. # Alocar uma interface de rede para tarefas nas instâncias gerenciadas do Amazon ECS O uso do modo de rede `awsvpc` nas instâncias gerenciadas do Amazon ECS simplifica a rede de contêineres porque você tem mais controle sobre como as aplicações se comunicam entre si e com outros serviços dentro das VPCs. O modo de rede `awsvpc` também fornece maior segurança para os contêineres, permitindo que você use grupos de segurança e ferramentas de monitoramento de rede em um nível mais granular dentro das tarefas. Por padrão, cada instância gerenciada do Amazon ECS tem uma interface de rede elástica (ENI) de tronco conectada durante a inicialização como ENI primária quando o tipo de instância aceita entroncamento. Para obter mais informações sobre tipos de instância que oferecem suporte ao entroncamento ENI, consulte [Instâncias compatíveis para aumentar as interfaces de rede de contêineres do Amazon ECS.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/eni-trunking-supported-instance-types.html) **nota** Quando o tipo de instância escolhido não for compatível com ENIs de tronco, a instância será inicializada com uma ENI normal. Cada tarefa executada na instância recebe sua própria ENI anexada à ENI do tronco, com um endereço IP privado primário. Se a VPC estiver configurada para o modo de pilha dupla e você usar uma sub-rede com um bloco CIDR IPv6, a ENI também receberá um endereço IPv6. Ao usar uma sub-rede pública, você tem a opção de atribuir um endereço IP público à ENI primária da instância gerenciada do Amazon ECS habilitando o endereçamento público IPv4 para a sub-rede. Para obter mais informações, consulte [Modificar os atributos de endereçamento IP da sua sub-rede](https://docs.aws.amazon.com//vpc/latest/userguide/subnet-public-ip.html) no *Guia do usuário da Amazon VPC*. Uma tarefa só pode ter uma ENI associada a ela de cada vez. Os contêineres que pertencem à mesma tarefa também podem se comunicar por meio da interface `localhost`. Para obter mais informações sobre VPCs e sub-redes, consulte [Como a Amazon VPC funciona](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) no *Guia do usuário da Amazon VPC* As seguintes operações usam a ENI primária anexada à instância: + **Downloads de imagens**: as imagens de contêiner são baixadas do Amazon ECR por meio da ENI principal. + **Recuperação de segredos**: os segredos e outras credenciais do Secrets Manager são recuperados por meio da ENI primária. + **Uploads de logs**: os logs são enviados por upload para o CloudWatch por meio da ENI primária. + **Downloads de arquivos de ambiente**: os arquivos de ambiente são baixados por meio da ENI principal. O tráfego da aplicação flui pela ENI da tarefa. Como cada tarefa tem sua própria ENI, você pode usar recursos de rede, como os logs de fluxo de VPC, que podem ser usados para monitorar o tráfego de e para suas tarefas. Para obter mais informações, consulte [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) no *Guia do usuário do Amazon Virtual Private Cloud*. Você também pode utilizar AWS PrivateLink. É possível configurar um endpoint de interface VPC para que você possa acessar APIs do Amazon ECS por meio de endereços IP privados. AWS PrivateLink restringe todo o tráfego de rede entre sua VPC e o Amazon ECS para a rede da Amazon. Você não precisa de um gateway da Internet, de um dispositivo NAT ou de um gateway privado virtual. Para obter mais informações, consulte [Endpoints da VPC da interface do Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html). O modo de rede `awsvpc` também permite que você utilize o Amazon VPC Traffic Mirroring para segurança e monitoramento do tráfego de rede ao usar tipos de instância que não têm ENIs de tronco anexadas. Para obter mais informações, consulte [O que é Traffic Mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) no *Guia do Amazon VPC Traffic Mirroring*. ## Considerações sobre o modo `awsvpc` + As tarefas exigem o perfil vinculado ao serviço do Amazon ECS para o gerenciamento da ENI. Esse perfil é criado automaticamente quando você cria um cluster ou um serviço. + As ENIs de tarefas são gerenciados pelo Amazon ECS e não podem ser desanexados ou modificados manualmente. + A atribuição de um endereço IP público à ENI de tarefa usando `assignPublicIp` ao executar uma tarefa autônoma (`RunTask`), criar ou atualizar um serviço (`CreateService`/`UpdateService`) não é compatível. + Quando você configurar a rede `awsvpc` no nível da tarefa, use a mesma VPC especificada como parte do modelo de inicialização do provedor de capacidade de instâncias gerenciadas do Amazon ECS. Você pode usar sub-redes e grupos de segurança diferentes dos especificados no modelo de inicialização. + Para tarefas no modo de rede `awsvpc`, use o tipo de destino `ip` ao configurar grupos de destino do balanceador de carga. O Amazon ECS gerencia automaticamente o registro do grupo de destino para os modos de rede compatíveis. ## Usar uma VPC no modo de pilha dupla Ao usar uma VPC no modo de pilha dupla, as tarefas podem se comunicar por IPv4, IPv6 ou ambos. Os endereços IPv4 e IPv6 são independentes um do outro. Portanto, é preciso configurar o encaminhamento e a segurança na VPC separadamente para IPv4 e IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*. Se tiver configurado sua VPC com um gateway da Internet ou um gateway da Internet somente saída, será possível utilizar sua VPC no modo de pilha dupla. Fazendo isso, as tarefas que obtêm um endereço IPv6 podem acessar a Internet por meio de um gateway da Internet ou um gateway da Internet somente saída. Gateways NAT são opcionais. Para obter mais informações, consulte [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) e [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) somente de saída no *Guia do usuário da Amazon VPC*. As tarefas do Amazon ECS receberão um endereço IPv6 se as seguintes condições forem atendidas: + A instância gerenciada do Amazon ECS que hospeda a tarefa está usando a versão `1.45.0` ou posterior do agente de contêiner. Para obter informações sobre como verificar a versão do agente que a instância está usando e atualizá-la, se necessário, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md). + A configuração `dualStackIPv6` da conta está habilitada. Para obter mais informações, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md). + Sua tarefa está usando o modo de rede `awsvpc`. + Sua VPC e sua sub-rede estão configuradas para IPv6. A configuração inclui as interfaces de rede criadas na sub-rede especificada. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) e [Modificar o atributo de endereçamento IPv6 para a sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) no *Guia do usuário da Amazon VPC*. # Modo de rede do host No modo `host`, as tarefas compartilham diretamente o namespace de rede do host. A configuração de rede do contêiner está vinculada à instância host subjacente das instâncias gerenciadas do Amazon ECS que você especifica usando o parâmetro `networkConfiguration` ao criar um provedor de capacidade de instâncias gerenciadas do Amazon ECS.`` Existem desvantagens significativas em usar esse modo de rede. Você não pode executar mais do que uma única instanciação de uma tarefa em cada host. Isso ocorre porque somente a primeira tarefa pode ser vinculada à porta necessária na instância do Amazon EC2. Também não há como remapear uma porta de contêiner quando ela estiver usando o modo de rede `host`. Por exemplo, se uma aplicação precisar escutar um determinado número de porta, você não poderá remapear o número da porta diretamente. Em vez disso, você deverá gerenciar quaisquer conflitos de portas alterando a configuração da aplicação. Também há implicações de segurança com o uso do modo de rede `host`. Esse modo permite que os contêineres representem o host e permite que os contêineres se conectem a serviços de rede de loopback privados no host. Use o modo host somente quando precisar de acesso direto à rede do host ou ao migrar aplicações que exijam acesso de rede do host. # Opções da rede de tarefas do Amazon ECS para o EC2 O comportamento de rede das tarefas do Amazon ECS hospedadas em instâncias do Amazon EC2 depende do *modo de rede* especificado na definição de tarefa. Recomendamos que você use o modo de rede `awsvpc`, a menos que tenha uma necessidade específica de usar um modo de rede diferente. Veja a seguir os modos de rede disponíveis. | Modo de rede | Contêineres do Linux no EC2 | Contêineres do Windows no EC2 | Descrição | | --- | --- | --- | --- | | `awsvpc` | Sim | Sim | A tarefa recebe sua própria interface de rede elástica (ENI) e um endereço IPv4 ou IPv6 privado primário. Isso dá à tarefa as mesmas propriedades de rede que as instâncias do Amazon EC2. | | `bridge` | Sim | Não | A tarefa usa a rede virtual integrada do Docker no Linux, que é executada em cada instância do Amazon EC2 que hospeda a tarefa. A rede virtual integrada no Linux usa o driver de rede `bridge` do Docker. Esse é o modo de rede padrão no Linux quando um modo de rede não é especificado na definição de tarefa. | | `host` | Sim | Não | A tarefa usa a rede do host que ignora a rede virtual integrada do Docker mapeando as portas do contêiner diretamente para a ENI da instância do Amazon EC2 que hospeda a tarefa. Os mapeamentos dinâmicos de portas não podem ser usados nesse modo de rede. Um contêiner em uma definição de tarefa que use esse modo deve especificar um número de `hostPort` específico. Um número de porta em um host não pode ser usado por várias tarefas. Como resultado, não é possível executar várias tarefas da mesma definição de tarefa em uma única instância do Amazon EC2. | | `none` | Sim | Não | A tarefa não tem conectividade com rede externa. | | `default` | Não | Sim | A tarefa usa a rede virtual integrada do Docker no Windows, que é executada em cada instância do Amazon EC2 que hospeda a tarefa. A rede virtual integrada no Windows usa o driver de rede `nat` do Docker. Esse é o modo de rede padrão no Windows quando um modo de rede não é especificado na definição de tarefa. | Para obter mais informações sobre as redes do Docker no Linux, consulte [Networking overview](https://docs.docker.com/engine/network/) na *documentação do Docker*. Para obter mais informações sobre as redes do Docker no Windows, consulte [Windows container networking](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) na *documentação sobre containers no Windows* da Microsoft. ## Usar uma VPC no modo somente IPv6 Em uma configuração somente IPv6, suas tarefas do Amazon ECS se comunicam exclusivamente via IPv6. Para configurar VPCs e sub-redes para uma configuração somente IPv6, adicione um bloco CIDR IPv6 à VPC e crie novas sub-redes que incluam somente um bloco CIDR IPv6. Para obter mais informações, consulte [Adicionar suporte IPv6 para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) e [Criar uma sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) no *Guia do usuário da Amazon VPC*. Atualize também as tabelas de rotas com destinos IPv6 e configure grupos de segurança com regras IPv6. Para obter mais informações, consulte [Configurar tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) e [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Guia do usuário da Amazon VPC*. As seguintes considerações se aplicam: + Você pode atualizar um serviço somente IPv4 ou de pilha dupla do Amazon ECS para uma configuração somente IPv6 atualizando o serviço diretamente para usar sub-redes somente IPv6 ou criando um serviço somente IPv6 paralelo e usando implantações azul-verde do Amazon ECS para transferir o tráfego para o novo serviço. Para obter mais informações sobre implantações azul/verde do Amazon ECS, consulte [Implantações azuis/verdes do Amazon ECS](deployment-type-blue-green.md). + Um serviço somente IPv6 do Amazon ECS deve usar balanceadores de carga de pilha dupla com grupos-de destino IPv6. Se você estiver migrando um serviço do Amazon ECS existente que está por trás de um Application Load Balancer ou de um Network Load Balancer, será possível criar um novo balanceador de carga de pilha dupla e transferir o tráfego do balanceador de carga antigo ou atualizar o tipo de endereço IP do balanceador de carga existente. Para obter mais informações sobre Network Load Balancers consulte [Criar um Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) no *Guia do usuário para Network Load Balancers*. Para obter mais informações sobre Application Load Balancers, consulte [Criar um Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) no *Guia do usuário para Application Load Balancers*. + Não há suporte para a configuração somente IPv6 no Windows. Use as AMIs do Linux otimizadas para o Amazon ECS para executar tarefas em uma configuração somente IPv6. Para obter mais informações sobre as AMIs do Linux otimizadas para o Amazon ECS, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). + Ao iniciar uma instância de contêiner para executar tarefas em uma configuração somente IPv6, você deve definir um endereço IPv6 primário para a instância usando o parâmetro `--enable-primary-ipv6` do EC2. **nota** Sem um endereço IPv6 primário, as tarefas executadas na instância de contêiner nos modos de rede host ou ponte não serão registradas nos balanceadores de carga ou no AWS Cloud Map. Para obter mais informações sobre `--enable-primary-ipv6` para executar instâncias do Amazon EC2, consulte [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) na *Referência de comandos da AWS CLI*. Para obter mais informações sobre como inicializar instâncias de contêiner usando o Console de gerenciamento da AWS, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). + Por padrão, o agente de contêiner do Amazon ECS tentará detectar a compatibilidade da instância de contêiner com uma configuração somente IPv6 examinando as rotas IPv4 e IPv6 padrão da instância. Para substituir esse comportamento, você pode definir o parâmetro ` ECS_INSTANCE_IP_COMPATIBILITY` como `ipv4` ou `ipv6` no arquivo `/etc/ecs/ecs.config` da instância. + As tarefas devem usar a versão `1.99.1` ou posterior do agente de contêiner. Para obter informações sobre como verificar a versão do agente que a instância está usando e atualizá-la, se necessário, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md). + Para tarefas do Amazon ECS em uma configuração somente IPv6 para se comunicar com endpoints somente IPv4, você pode configurar DNS64 e NAT64 para converter endereços de rede de IPv6 para IPv4. Para obter mais informações, consulte [DNS64 e NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html), no *Guia do usuário da Amazon VPC*. + As workloads do Amazon ECS em uma configuração somente IPv6 devem usar endpoints de URI de imagem de pilha dupla do Amazon ECR ao extrair imagens do Amazon ECR. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*. **nota** O Amazon ECR não oferece suporte a endpoints da VPC de interface de pilha dupla que as tarefas de uma configuração somente IPv6 possam usar. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*. + Não há suporte para o Amazon ECS Exec em uma configuração somente IPv6. ### Regiões da AWS que são compatíveis com o modo somente IPv6 no Amazon ECS Você pode executar tarefas em uma configuração somente IPv6 nas seguintes regiões da AWS em que o Amazon ECS está disponível: + Leste dos EUA (Ohio) + Leste dos EUA (Norte da Virgínia) + Oeste dos EUA (N. da Califórnia) + Oeste dos EUA (Oregon) + África (Cidade do Cabo) + Ásia-Pacífico (Hong Kong) + Ásia-Pacífico (Hyderabad) + Ásia-Pacífico (Jacarta) + Ásia-Pacífico (Melbourne) + Ásia-Pacífico (Mumbai) + Ásia-Pacífico (Osaka) + Ásia-Pacífico (Seul) + Ásia-Pacífico (Singapura) + Ásia-Pacífico (Sydney) + Ásia-Pacífico (Tóquio) + Canadá (Central) + Oeste do Canadá (Calgary) + China (Pequim) + China (Ningxia) + Europa (Frankfurt) + Europa (Londres) + Europa (Milão) + Europe (Paris) + Europa (Espanha) + Israel (Tel Aviv) + Oriente Médio (Bahrein) + Oriente Médio (Emirados Árabes Unidos) + América do Sul (São Paulo) + AWS GovCloud (Leste dos EUA) + AWS GovCloud (Oeste dos EUA) # Alocar uma interface de rede para uma tarefa do Amazon ECS Os recursos de redes de tarefas fornecidos pelo modo de rede `awsvpc` dão às tarefas do Amazon ECS as mesmas propriedades de redes que as instâncias do Amazon EC2. Usar o modo de rede `awsvpc` simplifica a rede de contêineres. Você tem mais controle sobre como as aplicações se comunicam entre si e com outros serviços dentro das VPCs. O modo de rede `awsvpc` também fornece maior segurança para os contêineres, permitindo que você use grupos de segurança e ferramentas de monitoramento de rede em um nível mais granular dentro das tarefas. Você também pode usar outros recursos de rede do Amazon EC2, como o VPC Flow Logs, para monitorar o tráfego que entra e sai das tarefas. Além disso, os contêineres que pertencem à mesma tarefa podem se comunicar por meio da interface `localhost`. A interface de rede elástica (ENI) da tarefa é um recurso totalmente gerenciado do Amazon ECS. O Amazon ECS cria a ENI e a anexa à instância host do Amazon EC2 host com o grupo de segurança especificado. A tarefa envia e recebe tráfego de rede na ENI da mesma maneira que as instâncias do Amazon EC2 fazem com suas interfaces de rede primárias. A cada ENI de tarefa é atribuído um endereço IPv4 privado, por padrão. Se a VPC estiver habilitada para o modo de pilha dupla e você usar uma sub-rede com um bloco CIDR IPv6, a ENI da tarefa também receberá um endereço IPv6. Cada tarefa pode ter apenas uma ENI. Essas ENIs ficam visíveis no console do Amazon EC2 para sua conta. Sua conta não pode desanexar ou modificar as ENIs. Isso visa a evitar a exclusão acidental de uma ENI associada a uma tarefa em execução. É possível visualizar as informações do anexo da ENI para tarefas no console do Amazon ECS ou com a operação da API [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html). Quando a tarefa for interrompida ou se o serviço sofrer redução de escala vertical, a ENI da tarefa será desvinculada e excluída. Quando precisar aumentar a densidade da ENI, use a configuração de conta `awsvpcTrunking`. O Amazon ECS também cria e anexa uma interface de rede “tronco” para a instância de contêiner. A rede tronco é totalmente gerenciada pelo Amazon ECS. A ENI do tronco é excluída quando você encerra ou cancela o registro da instância de contêiner do cluster do Amazon ECS. Para obter mais informações sobre a configuração de conta de `awsvpcTrunking`, consulte [Pré-requisitos](container-instance-eni.md#eni-trunking-launching). Você especifica `awsvpc` no parâmetro `networkMode` da definição de tarefa. Para obter mais informações, consulte [Modo de rede](task_definition_parameters.md#network_mode). Depois, ao executar uma tarefa ou criar um serviço, use o parâmetro `networkConfiguration` que inclui uma ou mais sub-redes para colocar as tarefas e um ou mais grupos de segurança para anexar a uma ENI. Para obter mais informações, consulte [Configuração de rede](service_definition_parameters.md#sd-networkconfiguration). As tarefas são posicionadas em instâncias do Amazon EC2 nas mesmas zonas de disponibilidade que as dessas sub-redes e os grupos de segurança especificados são associados à ENI provisionada para a tarefa. ## Considerações sobre o Linux Considere o seguinte ao utilizar o sistema operacional Linux. + Se você usar uma instância p5.48xlarge no modo `awsvpc`, não será possível executar mais de uma tarefa na instância. + As tarefas e os serviços que usam o modo de rede `awsvpc` exigem que a função vinculada ao serviço do Amazon ECS forneça ao Amazon ECS as permissões para fazer chamadas a outros serviços da AWS em seu nome. Essa função será automaticamente criada quando você criar um cluster ou se criar ou atualizar um serviço no Console de gerenciamento da AWS. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). Você também pode criar a função vinculada ao serviço com o seguinte comando da AWS CLI: ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com ``` + A instância do Linux do Amazon EC2 requer a versão `1.15.0` ou posterior do agente de contêiner para executar tarefas que usam o modo de rede `awsvpc`. Se você estiver usando a AMI do Linux otimizada para o Amazon ECS, sua instância também precisará, pelo menos, da versão `1.15.0-4` do pacote `ecs-init`. + O Amazon ECS preenche o nome de host da tarefa usando a rede de tarefas com um nome de host DNS (interno) fornecido pela Amazon quando as opções `enableDnsHostnames` e `enableDnsSupport` estão habilitadas na sua VPC. Se essas opções não estiverem habilitadas, o nome de host DNS da tarefa será definido como um nome de host aleatório. Para obter mais informações sobre as configurações de DNS para uma VPC, consulte [Usar DNS com sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) no *Guia do usuário da Amazon VPC*. + Cada tarefa do Amazon ECS que usa o modo de rede `awsvpc` recebe sua própria interface de rede elástica (ENI), que está anexada à instância do Amazon EC2 que a hospeda. Existe uma cota padrão para o número de interfaces de rede que é possível anexar a uma instância Linux do Amazon EC2. A interface de rede primária conta para essa cota. Por exemplo, por padrão, uma instância `c5.large` só pode ter até três ENIs associadas a ela. A interface de rede primária da instância conta como uma. É possível associar mais duas ENIs à instância. Como cada tarefa que usa o modo de rede `awsvpc` exige uma ENI, em geral, você pode executar somente duas dessas tarefas nesse tipo de instância. Para obter mais informações sobre os limites de ENI padrão para cada tipo de instância, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) no *Guia do usuário do Amazon EC2*. + O Amazon ECS oferece suporte ao lançamento de instâncias do Linux do Amazon EC2 usando tipos de instâncias compatíveis, com maior densidade de ENI. Quando você aceitar a configuração de conta `awsvpcTrunking` e registrar instâncias do Linux do Amazon EC2 usando esses tipos de instância no seu cluster, estas instâncias terão cotas de ENI mais altas. Utilizar essas instâncias com a cota mais alta significa que é possível colocar mais tarefas em cada instância Linux do Amazon EC2. Para usar a maior densidade de ENI com o recurso de entroncamento, sua instância do Amazon EC2 deve usar a versão `1.28.1` ou posterior do agente de contêiner. Se você estiver usando a AMI otimizada para o Amazon ECS, sua instância precisará, pelo menos, da versão `1.28.1-2` do pacote `ecs-init`. Para obter mais informações sobre como optar pela configuração de conta `awsvpcTrunking`, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md). Para obter mais informações sobre o entroncamento de ENI, consulte [Aumento das interfaces de rede de instâncias de contêiner do Linux no Amazon ECS](container-instance-eni.md). + Ao hospedar tarefas que usam o modo de rede `awsvpc` em instâncias do Linux do Amazon EC2, suas ENIs de tarefa não recebem endereços IP públicos. Para acessar a Internet, as tarefas devem ser executadas em uma sub-rede privada configurada para usar um gateway NAT. Para obter mais informações, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. O acesso à rede de entrada deve ocorrer de dentro da VPC que usa o endereço IP privado ou roteado por um balanceador de carga de dentro da VPC. As tarefas inicializadas em sub-redes públicas não têm acesso à Internet. + O Amazon ECS reconhece somente as ENIs que ele anexa às suas instâncias Linux do Amazon EC2. Se você tiver anexado ENIs manualmente às suas instâncias, o Amazon ECS poderá tentar adicionar uma tarefa a uma instância que não tenha adaptadores de rede suficientes. Isso pode fazer com que a tarefa atinja o tempo limite, passe para um status em desprovisionamento e, em seguida, para um status de interrompida. Recomendamos que você não anexe ENIs às suas instâncias manualmente. + As instâncias do Linux do Amazon EC2 devem ser registradas com o recurso `ecs.capability.task-eni` para serem consideradas para posicionamento de tarefas com o modo de rede `awsvpc`. As instâncias que executam a versão `1.15.0-4` ou posterior do `ecs-init` são automaticamente registradas com esse atributo. + As ENIs criadas e anexadas às suas instâncias do Linux do Amazon EC2 não podem ser desvinculadas manualmente nem modificadas pela sua conta. Isso visa a evitar a exclusão acidental de uma ENI associada a uma tarefa em execução. Para liberar as ENIs para uma tarefa, interrompa-a. + Há um limite de 16 sub-redes e 5 grupos de segurança que podem ser especificados na `awsVpcConfiguration` ao executar uma tarefa ou ao criar um serviço que usa o modo de rede `awsvpc`. Para obter mais informações, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) na *Referência da API de serviço do contêiner do Amazon Elastic Container Service*. + Quando uma tarefa é iniciada com o modo de rede `awsvpc`, o agente de contêiner do Amazon ECS cria um contêiner `pause` adicional para cada tarefa antes de iniciar os contêineres na definição de tarefa. Em seguida, ele configura o namespace de rede do contêiner `pause` ao executar os plug-ins do CNI [amazon-ecs-cni-plugins](https://github.com/aws/amazon-ecs-cni-plugins). O agente inicia então o restante dos contêineres na tarefa para que eles compartilhem a pilha de rede do contêiner `pause`. Isso significa que todos os contêineres em uma tarefa são endereçáveis por endereços IP da ENI, e que eles podem se comunicar entre eles por meio da interface `localhost`. + Serviços com tarefas que usam o modo de rede `awsvpc` oferecem suporte somente a Application Load Balancers e Network Load Balancers. Ao criar grupos de destino para esses serviços, você precisa escolher `ip` como o tipo de destino. Não use `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` são associadas a uma ENI, não a uma instância do Linux do Amazon EC2. Para obter mais informações, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](service-load-balancing.md). + Se a sua VPC for atualizada para alterar o conjunto de opções de DHCP que ela utiliza, não será possível aplicar essas alterações às tarefas existentes. Inicie novas tarefas com essas alterações aplicadas, verifique se elas estão funcionando corretamente e, em seguida, interrompa tarefas existentes para modificar essas configurações de rede com segurança. ## Considerações sobre Windows Veja a seguir considerações quando for usado o sistema operacional Windos. + Instâncias de contêiner que usam a AMI do Windows Server 2016 otimizada para o Amazon ECS não podem hospedar tarefas que usam o modo de rede `awsvpc`. Se você tiver um cluster que contém AMIs do Windows Server 2016 otimizadas para o Amazon ECS e AMIs do Windows compatíveis com o modo de rede `awsvpc`, tarefas que usam o modo de rede `awsvpc` não serão iniciadas nas instâncias do Windows Server 2016. Em vez disso, elas são iniciadas em instâncias com suporte para o modo de rede `awsvpc`. + Sua instância do Windows do Amazon EC2 requer a versão `1.57.1` ou posterior do agente de contêiner para usar métricas do CloudWatch para contêineres do Windows que usem o modo de rede `awsvpc`. + As tarefas e os serviços que usam o modo de rede `awsvpc` exigem que a função vinculada ao serviço do Amazon ECS forneça ao Amazon ECS as permissões para fazer chamadas a outros serviços da AWS em seu nome. Essa função será criada automaticamente quando você criar um cluster ou se criar ou atualizar um serviço no Console de gerenciamento da AWS. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). Também é possível criar a função vinculada ao serviço com o comando da AWS CLI a seguir. ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com ``` + Sua instância do Windows do Amazon EC2 requer a versão `1.54.0` ou posterior do agente de contêiner para executar tarefas que usam o modo de rede `awsvpc`. Ao inicializar a instância, você deve configurar as opções necessárias para o modo de rede `awsvpc`. Para obter mais informações, consulte [Inicialização de instâncias de contêiner do Windows no Amazon ECS para transmitir dados](bootstrap_windows_container_instance.md). + O Amazon ECS preenche o nome de host da tarefa usando a rede de tarefas com um nome de host DNS (interno) fornecido pela Amazon quando as opções `enableDnsHostnames` e `enableDnsSupport` estão habilitadas na sua VPC. Se essas opções não estiverem habilitadas, o nome de host DNS da tarefa será um nome de host aleatório. Para obter mais informações sobre as configurações de DNS para uma VPC, consulte [Usar DNS com sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) no *Guia do usuário da Amazon VPC*. + Cada tarefa do Amazon ECS que usa o modo de rede `awsvpc` recebe sua própria interface de rede elástica (ENI), que está anexada à instância do Windows do Amazon EC2 que a hospeda. Existe uma cota padrão para o número de interfaces de rede que é possível anexar a uma instância Windows do Amazon EC2. A interface de rede primária conta para essa cota. Por exemplo, por padrão, uma instância `c5.large` só pode ter até três ENIs associadas a ela. A interface de rede primária da instância conta como uma delas. É possível associar mais duas ENIs à instância. Como cada tarefa que usa o modo de rede `awsvpc` exige uma ENI, em geral, você pode executar somente duas dessas tarefas nesse tipo de instância. Para obter mais informações sobre os limites de ENI padrão para cada tipo de instância, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) no *Guia do usuário do Amazon EC2*. + Ao hospedar tarefas que usam o modo de rede `awsvpc` em instâncias do Windows do Amazon EC2, suas ENIs de tarefa não recebem endereços IP públicos. Para acessar a Internet, inicie tarefas em uma sub-rede privada configurada para usar um gateway NAT. Para obter mais informações, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. O acesso à rede de entrada deve ocorrer de dentro da VPC usando o endereço IP privado ou roteado por um load balancer de dentro da VPC. As tarefas inicializadas em sub-redes públicas não têm acesso à Internet. + O Amazon ECS reconhece somente as ENIs que ele anexa às suas instâncias Windows do Amazon EC2. Se você tiver anexado ENIs manualmente às suas instâncias, o Amazon ECS poderá tentar adicionar uma tarefa a uma instância que não tenha adaptadores de rede suficientes. Isso pode fazer com que a tarefa atinja o tempo limite, passe para um status em desprovisionamento e, em seguida, para um status de interrompida. Recomendamos que você não anexe ENIs às suas instâncias manualmente. + As instâncias do Windows do Amazon EC2 devem ser registradas com o recurso `ecs.capability.task-eni` para serem consideradas para posicionamento de tarefas com o modo de rede `awsvpc`. + É possível modificar ou desanexar manualmente as ENIs criadas e anexadas às suas instâncias do Windows do Amazon EC2. Isso evita que você exclua acidentalmente uma ENI associada a uma tarefa em execução. Para liberar as ENIs para uma tarefa, interrompa-a. + É possível especificar até 16 sub-redes e 5 grupos de segurança em `awsVpcConfiguration` ao executar uma tarefa ou criar um serviço que usa o modo de rede `awsvpc`. Para obter mais informações, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) na *Referência da API de serviço do contêiner do Amazon Elastic Container Service*. + Quando uma tarefa é iniciada com o modo de rede `awsvpc`, o agente de contêiner do Amazon ECS cria um contêiner `pause` adicional para cada tarefa antes de iniciar os contêineres na definição de tarefa. Em seguida, ele configura o namespace de rede do contêiner `pause` ao executar os plug-ins do CNI [amazon-ecs-cni-plugins](https://github.com/aws/amazon-ecs-cni-plugins). O agente inicia então o restante dos contêineres na tarefa para que eles compartilhem a pilha de rede do contêiner `pause`. Isso significa que todos os contêineres em uma tarefa são endereçáveis por endereços IP da ENI, e que eles podem se comunicar entre eles por meio da interface `localhost`. + Serviços com tarefas que usam o modo de rede `awsvpc` oferecem suporte somente a Application Load Balancers e Network Load Balancers. Ao criar grupos de destino para esses serviços, você precisa escolher `ip` como o tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` são associadas a uma ENI, não a uma instância do Windows do Amazon EC2. Para obter mais informações, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](service-load-balancing.md). + Se a sua VPC for atualizada para alterar o conjunto de opções de DHCP que ela utiliza, não será possível aplicar essas alterações às tarefas existentes. Inicie novas tarefas com essas alterações aplicadas, verifique se elas estão funcionando corretamente e, em seguida, interrompa tarefas existentes para modificar essas configurações de rede com segurança. + Não há suporte para os seguintes recursos quando você usa o modo de rede `awsvpc` em uma configuração de EC2 do Windows: + Configuração de pilha dupla + IPv6 + Entroncamento ENI ## Usar uma VPC no modo de pilha dupla Ao usar uma VPC no modo de pilha dupla, as tarefas podem se comunicar por IPv4, IPv6 ou ambos. Os endereços IPv4 e IPv6 são independentes um do outro. Portanto, é preciso configurar o encaminhamento e a segurança na VPC separadamente para IPv4 e IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*. Se tiver configurado sua VPC com um gateway da Internet ou um gateway da Internet somente saída, será possível utilizar sua VPC no modo de pilha dupla. Fazendo isso, as tarefas que obtêm um endereço IPv6 podem acessar a Internet por meio de um gateway da Internet ou um gateway da Internet somente saída. Gateways NAT são opcionais. Para obter mais informações, consulte [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) e [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) somente de saída no *Guia do usuário da Amazon VPC*. As tarefas do Amazon ECS receberão um endereço IPv6 se as seguintes condições forem atendidas: + A instância Linux do Amazon EC2 que hospeda a tarefa está usando a versão `1.45.0` ou posterior do agente de contêiner. Para obter informações sobre como verificar a versão do agente que a instância está usando e atualizá-la, se necessário, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md). + A configuração `dualStackIPv6` da conta está habilitada. Para obter mais informações, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md). + Sua tarefa está usando o modo de rede `awsvpc`. + Sua VPC e sua sub-rede estão configuradas para IPv6. A configuração inclui as interfaces de rede criadas na sub-rede especificada. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) e [Modificar o atributo de endereçamento IPv6 para a sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) no *Guia do usuário da Amazon VPC*. # Mapeie as portas de contêiner do Amazon ECS para a interface de rede de instância do EC2 Só há suporte para o modo de rede `host` com tarefas do Amazon ECS hospedadas em instâncias do Amazon EC2. Não há suporte com o uso do Amazon ECS no Fargate. O modo de rede `host` é o modo de rede mais básico com suporte no Amazon ECS. Com o uso do modo host, a rede do contêiner é vinculada diretamente ao host subjacente que está executando o contêiner. ![\[Diagrama que mostra a arquitetura de uma rede com contêineres usando o modo de rede host.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/networkmode-host.png) Suponha que você esteja executando um contêiner Node.js com uma aplicação Express que escuta em uma porta `3000` semelhante à ilustrada no diagrama anterior. Quando o modo de rede `host` é usado, o contêiner recebe tráfego na porta 3000 usando o endereço IP da instância de host subjacente do Amazon EC2. Não é recomendável usar esse modo. Existem desvantagens significativas em usar esse modo de rede. Você não pode executar mais do que uma única instanciação de uma tarefa em cada host. Isso ocorre porque somente a primeira tarefa pode ser vinculada à porta necessária na instância do Amazon EC2. Também não há como remapear uma porta de contêiner quando ela estiver usando o modo de rede `host`. Por exemplo, se uma aplicação precisar escutar um determinado número de porta, você não poderá remapear o número da porta diretamente. Em vez disso, você deverá gerenciar quaisquer conflitos de portas alterando a configuração da aplicação. Também há implicações de segurança com o uso do modo de rede `host`. Esse modo permite que os contêineres representem o host e permite que os contêineres se conectem a serviços de rede de loopback privados no host. # Usar a rede virtual do Docker para tarefas do Linux no Amazon ECS Só há suporte para o modo de rede `bridge` com tarefas do Amazon ECS hospedadas em instâncias do Amazon EC2. Com o modo `bridge`, você está usando uma ponte de rede virtual para criar uma camada entre o host e a rede do contêiner. Dessa forma, é possível criar mapeamentos de portas que remapeiem uma porta de host para uma porta de contêiner. Os mapeamentos podem ser estáticos ou dinâmicos. ![\[Diagrama que mostra a arquitetura de uma rede usando o modo de rede bridge com mapeamento de portas estático.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/networkmode-bridge.png) Com um mapeamento estático de portas, é possível definir explicitamente qual porta de host deseja mapear para uma porta de contêiner. Usando o exemplo acima, a porta `80` do host está sendo mapeada para a porta `3000` do contêiner. Para se comunicar com a aplicação em contêiner, você envia tráfego para a porta `80` no endereço IP da instância do Amazon EC2. Do ponto de vista da aplicação em contêineres, ela vê esse tráfego de entrada na porta `3000`. Se você quiser alterar apenas a porta de tráfego, os mapeamentos de portas estáticos são adequados. No entanto, isso ainda tem a mesma desvantagem de usar o modo de rede `host`. Você não pode executar mais do que uma única instanciação de uma tarefa em cada host. Isso ocorre porque um mapeamento estático de portas permite que apenas um único contêiner seja mapeado para a porta 80. Para resolver esse problema, considere usar o modo de rede `bridge` com um mapeamento dinâmico de portas, conforme mostrado no diagrama a seguir. ![\[Diagrama que mostra a arquitetura de uma rede usando o modo de rede bridge com mapeamento de portas dinâmico.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/networkmode-bridge-dynamic.png) Ao não especificar uma porta host no mapeamento de portas, é possível fazer com que o Docker escolha uma porta aleatória e não usada do intervalo de portas temporárias e a atribua como porta host pública para o contêiner. Por exemplo, a aplicação Node.js receptora na porta `3000` do contêiner pode receber uma porta aleatória de número alto, como `47760`, no host do Amazon EC2. Isso significa que é possível executar várias cópias desse contêiner no host. Além disso, cada contêiner pode ter sua própria porta atribuída no host. Cada cópia do contêiner recebe tráfego na porta `3000`. Contudo, os clientes que enviam tráfego para esses contêineres usam as portas de host atribuídas aleatoriamente. O Amazon ECS ajuda você a acompanhar as portas atribuídas aleatoriamente para cada tarefa. Isso é feito atualizando automaticamente os grupos-alvo do balanceador de carga e a descoberta de serviços do AWS Cloud Map para ter a lista de portas e endereços IP de tarefas. Isso facilita o uso de serviços em operação usando o modo `bridge` com portas dinâmicas. No entanto, uma desvantagem de se usar o modo de rede `bridge` é que é difícil bloquear as comunicações entre serviços. Como os serviços podem ser atribuídos a qualquer porta aleatória e não usada, é necessário abrir amplos intervalos de portas entre os hosts. Contudo, não é fácil criar regras específicas para que um determinado serviço só possa se comunicar com outro serviço específico. Os serviços não têm portas específicas para usar nas regras de rede de grupos de segurança. ## Configurar o modo de rede ponte para workloads somente IPv6 Para configurar o modo `bridge` para comunicação via IPv6, você deve atualizar as configurações do daemon do Docker. Atualize `/etc/docker/daemon.json` com o seguinte: ``` { "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64", "ip6tables": true, "experimental": true } ``` Depois de atualizar as configurações do daemon do Docker, você precisará reiniciar o daemon. **nota** Quando você atualiza e reinicia o daemon, o Docker ativa o encaminhamento IPv6 na instância, o que pode resultar na perda de rotas padrão nas instâncias que usam uma AMI do Amazon Linux 2. Para evitar isso, use o comando a seguir para adicionar uma rota padrão por meio do gateway IPv6 da sub-rede. ``` ip route add default via FE80:EC2::1 dev eth0 metric 100 ``` # Opções de redes de tarefas do Amazon ECS para o Fargate Por padrão, todas as tarefas do Amazon ECS no Fargate recebem uma interface de rede elástica (ENI) com um endereço IP privado primário. Ao usar uma sub-rede pública, você pode opcionalmente atribuir um endereço IP público à ENI da tarefa. Se a VPC estiver configurada para o modo de pilha dupla e você usar uma sub-rede com um bloco CIDR IPv6, a ENI da tarefa também receberá um endereço IPv6. Uma tarefa só pode ter uma ENI associada a ela de cada vez. Os contêineres que pertencem à mesma tarefa também podem se comunicar por meio da interface `localhost`. Para obter mais informações sobre VPCs e sub-redes, consulte [Como a Amazon VPC funciona](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) no *Guia do usuário da Amazon VPC*. Para que uma tarefa no Fargate possa extrair uma imagem de contêiner, a tarefa deve ter uma rota para a Internet. Veja a seguir como verificar se a sua tarefa tem uma rota para a Internet. + Quando você usa uma sub-rede pública, pode atribuir um endereço IP público à ENI da tarefa. + Ao usar uma sub-rede privada, a sub-rede pode ter um gateway NAT anexado. + Ao usar imagens de contêiner hospedadas no Amazon ECR, você pode configurar o Amazon ECR para usar um endpoint da VPC de interface e a extração da imagem ocorre no endereço IPv4 privado da tarefa. Para obter mais informações, 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*. Como cada tarefa tem sua própria ENI, você pode usar recursos de rede, como os logs de fluxo de VPC, que podem ser usados para monitorar o tráfego de e para suas tarefas. Para obter mais informações, consulte [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) no *Guia do usuário do Amazon Virtual Private Cloud*. Você também pode utilizar AWS PrivateLink. É possível configurar um endpoint de interface VPC para que você possa acessar APIs do Amazon ECS por meio de endereços IP privados. AWS PrivateLink restringe todo o tráfego de rede entre sua VPC e o Amazon ECS para a rede da Amazon. Você não precisa de um gateway da Internet, de um dispositivo NAT ou de um gateway privado virtual. Para obter mais informações, consulte [Endpoints da VPC da interface do Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html). Consulte exemplos de como usar o recurso `NetworkConfiguration` com o CloudFormation, consulte [Exemplos de modelos do CloudFormation para o Amazon ECS](working-with-templates.md). As ENIs que são criadas são totalmente gerenciadas pelo AWS Fargate. Além disso, existe uma política do IAM associada que é utilizada para conceder permissões para o Fargate. Para tarefas que usam a versão `1.4.0` ou posterior da plataforma do Fargate, a tarefa recebe uma única ENI (conhecida como ENI de tarefa), e todo o tráfego de rede flui por essa ENI dentro da VPC. Esse tráfego é registrado nos seus logs de fluxo da VPC. Para tarefas que usam a versão `1.3.0` e anterior da plataforma, além da ENI de tarefa, a tarefa também recebe uma ENI de propriedade do Fargate separada, que é usada para algum tráfego de rede que não é visível nos logs de fluxo da VPC. A tabela a seguir descreve o comportamento do tráfego de rede e a política do IAM necessária para cada versão da plataforma. | Ação | Fluxo de tráfego com versão `1.3.0` e anterior da plataforma Linux | Fluxo de tráfego com versão da plataforma Linux `1.4.0` | Fluxo de tráfego com versão da plataforma Windows `1.0.0` | Permissão do IAM | | --- | --- | --- | --- | --- | | Recuperar credenciais de login do Amazon ECR | ENI de propriedade do Fargate | ENI de tarefa | ENI de tarefa | Função do IAM de execução de tarefas | | Extração de imagem | ENI de tarefa | ENI de tarefa | ENI de tarefa | Função do IAM de execução de tarefas | | Como enviar logs por meio de um driver de log | ENI de tarefa | ENI de tarefa | ENI de tarefa | Função do IAM de execução de tarefas | | Enviar logs pelo FireLens para Amazon ECS | ENI de tarefa | ENI de tarefa | ENI de tarefa | Função do IAM de tarefa | | Recuperar segredos do Secrets Manager ou Systems Manager | ENI de propriedade do Fargate | ENI de tarefa | ENI de tarefa | Função do IAM de execução de tarefas | | Tráfego do sistema de arquivos do Amazon EFS | Indisponível | ENI de tarefa | ENI de tarefa | Função do IAM de tarefa | | Tráfego de aplicativos | ENI de tarefa | ENI de tarefa | ENI de tarefa | Função do IAM de tarefa | ## Considerações Considere o seguinte ao usar redes de tarefas: + É necessário que a função vinculada ao serviço do Amazon ECS forneça ao Amazon ECS as permissões para fazer chamadas a outros serviços da AWS em seu nome. Essa função será criada quando você criar um cluster ou se criar ou atualizar um serviço no Console de gerenciamento da AWS. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). Também é possível criar a função vinculada ao serviço usando o comando da AWS CLI a seguir. ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com ``` + O Amazon ECS preenche o nome de host da tarefa usando a rede de tarefas com um nome de host DNS (interno) fornecido pela Amazon quando as opções `enableDnsHostnames` e `enableDnsSupport` estão habilitadas na sua VPC. Se essas opções não estiverem habilitadas, o nome de host DNS da tarefa será definido como um nome de host aleatório. Para obter mais informações sobre as configurações de DNS para uma VPC, consulte [Usar DNS com sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) no *Guia do usuário da Amazon VPC*. + É possível especificar até 16 sub-redes e 5 grupos de segurança para `awsVpcConfiguration`. Para obter mais informações, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) na *Referência da API de serviço do contêiner do Amazon Elastic Container Service*. + Você não pode desanexar ou modificar manualmente as ENIs criadas e anexadas pelo Fargate. Isso visa a evitar a exclusão acidental de uma ENI associada a uma tarefa em execução. Para liberar as ENIs para uma tarefa, interrompa-a. + Se uma sub-rede de VPC for atualizada para alterar o conjunto de opções de DHCP que ela utiliza, não será possível aplicar essas alterações às tarefas existentes que usarem a VPC. Inicie novas tarefas, que receberão a nova configuração para uma migração tranquila ao testar a nova alteração e, em seguida, interrompa as antigas caso nenhuma reversão seja necessária. + O seguinte se aplica às tarefas executadas na plataforma Fargate versão `1.4.0` ou posterior para Linux, ou `1.0.0` para Windows. Tarefas iniciadas em sub-redes de pilha dupla recebem um endereço IPv4 e um endereço IPv6. As tarefas inicializadas em sub-redes somente IPv6 recebem apenas um endereço IPv6. + Para tarefas que utilizam versão da plataforma `1.4.0` ou posterior para Linux ou `1.0.0` para Windows, as ENIs de tarefas oferecem suporte a frames jumbo. As interfaces de rede são configuradas com uma unidade de transmissão máxima (MTU), que se refere ao tamanho da maior carga útil que cabe em um único quadro. Quanto maior a MTU, maior será a carga útil do aplicativo que pode caber em um único quadro, o que reduz a sobrecarga por quadro e aumenta a eficiência. O suporte a quadros jumbo reduz a sobrecarga quando o caminho de rede entre a tarefa e o destino oferece suporte a quadros jumbo. + Os serviços com tarefas que usam o Fargate só oferecem suporte ao Application Load Balancer e ao Network Load Balancer. Não há suporte para Classic Load Balancers. Ao criar grupos de destino, você precisa escolher `ip` como o tipo de destino, e não `instance`. Para obter mais informações, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](service-load-balancing.md). ## Usar uma VPC no modo de pilha dupla Ao usar uma VPC no modo de pilha dupla, suas tarefas podem se comunicar por IPv4, IPv6 ou ambos. Os endereços IPv4 e IPv6 são independentes um do outro e você pode configurar o roteamento e a segurança na VPC separadamente para IPv4 e IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*. As tarefas do Amazon ECS no Fargate receberão um endereço IPv6 se as seguintes condições forem atendidas: + A configuração de conta `dualStackIPv6` do Amazon ECS está ativada (`enabled`) para que a entidade principal do IAM execute as tarefas na região em que você está executando suas tarefas. Essa configuração só pode ser modificada usando a API ou a AWS CLI. Você tem a opção de ativar essa configuração para uma entidade principal do IAM específica na conta ou para toda a conta, definindo a configuração padrão da conta. Para obter mais informações, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md). + Sua VPC e sua sub-rede estão habilitadas para IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*. + Sua sub-rede está habilitada para atribuição automática de endereços IPv6. Para obter mais informações sobre como configurar sua sub-rede, consulte [Modificar o atributo de endereçamento IPv6 para a sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html) no *Guia do usuário da Amazon VPC*. + A tarefa ou o serviço utiliza a versão `1.4.0` ou posterior da plataforma Fargate para Linux. Para tarefas do Amazon ECS no Fargate executadas em uma VPC no modo de pilha dupla, para se comunicar com serviços de dependência usados no processo de execução de tarefas, como ECR, SSM e SecretManager, a tabela de rotas da sub-rede pública precisa de uma rota IPv4 (0.0.0.0/0) para um gateway de internet e a tabela de rotas da sub-rede privada precisa de uma rota IPv4 (0.0.0.0/0) para um Gateway NAT. Para obter mais informações, consulte [gateways da internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) e [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. Para ver exemplos de como configurar uma VPC de pilha dupla, consulte [Exemplo de configuração VPC de pilha dupla](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-example.html). ## Usar uma VPC no modo somente IPv6 Em uma configuração somente IPv6, suas tarefas do Amazon ECS se comunicam exclusivamente via IPv6. Para configurar VPCs e sub-redes para uma configuração somente IPv6, adicione um bloco CIDR IPv6 à VPC e crie sub-redes que incluam apenas um bloco CIDR IPv6. Para obter mais informações, consulte [Adicionar suporte IPv6 para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) e [Criar uma sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) no *Guia do usuário da Amazon VPC*. Atualize também as tabelas de rotas com destinos IPv6 e configure grupos de segurança com regras IPv6. Para obter mais informações, consulte [Configurar tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) e [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Guia do usuário da Amazon VPC*. As seguintes considerações se aplicam: + Você pode atualizar um serviço somente IPv4 ou de pilha dupla do Amazon ECS para uma configuração somente IPv6 atualizando o serviço diretamente para usar sub-redes somente IPv6 ou criando um serviço somente IPv6 paralelo e usando implantações azul-verde do Amazon ECS para transferir o tráfego para o novo serviço. Para obter mais informações sobre implantações azul/verde do Amazon ECS, consulte [Implantações azuis/verdes do Amazon ECS](deployment-type-blue-green.md). + Um serviço somente IPv6 do Amazon ECS deve usar balanceadores de carga de pilha dupla com grupos-de destino IPv6. Se você estiver migrando um serviço do Amazon ECS existente que está por trás de um Application Load Balancer ou de um Network Load Balancer, será possível criar um novo balanceador de carga de pilha dupla e transferir o tráfego do balanceador de carga antigo ou atualizar o tipo de endereço IP do balanceador de carga existente. Para obter mais informações sobre Network Load Balancers consulte [Criar um Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) no *Guia do usuário para Network Load Balancers*. Para obter mais informações sobre Application Load Balancers, consulte [Criar um Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) no *Guia do usuário para Application Load Balancers*. + Não há suporte para a configuração somente IPv6 no Windows. + Para tarefas do Amazon ECS em uma configuração somente IPv6 para se comunicar com endpoints somente IPv4, você pode configurar DNS64 e NAT64 para converter endereços de rede de IPv6 para IPv4. Para obter mais informações, consulte [DNS64 e NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html), no *Guia do usuário da Amazon VPC*. + A configuração somente IPv6 é compatível com a versão da plataforma `1.4.0` ou posterior do Fargate. + As workloads do Amazon ECS em uma configuração somente IPv6 devem usar endpoints de URI de imagem de pilha dupla do Amazon ECR ao extrair imagens do Amazon ECR. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*. **nota** O Amazon ECR não oferece suporte a endpoints da VPC de interface de pilha dupla que as tarefas de uma configuração somente IPv6 possam usar. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*. + Não há suporte para o Amazon ECS Exec em uma configuração somente IPv6. + O Amazon CloudWatch não oferece suporte a um endpoint FIPS de pilha dupla que possa ser usado para monitorar as tarefas do Amazon ECS em configurações somente IPv6 que usam conformidade com FIPS-140. Para obter mais informações sobre FIPS-140, consulte [Padrão Federal de Processamento de Informações (FIPS-140) do AWS Fargate](ecs-fips-compliance.md). ### Regiões da AWS que são compatíveis com o modo somente IPv6 no Amazon ECS Você pode executar tarefas em uma configuração somente IPv6 nas seguintes Regiões da AWS em que o Amazon ECS está disponível: + Leste dos EUA (Ohio) + Leste dos EUA (Norte da Virgínia) + Oeste dos EUA (N. da Califórnia) + Oeste dos EUA (Oregon) + África (Cidade do Cabo) + Ásia-Pacífico (Hong Kong) + Ásia-Pacífico (Hyderabad) + Ásia-Pacífico (Jacarta) + Ásia-Pacífico (Melbourne) + Ásia-Pacífico (Mumbai) + Ásia-Pacífico (Osaka) + Ásia-Pacífico (Seul) + Ásia-Pacífico (Singapura) + Ásia-Pacífico (Sydney) + Ásia-Pacífico (Tóquio) + Canadá (Central) + Oeste do Canadá (Calgary) + China (Pequim) + China (Ningxia) + Europa (Frankfurt) + Europa (Londres) + Europa (Milão) + Europe (Paris) + Europa (Espanha) + Israel (Tel Aviv) + Oriente Médio (Bahrein) + Oriente Médio (Emirados Árabes Unidos) + América do Sul (São Paulo) + AWS GovCloud (Leste dos EUA) + AWS GovCloud (Oeste dos EUA) # Opções de armazenamento para tarefas do Amazon ECS O Amazon ECS fornece opções de armazenamento de dados flexíveis, econômicas e fáceis de usar, dependendo das suas necessidades.. O Amazon ECS oferece suporte às seguintes opções de volume de dados para contêineres: | Volume de dados | Capacidade compatível | Sistemas operacionais compatíveis | Persistência de armazenamento | Casos de uso | | --- | --- | --- | --- | --- | | Amazon Elastic Block Store (Amazon EBS) | Fargate, Amazon EC2, instâncias gerenciadas do Amazon ECS | Linux, Windows (somente no Amazon EC2) | Pode ser persistido quando anexado a uma tarefa autônoma. Temporário quando anexado a uma tarefa mantida por um serviço. | 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. Os casos de uso comuns incluem workloads transacionais, como bancos de dados, áreas de trabalho virtuais e volumes raiz, e workloads com alto throughput, como processamento de logs e workloads ETL. Para obter mais informações, consulte [Uso de volumes do Amazon EBS com o Amazon ECS](ebs-volumes.md). | | Amazon Elastic File System (Amazon EFS) | Fargate, Amazon EC2, instâncias gerenciadas do Amazon ECS | Linux | Persistente | Os volumes do Amazon EFS fornecem armazenamento de arquivos compartilhado simples, escalável e persistente para uso com tarefas do Amazon ECS, que cresce e diminui automaticamente à medida que arquivos são adicionados e removidos. Os volumes do Amazon EFS oferecem suporte à concorrência e são úteis para aplicações em contêineres que escalam horizontalmente e precisam de funcionalidades de armazenamento, como baixa latência, alto throughput e consistência de leitura após gravação. Os casos de uso comuns incluem workloads, como data analytics, processamento de mídia, gerenciamento de conteúdo e distribuição pela Web. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md). | | Amazon FSx para Windows File Server | Amazon EC2 | Windows | Persistente | Os volumes do FSx para Windows File Server fornecem servidores de arquivos do Windows totalmente gerenciados que podem ser usados para provisionar tarefas do Windows que precisam de armazenamento de arquivos persistente, distribuído, compartilhado e estático. Casos de uso comuns incluem aplicações .NET que podem exigir pastas locais como armazenamento persistente para salvar as saídas da aplicação. O Amazon FSx para Windows File Server oferece uma pasta local no contêiner que permite a leitura e gravação de vários contêineres no mesmo sistema de arquivos apoiado por um compartilhamento SMB. Para obter mais informações, consulte [Uso de volumes do FSx para Windows File Server com Amazon ECS](wfsx-volumes.md). | | Amazon FSx para NetApp ONTAP | Amazon EC2 | Linux | Persistente | Os volumes do Amazon FSx para NetApp ONTAP fornecem sistemas de arquivos NetApp ONTAP totalmente gerenciados que podem ser usar para provisionar suas tarefas Linux que precisam de armazenamento de arquivos compartilhado persistente, de alta performance e rico em recursos. O Amazon FSx para NetApp ONTAP oferece suporte aos protocolos NFS e SMB e fornece recursos de nível corporativo, como snapshots, clonagem e desduplicação de dados. Os casos de uso comuns incluem workloads de computação de alta performance, repositórios de conteúdo e aplicações que exigem armazenamento compartilhado compatível com POSIX. Para obter mais informações, consulte [Montar sistemas de arquivos do Amazon FSx para NetApp ONTAP a partir de contêineres do Amazon ECS](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/mount-ontap-ecs-containers.html). | | Volumes do Docker | Amazon EC2 | Windows, Linux | Persistente | Os volumes do Docker são um recurso de runtime do contêiner do Docker que permite que os contêineres persistam os dados montando um diretório no sistema de arquivos do host. Drivers de volume do Docker (também conhecidos como plug-ins) são usados para integrar os volumes do contêiner com os sistemas de armazenamento externos. Os volumes do Docker podem ser gerenciados por drivers de terceiros ou pelo driver local integrado. Casos de uso comuns para volumes do Docker incluem fornecer volumes de dados persistentes ou compartilhar volumes em diferentes locais em diferentes contêineres na mesma instância de contêiner. Para obter mais informações, consulte [Uso de volumes do Docker com o Amazon ECS](docker-volumes.md). | | Montagens bind | Fargate, Amazon EC2, instâncias gerenciadas do Amazon ECS | Windows, Linux | Temporário | As montagens vinculadas consistem em um arquivo ou diretório no host, como uma instância do Amazon EC2 ou o AWS Fargate, que é montado em um contêiner. Casos de uso comuns para montagens vinculadas incluem compartilhar um volume de um contêiner de origem com outros contêineres na mesma tarefa ou montar um volume de host ou um volume vazio em um ou mais contêineres. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md). | # Uso de volumes do Amazon EBS com o Amazon ECS Os volumes do Amazon Elastic Block Store (Amazon EBS) fornecem armazenamento em bloco de alta disponibilidade, econômico, durável e de alta performance para workloads com uso intenso de dados. Os volumes do Amazon EBS podem ser usados com tarefas do Amazon ECS em aplicações de alto throughput e uso intenso de transações. Para obter mais informações sobre volumes do Amazon EBS, consulte [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) no *Guia do usuário do Amazon EBS*. Os volumes do Amazon EBS anexados às tarefas do Amazon ECS são gerenciados pelo Amazon ECS em seu nome. Durante a execução de tarefas autônomas, você pode fornecer a configuração que será usada para anexar um volume do EBS à tarefa. Durante a criação ou atualização do serviço, você pode fornecer a configuração que será usada para anexar um volume do EBS por tarefa a cada tarefa gerenciada pelo serviço do Amazon ECS. Você pode configurar volumes novos e vazios para anexação ou usar snapshots para carregar dados de volumes existentes. **nota** Ao usar snapshots para configurar volumes, você pode especificar uma `volumeInitializationRate`, em MiB/s, no qual os dados são buscados do snapshot para criar volumes totalmente inicializados em um período previsível. Para obter mais informações sobre a inicialização de volumes, consulte [Inicializar volumes do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html) no *Guia do usuário do Amazon EBS*. Para obter mais informações sobre a configuração de volumes do Amazon EBS, consulte [Adiar a configuração de volumes para o momento da inicialização na definição de tarefa do Amazon ECS](specify-ebs-config.md) e [Especificar a configuração de volumes do Amazon EBS na implantação do Amazon ECS](configure-ebs-volume.md). A configuração de volume é adiada para o horário de inicialização usando o parâmetro `configuredAtLaunch` na definição da tarefa. Ao fornecer a configuração de volume no momento da inicialização em vez de na definição da tarefa, você cria definições de tarefas que não estão restritas a um tipo específico de volume de dados ou a configurações específicas de volume do EBS. Em seguida, você pode reutilizar as definições de tarefas em diferentes ambientes de runtime. Por exemplo, você pode fornecer mais throughput durante a implantação para as workloads de produção do que para os ambientes de pré-produção. Os volumes do Amazon EBS anexados às tarefas podem ser criptografados com chaves AWS Key Management Service (AWS KMS) para proteger seus dados. Para obter mais informações, consulte, [Criptografar dados armazenados em volumes do Amazon EBS para tarefas do Amazon ECS](ebs-kms-encryption.md). Para monitorar o desempenho do volume, você também pode usar as métricas do Amazon CloudWatch. Para obter mais informações sobre as métricas do Amazon ECS para volumes do Amazon EBS, consulte [Métricas do CloudWatch do Amazon ECS](available-metrics.md) e [Métricas do Amazon ECS Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html). A anexação de um volume do Amazon EBS a uma tarefa é compatível com todas as [Regiões da AWS](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#region) de empresas comerciais e na China que oferecem suporte ao Amazon ECS. ## Sistemas operacionais e capacidade compatíveis A tabela a seguir fornece as configurações compatíveis de sistema operacional e capacidade. | Capacidade | Linux | Windows | | --- | --- | --- | | Fargate | Os volumes do Amazon EBS são compatíveis com a versão da plataforma 1.4.0 ou posterior (Linux). Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md). | Não compatível | | EC2 | Há suporte para volumes do Amazon EBS nas tarefas hospedadas em instâncias baseadas em Nitro com imagens de máquina da Amazon (AMIs) otimizadas para o Amazon ECS. Para obter mais informações sobre os tipos de instância, consulte [Tipos de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) no Guia do usuário do Amazon EC2. Os volumes do Amazon EBS são compatíveis com a AMI otimizada para ECS `20231219` ou posterior. Para obter mais informações, consulte [Recuperar os metadados da AMI otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html). | Tarefas hospedadas em instâncias baseadas em Nitro com imagens de máquina da Amazon (AMIs) otimizadas para Amazon ECS. Para obter mais informações sobre os tipos de instância, consulte [Tipos de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) no Guia do usuário do Amazon EC2. Os volumes do Amazon EBS são compatíveis com a AMI otimizada para ECS `20241017` ou posterior. Para obter mais informações, consulte [Recuperar os metadados da AMI do Windows otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html). | | Instâncias gerenciadas do Amazon ECS | Os volumes do Amazon EBS são compatíveis com tarefas hospedadas em instâncias gerenciadas do Amazon ECS no Linux. | Não compatível | ## Considerações Considere o seguinte ao usar volumes do Amazon EBS: + Não é possível configurar volumes do Amazon EBS para serem anexados às tarefas do Fargate para Amazon ECS nas zonas de disponibilidade `use1-az3`. + O tipo de volume magnético (`standard`) do Amazon EBS não é compatível com tarefas hospedadas no Fargate. Para obter mais informações sobre os tipos de volumes do Amazon EBS, consulte [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) no *Guia do usuário do Amazon EC2*. + Um perfil do IAM na infraestrutura do Amazon ECS é necessário ao criar um serviço ou uma tarefa autônoma que esteja configurando um volume na implantação. Você pode anexar a política do IAM `AmazonECSInfrastructureRolePolicyForVolumes` gerenciada pela AWS ao perfil ou usar a política gerenciada como um guia para criar e anexar sua própria política com permissões que atendam às suas necessidades específicas. Para obter mais informações, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). + Você pode anexar, no máximo, um volume do Amazon EBS a cada tarefa do Amazon ECS, e ele deve ser novo. Não é possível anexar um volume existente do Amazon EBS a uma tarefa. No entanto, você pode configurar um novo volume do Amazon EBS na implantação usando o snapshot de um volume existente. + Para usar os volumes do Amazon EBS com os serviços do Amazon ECS, o controlador de implantação deve ser `ECS`. Tanto a estratégia de implantação azul/verde como a contínua são compatíveis ao usar esse controlador de implantação. + Para que um contêiner na tarefa grave no volume montado do Amazon EBS, ele deve ter permissões apropriadas do sistema de arquivos. Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume com permissões baseadas em grupo que permitem que o usuário especificado leia e grave no volume. Se nenhum usuário for especificado, o contêiner será executado como raiz e terá acesso total ao volume. + O Amazon ECS adiciona automaticamente as tags reservadas `AmazonECSCreated` e `AmazonECSManaged` ao volume anexado. Se você remover essas tags do volume, o Amazon ECS não poderá gerenciá-lo em seu nome. Para obter mais informações sobre marcação de volumes do Amazon EBS, consulte [Tagging Amazon EBS volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specify-ebs-config.html#ebs-volume-tagging). Para obter mais informações sobre marcação de recursos do Amazon ECS, consulte [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html). + Não há suporte para o provisionamento de volumes usando um snapshot de um volume do Amazon EBS que contém partições. + Os volumes anexados às tarefas gerenciadas por um serviço não são preservados e sempre são excluídos após o encerramento da tarefa. + Não é possível configurar volumes do Amazon EBS para anexar tarefas do Amazon ECS em execução no AWS Outposts. # Comportamento de usuário não raiz Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume do Amazon EBS com permissões baseadas em grupo que permitem que o usuário especificado leia e grave no volume. O volume é montado com as seguintes características: + O volume pertence ao usuário-raiz e ao grupo-raiz. + As permissões de grupo são definidas para permitir acesso de leitura e gravação. + O usuário não raiz é adicionado ao grupo apropriado para acessar o volume. Siga estas práticas recomendadas ao usar volumes do Amazon EBS com contêineres não raiz: + Use IDs de usuário (UIDs) e IDs de grupo (GIDs) consistentes em todas as imagens de contêiner para garantir permissões consistentes. + Crie previamente diretórios de ponto de montagem na imagem do contêiner e defina a propriedade e as permissões apropriadas. + Teste seus contêineres com volumes do Amazon EBS em um ambiente de desenvolvimento para confirmar se as permissões do sistema de arquivos funcionam conforme o esperado. + Se vários contêineres na mesma tarefa compartilharem um volume, certifique-se de que eles usem UIDs/GIDs compatíveis ou montem o volume com expectativas de acesso consistentes. # Adiar a configuração de volumes para o momento da inicialização na definição de tarefa do Amazon ECS Para configurar um volume do Amazon EBS para anexar à tarefa, você deve especificar a configuração do ponto de montagem na definição da tarefa e nomear o volume. Você também deve definir `configuredAtLaunch` como `true` porque os volumes do Amazon EBS não podem ser configurados para anexação na definição da tarefa. Em vez disso, os volumes do Amazon EBS são configurados para associação durante a implantação. Para registrar a definição de tarefa usando a AWS Command Line Interface (AWS CLI), salve o modelo como arquivo JSON e passe o arquivo como entrada para o comando `[register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)`. Para criar e registrar uma definição de tarefa usando o Console de gerenciamento da AWS, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). A definição de tarefa a seguir mostra a sintaxe dos objetos `mountPoints` e `volumes` na definição de tarefa. Para obter mais informações sobre os parâmetros de definição de tarefa, consulte [Parâmetros de definição de tarefa do Amazon ECS para o Fargate](task_definition_parameters.md). Para usar esse exemplo, substitua os `user input placeholders` por suas próprias informações. ## Linux ``` { "family": "mytaskdef", "containerDefinitions": [ { "name": "nginx", "image": "public.ecr.aws/nginx/nginx:latest", "networkMode": "awsvpc", "portMappings": [ { "name": "nginx-80-tcp", "containerPort": 80, "hostPort": 80, "protocol": "tcp", "appProtocol": "http" } ], "mountPoints": [ { "sourceVolume": "myEBSVolume", "containerPath": "/mount/ebs", "readOnly": true } ] } ], "volumes": [ { "name": "myEBSVolume", "configuredAtLaunch": true } ], "requiresCompatibilities": [ "FARGATE", "EC2" ], "cpu": "1024", "memory": "3072", "networkMode": "awsvpc" } ``` ## Windows ``` { "family": "mytaskdef", "memory": "4096", "cpu": "2048", "family": "windows-simple-iis-2019-core", "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole", "runtimePlatform": {"operatingSystemFamily": "WINDOWS_SERVER_2019_CORE"}, "requiresCompatibilities": ["EC2"] "containerDefinitions": [ { "command": ["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

'; C:\\ServiceMonitor.exe w3svc"], "entryPoint": [ "powershell", "-Command" ], "essential": true, "cpu": 2048, "memory": 4096, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "name": "sample_windows_app", "portMappings": [ { "hostPort": 443, "containerPort": 80, "protocol": "tcp" } ], "mountPoints": [ { "sourceVolume": "myEBSVolume", "containerPath": "drive:\ebs", "readOnly": true } ] } ], "volumes": [ { "name": "myEBSVolume", "configuredAtLaunch": true } ], "requiresCompatibilities": [ "FARGATE", "EC2" ], "cpu": "1024", "memory": "3072", "networkMode": "awsvpc" } ``` `mountPoints` Tipo: Matriz de objeto Obrigatório: não Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS. `sourceVolume` Tipo: string Exigido: Sim, quando `mountPoints` são usados O nome do volume a ser montado. `containerPath` Tipo: string Exigido: Sim, quando `mountPoints` são usados O caminho no contêiner onde o volume será montado. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`. `name` Tipo: string Obrigatório: não O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner. `configuredAtLaunch` Tipo: booliano Obrigatório: sim, quando você deseja anexar um volume do EBS diretamente a uma tarefa. Especifica se um volume é configurável na execução. Quando definido como `true`, você pode configurar o volume ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Quando definido como `false`, não será possível fornecer outra configuração de volume na definição da tarefa. Esse parâmetro deve ser fornecido e definido como `true` para configurar um volume do Amazon EBS para anexar a uma tarefa. # Criptografar dados armazenados em volumes do Amazon EBS para tarefas do Amazon ECS Você pode usar o AWS Key Management Service (AWS KMS) para criar e gerenciar chaves criptográficas que protegem seus dados. Os volumes do Amazon EBS são criptografados em repouso usando o AWS KMS keys. Os seguintes tipos de dados são criptografados: + Dados armazenados em repouso no volume + E/S de disco + Snapshots criados no volume + Novos volumes criados de snapshots criptografados Os volumes do Amazon EBS associados a tarefas podem ser criptografados usando uma Chave gerenciada pela AWS padrão com o alias `alias/aws/ebs` ou uma chave simétrica gerenciada pelo cliente especificada na configuração do volume. As Chaves gerenciadas pela AWS padrão são exclusivas para cada Conta da AWS por Região da AWS e são criadas automaticamente. Para criar uma chave simétrica gerenciada pelo cliente, siga as etapas em [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) no *Guia do desenvolvedor do AWS KMS*. É possível configurar a criptografia do Amazon EBS por padrão para que todos os novos volumes criados e anexados a uma Região da AWS específica sejam criptografados usando a chave do KMS especificada para a sua conta. Para obter mais informações sobre criptografia do Amazon EBS e criptografia por padrão, consulte [Criptografia do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) no *Guia do usuário do Amazon EBS*. ## Comportamento de instâncias gerenciadas do Amazon ECS Criptografe volumes do Amazon EBS habilitando a criptografia, usando a criptografia por padrão ou habilitando a criptografia ao criar um volume que deseja criptografar. Para obter informações sobre como habilitar a criptografia por padrão (no nível da conta), consulte [Criptografia por padrão](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) no *Guia do usuário do Amazon EBS*. É possível configurar uma combinação qualquer dessas chaves. A ordem de precedência das chaves do KMS é a seguinte: 1. A chave do KMS especificada na configuração do volume. Quando você especifica uma chave KMS na configuração de volume, ela substitui o padrão do Amazon EBS e qualquer chave KMS especificada no nível da conta. 1. A chave KMS especificada no nível da conta. Quando você especifica uma chave do KMS para criptografia no nível de cluster do armazenamento gerenciado do Amazon ECS, ela substitui a criptografia padrão do Amazon EBS, mas não substitui nenhuma chave do KMS especificada na configuração do volume. 1. Criptografia padrão do Amazon EBS. A criptografia padrão se aplica quando você não especifica uma chave KMS no nível da conta ou uma chave na configuração de volume. Se você habilitar a criptografia do Amazon EBS por padrão, o padrão será a chave do KMS que você especifica para criptografia por padrão. Caso contrário, o padrão é o Chave gerenciada pela AWS com o alias `alias/aws/ebs`. **nota** Se você definir `encrypted` como `false` na configuração de volume, não especificar nenhuma chave KMS no nível da conta e habilitar a criptografia do Amazon EBS por padrão, o volume ainda será criptografado com a chave especificada para a criptografia do Amazon EBS por padrão. ## Comportamento de instâncias gerenciadas não do Amazon ECS Você também pode configurar a criptografia em nível de cluster do Amazon ECS para armazenamento gerenciado do Amazon ECS ao criar ou atualizar um cluster. A criptografia no nível do cluster tem efeito no nível da tarefa e pode ser usada para criptografar os volumes do Amazon EBS anexados a cada tarefa executada em um cluster específico usando a chave KMS especificada. Para obter mais informações sobre como configurar a criptografia no nível do cluster para cada tarefa, consulte [ManagedStorageConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedStorageConfiguration.html) na *Referência da API do Amazon ECS*. É possível configurar uma combinação qualquer dessas chaves. A ordem de precedência das chaves do KMS é a seguinte: 1. A chave do KMS especificada na configuração do volume. Quando você especifica uma chave KMS na configuração do volume, ela substitui o padrão do Amazon EBS e qualquer chave do KMS especificada no nível do cluster. 1. A chave do KMS especificada no nível do cluster. Quando você especifica uma chave do KMS para criptografia no nível de cluster do armazenamento gerenciado do Amazon ECS, ela substitui a criptografia padrão do Amazon EBS, mas não substitui nenhuma chave do KMS especificada na configuração do volume. 1. Criptografia padrão do Amazon EBS. A criptografia padrão se aplica quando você não especifica uma chave do KMS em nível do cluster ou uma chave na configuração do volume. Se você habilitar a criptografia do Amazon EBS por padrão, o padrão será a chave do KMS que você especifica para criptografia por padrão. Caso contrário, o padrão é o Chave gerenciada pela AWS com o alias `alias/aws/ebs`. **nota** Se você definir `encrypted` como `false` na configuração do volume, não especificar nenhuma chave do KMS em nível de cluster e habilitar a criptografia do Amazon EBS por padrão, o volume ainda será criptografado com a chave especificada para a criptografia do Amazon EBS por padrão. ## Política de chave do KMS gerenciada pelo cliente Para criptografar um volume do EBS anexado à tarefa usando uma chave gerenciada pelo cliente, você deve configurar sua política de chave do KMS para garantir que o perfil do IAM usado na configuração do volume tenha as permissões necessárias para usar a chave. A política de chave deve incluir as permissões `kms:CreateGrant` e `kms:GenerateDataKey*`. As permissões `kms:ReEncryptTo` e `kms:ReEncryptFrom` são necessárias para criptografar volumes criados usando snapshots. Se quiser configurar e criptografar somente volumes novos e vazios para anexação, você pode excluir as permissões `kms:ReEncryptTo` e `kms:ReEncryptFrom`. O trecho JSON a seguir mostra as instruções de política de chave que você pode anexar à sua política de chave do KMS. O uso dessas instruções fornecerá acesso ao Amazon ECS para usar a chave para criptografar o volume do EBS. Para usar os exemplos de instruções de política, substitua os `user input placeholders` por suas próprias informações. Como sempre, configure apenas as permissões de que você precisa. ``` { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:DescribeKey", "Resource":"*" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": [ "kms:GenerateDataKey*", "kms:ReEncryptTo", "kms:ReEncryptFrom" ], "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:CreateGrant", "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" }, "Bool": { "kms:GrantIsForAWSResource": true } } } ``` Para obter mais informações sobre políticas e permissões de chave, consulte [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) e [AWS KMS permissions](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html) no *Guia do desenvolvedor do AWS KMS*. Para solucionar problemas de anexação de volumes do EBS relacionados às permissões de chave, consulte [Solução de problemas de anexações de volumes do Amazon EBS às tarefas do Amazon ECS](troubleshoot-ebs-volumes.md). # Especificar a configuração de volumes do Amazon EBS na implantação do Amazon ECS Depois de registrar uma definição de tarefa com o parâmetro `configuredAtLaunch` definido como `true`, você pode configurar um volume do Amazon EBS na implantação ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Para obter mais informações sobre como adiar a configuração de volume para o momento da inicialização usando o parâmetro `configuredAtLaunch`, consulte [Adiar a configuração de volumes para o momento da inicialização na definição de tarefa do Amazon ECS](specify-ebs-config.md). Para configurar um volume, você pode usar as APIs do Amazon ECS ou passar um arquivo JSON como entrada para os seguintes comandos da AWS CLI: + `[run-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)` para executar uma tarefa autônoma do ECS. + `[start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html)` para executar uma tarefa autônoma do ECS em uma instância de contêiner específica. Esse comando não é aplicável às tarefas do Fargate. + `[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)` para criar um serviço do ECS. + `[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)` para atualizar um serviço existente. **nota** Para que um contêiner na tarefa grave no volume montado do Amazon EBS, ele deve ter permissões apropriadas do sistema de arquivos. Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume com permissões baseadas em grupo que permitem que o usuário especificado leia e grave no volume. Se nenhum usuário for especificado, o contêiner será executado como raiz e terá acesso total ao volume. Você também pode configurar um volume do Amazon EBS usando o Console de gerenciamento da AWS. Para obter mais informações, consulte [Execução de uma aplicação como uma tarefa do Amazon ECS](standalone-task-create.md), [Criação de uma implantação de atualização contínua do Amazon ECS](create-service-console-v2.md) e [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). O trecho JSON a seguir mostra todos os parâmetros de um volume do Amazon EBS que podem ser configurados na implantação. Para usar esses parâmetros na configuração de volume, substitua os `user input placeholders` por suas próprias informações. Para obter mais informações sobre esses parâmetros, consulte [Volume configurations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-volumeConfigurations). ``` "volumeConfigurations": [ { "name": "ebs-volume", "managedEBSVolume": { "encrypted": true, "kmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "volumeType": "gp3", "sizeInGiB": 10, "snapshotId": "snap-12345", "volumeInitializationRate":100, "iops": 3000, "throughput": 125, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn": "arn:aws:iam::1111222333:role/ecsInfrastructureRole", "terminationPolicy": { "deleteOnTermination": true//can't be configured for service-managed tasks, always true }, "filesystemType": "ext4" } } ] ``` **Importante** Certifique-se de que o `volumeName` especificado na configuração seja o mesmo `volumeName` especificado na definição de tarefa. Para obter informações sobre como verificar o status de anexação de volumes, consulte [Solução de problemas de anexações de volumes do Amazon EBS às tarefas do Amazon ECS](troubleshoot-ebs-volumes.md). Para obter informações sobre o perfil do AWS Identity and Access Management (IAM) na infraestrutura do Amazon ECS necessário para a anexação de volumes do EBS, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). Veja a seguir exemplos de trechos JSON que mostram a configuração dos volumes do Amazon EBS. Esses exemplos podem ser usados salvando os trechos em arquivos JSON e passando os arquivos como parâmetros (usando o parâmetro `--cli-input-json file://filename`) para comandos da AWS CLI. Substitua `user input placeholders` por suas próprias informações. ## Configuração de um volume para uma tarefa autônoma O trecho a seguir mostra a sintaxe para configurar volumes do Amazon EBS para anexação a uma tarefa autônoma. O trecho JSON a seguir mostra a sintaxe para definir as configurações de `volumeType`, `sizeInGiB`, `encrypted` e `kmsKeyId`. A configuração especificada no arquivo JSON é usada para criar e anexar um volume do EBS à tarefa autônoma. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` ## Configuração de um volume na criação do serviço O trecho a seguir mostra a sintaxe para configurar volumes do Amazon EBS para anexação a tarefas gerenciadas por um serviço. Os volumes são baseados no snapshot especificado usando o parâmetro `snapshotId` a uma taxa de 200 MiB/s. A configuração especificada no arquivo JSON é usada para criar e anexar um volume do EBS a cada tarefa gerenciada pelo serviço. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "snapshotId": "snap-12345", "volumeInitializationRate": 200 } } ] } ``` ## Configuração de um volume na atualização do serviço O trecho JSON a seguir mostra a sintaxe para atualizar um serviço que anteriormente não tinha volumes do Amazon EBS configurados para anexar a tarefas. Você deve fornecer o ARN de uma revisão de definição de tarefa com `configuredAtLaunch` definido como `true`. O trecho JSON a seguir mostra a sintaxe para definir `volumeType`, `sizeInGiB`, `throughput` e `iops` e as configurações de `filesystemType`. Essa configuração é usada para criar e anexar um volume do EBS a cada tarefa gerenciada pelo serviço. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "volumeType": "gp3", "sizeInGiB": 100, "iops": 3000, "throughput": 125, "filesystemType": "ext4" } } ] } ``` ### Configuração de um serviço para não utilizar mais os volumes do Amazon EBS O trecho JSON a seguir mostra a sintaxe para atualizar um serviço para não utilizar mais os volumes do Amazon EBS. Você deve fornecer o ARN de uma definição de tarefa com `configuredAtLaunch` definido como `false` ou de uma definição de tarefa sem o parâmetro `configuredAtLaunch`. Você também deve fornecer um objeto `volumeConfigurations` vazio. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [] } ``` ## Política de encerramento para volumes do Amazon EBS Quando uma tarefa do Amazon ECS é encerrada, o Amazon ECS usa o valor de `deleteOnTermination` para determinar se o volume do Amazon EBS associado à tarefa encerrada deve ser excluído. Por padrão, os volumes do EBS anexados às tarefas são excluídos quando a tarefa é encerrada. Em tarefas autônomas, você pode alterar essa configuração para preservar o volume após o encerramento da tarefa. **nota** Os volumes anexados às tarefas gerenciadas por um serviço não são preservados e sempre são excluídos após o encerramento da tarefa. ## Tags em volumes do Amazon EBS Você pode marcar volumes do Amazon EBS usando o objeto `tagSpecifications`. Usando o objeto, você pode fornecer suas próprias tags e definir a propagação delas na definição da tarefa ou do serviço, dependendo se o volume está anexado a uma tarefa autônoma ou a uma tarefa em um serviço. O número máximo de tags que podem ser anexadas a um volume é 50. **Importante** O Amazon ECS anexa automaticamente as tags reservadas `AmazonECSCreated` e `AmazonECSManaged` a um volume do Amazon EBS. Isso significa que você pode controlar a anexação de no máximo 48 tags adicionais a um volume. Essas tags adicionais podem ser definidas pelo usuário, gerenciadas pelo ECS ou propagadas. Se quiser adicionar tags gerenciadas pelo Amazon ECS ao volume, você deve definir `enableECSManagedTags` como `true` na chamada de `UpdateService`, `CreateService`, `RunTask` ou `StartTask`. Se você ativar as tags gerenciadas pelo Amazon ECS, o Amazon ECS marca o volume automaticamente com informações de cluster e serviço (`aws:ecs:clusterName` e `aws:ecs:serviceName`). Para obter mais informações sobre marcação de recursos do Amazon ECS, consulte [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html). O trecho JSON a seguir mostra a sintaxe para marcar cada volume do Amazon EBS anexado a cada tarefa em um serviço com uma tag definida pelo usuário. Para usar esse exemplo para criar um serviço, substitua os `user input placeholders` pelas suas próprias informações. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "enableECSManagedTags": true, "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn":"arn:aws:iam:1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` **Importante** Você deve especificar um tipo de recurso de `volume` para marcar os volumes do Amazon EBS. # Desempenho de volumes do Amazon EBS para tarefas sob demanda do Fargate As IOPS e o throughput básico de volume do Amazon EBS disponíveis para uma tarefa sob demanda do Fargate dependem do total de unidades de CPU solicitadas para a tarefa. Se você solicitar 0,25, 0,5 ou 1 unidade de CPU virtual (vCPU) para a tarefa do Fargate, recomendamos configurar um volume SSD de uso geral (`gp2` ou `gp3`) ou um volume de unidade de disco rígido (HDD) (`st1` ou `sc1`). Se você solicitar mais de 1 vCPU para a tarefa do Fargate, os limites básicos de desempenho a seguir se aplicam a um volume do Amazon EBS anexado à tarefa. Você pode obter temporariamente um desempenho do EBS superior aos limites a seguir. No entanto, é recomendável planejar a workload com base nesses limites. | Unidades de CPU solicitadas (em vCPUs) | IOPS básicas do Amazon EBS (E/S de 16 KiB) | Throughput básico do Amazon EBS (em MiBps, E/S de 128 KiB) | Largura de banda básica (Mbps) | | --- | --- | --- | --- | | 2 | 3.000 | 75 | 360 | | 4 | 5.000 | 120 | 1.150 | | 8 | 10.000 | 250 | 2.300 | | 16 | 15.000 | 500 | 4,500 | **nota** Ao configurar um volume do Amazon EBS para ser anexado a uma tarefa do Fargate, o limite de performance do Amazon EBS para a tarefa do Fargate é compartilhado entre o armazenamento temporário da tarefa e o volume anexado. # Desempenho dos volumes do Amazon EBS para tarefas do EC2 O Amazon EBS fornece tipos de volume que diferem em características de performance e preço para que você possa adaptar o custo e a performance de armazenamento às necessidades das aplicações. Para obter informações sobre performance, incluindo IOPS por volume e throughput por volume, consulte [Tipos de volume do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) no *Guia do usuário do Amazon Elastic Block Store*. # Performance de volumes do Amazon EBS para tarefas de instâncias gerenciadas do Amazon ECS O Amazon EBS fornece tipos de volume que diferem em características de performance e preço para que você possa adaptar o custo e a performance de armazenamento às necessidades das aplicações. Para obter informações sobre performance, incluindo IOPS por volume e throughput por volume, consulte [Tipos de volume do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) no *Guia do usuário do Amazon Elastic Block Store*. # Solução de problemas de anexações de volumes do Amazon EBS às tarefas do Amazon ECS Talvez seja necessário solucionar problemas ou verificar a anexação dos volumes do Amazon EBS às tarefas do Amazon ECS. ## Verificação do status de anexação de volumes Você pode usar o Console de gerenciamento da AWS para visualizar o status de anexação de um volume do Amazon EBS a uma tarefa do Amazon ECS. Se a tarefa for iniciada e a anexação falhar, você também verá um motivo do status que pode ser usado para solucionar problemas. O volume criado será excluído e a tarefa será interrompida. Para obter mais informações sobre os motivos de status, consulte [Motivos do status para anexação do volume do Amazon EBS às tarefas do Amazon ECS](troubleshoot-ebs-volumes-scenarios.md). **Para visualizar o status de anexação e o motivo do status de um volume usando o console** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster em que a tarefa está sendo executada. A página de detalhes do cluster é exibida. 1. Na página de detalhes do cluster, escolha a guia **Tarefas**. 1. Escolha a tarefa cujo status de anexação de volumes você deseja visualizar. Talvez seja necessário usar **Filtrar o status desejado** e escolher **Interrompida** se a tarefa que você deseja examinar tiver sido interrompida. 1. Na página de detalhes da tarefa, escolha a guia **Volumes**. Você poderá ver o status de anexação do volume do Amazon EBS em **Status do anexo**. Se o volume apresentar falhas ao ser anexado à tarefa, você poderá escolher o status em **Status do anexo** para exibir a causa da falha. Você também pode visualizar o status de anexação de volumes de uma tarefa e o motivo associado do status usando a API [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html). ## Falhas de serviço e tarefas Você pode encontrar falhas em serviços ou tarefas que não são específicas dos volumes do Amazon EBS e que podem afetar a anexação do volume. Para obter mais informações, consulte + [Mensagens de evento de serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-event-messages.html) + [Códigos de erro de tarefas interrompidas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html) + [Motivos de falha da API](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/api_failures_messages.html) # O contêiner não pode gravar no volume do Amazon EBS Usuário não root sem as permissões corretas Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume com permissões baseadas em grupo que permitem o acesso de gravação. No entanto, se você ainda estiver enfrentando problemas de permissão: + Verifique se o parâmetro `user` está especificado corretamente na definição de contêiner usando o formato `uid:gid` (por exemplo,`1001:1001`). + Certifique-se de que a imagem do contêiner não substitua as permissões do usuário após a montagem do volume. + Verifique se sua aplicação está sendo executada com o ID de usuário esperado examinando os logs do contêiner ou usando o Amazon ECS Exec para inspecionar o contêiner em execução. Usuário-root com problemas de permissão Se nenhum usuário for especificado em sua definição de contêiner, o contêiner será executado como raiz e deverá ter acesso total ao volume. Se você estiver enfrentando problemas: + Verifique se o volume está montado corretamente conferindo os pontos de montagem dentro do contêiner. + Garanta que volume não esteja configurado como somente leitura na configuração de ponto de montagem. Tarefas de vários contêineres com diferentes usuários Em tarefas com vários contêineres sendo executados como usuários diferentes, o Amazon ECS gerencia automaticamente as permissões de grupo para permitir que todos os usuários especificados gravem no volume. Se os contêineres não puderem gravar: + Verifique se todos os contêineres que exigem acesso de gravação têm o parâmetro `user` configurado corretamente. + Verifique se o volume está montado em todos os contêineres que precisam acessá-lo. Para obter mais informações sobre como configurar usuários em definições de contêiner, consulte [ Parâmetros de definição de tarefa do Amazon ECS para o Fargate ](https://docs.aws.amazon.com/./task_definition_parameters.html). # Motivos do status para anexação do volume do Amazon EBS às tarefas do Amazon ECS Use a referência a seguir para corrigir problemas que você possa encontrar na forma de motivos de status no Console de gerenciamento da AWS ao configurar volumes do Amazon EBS para anexação às tarefas do Amazon ECS. Para obter mais informações sobre como localizar esses motivos de status no console, consulte [Verificação do status de anexação de volumes](troubleshoot-ebs-volumes.md#troubleshoot-ebs-volumes-location). O ECS não conseguiu assumir o perfil de infraestrutura do ECS configurado 'arn:aws:iam::*111122223333*:role/*ecsInfrastructureRole*'. Verifique se o perfil que está sendo passado tem a relação de confiança adequada com o Amazon ECS Esse motivo de status aparece nos cenários a seguir. + Você fornece um perfil do IAM sem a política de confiança necessária anexada. O Amazon ECS não poderá acessar o perfil do IAM de infraestrutura do Amazon ECS fornecida se o perfil não tiver a política de confiança necessária. A tarefa pode ficar presa no estado `DEPROVISIONING`. Para obter mais informações sobre a política de confiança necessária, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). + O usuário do IAM não tem permissão para passar o perfil de infraestrutura do Amazon ECS para o Amazon ECS. A tarefa pode ficar presa no estado `DEPROVISIONING`. Para evitar esse problema, você pode anexar a permissão `PassRole` ao usuário. Para obter mais informações, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). + O perfil do IAM não tem as permissões necessárias para anexação de volumes do Amazon EBS. A tarefa pode ficar presa no estado `DEPROVISIONING`. Para obter mais informações sobre as permissões específicas necessárias para anexação de volumes do Amazon EBS às tarefas, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). Você também pode ver essa mensagem de erro devido a um atraso na propagação do perfil. Se tentar usar o perfil novamente depois de esperar alguns minutos não resolver o problema, você pode ter configurado incorretamente a política de confiança do perfil. O ECS não conseguiu configurar o volume do EBS. IdempotentParameterMismatch” encontrado; “O token do cliente que você forneceu está associado a um recurso que já foi excluído. Use um token de cliente diferente." Os seguintes cenários envolvendo a chave do AWS KMS podem fazer com que uma mensagem de `IdempotentParameterMismatch` apareça: + Você especifica um ARN, ID ou alias da chave do KMS que não é válido. Nesse cenário, a tarefa pode parecer ter sido executada com êxito, mas ela falhará, porque a AWS autentica a chave do KMS de forma assíncrona. Para obter mais informações, consulte [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) no *Guia do usuário do Amazon EC2*. + Você fornece uma chave gerenciada pelo cliente sem as permissões para que o perfil do IAM de infraestrutura do Amazon ECS use a chave para criptografia. Para evitar problemas na permissão da política de chave, consulte o exemplo política de chave do AWS KMS em [Data encryption for Amazon EBS volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html#ebs-kms-encryption). Você pode configurar o Amazon EventBridge para enviar eventos de volumes do Amazon EBS e eventos de alteração do estado de tarefas do Amazon ECS para um destino, como grupos do Amazon CloudWatch. Em seguida, você pode usar esses eventos para identificar o problema específico relacionado à chave gerenciada pelo cliente que afetou a anexação do volume. Para obter mais informações, consulte + [Como posso criar um grupo de logs do CloudWatch para usar como destino para uma regra do EventBridge?](https://repost.aws/knowledge-center/cloudwatch-log-group-eventbridge) no AWS re:Post. + [Task state change events](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html#ecs_task_events). + [Eventos do Amazon EventBridge para Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html) no *Guia do usuário do Amazon EBS*. O ECS atingiu o tempo limite ao configurar a anexação de volumes do EBS à tarefa. Os cenários a seguir, relacionados ao formato do sistema de arquivos, resultam nessa mensagem. + O formato do sistema de arquivos que você especifica durante a configuração não é compatível com o [sistema operacional da tarefa](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RuntimePlatform.html). + Você configura um volume do Amazon EBS para ser criado de um snapshot, e o formato do sistema de arquivos do snapshot não é compatível com o sistema operacional da tarefa. Em volumes criados de um snapshot, você deve especificar o mesmo tipo de sistema de arquivos que o volume estava usando quando o snapshot foi criado. Você pode utilizar os logs do agente de contêiner do Amazon ECS para solucionar essa mensagem em tarefas EC2. Para obter mais informações, consulte [Amazon ECS log file locations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html) e [Amazon ECS log collector](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-logs-collector.html). # Uso de volumes do Amazon EFS com o Amazon ECS O Amazon Elastic File System (Amazon EFS) oferece armazenamento simples e escalável de arquivos para uso com tarefas do Amazon ECS. Com o Amazon EFS, a capacidade de armazenamento é elástica. Ela aumenta e diminui automaticamente à medida que arquivos são adicionados e removidos. Suas aplicações poderão ter o armazenamento que precisarem e quando precisarem. Use os sistemas de arquivos do Amazon EFS com o Amazon ECS para exportar dados do sistema de arquivos em sua frota de instâncias de contêiner. Desse modo, suas tarefas terão acesso ao mesmo armazenamento persistente, não importa a instância em que estejam. Suas definições de tarefa devem fazer referências a montagens de volume na instância de contêiner para usar o sistema de arquivos. Para ver um tutorial, consulte [Configurar os sistemas de arquivos do Amazon EFS para o Amazon ECS usando o console](tutorial-efs-volumes.md). ## Considerações Considere o seguinte ao usar volumes do Amazon EFS: + Para tarefas executadas no EC2, o suporte do sistema de arquivos do Amazon EFS foi adicionado como visualização prévia pública com a versão `20191212` da AMI otimizada para o Amazon ECS com a versão 1.35.0 do agente de contêiner. No entanto, o suporte ao sistema de arquivos do Amazon EFS se tornou disponível para o público com a versão `20200319` da AMI otimizada para Amazon ECS com a versão 1.38.0 do agente de contêiner, que continha os recursos de ponto de acesso do Amazon EFS e de autorização do IAM. Recomendamos o uso da versão `20200319` ou posterior da AMI otimizada para Amazon ECS ou posterior para usar esses recursos. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). **nota** Se você criar sua própria AMI, deverá usar o agente de contêiner 1.38.0 ou posterior, `ecs-init` versão 1.38.0-1 ou posterior e executar os comandos a seguir na instância do Amazon EC2 para habilitar o plug-in de volume do Amazon ECS. Os comandos dependem de você estar usando o Amazon Linux 2 ou o Amazon Linux como imagem base. Amazon Linux 2 ``` yum install amazon-efs-utils systemctl enable --now amazon-ecs-volume-plugin ``` Amazon Linux ``` yum install amazon-efs-utils sudo shutdown -r now ``` + Para tarefas hospedadas no Fargate, os sistemas de arquivos do Amazon EFS são compatíveis com a versão 1.4.0 ou posterior (Linux) da plataforma. Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md). + Ao usar volumes do Amazon EFS para tarefas hospedadas no Fargate, o Fargate cria um contêiner do supervisor responsável pelo gerenciamento do volume do Amazon EFS. O contêiner do supervisor usa uma pequena quantidade de memória da tarefa e CPU. O contêiner supervisor fica visível ao consultar a versão 4 do endpoint de metadados de tarefa. Além disso, ele é visível no CloudWatch Container Insights como o nome de contêiner `aws-fargate-supervisor`. Para obter mais informações ao usar o EC2, consulte [Endpoint de metadados de tarefas do Amazon ECS versão 4](task-metadata-endpoint-v4.md). Para obter mais informações ao usar o Fargate, consulte [Endpoint de metadados de tarefas do Amazon ECS versão 4 para tarefas no Fargate](task-metadata-endpoint-v4-fargate.md). + Não há suporte para o uso de volumes do Amazon EFS ou a especificação de um `EFSVolumeConfiguration` em instâncias externas. + O uso de volumes do Amazon EFS é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. + Recomendamos que você defina o parâmetro `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` no arquivo de configuração do agente como um valor menor do que o padrão (cerca de 1 hora). Essa alteração ajuda a evitar a expiração da credencial de montagem do EFS e permite limpar as montagens que não estão em uso. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). ## Uso dos pontos de acesso do Amazon EFS Os pontos de acesso do Amazon EFS são pontos de entrada específicos da aplicação para um sistema de arquivos do EFS para gerenciar o acesso de aplicações a conjuntos de dados compartilhados. Para obter mais informações sobre pontos de acesso do Amazon EFS e como controlar o acesso a eles, consulte [Trabalhar com pontos de acesso do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) no *Guia do usuário do Amazon Elastic File System*. Os pontos de acesso podem impor uma identidade de usuário, inclusive grupos POSIX do usuário, para todas as solicitações do sistema de arquivamento feitas por meio do ponto de acesso. Pontos de acesso também podem impor um diretório raiz distinto para o sistema de arquivos. Isso é feito para que os clientes apenas possam acessar dados no diretório definido ou em seus subdiretórios. **nota** Ao criar um ponto de acesso do EFS, você especifica um caminho no sistema de arquivos para servir como o diretório raiz. Ao fazer referência ao sistema de arquivos do EFS com um ID de ponto de acesso em sua definição de tarefa do Amazon ECS, o diretório raiz deve ser omitido ou definido como `/`, o que impõe o caminho definido no ponto de acesso do EFS. É possível usar uma função do IAM da tarefa do Amazon ECS para obrigar que aplicações específicas usem um ponto de acesso específico. Ao combinar políticas do IAM com pontos de acesso, você pode fornecer facilmente acesso seguro a conjuntos de dados específicos para as suas aplicações. Para obter mais informações sobre como usar perfis do IAM de tarefa, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md). # Práticas recomendadas para usar volumes do Amazon EFS com o Amazon ECS Anote as práticas recomendadas a seguir ao usar o Amazon EFS com o Amazon ECS. ## Controles de segurança e acesso para volumes do Amazon EFS O Amazon EFS oferece recursos de controle de acesso para garantir que os dados armazenados em um sistema de arquivos do Amazon EFS estejam seguros e acessíveis somente em aplicações que precisam deles. Você pode proteger os dados habilitando a criptografia em repouso e em trânsito. Para obter mais informações, consulte [Criptografia de dados no Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) no *Manual do usuário do Amazon Elastic File System*. Além da criptografia de dados, você pode usar o Amazon EFS para restringir o acesso a um sistema de arquivos. Há três maneiras de implementar o controle de acesso no EFS. + **Grupos de segurança**: com os destinos de montagem do Amazon EFS, você pode configurar um grupo de segurança usado para permitir e negar tráfego de rede. É possível configurar o grupo de segurança anexado ao Amazon EFS para permitir o tráfego do NFS (porta 2049) do grupo de segurança que está conectado às instâncias do Amazon ECS ou, ao usar o modo de rede `awsvpc`, da tarefa do Amazon ECS. + **IAM**: você pode restringir o acesso a um sistema de arquivos do Amazon EFS usando o IAM. Quando configuradas, as tarefas do Amazon ECS exigem um perfil do IAM para acessar o sistema de arquivos e montar um sistema de arquivos do EFS. Para obter mais informações, consulte [Usar o IAM para controlar o acesso de dados do system de arquivos](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html) no *Guia do usuário do Amazon Elastic File System*. As políticas do IAM também podem impor condições predefinidas, como exigir que um cliente use TLS ao se conectar a um sistema de arquivos do Amazon EFS. Para obter mais informações, consulte [Amazon EFS condition keys for clients](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#efs-condition-keys-for-nfs) no *Guia do usuário do Amazon Elastic File System*. + **Pontos de acesso do Amazon EFS**: os pontos de acesso do Amazon EFS são pontos de entrada específicos da aplicação em um sistema de arquivos do Amazon EFS. Você pode usar os pontos de acesso para impor uma identidade de usuário, incluindo grupos POSIX do usuário, a todas as solicitações do sistema de arquivos feitas por meio do ponto de acesso. Pontos de acesso também podem impor um diretório raiz distinto para o sistema de arquivos. Isso é feito para que os clientes só possam acessar dados no diretório especificado ou em seus subdiretórios. ### Políticas do IAM É posssível usar políticas do IAM para controlar o acesso ao sistema de arquivos do Amazon EFS. É possível especificar as ações a seguir para clientes NFS em um sistema de arquivos usando uma política de sistema de arquivos. | Ação | Descrição | | --- | --- | | `elasticfilesystem:ClientMount` | Fornece acesso somente leitura a um sistema de arquivos para um cliente NFS. | | `elasticfilesystem:ClientWrite` | Fornece permissões de gravação em um sistema de arquivos. | | `elasticfilesystem:ClientRootAccess` | Fornece o uso do usuário raiz ao acessar um sistema de arquivos. | Você precisa especificar cada ação em uma política. É possível definir políticas das seguintes maneiras: + Baseada no cliente: anexe a política ao perfil da tarefa Defina a opção **Autorização do IAM** ao criar a definição da tarefa. + Baseada em recursos: anexe a política ao sistema de arquivos do Amazon EFS Se a política baseada em recursos não existir, por padrão, na criação do sistema de arquivos, o acesso será concedido a todas as entidades principais (\$1). Quando você define a opção **Autorização do IAM**, mesclamos a política associada ao perfil da tarefa e a baseada em recursos do Amazon EFS. A opção **Autorização do IAM** passa a identidade da tarefa (o perfil da tarefa) com a política para o Amazon EFS. Isso permite que a política baseada em recursos do Amazon EFS tenha contexto para o usuário ou perfil do IAM especificado na política. Se você não definir a opção, a política em nível de recurso do Amazon EFS identificará o usuário do IAM como "anônimo". Considere implementar todos os três controles de acesso em um sistema de arquivos do Amazon EFS para obter segurança máxima. Por exemplo, você pode configurar o grupo de segurança anexado a um ponto de montagem do Amazon EFS para permitir somente a entrada de tráfego do NFS de um grupo de segurança associado à instância de contêiner ou tarefa do Amazon ECS. Além disso, você pode configurar o Amazon EFS para exigir um perfil do IAM para acessar o sistema de arquivos, mesmo que a conexão seja originada de um grupo de segurança permitido. Por último, você pode usar os pontos de acesso do Amazon EFS para impor permissões de usuário POSIX e especificar diretórios raiz para aplicações. O trecho de definição de tarefa a seguir mostra como montar um sistema de arquivos do Amazon EFS usando um ponto de acesso. ``` "volumes": [ { "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" }, "transitEncryption": "ENABLED", "rootDirectory": "" }, "name": "my-filesystem" } ] ``` ## Performance de volumes do Amazon EFS O Amazon EFS oferece dois modos de desempenho: uso geral e E/S máxima. O uso geral é adequado para aplicações sensíveis à latência, como sistemas de gerenciamento de conteúdo e ferramentas de CI/CD. Por outro lado, os sistemas de arquivos com E/S máxima são adequados para workloads como data analytics, processamento de mídia e machine learning. Essas workloads precisam realizar operações paralelas de centenas ou até milhares de contêineres e exigem o maior throughput agregado e IOPS possíveis. Para obter mais informações, consulte [Amazon EFS performance modes](https://docs.aws.amazon.com/efs/latest/ug/performance.html#performancemodes) no *Guia do usuário do Amazon Elastic File System*. Algumas workloads sensíveis à latência exigem os níveis mais altos de E/S fornecidos pelo modo de desempenho de E/S máxima e a latência mais baixa fornecida pelo modo de desempenho de uso geral. Para esse tipo de workload, recomendamos a criação de vários sistemas de arquivos do modo de desempenho de uso geral. Nesse caso, recomendamos distribuir a workload da aplicação em todos esses sistemas de arquivos, desde que a workload e as aplicações possam oferecer suporte a ela. ## Throughput dos volumes do Amazon EFS Todos os sistemas de arquivos do Amazon EFS têm um throughput associado medido, determinado pela quantidade de throughput provisionado para sistemas de arquivos que usam *Throughput provisionado* ou pela quantidade de dados armazenados na classe de armazenamento EFS Standard ou One Zone para sistemas de arquivos que usam *Throughput intermitente*. Para obter mais informações, consulte [Understanding metered throughput](https://docs.aws.amazon.com/efs/latest/ug/performance.html#read-write-throughput) no *Guia do usuário do Amazon Elastic File System*. O modo de throughput padrão dos sistemas de arquivos do Amazon EFS é o modo intermitente. Com o modo intermitente, o throughput disponível para um sistema de arquivos aumenta ou reduz a escala verticalmente à medida que o sistema de arquivos cresce. Como workloads baseadas em arquivos costumam apresentar picos, exigindo altos níveis de throughput por um tempo e níveis mais baixos de throughput no restante, o Amazon EFS foi criado para intermitência, permitindo altos níveis de throughput por alguns períodos. Além disso, como várias workloads exigem muita leitura, as operações de leitura são medidas na proporção de 1:3 em relação a outras operações de NFS (como gravação). Todos os sistemas de arquivos do Amazon EFS oferecem um desempenho básico consistente de 50 MB/s para cada TB de armazenamento no Amazon EFS Standard ou Amazon EFS One Zone. Todos os sistemas de arquivos (independentemente do tamanho) podem gerar intermitências a 100 MiB/s. Sistemas de arquivos com mais de 1 TB de armazenamento EFS Standard ou EFS One Zone podem gerar intermitência a 100 MB/s para cada TB. Como as operações de leitura são medidas na proporção de 1:3, você pode gerar até 300 MiBs/s para cada TiB de throughput de leitura. Conforme você adiciona dados ao sistema de arquivos, o throughput máximo disponível para ele é escalado de forma linear e automática com seu armazenamento na classe Amazon EFS Standard. Se precisar de mais throughput do que pode obter com a quantidade de dados armazenados, você pode configurar o throughput provisionado de acordo com a quantidade específica que a workload exige. O throughput do sistema de arquivos é compartilhado por todas as instâncias do Amazon EC2 conectadas a um sistema de arquivos. Por exemplo, um sistema de arquivos de 1 TB que atinge intermitência a 100 MB/s de throughput pode gerar 100 MB/s de uma única instância do Amazon EC2, cada uma com 10 MB/s. Para obter mais informações, consulte [Modos de performance](https://docs.aws.amazon.com/efs/latest/ug/performance.html) no *Guia do usuário do Amazon Elastic File System*. ## Otimização de custos para volumes do Amazon EFS O Amazon EFS simplifica o ajuste de escala do armazenamento para você. Os sistemas de arquivos do Amazon EFS crescem automaticamente à medida que você adiciona mais dados. Principalmente com o modo *Throughput intermitente* do Amazon EFS, o throughput no Amazon EFS escala à medida que o tamanho do sistema de arquivos na classe de armazenamento padrão aumenta. Para melhorar o throughput sem pagar um custo adicional pelo throughput provisionado em um sistema de arquivos do EFS, você pode compartilhar um sistema de arquivos do Amazon EFS com várias aplicações. Usando pontos de acesso do Amazon EFS, você pode implementar o isolamento de armazenamento em sistemas de arquivos compartilhados do Amazon EFS. Ao fazer isso, mesmo que as aplicações ainda compartilhem o mesmo sistema de arquivos, elas não podem acessar os dados a menos que você as autorize. À medida que os dados crescem, o Amazon EFS ajuda você a mover automaticamente arquivos acessados com pouca frequência para uma classe de armazenamento inferior. A classe de armazenamento Amazon EFS Standard-Infrequent Access (IA) reduz os custos de armazenamento de arquivos que não são acessados todos os dias. O EFS faz isso sem sacrificar a alta disponibilidade, a alta durabilidade, a elasticidade e o acesso ao sistema de arquivos POSIX que o Amazon EFS fornece. Para obter mais informações, consulte [Classes de armazenamento do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/features.html) no *Guia do usuário do Amazon Elastic File System*. Considere usar as políticas de ciclo de vida do Amazon EFS para economizar dinheiro transferindo automaticamente arquivos acessados com pouca frequência para o armazenamento Amazon EFS IA. Para obter mais informações, consulte [Amazon EFS lifecycle management](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) (Gerenciamento de ciclo de vida do Amazon EFS) no *Guia do usuário do Amazon Elastic File System*. Ao criar um sistema de arquivos do Amazon EFS, você pode escolher se o Amazon EFS replica seus dados em várias zonas de disponibilidade (padrão) ou os armazena de forma redundante em uma única zona de disponibilidade. A classe de armazenamento Amazon EFS One Zone pode reduzir os custos de armazenamento em uma margem significativa em comparação com as classes de armazenamento Amazon EFS Standard. Considere usar a classe de armazenamento Amazon EFS One Zone para workloads que não exigem resiliência Multi-AZ. Você pode reduzir ainda mais o custo do armazenamento Amazon EFS One Zone transferindo arquivos acessados com pouca frequência para o Amazon EFS One Zone-Infrequent Access. Para obter mais informações, consulte o [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/). ## Proteção de dados de volume do Amazon EFS O Amazon EFS armazena os dados de forma redundante em várias zonas de disponibilidade em sistemas de arquivos que usam classes de armazenamento padrão. Ao selecionar as classes de armazenamento Amazon EFS One Zone, seus dados são armazenados de forma redundante em uma única zona de disponibilidade. Além disso, o Amazon EFS foi projetado para fornecer 99,999999999% (11 noves) de durabilidade em um determinado ano. Como em qualquer ambiente, é uma prática recomendada ter um backup e criar proteções contra a exclusão acidental. Para dados do Amazon EFS, essa prática recomendada inclui um backup funcional e testado regularmente usando o AWS Backup. Os sistemas de arquivos que usam as classes de armazenamento Amazon EFS One Zone são configurados para fazer backup automático dos arquivos por padrão na criação do sistema de arquivos, a menos que você desabilite essa funcionalidade. Para obter mais informações, consulte [Backup de sistemas de arquivos EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) no *Guia do usuário do Amazon Elastic File System*. # Especificar um sistema de arquivos do Amazon EFS na definição de tarefa do Amazon ECS Para usar volumes do sistema de arquivos do Amazon EFS para seus contêineres, você deve especificar as configurações de volume e ponto de montagem na definição de tarefa. O trecho JSON de definição de tarefa a seguir mostra a sintaxe para os objetos `volumes` e `mountPoints` de um contêiner. ``` { "containerDefinitions": [ { "name": "container-using-efs", "image": "public.ecr.aws/amazonlinux/amazonlinux:latest", "entryPoint": [ "sh", "-c" ], "command": [ "ls -la /mount/efs" ], "mountPoints": [ { "sourceVolume": "myEfsVolume", "containerPath": "/mount/efs", "readOnly": true } ] } ], "volumes": [ { "name": "myEfsVolume", "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "rootDirectory": "/path/to/my/data", "transitEncryption": "ENABLED", "transitEncryptionPort": integer, "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" } } } ] } ``` `efsVolumeConfiguration` Tipo: Objeto Obrigatório: não Esse parâmetro é especificado quando volumes Amazon EFS são usados. `fileSystemId` Tipo: String Exigido: sim A ID do sistema de arquivamento Amazon EFS a ser usada. `rootDirectory` Tipo: string Obrigatório: Não O diretório dentro do sistema de arquivamento Amazon EFS a ser montado como diretório raiz dentro do host. Caso esse parâmetro seja omitido, a raiz do volume Amazon EFS será usada. Especificar `/` tem o mesmo efeito que omitir esse parâmetro. Se um ponto de acesso do EFS for especificado no `authorizationConfig`, o parâmetro do diretório raiz deverá ser omitido ou definido como `/`, o que imporá o caminho definido no ponto de acesso do EFS. `transitEncryption` Tipo: string Valores válidos: `ENABLED` \$1 `DISABLED` Obrigatório: não Especifica se a criptografia deve ou não ser habilitada para dados do Amazon EFS em trânsito entre o host do Amazon ECS e o servidor do Amazon EFS. A criptografia de trânsito deverá ser habilitada se a autorização do IAM do Amazon EFS for usada. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Criptografar dados em trânsito](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) no *Guia do usuário do Amazon Elastic File System*. `transitEncryptionPort` Tipo: inteiro Obrigatório: não A porta a ser usada ao enviar dados criptografados entre o host do Amazon ECS e o servidor do Amazon EFS. Se você não especificar uma porta de criptografia em trânsito, será usada a estratégia de seleção de porta usada pelo assistente de montagem do Amazon EFS. Para mais informações, consulte [Auxiliar de Montagem EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) no *Guia de Usuário Amazon Elastic File System*. `authorizationConfig` Tipo: Objeto Obrigatório: Não Detalhes de configuração de autorização do sistema de arquivamento Amazon EFS. `accessPointId` Tipo: Sequência Obrigatório: não ID do ponto de acesso a ser usado. Se um ponto de acesso for especificado, o valor do diretório raiz no `efsVolumeConfiguration` deve ser omitido ou definido como `/`, que impõe o caminho definido no ponto de acesso do EFS. Se um ponto de acesso for usado, a criptografia em trânsito deverá ser habilitada em `EFSVolumeConfiguration`. Para mais informações, consulte [Trabalhando com Pontos de Acesso Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) no *Guia de Usuário Amazon Elastic File System*. `iam` Tipo: string Valores válidos: `ENABLED` \$1 `DISABLED` Obrigatório: não Especifica se é necessário ou não usar o perfil do IAM para a tarefa do Amazon ECS estabelecida em uma definição de tarefa ao montar o sistema de arquivos do Amazon EFS. Em caso positivo, a criptografia de trânsito deve estar habilitada em `EFSVolumeConfiguration`. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Funções do IAM para tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). # Configurar os sistemas de arquivos do Amazon EFS para o Amazon ECS usando o console Saiba como usar os sistemas de arquivos do Amazon Elastic File System (Amazon EFS) com o Amazon ECS. ## Etapa 1: criar um cluster do Amazon ECS Use as etapas a seguir para criar um cluster do Amazon ECS. **Para criar um novo cluster (console do Amazon ECS)** Antes de começar, atribua a permissão apropriada do IAM. Para obter mais informações, consulte [Exemplos de clusters do Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na barra de navegação, selecione a Região a ser usada. 1. No painel de navegação, escolha **Clusters**. 1. Na página **Clusters**, escolha **Create Cluster** (Criar cluster). 1. Em **Configuração do cluster**, em **Nome do cluster**, insira `EFS-tutorial` para o nome do cluster. 1. (Opcional) Para alterar a VPC e as sub-redes onde suas tarefas e serviços são iniciados, em **Networking** (Redes), execute qualquer uma das operações a seguir: + Para remover uma sub-rede, em **Subnets** (Sub-redes), escolha **X** para cada sub-rede que você deseja remover. + Para alterar para uma VPC diferente do **padrão**, em **VPC**, escolha uma **VPC** existente e depois, em **Sub-redes**, selecione cada sub-rede. 1. Para adicionar instâncias do Amazon EC2 ao seu cluster, expanda **Infraestrutura** e selecione **Instâncias do Amazon EC2**. Em seguida, configure o grupo do Auto Scaling que atua como o provedor de capacidade: 1. Para criar um grupo do Auto Scaling, a partir de **Auto Scaling group (ASG)** (Grupo do Auto Scaling (ASG)), selecione **Create new group** (Criar novo grupo) e, em seguida, forneça os seguintes detalhes sobre o grupo: + Em **Sistema/arquitetura operacional**, escolha Amazon Linux 2. + Em **EC2 instance type (Tipo de instância do EC2)**, escolha `t2.micro`. Em **SSH key pair** (Par de chaves de SSH), escolha o par que prova sua identidade quando você se conecta à instância. + Em **Capacidade**, insira `1`. 1. Escolha **Criar**. ## Etapa 2: criar um grupo de segurança para instâncias do Amazon EC2 e o sistema de arquivos Amazon EFS Nesta etapa, você criará um grupo de segurança para suas instâncias do Amazon EC2 que permite tráfego de rede de entrada na porta 80 e seu sistema de arquivos Amazon EFS que permite o acesso de entrada das suas instâncias de contêiner. Crie um grupo de segurança para suas instâncias do Amazon EC2 com as opções a seguir: + **Nome do grupo de segurança**: um nome exclusivo para seu grupo de segurança. + **VP**: a VPC identificada anteriormente para o cluster. + **Regra de entrada** + **Tipo**: **HTTP** + **Origem** - **0.0.0.0/0**. Crie um grupo de segurança seu sistema de arquivos Amazon EFS com as opções a seguir: + **Nome do grupo de segurança**: um nome exclusivo para seu grupo de segurança. Por exemplo, `EFS-access-for-sg-dc025fa2`. + **VP**: a VPC identificada anteriormente para o cluster. + **Regra de entrada** + **Tipo**: **NFS** + **Origem**: **Personalizada** com o ID do grupo de segurança que você criou para suas instâncias. Para obter informações sobre como criar um grupo de segurança, consulte [Criar um grupo de segurança para sua instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html) no *Guia do usuário do Amazon EC2*. ## Etapa 3: criar um sistema de arquivos do Amazon EFS Nesta etapa, você cria um sistema de arquivos do Amazon EFS. **Para criar um sistema de arquivos do Amazon EFS para tarefas do Amazon ECS.** 1. Abra o console do Amazon Elastic File System em [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/). 1. Escolha **Create file system (Criar sistema de arquivos)**. 1. Insira um nome para seu sistema de arquivos e escolha a VPC na qual suas instâncias de contêiner estão hospedadas. Por padrão, cada sub-rede na VPC especificada recebe um destino de montagem que usa o grupo de segurança padrão para essa VPC. Em seguida, escolha **Personalizar**. **nota** Este tutorial pressupõe que o sistema de arquivos do Amazon EFS, o cluster do Amazon ECS, as instâncias de contêiner e as tarefas estejam na mesma VPC. Para obter mais informações sobre a montagem de um sistema de arquivos em uma VPC diferente, consulte [Walkthrough: Mount a file system from a different VPC](https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html) no *Guia do usuário do Amazon EFS*. 1. Na página **Configurações do sistema de arquivos**, defina as configurações opcionais e, em **Configurações de performance**, escolha o modo de throughput **Intermitente** para seu sistema de arquivos. Depois de definir as configurações, selecione **Avançar**. 1. (Opcional) Adicione tags ao sistema de arquivos. Por exemplo, você pode especificar um nome exclusivo para o sistema de arquivos inserindo esse nome na coluna **Value (Valor)** ao lado da chave **Name (Nome)**. 1. (Opcional) Habilite o gerenciamento do ciclo de vida para economizar dinheiro em armazenamento acessado com pouca frequência. Para obter mais informações, consulte [Gerenciamento de ciclo de vida do EFS](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) no *Guia do usuário do Amazon Elastic File System*. 1. (Opcional) Habilitar criptografia. Marque a caixa de seleção para habilitar a criptografia do sistema de arquivos do Amazon EFS em repouso. 1. Na página **Acesso à rede**, em **Montar destinos**, substitua a configuração do grupo de segurança existente para cada zona de disponibilidade pelo grupo de segurança que você criou para o sistema de arquivos [Etapa 2: criar um grupo de segurança para instâncias do Amazon EC2 e o sistema de arquivos Amazon EFS](#efs-security-group) e escolha **Avançar**. 1. Não é preciso configurar a **Política do sistema de arquivos** para este tutorial, de modo que é possível pular a seção escolhendo **Avançar**. 1. Revise as opções do sistema de arquivos e escolha **Criar** para concluir o processo. 1. Na tela **Sistemas de arquivo**, registre o **ID do sistema de arquivos**. Na próxima etapa, você fará referência a esse valor na definição de tarefa do Amazon ECS. ## Etapa 4: adicionar conteúdo ao sistema de arquivos do Amazon EFS Nesta etapa, você monta o sistema de arquivos do Amazon EFS em uma instância do Amazon EC2 e adiciona conteúdo a ela. Esta etapa é para fins de teste neste tutorial, a fim de ilustrar a natureza persistente dos dados. Ao usar esse recurso, você normalmente teria sua aplicação ou outro método de gravação de dados no seu sistema de arquivos do Amazon EFS. **Para criar uma instância do Amazon EC2 e montar o sistema de arquivos do Amazon EFS** 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Escolha **Executar instância**. 1. Em **Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)**, selecione a **AMI do Amazon Linux 2 (HVM)**. 1. Em **Tipo de instância**, mantenha o tipo de instância padrão, `t2.micro`. 1. Em **Par de chaves (login)**, selecione um par de chaves para acesso por SSH à instância. 1. Em **Configurações de rede**, selecione a VPC especificada para o sistema de arquivos Amazon EFS e o cluster do Amazon ECS. Selecione uma sub-rede e o grupo de segurança da instância criado em [Etapa 2: criar um grupo de segurança para instâncias do Amazon EC2 e o sistema de arquivos Amazon EFS](#efs-security-group). Configure o grupo de segurança da instância. Verifique se **Atribuir automaticamente IP público** está habilitado. 1. Em **Configurar armazenamento**, escolha o botão **Editar** para sistemas de arquivos e, em seguida, escolha **EFS**. Selecione o sistema de arquivos que você criou em [Etapa 3: criar um sistema de arquivos do Amazon EFS](#efs-create-filesystem). Opcionalmente, é possível alterar o ponto de montagem ou deixar o valor padrão. **Importante** É necessário selecionar uma sub-rede antes de adicionar um sistema de arquivos à instância. 1. Desmarque **Criar e anexar grupos de segurança automaticamente**. Deixe a outra caixa de seleção marcada. Selecione **Add shared file system** (Adicionar sistema de arquivos compartilhado). 1. Em **Advanced Details** (Detalhes avançados), certifique-se de que o script de dados do usuário seja preenchido automaticamente com as etapas de montagem do sistema de arquivos do Amazon EFS. 1. Em **Resumo**, verifique se o **Número de instâncias** é **1**. Escolha **Iniciar instância**. 1. Na página **Iniciar uma instância** escolha **Visualizar todas instâncias** para ver o status das suas instâncias. Inicialmente, o **Estado da instância** é `PENDING`. Depois que o estado mudar para `RUNNING` e a instância passar por todas as verificações de status, a instância estará pronta para uso. Agora, você se conecta à instância do Amazon EC2 e adiciona conteúdo ao sistema de arquivos do Amazon EFS. **Para conectar-se à instância do Amazon EC2 e adicionar conteúdo ao sistema de arquivos do Amazon EFS** 1. SSH para a instância do Amazon EC2 que você criou. Para obter mais informações, consulte [Conectar-se à instância do Linux usando SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html) no *Guia do usuário do Amazon EC2*. 1. Na janela do terminal, execute o comando **df -T** para verificar se o sistema de arquivos Amazon EFS está montado. Na saída a seguir, destacamos a montagem do sistema de arquivos do Amazon EFS. ``` $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on devtmpfs devtmpfs 485468 0 485468 0% /dev tmpfs tmpfs 503480 0 503480 0% /dev/shm tmpfs tmpfs 503480 424 503056 1% /run tmpfs tmpfs 503480 0 503480 0% /sys/fs/cgroup /dev/xvda1 xfs 8376300 1310952 7065348 16% / 127.0.0.1:/ nfs4 9007199254739968 0 9007199254739968 0% /mnt/efs/fs1 tmpfs tmpfs 100700 0 100700 0% /run/user/1000 ``` 1. Navegue até o diretório no qual o sistema de arquivos do Amazon EFS está montado. No exemplo acima, ele é `/mnt/efs/fs1`. 1. Crie um arquivo chamado `index.html` com o seguinte conteúdo: ```

It Works!

You are using an Amazon EFS file system for persistent container storage.

``` ## Etapa 5: criar uma definição de tarefa A definição de tarefa a seguir cria um volume de dados chamado `efs-html`. O contêiner `nginx` monta o volume de dados do host na raiz de NGINX, `/usr/share/nginx/html`. **Para criar uma nova definição de tarefa usando o console do Amazon ECS** 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, copie e cole o seguinte texto JSON, substituindo `fileSystemId` pelo ID do sistema de arquivos do Amazon EFS. ``` { "containerDefinitions": [ { "memory": 128, "portMappings": [ { "hostPort": 80, "containerPort": 80, "protocol": "tcp" } ], "essential": true, "mountPoints": [ { "containerPath": "/usr/share/nginx/html", "sourceVolume": "efs-html" } ], "name": "nginx", "image": "public.ecr.aws/docker/library/nginx:latest" } ], "volumes": [ { "name": "efs-html", "efsVolumeConfiguration": { "fileSystemId": "fs-1324abcd", "transitEncryption": "ENABLED" } } ], "family": "efs-tutorial", "executionRoleArn":"arn:aws:iam::111122223333:role/ecsTaskExecutionRole" } ``` **nota** O perfil do IAM de execução de tarefas do Amazon ECS não exige nenhuma permissão específica relacionada ao Amazon EFS para montar um sistema de arquivos do Amazon EFS. Por padrão, se a política baseada em recursos do Amazon EFS não existir, o acesso será concedido a todas as entidades principais (\$1) na criação do sistema de arquivos. O perfil da tarefa do Amazon ECS será necessário apenas se a “autorização do IAM para EFS” estiver habilitada na definição da tarefa do Amazon ECS. Quando habilitada, a identidade do perfil da tarefa deverá ter o acesso permitido ao sistema de arquivos do Amazon EFS na política baseada em recursos do Amazon EFS, e o acesso anônimo deverá ser desabilitado. 1. Escolha **Criar**. ## Etapa 6: executar uma tarefa e visualizar os resultados Agora que o sistema de arquivos do Amazon EFS foi criado e há conteúdo da Web para o contêiner NGINX atender, você pode executar uma tarefa usando a definição de tarefa criada. Os servidores web do NGINX fornecem sua página HTML simples. Se você atualizar o conteúdo no sistema de arquivos do Amazon EFS, essas alterações serão propagadas para todos os contêineres que também tenham montado este sistema de arquivos. A tarefa é executada na sub-rede que você definiu para o cluster. **Para executar uma tarefa e visualizar os resultados usando o console** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, selecione o cluster que contém a tarefa autônoma. Determine o recurso no qual você inicia o serviço. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. (Opcional) Escolha como a tarefa programada é distribuída em toda a infraestrutura do cluster. Expanda **Compute configuration** (Configuração de computação) e realize estas ações: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. Em **Application type** (Tipo de aplicação), escolha **Task** (Tarefa). 1. Em **Definição de tarefa**, escolha a definição de tarefa `efs-tutorial` que você criou anteriormente. 1. Em **Tarefas desejadas**, insira `1`. 1. Escolha **Criar**. 1. Na página **Cluster**, escolha **Infraestrutura**. 1. Em **Instâncias de contêiner**, escolha a instância de contêiner com a qual deseja estabelecer conexão. 1. Na página **Instância de contêiner**, Em **Redes**, registre o **IP público** para sua instância. 1. Abra um navegador e insira o endereço IP público. Você deve ver a mensagem a seguir: ``` It works! You are using an Amazon EFS file system for persistent container storage. ``` **nota** Se você não vir a mensagem, verifique se o grupo de segurança para suas instâncias de contêiner permite o tráfego de rede de entrada na porta 80 e se o grupo de segurança do seu sistema de arquivos permite acesso de entrada a partir da instância de contêiner. # Uso de volumes do FSx para Windows File Server com Amazon ECS O FSx para Windows File Server fornece servidores de arquivos Windows totalmente gerenciados, baseados em um sistema de arquivos Windows. Ao usar o FSx for Windows File Server junto com o ECS, você pode provisionar tarefas do Windows com armazenamento de arquivos persistente, distribuído, compartilhado e estático. Para obter mais informações, consulte o [O que é FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). **nota** As instâncias do EC2 que usam a AMI completa do Windows Server 2016 otimizada para o Amazon ECS não oferecem suporte a volumes de tarefas do ECS do FSx for Windows File Server. Não é possível usar volumes do FSx para Windows File Server em contêineres do Windows na configuração do Fargate. Em vez disso, você pode [modificar os contêineres para montá-los no startup](https://aws.amazon.com/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/). É possível usar o FSx for Windows File Server para implantar workloads do Windows que exigem acesso ao armazenamento externo compartilhado, ao armazenamento regional de alta disponibilidade ou ao armazenamento de alta throughput. É possível montar um ou mais volumes do sistema de arquivos do FSx para Windows File Server em um contêiner do Amazon ECS executado em uma instância do Amazon ECS. É possível compartilhar volumes do sistema de arquivos do FSx para Windows File Server entre vários contêineres do Amazon ECS em uma única tarefa do Amazon ECS. Para permitir o uso do FSx para Windows File Server com o ECS, inclua o ID do sistema de arquivos FSx para Windows File Server e as informações relacionadas em uma definição de tarefa. Isso está no exemplo a seguir de trecho JSON de definição de tarefa. Antes de criar e executar uma definição de tarefa, você precisa do seguinte. + Uma instância Windows do EC2 do ECS que é unida a um domínio válido. Ela pode ser hospedada por um [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), Active Directory on-premises ou Active Directory auto-hospedado no Amazon EC2. + Um segredo do AWS Secrets Manager ou um parâmetro do Systems Manager que contém as credenciais usadas para associação ao domínio do Active Directory e anexar o sistema de arquivos do FSx para Windows File Server. Os valores de credencial são as credenciais de nome e senha que você inseriu ao criar o diretório ativo. Para ver um tutorial relacionado, consulte [Saiba como configurar sistemas de arquivos do FSx para Windows File Server para o Amazon ECS](tutorial-wfsx-volumes.md). ## Considerações Considere o seguinte ao usar volumes do FSx for Windows File Server. + Os volumes do FSx for Windows File Server são suportados nativamente pelo Amazon ECS em instâncias do Amazon EC2 com Windows — o Amazon ECS gerencia automaticamente a montagem por meio da configuração da definição de tarefa. Em instâncias do Amazon EC2 no Linux, o Amazon ECS não consegue montar automaticamente volumes do FSx for Windows File Server por meio de definições de tarefa. No entanto, é possível montar manualmente um compartilhamento de arquivos do Amazon FSx para Windows File Server em uma instância do EC2 do Linux no nível do host e, em seguida, fazer a montagem por ligação desse caminho nos seus contêineres do Amazon ECS. Para obter mais informações, consulte [Montar compartilhamentos de arquivos do Amazon FSx a partir do Linux](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/map-shares-linux.html). **Importante** Esta é uma configuração autogerenciada. Para obter orientações sobre como montar e manter compartilhamentos de arquivos do FSx para Windows File Server no Linux, consulte a documentação do [FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/). **Importante** Ao utilizar um compartilhamento do Amazon FSx for Windows File Server montado manualmente em instâncias do Amazon EC2 do Linux, o Amazon ECS e o FSx para Windows File Server operam de forma independente — o Amazon ECS não monitora a montagem do Amazon FSx, e o FSx for Windows File Server não rastreia o posicionamento das tarefas do Amazon ECS nem os eventos do ciclo de vida. É de sua responsabilidade garantir a conectividade de rede entre suas instâncias de contêiner do Amazon ECS e o sistema de arquivos Amazon FSx, implementar verificações de integridade de montagem e gerenciar a lógica de reconexão para lidar com eventos de failover. + O FSx for Windows File Server com o Amazon ECS não oferece suporte ao AWS Fargate. + O FSx for Windows File Server com o Amazon ECS não é compatível com instâncias gerenciadas do Amazon ECS. + O FSx for Windows File Server com o Amazon ECS, com modo de rede `awsvpc`, exige a versão `1.54.0` ou posterior do agente de contêiner. + O número máximo de letras de unidade que podem ser usadas para uma tarefa do Amazon ECS é 23. Cada tarefa com um volume do FSx for Windows File Server obtém uma letra de unidade atribuída a ela. + Por padrão, o tempo de limpeza de recursos de tarefas é de três horas após o término da tarefa. Mesmo que nenhuma tarefa o use, um mapeamento de arquivos criado por uma tarefa persiste por três horas. O tempo de limpeza padrão pode ser configurado usando a variável de ambiente do Amazon ECS `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). + Normalmente, as tarefas somente são executadas na mesma VPC do sistema de arquivos do FSx for Windows File Server. No entanto, é possível ter suporte entre VPCs se houver uma conectividade de rede estabelecida entre a VPC do cluster do Amazon ECS e o sistema de arquivos do FSx for Windows File Server por meio de emparelhamento da VPC. + Controle o acesso a um sistema de arquivos do FSx for Windows File Server no nível da rede configurando os grupos de segurança da VPC. Somente as tarefas hospedadas em instâncias do EC2, associadas ao domínio do Active Directory com grupos de segurança do Active Directory configurados corretamente, podem acessar o compartilhamento de arquivos do FSx para Windows File Server. Se os grupos de segurança estiverem configurados incorretamente, o Amazon ECS falhará na inicialização da tarefa e apresentará a seguinte mensagem de erro: ”.: `unable to mount file system fs-id`.” + O FSx for Windows File Server é integrado ao AWS Identity and Access Management (IAM) para controlar as ações que os usuários e grupos do IAM podem executar em recursos específicos do FSx for Windows File Server. Com autorização do cliente, os clientes podem definir funções do IAM que permitem ou negam acesso a sistemas de arquivos específicos do FSx for Windows File Server, opcionalmente exigir acesso somente leitura e, opcionalmente, permitir ou impedir acesso raiz ao sistema de arquivos do cliente. Para obter mais informações, consulte [Segurança](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/security.html) no Guia do usuário do Amazon FSx for Windows. # Práticas recomendadas ao usar o FSx para Windows File Server com o Amazon ECS Anote as práticas recomendadas a seguir ao usar o FSx para Windows File Server com o Amazon ECS. ## Segurança e controles de acesso para o FSx para Windows File Server O FSx para Windows File Server oferece os recursos de controle de acesso a seguir, usados para garantir que os dados armazenados em um sistema de arquivos do FSx para Windows File Server estejam seguros e acessíveis somente pelas aplicações que precisam deles. ### Criptografia de dados para volumes do FSx para Windows File Server O FSx para Windows File Server oferece suporte a duas formas de criptografia para sistemas de arquivos. São elas a criptografia de dados em trânsito e a criptografia em repouso. A criptografia de dados em trânsito é compatível com compartilhamentos de arquivos mapeados em uma instância de contêiner que seja compatível com o protocolo SMB 3.0 ou mais recente. A criptografia de dados em repouso é habilitada automaticamente ao criar um sistema de arquivos do Amazon FSx. O Amazon FSx criptografa automaticamente os dados em trânsito usando a criptografia SMB à medida que você acessa seu sistema de arquivos, sem a necessidade de modificar suas aplicações. Para obter mais informações, consulte [Data encryption in Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html) no *Guia do usuário do Amazon FSx para Windows File Server*. ### Uso de ACLs do Windows para controle de acesso em nível de pasta A instância do Windows para Amazon EC2 acessa os compartilhamentos de arquivos do Amazon FSx usando as credenciais do Active Directory. Ela usa listas de controle de acesso (ACLs) padrão do Windows para controle de acesso refinado em nível de arquivo e pasta. Você pode criar várias credenciais, cada uma para uma pasta específica dentro do compartilhamento que mapeia para uma tarefa específica. No exemplo a seguir, a tarefa tem acesso à pasta `App01` usando uma credencial salva no Secrets Manager. Seu nome do recurso da Amazon (ARN) é `1234`. ``` "rootDirectory": "\\path\\to\\my\\data\App01", "credentialsParameter": "arn-1234", "domain": "corp.fullyqualified.com", ``` Em outro exemplo, uma tarefa tem acesso à pasta `App02` usando uma credencial salva no Secrets Manager. Seu ARN é `6789`. ``` "rootDirectory": "\\path\\to\\my\\data\App02", "credentialsParameter": "arn-6789", "domain": "corp.fullyqualified.com", ``` # Especificar um sistema de arquivos do FSx para Windows File Server em uma definição de tarefa do Amazon ECS Para usar volumes do sistema de arquivos do FSx for Windows File Server para seus contêineres, especifique as configurações de volume e ponto de montagem na definição de tarefa. O trecho JSON de definição de tarefa a seguir mostra a sintaxe para os objetos `volumes` e `mountPoints` de um contêiner. ``` { "containerDefinitions": [ { "entryPoint": [ "powershell", "-Command" ], "portMappings": [], "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

It Works!

You are using Amazon FSx for Windows File Server file system for persistent container storage.

' -Force"], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": false, "name": "container1", "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ] }, { "entryPoint": [ "powershell", "-Command" ], "portMappings": [ { "hostPort": 443, "protocol": "tcp", "containerPort": 80 } ], "command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"], "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": true, "name": "container2" } ], "family": "fsx-windows", "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole", "volumes": [ { "name": "fsx-windows-dir", "fsxWindowsFileServerVolumeConfiguration": { "fileSystemId": "fs-0eeb5730b2EXAMPLE", "authorizationConfig": { "domain": "example.com", "credentialsParameter": "arn:arn-1234" }, "rootDirectory": "share" } } ] } ``` `FSxWindowsFileServerVolumeConfiguration` Tipo: Objeto Obrigatório: não Esse parâmetro é especificado quando você está usando o sistema de arquivos do [FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) para armazenamento de tarefas. `fileSystemId` Tipo: String Exigido: sim O ID do sistema de arquivos do FSx for Windows File Server a ser usado. `rootDirectory` Tipo: String Exigido: sim O diretório no sistema de arquivos do FSx for Windows File Server que deve ser montado como o diretório raiz dentro do host. `authorizationConfig` `credentialsParameter` Tipo: String Exigido: sim As opções de credencial de autorização: + Nome do recurso da Amazon (ARN) de um segredo do [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + Nome do recurso da Amazon (ARN) de um parâmetro do [Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Tipo: String Exigido: sim Um nome de domínio totalmente qualificado hospedado por um diretório do [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ou por um Active Directory do EC2 auto-hospedado. ## Métodos para o armazenamento de credenciais de volume do FSx para Windows File Server Existem dois métodos diferentes de armazenamento de credenciais para uso com o parâmetro de credenciais. + **AWS Secrets Manager Segredo do** Essa credencial pode ser criada no console do AWS Secrets Manager usando a categoria *Other type of secret* (Outro tipo de segredo). Você adiciona uma linha para cada par chave-valor, nome de usuário/administrador e senha/*senha*. + **Parâmetro do Systems Manager** Essa credencial pode ser criada no console de parâmetros do Systems Manager inserindo texto no formulário mostrado no trecho do código de exemplo a seguir. ``` { "username": "admin", "password": "password" } ``` O `credentialsParameter` no parâmetro `FSxWindowsFileServerVolumeConfiguration` da definição de tarefa mantém o ARN do segredo ou o ARN do parâmetro do Systems Manager. Para obter mais informações, consulte [O que é o AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) no *Guia do usuário do Secrets Manager* e [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) no *Guia do usuário do Systems Manager*. # Saiba como configurar sistemas de arquivos do FSx para Windows File Server para o Amazon ECS Saiba como iniciar uma instância do Windows otimizada para o Amazon ECS que hospeda um sistema de arquivos do FSx para Windows File Server e contêineres que podem acessar o sistema de arquivos. Para fazer isso, você primeiro criará um Microsoft Active Directory gerenciado pela AWS do Directory Service. Em seguida, você cria um sistema de arquivos do FSx para Windows File Server e um cluster com uma instância do Amazon EC2 e uma definição de tarefa. Configure a definição de tarefa para os contêineres usarem o sistema de arquivos do FSx for Windows File Server. Finalmente, teste o sistema de arquivos. Entre 20 e 45 minutos são necessários toda vez que você inicia ou exclui o Active Directory ou o sistema de arquivos do FSx for Windows File Server. Esteja preparado para reservar pelo menos 90 minutos para concluir o tutorial ou conclua o tutorial em algumas sessões. ## Pré-requisitos para o tutorial + Um usuário administrativo. Consulte [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md). + (Opcional) Um par de chaves `PEM` para se conectar à instância do Windows do EC2 por acesso RDP. Para obter informações sobre como criar pares de chaves, consulte [Pares de chaves do Amazon EC2 e instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*. + Uma VPC com pelo menos uma sub-rede pública e uma privada e um grupo de segurança. É possível usar a VPC padrão. Você não precisa de um gateway ou dispositivo NAT. O Directory Service não oferece suporte à conversão de endereços de rede (NAT) com o Active Directory. Para que isso funcione, o Active Directory, o sistema de arquivos do FSx for Windows File Server, o cluster do ECS e a instância do EC2 devem estar localizados na VPC. Para obter mais informações sobre VPCs e Active Directories, consulte [Criar uma VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) e [Pré-requisitos para criar um Microsoft AD gerenciado pela AWS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_prereqs). + As permissões do IAM ecsInstanceRole e ecsTaskExecutionRole estão associadas à sua conta. Esses perfis vinculados ao serviço permitem que os serviços façam chamadas de API e acessem contêineres, segredos, diretórios e servidores de arquivos em seu nome. ## Etapa 1: criar funções de acesso do IAM **Crie um cluster com o Console de gerenciamento da AWS.** 1. Consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md) para verificar se você tem uma ecsInstanceRole e ver como será possível criar uma, caso não tenha. 1. Recomendamos que as políticas de função sejam personalizadas para permissões mínimas em um ambiente de produção real. Com a finalidade de trabalhar neste tutorial, verifique se a política gerenciada pela AWS a seguir está anexada a ecsInstanceRole. Anexe a política, caso ela ainda não esteja anexada. + AmazonEC2ContainerServiceforEC2Role + AmazonSSMManagedInstanceCore + AmazonSSMDirectoryServiceAccess Para anexar políticas gerenciadas pela AWS 1. Abra o [console do IAM](https://console.aws.amazon.com//iam/). 1. No painel de navegação, selecione **Roles**. 1. Escolha um **perfil gerenciado da AWS**. 1. Escolha **Permissões, Anexar políticas**. 1. Para restringir as políticas disponíveis a serem anexadas, use **Filter**. 1. Selecione a política apropriada e escolha **Attach policy** (Anexar política). 1. Consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md) para verificar se você tem uma ecsTaskExecutionRole e ver como será possível criar uma, caso não tenha. Recomendamos que as políticas de função sejam personalizadas para permissões mínimas em um ambiente de produção real. Com a finalidade de trabalhar neste tutorial, verifique se as políticas gerenciadas pela AWS a seguir estão anexadas a ecsTaskExecutionRole Anexe as políticas, caso elas ainda não estejam anexadas. Use o procedimento indicado na seção anterior para anexar as políticas gerenciadas pela AWS. + SecretsManagerReadWrite + AmazonFSxReadOnlyAccess + AmazonSSMReadOnlyAccess + AmazonECSTaskExecutionRolePolicy ## Etapa 2: criar o Windows Active Directory (AD) 1. Siga as etapas descritas em [Criar seu Microsoft AD gerenciado pela AWS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory) no *Guia de administração do AWS Directory Service*. Use a VPC que você designou para este tutorial. Na etapa 3 de *Criar seu Microsoft AD gerenciado pela AWS*, salve o nome do usuário e a senha de administrador para uso em uma etapa posterior. Além disso, anote o nome de DNS totalmente qualificado para etapas futuras. É possível concluir a etapa a seguir enquanto o Active Directory está sendo criado. 1. Crie um segredo do AWS Secrets Manager a ser usado nas etapas a seguir. Para obter mais informações, consulte [Conceitos básicos do Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#get-started) no *Guia do usuário do AWS Secrets Manager*. 1. Abra o [console do Secrets Manager](https://console.aws.amazon.com//secretsmanager/). 1. Clique em **Store a new secret** (Armazenar um novo segredo). 1. Selecione **Other type of secrets** (Outro tipo de segredos). 1. Em **Secret key/value** (Chave/valor secreto), na primeira linha, crie uma chave **username** com valor **admin**. Clique em **\$1 Add row** (\$1 Adicionar linha). 1. Na nova linha, crie uma chave **password**. Em valor, digite a senha inserida na Etapa 3 de *Criar seu diretório do AD gerenciado pela AWS*. 1. Clique no botão **Next** (Avançar). 1. Forneça um nome e uma descrição do segredo. Clique em **Next**. 1. Clique em **Next**. Clique em **Store** (Armazenar). 1. Na lista da página **Segredos**, clique no segredo que você acabou de criar. 1. Salve o ARN do novo segredo para uso nas próximas etapas, 1. É possível ir para a próxima etapa enquanto seu Active Directory está sendo criado. ## Etapa 3: verificar e atualizar o grupo de segurança Nesta etapa, você verificará e atualizará as regras do grupo de segurança que você estiver usando. Para isso, você pode usar o grupo de segurança padrão que foi criado para a VPC. **Verifique e atualize o grupo de segurança.** Você precisa criar ou editar o grupo de segurança para enviar dados de e para as portas, que são descritas em [Grupos de segurança da Amazon VPC](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/limit-access-security-groups.html#fsx-vpc-security-groups) no *Guia do usuário do FSx for Windows File Server*. É possível fazer isso criando a regra de entrada do grupo de segurança mostrada na primeira linha da tabela de regras de entrada a seguir. Essa regra permite tráfego de entrada de interfaces de rede (e das instâncias associadas) atribuídas ao grupo de segurança. Todos os recursos de nuvem criados estão dentro da mesma VPC e anexados ao mesmo grupo de segurança. Portanto, essa regra permite o tráfego entre o sistema de arquivos do FSx for Windows File Server, o Active Directory e a instância do ECS conforme necessário. As outras regras de entrada permitem que o tráfego atenda ao site e ao acesso RDP para conexão à instância do ECS. A tabela a seguir mostra quais regras de entrada do grupo de segurança são necessárias para este tutorial. | Tipo | Protocolo | Intervalo de portas | Origem | | --- | --- | --- | --- | | Todo o tráfego | Tudo | Todos | *sg-securitygroup* | | HTTPS | TCP | 443 | 0.0.0.0/0 | | RDP | TCP | 3389 | endereço IP do seu laptop | A tabela a seguir mostra quais regras de saída do grupo de segurança são necessárias para este tutorial. | Tipo | Protocolo | Intervalo de portas | Destino | | --- | --- | --- | --- | | Todo o tráfego | Tudo | Tudo | 0.0.0.0/0 | 1. Abra o [Console do EC2](https://console.aws.amazon.com//ec2/) e selecione **Security groups** (Grupos de segurança) no menu à esquerda. 1. Na lista de grupos de segurança exibida, marque a caixa de seleção à esquerda do grupo de segurança que você está usando para este tutorial. Os detalhes do security group são exibidos. 1. Edite as regras de entrada e saída selecionando as guias **Regras de entrada** ou **Regras de saída** e clicando nos botões **Editar regras de entrada** ou **Editar regras de saída**. Edite as regras para corresponder às regras exibidas nas tabelas anteriores. Depois de criar a instância do EC2 posteriormente neste tutorial, edite a origem RDP da regra de entrada com o endereço IP público da instância do EC2, conforme descrito em [Conectar-se à sua instância do Windows usando RDP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html) no *Guia do usuário do Amazon EC2*. ## Etapa 4: criar um sistema de arquivos do FSx for Windows File Server Depois que o grupo de segurança for verificado e atualizado e o Active Directory for criado e estiver no status ativo, crie o sistema de arquivos do FSx for Windows File Server na mesma VPC do Active Directory. Use as etapas a seguir para criar um sistema de arquivos do FSx for Windows File Server para as tarefas do Windows. **Crie seu primeiro sistema de arquivos.** 1. Abra o [console do Amazon FSx](https://console.aws.amazon.com//fsx/). 1. No painel, escolha **Create file system** (Criar sistema de arquivos) para iniciar o assistente de criação de sistemas de arquivos. 1. Na página **Selecionar tipo de sistema de arquivos**, escolha **FSx para Windows File Server** e, em seguida, selecione **Next** (Avançar). A página **Criar sistema de arquivos** é exibida. 1. Na seção **Detalhes do sistema de arquivos**, forneça um nome para o sistema de arquivos. Nomear seus sistemas de arquivos torna mais fácil encontrar e gerenciar seus sistemas. Podem ser usados até 256 caracteres Unicode. Os caracteres permitidos são letras, números, espaços e os caracteres especiais sinal de mais (\$1). sinal de menos (-), sinal de igual (=), ponto (.), sublinhado (\$1), dois-pontos (:) e barra (/). 1. Em **Deployment type** (Tipo de implantação), escolha **Single-AZ** para implantar um sistema de arquivos implantado em uma única zona de disponibilidade. *Single-AZ 2* é a geração mais recente de sistemas de arquivos de zona de disponibilidade única. É compatível com armazenamento SSD e HDD. 1. Em **Storage type** (Tipo de armazenamento), escolha **HDD**. 1. Em **Storage capacity** (Capacidade de armazenamento), insira a capacidade mínima de armazenamento. 1. Mantenha a **Capacidade de Throughput** na configuração padrão. 1. Na seção **Rede e segurança**, escolha a mesma Amazon VPC que você escolheu para o diretório do Directory Service. 1. Em **VPC Security Groups** (Grupos de segurança da VPC), escolha o grupo de segurança que você verificou na *Etapa 3: verificar e atualizar o grupo de segurança*. 1. Em **Windows authentication** (Autenticação do Windows), escolha **AWS Managed Microsoft Active Directory** (Microsoft Active Directory gerenciado pela ) e, depois, escolha o diretório do Directory Service na lista. 1. Em **Encryption** (Criptografia), mantenha a configuração padrão da **Encryption key** (Chave de criptografia) como **aws/fsx (default)**. 1. Mantenha as configurações padrão para **Preferências de manutenção**. 1. Clique no botão **Next** (Avançar). 1. Verifique a configuração do sistema de arquivos mostrada na página **Criar sistema de arquivos**. Para sua referência, anote quais configurações do sistema de arquivos você pode modificar após a criação do sistema de arquivos. Escolha **Create file system (Criar sistema de arquivos)**. 1. Anote o ID do sistema de arquivos. Você precisará usá-lo em uma etapa posterior. É possível seguir para as próximas etapas para criar um cluster e uma instância do EC2 enquanto o sistema de arquivos do FSX for Windows File Server está sendo criado. ## Etapa 5: criar um cluster do Amazon ECS **Criar um cluster usando o console do Amazon ECS** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na barra de navegação, selecione a Região a ser usada. 1. No painel de navegação, escolha **Clusters**. 1. Na página **Clusters**, escolha **Create Cluster** (Criar cluster). 1. Em **Configuração do cluster)**, para **Nome do cluster**, insira **windows-fsx-cluster**. 1. Expanda **Infraestrutura**, desmarque AWS Fargate (tecnologia sem servidor) e selecione **Instâncias do Amazon EC2**. 1. Para criar um grupo do Auto Scaling, a partir de **Auto Scaling group (ASG)** (Grupo do Auto Scaling (ASG)), selecione **Create new group** (Criar novo grupo) e, em seguida, forneça os seguintes detalhes sobre o grupo: + Em **Sistema operacional/Arquitetura**, escolha **Windows Server 2019 Core**. + Em **Tipo de instância do EC2**, escolha t2.medium ou t2.micro. 1. Escolha **Criar**. ## Etapa 6: criar uma instância do Amazon ECS otimizada para o Amazon EC2 Crie uma instância de contêiner do Windows do Amazon ECS. **Para criar uma instância do Amazon ECS** 1. Use o comando `aws ssm get-parameters` para recuperar o nome da AMI para a região que hospeda sua VPC. Para obter mais informações, consulte [Recuperar os metadados da AMI otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html). 1. Use o console do Amazon EC2 para iniciar a instância. 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Na barra de navegação, selecione a Região a ser usada. 1. No **Painel do EC2**, escolha **Launch Instance** (Iniciar instância). 1. Em **Name (Nome)**, insira um nome exclusivo. 1. Em **Imagens de aplicações e SO (Amazon Machine Image)**, no campo **pesquisar**, insira o nome da AMI que você recuperou. 1. Em **Tipo de instância**, escolha t2.medium ou t2.micro. 1. Em **Key pair (login)** (Par de chaves [login]), escolha um par de chaves. Se você não especificar um par de chaves, você 1. Em **Configurações de rede**, para **VPC** e **sub-rede**, escolha sua VPC e uma sub-rede pública. 1. Em **Network settings** (Configurações de rede), em **Security group** (Grupo de segurança), selecione um grupo de segurança existente ou crie outro. Certifique-se de que o grupo de segurança escolhido tenha as regras de entrada e saída definidas em [Pré-requisitos para o tutorial](#wfsx-prerequisites) 1. Em **Network settings** (Configurações de rede), em **Auto-assign Public IPC** (Atribuir IP público automaticamente), selecione **Enable** (Habilitar). 1. Expanda **Detalhes avançados**, e em **Associar diretório a domínio**, selecione o ID do Active Directory que você criou. Esse domínio se junta ao AD quando a instância do EC2 é iniciada. 1. Em **Advanced details** (Detalhes avançados), em **IAM instance profile** (Perfil de instância do IAM), escolha **ecsInstanceRole**. 1. Configure a instância de contêiner do Amazon ECS com os dados de usuário a seguir. Em **Advanced Details** (Detalhes avançados), cole o seguinte script no campo **User data** (Dados do usuário), substituindo *cluster\$1name* pelo nome do cluster. ``` Initialize-ECSAgent -Cluster windows-fsx-cluster -EnableTaskIAMRole ``` 1. Quando estiver pronto, selecione o campo de confirmação e, então, escolha **Launch Instances**. 1. Uma página de confirmação informa que sua instância está sendo executada. Selecione **Visualizar instâncias** para fechar a página de confirmação e voltar ao console. 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, em seguida, escolha **windows-fsx-cluster**. 1. Selecione a guia **Infraestrutura** e verifique se a sua instância foi registrada no cluster **windows-fsx-cluster**. ## Etapa 7: registrar uma definição de tarefa do Windows Para executar contêineres do Windows no cluster do Amazon ECS, você deve registrar uma definição de tarefa. O exemplo de definição de tarefa a seguir exibe uma página da Web simples. A tarefa inicia dois contêineres que têm acesso ao sistema de arquivos do FSx. O primeiro contêiner grava um arquivo HTML no sistema de arquivos. O segundo contêiner baixa o arquivo HTML do sistema de arquivos e serve a página da Web. 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, substitua os valores do seu perfil de execução da tarefa e os detalhes sobre o sistema de arquivos FSx e, em seguida, escolha **Salvar**. ``` { "containerDefinitions": [ { "entryPoint": [ "powershell", "-Command" ], "portMappings": [], "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

It Works!

You are using Amazon FSx for Windows File Server file system for persistent container storage.

' -Force"], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": false, "name": "container1", "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ] }, { "entryPoint": [ "powershell", "-Command" ], "portMappings": [ { "hostPort": 443, "protocol": "tcp", "containerPort": 80 } ], "command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"], "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": true, "name": "container2" } ], "family": "fsx-windows", "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole", "volumes": [ { "name": "fsx-windows-dir", "fsxWindowsFileServerVolumeConfiguration": { "fileSystemId": "fs-0eeb5730b2EXAMPLE", "authorizationConfig": { "domain": "example.com", "credentialsParameter": "arn:arn-1234" }, "rootDirectory": "share" } } ] } ``` ## Etapa 8: executar uma tarefa e visualizar os resultados Antes de executar a tarefa, verifique se o status do sistema de arquivos do FSx for Windows File Server está **Available** (Disponível). Depois que ele estiver disponível, será possível executar uma tarefa usando a definição de tarefa criada. A tarefa começa ao criar contêineres que embaralham um arquivo HTML entre eles usando o sistema de arquivos. Após o embaralhamento, um servidor Web atende à página HTML simples. **nota** Talvez você não seja capaz de se conectar ao site a partir de uma VPN. **Execute uma tarefa e veja os resultados no console do Amazon ECS.** 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, em seguida, escolha **windows-fsx-cluster**. 1. Escolha a guia **Tarefas** e, em seguida, escolha **Executar nova tarefa**. 1. Em **Launch Type**, selecione **EC2**. 1. Em Configuração de implantação, para **Definição de tarefa**, escolha **fsx-windows** e, em seguida, escolha **Criar**. 1. Quando o status da tarefa for **EM EXECUÇÃO**, escolha o ID da tarefa. 1. Em **Contêineres**, quando o status do contêiner1 for **INTERROMPIDO**, selecione contêiner2 para ver os detalhes do contêiner. 1. Em **Detalhes de contêiner para o contêiner2**, selecione **Ligações de rede** e clique no endereço IP externo associado ao contêiner. O navegador abrirá e exibirá a mensagem a seguir. ``` Amazon ECS Sample App It Works! You are using Amazon FSx for Windows File Server file system for persistent container storage. ``` **nota** Pode demorar alguns minutos para que a mensagem seja exibida. Se você não vir a mensagem após alguns minutos, certifique-se de que as execuções não estejam ocorrendo em uma VPN e de que o grupo de segurança das instâncias de contêiner permita o tráfego HTTP da rede de entrada na porta 443. ## Etapa 9: limpar **nota** Demora de 20 a 45 minutos para excluir o sistema de arquivos do FSx for Windows File Server ou o AD. Você deve aguardar até que as operações de exclusão do sistema de arquivos do FSx for Windows File Server sejam concluídas antes de iniciar as operações de exclusão do AD. **Exclua o sistema de arquivos do FSx for Windows File Server** 1. Abra o [console do Amazon FSx](https://console.aws.amazon.com//fsx/). 1. Escolha o botão de opção à esquerda do sistema de arquivos do FSx for Windows File Server que você acabou de criar. 1. Escolha **Ações**. 1. Selecione **Delete file system** (Excluir sistema de arquivos). **Excluir AD.** 1. Abra o [console do Directory Service](https://console.aws.amazon.com//directoryservicev2/). 1. Escolha o botão de opção à esquerda do AD que você acabou de criar. 1. Escolha **Ações**. 1. Selecione **Delete directory** (Excluir diretório). **Excluir o cluster.** 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, em seguida, escolha **windows-fsx-cluster**. 1. Escolha **Delete Cluster (Excluir cluster)**. 1. Insira a frase e, em seguida, escolha **Excluir**. **Encerra a instância do EC2.** 1. Abra o [console do Amazon EC2](https://console.aws.amazon.com//ec2/). 1. No menu à esquerda, selecione **Instances** (Instâncias). 1. Marque a caixa de seleção à esquerda da instância do EC2 que você criou. 1. Clique no **Estado da instância**, **Encerrar instância**. **Excluir segredo.** 1. Abra o [console do Secrets Manager](https://console.aws.amazon.com//secretsmanager/). 1. Selecione o segredo que você criou para esta demonstração. 1. Clique em **Actions** (Ações) 1. Selecione **Delete secret** Excluir segredo). # Uso de volumes do Docker com o Amazon ECS Ao usar os volumes do Docker, o driver `local` integrado ou um driver de volume de terceiros poderão ser usados. Os volumes do Docker são gerenciados pelo Docker e um diretório é criado em `/var/lib/docker/volumes` na instância de contêiner que contém os dados de volume. Para usar os volumes do Docker, especifique uma `dockerVolumeConfiguration` em sua definição de tarefa. Para obter mais informações, consulte [Volumes](https://docs.docker.com/engine/storage/volumes/) na documentação do Docker. Alguns casos de uso comuns para os volumes do Docker são os seguintes: + Para fornecer volumes de dados persistentes para uso com contêineres + Para compartilhar um volume de dados definido em locais diferentes em contêineres diferentes na mesma instância de contêiner + Para definir um volume de dados não persistente e vazio, além de montá-lo em vários contêineres na mesma tarefa + Para fornecer um volume de dados para sua tarefa gerenciada por um driver de terceiros ## Considerações sobre o uso de volumes do Docker Considere o seguinte ao usar volumes do Docker: + Só há suporte para os volumes do Docker com o uso do tipo de inicialização do EC2 ou instâncias externas. + Os contêineres do Windows só são compatíveis com o uso do driver `local`. + Se um driver de terceiros for usado, verifique se ele está instalado e ativo na instância do contêiner antes que o agente de contêiner seja iniciado. Se o driver de terceiros não estiver ativo antes da inicialização do agente, será possível reiniciar o agente do contêiner usando um dos comandos a seguir: + Para a AMI do Amazon Linux 2 otimizada para o Amazon ECS: ``` sudo systemctl restart ecs ``` + Para a AMI do Amazon Linux otimizada para o Amazon ECS: ``` sudo stop ecs && sudo start ecs ``` Para obter informações sobre como especificar um volume do Docker em uma definição de tarefa, consulte [Especificar um volume do Docker em uma definição de tarefa do Amazon ECS](specify-volume-config.md). # Especificar um volume do Docker em uma definição de tarefa do Amazon ECS Antes de seus contêineres poderem usar volumes de dados, você deve especificar as configurações de volume e ponto de montagem em sua definição de tarefa. Esta seção descreve a configuração do volume de um contêiner. Para tarefas que usam um volume do Docker, especifique um `dockerVolumeConfiguration`. Para tarefas que usam um volume de host de montagem bind, especifique um `host` e `sourcePath` opcional. O JSON de definição de tarefa a seguir mostra a sintaxe para os objetos `volumes` e `mountPoints` de um contêiner. ``` { "containerDefinitions": [ { "mountPoints": [ { "sourceVolume": "string", "containerPath": "/path/to/mount_volume", "readOnly": boolean } ] } ], "volumes": [ { "name": "string", "dockerVolumeConfiguration": { "scope": "string", "autoprovision": boolean, "driver": "string", "driverOpts": { "key": "value" }, "labels": { "key": "value" } } } ] } ``` `name` Tipo: string Obrigatório: não O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner. `dockerVolumeConfiguration` Tipo: objeto [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado ao usar volumes do Docker. Os volumes do Docker só são compatíveis ao executar tarefas em instâncias do EC2. Os contêineres do Windows só são compatíveis com o uso do driver `local`. Para usar montagens bind, em vez disso, especifique um `host`. `scope` Tipo: string Valores válidos: `task` \$1 `shared` Obrigatório: não O escopo para o volume do Docker, que determina o ciclo de vida. Os volumes do Docker que são delimitados para uma `task` são provisionados automaticamente quando a tarefa é iniciada e destruídos quando a tarefa é interrompida. Volumes do Docker delimitados como `shared` são mantidos após a interrupção da tarefa. `autoprovision` Tipo: booliano Valor padrão: `false` Obrigatório: não Se o valor for `true`, o volume de Docker será criado se ele ainda não existir. Esse campo só será usado se `scope` for `shared`. Se `scope` for `task`, esse parâmetro deverá ser omitido. `driver` Tipo: string Obrigatório: não O driver do volume do Docker a ser usado. O valor do driver deve corresponder ao nome do driver fornecido pelo Docker porque esse nome é usado no posicionamento de tarefas. Se o driver foi instalado usando a CLI de plug-in do Docker, use `docker plugin ls` para recuperar o nome do driver na instância de contêiner. Se o driver foi instalado usando outro método, use a descoberta de plug-in do Docker para recuperar o nome do driver. `driverOpts` Tipo: string Obrigatório: não Um mapa de opções específicas do driver do Docker pelas quais passar. Esse parâmetro é mapeado para `DriverOpts` na seção Criar um volume da API remota do Docker. `labels` Tipo: string Obrigatório: não Metadados personalizados para adicionar ao volume do Docker. `mountPoints` Tipo: Matriz de objeto Obrigatório: não Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS. `sourceVolume` Tipo: string Exigido: Sim, quando `mountPoints` são usados O nome do volume a ser montado. `containerPath` Tipo: string Exigido: Sim, quando `mountPoints` são usados O caminho no contêiner onde o volume será montado. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`. # Exemplos de volume do Docker para o Amazon ECS Os exemplos a seguir mostram como fornecer armazenamento temporário para um contêiner, como fornecer um volume compartilhado para vários contêineres e como fornecer armazenamento persistente NFS para um contêiner. **Para fornecer armazenamento temporário em um contêiner usando um volume do Docker** Neste exemplo, um contêiner utiliza um volume de dados vazio que é descartado após o término da tarefa. Um exemplo de caso de uso é que você pode ter um contêiner que precisa acessar algum local de armazenamento de arquivos temporários durante uma tarefa. Essa tarefa pode ser realizada usando um volume do Docker. 1. Na seção `volumes` de definição de tarefa, defina um volume de dados com os valores `name` e `DockerVolumeConfiguration`. Neste exemplo, especificamos o escopo como `task` para que o volume seja excluído depois que a tarefa é interrompida e use o driver `local` integrado. ``` "volumes": [ { "name": "scratch", "dockerVolumeConfiguration" : { "scope": "task", "driver": "local", "labels": { "scratch": "space" } } } ] ``` 1. Na seção `containerDefinitions`, defina um contêiner com valores `mountPoints` que faz referência ao nome do volume definido e o valor `containerPath` para montar o volume no contêiner. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "scratch", "containerPath": "/var/scratch" } ] } ] ``` **Para fornecer armazenamento persistente para vários contêiner usando um volume do Docker** Neste exemplo, você quer um volume compartilhado para vários contêineres usarem e deseja que ele persista após a interrupção de qualquer tarefa única que o esteja usando. O driver `local` integrado está sendo usado. Isso acontece para que o volume permaneça vinculado ao ciclo de vida da instância de contêiner. 1. Na seção `volumes` de definição de tarefa, defina um volume de dados com os valores `name` e `DockerVolumeConfiguration`. Neste exemplo, especifique um escopo `shared` de forma que o volume persista e defina a provisão automática como `true`. Isso acontece para que o volume seja criado para uso. Então, utilize também o driver `local` incorporado. ``` "volumes": [ { "name": "database", "dockerVolumeConfiguration" : { "scope": "shared", "autoprovision": true, "driver": "local", "labels": { "database": "database_name" } } } ] ``` 1. Na seção `containerDefinitions`, defina um contêiner com valores `mountPoints` que faz referência ao nome do volume definido e o valor `containerPath` para montar o volume no contêiner. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "database", "containerPath": "/var/database" } ] }, { "name": "container-2", "mountPoints": [ { "sourceVolume": "database", "containerPath": "/var/database" } ] } ] ``` **Para fornecer armazenamento NFS persistente para um contêiner usando um volume do Docker** Neste exemplo, um contêiner utiliza um volume de dados do NFS que é montado automaticamente quando a tarefa é iniciada e desmontado quando a tarefa é interrompida. Isso usa o driver `local` integrado do Docker. Um exemplo de caso de uso: você pode ter um armazenamento NFS local e precisa acessá-lo por meio de uma tarefa do ECS Anywhere. Isso pode ser feito usando uma opção de volume do Docker com driver NFS. 1. Na seção `volumes` de definição de tarefa, defina um volume de dados com os valores `name` e `DockerVolumeConfiguration`. Neste exemplo, especifique um escopo de `task` para que o volume seja desmontado após o término da tarefa. Use o driver `local` e configure o `driverOpts` com as opções `type`, `device` e `o` de acordo. Substitua `NFS_SERVER` pelo endpoint do servidor NFS. ``` "volumes": [ { "name": "NFS", "dockerVolumeConfiguration" : { "scope": "task", "driver": "local", "driverOpts": { "type": "nfs", "device": "$NFS_SERVER:/mnt/nfs", "o": "addr=$NFS_SERVER" } } } ] ``` 1. Na seção `containerDefinitions`, defina um contêiner com valores `mountPoints` que faça referência ao nome do volume definido e o valor `containerPath` para montar o volume no contêiner. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "NFS", "containerPath": "/var/nfsmount" } ] } ] ``` # Uso de montagens vinculadas com o Amazon ECS Com montagens vinculadas, um arquivo ou diretório em um host, como uma instância do Amazon EC2, é montado em um contêiner. As montagens bind são compatíveis com tarefas hospedadas em instâncias do Fargate e do Amazon EC2. Montagens vinculadas estão associadas ao ciclo de vida do contêiner que as usa. A partir do momento em que todos os contêineres que utilizam uma montagem bind forem interrompidos, por exemplo, quando uma tarefa é interrompida, os dados serão removidos. Para tarefas hospedadas em instâncias do Amazon EC2, os dados podem ser vinculados ao ciclo de vida da instância do Amazon EC2 do host especificando um `host` e um valor opcional de `sourcePath` na definição de tarefa. Para obter mais informações, consulte [Montagens bind](https://docs.docker.com/engine/storage/bind-mounts/) na documentação do Docker. Veja a seguir alguns casos de uso comuns de montagens bind. + Para fornecer um volume de dados vazio para ser montado em um ou mais contêineres. + Para montar um volume de dados de host em um ou mais contêineres. + Para compartilhar um volume de dados de um contêiner de origem com outros contêineres na mesma tarefa. + Para expor um caminho e seu conteúdo de um Dockerfile para um ou mais contêineres. ## Considerações quando forem usadas montagens bind Ao usar montagens bind, considere o seguinte. + Por padrão, as tarefas hospedadas no AWS Fargate usando a versão da plataforma `1.4.0` ou posterior (Linux) ou `1.0.0` ou posterior (Windows) recebem, no mínimo, 20 GiB de armazenamento temporário para montagens vinculadas. É possível aumentar a quantidade total de armazenamento temporário, até um máximo de 200 GiB, com a especificação do parâmetro `ephemeralStorage` na definição da tarefa. + Para expor arquivos de um Dockerfile a um volume de dados quando uma tarefa é executada, o plano de dados do Amazon ECS procura uma diretiva `VOLUME`. Se o caminho absoluto especificado na diretiva `VOLUME` é o mesmo que o `containerPath` especificado na definição de tarefa, os dados no caminho da diretiva `VOLUME` são copiados para o volume de dados. No exemplo de Dockerfile a seguir, um arquivo denominado `examplefile` do diretório `/var/log/exported` é gravado no host e, em seguida, montado no contêiner. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Por padrão, as permissões de volume são definidas como `0755` e o proprietário como `root`. É possível personalizar essas permissões no Dockerfile. O exemplo a seguir define o proprietário do diretório como `node`. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported RUN touch /var/log/exported/examplefile USER node VOLUME ["/var/log/exported"] ``` + Para tarefas hospedadas em instâncias do Amazon EC2, quando um`host` e `sourcePath` não são especificados, o daemon do Docker gerencia a montagem bind para você. Quando nenhum contêiner fizer referência a essa montagem bind, o serviço de limpeza de tarefas do agente de contêiner do Amazon ECS acabará excluindo-a. Isso ocorre por padrão três horas após o encerramento do contêiner. Porém, é possível configurar essa duração com a variável de agente `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). Se você precisar que esses dados persistam além do ciclo de vida do contêiner, especifique um valor `sourcePath` para a montagem bind. + Para tarefas hospedadas em instâncias gerenciadas do Amazon ECS, partes do sistema de arquivos raiz são somente de leitura. As montagens de ligação de leitura/gravação devem utilizar diretórios graváveis, como `/var` para dados persistentes ou `/tmp` para dados temporários. A tentativa de criar montagens vinculadas de leitura/gravação em outros diretórios faz com que a tarefa não seja iniciada, gerando um erro semelhante ao seguinte: ``` error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system ``` Montagens de associação somente leitura (configuradas com `"readOnly": true` no parâmetro `mountPoints`) podem apontar para qualquer diretório acessível no host. Para visualizar uma lista completa dos caminhos graváveis, você pode executar uma tarefa em uma Instância Gerenciada do Amazon ECS e usar o comando para inspecionar a tabela de montagens da instância. Crie uma definição de tarefa com as seguintes configurações para acessar o sistema de arquivos do host: ``` { "pidMode": "host", "containerDefinitions": [{ "privileged": true, ... }] } ``` Em seguida, execute os seguintes comandos dentro do contêiner: ``` # List writable mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^rw,/ || $4 == "rw" {print $2}' | sort # List read-only mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^ro,/ || $4 == "ro" {print $2}' | sort ``` **Importante** A configuração `privileged` concede ao contêiner recursos estendidos no host, equivalentes ao acesso root. Neste exemplo, ele é utilizado para examinar a tabela de montagens do host para fins de diagnóstico. Para obter mais informações, consulte [Evitar executar contêineres como privilegiados (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers). Para obter mais informações sobre como executar comandos de forma interativa em contêineres, consulte [Monitoramento de contêineres do Amazon ECS com o ECS Exec](ecs-exec.md). # Especificar uma montagem associada em uma definição de tarefa do Amazon ECS Em tarefas do Amazon ECS hospedadas em instâncias do Fargate ou do Amazon EC2, o trecho JSON de definição de tarefa a seguir mostra a sintaxe dos objetos `volumes`, `mountPoints` e `ephemeralStorage` para uma definição de tarefa. ``` { "family": "", ... "containerDefinitions" : [ { "mountPoints" : [ { "containerPath" : "/path/to/mount_volume", "sourceVolume" : "string" } ], "name" : "string" } ], ... "volumes" : [ { "name" : "string" } ], "ephemeralStorage": { "sizeInGiB": integer } } ``` Para tarefas do Amazon ECS que são hospedadas em instâncias do Amazon EC2, é possível utilizar o parâmetro `host` e um `sourcePath` ao especificar detalhes do volume da tarefa. Quando especificado, ele associa a montagem bind ao ciclo de vida da tarefa no lugar do contêiner. ``` "volumes" : [ { "host" : { "sourcePath" : "string" }, "name" : "string" } ] ``` A seguir, é descrito em mais detalhes cada parâmetro de definição de tarefa. `name` Tipo: string Obrigatório: não O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner. `host` Obrigatório: não O parâmetro `host` é usado para vincular o ciclo de vida da montagem bind à instância host do Amazon EC2, em vez da tarefa, e onde ela está armazenada. Caso o parâmetro `host` esteja vazio, o daemon do Docker atribui um caminho host para o volume de dados, mas os dados não têm garantia de persistir depois que os contêineres associados deixarem de ser executados. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. O parâmetro `sourcePath` é compatível apenas quando se utilizam tarefas hospedadas em instâncias do Amazon EC2 ou em instâncias gerenciadas do Amazon ECS. `sourcePath` Tipo: string Obrigatório: não Quando o parâmetro `host` é usado, especifique um `sourcePath` para declarar o caminho na instância host do Amazon EC2 que é apresentada ao contêiner. Caso esse parâmetro esteja vazio, o daemon do Docker atribui um caminho host para você. Caso o parâmetro `host` contenha um local de arquivo `sourcePath`, o volume de dados persistirá no local especificado na instância host do Amazon EC2 até você excluí-lo manualmente. Caso o valor `sourcePath` não exista na instância host do Amazon EC2, o daemon do Docker o criará. Caso o local exista, o conteúdo da pasta do caminho de origem é exportado. `mountPoints` Tipo: Matriz de objeto Obrigatório: não Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS. `sourceVolume` Tipo: string Exigido: Sim, quando `mountPoints` são usados O nome do volume a ser montado. `containerPath` Tipo: string Exigido: Sim, quando `mountPoints` são usados O caminho no contêiner onde o volume será montado. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`. `ephemeralStorage` Tipo: Objeto Obrigatório: não A quantidade de armazenamento temporário a ser alocada para a tarefa. Esse parâmetro é usado para expandir a quantidade total de armazenamento temporário, além da quantidade padrão, para tarefas hospedadas no AWS Fargate, usando a versão `1.4.0` ou posterior (Linux) ou `1.0.0` ou posterior (Windows) da plataforma. É possível usar a CLI do Copilot, o CloudFormation, o AWS SDK ou a CLI para especificar o armazenamento temporário para uma montagem bind. # Exemplos de montagem de associação para o Amazon ECS Os exemplos a seguir abrangem casos de uso comuns de uma montagem bind para contêineres. **Para alocar uma quantidade maior de espaço de armazenamento temporário para uma tarefa do Fargate** Para tarefas do Amazon ECS hospedadas no Fargate usando a versão `1.4.0` ou posterior (Linux) ou `1.0.0` (windows) da plataforma, você pode alocar mais do que a quantidade padrão de armazenamento temporário para os contêineres da tarefa que serão usados. Esse exemplo pode ser incorporado aos outros exemplos para alocar mais armazenamento temporário para suas tarefas do Fargate. + Na definição da tarefa, defina um objeto `ephemeralStorage`. O `sizeInGiB` deve ser um número inteiro entre os valores de `21` e `200` e é expresso em GiB. ``` "ephemeralStorage": { "sizeInGiB": integer } ``` **Para fornecer um volume de dados vazio para um ou mais contêineres** Em alguns casos, você pode querer fornecer aos contêineres de uma tarefa algum espaço temporário. Por exemplo, você pode ter dois contêineres de banco de dados que precisam acessar o mesmo local de armazenamento de arquivos temporários durante uma tarefa. Isso pode ser feito usando uma montagem bind. 1. Na seção `volumes` da definição de tarefa, defina uma montagem bind com o nome `database_scratch`. ``` "volumes": [ { "name": "database_scratch" } ] ``` 1. Na seção `containerDefinitions`, crie as definições de contêiner de banco de dados. Isso deve ser feito para que elas montem o volume. ``` "containerDefinitions": [ { "name": "database1", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] }, { "name": "database2", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] } ] ``` **Para expor um caminho e seu conteúdo em um Dockerfile para um contêiner** Neste exemplo, você tem um Dockerfile que grava dados que você quer montar em um contêiner. Este exemplo funciona para tarefas hospedadas em instâncias do Fargate ou do Amazon EC2. 1. Crie um Dockerfile. O exemplo a seguir usa a imagem pública do contêiner do Amazon Linux 2 e cria um arquivo denominado `examplefile` no diretório `/var/log/exported`que queremos montar dentro do contêiner. A diretiva `VOLUME` deve especificar um caminho absoluto. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Por padrão, as permissões de volume são definidas como `0755` e o proprietário como `root`. Essas permissões podem ser alteradas no Dockerfile. No exemplo a seguir, o proprietário do diretório `/var/log/exported` é definido como `node`. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported USER node RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` 1. Na seção `volumes` da definição da tarefa, defina um volume com o nome `application_logs`. ``` "volumes": [ { "name": "application_logs" } ] ``` 1. Na seção `containerDefinitions`, crie as definições do contêiner da aplicação. Isso deve ser feito para que elas montem o armazenamento. O valor `containerPath` deve corresponder ao caminho absoluto especificado na diretiva `VOLUME` do Dockerfile. ``` "containerDefinitions": [ { "name": "application1", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] }, { "name": "application2", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] } ] ``` **Para fornecer um volume de dados vazio para um contêiner vinculado ao ciclo de vida da instância host do Amazon EC2** Para tarefas hospedadas em instâncias do Amazon EC2, você pode usar montagens bind e ter os dados vinculados ao ciclo de vida da instância host do Amazon EC2. É possível fazer isso usando o parâmetro `host` e especificando um valor `sourcePath`. Todos os arquivos existentes em `sourcePath` são apresentados aos contêineres no valor `containerPath`. Todos os arquivos que são gravados no valor `containerPath` são gravados no valor `sourcePath` na instância do host do Amazon EC2. **Importante** O Amazon ECS não sincroniza seu armazenamento entre instâncias do Amazon EC2. As tarefas que usam armazenamento persistente podem ser colocadas em qualquer instância do Amazon EC2, no cluster que tiver capacidade disponível. Se suas tarefas exigirem armazenamento persistente após a interrupção e a reinicialização, sempre especifique a mesma instância do Amazon EC2 no momento da inicialização da tarefa com o comando [start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) da AWS CLI. Também podem ser usados 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). 1. Na seção `volumes` da definição de tarefa, defina uma montagem bind com os valores `name` e `sourcePath`. No exemplo a seguir, a instância host do Amazon EC2 contém dados em `/ecs/webdata` que você quer montar no contêiner. ``` "volumes": [ { "name": "webdata", "host": { "sourcePath": "/ecs/webdata" } } ] ``` 1. Na seção `containerDefinitions`, defina um contêiner com um valor `mountPoints` que faça referência ao nome da montagem bind definida e ao valor `containerPath` para montar a montagem bind no contêiner. ``` "containerDefinitions": [ { "name": "web", "image": "public.ecr.aws/docker/library/nginx:latest", "cpu": 99, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webdata", "containerPath": "/usr/share/nginx/html" } ] } ] ``` **Para montar um volume definido em vários contêineres em diferentes locais** É possível definir um volume de dados em uma definição de tarefa e montar esse volume em locais diferentes em diferentes contêineres. Por exemplo, seu contêiner host tem uma pasta de dados de site em `/data/webroot`. É possível montar esse volume de dados como somente leitura em dois servidores Web diferentes com raízes de documentos distintas. 1. Na seção `volumes` de definição de tarefa, defina um volume de dados com o nome `webroot` e o caminho de origem `/data/webroot`. ``` "volumes": [ { "name": "webroot", "host": { "sourcePath": "/data/webroot" } } ] ``` 1. Na seção `containerDefinitions`, defina um contêiner para cada servidor da Web com valores `mountPoints` que associam o volume `webroot` com o valor `containerPath` apontando para a raiz do documento desse contêiner. ``` "containerDefinitions": [ { "name": "web-server-1", "image": "my-repo/ubuntu-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/var/www/html", "readOnly": true } ] }, { "name": "web-server-2", "image": "my-repo/sles11-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 8080, "hostPort": 8080 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/srv/www/htdocs", "readOnly": true } ] } ] ``` **Para montar volumes de outro contêiner usando `volumesFrom`** Para tarefas hospedadas em instâncias do Amazon EC2, é possível definir um ou mais volumes em um contêiner e, em seguida, usar o parâmetro `volumesFrom` em uma definição de contêiner diferente (dentro da mesma tarefa) para montar todos os volumes do `sourceContainer` em seus pontos de montagem definidos originalmente. O parâmetro `volumesFrom` se aplica a volumes determinados na definição de tarefa, e os que são incorporados na imagem com um Dockerfile. 1. (Opcional) Para compartilhar um volume incorporado em uma imagem, utilize a instrução `VOLUME` no arquivo Dockerfile. O Dockerfile de exemplo a seguir usa uma imagem `httpd` e, em seguida, adiciona um volume e monta-o em `dockerfile_volume` na raiz do documento Apache. É a pasta usada pelo servidor Web `httpd`. ``` FROM httpd VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"] ``` É possível incorporar uma imagem com esse Dockerfile e enviá-la para um repositório, como o Docker Hub, e usá-la em sua definição de tarefa. A imagem de exemplo `my-repo/httpd_dockerfile_volume` usada nas etapas a seguir foi criada com o Dockerfile anterior. 1. Crie uma definição de tarefa que defina seus outros volumes e pontos de montagem para os contêineres. Nesta seção `volumes` de exemplo, você cria um volume vazio chamado `empty`, que o daemon do Docker gerencia. Há também um volume host definido que se chama `host_etc`. Ele exporta a pasta `/etc` na instância de contêiner host. ``` { "family": "test-volumes-from", "volumes": [ { "name": "empty", "host": {} }, { "name": "host_etc", "host": { "sourcePath": "/etc" } } ], ``` Na seção definições de contêiner, crie um contêiner que monte os volumes definidos anteriormente. Neste exemplo, o contêiner `web` monta os volumes `empty` e `host_etc`. Este é o contêiner que utiliza a imagem criada com um volume no Dockerfile. ``` "containerDefinitions": [ { "name": "web", "image": "my-repo/httpd_dockerfile_volume", "cpu": 100, "memory": 500, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "mountPoints": [ { "sourceVolume": "empty", "containerPath": "/usr/local/apache2/htdocs/empty_volume" }, { "sourceVolume": "host_etc", "containerPath": "/usr/local/apache2/htdocs/host_etc" } ], "essential": true }, ``` Crie outro contêiner que use `volumesFrom` para montar todos os volumes que estão associados com o contêiner `web`. Todos os volumes no contêiner `web` também são montados no contêiner `busybox`. Isso inclui o volume especificado no Dockerfile que foi utilizado para criar a imagem `my-repo/httpd_dockerfile_volume`. ``` { "name": "busybox", "image": "busybox", "volumesFrom": [ { "sourceContainer": "web" } ], "cpu": 100, "memory": 500, "entryPoint": [ "sh", "-c" ], "command": [ "echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date" ], "essential": false } ] } ``` Quando essa tarefa é executada, os dois contêineres montam os volumes, e o `command` no contêiner `busybox` grava a data e a hora em um arquivo. Esse arquivo se chama `date` em cada uma das pastas de volume. As pastas ficam visíveis no site exibido pelo contêiner `web`. **nota** Como o contêiner `busybox` executa um comando rápido e, em seguida, é encerrado, ele deve ser definido como `"essential": false` na definição do contêiner. Caso contrário, ele interromperá toda a tarefa quando for encerrado. # Gerenciar o espaço de memória de troca de contêiner no Amazon ECS Com o Amazon ECS, você pode controlar o uso do espaço de memória de troca em suas instâncias do Amazon EC2 baseadas em Linux no nível de contêiner. Utilizando uma configuração de troca de contêiner, cada contêiner de uma definição de tarefa pode ter a troca habilitada ou desabilitada. Para aqueles com troca habilitada, a quantidade máxima de espaço de troca utilizada pode ser limitada. Por exemplo, contêineres críticos para latência podem ter a troca desabilitada. Por outro lado, contêineres com altas demandas de memória transitória podem ter a troca habilitada para reduzir as chances de erros de falta de memória quando o contêiner está sob carga. A configuração de troca para um contêiner é gerenciada pelos seguintes parâmetros de definição de contêiner. `maxSwap` A quantidade total de memória de troca (em MiB) que um contêiner pode usar. Esse parâmetro será convertido na opção `--memory-swap` para execução do docker em que o valor é a soma da memória do contêiner mais o valor de `maxSwap`. Se um valor `maxSwap` de `0` for especificado, o contêiner não usará a troca. Os valores aceitos são `0` ou qualquer número inteiro positivo. Se o parâmetro `maxSwap` for omitido, o contêiner usará a configuração de troca para a instância de contêiner na qual ele está sendo executado. Um valor `maxSwap` deve ser definido para que o parâmetro `swappiness` seja usado. `swappiness` É possível usar isso para ajustar o comportamento de troca de memória de um contêiner. Um valor `swappiness` igual a `0` faz com que a troca não ocorra, a menos que ela seja necessária. Um valor `swappiness` de `100` fará com que as páginas sejam trocadas de forma agressiva. Os valores aceitos são números inteiros entre `0` e `100`. Se o parâmetro `swappiness` não for especificado, será usado um valor padrão de `60`. Se nenhum valor for especificado para `maxSwap`, esse parâmetro será ignorado. Esse parâmetro é mapeado para a opção `--memory-swappiness` de execução do docker. No exemplo abaixo, é fornecida a sintaxe JSON. ``` "containerDefinitions": [{ ... "linuxParameters": { "maxSwap": integer, "swappiness": integer }, ... }] ``` ## Considerações Considere o seguinte ao usar uma configuração de troca de contêiner. + O espaço de troca deve ser habilitado e alocado na instância do Amazon EC2 que hospeda suas tarefas para os contêineres usarem. As AMIs otimizadas para o Amazon ECS não têm a troca habilitada por padrão. É necessário habilitar a troca na instância para usar esse atributo. Para obter mais informações, consulte [Volumes de troca de armazenamento de instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-swap-volumes.html) no *Manual do usuário do Amazon EC2* ou [Como alocar memória para atuar como espaço de troca em uma instância do Amazon EC2?](https://repost.aws/knowledge-center/ec2-memory-swap-file). + Os parâmetros de definição de contêiner do espaço de troca são compatíveis apenas com definições de tarefa que especificam o EC2. Esses parâmetros não são compatíveis com definições de tarefa destinadas somente ao uso do Amazon ECS no Fargate. + Esse recurso é compatível somente com contêineres do Linux. No momento, não há compatibilidade com contêineres do Windows. + Se os parâmetros `maxSwap` e `swappiness` de definição de contêiner forem omitidos de uma definição de tarefa, cada contêiner terá um valor `swappiness` padrão de `60`. Além disso, o limite de uso total de trocas é de duas vezes a memória do contêiner. + Se você estiver usando tarefas no Amazon Linux 2023, não haverá suporte para o parâmetro `swappiness`. # Diferenças de definição de tarefa do Amazon ECS para instâncias gerenciadas do Amazon ECS Para usar as instâncias gerenciadas do Amazon ECS, configure a definição de tarefa para usar o tipo de inicialização de instâncias gerenciadas do Amazon ECS. Há considerações adicionais ao usar instâncias gerenciadas do Amazon ECS. ## Parâmetros de definição de tarefa As tarefas que usam instâncias gerenciadas do Amazon ECS oferecem suporte à maioria dos parâmetros de definição de tarefa do Amazon ECS que estão disponíveis. No entanto, alguns parâmetros têm comportamentos ou limitações específicos quando usados com tarefas de instâncias gerenciadas do Amazon ECS. Os seguintes parâmetros de definição de tarefa não são válidos nas tarefas das instâncias gerenciadas do Amazon ECS: + `disableNetworking` + `dnsSearchDomains` + `dnsServers` + `dockerLabels` + `dockerSecurityOptions` + `dockerVolumeConfiguration` + `ephemeralStorage` + `extraHosts` + `fsxWindowsFileServerVolumeConfiguration` + `hostname` + `inferenceAccelerator` + `ipcMode` + `links` + `maxSwap` + `proxyConfiguration` + `sharedMemorySize` + `sourcepath`Volumes do + `swappiness` + `tmpfs` Os seguintes parâmetros de definição de tarefa são válidos nas tarefas das instâncias gerenciadas do Amazon ECS, mas têm limitações que devem ser observadas: + `networkConfiguration`: as instâncias gerenciadas do Amazon ECS usam o modo de rede `awsvpc` ou `host`. + `placementConstraints`: os atributos de restrição a seguir são compatíveis. + `ecs.subnet-id` + `ecs.availability-zone` + `ecs.instance-type` + `ecs.cpu-architecture` + `requiresCompatibilities`: deve incluir `MANAGED_INSTANCES` para garantir que a definição de tarefa seja compatível com as instâncias gerenciadas do Amazon ECS. + `resourceRequirement`: não há suporte para `InferenceAccelerator`. + `operatingSystemFamily`: as instâncias gerenciadas do Amazon ECS usam `LINUX`. + `volumes`: ao utilizar montagens de ligação com um `sourcePath`, o caminho deve apontar para um diretório gravável no host. Algumas partes do sistema de arquivos da Instância Gerenciada do Amazon ECS são somente leitura. Os diretórios graváveis incluem `/var` e `/tmp`. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md). Para garantir que sua definição de tarefa seja válida para uso com as instâncias gerenciadas do Amazon ECS, é possível especificar o seguinte ao registrar a definição de tarefa: + No Console de gerenciamento da AWS, para o campo **Requires Compatibilities (Requer compatibilidades)**, especifique `MANAGED_INSTANCES`. + Na AWS CLI, especifique a opção `--requires-compatibilities`. + Na API do Amazon ECS, especifique o sinalizador `requiresCompatibilities`. # 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 '.' ``` # Diferenças de definição de tarefa do Amazon ECS para instâncias do EC2 executando o Windows As tarefas executadas em instâncias do EC2 do Windows não oferecem suporte a todos os parâmetros de definição de tarefa disponíveis do Amazon ECS. Alguns parâmetros são totalmente incompatíveis e outros se comportam de maneira diferente. Os seguintes parâmetros de definição de tarefa não são compatíveis com definições de tarefa do Amazon EC2 do Windows: + `containerDefinitions` + `disableNetworking` + `dnsServers` + `dnsSearchDomains` + `extraHosts` + `links` + `linuxParameters` + `privileged` + `readonlyRootFilesystem` + `user` + `ulimits` + `volumes` + `dockerVolumeConfiguration` + `cpu` É recomendável especificar a CPU em nível de contêiner para contêineres do Windows. + `memory` É recomendável especificar a memória em nível de contêiner para contêineres do Windows. + `proxyConfiguration` + `ipcMode` + `pidMode` + `taskRoleArn` Os perfis do IAM para tarefas em recursos de instâncias do Windows para EC2 exigem uma configuração adicional, mas boa parte dela é semelhante à configuração de perfis do IAM para tarefas em instâncias de contêiner do Linux. Para obter mais informações, consulte [Configuração adicional de instância do Windows no Amazon EC2](task-iam-roles.md#windows_task_IAM_roles). # Criar uma definição de tarefa do Amazon ECS usando o console Crie uma definição de tarefa para poder definir a aplicação que você executa como tarefa ou serviço. Ao criar uma definição de tarefa para o tipo de execução externo, é necessário criar a definição da tarefa usando o editor JSON e definir o parâmetro `requireCapabilities` como `EXTERNAL`. É possível criar uma definição de tarefa usando a experiência do console ou especificando um arquivo JSON. Você pode fazer com que o Amazon Q forneça recomendações ao usar o editor JSON. Para obter mais informações, consulte . [Usar o Amazon Q Developer para fornecer recomendações de definição de tarefa no console do Amazon ECS](using-amazon-q.md) ## Validação de JSON O editor de JSON do console do Amazon ECS valida o seguinte no arquivo JSON: + O arquivo é um arquivo JSON válido. + O arquivo não contém nenhuma chave estranha. + O arquivo contém o parâmetro `familyName`. + Há pelo menos uma entrada em `containerDefinitions`. ## Pilhas do CloudFormation O comportamento a seguir é aplicável às definições de tarefa criadas no novo console do Amazon ECS antes de 12 de janeiro de 2023. Ao criar uma definição de tarefa, o console do Amazon ECS cria automaticamente uma pilha do CloudFormation com um nome que começa com `ECS-Console-V2-TaskDefinition-`. Se tiver usado a AWS CLI ou um AWS SDK para cancelar o registro da definição de tarefa, você deverá excluir manualmente a pilha de definições de tarefa. Para obter mais informações, consulte [Excluir uma pilha](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) no *Guia do usuário do CloudFormation*. As definições de tarefa criadas após 12 de janeiro de 2023 não têm uma pilha do CloudFormation criada automaticamente para elas. ## Procedimento ------ #### [ Amazon ECS console ] 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. No menu **Criar definição de tarefa**, escolha **Criar definição de tarefa**. 1. Em **Task definition family** (Família de definição de tarefa), especifique um nome exclusivo para a definição de tarefa. 1. Em **Tipo de inicialização**, escolha o ambiente da aplicação. O padrão do console é **AWS Fargate** (tecnologia sem servidor). O Amazon ECS usa esse valor para realizar a validação e garantir que os parâmetros de definição de tarefa sejam válidos para o tipo de infraestrutura. 1. Em **Operating system/Architecture** (Sistema operacional/arquitetura), escolha o sistema operacional e a arquitetura da CPU para a tarefa. Para executar a tarefa em uma arquitetura ARM de 64 bits, selecione **Linux/ARM64**. Para obter mais informações, consulte [Plataforma de runtime](task_definition_parameters.md#runtime-platform). Para executar suas tarefas do **AWS Fargate** em contêineres do Windows, escolha um sistema operacional Windows compatível. Para obter mais informações, consulte [Arquiteturas e sistemas operacionais](fargate-tasks-services.md#fargate-task-os). 1. Em **Task size** (Tamanho da tarefa), escolha os valores de CPU e memória a serem reservados para a tarefa. O valor da CPU é especificado como vCPUs e a memória é especificada como GB. Para tarefas hospedadas no Fargate, a tabela a seguir mostra as combinações válidas de CPU e memória. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-task-definition.html) Para tarefas que usam instâncias do EC2 ou externas, os valores compatíveis de CPU da tarefa são entre 128 unidades de CPU (0,125 vCPUs) e 196.608 unidades de CPU (192 vCPUs). Para especificar o valor da memória em GB, insira **GB** após o valor. Por exemplo, para definir o **Valor da memória** como 3 GB, insira **3 GB**. **nota** Os parâmetros de CPU e memória em nível de tarefa são ignorados para contêineres do Windows. 1. Em **Network mode** (Modo de rede), escolha o modo de rede a ser usado. O padrão é o modo **awsvpc**. Para obter mais informações, consulte [Redes de tarefas no Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). Se escolher **bridge**, em **Mapeamentos de portas**, em **Porta do host**, insira o número da porta na instância de contêiner a ser reservada para o contêiner. 1. (Opcional) Expanda a seção **Perfis de tarefa** para configurar os perfis do AWS Identity and Access Management (IAM) para a tarefa: 1. Em **Task role** (Perfil da tarefa), escolha um perfil do IAM para atribuir à tarefa. Um perfil do IAM de tarefa fornece permissões aos contêineres em uma tarefa para chamar operações de API da AWS. 1. Em **Perfil de execução de tarefas**, escolha o perfil. Para obter mais informações sobre quando usar um 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 você não precisar do perfil, escolha **Nenhum**. 1. (Opcional) Expanda a seção **Posicionamento de tarefas** para adicionar restrições de posicionamento. Restrições de posicionamento de tarefas permitem filtrar instâncias de contêiner utilizadas para o posicionamento das suas tarefas usando atributos integrados ou personalizados. 1. (Opcional) Expanda a seção **Injeção de falhas** para habilitar a injeção de falhas. A injeção de falhas permite testar como sua aplicação responde a certos cenários de comprometimento. 1. Para cada contêiner ser definido em sua definição de tarefa, conclua as seguintes etapas. 1. Em **Name** (Nome), insira um nome para o contêiner. 1. Em **Image URI** (URI da imagem), especifique a imagem a ser usada para iniciar um contêiner. As imagens no registro da Galeria pública do Amazon ECR podem ser especificadas usando apenas o nome do registro do Amazon ECR Public. Por exemplo, se `public.ecr.aws/ecs/amazon-ecs-agent:latest` for especificado, o contêiner do Amazon Linux hospedado na Galeria pública do Amazon ECR será usado. Para todos os outros repositórios, especifique o repositório usando os formatos `repository-url/image:tag` ou `repository-url/image@digest`. 1. Se sua imagem estiver em um registro privado fora do Amazon ECR, em **Registro privado**, ative a **Autenticação de registro privado**. Em seguida, em **ARN ou nome do Secrets Manager**, insira o nome do recurso da Amazon (ARN) do segredo. 1. Em **Contêiner essencial**, se a definição de tarefa tiver dois ou mais contêineres definidos, é possível especificar se o contêiner deve ser considerado essencial. Se um contêiner estiver marcado como **Essencial**, caso esse contêiner pare, a tarefa será interrompida. Cada definição de tarefa deve conter pelo menos um contêiner essencial. 1. Um mapeamento de porta permite que o contêiner acesse portas no host para enviar ou receber tráfego. Em **Port mappings** (Mapeamentos de porta), siga um destes procedimentos: + Quando você usar o modo de rede **awsvpc**, em **Container port** (Porta do contêiner) e **Protocol** (Protocolo), escolha o mapeamento de porta a ser usado para o contêiner. + Quando você usar o modo de rede **bridge**, em **Container port** (Porta do contêiner) e **Protocol** (Protocolo), especifique o mapeamento de porta a ser usado para o contêiner. Escolha **Add more port mappings** (Adicionar mais mapeamentos de portas) para especificar mapeamentos de porta de contêiner adicionais. 1. Para dar ao contêiner acesso somente de leitura ao sistema de arquivos raiz, em **Sistema de arquivos raiz somente leitura**, selecione **Somente leitura**. 1. (Opcional) Para definir os limites de CPU, GPU e memória em nível de contêiner que sejam diferentes dos valores em nível de tarefa, em **Limites de alocação de recursos**, faça o seguinte: + Em **CPU**, insira o número de unidades de CPU que o agente de contêiner do Amazon ECS reserva para o contêiner. + Em **GPU**, insira o número de unidades de GPU para a instância de contêiner. Uma instância do Amazon EC2 compatível com GPU tem 1 unidade de GPU para cada GPU. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md). + Em **Limite rígido de memória**, insira a quantidade de memória, em GB, para fornecer ao contêiner. Se o contêiner tentar exceder o limite rígido, o contêiner será interrompido. + O daemon 20.10.0 ou posterior do Docker reserva um mínimo de 6 mebibytes (MiB) de memória para um contêiner, portanto, não especifique menos de 6 MiB de memória para os contêineres. O daemon 19.03.13-ce ou anterior do Docker reserva um mínimo de 4 MiB de memória para um contêiner, portanto, não especifique menos de 4 MiB de memória para os contêineres. + Em **Limite flexível de memória**, insira o limite flexível (em GB) de memória a ser reservada para o contêiner. Quando a memória do sistema estiver em contenção, o Docker tentará manter a memória do contêiner dentro desse limite flexível. Se não especificar memória no nível de tarefa, será necessário especificar um número inteiro diferente de zero para um ou ambos os **Limite rígido de memória** e **limite flexível de memória**. Se você especificar ambos, o **Limite rígido de memória** deverá ser maior que o **Limite flexível de memória**. Não há suporte para esse recurso em contêineres do Windows. 1. (Opcional) Expanda a seção **Variáveis de ambiente** para especificar variáveis de ambiente a serem injetadas no contêiner. É possível especificar variáveis de ambiente individualmente usando pares de chave-valor ou em massa, especificando um arquivo de variável de ambiente hospedado em um bucket do Amazon S3. Para obter informações sobre como formatar um arquivo de variáveis de ambiente, consulte [Transferência de uma variável de ambiente individual para um contêiner do Amazon ECS](taskdef-envfiles.md). Ao especificar uma variável de ambiente para o armazenamento de segredos, em **Key**, insira o nome do segredo. Em seguida, para **ValueFrom**, insira o ARN completo do segredo do Systems Manager Parameter Store ou do segredo do Secrets Manager. 1. (Opcional) Selecione a opção **Use log collection** (Usar coleção de logs) para especificar uma configuração de log. Para cada driver de log disponível, há opções de driver de log a serem especificadas. A opção padrão envia os logs do contêiner ao Amazon CloudWatch Logs. As outras opções de driver de log são configuradas usando o AWS FireLens. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). Veja a seguir a descrição de cada destino de log de contêiner mais detalhadamente. + **Amazon CloudWatch**: configura a tarefa para enviar logs de contêiner ao CloudWatch Logs. São fornecidas as opções de driver de log padrão, que criam um grupo de logs do CloudWatch em seu nome. Para especificar um nome de grupo de logs diferente, altere os valores da opção de driver. + **Exportar logs para o Splunk**: configure a tarefa para enviar os log do contêiner ao driver do Splunk que envia os logs para a serviço remoto. Você deve inserir o URL do serviço Web Splunk. O token do Splunk é especificado como uma opção secreta, pois ele pode ser tratado como dados confidenciais. + **Exportar logs para o Amazon Data Firehose**: configure a tarefa para enviar logs de contêiner ao Firehose. São fornecidas as opções de driver de log padrão, que envia logs para um fluxo de entrega do Firehose. Para especificar um nome de fluxo de entrega diferente, altere os valores da opção de driver. + **Exportar logs para o Amazon Kinesis Data Streams**: configure a tarefa para enviar logs de contêiner ao Kinesis Data Streams. São fornecidas as opções de driver de log padrão, que envia logs a um fluxo do Kinesis Data Streams. Para especificar um nome de transmissão diferente, altere os valores da opção de driver. + **Exportar logs para o Amazon OpenSearch Service**: configure a tarefa para enviar logs de contêiner a um domínio do OpenSearch Service. As opções de driver de log devem ser fornecidas. + **Exportar logs para o Amazon S3**: configure a tarefa para enviar logs de contêiner a um bucket do Amazon S3. As opções de driver de log padrão são fornecidas, mas você deve especificar um nome de bucket válido do Amazon S3. 1. (Opcional) Configure parâmetros adicionais do contêiner. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-task-definition.html) 1. (Opcional) Escolha **Add more containers** (Adicionar mais contêineres) para incluir contêineres adicionais à definição de tarefa. 1. (Opcional) A seção **Armazenamento** é usada para expandir a quantidade de armazenamento temporário para tarefas hospedadas no Fargate. Também é possível usar essa seção para adicionar uma configuração de volume de dados à tarefa. 1. Para expandir o armazenamento temporário disponível além do valor padrão de 20 gibibytes (GiB) para as tarefas do Fargate, em **Amount** (Quantidade), insira um valor até 200 GiB. 1. (Opcional) Para adicionar uma configuração de volume de dados à definição da tarefa, escolha **Adicionar volume** e siga as etapas a seguir. 1. Em **Volume name** (Nome do volume), insira um nome para o volume de dados. O nome do volume de dados é usado na ocasião da criação de um ponto de montagem de contêiner. 1. Em **Configuração de volume**, selecione se deseja configurar o volume ao criar a definição de tarefa ou durante a implantação. **nota** Os volumes que podem ser configurados ao criar uma definição de tarefa incluem montagem vinculada, Docker, Amazon EFS e Amazon FSx para Windows File Server. Os volumes que podem ser configurados na implantação ao executar uma tarefa ou ao criar ou atualizar um serviço incluem o Amazon EBS. 1. Em **Tipo de volume**, selecione um tipo de volume compatível com o tipo de configuração selecionado e configure o tipo de volume. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-task-definition.html) 1. Para adicionar um volume de outro contêiner, escolha **Adicionar volume de** e configure o seguinte: + Em **Contêiner**, escolha o contêiner. + Em **Origem**, escolha o contêiner que tem o volume que você deseja montar. + Em **Somente leitura**, selecione se o contêiner tem acesso somente leitura ao volume. 1. (Opcional) Para definir as configurações de rastreamento e coleção de métricas de aplicações usando a integração AWS Distro for OpenTelemetry, expanda **Monitoramento** e selecione **Usar coleção de métricas** para coletar e enviar métricas das tarefas ao Amazon CloudWatch ou ao Amazon Managed Service for Prometheus. Quando essa opção é selecionada, o Amazon ECS cria um arquivo associado de contêiner do AWS Distro for OpenTelemetry pré-configurado para enviar as métricas da aplicação. Para obter mais informações, consulte [Correlação do desempenho da aplicação do Amazon ECS usando métricas de aplicações](metrics-data.md). 1. Quando **Amazon CloudWatch** está selecionado, suas métricas de aplicação personalizadas são roteadas para o CloudWatch como métricas personalizadas. Para obter mais informações, consulte [Exportação de métricas de aplicações para o Amazon CloudWatch](application-metrics-cloudwatch.md). **Importante** Ao exportar métricas de aplicações para o Amazon CloudWatch, sua definição de tarefa requer uma função do IAM de tarefa com as permissões necessárias. Para obter mais informações, consulte [Permissões obrigatórias do IAM para integração da distribuição da AWS do OpenTelemetry com o Amazon CloudWatch](application-metrics-cloudwatch.md#application-metrics-cloudwatch-iam). 1. Quando **Amazon Managed Service for Prometheus (Prometheus libraries instrumentation)** (Amazon Managed Service for Prometheus [instrumentação das bibliotecas Prometheus]) está selecionado, as métricas de CPU, memória, rede e armazenamento no nível da tarefa e as métricas de aplicação personalizadas são roteadas para o Amazon Managed Service for Prometheus. Em **Endpoint de gravação remoto do espaço de trabalho**, insira o URL do endpoint de gravação remoto para o espaço de trabalho do Prometheus. Em **Destino de rascunho**, insira o host e a porta que o coletor Distro for OpenTelemetry da AWS pode usar para extrair dados de métricas. Para obter mais informações, consulte [Exportação de métricas de aplicações para o Amazon Managed Service for Prometheus](application-metrics-prometheus.md). **Importante** Ao exportar métricas de aplicações para o Amazon Managed Service for Prometheus, sua definição de tarefa requer uma função do IAM de tarefa com as permissões necessárias. Para obter mais informações, consulte [Permissões obrigatórias do IAM para integração da distribuição da AWS do OpenTelemetry com o Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam). 1. Ao selecionar **Amazon Managed Service for Prometheus (instrumentação do OpenTelemetry)**, as métricas de CPU, memória, rede e armazenamento em nível de tarefa e as métricas de aplicação personalizadas são encaminhadas ao Amazon Managed Service for Prometheus. Em **Endpoint de gravação remoto do espaço de trabalho**, insira o URL do endpoint de gravação remoto para o espaço de trabalho do Prometheus. Para obter mais informações, consulte [Exportação de métricas de aplicações para o Amazon Managed Service for Prometheus](application-metrics-prometheus.md). **Importante** Ao exportar métricas de aplicações para o Amazon Managed Service for Prometheus, sua definição de tarefa requer uma função do IAM de tarefa com as permissões necessárias. Para obter mais informações, consulte [Permissões obrigatórias do IAM para integração da distribuição da AWS do OpenTelemetry com o Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam). 1. (Opcional) Expanda a seção **Tags** para adicionar tags à definição da tarefa, como pares de chave-valor. + [Adicionar uma etiqueta] Escolha **Add tag** (Adicionar etiqueta) e faça o seguinte: + Em **Chave**, insira o nome da chave. + Em **Valor** insira o valor da chave. + [Remover uma tag] Ao lado da tag, escolha **Remove tag (Remover tag)**. 1. Escolha **Criar** para registrar a definição de tarefa. ------ #### [ Amazon ECS console JSON editor ] 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. No menu **Criar definição de tarefa**, escolha **Criar definição de tarefa com JSON**. 1. Na caixa do editor de JSON, edite o arquivo JSON. O JSON deve ser aprovado nas verificações de validação especificadas em [Validação de JSON](#json-validate-for-create). 1. Escolha **Criar**. ------ # Usar o Amazon Q Developer para fornecer recomendações de definição de tarefa no console do Amazon ECS Ao usar o editor JSON no console do Amazon ECS para criar uma definição de tarefa, você pode usar o Amazon Q Developer para fornecer sugestões de código geradas por IA para suas definições de tarefas. Você pode usar o recurso de chat em linha para pedir ao Amazon Q Developer que gere, explique ou refatore o JSON de definição de tarefa com uma interface de conversa. Você pode injetar sugestões geradas em qualquer ponto da definição da tarefa e aceitar ou rejeitar as alterações propostas. O Amazon ECS também aprimorou o recurso existente de sugestões em linha para utilizar o Amazon Q Developer. Ao criar uma definição de tarefa usando o editor JSON, você pode fazer com que o Amazon Q Developer forneça recomendações que ajudem a criar uma definição de tarefa mais rapidamente. Você pode ter sugestões em linha baseadas em propriedade ou usar as sugestões do Amazon Q Developer para preencher automaticamente blocos inteiros de código de amostra. Você pode usar esse recurso em regiões nas quais há suporte para o Amazon Q Developer. Para obter mais informações, consulte [Serviços da AWS por região](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). ## Pré-requisitos Veja a seguir os pré-requisitos: + Além das permissões do console, o usuário que cria a definição da tarefa no console deve ter a permissão `codewhisperer:GenerateRecommendations` para as recomendações e `q:SendMessage` para usar o chat em linha. Para obter mais informações, consulte [Permissões necessárias para usar o Amazon Q Developer para fornecer recomendações no console](console-permissions.md#amazon-q-permission). ## Procedimento 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. No menu **Criar definição de tarefa**, escolha **Criar definição de tarefa com JSON**. A página **Criar definição de tarefa** é aberta. O console fornece o modelo padrão a seguir. ``` { "requiresCompatibilities": [ "FARGATE" ], "family": "", "containerDefinitions": [ { "name": "", "image": "", "essential": true } ], "volumes": [], "networkMode": "awsvpc", "memory": "3 GB", "cpu": "1 vCPU", "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole" } ``` 1. No pop-up de sugestões em linha do Amazon Q, escolha **Permitir**. Se você ignorar o pop-up, poderá habilitar o Amazon Q no ícone de engrenagem. 1. Na caixa do editor de JSON, edite o documento JSON. Para que o Amazon Q crie e preencha os parâmetros, insira um comentário com o que você deseja adicionar. No exemplo abaixo, o comentário faz com que o Amazon Q gere as linhas em negrito. ``` { "requiresCompatibilities": [ "FARGATE" ], "family": "", "containerDefinitions": [ { "name": "", "image": "", "essential": true }, // add an nginx container using an image from Public ECR, with port 80 open, and send logs to CloudWatch log group "myproxy" { "name": "nginx", "image": "public.ecr.aws/nginx/nginx:latest", "essential": true, "portMappings": [ { "containerPort": 80, "hostPort": 80, "protocol": "tcp" } ], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "myproxy", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "nginx" } } } ], "volumes": [], "networkMode": "awsvpc", "memory": "3 GB", "cpu": "1 vCPU", "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole" } ``` 1. Para usar o recurso de chat em linha, você pode destacar as linhas e escolher o ícone de estrela. A caixa de chat do Amazon Q Developer é exibida. Insira sua solicitação. O Amazon Q Developer gera e depois atualiza o JSON. Para aceitar as alterações, escolha **Aceitar tudo** 1. Escolha **Criar**. # Atualizar uma definição de tarefa do Amazon ECS usando o console Uma *revisão de definição de tarefa* é uma cópia da definição de tarefa atual com os novos valores de parâmetro substituindo os existentes. Todos os parâmetros que você não modificar estão na nova revisão. Para atualizar uma definição de tarefa, crie uma revisão de definição de tarefa. Se a definição de tarefa for usada em um serviço, será necessário atualizá-lo para usar a definição de tarefa atualizada. Ao criar uma revisão, você pode modificar as propriedades do contêiner e as propriedades do ambiente a seguir. + URI da imagem do contêiner + Mapeamentos de porta + Variáveis de ambiente + Requisitos de infraestrutura + Tamanho da tarefa + Tamanho do contêiner + Função do para tarefa + Função do para execução de tarefas + Pontos de montagem de volumes e contêineres + Registro privado Você pode fazer com que o Amazon Q forneça recomendações ao usar o editor JSON. Para obter mais informações, consulte . [Usar o Amazon Q Developer para fornecer recomendações de definição de tarefa no console do Amazon ECS](using-amazon-q.md) ## Validação de JSON O editor de JSON do console do Amazon ECS valida o seguinte no arquivo JSON: + O arquivo é um arquivo JSON válido + O arquivo não contém nenhuma chave estranha + O arquivo contém o parâmetro `familyName` + Há pelo menos uma entrada em `containerDefinitions` ## Procedimento ------ #### [ Amazon ECS console ] 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na barra de navegação, selecione a região que contém a definição de tarefa. 1. No painel de navegação, escolha **Task definitions** (Definições de tarefa). 1. Escolha a definição da tarefa. 1. Selecione a revisão da definição de tarefa e escolha **Criar nova revisão**, **Criar nova revisão**. 1. Na página **Create new task definition revision** (Criar nova revisão da definição de tarefa), faça as alterações. Por exemplo, para alterar as definições do contêiner existentes (como a imagem do contêiner, limites de memória ou mapeamentos de porta), selecione o contêiner e faça as alterações. Você pode atualizar a compatibilidade de definição de tarefa para uma destas opções: **AWS Fargate**, **Instâncias gerenciadas** ou **Instâncias do Amazon EC2**. 1. Verifique as informações e escolha **Criar**. 1. Se a sua definição de tarefa for usada em um serviço, atualize o serviço com a definição de tarefa atualizada. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). ------ #### [ Amazon ECS console JSON editor ] 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 revision** (Criar nova revisão), **Create new revision with JSON** (Criar nova revisão com JSON). 1. Na caixa do editor de JSON, edite o arquivo JSON. O JSON deve ser aprovado nas verificações de validação especificadas em [Validação de JSON](#json-validate-for-update). 1. Escolha **Criar**. ------ # Cancelar registro de uma revisão de definição de tarefa do Amazon ECS usando o console É possível cancelar o registro da revisão de definição de tarefa, de modo que ela não seja mais exibida nas chamadas de API `ListTaskDefinition` ou no console quando quiser executar uma tarefa ou atualizar um serviço. Quando você cancela o registro de uma revisão de definição de tarefa, ela é marcada imediatamente como `INACTIVE`. Tarefas e serviços existentes que fazem referência a uma revisão de definição de tarefa `INACTIVE` continuam a ser executados sem interrupções. Serviços existentes que fazem referência a uma revisão de definição de tarefa `INACTIVE` ainda podem aumentar ou diminuir na escala vertical modificando-se a contagem desejada do serviço. Não é possível usar uma revisão de definição de tarefa `INACTIVE` para executar novas tarefas ou criar novos serviços. Você também não pode atualizar um serviço existente para fazer referência a uma revisão de definição de tarefa `INACTIVE` (embora possa haver uma janela de até 10 minutos após o cancelamento do registro no qual essas restrições ainda não tenham entrado em vigor). **nota** Quando você cancela o registro de todas as revisões em uma família de tarefas, a família de definição de tarefa é movida para a lista `INACTIVE`. Adicionar uma nova revisão de uma definição de tarefa de `INACTIVE` fará com que a família de definição de tarefa retorne para a lista `ACTIVE`. Neste momento, as revisões de definição de tarefa `INACTIVE` permanecem detectáveis na sua conta indefinidamente. No entanto, esse comportamento está sujeito a alterações no futuro. Portanto, você não deve confiar em revisões de definição de tarefa `INACTIVE` que persistem além do ciclo de vida de quaisquer tarefas e serviços associados. ## Pilhas do CloudFormation O comportamento a seguir é aplicável às definições de tarefa criadas no novo console do Amazon ECS antes de 12 de janeiro de 2023. Ao criar uma definição de tarefa, o console do Amazon ECS cria automaticamente uma pilha do CloudFormation com um nome que começa com `ECS-Console-V2-TaskDefinition-`. Se tiver usado a AWS CLI ou um AWS SDK para cancelar o registro da definição de tarefa, você deverá excluir manualmente a pilha de definições de tarefa. Para obter mais informações, consulte [Excluir uma pilha](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) no *Guia do usuário do CloudFormation*. As definições de tarefa criadas após 12 de janeiro de 2023 não têm uma pilha do CloudFormation criada automaticamente para elas. ## Procedimento **Para cancelar o registro de uma nova definição de tarefa (console do Amazon ECS)** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na barra de navegação, selecione a região que contém a definição de tarefa. 1. No painel de navegação, escolha **Task definitions** (Definições de tarefa). 1. Na página **Task definitions** (Definições de tarefa), escolha a família de definições de tarefa que contém uma ou mais revisões cujos registros você quer cancelar. 1. Na página **Nome da definição da tarefa**, selecione as revisões a serem excluídas e escolha **Ações**, **Cancelar registro**. 1. Verifique as informações na janela **Deregister** (Cancelar registro) e escolha **Deregister** (Cancelar registro) para terminar. # Exclusão de uma revisão de definição de tarefa do Amazon ECS usando o console Quando não precisar mais de uma revisão específica da definição de tarefa no Amazon ECS, você pode excluir a revisão da definição da tarefa. Quando você exclui uma revisão de definição de tarefa, ela passa imediatamente de `INACTIVE` para `DELETE_IN_PROGRESS`. Tarefas e serviços existentes que fazem referência a uma revisão de definição de tarefa `DELETE_IN_PROGRESS` continuam a ser executados sem interrupções. Não é possível usar uma revisão de definição de tarefa `DELETE_IN_PROGRESS` para executar novas tarefas ou criar novos serviços. Também não é possível atualizar um serviço existente para fazer referência a uma revisão de definição de tarefa `DELETE_IN_PROGRESS`. Quando você exclui todas as revisões de definição da tarefa `INACTIVE`, o nome da definição da tarefa não é exibido no console e não é retornado na API. Se uma revisão de definição de tarefa estiver no estado `DELETE_IN_PROGRESS`, o nome da definição de tarefa é exibido no console e retornado na API. O nome da definição da tarefa é mantido pelo Amazon ECS e a revisão será incrementada na próxima vez que você criar uma definição de tarefa com esse nome. ## Recursos do Amazon ECS que podem bloquear uma exclusão Uma solicitação de exclusão da definição de tarefa não será concluída se houver algum recurso do Amazon ECS que dependa da revisão da definição de tarefa. Os recursos a seguir podem impedir que uma definição de tarefa seja excluída: + Tarefas autônomas do Amazon ECS: a definição da tarefa é necessária para que a tarefa permaneça íntegra. + Tarefas de serviço do Amazon ECS: a definição da tarefa é necessária para que a tarefa permaneça íntegra. + Implantações e conjuntos de tarefas do serviço do Amazon ECS: a definição da tarefa é necessária quando um evento de escalabilidade é iniciado para uma implantação ou conjunto de tarefas do Amazon ECS. Se sua definição de tarefa permanecer no estado `DELETE_IN_PROGRESS`, será possível usar o console ou a AWS CLI para identificar e interromper os recursos que bloqueiem a exclusão da definição de tarefa. ### Exclusão da definição de tarefa após a remoção do recurso bloqueado As regras a seguir se aplicam depois que você remove os recursos que bloqueiam a exclusão da definição da tarefa: + Tarefas do Amazon ECS: a exclusão da definição da tarefa pode levar até uma hora para ser concluída após a interrupção da tarefa. + Implantações e conjuntos de tarefas do serviço do Amazon ECS: a exclusão da definição da tarefa pode levar até 24 horas para ser concluída após a exclusão da implantação ou do conjunto de tarefas. ## Procedimento **Para excluir definições de tarefa (console do Amazon ECS)** É necessário cancelar o registro de uma revisão da definição de tarefa antes de excluí-la. Para obter mais informações, consulte [Cancelar registro de uma revisão de definição de tarefa do Amazon ECS usando o console](deregister-task-definition-v2.md). 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na barra de navegação, selecione a região que contém a definição de tarefa. 1. No painel de navegação, escolha **Task definitions** (Definições de tarefa). 1. Na página **Definições de tarefa**, escolha a família de definições de tarefa que contém uma ou mais revisões cujos registros você quer excluir. 1. Na página **Nome da definição de tarefa**, selecione as revisões a serem excluídas e escolha **Ações**, **Excluir**. Se a opção **Excluir** não estiver disponível, você deve cancelar o registro da definição da tarefa. 1. Verifique as informações na caixa de confirmação **Excluir** e escolha **Excluir** para finalizar. # Casos de uso de definição de tarefa do Amazon ECS 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 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 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 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 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 **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 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 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 É 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 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 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 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 <> /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 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 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 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 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 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 É 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 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 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 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 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 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 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 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 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 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 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 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 É 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 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 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 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 + 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 É 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable ``` # Exemplo de definição de tarefa do Amazon ECS: rotear logs para o FireLens 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 É 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 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 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 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 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 ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

' > /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 É 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 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 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 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 **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 **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 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 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 É 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 É 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 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 É 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 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 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: ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine") Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' ``` + 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 É 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 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 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 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: ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine") Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' ``` ## Criação do parâmetro do Systems Manager É 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 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 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 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 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 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 É 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 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 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 É 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 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 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 ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

' > /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 É 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 É 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 É 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 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)**. # Parâmetros de definição de tarefa do Amazon ECS para instâncias gerenciadas do Amazon ECS As definições de tarefa são divididas em partes distintas: a família de tarefas, o perfil de tarefa do AWS Identity and Access Management (IAM), o modo de rede, definições de contêiner, volumes e capacidade. As definições de família e de contêiner são obrigatórias em uma definição de tarefa. Por outro lado, perfil de tarefa, modo de rede, volumes e capacidade são opcionais. É possível usar esses parâmetros em um arquivo JSON para configurar sua definição de tarefa. Veja a seguir descrições mais detalhadas de cada parâmetro de definição de tarefa para instâncias gerenciadas do Amazon ECS. ## Família `family` Tipo: String Exigido: sim Ao registrar uma definição de tarefa, você dá a ela uma família, semelhante a um nome para várias versões da definição de tarefa, especificada com um número de revisão. A primeira definição de tarefa registrada em uma determinada família recebe uma revisão 1, e todas as definições de tarefa registradas depois receberão um número de revisão sequencial. ## Capacidade Ao registrar uma definição de tarefa, você pode especificar a capacidade segundo a qual o Amazon ECS deve validar a definição de tarefa. Se a definição de tarefa não for validada em relação às compatibilidades especificadas, uma exceção de cliente será retornada. Para obter mais informações, consulte [Tipos de inicialização do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html). O seguinte parâmetro é permitido em uma definição de tarefa. `requiresCompatibilities` Tipo: Matriz de strings Obrigatório: não Valores válidos: `MANAGED_INSTANCES` A capacidade segundo a qual a definição de tarefa é validada. Isso inicia uma verificação para garantir que todos os parâmetros usados na definição de tarefa atendam aos requisitos das instâncias gerenciadas do Amazon ECS. ## Função do para tarefa `taskRoleArn` Tipo: string Obrigatório: não Ao registrar uma definição de tarefa, você pode fornecer uma função de tarefa para uma função do IAM que permita que os contêineres da permissão de tarefa chame as APIs da AWS especificadas nas políticas associadas em seu nome. Para obter mais informações, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md). ## Função do para execução de tarefas `executionRoleArn` Tipo: string Obrigatório: Condicional O nome do recurso da Amazon (ARN) da função de execução de tarefas que concede ao agente de contêiner do Amazon ECS permissão para fazer chamadas de API da AWS em seu nome. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md). A função do IAM para execução da tarefa é necessária dependendo dos requisitos da sua tarefa. O perfil é necessário para extrações de imagens privadas do ECR e uso do driver de log `awslogs`. ## Modo de rede `networkMode` Tipo: string Obrigatório: não Padrão: `awsvpc` O modo de rede a ser usado para os contêineres na tarefa. Para tarefas do Amazon ECS hospedadas em instâncias gerenciadas do Amazon ECS, os valores válidos são `awsvpc` e `host`. Se nenhum modo de rede for especificado, o modo de rede padrão será `awsvpc`. Se o modo de rede for `host`, a tarefa vai ignorar o isolamento da rede e os contêineres usarão diretamente a pilha de rede do host. Ao executar tarefas que usam o modo de rede `host`, não execute contêineres usando o usuário raiz (UID 0) para melhor segurança. Como uma prática recomendada de segurança, sempre utilize um usuário não raiz. Se o modo de rede for `awsvpc`, será alocada uma interface de rede elástica para a tarefa e você deverá especificar uma `NetworkConfiguration` ao criar um serviço ou executar uma tarefa com a definição de tarefa. Para obter mais informações, consulte [Rede de tarefas do Amazon ECS para instâncias gerenciadas do Amazon ECS](managed-instance-networking.md). Os modos de rede `host` e `awsvpc` oferecem a melhor performance de rede para contêineres, pois usam a pilha de rede do Amazon EC2. Com os modos de rede `host` e `awsvpc`, as portas do contêiner expostas são mapeadas diretamente para a porta do host correspondente (para o modo de rede do `host`) ou para a porta de interface de rede elástica anexada (para o modo de rede `awsvpc`). Por causa disso, não é possível usar mapeamentos dinâmicos de portas de host. ## Plataforma de runtime `operatingSystemFamily` Tipo: string Obrigatório: não Padrão: LINUX Ao registrar uma definição de tarefa, você especifica a família do sistema operacional. O valor válido para esse campo é `LINUX`. Todas as definições de tarefa usadas em um serviço devem ter o mesmo valor para esse parâmetro. Quando uma definição de tarefa faz parte de um serviço, esse valor deve corresponder ao valor `platformFamily` do serviço. `cpuArchitecture` Tipo: string Obrigatório: Condicional Ao registrar uma definição de tarefa, você especifica a arquitetura da CPU. Os valores válidos são `X86_64` e `ARM64`. Se você não especificar um valor, o Amazon ECS tentará colocar tarefas na arquitetura de CPU disponível com base na configuração do provedor de capacidade. Para garantir que as tarefas sejam colocadas em uma arquitetura de CPU específica, informe um valor para `cpuArchitecture` na definição de tarefa. Todas as definições de tarefa usadas em um serviço devem ter o mesmo valor para esse parâmetro. Para obter mais informações sobre o `ARM64`, consulte [Definições de tarefa do Amazon ECS para workloads do ARM de 64 bits](ecs-arm64.md). ## Tamanho da tarefa Ao registrar uma definição de tarefa, você pode especificar o total de CPU e memória usados para a tarefa. Isso é separado dos valores de `cpu` e `memory` no nível de definição de contêiner. Para tarefas hospedadas em instâncias do Amazon EC2, esses campos são opcionais. **nota** Os parâmetros de CPU e memória em nível de tarefa são ignorados para contêineres do Windows. É recomendável especificar recursos em nível de contêiner para contêineres do Windows. `cpu` Tipo: string Obrigatório: Condicional O limite rígido de unidades de CPU a ser apresentado para a tarefa. 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. Quando a definição de tarefa for registrada, um valor de vCPU será convertido em um inteiro indicando as unidades de CPU. Esse campo é opcional. Se o seu cluster não tiver registrado instâncias de contêiner com as unidades de CPU solicitadas disponíveis, ocorrerá uma falha na tarefa. Os valores compatível são de `0.125` vCPUs a `10` vCPUs. `memory` Tipo: string Obrigatório: Condicional O limite fixo de memória a ser apresentada para a tarefa. É possível especificar valores de memória na definição de tarefa como uma string em mebibytes (MiB) ou gigabytes (GB). Por exemplo, você pode especificar um valor de memória como `3072` em MiB ou `3 GB` em GB. Quando a definição de tarefa for registrada, um valor em GB será convertido em um inteiro indicando o MiB. Esse campo é opcional e qualquer valor pode ser usado. Se um valor de memória no nível de tarefa for especificado, o valor de memória no nível de contêiner será opcional. Se o seu cluster não tiver registrado instâncias de contêiner com a memória solicitada disponível, ocorrerá uma falha na tarefa. É possível maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância. Para obter mais informações, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). ## Outros parâmetros de definição de tarefa Os parâmetros de definição de tarefa a seguir podem ser usados durante o registro das definições de tarefa no console do Amazon ECS usando a opção **Configure via JSON** (Configurar via JSON). Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). **Topics** + [ ### Armazenamento temporário ](#task_definition_ephemeralStorage-managed-instances) + [ ### Modo IPC ](#task_definition_ipcmode-managed-instances) + [ ### Modo PID ](#task_definition_pidmode-managed-instances) + [ ### Configuração do proxy ](#proxyConfiguration-managed-instances) + [ ### Tags ](#tags-managed-instances) + [ ### Acelerador do Elastic Inference (obsoleto) ](#elastic-Inference-accelerator-managed-instances) + [ ### Limitações de posicionamento ](#constraints-managed-instances) + [ ### Volumes ](#volumes-managed-instances) ### Armazenamento temporário `ephemeralStorage` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: objeto [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Obrigatório: não A quantidade de armazenamento temporário (em GB) a ser alocado para a tarefa. Esse parâmetro é usado para expandir a quantidade total de armazenamento temporário, além da quantidade padrão, para tarefas hospedadas no AWS Fargate. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md). ### Modo IPC `ipcMode` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: string Obrigatório: não O namespace de recurso IPC a ser usado para os contêineres na tarefa. Os valores válidos são `host`, `task` ou `none`. Se o `host` for especificado, todos os contêineres dentro das tarefas que especificaram o modo IPC `host` na mesma instância de contêiner compartilham os mesmos recursos IPC com a instância do Amazon EC2 do host. Se `task` for especificado, todos os contêineres dentro da tarefa especificada compartilharão os mesmos recursos IPC. Se `none` for especificado, os recursos IPC nos contêineres de uma tarefa serão privados e não serão compartilhados com outros contêineres em uma tarefa ou na instância de contêiner. Se nenhum valor for especificado, o compartilhamento do namespace de recurso IPC dependerá da configuração de runtime do contêiner. ### Modo PID `pidMode` Tipo: string Obrigatório: não O namespace do processo a ser usado para os contêineres na tarefa. Os valores válidos são `host` ou `task`. Se `host` for especificado, todos os contêineres que estiverem nas tarefas que especificaram o modo PID `host` na mesma instância de contêiner compartilharão o mesmo namespace de processo com a instância host do Amazon EC2. Se `task` for especificado, todos os contêineres que estiverem na tarefa especificada compartilharão o mesmo namespace de processo. Se nenhum valor for especificado, o padrão será um namespace privado. Se o modo PID `host` for usado, haverá um risco elevado de exposição indesejada do namespace de processo. ### Configuração do proxy `proxyConfiguration` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: objeto [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obrigatório: não Os detalhes de configuração do proxy do App Mesh. ### Tags Os metadados que você aplica a uma definição de tarefa para ajudar a categorizá-los e organizá-los. Cada tag consiste em uma chave e um valor opcional. Defina ambos. As restrições básicas a seguir se aplicam às tags. + Número máximo de tags por recurso: 50 + Em todos os recursos, cada chave de tag deve ser exclusiva e possuir apenas um valor. + Comprimento máximo da chave: 128 caracteres Unicode em UTF-8 + Comprimento máximo do valor: 256 caracteres Unicode em UTF-8 + Se seu esquema de tags é usado em vários serviços e recursos, lembre-se de que outros serviços podem ter restrições nos caracteres permitidos. Em geral, os caracteres permitidos são: letras, números e espaços representáveis em UTF-8 e os seguintes caracteres: \$1 - = . \$1 : / @. + As chaves e os valores de tags diferenciam maiúsculas de minúsculas. + Não use `aws:`, `AWS:` nem qualquer combinação de letras maiúsculas e minúsculas deles como um prefixo para chaves ou valores, pois são reservados para uso pela AWS. Você não pode editar nem excluir chaves nem valores de tag com esse prefixo. As tags com esse prefixo não contam para as tags por limite de recurso. `key` Tipo: string Obrigatório: não Uma parte de um par de chave/valor que compõe uma tag. Uma chave é um rótulo geral que age como uma categoria para valores de tag mais específicos. `value` Tipo: string Obrigatório: não A parte opcional de um par de chave/valor que compõe uma tag. Um valor atua como um descritor dentro de uma categoria de tag (chave). ### Acelerador do Elastic Inference (obsoleto) **nota** O Amazon Elastic Inference (EI) não está mais disponível para clientes. `inferenceAccelerator` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: objeto [InferenceAccelerator](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_InferenceAccelerator.html) Obrigatório: não As aceleradoras do Elastic Inference que devem ser usadas para os contêineres na tarefa. ### Limitações de posicionamento `placementConstraints` Tipo: matriz de objetos [TaskDefinitionPlacementConstraint](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskDefinitionPlacementConstraint.html) Obrigatório: não Uma matriz de objetos de restrição de posicionamento para uso na tarefa. É possível especificar um máximo de dez restrições por tarefa (esse limite inclui restrições na definição da tarefa e as especificadas no runtime). O Amazon ECS aceita as restrições de posicionamento `distinctInstace` e `memberOf` para tarefas executadas nas instâncias gerenciadas do Amazon ECS. Os atributos a seguir são compatíveis com tarefas que usam a restrição de posicionamento `memberOf`: + `ecs.subnet-id` + `ecs.availability-zone` + `ecs.cpu-architecture` + `ecs.instance-type` Para obter mais informações sobre restrições de posicionamento, consulte [Definição de quais instâncias de contêiner o Amazon ECS usa em tarefas](task-placement-constraints.md). ### Volumes Quando você registra uma definição de tarefa, tem a opção de especificar uma lista de volumes para as tarefas. Isso permite que você use volumes de dados em suas tarefas. Para obter mais informações sobre tipos de volume e outros parâmetros, consulte [Opções de armazenamento para tarefas do Amazon ECS](using_data_volumes.md). `name` Tipo: String Exigido: sim O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números e hifens. Este nome é referenciado no parâmetro `sourceVolume` da definição de contêiner `mountPoints`. `host` Tipo: objeto [HostVolumeProperties](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HostVolumeProperties.html) Obrigatório: não Esse parâmetro é especificado quando você está usando volumes do host de montagem bind. O conteúdo do parâmetro `host` determina se o volume de dados da montagem de host persiste na instância de contêiner host e onde é armazenado. Se o parâmetro `host` estiver vazio, o sistema atribuirá um caminho de host para o volume de dados. No entanto, não há garantia de que os dados persistirão depois que os contêineres associados a eles deixarem de ser executados. `sourcePath` Tipo: string Obrigatório: não Quando o parâmetro `host` é usado, especifique um `sourcePath` para declarar o caminho na instância host que é apresentada ao contêiner. Se este parâmetro estiver vazio, o sistema atribuirá um caminho de host para você. Caso o parâmetro `host` contenha um local de arquivo `sourcePath`, o volume de dados persiste no local especificado na instância host até você excluí-lo manualmente. Se o valor `sourcePath` não existir na instância do host, o sistema o cria. Caso o local exista, o conteúdo da pasta do caminho de origem é exportado. Nas instâncias gerenciadas do Amazon ECS, partes do sistema de arquivos do host são somente de leitura. `sourcePath`Deve apontar para um diretório gravável, como `/var` ou `/tmp`. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md). `dockerVolumeConfiguration` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: objeto [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado quando você está usando volumes do Docker. `efsVolumeConfiguration` Tipo: objeto [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado quando você está usando um sistema de arquivos Amazon EFS para armazenamento de tarefas. `fsxWindowsFileServerVolumeConfiguration` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: objeto [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado quando você está usando o sistema de arquivos Amazon FSx para Windows File Server para armazenamento de tarefas. `configuredAtLaunch` Tipo: booliano Obrigatório: não Especifica se o volume deve ser configurado no momento da inicialização. Isso é usado para criar volumes do Amazon EBS para tarefas autônomas ou tarefas criadas como parte de um serviço. Cada revisão da definição de tarefa pode ter somente um volume configurado na inicialização na configuração do volume. ## Definições de contêiner Ao registrar uma definição de tarefa, você deve especificar uma lista de definições de contêiner passadas para o daemon do Docker em uma instância de contêiner. Os parâmetros a seguir são permitidos em uma definição de contêiner. **Topics** + [ ### Nome ](#container_definition_name-managed-instances) + [ ### Imagem ](#container_definition_image-managed-instances) + [ ### Memória ](#container_definition_memory-managed-instances) + [ ### CPU ](#container_definition_cpu-managed-instances) + [ ### Mapeamentos de porta ](#container_definition_portmappings-managed-instances) + [ ### Credenciais de repositório privado ](#container_definition_repositoryCredentials-managed-instances) + [ ### Essential ](#container_definition_essential-managed-instances) + [ ### Ponto de entrada ](#container_definition_entrypoint-managed-instances) + [ ### Command ](#container_definition_command-managed-instances) + [ ### Diretório de trabalho ](#container_definition_workingdirectory-managed-instances) + [ ### Parâmetros avançados de definição de contêiner ](#advanced_container_definition_params-managed-instances) + [ ### Parâmetros do Linux ](#container_definition_linuxparameters-managed-instances) ### Nome `name` Tipo: String Exigido: sim O nome de um contêiner. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Se estiver vinculando vários contêineres em uma definição de tarefa, o `name` de um contêiner poderá ser informado no `links` de outro contêiner. Isso deve ser feito para conectar os contêineres. ### Imagem `image` Tipo: String Exigido: sim A imagem usada para iniciar um contêiner. Essa string é passada diretamente para o daemon do Docker. Por padrão, as imagens no registro do Docker Hub estão disponíveis. Você também pode especificar outros repositórios com `repository-url/image:tag` ou `repository-url/image@digest`. São permitidos até 255 letras (caixa alta e baixa), números, hifens, sublinhados, dois pontos, ponto, barras e sinais numéricos. Esse parâmetro é mapeado para `Image` no comando create-container do docker e no parâmetro `IMAGE` do comando run do docker. + Quando uma nova tarefa é iniciada, o agente do contêiner do Amazon ECS obtém a versão mais recente da imagem especificada e a tag do contêiner a ser usado. No entanto, as atualizações subsequentes feitas em um repositório de imagens não são propagadas para tarefas já em execução. + Quando não é especificada uma tag ou um resumo no caminho da imagem na definição da tarefa, o agente de contêiner do Amazon ECS usa a tag `latest` para extrair a imagem especificada. + As atualizações subsequentes para um repositório de imagens não são propagadas para tarefas já em execução. + As imagens em registros privados são suportadas. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). + As imagens nos repositórios do Amazon ECR podem ser especificadas usando a convenção de nomenclatura completa `registry/repository:tag` ou `registry/repository@digest` (por exemplo, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` ou `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + As imagens em repositórios oficiais no Docker Hub usam um único nome (por exemplo, `ubuntu` ou `mongo`). + Imagens em outros repositórios Docker Hub são qualificadas com um nome de organização (por exemplo, `amazon/amazon-ecs-agent`). + Imagens em outros repositórios online também são qualificadas por um nome de domínio (por exemplo, `quay.io/assemblyline/ubuntu`). `versionConsistency` Tipo: string Valores válidos: `enabled`\$1`disabled` Obrigatório: não Especifica se o Amazon ECS resolverá a tag de imagem do contêiner fornecida na definição do contêiner em um resumo de imagem. Por padrão, esse comportamento é `enabled`. Se você definir o valor de um contêiner como `disabled`, o Amazon ECS não resolverá a tag da imagem do contêiner como um resumo e usará o URI da imagem original especificado na definição do contêiner para implantação. Para obter mais informações sobre resolução de imagem do contêiner, consulte [Resolução da imagem do contêiner](deployment-type-ecs.md#deployment-container-image-stability). ### Memória `memory` Tipo: inteiro Obrigatório: não A quantidade (em MiB) de memória a ser apresentada ao contêiner. Caso tente exceder a memória especificada aqui, o contêiner será excluído. A quantidade total de memória reservada para todos os contêineres dentro da tarefa deve ser menor que o valor da tarefa `memory`, se estiver especificado. Esse parâmetro é mapeado para `Memory` no comando create-container do docker na opção `--memory` de execução do docker. O daemon para Docker 20.10.0 ou versão posterior reserva no mínimo 6 MiB de memória para um contêiner. Por isso, não especifique menos de 6 MiB de memória para os seus contêineres. O daemon para Docker 19.03.13-ce ou versão anterior reserva no mínimo 4 MiB de memória para um contêiner. Por isso, não especifique menos de 4 MiB de memória para os seus contêineres. Se você deseja maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). `memoryReservation` Tipo: inteiro Obrigatório: não O limite flexível (em MiB) de memória a ser reservado para o contêiner. Quando a memória do sistema estiver em contenção, o Docker tentará manter a memória do contêiner dentro desse limite flexível. Entrentanto, seu contêiner pode usar mais memória quando necessário. O contêiner pode consumir até o limite rígido especificado pelo parâmetro `memory` (se aplicável), ou toda a memória disponível na instância de contêiner, o que ocorrer primeiro. Esse parâmetro é mapeado para `MemoryReservation` no comando create-container do docker na opção `--memory-reservation` de execução do docker. Se um valor de memória no nível de tarefa não for especificado, será necessário especificar um número inteiro diferente de zero para um ou ambos `memory` ou `memoryReservation` em uma definição de contêiner. Caso você especifique ambos, `memory` deve ser maior que `memoryReservation`. Caso você especifique `memoryReservation`, o valor é subtraído dos recursos de memória disponíveis para a instância de contêiner na qual o contêiner está colocado. Caso contrário, o valor de `memory` é usado. Por exemplo, suponha que seu contêiner normalmente use 128 MiB de memória, mas às vezes chegue a 256 MiB de memória por períodos curtos. É possível definir um `memoryReservation` de 128 MiB e um limite rígido de `memory` de 300 MiB. Essa configuração permite que contêiner reservasse apenas 128 MiB de memória dos recursos restantes na instância de contêiner. Ao mesmo tempo, essa configuração também possibilita que o contêiner utilize mais recursos de memória quando necessário. O daemon para Docker 20.10.0 ou versão posterior reserva no mínimo 6 MiB de memória para um contêiner. Por isso, não especifique menos de 6 MiB de memória para os seus contêineres. O daemon para Docker 19.03.13-ce ou versão anterior reserva no mínimo 4 MiB de memória para um contêiner. Por isso, não especifique menos de 4 MiB de memória para os seus contêineres. Se você deseja maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). ### CPU `cpu` Tipo: inteiro Obrigatório: não O número de unidades `cpu` reservadas para o contêiner. Esse parâmetro é mapeado para `CpuShares` no comando create-container do docker na opção `--cpu-shares` de execução do docker. Esse campo é opcional para tarefas que usam provedores de capacidade do EC2 e a única exigência é que a quantidade total de CPU reservada para todos os contêineres dentro de uma tarefa seja inferior ao valor `cpu` no nível da tarefa. Você pode determinar o número de unidades de CPU disponíveis por tipo de instância do EC2 multiplicando as vCPUs listadas para esse tipo de instância na página de detalhes [Instâncias do Amazon EC2](https://aws.amazon.com/ec2/instance-types/) por 1.024. Os contêineres do Linux compartilham unidades de CPU não alocadas com outros contêineres na instância de contêiner que tem a mesma proporção que a respectiva quantidade alocada. Por exemplo, caso você execute uma tarefa de contêiner único em um tipo de instância de núcleo único com 512 unidades de CPU especificadas para esse contêiner e essa seja a única tarefa em execução na instância de contêiner, esse contêiner poderá usar as 1.024 unidades de CPU integrais a qualquer momento. No entanto, se você executou outra cópia da mesma tarefa nessa instância de contêiner, cada tarefa terá garantido um mínimo de 512 unidades de CPU quando necessário. Além disso, cada contêiner poderá flutuar para o uso maior da CPU, se o outro contêiner não o estiver usando. Se ambas as tarefas estiverem 100% ativas o tempo todo, elas ficarão limitadas a 512 unidades de CPU. Nas instâncias de contêiner do Linux, o daemon do Docker na instância de contêiner usa o valor de CPU para calcular as proporções de compartilhamento de CPU para contêineres em execução. Para obter mais informações, consulte [CPU share constraint](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) na documentação do Docker. O valor mínimo válido de compartilhamento da CPU permitido pelo kernel do Linux é 2. No entanto, o parâmetro de CPU não é necessário, e é possível usar valores de CPU abaixo de dois em suas definições de contêiner. Para valores de CPU abaixo de 2 (inclusive nulo), o comportamento varia com base na versão do agente de contêiner do Amazon ECS: + **Versões de agente inferiores ou iguais a 1.1.0:** os valores de CPU nulo e zero são passados para o Docker como 0, que o Docker acaba convertendo em 1.024 compartilhamentos de CPU. Os valores de CPU de 1 são passados para o Docker como 1, que o kernel do Linux converte para dois compartilhamentos de CPU. + **Versões de agente inferiores ou iguais a 1.2.0:** os valores nulo, zero e de CPU de 1 são passados para o Docker como 2. Nas instâncias de contêiner do Windows, o limite de CPU é imposto como um limite absoluto ou uma cota. Os contêineres do Windows só têm acesso à quantidade de CPU descrita na definição da tarefa. Um valor de CPU nulo ou zero é transmitido para o Docker como `0`, que o Windows interpreta como 1% de uma CPU. ### Mapeamentos de porta `portMappings` Tipo: Matriz de objeto Obrigatório: não Os mapeamentos de portas expõem as portas de rede do seu contêiner ao mundo externo. Isso permite que os clientes acessem sua aplicação. Também é usado para comunicação entre contêineres dentro da mesma tarefa. Para definições de tarefa que usam o modo de rede `awsvpc`, apenas especifique `containerPort`. A `hostPort` é sempre ignorada e a porta do contêiner é automaticamente mapeada para uma porta aleatória de alto número no host. A maioria dos campos desse parâmetro (incluindo `containerPort`, `hostPort`, `protocol`) é mapeada para `PortBindings` no comando create-container do docker e a opção `--publish` de execução do docker. Caso o modo de rede de uma definição de tarefa seja definido como `host`, as portas host devem ser indefinidas ou corresponder à porta de contêiner no mapeamento de porta. Quando a tarefa obter o status `RUNNING`, as atribuições automáticas e manuais da porta do contêiner e do host estarão visíveis nos seguintes locais: + Console: a seção **Network Bindings** (Associações de rede) de uma descrição de contêiner para uma tarefa selecionada. + AWS CLI: a seção `networkBindings` do resultado do comando **describe-tasks**. + API: a resposta `DescribeTasks`. + Metadados: o endpoint de metadados da tarefa. `appProtocol` Tipo: string Obrigatório: não O protocolo da aplicação usado no mapeamento da porta. Esse parâmetro só se aplica ao Service Connect. Recomendamos que você defina esse parâmetro para que seja consistente com o protocolo usado por sua aplicação. Se você definir esse parâmetro, o Amazon ECS adicionará o tratamento de conexão específico do protocolo ao proxy do Service Connect. Se você definir esse parâmetro, o Amazon ECS adicionará telemetria específica de protocolo no console do Amazon ECS e no CloudWatch. Se você não definir um valor para esse parâmetro, o TCP será usado. No entanto, o Amazon ECS não adiciona telemetria específica de protocolo para TCP. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). Valores de protocolo válidos: `"HTTP" | "HTTP2" | "GRPC" ` `containerPort` Tipo: inteiro Exigido: Sim, quando `portMappings` são usados O número da porta no contêiner vinculado à porta host atribuída automaticamente ou especificada pelo usuário. Para as tarefas que usam o modo de rede `awsvpc`, você usa `containerPort` para especificar as portas expostas. `containerPortRange` Tipo: string Obrigatório: não O intervalo de números de porta no contêiner vinculado ao intervalo de portas host mapeado dinamicamente. Você só pode definir esse parâmetro usando a API `register-task-definition`. A opção está disponível no parâmetro `portMappings`. Para obter mais informações, consulte [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html), na *Referência da AWS Command Line Interface*. As regras a seguir se aplicam quando você especifica um `containerPortRange`: + Você deve usar o modo de rede `awsvpc`. + A instância de contêiner deve ter pelo menos a versão 1.67.0 do agente do contêiner e pelo menos a versão 1.67.0-1 do pacote `ecs-init` + É possível especificar no máximo 100 intervalos de portas para cada contêiner. + Você não especifica um `hostPortRange`. O valor do `hostPortRange` é definido da seguinte forma: + Para contêineres em uma tarefa com o modo de rede `awsvpc`, o `hostPort` é definido com o mesmo valor que `containerPort`. Essa é uma estratégia de mapeamento estático. + Os valores válidos de `containerPortRange` estão entre 1 e 65535. + Uma porta só pode ser incluída em um mapeamento de portas para cada contêiner. + Não é possível especificar intervalos de portas sobrepostos. + A primeira porta no intervalo deve ser menor que a última porta no intervalo. + O Docker recomenda que você desative o docker-proxy no arquivo de configuração do daemon do Docker quando tiver um grande número de portas. Para obter mais informações, consulte [Issue \$111185](https://github.com/moby/moby/issues/11185) no GitHub. Para obter informações sobre como desativar o docker-proxy no arquivo de configuração do daemon do Docker, consulte [Daemon do Docker](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) no *Guia do desenvolvedor do Amazon ECS*. É possível chamar [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) para visualizar o `hostPortRange`, que são as portas do host vinculadas às portas do contêiner. Os intervalos de portas não estão incluídos nos eventos de tarefas do Amazon ECS que são enviados ao EventBridge. Para obter mais informações, consulte [Automatização de respostas a erros do Amazon ECS usando o EventBridge](cloudwatch_event_stream.md). `hostPortRange` Tipo: Sequência Obrigatório: não O intervalo de números de portas no host que é usado com a vinculação de rede. Isso é atribuído pelo Docker e fornecido pelo agente do Amazon ECS. `hostPort` Tipo: inteiro Obrigatório: não O número da porta na instância de contêiner a ser reservado para o contêiner. A `hostPort` pode ser deixada em branco ou ter um valor igual a `containerPort`. O intervalo de portas temporárias padrão para a versão 1.6.0 e posterior do Docker é listado na instância em `/proc/sys/net/ipv4/ip_local_port_range`. Se esse parâmetro do kernel não estiver disponível, será usado o intervalo de portas temporárias padrão de `49153–65535`. Não tente especificar uma porta de host no intervalo de portas transitório. Isso ocorre porque essas portas são reservadas para atribuição automática. Em geral, as portas abaixo de `32768` estão fora do intervalo de portas temporárias. As portas reservadas padrão são `22` para SSH, as portas do Docker `2375` e`2376` e as portas do agente de contêiner do Amazon ECS `51678-51680`. Qualquer porta de host que tenha sido especificada pelo usuário anteriormente para uma tarefa em execução também é reservada enquanto a tarefa está em execução. Depois que uma tarefa é interrompida, a porta do host é liberada. As portas reservadas atuais são exibidas nos `remainingResources` de **describe-container-instances** de saída. Uma instância de contêiner pode ter até 100 portas reservadas por vez, incluindo as portas reservadas padrão. As portas atribuídas automaticamente não contam em relação à cota de 100 portas reservadas. `name` Tipo: string Obrigatório: não, obrigatório para que o Service Connect e o VPC Lattice sejam configurados em um serviço Nome que é usado para o mapeamento da porta. Esse parâmetro só se aplica ao Service Connect e ao VPC Lattice. Esse parâmetro é o nome que você usa na configuração do Service Connect e do VPC Lattice de um serviço. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). No exemplo a seguir, ambos os campos obrigatórios para o Service Connect e o VPC Lattice são usados. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Tipo: string Obrigatório: não O protocolo usado no mapeamento da porta. Os valores válidos são `tcp` e `udp`. O padrão é `tcp`. Só `tcp` é compatível com o Service Connect. Lembre-se de que `tcp` estará implícito se esse campo não estiver definido. Caso você esteja especificando uma porta host, use a seguinte sintaxe: ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Caso você queira uma porta host atribuída automaticamente, use a seguinte sintaxe: ``` "portMappings": [ { "containerPort": integer } ... ] ``` ### Credenciais de repositório privado `repositoryCredentials` Tipo: objeto [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obrigatório: não As credenciais do repositório para autenticação de registro privado. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). `credentialsParameter` Tipo: string Exigido: Sim, quando `repositoryCredentials` são usados O nome de recurso da Amazon (ARN) do segredo que contém as credenciais do repositório privado. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). Quando você usa a API do Amazon ECS, a AWS CLI ou os AWS SDKs, se o segredo existir na mesma região da tarefa que estiver sendo executada, será possível usar o ARN completo ou o nome do segredo. Ao usar o Console de gerenciamento da AWS, é preciso especificar o ARN completo do segredo. Veja a seguir um trecho de uma definição de tarefa que mostra os parâmetros necessários. ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Essential `essential` Tipo: booliano Obrigatório: não Caso o parâmetro `essential` de um contêiner esteja marcado como `true` e esse contêiner falhe ou pare por algum motivo, todos os outros contêineres que fazem parte da tarefa são parados. Caso o parâmetro `essential` de um contêiner esteja marcado como `false`, a falha não afetará o restante dos contêineres em uma tarefa. Caso esse parâmetro seja omitido, um contêiner pressupõe-se que um contêiner seja essencial. Todas as tarefas devem ter pelo menos um contêiner essencial. Caso tenha um aplicativo composto de vários contêineres, agrupe contêineres usados com uma finalidade em comum em componentes e separar os componentes diferentes em várias definições de tarefa. Para obter mais informações, consulte [Projetar sua aplicação para o Amazon ECS](application_architecture.md). ### Ponto de entrada `entryPoint` Tipo: Matriz de strings Obrigatório: não O ponto de entrada passado para o contêiner. Esse parâmetro é mapeado para `Entrypoint` no comando create-container do docker na opção `--entrypoint` de execução do docker. ``` "entryPoint": ["string", ...] ``` ### Command `command` Tipo: Matriz de strings Obrigatório: não O comando que é passado para o contêiner. Esse parâmetro é mapeado para `Cmd` no comando create-container do docker e o parâmetro `COMMAND` para execução do docker. Se houver vários argumentos, cada um será uma string separada na matriz. ``` "command": ["string", ...] ``` ### Diretório de trabalho `workingDirectory` Tipo: string Obrigatório: não O diretório de trabalho no qual executar comandos no contêiner. Esse parâmetro é mapeado para `WorkingDir` no comando create-container do docker na opção `--workdir` de execução do docker. ### Parâmetros avançados de definição de contêiner Os parâmetros avançados de definição de contêiner a seguir fornecem recursos estendidos ao comando run do docker usado para iniciar contêineres nas instâncias de contêiner do Amazon ECS. **Topics** + [ #### Política de reinicialização ](#container_definition_restart_policy-managed-instances) + [ #### Verificação de integridade ](#container_definition_healthcheck-managed-instances) + [ #### Environment ](#container_definition_environment-managed-instances) + [ #### Segurança ](#container_definition_security-managed-instances) + [ #### Configurações de rede ](#container_definition_network-managed-instances) + [ #### Armazenamento e registro ](#container_definition_storage-managed-instances) + [ #### Requisitos de recursos ](#container_definition_resourcerequirements-managed-instances) + [ #### Tempos limite de contêiner ](#container_definition_timeout-managed-instances) + [ #### Dependência de contêiner ](#container_definition_dependency-managed-instances) + [ #### Controles do sistema ](#container_definition_systemcontrols-managed-instances) + [ #### Interativo ](#container_definition_interactive-managed-instances) + [ #### Pseudoterminal ](#container_definition_pseudoterminal-managed-instances) #### Política de reinicialização `restartPolicy` A política de reinicialização do contêiner e os parâmetros de configuração associados. Quando você configura uma política de reinicialização para um contêiner, o Amazon ECS pode reiniciar o contêiner sem precisar substituir a tarefa. Para obter mais informações, consulte [Reiniciar contêineres individuais em tarefas do Amazon ECS com políticas de reinicialização de contêineres](container-restart-policy.md). `enabled` Tipo: booliano Obrigatório: Sim Especifica se uma política de reinicialização está habilitada para o contêiner. `ignoredExitCodes` Tipo: matriz de inteiros Obrigatório: não Uma lista de códigos de saída que o Amazon ECS ignorará e não tentará reiniciar. Você pode especificar um máximo de 50 códigos de saída de contêiner. Por padrão, o Amazon ECS não ignora nenhum código de saída. `restartAttemptPeriod` Tipo: inteiro Obrigatório: não A quantidade de tempo (em segundos) que o contêiner deve ser executado antes de uma tentativa de reinicialização. Um contêiner só pode ser reiniciado uma vez a cada `restartAttemptPeriod` segundos. Se um contêiner não puder ser executado nesse período e sair mais cedo, ele não será reiniciado. Você pode especificar um `restartAttemptPeriod` mínimo de 60 segundos e um `restartAttemptPeriod` máximo de 1800 segundos. Por padrão, um contêiner deve ser executado por 300 segundos antes de ser reiniciado. #### Verificação de integridade `healthCheck` O comando da verificação de integridade de contêiner e os parâmetros de configuração associados para o contêiner. Para obter mais informações, consulte [Como determinar a integridade das tarefas do Amazon ECS usando verificações de integridade de contêineres](healthcheck.md). `command` Uma matriz de strings que representa o comando executado pelo contêiner para determinar se ela está íntegra. A matriz de strings pode começar com `CMD` para executar os argumentos de comando diretamente ou `CMD-SHELL` para executar o comando com o shell padrão do contêiner. Se nenhuma for especificado, `CMD` será usada. Ao registrar uma definição de tarefa no Console de gerenciamento da AWS, use uma lista de comandos separados por vírgulas. Esses comandos serão convertidos em uma string após a criação da definição de tarefa. Veja a seguir um exemplo de entrada para uma verificação de integridade. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Ao registrar uma definição de tarefa usando o painel JSON do Console de gerenciamento da AWS, a AWS CLI ou as APIs, delimite a lista de comandos por colchetes. Veja a seguir um exemplo de entrada para uma verificação de integridade. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Um código de saída 0, sem saída de `stderr`, indica sucesso, e um código de saída diferente de zero indica falha. `interval` O período em segundos entre cada verificação de integridade. É possível especificar entre 5 e 300 segundos. O valor padrão de é 30 segundos. `timeout` O período de espera (em segundos) para que uma verificação de integridade seja bem-sucedida antes de ser considerada uma falha. É possível especificar entre 2 e 60 segundos. O valor de padrão é 5 segundos. `retries` O número de novas tentativas de uma verificação de integridade com falha até o contêiner ser considerado não íntegro. É possível especificar entre 1 e 10 novas tentativas. O valor padrão é três novas tentativas. `startPeriod` O período de carência opcional para que os contêineres possam inicializar antes de as verificações de integridade com falha serem contabilizadas no número máximo de novas tentativas. Você pode especificar um valor entre 0 e 300 segundos. Por padrão, o `startPeriod` está desabilitado. Se uma verificação de integridade for bem-sucedida dentro do `startPeriod`, então o contêiner é considerado saudável e quaisquer falhas subsequentes contam para o número máximo de novas tentativas. #### Environment `cpu` Tipo: inteiro Obrigatório: não O número de unidades de `cpu` que o agente de contêiner do Amazon ECS reservará para o contêiner. No Linux, esse parâmetro é mapeado como `CpuShares` na seção [Criar um contêiner](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Esse campo é opcional para tarefas executadas em instâncias gerenciadas do Amazon ECS. A quantidade total de CPU reservada para todos os contêineres dentro da tarefa deve ser menor que o valor `cpu` de nível da tarefa. Os contêineres de Linux compartilham unidades de CPU não alocadas com outros contêineres na instância de contêiner que tem a mesma proporção que a respectiva quantidade alocada. Por exemplo, suponha que você execute uma tarefa de contêiner único em um tipo de instância de núcleo único com 512 unidades de CPU especificadas para esse contêiner. Além disso, essa tarefa é a única em execução na instância de contêiner. Nesse exemplo, o contêiner pode utilizar o compartilhamento total de 1.024 unidades de CPU a qualquer momento. Porém, suponha que você tenha iniciado outra cópia da mesma tarefa nessa instância de contêiner. Cada tarefa tem garantido um mínimo de 512 unidades de CPU quando necessário. Da mesma forma, se o outro contêiner não estiver usando a CPU restante, cada contêiner poderá flutuar para o uso maior da CPU. Porém, se ambas as tarefas estiverem 100% ativas o tempo todo, elas ficarão limitadas a 512 unidades de CPU. Nas instâncias de contêiner de Linux, o daemon do Docker na instância de contêiner usa o valor de CPU para calcular as proporções de compartilhamento de CPU para contêineres em execução. O valor de compartilhamento de CPU mínimo válido permitido pelo kernel do Linux é 2 e o valor de compartilhamento de CPU máximo válido permitido pelo kernel do Linux é 262144. No entanto, o parâmetro de CPU não é necessário, e é possível usar valores de CPU abaixo de dois e superior a 262144 em suas definições de contêiner. Para valores de CPU abaixo de dois (inclusive nulo) e acima de 262144, o comportamento varia com base na versão do agente de contêiner do Amazon ECS: Para obter exemplos adicionais, consulte [Como o Amazon ECS gerencia recursos de CPU e memória](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obrigatório: não O número de `GPUs` físicas que o agente de contêiner do Amazon ECS reservará para o contêiner. 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 [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md). `Elastic Inference accelerator` Esse parâmetro não é compatível com contêineres hospedados em instâncias gerenciadas do Amazon ECS. Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obrigatório: não Para o tipo `InferenceAccelerator`, o `value` corresponde ao `deviceName` para um `InferenceAccelerator` especificado em uma definição de tarefa. Para obter mais informações, consulte [Nome do acelerador do Elastic Inference (obsoleto)](task_definition_parameters.md#elastic-Inference-accelerator). `essential` Tipo: booliano Obrigatório: não Suponha que o parâmetro `essential` de um contêiner esteja marcado como `true`, e que esse contêiner falhe ou seja interrompido por algum motivo. Em seguida, todos os outros contêineres que fazem parte da tarefa são interrompidos. Caso o parâmetro `essential` de um contêiner esteja marcado como `false`, a falha não afeta o restante dos contêineres em uma tarefa. Caso esse parâmetro seja omitido, um contêiner pressupõe-se que um contêiner seja essencial. Todas as tarefas devem ter pelo menos um contêiner essencial. Suponha que você tenha uma aplicação composta por vários contêineres. Em seguida, agrupe os contêineres usados para uma finalidade em comum em componentes e separe os componentes diferentes em várias definições de tarefa. Para obter mais informações, consulte [Projetar sua aplicação para o Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` As versões anteriores do agente de contêiner do Amazon ECS não lidam corretamente com parâmetros `entryPoint`. Caso você enfrente problemas para usar `entryPoint`, atualize o agente de contêiner ou informe os comandos e os argumentos como itens de matriz `command` em vez disso. Tipo: Matriz de strings Obrigatório: não O ponto de entrada passado para o contêiner. ``` "entryPoint": ["string", ...] ``` `command` Tipo: Matriz de strings Obrigatório: não O comando que é passado para o contêiner. Esse parâmetro é mapeado para `Cmd` no comando create-container e o parâmetro `COMMAND` de execução do docker. Se houver vários argumentos, certifique-se de que cada um seja uma string separada na matriz. ``` "command": ["string", ...] ``` `workingDirectory` Tipo: string Obrigatório: não O diretório de trabalho no qual executar comandos no contêiner. Esse parâmetro é mapeado para `WorkingDir` na seção [Criar um contêiner](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) da [Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) e a opção `--workdir` para [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Tipo: Matriz de objeto Obrigatório: não Uma lista de arquivos que contêm as variáveis de ambiente a serem passadas para um contêiner. Esse parâmetro é mapeado para a opção `--env-file` para o comando run do docker. É possível especificar até 10 arquivos de ambiente. O arquivo deve ter uma extensão `.env`. Cada linha em um arquivo de ambiente contém uma variável de ambiente no formato `VARIABLE=VALUE`. As linhas que começam com `#` são tratadas como comentários e são ignoradas. Se houver variáveis de ambiente individuais especificadas na 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 de cima para baixo. Recomendamos usar nomes de variáveis exclusivos. Para obter mais informações, consulte [Transferência de uma variável de ambiente individual para um contêiner do Amazon ECS](taskdef-envfiles.md). `value` Tipo: String Exigido: sim O nome de recurso da Amazon (ARN) do objeto do Amazon S3 que contém o arquivo de variáveis de ambiente. `type` Tipo: String Exigido: sim Tipo de arquivo a ser usado O único valor aceito é `s3`. `environment` Tipo: Matriz de objeto Obrigatório: não As variáveis de ambiente a serem passadas para um contêiner. Esse parâmetro é mapeado para `Env` no comando create-container do docker na opção `--env` para o comando run do docker. Não recomendamos o uso de variáveis de ambiente de texto simples para informações confidenciais, tais como dados de credenciais. `name` Tipo: string Exigido: sim, quando `environment` for usado O nome da variável de ambiente. `value` Tipo: string Exigido: sim, quando `environment` for usado O valor da variável de ambiente. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Tipo: Matriz de objeto Obrigatório: não Um objeto que representa o segredo a ser exposto ao seu contêiner. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). `name` Tipo: String Exigido: sim O valor a ser definido como a variável de ambiente no contêiner. `valueFrom` Tipo: String Exigido: sim O segredo a ser exposto ao contêiner. Os valores com suporte são o nome do recurso da Amazon (ARN) completo do segredo do AWS Secrets Manager ou o ARN completo do parâmetro no Parameter Store do AWS Systems Manager. Se o parâmetro do Systems Manager Parameter Store ou do Secrets Manager existir na mesma Região da AWS que a tarefa sendo iniciada, você poderá usar o ARN completo ou o nome do segredo. Se o parâmetro existir em uma Região diferente, o ARN completo deverá ser especificado. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Segurança `privileged` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, o contêiner recebe privilégios elevados na instância de contêiner host (semelhante ao usuário `root`). Esse parâmetro é mapeado para `Privileged` no comando create-container do docker na opção `--privileged` de execução do docker. `user` Tipo: string Obrigatório: não O usuário a ser utilizado dentro do contêiner. Esse parâmetro é mapeado para `User` no comando create-container do docker na opção `--user` de execução do docker. Quando executar tarefas usando o modo de rede `host`, não execute contêineres usando o usuário raiz (UID 0). Recomendamos o uso de um usuário que não seja raiz para melhor segurança. É possível especificar o `user` usando os formatos a seguir. Se especificar um UID ou um GID, você deverá especificá-lo como um número inteiro positivo. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` `readonlyRootFilesystem` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, o contêiner recebe um sistema de arquivos raiz somente leitura. Esse parâmetro é mapeado para `ReadonlyRootfs` no comando create-container do docker na opção `--read-only` de execução do docker. `dockerSecurityOptions` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: Matriz de strings Obrigatório: não Uma lista de strings a fim de fornecer rótulos personalizados para sistemas de segurança multinível SELinux e AppArmor. Esse campo não é válido para contêineres em tarefas que usam o Fargate. `ulimits` Tipo: matriz de objetos [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) Obrigatório: não Uma lista de `ulimits` a ser definida no contêiner. Se um valor ulimit for especificado em uma definição de tarefa, ele substituirá os valores padrão definidos pelo Docker. Esse parâmetro é mapeado para `Ulimits` no comando create-container do docker na opção `--ulimit` de execução do docker. Valores de nomenclatura válidos são exibidos no tipo de dados [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html). As tarefas do Amazon ECS hospedadas no Fargate usam os valores de limite de recursos padrão definidos pelo sistema operacional, com exceção do parâmetro de limite de recursos `nofile`, que é substituído pelo Fargate. O limite de recursos `nofile` define uma restrição sobre o número de arquivos abertos que um contêiner pode usar. O limite flexível padrão `nofile` é `1024` e o limite rígido padrão é `65535`. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. Para verificar a versão da API remota do Docker na instância de contêiner, faça login na instância de contêiner e execute o seguinte comando: `sudo docker version --format '{{.Server.APIVersion}}'` `dockerLabels` Tipo: mapa de string para string Obrigatório: não Um mapa de chave/valor de rótulos a ser adicionado ao contêiner. Esse parâmetro é mapeado para `Labels` no comando create-container do docker na opção `--label` de execução do docker. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. ``` "dockerLabels": {"string": "string" ...} ``` #### Configurações de rede `disableNetworking` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: booliano Obrigatório: não Quando esse parâmetro é verdadeiro, a rede é desativada dentro do contêiner. O padrão é `false`. ``` "disableNetworking": true|false ``` `links` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: Matriz de strings Obrigatório: não O parâmetro `link` permite que os contêineres se comuniquem entre si sem a necessidade de mapeamentos de porta. Só há suporte para esse parâmetro se o modo de rede de uma definição de tarefa estiver definido como `bridge`. O construto `name:internalName` é igual ao `name:alias` em links do Docker. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Os contêineres colocados na mesma instância de contêiner podem se comunicar entre si sem exigir links ou mapeamentos de porta de host. O isolamento de rede em uma instância de contêiner é controlado por grupos de segurança e configurações de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: string Obrigatório: não O nome de host a ser usado para o contêiner. Esse parâmetro é mapeado para `Hostname` em create-container do docker na opção `--hostname` de execução do docker. ``` "hostname": "string" ``` `dnsServers` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: Matriz de strings Obrigatório: não Uma lista de servidores DNS apresentados ao contêiner. ``` "dnsServers": ["string", ...] ``` `extraHosts` Esse parâmetro não é compatível com tarefas que usam o modo de rede `awsvpc`. Tipo: Matriz de objeto Obrigatório: não Uma lista de nomes de host e mapeamentos de endereço IP a ser acrescentada ao arquivo `/etc/hosts` no contêiner. Esse parâmetro é mapeado para `ExtraHosts` no comando create-container do docker na opção `--add-host` de execução do docker. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Tipo: string Exigido: Sim, quando `extraHosts` são usados O nome do host a ser usado na entrada `/etc/hosts`. `ipAddress` Tipo: string Exigido: Sim, quando `extraHosts` são usados O endereço IP a ser usado na entrada `/etc/hosts`. #### Armazenamento e registro `readonlyRootFilesystem` Tipo: booliano Obrigatório: Não Quando esse parâmetro é verdadeiro, o contêiner recebe acesso somente leitura ao sistema de arquivos raiz. Esse parâmetro é mapeado para `ReadonlyRootfs` no comando create-container do docker na opção `--read-only` de execução do docker. O padrão é `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Tipo: Matriz de objeto Obrigatório: não Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS. `sourceVolume` Tipo: string Exigido: Sim, quando `mountPoints` são usados O nome do volume a ser montado. `containerPath` Tipo: string Exigido: Sim, quando `mountPoints` são usados O caminho no contêiner onde o volume será montado. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`. `volumesFrom` Tipo: Matriz de objeto Obrigatório: não Volumes de dados a serem montados de outro contêiner. Esse parâmetro é mapeado para `VolumesFrom` no comando create-container do docker na opção `--volumes-from` de execução do docker. `sourceContainer` Tipo: string Exigido: sim, quando `volumesFrom` for usado O nome do contêiner com base no qual montar volumes. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Tipo: objeto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) Obrigatório: não A especificação de configuração do log para o contêiner. Para obter definições de tarefa de exemplo que usam uma configuração de log, consulte [Exemplos de definições de tarefa do Amazon ECS](example_task_definitions.md). Esse parâmetro é mapeado para `LogConfig` no comando create-container do docker na opção `--log-driver` de execução do docker. Por padrão, os contêineres usam o mesmo driver de registro em log que o daemon do Docker usa. No entanto, o contêiner pode usar um driver de registro em log diferente do daemon do Docker especificando um driver de log com esse parâmetro na definição de contêiner. Para usar um driver de registro em log diferente para um contêiner, o sistema de log deve ser configurado corretamente na instância de contêiner (ou em um servidor de log diferente para opções de registro em log remotas). Considere o seguinte ao especificar uma configuração de log para seus contêineres: + O Amazon ECS oferece suporte a um subconjunto dos drivers de registro em log disponíveis para o daemon Docker. + Esse parâmetro exige a versão 1.18 ou posterior da API remota do Docker na sua instância de contêiner. ``` "logConfiguration": { "logDriver": "awslogs",""splunk", "awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Tipo: string Valores válidos: `"awslogs","splunk","awsfirelens"` Exigido: sim, quando `logConfiguration` for usado O driver de log a ser usado para o contêiner. Por padrão, os valores válidos listados anteriormente são drivers de log com os quais o agente de contêiner do Amazon ECS pode se comunicar. Os drivers de log compatíveis são `awslogs`, `splunk` e `awsfirelens`. Para obter mais informações sobre como usar o driver de log `awslogs` nas definições de tarefa para enviar os logs de contêiner ao CloudWatch Logs, consulte [Envio de logs do Amazon ECS para o CloudWatch](using_awslogs.md). Para obter mais informações sobre o uso do driver de log `awsfirelens`, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). Se tiver um driver personalizado que não esteja listado acima, será possível bifurcar o projeto do agente de contêiner do Amazon ECS que está [disponível no GitHub](https://github.com/aws/amazon-ecs-agent) e personalizá-lo para funcionar com esse driver. Incentivamos você a enviar solicitações pull para alterações que você gostaria de ter incluído. Porém, no momento, não oferecemos suporte à execução de cópias modificadas desse software. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. `options` Tipo: mapa de string para string Obrigatório: não O mapa chave/valor de opções de configuração a serem enviadas para o driver de log. As opções que você pode especificar dependem do driver de log. Algumas das opções que você pode especificar ao usar o roteador `awslogs` para rotear os logs para o Amazon CloudWatch incluem o seguinte: `awslogs-create-group` Obrigatório: não Especifique se você deseja que o grupo de logs seja criado automaticamente. Se essa opção não for especificada, o padrão será `false`. Sua política do IAM deve incluir a permissão `logs:CreateLogGroup` antes que você tente usar `awslogs-create-group`. `awslogs-region` Obrigatório: Sim Especifique a Região da AWS para a qual o driver de log do `awslogs` deve enviar seus logs do Docker. É possível optar por enviar todos os logs de clusters em regiões distintas para uma única região no CloudWatch Logs. Isso tem o objetivo de fazer com que todos fiquem visíveis em um único local. Caso contrário, você pode separá-los por região para mais granularidade. Certifique-se de que o grupo de logs especificado exista na região especificada com essa opção. `awslogs-group` Obrigatório: Sim Certifique-se de especificar um grupo de logs para o qual o driver de log do `awslogs` envia seus fluxos de logs. `awslogs-stream-prefix` Obrigatório: Sim Use a opção `awslogs-stream-prefix` para associar um fluxo de log ao prefixo especificado, ao nome do contêiner e ao ID da tarefa do Amazon ECS à qual o contêiner pertence. Caso você especifique um prefixo com essa opção, o fluxo de log utiliza o seguinte formato. ``` prefix-name/container-name/ecs-task-id ``` Se você não especificar um prefixo com essa opção, o fluxo de log será nomeado depois que o ID do contêiner for atribuído pelo daemon do Docker na instância de contêiner. Como é difícil rastrear logs até o contêiner que os enviou apenas com o ID do contêiner do Docker (disponível apenas na instância de contêiner), recomendamos especificar um prefixo com essa opção. Para serviços do Amazon ECS, é possível utilizar o nome do serviço como prefixo. Ao fazer isso, será possível rastrear fluxos de logs até o serviço ao qual o contêiner pertence, o nome do contêiner que os enviou e o ID da tarefa à qual o contêiner pertence. Você deve especificar um stream-prefix para seus logs para fazer com que eles apareçam no painel Logs quando o console do Amazon ECS for usado. `awslogs-datetime-format` Obrigatório: não Essa opção define um padrão de início de várias linhas no formato `strftime` em Python. Uma mensagem de log é formada por uma linha em conformidade com o padrão e as linhas seguintes que não correspondem ao padrão. A linha em conformidade é o delimitador entre as mensagens de log. Um exemplo de um caso de uso para esse formato é a análise da saída, como um despejo de pilha, que poderia ser registrado em várias entradas. O padrão correto permite que ele seja capturado em uma única entrada. Para obter mais informações, consulte [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). Você não pode configurar as opções `awslogs-datetime-format` e `awslogs-multiline-pattern`. O registro em várias linhas executa a análise da expressão regular e a correspondência de todas as mensagens de log. Isso pode ter um impacto negativo na performance do registro em log. `awslogs-multiline-pattern` Obrigatório: não Essa opção define um padrão inicial de várias linhas que usa uma expressão regular. Uma mensagem de log é formada por uma linha em conformidade com o padrão e as linhas seguintes que não correspondem ao padrão. A linha em conformidade é o delimitador entre as mensagens de log. Para obter mais informações, consulte [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Essa opção será ignorada se `awslogs-datetime-format` também estiver configurado. Você não pode configurar as opções `awslogs-datetime-format` e `awslogs-multiline-pattern`. O registro em várias linhas executa a análise da expressão regular e a correspondência de todas as mensagens de log. Isso pode ter um impacto negativo na performance do registro em log. `mode` Obrigatório: não Valores válidos: `non-blocking` \$1 `blocking` Essa opção define o modo de entrega de mensagens de log do contêiner para o driver de log do `awslogs`. O modo de entrega escolhido afeta a disponibilidade da aplicação quando o fluxo de logs do contêiner é interrompido. Se você usar o modo `blocking` e o fluxo de logs para o CloudWatch for interrompido, as chamadas do código do contêiner para gravar nos fluxos `stdout` e `stderr` serão bloqueadas. Como resultado, o encadeamento de logs da aplicação será bloqueado. Isso pode fazer com que a aplicação pare de responder e causar uma falha na verificação de integridade do contêiner. Se você usar o modo `non-blocking`, os registros do contêiner serão armazenados em um buffer intermediário na memória configurado com a opção `max-buffer-size`. Isso evita que a aplicação pare de responder quando os registros não puderem ser enviados para o CloudWatch. Recomendamos usar esse modo se você quiser garantir a disponibilidade do serviço e aceitar alguma perda de logs. Para obter mais informações, consulte [Preventing log loss with non-blocking mode in the `awslogs` container log driver](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). `max-buffer-size` Obrigatório: não Valor padrão: `1m` Quando o modo `non-blocking` é usado, a opção de log `max-buffer-size` controla o tamanho do buffer de anel usado para armazenamento de mensagens intermediárias. Certifique-se de especificar um tamanho de buffer adequado com base na sua aplicação. Quando o buffer ficar cheio, logs adicionais não poderão ser armazenados. Os logs que não puderem ser armazenados serão perdidos. Para rotear logs usando o roteador de logs do `splunk`, você precisa especificar um `splunk-token` e um `splunk-url`. Ao usar o roteador de log `awsfirelens` para rotear logs para um destino do AWS service (Serviço da AWS) ou para armazenamento e analytics de logs do AWS Partner Network, você pode definir a opção `log-driver-buffer-limit` para limitar o número de eventos que são armazenados em buffer na memória antes de serem enviados ao contêiner do roteador de logs. Isso pode ajudar a resolver possíveis problemas de perda de logs, pois o alto throughput pode resultar na falta de memória para o buffer dentro do Docker. Para obter mais informações, consulte [Configuração de logs do Amazon ECS para obtenção de alto throughput](firelens-docker-buffer-limit.md). Outras opções que você pode especificar ao usar o `awsfirelens` para rotear logs dependem do destino. Ao exportar logs para o Amazon Data Firehose, você pode especificar a Região da AWS com a `region` e um nome para o fluxo de logs com `delivery_stream`. Ao exportar logs para o Amazon Kinesis Data Streams, você pode especificar um Região da AWS com a `region` um com e um nome de fluxo de dados com `stream`. Ao exportar logs para o Amazon OpenSearch Service, você pode especificar opções como `Name`, `Host` (endpoint do OpenSearch Service sem protocolo) `Port`, `Index`, `Type`, `Aws_auth`, `Aws_region`, `Suppress_Type_Name` e `tls`. Ao exportar logs para o Amazon S3, você pode especificar o bucket usando a opção `bucket`. Você também pode especificar `region`, `total_file_size`, `upload_timeout` e `use_put_object` como opções. Este parâmetro requer a versão 1.19 da Docker Remote API ou posterior em sua instância de contêiner. `secretOptions` Tipo: Matriz de objeto Obrigatório: não Um objeto que representa o segredo a ser passado para a configuração de log. Os segredos usados na configuração de log podem incluir tokens de autenticação, certificados ou chaves de criptografia. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). `name` Tipo: String Exigido: sim O valor a ser definido como a variável de ambiente no contêiner. `valueFrom` Tipo: String Exigido: sim O segredo a ser exposto à configuração de log do contêiner. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Tipe: objeto [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) Obrigatório: não A configuração do FireLens para o contêiner. Isso é usado para especificar e configurar um roteador de log para logs de contêiner. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Tipo: Mapa de string para string Obrigatório: não O mapa chave/valor de opções a serem usadas ao configurar o roteador de log. Esse campo é opcional e pode ser usado para especificar um arquivo de configuração personalizado ou para adicionar outros metadados, como a tarefa, a definição de tarefa, o cluster e detalhes da instância de contêiner ao evento de log. Se especificado, a sintaxe a ser usada é `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Para obter mais informações, consulte [Exemplo de definição de tarefa do Amazon ECS: rotear logs para o FireLens](firelens-taskdef.md). `type` Tipo: String Exigido: sim O roteador de log a ser usado. Os valores válidos são `fluentd` ou `fluentbit`. #### Requisitos de recursos `resourceRequirements` Tipo: objetos [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obrigatório: não O tipo e a quantidade de um recurso a serem atribuídos a um contêiner. O único recurso compatível é uma GPU. `type` Tipo: String Exigido: sim O tipo de recurso a ser atribuído a um contêiner. O valor suportado é `GPU`. `value` Tipo: String Exigido: sim O valor do tipo de recurso especificado. Se o tipo `GPU` for usado, o valor será o número de `GPUs` físicas que o agente de contêiner do Amazon ECS reserva para o contêiner. O número de GPUs reservadas para todos os contêineres em uma tarefa não pode exceder o número de GPUs disponíveis na instância de contêiner na qual a tarefa é iniciada. As GPUs não estão disponíveis para tarefas executados no Fargate. #### Tempos limite de contêiner `startTimeout` Tipo: inteiro Obrigatório: não Valores de exemplo: `120` Tempo a ser aguardado (em segundos) antes de desistir de resolver dependências para um contêiner. Por exemplo, você especifica dois contêineres em uma definição de tarefa com o `containerA` tendo uma dependência do `containerB` atingir um status `COMPLETE`, `SUCCESS` ou `HEALTHY`. Se um valor de `startTimeout` for especificado para o `containerB` e ele não atingir o status desejado nesse tempo, o `containerA` não será iniciado. Se um contêiner não atender a uma restrição de dependência ou expirar antes de cumprir a restrição, o Amazon ECS não evoluirá contêineres dependentes para seu próximo estado. O valor máximo é de 600 segundos (10 minutos). `stopTimeout` Tipo: inteiro Obrigatório: não Valores de exemplo: `120` Período (em segundos) a ser aguardado antes de o contêiner ser eliminado de maneira forçada se não for encerrado normalmente por conta própria. Se o parâmetro não for especificado, então o valor padrão de 30 segundos será usado. O valor máximo é de 86.400 segundos (24 horas). #### Dependência de contêiner `dependsOn` Tipo: matriz de objetos [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obrigatório: não As dependências definidas para startup e desligamento do contêiner. Um contêiner pode conter várias dependências. Quando uma dependência é definida para o startup do contêiner, ela é revertida para o desligamento do contêiner. Para ver um exemplo, consulte [Dependência de contêiner](example_task_definitions.md#example_task_definition-containerdependency). Se um contêiner não atender a uma restrição de dependência ou expirar antes de cumprir a restrição, o Amazon ECS não evoluirá contêineres dependentes para seu próximo estado. Este parâmetro exige que a tarefa ou o serviço usem a plataforma versão `1.3.0` ou posterior (Linux), ou `1.0.0` (Windows). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Tipo: String Exigido: sim O nome do contêiner que deve atender à condição especificada. `condition` Tipo: String Exigido: sim A condição de dependência do contêiner. A seguir estão as condições disponíveis e seus comportamentos. + `START`: essa condição emula o comportamento de links e volumes atuais. A condição valida que um contêiner dependente seja iniciado antes de permitir que outros contêineres sejam iniciados. + `COMPLETE`: essa condição valida que um contêiner dependente seja executado até a conclusão (encerramento) antes de permitir que outros contêineres sejam iniciados. Isso pode ser útil para os contêineres não essenciais que executam um script e depois são encerrados. Não é possível definir essa condição em um contêiner essencial. + `SUCCESS`: essa condição é igual a `COMPLETE`, mas também exige que o contêiner seja encerrado com um status `zero`. Não é possível definir essa condição em um contêiner essencial. + `HEALTHY`: essa condição valida que o contêiner dependente foi aprovado na verificação de integridade do Docker antes de permitir que outros contêineres sejam iniciados. Isso requer que o contêiner dependente tenha verificações de integridade configuradas na definição de tarefa. Essa condição é confirmada apenas no startup da tarefa. #### Controles do sistema `systemControls` Tipo: objeto [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obrigatório: não Uma lista de parâmetros de kernel com namespace a ser definida no contêiner. Esse parâmetro é mapeado para `Sysctls` no comando create-container do docker e na opção `--sysctl` de execução do docker. Por exemplo, é possível definir a configuração `net.ipv4.tcp_keepalive_time` para manter conexões de longa duração. Não recomendamos que você especifique parâmetros `systemControls` relacionados à rede para vários contêineres em uma única tarefa que também use o modo de rede `awsvpc` ou `host`. Fazer isso apresenta as desvantagens a seguir: + Se você definir `systemControls` para algum contêiner, isso se aplicará a todos os contêineres na tarefa. Se você definir um `systemControls` diferente para vários contêineres em uma única tarefa, o contêiner iniciado por último determinará qual `systemControls` entra em vigor. Se você estiver configurando um namespace de recurso IPC para usar nos contêineres da tarefa, as condições a seguir serão aplicadas aos controles do sistema. Para obter mais informações, consulte [Modo IPC](task_definition_parameters.md#task_definition_ipcmode). + Para tarefas que usam o modo IPC `host`, o namespace IPC `systemControls` não é compatível. + Para tarefas que usam o modo IPC de `task`, os valores de `systemControls` do namespace IPC serão aplicados a todos os contêineres em uma tarefa. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Tipo: string Obrigatório: não O parâmetro de kernel com namespace para o qual definir um `value`. Valores de namespace IPC válidos: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` e `Sysctls`, que comecem com `"fs.mqueue.*"` Valores de namespace de rede válidos: `Sysctls`, que comece com `"net.*"`. No Fargate, apenas os `Sysctls` com namespace existentes dentro do contêiner são aceitos. Há suporte para todos esses valores no Fargate. `value` Tipo: string Obrigatório: não O valor do parâmetro de kernel com namespace especificado em `namespace`. #### Interativo `interactive` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, você pode implantar aplicações em contêineres que exigem a alocação de `stdin` ou `tty`. Esse parâmetro é mapeado para `OpenStdin` no comando create-container do docker na opção `--interactive` de execução do docker. O padrão é `false`. #### Pseudoterminal `pseudoTerminal` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, um TTY é alocado. Esse parâmetro é mapeado para `Tty` no comando create-container do docker na opção `--tty` de execução do docker. O padrão é `false`. ### Parâmetros do Linux `linuxParameters` Tipo: Objeto [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obrigatório: não Modificações específicas ao Linux aplicadas ao contêiner, como recursos do kernel do Linux. `capabilities` Tipo: objeto [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Obrigatório: não Os recursos do Linux para o contêiner que são adicionados ou descartados da configuração padrão fornecida pelo Docker. `devices` Tipo: Matriz de objetos [Device](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obrigatório: não Todos os dispositivos do host a serem expostos ao contêiner. Esse parâmetro é mapeado para `Devices` no comando create-container do docker na opção `--device` de execução do docker. `initProcessEnabled` Tipo: booliano Obrigatório: não Execute um processo `init` dentro do contêiner que encaminha sinais e colhe processos. Esse parâmetro é mapeado para a opção `--init` de execução do docker. `maxSwap` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: inteiro Obrigatório: não A quantidade total de memória de troca (em MiB) que um contêiner pode usar. Esse parâmetro será convertido na opção `--memory-swap` para execução do docker em que o valor é a soma da memória do contêiner mais o valor de `maxSwap`. `swappiness` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: inteiro Obrigatório: não Isso permite ajustar o comportamento de troca de memória de um contêiner. Um valor `swappiness` de `0` fará com que a troca não ocorra, a menos que seja absolutamente necessário. Um valor `swappiness` de `100` fará com que as páginas sejam trocadas de forma muito agressiva. Os valores válidos são números inteiros de `0` a `100`. Se o parâmetro `swappiness` não for especificado, será usado um valor padrão de `60`. Se nenhum valor for especificado para `maxSwap`, esse parâmetro será ignorado. Esse parâmetro é mapeado para a opção `--memory-swappiness` de execução do docker. `sharedMemorySize` Esse parâmetro não é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS. Tipo: inteiro Obrigatório: não O tamanho (em MiB) do volume `/dev/shm`. Esse parâmetro é mapeado para a opção `--shm-size` de execução do docker. `tmpfs` Tipo: Matriz de objetos [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obrigatório: não O caminho do contêiner, as opções de montagem e o tamanho (em MiB) da montagem tmpfs. Esse parâmetro é mapeado para a opção `--tmpfs` de execução do docker. # Parâmetros de definição de tarefa do Amazon ECS para o Fargate As definições de tarefa se dividem em partes distintas: a família da tarefa, o perfil da tarefa do AWS Identity and Access Management (IAM), o modo de rede, definições de contêiner, volumes e tipos de inicialização. As definições de família e de contêiner são obrigatórias em uma definição de tarefa. Por outro lado, perfil de tarefa, modo da rede, volumes e tipo de inicialização são opcionais. É possível usar esses parâmetros em um arquivo JSON para configurar sua definição de tarefa. Veja a seguir descrições mais detalhadas de cada parâmetro de definição de tarefa para o Fargate. ## Família `family` Tipo: String Exigido: sim Ao registrar uma definição de tarefa, você dá a ela uma família, semelhante a um nome para várias versões da definição de tarefa, especificada com um número de revisão. A primeira definição de tarefa registrada em uma determinada família recebe uma revisão 1, e todas as definições de tarefa registradas depois receberão um número de revisão sequencial. ## Capacidade Ao registrar uma definição de tarefa, você pode especificar a capacidade segundo a qual o Amazon ECS deve validar a definição de tarefa. Se a definição de tarefa não for validada em relação às compatibilidades especificadas, uma exceção de cliente será retornada. O seguinte parâmetro é permitido em uma definição de tarefa. `requiresCompatibilities` Tipo: Matriz de strings Obrigatório: não Valores válidos: `FARGATE` A capacidade segundo a qual a definição de tarefa é validada. Isso inicia uma verificação para garantir que todos os parâmetros usados na definição de tarefa atendam aos requisitos do Fargate. ## Função do para tarefa `taskRoleArn` Tipo: string Obrigatório: não Ao registrar uma definição de tarefa, você pode fornecer uma função de tarefa para uma função do IAM que permita que os contêineres da permissão de tarefa chame as APIs da AWS especificadas nas políticas associadas em seu nome. Para obter mais informações, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md). ## Função do para execução de tarefas `executionRoleArn` Tipo: string Obrigatório: Condicional O nome do recurso da Amazon (ARN) da função de execução de tarefas que concede ao agente de contêiner do Amazon ECS permissão para fazer chamadas de API da AWS em seu nome. A função do IAM para execução da tarefa é necessária dependendo dos requisitos da sua tarefa. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md). ## Modo de rede `networkMode` Tipo: String Exigido: sim O modo de rede do Docker a ser usado para os contêineres na tarefa. Para tarefas do Amazon ECS hospedadas no Fargate, é necessário o modo de rede `awsvpc`. ## Plataforma de runtime `operatingSystemFamily` Tipo: string Obrigatório: Condicional Padrão: LINUX Esse parâmetro é necessário para tarefas do Amazon ECS hospedadas no Fargate. Ao registrar uma definição de tarefa, você especifica a família do sistema operacional. Os valores válidos são `LINUX`, `WINDOWS_SERVER_2025_FULL`, `WINDOWS_SERVER_2025_CORE`, `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_2019_FULL` e `WINDOWS_SERVER_2019_CORE`. Todas as definições de tarefa usadas em um serviço devem ter o mesmo valor para esse parâmetro. Quando uma definição de tarefa faz parte de um serviço, esse valor deve corresponder ao valor `platformFamily` do serviço. `cpuArchitecture` Tipo: string Obrigatório: Condicional Padrão: X86\$164 Se o parâmetro for deixado como `null`, o valor padrão é atribuído automaticamente ao iniciar uma tarefa hospedada no Fargate. Ao registrar uma definição de tarefa, você especifica a arquitetura da CPU. Os valores válidos são `X86_64` e `ARM64`. Todas as definições de tarefa usadas em um serviço devem ter o mesmo valor para esse parâmetro. Quando você tem tarefas do Linux, pode definir o valor como `ARM64`. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads do ARM de 64 bits](ecs-arm64.md). ## Tamanho da tarefa Ao registrar uma definição de tarefa, você pode especificar o total de CPU e memória usados para a tarefa. Isso é separado dos valores de `cpu` e `memory` no nível de definição de contêiner. Para tarefas hospedadas no Fargate (tanto de Linux quanto de Windows), esses campos são obrigatórios e existem valores específicos para `cpu` e `memory` com suporte. O seguinte parâmetro é permitido em uma definição de tarefa: `cpu` Tipo: String Exigido: sim É necessário informar os parâmetros de CPU e memória no nível da tarefa, que são usados para determinar o tipo e o tamanho da instância na qual as tarefas são executadas. Para tarefas do Windows, esses valores não são aplicados em runtime, porque o Windows não tem um mecanismo nativo que possa impor facilmente limites coletivos de recursos em um grupo de contêineres. Se você quiser impor limites de recursos, recomendamos usar os recursos no nível de contêiner para contêineres do Windows. O limite rígido de unidades de CPU a ser apresentado para a tarefa. 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. Quando a definição de tarefa for registrada, um valor de vCPU será convertido em um inteiro indicando as unidades de CPU. Esse campo é obrigatório e você deve usar um dos valores a seguir, o que determina o intervalo de valores compatíveis com o parâmetro `memory`. A tabela a seguir mostra as combinações válidas para CPU e memória em nível de tarefa. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/task_definition_parameters.html) `memory` Tipo: String Exigido: sim É necessário informar os parâmetros de CPU e memória no nível da tarefa, que são usados para determinar o tipo e o tamanho da instância na qual as tarefas são executadas. Para tarefas do Windows, esses valores não são aplicados em runtime, porque o Windows não tem um mecanismo nativo que possa impor facilmente limites coletivos de recursos em um grupo de contêineres. Se você quiser impor limites de recursos, recomendamos usar os recursos no nível de contêiner para contêineres do Windows. O limite fixo de memória a ser apresentada para a tarefa. É possível especificar valores de memória na definição de tarefa como uma string em mebibytes (MiB) ou gigabytes (GB). Por exemplo, você pode especificar um valor de memória como `3072` em MiB ou `3 GB` em GB. Quando a definição de tarefa for registrada, um valor em GB será convertido em um inteiro indicando o MiB. Esse campo é obrigatório e você deve usar um dos valores a seguir, o que determina o intervalo de valores compatíveis com o parâmetro `cpu`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/task_definition_parameters.html) ## Definições de contêiner Ao registrar uma definição de tarefa, você deve especificar uma lista de definições de contêiner passadas para o daemon do Docker em uma instância de contêiner. Os parâmetros a seguir são permitidos em uma definição de contêiner. **Topics** + [ ### Parâmetros padrão de definição de contêiner ](#standard_container_definition_params) + [ ### Parâmetros avançados de definição de contêiner ](#advanced_container_definition_params) + [ ### Outros parâmetros de definição de contêiner ](#other_container_definition_params) ### Parâmetros padrão de definição de contêiner Os parâmetros de definição de tarefa a seguir são obrigatórios ou usados na maioria das definições de contêiner. **Topics** + [ #### Nome ](#container_definition_name) + [ #### Imagem ](#container_definition_image) + [ #### Memória ](#container_definition_memory) + [ #### Mapeamentos de porta ](#container_definition_portmappings) + [ #### Credenciais de repositório privado ](#container_definition_repositoryCredentials) #### Nome `name` Tipo: String Exigido: sim O nome de um contêiner. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Se estiver vinculando vários contêineres em uma definição de tarefa, o `name` de um contêiner poderá ser informado no `links` de outro contêiner. Isso deve ser feito para conectar os contêineres. #### Imagem `image` Tipo: String Exigido: sim A imagem usada para iniciar um contêiner. Essa string é passada diretamente para o daemon do Docker. Por padrão, as imagens no registro do Docker Hub estão disponíveis. Você também pode especificar outros repositórios com `repository-url/image:tag` ou `repository-url/image@digest`. São permitidos até 255 letras (caixa alta e baixa), números, hifens, sublinhados, dois pontos, ponto, barras e sinais numéricos. Esse parâmetro é mapeado para `Image` no comando create-container do docker e no parâmetro `IMAGE` do comando run do docker. + Quando uma nova tarefa é iniciada, o agente do contêiner do Amazon ECS obtém a versão mais recente da imagem especificada e a tag do contêiner a ser usado. No entanto, as atualizações subsequentes feitas em um repositório de imagens não são propagadas para tarefas já em execução. + Quando não é especificada uma tag ou um resumo no caminho da imagem na definição da tarefa, o agente de contêiner do Amazon ECS usa a tag `latest` para extrair a imagem especificada. + As atualizações subsequentes para um repositório de imagens não são propagadas para tarefas já em execução. + As imagens em registros privados são suportadas. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). + As imagens nos repositórios do Amazon ECR podem ser especificadas usando a convenção de nomenclatura completa `registry/repository:tag` ou `registry/repository@digest` (por exemplo, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` ou `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + As imagens em repositórios oficiais no Docker Hub usam um único nome (por exemplo, `ubuntu` ou `mongo`). + Imagens em outros repositórios Docker Hub são qualificadas com um nome de organização (por exemplo, `amazon/amazon-ecs-agent`). + Imagens em outros repositórios online também são qualificadas por um nome de domínio (por exemplo, `quay.io/assemblyline/ubuntu`). `versionConsistency` Tipo: string Valores válidos: `enabled`\$1`disabled` Obrigatório: não Especifica se o Amazon ECS resolverá a tag de imagem do contêiner fornecida na definição do contêiner em um resumo de imagem. Por padrão, esse comportamento é `enabled`. Se você definir o valor de um contêiner como `disabled`, o Amazon ECS não resolverá a tag da imagem do contêiner como um resumo e usará o URI da imagem original especificado na definição do contêiner para implantação. Para obter mais informações sobre resolução de imagem do contêiner, consulte [Resolução da imagem do contêiner](deployment-type-ecs.md#deployment-container-image-stability). #### Memória `memory` Tipo: inteiro Obrigatório: não A quantidade (em MiB) de memória a ser apresentada ao contêiner. Caso tente exceder a memória especificada aqui, o contêiner será excluído. A quantidade total de memória reservada para todos os contêineres dentro da tarefa deve ser menor que o valor da tarefa `memory`, se estiver especificado. Esse parâmetro é mapeado para `Memory` no comando create-container do docker na opção `--memory` de execução do docker. O daemon para Docker 20.10.0 ou versão posterior reserva no mínimo 6 MiB de memória para um contêiner. Por isso, não especifique menos de 6 MiB de memória para os seus contêineres. O daemon para Docker 19.03.13-ce ou versão anterior reserva no mínimo 4 MiB de memória para um contêiner. Por isso, não especifique menos de 4 MiB de memória para os seus contêineres. Se você deseja maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). `memoryReservation` Tipo: inteiro Obrigatório: não O limite flexível (em MiB) de memória a ser reservado para o contêiner. Quando a memória do sistema estiver em contenção, o Docker tentará manter a memória do contêiner dentro desse limite flexível. Entrentanto, seu contêiner pode usar mais memória quando necessário. O contêiner pode consumir até o limite rígido especificado pelo parâmetro `memory` (se aplicável), ou toda a memória disponível na instância de contêiner, o que ocorrer primeiro. Esse parâmetro é mapeado para `MemoryReservation` no comando create-container do docker na opção `--memory-reservation` de execução do docker. Se um valor de memória no nível de tarefa não for especificado, será necessário especificar um número inteiro diferente de zero para um ou ambos `memory` ou `memoryReservation` em uma definição de contêiner. Caso você especifique ambos, `memory` deve ser maior que `memoryReservation`. Caso você especifique `memoryReservation`, o valor é subtraído dos recursos de memória disponíveis para a instância de contêiner na qual o contêiner está colocado. Caso contrário, o valor de `memory` é usado. Por exemplo, suponha que seu contêiner normalmente use 128 MiB de memória, mas às vezes chegue a 256 MiB de memória por períodos curtos. É possível definir um `memoryReservation` de 128 MiB e um limite rígido de `memory` de 300 MiB. Essa configuração permite que contêiner reservasse apenas 128 MiB de memória dos recursos restantes na instância de contêiner. Ao mesmo tempo, essa configuração também possibilita que o contêiner utilize mais recursos de memória quando necessário. Este parâmetro não é compatível com contêineres do Windows. O daemon para Docker 20.10.0 ou versão posterior reserva no mínimo 6 MiB de memória para um contêiner. Por isso, não especifique menos de 6 MiB de memória para os seus contêineres. O daemon para Docker 19.03.13-ce ou versão anterior reserva no mínimo 4 MiB de memória para um contêiner. Por isso, não especifique menos de 4 MiB de memória para os seus contêineres. Se você deseja maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). #### Mapeamentos de porta `portMappings` Tipo: Matriz de objeto Obrigatório: não Os mapeamentos de portas expõem as portas de rede do seu contêiner ao mundo externo. Isso permite que os clientes acessem sua aplicação. Também é usado para comunicação entre contêineres dentro da mesma tarefa. Para definições de tarefa que usam o modo de rede `awsvpc`, apenas especifique `containerPort`. A `hostPort` é sempre ignorada e a porta do contêiner é automaticamente mapeada para uma porta aleatória de alto número no host. Os mapeamentos de porta no Windows usam o endereço de gateway `NetNAT`, e não o `localhost`. Não há loopback para mapeamentos de porta no Windows, de modo que você não pode acessar a porta mapeada de um contêiner no próprio host. A maioria dos campos desse parâmetro (incluindo `containerPort`, `hostPort`, `protocol`) é mapeada para `PortBindings` no comando create-container do docker e a opção `--publish` de execução do docker. Caso o modo de rede de uma definição de tarefa seja definido como `host`, as portas host devem ser indefinidas ou corresponder à porta de contêiner no mapeamento de porta. Quando a tarefa obter o status `RUNNING`, as atribuições automáticas e manuais da porta do contêiner e do host estarão visíveis nos seguintes locais: + Console: a seção **Network Bindings** (Associações de rede) de uma descrição de contêiner para uma tarefa selecionada. + AWS CLI: a seção `networkBindings` do resultado do comando **describe-tasks**. + API: a resposta `DescribeTasks`. + Metadados: o endpoint de metadados da tarefa. `appProtocol` Tipo: string Obrigatório: não O protocolo da aplicação usado no mapeamento da porta. Esse parâmetro só se aplica ao Service Connect. Recomendamos que você defina esse parâmetro para que seja consistente com o protocolo usado por sua aplicação. Se você definir esse parâmetro, o Amazon ECS adicionará o tratamento de conexão específico do protocolo ao proxy do Service Connect. Se você definir esse parâmetro, o Amazon ECS adicionará telemetria específica de protocolo no console do Amazon ECS e no CloudWatch. Se você não definir um valor para esse parâmetro, o TCP será usado. No entanto, o Amazon ECS não adiciona telemetria específica de protocolo para TCP. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). Valores de protocolo válidos: `"http" | "http2" | "grpc" ` `containerPort` Tipo: inteiro Exigido: Sim, quando `portMappings` são usados O número da porta no contêiner vinculado à porta host atribuída automaticamente ou especificada pelo usuário. Para as tarefas que usam o modo de rede `awsvpc`, você usa `containerPort` para especificar as portas expostas. Para contêineres Windows no Fargate, não é possível usar a porta 3150 para `containerPort`. Isso acontece porque ela está reservada. `containerPortRange` Tipo: string Obrigatório: não O intervalo de números de porta no contêiner vinculado ao intervalo de portas host mapeado dinamicamente. Você só pode definir esse parâmetro usando a API `register-task-definition`. A opção está disponível no parâmetro `portMappings`. Para obter mais informações, consulte [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html), na *Referência da AWS Command Line Interface*. As regras a seguir se aplicam quando você especifica um `containerPortRange`: + Você deve usar o modo de rede `awsvpc`. + Esse parâmetro está disponível para os sistemas operacionais Windows e Linux. + A instância de contêiner deve ter pelo menos a versão 1.67.0 do agente do contêiner e pelo menos a versão 1.67.0-1 do pacote `ecs-init` + É possível especificar no máximo 100 intervalos de portas para cada contêiner. + Você não especifica um `hostPortRange`. O valor do `hostPortRange` é definido da seguinte forma: + Para contêineres em uma tarefa com o modo de rede `awsvpc`, o `hostPort` é definido com o mesmo valor que `containerPort`. Essa é uma estratégia de mapeamento estático. + Os valores válidos de `containerPortRange` estão entre 1 e 65535. + Uma porta só pode ser incluída em um mapeamento de portas para cada contêiner. + Não é possível especificar intervalos de portas sobrepostos. + A primeira porta no intervalo deve ser menor que a última porta no intervalo. + O Docker recomenda que você desative o docker-proxy no arquivo de configuração do daemon do Docker quando tiver um grande número de portas. Para obter mais informações, consulte [Issue \$111185](https://github.com/moby/moby/issues/11185) no GitHub. Para obter informações sobre como desativar o docker-proxy no arquivo de configuração do daemon do Docker, consulte [Daemon do Docker](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) no *Guia do desenvolvedor do Amazon ECS*. É possível chamar [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) para visualizar o `hostPortRange`, que são as portas do host vinculadas às portas do contêiner. Os intervalos de portas não estão incluídos nos eventos de tarefas do Amazon ECS que são enviados ao EventBridge. Para obter mais informações, consulte [Automatização de respostas a erros do Amazon ECS usando o EventBridge](cloudwatch_event_stream.md). `hostPortRange` Tipo: Sequência Obrigatório: não O intervalo de números de portas no host que é usado com a vinculação de rede. Isso é atribuído pelo Docker e fornecido pelo agente do Amazon ECS. `hostPort` Tipo: inteiro Obrigatório: não O número da porta na instância de contêiner a ser reservado para o contêiner. A `hostPort` pode ser deixada em branco ou ter um valor igual a `containerPort`. O intervalo de portas temporárias padrão para a versão 1.6.0 e posterior do Docker é listado na instância em `/proc/sys/net/ipv4/ip_local_port_range`. Se esse parâmetro do kernel não estiver disponível, será usado o intervalo de portas temporárias padrão de `49153–65535`. Não tente especificar uma porta de host no intervalo de portas transitório. Isso ocorre porque essas portas são reservadas para atribuição automática. Em geral, as portas abaixo de `32768` estão fora do intervalo de portas temporárias. As portas reservadas padrão são `22` para SSH, as portas do Docker `2375` e`2376` e as portas do agente de contêiner do Amazon ECS `51678-51680`. Qualquer porta de host que tenha sido especificada pelo usuário anteriormente para uma tarefa em execução também é reservada enquanto a tarefa está em execução. Depois que uma tarefa é interrompida, a porta do host é liberada. As portas reservadas atuais são exibidas nos `remainingResources` de **describe-container-instances** de saída. Uma instância de contêiner pode ter até 100 portas reservadas por vez, incluindo as portas reservadas padrão. As portas atribuídas automaticamente não contam em relação à cota de 100 portas reservadas. `name` Tipo: string Obrigatório: não, obrigatório para que o Service Connect e o VPC Lattice sejam configurados em um serviço Nome que é usado para o mapeamento da porta. Esse parâmetro só se aplica ao Service Connect e ao VPC Lattice. Esse parâmetro é o nome que você usa na configuração do Service Connect e do VPC Lattice de um serviço. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). No exemplo a seguir, ambos os campos obrigatórios para o Service Connect e o VPC Lattice são usados. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Tipo: string Obrigatório: não O protocolo usado no mapeamento da porta. Os valores válidos são `tcp` e `udp`. O padrão é `tcp`. Só `tcp` é compatível com o Service Connect. Lembre-se de que `tcp` estará implícito se esse campo não estiver definido. Caso você esteja especificando uma porta host, use a seguinte sintaxe: ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Caso você queira uma porta host atribuída automaticamente, use a seguinte sintaxe: ``` "portMappings": [ { "containerPort": integer } ... ] ``` #### Credenciais de repositório privado `repositoryCredentials` Tipo: objeto [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obrigatório: não As credenciais do repositório para autenticação de registro privado. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). `credentialsParameter` Tipo: string Exigido: Sim, quando `repositoryCredentials` são usados O nome de recurso da Amazon (ARN) do segredo que contém as credenciais do repositório privado. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). Quando você usa a API do Amazon ECS, a AWS CLI ou os AWS SDKs, se o segredo existir na mesma região da tarefa que estiver sendo executada, será possível usar o ARN completo ou o nome do segredo. Ao usar o Console de gerenciamento da AWS, é preciso especificar o ARN completo do segredo. Veja a seguir um trecho de uma definição de tarefa que mostra os parâmetros necessários. ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Parâmetros avançados de definição de contêiner Os parâmetros avançados de definição de contêiner a seguir fornecem recursos estendidos ao comando run do docker usado para iniciar contêineres nas instâncias de contêiner do Amazon ECS. **Topics** + [ #### Política de reinicialização ](#container_definition_restart_policy) + [ #### Verificação de integridade ](#container_definition_healthcheck) + [ #### Environment ](#container_definition_environment) + [ #### Configurações de rede ](#container_definition_network) + [ #### Armazenamento e registro ](#container_definition_storage) + [ #### Segurança ](#container_definition_security) + [ #### Limites de recurso ](#container_definition_limits) + [ #### Rótulos do Docker ](#container_definition_labels) #### Política de reinicialização `restartPolicy` A política de reinicialização do contêiner e os parâmetros de configuração associados. Quando você configura uma política de reinicialização para um contêiner, o Amazon ECS pode reiniciar o contêiner sem precisar substituir a tarefa. Para obter mais informações, consulte [Reiniciar contêineres individuais em tarefas do Amazon ECS com políticas de reinicialização de contêineres](container-restart-policy.md). `enabled` Tipo: booliano Obrigatório: Sim Especifica se uma política de reinicialização está habilitada para o contêiner. `ignoredExitCodes` Tipo: matriz de inteiros Obrigatório: não Uma lista de códigos de saída que o Amazon ECS ignorará e não tentará reiniciar. Você pode especificar um máximo de 50 códigos de saída de contêiner. Por padrão, o Amazon ECS não ignora nenhum código de saída. `restartAttemptPeriod` Tipo: inteiro Obrigatório: não A quantidade de tempo (em segundos) que o contêiner deve ser executado antes de uma tentativa de reinicialização. Um contêiner só pode ser reiniciado uma vez a cada `restartAttemptPeriod` segundos. Se um contêiner não puder ser executado nesse período e sair mais cedo, ele não será reiniciado. Você pode especificar um `restartAttemptPeriod` mínimo de 60 segundos e um `restartAttemptPeriod` máximo de 1800 segundos. Por padrão, um contêiner deve ser executado por 300 segundos antes de ser reiniciado. #### Verificação de integridade `healthCheck` O comando da verificação de integridade de contêiner e os parâmetros de configuração associados para o contêiner. Para obter mais informações, consulte [Como determinar a integridade das tarefas do Amazon ECS usando verificações de integridade de contêineres](healthcheck.md). `command` Uma matriz de strings que representa o comando executado pelo contêiner para determinar se ela está íntegra. A matriz de strings pode começar com `CMD` para executar os argumentos de comando diretamente ou `CMD-SHELL` para executar o comando com o shell padrão do contêiner. Se nenhuma for especificado, `CMD` será usada. Ao registrar uma definição de tarefa no Console de gerenciamento da AWS, use uma lista de comandos separados por vírgulas. Esses comandos serão convertidos em uma string após a criação da definição de tarefa. Veja a seguir um exemplo de entrada para uma verificação de integridade. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Ao registrar uma definição de tarefa usando o painel JSON do Console de gerenciamento da AWS, a AWS CLI ou as APIs, delimite a lista de comandos por colchetes. Veja a seguir um exemplo de entrada para uma verificação de integridade. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Um código de saída 0, sem saída de `stderr`, indica sucesso, e um código de saída diferente de zero indica falha. `interval` O período em segundos entre cada verificação de integridade. É possível especificar entre 5 e 300 segundos. O valor padrão de é 30 segundos. `timeout` O período de espera (em segundos) para que uma verificação de integridade seja bem-sucedida antes de ser considerada uma falha. É possível especificar entre 2 e 60 segundos. O valor de padrão é 5 segundos. `retries` O número de novas tentativas de uma verificação de integridade com falha até o contêiner ser considerado não íntegro. É possível especificar entre 1 e 10 novas tentativas. O valor padrão é três novas tentativas. `startPeriod` O período de carência opcional para que os contêineres possam inicializar antes de as verificações de integridade com falha serem contabilizadas no número máximo de novas tentativas. Você pode especificar um valor entre 0 e 300 segundos. Por padrão, o `startPeriod` está desabilitado. Se uma verificação de integridade for bem-sucedida dentro do `startPeriod`, então o contêiner é considerado saudável e quaisquer falhas subsequentes contam para o número máximo de novas tentativas. #### Environment `cpu` Tipo: inteiro Obrigatório: não O número de unidades de `cpu` que o agente de contêiner do Amazon ECS reservará para o contêiner. No Linux, esse parâmetro é mapeado como `CpuShares` na seção [Criar um contêiner](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Esse campo é opcional para tarefas que usam o Fargate. A quantidade total de CPU reservada para todos os contêineres dentro da tarefa deve ser menor que o valor `cpu` de nível da tarefa. Os contêineres de Linux compartilham unidades de CPU não alocadas com outros contêineres na instância de contêiner que tem a mesma proporção que a respectiva quantidade alocada. Por exemplo, suponha que você execute uma tarefa de contêiner único em um tipo de instância de núcleo único com 512 unidades de CPU especificadas para esse contêiner. Além disso, essa tarefa é a única em execução na instância de contêiner. Nesse exemplo, o contêiner pode utilizar o compartilhamento total de 1.024 unidades de CPU a qualquer momento. Porém, suponha que você tenha iniciado outra cópia da mesma tarefa nessa instância de contêiner. Cada tarefa tem garantido um mínimo de 512 unidades de CPU quando necessário. Da mesma forma, se o outro contêiner não estiver usando a CPU restante, cada contêiner poderá flutuar para o uso maior da CPU. Porém, se ambas as tarefas estiverem 100% ativas o tempo todo, elas ficarão limitadas a 512 unidades de CPU. Nas instâncias de contêiner de Linux, o daemon do Docker na instância de contêiner usa o valor de CPU para calcular as proporções de compartilhamento de CPU para contêineres em execução. O valor de compartilhamento de CPU mínimo válido permitido pelo kernel do Linux é 2 e o valor de compartilhamento de CPU máximo válido permitido pelo kernel do Linux é 262144. No entanto, o parâmetro de CPU não é necessário, e é possível usar valores de CPU abaixo de dois e superior a 262144 em suas definições de contêiner. Para valores de CPU abaixo de dois (inclusive nulo) e acima de 262144, o comportamento varia com base na versão do agente de contêiner do Amazon ECS: Nas instâncias de contêiner de Windows, a cota de CPU é imposta como uma cota absoluta. Os contêineres de Windows só têm acesso à quantidade de CPU especificada na definição de tarefa. Um valor de CPU nulo ou zero é transmitido para Docker como `0`. Em seguida, Windows interpreta esse valor como 1% de uma CPU. Para obter exemplos adicionais, consulte [Como o Amazon ECS gerencia recursos de CPU e memória](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Esse parâmetro não é compatível com contêineres hospedados no Fargate. Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obrigatório: não O número de `GPUs` físicas que o agente de contêiner do Amazon ECS reservará para o contêiner. 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 [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md). `Elastic Inference accelerator` Esse parâmetro não é compatível com contêineres hospedados no Fargate. Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obrigatório: não Para o tipo `InferenceAccelerator`, o `value` corresponde ao `deviceName` para um `InferenceAccelerator` especificado em uma definição de tarefa. Para obter mais informações, consulte [Nome do acelerador do Elastic Inference (obsoleto)](#elastic-Inference-accelerator). `essential` Tipo: booliano Obrigatório: não Suponha que o parâmetro `essential` de um contêiner esteja marcado como `true`, e que esse contêiner falhe ou seja interrompido por algum motivo. Em seguida, todos os outros contêineres que fazem parte da tarefa são interrompidos. Caso o parâmetro `essential` de um contêiner esteja marcado como `false`, a falha não afeta o restante dos contêineres em uma tarefa. Caso esse parâmetro seja omitido, um contêiner pressupõe-se que um contêiner seja essencial. Todas as tarefas devem ter pelo menos um contêiner essencial. Suponha que você tenha uma aplicação composta por vários contêineres. Em seguida, agrupe os contêineres usados para uma finalidade em comum em componentes e separe os componentes diferentes em várias definições de tarefa. Para obter mais informações, consulte [Projetar sua aplicação para o Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` As versões anteriores do agente de contêiner do Amazon ECS não lidam corretamente com parâmetros `entryPoint`. Caso você enfrente problemas para usar `entryPoint`, atualize o agente de contêiner ou informe os comandos e os argumentos como itens de matriz `command` em vez disso. Tipo: Matriz de strings Obrigatório: não O ponto de entrada passado para o contêiner. ``` "entryPoint": ["string", ...] ``` `command` Tipo: Matriz de strings Obrigatório: não O comando que é passado para o contêiner. Esse parâmetro é mapeado para `Cmd` no comando create-container e o parâmetro `COMMAND` de execução do docker. Se houver vários argumentos, certifique-se de que cada um seja uma string separada na matriz. ``` "command": ["string", ...] ``` `workingDirectory` Tipo: string Obrigatório: não O diretório de trabalho no qual executar comandos no contêiner. Esse parâmetro é mapeado para `WorkingDir` na seção [Criar um Contêiner](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) da [API remota do Docker](https://docs.docker.com/reference/api/engine/version/v1.38/) e a opção `--workdir` para [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Isso não está disponível para contêineres do Windows no Fargate. Tipo: Matriz de objeto Obrigatório: não Uma lista de arquivos que contêm as variáveis de ambiente a serem passadas para um contêiner. Esse parâmetro é mapeado para a opção `--env-file` para o comando run do docker. É possível especificar até 10 arquivos de ambiente. O arquivo deve ter uma extensão `.env`. Cada linha em um arquivo de ambiente contém uma variável de ambiente no formato `VARIABLE=VALUE`. As linhas que começam com `#` são tratadas como comentários e são ignoradas. Se houver variáveis de ambiente individuais especificadas na 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 de cima para baixo. Recomendamos usar nomes de variáveis exclusivos. Para obter mais informações, consulte [Transferência de uma variável de ambiente individual para um contêiner do Amazon ECS](taskdef-envfiles.md). `value` Tipo: String Exigido: sim O nome de recurso da Amazon (ARN) do objeto do Amazon S3 que contém o arquivo de variáveis de ambiente. `type` Tipo: String Exigido: sim Tipo de arquivo a ser usado O único valor aceito é `s3`. `environment` Tipo: Matriz de objeto Obrigatório: não As variáveis de ambiente a serem passadas para um contêiner. Esse parâmetro é mapeado para `Env` no comando create-container do docker na opção `--env` para o comando run do docker. Não recomendamos o uso de variáveis de ambiente de texto simples para informações confidenciais, tais como dados de credenciais. `name` Tipo: string Exigido: sim, quando `environment` for usado O nome da variável de ambiente. `value` Tipo: string Exigido: sim, quando `environment` for usado O valor da variável de ambiente. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Tipo: Matriz de objeto Obrigatório: não Um objeto que representa o segredo a ser exposto ao seu contêiner. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). `name` Tipo: String Exigido: sim O valor a ser definido como a variável de ambiente no contêiner. `valueFrom` Tipo: String Exigido: sim O segredo a ser exposto ao contêiner. Os valores com suporte são o nome do recurso da Amazon (ARN) completo do segredo do AWS Secrets Manager ou o ARN completo do parâmetro no Parameter Store do AWS Systems Manager. Se o parâmetro do Systems Manager Parameter Store ou do Secrets Manager existir na mesma Região da AWS que a tarefa sendo iniciada, você poderá usar o ARN completo ou o nome do segredo. Se o parâmetro existir em uma Região diferente, o ARN completo deverá ser especificado. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Configurações de rede `disableNetworking` Esse parâmetro não é compatível com tarefas que são executadas no Fargate. Tipo: booliano Obrigatório: não Quando esse parâmetro é verdadeiro, a rede é desativada dentro do contêiner. O padrão é `false`. ``` "disableNetworking": true|false ``` `links` Esse parâmetro não é compatível com tarefas que usam o modo de rede `awsvpc`. Tipo: Matriz de strings Obrigatório: não O parâmetro `link` permite que os contêineres se comuniquem entre si sem a necessidade de mapeamentos de porta. Só há suporte para esse parâmetro se o modo de rede de uma definição de tarefa estiver definido como `bridge`. O construto `name:internalName` é igual ao `name:alias` em links do Docker. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Os contêineres colocados na mesma instância de contêiner podem se comunicar entre si sem exigir links ou mapeamentos de porta de host. O isolamento de rede em uma instância de contêiner é controlado por grupos de segurança e configurações de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Tipo: string Obrigatório: não O nome de host a ser usado para o contêiner. Esse parâmetro é mapeado para `Hostname` em create-container do docker na opção `--hostname` de execução do docker. Se você estiver usando o modo de rede `awsvpc`, o parâmetro `hostname` não terá suporte. ``` "hostname": "string" ``` `dnsServers` Esse parâmetro não é compatível com tarefas sendo executadas no Fargate. Tipo: Matriz de strings Obrigatório: não Uma lista de servidores DNS apresentados ao contêiner. ``` "dnsServers": ["string", ...] ``` `extraHosts` Esse parâmetro não é compatível com tarefas que usam o modo de rede `awsvpc`. Tipo: Matriz de objeto Obrigatório: não Uma lista de nomes de host e mapeamentos de endereço IP a ser acrescentada ao arquivo `/etc/hosts` no contêiner. Esse parâmetro é mapeado para `ExtraHosts` no comando create-container do docker na opção `--add-host` de execução do docker. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Tipo: string Exigido: Sim, quando `extraHosts` são usados O nome do host a ser usado na entrada `/etc/hosts`. `ipAddress` Tipo: string Exigido: Sim, quando `extraHosts` são usados O endereço IP a ser usado na entrada `/etc/hosts`. #### Armazenamento e registro `readonlyRootFilesystem` Tipo: booliano Obrigatório: Não Quando esse parâmetro é verdadeiro, o contêiner recebe acesso somente leitura ao sistema de arquivos raiz. Esse parâmetro é mapeado para `ReadonlyRootfs` no comando create-container do docker na opção `--read-only` de execução do docker. Este parâmetro não é compatível com contêineres do Windows. O padrão é `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Tipo: Matriz de objeto Obrigatório: não Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS. `sourceVolume` Tipo: string Exigido: Sim, quando `mountPoints` são usados O nome do volume a ser montado. `containerPath` Tipo: string Exigido: Sim, quando `mountPoints` são usados O caminho no contêiner onde o volume será montado. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`. `volumesFrom` Tipo: Matriz de objeto Obrigatório: não Volumes de dados a serem montados de outro contêiner. Esse parâmetro é mapeado para `VolumesFrom` no comando create-container do docker na opção `--volumes-from` de execução do docker. `sourceContainer` Tipo: string Exigido: sim, quando `volumesFrom` for usado O nome do contêiner com base no qual montar volumes. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Tipo: objeto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) Obrigatório: não A especificação de configuração do log para o contêiner. Para obter definições de tarefa de exemplo que usam uma configuração de log, consulte [Exemplos de definições de tarefa do Amazon ECS](example_task_definitions.md). Esse parâmetro é mapeado para `LogConfig` no comando create-container do docker na opção `--log-driver` de execução do docker. Por padrão, os contêineres usam o mesmo driver de registro em log que o daemon do Docker usa. No entanto, o contêiner pode usar um driver de registro em log diferente do daemon do Docker especificando um driver de log com esse parâmetro na definição de contêiner. Para usar um driver de registro em log diferente para um contêiner, o sistema de log deve ser configurado corretamente na instância de contêiner (ou em um servidor de log diferente para opções de registro em log remotas). Considere o seguinte ao especificar uma configuração de log para seus contêineres: + O Amazon ECS oferece suporte a um subconjunto dos drivers de registro em log disponíveis para o daemon Docker. + Esse parâmetro exige a versão 1.18 ou posterior da API remota do Docker na sua instância de contêiner. + Qualquer software adicional deve ser instalado fora da tarefa. Por exemplo, os agregadores de saída Fluentd ou um host remoto executando o Logstash para o qual enviar logs Gelf. ``` "logConfiguration": { "logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Tipo: string Valores válidos: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"` Exigido: sim, quando `logConfiguration` for usado O driver de log a ser usado para o contêiner. Por padrão, os valores válidos listados anteriormente são drivers de log com os quais o agente de contêiner do Amazon ECS pode se comunicar. Os drivers de log compatíveis são `awslogs`, `splunk` e `awsfirelens`. Para obter mais informações sobre como usar o driver de log `awslogs` nas definições de tarefa para enviar os logs de contêiner ao CloudWatch Logs, consulte [Envio de logs do Amazon ECS para o CloudWatch](using_awslogs.md). Para obter mais informações sobre como usar o driver de log `awsfirelens`, consulte [Roteamento de logs personalizados](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html). Se tiver um driver personalizado que não esteja listado acima, será possível bifurcar o projeto do agente de contêiner do Amazon ECS que está [disponível no GitHub](https://github.com/aws/amazon-ecs-agent) e personalizá-lo para funcionar com esse driver. Incentivamos você a enviar solicitações pull para alterações que você gostaria de ter incluído. Porém, no momento, não oferecemos suporte à execução de cópias modificadas desse software. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. `options` Tipo: mapa de string para string Obrigatório: não O mapa chave/valor de opções de configuração a serem enviadas para o driver de log. As opções que você pode especificar dependem do driver de log. Algumas das opções que você pode especificar ao usar o roteador `awslogs` para rotear os logs para o Amazon CloudWatch incluem o seguinte: `awslogs-create-group` Obrigatório: não Especifique se você deseja que o grupo de logs seja criado automaticamente. Se essa opção não for especificada, o padrão será `false`. Sua política do IAM deve incluir a permissão `logs:CreateLogGroup` antes que você tente usar `awslogs-create-group`. `awslogs-region` Obrigatório: Sim Especifique a Região da AWS para a qual o driver de log do `awslogs` deve enviar seus logs do Docker. É possível optar por enviar todos os logs de clusters em regiões distintas para uma única região no CloudWatch Logs. Isso tem o objetivo de fazer com que todos fiquem visíveis em um único local. Caso contrário, você pode separá-los por região para mais granularidade. Certifique-se de que o grupo de logs especificado exista na região especificada com essa opção. `awslogs-group` Obrigatório: Sim Certifique-se de especificar um grupo de logs para o qual o driver de log do `awslogs` envia seus fluxos de logs. `awslogs-stream-prefix` Obrigatório: Sim Use a opção `awslogs-stream-prefix` para associar um fluxo de log ao prefixo especificado, ao nome do contêiner e ao ID da tarefa do Amazon ECS à qual o contêiner pertence. Caso você especifique um prefixo com essa opção, o fluxo de log utiliza o seguinte formato. ``` prefix-name/container-name/ecs-task-id ``` Se você não especificar um prefixo com essa opção, o fluxo de log será nomeado depois que o ID do contêiner for atribuído pelo daemon do Docker na instância de contêiner. Como é difícil rastrear logs até o contêiner que os enviou apenas com o ID do contêiner do Docker (disponível apenas na instância de contêiner), recomendamos especificar um prefixo com essa opção. Para serviços do Amazon ECS, é possível utilizar o nome do serviço como prefixo. Ao fazer isso, será possível rastrear fluxos de logs até o serviço ao qual o contêiner pertence, o nome do contêiner que os enviou e o ID da tarefa à qual o contêiner pertence. Você deve especificar um stream-prefix para seus logs para fazer com que eles apareçam no painel Logs quando o console do Amazon ECS for usado. `awslogs-datetime-format` Obrigatório: não Essa opção define um padrão de início de várias linhas no formato `strftime` em Python. Uma mensagem de log é formada por uma linha em conformidade com o padrão e as linhas seguintes que não correspondem ao padrão. A linha em conformidade é o delimitador entre as mensagens de log. Um exemplo de um caso de uso para esse formato é a análise da saída, como um despejo de pilha, que poderia ser registrado em várias entradas. O padrão correto permite que ele seja capturado em uma única entrada. Para obter mais informações, consulte [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). Você não pode configurar as opções `awslogs-datetime-format` e `awslogs-multiline-pattern`. O registro em várias linhas executa a análise da expressão regular e a correspondência de todas as mensagens de log. Isso pode ter um impacto negativo na performance do registro em log. `awslogs-multiline-pattern` Obrigatório: não Essa opção define um padrão inicial de várias linhas que usa uma expressão regular. Uma mensagem de log é formada por uma linha em conformidade com o padrão e as linhas seguintes que não correspondem ao padrão. A linha em conformidade é o delimitador entre as mensagens de log. Para obter mais informações, consulte [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Essa opção será ignorada se `awslogs-datetime-format` também estiver configurado. Você não pode configurar as opções `awslogs-datetime-format` e `awslogs-multiline-pattern`. O registro em várias linhas executa a análise da expressão regular e a correspondência de todas as mensagens de log. Isso pode ter um impacto negativo na performance do registro em log. As opções a seguir se aplicam a todos os drivers de logs compatíveis. `mode` Obrigatório: não Valores válidos: `non-blocking` \$1 `blocking` Essa opção define o modo de entrega de mensagens de log do contêiner para o driver de logs especificado usando o `logDriver`. O modo de entrega escolhido afeta a disponibilidade da aplicação quando o fluxo de logs do contêiner é interrompido. Se você usar o modo `blocking` e o fluxo de logs for interrompido, as chamadas do código do contêiner para gravar nos fluxos `stdout` e `stderr` serão bloqueadas. Como resultado, o encadeamento de logs da aplicação será bloqueado. Isso pode fazer com que a aplicação pare de responder e causar uma falha na verificação de integridade do contêiner. Se você usar o modo `non-blocking`, os registros do contêiner serão armazenados em um buffer intermediário na memória configurado com a opção `max-buffer-size`. Isso evita que a aplicação pare de responder quando não for possível enviar os logs. Recomendamos usar esse modo se você quiser garantir a disponibilidade do serviço e aceitar alguma perda de logs. Para obter mais informações, consulte [Preventing log loss with non-blocking mode in the `awslogs` container log driver](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). Você pode definir um `mode` padrão para todos os contêineres em uma determinada Região da AWS usando a configuração de conta `defaultLogDriverMode`. Se você não especificar a opção de `mode` na `logConfiguration` nem definir a configuração de conta, o Amazon ECS usará o modo `non-blocking` como padrão. Para obter mais informações sobre a configuração de conta, consulte [Modo de driver de logs padrão](ecs-account-settings.md#default-log-driver-mode). Quando o modo `non-blocking` é usado, a opção de log `max-buffer-size` controla o tamanho do buffer de anel usado para armazenamento de mensagens intermediárias. Certifique-se de especificar um tamanho de buffer adequado com base na sua aplicação. 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. Em 25 de junho de 2025, o Amazon ECS alterou o modo padrão do driver de log de `blocking` para `non-blocking` a fim de priorizar a disponibilidade das tarefas em relação ao registro em log. Para continuar usando o modo `blocking` após essa alteração, siga uma destas opções: + Defina a opção `mode` na definição `logConfiguration` do seu contêiner como `blocking`. + Defina a configuração da conta `defaultLogDriverMode` como `blocking`. `max-buffer-size` Obrigatório: não Valor padrão: `10m` Quando o modo `non-blocking` é usado, a opção de log `max-buffer-size` controla o tamanho do buffer de anel usado para armazenamento de mensagens intermediárias. Certifique-se de especificar um tamanho de buffer adequado com base na sua aplicação. Quando o buffer ficar cheio, logs adicionais não poderão ser armazenados. Os logs que não puderem ser armazenados serão perdidos. Para rotear logs usando o roteador de logs do `splunk`, você precisa especificar um `splunk-token` e um `splunk-url`. Ao usar o roteador de log `awsfirelens` para rotear logs para um destino do AWS service (Serviço da AWS) ou do AWS Partner Network para armazenamento e analytics de logs, você pode definir a opção `log-driver-buffer-limit` para limitar o número de linhas de log que são armazenadas em buffer na memória antes de serem enviadas ao contêiner do roteador de logs. Isso pode ajudar a resolver possíveis problemas de perda de logs, pois o alto throughput pode resultar na falta de memória para o buffer dentro do Docker. Para obter mais informações, consulte [Configuração de logs do Amazon ECS para obtenção de alto throughput](firelens-docker-buffer-limit.md). Outras opções que você pode especificar ao usar o `awsfirelens` para rotear logs dependem do destino. Ao exportar logs para o Amazon Data Firehose, você pode especificar a Região da AWS com a `region` e um nome para o fluxo de logs com `delivery_stream`. Ao exportar logs para o Amazon Kinesis Data Streams, você pode especificar um Região da AWS com a `region` um com e um nome de fluxo de dados com `stream`. Ao exportar logs para o Amazon OpenSearch Service, você pode especificar opções como `Name`, `Host` (endpoint do OpenSearch Service sem protocolo) `Port`, `Index`, `Type`, `Aws_auth`, `Aws_region`, `Suppress_Type_Name` e `tls`. Ao exportar logs para o Amazon S3, você pode especificar o bucket usando a opção `bucket`. Você também pode especificar `region`, `total_file_size`, `upload_timeout` e `use_put_object` como opções. Este parâmetro requer a versão 1.19 da Docker Remote API ou posterior em sua instância de contêiner. `secretOptions` Tipo: Matriz de objeto Obrigatório: não Um objeto que representa o segredo a ser passado para a configuração de log. Os segredos usados na configuração de log podem incluir tokens de autenticação, certificados ou chaves de criptografia. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). `name` Tipo: String Exigido: sim O valor a ser definido como a variável de ambiente no contêiner. `valueFrom` Tipo: String Exigido: sim O segredo a ser exposto à configuração de log do contêiner. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Tipe: objeto [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) Obrigatório: não A configuração do FireLens para o contêiner. Isso é usado para especificar e configurar um roteador de log para logs de contêiner. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Tipo: Mapa de string para string Obrigatório: não O mapa chave/valor de opções a serem usadas ao configurar o roteador de log. Esse campo é opcional e pode ser usado para especificar um arquivo de configuração personalizado ou para adicionar outros metadados, como a tarefa, a definição de tarefa, o cluster e detalhes da instância de contêiner ao evento de log. Se especificado, a sintaxe a ser usada é `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Para obter mais informações, consulte [Exemplo de definição de tarefa do Amazon ECS: rotear logs para o FireLens](firelens-taskdef.md). `type` Tipo: String Exigido: sim O roteador de log a ser usado. Os valores válidos são `fluentd` ou `fluentbit`. #### Segurança Para obter mais informações sobre a segurança de contêineres, consulte [Práticas recomendadas de segurança de tarefas e contêineres no Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html). `credentialSpecs` Tipo: Matriz de strings Obrigatório: não Uma lista de ARNs no SSM ou no Amazon S3 para um arquivo de especificação de credencial (`CredSpec`) que configura o contêiner para autenticação do Active Directory. Recomendamos o uso deste parâmetro, em vez de `dockerSecurityOptions`. O número máximo de ARNs é 1. Há dois formatos para cada ARN. credentialspecdomainless:MyARN Você usa `credentialspecdomainless:MyARN` para fornecer uma `CredSpec` com uma seção adicional para um segredo no Secrets Manager. Você fornece as credenciais de login para o domínio no segredo. Cada tarefa executada em qualquer instância de contêiner pode se associar a domínios diferentes. É possível usar esse formato sem associar a instância de contêiner a um domínio. credentialspec:MyARN Você usa `credentialspec:MyARN` para fornecer um `CredSpec` para um único domínio. Você deve associar a instância de contêiner ao domínio antes de iniciar qualquer tarefa que use essa definição de tarefa. Em ambos os formatos, substitua `MyARN` pelo ARN no SSM ou no Amazon S3. A `credspec` deve fornecer um ARN no Secrets Manager para um segredo contendo o nome de usuário, a senha e o domínio ao qual se conectar. Para maior segurança, a instância não é associada ao domínio para autenticação sem domínio. Outras aplicações na instância não podem usar as credenciais sem domínio. É possível usar esse parâmetro para executar tarefas na mesma instância, mesmo que as tarefas precisem ser associadas a domínios diferentes. Para obter mais informações, consulte [Uso de gMSAs para contêineres de Windows](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) e [Uso de gMSAs para contêineres de Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html). `user` Tipo: string Obrigatório: não O usuário a ser utilizado dentro do contêiner. Esse parâmetro é mapeado para `User` no comando create-container do docker na opção `--user` de execução do docker. Ao executar tarefas que usam o modo de rede `host`, não execute contêineres usando o usuário raiz (UID 0). Como uma prática recomendada de segurança, sempre utilize um usuário não raiz. É possível especificar o `user` usando os formatos a seguir. Se especificar um UID ou um GID, você deverá especificá-lo como um número inteiro positivo. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` Este parâmetro não é compatível com contêineres do Windows. ``` "user": "string" ``` #### Limites de recurso `ulimits` Tipo: Matriz de objeto Obrigatório: não Lista de valores `ulimit` a serem definidos para um contêiner. Esse valor substitui a configuração de cota de recursos padrão do sistema operacional. Esse parâmetro é mapeado para `Ulimits` no comando create-container do docker na opção `--ulimit` de execução do docker. 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`. Para obter mais informações, consulte [Limites de recursos de tarefa](fargate-tasks-services.md#fargate-resource-limits). Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. Este parâmetro não é compatível com contêineres do Windows. ``` "ulimits": [ { "name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack", "softLimit": integer, "hardLimit": integer } ... ] ``` `name` Tipo: string Valores válidos: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"` Exigido: Sim, quando `ulimits` são usados O `type` do `ulimit`. `hardLimit` Tipo: inteiro Exigido: Sim, quando `ulimits` são usados O limite rígido do tipo `ulimit`. O valor pode ser especificado em bytes, segundos ou como uma contagem, dependendo `type` do `ulimit`. `softLimit` Tipo: inteiro Exigido: Sim, quando `ulimits` são usados O limite flexível do tipo `ulimit`. O valor pode ser especificado em bytes, segundos ou como uma contagem, dependendo `type` do `ulimit`. #### Rótulos do Docker `dockerLabels` Tipo: mapa de string para string Obrigatório: não Um mapa de chave/valor de rótulos a ser adicionado ao contêiner. Esse parâmetro é mapeado para `Labels` no comando create-container do docker na opção `--label` de execução do docker. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. ``` "dockerLabels": {"string": "string" ...} ``` ### Outros parâmetros de definição de contêiner Os parâmetros de definição de contêiner a seguir podem ser usados durante o registro das definições de tarefa no console do Amazon ECS usando a opção **Configure via JSON** (Configurar via JSON). Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). **Topics** + [ #### Parâmetros do Linux ](#container_definition_linuxparameters) + [ #### Dependência de contêiner ](#container_definition_dependson) + [ #### Tempos limite de contêiner ](#container_definition_timeout) + [ #### Controles do sistema ](#container_definition_systemcontrols) + [ #### Interativo ](#container_definition_interactive) + [ #### Pseudoterminal ](#container_definition_pseudoterminal) #### Parâmetros do Linux `linuxParameters` Tipo: Objeto [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obrigatório: não Opções específicas do Linux que são aplicadas ao contêiner, como [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html). Não há suporte para este parâmetro em contêineres do Windows. ``` "linuxParameters": { "capabilities": { "add": ["string", ...], "drop": ["string", ...] } } ``` `capabilities` Tipo: objeto [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Obrigatório: não Os recursos do Linux para o contêiner que são descartados da configuração padrão fornecida pelo Docker. Para obter mais informações sobre esses recursos do Linux, consulte a página do manual do Linux [recursos(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html). `add` Tipo: Matriz de strings Valores válidos: `"SYS_PTRACE"` Obrigatório: não Os recursos do Linux para o contêiner que são adicionados à configuração padrão que é fornecida pelo Docker. Esse parâmetro é mapeado para `CapAdd` no comando create-container do docker na opção `--cap-add` de execução do docker. `drop` Tipo: Matriz de strings Valores válidos: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"` Obrigatório: não Os recursos do Linux para o contêiner que são removidos da configuração padrão fornecida pelo Docker. Esse parâmetro é mapeado para `CapDrop` no comando create-container do docker na opção `--cap-drop` de execução do docker. `devices` Todos os dispositivos do host a serem expostos ao contêiner. Esse parâmetro é mapeado para `Devices` no comando create-container do docker na opção `--device` de execução do docker. O parâmetro `devices` não é compatível com o tipo de inicialização do Fargate. Tipo: Matriz de objetos [Device](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obrigatório: não `hostPath` O caminho para o dispositivo na instância de contêiner host. Tipo: String Exigido: sim `containerPath` O caminho dentro do contêiner no qual expor o dispositivo do host. Tipo: string Obrigatório: não `permissions` As permissões explícitas a serem fornecidas ao contêiner para o dispositivo. Por padrão, o contêiner tem permissões para `read`, `write` e `mknod` no dispositivo. Tipo: matriz de strings Valores válidos: `read` \$1 `write` \$1 `mknod` `initProcessEnabled` Execute um processo `init` dentro do contêiner que encaminha sinais e colhe processos. Esse parâmetro é mapeado para a opção `--init` de execução do docker. Este parâmetro requer a versão 1.25 ou posterior da Docker Remote API ou posterior em sua instância de contêiner. `maxSwap` Esse parâmetro não é compatível com tarefas sendo executadas no Fargate. A quantidade total de memória de troca (em MiB) que um contêiner pode usar. Esse parâmetro será convertido na opção `--memory-swap` para execução do docker em que o valor é a soma da memória do contêiner mais o valor de `maxSwap`. Se um valor `maxSwap` de `0` for especificado, o contêiner não usará a troca. Os valores aceitos são `0` ou qualquer número inteiro positivo. Se o parâmetro `maxSwap` for omitido, o contêiner usará a configuração de troca para a instância de contêiner na qual ele está sendo executado. Um valor `maxSwap` deve ser definido para que o parâmetro `swappiness` seja usado. `sharedMemorySize` O valor do tamanho (em MiB) do volume `/dev/shm`. Esse parâmetro é mapeado para a opção `--shm-size` de execução do docker. Se você estiver usando tarefas que utilizam o Fargate, o parâmetro `sharedMemorySize` não será compatível. Tipo: inteiro `tmpfs` O caminho do contêiner, as opções de montagem e o tamanho (em MiB) da montagem do tmpfs. Esse parâmetro é mapeado para a opção `--tmpfs` de execução do docker. Tipo: Matriz de objetos [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obrigatório: não `containerPath` O caminho absoluto do arquivo no qual o volume tmpfs deve ser montado. Tipo: String Obrigatório: Sim `mountOptions` A lista de opções de montagem do volume tmpfs. Tipo: matriz de strings Obrigatório: Não Valores válidos: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"` `size` O tamanho máximo (em MiB) do volume tmpfs. Tipo: inteiro Obrigatório: Sim #### Dependência de contêiner `dependsOn` Tipo: matriz de objetos [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obrigatório: não As dependências definidas para startup e desligamento do contêiner. Um contêiner pode conter várias dependências. Quando uma dependência é definida para o startup do contêiner, ela é revertida para o desligamento do contêiner. Para ver um exemplo, consulte [Dependência de contêiner](example_task_definitions.md#example_task_definition-containerdependency). Se um contêiner não atender a uma restrição de dependência ou expirar antes de cumprir a restrição, o Amazon ECS não evoluirá contêineres dependentes para seu próximo estado. Este parâmetro exige que a tarefa ou o serviço usem a plataforma versão `1.3.0` ou posterior (Linux), ou `1.0.0` (Windows). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Tipo: String Exigido: sim O nome do contêiner que deve atender à condição especificada. `condition` Tipo: String Exigido: sim A condição de dependência do contêiner. A seguir estão as condições disponíveis e seus comportamentos. + `START`: essa condição emula o comportamento de links e volumes atuais. A condição valida que um contêiner dependente seja iniciado antes de permitir que outros contêineres sejam iniciados. + `COMPLETE`: essa condição valida que um contêiner dependente seja executado até a conclusão (encerramento) antes de permitir que outros contêineres sejam iniciados. Isso pode ser útil para os contêineres não essenciais que executam um script e depois são encerrados. Não é possível definir essa condição em um contêiner essencial. + `SUCCESS`: essa condição é igual a `COMPLETE`, mas também exige que o contêiner seja encerrado com um status `zero`. Não é possível definir essa condição em um contêiner essencial. + `HEALTHY`: essa condição valida que o contêiner dependente foi aprovado na verificação de integridade do Docker antes de permitir que outros contêineres sejam iniciados. Isso requer que o contêiner dependente tenha verificações de integridade configuradas na definição de tarefa. Essa condição é confirmada apenas no startup da tarefa. #### Tempos limite de contêiner `startTimeout` Tipo: inteiro Obrigatório: não Valores de exemplo: `120` Tempo a ser aguardado (em segundos) antes de desistir de resolver dependências para um contêiner. Por exemplo, você especifica dois contêineres em uma definição de tarefa com o `containerA` tendo uma dependência do `containerB` atingir um status `COMPLETE`, `SUCCESS` ou `HEALTHY`. Se um valor de `startTimeout` for especificado para o `containerB` e ele não atingir o status desejado nesse tempo, o `containerA` não será iniciado. Se um contêiner não atender a uma restrição de dependência ou expirar antes de cumprir a restrição, o Amazon ECS não evoluirá contêineres dependentes para seu próximo estado. Este parâmetro exige que a tarefa ou o serviço usem a plataforma versão `1.3.0` ou posterior (Linux). O valor máximo é 120 segundos. `stopTimeout` Tipo: inteiro Obrigatório: não Valores de exemplo: `120` Período (em segundos) a ser aguardado antes de o contêiner ser eliminado de maneira forçada se não for encerrado normalmente por conta própria. Este parâmetro exige que a tarefa ou o serviço usem a plataforma versão `1.3.0` ou posterior (Linux). Se o parâmetro não for especificado, então o valor padrão de 30 segundos será usado. O valor máximo é 120 segundos. #### Controles do sistema `systemControls` Tipo: objeto [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obrigatório: não Uma lista de parâmetros de kernel com namespace a ser definida no contêiner. Esse parâmetro é mapeado para `Sysctls` no comando create-container do docker e na opção `--sysctl` de execução do docker. Por exemplo, é possível definir a configuração `net.ipv4.tcp_keepalive_time` para manter conexões de longa duração. Não recomendamos que você especifique parâmetros `systemControls` relacionados à rede para vários contêineres em uma única tarefa que também use o modo de rede `awsvpc` ou `host`. Fazer isso apresenta as desvantagens a seguir: + Se você definir `systemControls` para algum contêiner, isso se aplicará a todos os contêineres na tarefa. Se você definir um `systemControls` diferente para vários contêineres em uma única tarefa, o contêiner iniciado por último determinará qual `systemControls` entra em vigor. Se você estiver configurando um namespace de recurso IPC para usar nos contêineres da tarefa, as condições a seguir serão aplicadas aos controles do sistema. Para obter mais informações, consulte [Modo IPC](#task_definition_ipcmode). + Para tarefas que usam o modo IPC `host`, o namespace IPC `systemControls` não é compatível. + Para tarefas que usam o modo IPC de `task`, os valores de `systemControls` do namespace IPC serão aplicados a todos os contêineres em uma tarefa. Este parâmetro não é compatível com contêineres do Windows. Só há suporte para o parâmetro para tarefas hospedadas no AWS Fargate que usem a versão da plataforma `1.4.0` ou posterior (Linux). Não há suporte para isso nos contêineres do Windows no Fargate. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Tipo: string Obrigatório: não O parâmetro de kernel com namespace para o qual definir um `value`. Valores de namespace IPC válidos: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` e `Sysctls`, que comecem com `"fs.mqueue.*"` Valores de namespace de rede válidos: `Sysctls`, que comece com `"net.*"`. No Fargate, apenas os `Sysctls` com namespace existentes dentro do contêiner são aceitos. Há suporte para todos esses valores no Fargate. `value` Tipo: string Obrigatório: não O valor do parâmetro de kernel com namespace especificado em `namespace`. #### Interativo `interactive` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, você pode implantar aplicações em contêineres que exigem a alocação de `stdin` ou `tty`. Esse parâmetro é mapeado para `OpenStdin` no comando create-container do docker na opção `--interactive` de execução do docker. O padrão é `false`. #### Pseudoterminal `pseudoTerminal` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, um TTY é alocado. Esse parâmetro é mapeado para `Tty` no comando create-container do docker na opção `--tty` de execução do docker. O padrão é `false`. ## Nome do acelerador do Elastic Inference (obsoleto) Requisito do recurso acelerador Elastic Inference para a definição de tarefa. **nota** O Amazon Elastic Inference (EI) não está mais disponível para clientes. Os seguintes parâmetros são permitidos em uma definição de tarefa: `deviceName` Tipo: String Exigido: sim O nome do dispositivo do acelerador de inferência elástica. O `deviceName` também deve ser referenciado em uma definição de contêiner, consulte [Elastic Inference accelerator](#ContainerDefinition-elastic-inference). `deviceType` Tipo: String Exigido: sim O acelerador de inferência elástica a ser usado. ## Configuração do proxy `proxyConfiguration` Tipo: objeto [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obrigatório: não Os detalhes de configuração do proxy do App Mesh. Este parâmetro não é compatível com contêineres do Windows. ``` "proxyConfiguration": { "type": "APPMESH", "containerName": "string", "properties": [ { "name": "string", "value": "string" } ] } ``` `type` Tipo: string Valor: `APPMESH` Obrigatório: não O tipo de proxy. O único valor aceito é `APPMESH`. `containerName` Tipo: String Exigido: sim O nome do contêiner que serve como proxy do App Mesh. `properties` Tipo: matriz de objetos [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html) Obrigatório: não O conjunto de parâmetros de configuração de rede para fornecer o plugin Container Network Interface (CNI), especificado como pares de chave/valor. + `IgnoredUID`: (obrigatório) o ID de usuário (UID) do contêiner de proxy conforme definido pelo parâmetro `user` em uma definição de contêiner. Isso é usado para garantir que o proxy ignore seu próprio tráfego. Se `IgnoredGID` for especificado, esse campo poderá estar vazio. + `IgnoredGID`: (obrigatório) o ID de grupo (GID) do contêiner de proxy conforme definido pelo parâmetro `user` em uma definição de contêiner. Isso é usado para garantir que o proxy ignore seu próprio tráfego. Se `IgnoredUID` for especificado, esse campo poderá estar vazio. + `AppPorts`: (obrigatório) a lista de portas usadas pelo aplicativo. O tráfego de rede para essas portas é encaminhado para `ProxyIngressPort` e `ProxyEgressPort`. + `ProxyIngressPort`: (obrigatório) especifica a porta para a qual o tráfego de entrada para `AppPorts` é direcionado. + `ProxyEgressPort`: (obrigatório) especifica a porta para a qual o tráfego de saída de `AppPorts` é direcionado. + `EgressIgnoredPorts`: (obrigatório) o tráfego de saída para essas portas especificadas é ignorado e não é redirecionado para `ProxyEgressPort`. Ele pode ser uma lista vazia. + `EgressIgnoredIPs`: (obrigatório) o tráfego de saída para esses endereços IP especificados é ignorado e não é redirecionado para `ProxyEgressPort`. Ele pode ser uma lista vazia. `name` Tipo: string Obrigatório: não O nome do par de chave/valor. `value` Tipo: string Obrigatório: não O valor do par de chave/valor. ## Volumes Se preferir, ao registrar uma definição de tarefa, é possível especificar uma lista de volumes a serem passados para o daemon do Docker em uma instância de contêiner, que se tornará disponível para o acesso de outros contêineres da mesma instância de contêiner. A seguir estão os tipos de volumes de dados que podem ser usados. + Volumes do Amazon EBS: fornece armazenamento em blocos econômico, durável e de alto desempenho para workloads em contêineres com uso intenso de dados. Você pode anexar um volume do Amazon EBS por tarefa do Amazon ECS ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Os volumes do Amazon EBS são compatíveis com as tarefas do Linux hospedadas no Fargate. Para obter mais informações, consulte [Uso de volumes do Amazon EBS com o Amazon ECS](ebs-volumes.md). + Volumes do Amazon EFS: oferece armazenamento de arquivos simples, escalável e persistente para uso com tarefas do Amazon ECS. Com o Amazon EFS, a capacidade de armazenamento é elástica. Ela aumenta e diminui automaticamente à medida que arquivos são adicionados e removidos. As aplicações podem ter o armazenamento de que precisam, quando precisam. Os volumes do Amazon EFS são compatíveis com as tarefas hospedadas no Fargate. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md). + Volumes do FSx para Windows File Server: fornece servidores de arquivos Microsoft Windows totalmente gerenciados. Esses servidores têm o suporte de um sistema de arquivos do Windows. Ao usar o FSx for Windows File Server junto com o Amazon ECS, você pode provisionar tarefas do Windows com armazenamento de arquivos persistente, distribuído, compartilhado e estático. Para obter mais informações, consulte [Uso de volumes do FSx para Windows File Server com Amazon ECS](wfsx-volumes.md). Não há suporte para essa opção nos contêineres do Windows no Fargate. + Montagens vinculadas: um arquivo ou diretório do computador host é montado em um contêiner. Volumes de host de montagem vinculada são compatíveis ao executar tarefas. Para usar os volumes de host de montagens bind, especifique um `host` e um valor `sourcePath` opcional em sua definição de tarefa. Para obter mais informações, consulte [Opções de armazenamento para tarefas do Amazon ECS](using_data_volumes.md). Os parâmetros a seguir são permitidos em uma definição de contêiner. `name` Tipo: string Obrigatório: não O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner. `host` Obrigatório: não O parâmetro `host` é usado para vincular o ciclo de vida da montagem bind à instância host do Amazon EC2, em vez da tarefa, e onde ela está armazenada. Caso o parâmetro `host` esteja vazio, o daemon do Docker atribui um caminho host para o volume de dados, mas os dados não têm garantia de persistir depois que os contêineres associados deixarem de ser executados. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. O parâmetro `sourcePath` é compatível apenas quando se utilizam tarefas hospedadas em instâncias do Amazon EC2 ou em instâncias gerenciadas do Amazon ECS. `sourcePath` Tipo: string Obrigatório: não Quando o parâmetro `host` é usado, especifique um `sourcePath` para declarar o caminho na instância host do Amazon EC2 que é apresentada ao contêiner. Caso esse parâmetro esteja vazio, o daemon do Docker atribui um caminho host para você. Caso o parâmetro `host` contenha um local de arquivo `sourcePath`, o volume de dados persistirá no local especificado na instância host do Amazon EC2 até você excluí-lo manualmente. Caso o valor `sourcePath` não exista na instância host do Amazon EC2, o daemon do Docker o criará. Caso o local exista, o conteúdo da pasta do caminho de origem é exportado. `configuredAtLaunch` Tipo: booliano Obrigatório: não Especifica se um volume é configurável na execução. Quando definido como `true`, você pode configurar o volume ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Quando definido como `true`, não será possível fornecer outra configuração de volume na definição da tarefa. Esse parâmetro deve ser definido como `true` para configurar um volume do Amazon EBS para anexação a uma tarefa. Definir `configuredAtLaunch` como `true` e adiar a configuração do volume para a fase de execução permite criar definições de tarefas que não estão restritas a um tipo de volume ou a configurações de volume específicas. Isso torna a definição de tarefa reutilizável em diferentes ambientes de execução. Para obter mais informações, consulte [Volumes do Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html). `dockerVolumeConfiguration` Tipo: objeto [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado ao usar volumes do Docker. Os volumes do Docker só são compatíveis ao executar tarefas em instâncias do EC2. Os contêineres do Windows só são compatíveis com o uso do driver `local`. Para usar montagens bind, em vez disso, especifique um `host`. `scope` Tipo: string Valores válidos: `task` \$1 `shared` Obrigatório: não O escopo para o volume do Docker, que determina o ciclo de vida. Os volumes do Docker que são delimitados para uma `task` são provisionados automaticamente quando a tarefa é iniciada e destruídos quando a tarefa é interrompida. Volumes do Docker delimitados como `shared` são mantidos após a interrupção da tarefa. `autoprovision` Tipo: booliano Valor padrão: `false` Obrigatório: não Se o valor for `true`, o volume de Docker será criado se ele ainda não existir. Esse campo só será usado se `scope` for `shared`. Se `scope` for `task`, esse parâmetro deverá ser omitido. `driver` Tipo: string Obrigatório: não O driver do volume do Docker a ser usado. O valor do driver deve corresponder ao nome do driver fornecido pelo Docker porque esse nome é usado no posicionamento de tarefas. Se o driver foi instalado usando a CLI de plug-in do Docker, use `docker plugin ls` para recuperar o nome do driver na instância de contêiner. Se o driver foi instalado usando outro método, use a descoberta de plug-in do Docker para recuperar o nome do driver. `driverOpts` Tipo: string Obrigatório: não Um mapa de opções específicas do driver do Docker pelas quais passar. Esse parâmetro é mapeado para `DriverOpts` na seção Criar um volume da API remota do Docker. `labels` Tipo: string Obrigatório: não Metadados personalizados para adicionar ao volume do Docker. `efsVolumeConfiguration` Tipo: objeto [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado quando volumes Amazon EFS são usados. `fileSystemId` Tipo: String Exigido: sim A ID do sistema de arquivamento Amazon EFS a ser usada. `rootDirectory` Tipo: string Obrigatório: Não O diretório dentro do sistema de arquivamento Amazon EFS a ser montado como diretório raiz dentro do host. Se esse parâmetro for omitido, a raiz do volume do Amazon EFS será usada. Especificar `/` tem o mesmo efeito que omitir esse parâmetro. Se um ponto de acesso do EFS for especificado em `authorizationConfig`, o parâmetro de diretório raiz deverá ser omitido ou definido como `/`, o que imporá o caminho definido no ponto de acesso do EFS. `transitEncryption` Tipo: string Valores válidos: `ENABLED` \$1 `DISABLED` Obrigatório: não Especifica se a criptografia deve ou não ser habilitada para dados do Amazon EFS em trânsito entre o host do Amazon ECS e o servidor do Amazon EFS. A criptografia de trânsito deverá ser habilitada se a autorização do IAM do Amazon EFS for usada. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Criptografar dados em trânsito](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) no *Guia do usuário do Amazon Elastic File System*. `transitEncryptionPort` Tipo: inteiro Obrigatório: não A porta a ser usada ao enviar dados criptografados entre o host do Amazon ECS e o servidor do Amazon EFS. Caso não especifique uma porta de criptografia em trânsito, a tarefa usará a estratégia de seleção de porta usada pelo assistente de montagem do Amazon EFS. Para mais informações, consulte [Auxiliar de Montagem EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) no *Guia de Usuário Amazon Elastic File System*. `authorizationConfig` Tipo: objeto [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) Obrigatório: não Detalhes de configuração de autorização do sistema de arquivamento Amazon EFS. `accessPointId` Tipo: Sequência Obrigatório: não ID do ponto de acesso a ser usado. Se um ponto de acesso for especificado, o valor do diretório raiz em `efsVolumeConfiguration` deve ser omitido ou definido como `/`, o que imporá o caminho definido no ponto de acesso do EFS. Se um ponto de acesso for usado, a criptografia em trânsito deverá ser habilitada em `EFSVolumeConfiguration`. Para mais informações, consulte [Trabalhando com Pontos de Acesso Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) no *Guia de Usuário Amazon Elastic File System*. `iam` Tipo: string Valores válidos: `ENABLED` \$1 `DISABLED` Obrigatório: não Especifica se é necessário ou não usar o perfil do IAM para a tarefa do Amazon ECS estabelecida em uma definição de tarefa ao montar o sistema de arquivos do Amazon EFS. Em caso positivo, a criptografia de trânsito deve estar habilitada em `EFSVolumeConfiguration`. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Funções do IAM para tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). `FSxWindowsFileServerVolumeConfiguration` Tipo: objeto [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Obrigatório: Sim Esse parâmetro é especificado quando você está usando um sistema de arquivos do [Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) para armazenamento de tarefas. `fileSystemId` Tipo: String Exigido: sim O ID do sistema de arquivos do FSx for Windows File Server a ser usado. `rootDirectory` Tipo: String Exigido: sim O diretório no sistema de arquivos do FSx for Windows File Server que deve ser montado como o diretório raiz dentro do host. `authorizationConfig` `credentialsParameter` Tipo: String Exigido: sim As opções de credencial de autorização. **opções:** + O nome do recurso da Amazon (ARN) do segredo do [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + ARN de um parâmetro do [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Tipo: String Exigido: sim Um nome de domínio totalmente qualificado hospedado por um diretório do [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ou por um Active Directory do EC2 auto-hospedado. ## Tags Quando você registra uma definição de tarefa, pode especificar opcionalmente etiquetas de metadados aplicadas à definição de tarefa. As etiquetas ajudam você a categorizar e organizar sua definição de tarefa. Cada tag consiste em uma chave e um valor opcional. Defina ambos. Para obter mais informações, consulte [Marcação de recursos do Amazon ECS](ecs-using-tags.md). **Importante** Não adicione informações de identificação pessoal nem outras informações confidenciais ou sigilosas em tags. As tags são acessíveis a muitos serviços da AWS, incluindo faturamento. As tags não devem ser usadas para dados privados ou confidenciais. Os parâmetros a seguir são permitidos em um objeto de etiqueta. `key` Tipo: string Obrigatório: não Uma parte de um par de chave/valor que compõe uma tag. Uma chave é um rótulo geral que age como uma categoria para valores de tag mais específicos. `value` Tipo: string Obrigatório: não A parte opcional de um par de chave/valor que compõe uma tag. Um valor atua como um descritor dentro de uma categoria de tag (chave). ## Outros parâmetros de definição de tarefa Os parâmetros de definição de tarefa a seguir podem ser usados durante o registro das definições de tarefa no console do Amazon ECS usando a opção **Configure via JSON** (Configurar via JSON). Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). **Topics** + [ ### Armazenamento temporário ](#task_definition_ephemeralStorage) + [ ### Modo IPC ](#task_definition_ipcmode) + [ ### Modo PID ](#task_definition_pidmode) + [ ### Injeção de falhas ](#task_definition_faultInjection) ### Armazenamento temporário `ephemeralStorage` Tipo: objeto [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Obrigatório: não A quantidade de armazenamento temporário (em GB) a ser alocado para a tarefa. Esse parâmetro é usado para expandir a quantidade total de armazenamento temporário, além da quantidade padrão, para tarefas hospedadas no AWS Fargate. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md). Este parâmetro é compatível apenas com a plataforma versão `1.4.0` ou posterior (Linux), ou `1.0.0` ou posterior (Windows). ### Modo IPC `ipcMode` Esse parâmetro não é compatível com tarefas sendo executadas no Fargate. Tipo: string Obrigatório: não O namespace de recurso IPC a ser usado para os contêineres na tarefa. Os valores válidos são `host`, `task` ou `none`. Se o `host` for especificado, todos os contêineres dentro das tarefas que especificaram o modo IPC `host` na mesma instância de contêiner compartilham os mesmos recursos IPC com a instância do Amazon EC2 do host. Se `task` for especificado, todos os contêineres dentro da tarefa especificada compartilharão os mesmos recursos IPC. Se `none` for especificado, os recursos IPC nos contêineres de uma tarefa serão privados e não serão compartilhados com outros contêineres em uma tarefa ou na instância de contêiner. Se nenhum valor for especificado, o compartilhamento do namespace de recurso IPC dependerá da configuração do daemon do Docker na instância de contêiner. Se o modo IPC `host` for usado, haverá um risco elevado de exposição indesejada do namespace IPC. Se você estiver definindo parâmetros de kernel com namespace que usa `systemControls` para os contêineres na tarefa, os itens a seguir serão aplicados ao seu namespace de recurso IPC. + Para tarefas que usam o modo IPC `host`, o namespace IPC relacionado `systemControls` não é compatível. + Para tarefas que usam o modo IPC `task`, `systemControls` relacionados ao namespace IPC serão aplicados a todos os contêineres em uma tarefa. **nota** Esse parâmetro não é compatível com os contêineres do Windows ou tarefas que usam o tipo de inicialização Fargate. ### Modo PID `pidMode` Tipo: string Valores válidos: `host` \$1 `task` Obrigatório: não O namespace do processo a ser usado para os contêineres na tarefa. Os valores válidos são `host` ou `task`. Em contêineres do Linux, o único valor válido é `task`. Por exemplo, o monitoramento de arquivos associados pode precisar que `pidMode` acesse informações sobre outros contêineres em execução na mesma tarefa. Se a `task` for especificada, todos os contêineres da tarefa especificada compartilharão o mesmo namespace de processo. Se nenhum valor for especificado, o padrão será um namespace privado para cada contêiner. **nota** Só há suporte para o parâmetro para tarefas hospedadas no AWS Fargate que usem a versão da plataforma `1.4.0` ou posterior (Linux). Não há suporte para isso nos contêineres do Windows no Fargate. ### Injeção de falhas `enableFaultInjection` Tipo: booliano Valores válidos: `true` \$1 `false` Obrigatório: não Se esse parâmetro estiver definido como `true`, na carga útil de uma tarefa, o Amazon ECS e o Fargate aceitam solicitações de injeção de falhas dos contêineres da tarefa. Esse parâmetro é definido como por padrão `false`. # Parâmetros de definição de tarefa do Amazon ECS para o Amazon EC2 As definições de tarefa são divididas em partes separadas: a família de tarefas, o perfil de tarefas do AWS Identity and Access Management (IAM), o modo de rede, definições de contêiner, volumes, restrições de posicionamento de tarefas e capacidade. As definições de família e de contêiner são obrigatórias em uma definição de tarefa. Por outro lado, a função de tarefa, o modo da rede, volumes, restrições de posicionamento de tarefa e o tipo de inicialização são opcionais. É possível usar esses parâmetros em um arquivo JSON para configurar sua definição de tarefa. Veja a seguir descrições mais detalhadas de cada parâmetro de definição de tarefa para o Amazon EC2. ## Família `family` Tipo: String Exigido: sim Ao registrar uma definição de tarefa, você dá a ela uma família, semelhante a um nome para várias versões da definição de tarefa, especificada com um número de revisão. A primeira definição de tarefa registrada em uma determinada família recebe uma revisão 1, e todas as definições de tarefa registradas depois receberão um número de revisão sequencial. ## Capacidade Ao registrar uma definição de tarefa, você pode especificar a capacidade segundo a qual o Amazon ECS deve validar a definição de tarefa. Se a definição de tarefa não for validada em relação às compatibilidades especificadas, uma exceção de cliente será retornada. O seguinte parâmetro é permitido em uma definição de tarefa. `requiresCompatibilities` Tipo: Matriz de strings Obrigatório: não Valores válidos: `EC2` A capacidade segundo a qual a definição de tarefa é validada. Isso inicia uma verificação para garantir que todos os parâmetros usados na definição de tarefa atendam aos requisitos do Amazon EC2. ## Função do para tarefa `taskRoleArn` Tipo: string Obrigatório: não Ao registrar uma definição de tarefa, você pode fornecer uma função de tarefa para uma função do IAM que permita que os contêineres da permissão de tarefa chame as APIs da AWS especificadas nas políticas associadas em seu nome. Para obter mais informações, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md). Quando você inicia a AMI do Windows Server otimizada para o Amazon ECS, os perfis do IAM para tarefas no Windows exigem que a opção `-EnableTaskIAMRole` seja definida. Seus contêineres também devem executar algum código de configuração para usar o recurso. Para obter mais informações, consulte [Configuração adicional de instância do Windows no Amazon EC2](task-iam-roles.md#windows_task_IAM_roles). ## Função do para execução de tarefas `executionRoleArn` Tipo: string Obrigatório: Condicional O nome do recurso da Amazon (ARN) da função de execução de tarefas que concede ao agente de contêiner do Amazon ECS permissão para fazer chamadas de API da AWS em seu nome. A função do IAM para execução da tarefa é necessária dependendo dos requisitos da sua tarefa. Para obter mais informações, consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md). ## Modo de rede `networkMode` Tipo: string Obrigatório: não O modo de rede do Docker a ser usado para os contêineres na tarefa. Para tarefas do Amazon ECS hospedadas em instâncias do Linux do Amazon EC2, os valores válidos são `none`, `bridge`, `awsvpc` e `host`. Se nenhum modo de rede for especificado, o modo de rede padrão será `bridge`. Para tarefas do Amazon ECS hospedadas em instâncias do Windows do Amazon EC2, os valores válidos são `default` e `awsvpc`. Se nenhum modo de rede for especificado, o modo de rede `default` será usado. Caso o modo de rede estiver definido como `none`, os contêineres da tarefa não terão conectividade externa e os mapeamentos de porta não poderão ser especificados na definição de contêiner. Se o modo da rede for `bridge`, a tarefa usará a rede virtual integrada do Docker no Linux, que é executada em cada instância do Amazon EC2 que hospeda a tarefa. A rede virtual integrada no Linux usa o driver de rede `bridge` do Docker. Se o modo de rede for `host`, a tarefa usará a rede do host que ignora a rede virtual integrada do Docker mapeando as portas de contêiner diretamente para a ENI da instância do Amazon EC2 que hospeda a tarefa. Os mapeamentos dinâmicos de portas não podem ser usados nesse modo de rede. Um contêiner em uma definição de tarefa que use esse modo deve especificar um número de `hostPort` específico. Um número de porta em um host não pode ser usado por várias tarefas. Como resultado, não é possível executar várias tarefas da mesma definição de tarefa em uma única instância do Amazon EC2. Ao executar tarefas que usam o modo de rede `host`, não execute contêineres usando o usuário raiz (UID 0) para melhor segurança. Como uma prática recomendada de segurança, sempre utilize um usuário não raiz. Se o modo de rede for `awsvpc`, será alocada uma interface de rede elástica para a tarefa e você deverá especificar uma `NetworkConfiguration` ao criar um serviço ou executar uma tarefa com a definição de tarefa. Para obter mais informações, consulte [Opções da rede de tarefas do Amazon ECS para o EC2](task-networking.md). Se o modo da rede for `default`, a tarefa usará a rede virtual integrada do Docker no Windows, que é executada em cada instância do Amazon EC2 que hospeda a tarefa. A rede virtual integrada no Windows usa o driver de rede `nat` do Docker. Os modos de rede `host` e `awsvpc` oferecem a melhor performance de rede para contêineres, pois usam a pilha de rede do Amazon EC2. Com os modos de rede `host` e `awsvpc`, as portas do contêiner expostas são mapeadas diretamente para a porta do host correspondente (para o modo de rede do `host`) ou para a porta de interface de rede elástica anexada (para o modo de rede `awsvpc`). Por causa disso, não é possível usar mapeamentos dinâmicos de portas de host. O modo de rede permitido depende do sistema operacional da instância do EC2 subjacente. Se for o Linux, qualquer modo de rede pode ser usado. Se for o Windows, podem ser usados os modos `default` e `awsvpc`. ## Plataforma de runtime `operatingSystemFamily` Tipo: string Obrigatório: Condicional Padrão: LINUX Ao registrar uma definição de tarefa, você especifica a família do sistema operacional. Os valores válidos são `LINUX`, `WINDOWS_SERVER_2025_FULL`, `WINDOWS_SERVER_2025_CORE`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2019_FULL` e `WINDOWS_SERVER_2019_CORE`, `WINDOWS_SERVER_2016_FULL`, `WINDOWS_SERVER_2004_CORE` e `WINDOWS_SERVER_20H2_CORE`. Todas as definições de tarefa usadas em um serviço devem ter o mesmo valor para esse parâmetro. Quando uma definição de tarefa faz parte de um serviço, esse valor deve corresponder ao valor `platformFamily` do serviço. `cpuArchitecture` Tipo: string Obrigatório: Condicional Ao registrar uma definição de tarefa, você especifica a arquitetura de CPU. Os valores válidos são `X86_64` e `ARM64`. Se você não especificar um valor, o Amazon ECS tentará colocar tarefas na arquitetura de CPU disponível com base na configuração do provedor de capacidade. Para garantir que as tarefas sejam colocadas em uma arquitetura de CPU específica, informe um valor para `cpuArchitecture` na definição de tarefa. Todas as definições de tarefa usadas em um serviço devem ter o mesmo valor para esse parâmetro. Quando você tem tarefas do Linux, pode definir o valor como `ARM64`. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads do ARM de 64 bits](ecs-arm64.md). ## Tamanho da tarefa Ao registrar uma definição de tarefa, você pode especificar o total de CPU e memória usados para a tarefa. Isso é separado dos valores de `cpu` e `memory` no nível de definição de contêiner. Para tarefas hospedadas em instâncias do Amazon EC2, esses campos são opcionais. **nota** Os parâmetros de CPU e memória em nível de tarefa são ignorados para contêineres do Windows. É recomendável especificar recursos em nível de contêiner para contêineres do Windows. `cpu` Tipo: string Obrigatório: Condicional Este parâmetro não é compatível com contêineres do Windows. O limite rígido de unidades de CPU a ser apresentado para a tarefa. 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. Quando a definição de tarefa for registrada, um valor de vCPU será convertido em um inteiro indicando as unidades de CPU. Esse campo é opcional. Se o seu cluster não tiver registrado instâncias de contêiner com as unidades de CPU solicitadas disponíveis, ocorrerá uma falha na tarefa. Os valores compatível são de `0.125` vCPUs a `192` vCPUs. `memory` Tipo: string Obrigatório: Condicional Este parâmetro não é compatível com contêineres do Windows. O limite fixo de memória a ser apresentada para a tarefa. É possível especificar valores de memória na definição de tarefa como uma string em mebibytes (MiB) ou gigabytes (GB). Por exemplo, você pode especificar um valor de memória como `3072` em MiB ou `3 GB` em GB. Quando a definição de tarefa for registrada, um valor em GB será convertido em um inteiro indicando o MiB. Esse campo é opcional e qualquer valor pode ser usado. Se um valor de memória no nível de tarefa for especificado, o valor de memória no nível de contêiner será opcional. Se o seu cluster não tiver registrado instâncias de contêiner com a memória solicitada disponível, ocorrerá uma falha na tarefa. É possível maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância. Para obter mais informações, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). ## Definições de contêiner Ao registrar uma definição de tarefa, você deve especificar uma lista de definições de contêiner passadas para o daemon do Docker em uma instância de contêiner. Os parâmetros a seguir são permitidos em uma definição de contêiner. **Topics** + [ ### Parâmetros padrão de definição de contêiner ](#standard_container_definition_params_ec2) + [ ### Parâmetros avançados de definição de contêiner ](#advanced_container_definition_params_ec2) + [ ### Outros parâmetros de definição de contêiner ](#other_container_definition_params_ec2) ### Parâmetros padrão de definição de contêiner Os parâmetros de definição de tarefa a seguir são obrigatórios ou usados na maioria das definições de contêiner. **Topics** + [ #### Nome ](#container_definition_name_ec2) + [ #### Imagem ](#container_definition_image_ec2) + [ #### Memória ](#container_definition_memory_ec2) + [ #### Mapeamentos de porta ](#container_definition_portmappings_ec2) + [ #### Credenciais de repositório privado ](#container_definition_repositoryCredentials_ec2) #### Nome `name` Tipo: String Exigido: sim O nome de um contêiner. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Se estiver vinculando vários contêineres em uma definição de tarefa, o `name` de um contêiner poderá ser informado no `links` de outro contêiner. Isso deve ser feito para conectar os contêineres. #### Imagem `image` Tipo: String Exigido: sim A imagem usada para iniciar um contêiner. Essa string é passada diretamente para o daemon do Docker. Por padrão, as imagens no registro do Docker Hub estão disponíveis. Você também pode especificar outros repositórios com `repository-url/image:tag` ou `repository-url/image@digest`. São permitidos até 255 letras (caixa alta e baixa), números, hifens, sublinhados, dois pontos, ponto, barras e sinais numéricos. Esse parâmetro é mapeado para `Image` no comando create-container do docker e no parâmetro `IMAGE` do comando run do docker. + Quando uma nova tarefa é iniciada, o agente do contêiner do Amazon ECS obtém a versão mais recente da imagem especificada e a tag do contêiner a ser usado. No entanto, as atualizações subsequentes feitas em um repositório de imagens não são propagadas para tarefas já em execução. + Quando não é especificada uma tag ou um resumo no caminho da imagem na definição da tarefa, o agente de contêiner do Amazon ECS usa a tag `latest` para extrair a imagem especificada. + As atualizações subsequentes para um repositório de imagens não são propagadas para tarefas já em execução. + As imagens em registros privados são suportadas. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). + As imagens nos repositórios do Amazon ECR podem ser especificadas usando a convenção de nomenclatura completa `registry/repository:tag` ou `registry/repository@digest` (por exemplo, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` ou `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + As imagens em repositórios oficiais no Docker Hub usam um único nome (por exemplo, `ubuntu` ou `mongo`). + Imagens em outros repositórios Docker Hub são qualificadas com um nome de organização (por exemplo, `amazon/amazon-ecs-agent`). + Imagens em outros repositórios online também são qualificadas por um nome de domínio (por exemplo, `quay.io/assemblyline/ubuntu`). `versionConsistency` Tipo: string Valores válidos: `enabled`\$1`disabled` Obrigatório: não Especifica se o Amazon ECS resolverá a tag de imagem do contêiner fornecida na definição do contêiner em um resumo de imagem. Por padrão, esse comportamento é `enabled`. Se você definir o valor de um contêiner como `disabled`, o Amazon ECS não resolverá a tag da imagem do contêiner como um resumo e usará o URI da imagem original especificado na definição do contêiner para implantação. Para obter mais informações sobre resolução de imagem do contêiner, consulte [Resolução da imagem do contêiner](deployment-type-ecs.md#deployment-container-image-stability). #### Memória `memory` Tipo: inteiro Obrigatório: não A quantidade (em MiB) de memória a ser apresentada ao contêiner. Caso tente exceder a memória especificada aqui, o contêiner será excluído. A quantidade total de memória reservada para todos os contêineres dentro da tarefa deve ser menor que o valor da tarefa `memory`, se estiver especificado. Esse parâmetro é mapeado para `Memory` no comando create-container do docker na opção `--memory` de execução do docker. Você deve especificar um valor de memória ao nível de tarefa ou um valor de memória ao nível de contêiner. Se você especificar um nível de contêiner `memory` e um valor de `memoryReservation`, o valor de `memory` deverá ser maior que o valor de `memoryReservation`. Caso você especifique `memoryReservation`, o valor é subtraído dos recursos de memória disponíveis para a instância de contêiner na qual o contêiner está colocado. Caso contrário, o valor de `memory` é usado. O daemon para Docker 20.10.0 ou versão posterior reserva no mínimo 6 MiB de memória para um contêiner. Por isso, não especifique menos de 6 MiB de memória para os seus contêineres. O daemon para Docker 19.03.13-ce ou versão anterior reserva no mínimo 4 MiB de memória para um contêiner. Por isso, não especifique menos de 4 MiB de memória para os seus contêineres. Se você deseja maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). `memoryReservation` Tipo: inteiro Obrigatório: não O limite flexível (em MiB) de memória a ser reservado para o contêiner. Quando a memória do sistema estiver em contenção, o Docker tentará manter a memória do contêiner dentro desse limite flexível. Entrentanto, seu contêiner pode usar mais memória quando necessário. O contêiner pode consumir até o limite rígido especificado pelo parâmetro `memory` (se aplicável), ou toda a memória disponível na instância de contêiner, o que ocorrer primeiro. Esse parâmetro é mapeado para `MemoryReservation` no comando create-container do docker na opção `--memory-reservation` de execução do docker. Se um valor de memória no nível de tarefa não for especificado, será necessário especificar um número inteiro diferente de zero para um ou ambos `memory` ou `memoryReservation` em uma definição de contêiner. Caso você especifique ambos, `memory` deve ser maior que `memoryReservation`. Caso você especifique `memoryReservation`, o valor é subtraído dos recursos de memória disponíveis para a instância de contêiner na qual o contêiner está colocado. Caso contrário, o valor de `memory` é usado. Por exemplo, suponha que seu contêiner normalmente use 128 MiB de memória, mas às vezes chegue a 256 MiB de memória por períodos curtos. É possível definir um `memoryReservation` de 128 MiB e um limite rígido de `memory` de 300 MiB. Essa configuração permite que contêiner reservasse apenas 128 MiB de memória dos recursos restantes na instância de contêiner. Ao mesmo tempo, essa configuração também possibilita que o contêiner utilize mais recursos de memória quando necessário. Este parâmetro não é compatível com contêineres do Windows. O daemon para Docker 20.10.0 ou versão posterior reserva no mínimo 6 MiB de memória para um contêiner. Por isso, não especifique menos de 6 MiB de memória para os seus contêineres. O daemon para Docker 19.03.13-ce ou versão anterior reserva no mínimo 4 MiB de memória para um contêiner. Por isso, não especifique menos de 4 MiB de memória para os seus contêineres. Se você deseja maximizar a utilização de recursos fornecendo às tarefas o máximo de memória possível para um determinado tipo de instância, consulte [Reserva de memória da instância de contêiner do Linux no Amazon ECS](memory-management.md). #### Mapeamentos de porta `portMappings` Tipo: Matriz de objeto Obrigatório: não Os mapeamentos de portas expõem as portas de rede do seu contêiner ao mundo externo. Isso permite que os clientes acessem sua aplicação. Também é usado para comunicação entre contêineres dentro da mesma tarefa. Para definições de tarefa que usam o modo de rede `awsvpc`, apenas especifique `containerPort`. A `hostPort` é sempre ignorada e a porta do contêiner é automaticamente mapeada para uma porta aleatória de alto número no host. Os mapeamentos de porta no Windows usam o endereço de gateway `NetNAT`, e não o `localhost`. Não há loopback para mapeamentos de porta no Windows, de modo que você não pode acessar a porta mapeada de um contêiner no próprio host. A maioria dos campos desse parâmetro (incluindo `containerPort`, `hostPort`, `protocol`) é mapeada para `PortBindings` no comando create-container do docker e a opção `--publish` de execução do docker. Caso o modo de rede de uma definição de tarefa seja definido como `host`, as portas host devem ser indefinidas ou corresponder à porta de contêiner no mapeamento de porta. Quando a tarefa obter o status `RUNNING`, as atribuições automáticas e manuais da porta do contêiner e do host estarão visíveis nos seguintes locais: + Console: a seção **Network Bindings** (Associações de rede) de uma descrição de contêiner para uma tarefa selecionada. + AWS CLI: a seção `networkBindings` do resultado do comando **describe-tasks**. + API: a resposta `DescribeTasks`. + Metadados: o endpoint de metadados da tarefa. `appProtocol` Tipo: string Obrigatório: não O protocolo da aplicação usado no mapeamento da porta. Esse parâmetro só se aplica ao Service Connect. Recomendamos que você defina esse parâmetro para que seja consistente com o protocolo usado por sua aplicação. Se você definir esse parâmetro, o Amazon ECS adicionará o tratamento de conexão específico do protocolo ao proxy do Service Connect. Se você definir esse parâmetro, o Amazon ECS adicionará telemetria específica de protocolo no console do Amazon ECS e no CloudWatch. Se você não definir um valor para esse parâmetro, o TCP será usado. No entanto, o Amazon ECS não adiciona telemetria específica de protocolo para TCP. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). Valores de protocolo válidos: `"http" | "http2" | "grpc" ` `containerPort` Tipo: inteiro Exigido: Sim, quando `portMappings` são usados O número da porta no contêiner vinculado à porta host atribuída automaticamente ou especificada pelo usuário. Para as tarefas que usam o modo de rede `awsvpc`, você usa `containerPort` para especificar as portas expostas. Suponha que você esteja usando contêineres em uma tarefa com os provedores de capacidade do EC2 e especifique uma porta de contêiner, e não uma porta de host. Em seguida, seu contêiner receberá automaticamente uma porta de host no intervalo de portas temporárias. Para obter mais informações, consulte `hostPort`. Os mapeamentos de porta atribuídos automaticamente dessa maneira não contam para a cota de 100 portas reservadas de uma instância de contêiner. `containerPortRange` Tipo: string Obrigatório: não O intervalo de números de porta no contêiner vinculado ao intervalo de portas host mapeado dinamicamente. Você só pode definir esse parâmetro usando a API `register-task-definition`. A opção está disponível no parâmetro `portMappings`. Para obter mais informações, consulte [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html), na *Referência da AWS Command Line Interface*. As regras a seguir se aplicam quando você especifica um `containerPortRange`: + Você deve usar o modo de rede `bridge` ou o modo de rede `awsvpc`. + Esse parâmetro está disponível para os sistemas operacionais Windows e Linux. + A instância de contêiner deve ter pelo menos a versão 1.67.0 do agente do contêiner e pelo menos a versão 1.67.0-1 do pacote `ecs-init` + É possível especificar no máximo 100 intervalos de portas para cada contêiner. + Você não especifica um `hostPortRange`. O valor do `hostPortRange` é definido da seguinte forma: + Para contêineres em uma tarefa com o modo de rede `awsvpc`, o `hostPort` é definido com o mesmo valor que `containerPort`. Essa é uma estratégia de mapeamento estático. + Para contêineres em uma tarefa com o modo de rede `bridge`, o agente do Amazon ECS encontra portas de host abertas no intervalo temporário padrão e as passa ao Docker para vinculá-las às portas do contêiner. + Os valores válidos de `containerPortRange` estão entre 1 e 65535. + Uma porta só pode ser incluída em um mapeamento de portas para cada contêiner. + Não é possível especificar intervalos de portas sobrepostos. + A primeira porta no intervalo deve ser menor que a última porta no intervalo. + O Docker recomenda que você desative o docker-proxy no arquivo de configuração do daemon do Docker quando tiver um grande número de portas. Para obter mais informações, consulte [Issue \$111185](https://github.com/moby/moby/issues/11185) no GitHub. Para obter informações sobre como desativar o docker-proxy no arquivo de configuração do daemon do Docker, consulte [Daemon do Docker](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) no *Guia do desenvolvedor do Amazon ECS*. É possível chamar [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) para visualizar o `hostPortRange`, que são as portas do host vinculadas às portas do contêiner. Os intervalos de portas não estão incluídos nos eventos de tarefas do Amazon ECS que são enviados ao EventBridge. Para obter mais informações, consulte [Automatização de respostas a erros do Amazon ECS usando o EventBridge](cloudwatch_event_stream.md). `hostPortRange` Tipo: Sequência Obrigatório: não O intervalo de números de portas no host que é usado com a vinculação de rede. Isso é atribuído pelo Docker e fornecido pelo agente do Amazon ECS. `hostPort` Tipo: inteiro Obrigatório: não O número da porta na instância de contêiner a ser reservado para o contêiner. É possível especificar uma porta de host não reservada para o mapeamento da porta do contêiner. Isso é conhecido como mapeamento *estático* da porta do host. Ou é possível omitir a `hostPort` (ou configurá-la como `0`) ao especificar uma `containerPort`. Seu contêiner recebe automaticamente uma porta no intervalo de portas temporárias para o sistema operacional e a versão Docker da instância de contêiner. Isso é conhecido como mapeamento *dinâmico* da porta do host. O intervalo de portas temporárias padrão para a versão 1.6.0 e posterior do Docker é listado na instância em `/proc/sys/net/ipv4/ip_local_port_range`. Se esse parâmetro do kernel não estiver disponível, será usado o intervalo de portas temporárias padrão de `49153–65535`. Não tente especificar uma porta de host no intervalo de portas transitório. Isso ocorre porque essas portas são reservadas para atribuição automática. Em geral, as portas abaixo de `32768` estão fora do intervalo de portas temporárias. Você pode usar a configuração `ECS_DYNAMIC_HOST_PORT_RANGE` na configuração do agente de contêiner do ECS para especificar um intervalo personalizado para portas de host atribuídas dinamicamente. Isso pode ser útil se suas tarefas falharem ao iniciar devido a conflitos de portas com outros processos na instância de contêiner, como conexões de saída que também usam portas do intervalo de portas efêmeras. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). As portas reservadas padrão são `22` para SSH, as portas do Docker `2375` e`2376` e as portas do agente de contêiner do Amazon ECS `51678-51680`. Qualquer porta de host que tenha sido especificada pelo usuário anteriormente para uma tarefa em execução também é reservada enquanto a tarefa está em execução. Depois que uma tarefa é interrompida, a porta do host é liberada. As portas reservadas atuais são exibidas em `remainingResources` da saída **describe-container-instances**. Uma instância de contêiner pode ter até 100 portas reservadas por vez, incluindo as portas reservadas padrão. As portas atribuídas automaticamente não contam em relação à cota de 100 portas reservadas. `name` Tipo: string Obrigatório: não, obrigatório para que o Service Connect e o VPC Lattice sejam configurados em um serviço Nome que é usado para o mapeamento da porta. Esse parâmetro só se aplica ao Service Connect e ao VPC Lattice. Esse parâmetro é o nome que você usa na configuração do Service Connect e do VPC Lattice de um serviço. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). No exemplo a seguir, ambos os campos obrigatórios para o Service Connect e o VPC Lattice são usados. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Tipo: string Obrigatório: não O protocolo usado no mapeamento da porta. Os valores válidos são `tcp` e `udp`. O padrão é `tcp`. Só `tcp` é compatível com o Service Connect. Lembre-se de que `tcp` estará implícito se esse campo não estiver definido. O suporte a UDP só está disponível em instâncias de contêiner que foram iniciadas com a versão 1.2.0 ou posterior do agente de contêiner do Amazon ECS (como a AMI `amzn-ami-2015.03.c-amazon-ecs-optimized`) ou com agentes de contêiner que tenham sido atualizados para a versão 1.3.0 ou posterior. Para atualizar o agente de contêiner para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md). Caso você esteja especificando uma porta host, use a seguinte sintaxe: ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Caso você queira uma porta host atribuída automaticamente, use a seguinte sintaxe: ``` "portMappings": [ { "containerPort": integer } ... ] ``` #### Credenciais de repositório privado `repositoryCredentials` Tipo: objeto [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obrigatório: não As credenciais do repositório para autenticação de registro privado. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). `credentialsParameter` Tipo: string Exigido: Sim, quando `repositoryCredentials` são usados O nome de recurso da Amazon (ARN) do segredo que contém as credenciais do repositório privado. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). Quando você usa a API do Amazon ECS, a AWS CLI ou os AWS SDKs, se o segredo existir na mesma região da tarefa que estiver sendo executada, será possível usar o ARN completo ou o nome do segredo. Ao usar o Console de gerenciamento da AWS, é preciso especificar o ARN completo do segredo. Veja a seguir um trecho de uma definição de tarefa que mostra os parâmetros necessários. ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Parâmetros avançados de definição de contêiner Os parâmetros avançados de definição de contêiner a seguir fornecem recursos estendidos ao comando run do docker usado para iniciar contêineres nas instâncias de contêiner do Amazon ECS. **Topics** + [ #### Política de reinicialização ](#container_definition_restart_policy_ec2) + [ #### Verificação de integridade ](#container_definition_healthcheck_ec2) + [ #### Environment ](#container_definition_environment_ec2) + [ #### Configurações de rede ](#container_definition_network_ec2) + [ #### Armazenamento e registro ](#container_definition_storage_ec2) + [ #### Segurança ](#container_definition_security_ec2) + [ #### Limites de recurso ](#container_definition_limits_ec2) + [ #### Rótulos do Docker ](#container_definition_labels_ec2) #### Política de reinicialização `restartPolicy` A política de reinicialização do contêiner e os parâmetros de configuração associados. Quando você configura uma política de reinicialização para um contêiner, o Amazon ECS pode reiniciar o contêiner sem precisar substituir a tarefa. Para obter mais informações, consulte [Reiniciar contêineres individuais em tarefas do Amazon ECS com políticas de reinicialização de contêineres](container-restart-policy.md). `enabled` Tipo: booliano Obrigatório: Sim Especifica se uma política de reinicialização está habilitada para o contêiner. `ignoredExitCodes` Tipo: matriz de inteiros Obrigatório: não Uma lista de códigos de saída que o Amazon ECS ignorará e não tentará reiniciar. Você pode especificar um máximo de 50 códigos de saída de contêiner. Por padrão, o Amazon ECS não ignora nenhum código de saída. `restartAttemptPeriod` Tipo: inteiro Obrigatório: não A quantidade de tempo (em segundos) que o contêiner deve ser executado antes de uma tentativa de reinicialização. Um contêiner só pode ser reiniciado uma vez a cada `restartAttemptPeriod` segundos. Se um contêiner não puder ser executado nesse período e sair mais cedo, ele não será reiniciado. Você pode especificar um `restartAttemptPeriod` mínimo de 60 segundos e um `restartAttemptPeriod` máximo de 1800 segundos. Por padrão, um contêiner deve ser executado por 300 segundos antes de ser reiniciado. #### Verificação de integridade `healthCheck` O comando da verificação de integridade de contêiner e os parâmetros de configuração associados para o contêiner. Para obter mais informações, consulte [Como determinar a integridade das tarefas do Amazon ECS usando verificações de integridade de contêineres](healthcheck.md). `command` Uma matriz de strings que representa o comando executado pelo contêiner para determinar se ela está íntegra. A matriz de strings pode começar com `CMD` para executar os argumentos de comando diretamente ou `CMD-SHELL` para executar o comando com o shell padrão do contêiner. Se nenhuma for especificado, `CMD` será usada. Ao registrar uma definição de tarefa no Console de gerenciamento da AWS, use uma lista de comandos separados por vírgulas. Esses comandos serão convertidos em uma string após a criação da definição de tarefa. Veja a seguir um exemplo de entrada para uma verificação de integridade. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Ao registrar uma definição de tarefa usando o painel JSON do Console de gerenciamento da AWS, a AWS CLI ou as APIs, delimite a lista de comandos por colchetes. Veja a seguir um exemplo de entrada para uma verificação de integridade. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Um código de saída 0, sem saída de `stderr`, indica sucesso, e um código de saída diferente de zero indica falha. `interval` O período em segundos entre cada verificação de integridade. É possível especificar entre 5 e 300 segundos. O valor padrão de é 30 segundos. `timeout` O período de espera (em segundos) para que uma verificação de integridade seja bem-sucedida antes de ser considerada uma falha. É possível especificar entre 2 e 60 segundos. O valor de padrão é 5 segundos. `retries` O número de novas tentativas de uma verificação de integridade com falha até o contêiner ser considerado não íntegro. É possível especificar entre 1 e 10 novas tentativas. O valor padrão é três novas tentativas. `startPeriod` O período de carência opcional para que os contêineres possam inicializar antes de as verificações de integridade com falha serem contabilizadas no número máximo de novas tentativas. É possível especificar entre 0 e 300 segundos. Por padrão, o `startPeriod` está desabilitado. Se uma verificação de integridade for bem-sucedida dentro do `startPeriod`, então o contêiner é considerado saudável e quaisquer falhas subsequentes contam para o número máximo de novas tentativas. #### Environment `cpu` Tipo: inteiro Obrigatório: não O número de unidades de `cpu` que o agente de contêiner do Amazon ECS reservará para o contêiner. No Linux, esse parâmetro é mapeado como `CpuShares` na seção [Criar um contêiner](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). É possível determinar o número de unidades de CPU disponíveis para cada tipo de instância do Amazon EC2. Para fazer isso, multiplique o número de vCPUs listadas para esse tipo de instância na página de detalhes [Instâncias do Amazon EC2](https://aws.amazon.com/ec2/instance-types/) por 1.024. Os contêineres de Linux compartilham unidades de CPU não alocadas com outros contêineres na instância de contêiner que tem a mesma proporção que a respectiva quantidade alocada. Por exemplo, suponha que você execute uma tarefa de contêiner único em um tipo de instância de núcleo único com 512 unidades de CPU especificadas para esse contêiner. Além disso, essa tarefa é a única em execução na instância de contêiner. Nesse exemplo, o contêiner pode utilizar o compartilhamento total de 1.024 unidades de CPU a qualquer momento. Porém, suponha que você tenha iniciado outra cópia da mesma tarefa nessa instância de contêiner. Cada tarefa tem garantido um mínimo de 512 unidades de CPU quando necessário. Da mesma forma, se o outro contêiner não estiver usando a CPU restante, cada contêiner poderá flutuar para o uso maior da CPU. Porém, se ambas as tarefas estiverem 100% ativas o tempo todo, elas ficarão limitadas a 512 unidades de CPU. Nas instâncias de contêiner de Linux, o daemon do Docker na instância de contêiner usa o valor de CPU para calcular as proporções de compartilhamento de CPU para contêineres em execução. O valor de compartilhamento de CPU mínimo válido permitido pelo kernel do Linux é 2 e o valor de compartilhamento de CPU máximo válido permitido pelo kernel do Linux é 262144. No entanto, o parâmetro de CPU não é necessário, e é possível usar valores de CPU abaixo de dois e superior a 262144 em suas definições de contêiner. Para valores de CPU abaixo de dois (inclusive nulo) e acima de 262144, o comportamento varia com base na versão do agente de contêiner do Amazon ECS: + **Versões de agente <= 1.1.0**: os valores de CPU nulo e zero são passados para o Docker como 0. O Docker, em seguida, converte esse valor para 1.024 compartilhamentos de CPU. Os valores de CPU de um são passados para o Docker como um, que o kernel do Linux converte para dois compartilhamentos de CPU. + **Versões de agente >= 1.2.0**: os valores nulo, zero e de CPU de 1 são passados para o Docker como dois compartilhamentos de CPU. + **Versões do agente >= 1.84.0:** valores de CPU maiores que 256 vCPU são passados para Docker como 256, o que equivale a 262144 compartilhamentos de CPU. Nas instâncias de contêiner de Windows, a cota de CPU é imposta como uma cota absoluta. Os contêineres de Windows só têm acesso à quantidade de CPU especificada na definição de tarefa. Um valor de CPU nulo ou zero é transmitido para Docker como `0`. Em seguida, Windows interpreta esse valor como 1% de uma CPU. Para obter exemplos adicionais, consulte [Como o Amazon ECS gerencia recursos de CPU e memória](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obrigatório: não O número de `GPUs` físicas que o agente de contêiner do Amazon ECS reservará para o contêiner. 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 [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md). Não há suporte para este parâmetro em contêineres do Windows. `Elastic Inference accelerator` Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obrigatório: não Para o tipo `InferenceAccelerator`, o `value` corresponde ao `deviceName` para um `InferenceAccelerator` especificado em uma definição de tarefa. Para obter mais informações, consulte [Nome do acelerador do Elastic Inference (obsoleto)](task_definition_parameters.md#elastic-Inference-accelerator). Não há suporte para este parâmetro em contêineres do Windows. `essential` Tipo: booliano Obrigatório: não Suponha que o parâmetro `essential` de um contêiner esteja marcado como `true`, e que esse contêiner falhe ou seja interrompido por algum motivo. Em seguida, todos os outros contêineres que fazem parte da tarefa são interrompidos. Caso o parâmetro `essential` de um contêiner esteja marcado como `false`, a falha não afeta o restante dos contêineres em uma tarefa. Caso esse parâmetro seja omitido, um contêiner pressupõe-se que um contêiner seja essencial. Todas as tarefas devem ter pelo menos um contêiner essencial. Suponha que você tenha uma aplicação composta por vários contêineres. Em seguida, agrupe os contêineres usados para uma finalidade em comum em componentes e separe os componentes diferentes em várias definições de tarefa. Para obter mais informações, consulte [Projetar sua aplicação para o Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` As versões anteriores do agente de contêiner do Amazon ECS não lidam corretamente com parâmetros `entryPoint`. Caso você enfrente problemas para usar `entryPoint`, atualize o agente de contêiner ou informe os comandos e os argumentos como itens de matriz `command` em vez disso. Tipo: Matriz de strings Obrigatório: não O ponto de entrada passado para o contêiner. ``` "entryPoint": ["string", ...] ``` `command` Tipo: Matriz de strings Obrigatório: não O comando que é passado para o contêiner. Esse parâmetro é mapeado para `Cmd` no comando create-container e o parâmetro `COMMAND` de execução do docker. Se houver vários argumentos, certifique-se de que cada um seja uma string separada na matriz. ``` "command": ["string", ...] ``` `workingDirectory` Tipo: string Obrigatório: não O diretório de trabalho no qual executar comandos no contêiner. Esse parâmetro é mapeado para `WorkingDir` na seção [Criar um contêiner](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) da [Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) e a opção `--workdir` para [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Tipo: Matriz de objeto Obrigatório: não Uma lista de arquivos que contêm as variáveis de ambiente a serem passadas para um contêiner. Esse parâmetro é mapeado para a opção `--env-file` para o comando run do docker. Quando o FIPS está habilitado, nomes de bucket que contêm pontos (.) (por exemplo, amzn-s3-demo-bucket1.name.example) não são compatíveis. Ter pontos (.) no nome do bucket impede que a tarefa seja iniciada porque o agente não consegue extrair o arquivo da variável de ambiente do Amazon S3. Isso não está disponível para contêineres Windows. É possível especificar até 10 arquivos de ambiente. O arquivo deve ter uma extensão `.env`. Cada linha em um arquivo de ambiente contém uma variável de ambiente no formato `VARIABLE=VALUE`. As linhas que começam com `#` são tratadas como comentários e são ignoradas. Se houver variáveis de ambiente individuais especificadas na 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 de cima para baixo. Recomendamos usar nomes de variáveis exclusivos. Para obter mais informações, consulte [Transferência de uma variável de ambiente individual para um contêiner do Amazon ECS](taskdef-envfiles.md). `value` Tipo: String Exigido: sim O nome de recurso da Amazon (ARN) do objeto do Amazon S3 que contém o arquivo de variáveis de ambiente. `type` Tipo: String Exigido: sim Tipo de arquivo a ser usado O único valor aceito é `s3`. `environment` Tipo: Matriz de objeto Obrigatório: não As variáveis de ambiente a serem passadas para um contêiner. Esse parâmetro é mapeado para `Env` no comando create-container do docker na opção `--env` para o comando run do docker. Não recomendamos o uso de variáveis de ambiente de texto simples para informações confidenciais, tais como dados de credenciais. `name` Tipo: string Exigido: sim, quando `environment` for usado O nome da variável de ambiente. `value` Tipo: string Exigido: sim, quando `environment` for usado O valor da variável de ambiente. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Tipo: Matriz de objeto Obrigatório: não Um objeto que representa o segredo a ser exposto ao seu contêiner. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). `name` Tipo: String Exigido: sim O valor a ser definido como a variável de ambiente no contêiner. `valueFrom` Tipo: String Exigido: sim O segredo a ser exposto ao contêiner. Os valores com suporte são o nome do recurso da Amazon (ARN) completo do segredo do AWS Secrets Manager ou o ARN completo do parâmetro no Parameter Store do AWS Systems Manager. Se o parâmetro do Systems Manager Parameter Store ou do Secrets Manager existir na mesma Região da AWS que a tarefa sendo iniciada, você poderá usar o ARN completo ou o nome do segredo. Se o parâmetro existir em uma Região diferente, o ARN completo deverá ser especificado. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Configurações de rede `disableNetworking` Tipo: booliano Obrigatório: não Quando esse parâmetro é verdadeiro, a rede é desativada dentro do contêiner. Não há suporte para esse parâmetro em contêineres do Windows ou tarefas que usem o modo de rede `awsvpc`. O padrão é `false`. ``` "disableNetworking": true|false ``` `links` Tipo: Matriz de strings Obrigatório: não O parâmetro `link` permite que os contêineres se comuniquem entre si sem a necessidade de mapeamentos de porta. Só há suporte para esse parâmetro se o modo de rede de uma definição de tarefa estiver definido como `bridge`. O construto `name:internalName` é igual ao `name:alias` em links do Docker. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Não há suporte para esse parâmetro em contêineres do Windows ou tarefas que usem o modo de rede `awsvpc`. Os contêineres colocados na mesma instância de contêiner podem se comunicar entre si sem exigir links ou mapeamentos de porta de host. O isolamento de rede em uma instância de contêiner é controlado por grupos de segurança e configurações de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Tipo: string Obrigatório: não O nome de host a ser usado para o contêiner. Esse parâmetro é mapeado para `Hostname` em create-container do docker na opção `--hostname` de execução do docker. Se você estiver usando o modo de rede `awsvpc`, o parâmetro `hostname` não terá suporte. ``` "hostname": "string" ``` `dnsServers` Tipo: Matriz de strings Obrigatório: não Uma lista de servidores DNS apresentados ao contêiner. Não há suporte para esse parâmetro em contêineres do Windows ou tarefas que usem o modo de rede `awsvpc`. ``` "dnsServers": ["string", ...] ``` `dnsSearchDomains` Tipo: Matriz de strings Obrigatório: não Padrão: ^[a-zA-Z0-9-.]\$10,253\$1[a-zA-Z0-9]\$1 Uma lista de domínios de pesquisa DNS apresentados ao contêiner. Esse parâmetro é mapeado para `DnsSearch` no comando create-container do docker na opção `--dns-search` de execução do docker. Esse parâmetro não tem suporte para contêineres do Windows ou tarefas que usam o modo de rede `awsvpc`. ``` "dnsSearchDomains": ["string", ...] ``` `extraHosts` Tipo: Matriz de objeto Obrigatório: não Uma lista de nomes de host e mapeamentos de endereço IP a ser acrescentada ao arquivo `/etc/hosts` no contêiner. Esse parâmetro é mapeado para `ExtraHosts` no comando create-container do docker na opção `--add-host` de execução do docker. Esse parâmetro não tem suporte para contêineres do Windows ou tarefas que usam o modo de rede `awsvpc`. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Tipo: string Exigido: Sim, quando `extraHosts` são usados O nome do host a ser usado na entrada `/etc/hosts`. `ipAddress` Tipo: string Exigido: Sim, quando `extraHosts` são usados O endereço IP a ser usado na entrada `/etc/hosts`. #### Armazenamento e registro `readonlyRootFilesystem` Tipo: booliano Obrigatório: Não Quando esse parâmetro é verdadeiro, o contêiner recebe acesso somente leitura ao sistema de arquivos raiz. Esse parâmetro é mapeado para `ReadonlyRootfs` no comando create-container do docker na opção `--read-only` de execução do docker. Este parâmetro não é compatível com contêineres do Windows. O padrão é `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Tipo: Matriz de objeto Obrigatório: não Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS. `sourceVolume` Tipo: string Exigido: Sim, quando `mountPoints` são usados O nome do volume a ser montado. `containerPath` Tipo: string Exigido: Sim, quando `mountPoints` são usados O caminho no contêiner onde o volume será montado. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. Em tarefas que executam o sistema operacional Windows, não modifique o valor padrão `false`. `volumesFrom` Tipo: Matriz de objeto Obrigatório: não Volumes de dados a serem montados de outro contêiner. Esse parâmetro é mapeado para `VolumesFrom` no comando create-container do docker na opção `--volumes-from` de execução do docker. `sourceContainer` Tipo: string Exigido: sim, quando `volumesFrom` for usado O nome do contêiner com base no qual montar volumes. `readOnly` Tipo: booliano Obrigatório: não Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Tipo: objeto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) Obrigatório: não A especificação de configuração do log para o contêiner. Para obter definições de tarefa de exemplo que usam uma configuração de log, consulte [Exemplos de definições de tarefa do Amazon ECS](example_task_definitions.md). Esse parâmetro é mapeado para `LogConfig` no comando create-container do docker na opção `--log-driver` de execução do docker. Por padrão, os contêineres usam o mesmo driver de registro em log que o daemon do Docker usa. No entanto, o contêiner pode usar um driver de registro em log diferente do daemon do Docker especificando um driver de log com esse parâmetro na definição de contêiner. Para usar um driver de registro em log diferente para um contêiner, o sistema de log deve ser configurado corretamente na instância de contêiner (ou em um servidor de log diferente para opções de registro em log remotas). Considere o seguinte ao especificar uma configuração de log para seus contêineres: + O Amazon ECS oferece suporte a um subconjunto dos drivers de registro em log disponíveis para o daemon Docker. + Esse parâmetro exige a versão 1.18 ou posterior da API remota do Docker na sua instância de contêiner. + O agente de contêiner do Amazon ECS executado em uma instância de contêiner deve registrar os drivers de log disponíveis na instância com a variável de ambiente `ECS_AVAILABLE_LOGGING_DRIVERS` para que os contêineres colocados nessa instância possam usar essas opções de configuração de log. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). ``` "logConfiguration": { "logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Tipo: String Valores válidos: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"` Exigido: sim, quando `logConfiguration` for usado O driver de log a ser usado para o contêiner. Por padrão, os valores válidos listados anteriormente são drivers de log com os quais o agente de contêiner do Amazon ECS pode se comunicar. Os drivers de log compatíveis são `awslogs`, `fluentd`, `gelf`, `json-file`, `journald`, `syslog`, `splunk` e `awsfirelens`. Para obter mais informações sobre como usar o driver de log `awslogs` nas definições de tarefa para enviar os logs de contêiner ao CloudWatch Logs, consulte [Envio de logs do Amazon ECS para o CloudWatch](using_awslogs.md). Para obter mais informações sobre como usar o driver de log `awsfirelens`, consulte [Roteamento de logs personalizados](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html). Se tiver um driver personalizado que não esteja listado acima, será possível bifurcar o projeto do agente de contêiner do Amazon ECS que está [disponível no GitHub](https://github.com/aws/amazon-ecs-agent) e personalizá-lo para funcionar com esse driver. Incentivamos você a enviar solicitações pull para alterações que você gostaria de ter incluído. Porém, no momento, não oferecemos suporte à execução de cópias modificadas desse software. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. `options` Tipo: mapa de string para string Obrigatório: não O mapa chave/valor de opções de configuração a serem enviadas para o driver de log. As opções que você pode especificar dependem do driver de log. Algumas das opções que você pode especificar ao usar o roteador `awslogs` para rotear os logs para o Amazon CloudWatch incluem o seguinte: `awslogs-create-group` Obrigatório: não Especifique se você deseja que o grupo de logs seja criado automaticamente. Se essa opção não for especificada, o padrão será `false`. Sua política do IAM deve incluir a permissão `logs:CreateLogGroup` antes que você tente usar `awslogs-create-group`. `awslogs-region` Obrigatório: Sim Especifique a Região da AWS para a qual o driver de log do `awslogs` deve enviar seus logs do Docker. É possível optar por enviar todos os logs de clusters em regiões distintas para uma única região no CloudWatch Logs. Isso tem o objetivo de fazer com que todos fiquem visíveis em um único local. Caso contrário, você pode separá-los por região para mais granularidade. Certifique-se de que o grupo de logs especificado exista na região especificada com essa opção. `awslogs-group` Obrigatório: Sim Certifique-se de especificar um grupo de logs para o qual o driver de log do `awslogs` envia seus fluxos de logs. `awslogs-stream-prefix` Obrigatório: opcional Use a opção `awslogs-stream-prefix` para associar um fluxo de log ao prefixo especificado, ao nome do contêiner e ao ID da tarefa do Amazon ECS à qual o contêiner pertence. Caso você especifique um prefixo com essa opção, o fluxo de log utiliza o seguinte formato. ``` prefix-name/container-name/ecs-task-id ``` Se você não especificar um prefixo com essa opção, o fluxo de log será nomeado depois que o ID do contêiner for atribuído pelo daemon do Docker na instância de contêiner. Como é difícil rastrear logs até o contêiner que os enviou apenas com o ID do contêiner do Docker (disponível apenas na instância de contêiner), recomendamos especificar um prefixo com essa opção. Para serviços do Amazon ECS, é possível utilizar o nome do serviço como prefixo. Ao fazer isso, será possível rastrear fluxos de logs até o serviço ao qual o contêiner pertence, o nome do contêiner que os enviou e o ID da tarefa à qual o contêiner pertence. Você deve especificar um stream-prefix para seus logs para fazer com que eles apareçam no painel Logs quando o console do Amazon ECS for usado. `awslogs-datetime-format` Obrigatório: não Essa opção define um padrão de início de várias linhas no formato `strftime` em Python. Uma mensagem de log é formada por uma linha em conformidade com o padrão e as linhas seguintes que não correspondem ao padrão. A linha em conformidade é o delimitador entre as mensagens de log. Um exemplo de um caso de uso para esse formato é a análise da saída, como um despejo de pilha, que poderia ser registrado em várias entradas. O padrão correto permite que ele seja capturado em uma única entrada. Para obter mais informações, consulte [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). Você não pode configurar as opções `awslogs-datetime-format` e `awslogs-multiline-pattern`. O registro em várias linhas executa a análise da expressão regular e a correspondência de todas as mensagens de log. Isso pode ter um impacto negativo na performance do registro em log. `awslogs-multiline-pattern` Obrigatório: não Essa opção define um padrão inicial de várias linhas que usa uma expressão regular. Uma mensagem de log é formada por uma linha em conformidade com o padrão e as linhas seguintes que não correspondem ao padrão. A linha em conformidade é o delimitador entre as mensagens de log. Para obter mais informações, consulte [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Essa opção será ignorada se `awslogs-datetime-format` também estiver configurado. Você não pode configurar as opções `awslogs-datetime-format` e `awslogs-multiline-pattern`. O registro em várias linhas executa a análise da expressão regular e a correspondência de todas as mensagens de log. Isso pode ter um impacto negativo na performance do registro em log. As opções a seguir se aplicam a todos os drivers de logs compatíveis. `mode` Obrigatório: não Valores válidos: `non-blocking` \$1 `blocking` Essa opção define o modo de entrega de mensagens de log do contêiner para o driver de logs especificado usando o `logDriver`. O modo de entrega escolhido afeta a disponibilidade da aplicação quando o fluxo de logs do contêiner é interrompido. Se você usar o modo `blocking` e o fluxo de logs for interrompido, as chamadas do código do contêiner para gravar nos fluxos `stdout` e `stderr` serão bloqueadas. Como resultado, o encadeamento de logs da aplicação será bloqueado. Isso pode fazer com que a aplicação pare de responder e causar uma falha na verificação de integridade do contêiner. Se você usar o modo `non-blocking`, os registros do contêiner serão armazenados em um buffer intermediário na memória configurado com a opção `max-buffer-size`. Isso evita que a aplicação pare de responder quando não for possível enviar os logs. Recomendamos usar esse modo se você quiser garantir a disponibilidade do serviço e aceitar alguma perda de logs. Para obter mais informações, consulte [Preventing log loss with non-blocking mode in the `awslogs` container log driver](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). Você pode definir um `mode` padrão para todos os contêineres em uma determinada Região da AWS usando a configuração de conta `defaultLogDriverMode`. Se você não especificar a opção de `mode` na `logConfiguration` nem definir a configuração de conta, o Amazon ECS usará o modo `non-blocking` como padrão. Para obter mais informações sobre a configuração de conta, consulte [Modo de driver de logs padrão](ecs-account-settings.md#default-log-driver-mode). Quando o modo `non-blocking` é usado, a opção de log `max-buffer-size` controla o tamanho do buffer de anel usado para armazenamento de mensagens intermediárias. Certifique-se de especificar um tamanho de buffer adequado com base na sua aplicação. 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. Em 25 de junho de 2025, o Amazon ECS alterou o modo padrão do driver de log de `blocking` para `non-blocking` a fim de priorizar a disponibilidade das tarefas em relação ao registro em log. Para continuar usando o modo `blocking` após essa alteração, siga uma destas opções: + Defina a opção `mode` na definição `logConfiguration` do seu contêiner como `blocking`. + Defina a configuração da conta `defaultLogDriverMode` como `blocking`. `max-buffer-size` Obrigatório: não Valor padrão: `10 m` Quando o modo `non-blocking` é usado, a opção de log `max-buffer-size` controla o tamanho do buffer de anel usado para armazenamento de mensagens intermediárias. Certifique-se de especificar um tamanho de buffer adequado com base na sua aplicação. Quando o buffer ficar cheio, logs adicionais não poderão ser armazenados. Os logs que não puderem ser armazenados serão perdidos. Para rotear logs usando o roteador de logs do `splunk`, você precisa especificar um `splunk-token` e um `splunk-url`. Ao usar o roteador de log `awsfirelens` para rotear logs para um destino do AWS service (Serviço da AWS) ou do AWS Partner Network para armazenamento e analytics de logs, você pode definir a opção `log-driver-buffer-limit` para limitar o número de linhas de log que são armazenadas em buffer na memória antes de serem enviadas ao contêiner do roteador de logs. Isso pode ajudar a resolver possíveis problemas de perda de logs, pois o alto throughput pode resultar na falta de memória para o buffer dentro do Docker. Para obter mais informações, consulte [Configuração de logs do Amazon ECS para obtenção de alto throughput](firelens-docker-buffer-limit.md). Outras opções que você pode especificar ao usar o `awsfirelens` para rotear logs dependem do destino. Ao exportar logs para o Amazon Data Firehose, você pode especificar a Região da AWS com a `region` e um nome para o fluxo de logs com `delivery_stream`. Ao exportar logs para o Amazon Kinesis Data Streams, você pode especificar um Região da AWS com a `region` um com e um nome de fluxo de dados com `stream`. Ao exportar logs para o Amazon OpenSearch Service, você pode especificar opções como `Name`, `Host` (endpoint do OpenSearch Service sem protocolo) `Port`, `Index`, `Type`, `Aws_auth`, `Aws_region`, `Suppress_Type_Name` e `tls`. Ao exportar logs para o Amazon S3, você pode especificar o bucket usando a opção `bucket`. Você também pode especificar `region`, `total_file_size`, `upload_timeout` e `use_put_object` como opções. Este parâmetro requer a versão 1.19 da Docker Remote API ou posterior em sua instância de contêiner. `secretOptions` Tipo: Matriz de objeto Obrigatório: não Um objeto que representa o segredo a ser passado para a configuração de log. Os segredos usados na configuração de log podem incluir tokens de autenticação, certificados ou chaves de criptografia. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). `name` Tipo: String Exigido: sim O valor a ser definido como a variável de ambiente no contêiner. `valueFrom` Tipo: String Exigido: sim O segredo a ser exposto à configuração de log do contêiner. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Tipe: objeto [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) Obrigatório: não A configuração do FireLens para o contêiner. Isso é usado para especificar e configurar um roteador de log para logs de contêiner. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Tipo: Mapa de string para string Obrigatório: não O mapa chave/valor de opções a serem usadas ao configurar o roteador de log. Esse campo é opcional e pode ser usado para especificar um arquivo de configuração personalizado ou para adicionar outros metadados, como a tarefa, a definição de tarefa, o cluster e detalhes da instância de contêiner ao evento de log. Se especificado, a sintaxe a ser usada é `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Para obter mais informações, consulte [Exemplo de definição de tarefa do Amazon ECS: rotear logs para o FireLens](firelens-taskdef.md). `type` Tipo: String Exigido: sim O roteador de log a ser usado. Os valores válidos são `fluentd` ou `fluentbit`. #### Segurança Para obter mais informações sobre a segurança de contêineres, consulte [Práticas recomendadas de segurança de tarefas e contêineres no Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html). `credentialSpecs` Tipo: Matriz de strings Obrigatório: não Uma lista de ARNs no SSM ou no Amazon S3 para um arquivo de especificação de credencial (`CredSpec`) que configura o contêiner para autenticação do Active Directory. Recomendamos o uso deste parâmetro, em vez de `dockerSecurityOptions`. O número máximo de ARNs é 1. Há dois formatos para cada ARN. credentialspecdomainless:MyARN Você usa `credentialspecdomainless:MyARN` para fornecer uma `CredSpec` com uma seção adicional para um segredo no Secrets Manager. Você fornece as credenciais de login para o domínio no segredo. Cada tarefa executada em qualquer instância de contêiner pode se associar a domínios diferentes. É possível usar esse formato sem associar a instância de contêiner a um domínio. credentialspec:MyARN Você usa `credentialspec:MyARN` para fornecer um `CredSpec` para um único domínio. Você deve associar a instância de contêiner ao domínio antes de iniciar qualquer tarefa que use essa definição de tarefa. Em ambos os formatos, substitua `MyARN` pelo ARN no SSM ou no Amazon S3. A `credspec` deve fornecer um ARN no Secrets Manager para um segredo contendo o nome de usuário, a senha e o domínio ao qual se conectar. Para maior segurança, a instância não é associada ao domínio para autenticação sem domínio. Outras aplicações na instância não podem usar as credenciais sem domínio. É possível usar esse parâmetro para executar tarefas na mesma instância, mesmo que as tarefas precisem ser associadas a domínios diferentes. Para obter mais informações, consulte [Uso de gMSAs para contêineres de Windows](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) e [Uso de gMSAs para contêineres de Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html). `privileged` Tipo: booliano Obrigatório: não Quando esse parâmetro é verdadeiro, o contêiner recebe privilégios elevados na instância de contêiner host (semelhante ao usuário `root`). Não recomendamos operar contêineres com `privileged`. Na maioria dos casos, é possível especificar os privilégios exatos necessários usando os parâmetros específicos em vez de `privileged`. Esse parâmetro é mapeado para `Privileged` no comando create-container do docker na opção `--privileged` de execução do docker. Esse parâmetro não é compatível com os contêineres do Windows ou tarefas que usam o tipo de inicialização Fargate. O padrão é `false`. ``` "privileged": true|false ``` `user` Tipo: string Obrigatório: não O usuário a ser utilizado dentro do contêiner. Esse parâmetro é mapeado para `User` no comando create-container do docker na opção `--user` de execução do docker. Ao executar tarefas que usam o modo de rede `host`, não execute contêineres usando o usuário raiz (UID 0). Como uma prática recomendada de segurança, sempre utilize um usuário não raiz. É possível especificar o `user` usando os formatos a seguir. Se especificar um UID ou um GID, você deverá especificá-lo como um número inteiro positivo. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` Este parâmetro não é compatível com contêineres do Windows. ``` "user": "string" ``` `dockerSecurityOptions` Tipo: Matriz de strings Valores válidos: "no-new-privileges" \$1 "apparmor:PROFILE" \$1 "label:*value*" \$1 "credentialspec:*CredentialSpecFilePath*" Obrigatório: não Uma lista de strings para fornecer configuração personalizada para vários sistemas de segurança. Em tarefas do Linux, esse parâmetro pode ser usado para referenciar rótulos personalizados para sistemas de segurança de vários níveis SELinux e AppArmor . Esse parâmetro pode ser usado para referenciar um arquivo de especificação de credenciais que configura um contêiner para autenticação do Active Directory. Para obter mais informações, consulte [Saiba como usar gMSAs para contêineres do Windows do Amazon EC2 para o Amazon ECS](windows-gmsa.md) e [Usar gMSA para contêineres do Linux do EC2 no Amazon ECS](linux-gmsa.md). Esse parâmetro é mapeado para `SecurityOpt` no comando create-container do docker na opção `--security-opt` de execução do docker. ``` "dockerSecurityOptions": ["string", ...] ``` O agente de contêiner do Amazon ECS em execução em uma instância de contêiner deve se registrar com as variáveis de ambiente `ECS_SELINUX_CAPABLE=true` ou `ECS_APPARMOR_CAPABLE=true` para contêineres colocados nessa instância possam usar essas opções de segurança. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). #### Limites de recurso `ulimits` Tipo: Matriz de objeto Obrigatório: não Lista de valores `ulimit` a serem definidos para um contêiner. Esse valor substitui a configuração de cota de recursos padrão do sistema operacional. Esse parâmetro é mapeado para `Ulimits` no comando create-container do docker na opção `--ulimit` de execução do docker. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. Este parâmetro não é compatível com contêineres do Windows. ``` "ulimits": [ { "name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack", "softLimit": integer, "hardLimit": integer } ... ] ``` `name` Tipo: string Valores válidos: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"` Exigido: Sim, quando `ulimits` são usados O `type` do `ulimit`. `hardLimit` Tipo: inteiro Exigido: Sim, quando `ulimits` são usados O limite rígido do tipo `ulimit`. O valor pode ser especificado em bytes, segundos ou como uma contagem, dependendo `type` do `ulimit`. `softLimit` Tipo: inteiro Exigido: Sim, quando `ulimits` são usados O limite flexível do tipo `ulimit`. O valor pode ser especificado em bytes, segundos ou como uma contagem, dependendo `type` do `ulimit`. #### Rótulos do Docker `dockerLabels` Tipo: mapa de string para string Obrigatório: não Um mapa de chave/valor de rótulos a ser adicionado ao contêiner. Esse parâmetro é mapeado para `Labels` no comando create-container do docker na opção `--label` de execução do docker. Este parâmetro requer a versão 1.18 da Docker Remote API ou posterior em sua instância de contêiner. ``` "dockerLabels": {"string": "string" ...} ``` ### Outros parâmetros de definição de contêiner Os parâmetros de definição de contêiner a seguir podem ser usados durante o registro das definições de tarefa no console do Amazon ECS usando a opção **Configure via JSON** (Configurar via JSON). Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). **Topics** + [ #### Parâmetros do Linux ](#container_definition_linuxparameters_ec2) + [ #### Dependência de contêiner ](#container_definition_dependson_ec2) + [ #### Tempos limite de contêiner ](#container_definition_timeout_ec2) + [ #### Controles do sistema ](#container_definition_systemcontrols_ec2) + [ #### Interativo ](#container_definition_interactive_ec2) + [ #### Pseudoterminal ](#container_definition_pseudoterminal_ec2) #### Parâmetros do Linux `linuxParameters` Tipo: Objeto [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obrigatório: não Opções específicas do Linux que são aplicadas ao contêiner, como [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html). Não há suporte para este parâmetro em contêineres do Windows. ``` "linuxParameters": { "capabilities": { "add": ["string", ...], "drop": ["string", ...] } } ``` `capabilities` Tipo: objeto [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities_ec2.html) Obrigatório: não Os recursos do Linux para o contêiner que são adicionados ou descartados da configuração padrão fornecida pelo Docker. Para obter mais informações sobre esses recursos do Linux, consulte a página do manual do Linux [recursos(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html). `add` Tipo: Matriz de strings Valores válidos: `"ALL" | "AUDIT_CONTROL" | "AUDIT_READ" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"` Obrigatório: não Os recursos do Linux para o contêiner que são adicionados à configuração padrão fornecida pelo Docker. Esse parâmetro é mapeado para `CapAdd` no comando create-container do docker na opção `--cap-add` de execução do docker. `add` Tipo: Matriz de strings Valores válidos: `"SYS_PTRACE"` Obrigatório: não Os recursos do Linux para o contêiner que são adicionados à configuração padrão que é fornecida pelo Docker. Esse parâmetro é mapeado para `CapAdd` no comando create-container do docker na opção `--cap-add` de execução do docker. `drop` Tipo: Matriz de strings Valores válidos: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"` Obrigatório: não Os recursos do Linux para o contêiner que são removidos da configuração padrão fornecida pelo Docker. Esse parâmetro é mapeado para `CapDrop` no comando create-container do docker na opção `--cap-drop` de execução do docker. `devices` Todos os dispositivos do host a serem expostos ao contêiner. Esse parâmetro é mapeado para `Devices` no comando create-container do docker na opção `--device` de execução do docker. Tipo: Matriz de objetos [Device](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obrigatório: não `hostPath` O caminho para o dispositivo na instância de contêiner host. Tipo: String Exigido: sim `containerPath` O caminho dentro do contêiner no qual expor o dispositivo do host. Tipo: string Obrigatório: não `permissions` As permissões explícitas a serem fornecidas ao contêiner para o dispositivo. Por padrão, o contêiner tem permissões para `read`, `write` e `mknod` no dispositivo. Tipo: matriz de strings Valores válidos: `read` \$1 `write` \$1 `mknod` `initProcessEnabled` Execute um processo `init` dentro do contêiner que encaminha sinais e colhe processos. Esse parâmetro é mapeado para a opção `--init` de execução do docker. Este parâmetro requer a versão 1.25 ou posterior da Docker Remote API ou posterior em sua instância de contêiner. `maxSwap` A quantidade total de memória de troca (em MiB) que um contêiner pode usar. Esse parâmetro será convertido na opção `--memory-swap` para execução do docker em que o valor é a soma da memória do contêiner mais o valor de `maxSwap`. Se um valor `maxSwap` de `0` for especificado, o contêiner não usará a troca. Os valores aceitos são `0` ou qualquer número inteiro positivo. Se o parâmetro `maxSwap` for omitido, o contêiner usará a configuração de troca para a instância de contêiner na qual ele está sendo executado. Um valor `maxSwap` deve ser definido para que o parâmetro `swappiness` seja usado. `sharedMemorySize` O valor do tamanho (em MiB) do volume `/dev/shm`. Esse parâmetro é mapeado para a opção `--shm-size` de execução do docker. Tipo: inteiro `swappiness` É possível usar este parâmetro para ajustar o comportamento de troca de memória de um contêiner. Um valor de `swappiness` igual a `0` evita a troca, a menos que ela seja necessária. Um valor de `swappiness` igual a `100` resulta na troca frequente das páginas. Os valores aceitos são números inteiros entre `0` e `100`. Se você não especificar um valor, será usado o valor padrão de `60`. Além disso, se você não especificar um valor para `maxSwap`, esse parâmetro será ignorado. Esse parâmetro é mapeado para a opção `--memory-swappiness` de execução do docker. Se você estiver usando tarefas no Amazon Linux 2023, não haverá suporte para o parâmetro `swappiness`. `tmpfs` O caminho do contêiner, as opções de montagem e o tamanho (em MiB) da montagem do tmpfs. Esse parâmetro é mapeado para a opção `--tmpfs` de execução do docker. Tipo: Matriz de objetos [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obrigatório: não `containerPath` O caminho absoluto do arquivo no qual o volume tmpfs deve ser montado. Tipo: String Obrigatório: Sim `mountOptions` A lista de opções de montagem do volume tmpfs. Tipo: matriz de strings Obrigatório: Não Valores válidos: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"` `size` O tamanho máximo (em MiB) do volume tmpfs. Tipo: inteiro Obrigatório: Sim #### Dependência de contêiner `dependsOn` Tipo: matriz de objetos [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obrigatório: não As dependências definidas para startup e desligamento do contêiner. Um contêiner pode conter várias dependências. Quando uma dependência é definida para o startup do contêiner, ela é revertida para o desligamento do contêiner. Para ver um exemplo, consulte [Dependência de contêiner](example_task_definitions.md#example_task_definition-containerdependency). Se um contêiner não atender a uma restrição de dependência ou expirar antes de cumprir a restrição, o Amazon ECS não evoluirá contêineres dependentes para seu próximo estado. As instâncias exigem pelo menos a versão `1.26.0` do agente de contêiner para habilitar as dependências 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 uma AMI do Amazon Linux otimizada para o Amazon ECS, sua instância precisará pelo menos da versão `1.26.0-1` do pacote `ecs-init`. Se as instâncias de contêiner são executadas na versão `20190301` ou posterior, então elas contêm as versões necessárias do agente de contêiner e do `ecs-init`. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Tipo: String Exigido: sim O nome do contêiner que deve atender à condição especificada. `condition` Tipo: String Exigido: sim A condição de dependência do contêiner. A seguir estão as condições disponíveis e seus comportamentos. + `START`: essa condição emula o comportamento de links e volumes atuais. A condição valida que um contêiner dependente seja iniciado antes de permitir que outros contêineres sejam iniciados. + `COMPLETE`: essa condição valida que um contêiner dependente seja executado até a conclusão (encerramento) antes de permitir que outros contêineres sejam iniciados. Isso pode ser útil para os contêineres não essenciais que executam um script e depois são encerrados. Não é possível definir essa condição em um contêiner essencial. + `SUCCESS`: essa condição é igual a `COMPLETE`, mas também exige que o contêiner seja encerrado com um status `zero`. Não é possível definir essa condição em um contêiner essencial. + `HEALTHY`: essa condição valida que o contêiner dependente foi aprovado na verificação de integridade do Docker antes de permitir que outros contêineres sejam iniciados. Isso requer que o contêiner dependente tenha verificações de integridade configuradas na definição de tarefa. Essa condição é confirmada apenas no startup da tarefa. #### Tempos limite de contêiner `startTimeout` Tipo: inteiro Obrigatório: não Valores de exemplo: `120` Tempo a ser aguardado (em segundos) antes de desistir de resolver dependências para um contêiner. Por exemplo, você especifica dois contêineres em uma definição de tarefa com o `containerA` tendo uma dependência do `containerB` atingir um status `COMPLETE`, `SUCCESS` ou `HEALTHY`. Se um valor de `startTimeout` for especificado para o `containerB` e ele não atingir o status desejado nesse tempo, o `containerA` não será iniciado. Se um contêiner não atender a uma restrição de dependência ou expirar antes de cumprir a restrição, o Amazon ECS não evoluirá contêineres dependentes para seu próximo estado. O valor máximo é 120 segundos. `stopTimeout` Tipo: inteiro Obrigatório: não Valores de exemplo: `120` Período (em segundos) a ser aguardado antes de o contêiner ser eliminado de maneira forçada se não for encerrado normalmente por conta própria. Se o parâmetro `stopTimeout` não for especificado, o valor definido para a variável de configuração `ECS_CONTAINER_STOP_TIMEOUT` do agente de contêiner do Amazon ECS será usada. Se nem o parâmetro `stopTimeout` nem a variável de configuração do agente `ECS_CONTAINER_STOP_TIMEOUT` forem definidos, serão usados os valores padrão de 30 segundos para contêineres de Linux e 30 segundos para contêineres de Windows. As instâncias de contêiner exigem pelo menos a versão 1.26.0 do agente de contêiner para habilitar um valor de tempo limite de interrupção 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 a AMI do Amazon Linux otimizada para o Amazon ECS, sua instância precisará pelo menos da versão 1.26.0-1 do pacote `ecs-init`. Se as instâncias de contêiner são executadas na versão `20190301` ou posterior, então elas contêm as versões necessárias do agente de contêiner e do `ecs-init`. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). #### Controles do sistema `systemControls` Tipo: objeto [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obrigatório: não Uma lista de parâmetros de kernel com namespace a ser definida no contêiner. Esse parâmetro é mapeado para `Sysctls` no comando create-container do docker e na opção `--sysctl` de execução do docker. Por exemplo, é possível definir a configuração `net.ipv4.tcp_keepalive_time` para manter conexões de longa duração. Não recomendamos que você especifique parâmetros `systemControls` relacionados à rede para vários contêineres em uma única tarefa que também use o modo de rede `awsvpc` ou `host`. Fazer isso apresenta as desvantagens a seguir: + Para tarefas que usam o modo de rede `awsvpc`, se você definir `systemControls` para qualquer contêiner, ele se aplicará a todos os contêineres na tarefa. Se você definir um `systemControls` diferente para vários contêineres em uma única tarefa, o contêiner iniciado por último determinará qual `systemControls` entra em vigor. + Para tarefas que usam o modo de rede `host`, o namespace de rede `systemControls` não é compatível. Se você estiver configurando um namespace de recurso IPC para usar nos contêineres da tarefa, as condições a seguir serão aplicadas aos controles do sistema. Para obter mais informações, consulte [Modo IPC](task_definition_parameters.md#task_definition_ipcmode). + Para tarefas que usam o modo IPC `host`, o namespace IPC `systemControls` não é compatível. + Para tarefas que usam o modo IPC de `task`, os valores de `systemControls` do namespace IPC serão aplicados a todos os contêineres em uma tarefa. Este parâmetro não é compatível com contêineres do Windows. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Tipo: string Obrigatório: não O parâmetro de kernel com namespace para o qual definir um `value`. Valores de namespace IPC válidos: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` e `Sysctls`, que comecem com `"fs.mqueue.*"` Valores de namespace de rede válidos: `Sysctls`, que comece com `"net.*"` `value` Tipo: string Obrigatório: não O valor do parâmetro de kernel com namespace especificado em `namespace`. #### Interativo `interactive` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, você pode implantar aplicações em contêineres que exigem a alocação de `stdin` ou `tty`. Esse parâmetro é mapeado para `OpenStdin` no comando create-container do docker na opção `--interactive` de execução do docker. O padrão é `false`. #### Pseudoterminal `pseudoTerminal` Tipo: booliano Obrigatório: não Quando esse parâmetro é `true`, um TTY é alocado. Esse parâmetro é mapeado para `Tty` no comando create-container do docker na opção `--tty` de execução do docker. O padrão é `false`. ## Nome do acelerador do Elastic Inference (obsoleto) Requisito do recurso acelerador Elastic Inference para a definição de tarefa. **nota** O Amazon Elastic Inference (EI) não está mais disponível para clientes. Os seguintes parâmetros são permitidos em uma definição de tarefa: `deviceName` Tipo: String Exigido: sim O nome do dispositivo do acelerador de inferência elástica. O `deviceName` também deve ser referenciado em uma definição de contêiner, consulte [Elastic Inference accelerator](task_definition_parameters.md#ContainerDefinition-elastic-inference). `deviceType` Tipo: String Exigido: sim O acelerador de inferência elástica a ser usado. ## Limitações de posicionamento de tarefa Ao registrar uma definição de tarefa, você pode fornecer restrições de posicionamento de tarefa que personalizam como o Amazon ECS posiciona tarefas. Você pode usar restrições para posicionar tarefas de acordo com a zona de disponibilidade, o tipo de instância ou os atributos personalizados. Para obter mais informações, consulte [Definição de quais instâncias de contêiner o Amazon ECS usa em tarefas](task-placement-constraints.md). Os parâmetros a seguir são permitidos em uma definição de contêiner. `expression` Tipo: string Obrigatório: não Uma expressão de idioma de consulta de cluster a ser aplicada à restrição. Para obter mais informações, consulte [Criação de expressões para definir instâncias de contêiner em tarefas do Amazon ECS](cluster-query-language.md). `type` Tipo: String Exigido: sim O tipo de restrição. Use `memberOf` para restringir a seleção a um grupo de candidatos válidos. ## Configuração do proxy `proxyConfiguration` Tipo: objeto [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obrigatório: não Os detalhes de configuração do proxy do App Mesh. Para as tarefas que usam o EC2, as instâncias de contêiner exigem pelo menos a versão 1.26.0 do agente de contêiner e pelo menos a versão 1.26.0-1 do pacote `ecs-init` para habilitar uma configuração de proxy. Se as instâncias de contêiner forem executadas na AMI otimizada para o Amazon ECS versão `20190301` ou posterior, elas conterão as versões necessárias do agente de contêiner e do `ecs-init`. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). Este parâmetro não é compatível com contêineres do Windows. ``` "proxyConfiguration": { "type": "APPMESH", "containerName": "string", "properties": [ { "name": "string", "value": "string" } ] } ``` `type` Tipo: string Valor: `APPMESH` Obrigatório: não O tipo de proxy. O único valor aceito é `APPMESH`. `containerName` Tipo: String Exigido: sim O nome do contêiner que serve como proxy do App Mesh. `properties` Tipo: matriz de objetos [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html) Obrigatório: não O conjunto de parâmetros de configuração de rede para fornecer o plugin Container Network Interface (CNI), especificado como pares de chave/valor. + `IgnoredUID`: (obrigatório) o ID de usuário (UID) do contêiner de proxy conforme definido pelo parâmetro `user` em uma definição de contêiner. Isso é usado para garantir que o proxy ignore seu próprio tráfego. Se `IgnoredGID` for especificado, esse campo poderá estar vazio. + `IgnoredGID`: (obrigatório) o ID de grupo (GID) do contêiner de proxy conforme definido pelo parâmetro `user` em uma definição de contêiner. Isso é usado para garantir que o proxy ignore seu próprio tráfego. Se `IgnoredUID` for especificado, esse campo poderá estar vazio. + `AppPorts`: (obrigatório) a lista de portas usadas pelo aplicativo. O tráfego de rede para essas portas é encaminhado para `ProxyIngressPort` e `ProxyEgressPort`. + `ProxyIngressPort`: (obrigatório) especifica a porta para a qual o tráfego de entrada para `AppPorts` é direcionado. + `ProxyEgressPort`: (obrigatório) especifica a porta para a qual o tráfego de saída de `AppPorts` é direcionado. + `EgressIgnoredPorts`: (obrigatório) o tráfego de saída para essas portas especificadas é ignorado e não é redirecionado para `ProxyEgressPort`. Ele pode ser uma lista vazia. + `EgressIgnoredIPs`: (obrigatório) o tráfego de saída para esses endereços IP especificados é ignorado e não é redirecionado para `ProxyEgressPort`. Ele pode ser uma lista vazia. `name` Tipo: string Obrigatório: não O nome do par de chave/valor. `value` Tipo: string Obrigatório: não O valor do par de chave/valor. ## Volumes Se preferir, ao registrar uma definição de tarefa, é possível especificar uma lista de volumes a serem passados para o daemon do Docker em uma instância de contêiner, que se tornará disponível para o acesso de outros contêineres da mesma instância de contêiner. A seguir estão os tipos de volumes de dados que podem ser usados. + Volumes do Amazon EBS: fornece armazenamento em blocos econômico, durável e de alto desempenho para workloads em contêineres com uso intenso de dados. Você pode anexar um volume do Amazon EBS por tarefa do Amazon ECS ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Os volumes do Amazon EBS são compatíveis com as tarefas do Linux. Para obter mais informações, consulte [Uso de volumes do Amazon EBS com o Amazon ECS](ebs-volumes.md). + Volumes do Amazon EFS: oferece armazenamento de arquivos simples, escalável e persistente para uso com tarefas do Amazon ECS. Com o Amazon EFS, a capacidade de armazenamento é elástica. Ela aumenta e diminui automaticamente à medida que arquivos são adicionados e removidos. As aplicações podem ter o armazenamento de que precisam, quando precisam. Os volumes do Amazon EFS são compatíveis. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md). + Volumes do FSx para Windows File Server: fornece servidores de arquivos Microsoft Windows totalmente gerenciados. Esses servidores têm o suporte de um sistema de arquivos do Windows. Ao usar o FSx for Windows File Server junto com o Amazon ECS, você pode provisionar tarefas do Windows com armazenamento de arquivos persistente, distribuído, compartilhado e estático. Para obter mais informações, consulte [Uso de volumes do FSx para Windows File Server com Amazon ECS](wfsx-volumes.md). Não há suporte para essa opção nos contêineres do Windows no Fargate. + Volumes do Docker: um volume gerenciado pelo Docker criado em `/var/lib/docker/volumes` na instância de host do Amazon EC2. Drivers de volume do Docker (também conhecidos como plug-ins) são usados para integrar os volumes com sistemas de armazenamento externos, como o Amazon EBS. O driver de volume `local` integrado ou um driver de volume de terceiros podem ser usados. Os volumes do Docker só são compatíveis com a execução de tarefas em instâncias do Amazon EC2. Os contêineres do Windows só são compatíveis com o uso do driver `local`. Para usar os volumes do Docker, especifique uma `dockerVolumeConfiguration` em sua definição de tarefa. + Montagens vinculadas: um arquivo ou diretório do computador host é montado em um contêiner. Os volumes de host de montagem vinculada são compatíveis. Para usar os volumes de host de montagens bind, especifique um `host` e um valor `sourcePath` opcional em sua definição de tarefa. Para obter mais informações, consulte [Opções de armazenamento para tarefas do Amazon ECS](using_data_volumes.md). Os parâmetros a seguir são permitidos em uma definição de contêiner. `name` Tipo: string Obrigatório: não O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner. `host` Obrigatório: não O parâmetro `host` é usado para vincular o ciclo de vida da montagem bind à instância host do Amazon EC2, em vez da tarefa, e onde ela está armazenada. Caso o parâmetro `host` esteja vazio, o daemon do Docker atribui um caminho host para o volume de dados, mas os dados não têm garantia de persistir depois que os contêineres associados deixarem de ser executados. Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. O parâmetro `sourcePath` é compatível apenas quando se utilizam tarefas hospedadas em instâncias do Amazon EC2 ou em instâncias gerenciadas do Amazon ECS. `sourcePath` Tipo: string Obrigatório: não Quando o parâmetro `host` é usado, especifique um `sourcePath` para declarar o caminho na instância host do Amazon EC2 que é apresentada ao contêiner. Caso esse parâmetro esteja vazio, o daemon do Docker atribui um caminho host para você. Caso o parâmetro `host` contenha um local de arquivo `sourcePath`, o volume de dados persistirá no local especificado na instância host do Amazon EC2 até você excluí-lo manualmente. Caso o valor `sourcePath` não exista na instância host do Amazon EC2, o daemon do Docker o criará. Caso o local exista, o conteúdo da pasta do caminho de origem é exportado. `configuredAtLaunch` Tipo: booliano Obrigatório: não Especifica se um volume é configurável na execução. Quando definido como `true`, você pode configurar o volume ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Quando definido como `true`, não será possível fornecer outra configuração de volume na definição da tarefa. Esse parâmetro deve ser definido como `true` para configurar um volume do Amazon EBS para anexação a uma tarefa. Definir `configuredAtLaunch` como `true` e adiar a configuração do volume para a fase de execução permite criar definições de tarefas que não estão restritas a um tipo de volume ou a configurações de volume específicas. Isso torna a definição de tarefa reutilizável em diferentes ambientes de execução. Para obter mais informações, consulte [Volumes do Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html). `dockerVolumeConfiguration` Tipo: objeto [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado ao usar volumes do Docker. Os volumes do Docker só são compatíveis ao executar tarefas em instâncias do EC2. Os contêineres do Windows só são compatíveis com o uso do driver `local`. Para usar montagens bind, em vez disso, especifique um `host`. `scope` Tipo: string Valores válidos: `task` \$1 `shared` Obrigatório: não O escopo para o volume do Docker, que determina o ciclo de vida. Os volumes do Docker que são delimitados para uma `task` são provisionados automaticamente quando a tarefa é iniciada e destruídos quando a tarefa é interrompida. Volumes do Docker delimitados como `shared` são mantidos após a interrupção da tarefa. `autoprovision` Tipo: booliano Valor padrão: `false` Obrigatório: não Se o valor for `true`, o volume de Docker será criado se ele ainda não existir. Esse campo só será usado se `scope` for `shared`. Se `scope` for `task`, esse parâmetro deverá ser omitido. `driver` Tipo: string Obrigatório: não O driver do volume do Docker a ser usado. O valor do driver deve corresponder ao nome do driver fornecido pelo Docker porque esse nome é usado no posicionamento de tarefas. Se o driver foi instalado usando a CLI de plug-in do Docker, use `docker plugin ls` para recuperar o nome do driver na instância de contêiner. Se o driver foi instalado usando outro método, use a descoberta de plug-in do Docker para recuperar o nome do driver. `driverOpts` Tipo: string Obrigatório: não Um mapa de opções específicas do driver do Docker pelas quais passar. Esse parâmetro é mapeado para `DriverOpts` na seção Criar um volume da API remota do Docker. `labels` Tipo: string Obrigatório: não Metadados personalizados para adicionar ao volume do Docker. `efsVolumeConfiguration` Tipo: objeto [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obrigatório: não Esse parâmetro é especificado quando volumes Amazon EFS são usados. `fileSystemId` Tipo: String Exigido: sim A ID do sistema de arquivamento Amazon EFS a ser usada. `rootDirectory` Tipo: string Obrigatório: Não O diretório dentro do sistema de arquivamento Amazon EFS a ser montado como diretório raiz dentro do host. Se esse parâmetro for omitido, a raiz do volume do Amazon EFS será usada. Especificar `/` tem o mesmo efeito que omitir esse parâmetro. Se um ponto de acesso do EFS for especificado em `authorizationConfig`, o parâmetro de diretório raiz deverá ser omitido ou definido como `/`, o que imporá o caminho definido no ponto de acesso do EFS. `transitEncryption` Tipo: string Valores válidos: `ENABLED` \$1 `DISABLED` Obrigatório: não Especifica se a criptografia deve ou não ser habilitada para dados do Amazon EFS em trânsito entre o host do Amazon ECS e o servidor do Amazon EFS. A criptografia de trânsito deverá ser habilitada se a autorização do IAM do Amazon EFS for usada. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Criptografar dados em trânsito](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) no *Guia do usuário do Amazon Elastic File System*. `transitEncryptionPort` Tipo: inteiro Obrigatório: não A porta a ser usada ao enviar dados criptografados entre o host do Amazon ECS e o servidor do Amazon EFS. Caso não especifique uma porta de criptografia em trânsito, a tarefa usará a estratégia de seleção de porta usada pelo assistente de montagem do Amazon EFS. Para mais informações, consulte [Auxiliar de Montagem EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) no *Guia de Usuário Amazon Elastic File System*. `authorizationConfig` Tipo: objeto [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) Obrigatório: não Detalhes de configuração de autorização do sistema de arquivamento Amazon EFS. `accessPointId` Tipo: Sequência Obrigatório: não ID do ponto de acesso a ser usado. Se um ponto de acesso for especificado, o valor do diretório raiz em `efsVolumeConfiguration` deve ser omitido ou definido como `/`, o que imporá o caminho definido no ponto de acesso do EFS. Se um ponto de acesso for usado, a criptografia em trânsito deverá ser habilitada em `EFSVolumeConfiguration`. Para mais informações, consulte [Trabalhando com Pontos de Acesso Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) no *Guia de Usuário Amazon Elastic File System*. `iam` Tipo: string Valores válidos: `ENABLED` \$1 `DISABLED` Obrigatório: não Especifica se é necessário ou não usar o perfil do IAM para a tarefa do Amazon ECS estabelecida em uma definição de tarefa ao montar o sistema de arquivos do Amazon EFS. Em caso positivo, a criptografia de trânsito deve estar habilitada em `EFSVolumeConfiguration`. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Funções do IAM para tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). `FSxWindowsFileServerVolumeConfiguration` Tipo: objeto [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Obrigatório: Sim Esse parâmetro é especificado quando você está usando um sistema de arquivos do [Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) para armazenamento de tarefas. `fileSystemId` Tipo: String Exigido: sim O ID do sistema de arquivos do FSx for Windows File Server a ser usado. `rootDirectory` Tipo: String Exigido: sim O diretório no sistema de arquivos do FSx for Windows File Server que deve ser montado como o diretório raiz dentro do host. `authorizationConfig` `credentialsParameter` Tipo: String Exigido: sim As opções de credencial de autorização. **opções:** + O nome do recurso da Amazon (ARN) do segredo do [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + ARN de um parâmetro do [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Tipo: String Exigido: sim Um nome de domínio totalmente qualificado hospedado por um diretório do [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ou por um Active Directory do EC2 auto-hospedado. ## Tags Quando você registra uma definição de tarefa, pode especificar opcionalmente etiquetas de metadados aplicadas à definição de tarefa. As etiquetas ajudam você a categorizar e organizar sua definição de tarefa. Cada tag consiste em uma chave e um valor opcional. Defina ambos. Para obter mais informações, consulte [Marcação de recursos do Amazon ECS](ecs-using-tags.md). **Importante** Não adicione informações de identificação pessoal nem outras informações confidenciais ou sigilosas em tags. As tags são acessíveis a muitos serviços da AWS, incluindo faturamento. As tags não devem ser usadas para dados privados ou confidenciais. Os parâmetros a seguir são permitidos em um objeto de etiqueta. `key` Tipo: string Obrigatório: não Uma parte de um par de chave/valor que compõe uma tag. Uma chave é um rótulo geral que age como uma categoria para valores de tag mais específicos. `value` Tipo: string Obrigatório: não A parte opcional de um par de chave/valor que compõe uma tag. Um valor atua como um descritor dentro de uma categoria de tag (chave). ## Outros parâmetros de definição de tarefa Os parâmetros de definição de tarefa a seguir podem ser usados durante o registro das definições de tarefa no console do Amazon ECS usando a opção **Configure via JSON** (Configurar via JSON). Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). **Topics** + [ ### Modo IPC ](#task_definition_ipcmode_ec2) + [ ### Modo PID ](#task_definition_pidmode_ec2) + [ ### Injeção de falhas ](#task_definition_faultInjection_ec2) ### Modo IPC `ipcMode` Tipo: string Obrigatório: não O namespace de recurso IPC a ser usado para os contêineres na tarefa. Os valores válidos são `host`, `task` ou `none`. Se o `host` for especificado, todos os contêineres dentro das tarefas que especificaram o modo IPC `host` na mesma instância de contêiner compartilham os mesmos recursos IPC com a instância do Amazon EC2 do host. Se `task` for especificado, todos os contêineres dentro da tarefa especificada compartilharão os mesmos recursos IPC. Se `none` for especificado, os recursos IPC nos contêineres de uma tarefa serão privados e não serão compartilhados com outros contêineres em uma tarefa ou na instância de contêiner. Se nenhum valor for especificado, o compartilhamento do namespace de recurso IPC dependerá da configuração do daemon do Docker na instância de contêiner. Se o modo IPC `host` for usado, haverá um risco elevado de exposição indesejada do namespace IPC. Se você estiver definindo parâmetros de kernel com namespace que usa `systemControls` para os contêineres na tarefa, os itens a seguir serão aplicados ao seu namespace de recurso IPC. + Para tarefas que usam o modo IPC `host`, o namespace IPC relacionado `systemControls` não é compatível. + Para tarefas que usam o modo IPC `task`, `systemControls` relacionados ao namespace IPC serão aplicados a todos os contêineres em uma tarefa. ### Modo PID `pidMode` Tipo: string Valores válidos: `host` \$1 `task` Obrigatório: não O namespace do processo a ser usado para os contêineres na tarefa. Os valores válidos são `host` ou `task`. Por exemplo, o monitoramento de arquivos associados pode precisar que `pidMode` acesse informações sobre outros contêineres em execução na mesma tarefa. Se o `host` for especificado, todos os contêineres das tarefas que especificaram o modo PID `host` na mesma instância de contêiner compartilharão namespace de processo com a instância do Amazon EC2 do host. Se a `task` for especificada, todos os contêineres da tarefa especificada compartilharão o mesmo namespace de processo. Se nenhum valor for especificado, o padrão será um namespace privado para cada contêiner. Se o modo PID `host` for usado, haverá um risco elevado de exposição indesejada do namespace de processo. **nota** Este parâmetro não é compatível com contêineres do Windows. ### Injeção de falhas `enableFaultInjection` Tipo: booliano Valores válidos: `true` \$1 `false` Obrigatório: não Se esse parâmetro estiver definido como `true`, na carga útil de uma tarefa, o Amazon ECS aceita solicitações de injeção de falhas dos contêineres da tarefa. Esse parâmetro é definido como por padrão `false`. # Modelo de definição de tarefa do Amazon ECS Um modelo de definição de tarefa vazio é mostrado a seguir. É possível usar esse modelo para criar a definição de tarefa que pode acabar sendo colada na área de entrada JSON do console ou salva em um arquivo e usada com a opção da AWS CLI `--cli-input-json`. Para obter mais informações, consulte [Parâmetros de definição de tarefa do Amazon ECS para o Fargate](task_definition_parameters.md). **Modelo do EC2** ``` { "family": "", "taskRoleArn": "", "executionRoleArn": "", "networkMode": "none", "containerDefinitions": [ { "name": "", "image": "", "repositoryCredentials": { "credentialsParameter": "" }, "cpu": 0, "memory": 0, "memoryReservation": 0, "links": [""], "portMappings": [ { "containerPort": 0, "hostPort": 0, "protocol": "tcp" } ], "restartPolicy": { "enabled": true, "ignoredExitCodes": [0], "restartAttemptPeriod": 180 }, "essential": true, "entryPoint": [""], "command": [""], "environment": [ { "name": "", "value": "" } ], "environmentFiles": [ { "value": "", "type": "s3" } ], "mountPoints": [ { "sourceVolume": "", "containerPath": "", "readOnly": true } ], "volumesFrom": [ { "sourceContainer": "", "readOnly": true } ], "linuxParameters": { "capabilities": { "add": [""], "drop": [""] }, "devices": [ { "hostPath": "", "containerPath": "", "permissions": ["read"] } ], "initProcessEnabled": true, "sharedMemorySize": 0, "tmpfs": [ { "containerPath": "", "size": 0, "mountOptions": [""] } ], "maxSwap": 0, "swappiness": 0 }, "secrets": [ { "name": "", "valueFrom": "" } ], "dependsOn": [ { "containerName": "", "condition": "COMPLETE" } ], "startTimeout": 0, "stopTimeout": 0, "hostname": "", "user": "", "workingDirectory": "", "disableNetworking": true, "privileged": true, "readonlyRootFilesystem": true, "dnsServers": [""], "dnsSearchDomains": [""], "extraHosts": [ { "hostname": "", "ipAddress": "" } ], "dockerSecurityOptions": [""], "interactive": true, "pseudoTerminal": true, "dockerLabels": { "KeyName": "" }, "ulimits": [ { "name": "nofile", "softLimit": 0, "hardLimit": 0 } ], "logConfiguration": { "logDriver": "splunk", "options": { "KeyName": "" }, "secretOptions": [ { "name": "", "valueFrom": "" } ] }, "healthCheck": { "command": [""], "interval": 0, "timeout": 0, "retries": 0, "startPeriod": 0 }, "systemControls": [ { "namespace": "", "value": "" } ], "resourceRequirements": [ { "value": "", "type": "InferenceAccelerator" } ], "firelensConfiguration": { "type": "fluentbit", "options": { "KeyName": "" } } } ], "volumes": [ { "name": "", "host": { "sourcePath": "" }, "configuredAtLaunch": true, "dockerVolumeConfiguration": { "scope": "shared", "autoprovision": true, "driver": "", "driverOpts": { "KeyName": "" }, "labels": { "KeyName": "" } }, "efsVolumeConfiguration": { "fileSystemId": "", "rootDirectory": "", "transitEncryption": "DISABLED", "transitEncryptionPort": 0, "authorizationConfig": { "accessPointId": "", "iam": "ENABLED" } }, "fsxWindowsFileServerVolumeConfiguration": { "fileSystemId": "", "rootDirectory": "", "authorizationConfig": { "credentialsParameter": "", "domain": "" } } } ], "placementConstraints": [ { "type": "memberOf", "expression": "" } ], "requiresCompatibilities": ["EC2"], "cpu": "", "memory": "", "tags": [ { "key": "", "value": "" } ], "pidMode": "task", "ipcMode": "task", "proxyConfiguration": { "type": "APPMESH", "containerName": "", "properties": [ { "name": "", "value": "" } ] }, "inferenceAccelerators": [ { "deviceName": "", "deviceType": "" } ], "ephemeralStorage": { "sizeInGiB": 0 }, "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "WINDOWS_SERVER_20H2_CORE" } } ``` **Modelo do Fargate** **Importante** No Fargate, você deve incluir o parâmetro `operatingSystemFamily` com um dos seguintes valores: `LINUX` `WINDOWS_SERVER_2019_FULL` `WINDOWS_SERVER_2019_CORE` `WINDOWS_SERVER_2022_FULL` `WINDOWS_SERVER_2022_CORE` ``` { "family": "", "runtimePlatform": {"operatingSystemFamily": ""}, "taskRoleArn": "", "executionRoleArn": "", "networkMode": "awsvpc", "platformFamily": "", "containerDefinitions": [ { "name": "", "image": "", "repositoryCredentials": {"credentialsParameter": ""}, "cpu": 0, "memory": 0, "memoryReservation": 0, "links": [""], "portMappings": [ { "containerPort": 0, "hostPort": 0, "protocol": "tcp" } ], "essential": true, "entryPoint": [""], "command": [""], "environment": [ { "name": "", "value": "" } ], "environmentFiles": [ { "value": "", "type": "s3" } ], "mountPoints": [ { "sourceVolume": "", "containerPath": "", "readOnly": true } ], "volumesFrom": [ { "sourceContainer": "", "readOnly": true } ], "linuxParameters": { "capabilities": { "add": [""], "drop": [""] }, "devices": [ { "hostPath": "", "containerPath": "", "permissions": ["read"] } ], "initProcessEnabled": true, "sharedMemorySize": 0, "tmpfs": [ { "containerPath": "", "size": 0, "mountOptions": [""] } ], "maxSwap": 0, "swappiness": 0 }, "secrets": [ { "name": "", "valueFrom": "" } ], "dependsOn": [ { "containerName": "", "condition": "HEALTHY" } ], "startTimeout": 0, "stopTimeout": 0, "hostname": "", "user": "", "workingDirectory": "", "disableNetworking": true, "privileged": true, "readonlyRootFilesystem": true, "dnsServers": [""], "dnsSearchDomains": [""], "extraHosts": [ { "hostname": "", "ipAddress": "" } ], "dockerSecurityOptions": [""], "interactive": true, "pseudoTerminal": true, "dockerLabels": {"KeyName": ""}, "ulimits": [ { "name": "msgqueue", "softLimit": 0, "hardLimit": 0 } ], "logConfiguration": { "logDriver": "awslogs", "options": {"KeyName": ""}, "secretOptions": [ { "name": "", "valueFrom": "" } ] }, "healthCheck": { "command": [""], "interval": 0, "timeout": 0, "retries": 0, "startPeriod": 0 }, "systemControls": [ { "namespace": "", "value": "" } ], "resourceRequirements": [ { "value": "", "type": "GPU" } ], "firelensConfiguration": { "type": "fluentd", "options": {"KeyName": ""} } } ], "volumes": [ { "name": "", "host": {"sourcePath": ""}, "configuredAtLaunch":true, "dockerVolumeConfiguration": { "scope": "task", "autoprovision": true, "driver": "", "driverOpts": {"KeyName": ""}, "labels": {"KeyName": ""} }, "efsVolumeConfiguration": { "fileSystemId": "", "rootDirectory": "", "transitEncryption": "ENABLED", "transitEncryptionPort": 0, "authorizationConfig": { "accessPointId": "", "iam": "ENABLED" } } } ], "requiresCompatibilities": ["FARGATE"], "cpu": "", "memory": "", "tags": [ { "key": "", "value": "" } ], "ephemeralStorage": {"sizeInGiB": 0}, "pidMode": "task", "ipcMode": "none", "proxyConfiguration": { "type": "APPMESH", "containerName": "", "properties": [ { "name": "", "value": "" } ] }, "inferenceAccelerators": [ { "deviceName": "", "deviceType": "" } ] } ``` É possível gerar esse modelo de definição de tarefa usando o seguinte comando da AWS CLI. ``` aws ecs register-task-definition --generate-cli-skeleton ``` # Exemplos de definições de tarefa do Amazon ECS É possível copiar os exemplos e trechos para começar a criar suas próprias definições de tarefa. É possível copiar os exemplos e, em seguida, colá-los quando usar a opção **Configurar via JSON** no console. Certifique-se de personalizar os exemplos, como usar o ID da sua conta. É possível incluir os trechos no JSON de 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) e [Parâmetros de definição de tarefa do Amazon ECS para o Fargate](task_definition_parameters.md). Para obter mais exemplos de definição de tarefa, consulte [Exemplos de definição de tarefa da AWS](https://github.com/aws-samples/aws-containers-task-definitions) no GitHub. **Topics** + [ ## Webserver ](#example_task_definition-webserver) + [ ## Driver de log do `splunk` ](#example_task_definition-splunk) + [ ## Driver de log do `fluentd` ](#example_task_definition-fluentd) + [ ## Driver de log do `gelf` ](#example_task_definition-gelf) + [ ## Workloads em instâncias externas ](#ecs-anywhere-runtask) + [ ## Perfil do IAM para definição de imagem e tarefa do Amazon ECR ](#example_task_definition-iam) + [ ## Ponto de entrada com comando ](#example_task_definition-ping) + [ ## Dependência de contêiner ](#example_task_definition-containerdependency) + [ ## Volumes nas definições de tarefa ](#volume_sample_task_defs) + [ ## Definições de tarefa de exemplo do Windows ](#windows_sample_task_defs) ## Webserver Veja a seguir um exemplo de definição de tarefa usando os contêineres do Linux no Fargate que configura um servidor web: ``` { "containerDefinitions": [ { "command": [ "/bin/sh -c \"echo ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

' > /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" } ] } ], "cpu": "256", "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole", "family": "fargate-task-definition", "memory": "512", "networkMode": "awsvpc", "runtimePlatform": { "operatingSystemFamily": "LINUX" }, "requiresCompatibilities": [ "FARGATE" ] } ``` Veja a seguir um exemplo de definição de tarefa usando os contêineres do Windows no Fargate que configura um servidor web: ``` { "containerDefinitions": [ { "command": ["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

'; C:\\ServiceMonitor.exe w3svc"], "entryPoint": [ "powershell", "-Command" ], "essential": true, "cpu": 2048, "memory": 4096, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "name": "sample_windows_app", "portMappings": [ { "hostPort": 80, "containerPort": 80, "protocol": "tcp" } ] } ], "memory": "4096", "cpu": "2048", "networkMode": "awsvpc", "family": "windows-simple-iis-2019-core", "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole", "runtimePlatform": {"operatingSystemFamily": "WINDOWS_SERVER_2019_CORE"}, "requiresCompatibilities": ["FARGATE"] } ``` ## Driver de log do `splunk` O trecho a seguir demonstra como usar o driver de log `splunk` em uma definição de tarefa que envia os logs para um serviço remoto. O parâmetro de token do Splunk é especificado como uma opção secreta, pois ele pode ser tratado como dados confidenciais. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). ``` "containerDefinitions": [{ "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "tag": "tag_name", }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:splunk-token-KnrBkD" }], ``` ## Driver de log do `fluentd` O trecho a seguir demonstra como usar o driver de log `fluentd` em uma definição de tarefa que envia os logs para um serviço remoto. O valor `fluentd-address` é especificado como uma opção secreta, pois ele pode ser tratado como dados confidenciais. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md). ``` "containerDefinitions": [{ "logConfiguration": { "logDriver": "fluentd", "options": { "tag": "fluentd demo" }, "secretOptions": [{ "name": "fluentd-address", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:fluentd-address-KnrBkD" }] }, "entryPoint": [], "portMappings": [{ "hostPort": 80, "protocol": "tcp", "containerPort": 80 }, { "hostPort": 24224, "protocol": "tcp", "containerPort": 24224 }] }], ``` ## Driver de log do `gelf` O trecho a seguir demonstra como usar o driver de log `gelf` em uma definição de tarefa que envia os logs para um host remoto executando o Logstash que leva logs Gelf como uma entrada. Para obter mais informações, consulte [logConfiguration](task_definition_parameters.md#ContainerDefinition-logConfiguration). ``` "containerDefinitions": [{ "logConfiguration": { "logDriver": "gelf", "options": { "gelf-address": "udp://logstash-service-address:5000", "tag": "gelf task demo" } }, "entryPoint": [], "portMappings": [{ "hostPort": 5000, "protocol": "udp", "containerPort": 5000 }, { "hostPort": 5000, "protocol": "tcp", "containerPort": 5000 } ] }], ``` ## Workloads em instâncias externas Ao registrar uma definição de tarefa do Amazon ECS, use o parâmetro `requiresCompatibilities` e especifique `EXTERNAL`, que valida se a definição da tarefa é compatível para usar na execução de workloads do Amazon ECS nas instâncias externas. Se você usar o console para registrar uma definição de tarefa, deverá usar o editor JSON. Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). **Importante** Se as tarefas exigirem uma função do IAM de execução de tarefa, verifique se ela está especificada na definição de tarefa. Ao implantar a workload, use o tipo de inicialização `EXTERNAL` quando criar o serviço ou quando executar a tarefa autônoma. Veja a seguir um exemplo de definição de tarefa. ------ #### [ Linux ] ``` { "requiresCompatibilities": [ "EXTERNAL" ], "containerDefinitions": [{ "name": "nginx", "image": "public.ecr.aws/nginx/nginx:latest", "memory": 256, "cpu": 256, "essential": true, "portMappings": [{ "containerPort": 80, "hostPort": 8080, "protocol": "tcp" }] }], "networkMode": "bridge", "family": "nginx" } ``` ------ #### [ Windows ] ``` { "requiresCompatibilities": [ "EXTERNAL" ], "containerDefinitions": [{ "name": "windows-container", "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "memory": 256, "cpu": 512, "essential": true, "portMappings": [{ "containerPort": 80, "hostPort": 8080, "protocol": "tcp" }] }], "networkMode": "bridge", "family": "windows-container" } ``` ------ ## Perfil do IAM para definição de imagem e tarefa do Amazon ECR O trecho a seguir usa uma imagem do Amazon ECR denominada `aws-nodejs-sample` com a tag `v1` do registro `123456789012.dkr.ecr.us-west-2.amazonaws.com`. O contêiner dessa tarefa herda permissões do IAM da função `arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole`. Para obter mais informações, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md). ``` { "containerDefinitions": [ { "name": "sample-app", "image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/aws-nodejs-sample:v1", "memory": 200, "cpu": 10, "essential": true } ], "family": "example_task_3", "taskRoleArn": "arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole" } ``` ## Ponto de entrada com comando O trecho a seguir demonstra a sintaxe de um contêiner do Docker que usa um ponto de entrada e um argumento de comando. Este contêiner executa ping no `example.com` quatro vezes e, em seguida, sai. ``` { "containerDefinitions": [ { "memory": 32, "essential": true, "entryPoint": ["ping"], "name": "alpine_ping", "readonlyRootFilesystem": true, "image": "alpine:3.4", "command": [ "-c", "4", "example.com" ], "cpu": 16 } ], "family": "example_task_2" } ``` ## Dependência de contêiner Este trecho demonstra a sintaxe para uma definição de tarefa com vários contêineres em que a dependência de contêiner é especificada. Na definição de tarefa a seguir, o contêiner `envoy` deve alcançar um status íntegro, determinado pelos parâmetros de verificação de integridade de contêiner necessários, antes que o contêiner `app` seja iniciado. Para obter mais informações, consulte [Dependência de contêiner](task_definition_parameters.md#container_definition_dependson). ``` { "family": "appmesh-gateway", "runtimePlatform": { "operatingSystemFamily": "LINUX" }, "proxyConfiguration":{ "type": "APPMESH", "containerName": "envoy", "properties": [ { "name": "IgnoredUID", "value": "1337" }, { "name": "ProxyIngressPort", "value": "15000" }, { "name": "ProxyEgressPort", "value": "15001" }, { "name": "AppPorts", "value": "9080" }, { "name": "EgressIgnoredIPs", "value": "169.254.170.2,169.254.169.254" } ] }, "containerDefinitions": [ { "name": "app", "image": "application_image", "portMappings": [ { "containerPort": 9080, "hostPort": 9080, "protocol": "tcp" } ], "essential": true, "dependsOn": [ { "containerName": "envoy", "condition": "HEALTHY" } ] }, { "name": "envoy", "image": "840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.15.1.0-prod", "essential": true, "environment": [ { "name": "APPMESH_VIRTUAL_NODE_NAME", "value": "mesh/meshName/virtualNode/virtualNodeName" }, { "name": "ENVOY_LOG_LEVEL", "value": "info" } ], "healthCheck": { "command": [ "CMD-SHELL", "echo hello" ], "interval": 5, "timeout": 2, "retries": 3 } } ], "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "networkMode": "awsvpc" } ``` ## Volumes nas definições de tarefa Use as informações a seguir para entender como especificar volumes em tarefas. + Para obter informações sobre como configurar um volume do Amazon EBS, consulte [Especificar a configuração de volumes do Amazon EBS na implantação do Amazon ECS](configure-ebs-volume.md). + Para obter informações sobre como configurar um volume do Amazon EFS, consulte [Configurar os sistemas de arquivos do Amazon EFS para o Amazon ECS usando o console](tutorial-efs-volumes.md). + Para obter informações sobre como configurar um volume do FSx para Windows File Server, consulte [Saiba como configurar sistemas de arquivos do FSx para Windows File Server para o Amazon ECS](tutorial-wfsx-volumes.md). + Para obter informações sobre como configurar um volume do Docker, consulte [Exemplos de volume do Docker para o Amazon ECS](docker-volume-examples.md). + Para obter mais informações sobre como configurar uma montagem de associação, consulte [Exemplos de montagem de associação para o Amazon ECS](bind-mount-examples.md). ## Definições de tarefa de exemplo do Windows Veja a seguir um exemplo de definição de tarefa para ajudar você nos conceitos básicos dos contêineres do Windows no Amazon ECS. **Example Exemplo de aplicação de console do Amazon ECS para Windows** A definição de tarefa a seguir é o exemplo de aplicação de console do Amazon ECS produzida no assistente da primeira execução para o Amazon ECS. Ela foi convertida para usar a imagem de contêiner do `microsoft/iis` Windows. ``` { "family": "windows-simple-iis", "containerDefinitions": [ { "name": "windows_sample_app", "image": "mcr.microsoft.com/windows/servercore/iis", "cpu": 1024, "entryPoint":["powershell", "-Command"], "command":["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

'; C:\\ServiceMonitor.exe w3svc"], "portMappings": [ { "protocol": "tcp", "containerPort": 80 } ], "memory": 1024, "essential": true } ], "networkMode": "awsvpc", "memory": "1024", "cpu": "1024" } ```