# Clusters do Amazon ECS Um cluster do Amazon ECS é o agrupamento lógico de tarefas ou serviços que fornece capacidade de infraestrutura para as aplicações em contêiner. Ao criar um cluster, você escolhe entre os três tipos principais de infraestrutura, cada um otimizado para diferentes casos de uso e requisitos operacionais. ## Como escolher o tipo de cluster certo O Amazon ECS oferece três tipos de infraestrutura para seus clusters. Escolha o tipo que melhor atende aos seus requisitos de workload, preferências operacionais e metas de otimização de custos: Instâncias gerenciadas do Amazon ECS (recomendado) **Melhor para a maioria das workloads**: a AWS gerencia totalmente as instâncias do Amazon EC2 subjacentes, incluindo provisionamento, aplicação de patches e escala. Essa opção fornece o equilíbrio ideal entre performance, economia e simplicidade operacional. **Use quando:** + Você quer que a AWS administre o gerenciamento de infraestrutura + Você precisa de computação econômica com otimização automática + Você quer se concentrar em suas aplicações em vez de na infraestrutura + Você precisa de performance previsível com escala flexível Fargate **Computação com tecnologia sem servidor**: pague somente pelos recursos que suas tarefas usam sem gerenciar nenhuma infraestrutura. Ideal para workloads variáveis e para começar rapidamente. **Use quando:** + Você quer operações totalmente sem servidor + Você tem workloads imprevisíveis ou variáveis + Você deseja minimizar a sobrecarga operacional + Você precisa de implantação e escala rápidas Instâncias do Amazon EC2 **Controle total**: você gerencia diretamente as instâncias subjacentes do Amazon EC2, incluindo seleção, configuração e manutenção das instâncias. **Use quando:** + Você precisa de tipos ou configurações de instância específicos + Você tem uma infraestrutura existente do Amazon EC2 para aproveitar + Você precisa de AMIs personalizadas ou software especializado + Você precisa de controle máximo sobre a infraestrutura subjacente **nota** As instâncias gerenciadas do Amazon ECS são a escolha recomendada para a maioria das novas workloads, já que oferecem a melhor combinação de performance, otimização de custos e simplicidade operacional, ao mesmo tempo em que permitem que a AWS administre as tarefas de gerenciamento de infraestrutura. ## Componentes do cluster Além da capacidade de infraestrutura, um cluster consiste nos seguintes recursos: + A rede (VPC e sub-rede) em que suas tarefas e serviços são executados Quando você usa as instâncias gerenciadas do Amazon ECS ou as instâncias do Amazon EC2 para obter capacidade, a sub-rede pode estar em zonas de disponibilidade, zonas locais, zonas do Wavelength ou AWS Outposts. + Um namespace opcional O namespace é usado para comunicação entre serviços com o Service Connect. + Uma opção de monitoramento O CloudWatch Container Insights tem um custo adicional e é um serviço totalmente gerenciado. Ele coleta, agrega e resume automaticamente métricas e logs do Amazon ECS. ## Conceitos de cluster Veja a seguir os conceitos gerais sobre clusters do Amazon ECS. + Crie clusters adicionais para separar seus recursos. + Os clusters são específicos da Região da AWS. + Os clusters podem estar em qualquer um dos estados a seguir. ACTIVE O cluster está pronto para aceitar tarefas e, se for aplicável, você pode registrar instâncias de contêiner com o cluster. PROVISIONING O cluster tem provedores de capacidade associados a ele e os recursos necessários para o provedor de capacidade estão sendo criados. DEPROVISIONING O cluster tem provedores de capacidade associados a ele e os recursos necessários para o provedor de capacidade estão sendo excluídos. FAILED O cluster tem provedores de capacidade associados a ele e os recursos necessários para o provedor de capacidade apresentaram falha na criação. INACTIVE O cluster foi excluído. Os clusters com um status `INACTIVE` podem permanecer detectáveis em sua conta por um período. Esse comportamento está sujeito a alterações no futuro, portanto, certifique-se de não confiar na persistência de clusters com o estado `INACTIVE`. + Um cluster pode conter uma combinação de tarefas hospedadas nas instâncias gerenciadas do Amazon ECS, no AWS Fargate, nas instâncias do Amazon EC2 ou em instâncias externas. As tarefas podem ser executadas nas instâncias gerenciadas do Amazon ECS, na infraestrutura do Fargate ou do EC2 como tipo de inicialização ou estratégia de provedor de capacidade. Se você usar os provedores de capacidade do EC2, o Amazon ECS não rastreará nem escalará a capacidade dos grupos do Amazon EC2 Auto Scaling. + Um cluster pode conter uma combinação de provedores de capacidade das instâncias gerenciadas do Amazon ECS, do grupo do Auto Scaling e do Fargate. Uma estratégia de provedor de capacidade só pode conter provedores de capacidade das instâncias gerenciadas do Amazon ECS, do grupo do Auto Scaling e do Fargate. + É possível usar diferentes tipos de instância para os provedores de capacidade das instâncias gerenciadas do Amazon ECS e EC2 ou do grupo do Auto Scaling. Uma instância pode ser registrada somente em um cluster por vez. + É possível restringir o acesso aos clusters ao criar políticas do IAM personalizadas. Para obter informações, consulte a seção [Exemplos de clusters do Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies) em [Exemplos de políticas baseadas em identidade do Amazon Elastic Container Service](security_iam_id-based-policy-examples.md). + É possível usar o Service Auto Scaling para escalar tarefas do Fargate. Para obter mais informações, consulte [Como escalar automaticamente o serviço do Amazon ECS](service-auto-scaling.md). + É possível configurar um namespace padrão do Service Connect para um cluster. Depois de definir um namespace padrão do Service Connect, todos os novos serviços criados no cluster podem ser adicionados como serviços de cliente no namespace com a ativação do Service Connect. Não é exigida nenhuma configuração adicional. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). ## Provedores de capacidade Provedores de capacidade do Amazon ECS gerenciam a escalabilidade da infraestrutura das tarefas dos clusters. Cada cluster pode ter um ou mais provedores de capacidade e uma estratégia opcional de provedor de capacidade. É possível atribuir uma estratégia de provedor de capacidade padrão ao cluster. A estratégia de provedor de capacidade determina como as tarefas são distribuídas entre os provedores de capacidade do cluster. Ao executar uma tarefa autônoma ou criar um serviço, você pode usar a estratégia padrão de provedor de capacidade do cluster ou uma estratégia de provedor de capacidade que substitua a estratégia padrão. A estratégia de provedor de capacidade padrão do cluster só se aplica quando você não especifica um tipo de inicialização ou uma estratégia de provedor de capacidade para sua tarefa ou serviço. Se você fornecer qualquer um desses parâmetros, a estratégia padrão não será usada. O Amazon ECS oferece três tipos de provedores de capacidade para seus clusters: Provedores de capacidade das instâncias gerenciadas do Amazon ECS A AWS gerencia totalmente as instâncias do Amazon EC2 subjacentes, incluindo provisionamento, aplicação de patches, escala e gerenciamento do ciclo de vida. Isso fornece o equilíbrio ideal entre performance, economia e simplicidade operacional. Os provedores de capacidade de instâncias gerenciadas do Amazon ECS otimizam automaticamente a seleção e a escala de instâncias com base nos requisitos de workload. Com as instâncias gerenciadas do Amazon ECS, você se beneficia de: + Provisionamento e escala automáticos de instâncias + Aplicação de patches e atualizações de segurança gerenciadas + Otimização de custos por meio da seleção inteligente de instâncias + Menor sobrecarga operacional Provedores de capacidade do Fargate Computação com tecnologia sem servidor em que você paga somente pelos recursos que suas tarefas usam sem gerenciar nenhuma infraestrutura. Você só precisa associar os provedores de capacidade predefinidos (Fargate e Fargate Spot) ao cluster. Provedores de capacidade de grupo do Auto Scaling Ao usar instâncias do Amazon EC2 para sua capacidade, você usa grupos do Auto Scaling para gerenciar as instâncias do Amazon EC2. O Auto Scaling ajuda a garantir que você tenha o número adequado de instâncias do Amazon EC2 disponíveis para lidar com a carga da aplicação. Você tem controle total sobre a infraestrutura subjacente. Um cluster pode conter uma combinação de tarefas hospedadas nas instâncias gerenciadas do Amazon ECS, no AWS Fargate, nas instâncias do Amazon EC2 ou em instâncias externas. As tarefas podem ser executadas nas instâncias gerenciadas do Amazon ECS, na infraestrutura do Fargate ou do EC2 como tipo de inicialização ou estratégia de provedor de capacidade. Se você usar o EC2 como um tipo de inicialização, o Amazon ECS não rastreará nem escalará a capacidade dos grupos do Amazon EC2 Auto Scaling. Um cluster pode conter uma combinação de provedores de capacidade das instâncias gerenciadas do Amazon ECS, do grupo do Auto Scaling e do Fargate. Uma estratégia de provedor de capacidade só pode conter provedores de capacidade das instâncias gerenciadas do Amazon ECS, do grupo do Auto Scaling e do Fargate. # Clusters para instâncias gerenciadas do Amazon ECS Provedores de capacidade do Amazon ECS gerenciam a escalabilidade da infraestrutura das tarefas dos clusters. Depois de criar o cluster, você cria um ou mais provedores de capacidade e uma estratégia opcional de provedor de capacidade para o cluster. A estratégia de provedor de capacidade determina como as tarefas são distribuídas entre os provedores de capacidade do cluster. Ao executar uma tarefa autônoma ou criar um serviço, você pode usar a estratégia padrão de provedor de capacidade do cluster ou uma estratégia de provedor de capacidade que substitua a estratégia padrão. As instâncias gerenciadas do Amazon ECS têm os seguintes provedores de capacidade: | Tipo | Critérios usados para escolher instâncias | | --- | --- | | Padrão | As instâncias mais econômicas que atendem aos seguintes requisitos de definição de tarefa e parâmetro de serviço: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/managed-instance-clusters.html) | | Personalizada | As instâncias que atendem aos requisitos de atributos e tipos que você especifica ao criar o cluster. Para obter informações sobre atributos, consulte [Atributos de instância de contêiner do Amazon ECS](task-placement-constraints.md#attributes). Para obter informações sobre tipos de instância, consulte [Especificações de tipo de instância do Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) em Tipos de instância do Amazon EC2. | O Amazon ECS inicializa as instâncias e as associa ao provedor de capacidade de instâncias gerenciadas do Amazon ECS. Para o provedor de capacidade personalizado, o Amazon ECS também cria o provedor de capacidade. # Criar um cluster para instâncias gerenciadas do Amazon ECS Crie um cluster para definir a infraestrutura na qual suas tarefas e serviços são executados. Ao criar um cluster para instâncias gerenciadas do Amazon ECS, você obtém acesso ao provedor de capacidade `FARGATE_MANAGED_INSTANCE` por padrão. Esse provedor de capacidade seleciona automaticamente os tipos de instância mais econômicos para suas workloads. Você também poderá criar provedores de capacidade personalizados se precisar de atributos ou tipos de instância específicos. Para tornar o processo de criação de cluster o mais fácil possível, o console tem seleções padrão para várias opções. + Cria um namespace padrão no AWS Cloud Map com o mesmo nome do cluster. Um namespace permite que os serviços que você cria no cluster se conectem aos outros serviços do namespace sem configuração adicional. Para obter mais informações, consulte [Interconexão de serviços do Amazon ECS](interconnecting-services.md). É possível modificar as opções a seguir: + Altere o namespace padrão associado ao cluster. Um namespace permite que os serviços que você cria no cluster se conectem aos outros serviços do namespace sem configuração adicional. O namespace padrão é o mesmo nome do cluster. Para obter mais informações, consulte [Interconexão de serviços do Amazon ECS](interconnecting-services.md). + Atribua uma chave do AWS KMS ao seu armazenamento gerenciado. Para obter informações sobre como criar uma chave, consulte [Criar uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do usuário do AWS Key Management Service*. + Adicione tags para ajudar a identificar seu cluster. ## Pré-requisitos Antes de começar, é necessário concluir as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md) e atribuir a permissão adequada do IAM. Para obter mais informações, consulte [Exemplos de clusters do Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). O usuário que está criando o cluster deve ter uma permissão adicional: `iam:CreateServiceLinkedRole`. Por padrão, o Amazon ECS escolhe os tipos de instância com base nos requisitos especificados na definição de tarefa. Esse é o provedor de capacidade padrão. Se você precisar de atributos ou tipos de instância específicos, anote todos os requisitos. Você precisará usar um provedor de capacidade personalizado e, em seguida, especificar os requisitos de instância. Entenda como escolher suas instâncias. Para obter mais informações, consulte [Práticas recomendadas de seleção de instâncias gerenciadas do Amazon ECS](managed-instances-instance-selection-best-practices.md). Você tem os perfis do IAM necessários para instâncias gerenciadas do Amazon ECS. Isso inclui: + **Perfil de infraestrutura**: permite que o Amazon ECS faça chamadas para serviços da AWS em seu nome para gerenciar a infraestrutura de instâncias gerenciadas do Amazon ECS. Para obter mais informações, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). + **Perfil de instância**: fornece permissões para o agente de contêiner do Amazon ECS e para o daemon do Docker em execução nas instâncias gerenciadas. Para obter mais informações, consulte [Perfil de instância de instâncias gerenciadas do Amazon ECS](managed-instances-instance-profile.md). ## Procedimento do console **Para criar um novo cluster (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 de cluster**, configure o seguinte: + Em **Nome do cluster**, insira um nome exclusivo. O nome pode conter até 255 letras (minúsculas e maiúsculas), números e hifens. + (Opcional) Para que o namespace usado para o Service Connect seja diferente do nome do cluster, em **Namespace**, insira um nome exclusivo. 1. Em **Provedor de capacidade personalizado**, faça o seguinte: + Em **Selecionar um método de obtenção da capacidade do EC2**, escolha **Instâncias gerenciadas do Amazon ECS**. + Em Perfil de instância, escolha o perfil. + Em Função de infraestrutura, escolha o perfil de infraestrutura. + Para usar um provedor de capacidade personalizado, em **Seleção de instância**, escolha **Usar personalizado**. Em seguida, para cada atributo, insira o **Valor do atributo**. 1. (Opcional) Utilize o Container Insights, expanda **Monitoramento** e escolha uma destas opções: + Para usar o Container Insights com observabilidade aprimorada (recomendado), escolha **Container Insights com observabilidade aprimorada**. + Para usar o Container Insights, escolha **Container Insights**. 1. (Opcional) Criptografe os dados no armazenamento gerenciado. Em **Criptografia**, em **Armazenamento gerenciado**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados do armazenamento gerenciado. 1. (Opcional) Para ajudar a identificar seu cluster, expanda **Tags** (Etiquetas) e configure suas etiquetas. [Adicionar uma tag] Selecione **Add tag** (Adicionar tag) e faça o seguinte: + Em **Key (Chave)**, insira o nome da chave. + Em **Valor** insira o valor da chave. 1. Escolha **Criar**. ## Procedimento da AWS CLI Você pode criar um cluster para instâncias gerenciadas do Amazon ECS usando a AWS CLI. Use a versão mais recente da AWS CLI. Para obter informações sobre como atualizar para a versão mais recente [Consulte instalar ou atualizar para a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **nota** É possível usar endpoints de serviço de pilha dupla para interagir com o Amazon ECS via AWS AWS CLI, SDKs e API do Amazon ECS sobre IPv4 e IPv6. Para obter mais informações, consulte [Usar endpoints de pilha dupla do Amazon ECS](dual-stack-endpoint.md). **Para criar um novo cluster (AWS CLI)** 1. Crie o cluster com um nome exclusivo usando o seguinte comando: ``` aws ecs create-cluster --cluster-name managed-instances-cluster ``` Resultado: ``` { "cluster": { "status": "ACTIVE", "defaultCapacityProviderStrategy": [], "statistics": [], "capacityProviders": [], "tags": [], "clusterName": "managed-instances-cluster", "settings": [ { "name": "containerInsights", "value": "disabled" } ], "registeredContainerInstancesCount": 0, "pendingTasksCount": 0, "runningTasksCount": 0, "activeServicesCount": 0, "clusterArn": "arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster" } } ``` 1. (Opcional) Para habilitar o Container Insights com observabilidade aprimorada para seu cluster, use o seguinte comando: ``` aws ecs put-account-setting --name containerInsights --value enhanced ``` 1. (Opcional) Para adicionar tags ao seu cluster, use o seguinte comando: ``` aws ecs tag-resource --resource-arn arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster --tags key=Environment,value=Production ``` ## Próximas etapas Crie uma definição de tarefa para instâncias gerenciadas do Amazon ECS. Para obter mais informações, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md). Execute suas aplicações como tarefas autônomas ou como parte de um serviço. Para saber mais, 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) # Atualizar um cluster para usar instâncias gerenciadas do Amazon ECS Você pode atualizar um cluster existente para usar as instâncias gerenciadas do Amazon ECS. Ao adicionar instâncias gerenciadas do Amazon ECS ao seu cluster, você obtém acesso ao provedor de capacidade `FARGATE_MANAGED_INSTANCE` por padrão. Esse provedor de capacidade seleciona automaticamente os tipos de instância de uso geral mais econômicos para suas workloads. Você também poderá criar provedores de capacidade personalizados se precisar de atributos ou tipos de instância específicos. ## Pré-requisitos Por padrão, o Amazon ECS escolhe os tipos de instância com base nos requisitos especificados na definição de tarefa. Esse é o provedor de capacidade padrão. Se você precisar de atributos ou tipos de instância específicos, anote todos os requisitos. Você precisará usar um provedor de capacidade personalizado e, em seguida, especificar os requisitos de instância. Você tem os perfis do IAM necessários para instâncias gerenciadas do Amazon ECS. Isso inclui: + **Perfil de infraestrutura**: permite que o Amazon ECS faça chamadas para serviços da AWS em seu nome para gerenciar a infraestrutura de instâncias gerenciadas do Amazon ECS. Para obter mais informações, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). + **Perfil de instância**: fornece permissões para o agente de contêiner do Amazon ECS e para o daemon do Docker em execução nas instâncias gerenciadas. Para obter mais informações, consulte [Perfil de instância de instâncias gerenciadas do Amazon ECS](managed-instances-instance-profile.md). ## Considerações sobre atualização Ao atualizar um cluster para instâncias gerenciadas do Amazon ECS, considere o seguinte: + Tarefas em execução: a atualização das configurações do cluster não afeta as tarefas em execução no momento. As alterações serão aplicadas às novas tarefas iniciadas após a atualização. + Alterações no provedor de capacidade: se você modificar as configurações do provedor de capacidade, as instâncias gerenciadas existentes continuarão em execução, mas as novas instâncias usarão a configuração atualizada. + Monitoramento de alterações: habilitar ou desabilitar o Container Insights afetará a coleta de métricas em todo o cluster. ## Procedimento do console **Para atualizar um cluster (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**, selecione o cluster que deseja atualizar. 1. Escolha **Atualizar cluster**. 1. (Opcional) Para modificar as configurações do provedor de capacidade, em **Provedor de capacidade personalizado**, atualize o seguinte conforme necessário: + Em **Perfil de instância**, escolha um perfil diferente, se necessário. + Em **Perfil de infraestrutura**, escolha um perfil diferente, se necessário. + Para usar um provedor de capacidade personalizado, em **Seleção de instância**, atualize as configurações de **Valor do atributo**. 1. Selecione **Atualizar**. ## Procedimento da AWS CLI Você pode atualizar um cluster para instâncias gerenciadas do Amazon ECS usando a AWS CLI. Use a versão mais recente da AWS CLI. Para obter informações sobre como atualizar para a versão mais recente [Consulte instalar ou atualizar para a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **nota** É possível usar endpoints de serviço de pilha dupla para interagir com o Amazon ECS via AWS AWS CLI, SDKs e API do Amazon ECS sobre IPv4 e IPv6. Para obter mais informações, consulte [Usar endpoints de pilha dupla do Amazon ECS](dual-stack-endpoint.md). **Para atualizar um cluster (AWS CLI)** 1. Crie um provedor de capacidade para . Execute o seguinte comando: Substitua os valores das *user-input* pelos seus. ``` aws ecs create-capacity-provider \ --name my-managed-instances-provider \ --managed-instances-provider \ --instance-profile arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile \ --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRole \ --instance-requirements '{ "vCpuCount": {"min": 2, "max": 8}, "memoryMiB": {"min": 4096, "max": 16384} } ``` 1. Adicione o provedor de capacidade ao cluster usando o seguinte comando: Substitua os valores das *user-input* pelos seus. ``` aws ecs put-cluster-capacity-providers --cluster managed-instances-cluster --capacity-providers my-managed-instances-provider --default-capacity-provider-strategy capacityProvider=my-managed-instances-provider,weight=1 ``` # Provedores de capacidade das instâncias gerenciadas do Amazon ECS Os provedores de capacidade de instâncias gerenciadas do Amazon ECS fornecem um modelo de computação em contêiner que dá acesso a toda a faixa de recursos da AWS e ofertas do Amazon EC2, enquanto a AWS gerencia responsabilidades operacionais e de segurança. A AWS administra aplicação de patches de software e sistema operacional, escala de instâncias e manutenção, oferecendo os benefícios operacionais do Fargate e ainda mantendo o acesso a todos os recursos e integrações da AWS. O Amazon ECS cria modelos de inicialização para suas instâncias gerenciadas do Amazon ECS. Isso define como o Amazon ECS inicializa as instâncias gerenciadas do Amazon ECS, incluindo o perfil de instância para suas tarefas, configuração de rede e armazenamento, opções de capacidade e requisitos de instância para seleção flexível do tipo de instância. ## Quando usar provedores de capacidade personalizados Considere provedores de capacidade personalizados quando suas workloads exigirem: + Requisitos específicos de computação: aplicações que exigem computação acelerada, conjuntos de instruções de CPU específicos, alta performance de rede ou grandes configurações de memória que não estão disponíveis com as opções padrão do Fargate. + Workloads de GPU: inferência de machine learning, renderização de imagem em tempo real, codificação de vídeo ou outras aplicações aceleradas por GPU que precisam de acesso às GPUs NVIDIA ou AMD. + Reservas de capacidade: workloads essenciais que exigem disponibilidade de capacidade previsível. + Observabilidade avançada: ferramentas de segurança e monitoramento que exigem acesso privilegiado ao sistema operacional subjacente, como soluções de monitoramento baseadas em eBPF ou ferramentas de análise de rede. + Otimização de custos: workloads que podem se beneficiar do posicionamento de várias tarefas, dos componentes de infraestrutura compartilhada ou da necessidade de maximizar a utilização de tipos de instância maiores. ## Opções de monitoramento As instâncias gerenciadas do Amazon ECS fornecem recursos abrangentes de monitoramento que ajudam você a monitorar a performance, a integridade e a utilização de recursos de suas workloads em contêiner. Você pode escolher entre diferentes níveis de monitoramento com base em seus requisitos operacionais. + **Monitoramento básico**: fornece métricas essenciais em intervalos de cinco minutos para a maioria das métricas e intervalos de um minuto para verificações de status. Esse recurso está ativado por padrão e incorre em taxas adicionais. + **Monitoramento detalhado**: oferece visibilidade aprimorada com todas as métricas disponíveis em intervalos de um minuto, permitindo detecção e resposta mais rápidas a problemas operacionais. Para obter mais informações, consulte [Monitoramento detalhado para instâncias gerenciadas do Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances). Ambas as opções de monitoramento se integram perfeitamente ao CloudWatch para fornecer painéis, alarmes e respostas automatizadas para ajudar a manter a performance e a disponibilidade ideais das aplicações. ## Considerações sobre o provedor de capacidade Um cluster pode conter uma combinação de provedores de capacidade das instâncias gerenciadas do Amazon ECS, do grupo do Auto Scaling e do Fargate. Uma estratégia de provedor de capacidade só pode conter provedores de capacidade das instâncias gerenciadas do Amazon ECS, do grupo do Auto Scaling e do Fargate. ## Propagação de tags Os provedores de capacidade para instâncias gerenciadas do Amazon ECS oferecem suporte à propagação de tags. Com a propagação de tags, todos os recursos gerenciados pelo provedor de capacidade, ou seja, instância gerenciada, instância de contêiner do Amazon ECS, modelo de inicialização, volumes e interfaces de rede elástica, são marcados com as mesmas tags especificadas no nível do provedor de capacidade. Você pode especificar tags durante a criação do provedor de capacidade e habilitar a propagação de tags especificando o parâmetro `propagateTags` como `CAPACITY_PROVIDER`. Para obter mais informações sobre como marcar com tags as instâncias gerenciadas do Amazon ECS, consulte [Tags para instâncias gerenciadas do Amazon ECS](instance-details-tags-managed-instances.md). # Práticas recomendadas de atualização de provedores de capacidade para instâncias gerenciadas do Amazon ECS Para obter o mais alto nível de segurança e suporte à reversão, recomendamos tratar os provedores de capacidade como recursos imutáveis. Quando precisar atualizar a configuração de um provedor de capacidade, siga este fluxo de trabalho recomendado: 1. **Crie um novo provedor de capacidade** com sua configuração atualizada, em vez de modificar a configuração existente. 1. **Atualize cada serviço** para usar o novo provedor de capacidade e permitir que as implantações sejam concluídas. 1. **Exclua o provedor de capacidade antigo** depois de confirmar que a nova configuração funciona conforme o esperado. Esta abordagem oferece vários benefícios: + **Implantação controlada**: você pode atualizar os serviços um por vez e monitorar o impacto. + **Fácil reversão**: se ocorrerem problemas, você poderá reverter rapidamente os serviços para usar o provedor de capacidade anterior. + **Raio de explosão reduzido**: os problemas com a nova configuração não afetam imediatamente todas as workloads. **nota** Se você estiver usando CloudFormation, considere manter o antigo provedor de capacidade até uma implantação posterior para preservar a capacidade de reverter as alterações na pilha. Embora você possa atualizar os provedores de capacidade existentes, essa abordagem cria um raio de explosão maior e não controlado. As atualizações em vigor aplicam novas configurações a toda a nova capacidade provisionada no futuro, mas não acionam implantações de serviços. Isso significa que você pode não descobrir problemas de configuração até muito tempo depois, quando for necessário escalar seus serviços. # Criar um provedor de capacidade para instâncias gerenciadas do Amazon ECS As instâncias gerenciadas do Amazon ECS usam provedores de capacidade para gerenciar a capacidade computacional das workloads. Por padrão, o Amazon ECS fornece um provedor de capacidade padrão que seleciona automaticamente os tipos de instância de uso geral mais econômicos. No entanto, você pode criar provedores de capacidade personalizados para especificar atributos de instância, como tipos de instância, fabricantes de CPU, tipos de acelerador e outros requisitos. Os provedores de capacidade personalizados usam a seleção de tipo de instância baseada em atributo, o que permite expressar os requisitos da instância como um conjunto de atributos. Esses requisitos são traduzidos automaticamente para todos os tipos de instância do Amazon EC2 correspondentes, simplificando a criação e a manutenção das configurações do tipo de instância. Para saber mais sobre requisitos de instância e seleção baseada em atributo, consulte a documentação [Seleção de tipo de instância baseada em atributo do Amazon EC2 Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) no *Guia do usuário do Amazon EC2*. ## Pré-requisitos Antes de começar, certifique-se de ter concluído os seguintes procedimentos: + Determine que tipo de monitoramento usar. Para obter mais informações, consulte [Monitoramento detalhado para instâncias gerenciadas do Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances). + Tenha um cluster existente ou planeje criar um. Para obter mais informações, consulte [Criar um cluster para instâncias gerenciadas do Amazon ECS](create-cluster-managed-instances.md). + Você tem os perfis do IAM necessários para instâncias gerenciadas do Amazon ECS. Isso inclui: + **Perfil de infraestrutura**: permite que o Amazon ECS faça chamadas para serviços da AWS em seu nome para gerenciar a infraestrutura de instâncias gerenciadas do Amazon ECS. Para obter mais informações, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md). + **Perfil de instância**: fornece permissões para o agente de contêiner do Amazon ECS e para o daemon do Docker em execução nas instâncias gerenciadas. Para obter mais informações, consulte [Perfil de instância de instâncias gerenciadas do Amazon ECS](managed-instances-instance-profile.md). Entenda como escolher suas instâncias. Para obter mais informações, consulte [Práticas recomendadas de seleção de instâncias gerenciadas do Amazon ECS](managed-instances-instance-selection-best-practices.md). ## Procedimento do console **Para criar um provedor de capacidade para instâncias gerenciadas do Amazon ECS (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 o nome do cluster. 1. Na página do cluster, escolha a guia **Infraestrutura**. 1. Na seção **Provedores de capacidade**, escolha **Criar provedor de capacidade**. 1. Em **Configuração do provedor de capacidade**, configure o seguinte: + Em **Nome do provedor de capacidade**, insira um nome exclusivo para o provedor de capacidade. + Em **Tipo de provedor de capacidade**, escolha **Instâncias gerenciadas do Amazon ECS**. 1. Em **Configuração de instância**, configure o seguinte: + Em **Perfil de instância**, escolha o perfil criado para as instâncias gerenciadas do Amazon ECS. + Em **Perfil de infraestrutura**, escolha o perfil criado para as instâncias gerenciadas do Amazon ECS. 1. Em **Requisitos de instância**, especifique os atributos para suas instâncias. É possível configurar qualquer combinação de: + **Contagem de vCPUs**: especifique o número de vCPUs (por exemplo, `4` ou `8-16` para um intervalo). + **Memória (MiB)**: especifique a quantidade de memória em MiB (por exemplo, `8192` ou `16384-32768` para um intervalo). + **Tipos de instância**: especifique tipos de instância específicos (por exemplo, `m5.large,m5.xlarge,c5.large`). + **Fabricantes de CPU**: escolha entre `intel`, `amd` ou `amazon-web-services`. + **Tipos de acelerador**: especifique os tipos de acelerador, como `gpu`, `fpga` ou `inference`. + **Contagem de aceleradores**: especifique o número de aceleradores (por exemplo, `1` ou `2-4` para um intervalo). 1. Em **Configuração avançada**, escolha uma das seguintes opções de monitoramento: + Para que o CloudWatch envie métricas de verificação de status, escolha **Básico**. + Para que o CloudWatch envie todas as métricas, escolha **Detalhado**. 1. (Opcional) Para ajudar a identificar seu provedor de capacidade, expanda **Tags** e configure suas tags. Para habilitar a propagação de tags do provedor de capacidade para recursos gerenciados, como instâncias inicializadas no provedor de capacidade, em **Propagar tags de**, escolha **Provedor de capacidade**. [Adicionar uma tag] Selecione **Add tag** (Adicionar tag) e faça o seguinte: + Em **Key (Chave)**, insira o nome da chave. + Em **Valor** insira o valor da chave. 1. Escolha **Criar**. ## Procedimento da AWS CLI Você pode criar um provedor de capacidade para instâncias gerenciadas do Amazon ECS usando a AWS CLI. Use a versão mais recente da AWS CLI. Para obter informações sobre como atualizar para a versão mais recente [Consulte instalar ou atualizar para a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **Para criar um provedor de capacidade para instâncias gerenciadas do Amazon ECS (AWS CLI)** 1. Execute o seguinte comando: ``` aws ecs create-capacity-provider --cli-input-json file://capacity-provider-definition.json ``` O seguinte `capacity-provider-definition.json` pode ser usado para especificar os requisitos básicos da instância, o tamanho do armazenamento da instância e permitir a propagação de tags: ``` { "name": "my-managed-instances-provider", "cluster": "my-cluster", "tags": [ { "key": "version", "value": "test" } ], "managedInstancesProvider": { "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole", "instanceLaunchTemplate": { "ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole", "instanceRequirements": { "vCpuCount": { "min": 4, "max": 8 }, "memoryMiB": { "min": 8192, "max": 16384 } }, "networkConfiguration": { "subnets": [ "subnet-abcdef01234567", "subnet-bcdefa98765432" ], "securityGroups": [ "sg-0123456789abcdef" ] }, "storageConfiguration": { "storageSizeGiB": 100 }, "monitoring": "basic" }, "propagateTags": "CAPACITY_PROVIDER" } } ``` 1. Verifique se o seu provedor de capacidade foi criado com êxito: ``` aws ecs describe-capacity-providers \ --capacity-providers my-managed-instances-provider ``` ## Próximas etapas Depois de criar seu provedor de capacidade, você pode usá-lo ao criar serviços ou executar tarefas: + Para usar o provedor de capacidade com um serviço, consulte [Criação de uma implantação de atualização contínua do Amazon ECS](create-service-console-v2.md). + Para usar o provedor de capacidade com tarefas autônomas, consulte [Execução de uma aplicação como uma tarefa do Amazon ECS](standalone-task-create.md). # Atualizar o monitoramento de instâncias gerenciadas do Amazon ECS Você pode modificar a opção de monitoramento do seu provedor de capacidade de instâncias gerenciadas do Amazon ECS para alternar entre monitoramento básico e detalhado. Isso permite ajustar o nível de monitoramento dos dados coletados sem recriar o provedor de capacidade. Para obter mais informações sobre opções de monitoramento, consulte [Monitorar instâncias gerenciadas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-managed-instances.html). ## Procedimento do console **Para atualizar o monitoramento das instâncias gerenciadas do Amazon ECS (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 o nome do cluster. 1. Na página do cluster, escolha a guia **Infraestrutura**. 1. Em **Configuração avançada**, escolha uma das seguintes opções de monitoramento: + Para que o CloudWatch envie métricas de verificação de status, escolha **Básico**. + Para que o CloudWatch envie todas as métricas, escolha **Detalhado**. 1. Selecione **Atualizar**. Para atualizar as tags associadas a um provedor de capacidade existente de instâncias gerenciadas do Amazon ECS, siga estas etapas: 1. No painel de navegação, escolha **Clusters**. 1. Na página de clusters, escolha **Infraestrutura**. 1. Na página de infraestrutura, escolha o provedor de capacidade que você criou. 1. Na página do provedor de capacidade, escolha **Tags**. 1. Em **Tags**, selecione **Gerenciar tags**. 1. Para adicionar uma tag, especifique a chave e o valor da tag que você deseja adicionar e escolha **Salvar**. Para adicionar várias tags ao mesmo tempo, escolha **Adicionar tag** para cada tag que você deseja adicionar. É possível adicionar um máximo de 50 tags. Para remover uma tag, selecione **Remover**. **nota** Se a propagação de tags estiver habilitada, as tags adicionadas ou removidas após a criação do provedor de capacidade não se aplicarão aos recursos criados anteriormente pelo provedor de capacidade. ## Procedimento da AWS CLI Você pode atualizar um provedor de capacidade para instâncias gerenciadas do Amazon ECS usando a AWS CLI. Use a versão mais recente da AWS CLI. Para obter informações sobre como atualizar para a versão mais recente [Consulte instalar ou atualizar para a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **Para atualizar o monitoramento das instâncias gerenciadas do Amazon ECS (AWS CLI)** 1. Para habilitar o monitoramento detalhado, use o seguinte comando: ``` aws ecs update-capacity-provider \ --name my-managed-instances-provider \ --managed-instances-provider '{ "instanceLaunchTemplateUpdate": { "monitoring": "DETAILED" } }' ``` 1. Para habilitar o monitoramento básico, use o seguinte comando: ``` aws ecs update-capacity-provider \ --name my-managed-instances-provider \ --managed-instances-provider '{ "instanceLaunchTemplateUpdate": { "monitoring": "BASIC" } }' ``` # Excluir um provedor de capacidade de instâncias gerenciadas do Amazon ECS Se tiver terminado de usar um provedor de capacidade de instâncias gerenciadas do Amazon ECS, você poderá excluí-lo. Depois que o grupo for excluído, o provedor de capacidade de instâncias gerenciadas do Amazon ECS fará a transição para o estado `INACTIVE`. Os clusters com um status `INACTIVE` podem permanecer detectáveis em sua conta durante algum tempo. No entanto, esse comportamento está sujeito a alterações no futuro, então você não deve confiar na persistência de provedores de capacidade `INACTIVE`. Antes da exclusão do provedor de capacidade de instâncias gerenciadas do Amazon ECS, ele deve ser removido da estratégia de provedor de capacidade de todos os serviços. É possível usar a API `UpdateService` ou o fluxo de trabalho do serviço de atualização no console do Amazon ECS para remover um provedor de capacidade da estratégia do provedor de capacidade de um serviço. Use a opção **Forçar uma nova implantação** para garantir que todas as tarefas que usam a capacidade de instâncias gerenciadas do Amazon ECS fornecida pelo provedor de capacidade sejam transferidas para usar a capacidade dos provedores de capacidade restantes. **Para excluir um provedor de capacidade para o cluster (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**. 1. Na página **Clusters**, escolha o cluster. 1. Na página **Cluster: *nome***, escolha **Infraestrutura**, o provedor de capacidade de instâncias gerenciadas do Amazon ECS e, em seguida, escolha **Excluir**. 1. Na caixa de confirmação, insira **excluir *nome do provedor de capacidade de instâncias gerenciadas do Amazon ECS*** 1. Escolha **Excluir**. # Interromper com segurança as workloads do Amazon ECS em execução nas instâncias gerenciadas do Amazon ECS Você pode usar a Proteção de Tarefa na Redução de Escala do Amazon ECS para impedir que suas tarefas sejam encerradas por eventos de redução de escala horizontal de implantações ou escala de serviço. Certas aplicações exigem um mecanismo para impedir que tarefas de missão crítica sejam encerradas por meio de eventos de redução da escala horizontalmente durante períodos de baixa utilização ou durante implantações de serviços. Por exemplo: + Você tem uma aplicação assíncrona de processamento de filas, como um trabalho de transcodificação de vídeo, em que algumas tarefas precisam ser executadas por horas, mesmo quando a utilização cumulativa do serviço é baixa. + Você tem uma aplicação de jogos que executa servidores de jogos como tarefas do Amazon ECS que precisam continuar em execução mesmo que todos os usuários tenham se desconectado para reduzir a latência de inicialização de uma reinicialização do servidor. + Quando implantar uma nova versão de código, você precisa que as tarefas continuem em execução, pois seria caro reprocessar. Para proteger as tarefas pertencentes ao seu serviço de encerramentos em um evento de redução da escala na horizontal, defina o atributo `ProtectionEnabled` como `true`. Ao definir `ProtectionEnabled` como verdadeiro, as tarefas ficam protegidas por 2 horas por padrão. Em seguida, é possível personalizar o período de proteção usando o atributo `ExpiresInMinutes`. É possível proteger suas tarefas por no mínimo um minuto e até no máximo 2.880 minutos (48 horas). Se estiver usando o AWS CLI, você poderá especificar a opção `--protection-enabled`. Depois que uma tarefa terminar o trabalho necessário, será possível definir o atributo `ProtectionEnabled` como `false`, permitindo que a tarefa seja encerrada por eventos subsequentes de redução da escala na horizontal. Se estiver usando o AWS CLI, você poderá especificar a opção `--no-protection-enabled`. ## Mecanismos de proteção de tarefa na redução da escala horizontalmente É possível definir e obter proteção de tarefa na redução da escala na horizontal usando o endpoint do agente de contêiner do Amazon ECS ou a API do Amazon ECS. + **Endpoint do agente de contêiner do Amazon ECS** Recomendamos o uso do endpoint do agente de contêiner do Amazon ECS para tarefas que possam autodeterminar a necessidade de proteção. Use essa abordagem para workloads baseadas em filas ou em processamento de tarefas. Quando um contêiner começa a processar o trabalho, por exemplo, consumindo uma mensagem do SQS, você pode definir o atributo `ProtectionEnabled` por meio do caminho `$ECS_AGENT_URI/task-protection/v1/state` do endpoint de proteção de tarefa na redução da escala horizontalmente de dentro do contêiner. O Amazon ECS não encerrará essa tarefa durante eventos de redução da escala horizontalmente. Depois que a tarefa concluir o trabalho, você pode limpar o atributo `ProtectionEnabled` usando o mesmo endpoint, tornando a tarefa elegível para encerramento durante eventos subsequentes de redução horizontal na escala. Para obter mais informações sobre o endpoint do agente de container do Amazon ECS, consulte [Endpoint de Proteção de Tarefa na Redução de Escala do Amazon ECS](managed-instance-task-scale-in-protection-endpoint.md). + **API do Amazon ECS** É possível usar a API do Amazon ECS para definir e recuperar a proteção de tarefa na redução da escala se a aplicação tiver um componente que rastreie o status das tarefas ativas. Use `UpdateTaskProtection` para marcar uma ou mais tarefas como protegidas. Use `GetTaskProtection` para recuperar o status da proteção. Um exemplo dessa abordagem é o caso de a sua aplicação hospedar sessões de servidores de jogos como tarefas do Amazon ECS. Quando um usuário faz login em uma sessão no servidor (tarefa), você pode marcar a tarefa como protegida. Depois que o usuário se desconecta, é possível desmarcar a proteção especificamente para essa tarefa ou desmarcar periodicamente a proteção para tarefas semelhantes que não tenham mais sessões ativas, dependendo da sua necessidade de manter servidores ociosos. Para obter mais informações, consulte [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html) e [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html) na *Referência de APIs do Amazon Elastic Container Service*. É possível combinar as duas abordagens. Por exemplo, use o endpoint do agente do Amazon ECS para definir a proteção de tarefas de dentro de um contêiner e use a API do Amazon ECS para remover a proteção de tarefas do seu serviço de controlador externo. ## Considerações Considere os seguintes pontos antes de usar a proteção de tarefa na redução da escala horizontalmente: + A proteção de tarefa na redução da escala é compatível apenas com tarefas implantadas de um serviço. + A proteção de tarefa na redução da escala é compatível apenas com tarefas implantadas de um serviço que está sendo executado nas instâncias gerenciadas do Amazon ECS. + Recomendamos o uso do endpoint do agente de contêiner do Amazon ECS porque o agente do Amazon ECS tem mecanismos de repetição integrados e uma interface mais simples. + É possível redefinir o período de validade da proteção de tarefa na redução da escala na horizontal invocando `UpdateTaskProtection` para uma tarefa que já tenha a proteção ativada. + Determine quanto tempo uma tarefa precisaria para concluir o trabalho necessário e defina a propriedade `expiresInMinutes` adequadamente. Se você definir a validade da proteção por mais tempo do que o necessário, incorrerá em custos e enfrentará atrasos na implantação de novas tarefas. + Considerações de implantação: + Se o serviço estiver usando uma atualização contínua, novas tarefas serão criadas, mas as tarefas que executem versões mais antigas não serão encerradas até que `protectionEnabled` seja desmarcada ou expire. É possível ajustar o parâmetro `maximumPercentage` na configuração de implantação para um valor que permita que novas tarefas sejam criadas quando tarefas antigas estiverem protegidas. + Caso use o CloudFormation, a update-stack tem um tempo limite de três horas. Portanto, se você definir a proteção de tarefas por mais de três horas, a implantação do CloudFormation poderá resultar em falha e reversão. Durante o tempo em que suas tarefas antigas estão protegidas, a pilha do CloudFormation exibirá `UPDATE_IN_PROGRESS`. Se a proteção de tarefa na redução da escala na horizontal for removida ou expirar dentro da janela de três horas, sua implantação será bem-sucedida e passará para o status `UPDATE_COMPLETE`. Se a implantação ficar presa em `UPDATE_IN_PROGRESS` por mais de três horas, apresentará falha, mostrará o estado `UPDATE_FAILED` e, em seguida, será revertida para o antigo conjunto de tarefas. + O Amazon ECS enviará eventos de serviço quando as tarefas protegidas estiverem impedindo que uma implantação (contínua ou azul/verde) atinja o estado estacionário para que você possa tomar medidas corretivas. Ao tentar atualizar o status de proteção de uma tarefa, se você receber a mensagem de erro `DEPLOYMENT_BLOCKED`, isso significa que o serviço tem mais tarefas protegidas do que a contagem desejada de tarefas para o serviço. Para corrigir esse erro, execute um dos seguintes procedimentos: + Aguarde até que a proteção da tarefa atual expire. Em seguida, defina a proteção da tarefa. + Determine quais tarefas podem ser interrompidas. Em seguida, use `UpdateTaskProtection` com a opção `protectionEnabled` definida como `false` para essas tarefas. + Aumente a contagem de tarefas desejada do serviço para mais do que o número de tarefas protegidas. ## Permissões do IAM necessárias para a proteção de tarefa na redução da escala horizontalmente A tarefa deve ter o perfil de tarefa do Amazon ECS com as seguintes permissões: + `ecs:GetTaskProtection`: permite que o agente de contêiner do Amazon ECS chame `GetTaskProtection`. + `ecs:UpdateTaskProtection`: permite que o agente de contêiner do Amazon ECS chame `UpdateTaskProtection`. # Endpoint de Proteção de Tarefa na Redução de Escala do Amazon ECS O agente de contêiner do Amazon ECS injeta automaticamente a variável de ambiente `ECS_AGENT_URI` nos contêineres de tarefas do Amazon ECS para fornecer um método de interação com o endpoint da API do agente de contêiner. Recomendamos o uso do endpoint do agente de contêiner do Amazon ECS para tarefas que possam autodeterminar a necessidade de proteção. Quando um contêiner começa a processar o trabalho, você pode definir o atributo `protectionEnabled` por meio do caminho `$ECS_AGENT_URI/task-protection/v1/state` do endpoint de proteção de tarefa na redução de escala de dentro do contêiner. Use uma solicitação PUT para esse URI de dentro de um contêiner para definir a proteção de tarefa na redução da escala. Uma solicitação GET para esse URI retorna o status atual da proteção de uma tarefa. ## Parâmetros de solicitação da proteção de tarefa na redução de escala É possível definir a proteção de tarefa na redução da escala na horizontal usando o endpoint `${ECS_AGENT_URI}/task-protection/v1/state` com os parâmetros de solicitação a seguir. `ProtectionEnabled` Especifique `true` para que uma tarefa receba proteção. Especifique `false` para remover a proteção e tornar a tarefa elegível para encerramento. Tipo: booliano Obrigatório: Sim `ExpiresInMinutes` O número de minutos em que a tarefa é protegida. É possível especificar, no mínimo, de 1 minuto a 2.880 minutos (48 horas). Durante esse período, a tarefa não será encerrada por eventos de redução da escala na horizontal decorrentes de ajuste de escala automático do serviço ou de implantações. Após esse período, o parâmetro `protectionEnabled` será definido como `false` Se você não especificar o tempo, a tarefa será automaticamente protegida por 120 minutos (duas horas). Tipo: inteiro Obrigatório: não Os exemplos a seguir mostram como definir uma proteção de tarefa na redução da escala horizontalmente com diferentes durações. **Exemplo de como proteger uma tarefa com o período padrão** Este exemplo mostra como proteger uma tarefa com o período padrão de duas horas. ``` curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}' ``` **Exemplo de como proteger uma tarefa por 60 minutos** Este exemplo mostra como proteger uma tarefa por 60 minutos usando o parâmetro `expiresInMinutes`. ``` curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}' ``` **Exemplo de como proteger uma tarefa por 24 horas** Este exemplo mostra como proteger uma tarefa por 24 horas usando o parâmetro `expiresInMinutes`. ``` curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}' ``` A solicitação PUT retorna a resposta a seguir. ``` { "protection": { "ExpirationDate": "2023-12-20T21:57:44.837Z", "ProtectionEnabled": true, "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0" } } ``` ## Parâmetros de resposta da proteção de tarefa na redução de escala As informações a seguir são retornadas do endpoint de proteção de tarefa na redução da escala `${ECS_AGENT_URI}/task-protection/v1/state` na resposta em JSON . `ExpirationDate` O período em que a proteção da tarefa expirará. Se a tarefa não estiver protegida, esse valor será nulo. `ProtectionEnabled` O status de proteção da tarefa. Se a proteção contra redução da escala horizontalmente estiver ativada para uma tarefa, o valor será `true`. Caso contrário, ele será `false`. `TaskArn` O nome de recurso da Amazon (ARN) da tarefa à qual o contêiner pertence. O exemplo a seguir mostra os detalhes retornados para uma tarefa protegida. ``` curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state ``` ``` { "protection":{ "ExpirationDate":"2023-12-20T21:57:44Z", "ProtectionEnabled":true, "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0" } } ``` As informações a seguir são retornadas quando ocorre uma falha. `Arn` O nome completo do recurso da Amazon (ARN) da tarefa. `Detail` Os detalhes relacionados à falha. `Reason` O motivo da falha. O exemplo a seguir mostra os detalhes retornados para uma tarefa que não está protegida. ``` { "failure":{ "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0", "Detail":null, "Reason":"TASK_NOT_VALID" } } ``` As informações a seguir são retornadas quando ocorre uma exceção. `requestID` O ID da solicitação da AWS para a chamada de API do Amazon ECS que resulta em uma exceção. `Arn` O nome completo do recurso da Amazon (ARN) da tarefa ou serviço. `Code` O código do erro. `Message` A mensagem de erro. Se surgir um erro `RequestError` ou `RequestTimeout`, provavelmente será um problema de rede. Experimente usar endpoints da VPC para o Amazon ECS. O exemplo a seguir mostra os detalhes retornados quando ocorre um erro. ``` { "requestID":"12345-abc-6789-0123-abc", "error":{ "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0", "Code":"AccessDeniedException", "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action" } } ``` O erro a seguir será exibido se o agente do Amazon ECS não conseguir obter uma resposta do endpoint do Amazon ECS devido a problemas de rede ou inoperância do ambiente de gerenciamento do Amazon ECS. ``` { "error": { "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0", "Code": "RequestCanceled", "Message": "Timed out calling Amazon ECS Task Protection API" } } ``` O erro a seguir é exibido quando o agente do Amazon ECS recebe uma exceção de controle de utilização do Amazon ECS. ``` { "requestID": "12345-abc-6789-0123-abc", "error": { "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0", "Code": "ThrottlingException", "Message": "Rate exceeded" } } ``` # Clusters do Amazon ECS para Fargate Com o Amazon ECS em provedores de capacidade do AWS Fargate, é possível usar a capacidade do Fargate e do Fargate Spot com as tarefas do Amazon ECS. Com o Fargate Spot, é possível executar tarefas tolerantes a interrupções do Amazon ECS a uma taxa com desconto em comparação com o preço do Fargate. O Fargate Spot executa tarefas com capacidade adicional de computação. Quando a AWS precisar recuperar a capacidade, as tarefas serão interrompidas com um aviso de dois minutos. Quando as tarefas que usam os provedores de capacidade do Fargate e do Fargate Spot são interrompidas, o evento de alteração de estado da tarefa é enviado para o Amazon EventBridge. O motivo da interrupção descreve a causa. Para obter mais informações, consulte [Eventos de alteração de estado de tarefa do Amazon ECS](ecs_task_events.md). Um cluster pode conter uma combinação de provedores de capacidade do Fargate e do grupo do Auto Scaling. Entretanto, uma estratégia de provedor de capacidade só pode conter provedores de capacidade do Fargate ou do grupo do Auto Scaling, mas não ambos. Para obter mais informações, consulte [Auto Scaling Group Capacity Providers](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html#asg-capacity-providers). Leve em consideração o seguinte, quando usar provedores de capacidade: + Você deve associar um provedor de capacidade a um cluster antes de associá-lo à estratégia do provedor de capacidade. + É possível especificar, no máximo, 20 provedores de capacidade para uma estratégia do provedor de capacidade. + Não é possível atualizar um serviço que usa um provedor de capacidade do grupo do Auto Scaling para usar um provedor de capacidade do Fargate. O inverso também é verdadeiro. + Em uma estratégia de provedor de capacidade, se não houver um valor de `weight` especificado para um provedor de capacidade no console, será usado o valor padrão `1`. Se a API ou a AWS CLI estiver sendo usada, será usado o valor padrão `0`. + Quando vários fornecedores de capacidade são especificados dentro de uma estratégia de provedor de capacidade, pelo menos um dos provedores de capacidade deve ter um valor de peso superior a zero. Quaisquer provedores de capacidade com peso zero não serão usados na atribuição de tarefas. Se você especificar vários provedores de capacidade em uma estratégia em que todos tenham um peso zero, quaisquer ações `RunTask` ou `CreateService` que usarem a estratégia de provedor de capacidade apresentarão falha. + Somente um provedor de capacidade em uma estratégia de provedor de capacidade pode ter um valor de *base* definido. Se nenhum valor de base for especificado, será usado o valor padrão de zero. + Um cluster pode conter uma combinação de provedores de capacidade de grupo do Auto Scaling e provedores de capacidade do Fargate. Entretanto, uma estratégia de provedor de capacidade só pode conter provedores de capacidade do grupo do Auto Scaling ou do Fargate, mas não ambos. + Um cluster pode conter uma combinação de serviços e tarefas autônomas que usam ambos os provedores de capacidade. Um serviço pode ser atualizado para usar uma estratégia de provedor de capacidade em vez de um tipo de inicialização. Entretanto, você deve forçar uma nova implantação ao fazer isso. ## Avisos de encerramento do Fargate Spot Durante períodos de demanda extremamente alta, a capacidade do Fargate Spot pode estar indisponível. Isso pode atrasar as tarefas do Fargate Spot. Quando isso acontece, os serviços do Amazon ECS tentam iniciar tarefas novamente até que a capacidade necessária se torne disponível. O Fargate não substitui a capacidade spot pela capacidade sob demanda. Quando as tarefas que usam a capacidade do Fargate Spot são interrompidas devido a uma interrupção do Spot, um aviso de dois minutos é enviado antes da interrupção de uma tarefa. O aviso é enviado como um evento de alteração de estado da tarefa para o Amazon EventBridge e como um sinal de SIGTERM para a tarefa em execução. Se você usar o Fargate Spot como parte de um serviço, então, nesse cenário, o programador de serviços receberá o sinal de interrupção e tentará iniciar tarefas adicionais no Fargate Spot se houver capacidade disponível. Um serviço com apenas uma tarefa será interrompido até que a capacidade esteja disponível. Para obter mais informações sobre um desligamento normal, consulte [Desligamentos normais com o ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/). Para garantir que seus contêineres saiam normalmente antes que a tarefa seja interrompida, é possível configurar o seguinte: + Um valor de `stopTimeout` `120` segundos ou menos pode ser especificado na definição de contêiner que a tarefa está usando. O valor padrão de `stopTimeout` é 30 segundos. É possível especificar um valor mais longo de `stopTimeout` para ter mais tempo entre o momento em que o evento de alteração de estado da tarefa é recebido e o instante no qual o contêiner é interrompido forçosamente. Para obter mais informações, consulte [Tempos limite de contêiner](task_definition_parameters.md#container_definition_timeout). + Para executar ações de limpeza, o sinal de SIGTERM deve ser recebido de dentro do contêiner. A falha ao processar esse sinal fará com que a tarefa receba um sinal de SIGKILL após a configuração do `stopTimeout` e poderá causar perda ou corrupção de dados. Veja a seguir o trecho de um evento de alteração de estado da tarefa. Esse trecho exibe o motivo e o código de uma interrupção do Fargate Spot. ``` { "version": "0", "id": "9bcdac79-b31f-4d3d-9410-fbd727c29fab", "detail-type": "ECS Task State Change", "source": "aws.ecs", "account": "111122223333", "resources": [ "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6f1cebef" ], "detail": { "clusterArn": "arn:aws:ecs:us-east-1:111122223333:cluster/default", "createdAt": "2016-12-06T16:41:05.702Z", "desiredStatus": "STOPPED", "lastStatus": "RUNNING", "stoppedReason": "Your Spot Task was interrupted.", "stopCode": "SpotInterruption", "taskArn": "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6fEXAMPLE", ... } } ``` Veja a seguir um padrão de evento que é usado para criar uma regra do Eventbridge para eventos de alteração de estado da tarefa do Amazon ECS. Opcionalmente, você pode especificar um cluster no campo `detail`. Isso significa que você receberá eventos de alteração do estado da tarefa para esse cluster. Para obter mais informações sobre a criação de uma regra do EventBridge, consulte [Conceitos básicos do Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) no *Guia do usuário do Amazon EventBridge*. ``` { "source": [ "aws.ecs" ], "detail-type": [ "ECS Task State Change" ], "detail": { "clusterArn": [ "arn:aws:ecs:us-west-2:111122223333:cluster/default" ] } } ``` # Criar um cluster do Amazon ECS para workloads do Fargate Crie um cluster para definir a infraestrutura na qual suas tarefas e serviços são executados. Antes de começar, é necessário concluir as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md) e atribuir a permissão adequada do IAM. Para obter mais informações, consulte [Exemplos de clusters do Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). O console do Amazon ECS cria os recursos necessários para um cluster do Amazon ECS ao criar uma pilha do CloudFormation. O console associa automaticamente os provedores de capacidade do Fargate e do Fargate Spot ao cluster. É possível modificar as opções a seguir: + Adicione um namespace ao cluster. Um namespace permite que os serviços que você cria no cluster possam se conectar a outros serviços no namespace sem configuração adicional. Para obter mais informações, consulte [Interconexão de serviços do Amazon ECS](interconnecting-services.md). + Habilite eventos de tarefas para receber notificações do EventBridge sobre mudanças de estado das tarefas. + Adicione tags para ajudar a identificar seu cluster. + Atribua uma chave do AWS KMS ao seu armazenamento gerenciado. Para obter informações sobre como criar uma chave, consulte [Criar uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do usuário do AWS Key Management Service*. + Atribua uma chave do AWS KMS ao armazenamento efêmero do Fargate. Para obter informações sobre como criar uma chave, consulte [Criar uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do usuário do AWS Key Management Service*. + Configure a chave do AWS KMS e o registro em log para o ECS Exec. ## Procedimento **Para criar um novo cluster (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 de cluster**, configure o seguinte: + Em **Nome do cluster**, insira um nome exclusivo. O nome pode conter até 255 letras (minúsculas e maiúsculas), números e hifens. + (Opcional) Para que o namespace usado para o Service Connect seja diferente do nome do cluster, em **Padrões do Service Connect**, para **Namespace padrão**, escolha ou insira um nome de namespace. Para usar um namespace compartilhado, escolha ou insira um ARN de namespace. Para obter mais informações sobre o uso de namespaces compartilhados, consulte [Amazon ECS Service Connect com Namespaces compartilhados do AWS Cloud Map](service-connect-shared-namespaces.md). 1. (Opcional) Utilize o Container Insights, expanda **Monitoramento** e escolha uma destas opções: + Para usar o Container Insights com observabilidade aprimorada (recomendado), escolha **Container Insights com observabilidade aprimorada**. + Para usar o Container Insights, escolha **Container Insights**. 1. (Opcional) Para habilitar eventos de tarefas, expanda **Eventos de tarefas** e ative **Habilitar eventos de tarefas**. Quando você habilita eventos de tarefas, o Amazon ECS envia eventos de mudança de estado da tarefa ao EventBridge. Isso permite que você monitore e responda automaticamente às mudanças no ciclo de vida da tarefa. 1. (Opcional) Para usar o ECS Exec para depurar tarefas no cluster, expanda **Configuração de solução de problemas** e, em seguida, configure o seguinte: + (Opcional) Em **Chave do AWS KMS para ECS Exec**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados da sessão do ECS Exec. + (Opcional) Para **Registro em log do ECS Exec**, escolha o destino do log: + Para enviar logs para o CloudWatch Logs, escolha **Amazon CloudWatch**. + Para enviar logs para o Amazon S3, escolha **Amazon S3**. + Para desativar o registro em log, escolha **Nenhum**. 1. (Opcional), em **Criptografia**, você pode configurar o seguinte: + Criptografe os dados no armazenamento efêmero do Fargate. Em **Criptografia**, em **Armazenamento efêmero do Fargate**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados do armazenamento efêmero do Fargate. + Criptografe os dados no armazenamento gerenciado. Em **Criptografia**, em **Armazenamento gerenciado**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados do armazenamento gerenciado. 1. (Opcional) Para ajudar a identificar seu cluster, expanda **Tags** (Etiquetas) e configure suas etiquetas. [Adicionar uma tag] Selecione **Add tag** (Adicionar tag) e faça o seguinte: + Em **Key (Chave)**, insira o nome da chave. + Em **Value (Valor)**, insira o valor da chave. [Remover uma tag] Escolha **Remover** à direita da chave e do valor da tag. 1. Selecione **Create** (Criar). ## Próximas etapas Após criar o cluster, será possível criar definições de tarefas para suas aplicações e executá-las como tarefas autônomas ou como parte de um serviço. Para saber mais, consulte: + [Definições de tarefa do Amazon ECS](task_definitions.md) + [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) # Provedores de capacidade do Amazon ECS para workloads do EC2 Ao usar instâncias do Amazon EC2 para sua capacidade, você usa grupos do Auto Scaling para gerenciar as instâncias do Amazon EC2 registradas em seus clusters. O Auto Scaling ajuda a garantir que você tenha o número adequado de instâncias do Amazon EC2 disponíveis para lidar com a carga da aplicação. É possível usar o recurso de ajuste de escala gerenciado para que o Amazon ECS gerencie as ações reduzir a escala horizontalmente e aumentar a escala horizontalmente do grupo do Auto Scaling ou gerenciar as ações de ajuste de escala por si próprio. Para obter mais informações, consulte [Gerenciamento automático da capacidade do Amazon ECS com ajuste de escala automático de cluster](cluster-auto-scaling.md). Recomendamos criar um novo grupo do Auto Scaling vazio. Se você usar um grupo do Auto Scaling existente, todas as instâncias do Amazon EC2 associadas ao grupo que já estavam em execução e registradas em um cluster do Amazon ECS antes de o grupo do Auto Scaling ser usado para criar um provedor de capacidade poderão não estar registradas corretamente no provedor de capacidade. Isso poderá causar problemas quando o provedor de capacidade for usado em uma estratégia de provedor de capacidade. Use `DescribeContainerInstances` para confirmar se uma instância de contêiner está associada a um provedor de capacidade ou não. **nota** Para criar um grupo do Auto Scaling vazio, defina a contagem desejada como zero. Depois da criação do provedor de capacidade e da sua associação a um cluster, é possível aumentar sua escala horizontalmente. Ao usar o console do Amazon ECS, o Amazon ECS cria um modelo de inicialização do Amazon EC2 e um grupo do Auto Scaling em seu nome como parte da pilha do CloudFormation. Eles são prefixados com `EC2ContainerService-`. É possível usar o grupo do Auto Scaling como um provedor de capacidade para aquele cluster. Recomendamos usar a drenagem gerenciada de instâncias para permitir o encerramento tranquilo de instâncias do Amazon EC2 que não interrompe as workloads. Este recurso está ativado por padrão. Para obter mais informações, consulte . [Interrupção de workloads do Amazon ECS em execução em instâncias do EC2 com segurança](managed-instance-draining.md) Ao usar provedores de capacidade do grupo do Auto Scaling no console, considere o seguinte: + Um grupo do Auto Scaling deve ter um `MaxSize` maior do que zero para o aumento de escala na horizontal. + O grupo do Auto Scaling não pode ter configurações de ponderação da instância. + Se o grupo do Auto Scaling não conseguir aumentar a escala horizontalmente para acomodar o número de tarefas executadas, as tarefas apresentarão falha na transição para além do estado `PROVISIONING`. + Não modifique o recurso de política de escalabilidade associado aos grupos do Auto Scaling que são gerenciados por provedores de capacidade. + Se a escalabilidade gerenciada estiver ativada ao ser criado um provedor de capacidade, a contagem desejada do grupo do Auto Scaling poderá ser definida como `0`. Quando a escalabilidade gerenciada está habilitada, o Amazon ECS gerencia as ações do grupo do Auto Scaling para reduzir e aumentar a escala horizontalmente. + Você deve associar o provedor de capacidade a um cluster antes de associá-lo à estratégia do provedor de capacidade. + É possível especificar, no máximo, 20 provedores de capacidade para uma estratégia do provedor de capacidade. + Não é possível atualizar um serviço que usa um provedor de capacidade do grupo do Auto Scaling para usar um provedor de capacidade do Fargate. O inverso também é verdadeiro. + Em uma estratégia de provedor de capacidade, se não houver um valor de `weight` especificado para um provedor de capacidade no console, será usado o valor padrão `1`. Se a API ou a AWS CLI estiver sendo usada, será usado o valor padrão `0`. + Quando vários fornecedores de capacidade são especificados dentro de uma estratégia de provedor de capacidade, pelo menos um dos provedores de capacidade deve ter um valor de peso superior a zero. Quaisquer provedores de capacidade com peso zero não serão usados na atribuição de tarefas. Se você especificar vários provedores de capacidade em uma estratégia em que todos tenham um peso zero, quaisquer ações `RunTask` ou `CreateService` que usarem a estratégia de provedor de capacidade apresentarão falha. + Somente um provedor de capacidade em uma estratégia de provedor de capacidade pode ter um valor de *base* definido. Se nenhum valor de base for especificado, será usado o valor padrão de zero. + Um cluster pode conter uma combinação de provedores de capacidade de grupo do Auto Scaling e provedores de capacidade do Fargate. Entretanto, uma estratégia de provedor de capacidade só pode conter provedores de capacidade do grupo do Auto Scaling ou do Fargate, mas não ambos. + Um cluster pode conter uma combinação de serviços e tarefas autônomas que usem tanto provedores de capacidade quanto tipos de inicialização. Um serviço pode ser atualizado para usar uma estratégia de provedor de capacidade em vez de um tipo de inicialização. Entretanto, você deve forçar uma nova implantação ao fazer isso. + O Amazon ECS oferece suporte a grupos de alta atividade do Amazon EC2 Auto Scaling. Um grupo de alta atividade é um grupo de instâncias do Amazon EC2 pré-inicializadas e prontas para serem colocadas em serviço. Sempre que a aplicação precisa aumentar a escala horizontalmente, o Amazon EC2 Auto Scaling usa as instâncias inicializadas previamente do grupo de aquecimento em vez de iniciar instâncias a frio. Isso permite que qualquer processo de inicialização final seja executado antes de a instância ser atribuída para um serviço. Para obter mais informações, consulte [Configuração de instâncias inicializadas previamente para o grupo do Amazon ECS Auto Scaling](using-warm-pool.md). Para obter mais informações sobre a criação de um modelo de execução do Amazon EC2 Auto Scaling, consulte [Modelos de execução do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. Para obter mais informações sobre a criação de um grupo do Amazon EC2 Auto Scaling, consulte [Grupos do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. # Considerações de segurança sobre a instância de contêiner do Amazon EC2 para o Amazon ECS Você deve considerar uma única instância de contêiner e seu acesso dentro do seu modelo de ameaças. Por exemplo, uma única tarefa afetada pode aproveitar as permissões do IAM de uma tarefa não infectada na mesma instância. Recomendamos que você use o indicado a seguir para ajudar a evitar isso: + Não use privilégios de administrador ao executar suas tarefas. + Atribua um perfil de tarefa com acesso de privilégio mínimo às suas tarefas. O agente de contêiner cria automaticamente um token com um ID de credencial exclusivo que é usado para acessar os recursos do Amazon ECS. + Para evitar que contêineres executados por tarefas que usem o modo de rede `awsvpc` acessem as informações de credenciais fornecidas ao perfil de instância do Amazon EC2, e ainda permitindo que as permissões fornecidas pelo perfil da tarefa, defina a variável de configuração de agente `ECS_AWSVPC_BLOCK_IMDS` como verdadeira no arquivo de configuração do agente e reinicie o agente. + Use o monitoramento de runtime do Amazon GuardDuty para detectar ameaças em clusters e contêineres no ambiente da AWS. O monitoramento de runtime usa um agente de segurança do GuardDuty que adiciona visibilidade de runtime às workloads individuais do Amazon ECS, por exemplo, acesso a arquivos, execução de processos e conexões de rede. Para obter mais informações, consulte [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) no *Guia do usuário do GuardDuty*. # Criar um cluster do Amazon ECS para workloads do Amazon EC2 Crie um cluster para definir a infraestrutura na qual suas tarefas e serviços são executados. Antes de começar, é necessário concluir as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md) e atribuir a permissão adequada do IAM. Para obter mais informações, consulte [Exemplos de clusters do Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). O console do Amazon ECS fornece uma maneira simples de criar os recursos necessários para um cluster do Amazon ECS criando uma pilha do CloudFormation. Para tornar o processo de criação do cluster o mais fácil possível, o console tem seleções padrão para muitas opções, que descrevemos abaixo. Também há painéis de ajuda disponíveis para a maioria das seções do console, que fornecem mais contexto. É possível registrar instâncias do Amazon EC2 ao criar o cluster ou registrar instâncias adicionais no cluster após ele ter sido criado. É possível modificar as opções padrão a seguir: + Alterar as sub-redes em que suas instâncias são executadas. + Alterar os grupos de segurança usados para controlar o tráfego para as instâncias de contêineres. + Adicione um namespace ao cluster. Um namespace permite que os serviços que você cria no cluster possam se conectar a outros serviços no namespace sem configuração adicional. Para obter mais informações, consulte [Interconexão de serviços do Amazon ECS](interconnecting-services.md). + Habilite eventos de tarefas para receber notificações do EventBridge sobre mudanças de estado das tarefas. + Atribua uma chave do AWS KMS ao seu armazenamento gerenciado. Para obter informações sobre como criar uma chave, consulte [Criar uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do usuário do AWS Key Management Service*. + Atribua uma chave do AWS KMS ao armazenamento efêmero do Fargate. Para obter informações sobre como criar uma chave, consulte [Criar uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do usuário do AWS Key Management Service*. + Configure a chave do AWS KMS e o registro em log para o ECS Exec. + Adicione tags para ajudar a identificar seu cluster. ## Opções do grupo do Auto Scaling Ao usar instâncias do Amazon EC2, você deve especificar um grupo do Auto Scaling para gerenciar a infraestrutura em que suas tarefas e serviços são executados. Quando você escolhe criar um novo grupo do Auto Scaling, ele é configurado automaticamente para o seguinte comportamento: + O Amazon ECS gerencia as ações de redução e aumento de escala na horizontal do grupo do Auto Scaling. + O Amazon ECS não impedirá que as instâncias do Amazon EC2 que contenham tarefas e estejam em um grupo do Auto Scaling sejam terminadas durante uma ação de redução de escala na horizontal. Para obter mais informações, consulte [Proteção de instância](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection) no *Guia do usuário do AWS Auto Scaling*. Você configura as seguintes propriedades do grupo do Auto Scaling que determinam o tipo e o número de instâncias a serem iniciadas para o grupo: + As AMIs otimizadas para o Amazon ECS + O tipo de instância. + O par de chaves de SSH que prova sua identidade quando você se conecta à instância. Para obter informações sobre como criar chaves SSH, consulte [Pares de chaves do Amazon EC2 e instância do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Manual do usuário do Amazon EC2*. + O número mínimo de instâncias a iniciar para o grupo do Auto Scaling. + O número máximo de instâncias iniciadas para o grupo do Auto Scaling. Para que o grupo sofra aumento de escala na horizontal, o máximo deve ser maior que 0. O Amazon ECS cria um modelo de execução do Amazon EC2 Auto Scaling e um grupo do Auto Scaling em seu nome como parte da pilha do CloudFormation. Os valores especificados para a AMI, os tipos de instância e o par de chaves de SSH fazem parte do modelo de inicialização. Os modelos possuem o prefixo `EC2ContainerService-`, o que os torna fáceis de identificar. Os grupos do Auto Scaling são prefixados com `-ECS-Infra-ECSAutoScalingGroup`. As instâncias iniciadas para o grupo do Auto Scaling usam o modelo de inicialização. ## Opções de rede Por padrão, as instâncias são iniciadas nas sub-redes padrão da região. São usados os grupos de segurança, que controlam o tráfego para as instâncias de contêiner, atualmente associados às sub-redes. É possível alterar as sub-redes e os grupos de segurança das instâncias. É possível escolher uma sub-rede existente. Você pode usar um grupo de segurança existente ou criar um novo. Para criar tarefas em uma configuração somente IPv6, use sub-redes que incluam apenas um bloco CIDR IPv6. Ao criar um novo grupo de segurança, você precisa especificar pelo menos uma regra de entrada. As regras de entrada determinam qual tráfego pode alcançar suas instâncias de contêiner e incluem as propriedades a seguir: + O protocolo a permitir + O intervalo de portas a permitir + O tráfego de entrada (origem) Para permitir o tráfego de entrada de um endereço ou bloco CIDR específico, use **Personalizada** para **Origem** com o CIDR permitido. Para permitir o tráfego de entrada de todos os destinos, use **Qualquer lugar** para **Origem**. Essa opção adiciona automaticamente o bloco CIDR IPv4 0.0.0.0/0 e o bloco CIDR IPv6 ::/0. Para permitir o tráfego de entrada do seu computador local, use **Grupo de origem** para **Origem**. Isso adiciona automaticamente o endereço IP atual de seu computador local como a origem permitida. **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 de cluster**, configure o seguinte: + Em **Nome do cluster**, insira um nome exclusivo. O nome pode conter até 255 letras (minúsculas e maiúsculas), números e hifens. + (Opcional) Para que o namespace usado para o Service Connect seja diferente do nome do cluster, em **Padrões do Service Connect**, para **Namespace padrão**, escolha ou insira um nome de namespace. Para usar um namespace compartilhado, escolha ou insira um ARN de namespace. Para obter mais informações sobre o uso de namespaces compartilhados, consulte [Amazon ECS Service Connect com Namespaces compartilhados do AWS Cloud Map](service-connect-shared-namespaces.md). 1. Adicione instâncias do Amazon EC2 ao seu cluster, expanda **Infraestrutura** e selecione **Instâncias do Fargate e autogerenciadas**. Em seguida, configure o grupo do Auto Scaling que atua como o provedor de capacidade: 1. Para usar um grupo do Auto Scaling existente, em **Auto Scaling group (ASG)** (Grupo do Auto Scaling (ASG)), selecione o grupo. 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 **Modelo de provisionamento**, escolha se deseja usar instâncias **Sob demanda** ou instâncias **Spot**. + Caso opte por usar instâncias spot, em **Estratégia de alocação**, escolha quais grupos de capacidade spot (tipos de instância e zonas de disponibilidade) serão usados nas instâncias. Na maioria das workloads, você pode escolher **Otimizada para capacidade de preço**. Para obter mais informações, consulte [Estratégias de alocação para Instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) no *Manual do usuário do Amazon EC2*. + Em **Imagem de máquina das Amazon (AMI) da instância de contêiner**, escolha a AMI otimizada para o Amazon ECS para as instâncias do grupo do Auto Scaling. + Em **EC2 instance type** (Tipo de instância do EC2), escolha o tipo de instância para suas workloads. A escalabilidade gerenciada funciona melhor se o grupo do Auto Scaling usa os mesmos tipos de instância ou semelhantes. + Em **Perfil de instância do EC2**, escolha um perfil de instância de contêiner existente ou crie um novo. Para obter mais informações, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md). + Em **Capacity** (Capacidade), insira o número mínimo e o número máximo de instâncias a serem iniciadas no grupo do Auto Scaling. + Em **SSH key pair** (Par de chaves de SSH), escolha o par que prova sua identidade quando você se conecta à instância. + Para permitir imagens e armazenamento maiores, em **Tamanho do volume raiz do EBS**, insira o valor em GiB. 1. (Opcional) Para alterar a VPC e as sub-redes, em **Redes para instâncias do Amazon EC2**, 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 mudar para uma VPC diferente da VPC **padrão**, em **VPC**, escolha uma **VPC** existente e depois em **Sub-redes**, escolha as sub-redes. Para uma configuração somente IPv6, escolha uma VPC que tenha um bloco CIDR IPv6 e sub-redes que tenham apenas um bloco CIDR IPv6. + Escolha os grupos de segurança. Em **Grupo de segurança**, escolha uma das seguintes opções: + Para usar um grupo de segurança existente, escolha **Usar um grupo de segurança existente** e, em seguida, selecione o grupo de segurança. + Para criar um grupo de segurança, escolha **Criar um novo grupo de segurança**. Em seguida, escolha **Adicionar regra** para cada regra de entrada. Para obter informações sobre regras de entrada, consulte [Opções de rede](#networking-options). + Para atribuir automaticamente endereços IP públicos às suas instâncias de contêiner do Amazon EC2, em **Atribuir automaticamente IP público**, escolha uma das seguintes opções: + **Usar configuração de sub-rede**: atribui um endereço IP público às instâncias quando a sub-rede na qual as instâncias são executadas for uma sub-rede pública. + **Ativar**: atribui um endereço IP público às instâncias. 1. (Opcional) Utilize o Container Insights, expanda **Monitoramento** e escolha uma destas opções: + Para usar o Container Insights com observabilidade aprimorada (recomendado), escolha **Container Insights com observabilidade aprimorada**. + Para usar o Container Insights, escolha **Container Insights**. 1. (Opcional) Para habilitar eventos de tarefas, expanda **Eventos de tarefas** e ative **Habilitar eventos de tarefas**. Quando você habilita eventos de tarefas, o Amazon ECS envia eventos de mudança de estado da tarefa ao EventBridge. Isso permite que você monitore e responda automaticamente às mudanças no ciclo de vida da tarefa. 1. (Opcional) Para usar o ECS Exec para depurar tarefas no cluster, expanda **Configuração de solução de problemas** e, em seguida, configure o seguinte: + (Opcional) Em **Chave do AWS KMS para ECS Exec**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados da sessão do ECS Exec. + (Opcional) Para **Registro em log do ECS Exec**, escolha o destino do log: + Para enviar logs para o CloudWatch Logs, escolha **Amazon CloudWatch**. + Para enviar logs para o Amazon S3, escolha **Amazon S3**. + Para desativar o registro em log, escolha **Nenhum**. 1. (Opcional) Se você usa o monitoramento de runtime com a opção manual e deseja que esse cluster seja monitorado pelo GuardDuty, escolha **Adicionar tag** e faça o seguinte: + Em **Chave**, insira **guardDutyRuntimeMonitoringManaged**. + Em **Valor**, insira **true**. 1. (Opcional) Criptografe os dados no armazenamento gerenciado. Em **Criptografia**, em **Armazenamento gerenciado**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados do armazenamento gerenciado. 1. (Opcional) Para gerenciar as tags de cluster, expanda **Tags** e, em seguida, execute uma das seguintes operações: [Adicionar uma tag] Selecione **Add tag** (Adicionar tag) e faça o seguinte: + Em **Key (Chave)**, insira o nome da chave. + Em **Value (Valor)**, insira o valor da chave. [Remover uma tag] Escolha **Remover** à direita da chave e do valor da tag. 1. Selecione **Create** (Criar). ## Próximas etapas Após criar o cluster, será possível criar definições de tarefas para suas aplicações e executá-las como tarefas autônomas ou como parte de um serviço. Para saber mais, consulte: + [Definições de tarefa do Amazon ECS](task_definitions.md) + [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) # Gerenciamento automático da capacidade do Amazon ECS com ajuste de escala automático de cluster O Amazon ECS pode gerenciar a escalabilidade de instâncias do Amazon EC2 registradas no seu cluster. Isso se chama *ajuste de escala automático do cluster* do Amazon ECS. Você ativa o ajuste de escala gerenciado ao criar o provedor de capacidade do grupo do Amazon ECS Auto Scaling. Em seguida, você define uma porcentagem para o destino (a `targetCapacity`) para a utilização da instância neste grupo do Auto Scaling. O Amazon ECS cria duas métricas personalizadas do CloudWatch e uma política de ajuste de escala de rastreamento de destino para o grupo do Auto Scaling. O Amazon ECS gerencia as ações reduzir a escala horizontalmente e aumentar a escala horizontalmente com base na utilização de recursos por parte das suas tarefas. Para cada provedor de capacidade do grupo do Auto Scaling associado a um cluster, o Amazon ECS cria e gerencia os seguintes recursos: + Um alarme do CloudWatch de baixo valor métrico + Um alarme do CloudWatch de alto valor métrico + Uma política de escalabilidade de rastreamento de destino. **nota** O Amazon ECS cria a política de escalabilidade de rastreamento de destino e a anexa ao grupo do Auto Scaling. Para atualizar a política de escalabilidade de rastreamento de destino, atualize as configurações de escalabilidade gerenciadas pelo provedor de capacidade em vez de atualizar a política de escalabilidade diretamente. Quando a escalabilidade gerenciada é desativada ou o provedor de capacidade é desassociado de um cluster, o Amazon ECS remove as métricas do CloudWatch e os recursos da política de escalabilidade de rastreamento de destino. O Amazon ECS usa as seguintes métricas para determinar quais ações realizar: `CapacityProviderReservation` A porcentagem de instâncias de contêiner em uso para um provedor de capacidade específico. O Amazon ECS gera essa métrica. O Amazon ECS define o valor `CapacityProviderReservation` como um número entre 0 e 100. O Amazon ECS usa a fórmula a seguir para representar a proporção de quanta capacidade permanece no grupo do Auto Scaling. Em seguida, o Amazon ECS publica a métrica no CloudWatch. Para obter mais informações sobre como a métrica é calculada, consulte [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/). ``` CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100 ``` `DesiredCapacity` A quantidade de capacidade para o grupo do Auto Scaling. Esta métrica não é publicada no CloudWatch. O Amazon ECS publica a métrica `CapacityProviderReservation` no CloudWatch, no namespace `AWS/ECS/ManagedScaling`. A métrica `CapacityProviderReservation` faz com que ocorra uma das seguintes ações: **O valor `CapacityProviderReservation` é igual a `targetCapacity`** O grupo do Auto Scaling não precisa aumentar nem reduzir a escala horizontalmente. O percentual de utilização pretendido foi atingido. **O valor `CapacityProviderReservation` é maior que `targetCapacity`** Há mais tarefas usando um percentual maior da capacidade do que seu percentual de `targetCapacity`. O aumento do valor da métrica `CapacityProviderReservation` faz com que o alarme do CloudWatch associado se ative. Esse alarme atualiza o valor `DesiredCapacity` para o grupo do Auto Scaling. O grupo do Auto Scaling usa esse valor para iniciar instâncias do EC2 e registrá-las no cluster. Quando a `targetCapacity` for o valor padrão de 100%, as novas tarefas ficam no estado `PENDING` durante o aumento de escala na horizontal, pois não há capacidade disponível nas instâncias para executar as tarefas. Depois que as novas instâncias se registrarem no ECS, essas tarefas serão iniciadas nas novas instâncias. **O valor `CapacityProviderReservation` é menor que `targetCapacity`** Há menos tarefas usando um percentual menor da capacidade do que seu percentual de `targetCapacity`, e há pelo menos uma instância que pode ser encerrada. O valor reduzido da métrica `CapacityProviderReservation` faz com que o alarme do CloudWatch associado se ative. Esse alarme atualiza o valor `DesiredCapacity` para o grupo do Auto Scaling. O grupo do Auto Scaling usa esse valor para terminar instâncias de contêiner do EC2 e, em seguida, cancelar seus registros no cluster. O grupo do Auto Scaling segue as políticas de término de grupo para determinar quais instâncias ele encerrará primeiro durante os eventos de redução de escala na horizontal. Além disso, ele evita instâncias com a configuração de proteção contra redução de escala na horizontal de instâncias ativada. O ajuste de escala automático de clusters pode gerenciar quais instâncias têm a configuração de proteção contra redução de escala na horizontal de instância se você ativar a proteção contra encerramento gerenciada. Para obter mais informações sobre proteção contra encerramento gerenciada, consulte [Controle das instâncias encerradas pelo Amazon ECS](managed-termination-protection.md). Para obter mais informações sobre como os grupos do Auto Scaling encerram instâncias, consulte [Controlar quais instâncias do Auto Scaling são encerradas durante uma redução de escala na horizontal](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. Ao usar o ajuste de escala automático de clusters, leve em consideração o seguinte: + Não altere nem gerencie a capacidade desejada para o grupo do Auto Scaling associado a um provedor de capacidade com quaisquer políticas de escalabilidade diferentes da que o Amazon ECS gerencia. + Quando o Amazon ECS aumenta a escala horizontalmente a partir de 0 instâncias, ele inicia 2 instâncias automaticamente. + O Amazon ECS usa o perfil do IAM vinculado ao serviço `AWSServiceRoleForECS` para as permissões das quais ele precisa para chamar o AWS Auto Scaling em seu nome. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). + Ao usar provedores de capacidade com grupos do Auto Scaling, é necessária a permissão `autoscaling:CreateOrUpdateTags` para que o usuário, o grupo ou o perfil crie os provedores de capacidade. Isso ocorre porque o Amazon ECS adiciona uma etiqueta ao grupo do Auto Scaling quando ele o associa ao provedor de capacidade. **Importante** Certifique-se de usar ferramentas que não removam a tag `AmazonECSManaged` do grupo do Auto Scaling. Se essa tag for removida, o Amazon ECS não conseguirá gerenciar o ajuste de escala. + O ajuste de escala automático de clusters não modifica a **MinimumCapacity** (Capacidade mínima) nem a **MaximumCapacity** (Capacidade máxima) do grupo. Para que o grupo aumente a escala horizontalmente, o valor de **MaximumCapacity** deve ser maior que zero. + Quando o Auto Scaling (escalabilidade gerenciada) está ativado, um provedor de capacidade só pode ser conectado a um cluster ao mesmo tempo. Se o seu provedor de capacidade tiver a escalabilidade gerenciada desativada, será possível associá-lo a vários clusters. + Quando a escalabilidade gerenciada está desativada, o provedor de capacidade não reduz nem aumenta a escala horizontalmente. É possível usar uma estratégia de provedor de capacidade para equilibrar as tarefas entre provedores de capacidade. + A estratégia `binpack` é a mais eficiente em termos de capacidade. + Quando a capacidade pretendida é menos de 100%, dentro da estratégia de posicionamento, a estratégia `binpack` deve ter uma ordem maior do que a estratégia `spread`. Isso evita que o provedor de capacidade aumente a escala horizontalmente até que cada tarefa tenha uma instância dedicada ou que o limite seja atingido. ## Ativar o ajuste de escala automático de clusters É possível ativar o ajuste de escala automático de clusters usando o console ou a AWS CLI. Quando você cria um cluster que usa provedores de capacidade do EC2 usando o console, o Amazon ECS cria um grupo do Auto Scaling em seu nome e define a capacidade pretendida. Para obter mais informações, consulte [Criar um cluster do Amazon ECS para workloads do Amazon EC2](create-ec2-cluster-console-v2.md). Você também pode criar um grupo do Auto Scaling e depois atribuí-lo a um cluster. Para obter mais informações, consulte [Atualização de um provedor de capacidade do Amazon ECS](update-capacity-provider-console-v2.md). Ao usar a AWS CLI após criar o cluster 1. Antes de criar o provedor de capacidade, você precisa criar um grupo do Auto Scaling. Para obter mais informações, consulte[ Grupos do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. 1. Use `put-cluster-capacity-providers` para modificar o provedor de capacidade do cluster. Para obter mais informações, consulte [Ativação do ajuste de escala automático de cluster do Amazon ECS](turn-on-cluster-auto-scaling.md). # Otimização do ajuste de escala automático de cluster do Amazon ECS Os clientes que executam o Amazon ECS no Amazon EC2 podem aproveitar o ajuste de escala automático de cluster para gerenciar o ajuste de escala de grupos do Amazon EC2 Auto Scaling. Com o ajuste de escala automático de cluster, é possível configurar o Amazon ECS para escalar o grupo do Auto Scaling automaticamente e se concentrar apenas na execução das tarefas. O Amazon ECS garante que o grupo do Auto Scaling reduza ou aumente a escala horizontalmente, conforme necessário, sem a necessidade de intervenção adicional. Os provedores de capacidade do Amazon ECS são usados ​​para gerenciar a infraestrutura do cluster ao garantir que haja instâncias de contêiner suficientes para atender às demandas da aplicação. Para saber como o ajuste de escala automático de cluster funciona internamente, consulte [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/). O ajuste de escala automático de cluster depende de uma integração baseada no CloudWatch com o grupo do Auto Scaling para ajustar a capacidade do cluster. Portanto, ele tem uma latência inerente associada a + Publicar as métricas do CloudWatch, + O tempo necessário para a métrica `CapacityProviderReservation` violar os alarmes do CloudWatch (altos e baixos) + O tempo gasto por uma instância do Amazon EC2 recém-iniciada para entrar em modo de operação estável. É possível executar as seguintes ações para tornar o ajuste de escala automático de cluster mais responsivo com a finalidade de obter implantações mais rápidas: ## Tamanhos do ajuste de escala para as etapas do provedor de capacidade Os provedores de capacidade do Amazon ECS aumentarão ou reduzirão as instâncias de contêiner para atender às demandas da aplicação. Por padrão, o número mínimo de instâncias que o Amazon ECS iniciará está definido como um. Isso poderá adicionar mais tempo às implantações, se forem necessárias diversas instâncias para a atribuição das tarefas pendentes. É possível aumentar o [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) por meio da API do Amazon ECS com a finalidade de aumentar o número mínimo de instâncias em que o Amazon ECS aumenta ou reduz a escala horizontalmente ao mesmo tempo. Um [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) muito baixo pode limitar quantas instâncias de contêiner terão aumento ou redução da escala horizontalmente por vez, o que pode atrasar as implantações. **nota** No momento, essa configuração está disponível somente por meio das APIs [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html). ## Período de aquecimento da instância O período de aquecimento da instância corresponde ao período após o qual uma instância do Amazon EC2 iniciada recentemente pode contribuir para as métricas do CloudWatch relacionadas ao grupo do Auto Scaling. Depois que o período de aquecimento especificado expirar, a instância será contabilizada nas métricas agregadas do grupo do Auto Scaling, e o ajuste de escala automático de cluster continuará com sua próxima iteração de cálculos para estimar o número de instâncias necessárias. O valor padrão para [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod) é de 300 segundos, que você pode configurar para um valor mais baixo por meio das APIs [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) para obter um ajuste de escala mais responsivo. Recomendamos definir o valor como mais de 60 segundos para evitar provisionamento excessivo. ## Capacidade não utilizada Se o provedor de capacidade não tiver instâncias de contêiner disponíveis para a atribuição de tarefas, ele precisará aumentar (aumentar a escala horizontalmente) a capacidade do cluster ao iniciar instâncias do Amazon EC2 rapidamente e aguardar a inicialização antes de iniciar os contêineres nelas. Isso pode reduzir significativamente a taxa de inicialização de tarefas. Você tem duas opções disponíveis para lidar com isso. Nesse caso, ter a capacidade não utilizada do Amazon EC2 já iniciada e pronta para executar tarefas aumentará a taxa efetiva de inicialização de tarefas. É possível usar a configuração `Target Capacity` para indicar que deseja manter a capacidade não utilizada em seus clusters. Por exemplo, ao definir a `Target Capacity` como 80%, você indica que o cluster precisa de 20% de capacidade não utilizada disponível em todos os momentos. Essa capacidade não utilizada pode permitir que qualquer tarefa independente seja iniciada imediatamente, garantindo que a inicialização de tarefas não sofra o controle de utilização. A desvantagem desta abordagem é o potencial aumento dos custos de manutenção da capacidade não utilizada do cluster. Uma abordagem alternativa que pode ser considerada é adicionar reserva de capacidade ao seu serviço e não ao provedor de capacidade. Isso significa que, em vez de reduzir a configuração `Target Capacity` para iniciar a capacidade não utilizada, é possível aumentar o número de réplicas em seu serviço ao modificar a métrica de ajuste de escala de rastreamento de destino ou os limites de ajuste de escala em etapas do ajuste de escala automático do serviço. Observe que essa abordagem será útil somente para workloads com picos, mas não terá efeito ao implantar novos serviços e escalar de zero a determinado número de tarefas pela primeira vez. Para obter mais informações sobre as políticas de ajuste de escala relacionadas, consulte [Target Tracking Scaling Policies](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) ou [Step Scaling Policies](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. # Comportamento de escalabilidade gerenciada do Amazon ECS Quando você tem provedores de capacidade do grupo do Auto Scaling que usam ajuste de escala gerenciado, o Amazon ECS estima o número ideal de instâncias a serem adicionadas ao cluster e usa o valor para determinar quantas instâncias solicitar ou liberar. ## Comportamento gerenciado de aumento O Amazon ECS seleciona um provedor de capacidade para cada tarefa com base na estratégia do provedor de capacidade do serviço, da tarefa independente ou do padrão do cluster. O Amazon ECS segue o restante dessas etapas para um único provedor de capacidade. Tarefas sem uma estratégia de provedor de capacidade são ignoradas pelos provedores de capacidade. Uma tarefa pendente que não tenha uma estratégia de provedor de capacidade não fará com que nenhum provedor de capacidade sofra aumento de escala na horizontal. Tarefas ou serviços não podem definir uma estratégia de provedor de capacidade se essa tarefa ou serviço definir um tipo de inicialização. Veja a seguir a descrição do comportamento de aumento com mais detalhes. + Agrupe todas as tarefas de provisionamento desse provedor de capacidade para que cada grupo tenha os mesmos exatos requisitos de recursos. + Quando você usa vários tipos de instância em um grupo do Auto Scaling, os tipos de instância no grupo do Auto Scaling são ordenadas por seus parâmetros. Esses parâmetros incluem vCPU, memória, interfaces de rede elástica (ENIs), portas e GPUs. Os menores e maiores tipos de instância para cada parâmetro são selecionados. Para obter mais informações sobre como escolher o tipo de instância, consulte [Instâncias de contêiner do Amazon EC2 para o Amazon ECS](create-capacity.md). **Importante** Se um grupo de tarefas tiver requisitos de recursos maiores do que o menor tipo de instância no grupo do Auto Scaling, esse grupo de tarefas não poderá ser executado com esse provedor de capacidade. O provedor de capacidade não escala o grupo do Auto Scaling. As tarefas permanecem no estado `PROVISIONING`. Para evitar que as tarefas permaneçam no estado `PROVISIONING`, recomendamos que você crie grupos do Auto Scaling e provedores de capacidade separados para diferentes requisitos mínimos de recursos. Ao executar tarefas ou criar serviços, adicione somente provedores de capacidade à estratégia do provedor de capacidade que possa executar a tarefa no menor tipo de instância no grupo do Auto Scaling. Para outros parâmetros, é possível usar restrições de posicionamento + Para cada grupo de tarefas, o Amazon ECS calcula o número de instâncias necessárias para executar as tarefas não colocadas. Esse cálculo usa uma estratégia `binpack`. Essa estratégia leva em consideração os requisitos de vCPU, memória, interfaces de rede elásticas (ENI), portas e GPUs das tarefas. Ela também leva em consideração a disponibilidade de recursos das instâncias do Amazon EC2. Os valores para o maior tipo de instância são tratados como a contagem máxima de instâncias calculada. Os valores para o menor tipo de instância são usados como proteção. Se o menor tipo de instância não puder executar pelo menos uma instância da tarefa, o cálculo considerará a tarefa como não compatível. Como resultado, a tarefa será excluída do cálculo do aumento da escala horizontalmente. Quando todas as tarefas não são compatíveis com o menor tipo de instância, o ajuste de escala automático do cluster é interrompido e o valor `CapacityProviderReservation` permanece com o valor `targetCapacity`. + O Amazon ECS publicará a métrica `CapacityProviderReservation` para o CloudWatch em relação ao `minimumScalingStepSize` se ocorrer qualquer um dos eventos a seguir. + A contagem máxima de instâncias calculadas é menor que o tamanho mínimo da etapa de ajuste de escala. + O valor mais baixo para `maximumScalingStepSize` ou para a contagem máxima de instâncias calculadas. + Os alarmes do CloudWatch usam a métrica `CapacityProviderReservation` para provedores de capacidade. Quando a métrica `CapacityProviderReservation` é maior que o valor da `targetCapacity`, os alarmes também aumentam a `DesiredCapacity` do grupo do Auto Scaling. O valor `targetCapacity` é uma configuração do provedor de capacidade que é enviada para o alarme do CloudWatch durante a fase de ativação da autoescalabilidade do cluster. O padrão para `targetCapacity` é de 100%. + O grupo do Auto Scaling inicia instâncias do EC2 adicionais. Para evitar o excesso de provisionamento, o Auto Scaling garante que a capacidade das instâncias do EC2 executadas recentemente esteja estabilizada antes de executar novas instâncias. O Auto Scaling verifica se todas as instâncias existentes passaram pelo `instanceWarmupPeriod` (agora, subtraindo o tempo de inicialização da instância). O aumento horizontal da escala é bloqueado para instâncias que estão dentro do `instanceWarmupPeriod`. O número padrão de segundos para o aquecimento de uma instância recém-ativada é 300. Para obter mais informações, consulte [Deep dive on Amazon ECS cluster auto scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) (Análise profunda da autoescalabilidade de clusters do Amazon ECS). ### Considerações sobre aumento de escala na horizontal Considere o seguinte para o processo de aumento de escala na horizontal: + Embora existam várias restrições de posicionamento, recomendamos usar a restrição de posicionamento de tarefas `distinctInstance`. Isso impede que o processo de aumento de escala horizontalmente seja interrompido porque você está usando uma restrição de posicionamento que não é compatível com as instâncias amostradas. + A escalabilidade gerenciada funciona melhor se o grupo do Auto Scaling usa os mesmos tipos de instância ou semelhantes. + Quando um processo de aumento de escala na horizontal for necessário e não houver instâncias de contêiner em execução no momento, o Amazon ECS sempre aumentará a escala horizontalmente para duas instâncias no início e, em seguida, executará processos adicionais de redução ou aumento da escala na horizontal. Qualquer aumento de escala na horizontal adicional aguardará o período de aquecimento da instância. Para processos de redução de escala na horizontal, o Amazon ECS espera 15 minutos após um processo de aumento de escala na horizontal antes de iniciar os processos de redução de escala na horizontal a qualquer momento. + A segunda etapa de aumento da escala na horizontal precisa aguardar até que o `instanceWarmupPeriod` expire, o que pode afetar o limite geral da escala. Caso precise reduzir esse tempo, certifique-se de que `instanceWarmupPeriod` seja grande o suficiente para que a instância do EC2 seja executada e inicie o agente do Amazon ECS (o que impede o excesso de provisionamento). + O ajuste de escala automático de clusters oferece suporte à configuração de execução, aos modelos de execução e a vários tipos de instâncias no grupo do Auto Scaling do provedor de capacidade. Também é possível usar a seleção de tipo de instância baseada em atributos sem vários tipos de instâncias. + Ao usar um grupo do Auto Scaling com instâncias sob demanda e vários tipos de instância ou instâncias spot, coloque os tipos de instância maiores acima na lista de prioridades e não especifique um peso. Não há suporte para a especificação de um peso, no momento. Para obter mais informações, consulte [Grupos do Auto Scaling com vários tipos de instância](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) no *Guia do usuário do AWS Auto Scaling*. + O Amazon ECS iniciará o `minimumScalingStepSize` se a contagem máxima de instâncias calculada for menor do que o tamanho mínimo da etapa de escalabilidade ou o que for menor entre `maximumScalingStepSize` e o valor máximo calculado da contagem de instâncias. + Se um serviço ou `run-task` do Amazon ECS iniciar uma tarefa e as instâncias de contêiner do provedor de capacidade não tiverem recursos suficientes para iniciá-la, o Amazon ECS limitará o número de tarefas com esse status para cada cluster e impedirá que qualquer tarefa ultrapasse esse limite. Para obter mais informações, consulte [Cotas de serviço do Amazon ECS](service-quotas.md). ## Comportamento gerenciado de redução de escala na horizontal O Amazon ECS monitora instâncias de contêiner para cada provedor de capacidade dentro de um cluster. Quando uma instância de contêiner não executa nenhuma tarefa, ela é considerada vazia e o Amazon ECS inicia o processo de redução de escala na horizontal. Os alarmes de escalabilidade do CloudWatch exigem 15 pontos de dados (15 minutos) antes do início do processo de escalabilidade para o grupo do Auto Scaling. Depois que o processo de redução de escala na horizontal é iniciado, até que o Amazon ECS precise reduzir o número de instâncias de contêiner registradas, o grupo do Auto Scaling define o valor `DesireCapacity` como sendo maior que uma instância e menor que 50% a cada minuto. Quando o Amazon ECS solicitar um aumento da escala horizontalmente (quando `CapacityProviderReservation` for maior que 100) enquanto um processo de redução da escala horizontalmente estiver em andamento, o processo de redução da escala horizontalmente será interrompido e começará do início, se necessário. Veja a seguir a descrição do comportamento de redução de escala na horizontal com mais detalhes: 1. O Amazon ECS calcula o número de instâncias de contêiner vazias. Uma instância de contêiner é considerada vazia mesmo quando houver tarefas de daemon em execução. 1. O Amazon ECS define o valor `CapacityProviderReservation` como um número entre 0 e 100 que usa a fórmula a seguir para representar a proporção de quão grande o grupo do Auto Scaling precisa ser em relação ao quão grande ele realmente é, expressa como um percentual. Em seguida, o Amazon ECS publica a métrica no CloudWatch. Para obter mais informações sobre como a métrica é calculada, consulte [Análise profunda do ajuste de escala automático de clusters do Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/). ``` CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100 ``` 1. A métrica `CapacityProviderReservation` gera um alarme do CloudWatch. Esse alarme atualiza o valor `DesiredCapacity` para o grupo do Auto Scaling. Em seguida, ocorre uma das seguintes ações: + Se você não usar o encerramento gerenciado do provedor de capacidade, o grupo do Auto Scaling selecionará instâncias do EC2 usando a política de encerramento do grupo do Auto Scaling e encerrará as instâncias até que o número de instâncias do EC2 atinja a `DesiredCapacity`. As instâncias de contêiner são canceladas do registro do cluster. + Se todas as instâncias de contêiner usarem proteção contra encerramento gerenciado, o Amazon ECS removerá a proteção de redução de escala na horizontal nas instâncias de contêiner que estiverem vazias. O grupo do Auto Scaling poderá, então, terminar as instâncias do EC2. As instâncias de contêiner são canceladas do registro do cluster. # Controle das instâncias encerradas pelo Amazon ECS **Importante** Você deve ativar a *proteção contra redução de escala na horizontal de instâncias* do ajuste de escala automático no grupo do Auto Scaling para usar o recurso de proteção contra encerramento gerenciada do ajuste de escala automático de clusters. A proteção gerenciada contra encerramento permite o ajuste de escala automático de cluster para controlar quais instâncias serão encerradas. Quando você usa a proteção gerenciada contra encerramento, o Amazon ECS encerra somente as instâncias do EC2 que não têm tarefas do Amazon ECS em execução. As tarefas executadas por um serviço que use a estratégia de agendamento `DAEMON` serão ignoradas, e uma instância poderá ser encerrada pelo ajuste de escala automático de clusters mesmo quando a instância estiver executando essas tarefas. Isso ocorre porque todas as instâncias no cluster estão executando essas tarefas. Primeiro, o Amazon ECS ativa a opção de *proteção contra a redução de escala horizontalmente de instâncias* para as instâncias do EC2 no grupo do Auto Scaling. Em seguida, o Amazon ECS coloca as tarefas nas instâncias. Quando todas as tarefas diferentes de daemon são interrompidas em uma instância, o Amazon ECS inicia o processo de redução da escala na horizontal e desativa a proteção contra redução da escala na horizontal para a instância do EC2. O grupo do Auto Scaling pode então terminar a instância. A *proteção contra redução de escala na horizontal de instâncias* do ajuste de escala automático controla quais instâncias do EC2 podem ser encerradas pelo ajuste de escala automático. Instâncias com o recurso de redução da escala horizontalmente ativado não podem ser encerradas durante o processo de redução da escala horizontalmente. Para obter mais informações sobre a proteção contra redução de escala na horizontal de instâncias do Auto Scaling, consulte [Uso de proteção contra redução de escala na horizontal de instâncias](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. Você pode definir o percentual de `targetCapacity` para ter capacidade disponível. Isso ajuda a executar tarefas futuras mais rapidamente porque o grupo do Auto Scaling não precisa executar mais instâncias. O Amazon ECS usa o valor da capacidade de destino para gerenciar a métrica do CloudWatch criada pelo serviço. O Amazon ECS gerencia a métrica do CloudWatch. O grupo do Auto Scaling será tratado como um estado estável para que nenhuma ação de ajuste de escala seja necessária. Os valores podem ser de 0 a 100%. Por exemplo, para configurar o Amazon ECS para manter 10% de capacidade livre sobre a usada pelas tarefas do Amazon ECS, defina o valor de capacidade-alvo como 90%. Considere as informações a seguir quando definir o valor da `targetCapacity` em um provedor de capacidade. + Um valor de `targetCapacity` inferior a 100% representa a quantidade de capacidade livre (instâncias do Amazon EC2) que precisam estar presentes no cluster. Capacidade livre significa que não há tarefas em execução. + Restrições de posicionamento, como zonas de disponibilidade, sem `binpack` adicional, forçam o Amazon ECS a acabar executando uma tarefa por cada instância, o que pode não ser o comportamento desejado. É necessário ativar a proteção contra redução de escala na horizontal de instâncias do ajuste de escala automático no grupo Auto Scaling para usar a proteção contra encerramento gerenciada. Se você não ativar a proteção de redução de escala na horizontal, ativar a proteção contra encerramento gerenciada poderá levar a um comportamento indesejável. Por exemplo, é possível ter instâncias paralisadas em estado de drenagem. Para obter mais informações, consulte [Uso de proteção contra redução de escala na horizontal da instância](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. Ao usar a proteção contra encerramento com um provedor de capacidade, não execute nenhuma ação manual, como desvincular a instância, no grupo do Auto Scaling associado ao provedor de capacidade. Ações manuais podem interromper a operação de redução de escala na horizontal do provedor de capacidade. Se você desvincular uma instância do grupo do Auto Scaling, precisará também [cancelar o registro da instância desvinculada](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html) no cluster do Amazon ECS. # Atualizar a proteção gerenciada contra encerramento para provedores de capacidade do Amazon ECS Ao usar a configuração de proteção gerenciada contra encerramento, é necessário atualizar a configuração para provedores de capacidade existentes. ## 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. 1. Na página do cluster, escolha a guia **Infraestrutura**. 1. Escolha o provedor de capacidade. 1. Escolha **Atualizar** para modificar as configurações do provedor de capacidade. 1. Em **Configurações do grupo do Auto Scaling**, ative a opção **Proteção gerenciada contra encerramento** para habilitar ou desabilitar o recurso. 1. Selecione **Atualizar**. ## AWS CLI Você pode atualizar a configuração de proteção gerenciada contra encerramento um provedor de capacidade usando o comando `update-capacity-provider`: Para habilitar a proteção gerenciada contra encerramento: ``` aws ecs update-capacity-provider \ --name CapacityProviderName \ --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=ENABLED" ``` Para desabilitar a proteção gerenciada contra encerramento: ``` aws ecs update-capacity-provider \ --name CapacityProviderName \ --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=DISABLED" ``` **nota** Alguns minutos podem ser necessários para que as alterações entrem em vigor em todo o cluster. Quando a proteção gerenciada contra encerramento é habilitada, as instâncias que já estão executando tarefas serão protegidas contra eventos de redução da escala horizontal. Quando a proteção gerenciada contra encerramento é desabilitada, o sinalizador de proteção será removido das instâncias durante o próximo ciclo de gerenciamento do provedor de capacidade do ECS. ## Console para a execução de tarefas 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. 1. Na página do cluster, escolha a guia **Tarefas**. 1. Escolha a tarefa. 1. Em **Configuração**, alterne **Proteção gerenciada contra encerramento** para habilitar ou desabilitar o recurso. 1. Escolha **Configurar proteção de tarefa na redução da escala**. A caixa de diálogo **Configurar proteção de tarefa na redução da escala** é exibida 1. Em **Proteção de tarefa na redução da escala**, alterne para **Habilitar**. 1. Em **Expira em minutos**, insira o número de minutos antes que a proteção de tarefa na redução da escala termine. 1. Escolha **Update (Atualizar)** # Ativação do ajuste de escala automático de cluster do Amazon ECS Você ativa o ajuste de escala automático de cluster, para que o Amazon ECS gerencie o ajuste de escala de instâncias do Amazon EC2 registradas no cluster. Se você quiser usar o console para ativar o ajuste de escala automático do cluster, consulte [Criação de um provedor de capacidade para o Amazon ECS](create-capacity-provider-console-v2.md). Antes de você começar, crie um grupo do Auto Scaling e um provedor de capacidade. Para obter mais informações, consulte [Provedores de capacidade do Amazon ECS para workloads do EC2](asg-capacity-providers.md). Para ativar o ajuste de escala automático de cluster, associe o provedor de capacidade ao cluster e, em seguida, ative o ajuste de escala automático de cluster. 1. Use o comando `put-cluster-capacity-providers` para associar um ou mais provedores de capacidade ao cluster. Para adicionar os provedores de capacidade do AWS Fargate, inclua os provedores de capacidade `FARGATE` e `FARGATE_SPOT` na solicitação. Para obter mais informações, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs put-cluster-capacity-providers \ --cluster ClusterName \ --capacity-providers CapacityProviderName FARGATE FARGATE_SPOT \ --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1 ``` Para adicionar um grupo do Auto Scaling para o EC2, inclua o nome do grupo do Auto Scaling na solicitação. Para obter mais informações, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs put-cluster-capacity-providers \ --cluster ClusterName \ --capacity-providers CapacityProviderName \ --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1 ``` 1. Use o comando `describe-clusters` para verificar se a associação foi bem-sucedida. Para obter mais informações, consulte `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs describe-clusters \ --cluster ClusterName \ --include ATTACHMENTS ``` 1. Use o comando `update-capacity-provider` para ativar a autoescalabilidade gerenciada para o provedor de capacidade. Para obter mais informações, consulte `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs update-capacity-provider \ --name CapacityProviderName \ --auto-scaling-group-provider "managedScaling={status=ENABLED}" ``` # Desativação do ajuste de escala automático de cluster do Amazon ECS Você desativa o ajuste de escala automático de cluster quando precisa de um controle mais granular das instâncias do EC2 registradas em seu cluster. Para desativar o ajuste de escala automático de cluster para um cluster, é possível desassociar o provedor de capacidade com o ajuste de escala gerenciado ativado no cluster ou atualizar o provedor de capacidade para desativar o ajuste de escala gerenciado. ## Desassociação do provedor de capacidade Use as etapas a seguir para desassociar um provedor de capacidade de um cluster. 1. Use o comando `put-cluster-capacity-providers` para desassociar o provedor de capacidade do grupo do Auto Scaling do cluster. O cluster pode manter a associação com os provedores de capacidade do AWS Fargate. Para obter mais informações, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs put-cluster-capacity-providers \ --cluster ClusterName \ --capacity-providers FARGATE FARGATE_SPOT \ --default-capacity-provider-strategy '[]' ``` Use o comando `put-cluster-capacity-providers` para desassociar o provedor de capacidade do grupo do Auto Scaling do cluster. Para obter mais informações, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs put-cluster-capacity-providers \ --cluster ClusterName \ --capacity-providers [] \ --default-capacity-provider-strategy '[]' ``` 1. Use o comando `describe-clusters` para verificar se a desassociação foi bem-sucedida. Para obter mais informações, consulte `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs describe-clusters \ --cluster ClusterName \ --include ATTACHMENTS ``` ## Desativar a escalabilidade gerenciada do provedor de capacidade Use as etapas a seguir para desativar a escalabilidade gerenciada do provedor de capacidade. + Use o comando `update-capacity-provider` para desativar a autoescalabilidade gerenciada para o provedor de capacidade. Para obter mais informações, consulte `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` na *Referência de comandos da AWS CLI*. ``` aws ecs update-capacity-provider \ --name CapacityProviderName \ --auto-scaling-group-provider "managedScaling={status=DISABLED}" ``` # Criação de um provedor de capacidade para o Amazon ECS Depois que a criação do cluster for concluída, será possível criar um novo provedor de capacidade (grupo do Auto Scaling) para o EC2. Os provedores de capacidade ajudam a gerenciar e escalar a infraestrutura para suas aplicações. Antes de criar o provedor de capacidade, você precisa criar um grupo do Auto Scaling. Para obter mais informações, consulte[ Grupos do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. **Para criar um provedor de capacidade para o cluster (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**. 1. Na página **Clusters**, escolha o cluster. 1. Na página **Cluster: *name*** (Cluster: nome), escolha **Infrastructure** (Infraestrutura) e, em seguida, escolha **Create** (Criar). 1. Na página **Create capacity providers** (Criar provedores de capacidade), configure as opções a seguir. 1. Em **Basic details** (Detalhes básicos), em **Capacity provider name** (Nome do provedor de capacidade), insira um nome exclusivo de provedor de capacidade. 1. Em **Auto Scaling group** (grupo do Auto Scaling), em **Use an existing Auto Scaling group** (Usar um grupo existente do Auto Scaling), escolha o grupo do Auto Scaling. 1. (Opcional) Para configurar uma política de escalabilidade, em **Scaling policies** (Políticas de escalabilidade), configure as opções a seguir. + Para que o Amazon ECS gerencie as ações de redução e aumento da escala horizontalmente, selecione **Turn on managed scaling** (Ativar escalabilidade gerenciada). + Para evitar que uma instância do EC2 com tarefas do Amazon ECS em execução seja encerrada, selecione **Turn on scaling protection** (Ativar proteção de escalabilidade). + Em **Set target capacity** (Definir capacidade de destino), insira o valor de destino para a métrica do CloudWatch usada na política de escalabilidade de rastreamento de destino gerenciada pelo Amazon ECS. 1. Escolha **Criar**. # Atualização de um provedor de capacidade do Amazon ECS Quando você usa um grupo do Auto Scaling como provedor de capacidade, é possível modificar a política de escalabilidade do grupo. **Para atualizar um provedor de capacidade do cluster (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**. 1. Na página **Clusters**, escolha o cluster. 1. Na página **Cluster: *name*** (Cluster: nome), escolha **Infrastructure** (Infraestrutura) e, em seguida, escolha **Update** (Atualizar). 1. Na página **Create capacity providers** (Criar provedores de capacidade), configure as opções a seguir. 1. Em **Grupo do Auto Scaling**, em **Políticas de escalabilidade**, configure as opções a seguir. + Para que o Amazon ECS gerencie as ações de redução e aumento da escala horizontalmente, selecione **Turn on managed scaling** (Ativar escalabilidade gerenciada). + Para evitar que instâncias do EC2 com tarefas do Amazon ECS em execução sejam encerradas, selecione **Ativar proteção de escalabilidade**. + Em **Set target capacity** (Definir capacidade de destino), insira o valor de destino para a métrica do CloudWatch usada na política de escalabilidade de rastreamento de destino gerenciada pelo Amazon ECS. 1. Selecione **Atualizar**. # Exclusão de um provedor de capacidade do Amazon ECS Se você tiver terminado de usar um provedor de capacidade de grupo do Auto Scaling, poderá excluí-lo. Depois que o grupo for excluído, o provedor de capacidade do grupo do Auto Scaling fará a transição para o estado `INACTIVE`. Os clusters com um status `INACTIVE` podem permanecer detectáveis em sua conta durante algum tempo. No entanto, esse comportamento está sujeito a alterações no futuro, então você não deve confiar na persistência de provedores de capacidade `INACTIVE`. Antes que o provedor de capacidade de grupo do Auto Scaling seja excluído, o provedor de capacidade deverá ser removido da estratégia de provedor de capacidade de todos os serviços. É possível usar a API `UpdateService` ou o fluxo de trabalho do serviço de atualização no console do Amazon ECS para remover um provedor de capacidade da estratégia do provedor de capacidade de um serviço. Use a opção **Forçar uma nova implantação** para garantir que todas as tarefas que usam a capacidade de instância do Amazon EC2 fornecida pelo provedor de capacidade sejam transferidas para usar a capacidade dos provedores de capacidade restantes. **Para excluir um provedor de capacidade para o cluster (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**. 1. Na página **Clusters**, escolha o cluster. 1. Na página **Cluster: *name*** (Cluster: nome), escolha **Infrastructure** (Infraestrutura), o grupo do Auto Scaling e, em seguida, escolha **Delete** (Excluir). 1. Na caixa de confirmação, insira **delete *nome do grupo do Auto Scaling***. 1. Escolha **Excluir**. # Interrupção de workloads do Amazon ECS em execução em instâncias do EC2 com segurança A drenagem gerenciada de instância facilita a interrupção normal de instâncias do Amazon EC2. Isso permite que as workloads sejam interrompidas com segurança e reprogramadas para instâncias sem interrupção. A manutenção e as atualizações da infraestrutura são realizadas sem se preocupar com a interrupção das workloads. Ao usar a drenagem gerenciada de instâncias, você simplifica os fluxos de trabalho de gerenciamento da infraestrutura que exigem a substituição das instâncias do Amazon EC2 e, ao mesmo tempo, garante a resiliência e a disponibilidade das aplicações. A drenagem gerenciada de instâncias do Amazon ECS funciona com substituições de instâncias do grupo do Auto Scaling. Com base na atualização da instância e na vida útil máxima dela, os clientes podem garantir a conformidade com os requisitos mais recentes de sistema operacional e segurança da capacidade. A drenagem gerenciada de instâncias pode ser usada somente com provedores de capacidade do Amazon ECS. É possível ativar a drenagem gerenciada de instâncias ao criar ou ao atualizar provedores de capacidade de grupo do Auto Scaling usando o console do Amazon ECS, a AWS CLI ou o SDK. Os eventos a seguir são cobertos pela drenagem gerenciada de instâncias do Amazon ECS. + [Atualização de instâncias do grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html): use a atualização de instâncias para realizar a substituição contínua das instâncias do Amazon EC2 no grupo do Auto Scaling em vez de fazer isso manualmente em lotes. Isso é útil quando você precisa substituir um grande número de instâncias. Uma atualização de instâncias é iniciada por meio do console do Amazon EC2 ou da API `StartInstanceRefresh`. Certifique-se de selecionar `Replace` para ativar a proteção na redução da escala ao chamar `StartInstanceRefresh` se estiver usando a proteção de encerramento gerenciada. + [Vida útil máxima da instância](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-max-instance-lifetime.html): você pode definir uma vida útil máxima quando se trata de substituir instâncias do grupo do Auto Scaling. Isso é útil para programar instâncias de substituição com base em políticas internas de segurança ou conformidade. + Redução horizontal de escala no grupo do Auto Scaling: com base em políticas de ajuste de escala e ações de ajuste de escala programadas, o grupo do Auto Scaling oferece suporte ao ajuste de escala automático de instâncias. Ao usar um grupo do Auto Scaling como provedor de capacidade do Amazon ECS, é possível reduzir a escala horizontalmente para instâncias de grupos do Auto Scaling quando nenhuma tarefa estiver em execução nessas instâncias. + [Verificações de integridade no grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html): o grupo do Auto Scaling oferece suporte a várias verificações de integridade para gerenciar o encerramento de instâncias não íntegras. + [Atualizações da pilha do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html): é possível adicionar um atributo `UpdatePolicy` à pilha do CloudFormation para executar atualizações cumulativas quando o grupo sofre alterações. + [Rebalanceamento de capacidade do spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html): o grupo do Auto Scaling tenta substituir, de forma proativa, as instâncias spot que apresentam maior risco de interrupção com base no aviso de rebalanceamento de capacidade do Amazon EC2. O grupo do Auto Scaling encerra a instância antiga quando a substituição é executada e está íntegra. A drenagem gerenciada de instâncias do Amazon ECS drena a instância spot da mesma forma que drena uma instância não spot. + [Interrupção de spot](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html): as instâncias spot são encerradas com um aviso prévio de dois minutos. A drenagem de instâncias gerenciada pelo Amazon ECS coloca a instância em estado de drenagem em resposta. **Ganchos do ciclo de vida do Amazon EC2 Auto Scaling com drenagem gerenciada de instâncias** Os ganchos do ciclo de vida do grupo do Auto Scaling permitem ao cliente criar soluções que são acionadas por determinados eventos no ciclo de vida da instância e executar uma ação personalizada quando esse evento ocorre. Um grupo do Auto Scaling permite até 50 hooks. Diversos ganchos de encerramento podem existir e serem executados em paralelo, e o grupo do Auto Scaling aguardará a conclusão de todos os hooks antes de encerrar uma instância. Além do encerramento de hook gerenciado pelo Amazon ECS, você pode configurar seus próprios hooks de encerramento do ciclo de vida. Os hooks do ciclo de vida têm uma `default action`, e recomendamos definir `continue` como o padrão para garantir que outros hooks, como o hook gerenciado pelo Amazon ECS, não sejam afetados por erros de hooks personalizados. Se você já configurou um hook do ciclo de vida de encerramento para um grupo do Auto Scaling e também habilitou a drenagem gerenciada de instâncias do Amazon ECS, ambos os hooks do ciclo de vida serão executados. No entanto, não há garantia para os horários relativos. Os ganchos do ciclo de vida têm uma configuração `default action` para especificar a ação a ser executada quando o tempo limite expirar. Em caso de falhas, recomendamos usar `continue` como resultado padrão no hook personalizado. Isso garante que outros hooks, principalmente os que são gerenciados pelo Amazon ECS, não sejam afetados por erros presentes no hook de ciclo de vida personalizado. O resultado alternativo de `abandon` faz com que todos os outros hooks sejam ignorados e deve ser evitado. Para obter mais informações sobre os ganchos do ciclo de vida para o grupo do Auto Scaling, consulte [Amazon EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) no Guia do usuário do *Amazon EC2* Auto Scaling. **Tarefas e drenagem gerenciada de instâncias** A drenagem gerenciada de instâncias do Amazon ECS usa o recurso de drenagem existente encontrado nas instâncias de contêineres. O recurso de [drenagem de instância de contêiner](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-draining.html) realiza a substituição e interrupção das tarefas de réplica que pertencem a um serviço do Amazon ECS. Uma tarefa independente, como uma invocada por `RunTask`, que está no estado `PENDING` ou `RUNNING`, permanecerá inalterada. Você terá que esperar que as tarefas sejam concluídas ou interrompê-las de forma manual. A instância de contêiner permanece no estado `DRAINING` até que todas as tarefas sejam interrompidas ou até que 48 horas tenham se passado. As tarefas do daemon são as últimas a serem interrompidas depois que todas as tarefas de réplica são interrompidas. **Drenagem gerenciada de instâncias e proteção gerenciada de encerramento** A drenagem gerenciada de instâncias funciona mesmo se o encerramento gerenciado estiver desabilitado. Para obter informações sobre a proteção contra o encerramento gerenciado, consulte [Controle das instâncias encerradas pelo Amazon ECS](managed-termination-protection.md). A tabela a seguir resume o comportamento de diferentes combinações de encerramento e drenagem gerenciados. | Encerramento gerenciado | Drenagem gerenciada | Outcome | | --- | --- | --- | | Habilitado | Habilitado | O Amazon ECS protege as instâncias do Amazon EC2 que estão executando tarefas de serem encerradas por eventos de redução horizontal de escala. Todas as instâncias que estão sendo encerradas, como aquelas que não têm proteção de encerramento definida, receberam interrupção spot ou são forçadas pela atualização da instância, são drenadas normalmente. | | Desabilitado | Habilitado | O Amazon ECS não oferece proteção para as instâncias do Amazon EC2 que executam tarefas contra a redução da escala horizontalmente. No entanto, todas as instâncias que estão sendo encerradas são drenadas normalmente. | | Habilitado | Desabilitado | O Amazon ECS protege as instâncias do Amazon EC2 que estão executando tarefas de serem encerradas por eventos de redução horizontal de escala. No entanto, as instâncias ainda podem ser encerradas por interrupção spot ou atualização forçada da instância, ou se não estiverem executando nenhuma tarefa. O Amazon ECS não realiza uma drenagem normal dessas instâncias e executa tarefas de serviço de substituição depois que elas são interrompidas. | | Desabilitado | Desabilitado | As instâncias do Amazon EC2 podem reduzir a escala horizontalmente ou ser encerradas a qualquer momento, mesmo que estejam executando tarefas do Amazon ECS. O Amazon ECS executará tarefas de serviço de substituição depois que elas forem encerradas. | **Drenagem gerenciada de instâncias e drenagem de instância spot** Com a drenagem de instância spot, é possível definir uma variável de ambiente `ECS_ENABLE_SPOT_INSTANCE_DRAINING` no agente do Amazon ECS que habilita que o Amazon ECS atribua uma instância no status de drenagem em resposta à interrupção de spot de dois minutos. A drenagem gerenciada de instâncias do Amazon ECS facilita o desligamento normal de instâncias do Amazon EC2 que estão sendo encerradas por vários motivos, não apenas por interrupções spot. Por exemplo, é possível usar o rebalanceamento de capacidade do Amazon EC2 Auto Scaling para substituir, de forma proativa, a instância spot com risco elevado de interrupção, e a drenagem da instância gerenciada executa o encerramento tranquilo da instância spot que está sendo substituída. Ao usar a drenagem gerenciada de instâncias, não é necessário habilitar a drenagem de instâncias spot separadamente. Portanto, usar `ECS_ENABLE_SPOT_INSTANCE_DRAINING` nos dados do usuário do grupo do Auto Scaling é redundante. Para obter mais informações sobre a drenagem de instância spot, consulte [Instâncias spot](create-capacity.md#container-instance-spot). ## Como funciona a drenagem gerenciada de instâncias com o EventBridge Os eventos de drenagem gerenciada de instâncias do Amazon ECS são publicados no Amazon EventBridge, e o Amazon ECS cria uma regra gerenciada do EventBridge no barramento padrão da sua conta para oferecer suporte à drenagem gerenciada de instâncias. Você pode filtrar esses eventos para outros serviços da AWS, como o Lambda, o Amazon SNS e o Amazon SQS para monitorar e solucionar problemas. + O Amazon EC2 Auto Scaling envia um evento para o EventBridge quando um hook de ciclo de vida é invocado. + Avisos de interrupção spot são publicados no EventBridge. + O Amazon ECS gera mensagens de erro que você pode recuperar por meio do console e das APIs do Amazon ECS. + O EventBridge tem mecanismos de repetição incorporados como mitigações para falhas temporárias. # Configuração de provedores de capacidade do Amazon ECS para o desligamento de instâncias com segurança É possível ativar a drenagem gerenciada de instâncias ao criar ou ao atualizar provedores de capacidade do grupo do Auto Scaling usando o console do Amazon ECS e a AWS CLI. **nota** Por padrão, a drenagem gerenciada de instâncias é ativada quando você cria um provedor de capacidade. Veja a seguir exemplos de uso da AWS CLI para criar um provedor de capacidade com a drenagem gerenciada de instâncias ativada e habilitar a drenagem gerenciada de instâncias para o provedor de capacidade existente de um cluster. **Criação de um provedor de capacidade com a drenagem gerenciada de instâncias habilitada** Para criar um provedor de capacidade com a drenagem gerenciada de instâncias habilitada, use o comando `create-capacity-provider`. Defina o parâmetro `managedDraining` como `ENABLED`. ``` aws ecs create-capacity-provider \ --name capacity-provider \ --auto-scaling-group-provider '{ "autoScalingGroupArn": "asg-arn", "managedScaling": { "status": "ENABLED", "targetCapacity": 100, "minimumScalingStepSize": 1, "maximumScalingStepSize": 1 }, "managedDraining": "ENABLED", "managedTerminationProtection": "ENABLED", }' ``` Resposta: ``` { "capacityProvider": { "capacityProviderArn": "capacity-provider-arn", "name": "capacity-provider", "status": "ACTIVE", "autoScalingGroupProvider": { "autoScalingGroupArn": "asg-arn", "managedScaling": { "status": "ENABLED", "targetCapacity": 100, "minimumScalingStepSize": 1, "maximumScalingStepSize": 1 }, "managedTerminationProtection": "ENABLED" "managedDraining": "ENABLED" } } } ``` **Como habilitar a drenagem gerenciada de instâncias para o provedor de capacidade existente de um cluster** Habilitar a drenagem gerenciada de instâncias para o provedor de capacidade existente de um cluster usa o comando `update-capacity-provider`. Você nota que `managedDraining` atualmente diz `DISABLED` e `updateStatus` diz `UPDATE_IN_PROGRESS`. ``` aws ecs update-capacity-provider \ --name cp-draining \ --auto-scaling-group-provider '{ "managedDraining": "ENABLED" } ``` Resposta: ``` { "capacityProvider": { "capacityProviderArn": "cp-draining-arn", "name": "cp-draining", "status": "ACTIVE", "autoScalingGroupProvider": { "autoScalingGroupArn": "asg-draining-arn", "managedScaling": { "status": "ENABLED", "targetCapacity": 100, "minimumScalingStepSize": 1, "maximumScalingStepSize": 1, "instanceWarmupPeriod": 300 }, "managedTerminationProtection": "DISABLED", "managedDraining": "DISABLED" // before update }, "updateStatus": "UPDATE_IN_PROGRESS", // in progress and need describe again to find out the result "tags": [ ] } } ``` Use o comando `describe-clusters` e inclua `ATTACHMENTS`. O `status` do anexo de drenagem gerenciada de instâncias é `PRECREATED`, e o `attachmentsStatus` geral é `UPDATING`. ``` aws ecs describe-clusters --clusters cluster-name --include ATTACHMENTS ``` Resposta: ``` { "clusters": [ { ... "capacityProviders": [ "cp-draining" ], "defaultCapacityProviderStrategy": [], "attachments": [ # new precreated managed draining attachment { "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "type": "managed_draining", "status": "PRECREATED", "details": [ { "name": "capacityProviderName", "value": "cp-draining" }, { "name": "autoScalingLifecycleHookName", "value": "ecs-managed-draining-termination-hook" } ] }, ... ], "attachmentsStatus": "UPDATING" } ], "failures": [] } ``` Quando a atualização estiver concluída, use `describe-capacity-providers` e você verá que `managedDraining` agora é `ENABLED`. ``` aws ecs describe-capacity-providers --capacity-providers cp-draining ``` Resposta: ``` { "capacityProviders": [ { "capacityProviderArn": "cp-draining-arn", "name": "cp-draining", "status": "ACTIVE", "autoScalingGroupProvider": { "autoScalingGroupArn": "asg-draning-arn", "managedScaling": { "status": "ENABLED", "targetCapacity": 100, "minimumScalingStepSize": 1, "maximumScalingStepSize": 1, "instanceWarmupPeriod": 300 }, "managedTerminationProtection": "DISABLED", "managedDraining": "ENABLED" // successfully update }, "updateStatus": "UPDATE_COMPLETE", "tags": [] } ] } ``` ## Solução de problemas de esgotamento de instância gerenciada do Amazon ECS Talvez seja necessário solucionar problemas relacionados com a drenagem gerenciada de instâncias. A seguir, apresentamos um exemplo de problema que você pode encontrar ao utilizá-la e sua resolução. **As instâncias não são encerradas após o tempo de vida máximo da instância ser excedido ao usar o ajuste de escala automático.** Se as instâncias não forem encerradas mesmo depois de atingir e exceder o tempo de vida máximo da instância ao usar um grupo do Auto Scaling, pode ser porque elas estão protegidas contra a redução da escala horizontalmente. É possível desativar o encerramento gerenciado e permitir a drenagem gerenciada para lidar com a reciclagem de instâncias. ## Comportamento da drenagem de instâncias gerenciadas do Amazon ECS. O encerramento de instâncias gerenciadas do Amazon ECS garante transições de workload perfeitas, ao mesmo tempo em que otimiza os custos e mantem a integridade do sistema. O sistema de encerramento fornece três caminhos de decisão distintos para encerramento de instâncias, cada um com diferentes características de tempo e perfis de impacto no cliente. ### Caminhos de decisão de encerramento Encerramento iniciado pelo cliente Fornece controle direto sobre a remoção de instâncias quando você precisa remover imediatamente as instâncias de contêiner do serviço. Você invoca a API DeregisterContainerInstance com o sinalizador forçar definido como verdadeiro, indicando que o encerramento imediato é necessário, apesar de qualquer workload em execução. Encerramento por inatividade iniciado pelo sistema As instâncias gerenciadas do Amazon ECS monitoram continuamente e otimizam os custos de maneira proativa, encerrando instâncias de contêineres inativas do Amazon ECS que não estão executando tarefas. O ECS utiliza um atraso heurístico para dar às instâncias de contêiner a chance de adquirir tarefas recém-lançadas antes que essas instâncias sejam encerradas. Esse comportamento pode ser personalizado com o parâmetro de configuração do provedor de capacidade de instâncias gerenciadas `scaleInAfter` do Amazon ECS. Encerramento da atualização da infraestrutura As instâncias gerenciadas do Amazon ECS gerenciam e atualizam automaticamente o software em instâncias de contêineres gerenciadas para garantir a segurança e a conformidade, mantendo a disponibilidade das workloads. Para obter mais informações, consulte [Aplicação de patches em instâncias gerenciadas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html). ### Drenagem e migração de workload sem problemas O perfeito sistema de drenagem implementa uma coordenação sofisticada com o gerenciamento de serviços do Amazon ECS para garantir que as tarefas gerenciadas por serviço sejam migradas adequadamente das instâncias programadas para encerramento. **Coordenação de drenagem de tarefas de serviço** Quando uma instância passa para o estado DRAINING, o programador do Amazon ECS interrompe automaticamente o posicionamento de novas tarefas na instância enquanto implementa procedimentos de desligamento adequados para as tarefas de serviço existentes. A drenagem das tarefas de serviço inclui a coordenação com as estratégias de implantação do serviço, os requisitos de verificação de integridade e as preferências de drenagem para garantir o tempo ideal de migração e as taxas de sucesso. **Manipulação de tarefas autônomas** As tarefas autônomas exigem um tratamento diferente porque não se beneficiam do gerenciamento automático de serviços. O sistema avalia as características das tarefas autônomas, incluindo estimativas de duração da tarefa, análise de probabilidade de conclusão e avaliação do impacto no cliente. A estratégia de conclusão normal permite que tarefas autônomas sejam concluídas naturalmente durante um período de carência prolongado, enquanto o encerramento forçado garante que a atualização da infraestrutura ocorra dentro de prazos aceitáveis quando as tarefas não são concluídas naturalmente. ### Estratégia de conclusão em duas fases O sistema de encerramento implementa uma abordagem de duas fases que equilibra a continuidade da workload com os requisitos de gerenciamento da infraestrutura. **Fase 1: período de conclusão sem dificuldades** Durante essa fase, o sistema implementa estratégias de drenagem normal que priorizam a continuidade da workload. As tarefas de serviço são drenadas sem dificuldades por meio dos processos normais de agendamento do Amazon ECS, as tarefas autônomas continuam em execução e podem ser concluídas naturalmente, e o sistema monitora se todas as tarefas atingem o estado parado por meio de processos de conclusão natural. **Fase 2: cumprimento de prazos rigorosos** Quando a conclusão normal não atinge os objetivos de encerramento dentro de prazos aceitáveis, o sistema implementa a aplicação de prazos rigorosos. O prazo rigoroso normalmente é definido como o tempo de início da drenagem mais sete dias, proporcionando um tempo substancial para uma conclusão perfeita e ainda mantendo os requisitos operacionais. A imposição inclui a invocação automática de procedimentos forçados de cancelamento de registro e o encerramento imediato de todas as tarefas restantes, independentemente do status de conclusão. # Criar recursos para ajuste de escala automático de cluster do Amazon ECS usando o Console de gerenciamento da AWS Saiba como criar os recursos para o ajuste de escala automático de cluster usando o Console de gerenciamento da AWS. Quando os recursos requerem um nome, usamos o prefixo `ConsoleTutorial` para garantir que todos tenham nomes exclusivos e facilitar sua localização. **Topics** + [Pré-requisitos](#console-tutorial-prereqs) + [Etapa 1: criar um cluster do Amazon ECS](#console-tutorial-cluster) + [Etapa 2: registrar uma definição de tarefa](#console-tutorial-register-task-definition) + [Etapa 3: executar uma tarefa](#console-tutorial-run-task) + [Etapa 4: verificar](#console-tutorial-verify) + [Etapa 5: limpar](#console-tutorial-cleanup) ## 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. + O usuário do IAM tem as permissões necessárias especificadas no exemplo de política do IAM de [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess). + A função do IAM de instância de contêiner do Amazon ECS é criada. Para obter mais informações, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md). + A função do IAM vinculada ao serviço do Amazon ECS é criada. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). + A função do IAM vinculada ao serviço do Auto Scaling é criada. Para obter mais informações, consulte [Funções vinculadas ao serviço para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. + Você tem uma VPC e um grupo de segurança criados para uso. Para obter mais informações, consulte [Criar uma nuvem privada virtual](get-set-up-for-amazon-ecs.md#create-a-vpc). ## Etapa 1: criar um cluster do Amazon ECS Use as etapas a seguir para criar um cluster do Amazon ECS. O Amazon ECS cria um modelo de execução do Amazon EC2 Auto Scaling e um grupo do Auto Scaling em seu nome como parte da pilha do CloudFormation. 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, selecione **Clusters** e, em seguida, **Criar cluster**. 1. Em **Configuração do cluster**, em **Nome do cluster**, insira `ConsoleTutorial-cluster`. 1. Em **Infraestrutura**, desmarque AWS Fargate (sem servidor) e selecione **Instâncias do Amazon EC2**. Em seguida, configure o grupo do Auto Scaling que atua como o provedor de capacidade. 1. Em **Grupo do Auto Scaling (ASG)**. Selecione **Criar novo ASG**, e forneça os detalhes a seguir sobre o grupo: + Em **Sistema/arquitetura operacional**, escolha **Amazon Linux 2**. + Em **Tipo de instância do EC2**, escolha **t3.nano**. + Em **Capacity** (Capacidade), insira o número mínimo e o número máximo de instâncias a serem iniciadas no grupo do Auto Scaling. 1. (Opcional) Para gerenciar as tags de cluster, expanda **Tags** e, em seguida, execute uma das seguintes operações: [Adicionar uma tag] Selecione **Add tag** (Adicionar tag) e faça o seguinte: + Em **Key (Chave)**, insira o nome da chave. + Em **Value (Valor)**, insira o valor da chave. [Remover uma tag] Escolha **Remover** à direita da chave e do valor da tag. 1. Escolha **Criar**. ## Etapa 2: registrar uma definição de tarefa Para executar uma tarefa no seu cluster, você deve registrar uma definição de tarefa. As definições de tarefa são listas de contêineres agrupados. O exemplo a seguir é uma definição de tarefa simples que usa uma imagem `amazonlinux` do Docker Hub e simplesmente hiberna. Para obter mais informações sobre os parâmetros de definição de tarefa disponíveis, consulte [Definições de tarefa do Amazon ECS](task_definitions.md). 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 **Editor JSON**, cole o conteúdo a seguir. ``` { "family": "ConsoleTutorial-taskdef", "containerDefinitions": [ { "name": "sleep", "image": "public.ecr.aws/amazonlinux/amazonlinux:latest", "memory": 20, "essential": true, "command": [ "sh", "-c", "sleep infinity" ] } ], "requiresCompatibilities": [ "EC2" ] } ``` 1. Escolha **Criar**. ## Etapa 3: executar uma tarefa Depois de registrar uma definição de tarefa para sua conta, você pode executar uma tarefa no cluster. Para este tutorial, execute cinco instâncias da definição de tarefa `ConsoleTutorial-taskdef` em seu cluster do `ConsoleTutorial-cluster`. 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 **ConsoleTutorial-cluster**. 1. Em **Tarefas**, escolha **Executar nova tarefa**. 1. Na seção **Ambiente**, em **Opções de computação**, escolha **Estratégia do provedor de capacidade**. 1. Em **Configuração de implantação**, para **Tipo de aplicação**, escolha **Tarefa**. 1. Escolha **ConsoleTutorial-taskdef** na lista suspensa **Família**. 1. Em **Tarefas desejadas**, insira 5. 1. Escolha **Criar**. ## Etapa 4: verificar Neste ponto do tutorial, você deve ter um cluster com cinco tarefas em execução e um grupo do Auto Scaling com um provedor de capacidade. O provedor de capacidade tem a escalabilidade gerenciada do Amazon ECS habilitada. Podemos verificar se tudo está funcionando corretamente visualizando as métricas do CloudWatch, as configurações do grupo do Auto Scaling e, finalmente, a contagem de tarefas de cluster do Amazon ECS. **Para visualizar as métricas do CloudWatch do cluster** 1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Na barra de navegação na parte superior da tela, selecione uma Região . 1. No painel de navegação, em **Métricas**, escolha **Todas as métricas**. 1. Na página **Todas as métricas**, na guia **Procurar**, escolha `AWS/ECS/ManagedScaling`. 1. Escolha **CapacityProviderName, ClusterName**. 1. Marque a caixa de seleção que corresponde ao `ConsoleTutorial-cluster` ** ClusterName**. 1. Na guia **Métricas em gráfico**, altere **Período** para **30 segundos** e **Estatística** para **Máximo**. O valor exibido no gráfico mostra o valor da capacidade do destino para o provedor de capacidade. Deve começar em `100`, que era o percentual de capacidade alvo que definimos. Você deve vê-lo aumentar até `200`, o que acionará um alarme para a política de escalabilidade de rastreamento de destino. O alarme irá acionar o grupo do Auto Scaling para expansão. Use as etapas a seguir para visualizar os detalhes do grupo do Auto Scaling e confirmar se a ação de aumento ocorreu. **Para verificar se o grupo do Auto Scaling foi aumentado** 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 na parte superior da tela, selecione uma Região . 1. No painel de navegação, em **Auto Scaling**, escolha **Auto Scaling Groups (Grupos de Auto Scaling)**. 1. Escolha o grupo do Auto Scaling `ConsoleTutorial-cluster` criado neste tutorial. Veja o valor em **Capacidade desejada** e veja as instâncias na guia **Gerenciamento de instâncias** para confirmar se o seu grupo sofreu aumento de escala na horizontal para duas instâncias. Use as etapas a seguir para visualizar o cluster do Amazon ECS e confirmar se as instâncias do Amazon EC2 foram registradas no cluster e suas tarefas, transferidas para um status de `RUNNING`. **Para verificar as instâncias no grupo do Auto Scaling** 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 `ConsoleTutorial-cluster`. 1. Na guia **Tarefas**, confirme que você vê cinco tarefas no status `RUNNING`. ## Etapa 5: limpar Ao concluir este tutorial, limpe os recursos associados a ele para evitar cobranças por recursos que você não está usando. A exclusão de provedores de capacidade e de definições de tarefa não é compatível, mas não há custo associado a esses recursos. **Para limpar os recursos do tutorial** 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 **ConsoleTutorial-cluster**. 1. Na página **ConsoleTutorial-cluster**, escolha a guia **Tarefas** e, em seguida, escolha **Interromper**, **Interromper tudo**. 1. No painel de navegação, escolha **Clusters**. 1. Na página **Clusters**, escolha **ConsoleTutorial-cluster**. 1. Na parte superior direita da página, escolha **Excluir cluster**. 1. Na caixa de confirmação, insira **excluir **ConsoleTutorial-cluster**** e escolha **Excluir**. 1. Exclua os grupos do Auto Scaling usando as etapas a seguir. 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 na parte superior da tela, selecione uma Região . 1. No painel de navegação, em **Auto Scaling**, escolha **Auto Scaling Groups (Grupos de Auto Scaling)**. 1. Selecione o grupo do Auto Scaling `ConsoleTutorial-cluster` e escolha ** Ações**. 1. No menu **Actions (Ações)**, escolha **Delete (Excluir)**. Insira ** excluir** na caixa de confirmação e, em seguida, escolha **Excluir**. # Instâncias de contêiner do Amazon EC2 para o Amazon ECS Uma instância de contêiner do Amazon ECS corresponde a uma instância do Amazon EC2 que executa o agente de contêiner do Amazon ECS e está registrada em um cluster. Quando você executa tarefas usando o provedor de capacidade do Amazon ECS, um provedor de capacidade externo ou um do grupo do Auto Scaling, suas tarefas são colocadas nas instâncias de contêiner ativas. Você é responsável pelo gerenciamento e manutenção da instância de contêiner. Embora você possa criar sua própria AMI de instância do Amazon EC2 que atenda às especificações básicas necessárias para executar workloads em contêineres no Amazon ECS, as AMIs otimizadas para Amazon ECS são pré-configuradas e testadas no Amazon ECS por engenheiros da AWS. É a maneira mais simples de você começar e fazer com que seus contêineres sejam executados na AWS rapidamente. Ao criar um cluster usando o console, o Amazon ECS cria um modelo de inicialização para as instâncias com a AMI mais recente associada ao sistema operacional selecionado. Quando você usa o CloudFormation para criar um cluster, o parâmetro SSM faz parte do modelo de inicialização do Amazon EC2 para instâncias do grupo do Auto Scaling. Você pode configurar o modelo para usar um parâmetro dinâmico do Systems Manager para determinar qual AMI otimizada do Amazon ECS deve ser implantada. Esse parâmetro garante que toda vez que você implantar a pilha, ele verificará se há uma atualização disponível que precise ser aplicada às instâncias do EC2. Para obter um exemplo de como usar o parâmetro do Systems Manager, consulte [Criar um cluster Amazon ECS com a AMI do Amazon Linux 2023 otimizada para o Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) no *Guia do usuário do AWS CloudFormation*. + [Recuperação de metadados da AMI do Linux otimizada para o Amazon ECS](retrieve-ecs-optimized_AMI.md) + [Recuperação dos metadados da AMI do Bottlerocket otimizada para o Amazon ECS](ecs-bottlerocket-retrieve-ami.md) + [Recuperação de metadados da AMI do Windows otimizada para o Amazon ECS](retrieve-ecs-optimized_windows_AMI.md) É possível escolher entre os tipos de instância que são compatíveis com sua aplicação. Com instâncias maiores, é possível iniciar mais tarefas ao mesmo tempo. Com instâncias menores, é possível aumentar a escala horizontalmente de maneira mais otimizada para economizar custos. Não é preciso escolher um único tipo de instância do Amazon EC2 que se adapte a todas as aplicações em seu cluster. Em vez disso, você pode criar diversos grupos do Auto Scaling de forma que cada grupo tenha um tipo de instância diferente. Em seguida, é possível criar um provedor de capacidade do Amazon EC2 para cada um desses grupos. Use as seguintes diretrizes para determinar os tipos de família de instâncias e o tipo de instância a ser usado: + Elimine os tipos ou as famílias de instâncias que não atendem aos requisitos específicos da aplicação. Por exemplo, se a sua aplicação exigir uma GPU, será possível excluir qualquer tipo de instância que não tenha uma GPU. + Considere os requisitos, incluindo o throughput e o armazenamento da rede. + Considere a CPU e a memória. Como regra geral, a CPU e a memória devem ser grandes o suficiente para armazenar pelo menos uma réplica da tarefa que você deseja executar. ## Instâncias spot A capacidade spot pode proporcionar economias de custo significativas em relação às instâncias sob demanda. A capacidade spot é o excesso de capacidade cujo preço é significativamente menor do que a capacidade sob demanda ou a capacidade reservada. A capacidade spot é adequada para workloads de processamento em lote e machine learning, além de ambientes de desenvolvimento e preparação. Em geral, é adequada para qualquer workload que tolere tempo de inatividade temporário. Entenda as consequências a seguir, pois a capacidade spot pode não estar disponível o tempo todo. + Durante períodos de demanda extremamente alta, a capacidade spot pode estar indisponível. Isso pode atrasar a execução de instâncias spot do Amazon EC2. Nesses casos, os serviços do Amazon ECS tentam executar tarefas novamente, e os grupos do Amazon EC2 Auto Scaling também tentam iniciar instâncias novamente, até que a capacidade necessária esteja disponível. O Amazon EC2 não substitui a capacidade spot por capacidade sob demanda. + Quando a demanda geral por capacidade aumenta, as instâncias spot e as tarefas podem ser encerradas com apenas um aviso de dois minutos. Depois que o aviso for enviado, as tarefas devem iniciar um desligamento ordenado, se necessário, antes que a instância seja totalmente encerrada. Isso ajuda a minimizar a possibilidade de erros. Para obter mais informações sobre um desligamento normal, consulte [Desligamentos normais com o ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/). Para ajudar a minimizar a escassez de capacidade Spot, considere as recomendações a seguir: + Use várias regiões e zonas de disponibilidade: a capacidade spot varia de acordo com a região e a zona de disponibilidade. É possível melhorar a disponibilidade de spot executando suas workloads em várias regiões e zonas de disponibilidade. Se possível, especifique sub-redes em todas as zonas de disponibilidade nas regiões em que você executar suas tarefas e instâncias. + Use vários tipos de instâncias do Amazon EC2: quando você usa políticas de instâncias mistas com o Amazon EC2 Auto Scaling, vários tipos de instâncias são iniciadas em seu grupo do Auto Scaling. Isso garante que uma solicitação por capacidade spot possa ser atendida quando necessário. Para maximizar a confiabilidade e minimizar a complexidade, use tipos de instâncias com aproximadamente a mesma quantidade de CPU e memória em sua Política de instâncias mistas. Essas instâncias podem ser de uma geração diferente ou de variantes do mesmo tipo de instância base. Observe que elas podem vir com recursos adicionais que você talvez não precise. Um exemplo dessa lista poderia incluir m4.large, m5.large, m5a.large, m5d.large, m5n.large, m5dn.large e m5ad.large. Para obter mais informações, consulte [Grupos de Auto Scaling com vários tipos de instância e opções de compra](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) no *Manual do usuário do Amazon EC2 Auto Scaling*. + Use a estratégia de alocação spot otimizada para capacidade: com o Amazon EC2 Spot, é possível escolher entre as estratégias de alocação otimizadas para capacidade e custo. Se você escolher a estratégia de capacidade otimizada ao iniciar uma nova instância, o Amazon EC2 Spot selecionará o tipo de instância com maior disponibilidade na zona de disponibilidade selecionada. Isso ajudará a reduzir a possibilidade de a instância ser encerrada logo após sua inicialização. Para obter informações sobre como configurar avisos de encerramento de spot em suas instâncias de contêiner, consulte: + [Configuração de instâncias de contêiner do Linux no Amazon ECS para receber avisos de instância spot](spot-instance-draining-linux-container.md) + [Configuração de instâncias de contêiner do Windows no Amazon ECS para receber avisos de instância spot](windows-spot-instance-draining-container.md) # AMIs do Linux otimizadas para o Amazon ECS **Importante** A AMI do Amazon Linux 2 otimizada para Amazon ECS chega ao fim de sua vida útil em 30 de junho de 2026, espelhando a mesma data de EOL do sistema operacional upstream Amazon Linux 2 (para obter mais informações, consulte as perguntas frequentes sobre o [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/faqs/)). Incentivamos os clientes a atualizar suas aplicações para usar o Amazon Linux 2023, que inclui suporte de longo prazo até 2028. Para obter informações sobre a migração do Amazon Linux 2 para o Amazon Linux 2023, consulte [Migrating from the Amazon Linux 2 Amazon ECS-optimized AMI to the Amazon Linux 2023 Amazon ECS-optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html). Por padrão, a data de descontinuação de todas as AMIs otimizadas para o Amazon ECS é definida para dois anos após a data de criação da AMI. Você pode usar a API `DescribeImages` do Amazon EC2 para verificar o status de suspensão de uso e a data de uma AMI. Para obter mais informações, consulte [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html) na *Amazon Elastic Compute Cloud API Reference*. O Amazon ECS fornece as AMIs otimizadas para Amazon ECS que são pré-configuradas com os requisitos e as recomendações para executar as workloads de contêiner. Recomendamos que você use a AMI do Amazon Linux 2023 otimizada para Amazon ECS para suas instâncias do Amazon EC2. A execução das suas instâncias de contêiner na AMI mais recente otimizada para Amazon ECS garante que você receba a versão atual das atualizações de segurança e do agente de contêiner. Para obter mais informações sobre como iniciar uma instância, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). Ao criar um cluster usando o console, o Amazon ECS cria um modelo de inicialização para as instâncias com a AMI mais recente associada ao sistema operacional selecionado. Quando você usa o CloudFormation para criar um cluster, o parâmetro SSM faz parte do modelo de inicialização do Amazon EC2 para instâncias do grupo do Auto Scaling. Você pode configurar o modelo para usar um parâmetro dinâmico do Systems Manager para determinar qual AMI otimizada do Amazon ECS deve ser implantada. Esse parâmetro garante que toda vez que você implantar a pilha, ele verificará se há uma atualização disponível que precise ser aplicada às instâncias do EC2. Para obter um exemplo de como usar o parâmetro do Systems Manager, consulte [Criar um cluster Amazon ECS com a AMI do Amazon Linux 2023 otimizada para o Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) no *Guia do usuário do AWS CloudFormation*. Se você precisar personalizar a AMI otimizada para o Amazon ECS, consulte [Amazon ECS Optimized AMI Build Recipes](https://github.com/aws/amazon-ecs-ami) no GitHub. As seguintes variantes da AMI otimizada para o Amazon ECS estão disponíveis para instâncias do Amazon EC2 com o sistema operacional do Amazon Linux 2023. | Sistema operacional | AMI | Descrição | Configuração do armazenamento | | --- | --- | --- | --- | | Amazon Linux 2023 | AMI do Amazon Linux 2023 otimizada para Amazon ECS | O Amazon Linux 2023 é a próxima geração do Amazon Linux da AWS. Para a maioria dos casos, é recomendado para iniciar suas instâncias do Amazon EC2 para workloads do Amazon ECS. Para obter mais informações, consulte [O que é o Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) no *Guia do Usuário do Amazon Linux 2023*. | Por padrão, a AMI do Amazon Linux 2023 otimizada para Amazon ECS é fornecida com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2023 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | Amazon Linux 2023 (arm64) | AMI do Amazon Linux 2023 (arm64) otimizada para Amazon ECS | Com base no Amazon Linux 2023, recomenda-se usar esta AMI ao inicializar suas instâncias do Amazon EC2 para processadores AWS Graviton/Graviton 2/Graviton 3/Graviton 4 baseados em Arm, para suas workloads do Amazon ECS. Para obter mais informações, consulte [Especificações para instâncias de uso geral do Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) no *Guia de tipos de instâncias do Amazon EC2*. | Por padrão, a AMI do Amazon Linux 2023 otimizada para Amazon ECS é fornecida com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2023 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | Amazon Linux 2023 (Neuron) | AMI do Amazon Linux 2023 otimizada para Amazon ECS | Baseada no Amazon Linux 2023, esta AMI destina-se a instâncias Inf1, Trn1 ou Inf2 do Amazon EC2. Ela vem pré-configurada com drivers do AWS Inferentia e do AWS Trainium, e o runtime do AWS Neuron para Docker, o que facilita a execução de workloads de inferência de machine learning no Amazon ECS. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads de machine learning do AWS Neuron](ecs-inference.md). A AMI do Amazon Linux 2023 (Neuron) otimizada para o Amazon ECS não é fornecida com a AWS CLI instalada previamente. | Por padrão, a AMI do Amazon Linux 2023 otimizada para Amazon ECS é fornecida com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2023 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | GPU Amazon Linux 2023 | AMI de GPU Amazon Linux 2023 otimizada para Amazon ECS | Com base no Amazon Linux 2023, recomenda-se usar esta AMI na inicialização de instâncias baseadas em GPU do Amazon EC2 para suas workloads do Amazon ECS. Ela vem pré-configurada com drivers de kernel NVIDIA e um runtime da GPU do Docker, que facilitam a execução de workloads que aproveitam as GPUs no Amazon ECS. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md). | Por padrão, a AMI do Amazon Linux 2023 otimizada para Amazon ECS é fornecida com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2023 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | As seguintes variantes da AMI otimizada para o Amazon ECS estão disponíveis para instâncias do Amazon EC2 com o sistema operacional do Amazon Linux 2. | Sistema operacional | AMI | Descrição | Configuração do armazenamento | | --- | --- | --- | --- | | **Amazon Linux 2** | AMI do Amazon Linux 2 kernel 5.10 otimizada para Amazon ECS | Com base no Amazon Linux 2, esta AMI é para ser usada ao inicializar suas instâncias do Amazon EC2 e quando você quiser usar o kernel do Linux 5.10 em vez do kernel 4.14 para suas workloads do Amazon ECS. A AMI do Amazon Linux 2 kernel 5.10 otimizada para Amazon ECS não vem com a AWS CLI pré-instalada. | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | **Amazon Linux 2** | AMI do Amazon Linux 2 otimizada para Amazon ECS | Isso é para suas workloads do Amazon ECS. A AMI do Amazon Linux 2 otimizada para Amazon ECS não vem com a AWS CLI pré-instalada. | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | **Amazon Linux 2 (arm64)** | AMI do Amazon Linux 2 kernel 5.10 (arm64) otimizada para Amazon ECS | Com base no Amazon Linux 2, esta AMI é para suas instâncias do Amazon EC2 para processadores AWS Graviton/Graviton 2/Graviton 3/Graviton 4 baseados em Arm, e quando você quiser usar o kernel 5.10 em vez do kernel 4.14 do Linux para suas workloads do Amazon ECS. Para obter mais informações, consulte [Especificações para instâncias de uso geral do Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) no *Guia de tipos de instâncias do Amazon EC2*. A AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS não vem com a AWS CLI pré-instalada. | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | Amazon Linux 2 (arm64) | AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS | Com base no Amazon Linux 2, essa AMI deve ser usada ao inicializar suas instâncias do Amazon EC2 para processadores AWS Graviton/Graviton 2/Graviton 3/Graviton 4 baseados em Arm, para suas workloads do Amazon ECS. A AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS não vem com a AWS CLI pré-instalada. | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | **Amazon Linux 2 (GPU)** | AMI do kernel 5.10 otimizada para GPU do Amazon ECS | Com base no Amazon Linux 2, recomenda-se usar essa AMI na execução de instâncias baseadas em GPU do Amazon EC2 com o kernel 5.10 do Linux nas workloads do Amazon ECS. Ela vem pré-configurada com drivers de kernel NVIDIA e um runtime da GPU do Docker, que facilitam a execução de workloads que aproveitam as GPUs no Amazon ECS. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md). | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | Amazon Linux 2 (GPU) | AMI otimizada para GPU do Amazon ECS | Com base no Amazon Linux 2, recomenda-se usar essa AMI na execução de instâncias baseadas em GPU do Amazon EC2 com o kernel 4.14 do Linux nas workloads do Amazon ECS. Ela vem pré-configurada com drivers de kernel NVIDIA e um runtime da GPU do Docker, que facilitam a execução de workloads que aproveitam as GPUs no Amazon ECS. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads de GPU](ecs-gpu.md). | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | Amazon Linux 2 (Neuron) | AMI do kernel 5.10 do Amazon Linux 2 (Neuron) otimizada para o Amazon ECS | Com base no Amazon Linux 2, essa AMI é para instâncias Inf1, Trn1 ou Inf2 do Amazon EC2. Ela vem pré-configurada com drivers do AWS Inferentia com kernel do Linux 5.10 e AWS Trainium e o runtime do AWS Neuron para Docker, que facilita a execução de workloads de inferência de machine learning no Amazon ECS. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads de machine learning do AWS Neuron](ecs-inference.md). A AMI do Amazon Linux 2 (Neuron) otimizada para Amazon ECS não é fornecida com a AWS CLI pré-instalada. | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | | Amazon Linux 2 (Neuron) | AMI do Amazon Linux 2 (Neuron) otimizada para Amazon ECS | Com base no Amazon Linux 2, essa AMI é para instâncias Inf1, Trn1 ou Inf2 do Amazon EC2. Ela vem pré-configurada com drivers do AWS Inferentia e do AWS Trainium, e o runtime do AWS Neuron para Docker, o que facilita a execução de workloads de inferência de machine learning no Amazon ECS. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads de machine learning do AWS Neuron](ecs-inference.md). A AMI do Amazon Linux 2 (Neuron) otimizada para Amazon ECS não é fornecida com a AWS CLI pré-instalada. | Por padrão, as AMIs otimizadas para Amazon ECS baseadas no Amazon Linux 2 (AMI do Amazon Linux 2 otimizado para Amazon ECS, AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS e AMI otimizada para GPU do Amazon ECS) são enviadas com um único volume raiz de 30 GiB. É possível modificar o tamanho de 30 GiB do volume raiz no momento da inicialização para aumentar o armazenamento disponível em sua instância de contêiner. Esse storage é usado para o sistema operacional e imagens e metadados de Docker. O sistema de arquivos padrão para a AMI do Amazon Linux 2 otimizada para Amazon ECS é `xfs` e o Docker usa o driver de armazenamento `overlay2`. Para obter mais informações, consulte [Usar o driver de armazenamento OverlayFS](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) na documentação do Docker. | O Amazon ECS fornece um log de alterações para a variante do Linux da AMI otimizada para Amazon ECS no GitHub. Para obter mais informações, consulte [Log de alterações](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md). As variantes do Linux da AMI otimizada para Amazon ECS usam a AMI do Amazon Linux 2 ou a AMI do Amazon Linux 2023 como base. O nome da AMI para cada variante pode ser recuperado consultando a API do Systems Manager Parameter Store. Para obter mais informações, consulte [Recuperação de metadados da AMI do Linux otimizada para o Amazon ECS](retrieve-ecs-optimized_AMI.md). As notas de versão do Amazon Linux 2 AMI também estão disponíveis. Para obter mais informações, consulte [Notas de lançamento do Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html). As notas de versão do Amazon Linux 2023 também estão disponíveis. Para obter mais informações, consulte [Notas de lançamento do Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html). As páginas a seguir fornecem informações adicionais sobre as alterações: + [Notas de lançamento da AMI de origem](https://github.com/aws/amazon-ecs-ami/releases) no GitHub + [Notas de lançamento do Docker Engine](https://docs.docker.com/engine/release-notes/) na documentação do Docker + [Documentação do driver NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) na documentação da NVIDIA + [Amazon ECS agent changelog](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) no GitHub O código-fonte da aplicação `ecs-init`, os scripts e a configuração para empacotar o agente agora fazem parte do repositório do agente. Para versões mais antigas de `ecs-init` e pacotes, consulte [Log de alterações do Amazon ecs-init](https://github.com/aws/amazon-ecs-init/blob/master/CHANGELOG.md) no GitHub ## Aplicação de atualizações de segurança à AMI otimizada para o Amazon ECS As AMIs otimizadas para o Amazon ECS baseadas no Amazon Linux contêm uma versão personalizada do cloud-init. O Cloud-init é um pacote usado para inicializar imagens do Linux em um ambiente de computação em nuvem e realizar ações desejadas ao executar uma instância. Por padrão, todas as AMIs otimizadas para o Amazon ECS baseadas no Amazon Linux lançadas antes de 12 de junho de 2024 têm todas as atualizações de segurança "críticas" e "importantes" aplicadas quando a instância é inicializada. A partir da versão de 12 de junho, nos lançamentos de 2024 das AMIs otimizadas para o Amazon ECS baseadas no Amazon Linux 2, o comportamento padrão não inclui mais a atualização de pacotes na inicialização. Em vez disso, recomendamos atualizar para uma nova AMI otimizada para o Amazon ECS à medida que as versões forem disponibilizadas. As AMIs otimizadas para o Amazon ECS são lançadas quando há atualizações de segurança disponíveis ou alterações de base da AMI. Isso garante que você receba as versões mais recentes do pacote e as atualizações de segurança, e que as versões do pacote sejam imutáveis por meio de execuções de instâncias. Para obter mais informações sobre como recuperar a AMI otimizada para o Amazon ECS mais recente, consulte [Recuperação de metadados da AMI do Linux otimizada para o Amazon ECS](retrieve-ecs-optimized_AMI.md). Recomendamos automatizar seu ambiente para atualizar para novas AMIs à medida que forem disponibilizadas. Para obter informações sobre as opções disponíveis, consulte [Amazon ECS enables easier EC2 capacity management, with managed instance draining](https://aws.amazon.com/blogs/containers/amazon-ecs-enables-easier-ec2-capacity-management-with-managed-instance-draining/). Para continuar aplicando manualmente as atualizações de segurança "críticas" e "importantes" em uma versão da AMI, você pode executar o comando a seguir na sua instância do Amazon EC2. ``` yum update --security ``` **Atenção** A atualização de pacotes docker ou containerd interromperá todos os contêineres em execução no host, o que significa que todas as tarefas em execução do Amazon ECS serão interrompidas. Planeje adequadamente para minimizar a interrupção do serviço. Se quiser habilitar novamente as atualizações de segurança na execução, você pode adicionar a linha a seguir à seção `#cloud-config` de dados do usuário do cloud-init ao executar a instância do Amazon EC2. Para obter mais informações, consulte [Using cloud-init on Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html) no *Guia do usuário do Amazon Linux*. ``` #cloud-config repo_upgrade: security ``` ## Pacotes com versão bloqueada em AMIs de GPU do AL2023 otimizadas para Amazon ECS Alguns pacotes são essenciais para o comportamento correto e eficiente da funcionalidade da GPU nas AMIs de GPU AL2023 otimizadas para o Amazon ECS. Isso inclui: + Drivers NVIDIA (`nvidia*`) + Módulos de kernel (`kmod*`) + Bibliotecas NVIDIA (`libnvidia*`) + Pacotes de kernel (`kernel*`) **nota** Esta não é uma lista completa. A lista completa de pacotes bloqueados está disponível na `dnf versionlock list` Esses pacotes são bloqueados por versão para garantir estabilidade e evitar alterações não intencionais que possam interromper as workloads da GPU. Como resultado, esses pacotes geralmente devem ser modificados dentro dos limites de um processo gerenciado que lida com facilidade com possíveis problemas e mantém a funcionalidade da GPU. Para evitar modificações não intencionais, o plug-in `dnf versionlock` é usado nesses pacotes. Se você quiser modificar um pacote bloqueado, você pode: ``` # unlock a single package sudo dnf versionlock delete $PACKAGE_NAME # unlock all packages sudo dnf versionlock clear ``` **Importante** Quando forem necessárias atualizações desses pacotes, os clientes devem considerar o uso da versão mais recente da AMI que inclua as atualizações necessárias. Se for necessário atualizar as instâncias existentes, uma abordagem cuidadosa envolvendo desbloqueio, atualização e rebloqueio de pacotes deve ser empregada, sempre garantindo que a funcionalidade da GPU seja mantida durante todo o processo. # Recuperação de metadados da AMI do Linux otimizada para o Amazon ECS Você pode recuperar programaticamente os metadados da AMI otimizada para o Amazon ECS. Os metadados incluem o nome da AMI, a versão do agente de contêiner do Amazon ECS e a versão de runtime do Amazon ECS, que inclui a versão do Docker. Ao criar um cluster usando o console, o Amazon ECS cria um modelo de inicialização para as instâncias com a AMI mais recente associada ao sistema operacional selecionado. Quando você usa o CloudFormation para criar um cluster, o parâmetro SSM faz parte do modelo de inicialização do Amazon EC2 para instâncias do grupo do Auto Scaling. Você pode configurar o modelo para usar um parâmetro dinâmico do Systems Manager para determinar qual AMI otimizada do Amazon ECS deve ser implantada. Esse parâmetro garante que toda vez que você implantar a pilha, ele verificará se há uma atualização disponível que precise ser aplicada às instâncias do EC2. Para obter um exemplo de como usar o parâmetro do Systems Manager, consulte [Criar um cluster Amazon ECS com a AMI do Amazon Linux 2023 otimizada para o Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) no *Guia do usuário do AWS CloudFormation*. O ID da AMI, o nome da imagem, o sistema operacional, a versão do agente de contêiner, o nome da imagem da fonte e a versão do runtime para cada variante das AMIs otimizadas para Amazon ECS podem ser recuperados de maneira programática, consultando a API da Systems Manager Parameter Store. Para obter mais informações sobre a API do Systems Manager Parameter Store, consulte [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) e [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html). **nota** O usuário administrador precisa ter as seguintes permissões do IAM para recuperar os metadados da AMI otimizada para Amazon ECS. Essas permissões foram adicionadas à política `AmazonECS_FullAccess` do IAM. ssm:GetParameters ssm:GetParameter ssm:GetParametersByPath ## Formato de parâmetro do Systems Manager Parameter Store Veja a seguir o formato do nome do parâmetro para cada variante da AMI otimizada para Amazon ECS. **AMIs do Linux otimizadas para Amazon ECS** + Metadados da AMI do Amazon Linux 2023: ``` /aws/service/ecs/optimized-ami/amazon-linux-2023/ ``` + Metadados da AMI do Amazon Linux 2023 (arm64): ``` /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/ ``` + Metadados da AMI do Amazon Linux 2023 (Neuron): ``` /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/ ``` + Metadados da AMI do Amazon Linux 2023 (GPU): ``` /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/ ``` Metadados da AMI do Amazon Linux 2: ``` /aws/service/ecs/optimized-ami/amazon-linux-2/ ``` + Metadados da AMI do Amazon Linux 2 kernel 5.10: ``` /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ ``` + Metadados da AMI do Amazon Linux 2 (arm64): ``` /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/ ``` + Metadados da AMI do Amazon Linux 2 kernel 5.10 (arm64): ``` /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/ ``` + Metadados da AMI do kernel 5.10 otimizada para GPU do Amazon ECS: ``` /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/ ``` + Metadados da AMI do Amazon Linux 2 (GPU): ``` /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/ ``` + Metadados de AMI do kernel 5.10 do Amazon Linux 2 (Neuron) otimizada para o Amazon ECS: ``` /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/ ``` + Metadados da AMI do Amazon Linux 2 (Neuron): ``` /aws/service/ecs/optimized-ami/amazon-linux-2/inf/ ``` O formato de nome de parâmetro a seguir recupera o ID de imagem da versão recomendada mais recente da AMI do Amazon Linux 2 otimizada para Amazon ECS usando o subparâmetro `image_id`. ``` /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id ``` O seguinte formato de nome de parâmetro recupera os metadados de uma versão específica da AMI otimizada para Amazon ECS especificando o nome da AMI. + Metadados da AMI do Amazon Linux 2 otimizada para Amazon ECS: ``` /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20181112-x86_64-ebs ``` **nota** Todas as versões da AMI do Amazon Linux 2 otimizada para Amazon ECS estão disponíveis para recuperação. Somente versões `amzn-ami-2017.09.l-amazon-ecs-optimized` e posteriores da AMI otimizada para Amazon ECS (Linux) podem ser recuperadas. ## Exemplos Os exemplos a seguir mostram maneiras como você pode recuperar os metadados de cada variante da AMI otimizada para Amazon ECS. ### Recuperar os metadados da AMI otimizada para Amazon ECS recomendada mais recente É possível recuperar a AMI otimizada para Amazon ECS recomendada mais recente por meio da AWS CLI, usando os comandos da AWS CLI a seguir. **AMIs do Linux otimizadas para Amazon ECS** + **Para as AMIs do Amazon Linux 2023 otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended --region us-east-1 ``` + **Para as AMIs do Amazon Linux 2023 (arm64) otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/recommended --region us-east-1 ``` + **Para as AMIs do Amazon Linux 2023 (Neuron) otimizadas para o Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended --region us-east-1 ``` + **Para as AMIs de GPU Amazon Linux 2023 otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/recommended --region us-east-1 ``` + **Para as AMIs do Amazon Linux 2 kernel 5.10 otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended --region us-east-1 ``` + **Para as AMIs do Amazon Linux 2 otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region us-east-1 ``` + **Para as AMIs do Amazon Linux 2 kernel 5.10 (arm64) otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended --region us-east-1 ``` + **Para as AMIs do Amazon Linux 2 (arm64) otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/recommended --region us-east-1 ``` + **Para as AMIs do kernel 5.10 otimizadas para GPU do Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended --region us-east-1 ``` + **Para as AMIs otimizadas para GPU do Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1 ``` + **Para as AMIs do kernel 5.10 do Amazon Linux 2 (Neuron) otimizadas para o Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended --region us-east-1 ``` + **Para as AMIs do Amazon Linux 2 (Neuron) otimizadas para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/inf/recommended --region us-east-1 ``` ### Recuperar o ID de imagem da AMI do Amazon Linux 2023 otimizada para Amazon ECS mais recente e recomendada É possível recuperar o ID de imagem da AMI do Amazon Linux 2023 otimizada para Amazon ECS mais recente e recomendada usando o subparâmetro `image_id`. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 ``` Para recuperar o valor `image_id` somente, você pode consultar o valor de parâmetro específico; por exemplo: ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 --query "Parameters[0].Value" ``` ### Recuperar os metadados de uma versão específica da AMI do Amazon Linux 2 otimizada para Amazon ECS Recupere os metadados de uma versão específica da AMI do Amazon Linux otimizada para Amazon ECS por meio da AWS CLI, usando o seguinte comando da AWS CLI. Substitua o nome da AMI pelo nome da AMI do Amazon Linux otimizada para Amazon ECS a ser recuperado. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20200928-x86_64-ebs --region us-east-1 ``` ### Recuperação de metadados da AMI do kernel 5.10 do Amazon Linux 2 otimizada para o Amazon ECS usando a API GetParametersByPath do Systems Manager Recupere os metadados da AMI do Amazon Linux 2 otimizada para Amazon ECS com a API GetParametersByPath do Systems Manager, usando a AWS CLI com o seguinte comando. ``` aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ --region us-east-1 ``` ### Recuperar o ID de imagem da AMI do Amazon Linux 2 com kernel 5.10 otimizada para o Amazon ECS mais recente e recomendada É possível recuperar o ID de imagem do ID de AMI do kernel 5.10 do Amazon Linux 2 otimizado para o Amazon ECS recomendado mais recente usando o subparâmetro `image_id`. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id --region us-east-1 ``` Para recuperar o valor `image_id` somente, você pode consultar o valor de parâmetro específico; por exemplo: ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region us-east-1 --query "Parameters[0].Value" ``` ### Usar a mais recente e recomendada AMI otimizada para Amazon ECS em um modelo do CloudFormation É possível referenciar a mais recente e recomendada AMI otimizada para Amazon ECS em um modelo do CloudFormation fazendo referência ao nome do armazenamento de parâmetros do Systems Manager. **Exemplo do Linux** ``` Parameters:kernel-5.10 LatestECSOptimizedAMI: Description: AMI ID Type: AWS::SSM::Parameter::Value Default: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id ``` # Migrar de um Amazon Linux 2 para uma AMI do Amazon Linux 2023 otimizada para Amazon ECS Após o [Amazon Linux](https://aws.amazon.com/amazon-linux-2/faqs), o Amazon ECS encerrará o suporte padrão para AMIs do Amazon Linux 2 otimizadas para Amazon ECS a partir de 30 de junho de 2026. Após essa data, a versão do agente do Amazon ECS será fixada e as novas AMIs do Amazon Linux 2 otimizadas para Amazon ECS só serão publicadas quando a AMI de origem do Amazon Linux 2 for atualizada. O fim da vida útil (EOL) ocorrerá em 30 de junho de 2026, após o qual nenhuma outra AMI do Amazon Linux 2 otimizada para Amazon ECS será publicada, mesmo que a AMI de origem seja atualizada. O Amazon Linux 2023 fornece uma abordagem segura por padrão com políticas de segurança pré-configuradas, SELinux no modo permissivo, modo somente IMDSv2 habilitado por padrão, tempos de inicialização otimizados e gerenciamento aprimorado de pacotes para maior segurança e performance. Há um alto grau de compatibilidade entre as AMIs do Amazon Linux 2 e do Amazon Linux 2023 otimizadas para Amazon ECS, e a maioria dos clientes verá mudanças mínimas, ou nenhuma, em suas workloads entre os dois sistemas operacionais. Para obter mais informações, consulte [Comparing Amazon Linux 2 and *Amazon Linux 2023*](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html), no *Guia do usuário do Amazon Linux 2023*, e as [Perguntas frequentes sobre o Amazon Linux 2023](https://aws.amazon.com/linux/amazon-linux-2023/faqs). ## Considerações sobre compatibilidade ### Gerenciamento de pacotes e atualizações do sistema operacional Diferentemente das versões anteriores do Amazon Linux, as AMIs do Amazon Linux 2023 otimizadas para o Amazon ECS estão bloqueadas em uma versão específica do repositório do Amazon Linux. Isso evita que os usuários atualizem inadvertidamente pacotes que possam trazer alterações indesejadas ou significativas. Para obter mais informações, consulte [Managing repositories and OS updates in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) no *Guia do usuário do Amazon Linux 2023*. ### versão de kernel do Linux As AMIs do Amazon Linux 2 são baseadas nos kernels Linux 4.14 e 5.10, enquanto o Amazon Linux 2023 usa os kernels Linux 6.1 e 6.12. Para obter mais informações, consulte [Comparing Amazon Linux 2 and Amazon Linux 2023 kernels](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html) no *Guia do usuário do Amazon Linux 2023*. ### Alterações na disponibilidade de pacotes Confira abaixo as alterações importantes de pacotes no Amazon Linux 2023: + Alguns pacotes binários de fontes no Amazon Linux 2 não estão mais disponíveis no Amazon Linux 2023. Para obter mais informações, consulte [Packages removed from Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/removed.html) nas *Notas da versão do Amazon Linux 2023*. + Mudanças na forma como o Amazon Linux é compatível com diferentes versões de pacotes. O sistema `amazon-linux-extras` usado no Amazon Linux 2 não existe no Amazon Linux 2023. Todos os pacotes estão simplesmente disponíveis no repositório “principal”. + Os pacotes extras para Enterprise Linux (EPEL) não são compatíveis no Amazon Linux 2023. Para obter mais informações, consulte [EPEL compatibility in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/epel.html) no *Guia do usuário do Amazon Linux 2023*. + As aplicações de 32 bits não são compatíveis no Amazon Linux 2023. Para obter mais informações, consulte [Deprecated features from Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms) no *Guia do usuário do Amazon Linux 2023*. ### Alterações nos grupos de controle (cgroups) Um grupo de controle (cgroup) é um recurso do kernel Linux para organizar hierarquicamente os processos e distribuir os recursos do sistema entre eles. Os grupos de controle são usados extensivamente para implementar um runtime de contêiner e por `systemd`. O agente do Amazon ECS, o Docker e o containerd são compatíveis tanto com o cgroupv1 quanto com o cgroupv2. O agente do Amazon ECS e o runtime do contêiner gerenciam os cgroups para você, portanto, os clientes do Amazon ECS não precisam fazer nenhuma alteração nessa atualização de cgroup subjacente. Para obter mais detalhes sobre o cgroupv2, consulte [Control groups v2 in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/cgroupv2.html) no *Guia do usuário do Amazon Linux 2023.* ### Alterações no serviço de metadados de instância (IMDS) O Amazon Linux 2023 requer o serviço de metadados de instância versão 2 (IMDSv2) por padrão. O IMDSv2 tem diversos benefícios que ajudam a aprimorar a postura de segurança. Ele usa um método de autenticação orientado por sessão que requer a criação de um token secreto em uma solicitação HTTP PUT simples para iniciar a sessão. O token de uma sessão pode ter validade de um segundo a seis horas. Para obter mais informações sobre como fazer a transição do IMDSv1 para o IMDSv2, consulte [Transição para usar o Serviço de metadados da instância versão 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) no *Guia do usuário do Amazon EC2*. Se desejar usar o IMDSv1, você ainda poderá fazê-lo ao substituir manualmente as configurações usando as propriedades de inicialização da opção de metadados da instância. ### Alterações na troca de memória A troca de memória por contêiner não é compatível com o Amazon Linux 2023 e os cgroups v2. Para obter mais informações, consulte [Gerenciar o espaço de memória de troca de contêiner no Amazon ECS](container-swap.md). ### Alterações na validação do FIPS O Amazon Linux 2 é certificado sob o FIPS 140-2, e o Amazon Linux 2023 é certificado sob o FIPS 140-3. Para habilitar o modo FIPS no Amazon Linux 2023, instale os pacotes necessários na sua instância do Amazon EC2 e siga as etapas de configuração usando as instruções em [Enable FIPS Mode on Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) no *Guia do usuário do Amazon Linux 2023*. ### Compatibilidade acelerada de instâncias As AMIs do Amazon Linux 2023 otimizadas para Amazon ECS são compatíveis com os tipos de instâncias aceleradas por GPU e Neuron. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). ## Criar AMIs personalizadas Embora recomendemos migrar para AMIs otimizadas para Amazon ECS oficialmente compatíveis e publicadas para o Amazon Linux 2023, você pode continuar a criar AMIs personalizadas do Amazon Linux 2 otimizadas para Amazon ECS usando os scripts de criação de código aberto usados para criar as variantes do Linux da AMI otimizada para Amazon ECS. Para obter mais informações, consulte [Script de compilação da AMI do Linux otimizada para o Amazon ECS](ecs-ami-build-scripts.md). ## Estratégias de migração Recomendamos criar e implementar um plano de migração que inclua testes completos de aplicações. As seções a seguir descrevem diferentes estratégias de migração com base em como você gerencia sua infraestrutura do Amazon ECS. ### Migração com provedores de capacidade do Amazon ECS 1. Crie um novo provedor de capacidade com um novo modelo de inicialização. Isso deve fazer referência a um grupo do Auto Scaling com um modelo de inicialização semelhante ao seu existente, mas em vez da AMI do Amazon Linux 2 otimizada para Amazon ECS, ele deve especificar uma das variantes do Amazon Linux 2023. Adicione esse novo provedor de capacidade ao seu cluster existente do Amazon ECS. 1. Atualize a estratégia de provedor de capacidade padrão do seu cluster para incluir tanto o provedor de capacidade do Amazon Linux 2 existente quanto o novo provedor de capacidade do Amazon Linux 2023. Comece com um peso maior no provedor do Amazon Linux 2 e um peso menor no provedor do Amazon Linux 2023 (por exemplo, Amazon Linux 2: peso 80, Amazon Linux 2023: peso 20). Isso faz com que o Amazon ECS comece a provisionar instâncias do Amazon Linux 2023 à medida que novas tarefas são agendadas. Verifique se as instâncias estão registradas corretamente e se as tarefas podem ser executadas com êxito nas novas instâncias. 1. Ajuste gradualmente os pesos do provedor de capacidade na estratégia padrão do seu cluster, aumentando o peso do provedor do Amazon Linux 2023 e diminuindo o peso do provedor do Amazon Linux 2 ao longo do tempo (por exemplo, 60/40, depois 40/60 e depois 20/80). Você também pode atualizar as estratégias individuais do provedor de capacidade de serviço para priorizar as instâncias do Amazon Linux 2023. Monitore o posicionamento das tarefas para garantir que elas sejam executadas com êxito nas instâncias do Amazon Linux 2023. 1. Opcionalmente, drene as instâncias de contêineres do Amazon Linux 2 para acelerar a migração de tarefas. Se você tiver capacidade suficiente de substituição do Amazon Linux 2023, poderá drenar manualmente suas instâncias de contêineres do Amazon Linux 2 por meio do console do Amazon ECS ou da AWS CLI para acelerar a transição de suas tarefas do Amazon Linux 2 para o Amazon Linux 2023. Depois que a migração for concluída, remova o provedor de capacidade do Amazon Linux 2 do seu cluster e exclua o grupo do Auto Scaling associado. ### Migração com um grupo do Amazon EC2 Auto Scaling 1. Crie um novo grupo do Amazon EC2 Auto Scaling com um novo modelo de inicialização. Isso deve ser semelhante ao seu modelo de inicialização existente, mas em vez da AMI do Amazon Linux 2 otimizada para Amazon ECS, ele deve especificar uma das variantes do Amazon Linux 2023. Esse novo grupo do Auto Scaling pode inicializar instâncias em seu cluster existente. 1. Aumente a escala verticalmente do grupo do Auto Scaling para que você comece a ter instâncias do Amazon Linux 2023 registradas em seu cluster. Verifique se as instâncias estão registradas corretamente e se as tarefas podem ser executadas com êxito nas novas instâncias. 1. Depois de verificar que suas tarefas funcionam no Amazon Linux 2023, aumente a escala verticalmente do grupo do Auto Scaling do Amazon Linux 2023 e, ao mesmo tempo, reduza a escala vertical e gradualmente do grupo do Auto Scaling do Amazon Linux 2, até substituir completamente todas as instâncias do Amazon Linux 2. 1. Se você tiver capacidade suficiente de substituição do Amazon Linux 2023, poderá querer drenar explicitamente suas instâncias de contêineres para acelerar a transição de suas tarefas do Amazon Linux 2 para o Amazon Linux 2023. Para obter mais informações, consulte [Drenagem de instâncias de contêiner do Amazon ECS](container-instance-draining.md). ### Migração com instâncias gerenciadas manualmente 1. Inicializar manualmente (ou ajustar scripts que inicializam) novas instâncias do Amazon EC2 usando a AMI do Amazon Linux 2023 otimizada para Amazon ECS em vez do Amazon Linux 2. Certifique-se de que essas instâncias usem os mesmos grupos de segurança, sub-redes, perfis do IAM e configuração de cluster que suas instâncias existentes do Amazon Linux 2. As instâncias devem se registrar automaticamente em seu cluster existente do Amazon ECS após a inicialização. 1. Verifique se as novas instâncias do Amazon Linux 2023 estão sendo registradas com êxito no seu cluster do Amazon ECS e se estão em um estado `ACTIVE`. Teste se as tarefas podem ser agendadas e executadas adequadamente nessas novas instâncias, aguardando o posicionamento natural das tarefas ou interrompendo e iniciando manualmente algumas tarefas para acionar o reagendamento. 1. Substitua gradualmente suas instâncias do Amazon Linux 2 inicializando instâncias adicionais do Amazon Linux 2023, conforme necessário, e, em seguida, drenando e encerrando manualmente as instâncias do Amazon Linux 2, uma a uma. Você pode drenar instâncias por meio do console do Amazon ECS definindo o status `DRAINING` da instância, o que deixará de colocar novas tarefas nela e permitirá que as tarefas existentes sejam concluídas ou reagendadas em outro lugar. # Script de compilação da AMI do Linux otimizada para o Amazon ECS O Amazon ECS abriu o código dos scripts de compilação usados para criar as variantes do Linux da AMI otimizada para o Amazon ECS. Esses scripts de compilação agora estão disponíveis no GitHub. Para obter mais informações, consulte [amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami) no GitHub. Se você precisar personalizar a AMI otimizada para o Amazon ECS, consulte [Amazon ECS Optimized AMI Build Recipies](https://github.com/aws/amazon-ecs-ami) no GitHub. O repositório de scripts de compilação inclui um modelo do [HashiCorp packer](https://developer.hashicorp.com/packer/docs) e scripts de compilação para gerar cada uma das variantes de Linux da AMI otimizada para o Amazon ECS. Esses scripts são a fonte da verdade para compilações das AMIs otimizadas para o Amazon ECS. Por isso, você pode acompanhar o repositório GitHub para monitorar alterações em nossas AMIs. Por exemplo, talvez você queira que sua AMI use a mesma versão do Docker que a equipe do Amazon ECS usa para a AMI oficial. Para obter mais informações, consulte o repositório de AMIs do Amazon ECS em [aws/amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami) no GitHub **Para compilar uma AMI do Linux otimizada para o Amazon ECS** 1. Clone o repositório `aws/amazon-ecs-ami` do GitHub. ``` git clone https://github.com/aws/amazon-ecs-ami.git ``` 1. Adicione uma variável de ambiente para a região da AWS a ser usada ao criar a AMI. Substitua o valor `us-west-2` com a região a ser usada. ``` export REGION=us-west-2 ``` 1. Um makefile é fornecido para compilar a AMI. A partir do diretório raiz do repositório clonado, use um dos seguintes comandos, correspondente à variante Linux da AMI otimizada para Amazon ECS que você deseja compilar. + AMI do Amazon Linux 2 otimizada para Amazon ECS ``` make al2 ``` + AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS ``` make al2arm ``` + AMI otimizada para GPU do Amazon ECS ``` make al2gpu ``` + AMI do Amazon Linux 2 (Neuron) otimizada para Amazon ECS ``` make al2inf ``` + AMI do Amazon Linux 2023 otimizada para Amazon ECS ``` make al2023 ``` + AMI do Amazon Linux 2023 (arm64) otimizada para Amazon ECS ``` make al2023arm ``` + AMI de GPU Amazon Linux 2023 otimizada para Amazon ECS ``` make al2023gpu ``` + AMI do Amazon Linux 2023 (Neuron) otimizada para Amazon ECS ``` make al2023neu ``` # AMIs Bottlerocket otimizadas para Amazon ECS O Bottlerocket é um sistema operacional de código aberto baseado no Linux que foi criado pela AWS especificamente para executar contêineres em máquinas virtuais ou hosts bare metal. A AMI Bottlerocket otimizada para Amazon ECS é segura e contém apenas o número mínimo de pacotes necessários para executar contêineres. Isso melhora o uso de recursos, reduz a superfície de ataque de segurança e ajuda a reduzir a sobrecarga de gerenciamento. A AMI Bottlerocket também é integrada ao Amazon ECS para ajudar a reduzir a sobrecarga operacional envolvida na atualização de instâncias de contêineres em um cluster. O Bottlerocket difere do Amazon Linux das maneiras a seguir: + O Bottlerocket não inclui um gerenciador de pacotes e seu software só pode ser executado como contêineres. As atualizações do Bottlerocket são aplicadas e podem ser revertidas em uma única etapa, o que reduz a probabilidade de erros de atualização. + O principal mecanismo para gerenciar hosts do Bottlerocket é com um programador de contêineres. Ao contrário do Amazon Linux, o login em instâncias individuais do Bottlerocket deve ser uma operação pouco frequente apenas para fins avançados de depuração e solução de problemas. Para obter mais informações sobre o Bottlerocket, consulte a [documentação](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) e os [comunicados](https://github.com/bottlerocket-os/bottlerocket/releases) no GitHub. Existem variantes da AMI do Bottlerocket otimizada para o Amazon ECS para o kernel 6.1 e o kernel 5.10. As seguintes variantes usam o kernel 6.1: + `aws-ecs-2` + `aws-ecs-2-nvidia` As seguintes variantes usam o kernel 5.10: + `aws-ecs-1` + `aws-ecs-1-nvidia` Para obter mais informações sobre a variante `aws-ecs-1-nvidia`, consulte [Anúncio do suporte à GPU NVIDIA para Bottlerocket no Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-nvidia-gpu-support-for-bottlerocket-on-amazon-ecs/). ## Considerações Considere o seguinte ao usar uma AMI Bottlerocket com o Amazon ECS. + Bottlerocket oferece suporte a instâncias do Amazon EC2 com processadores `x86_64` e `arm64`. O AMI Bottlerocket não é recomendado para uso com instâncias do Amazon EC2 com um chip Inferentia. + As imagens do Bottlerocket não incluem um servidor ou shell SSH. No entanto, é possível usar ferramentas de gerenciamento fora de banda para se obter acesso de administrador ao SSH e realizar a inicialização. Para obter mais informações, consulte essas seções no [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) no GitHub: + [Exploration (Exploração](https://github.com/bottlerocket-os/bottlerocket#exploration) + [Admin container (Contêiner Admin](https://github.com/bottlerocket-os/bottlerocket#admin-container) + Por padrão, o Bottlerocket tem um [contêiner de controle](https://github.com/bottlerocket-os/bottlerocket-control-container) que está habilitado. Esse contêiner executa o [agente do AWS Systems Manager](https://github.com/aws/amazon-ssm-agent) que você pode usar para executar comandos ou iniciar sessões de shell em instâncias Bottlerocket do Amazon EC2. Para obter mais informações, consulte [Configurar gerenciador de sessões](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) no *Guia do usuário do AWS Systems Manager*. + O Bottlerocket é otimizado para workloads de contêiner e tem foco na segurança. O Bottlerocket não inclui um gerenciador de pacotes e é imutável. Para obter informações sobre as orientações e recursos de segurança, consulte [Recursos de segurança](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md) e [Orientação de segurança](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md) no GitHub. + Há suporte para o modo de rede `awsvpc` para a versão `1.1.0` ou posterior da AMI do Bottlerocket. + Há suporte para o App Mesh em uma definição de tarefa para versão `1.15.0` do Bottlerocket AMI ou posterior. + O parâmetro de definição de tarefas `initProcessEnabled` é compatível com a versão `1.19.0` ou posterior da AMI do Bottlerocket. + As AMIs do Bottlerocket também não oferecem suporte com os serviços e recursos a seguir: + ECS Anywhere + Service Connect + Amazon EFS em modo criptografado + Amazon EFS em modo de rede `awsvpc` + Os volumes do Amazon EBS não podem ser montados + Acelerador de inferência elástica # Recuperação dos metadados da AMI do Bottlerocket otimizada para o Amazon ECS É 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. ## Variante `aws-ecs-2` da AMI do Bottlerocket É possível recuperar a última variante estável da AMI do Bottlerocket `aws-ecs-2` por Região da AWS e arquitetura com a AWS CLI ou o Console de gerenciamento da AWS. + **AWS CLI**: é possível recuperar o ID de imagem da AMI do Bottlerocket otimizada para o Amazon ECS recomendada mais recentemente com o comando AWS CLI a seguir, usando o subparâmetro `image_id`. Substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. Para recuperar uma versão diferente da mais recente, substitua `latest` pelo número de versão. + Para a arquitetura de 64 bits (`x86_64`): ``` aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id" --query Parameter.Value --output text ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id" --query Parameter.Value --output text ``` + **Console de gerenciamento da AWS** – É possível consultar o ID da AMI otimizada para o Amazon ECS recomendada, usando um URL no Console de gerenciamento da AWS. O URL abre o console do Amazon EC2 Systems Manager com o valor do ID para o parâmetro. No URL a seguir, substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. + Para a arquitetura de 64 bits (`x86_64`): ``` https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id/description?region=region# ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id/description?region=region# ``` ## Variante `aws-ecs-2-nvidia` da AMI do Bottlerocket É possível recuperar a última variante estável da AMI do Bottlerocket `aws-ecs-2-nvdia` por região e arquitetura com a AWS CLI ou o Console de gerenciamento da AWS. + **AWS CLI**: é possível recuperar o ID de imagem da AMI do Bottlerocket otimizada para o Amazon ECS recomendada mais recentemente com o comando AWS CLI a seguir, usando o subparâmetro `image_id`. Substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. Para recuperar uma versão diferente da mais recente, substitua `latest` pelo número de versão. + Para a arquitetura de 64 bits (`x86_64`): ``` aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id" --query Parameter.Value --output text ``` + **Console de gerenciamento da AWS** – É possível consultar o ID da AMI otimizada para o Amazon ECS recomendada, usando um URL no Console de gerenciamento da AWS. O URL abre o console do Amazon EC2 Systems Manager com o valor do ID para o parâmetro. No URL a seguir, substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. + Para a arquitetura de 64 bits (`x86_64`): ``` https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id/description?region=region# ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id/description?region=region# ``` ## Variante `aws-ecs-1` da AMI do Bottlerocket É possível recuperar a última variante estável da AMI do Bottlerocket `aws-ecs-1` por Região da AWS e arquitetura com a AWS CLI ou o Console de gerenciamento da AWS. + **AWS CLI**: é possível recuperar o ID de imagem da AMI do Bottlerocket otimizada para o Amazon ECS recomendada mais recentemente com o comando AWS CLI a seguir, usando o subparâmetro `image_id`. Substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. Para recuperar uma versão diferente da mais recente, substitua `latest` pelo número de versão. + Para a arquitetura de 64 bits (`x86_64`): ``` aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id" --query Parameter.Value --output text ``` + **Console de gerenciamento da AWS** – É possível consultar o ID da AMI otimizada para o Amazon ECS recomendada, usando um URL no Console de gerenciamento da AWS. O URL abre o console do Amazon EC2 Systems Manager com o valor do ID para o parâmetro. No URL a seguir, substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. + Para a arquitetura de 64 bits (`x86_64`): ``` https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id/description ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id/description ``` ## Variante `aws-ecs-1-nvidia` da AMI do Bottlerocket É possível recuperar a última variante estável da AMI do Bottlerocket `aws-ecs-1-nvdia` por região e arquitetura com a AWS CLI ou o Console de gerenciamento da AWS. + **AWS CLI**: é possível recuperar o ID de imagem da AMI do Bottlerocket otimizada para o Amazon ECS recomendada mais recentemente com o comando AWS CLI a seguir, usando o subparâmetro `image_id`. Substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. + Para a arquitetura de 64 bits (`x86_64`): ``` aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id" --query Parameter.Value --output text ``` + **Console de gerenciamento da AWS** – É possível consultar o ID da AMI otimizada para o Amazon ECS recomendada, usando um URL no Console de gerenciamento da AWS. O URL abre o console do Amazon EC2 Systems Manager com o valor do ID para o parâmetro. No URL a seguir, substitua a `region` pelo código da região para o qual você deseja o ID da AMI. Para obter informações sobre as Regiões da AWS com suporte, consulte [Encontrar uma AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) no GitHub. + Para a arquitetura de 64 bits (`x86_64`): ``` https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id/description?region=region# ``` + Para a arquitetura Arm de 64 bits (`arm64`): ``` https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id/description?region=region# ``` ## Próximas etapas Para obter um tutorial detalhado sobre como começar a usar o sistema operacional Bottlerocket no Amazon ECS, consulte [Usar uma AMI do Bottlerocket com o Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) no GitHub e [Conceitos básicos do Bottlerocket e do Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/), no site do blog da AWS. Para obter mais informações sobre como executar uma instância do Bottlerocket, consulte [Iniciar uma instância do Bottlerocket para o Amazon ECS](bottlerocket-launch.md) # Iniciar uma instância do Bottlerocket para o Amazon ECS Você pode executar uma instância do Bottlerocket para executar as workloads de contêiner. É possível usar a AWS CLI para executar a instância do Bottlerocket. 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. ``` [settings.ecs] cluster = "cluster-name" ``` 1. Use um dos comandos incluídos em [Recuperação dos metadados da AMI do Bottlerocket otimizada para o Amazon ECS](ecs-bottlerocket-retrieve-ami.md) para obter o ID da AMI do Bottlerocket. Você usará isso na etapa a seguir. 1. Execute o comando a seguir para iniciar a instância do Bottlerocket. 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 *bottlerocket\$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-bottlerocket-example \ --subnet-id subnet \ --image-id bottlerocket_ami \ --instance-type t3.large \ --region region \ --tag-specifications 'ResourceType=instance,Tags=[{Key=bottlerocket,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 ``` Para obter uma demonstração detalhada dos conceitos básicos do sistema operacional Bottlerocket no Amazon ECS, consulte [Usar uma AMI do Bottlerocket com o Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) no GitHub e Conceitos básicos do [Bottlerocket e do ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/), no site do blog da AWS. # Gerenciamento de instâncias de contêiner do Linux no Amazon ECS Ao usar as instâncias do EC2 para workloads do Amazon ECS, você é responsável pela manutenção das instâncias **Topics** + [Iniciar uma instância de contêiner](launch_container_instance.md) + [Inicialização de instâncias de contêiner do Linux](bootstrap_container_instance.md) + [Configuração de instâncias de contêiner para receber avisos de instância spot](spot-instance-draining-linux-container.md) + [Execução de um script ao iniciar uma instância de contêiner](start_task_at_launch.md) + [Aumento das interfaces de rede de instâncias de contêiner do Linux no Amazon ECS](container-instance-eni.md) + [Reserva de memória da instância de contêiner](memory-management.md) + [Gerenciar remotamente instâncias de contêiner](ec2-run-command.md) + [Uso de um proxy HTTP para instâncias de contêiner do Linux](http_proxy_config.md) + [Configuração de instâncias inicializadas previamente para o grupo do Auto Scaling](using-warm-pool.md) + [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md) Cada agente de contêiner do Amazon ECS oferece suporte a um conjunto diferente de recursos e fornece correções de erros de versões anteriores. Quando possível, sempre recomendamos usar a versão mais recente do agente de contêiner do Amazon ECS. 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). Para ver quais recursos e aprimoramentos estão incluídos em cada versão de agente, consulte [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases). **Importante** A versão mínima do Docker para métricas confiáveis é a versão Docker `v20.10.13` e posteriores, que está incluída na AMI otimizada para o Amazon ECS `20220607` e posteriores. As versões `1.20.0` e posteriores do agente do Amazon ECS descontinuaram o suporte para as versões do Docker anteriores à `18.01.0`. # Iniciar uma instância de contêiner do Linux do Amazon ECS É possível criar instâncias de contêiner do Amazon ECS usando o console do Amazon EC2. É possível iniciar uma instância usando vários métodos, incluindo o console do Amazon EC2, a AWS CLI e o SDK. Para obter informações sobre outros métodos de inicialização de uma instância, consulte [Iniciar uma instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html) no *Manual do usuário do Amazon EC2*. Para obter mais informações sobre o assistente de inicialização, consulte [Iniciar uma instância usando o novo assistente de inicialização de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) no *Manual do usuário do Amazon EC2*. Antes de começar, conclua as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md). É possível usar o assistente do Amazon EC2 para iniciar uma instância. O assistente de lançamento de instâncias especifica todos os parâmetros de início necessários para iniciar uma instância. **Topics** + [Procedimento](#linux-liw-initiate-instance-launch) + [Nome e tags](#linux-liw-name-and-tags) + [Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)](#linux-liw-ami) + [Tipo de instância](#linux-liw-instance-type) + [Par de chaves (login)](#linux-liw-key-pair) + [Configurações de rede](#linux-liw-network-settings) + [Configurar armazenamento](#linux-liw-storage) + [Detalhes avançados](#linux-liw-advanced-details) ## Procedimento Antes de começar, conclua as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md). 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 na parte superior da tela, a região atual AWS é exibida [por exemplo, Leste dos EUA (Ohio)]. Selecione uma região na qual a instância será iniciada. 1. No painel do console do Amazon EC2, selecione **Launch instance (Executar instância)**. ## Nome e tags O nome da instância é uma tag em que a chave é **Name** (Nome) e o valor é o nome que você especificar. É possível aplicar tags na instância, sos volumes e nos elementos gráficos elásticos. Para instâncias spot, é possível marcar apenas a solicitação de instância spot. A especificação de um nome de instância e de tags adicionais é opcional. + Em **Name** (Nome), insira um nome descritivo para a instância. Se você não especificar um nome, a instância poderá ser identificada por seu ID, que é gerado automaticamente quando você inicia a instância. + Para adicionar mais tags, selecione **Add additional tag** (Adicionar outra tag). Escolha **Add tag** (Adicionar tag), insira uma chave e um valor, e selecione o tipo de recurso a aplicar a tag. Escolha **Add tag** (Adicionar tag) para cada tag adicional a acrescentar. ## Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon) Uma imagem de máquina da Amazon (AMI) contém as informações necessárias para criar uma instância. Por exemplo, uma AMI pode conter o software necessário para atuar como servidor Web, por exemplo, Apache e seu site. Use a barra **Search** (Pesquisa) para encontrar uma AMI otimizada para o Amazon ECS publicada pela AWS. 1. Insira um dos seguintes termos na barra **Search** (Pesquisa). + **ami-ecs** + O **Value** (Valor) de uma AMI otimizada para o Amazon ECS. Para obter as mais recentes AMIs otimizadas para o Amazon ECS e seus valores, consulte [AMI do Linux otimizada para o Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux). 1. Pressione **Enter**. 1. Na página **Escolher uma imagem de máquina da Amazon AMI)**, selecione a guia **AMIs do AWS Marketplace**. 1. No painel esquerdo **Refine results** (Refinar os resultados), selecione **Amazon Web Services** como o **Publisher** (Editor). 1. Escolha **Select** (Selecionar) na linha da AMI que você deseja usar. Como alternativa, escolha **Cancel** (Cancelar) (no canto superior direito) para retornar ao assistente de inicialização de instância sem escolher uma AMI. Uma AMI padrão será selecionada. Confirme se a AMI atende aos requisitos descritos nas [AMIs do Linux otimizadas para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). ## Tipo de instância O tipo de instância define a configuração do hardware e o tamanho da instância. Os tipos de instâncias maiores têm mais CPU e memória. Para ter mais informações, consulte [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html), no *Guia do usuário do Amazon EC2*. Se você quiser executar uma workload somente IPv6, certos tipos de instância não oferecem suporte a endereços IPv6. Para obter mais informações, consulte [Endereços IPv6](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) no *Guia do usuário do Amazon EC2*. + Em **Instance type** (Tipo de instância), selecione o tipo de instância da instância. O tipo de instância que você selecionar determinará os recursos disponíveis para execução de suas tarefas. ## Par de chaves (login) Em **Key pair name** (Nome do par de chaves), escolha um par de chaves existente ou escolha **Create new key pair** (Criar um novo par de chaves) para criar um novo. **Importante** Se você escolher a opção **Proceed without key pair (Not recommended)** (Prosseguir sem par de chaves, não recomendado), não conseguirá se conectar à instância a menos que escolha uma AMI configurada para permitir que os usuários façam login de outro modo. ## Configurações de rede Defina as configurações de rede conforme necessário depois de escolher o botão **Editar** na seção **Configurações de rede** do formulário. + Em **VPC** escolha a VPC na qual você deseja inicializar a instância. Para executar uma workload somente IPv6, escolha uma VPC de pilha dupla que inclua blocos CIDR IPv4 e IPv6. + Em **Sub-rede**, escolha a sub-rede na qual deseja inicializar a instância. É possível inicializar uma instância em uma sub-rede associada a uma zona de disponibilidade, a uma zona local, a uma zona Wavelength ou a um Outpost. Para iniciar a instância em uma zona de disponibilidade, selecione a sub-rede na qual a instância será iniciada. Para criar uma nova sub-rede, escolha **Create new subnet (Criar nova sub-rede)** para acessar o console da Amazon VPC. Quando tiver concluído, retorne ao assistente de inicialização da instância e escolha o ícone Refresh (Atualizar) para carregar sua sub-rede na lista. Para iniciar a instância em uma zona local, selecione uma sub-rede que você criou na zona local. Para iniciar uma instância em um Outpost, selecione uma sub-rede em uma VPC associada ao Outpost. Para executar uma workload somente IPv6, escolha uma sub-rede que inclua apenas um bloco CIDR IPv6. + **Auto-assign Public IP** (Atribuir IP público automaticamente): se sua instância tiver de ser acessada pela Internet pública, verifique se o campo **Auto-assign Public IP** (Atribuir IP público automaticamente) está definido como **Enable** (Habilitar). Em caso negativo, defina esse campo como **Disable** (Desabilitar). **nota** Instâncias de contêiner precisam de acesso para se comunicar com o endpoint do serviço do Amazon ECS. Isso pode ser feito por meio de uma interface do endpoint da VPC ou por meio dos recursos de computação das instâncias de contêiner que tenham endereços IP públicos. Para saber mais sobre endpoints da VPC de interface, consulte [Endpoints da VPC de interface do Amazon ECS (AWS PrivateLink)](vpc-endpoints.md). Se você não tiver um endpoint da VPC de interface configurado e suas instâncias de contêiner não tiverem endereços IP públicos, elas deverão usar a conversão de endereço de rede (NAT) para fornecer esse acesso. 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* e [Uso de um proxy HTTP para instâncias de contêiner do Linux no Amazon ECS](http_proxy_config.md) neste guia. + Se você escolher uma VPC dual-stack e uma sub-rede somente IPv6, em **Atribuir automaticamente IP IPv6**, escolha **Habilitar**. + **Firewall (security groups)** (Firewall, grupos de segurança): use um grupo de segurança para definir regras de firewall da sua instância de contêiner. Essas regras especificam qual tráfego de rede de entrada será fornecido para sua instância de contêiner. Todo o tráfego é ignorado. + Para selecionar um grupo de segurança existente, escolha **Select an existing security group** (Selecionar um grupo de segurança existente) e escolha o grupo de segurança criado em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md). + Se você estiver inicializando a instância para uma workload somente IPv6, escolha **Configuração de rede avançada** e, em **Atribuir IP IPv6 primário**, escolha **Sim**. **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. ## Configurar armazenamento A AMI que você selecionou inclui um ou mais volumes de armazenamento, incluindo o volume raiz. É possível especificar volumes adicionais a serem anexados à instância. É possível usar a exibição **Simple** (Simples). + **Storage type** (Tipo de armazenamento): configure o armazenamento para a sua instância de contêiner. Se você estiver usando a AMI do Amazon Linux 2 otimizada para Amazon ECS, sua instância terá um único volume de 30 GiB configurado, que é compartilhado entre o sistema operacional e o Docker. Se você estiver usando a AMI otimizada para Amazon ECS, a instância terá dois volumes configurados. O volume **Raiz** é para uso do sistema operacional e o segundo volume do Amazon EBS (anexado a `/dev/xvdcz`) é para uso do Docker. Você também pode aumentar ou diminuir os tamanhos de volumes para a sua instância para atender às necessidades dos seus aplicativos. ## Detalhes avançados Em **Advanced details (Detalhes avançados)**, expanda a seção para visualizar os campos e especifique quaisquer parâmetros adicionais para a instância. + **Purchasing option (Opção de compra)**: escolha **Request Spot instances** (Solicitar instâncias Spot) para solicitar instâncias Spot. Também é necessário definir os outros campos relacionados a instâncias spot. Para obter mais informações, consulte [Solicitações de instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html). **nota** Se você estiver usando instâncias spot e vir uma mensagem `Not available`, pode ser necessário escolher um tipo de instância diferente. + **IAM instance profile** (Perfil de instância do IAM): selecione a função do IAM de instância de contêiner. Isso geralmente é chamado de `ecsInstanceRole`. **Importante** Se você não iniciar a instância de contêiner com as permissões apropriadas do IAM, o agente do Amazon ECS não poderá se conectar ao cluster. Para obter mais informações, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md). + **Dados do usuário**: configure a instância de contêiner do Amazon ECS com os dados do usuário, como as variáveis de ambiente de agente de [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). Os scripts de dados do usuário do Amazon EC2 são executados apenas uma vez, quando a instância é iniciada pela primeira vez. Veja a seguir exemplos comuns de quais dados do usuário são usados. + Por padrão, sua instância de contêiner é executada em seu cluster padrão. Para executar em um cluster que não seja padrão, escolha a lista **Detalhes avançados**. Em seguida, cole o seguinte script no campo **Dados do usuário** substituindo *your\$1cluster\$1name* pelo nome do seu cluster. ``` #!/bin/bash echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config ``` + Se você tiver um arquivo `ecs.config` no Amazon S3 e tiver habilitado o acesso somente leitura do Amazon S3 à função de instância de contêiner, escolha a lista **Advanced Details** (Detalhes avançados). Em seguida, cole o seguinte script no campo **User data (Dados do usuário)** substituindo *your\$1bucket\$1name* pelo nome do seu bucket para instalar a AWS CLI e gravar seu arquivo de configuração no momento da inicialização. **nota** Para saber mais sobre essa configuração, consulte [Armazenamento da configuração da instância de contêiner do Amazon ECS no Amazon S3](ecs-config-s3.md). ``` #!/bin/bash yum install -y aws-cli aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config ``` + Especifique tags para sua instância de contêiner usando o parâmetro de configuração `ECS_CONTAINER_INSTANCE_TAGS`. Isso cria etiquetas associadas somente ao Amazon ECS, elas não podem ser listadas usando a API do Amazon EC2. **Importante** Se você iniciar as instâncias de contêiner usando um grupo do Amazon EC2 Auto Scaling, deverá usar o parâmetro de configuração do agente ECS\$1CONTAINER\$1INSTANCE\$1TAGS para adicionar etiquetas. Isso é decorrente da maneira como as etiquetas são adicionadas às instâncias do Amazon EC2 que são iniciadas por meio de grupos do Auto Scaling. ``` #!/bin/bash cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=your_cluster_name ECS_CONTAINER_INSTANCE_TAGS={"tag_key": "tag_value"} EOF ``` + Especifique etiquetas para a instância de contêiner e use o parâmetro de configuração `ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM` para propagá-las do Amazon EC2 para o Amazon ECS Veja a seguir um exemplo de um script de dados do usuário que poderia propagar as tags associadas a uma instância de contêiner, bem como registrar a instância do contêiner com um cluster denominado `your_cluster_name`. ``` #!/bin/bash cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=your_cluster_name ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM=ec2_instance EOF ``` + 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. ``` #!/bin/bash cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=your_cluster_name ECS_INSTANCE_IP_COMPATIBILITY=ipv6 EOF ``` Para obter mais informações, consulte [Inicialização de instâncias de contêiner do Linux no Amazon ECS para transmitir dados](bootstrap_container_instance.md). # Inicialização de instâncias de contêiner do Linux no Amazon ECS para transmitir dados Ao iniciar uma instância do Amazon EC2, é possível transmitir dados do usuário para a instância do EC2. Os dados podem ser usados para realizar tarefas de configuração automatizadas em comum e até mesmo executar scripts na inicialização da instância. Para o Amazon ECS, os casos de uso mais comuns para dados de usuário devem transmitir informações de configuração para o daemon do Docker e o agente de contêiner do Amazon ECS. É possível transmitir vários tipos de dados de usuário para o Amazon EC2, inclusive boothooks de nuvem, scripts de shell e diretivas `cloud-init`. Para obter mais informações sobre esses e outros tipos de formato, consulte a documentação [Cloud-Init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html). Para transmitir os dados do usuário ao usar o assistente de inicialização do Amazon EC2, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). É possível configurar a instância de contêiner para transmitir dados na configuração do agente de contêiner ou na configuração do daemon do Docker. ## Agente do contêiner do Amazon ECS As variantes do Linux da AMI otimizada para Amazon ECS procuram os dados da configuração do agente no arquivo `/etc/ecs/ecs.config` quando o agente de contêiner é iniciado. É possível especificar esses dados de configuração na inicialização com os dados de usuário do Amazon EC2. Para obter mais informações sobre as variáveis ​​de configuração do agente de contêiner do Amazon ECS disponíveis, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). Para definir apenas uma única variável de configuração do agente, como o nome do cluster, use **echo** a fim de copiar a variável para o arquivo de configuração: ``` #!/bin/bash echo "ECS_CLUSTER=MyCluster" >> /etc/ecs/ecs.config ``` Caso você tenha várias variáveis a serem gravadas em `/etc/ecs/ecs.config`, use o formato `heredoc` a seguir. Esse formato grava tudo entre as linhas que começam com **cat** e `EOF` no arquivo de configuração. ``` #!/bin/bash cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=MyCluster ECS_ENGINE_AUTH_TYPE=docker ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}} ECS_LOGLEVEL=debug ECS_WARM_POOLS_CHECK=true EOF ``` Para definir atributos de instância personalizados, defina a variável de ambiente `ECS_INSTANCE_ATTRIBUTES`. ``` #!/bin/bash cat <<'EOF' >> ecs.config ECS_INSTANCE_ATTRIBUTES={"envtype":"prod"} EOF ``` ## Daemon do Docker É possível especificar informações de configuração do daemon do Docker com os dados de usuário do Amazon EC2. Para mais informações sobre as opções de configuração, consulte [a documentação de daemon do Docker](https://docs.docker.com/reference/cli/dockerd/). **nota** A AWS não oferece suporte a configurações personalizadas do Docker, pois ocasionalmente elas podem entrar em conflito com futuras alterações ou recursos do Amazon ECS sem aviso prévio. No exemplo abaixo, as opções personalizadas são adicionadas ao arquivo de configuração do daemon do Docker, `/etc/docker/daemon.json`, que é então especificado nos dados de usuário quando a instância é iniciada. ``` #!/bin/bash cat </etc/docker/daemon.json {"debug": true} EOF systemctl restart docker --no-block ``` No exemplo abaixo, as opções personalizadas são adicionadas ao arquivo de configuração do daemon do Docker, `/etc/docker/daemon.json`, que é então especificado nos dados de usuário quando a instância é iniciada. Este exemplo mostra como desabilitar o docker-proxy no arquivo de configuração do daemon do Docker. ``` #!/bin/bash cat </etc/docker/daemon.json {"userland-proxy": false} EOF systemctl restart docker --no-block ``` # Configuração de instâncias de contêiner do Linux no Amazon ECS para receber avisos de instância spot O Amazon EC2 encerra, interrompe ou coloca a instância spot em hibernação quando o preço spot excede o preço máximo da solicitação ou a capacidade não está mais disponível. O Amazon EC2 fornece um aviso de interrupção de dois minutos de instância spot para ações de terminar e interromper. Ele não fornece o aviso de dois minutos para a ação de hibernação. Se a drenagem da instância spot do Amazon ECS estiver ativada na instância, o Amazon ECS receberá o aviso de interrupção da instância spot e atribuirá a instância ao status `DRAINING`. **Importante** O Amazon ECS não recebe um aviso do Amazon EC2 quando as instâncias são removidas pelo rebalanceamento de capacidade do Auto Scaling. Para obter mais informações, consulte [Rebalanceamento de capacidade do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html). Quando uma instância de contêiner é definida como `DRAINING`, o Amazon ECS impede que novas tarefas sejam programadas para posicionamento na instância de contêiner. As tarefas de serviço nas instâncias de contêiner de drenagem que estão com o status de `PENDING` são interrompidas imediatamente. Se houver instâncias de contêiner no cluster disponíveis, as tarefas de serviço de substituição serão iniciadas nelas. Por padrão, a drenagem de instância spot está desativada. É possível ativar a drenagem de instância spot ao iniciar uma instância. Adicione o script apresentado a seguir ao campo **Dados do usuário**. Substitua *MyCluster* pelo nome do cluster no qual deseja registrar a instância de contêiner. ``` #!/bin/bash cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=MyCluster ECS_ENABLE_SPOT_INSTANCE_DRAINING=true EOF ``` Para obter mais informações, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). **Para ativar a drenagem de instâncias spot para uma instância de contêiner existente** 1. Conecte-se à instância spot pelo SSH. 1. Edite o arquivo `/etc/ecs/ecs.config` e adicione o seguinte: ``` ECS_ENABLE_SPOT_INSTANCE_DRAINING=true ``` 1. Reinicie o serviço `ecs`. + Para a AMI do Amazon Linux 2 otimizada para o Amazon ECS: ``` sudo systemctl restart ecs ``` 1. (Opcional) É possível verificar se o agente está em execução e consultar algumas informações sobre sua nova instância de contêiner consultando a operação da API de introspecção do agente. Para obter mais informações, consulte [Introspecção de contêiner do Amazon ECS](ecs-agent-introspection.md). ``` curl http://localhost:51678/v1/metadata ``` # Execução de um script ao iniciar uma instância de contêiner do Linux no Amazon ECS Talvez seja necessário executar um contêiner específico em cada instância de contêiner para lidar com operações ou questões de segurança, como monitoramento, segurança, métricas, descoberta de serviços ou registros em log. Para fazer isso, você pode configurar suas instâncias de contêiner de forma que elas chamem o comando **docker run** com esse script de dados de usuário na execução ou em algum sistema init como Upstart ou **systemd**. Quando esse método funciona, existem algumas desvantagens, pois o Amazon ECS não tem qualquer conhecimento de contêiner e não pode monitorar a CPU, a memória, as portas ou quaisquer outros recursos utilizados. Para garantir que o Amazon ECS possa assumir adequadamente todos os recursos de tarefas, crie uma definição de tarefa para que o contêiner seja executado nas instâncias de contêiner. Em seguida, use o Amazon ECS para trazer a tarefa até o momento da inicialização com dados de usuário do Amazon EC2. No procedimento a seguir, o script de dados de usuário do Amazon EC2 usa a API de introspecção do Amazon ECS para identificar a instância de contêiner. Em seguida, ele usa a AWS CLI e o comando **start-task** para executar uma tarefa específica nele durante o startup. **Para iniciar uma tarefa no momento da execução da instância de contêiner** 1. Modifique a função do IAM `ecsInstanceRole` para adicionar permissões para a operação de API `StartTask`. Para obter mais informações, consulte [Atualizar permissões para um perfil](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-permissions.html) no *Guia do usuário do AWS Identity and Access Management*. 1. Inicie uma ou mais instâncias de contêiner usando a AMI do Amazon Linux 2 otimizada para o Amazon ECS. Inicie novas instâncias de contêiner e use o script de exemplo apresentado a seguir nos dados do usuário do EC2. Substitua *your\$1cluster\$1name* pelo cluster no qual a instância de contêiner será registrada e *my\$1task\$1def* pela definição de tarefa a ser executada na instância na inicialização. Para obter mais informações, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). **nota** O conteúdo MIME de várias partes abaixo usa um script de shell para definir valores de configuração e instalar os pacotes. Ele também usa um trabalho systemd para iniciar a tarefa depois que o serviço **ecs** estiver em execução e a API de introspecção ficar disponível. ``` Content-Type: multipart/mixed; boundary="==BOUNDARY==" MIME-Version: 1.0 --==BOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash # Specify the cluster that the container instance should register into cluster=your_cluster_name # Write the cluster configuration variable to the ecs.config file # (add any other configuration variables here also) echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config START_TASK_SCRIPT_FILE="/etc/ecs/ecs-start-task.sh" cat <<- 'EOF' > ${START_TASK_SCRIPT_FILE} exec 2>>/var/log/ecs/ecs-start-task.log set -x # Install prerequisite tools yum install -y jq aws-cli # Wait for the ECS service to be responsive until curl -s http://localhost:51678/v1/metadata do sleep 1 done # Grab the container instance ARN and AWS Region from instance metadata instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F/ '{print $NF}' ) cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' ) region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}') # Specify the task definition to run at launch task_definition=my_task_def # Run the AWS CLI start-task command to start your task on this container instance aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region EOF # Write systemd unit file UNIT="ecs-start-task.service" cat <<- EOF > /etc/systemd/system/${UNIT} [Unit] Description=ECS Start Task Requires=ecs.service After=ecs.service [Service] Restart=on-failure RestartSec=30 ExecStart=/usr/bin/bash ${START_TASK_SCRIPT_FILE} [Install] WantedBy=default.target EOF # Enable our ecs.service dependent service with `--no-block` to prevent systemd deadlock # See https://github.com/aws/amazon-ecs-agent/issues/1707 systemctl enable --now --no-block "${UNIT}" --==BOUNDARY==-- ``` 1. Verifique se as suas instâncias de contêiner são executadas no cluster correto e se as suas tarefas foram iniciadas. 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 em que seu cluster está localizado. 1. No painel de navegação, escolha **Clusters** e selecione o cluster que hospeda as suas instâncias de contêiner. 1. Na página **Cluster**, escolha **Tarefas** e, em seguida, escolha suas tarefas. Cada instância de contêiner que você executou deve ter sua tarefa em execução nela. Se você não vir suas tarefas, faça login em suas instâncias de contêiner com SSH e verifique o arquivo `/var/log/ecs/ecs-start-task.log` para obter informações de depuração. # Aumento das interfaces de rede de instâncias de contêiner do Linux no Amazon ECS **nota** Esse recurso não está disponível no Fargate. Cada tarefa que usa o modo de rede `awsvpc` recebe sua própria interface de rede elástica (ENI), que está conectada à instância de contêiner que a hospeda. Existe um limite padrão para o número de interfaces de rede que podem ser anexadas a uma instância do Amazon EC2, e a interface de rede primária conta como uma delas. Por exemplo, por padrão, uma instância `c5.large` pode ter até três ENIs associadas a ela. A interface de rede principal para a instância conta como uma, por isso você pode 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. O Amazon ECS oferece suporte à execução de instâncias de contêiner com maior densidade de ENI usando tipos de instâncias do Amazon EC2 compatíveis. Quando você usa esses tipos de instância e ativa a configuração da conta `awsvpcTrunking`, ENIs adicionais ficam disponíveis em instâncias de contêiner iniciadas recentemente. Essa configuração permite que você coloque mais tarefas em cada instância de contêiner. Para usar o console para ativar o recurso, consulte [Modificar configurações de conta do Amazon ECS](ecs-modifying-longer-id-settings.md). Para usar a AWS CLI para ativar o recurso, consulte [Gerenciar configurações de conta do Amazon ECS usando o AWS CLI](account-setting-management-cli.md). Por exemplo, uma instância `c5.large` com `awsvpcTrunking` tem um limite de ENI aumentado para doze. A instância de contêiner terá a interface de rede prmária e o Amazon ECS cria e anexa uma interface de rede "tronco" à instância de contêiner. Portanto, essa configuração permite que você inicie 10 tarefas na instância de contêiner, em vez das duas tarefas atuais. A interface de rede tronco é totalmente gerenciada pelo Amazon ECS e é excluída quando você encerra ou cancela o registro da instância de contêiner do cluster. Para obter mais informações, consulte [Opções da rede de tarefas do Amazon ECS para o EC2](task-networking.md). ## Considerações Considere as informações apresentadas a seguir ao usar o recurso de entroncamento de ENI. + Somente variantes do Linux da AMI otimizada para o Amazon ECS ou outras variantes do Amazon Linux com a versão `1.28.1` ou posterior do agente de contêiner e a versão `1.28.1-2` ou posterior do pacote ecs-init oferecem suporte a limites maiores de ENI. Se você usar a variante do Linux mais recente da AMI otimizada para Amazon ECS, esses requisitos serão atendidos. Os contêineres do Windows não são suportados no momento. + Somente novas instâncias do Amazon EC2 executadas depois de habilitar `awsvpcTrunking` recebem o aumento de limites de ENI e a interface de rede de truncamento. Instâncias executadas anteriormente não recebem esses recursos, independentemente das ações executadas. + As instâncias do Amazon EC2 devem ter solicitações de DNS de IPv4 baseadas em recursos desativadas. Para desabilitar essa opção, desmarque a opção **Habilitar pedidos de DNS baseados em solicitações IPv4 (registo A)** ao criar uma nova instância no console do Amazon EC2. Para desabilitar essa opção usando o AWS CLI, use o comando a seguir. ``` aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run ``` + As instâncias do Amazon EC2 em sub-redes compartilhadas não são compatíveis. Elas falharão ao registrar em um cluster se forem usadas. + Suas tarefas devem usar o modo de rede `awsvpc` e o EC2. As tarefas que usam o Fargate sempre recebem uma ENI dedicada, independentemente de quantas são inicializadas. Por isso, esse recurso não é necessário. + Suas tarefas devem ser inicializadas na mesma Amazon VPC que a instância de contêiner. Suas tarefas falharão ao iniciar com um erro de atributo se não estiverem na mesma VPC. + Ao executar uma nova instância de contêiner, a instância muda para o status `REGISTERING` enquanto a interface de rede elástica tronco é provisionada para a instância. Se ocorrer uma falha no registro, a instância mudará para o status `REGISTRATION_FAILED`. É possível solucionar problemas de um registro com falha descrevendo a instância de contêiner para visualizar o campo `statusReason`, que descreve o motivo da falha. Em seguida, o registro da instância de contêiner pode ser cancelado manualmente ou encerrado. Depois que o registro da instância de contêiner for cancelado ou encerrado com êxito, o Amazon ECS exclui a ENI de truncamento. **nota** O Amazon ECS emite eventos de alteração de estado de instância de contêiner que você pode monitorar para instâncias que fazem a transição para um estado `REGISTRATION_FAILED`. Para obter mais informações, consulte [Eventos de alteração no estado da instância de contêiner do Amazon ECS](ecs_container_instance_events.md). + Assim que a instância de contêiner é encerrada, ela muda para o status `DEREGISTERING` enquanto a interface de rede elástica tronco é desprovisionada. Depois, a instância muda para o status `INACTIVE`. + Se uma instância de contêiner em uma sub-rede pública com o aumento dos limites de ENI for encerrada e depois reiniciada, a instância perderá o endereço IP público e o agente de contêiner perderá a conexão. + Quando você habilita `awsvpcTrunking`, as instâncias de contêiner recebem uma ENI adicional que usa o grupo de segurança padrão da VPC e é gerenciada pelo Amazon ECS. Uma VPC padrão vem com uma sub-rede pública em cada zona de disponibilidade, um gateway da Internet e configurações para habilitar a resolução de DNS. A sub-rede é pública, porque a tabela de rotas principal envia o tráfego da sub-rede destinado à internet para o gateway da internet. É possível transformar uma sub-rede padrão em uma sub-rede privada removendo a rota do destino 0.0.0.0/0 para o gateway da internet. Porém, se você fizer isso, nenhuma instância de container sendo executada nessa sub-rede poderá acessar a internet. Você pode adicionar ou excluir regras de grupo de segurança para controlar tráfego de entrada e saída das sub-redes. Para obter mais informações, consulte [Regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) no *Manual do usuário da Amazon Virtual Private Cloud*. ## Pré-requisitos Antes de executar uma instância de contêiner com limites de ENI maiores, os pré-requisitos a seguir devem ser atendidos. + A função vinculada ao serviço para Amazon ECS deve ser criada. A função vinculada ao serviço do Amazon ECS fornece 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). 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 conta ou perfil do IAM da instância de contêiner deve habilitar a configuração de conta `awsvpcTrunking`. Recomendamos que você crie dois perfis de instância de contêiner (`ecsInstanceRole`). Em seguida, você pode habilitar a configuração da conta `awsvpcTrunking` para um perfil e usá-lo em tarefas que exigem truncamento de ENI. Para obter informações sobre o perfil da instância de contêiner, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md). Assim que os pré-requisitos forem atendidos, é possível executar uma nova instância de contêiner usando um dos tipos de instância do Amazon EC2 compatíveis, e a instância terá os limites de ENI maiores. Para obter uma lista dos tipos de instâncias compatíveis, consulte [Instâncias com suporte para o aumento de interfaces de rede de contêineres do Amazon ECS](eni-trunking-supported-instance-types.md). A instância de contêiner deve ter a versão `1.28.1` ou posterior do agente de contêiner e a versão `1.28.1-2` ou posterior do pacote ecs-init. Se você usar a variante do Linux mais recente da AMI otimizada para Amazon ECS, esses requisitos serão atendidos. Para obter mais informações, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). **Importante** As instâncias do Amazon EC2 devem ter solicitações de DNS de IPv4 baseadas em recursos desativadas. Para desabilitar essa opção, certifique-se de que a opção **Enable resource-based IPV4 (A record) DNS requests** (Habilitar solicitações de DNS de IPV4 (registro A) baseadas em recursos) esteja desmarcada ao criar uma nova instância usando o console do Amazon EC2. Para desabilitar essa opção usando o AWS CLI, use o comando a seguir. ``` aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run ``` **Para visualizar as instâncias de contêiner com limites de ENI maiores com a AWS CLI** Cada instância de contêiner tem uma interface de rede padrão, conhecida como interface de rede tronco. Use o comando a seguir para listar as instâncias de contêiner com limites maiores de ENI consultando o atributo `ecs.awsvpc-trunk-id`, que indica a existência de uma interface de rede de truncamento. + [list-attributes](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-attributes.html) (AWS CLI) ``` aws ecs list-attributes \ --target-type container-instance \ --attribute-name ecs.awsvpc-trunk-id \ --cluster cluster_name \ --region us-east-1 ``` + [Get-ECSAttributeList](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ECSAttributeList.html) (AWS Tools for Windows PowerShell) ``` Get-ECSAttributeList -TargetType container-instance -AttributeName ecs.awsvpc-trunk-id -Region us-east-1 ``` # Instâncias com suporte para o aumento de interfaces de rede de contêineres do Amazon ECS A seguir, são mostrados os tipos de instância do Amazon EC2 compatíveis e o número de tarefas que usam o modo de rede `awsvpc` que podem ser iniciadas em cada tipo de instância antes e após a habilitação da configuração da conta `awsvpcTrunking`. **Importante** Embora outros tipos de instância sejam compatíveis na mesma família de instâncias, os tipos de instância `a1.metal`, `c5.metal`, `c5a.8xlarge`, `c5ad.8xlarge`, `c5d.metal`, `m5.metal`, `p3dn.24xlarge`, `r5.metal`, `r5.8xlarge` e `r5d.metal` não são compatíveis. As famílias de instâncias `c5n`, `d3`, `d3en`, `g3`, `g3s`, `g4dn`, `i3`, `i3en`, `inf1`, `m5dn`, `m5n`, `m5zn`, `mac1`, `r5b`, `r5n`, `r5dn`, `u-12tb1`, `u-6tb1`, `u-9tb1` e `z1d` não são compatíveis. **Topics** + [Uso geral](#eni-branch-gp) + [Otimizadas para computação](#eni-branch-co) + [Otimizado para memória](#eni-branch-mo) + [Otimizada para armazenamento](#eni-branch-so) + [Computação acelerada](#eni-branch-ac) + [Computação de alta performance](#eni-branch-hpc) ## Uso geral | Tipo de instância | Limite de tarefas sem truncamento da ENI | Limite de tarefas com truncamento da ENI | | --- | --- | --- | | a1.medium | 1 | 10 | | a1.large | 2 | 10 | | a1.xlarge | 3 | 20 | | a1.2xlarge | 3 | 40 | | a1.4xlarge | 7 | 60 | | m5.large | 2 | 10 | | m5.xlarge | 3 | 20 | | m5.2xlarge | 3 | 40 | | m5.4xlarge | 7 | 60 | | m5.8xlarge | 7 | 60 | | m5.12xlarge | 7 | 60 | | m5.16xlarge | 14 | 120 | | m5.24xlarge | 14 | 120 | | m5a.large | 2 | 10 | | m5a.xlarge | 3 | 20 | | m5a.2xlarge | 3 | 40 | | m5a.4xlarge | 7 | 60 | | m5a.8xlarge | 7 | 60 | | m5a.12xlarge | 7 | 60 | | m5a.16xlarge | 14 | 120 | | m5a.24xlarge | 14 | 120 | | m5ad.large | 2 | 10 | | m5ad.xlarge | 3 | 20 | | m5ad.2xlarge | 3 | 40 | | m5ad.4xlarge | 7 | 60 | | m5ad.8xlarge | 7 | 60 | | m5ad.12xlarge | 7 | 60 | | m5ad.16xlarge | 14 | 120 | | m5ad.24xlarge | 14 | 120 | | m5d.large | 2 | 10 | | m5d.xlarge | 3 | 20 | | m5d.2xlarge | 3 | 40 | | m5d.4xlarge | 7 | 60 | | m5d.8xlarge | 7 | 60 | | m5d.12xlarge | 7 | 60 | | m5d.16xlarge | 14 | 120 | | m5d.24xlarge | 14 | 120 | | m5d.metal | 14 | 120 | | m6a.large | 2 | 10 | | m6a.xlarge | 3 | 20 | | m6a.2xlarge | 3 | 40 | | m6a.4xlarge | 7 | 60 | | m6a.8xlarge | 7 | 90 | | m6a.12xlarge | 7 | 120 | | m6a.16xlarge | 14 | 120 | | m6a.24xlarge | 14 | 120 | | m6a.32xlarge | 14 | 120 | | m6a.48xlarge | 14 | 120 | | m6a.metal | 14 | 120 | | m6g.medium | 1 | 4 | | m6g.large | 2 | 10 | | m6g.xlarge | 3 | 20 | | m6g.2xlarge | 3 | 40 | | m6g.4xlarge | 7 | 60 | | m6g.8xlarge | 7 | 60 | | m6g.12xlarge | 7 | 60 | | m6g.16xlarge | 14 | 120 | | m6g.metal | 14 | 120 | | m6gd.medium | 1 | 4 | | m6gd.large | 2 | 10 | | m6gd.xlarge | 3 | 20 | | m6gd.2xlarge | 3 | 40 | | m6gd.4xlarge | 7 | 60 | | m6gd.8xlarge | 7 | 60 | | m6gd.12xlarge | 7 | 60 | | m6gd.16xlarge | 14 | 120 | | m6gd.metal | 14 | 120 | | m6i.large | 2 | 10 | | m6i.xlarge | 3 | 20 | | m6i.2xlarge | 3 | 40 | | m6i.4xlarge | 7 | 60 | | m6i.8xlarge | 7 | 90 | | m6i.12xlarge | 7 | 120 | | m6i.16xlarge | 14 | 120 | | m6i.24xlarge | 14 | 120 | | m6i.32xlarge | 14 | 120 | | m6i.metal | 14 | 120 | | m6id.large | 2 | 10 | | m6id.xlarge | 3 | 20 | | m6id.2xlarge | 3 | 40 | | m6id.4xlarge | 7 | 60 | | m6id.8xlarge | 7 | 90 | | m6id.12xlarge | 7 | 120 | | m6id.16xlarge | 14 | 120 | | m6id.24xlarge | 14 | 120 | | m6id.32xlarge | 14 | 120 | | m6id.metal | 14 | 120 | | m6idn.large | 2 | 10 | | m6idn.xlarge | 3 | 20 | | m6idn.2xlarge | 3 | 40 | | m6idn.4xlarge | 7 | 60 | | m6idn.8xlarge | 7 | 90 | | m6idn.12xlarge | 7 | 120 | | m6idn.16xlarge | 14 | 120 | | m6idn.24xlarge | 14 | 120 | | m6idn.32xlarge | 15 | 120 | | m6idn.metal | 15 | 120 | | m6in.large | 2 | 10 | | m6in.xlarge | 3 | 20 | | m6in.2xlarge | 3 | 40 | | m6in.4xlarge | 7 | 60 | | m6in.8xlarge | 7 | 90 | | m6in.12xlarge | 7 | 120 | | m6in.16xlarge | 14 | 120 | | m6in.24xlarge | 14 | 120 | | m6in.32xlarge | 15 | 120 | | m6in.metal | 15 | 120 | | m7a.medium | 1 | 4 | | m7a.large | 2 | 10 | | m7a.xlarge | 3 | 20 | | m7a.2xlarge | 3 | 40 | | m7a.4xlarge | 7 | 60 | | m7a.8xlarge | 7 | 90 | | m7a.12xlarge | 7 | 120 | | m7a.16xlarge | 14 | 120 | | m7a.24xlarge | 14 | 120 | | m7a.32xlarge | 14 | 120 | | m7a.48xlarge | 14 | 120 | | m7a.metal-48xl | 14 | 120 | | m7g.medium | 1 | 4 | | m7g.large | 2 | 10 | | m7g.xlarge | 3 | 20 | | m7g.2xlarge | 3 | 40 | | m7g.4xlarge | 7 | 60 | | m7g.8xlarge | 7 | 60 | | m7g.12xlarge | 7 | 60 | | m7g.16xlarge | 14 | 120 | | m7g.metal | 14 | 120 | | m7gd.medium | 1 | 4 | | m7gd.large | 2 | 10 | | m7gd.xlarge | 3 | 20 | | m7gd.2xlarge | 3 | 40 | | m7gd.4xlarge | 7 | 60 | | m7gd.8xlarge | 7 | 60 | | m7gd.12xlarge | 7 | 60 | | m7gd.16xlarge | 14 | 120 | | m7gd.metal | 14 | 120 | | m7i.large | 2 | 10 | | m7i.xlarge | 3 | 20 | | m7i.2xlarge | 3 | 40 | | m7i.4xlarge | 7 | 60 | | m7i.8xlarge | 7 | 90 | | m7i.12xlarge | 7 | 120 | | m7i.16xlarge | 14 | 120 | | m7i.24xlarge | 14 | 120 | | m7i.48xlarge | 14 | 120 | | m7i.metal-24xl | 14 | 120 | | m7i.metal-48xl | 14 | 120 | | m7i-flex.large | 2 | 4 | | m7i-flex.xlarge | 3 | 10 | | m7i-flex.2xlarge | 3 | 20 | | m7i-flex.4xlarge | 7 | 40 | | m7i-flex.8xlarge | 7 | 60 | | m7i-flex.12xlarge | 7 | 120 | | m7i-flex.16xlarge | 14 | 120 | | m8a.medium | 1 | 4 | | m8a.large | 2 | 10 | | m8a.xlarge | 3 | 20 | | m8a.2xlarge | 3 | 40 | | m8a.4xlarge | 7 | 60 | | m8a.8xlarge | 9 | 90 | | m8a.12xlarge | 11 | 120 | | m8a.16xlarge | 15 | 120 | | m8a.24xlarge | 15 | 120 | | m8a.48xlarge | 23 | 120 | | m8a.metal-24xl | 15 | 120 | | m8a.metal-48xl | 23 | 120 | | m8azn.medium | 2 | 4 | | m8azn.large | 3 | 10 | | m8azn.xlarge | 3 | 20 | | m8azn.3xlarge | 7 | 40 | | m8azn.6xlarge | 7 | 60 | | m8azn.12xlarge | 15 | 120 | | m8azn.24xlarge | 15 | 120 | | m8azn.metal-12xl | 15 | 120 | | m8azn.metal-24xl | 15 | 120 | | m8g.medium | 1 | 4 | | m8g.large | 2 | 10 | | m8g.xlarge | 3 | 20 | | m8g.2xlarge | 3 | 40 | | m8g.4xlarge | 7 | 60 | | m8g.8xlarge | 7 | 60 | | m8g.12xlarge | 7 | 60 | | m8g.16xlarge | 14 | 120 | | m8g.24xlarge | 14 | 120 | | m8g.48xlarge | 14 | 120 | | m8g.metal-24xl | 14 | 120 | | m8g.metal-48xl | 14 | 120 | | m8gb.medium | 1 | 4 | | m8gb.large | 2 | 10 | | m8gb.xlarge | 3 | 20 | | m8gb.2xlarge | 3 | 40 | | m8gb.4xlarge | 7 | 60 | | m8gb.8xlarge | 9 | 60 | | m8gb.12xlarge | 11 | 60 | | m8gb.16xlarge | 15 | 120 | | m8gb.24xlarge | 23 | 120 | | m8gb.48xlarge | 23 | 120 | | m8gb.metal-24xl | 23 | 120 | | m8gb.metal-48xl | 23 | 120 | | m8gd.medium | 1 | 4 | | m8gd.large | 2 | 10 | | m8gd.xlarge | 3 | 20 | | m8gd.2xlarge | 3 | 40 | | m8gd.4xlarge | 7 | 60 | | m8gd.8xlarge | 7 | 60 | | m8gd.12xlarge | 7 | 60 | | m8gd.16xlarge | 14 | 120 | | m8gd.24xlarge | 14 | 120 | | m8gd.48xlarge | 14 | 120 | | m8gd.metal-24xl | 14 | 120 | | m8gd.metal-48xl | 14 | 120 | | m8gn.medium | 1 | 4 | | m8gn.large | 2 | 10 | | m8gn.xlarge | 3 | 20 | | m8gn.2xlarge | 3 | 40 | | m8gn.4xlarge | 7 | 60 | | m8gn.8xlarge | 9 | 60 | | m8gn.12xlarge | 11 | 60 | | m8gn.16xlarge | 15 | 120 | | m8gn.24xlarge | 23 | 120 | | m8gn.48xlarge | 23 | 120 | | m8gn.metal-24xl | 23 | 120 | | m8gn.metal-48xl | 23 | 120 | | m8i.large | 2 | 10 | | m8i.xlarge | 3 | 20 | | m8i.2xlarge | 3 | 40 | | m8i.4xlarge | 7 | 60 | | m8i.8xlarge | 9 | 90 | | m8i.12xlarge | 11 | 120 | | m8i.16xlarge | 15 | 120 | | m8i.24xlarge | 15 | 120 | | m8i.32xlarge | 23 | 120 | | m8i.48xlarge | 23 | 120 | | m8i.96xlarge | 23 | 120 | | m8i.metal-48xl | 23 | 120 | | m8i.metal-96xl | 23 | 120 | | m8id.large | 2 | 10 | | m8id.xlarge | 3 | 20 | | m8id.2xlarge | 3 | 40 | | m8id.4xlarge | 7 | 60 | | m8id.8xlarge | 9 | 90 | | m8id.12xlarge | 11 | 120 | | m8id.16xlarge | 15 | 120 | | m8id.24xlarge | 15 | 120 | | m8id.32xlarge | 23 | 120 | | m8id.48xlarge | 23 | 120 | | m8id.96xlarge | 23 | 120 | | m8id.metal-48xl | 23 | 120 | | m8id.metal-96xl | 23 | 120 | | m8i-flex.large | 2 | 4 | | m8i-flex.xlarge | 3 | 10 | | m8i-flex.2xlarge | 3 | 20 | | m8i-flex.4xlarge | 7 | 40 | | m8i-flex.8xlarge | 9 | 60 | | m8i-flex.12xlarge | 11 | 120 | | m8i-flex.16xlarge | 15 | 120 | | mac2.metal | 7 | 12 | | mac2-m1ultra.metal | 7 | 12 | | mac2-m2.metal | 7 | 12 | | mac2-m2pro.metal | 7 | 12 | | mac-m4.metal | 7 | 12 | | mac-m4pro.metal | 7 | 12 | ## Otimizadas para computação | Tipo de instância | Limite de tarefas sem truncamento da ENI | Limite de tarefas com truncamento da ENI | | --- | --- | --- | | c5.large | 2 | 10 | | c5.xlarge | 3 | 20 | | c5.2xlarge | 3 | 40 | | c5.4xlarge | 7 | 60 | | c5.9xlarge | 7 | 60 | | c5.12xlarge | 7 | 60 | | c5.18xlarge | 14 | 120 | | c5.24xlarge | 14 | 120 | | c5a.large | 2 | 10 | | c5a.xlarge | 3 | 20 | | c5a.2xlarge | 3 | 40 | | c5a.4xlarge | 7 | 60 | | c5a.12xlarge | 7 | 60 | | c5a.16xlarge | 14 | 120 | | c5a.24xlarge | 14 | 120 | | c5ad.large | 2 | 10 | | c5ad.xlarge | 3 | 20 | | c5ad.2xlarge | 3 | 40 | | c5ad.4xlarge | 7 | 60 | | c5ad.12xlarge | 7 | 60 | | c5ad.16xlarge | 14 | 120 | | c5ad.24xlarge | 14 | 120 | | c5d.large | 2 | 10 | | c5d.xlarge | 3 | 20 | | c5d.2xlarge | 3 | 40 | | c5d.4xlarge | 7 | 60 | | c5d.9xlarge | 7 | 60 | | c5d.12xlarge | 7 | 60 | | c5d.18xlarge | 14 | 120 | | c5d.24xlarge | 14 | 120 | | c6a.large | 2 | 10 | | c6a.xlarge | 3 | 20 | | c6a.2xlarge | 3 | 40 | | c6a.4xlarge | 7 | 60 | | c6a.8xlarge | 7 | 90 | | c6a.12xlarge | 7 | 120 | | c6a.16xlarge | 14 | 120 | | c6a.24xlarge | 14 | 120 | | c6a.32xlarge | 14 | 120 | | c6a.48xlarge | 14 | 120 | | c6a.metal | 14 | 120 | | c6g.medium | 1 | 4 | | c6g.large | 2 | 10 | | c6g.xlarge | 3 | 20 | | c6g.2xlarge | 3 | 40 | | c6g.4xlarge | 7 | 60 | | c6g.8xlarge | 7 | 60 | | c6g.12xlarge | 7 | 60 | | c6g.16xlarge | 14 | 120 | | c6g.metal | 14 | 120 | | c6gd.medium | 1 | 4 | | c6gd.large | 2 | 10 | | c6gd.xlarge | 3 | 20 | | c6gd.2xlarge | 3 | 40 | | c6gd.4xlarge | 7 | 60 | | c6gd.8xlarge | 7 | 60 | | c6gd.12xlarge | 7 | 60 | | c6gd.16xlarge | 14 | 120 | | c6gd.metal | 14 | 120 | | c6gn.medium | 1 | 4 | | c6gn.large | 2 | 10 | | c6gn.xlarge | 3 | 20 | | c6gn.2xlarge | 3 | 40 | | c6gn.4xlarge | 7 | 60 | | c6gn.8xlarge | 7 | 60 | | c6gn.12xlarge | 7 | 60 | | c6gn.16xlarge | 14 | 120 | | c6i.large | 2 | 10 | | c6i.xlarge | 3 | 20 | | c6i.2xlarge | 3 | 40 | | c6i.4xlarge | 7 | 60 | | c6i.8xlarge | 7 | 90 | | c6i.12xlarge | 7 | 120 | | c6i.16xlarge | 14 | 120 | | c6i.24xlarge | 14 | 120 | | c6i.32xlarge | 14 | 120 | | c6i.metal | 14 | 120 | | c6id.large | 2 | 10 | | c6id.xlarge | 3 | 20 | | c6id.2xlarge | 3 | 40 | | c6id.4xlarge | 7 | 60 | | c6id.8xlarge | 7 | 90 | | c6id.12xlarge | 7 | 120 | | c6id.16xlarge | 14 | 120 | | c6id.24xlarge | 14 | 120 | | c6id.32xlarge | 14 | 120 | | c6id.metal | 14 | 120 | | c6in.large | 2 | 10 | | c6in.xlarge | 3 | 20 | | c6in.2xlarge | 3 | 40 | | c6in.4xlarge | 7 | 60 | | c6in.8xlarge | 7 | 90 | | c6in.12xlarge | 7 | 120 | | c6in.16xlarge | 14 | 120 | | c6in.24xlarge | 14 | 120 | | c6in.32xlarge | 15 | 120 | | c6in.metal | 15 | 120 | | c7a.medium | 1 | 4 | | c7a.large | 2 | 10 | | c7a.xlarge | 3 | 20 | | c7a.2xlarge | 3 | 40 | | c7a.4xlarge | 7 | 60 | | c7a.8xlarge | 7 | 90 | | c7a.12xlarge | 7 | 120 | | c7a.16xlarge | 14 | 120 | | c7a.24xlarge | 14 | 120 | | c7a.32xlarge | 14 | 120 | | c7a.48xlarge | 14 | 120 | | c7a.metal-48xl | 14 | 120 | | c7g.medium | 1 | 4 | | c7g.large | 2 | 10 | | c7g.xlarge | 3 | 20 | | c7g.2xlarge | 3 | 40 | | c7g.4xlarge | 7 | 60 | | c7g.8xlarge | 7 | 60 | | c7g.12xlarge | 7 | 60 | | c7g.16xlarge | 14 | 120 | | c7g.metal | 14 | 120 | | c7gd.medium | 1 | 4 | | c7gd.large | 2 | 10 | | c7gd.xlarge | 3 | 20 | | c7gd.2xlarge | 3 | 40 | | c7gd.4xlarge | 7 | 60 | | c7gd.8xlarge | 7 | 60 | | c7gd.12xlarge | 7 | 60 | | c7gd.16xlarge | 14 | 120 | | c7gd.metal | 14 | 120 | | c7gn.medium | 1 | 4 | | c7gn.large | 2 | 10 | | c7gn.xlarge | 3 | 20 | | c7gn.2xlarge | 3 | 40 | | c7gn.4xlarge | 7 | 60 | | c7gn.8xlarge | 7 | 60 | | c7gn.12xlarge | 7 | 60 | | c7gn.16xlarge | 14 | 120 | | c7gn.metal | 14 | 120 | | c7i.large | 2 | 10 | | c7i.xlarge | 3 | 20 | | c7i.2xlarge | 3 | 40 | | c7i.4xlarge | 7 | 60 | | c7i.8xlarge | 7 | 90 | | c7i.12xlarge | 7 | 120 | | c7i.16xlarge | 14 | 120 | | c7i.24xlarge | 14 | 120 | | c7i.48xlarge | 14 | 120 | | c7i.metal-24xl | 14 | 120 | | c7i.metal-48xl | 14 | 120 | | c7i-flex.large | 2 | 4 | | c7i-flex.xlarge | 3 | 10 | | c7i-flex.2xlarge | 3 | 20 | | c7i-flex.4xlarge | 7 | 40 | | c7i-flex.8xlarge | 7 | 60 | | c7i-flex.12xlarge | 7 | 120 | | c7i-flex.16xlarge | 14 | 120 | | c8a.medium | 1 | 4 | | c8a.large | 2 | 10 | | c8a.xlarge | 3 | 20 | | c8a.2xlarge | 3 | 40 | | c8a.4xlarge | 7 | 60 | | c8a.8xlarge | 9 | 90 | | c8a.12xlarge | 11 | 120 | | c8a.16xlarge | 15 | 120 | | c8a.24xlarge | 15 | 120 | | c8a.48xlarge | 23 | 120 | | c8a.metal-24xl | 15 | 120 | | c8a.metal-48xl | 23 | 120 | | c8g.medium | 1 | 4 | | c8g.large | 2 | 10 | | c8g.xlarge | 3 | 20 | | c8g.2xlarge | 3 | 40 | | c8g.4xlarge | 7 | 60 | | c8g.8xlarge | 7 | 60 | | c8g.12xlarge | 7 | 60 | | c8g.16xlarge | 14 | 120 | | c8g.24xlarge | 14 | 120 | | c8g.48xlarge | 14 | 120 | | c8g.metal-24xl | 14 | 120 | | c8g.metal-48xl | 14 | 120 | | c8gb.medium | 1 | 4 | | c8gb.large | 2 | 10 | | c8gb.xlarge | 3 | 20 | | c8gb.2xlarge | 3 | 40 | | c8gb.4xlarge | 7 | 60 | | c8gb.8xlarge | 9 | 60 | | c8gb.12xlarge | 11 | 60 | | c8gb.16xlarge | 15 | 120 | | c8gb.24xlarge | 23 | 120 | | c8gb.48xlarge | 23 | 120 | | c8gb.metal-24xl | 23 | 120 | | c8gb.metal-48xl | 23 | 120 | | c8gd.medium | 1 | 4 | | c8gd.large | 2 | 10 | | c8gd.xlarge | 3 | 20 | | c8gd.2xlarge | 3 | 40 | | c8gd.4xlarge | 7 | 60 | | c8gd.8xlarge | 7 | 60 | | c8gd.12xlarge | 7 | 60 | | c8gd.16xlarge | 14 | 120 | | c8gd.24xlarge | 14 | 120 | | c8gd.48xlarge | 14 | 120 | | c8gd.metal-24xl | 14 | 120 | | c8gd.metal-48xl | 14 | 120 | | c8gn.medium | 1 | 4 | | c8gn.large | 2 | 10 | | c8gn.xlarge | 3 | 20 | | c8gn.2xlarge | 3 | 40 | | c8gn.4xlarge | 7 | 60 | | c8gn.8xlarge | 9 | 60 | | c8gn.12xlarge | 11 | 60 | | c8gn.16xlarge | 15 | 120 | | c8gn.24xlarge | 23 | 120 | | c8gn.48xlarge | 23 | 120 | | c8gn.metal-24xl | 23 | 120 | | c8gn.metal-48xl | 23 | 120 | | c8i.large | 2 | 10 | | c8i.xlarge | 3 | 20 | | c8i.2xlarge | 3 | 40 | | c8i.4xlarge | 7 | 60 | | c8i.8xlarge | 9 | 90 | | c8i.12xlarge | 11 | 120 | | c8i.16xlarge | 15 | 120 | | c8i.24xlarge | 15 | 120 | | c8i.32xlarge | 23 | 120 | | c8i.48xlarge | 23 | 120 | | c8i.96xlarge | 23 | 120 | | c8i.metal-48xl | 23 | 120 | | c8i.metal-96xl | 23 | 120 | | c8id.large | 2 | 10 | | c8id.xlarge | 3 | 20 | | c8id.2xlarge | 3 | 40 | | c8id.4xlarge | 7 | 60 | | c8id.8xlarge | 9 | 90 | | c8id.12xlarge | 11 | 120 | | c8id.16xlarge | 15 | 120 | | c8id.24xlarge | 15 | 120 | | c8id.32xlarge | 23 | 120 | | c8id.48xlarge | 23 | 120 | | c8id.96xlarge | 23 | 120 | | c8id.metal-48xl | 23 | 120 | | c8id.metal-96xl | 23 | 120 | | c8i-flex.large | 2 | 4 | | c8i-flex.xlarge | 3 | 10 | | c8i-flex.2xlarge | 3 | 20 | | c8i-flex.4xlarge | 7 | 40 | | c8i-flex.8xlarge | 9 | 60 | | c8i-flex.12xlarge | 11 | 120 | | c8i-flex.16xlarge | 15 | 120 | ## Otimizado para memória | Tipo de instância | Limite de tarefas sem truncamento da ENI | Limite de tarefas com truncamento da ENI | | --- | --- | --- | | r5.large | 2 | 10 | | r5.xlarge | 3 | 20 | | r5.2xlarge | 3 | 40 | | r5.4xlarge | 7 | 60 | | r5.12xlarge | 7 | 60 | | r5.16xlarge | 14 | 120 | | r5.24xlarge | 14 | 120 | | r5a.large | 2 | 10 | | r5a.xlarge | 3 | 20 | | r5a.2xlarge | 3 | 40 | | r5a.4xlarge | 7 | 60 | | r5a.8xlarge | 7 | 60 | | r5a.12xlarge | 7 | 60 | | r5a.16xlarge | 14 | 120 | | r5a.24xlarge | 14 | 120 | | r5ad.large | 2 | 10 | | r5ad.xlarge | 3 | 20 | | r5ad.2xlarge | 3 | 40 | | r5ad.4xlarge | 7 | 60 | | r5ad.8xlarge | 7 | 60 | | r5ad.12xlarge | 7 | 60 | | r5ad.16xlarge | 14 | 120 | | r5ad.24xlarge | 14 | 120 | | r5b.16xlarge | 14 | 120 | | r5d.large | 2 | 10 | | r5d.xlarge | 3 | 20 | | r5d.2xlarge | 3 | 40 | | r5d.4xlarge | 7 | 60 | | r5d.8xlarge | 7 | 60 | | r5d.12xlarge | 7 | 60 | | r5d.16xlarge | 14 | 120 | | r5d.24xlarge | 14 | 120 | | r5dn.16xlarge | 14 | 120 | | r6a.large | 2 | 10 | | r6a.xlarge | 3 | 20 | | r6a.2xlarge | 3 | 40 | | r6a.4xlarge | 7 | 60 | | r6a.8xlarge | 7 | 90 | | r6a.12xlarge | 7 | 120 | | r6a.16xlarge | 14 | 120 | | r6a.24xlarge | 14 | 120 | | r6a.32xlarge | 14 | 120 | | r6a.48xlarge | 14 | 120 | | r6a.metal | 14 | 120 | | r6g.medium | 1 | 4 | | r6g.large | 2 | 10 | | r6g.xlarge | 3 | 20 | | r6g.2xlarge | 3 | 40 | | r6g.4xlarge | 7 | 60 | | r6g.8xlarge | 7 | 60 | | r6g.12xlarge | 7 | 60 | | r6g.16xlarge | 14 | 120 | | r6g.metal | 14 | 120 | | r6gd.medium | 1 | 4 | | r6gd.large | 2 | 10 | | r6gd.xlarge | 3 | 20 | | r6gd.2xlarge | 3 | 40 | | r6gd.4xlarge | 7 | 60 | | r6gd.8xlarge | 7 | 60 | | r6gd.12xlarge | 7 | 60 | | r6gd.16xlarge | 14 | 120 | | r6gd.metal | 14 | 120 | | r6i.large | 2 | 10 | | r6i.xlarge | 3 | 20 | | r6i.2xlarge | 3 | 40 | | r6i.4xlarge | 7 | 60 | | r6i.8xlarge | 7 | 90 | | r6i.12xlarge | 7 | 120 | | r6i.16xlarge | 14 | 120 | | r6i.24xlarge | 14 | 120 | | r6i.32xlarge | 14 | 120 | | r6i.metal | 14 | 120 | | r6id.large | 2 | 10 | | r6id.xlarge | 3 | 20 | | r6id.2xlarge | 3 | 40 | | r6id.4xlarge | 7 | 60 | | r6id.8xlarge | 7 | 90 | | r6id.12xlarge | 7 | 120 | | r6id.16xlarge | 14 | 120 | | r6id.24xlarge | 14 | 120 | | r6id.32xlarge | 14 | 120 | | r6id.metal | 14 | 120 | | r6idn.large | 2 | 10 | | r6idn.xlarge | 3 | 20 | | r6idn.2xlarge | 3 | 40 | | r6idn.4xlarge | 7 | 60 | | r6idn.8xlarge | 7 | 90 | | r6idn.12xlarge | 7 | 120 | | r6idn.16xlarge | 14 | 120 | | r6idn.24xlarge | 14 | 120 | | r6idn.32xlarge | 15 | 120 | | r6idn.metal | 15 | 120 | | r6in.large | 2 | 10 | | r6in.xlarge | 3 | 20 | | r6in.2xlarge | 3 | 40 | | r6in.4xlarge | 7 | 60 | | r6in.8xlarge | 7 | 90 | | r6in.12xlarge | 7 | 120 | | r6in.16xlarge | 14 | 120 | | r6in.24xlarge | 14 | 120 | | r6in.32xlarge | 15 | 120 | | r6in.metal | 15 | 120 | | r7a.medium | 1 | 4 | | r7a.large | 2 | 10 | | r7a.xlarge | 3 | 20 | | r7a.2xlarge | 3 | 40 | | r7a.4xlarge | 7 | 60 | | r7a.8xlarge | 7 | 90 | | r7a.12xlarge | 7 | 120 | | r7a.16xlarge | 14 | 120 | | r7a.24xlarge | 14 | 120 | | r7a.32xlarge | 14 | 120 | | r7a.48xlarge | 14 | 120 | | r7a.metal-48xl | 14 | 120 | | r7g.medium | 1 | 4 | | r7g.large | 2 | 10 | | r7g.xlarge | 3 | 20 | | r7g.2xlarge | 3 | 40 | | r7g.4xlarge | 7 | 60 | | r7g.8xlarge | 7 | 60 | | r7g.12xlarge | 7 | 60 | | r7g.16xlarge | 14 | 120 | | r7g.metal | 14 | 120 | | r7gd.medium | 1 | 4 | | r7gd.large | 2 | 10 | | r7gd.xlarge | 3 | 20 | | r7gd.2xlarge | 3 | 40 | | r7gd.4xlarge | 7 | 60 | | r7gd.8xlarge | 7 | 60 | | r7gd.12xlarge | 7 | 60 | | r7gd.16xlarge | 14 | 120 | | r7gd.metal | 14 | 120 | | r7i.large | 2 | 10 | | r7i.xlarge | 3 | 20 | | r7i.2xlarge | 3 | 40 | | r7i.4xlarge | 7 | 60 | | r7i.8xlarge | 7 | 90 | | r7i.12xlarge | 7 | 120 | | r7i.16xlarge | 14 | 120 | | r7i.24xlarge | 14 | 120 | | r7i.48xlarge | 14 | 120 | | r7i.metal-24xl | 14 | 120 | | r7i.metal-48xl | 14 | 120 | | r7iz.large | 2 | 10 | | r7iz.xlarge | 3 | 20 | | r7iz.2xlarge | 3 | 40 | | r7iz.4xlarge | 7 | 60 | | r7iz.8xlarge | 7 | 90 | | r7iz.12xlarge | 7 | 120 | | r7iz.16xlarge | 14 | 120 | | r7iz.32xlarge | 14 | 120 | | r7iz.metal-16xl | 14 | 120 | | r7iz.metal-32xl | 14 | 120 | | r8a.medium | 1 | 4 | | r8a.large | 2 | 10 | | r8a.xlarge | 3 | 20 | | r8a.2xlarge | 3 | 40 | | r8a.4xlarge | 7 | 60 | | r8a.8xlarge | 9 | 90 | | r8a.12xlarge | 11 | 120 | | r8a.16xlarge | 15 | 120 | | r8a.24xlarge | 15 | 120 | | r8a.48xlarge | 23 | 120 | | m8a.metal-24xl | 15 | 120 | | m8a.metal-48xl | 23 | 120 | | r8g.medium | 1 | 4 | | r8g.large | 2 | 10 | | r8g.xlarge | 3 | 20 | | r8g.2xlarge | 3 | 40 | | r8g.4xlarge | 7 | 60 | | r8g.8xlarge | 7 | 60 | | r8g.12xlarge | 7 | 60 | | r8g.16xlarge | 14 | 120 | | r8g.24xlarge | 14 | 120 | | r8g.48xlarge | 14 | 120 | | r8g.metal-24xl | 14 | 120 | | r8g.metal-48xl | 14 | 120 | | r8gb.medium | 1 | 4 | | r8gb.large | 2 | 10 | | r8gb.xlarge | 3 | 20 | | r8gb.2xlarge | 3 | 40 | | r8gb.4xlarge | 7 | 60 | | r8gb.8xlarge | 9 | 60 | | r8gb.12xlarge | 11 | 60 | | r8gb.16xlarge | 15 | 120 | | r8gb.24xlarge | 23 | 120 | | r8gb.48xlarge | 23 | 120 | | r8gb.metal-24xl | 23 | 120 | | r8gb.metal-48xl | 23 | 120 | | r8gd.medium | 1 | 4 | | r8gd.large | 2 | 10 | | r8gd.xlarge | 3 | 20 | | r8gd.2xlarge | 3 | 40 | | r8gd.4xlarge | 7 | 60 | | r8gd.8xlarge | 7 | 60 | | r8gd.12xlarge | 7 | 60 | | r8gd.16xlarge | 14 | 120 | | r8gd.24xlarge | 14 | 120 | | r8gd.48xlarge | 14 | 120 | | r8gd.metal-24xl | 14 | 120 | | r8gd.metal-48xl | 14 | 120 | | r8gn.medium | 1 | 4 | | r8gn.large | 2 | 10 | | r8gn.xlarge | 3 | 20 | | r8gn.2xlarge | 3 | 40 | | r8gn.4xlarge | 7 | 60 | | r8gn.8xlarge | 9 | 60 | | r8gn.12xlarge | 11 | 60 | | r8gn.16xlarge | 15 | 120 | | r8gn.24xlarge | 23 | 120 | | r8gn.48xlarge | 23 | 120 | | r8gn.metal-24xl | 23 | 120 | | r8gn.metal-48xl | 23 | 120 | | r8i.large | 2 | 10 | | r8i.xlarge | 3 | 20 | | r8i.2xlarge | 3 | 40 | | r8i.4xlarge | 7 | 60 | | r8i.8xlarge | 9 | 90 | | r8i.12xlarge | 11 | 120 | | r8i.16xlarge | 15 | 120 | | r8i.24xlarge | 15 | 120 | | r8i.32xlarge | 23 | 120 | | r8i.48xlarge | 23 | 120 | | r8i.96xlarge | 23 | 120 | | r8i.metal-48xl | 23 | 120 | | r8i.metal-96xl | 23 | 120 | | r8id.large | 2 | 10 | | r8id.xlarge | 3 | 20 | | r8id.2xlarge | 3 | 40 | | r8id.4xlarge | 7 | 60 | | r8id.8xlarge | 9 | 90 | | r8id.12xlarge | 11 | 120 | | r8id.16xlarge | 15 | 120 | | r8id.24xlarge | 15 | 120 | | r8id.32xlarge | 23 | 120 | | r8id.48xlarge | 23 | 120 | | r8id.96xlarge | 23 | 120 | | r8id.metal-48xl | 23 | 120 | | r8id.metal-96xl | 23 | 120 | | r8i-flex.large | 2 | 4 | | r8i-flex.xlarge | 3 | 10 | | r8i-flex.2xlarge | 3 | 20 | | r8i-flex.4xlarge | 7 | 40 | | r8i-flex.8xlarge | 9 | 60 | | r8i-flex.12xlarge | 11 | 120 | | r8i-flex.16xlarge | 15 | 120 | | u-3tb1.56xlarge | 7 | 12 | | u-6tb1.56xlarge | 14 | 12 | | u-18tb1.112xlarge | 14 | 12 | | u-18tb1.metal | 14 | 12 | | u-24tb1.112xlarge | 14 | 12 | | u-24tb1.metal | 14 | 12 | | u7i-6tb.112xlarge | 14 | 120 | | u7i-8tb.112xlarge | 14 | 120 | | u7i-12tb.224xlarge | 14 | 120 | | u7in-16tb.224xlarge | 15 | 120 | | u7in-24tb.224xlarge | 15 | 120 | | u7in-32tb.224xlarge | 15 | 120 | | u7inh-32tb.480xlarge | 15 | 120 | | x2gd.medium | 1 | 10 | | x2gd.large | 2 | 10 | | x2gd.xlarge | 3 | 20 | | x2gd.2xlarge | 3 | 40 | | x2gd.4xlarge | 7 | 60 | | x2gd.8xlarge | 7 | 60 | | x2gd.12xlarge | 7 | 60 | | x2gd.16xlarge | 14 | 120 | | x2gd.metal | 14 | 120 | | x2idn.16xlarge | 14 | 120 | | x2idn.24xlarge | 14 | 120 | | x2idn.32xlarge | 14 | 120 | | x2idn.metal | 14 | 120 | | x2iedn.xlarge | 3 | 13 | | x2iedn.2xlarge | 3 | 29 | | x2iedn.4xlarge | 7 | 60 | | x2iedn.8xlarge | 7 | 120 | | x2iedn.16xlarge | 14 | 120 | | x2iedn.24xlarge | 14 | 120 | | x2iedn.32xlarge | 14 | 120 | | x2iedn.metal | 14 | 120 | | x2iezn.2xlarge | 3 | 64 | | x2iezn.4xlarge | 7 | 120 | | x2iezn.6xlarge | 7 | 120 | | x2iezn.8xlarge | 7 | 120 | | x2iezn.12xlarge | 14 | 120 | | x2iezn.metal | 14 | 120 | | x8g.medium | 1 | 4 | | x8g.large | 2 | 10 | | x8g.xlarge | 3 | 20 | | x8g.2xlarge | 3 | 40 | | x8g.4xlarge | 7 | 60 | | x8g.8xlarge | 7 | 60 | | x8g.12xlarge | 7 | 60 | | x8g.16xlarge | 14 | 120 | | x8g.24xlarge | 14 | 120 | | x8g.48xlarge | 14 | 120 | | x8g.metal-24xl | 14 | 120 | | x8g.metal-48xl | 14 | 120 | | x8aedz.large | 3 | 10 | | x8aedz.xlarge | 3 | 20 | | x8aedz.3xlarge | 7 | 40 | | x8aedz.6xlarge | 7 | 60 | | x8aedz.12xlarge | 15 | 120 | | x8aedz.24xlarge | 15 | 120 | | x8aedz.metal-12xl | 15 | 120 | | x8aedz.metal-24xl | 15 | 120 | | x8i.large | 2 | 10 | | x8i.xlarge | 3 | 20 | | x8i.2xlarge | 3 | 40 | | x8i.4xlarge | 7 | 60 | | x8i.8xlarge | 9 | 90 | | x8i.12xlarge | 11 | 120 | | x8i.16xlarge | 15 | 120 | | x8i.24xlarge | 15 | 120 | | x8i.32xlarge | 23 | 120 | | x8i.48xlarge | 23 | 120 | | x8i.64xlarge | 23 | 120 | | x8i.96xlarge | 23 | 120 | | x8i.metal-48xl | 23 | 120 | | x8i.metal-96xl | 23 | 120 | ## Otimizada para armazenamento | Tipo de instância | Limite de tarefas sem truncamento da ENI | Limite de tarefas com truncamento da ENI | | --- | --- | --- | | i4g.large | 2 | 10 | | i4g.xlarge | 3 | 20 | | i4g.2xlarge | 3 | 40 | | i4g.4xlarge | 7 | 60 | | i4g.8xlarge | 7 | 60 | | i4g.16xlarge | 14 | 120 | | i4i.xlarge | 3 | 8 | | i4i.2xlarge | 3 | 28 | | i4i.4xlarge | 7 | 58 | | i4i.8xlarge | 7 | 118 | | i4i.12xlarge | 7 | 118 | | i4i.16xlarge | 14 | 248 | | i4i.24xlarge | 14 | 118 | | i4i.32xlarge | 14 | 498 | | i4i.metal | 14 | 498 | | i7i.large | 2 | 10 | | i7i.xlarge | 3 | 20 | | i7i.2xlarge | 3 | 40 | | i7i.4xlarge | 7 | 60 | | i7i.8xlarge | 7 | 90 | | i7i.12xlarge | 7 | 90 | | i7i.16xlarge | 14 | 120 | | i7i.24xlarge | 14 | 120 | | i7i.48xlarge | 14 | 120 | | i7i.metal-24xl | 14 | 120 | | i7i.metal-48xl | 14 | 120 | | i7ie.large | 2 | 20 | | i7ie.xlarge | 3 | 29 | | i7ie.2xlarge | 3 | 29 | | i7ie.3xlarge | 3 | 29 | | i7ie.6xlarge | 7 | 60 | | i7ie.12xlarge | 7 | 60 | | i7ie.18xlarge | 14 | 120 | | i7ie.24xlarge | 14 | 120 | | i7ie.48xlarge | 14 | 120 | | i7ie.metal-24xl | 14 | 120 | | i7ie.metal-48xl | 14 | 120 | | i8g.large | 2 | 10 | | i8g.xlarge | 3 | 20 | | i8g.2xlarge | 3 | 40 | | i8g.4xlarge | 7 | 60 | | i8g.8xlarge | 7 | 60 | | i8g.12xlarge | 7 | 60 | | i8g.16xlarge | 14 | 120 | | i8g.24xlarge | 14 | 120 | | i8g.48xlarge | 14 | 120 | | i8g.metal-24xl | 14 | 120 | | i8g.metal-48xl | 14 | 120 | | i8ge.large | 2 | 20 | | i8ge.xlarge | 3 | 29 | | i8ge.2xlarge | 3 | 29 | | i8ge.3xlarge | 5 | 29 | | i8ge.6xlarge | 9 | 60 | | i8ge.12xlarge | 11 | 60 | | i8ge.18xlarge | 15 | 120 | | i8ge.24xlarge | 15 | 120 | | i8ge.48xlarge | 23 | 120 | | i8ge.metal-24xl | 15 | 120 | | i8ge.metal-48xl | 23 | 120 | | im4gn.large | 2 | 10 | | im4gn.xlarge | 3 | 20 | | im4gn.2xlarge | 3 | 40 | | im4gn.4xlarge | 7 | 60 | | im4gn.8xlarge | 7 | 60 | | im4gn.16xlarge | 14 | 120 | | is4gen.medium | 1 | 4 | | is4gen.large | 2 | 10 | | is4gen.xlarge | 3 | 20 | | is4gen.2xlarge | 3 | 40 | | is4gen.4xlarge | 7 | 60 | | is4gen.8xlarge | 7 | 60 | ## Computação acelerada | Tipo de instância | Limite de tarefas sem truncamento da ENI | Limite de tarefas com truncamento da ENI | | --- | --- | --- | | dl1.24xlarge | 59 | 120 | | dl2q.24xlarge | 14 | 120 | | f2.6xlarge | 7 | 90 | | f2.12xlarge | 7 | 120 | | f2.48xlarge | 14 | 120 | | g4ad.xlarge | 1 | 12 | | g4ad.2xlarge | 1 | 12 | | g4ad.4xlarge | 2 | 12 | | g4ad.8xlarge | 3 | 12 | | g4ad.16xlarge | 7 | 12 | | g5.xlarge | 3 | 6 | | g5.2xlarge | 3 | 19 | | g5.4xlarge | 7 | 40 | | g5.8xlarge | 7 | 90 | | g5.12xlarge | 14 | 120 | | g5.16xlarge | 7 | 120 | | g5.24xlarge | 14 | 120 | | g5.48xlarge | 6 | 120 | | g5g.xlarge | 3 | 20 | | g5g.2xlarge | 3 | 40 | | g5g.4xlarge | 7 | 60 | | g5g.8xlarge | 7 | 60 | | g5g.16xlarge | 14 | 120 | | g5g.metal | 14 | 120 | | g6.xlarge | 3 | 20 | | g6.2xlarge | 3 | 40 | | g6.4xlarge | 7 | 60 | | g6.8xlarge | 7 | 90 | | g6.12xlarge | 7 | 120 | | g6.16xlarge | 14 | 120 | | g6.24xlarge | 14 | 120 | | g6.48xlarge | 14 | 120 | | g6e.xlarge | 3 | 20 | | g6e.2xlarge | 3 | 40 | | g6e.4xlarge | 7 | 60 | | g6e.8xlarge | 7 | 90 | | g6e.12xlarge | 9 | 120 | | g6e.16xlarge | 14 | 120 | | g6e.24xlarge | 19 | 120 | | g6e.48xlarge | 39 | 120 | | g6f.large | 1 | 10 | | g6f.xlarge | 3 | 20 | | g6f.2xlarge | 3 | 40 | | g6f.4xlarge | 7 | 60 | | gr6.4xlarge | 7 | 60 | | gr6.8xlarge | 7 | 90 | | gr6f.4xlarge | 7 | 60 | | g7e.2xlarge | 3 | 242 | | g7e.4xlarge | 7 | 242 | | g7e.8xlarge | 7 | 242 | | g7e.12xlarge | 9 | 242 | | g7e.24xlarge | 19 | 242 | | g7e.48xlarge | 39 | 242 | | inf2.xlarge | 3 | 20 | | inf2.8xlarge | 7 | 90 | | inf2.24xlarge | 14 | 120 | | inf2.48xlarge | 14 | 120 | | p4d.24xlarge | 59 | 120 | | p4de.24xlarge | 59 | 120 | | p5.4xlarge | 3 | 60 | | p5.48xlarge | 63 | 242 | | p5e.48xlarge | 63 | 242 | | p5en.48xlarge | 63 | 242 | | p6-b200.48xlarge | 31 | 242 | | p6-b300.48xlarge | 67 | 242 | | p6e-gb200.36xlarge | 38 | 120 | | trn1.2xlarge | 3 | 19 | | trn1.32xlarge | 39 | 120 | | trn1n.32xlarge | 79 | 242 | | trn2.3xlarge | 1 | 14 | | trn2.48xlarge | 31 | 242 | | trn2u.48xlarge | 31 | 242 | | vt1.3xlarge | 3 | 40 | | vt1.6xlarge | 7 | 60 | | vt1.24xlarge | 14 | 120 | ## Computação de alta performance | Tipo de instância | Limite de tarefas sem truncamento da ENI | Limite de tarefas com truncamento da ENI | | --- | --- | --- | | hpc6a.48xlarge | 1 | 120 | | hpc6id.32xlarge | 1 | 120 | | hpc7g.4xlarge | 3 | 120 | | hpc7g.8xlarge | 3 | 120 | | hpc7g.16xlarge | 3 | 120 | | hpc8a.96xlarge | 3 | -2 | # Reserva de memória da instância de contêiner do Linux no Amazon ECS Quando o agente de contêiner do Amazon ECS registra uma instância de contêiner em um cluster, o agente deve determinar a quantidade de memória que a instância de contêiner tem disponível com a finalidade de reservar para as tarefas. Devido à sobrecarga de memória da plataforma e à memória ocupada pelo kernel do sistema, esse número é diferente da memória instalada anunciada para instâncias do Amazon EC2. Por exemplo, uma instância `m4.large` tem 8 GiB de memória instalada. No entanto, isso nem sempre significa que exatos 8.192 MiB de memória estão disponíveis para as tarefas quando a instância de contêiner é registrada. ## Determinação de recursos de memória das instâncias gerenciadas do ECS As instâncias gerenciadas do Amazon ECS usam uma abordagem hierárquica para determinar os requisitos de recursos de memória para tarefas. Ao contrário do ECS no EC2, que depende da introspecção de memória do Docker, as instâncias gerenciadas do ECS calculam os requisitos de memória diretamente da carga útil da tarefa durante as decisões de agendamento. Quando o agente de instâncias gerenciadas do ECS recebe uma tarefa, ele calcula a necessidade de memória usando a seguinte ordem de prioridade: 1. **Memória no nível da tarefa (prioridade mais alta)**: se a memória no nível da tarefa for especificada na definição de tarefa, o agente usará esse valor diretamente. Isso tem precedência sobre todas as configurações de memória no nível do contêiner. 1. **Soma de memória no nível do contêiner (fallback)**: se a memória no nível da tarefa não for especificada (ou for 0), o agente somará os requisitos de memória de todos os contêineres na tarefa. Para cada contêiner, ele usa: 1. *Reserva de memória (limite flexível)*: se um contêiner especificar `memoryReservation` em sua configuração, o agente usará esse valor. 1. *Memória do contêiner (limite fixo)*: se `memoryReservation` não for especificado, o agente usará o campo `memory` do contêiner. **Example Memória especificada no nível da tarefa** Quando a memória no nível da tarefa é especificada, ela tem precedência sobre as configurações no nível do contêiner: ``` { "family": "my-task", "memory": "2048", "containerDefinitions": [ { "name": "container1", "memory": 1024, "memoryReservation": 512 } ] } ``` O agente reserva 2.048 MiB (a memória no nível da tarefa tem precedência). **Example Memória no nível do contêiner com reservas** Quando a memória no nível da tarefa não é especificada, o agente soma os requisitos de memória do contêiner: ``` { "family": "my-task", "containerDefinitions": [ { "name": "container1", "memory": 1024, "memoryReservation": 512 }, { "name": "container2", "memory": 512 } ] } ``` O agente reserva 512 MiB (reserva de contêiner 1) \$1 512 MiB (memória de contêiner 2) = 1.024 MiB no total. O agente de instâncias gerenciadas do ECS executa o cálculo de memória em três fases: 1. **Recepção da tarefa**: quando uma carga útil da tarefa chega do ambiente de gerenciamento do ECS, o agente calcula imediatamente a memória necessária. 1. **Armazenamento de recursos**: a necessidade de memória calculada é armazenada no modelo de tarefas para uso posterior em operações contábeis de recursos. 1. **Decisão de agendamento**: antes de aceitar uma tarefa, o agente verifica se há memória suficiente disponível. Se a memória disponível for insuficiente, a tarefa será rejeitada e permanecerá na fila de serviços do ECS até que os recursos estejam disponíveis. **nota** Diferentemente do ECS no EC2, as instâncias gerenciadas do ECS não usam a variável de configuração `ECS_RESERVED_MEMORY`. A reserva de memória para os processos do sistema é feita por meio do gerenciamento de recursos da plataforma subjacente, e o agente faz uma contabilidade precisa dos recursos com base nas definições das tarefas. Na opção ECS no EC2, o agente de contêiner do Amazon ECS fornece uma variável de configuração denominada `ECS_RESERVED_MEMORY`, que pode ser usada para remover um número específico de MiB de memória do grupo alocado para as tarefas. Isso reserva de forma efetiva a memória para processos críticos do sistema. Se você ocupar toda a memória em uma instância de contêiner com as tarefas, é possível que elas disputem a memória com processos essenciais do sistema e iniciem uma falha no sistema. Por exemplo, se você especificar `ECS_RESERVED_MEMORY=256` no arquivo de configuração do agente de contêiner, o agente registrará a memória total menos 256 MiB para essa instância, e 256 MiB de memória não poderão ser atribuídos para tarefas do ECS. Para obter mais informações sobre as variáveis de configuração do agente e como configurá-las, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md) e [Inicialização de instâncias de contêiner do Linux no Amazon ECS para transmitir dados](bootstrap_container_instance.md). Se você especificar 8.192 MiB para a tarefa e nenhuma de suas instâncias de contêiner tiver 8.192 MiB ou mais de memória disponível para atender a esse requisito, a tarefa não poderá ser posicionada no cluster. Se estiver usando um ambiente de computação gerenciado, o AWS Batch deverá executar um tipo de instância maior para acomodar a solicitação. O atendente de contêiner do Amazon ECS usa a função `ReadMemInfo()` do Docker para consultar a memória disponível total para o sistema operacional. Tanto o Linux quanto o Windows oferecem utilitários de linha de comando para determinar a memória total. **Example - Determinar a memória total do Linux** O comando **free** retorna a memória total reconhecida pelo sistema operacional. ``` $ free -b ``` Exemplo de saída para uma instância `m4.large` executando a AMI do Amazon Linux otimizada para Amazon ECS. ``` total used free shared buffers cached Mem: 8373026816 348180480 8024846336 90112 25534464 205418496 -/+ buffers/cache: 117227520 8255799296 ``` Essa instância tem 8.373.026.816 bytes de memória total, ou seja, 7.985 MiB estão disponíveis para tarefas. **Example - Determinar a memória total do Windows** O comando **wmic** retorna a memória total reconhecida pelo sistema operacional. ``` C:\> wmic ComputerSystem get TotalPhysicalMemory ``` Exemplo de saída para uma instância `m4.large` executando a AMI do Windows otimizada para o Amazon ECS. ``` TotalPhysicalMemory 8589524992 ``` Essa instância tem 8.589.524.992 bytes de memória total, ou seja, 8.191 MiB estão disponíveis para tarefas. ## Visualização da memória da instância de contêiner É possível visualizar a quantidade de memória com a qual uma instância de contêiner é registrada no console do Amazon ECS (ou com a operação da API [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html)). Se estiver tentando maximizar a utilização de recursos fornecendo às suas tarefas o máximo de memória possível para um tipo de instância específico, você pode observar a memória disponível para essa instância de contêiner e atribuir essa quantidade de memória às tarefas. **Para visualizar a memória da 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 hospeda a instância de contêiner. 1. Escolha **Infraestrutura** e, em Instâncias de contêiner, selecione uma instância de contêiner. 1. A seção **Recursos** mostra a memória registrada e disponível para a instância de contêiner. O valor da memória **Registrada** é o que a instância de contêiner registrou no Amazon ECS quando foi executada pela primeira vez, e o valor da memória **Disponível** é o que ainda não foi alocado para tarefas. # Gerenciamento de instâncias de contêiner do Amazon ECS remotamente usando o AWS Systems Manager É possível usar o recurso Run Command do AWS Systems Manager (Systems Manager) para gerenciar de forma remota e segura a configuração das instâncias de contêiner do Amazon ECS. O Run Command oferece uma maneira simples de executar tarefas administrativas comuns sem fazer login localmente na instância. É possível gerenciar as alterações de configuração entre clusters executando comandos simultaneamente nas várias instâncias de contêiner. O Run Command reporta o status e os resultados de cada comando. Veja alguns exemplos dos tipos de tarefas que você pode executar com o Run Command: + Instale ou desinstale pacotes. + Execute atualizações de segurança. + Limpe imagens de docker. + Interrompa ou inicie serviços. + Visualize os recursos do sistema. + Visualize os arquivos de log. + Execute operações de arquivos. Para obter mais informações sobre o Run Command, consulte [Run Command do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) no *Guia do usuário do AWS Systems Manager*. A seguir, apresentamos os pré-requisitos para usar o Systems Manager com o Amazon ECS. 1. Você deve conceder permissões para acessar as APIs do Systems Manager ao perfil de instância de contêiner (**ecsInstanceRole**). É possível fazer isso ao atribuir **AmazonSSMManagedInstanceCore** ao perfil `ecsInstanceRole`. Para obter informações sobre como anexar uma política a um perfil, consulte [Atualizar permissões para um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) no *Guia do usuário do AWS Identity and Access Management*. 1. Verifique se o SSM Agent está instalado nas instâncias de contêiner. Para obter mais informações, consulte [Instalar e desinstalar manualmente o SSM Agent em instâncias do EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html). Depois de anexar políticas gerenciadas do Systems Manager a `ecsInstanceRole` e verificar se o Agente (SSM Agent) do AWS Systems Manager está instalado nas instâncias de contêiner, será possível começar a usar o Run Command para enviar comandos às instâncias de contêiner. Para obter informações sobre a execução de comandos e scripts de shell nas instâncias e visualizar a saída resultante, consulte [Executar comandos usando o Run Command do Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) e [Demonstrações do Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command-walkthroughs.html) no *Guia do usuário do AWS Systems Manager.* Um caso de uso comum é atualizar o software da instância de contêiner com Executar comando. Você pode seguir os procedimentos no Guia do usuário do AWS Systems Manager com os parâmetros a seguir. | Parâmetro | Valor | | --- | --- | | **Documento de comando** | AWS-RunShellScript | | Comando | 
$ yum update -y
| | Instâncias de destino | Suas instâncias de contêiner | # Uso de um proxy HTTP para instâncias de contêiner do Linux no Amazon ECS É possível configurar as instâncias de contêiner do Amazon ECS para usar um proxy HTTP para o agente de contêiner do Amazon ECS e o daemon do Docker. Isso é útil se suas as instâncias de contêiner não têm acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. Para configurar sua instância de contêiner do Linux do Amazon ECS para usar um proxy HTTP, defina as variáveis a seguir nos arquivos relevantes no momento da inicialização (com dados de usuário do Amazon EC2). Além disso, é possível editar manualmente o arquivo de configuração e, em seguida, reiniciar o agente. `/etc/ecs/ecs.config` (Amazon Linux 2 e AmazonLinux AMI) `HTTP_PROXY=10.0.0.131:3128` Defina esse valor para o nome do host (ou endereço IP) e o número de porta de um proxy HTTP a serem usados pelo agente do Amazon ECS para se conectar à Internet. Por exemplo, as instâncias de contêiner podem não ter acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. `NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock` Defina esse valor como `169.254.169.254,169.254.170.2,/var/run/docker.sock` para filtrar metadados da instância do EC2, perfis do IAM para tarefas e o tráfego do daemon do Docker proveniente do proxy. `/etc/systemd/system/ecs.service.d/http-proxy.conf` (somente Amazon Linux 2) `Environment="HTTP_PROXY=10.0.0.131:3128/"` Defina esse valor como o nome do host (ou endereço IP) e o número de porta de um proxy HTTP a serem usados pelo `ecs-init` para se conectar à Internet. Por exemplo, as instâncias de contêiner podem não ter acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. `Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"` Defina esse valor como `169.254.169.254,169.254.170.2,/var/run/docker.sock` para filtrar metadados da instância do EC2, funções do IAM para tarefas e o tráfego do daemon do Docker proveniente do proxy. `/etc/init/ecs.override` (Somente Amazon Linux AMI) `env HTTP_PROXY=10.0.0.131:3128` Defina esse valor como o nome do host (ou endereço IP) e o número de porta de um proxy HTTP a serem usados pelo `ecs-init` para se conectar à Internet. Por exemplo, as instâncias de contêiner podem não ter acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. `env NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock` Defina esse valor como `169.254.169.254,169.254.170.2,/var/run/docker.sock` para filtrar metadados da instância do EC2, perfis do IAM para tarefas e o tráfego do daemon do Docker proveniente do proxy. `/etc/systemd/system/docker.service.d/http-proxy.conf` (somente Amazon Linux 2) `Environment="HTTP_PROXY=http://10.0.0.131:3128"` Defina este valor para o nome do host (ou endereço IP) e o número de porta de um proxy HTTP a serem usados pelo daemon do Docker para se conectar à Internet. Por exemplo, as instâncias de contêiner podem não ter acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. `Environment="NO_PROXY=169.254.169.254,169.254.170.2"` Defina este valor como `169.254.169.254,169.254.170.2` para filtrar os metadados da instância EC2 no proxy. `/etc/sysconfig/docker` (somente AMI do Amazon Linux AMI e Amazon Linux 2) `export HTTP_PROXY=http://10.0.0.131:3128` Defina este valor para o nome do host (ou endereço IP) e o número de porta de um proxy HTTP a serem usados pelo daemon do Docker para se conectar à Internet. Por exemplo, as instâncias de contêiner podem não ter acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. `export NO_PROXY=169.254.169.254,169.254.170.2` Defina este valor como `169.254.169.254,169.254.170.2` para filtrar os metadados da instância EC2 no proxy. Definir essas variáveis de ambiente nos arquivos acima só afeta o agente de contêiner do Amazon ECS, `ecs-init`, e o daemon do Docker. Elas não configuram nenhum outro serviço (como **yum**) para usar o proxy. Para obter informações sobre como configurar o proxy, consulte [How do I set up an HTTP proxy for Docker and the Amazon ECS container agent in Amazon Linux 2 or AL2023](https://repost.aws/knowledge-center/ecs-http-proxy-docker-linux2). # Configuração de instâncias inicializadas previamente para o grupo do Amazon ECS Auto Scaling O Amazon ECS oferece suporte a grupos de alta atividade do Amazon EC2 Auto Scaling. Um grupo de alta atividade é um grupo de instâncias do Amazon EC2 pré-inicializadas e prontas para serem colocadas em serviço. Sempre que sua aplicação precisar sofrer aumento de escala na horizontal, o Amazon EC2 Auto Scaling usa as instâncias pré-inicializadas do grupo de alta atividade em vez de iniciar instâncias frias, permite que qualquer processo de inicialização final seja executado e, em seguida, coloca a instância em serviço. Para saber mais sobre grupos de alta atividade e como adicionar um grupo de alta atividade ao seu grupo do Auto Scaling, consulte [Grupos de alta atividade para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. Ao criar ou atualizar um grupo de alta atividade para um grupo do Auto Scaling para o Amazon ECS, não é possível definir a opção que retorna instâncias para o grupo de alta atividade ao reduzir a escala horizontalmente (`ReuseOnScaleIn`). Para obter mais informações, consulte [put-warm-pool](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-warm-pool.html) na *Referência da AWS Command Line Interface*. Para usar grupos de alta atividade com seu cluster do Amazon ECS, defina a variável de configuração do agente `ECS_WARM_POOLS_CHECK` como `true` no campo **User data** (Dados do usuário) do seu modelo de inicialização do grupo do Amazon EC2 Auto Scaling. A seguir há um exemplo de como a variável de configuração do agente pode ser especificada no campo **User data** (Dados do usuário) de um modelo de inicialização do Amazon EC2. Substitua *MyCluster* pelo nome do seu cluster. ``` #!/bin/bash cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=MyCluster ECS_WARM_POOLS_CHECK=true EOF ``` Só há suporte para a variável `ECS_WARM_POOLS_CHECK` nas versões `1.59.0` e posteriores do agente. Para obter mais informações sobre as variáveis, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). # Atualizar o agente de contêiner do Amazon ECS Ocasionalmente, pode ser necessário atualizar o agente de contêiner do Amazon ECS para obter correções de erros e novos recursos. A atualização do agente de contêiner do Amazon ECS não interrompe a execução das tarefas ou dos serviços na instância de contêiner. O processo de atualização do agente varia, dependendo do local em que a instância de contêiner foi iniciada, se na AMI otimizada para Amazon ECS ou em outro sistema operacional. **nota** As atualizações de agente não se aplicam a instâncias de contêiner do Windows. É recomendável executar novas instâncias de contêiner para atualizar a versão do agente nos clusters do Windows. ## Verificar a versão do agente de contêiner do Amazon ECS É possível verificar a versão do agente de contêiner que está sendo executada nas instâncias de contêiner para saber se é preciso atualizá-la. A exibição da instância de contêiner no console do Amazon ECS fornece a versão do agente. Use o procedimento a seguir para verificar a versão do agente. ------ #### [ 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, escolha a região em que sua instância externa está registrada. 1. No painel de navegação, escolha **Clusters** e selecione o cluster que hospeda a instância externa. 1. Na página **Cluster : *name***, escolha a guia **Infrastructure** (Infraestrutura). 1. Em **Container instances** (Instâncias de contêiner), observe a coluna **Agent version** (Versão do agente) para suas instâncias de contêiner. Se a instância de contêiner não contiver a versão mais recente do agente de contêiner, o console o alertará com uma mensagem e sinalizará a versão desatualizada do agente. Se a sua versão do agente estiver desatualizada, será possível atualizar seu agente de contêiner com os procedimentos a seguir: + Se sua instância de contêiner estiver executando a AMI otimizada para o Amazon ECS, consulte [Atualizar o agente de contêiner do Amazon ECS em uma AMI otimizada para Amazon ECS](agent-update-ecs-ami.md). + Se sua instância de contêiner não estiver executando a AMI otimizada para o Amazon ECS, consulte [Atualizar manualmente o agente de contêiner do Amazon ECS (para AMIs não otimizadas para Amazon ECS)](manually_update_agent.md). **Importante** Para atualizar versões do agente do Amazon ECS anteriores à v1.0.0 na AMI otimizada para Amazon ECS, recomendamos que você encerre a instância de contêiner atual e execute uma nova instância com a versão mais recente da AMI. Todas as instâncias de contêiner que usam uma versão de pré-visualização devem ser retiradas e substituídas pela AMI mais recente. Para obter mais informações, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). ------ #### [ Amazon ECS container agent introspection API ] Também é possível usar a API de introspecção do agente de contêiner do Amazon ECS para verificar a versão do agente na própria instância de contêiner. Para obter mais informações, consulte [Introspecção de contêiner do Amazon ECS](ecs-agent-introspection.md). **Para verificar se o agente de contêiner do Amazon ECS está executando a versão mais recente com a API de introspecção** 1. Faça login em sua instância de contêiner via SSH. 1. Consulte a API de introspecção. ``` [ec2-user ~]$ curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool ``` **nota** A API de introspecção incluiu informações de `Version` na versão v1.0.0 do agente de contêiner do Amazon ECS. Se `Version` não estiver presente ao consultar a API de introspecção ou ela não estiver presente no seu agente, a versão que você está executando é v0.0.3 ou anterior. Você deve atualizar a versão. ------ # Atualizar o agente de contêiner do Amazon ECS em uma AMI otimizada para Amazon ECS Se você estiver usando a AMI otimizada para Amazon ECS, terá várias opções para obter a versão mais recente do agente de contêiner do Amazon ECS (mostrado por ordem de recomendação): + Encerre as instâncias de contêiner e inicie a versão mais recente da AMI do Amazon Linux 2 otimizada para Amazon ECS (manualmente ou atualizando a configuração de execução do Auto Scaling com a AMI mais recente). O resultado será uma instância de contêiner atualizada com as versões testadas e validadas mais recentes do Amazon Linux, do Docker, do `ecs-init` e do agente de contêiner do Amazon ECS. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md). + Conecte-se à instância com o SSH e atualize o pacote do `ecs-init` (e suas dependências) para a versão mais recente. Essa operação fornecerá as versões testadas e validadas mais recentes do Docker e do `ecs-init` que estão disponíveis nos repositórios do Amazon Linux e na versão mais recente do agente de contêiner do Amazon ECS. Para obter mais informações, consulte [Para atualizar o pacote `ecs-init` em uma AMI otimizada para o Amazon ECS](#procedure_update_ecs-init). + Atualize o agente de contêiner com a operação de API do `UpdateContainerAgent`, através do console ou com a AWS CLI ou os SDKs da AWS. Para obter mais informações, consulte [Atualizar o agente de contêiner do Amazon ECS com a operação de API do `UpdateContainerAgent`](#agent-update-api). **nota** As atualizações de agente não se aplicam a instâncias de contêiner do Windows. É recomendável executar novas instâncias de contêiner para atualizar a versão do agente nos clusters do Windows. **Para atualizar o pacote `ecs-init` em uma AMI otimizada para o Amazon ECS** 1. Faça login em sua instância de contêiner via SSH. 1. Atualize o pacote `ecs-init` com o comando a seguir. ``` sudo yum update -y ecs-init ``` **nota** O pacote `ecs-init` e o agente de contêiner do Amazon ECS são atualizados imediatamente. No entanto, as versões mais recentes do Docker não serão carregadas até que o daemon do Docker seja reiniciado. Inicie novamente reinicializando a instância ou executando os seguintes comandos em sua instância: AMI do Amazon Linux 2 otimizada para Amazon ECS: ``` sudo systemctl restart docker ``` AMI do Amazon Linux otimizada para Amazon ECS: ``` sudo service docker restart && sudo start ecs ``` ## Atualizar o agente de contêiner do Amazon ECS com a operação de API do `UpdateContainerAgent` **Importante** A API do `UpdateContainerAgent` só é compatível com variantes Linux da AMI otimizada para o Amazon ECS, com exceção da AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS. Para instâncias de contêiner que usam a AMI do Amazon Linux 2 (arm64) otimizada para Amazon ECS, atualize o pacote `ecs-init` para atualizar o agente. Para instâncias de contêiner que estão executando outros sistemas operacionais, consulte [Atualizar manualmente o agente de contêiner do Amazon ECS (para AMIs não otimizadas para Amazon ECS)](manually_update_agent.md). Se você está usando instâncias de container do Windows. recomendamos que você inicie novas instâncias de contêiner para atualizar a versão do agente nos clusters do Windows. O processo da API do `UpdateContainerAgent` começa quando você solicita uma atualização do agente, por meio do console ou com a AWS CLI ou AWS SDKs. O Amazon ECS compara a versão atual do agente com a versão mais recente disponível e verifica se é possível realizar uma atualização. Se uma atualização não estiver disponível, por exemplo, se o agente já estiver executando a versão mais recente, um `NoUpdateAvailableException` será retornado. Os estágios do processo de atualização mostrados acima são os seguintes: `PENDING` Uma atualização de agente está disponível, e o processo de atualização iniciou. `STAGING` O agente começou a baixar a atualização do agente. Se o agente não conseguir baixar a atualização ou se o conteúdo da atualização estiver incorreto ou corrompido, o agente enviará uma notificação da falha, e a atualização passará para o estado `FAILED`. `STAGED` O download do agente foi concluído e o conteúdo do agente foi verificado. `UPDATING` O serviço `ecs-init` é reiniciado e obtém a nova versão do agente. Se, por algum motivo, não for possível reiniciar o agente, a atualização passará para o estado `FAILED`; do contrário, o agente informará ao Amazon ECS que a atualização foi concluída. **nota** As atualizações de agente não se aplicam a instâncias de contêiner do Windows. É recomendável executar novas instâncias de contêiner para atualizar a versão do agente nos clusters do Windows. **Para atualizar o agente de contêiner do Amazon ECS em uma AMI otimizada para Amazon ECS no 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, escolha a região em que sua instância externa está registrada. 1. No painel de navegação, escolha **Clusters** e selecione o cluster. 1. Na página **Cluster : *name***, escolha a guia **Infrastructure** (Infraestrutura). 1. Em **Instâncias de contêiner**, selecione as instâncias a serem atualizadas e escolha **Ações**, **Agente de atualização**. # Atualizar manualmente o agente de contêiner do Amazon ECS (para AMIs não otimizadas para Amazon ECS) Ocasionalmente, pode ser necessário atualizar o agente de contêiner do Amazon ECS para obter correções de erros e novos recursos. A atualização do agente de contêiner do Amazon ECS não interrompe a execução das tarefas ou dos serviços na instância de contêiner. **nota** As atualizações de agente não se aplicam a instâncias de contêiner do Windows. É recomendável executar novas instâncias de contêiner para atualizar a versão do agente nos clusters do Windows. 1. Faça login em sua instância de contêiner via SSH. 1. Verifique se o seu agente usa a variável de ambiente `ECS_DATADIR` para salvar seu estado. ``` ubuntu:~$ docker inspect ecs-agent | grep ECS_DATADIR ``` Resultado: ``` "ECS_DATADIR=/data", ``` **Importante** Se o comando anterior não retornar a variável de ambiente `ECS_DATADIR`, você deverá interromper todas as tarefas em execução nessa instância de contêiner antes de atualizar seu agente. Agentes mais novos com a variável de ambiente `ECS_DATADIR` salvam seu estado, e você pode atualizá-los enquanto as tarefas são executadas sem problemas. 1. Interrompa o agente de contêiner do Amazon ECS. ``` ubuntu:~$ docker stop ecs-agent ``` 1. Exclua o contêiner de agente. ``` ubuntu:~$ docker rm ecs-agent ``` 1. Verifique se o diretório `/etc/ecs` e o arquivo de configuração do agente de contêiner do Amazon ECS existem em `/etc/ecs/ecs.config`. ``` ubuntu:~$ sudo mkdir -p /etc/ecs && sudo touch /etc/ecs/ecs.config ``` 1. Edite o arquivo `/etc/ecs/ecs.config` e verifique se ele contém pelo menos as seguintes instruções de variável. Se você não quiser que sua instância de contêiner seja registrada no cluster padrão, especifique seu nome de cluster como o valor para `ECS_CLUSTER`. ``` ECS_DATADIR=/data ECS_ENABLE_TASK_IAM_ROLE=true ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true ECS_LOGFILE=/log/ecs-agent.log ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"] ECS_LOGLEVEL=info ECS_CLUSTER=default ``` Para obter mais informações sobre essas e outras opções de runtime de agente, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). **nota** É possível, opcionalmente, armazenar suas variáveis de ambiente do agente no Amazon S3 (que podem ser baixadas para as instâncias de contêiner no momento da inicialização usando os dados de usuário do Amazon EC2). Isso é recomendado para informações confidenciais, como credenciais de autenticação para repositórios privados. Para obter mais informações, consulte [Armazenamento da configuração da instância de contêiner do Amazon ECS no Amazon S3](ecs-config-s3.md) e [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). 1. Extraia a imagem de agente de contêiner do Amazon ECS mais recente do Amazon Elastic Container Registry Public. ``` ubuntu:~$ docker pull public.ecr.aws/ecs/amazon-ecs-agent:latest ``` Resultado: ``` Pulling repository amazon/amazon-ecs-agent a5a56a5e13dc: Download complete 511136ea3c5a: Download complete 9950b5d678a1: Download complete c48ddcf21b63: Download complete Status: Image is up to date for amazon/amazon-ecs-agent:latest ``` 1. Execute o agente de contêiner do Amazon ECS mais recente na instância de contêiner. **nota** Use políticas de reinicialização do Docker ou um gerenciador de processos (como **upstart** ou **systemd**) para tratar o agente de contêiner como um serviço ou um daemon e garantir que ele seja reiniciado após sair. A AMI otimizada para Amazon ECS usa o RPM `ecs-init` para essa finalidade, e você pode visualizar o [código-fonte para esse RPM](https://github.com/aws/amazon-ecs-init) no GitHub. O comando de execução de agente do exemplo a seguir é dividido em linhas separadas para mostrar cada opção. Para obter mais informações sobre essas e outras opções de runtime de agente, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). **Importante** Os sistemas operacionais com o SELinux habilitado requerem a opção `--privileged` em seu comando **docker run**. Além disso, para instâncias de contêiner habilitadas para SELinux, recomendamos que você adicione a opção `:Z` às montagens de volume `/log` e `/data`. No entanto, as montagens de host para esses volumes devem existir para que você execute o comando; caso contrário, você receberá um erro `no such file or directory`. Execute a seguinte ação se você tiver dificuldades para executar o agente do Amazon ECS em uma instância de contêiner habilitada para o SELinux: Crie os pontos de montagem de volume de host na instância de contêiner. ``` ubuntu:~$ sudo mkdir -p /var/log/ecs /var/lib/ecs/data ``` Adicione a opção `--privileged` ao comando **docker run** abaixo. Anexe a opção `:Z` às montagens de volume de contêiner `/log` e `/data` (por exemplo, `--volume=/var/log/ecs/:/log:Z`) ao comando **docker run** abaixo. ``` ubuntu:~$ sudo docker run --name ecs-agent \ --detach=true \ --restart=on-failure:10 \ --volume=/var/run:/var/run \ --volume=/var/log/ecs/:/log \ --volume=/var/lib/ecs/data:/data \ --volume=/etc/ecs:/etc/ecs \ --volume=/etc/ecs:/etc/ecs/pki \ --net=host \ --env-file=/etc/ecs/ecs.config \ amazon/amazon-ecs-agent:latest ``` **nota** Se você receber uma mensagem `Error response from daemon: Cannot start container`, poderá excluir o contêiner com falha com o comando **sudo docker rm ecs-agent** e tentar executar o comando novamente. # AMIs do Windows otimizadas para o Amazon ECS As AMIs otimizadas para Amazon ECS são pré-configuradas com os componentes necessários para a execução de workloads do ECS. Embora você possa criar sua própria AMI de instância de contêiner que atenda às especificações básicas necessárias para executar workloads em contêineres no Amazon ECS, as AMIs otimizadas para Amazon ECS são pré-configuradas e testadas no Amazon ECS por engenheiros da AWS. É a maneira mais simples de você começar e fazer com que seus contêineres sejam executados na AWS rapidamente. Para cada variante, os metadados da AMI otimizada para o Amazon ECS, incluindo o nome da AMI, a versão do agente do contêiner do Amazon ECS e a versão do runtime do Amazon ECS, que inclui a versão do Docker, podem ser recuperados de forma programática. Para obter mais informações, consulte [Recuperação de metadados da AMI do Windows otimizada para o Amazon ECS](retrieve-ecs-optimized_windows_AMI.md). **Importante** Todas as variantes da AMI otimizadas para o ECS produzidas depois de agosto de 2022 serão migradas do Docker EE (Mirantis) para o Docker CE (projeto Moby). Para garantir que os clientes tenham as atualizações de segurança mais recentes por padrão, o Amazon ECS mantém pelo menos as três últimas AMIs otimizadas para Amazon ECS do Windows. Depois de lançar novas AMIs otimizadas para Amazon ECS do Windows, o Amazon ECS torna privadas as AMIs otimizadas para Amazon ECS do Windows mais antigas. Se você precisar ter acesso a uma AMI privada, avise-nos abrindo um tíquete no suporte à nuvem. ## Variantes da AMI otimizada para Amazon ECS As seguintes variantes do Windows Server da AMI otimizada para Amazon ECS estão disponíveis para instâncias do Amazon EC2. **Importante** Todas as variantes de AMI otimizadas para o ECS produzidas após agosto serão migradas do Docker EE (Mirantis) para o Docker CE (projeto Moby). + **AMI do Windows Server 2025 Full otimizada para Amazon ECS** + **AMI do Windows Server 2025 Core otimizada para Amazon ECS** + **AMI do Windows Server 2022 Full otimizada para Amazon ECS** + **AMI do Windows Server 2022 Core otimizada para Amazon ECS** + **AMI do Windows Server 2019 Full otimizada para Amazon ECS** + **AMI do Windows Server 2019 Core otimizada para Amazon ECS** + **AMI do Windows Server 2016 Full otimizada para Amazon ECS** **Importante** O Windows Server 2016 não oferece suporte à versão mais recente do Docker, por exemplo, 25.x.x. Portanto, as AMIs do Windows Server 2016 Full não receberão patches de segurança ou bugs no runtime do Docker. Recomendamos que você mude para uma das seguintes plataformas do Windows: Windows Server 2022 Full Windows Server 2022 Core Windows Server 2019 Full Windows Server 2019 Core Em 9 de agosto de 2022, a AMI do Windows Server 20H2 Core otimizada para Amazon ECS atingiu sua data de término do suporte. Nenhuma nova versão dessa AMI será lançada. Para obter mais informações, consulte [Windows Server release information](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info). O Windows Server 2025, Windows Server 2022, Windows Server 2019 e o Windows Server 2016 são versões de canal de manutenção em longo prazo (LTSC). O Windows Server 20H2 é uma versão do canal semestral (SAC). Para obter mais informações, consulte [Windows Server release information](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info). ### Considerações Veja algumas coisas que você deve saber sobre contêineres do Windows do Amazon EC2 e o Amazon ECS. + Os contêineres do Windows não podem ser executados em instâncias de contêiner do Linux, e o oposto também ocorre. Para uma melhor colocação de tarefas para Windows e Linux, mantenha as instâncias de contêiner do Windows e do Linux em clusters separados e só coloque tarefas do Windows em clusters do Windows. É possível garantir que as definições de tarefa do Windows só sejam colocadas em instâncias do Windows, para tal definindo a restrição de posicionamento a seguir: `memberOf(ecs.os-type=='windows')`. + Há suporte para contêineres do Windows nas tarefas que usam o EC2 e o Fargate. + Os contêineres do Windows e as instâncias de contêiner não podem oferecer suporte a todos os parâmetros de definição de tarefa disponíveis para contêineres e instâncias de contêiner do Linux. Para alguns parâmetros, eles sequer são compatíveis e outros se comportam de maneira diferente no Windows em comparação com o Linux. Para obter mais informações, consulte [Diferenças de definição de tarefa do Amazon ECS para instâncias do EC2 executando o Windows](windows_task_definitions.md). + Para o recurso de funções do IAM para tarefas, é necessário configurar as instâncias de contêiner do Windows para permitir o recurso na inicialização. Seus contêineres devem executar algum código do PowerShell fornecido quando usam 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). + O recurso de funções do IAM para tarefas usa um proxy de credencial para fornecer credenciais aos contêineres. Como esse proxy de credencial ocupa a porta 80 na instância de contêiner, caso você use funções do IAM para as tarefas, a porta 80 não permanecerá disponível para tarefas. Para contêineres de serviço da Web, você pode usar o Application Load Balancer e o mapeamento de porta dinâmico para fornecer conexões de porta 80 HTTP padrão aos contêineres. 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). + As imagens do Docker do servidor do Windows são grandes (9 GiB). Dessa forma, as instâncias de contêiner do Windows exigem mais espaço de armazenamento do que as instâncias de contêiner do Linux. + Para executar um contêiner do Windows em um Windows Server, a versão do sistema operacional da imagem base do contêiner deve corresponder à do host. Para obter mais informações, consulte [Compatibilidade de versão do contêiner do Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11) no site de documentação da Microsoft. Caso seu cluster execute várias versões do Windows, é possível garantir que uma tarefa seja colocada em uma instância do EC2 em execução na mesma versão usando a restrição de posicionamento: `memberOf(attribute:ecs.os-family == WINDOWS_SERVER__)`. Para obter mais informações, consulte [Recuperação de metadados da AMI do Windows otimizada para o Amazon ECS](retrieve-ecs-optimized_windows_AMI.md). # Recuperação de metadados da AMI do Windows otimizada para o Amazon ECS O ID da AMI, o nome da imagem, o sistema operacional, a versão do agente de contêiner e a versão do runtime para cada variante das AMIs otimizadas para Amazon ECS podem ser recuperados de maneira programática, consultando a API do Systems Manager Parameter Store. Para obter mais informações sobre a API do Systems Manager Parameter Store, consulte [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) e [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html). **nota** O usuário administrador precisa ter as seguintes permissões do IAM para recuperar os metadados da AMI otimizada para Amazon ECS. Essas permissões foram adicionadas à política `AmazonECS_FullAccess` do IAM. ssm:GetParameters ssm:GetParameter ssm:GetParametersByPath ## Formato de parâmetro do Systems Manager Parameter Store **nota** Os parâmetros a seguir da API do Systems Manager Parameter Store estão obsoletos e não devem ser usados para recuperar as AMIs mais recentes do Windows: `/aws/service/ecs/optimized-ami/windows_server/2016/english/full/recommended/image_id ` `/aws/service/ecs/optimized-ami/windows_server/2019/english/full/recommended/image_id` Veja a seguir o formato do nome do parâmetro para cada variante da AMI otimizada para Amazon ECS. + Metadados da AMI do Windows Server 2025 Full: ``` /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized ``` + Metadados da AMI do Windows Server 2025 Core: ``` /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized ``` + Metadados da AMI do Windows Server 2022 Full: ``` /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized ``` + Metadados da AMI do Windows Server 2022 Core: ``` /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized ``` + Metadados da AMI do Windows Server 2019 Full: ``` /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized ``` + Metadados da AMI do Windows Server 2019 Core: ``` /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized ``` + Metadados da AMI do Windows Server 2016 Full: ``` /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized ``` O formato de nome de parâmetro a seguir recupera os metadados da última versão estável da AMI do Windows Server 2019 Full. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized ``` Veja a seguir um exemplo do objeto JSON retornado para o valor do parâmetro. ``` { "Parameters": [ { "Name": "/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized", "Type": "String", "Value": "{\"image_name\":\"Windows_Server-2019-English-Full-ECS_Optimized-2023.06.13\",\"image_id\":\"ami-0debc1fb48e4aee16\",\"ecs_runtime_version\":\"Docker (CE) version 20.10.21\",\"ecs_agent_version\":\"1.72.0\"}", "Version": 58, "LastModifiedDate": "2023-06-22T19:37:37.841000-04:00", "ARN": "arn:aws:ssm:us-east-1::parameter/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized", "DataType": "text" } ], "InvalidParameters": [] } ``` Cada um dos campos na saída acima está disponível para ser consultado como subparâmetros. Crie o caminho do parâmetro para um subparâmetro anexando o nome do subparâmetro ao caminho para a AMI selecionada. Os seguintes subparâmetros estão disponíveis: + `schema_version` + `image_id` + `image_name` + `os` + `ecs_agent_version` + `ecs_runtime_version` ## Exemplos Os exemplos a seguir mostram maneiras como você pode recuperar os metadados de cada variante da AMI otimizada para Amazon ECS. ### Recuperar os metadados da AMI otimizada para Amazon ECS estável mais recente É possível recuperar a AMI otimizada para Amazon ECS estável mais recente por meio da AWS CLI, usando os comandos da AWS CLI a seguir. + **Para a AMI do Windows Server 2025 Full otimizada para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized --region us-east-1 ``` + **Para a AMI do Windows Server 2025 Core otimizada para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized --region us-east-1 ``` + **Para a AMI do Windows Server 2022 Full otimizada para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized --region us-east-1 ``` + **Para a AMI do Windows Server 2022 Core otimizada para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized --region us-east-1 ``` + **Para a AMI do Windows Server 2019 Full otimizada para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized --region us-east-1 ``` + **Para a AMI do Windows Server 2019 Core otimizada para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized --region us-east-1 ``` + **Para a AMI do Windows Server 2016 Full otimizada para Amazon ECS:** ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized --region us-east-1 ``` ### Usar a mais recente e recomendada AMI otimizada para Amazon ECS em um modelo do CloudFormation É possível referenciar a mais recente e recomendada AMI otimizada para Amazon ECS em um modelo do CloudFormation fazendo referência ao nome do armazenamento de parâmetros do Systems Manager. ``` Parameters: LatestECSOptimizedAMI: Description: AMI ID Type: AWS::SSM::Parameter::Value Default: /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized/image_id ``` # Versões da AMI do Windows otimizada para o Amazon ECS Visualize as versões atuais e anteriores das AMIs otimizadas para o Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS, do Docker e do pacote `ecs-init`. Os metadados da AMI otimizada para Amazon ECS, incluindo o ID da AMI, podem ser recuperados de maneira programática em cada variante. Para obter mais informações, consulte [Recuperação de metadados da AMI do Windows otimizada para o Amazon ECS](retrieve-ecs-optimized_windows_AMI.md). As guias a seguir exibem uma lista de versões de AMIs do Windows otimizadas para Amazon ECS. Para obter detalhes sobre como referenciar o parãmetro do Systems Manager Parameter Store em um modelo do CloudFormation, consulte [Usar a mais recente e recomendada AMI otimizada para Amazon ECS em um modelo do CloudFormation](retrieve-ecs-optimized_AMI.md#ecs-optimized-ami-parameter-examples-5). **Importante** Para garantir que os clientes tenham as atualizações de segurança mais recentes por padrão, o Amazon ECS mantém pelo menos as três últimas AMIs otimizadas para Amazon ECS do Windows. Depois de lançar novas AMIs otimizadas para Amazon ECS do Windows, o Amazon ECS torna privadas as AMIs otimizadas para Amazon ECS do Windows mais antigas. Se você precisar ter acesso a uma AMI privada, avise-nos abrindo um tíquete no suporte à nuvem. O Windows Server 2016 não oferece suporte à versão mais recente do Docker, por exemplo, 25.x.x. Portanto, as AMIs do Windows Server 2016 Full não receberão patches de segurança ou bugs no runtime do Docker. Recomendamos que você mude para uma das seguintes plataformas do Windows: Windows Server 2022 Full Windows Server 2022 Core Windows Server 2019 Full Windows Server 2019 Core **nota** O registro em log do plug-in gMSA foi migrado de log baseado em arquivo em `(C:\ProgramData\Amazon\gmsa)` para o Windows Event logging com o lançamento da AMI de agosto de 2025. O script coletor de logs público coletará todos os logs do gMSA. Para obter mais informações, consulte [Coleta de logs de contêiner com o coletor de logs do Amazon ECS](ecs-logs-collector.md). ------ #### [ Windows Server 2025 Full AMI versions ] A tabela a seguir lista as versões atuais e anteriores da AMI do Windows Server 2025 Full otimizada para Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS e do Docker. | AMI do Windows Server 2025 Full otimizada para Amazon ECS | Versão do agente de contêiner do Amazon ECS | Versão do Docker | Visibility | | --- | --- | --- | --- | | **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | Public | | Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | | **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.07.16** | `1.96.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.06.13** | `1.94.0` | `25.0.6 (Docker CE)` | Public | Use o seguinte comando da AWS CLI para recuperar a AMI do Windows Server 2025 Full otimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized ``` ------ #### [ Windows Server 2025 Core AMI versions ] A tabela a seguir lista as versões atuais e anteriores da AMI do Windows Server 2025 Core otimizada para Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS e do Docker. | AMI do Windows Server 2025 Core otimizada para Amazon ECS | Versão do agente de contêiner do Amazon ECS | Versão do Docker | Visibility | | --- | --- | --- | --- | | **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | Public | | Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | | **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.07.16** | `1.96.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.06.13** | `1.94.0` | `25.0.6 (Docker CE)` | Public | Use o seguinte comando da AWS CLI para recuperar a AMI do Windows Server 2025 Core otimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized ``` ------ #### [ Windows Server 2022 Full AMI versions ] A tabela a seguir lista as versões atuais e anteriores da AMI do Windows Server 2022 Full otimizada para Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS e do Docker. | AMI do Windows Server 2022 Full otimizada para Amazon ECS | Versão do agente de contêiner do Amazon ECS | Versão do Docker | Visibility | | --- | --- | --- | --- | | **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | Public | | Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | | **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | Public | Use o seguinte comando da AWS CLI para recuperar a AMI do Windows Server 2022 Full otimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized ``` ------ #### [ Windows Server 2022 Core AMI versions ] A tabela a seguir lista as versões atuais e anteriores da AMI do Windows Server 2022 Core otimizada para Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS e do Docker. | AMI do Windows Server 2022 Core otimizada para Amazon ECS | Versão do agente de contêiner do Amazon ECS | Versão do Docker | Visibility | | --- | --- | --- | --- | | **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | Public | | Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | | **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | Public | Use o seguinte comando da AWS CLI para recuperar a AMI do Windows Server 2022 Full otimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized ``` ------ #### [ Windows Server 2019 Full AMI versions ] A tabela a seguir lista as versões atuais e anteriores da AMI do Windows Server 2019 Full otimizada para Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS e do Docker. | AMI do Windows Server 2019 Full otimizada para Amazon ECS | Versão do agente de contêiner do Amazon ECS | Versão do Docker | Visibility | | --- | --- | --- | --- | | **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | Public | | Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | | **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | Public | Use o seguinte comando da AWS CLI para recuperar a AMI do Windows Server 2019 Full otimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized ``` ------ #### [ Windows Server 2019 Core AMI versions ] A tabela a seguir lista as versões atuais e anteriores da AMI do Windows Server 2019 Core otimizada para Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS e do Docker. | AMI do Windows Server 2019 Core otimizada para Amazon ECS | Versão do agente de contêiner do Amazon ECS | Versão do Docker | Visibility | | --- | --- | --- | --- | | **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | Public | | **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | Public | | Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | | **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | Public | Use o seguinte comando da AWS CLI para recuperar a AMI do Windows Server 2019 Full otimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized ``` ------ #### [ Windows Server 2016 Full AMI versions ] **Importante** O Windows Server 2016 não oferece suporte à versão mais recente do Docker, por exemplo, 25.x.x. Portanto, as AMIs do Windows Server 2016 Full não receberão patches de segurança ou bugs no runtime do Docker. Recomendamos que você mude para uma das seguintes plataformas do Windows: Windows Server 2022 Full Windows Server 2022 Core Windows Server 2019 Full Windows Server 2019 Core A tabela a seguir lista as versões atuais e anteriores da AMI do Windows Server 2016 Full otimizada para Amazon ECS e suas versões correspondentes do agente de contêiner do Amazon ECS e do Docker. | AMI do Windows Server 2016 Full otimizada para Amazon ECS | Versão do agente de contêiner do Amazon ECS | Versão do Docker | Visibility | | --- | --- | --- | --- | | **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `20.10.23 (Docker CE)` | Public | | **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.08.16** | `1.97.1` | `20.10.23 (Docker CE)` | Public | | **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.07.16** | `1.95.0` | `20.10.23 (Docker CE)` | Public | | **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.06.13** | `1.94.0` | `20.10.23 (Docker CE)` | Public | Use a seguinte AWS CLI AMI do Windows Server 2016 Full otimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized ``` ------ # Criar sua própria AMI do Windows otimizada para Amazon ECS Use o EC2 Image Builder para criar sua própria AMI personalizada do Windows otimizada para o Amazon ECS. Isso facilita o uso de uma AMI do Windows com sua própria licença no Amazon ECS. O Amazon ECS fornece um componente gerenciado do Image Builder que fornece a configuração do sistema necessária para executar instâncias do Windows para hospedar os contêineres. Cada componente gerenciado do Amazon ECS inclui um agente de contêiner específico e uma versão do Docker. É possível personalizar a imagem para usar o componente gerenciado do Amazon ECS mais recente ou, se for necessário um agente de contêiner ou uma versão do Docker mais antiga, poderá especificar um componente diferente. Para obter uma demonstração completa do uso do EC2 Image Builder, consulte [Conceitos básicos do EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/set-up-ib-env.html#image-builder-accessing-prereq) no *Guia do usuário do EC2 Image Builder*. Ao criar sua própria AMI do Windows otimizada para Amazon ECS usando o EC2 Image Builder, você cria uma receita de imagem. Sua receita de imagem deve atender aos seguintes requisitos: + A **imagem de origem** deve ser baseada no Windows Server 2019 Core, no Windows Server 2019 Full, no Windows Server 2022 Core ou no Windows Server 2022 Full. Nenhum outro sistema operacional Windows tem suporte. E, nesse caso, pode haver incompatibilidade com o componente. + Ao especificar os **Componentes de criação**, o componente `ecs-optimized-ami-windows` é obrigatório. O componente `update-windows` é recomendado, o que garante que a imagem contenha as atualizações de segurança mais recentes. Para especificar uma versão de componente diferente, expanda o menu **Versioning options** (Opções de versionamento) e especifique a versão do componente que quer usar. Para obter mais informações, consulte [Listar as versões do componente `ecs-optimized-ami-windows`](#windows-component-list). ## Listar as versões do componente `ecs-optimized-ami-windows` Ao criar uma receita do EC2 Image Builder e especificar o componente `ecs-optimized-ami-windows`, você pode usar a opção padrão ou especificar uma versão do componente específica. Para determinar quais versões do componente estão disponíveis, juntamente com o agente de contêiner do Amazon ECS e as versões do Docker contidas no componente, use o Console de gerenciamento da AWS. **Para listar as versões do componente `ecs-optimized-ami-windows` disponíveis** 1. Abra o console do EC2 Image Builder em [https://console.aws.amazon.com/imagebuilder/](https://console.aws.amazon.com/imagebuilder/). 1. Na barra de navegação, selecione a Região em que a imagem está sendo criada. 1. No painel de navegação, no menu **Saved configurations** (Configurações salvas), escolha **Components** (Componentes). 1. Na página **Components** (Componentes), na barra de pesquisa digite `ecs-optimized-ami-windows`, abra o menu de qualificação e selecione **Quick start (Amazon-managed)** (Início rápido [gerenciado pela Amazon]) . 1. Use a coluna **Description** (Descrição) para determinar a versão do componente com o agente de contêiner do Amazon ECS e a versão do Docker de que sua imagem precisa. # Gerenciamento de instâncias de contêiner do Windows do Amazon ECS Ao usar as instâncias do EC2 para workloads do Amazon ECS, você é responsável pela manutenção das instâncias. As atualizações de agente não se aplicam a instâncias de contêiner do Windows. É recomendável executar novas instâncias de contêiner para atualizar a versão do agente nos clusters do Windows. **Topics** + [Iniciar uma instância de contêiner](launch_window-container_instance.md) + [Inicialização de instâncias de contêiner](bootstrap_windows_container_instance.md) + [Uso de um proxy HTTP para instâncias de contêiner do Windows](http_proxy_config-windows.md) + [Configuração de instâncias de contêiner para receber avisos de instância spot](windows-spot-instance-draining-container.md) # Iniciar uma instância de contêiner do Windows do Amazon ECS As instâncias de contêiner do Amazon ECS são criadas por meio do console do Amazon EC2. Antes de começar, é necessário concluir as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md). Para obter mais informações sobre o assistente de inicialização, consulte [Iniciar uma instância usando o novo assistente de inicialização de instância](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html) no *Manual do usuário do Amazon EC2*. É possível usar o assistente do Amazon EC2 para iniciar uma instância. É possível usar a seguinte lista para os parâmetros e deixar os parâmetros não listados como padrão. As instruções a seguir orientam você por cada grupo de parâmetros. ## Procedimento Antes de começar, conclua as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md). 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 na parte superior da tela, a região atual AWS é exibida [por exemplo, Leste dos EUA (Ohio)]. Selecione uma região na qual a instância será iniciada. Essa escolha é importante, pois alguns recursos do Amazon EC2 podem ser compartilhados entre regiões, enquanto outros não podem. 1. No painel do console do Amazon EC2, selecione **Launch instance (Executar instância)**. ## Nome e tags O nome da instância é uma tag em que a chave é **Name** (Nome) e o valor é o nome que você especificar. É possível aplicar tags na instância, sos volumes e nos elementos gráficos elásticos. Para instâncias spot, é possível marcar apenas a solicitação de instância spot. A especificação de um nome de instância e de tags adicionais é opcional. + Em **Name** (Nome), insira um nome descritivo para a instância. Se você não especificar um nome, a instância poderá ser identificada por seu ID, que é gerado automaticamente quando você inicia a instância. + Para adicionar mais tags, selecione **Add additional tag** (Adicionar outra tag). Escolha **Add tag** (Adicionar tag), insira uma chave e um valor, e selecione o tipo de recurso a aplicar a tag. Escolha **Add tag** (Adicionar tag) para cada tag adicional a acrescentar. ## Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon) Uma imagem de máquina da Amazon (AMI) contém as informações necessárias para criar uma instância. Por exemplo, uma AMI pode conter o software necessário para atuar como servidor Web, por exemplo, Apache e seu site. Para obter as mais recentes AMIs otimizadas para o Amazon ECS e seus valores, consulte [AMI do Windows otimizada para o Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html). Use a barra **Search** (Pesquisa) para encontrar uma AMI otimizada para o Amazon ECS publicada pela AWS. 1. Com base em seus requisitos, insira uma das AMIs a seguir na barra **Search** (Pesquisa) e pressione **Enter**. + Windows\$1Server-2022-English-Full-ECS\$1Optimized + Windows\$1Server-2022-English-Core-ECS\$1Optimized + Windows\$1Server-2019-English-Full-ECS\$1Optimized + Windows\$1Server-2019-English-Core-ECS\$1Optimized + Windows\$1Server-2016-English-Full-ECS\$1Optimized 1. Na página **Choose an Amazon Machine Image (AMI)** (Escolher uma imagem de máquina da Amazon [AMI]), selecione a guia **Community AMIs** (AMIs da comunidade). 1. Na lista exibida, escolha uma AMI verificada pela Microsoft com a data de publicação mais recente e clique em **Select** (Selecionar). ## Tipo de instância O tipo de instância define a configuração do hardware e o tamanho da instância. Os tipos de instâncias maiores têm mais CPU e memória. Para obter mais informações, consulte [Tipos de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html). + Em **Instance type** (Tipo de instância), selecione o tipo de instância da instância. O tipo de instância que você selecionar determinará os recursos disponíveis para execução de suas tarefas. ## Par de chaves (login) Em **Key pair name** (Nome do par de chaves), escolha um par de chaves existente ou escolha **Create new key pair** (Criar um novo par de chaves) para criar um novo. **Importante** Se você escolher a opção **Proceed without key pair (Not recommended)** (Prosseguir sem par de chaves, não recomendado), não conseguirá se conectar à instância a menos que escolha uma AMI configurada para permitir que os usuários façam login de outro modo. ## Configurações de rede Defina as configurações de rede, conforme necessário. + **Networking platform** (Plataforma de rede): escolha **Virtual Private Cloud (VPC)** (Nuvem privada virtual - VPC) e especifique a sub-rede na seção **Network interfaces** (Interfaces de rede). + **VPC**: selecione uma VPC existente na qual criar o grupo de segurança. + **Subnet** (Sub-rede): é possível executar uma instância em uma sub-rede associada a uma zona de disponibilidade, a uma zona local, a uma zona Wavelength ou a um Outpost. Para iniciar a instância em uma zona de disponibilidade, selecione a sub-rede na qual a instância será iniciada. Para criar uma nova sub-rede, escolha **Create new subnet (Criar nova sub-rede)** para acessar o console da Amazon VPC. Quando tiver concluído, retorne ao assistente de inicialização da instância e escolha o ícone Refresh (Atualizar) para carregar sua sub-rede na lista. Para iniciar a instância em uma zona local, selecione uma sub-rede que você criou na zona local. Para iniciar uma instância em um Outpost, selecione uma sub-rede em uma VPC associada ao Outpost. + **Auto-assign Public IP** (Atribuir IP público automaticamente): se sua instância tiver de ser acessada pela Internet pública, verifique se o campo **Auto-assign Public IP** (Atribuir IP público automaticamente) está definido como **Enable** (Habilitar). Em caso negativo, defina esse campo como **Disable** (Desabilitar). **nota** Instâncias de contêiner precisam de acesso para se comunicar com o endpoint do serviço do Amazon ECS. Isso pode ser feito por meio de uma interface do endpoint da VPC ou por meio dos recursos de computação das instâncias de contêiner que tenham endereços IP públicos. Para saber mais sobre endpoints da VPC de interface, consulte [Endpoints da VPC de interface do Amazon ECS (AWS PrivateLink)](vpc-endpoints.md). Se você não tiver um endpoint da VPC de interface configurado e suas instâncias de contêiner não tiverem endereços IP públicos, elas deverão usar a conversão de endereço de rede (NAT) para fornecer esse acesso. 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* e [Uso de um proxy HTTP para instâncias de contêiner do Linux no Amazon ECS](http_proxy_config.md) neste guia. + **Firewall (security groups)** (Firewall, grupos de segurança): use um grupo de segurança para definir regras de firewall da sua instância de contêiner. Essas regras especificam qual tráfego de rede de entrada será fornecido para sua instância de contêiner. Todo o tráfego é ignorado. + Para selecionar um grupo de segurança existente, escolha **Select an existing security group** (Selecionar um grupo de segurança existente) e escolha o grupo de segurança criado em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md) ## Configurar armazenamento A AMI que você selecionou inclui um ou mais volumes de armazenamento, incluindo o volume raiz. É possível especificar volumes adicionais a serem anexados à instância. É possível usar a exibição **Simple** (Simples). + **Storage type** (Tipo de armazenamento): configure o armazenamento para a sua instância de contêiner. Se você estiver usando o Amazon Linux AMI otimizado para Amazon ECS, a instância terá dois volumes configurados. O volume **Raiz** é para uso do sistema operacional e o segundo volume do Amazon EBS (anexado a `/dev/xvdcz`) é para uso do Docker. Você também pode aumentar ou diminuir os tamanhos de volumes para a sua instância para atender às necessidades dos seus aplicativos. ## Detalhes avançados Em **Advanced details (Detalhes avançados)**, expanda a seção para visualizar os campos e especifique quaisquer parâmetros adicionais para a instância. + **Purchasing option (Opção de compra)**: escolha **Request Spot instances** (Solicitar instâncias Spot) para solicitar instâncias Spot. Também é necessário definir os outros campos relacionados a instâncias spot. Para obter mais informações, consulte [Solicitações de instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html). **nota** Se você estiver usando instâncias spot e vir uma mensagem `Not available`, pode ser necessário escolher um tipo de instância diferente. . + **IAM instance profile** (Perfil de instância do IAM): selecione a função do IAM de instância de contêiner. Isso geralmente é chamado de `ecsInstanceRole`. **Importante** Se você não iniciar a instância de contêiner com as permissões apropriadas do IAM, o agente do Amazon ECS não poderá se conectar ao cluster. Para obter mais informações, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md). + (Opcional) **User data** (Dados do usuário): configure a instância de contêiner do Amazon ECS com os dados do usuário, como as variáveis de ambiente de agente de [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). Os scripts de dados do usuário do Amazon EC2 são executados apenas uma vez, quando a instância é iniciada pela primeira vez. Veja a seguir exemplos comuns de quais dados do usuário são usados. + Por padrão, sua instância de contêiner é executada em seu cluster padrão. Para executar em um cluster que não seja padrão, escolha a lista **Detalhes avançados**. Em seguida, cole o seguinte script no campo **Dados do usuário** substituindo *your\$1cluster\$1name* pelo nome do seu cluster. O `EnableTaskIAMRole` ativa o recurso de funções de tarefas do IAM para as tarefas. Além disso, as seguintes opções estão disponíveis quando for usado o modo de rede `awsvpc`. + `EnableTaskENI`:este sinalizador ativa a rede de tarefas e é necessário quando é usado o modo de rede `awsvpc`. + `AwsvpcBlockIMDS`: este sinalizador opcional bloqueia o acesso IMDS para os contentores de tarefas em execução no modo de rede `awsvpc`. + `AwsvpcAdditionalLocalRoutes`: este sinalizador opcional permite que você tenha rotas adicionais no namespace da tarefa. Substitua `ip-address` pelo o endereço IP das rotas adicionais, por exemplo, 172.31.42.23/32. ``` Import-Module ECSTools Initialize-ECSAgent -Cluster your_cluster_name -EnableTaskIAMRole -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes '["ip-address"]' ``` # Inicialização de instâncias de contêiner do Windows no Amazon ECS para transmitir dados Ao iniciar uma instância do Amazon EC2, é possível transmitir dados do usuário para a instância do EC2. Os dados podem ser usados para realizar tarefas de configuração automatizadas em comum e até mesmo executar scripts na inicialização da instância. Para o Amazon ECS, os casos de uso mais comuns para dados de usuário devem transmitir informações de configuração para o daemon do Docker e o agente de contêiner do Amazon ECS. É possível transmitir vários tipos de dados de usuário para o Amazon EC2, inclusive boothooks de nuvem, scripts de shell e diretivas `cloud-init`. Para obter mais informações sobre esses e outros tipos de formato, consulte a documentação [Cloud-Init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html). É possível transmitir esses dados do usuário ao usar o assistente de inicialização do Amazon EC2. Para obter mais informações, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). ## Dados dos usuário do Windows padrão Este exemplo de script de dados do usuário mostra os dados do usuário padrão que as instâncias de contêiner do Windows receberão se você usar o console. O script abaixo faz o seguinte: + Define o nome do cluster para o nome que você inseriu. + Define as funções do IAM para tarefas. + Define `json-file` e `awslogs` como os drivers de registro em log disponíveis. Além disso, as seguintes opções estão disponíveis quando for usado o modo de rede `awsvpc`. + `EnableTaskENI`:este sinalizador ativa a rede de tarefas e é necessário quando é usado o modo de rede `awsvpc`. + `AwsvpcBlockIMDS`: este sinalizador opcional bloqueia o acesso IMDS para os contêineres de tarefas em execução no modo de rede `awsvpc`. + `AwsvpcAdditionalLocalRoutes`: este sinalizador opcional permite que você tenha rotas adicionais. Substitua `ip-address` pelo o endereço IP das rotas adicionais, por exemplo, 172.31.42.23/32. É possível usar esse script nas próprias instâncias de contêiner (desde que elas sejam iniciadas em AMIs Windows Server otimizadas para o Amazon ECS). Substitua a linha `-Cluster cluster-name` para especificar o nome do seu próprio cluster. ``` Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes '["ip-address"]' ``` 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 sintaxe a seguir. Substitua a linha `-Cluster cluster-name` para especificar o nome do seu próprio cluster. ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine") Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' ``` ## Dados do usuário da instalação do agente do Windows Este exemplo de script de dados do usuário instala o agente de contêiner do Amazon ECS em uma instância iniciada com uma AMI **Windows\$1Server-2016-English-Full-Containers**. Ele foi adaptado com base nas instruções de instalação do agente na página README [Repositório do GitHub do Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent). **nota** Esse script é compartilhado com finalidades de exemplo. É muito mais fácil começar a usar os contêineres do Windows usando a AMI do Windows Server otimizada para Amazon ECS. Para obter mais informações, consulte [Criar um cluster do Amazon ECS para workloads do Fargate](create-cluster-console-v2.md). Para obter informações sobre como instalar o agente do Amazon ECS no Windows Server 2022 Full, consulte o [problema 3753](https://github.com/aws/amazon-ecs-agent/issues/3753) no GitHub. É possível usar esse script para suas próprias instâncias de contêiner (desde que elas sejam executadas com uma versão da AMI **Windows\$1Server-2016-English-Full-Contêineres**). Não se esqueça de substituir a linha `windows` para especificar o nome de seu próprio cluster (caso não esteja usando um cluster chamado `windows`). ``` # Set up directories the agent uses New-Item -Type directory -Path ${env:ProgramFiles}\Amazon\ECS -Force New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS -Force New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS\data -Force # Set up configuration $ecsExeDir = "${env:ProgramFiles}\Amazon\ECS" [Environment]::SetEnvironmentVariable("ECS_CLUSTER", "windows", "Machine") [Environment]::SetEnvironmentVariable("ECS_LOGFILE", "${env:ProgramData}\Amazon\ECS\log\ecs-agent.log", "Machine") [Environment]::SetEnvironmentVariable("ECS_DATADIR", "${env:ProgramData}\Amazon\ECS\data", "Machine") # Download the agent $agentVersion = "latest" $agentZipUri = "https://s3.amazonaws.com/amazon-ecs-agent/ecs-agent-windows-$agentVersion.zip" $zipFile = "${env:TEMP}\ecs-agent.zip" Invoke-RestMethod -OutFile $zipFile -Uri $agentZipUri # Put the executables in the executable directory. Expand-Archive -Path $zipFile -DestinationPath $ecsExeDir -Force Set-Location ${ecsExeDir} # Set $EnableTaskIAMRoles to $true to enable task IAM roles # Note that enabling IAM roles will make port 80 unavailable for tasks. [bool]$EnableTaskIAMRoles = $false if (${EnableTaskIAMRoles}) { $HostSetupScript = Invoke-WebRequest https://raw.githubusercontent.com/aws/amazon-ecs-agent/master/misc/windows-deploy/hostsetup.ps1 Invoke-Expression $($HostSetupScript.Content) } # Install the agent service New-Service -Name "AmazonECS" ` -BinaryPathName "$ecsExeDir\amazon-ecs-agent.exe -windows-service" ` -DisplayName "Amazon ECS" ` -Description "Amazon ECS service runs the Amazon ECS agent" ` -DependsOn Docker ` -StartupType Manual sc.exe failure AmazonECS reset=300 actions=restart/5000/restart/30000/restart/60000 sc.exe failureflag AmazonECS 1 Start-Service AmazonECS ``` # Uso de um proxy HTTP para instâncias de contêiner do Windows no Amazon ECS É possível configurar as instâncias de contêiner do Amazon ECS para usar um proxy HTTP para o agente de contêiner do Amazon ECS e o daemon do Docker. Isso é útil se suas as instâncias de contêiner não têm acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. Para configurar sua instância de contêiner do Windows do Amazon ECS para usar um proxy HTTP, defina as variáveis a seguir no momento da inicialização (com dados de usuário do Amazon EC2). `[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.mydomain:port", "Machine")` Defina `HTTP_PROXY` como o nome do host (ou endereço IP) e o número de porta de um proxy HTTP a serem usados pelo agente do Amazon ECS para se conectar à Internet. Por exemplo, as instâncias de contêiner podem não ter acesso à rede externa através de um gateway da Internet da Amazon VPC, um gateway NAT ou uma instância. `[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")` Defina `NO_PROXY` como `169.254.169.254,169.254.170.2,\\.\pipe\docker_engine` para filtrar os metadados da instância do EC2, as funções do IAM para tarefas e o tráfego do daemon do Docker proveniente do proxy. **Example Script de dados do usuário do proxy HTTP do Windows** O exemplo de script PowerShell de dados de usuário abaixo configura o agente de contêiner do Amazon ECS e o daemon do Docker para usar um proxy HTTP especificado por você. Você também pode especificar um cluster no qual a instância de contêiner será registrada. Para usar esse script ao executar uma instância de contêiner, siga as etapas em [Iniciar uma instância de contêiner do Windows do Amazon ECS](launch_window-container_instance.md). Basta copiar e colar o script do PowerShell abaixo no campo **Dados do usuário** (substitua os valores de exemplo vermelhos pelas suas informações de proxy e cluster). A opção `-EnableTaskIAMRole` é necessária para habilitar funções do IAM para tarefas. 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). ``` Import-Module ECSTools $proxy = "http://proxy.mydomain:port" [Environment]::SetEnvironmentVariable("HTTP_PROXY", $proxy, "Machine") [Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine") Restart-Service Docker Initialize-ECSAgent -Cluster MyCluster -EnableTaskIAMRole ``` # Configuração de instâncias de contêiner do Windows no Amazon ECS para receber avisos de instância spot O Amazon EC2 encerra, interrompe ou coloca a instância spot em hibernação quando o preço spot excede o preço máximo da solicitação ou a capacidade não está mais disponível. O Amazon EC2 fornece um aviso de interrupção da instância spot, enviando à instância um aviso de dois minutos antes que ela seja interrompida. Se a drenagem da instância spot do Amazon ECS estiver habilitada na instância, o ECS receberá o aviso de interrupção da instância spot e colocará a instância no status `DRAINING`. **Importante** O Amazon ECS monitora os avisos de interrupção da instância spot que têm as ações de instância `terminate` e `stop`. Se você especificou o comportamento de interrupção `hibernate` da instância ao solicitar as instâncias spot ou a frota spot, a drenagem de instâncias spot do Amazon ECS não é compatível com essas instâncias. Quando uma instância de contêiner é definida como `DRAINING`, o Amazon ECS impede que novas tarefas sejam programadas para posicionamento na instância de contêiner. As tarefas de serviço nas instâncias de contêiner de drenagem que estão com o status de `PENDING` são interrompidas imediatamente. Se houver instâncias de contêiner no cluster disponíveis, as tarefas de serviço de substituição serão iniciadas nelas. É possível ativar a drenagem de instância spot ao iniciar uma instância. Você deve definir o parâmetro `ECS_ENABLE_SPOT_INSTANCE_DRAINING` antes de iniciar o agente de contêiner. Substitua *my-cluster* pelo nome do cluster. ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_SPOT_INSTANCE_DRAINING", "true", "Machine") # Initialize the agent Initialize-ECSAgent -Cluster my-cluster ``` Para obter mais informações, consulte [Iniciar uma instância de contêiner do Windows do Amazon ECS](launch_window-container_instance.md). # Clusters do Amazon ECS para instâncias externas O Amazon ECS Anywhere fornece suporte para registrar uma *Instância externa*, como um servidor on-premises ou uma máquina virtual (VM), no cluster do Amazon ECS. As instâncias externas são otimizadas para executar aplicações que geram tráfego de saída ou dados de processo. Se sua aplicação exigir tráfego de entrada, a falta de suporte do Elastic Load Balancing torna a execução dessas workloads menos eficiente. O Amazon ECS adicionou um novo tipo de inicialização `EXTERNAL` que você pode usar para criar serviços ou executar tarefas nas instâncias externas. ## Sistemas operacionais e arquiteturas de sistema compatíveis A seguir, apresentamos a lista de sistemas operacionais compatíveis. As arquiteturas de CPU `x86_64` e `ARM64` são compatíveis. + Amazon Linux 2023 + Ubuntu 20, Ubuntu 22, Ubuntu 24 + RHEL 9: é preciso garantir que o Docker esteja instalado antes da execução do [script de instalação do ECS Anywhere.](https://github.com/aws/amazon-ecs-agent/blob/master/scripts/ecs-anywhere-install.sh) Para obter mais informações, consulte [Install Docker Engine on RHEL](https://docs.docker.com/engine/install/rhel/) na documentação do Docker. A partir de 7 de agosto de 2026, o Amazon ECS Anywhere não será mais compatível com os seguintes sistemas operacionais: + Amazon Linux 2 + CentOS Stream 9 + RHEL 7, RHEL 8 + Fedora 32, Fedora 33, Fedora 40 + openSUSE Tumbleweed + Ubuntu 18 + Debian 9, Debian 10, Debian 11, Debian 12 + SUSE Enterprise Server 15 + Windows Server 2.022, Windows Server 2.019, Windows Server 2.016, Windows Server 20H2 ## Considerações Antes de começar a usar instâncias externas, esteja ciente das seguintes considerações. + É possível registrar uma instância externa em um cluster de cada vez. Para obter instruções sobre como registrar uma instância externa em um cluster diferente, consulte [Cancelamento do registro de uma instância externa do Amazon ECS](ecs-anywhere-deregistration.md). + As instâncias externas exigem uma função do IAM que permita que elas se comuniquem com APIs da AWS. Para obter mais informações, consulte [Perfil do IAM para o Amazon ECS Anywhere](iam-role-ecsanywhere.md). + As instâncias externas não devem ter uma cadeia de credenciais de instânciaa pré-configurada definida localmente, pois isso interferirá com o script de registro. + Para enviar logs de contêiner para o CloudWatch Logs, crie e especifique uma função do IAM de execução de tarefa na definição de tarefa. + Quando uma instância externa é registrada em um cluster, o atributo `ecs.capability.external` é associado à instância. Esse atributo identifica a instância como uma instância externa. É possível adicionar atributos personalizados às instâncias externas para usar como uma restrição de posicionamento de tarefas. Para obter mais informações, consulte [Atributos personalizados](task-placement-constraints.md#ecs-custom-attributes). + É possível adicionar etiquetas de recurso à instância externa. Para obter mais informações, consulte [Adicionar tags a instâncias de contêiner externas para o Amazon ECS](instance-details-tags-external.md). + Há suporte para o ECS Exec em instâncias externas. Para obter mais informações, consulte [Monitoramento de contêineres do Amazon ECS com o ECS Exec](ecs-exec.md). + Veja a seguir considerações adicionais que são específicas para as redes com instâncias externas. Para obter mais informações, consulte [Redes](#ecs-anywhere-networking). + O balanceamento de carga do serviço não é compatível. + A descoberta de serviço não é compatível. + Tarefas executadas em instâncias externas devem usar os modos de rede `bridge`, `host` ou `none`. O modo de rede `awsvpc` não é compatível. + Há domínios de serviço do Amazon ECS em cada região da AWS. Esses domínios de serviço devem ter permissão para enviar tráfego para as instâncias externas. + O SSM Agent instalado na instância externa mantém as credenciais do IAM que são alternadas a cada 30 minutos com o uso de uma impressão digital de hardware. Se a instância externa perder conexão com a AWS, o SSM Agent atualiza automaticamente as credenciais após a conexão ser restabelecida. Para obter mais informações, consulte [Validar servidores on-premises e máquinas virtuais usando uma impressão digital de hardware](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) no *Guia do usuário do AWS Systems Manager*. + Você pode executar tarefas do Linux em instâncias externas em uma configuração somente IPv6, desde que as instâncias estejam em sub-redes somente IPv6. Para obter mais informações, consulte [Usar uma VPC no modo somente IPv6](task-networking.md#networking-ipv6-only). + A API `UpdateContainerAgent` não é compatível. Para obter instruções sobre como atualizar o SSM Agent ou o agente do Amazon ECS nas instâncias externas, consulte [Atualização do agente do AWS Systems Manager e o agente de contêiner do Amazon ECS em uma instância externa](ecs-anywhere-updates.md). + Provedores de capacidade do Amazon ECS não são compatíveis. Para criar um serviço ou executar uma tarefa autônoma nas instâncias externas, use o tipo de inicialização `EXTERNAL`. + SELinux não é compatível. + Usar volumes do Amazon EFS ou especificar um `EFSVolumeConfiguration` não é compatível. + A integração com o App Mesh não é compatível. + Se você usar o console para criar uma definição de tarefa de instância externa, deverá criar a definição da tarefa com o editor JSON do console. + Ao usar uma AMI não otimizada para o Amazon ECS, execute os comandos a seguir na instância de contêiner externa para configurar regras para usar perfis do IAM em tarefas. Para obter mais informações, consulte [Configuração adicional para instância externa](task-iam-roles.md#enable_task_iam_roles). ``` $ sysctl -w net.ipv4.conf.all.route_localnet=1 $ iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679 $ iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679 ``` ### Redes As instâncias externas do Amazon ECS são otimizadas para executar aplicações que geram tráfego de saída ou dados de processo. Se sua aplicação exigir tráfego de entrada, como um serviço da Web, a falta de suporte do Elastic Load Balancing torna a execução dessas workloads menos eficiente porque não há suporte para colocar essas workloads atrás de um balanceador de carga. Veja a seguir considerações adicionais que são específicas para as redes com instâncias externas. + O balanceamento de carga do serviço não é compatível. + A descoberta de serviço não é compatível. + Tarefas do Linux executadas em instâncias externas devem usar os modos de rede `bridge`, `host` ou `none`. O modo de rede `awsvpc` não é compatível. Para obter mais informações sobre cada modo de rede, consulte [Opções de rede de tarefas do Amazon ECS para o EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). + Você pode executar tarefas do Linux em instâncias externas em uma configuração somente IPv6, desde que as instâncias estejam em sub-redes somente IPv6. Para obter mais informações, consulte [Usar uma VPC no modo somente IPv6](task-networking.md#networking-ipv6-only). + Há domínios de serviço do Amazon ECS em cada região e você deve ter permissão para enviar tráfego para as instâncias externas. + O SSM Agent instalado na instância externa mantém as credenciais do IAM que são alternadas a cada 30 minutos com o uso de uma impressão digital de hardware. Se a instância externa perder conexão com a AWS, o SSM Agent atualiza automaticamente as credenciais após a conexão ser restabelecida. Para obter mais informações, consulte [Validar servidores on-premises e máquinas virtuais usando uma impressão digital de hardware](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) no *Guia do usuário do AWS Systems Manager*. Os domínios a seguir são usados para comunicação entre o serviço do Amazon ECS e o agente do Amazon ECS instalado na instância externa. Certifique-se de que o tráfego seja permitido e que a resolução DNS funcione. Para cada endpoint, *região* representa o identificador da região da AWS com suporte do Amazon ECS, como `us-east-2`, para a região Leste dos EUA (Ohio). Os endpoints de todas as regiões que você usa devem ser permitidos. Para os endpoints `ecs-a` e `ecs-t`, você deve incluir um asterisco (por exemplo, `ecs-a-*`). + `ecs-a-*.region.amazonaws.com`: este endpoint é usado quando são gerenciadas tarefas. + `ecs-t-*.region.amazonaws.com`: este endpoint é usado para gerenciar métricas de tarefas e contêineres. + `ecs.region.amazonaws.com`: este é um endpoint de serviço do Amazon ECS. + `ssm.region.amazonaws.com ` — este é um endpoint de serviço para o AWS Systems Manager. + `ec2messages.region.amazonaws.com`: este é o endpoint de serviço que o AWS Systems Manager usa para se comunicar entre o agente Systems Manager e o serviço Systems Manager na nuvem. + `ssmmessages.region.amazonaws.com`: este é o endpoint de serviço necessário para criar e excluir canais de sessão com o serviço Session Manager na nuvem. + Se as tarefas requerem comunicação com quaisquer outros serviços da AWS, certifique-se de que esses endpoints sejam permitidos. Exemplos da aplicações incluem o uso do Amazon ECR para extrair imagens de contêiner ou o uso do CloudWatch para CloudWatch Logs. Para obter mais informações, consulte [Endpoints de serviço](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) na *Referência geral da AWS*. ### Amazon FSx for Windows File Server com ECS Anywhere **Importante** O suporte do Windows para o Amazon ECS Anywhere foi descontinuado. Esta seção não é mais aplicável. Para usar o Amazon FSx for Windows File Server com instâncias externas do Amazon ECS, você deve estabelecer uma conexão do entre seu data center on-premises e o Nuvem AWS. Para obter mais informações sobre as opções para conexão de sua rede a sua VPC, consulte [Opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). ### gMSA com ECS Anywhere **Importante** O suporte do Windows para o Amazon ECS Anywhere foi descontinuado. Esta seção não é mais aplicável. Os seguintes casos de uso eram compatíveis com o ECS Anywhere quando o Windows era um sistema operacional compatível. + O Active Directory está na Nuvem AWS: para essa configuração, você cria uma conexão da entre sua rede on-premises e a Nuvem AWS usando uma conexão AWS Direct Connect. Para obter informações sobre como criar a conexão, consulte [Opções de conectividade da Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Você cria um Active Directory na Nuvem AWS. Para obter informações sobre como começar a usar o AWS Directory Service, consulte [Configuração do AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setting_up.html) no *Guia de administração do AWS Directory Service*. Em seguida, você pode associar suas instâncias externas ao domínio usando a conexão AWS Direct Connect. Para obter informações sobre como trabalhar com o gMSA com o Amazon ECS, consulte [Saiba como usar gMSAs para contêineres do Windows do Amazon EC2 para o Amazon ECS](windows-gmsa.md). + O Active Directory está no data center on-premises. - Para essa configuração, você une suas instâncias externas ao Active Directory on-premises. Em seguida, você usa as credenciais disponíveis localmente ao executar as tarefas do Amazon ECS. # Criar um cluster do Amazon ECS para workloads de instâncias externas Crie um cluster para definir a infraestrutura na qual suas tarefas e serviços são executados. Antes de começar, é necessário concluir as etapas em [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md) e atribuir a permissão adequada do IAM. Para obter mais informações, consulte [Exemplos de clusters do Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). O console do Amazon ECS fornece uma maneira simples de criar os recursos necessários para um cluster do Amazon ECS criando uma pilha do CloudFormation. Para tornar o processo de criação do cluster o mais fácil possível, o console tem seleções padrão para muitas opções, que descrevemos abaixo. Também há painéis de ajuda disponíveis para a maioria das seções do console, que fornecem mais contexto. É possível modificar as opções a seguir: + Adicione um namespace ao cluster. Um namespace permite que os serviços que você cria no cluster possam se conectar a outros serviços no namespace sem configuração adicional. Para obter mais informações, consulte [Interconexão de serviços do Amazon ECS](interconnecting-services.md). + Configurar o cluster para instâncias externas + Atribua uma chave do AWS KMS ao seu armazenamento gerenciado. Para obter informações sobre como criar uma chave, consulte [Criar uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do usuário do AWS Key Management Service*. + Adicione tags para ajudar a identificar seu cluster. **Para criar um novo cluster (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 de cluster**, configure o seguinte: + Em **Nome do cluster**, insira um nome exclusivo. O nome pode conter até 255 letras (minúsculas e maiúsculas), números e hifens. + (Opcional) Para que o namespace usado para o Service Connect seja diferente do nome do cluster, em **Namespace**, insira um nome exclusivo. 1. (Opcional) Utilize o Container Insights, expanda **Monitoramento** e escolha uma destas opções: + Para usar o Container Insights com observabilidade aprimorada (recomendado), escolha **Container Insights com observabilidade aprimorada**. + Para usar o Container Insights, escolha **Container Insights**. 1. (Opcional) Para usar o ECS Exec para depurar tarefas no cluster, expanda **Configuração de solução de problemas** e, em seguida, configure o seguinte: + Selecione **Ativar o ECS Exec**. + (Opcional) Em **Chave do AWS KMS para ECS Exec**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados da sessão do ECS Exec. + (Opcional) Para **Registro em log do ECS Exec**, escolha o destino do log: + Para enviar logs para o CloudWatch Logs, escolha **Amazon CloudWatch**. + Para enviar logs para o Amazon S3, escolha **Amazon S3**. + Para desativar o registro em log, escolha **Nenhum**. 1. (Opcional) Criptografe os dados no armazenamento gerenciado. Em **Criptografia**, em **Armazenamento gerenciado**, insira o ARN da chave do AWS KMS que você deseja usar para criptografar os dados do armazenamento gerenciado. 1. (Opcional) Para ajudar a identificar seu cluster, expanda **Tags** (Etiquetas) e configure suas etiquetas. [Adicionar uma tag] Selecione **Add tag** (Adicionar tag) e faça o seguinte: + Em **Key (Chave)**, insira o nome da chave. + Em **Valor** insira o valor da chave. 1. Selecione **Create** (Criar). ## Próximas etapas Você deve registrar as instâncias no cluster. Para obter mais informações, consulte [Registro de uma instância externa para um cluster do Amazon ECS](ecs-anywhere-registration.md). Crie uma definição de tarefa para o tipo de execução externa. Para obter mais informações, consulte . [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md) Execute suas aplicações como tarefas autônomas ou como parte de um serviço. Para saber mais, 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) # Registro de uma instância externa para um cluster do Amazon ECS Cada instância externa registrada em um cluster do Amazon ECS deve ter o SSM Agent, o agente de contêiner do Amazon ECS e o Docker instalados. Para registrar a instância externa em um cluster do Amazon ECS, ela deve primeiro ser registrada como uma instância gerenciada do AWS Systems Manager. É possível criar o script de instalação com alguns cliques no console do Amazon ECS. O script de instalação inclui uma chave de ativação do Systems Manager e comandos para instalar cada um dos agentes necessários e o Docker. O script de instalação deve ser executado no servidor on-premises ou na VM para concluir as etapas de instalação e registro. **nota** Antes de registrar sua instância externa do Linux com o cluster, crie o arquivo `/etc/ecs/ecs.config` na instância externa e adicione todos os parâmetros de configuração do agente de contêiner desejados. Isso não pode ser feito depois do registro da instância externa em um cluster. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). ------ #### [ Console de gerenciamento da AWS ] 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 o cluster no qual a instância externa será registrada. 1. Na página **Cluster : *name***, escolha a guia **Infrastructure** (Infraestrutura). 1. Na página **Register external instances** (Registrar instâncias externas), execute as etapas a seguir. 1. Em **Activation key duration (in days)** (Duração da chave de ativação (em dias)), insira o número de dias durante os quais a chave de ativação permanece ativa. Depois da decorrência número de dias que você inseriu, a chave não funcionará mais ao ser registrada uma instância externa. 1. Em **Number of instances** (Número de instâncias), insira o número de instâncias externas que você quer registrar no cluster com a chave de ativação. 1. Em **Instance role** (Função da instância), escolha a função do IAM a ser associada às instâncias externas. Se uma função ainda não tiver sido criada, escolha **Create new role** (Criar nova função) para que o Amazon ECS crie uma função em seu nome. Para obter mais informações sobre quais permissões do IAM são necessárias para instâncias externas, consulte [Perfil do IAM para o Amazon ECS Anywhere](iam-role-ecsanywhere.md). 1. Copie o comando de registro. Esse comando deve ser executado em cada instância externa que você quer registrar no cluster. **Importante** A parte bash do script deve ser executada como raiz. Se o comando não for executado como root, será retornado um erro. 1. Escolha **Fechar**. ------ #### [ AWS CLI for Linux operating systems ] 1. Crie um par de ativação do Systems Manager. Isso é usado para a ativação de instâncias gerenciadas do Systems Manager. A saída inclui um `ActivationId` e um `ActivationCode`. Eles serão usados em uma etapa posterior. Especifique a função do IAM do ECS Anywhere que você criou. Para obter mais informações, consulte [Perfil do IAM para o Amazon ECS Anywhere](iam-role-ecsanywhere.md). ``` aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json ``` 1. No servidor on-premises ou na máquina virtual (VM), baixe o script de instalação. ``` curl --proto "https" -o "/tmp/ecs-anywhere-install.sh" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh" ``` 1. (Opcional) No servidor on-premises ou na máquina virtual (VM), use as etapas a seguir para verificar o script de instalação usando o arquivo de assinatura de script. 1. Baixe e instale GnuPG. Para obter mais informações sobre a GNUpg, consulte o [site da GnuPG](https://www.gnupg.org). Para sistemas Linux, instale `gpg` usando o gerenciador de pacotes no seu tipo de Linux. 1. Recuperar a chave pública PGP do Amazon ECS. ``` gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F ``` 1. Baixe a assinatura do script de instalação. Ela consiste em uma assinatura PGP desvinculada ascii armazenada em um arquivo com a extensão `.asc`. ``` curl --proto "https" -o "/tmp/ecs-anywhere-install.sh.asc" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh.asc" ``` 1. Verifique o arquivo de script de instalação usando a chave. ``` gpg --verify /tmp/ecs-anywhere-install.sh.asc /tmp/ecs-anywhere-install.sh ``` A saída esperada é mostrada a seguir. ``` gpg: Signature made Tue 25 May 2021 07:16:29 PM UTC gpg: using RSA key 50DECCC4710E61AF gpg: Good signature from "Amazon ECS " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF ``` 1. No servidor on-premises ou na máquina virtual (VM), execute o script de instalação. Especifique o nome do cluster, a região e o ID de ativação do Systems Manager e o código de ativação a partir da primeira etapa. ``` sudo bash /tmp/ecs-anywhere-install.sh \ --region $REGION \ --cluster $CLUSTER_NAME \ --activation-id $ACTIVATION_ID \ --activation-code $ACTIVATION_CODE ``` Para um servidor on-premises ou máquina virtual (VM) que tenha o driver NVIDIA instalado para workloads de GPU, você deve adicionar o sinalizador `--enable-gpu` ao script de instalação. Quando esse sinalizador é especificado, o script de instalação verifica se o driver NVIDIA está sendo executado e, em seguida, adiciona as variáveis de configuração necessárias para executar suas tarefas do Amazon ECS. Para obter mais informações sobre como executar workloads de GPU e especificar requisitos de GPU em uma definição de tarefa, consulte [Especificar GPUs em uma definição de tarefa do Amazon ECS](ecs-gpu-specifying.md). ``` sudo bash /tmp/ecs-anywhere-install.sh \ --region $REGION \ --cluster $CLUSTER_NAME \ --activation-id $ACTIVATION_ID \ --activation-code $ACTIVATION_CODE \ --enable-gpu ``` Use as etapas a seguir para registrar uma instância externa existente em um cluster diferente. **Para registrar uma instância externa existente em um cluster diferente** 1. Interrompa o agente de contêiner do Amazon ECS. ``` sudo systemctl stop ecs.service ``` 1. Edite o arquivo `/etc/ecs/ecs.config` e, na linha `ECS_CLUSTER`, verifique se o nome do cluster corresponde ao nome do cluster no qual a instância externa será registrada. 1. Remova os dados do agente do Amazon ECS existente. ``` sudo rm /var/lib/ecs/data/agent.db ``` 1. Inicie o agente de contêiner do Amazon ECS. ``` sudo systemctl start ecs.service ``` ------ #### [ AWS CLI for Windows operating systems ] 1. Crie um par de ativação do Systems Manager. Isso é usado para a ativação de instâncias gerenciadas do Systems Manager. A saída inclui um `ActivationId` e um `ActivationCode`. Eles serão usados em uma etapa posterior. Especifique a função do IAM do ECS Anywhere que você criou. Para obter mais informações, consulte [Perfil do IAM para o Amazon ECS Anywhere](iam-role-ecsanywhere.md). ``` aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json ``` 1. No servidor on-premises ou na máquina virtual (VM), baixe o script de instalação. ``` Invoke-RestMethod -URI "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.ps1" -OutFile “ecs-anywhere-install.ps1” ``` 1. (Opcional) O script do PowerShell é assinado pela Amazon e, portanto, o Windows executa automaticamente a validação do certificado no mesmo. Não há necessidade de realizar nenhuma validação manual. Para verificar manualmente o certificado, clique com o botão direito do mouse no arquivo, navegue até propriedades e use a guia Digital Signatures (Assinaturas digitais) para obter mais detalhes. Essa opção só está disponível quando o host tiver o certificado no armazenamento de certificados. Essa verificação deve retornar informações semelhante às seguintes: ``` # Verification (PowerShell) Get-AuthenticodeSignature -FilePath .\ecs-anywhere-install.ps1 SignerCertificate Status Path ----------------- ------ ---- EXAMPLECERTIFICATE Valid ecs-anywhere-install.ps1 ... Subject : CN="Amazon Web Services, Inc.",... ---- ``` 1. No servidor on-premises ou na máquina virtual (VM), execute o script de instalação. Especifique o nome do cluster, a região e o ID de ativação do Systems Manager e o código de ativação a partir da primeira etapa. ``` .\ecs-anywhere-install.ps1 -Region $Region -Cluster $Cluster -ActivationID $ActivationID -ActivationCode $ActivationCode ``` 1. Verifique se o agente de contêiner do Amazon ECS está em execução. ``` Get-Service AmazonECS Status Name DisplayName ------ ---- ----------- Running AmazonECS Amazon ECS ``` Use as etapas a seguir para registrar uma instância externa existente em um cluster diferente. **Para registrar uma instância externa existente em um cluster diferente** 1. Interrompa o agente de contêiner do Amazon ECS. ``` Stop-Service AmazonECS ``` 1. Modifique o parâmetro `ECS_CLUSTER` para que o nome do cluster corresponda ao nome do cluster no qual a instância externa será registrada. ``` [Environment]::SetEnvironmentVariable("ECS_CLUSTER", $ECSCluster, [System.EnvironmentVariableTarget]::Machine) ``` 1. Remova os dados do agente do Amazon ECS existente. ``` Remove-Item -Recurse -Force $env:ProgramData\Amazon\ECS\data\* ``` 1. Inicie o agente de contêiner do Amazon ECS. ``` Start-Service AmazonECS ``` ------ A AWS CLI pode ser usada para criar uma ativação do Systems Manager antes da execução do script de instalação para a conclusão do processo de registro da instância externa. # Cancelamento do registro de uma instância externa do Amazon ECS Recomendamos que você cancele o registro da instância no Amazon ECS e no AWS Systems Manager quando concluir o uso de uma instância externa. Depois do cancelamento do registro, a instância externa não poderá mais aceitar novas tarefas. Se você tiver tarefas em execução na instância de contêiner quando cancelar o registro, estas tarefas permanecerão em execução até serem interrompidas por outros meios. Contudo, essas tarefas não serão mais monitoradas ou gerenciadas pelo Amazon ECS. Se essas tarefas da instância externa fizerem parte de um serviço do Amazon ECS, o programador de serviços iniciará uma nova cópia das tarefas em uma instância diferente, se possível. Após cancelar o registro da instância, limpe os recursos da AWS restantes na instância. Depois, você pode registrá-la em um novo cluster. ## Procedimento ------ #### [ Console de gerenciamento da AWS ] 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, escolha a região em que sua instância externa está registrada. 1. No painel de navegação, escolha **Clusters** e selecione o cluster que hospeda a instância externa. 1. Na página **Cluster : *name***, escolha a guia **Infrastructure** (Infraestrutura). 1. Em **Container instances** (Instâncias de contêiner), selecione o ID da instância externa para cancelar o registro. Você será redirecionado para a página de detalhes da instância do contêiner. 1. Na página **Container Instance : *id***, escolha **Deregister**. 1. Revise a mensagem de cancelamento do registro. Selecione **Cancelar o registro no AWS Systems Manager** para também cancelar o registro da instância externa como uma instância gerenciada no Systems Manager. Escolha **Cancelar registro**. **nota** É possível cancelar o registro da instância externa como uma instância gerenciada do Systems Manager no console do Systems Manager. Para obter instruções, consulte [Cancelar o registro de nós gerenciados em um ambiente híbrido e multinuvem](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-deregister-hybrid-nodes.html) no *Guia do usuário do AWS Systems Manager*. 1. Após cancelar o registro da instância, limpe os recursos da AWS no servidor on-premises ou na VM. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html) ------ #### [ AWS CLI ] 1. Você precisa do ID da instância e do ARN da instância de contêiner para cancelar o registro da instância de contêiner. Se você não tiver esses valores, execute os comandos a seguir Execute o comando a seguir para obter o ID da instância. Você usa o ID da instância (`instanceID`) para obter o ARN (`containerInstanceARN`) da instância de contêiner. ``` instanceId=$(aws ssm describe-instance-information --region "{{ region }}" | jq ".InstanceInformationList[] |select(.IPAddress==\"{{ IPv4 Address }}\") | .InstanceId" | tr -d'"' ``` Execute os seguintes comandos. Você usa o `containerInstanceArn` como parâmetro no comando para cancelar o registro da instância (`deregister-container-instance`). ``` instances=$(aws ecs list-container-instances --cluster "{{ cluster }}" --region "{{ region }}" | jq -c '.containerInstanceArns') containerInstanceArn=$(aws ecs describe-container-instances --cluster "{{ cluster }}" --region "{{ region }}" --container-instances $instances | jq ".containerInstances[] | select(.ec2InstanceId==\"{{ instanceId }}\") | .containerInstanceArn" | tr -d '"') ``` 1. Execute o comando a seguir para drenar a instância. ``` aws ecs update-container-instances-state --cluster "{{ cluster }}" --region "{{ region }}" --container-instances "{{ containerInstanceArn }}" --status DRAINING ``` 1. Depois que a instância de contêiner terminar de ser drenada, execute o comando a seguir para cancelar o registro da instância. ``` aws ecs deregister-container-instance --cluster "{{ cluster }}" --region "{{ region }}" --container-instance "{{ containerInstanceArn }}" ``` 1. Execute o comando a seguir para remover instâncias de contêiner do SSM. ``` aws ssm deregister-managed-instance --region "{{ region }}" --instance-id "{{ instanceId }}" ``` 1. Após cancelar o registro da instância, limpe os recursos da AWS no servidor on-premises ou na VM. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html) ------ # Atualização do agente do AWS Systems Manager e o agente de contêiner do Amazon ECS em uma instância externa O servidor on-premises ou a VM deve executar o agente do AWS Systems Manager (SSM Agent) e o agente de contêiner do Amazon ECS ao executar workloads do Amazon ECS. A AWS lança novas versões desses agentes quando qualquer recurso é adicionado ou atualizado. Se as instâncias externas estiverem usando uma versão anterior de qualquer agente, será possível atualizá-las usando os procedimentos a seguir. ## Atualizar o SSM Agent em uma instância externa O AWS Systems Manager recomenda que você automatize o processo de atualização do SSM Agent nas instâncias. São fornecidos vários métodos para automatizar as atualizações. Para obter mais informações, consulte [Automatizar atualizações no SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html) no *Guia do usuário do AWS Systems Manager*. ## Atualizar o agente do Amazon ECS em uma instância externa Nas instâncias externas, o agente de contêiner do Amazon ECS é atualizado por meio do upgrade do pacote `ecs-init`. A atualização do agente de contêiner do Amazon ECS não interrompe a execução de tarefas ou serviços. O Amazon ECS fornece o pacote `ecs-init` e o arquivo de assinatura em um bucket do Amazon S3 em cada região. Começando com a versão `1.52.1-1` do código `ecs-init`, o Amazon ECS fornece pacotes `ecs-init` separados que dependem do sistema operacional e da arquitetura de sistema que a instância externa usa. Use a tabela a seguir para determinar o pacote `ecs-init` que você deve baixar com base no sistema operacional e na arquitetura de sistema que a instância externa usa. **nota** É possível determinar o sistema operacional e a arquitetura de sistema que a instância externa usa por meio dos comandos a seguir. ``` cat /etc/os-release uname -m ``` | Sistemas operacionais (arquitetura) | Pacote ecs-init | | --- | --- | | CentOS 7 (x86\$164) CentOS 8 (x86\$164) CentOS Stream 9 (x86\$164) SUSE Enterprise Server 15 (x86\$164) RHEL 7 (x86\$164) RHEL 8 (x86\$164) | `amazon-ecs-init-latest.x86_64.rpm` | | CentOS 7 (aarch64) CentOS 8 (aarch64) CentOS Stream 9 (aarch64) RHEL 7 (aarch64) | `amazon-ecs-init-latest.aarch64.rpm` | | Debian 9 (x86\$164) Debian 10 (x86\$164) Debian 11 (x86\$164) Debian 12 (x86\$164) Ubuntu 18 (x86\$164) Ubuntu 20 (x86\$164) Ubuntu 22 (x86\$164) Ubuntu 24 (x86\$164) | `amazon-ecs-init-latest.amd64.deb` | | Debian 9 (aarch64) Debian 10 (aarch64) Debian 11 (aarch64) Debian 12 (aarch64) Ubuntu 18 (aarch64) Ubuntu 20 (aarch64) Ubuntu 22 (aarch64) Ubuntu 24 (aarch64) | `amazon-ecs-init-latest.arm64.deb` | Siga estas etapas para atualizar o agente do Amazon ECS. **Para atualizar o agente do Amazon ECS** 1. Confirme a versão do agente do Amazon ECS que você está executando. ``` curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool ``` 1. Baixe o pacote `ecs-init` para seu sistema operacional e arquitetura de sistema. O Amazon ECS fornece o arquivo de pacote `ecs-init` em um bucket do Amazon S3 em cada região. Substitua o identificador ** no comando pelo nome da região (por exemplo, `us-west-2`) mais próxima de você geograficamente. **amazon-ecs-init-latest.x86\$164.rpm** ``` curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm ``` **amazon-ecs-init-latest.aarch64.rpm** ``` curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm ``` **amazon-ecs-init-latest.amd64.deb** ``` curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb ``` **amazon-ecs-init-latest.arm64.deb** ``` curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb ``` 1. (Opcional) Verifique a validade do arquivo de pacote `ecs-init` usando a assinatura PGP. 1. Baixe e instale GnuPG. Para obter mais informações sobre a GNUpg, consulte o [site da GnuPG](https://www.gnupg.org). Para sistemas Linux, instale `gpg` usando o gerenciador de pacotes no seu tipo de Linux. 1. Recuperar a chave pública PGP do Amazon ECS. ``` gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F ``` 1. Baixe a assinatura do pacote `ecs-init`. Ela consiste em uma assinatura PGP desvinculada ASCII armazenada em um arquivo com a extensão `.asc`. O Amazon ECS fornece o arquivo de assinatura em um bucket do Amazon S3 em cada região. Substitua o identificador ** no comando pelo nome da região (por exemplo, `us-west-2`) mais próxima de você geograficamente. **amazon-ecs-init-latest.x86\$164.rpm** ``` curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm.asc ``` **amazon-ecs-init-latest.aarch64.rpm** ``` curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm.asc ``` **amazon-ecs-init-latest.amd64.deb** ``` curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb.asc ``` **amazon-ecs-init-latest.arm64.deb** ``` curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb.asc ``` 1. Verifique o arquivo de pacote `ecs-init` usando a chave. **Para os pacotes `rpm`** ``` gpg --verify amazon-ecs-init.rpm.asc ./amazon-ecs-init.rpm ``` **Para os pacotes `deb`** ``` gpg --verify amazon-ecs-init.deb.asc ./amazon-ecs-init.deb ``` A saída esperada é mostrada a seguir. ``` gpg: Signature made Fri 14 May 2021 09:31:36 PM UTC gpg: using RSA key 50DECCC4710E61AF gpg: Good signature from "Amazon ECS " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF ``` 1. Instale o pacote `ecs-init`. **Para o pacote `rpm` no CentOS 7, CentOS 8 e RHEL 7** ``` sudo yum install -y ./amazon-ecs-init.rpm ``` **Para o pacote `rpm` no SUSE Enterprise Server 15** ``` sudo zypper install -y --allow-unsigned-rpm ./amazon-ecs-init.rpm ``` **Para o pacotes `deb`** ``` sudo dpkg -i ./amazon-ecs-init.deb ``` 1. Reinicie o serviço `ecs`. ``` sudo systemctl restart ecs ``` 1. Verifique se a versão do agente do Amazon ECS foi atualizada. ``` curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool ``` # Atualização de um cluster do Amazon ECS É possível modificar o as propriedades do cluster a seguir: + Definir um provedor de capacidade padrão Cada cluster pode ter um ou mais provedores de capacidade e uma estratégia opcional de provedor de capacidade. A estratégia de provedor de capacidade determina como as tarefas são distribuídas entre os provedores de capacidade do cluster. Ao executar uma tarefa autônoma ou criar um serviço, você pode usar a estratégia padrão de provedor de capacidade do cluster ou uma estratégia de provedor de capacidade que substitua a estratégia padrão. + Ative o Container Insights. O CloudWatch Container Insights coleta, agrega e resume métricas e logs das suas aplicações e microsserviços conteinerizados. O Container Insights também fornece informações de diagnóstico, como falhas de reinicialização de contêiner, que você usa para isolar problemas e resolvê-los rapidamente. Para obter mais informações, consulte [Monitorar contêineres do Amazon ECS utilizando o Container Insights com observabilidade aprimorada](cloudwatch-container-insights.md). + Adicione tags para ajudar a identificar seus clusters. **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 **Clusters**. 1. Na página **Clusters**, escolha o cluster. 1. Na página **Cluster : *nome***, escolha **Atualizar cluster**. 1. Para definir o provedor de capacidade padrão, em **Estratégia do provedor de capacidade padrão**, escolha **Adicionar mais**. 1. Em **Provedor de capacidade**, escolha o provedor de capacidade. 1. (Opcional) Em **Base**, insira o número mínimo de tarefas que serão executadas no provedor de capacidade. Você só pode definir um valor **Base** para um provedor de capacidade. 1. (Opcional) Em **Peso**, insira o percentual relativo do número total de tarefas executadas que usem o provedor de capacidade especificado. 1. (Opcional) Repita as etapas para qualquer provedor de capacidade adicional. 1. Para ativar ou desativar o Container Insights, expanda **Monitoramento** e, em seguida, ative **Usar o Conteiner Insights**. 1. Para ajudar a identificar seu cluster, expanda **Tags** e configure suas tags. [Adicionar uma tag] Selecione **Add tag** (Adicionar tag) e faça o seguinte: + Em **Key (Chave)**, insira o nome da chave. + Em **Value (Valor)**, insira o valor da chave. [Remover uma tag] Escolha **Remover** à direita da chave e do valor da tag. 1. Selecione **Atualizar**. # Exclusão de um cluster do Amazon ECS Se você terminou de usar um cluster, poderá excluí-lo. Depois de excluir o cluster, ele faz a transição para o estado `INACTIVE`. Os clusters com um status `INACTIVE` podem permanecer detectáveis em sua conta por um período. No entanto, esse comportamento está sujeito a alterações no futuro, então você não deve confiar na persistência de clusters `INACTIVE`. Antes de excluir um cluster, você deve executar as seguintes operações: + Exclua todos os serviços no cluster. Para obter mais informações, consulte [Exclusão de um serviço do Amazon ECS usando o console](delete-service-v2.md). + Interrompa todas as tarefas em execução no momento. Para obter mais informações, consulte [Interrupção de uma tarefa do Amazon ECS](standalone-task-stop.md). + Cancele o registro de todas as instâncias de contêiner registradas no cluster. Para obter mais informações, consulte [Cancelamento do registro de uma instância de contêiner do Amazon ECS](deregister_container_instance.md). + Excluir o namespace de . Para obter mais informações, consulte [Deleting namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map*. **Procedimento** 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**, selecione o cluster a ser excluído. 1. Na parte superior direita da página, escolha **Delete Cluster** (Excluir cluster). Uma mensagem é exibida quando você não excluiu todos os recursos associados ao cluster. 1. Na caixa de confirmação, insira **delete *nome do cluster***. # Cancelamento do registro de uma instância de contêiner do Amazon ECS **Importante** Este tópico abrange apenas instâncias de contêiner criadas no Amazon EC2. Para obter mais informações sobre como cancelar o registro de instâncias externas, consulte [Cancelamento do registro de uma instância externa do Amazon ECS](ecs-anywhere-deregistration.md). Quando você concluir uma instância de contêiner baseada no Amazon EC2, deverá cancelar o registro dela no cluster. Depois do cancelamento do registro, a instância de contêiner poderá mais aceitar novas tarefas. Se você tiver tarefas em execução na instância de contêiner quando cancelar o registro, essas tarefas permanecerão em execução até que você conclua a instância ou até que as tarefas sejam interrompidas por outros meios. Contudo, essas tarefas são órfãs, o que significa que elas não são mais monitoradas ou gerenciadas pelo Amazon ECS. Se uma tarefa órfã na instância de contêiner fizer parte de um serviço do Amazon ECS, o programador de serviços iniciará uma nova cópia desta tarefa em uma instância de contêiner diferente, se possível. Todos os contêineres em tarefas de serviço órfãs registradas em um grupo de destino do Application Load Balancer terão seu registro cancelado. Eles começarão a drenagem da conexão de acordo com as definições do load balancer ou do grupo de destino. Se uma tarefa órfã estiver usando o modo de rede `awsvpc`, as interfaces de rede elásticas serão excluídas. Se você pretende usar a instância de contêiner para qualquer outro propósito depois do cancelamento de registro, você deve interromper todas as tarefas em execução na instância de contêiner antes do cancelamento. Isso impede que as tarefas órfãs consumam recursos. Ao cancelar o registro de uma instância de contêiner do, esteja ciente das seguintes considerações. + Como cada instância de contêiner tem informações de estado exclusivas, o registro delas não deve ser cancelado de um cluster e realizado novamente em outro. Para relocar recursos de instância de contêiner, recomendamos que você encerre as instâncias de contêiner de um cluster e inicie novas instâncias de contêiner no novo cluster. Para obter mais informações, consulte [Encerrar a instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) no *Manual do usuário do Amazon EC2* e em [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). + Se a instância de contêiner for gerenciada por um grupo do Auto Scaling ou uma pilha do CloudFormation, encerre a instância atualizando o grupo do Auto Scaling ou a pilha do CloudFormation. Caso contrário, o grupo do Auto Scaling ou o CloudFormation criará uma nova instância depois que você a encerrar. + Se você encerra uma instância de contêiner em execução com um agente de contêiner do Amazon ECS conectado, o agente automaticamente cancela o registro da instância no cluster. O registro de instâncias de contêiner interrompidas ou instâncias com agentes desconectados não é automaticamente cancelado quando concluído. + O cancelamento de registro de uma instância de contêiner remove a instância de um cluster, mas não encerra a instância do Amazon EC2. Se você tiver terminado de usar a instância, certifique-se de encerrá-la também para interromper o faturamento. Para obter mais informações, consulte [Terminar sua instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) no *Guia do usuário do Amazon EC2*. ## Procedimento 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, escolha a região em que sua instância externa está registrada. 1. No painel de navegação, escolha **Clusters** e selecione o cluster que hospeda a instância. 1. Na página **Cluster : *name***, escolha a guia **Infrastructure** (Infraestrutura). 1. Em **Container instances** (Instâncias de contêiner), selecione o ID da instância para cancelar o registro. Você será redirecionado para a página de detalhes da instância do contêiner. 1. Na página **Container Instance : *id***, escolha **Deregister**. 1. Na tela de confirmação, escolha **Cancelar registro**. 1. Se você tiver terminado de trabalhar com a instância de contêiner, encerre a instância subjacente do Amazon EC2. Para obter mais informações, consulte [Encerrar a instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) no *Manual do usuário do Amazon EC2*. # Drenagem de instâncias de contêiner do Amazon ECS Poderá haver momentos em que você precisará remover uma instância de contêiner do cluster, por exemplo, para executar atualizações do sistema ou para reduzir a escala verticalmente da capacidade do cluster. O Amazon ECS fornece a capacidade de fazer a transição de uma instância de contêiner para um status `DRAINING`. Esse recurso é denominado *drenagem de instância de contêiner*. Quando uma instância de contêiner é definida como `DRAINING`, o Amazon ECS impede que novas tarefas sejam programadas para posicionamento na instância de contêiner. ## Comportamento de drenagem para serviços Todas as tarefas que fazem parte de um serviço e que estão no estado `PENDING` são interrompidas de imediato. Se houver capacidade de instância de contêiner disponível no cluster, o programador de serviços iniciará as tarefas de substituição. Se não houver capacidade suficiente de instância de contêiner, será enviada uma mensagem de evento de serviço indicando o problema. Tarefas que fazem parte de um serviço na instância de contêiner e que estão no estado `RUNNING` são transferidas para o estado `STOPPED`. O programador de serviços tenta substituir as tarefas de acordo com os parâmetros de tipo de implantação e de configuração de implantação do serviço, `minimumHealthyPercent` e `maximumPercent`. Para obter mais informações, consulte [Serviços do Amazon ECS](ecs_services.md) e [Parâmetros de definição de serviço do Amazon ECS](service_definition_parameters.md). + Se `minimumHealthyPercent` estiver abaixo de 100%, o programador pode ignorar `desiredCount` temporariamente durante a substituição de tarefas. Por exemplo, se `desiredCount` for quatro tarefas, um mínimo de 50% permitem que o programador interrompa duas tarefas existentes antes de iniciar duas novas tarefas. Se o mínimo é 100%, a programador de serviço não pode remover tarefas existentes até que as tarefas de substituição sejam consideradas saudáveis. Se as tarefas para serviços que não usam um load balancer estiverem com o status de `RUNNING`, elas serão consideradas saudáveis. As tarefas para serviços que usam um load balancer são consideradas saudáveis se estiverem com o status de `RUNNING` e se a instância de contêiner que as hospedam são relatadas como saudáveis pelo load balancer. **Importante** Se você usar Instâncias Spot e a `minimumHealthyPercent` for maior ou igual a 100%, o serviço não terá tempo suficiente para substituir a tarefa antes que a instância spot seja encerrada. + O parâmetro `maximumPercent` representa um limite maior no número de tarefas em execução durante a substituição de tarefas, o que permite que você defina o tamanho do lote de substituição. Por exemplo, se `desiredCount` for quatro tarefas, um máximo de 200% inicia quatro novas tarefas antes que elas sejam drenadas (considerando que os recursos de cluster necessários fazer isso estejam disponíveis). Se o máximo for 100%, as tarefas de substituição não podem começar até que tarefas de drenagem sejam interrompidas. **Importante** Se tanto `minimumHealthyPercent` quanto `maximumPercent` estiverem em 100%, então o serviço não pode remover tarefas existentes e também não pode iniciar tarefas de substituição. Isso evita a drenagem com êxito da instância de contêiner e evita a realização de novas implantações. ## Comportamento de drenagem para tarefas autônomas Quaisquer tarefas autônomas no estado `PENDING` ou `RUNNING` não são afetadas. Você deve esperar até que eles sejam interrompidas por conta própria ou interrompa-as manualmente. A instância de contêiner permanecerá no status `DRAINING`. ## Comportamento da drenagem de instâncias gerenciadas do Amazon ECS. O encerramento de instâncias gerenciadas do Amazon ECS garante transições de workload perfeitas, ao mesmo tempo em que otimiza os custos e mantem a integridade do sistema. O sistema de encerramento fornece três caminhos de decisão distintos para encerramento de instâncias, cada um com diferentes características de tempo e perfis de impacto no cliente. Encerramento iniciado pelo cliente Fornece controle direto sobre a remoção de instâncias quando você precisa remover imediatamente as instâncias de contêiner do serviço. Você executa `deregister-container-instance` com o parâmetro de solicitação `force` definido como “true”. Isso significa que é necessário um encerramento imediato, apesar de qualquer workload em execução. Encerramento por inatividade iniciado pelo sistema As instâncias gerenciadas do Amazon ECS monitoram continuamente e otimizam os custos de maneira proativa, encerrando instâncias de contêineres inativas do Amazon ECS que não estão executando tarefas. O ECS utiliza um atraso heurístico para dar às instâncias de contêiner a chance de adquirir tarefas recém-lançadas antes que essas instâncias sejam encerradas. Esse comportamento pode ser personalizado com o parâmetro de configuração do provedor de capacidade de instâncias gerenciadas `scaleInAfter` do Amazon ECS. Encerramento da atualização da infraestrutura As instâncias gerenciadas do Amazon ECS gerenciam e atualizam automaticamente o software em instâncias de contêineres gerenciadas para garantir a segurança e a conformidade, mantendo a disponibilidade das workloads. Para obter mais informações, consulte [Aplicação de patches em instâncias gerenciadas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html). O sistema de encerramento implementa uma abordagem de duas fases que equilibra a continuidade da workload com os requisitos de gerenciamento da infraestrutura. **Fase 1: período de conclusão sem dificuldades** Durante essa fase, o sistema implementa estratégias de drenagem normal que priorizam a continuidade da workload. As tarefas de serviço são drenadas sem dificuldades por meio dos processos normais de agendamento do Amazon ECS. As tarefas autônomas continuam sendo executadas porque podem ser concluídas naturalmente. O sistema monitora se todas as tarefas atingem o estado parado por meio dos processos de conclusão natural. **Fase 2: cumprimento de prazos rigorosos** Quando a conclusão normal não atinge os objetivos de encerramento dentro de prazos aceitáveis, o sistema implementa a aplicação de prazos rigorosos. O prazo rigoroso normalmente é definido como o tempo de início da drenagem mais sete dias, proporcionando um tempo substancial para uma conclusão perfeita e ainda mantendo os requisitos operacionais. A imposição inclui procedimentos automáticas de cancelamento de registro forçado e o encerramento imediato de todas as tarefas restantes, independentemente do status de conclusão. Uma instância de contêiner terá concluído a drenagem quando todas as tarefas em execução na instância tiverem feito a transição para o estado `STOPPED`. A instância de contêiner permanece no estado `DRAINING` até que seja reativada ou excluída. É possível verificar o estado das tarefas na instância de contêiner usando a operação [ListTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListTasks.html) com o parâmetro `containerInstance`para obter uma lista de tarefas na instância, seguida por uma operação [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) com o nome do recurso da Amazon (ARN) ou o ID de cada tarefa para verificar o estado da tarefa. Quando você estiver pronto para que a instância de contêiner comece a hospedar tarefas novamente, altere o estado da instância de contêiner de `DRAINING` para `ACTIVE`. O programador de serviços do Amazon ECS considera a instância de contêiner novamente para posicionamento de tarefa. ## Procedimento As etapas a seguir podem ser usadas para definir uma instância de contêiner a ser drenada usando o novo Console de gerenciamento da AWS. Você também pode usar a ação de API [UpdateContainerInstancesState](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html) ou o comando [update-container-instances-state](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-container-instances-state.html) a fim de alterar o status de uma instância de contêiner para `DRAINING`. **Console de gerenciamento da AWS** 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 um cluster que hospede suas instâncias. 1. Na página **Cluster : *name***, escolha a guia **Infrastructure** (Infraestrutura). Em seguida, em **Container instances** (Instâncias de contêiner), marque a caixa de seleção de cada instância de contêiner que você deseja drenar. 1. Escolha **Ações**, **Drenar**. # Como alterar o tipo ou tamanho da instância fora do grupo do Auto Scaling A AWS recomenda que você mantenha sua infraestrutura imutável. Se precisar alterar o tamanho das instâncias, faça o seguinte: + Escale horizontalmente e adicione mais instâncias. Em seguida, coloque tarefas adicionais nessas instâncias, ou + Escale verticalmente iniciando uma nova instância maior/menor e, em seguida, drene a instância antiga. Ambas as abordagens ajudarão a minimizar o impacto na disponibilidade da aplicação. Se você usar outro método para alterar a instância, poderá receber o seguinte erro: ``` Container instance type changes are not supported. ``` Ao receber esse erro, execute as seguintes etapas: 1. Inicialize novas instâncias com o tipo desejado. 1. Drene seus tipos de instância antigos. Para obter mais informações, consulte [Drenagem de instâncias de contêiner do Amazon ECS](container-instance-draining.md). # Instâncias de contêineres do EC2 para Amazon ECS O agente do Amazon ECS é um processo executado em cada instância de contêiner registrada em seu cluster. Ele facilita a comunicação entre as instâncias de contêiner e o Amazon ECS. **nota** Em instâncias de contêiner Linux, o contêiner do agente monta diretórios de nível superior, como `/lib`, `/lib64` e `/proc`. Isso é necessário para recursos e funcionalidades do ECS, como volumes do Amazon EBS, modo de rede `awsvpc`, Amazon ECS Service Connect e FireLens para Amazon ECS. Cada agente de contêiner do Amazon ECS oferece suporte a um conjunto diferente de recursos e fornece correções de erros de versões anteriores. Quando possível, sempre recomendamos usar a versão mais recente do agente de contêiner do Amazon ECS. 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). O agente de contêiner do Amazon ECS contém a imagem `amazon-ecs-pause`. O Amazon ECS usa essa imagem em tarefas que usam o modo de rede `awsvpc`. Para ver quais recursos e aprimoramentos estão incluídos em cada versão de agente, consulte [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases). **Importante** A versão mínima do Docker para métricas confiáveis é a versão Docker `v20.10.13` e posteriores, que está incluída na AMI otimizada para o Amazon ECS `20220607` e posteriores. As versões `1.20.0` e posteriores do agente do Amazon ECS descontinuaram o suporte para as versões do Docker anteriores à `18.01.0`. ## Ciclo de vida Quando o agente de contêiner do Amazon ECS registra uma instância do Amazon EC2 no cluster, a instância do Amazon EC2 relata seu status como `ACTIVE` e o status de conexão do agente como `TRUE`. Essa instância de contêiner pode aceitar solicitações de tarefas de processamento. Se você interrompe (sem concluir) uma instância de contêiner, o status permanece como `ACTIVE`, mas o status de conexão do agente muda para `FALSE` em instantes. As tarefas que estavam sendo executadas na instância de contêiner são interrompidas. Se você reiniciar a instância de contêiner, o agente de contêiner se reconectará com o serviço do Amazon ECS e será possível, novamente, executar tarefas na instância. Se você alterar o status de uma instância de contêiner para `DRAINING`, as novas tarefas não serão posicionadas na instância de contêiner. Todas as tarefas de serviço em execução na instância de contêiner são removidas, se possível, de modo que você possa realizar atualizações de sistema. Para obter mais informações, consulte [Drenagem de instâncias de contêiner do Amazon ECS](container-instance-draining.md). Se você cancela o registro ou encerra uma instância de contêiner, seu status muda para `INACTIVE` imediatamente, e ela não é mais referida não quando você lista suas instâncias de contêiner. No entanto, você ainda pode descrever a instância de contêiner por uma hora depois do encerramento. Depois desse período, a descrição de instância não estará mais disponível. É possível drenar as instâncias manualmente ou criar um hook do ciclo de vida do grupo do Auto Scaling para definir o status da instância como `DRAINING`. Para obter mais informações sobre hooks do ciclo de vida do Auto Scaling, consulte [Hooks do ciclo de vida do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html). ## Compatibilidade com o Docker O Amazon ECS é compatível com as duas últimas versões principais do Docker publicadas no Amazon Linux. Atualmente, isso inclui o Docker 20.10.x e o Docker 25.x. A versão mínima exigida do Docker para o Amazon ECS pode ser encontrada no [arquivo de especificação do agente do Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/dev/packaging/amazon-linux-ami-integrated/ecs-agent.spec#L53) no GitHub. Ao usar a AMI otimizada para Amazon ECS, o Docker é pré-instalado e configurado para funcionar com o agente de contêiner do Amazon ECS. A AMI inclui uma versão do Docker que é testada e compatível com o Amazon ECS. **nota** Embora o Amazon ECS seja compatível com várias versões do Docker, recomendamos usar a versão do Docker que vem com a AMI otimizada para Amazon ECS para obter a melhor compatibilidade e suporte. ## AMIs otimizadas para Amazon ECS Para obter mais informações sobre a AMI otimizada para o Amazon ECS, consulte [AMIs do Linux otimizadas para o Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). ## Mais informações As páginas a seguir fornecem informações adicionais sobre as alterações: + [Log de alterações do agente do Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) no GitHub + [Notas de release do Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html). + [Notas de lançamento do Docker Engine](https://docs.docker.com/engine/release-notes/27/) na documentação do Docker + [Documentação do driver NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) na documentação da NVIDIA # Configuração do agente de contêiner do Amazon ECS **Aplica-se a**: instâncias do EC2 O agente de contêiner do Amazon ECS oferece suporte a diversas opções de configuração, a maioria das quais você define por meio de variáveis de ambiente. Se a instância de contêiner tiver sido executada com a variante do Linux da AMI otimizada para Amazon ECS, será possível definir essas variáveis de ambiente no arquivo `/etc/ecs/ecs.config` e reiniciar o agente. Também é possível gravar essas variáveis de configuração nas instâncias de contêiner com os dados de usuário do Amazon EC2 no momento de inicialização. Para obter mais informações, consulte [Inicialização de instâncias de contêiner do Linux no Amazon ECS para transmitir dados](bootstrap_container_instance.md). Se a instância de contêiner tiver sido iniciada com a variante do Windows da AMI otimizada para Amazon ECS, será possível definir essas variáveis de ambiente com o comando SetEnvironmentVariable do PowerShell e, em seguida, reiniciar o agente. 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* e em [Inicialização de instâncias de contêiner do Windows no Amazon ECS para transmitir dados](bootstrap_windows_container_instance.md). Se você está iniciando o Amazon ECS manualmente, o agente de contêiner (para AMIs não otimizadas para Amazon ECS), pode usar essas variáveis de ambiente no comando **docker run** usado para iniciar o agente. Use essas variáveis com a sintaxe `--env=VARIABLE_NAME=VARIABLE_VALUE`. Para informações delicadas, como credenciais de autenticação para repositórios privados, você deve armazenar suas variáveis de ambiente do agente em um arquivo e passá-las todas ao mesmo tempo com a opção `--env-file path_to_env_file`. É possível usar os comandos a seguir para adicionar as variáveis. ``` sudo systemctl stop ecs sudo vi /etc/ecs/ecs.config # And add the environment variables with VARIABLE_NAME=VARIABLE_VALUE format. sudo systemctl start ecs ``` ## Executar o agente do Amazon ECS com o namespace de PID do host Por padrão, o agente do Amazon ECS é executado com seu próprio namespace de PID. Nas configurações a seguir, você poderá configurar o agente do Amazon ECS para ser executado com o namespace de PID do host: + O modo de imposição do SELinux está habilitado. + A política de segurança SELinux do Docker está definida como verdadeira. Você pode configurar esse comportamento definindo a variável de ambiente `ECS_AGENT_PID_NAMESPACE_HOST` como `true` em seu arquivo `/etc/ecs/ecs.config`. Quando essa variável estiver habilitada, `ecs-init` iniciará o contêiner do agente do Amazon ECS com o namespace de PID do host (`--pid=host`), permitindo que o agente faça seu bootstrap adequadamente em ambientes que impõem o SELinux. Esse recurso está disponível na versão `1.94.0` e posterior do agente do Amazon ECS. Para habilitar esse recurso, adicione a seguinte linha ao seu arquivo `/etc/ecs/ecs.config`: ``` ECS_AGENT_PID_NAMESPACE_HOST=true ``` Após fazer essa alteração, reinicie o agente do Amazon ECS para que a alteração entre em vigor: ``` sudo systemctl restart ecs ``` Os seguintes recursos não funcionarão quando o modo de imposição do SELinux estiver habilitado e a política de segurança do Docker estiver definida como verdadeira, mesmo quando `ECS_AGENT_PID_NAMESPACE_HOST=true` estiver definido. + Amazon ECS Exec + Anexação de tarefa do Amazon EBS + Service Connect + FireLens para o Amazon ECS ## Parâmetros disponíveis Para obter informações sobre os parâmetros de configuração do agente de contêiner do Amazon ECS, consulte [Agente de contêiner do Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) no GitHub.. # Armazenamento da configuração da instância de contêiner do Amazon ECS no Amazon S3 A configuração do agente de contêiner do Amazon ECS é controlada com a variável de ambiente. As variantes do Linux da AMI otimizada para Amazon ECS procuram essas variáveis em `/etc/ecs/ecs.config` quando o agente de contêiner é iniciado e configuram o agente adequadamente. Variáveis de ambiente não sensíveis, como `ECS_CLUSTER`, podem ser transmitidas para a instância de contêiner na inicialização com os dados de usuário do Amazon EC2 e gravadas nesse arquivo sem consequências. Contudo, outras informações confidenciais, como suas credenciais da AWS ou a variável `ECS_ENGINE_AUTH_DATA`, nunca devem ser passadas para uma instância em dados de usuário ou ser gravadas em `/etc/ecs/ecs.config` de forma a permitir que sejam exibidas em um arquivo `.bash_history`. Armazenar informações de configuração em um bucket privado no Amazon S3 e conceder acesso somente leitura à função do IAM de instância de contêiner é uma maneira segura e prática de permitir a configuração da instância de contêiner na inicialização. É possível armazenar uma cópia do seu arquivo `ecs.config` em um bucket privado. É possível usar os dados do usuário do Amazon EC2 para instalar a AWS CLI e copiar as informações de configuração em `/etc/ecs/ecs.config` quando a instância for iniciada. **Para armazenar um arquivo `ecs.config` no Amazon S3** 1. Você deve conceder permissões para ter acesso somente leitura ao Amazon S3 ao perfil de instância de contêiner (**ecsInstanceRole**). É possível fazer isso ao atribuir **AmazonS3ReadOnlyAccess** ao perfil `ecsInstanceRole`. Para obter informações sobre como anexar uma política a um perfil, consulte [Atualizar permissões para um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) no *Guia do usuário do AWS Identity and Access Management*. 1. Crie um arquivo `ecs.config` com variáveis de configuração válidas do agente Amazon ECS usando o formato a seguir. Este exemplo configura a 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). ``` ECS_ENGINE_AUTH_TYPE=dockercfg ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}} ``` **nota** Para obter uma lista completa das variáveis de configuração do agente do Amazon ECS disponíveis, consulte [Agente de contêiner do Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) no GitHub. 1. Para armazenar o arquivo de configuração, crie um bucket privado no Amazon S3. Para saber mais, consulte [Criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) no *Guia do usuário do Amazon Simple Storage Service*. 1. Faça upload do arquivo `ecs.config` no bucket do S3. Para obter mais informações, consulte [Fazer upload de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) no *Guia do usuário do Amazon Simple Storage Service*. **Para carregar um arquivo `ecs.config` do Amazon S3 na inicialização** 1. Execute os procedimentos anteriores nesta seção para permitir acesso somente leitura do Amazon S3 às suas instâncias de contêiner e armazene um arquivo `ecs.config` em um bucket do S3 privado. 1. Inicie novas instâncias de contêiner e use o script de exemplo apresentado a seguir nos dados do usuário do EC2. O script instala a AWS CLI e copia o arquivo de configuração para `/etc/ecs/ecs.config`. Para obter mais informações, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md). ``` #!/bin/bash yum install -y aws-cli aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config ``` # Instalar o agente de contêiner do Amazon ECS Se desejar registrar uma instância do Amazon EC2 com o cluster do Amazon ECS e essa instância não estiver usando uma AMI baseada na AMI otimizada para o Amazon ECS, você poderá instalar o agente de contêiner do Amazon ECS manualmente usando o procedimento apresentado a seguir. Para fazer isso, você pode efetuar o download do agente de um dos buckets regionais do Amazon S3 ou do Amazon Elastic Container Registry Public. Se você efetuar o download de um dos buckets regionais do Amazon S3, como opção, poderá verificar a validade do arquivo do agente de contêiner usando a assinatura PGP. **nota** As unidades `systemd` para os serviços do Amazon ECS e do Docker têm uma diretiva para aguardar a conclusão de `cloud-init` antes de iniciar ambos os serviços. O processo `cloud-init` só será considerado concluído quando a execução dos dados do usuário do Amazon EC2 estiver concluída. Portanto, iniciar o Amazon ECS ou o Docker por meio dos dados de usuário do Amazon EC2 pode causar um deadlock. Para iniciar o agente de contêiner usando dados de usuário do Amazon EC2, é possível usar `systemctl enable --now --no-block ecs.service`. ## Instalar o agente de contêiner do Amazon ECS em uma instância que não seja do EC2 do Amazon Linux Para instalar o agente de contêiner do Amazon ECS em uma instância do Amazon EC2, é possível efetuar o download do agente de um dos buckets regionais do Amazon S3 e instalá-lo. **nota** Ao usar uma AMI que não seja do Amazon Linux, sua instância do Amazon EC2 requer suporte do `cgroupfs` para o driver `cgroup` para que o agente do Amazon ECS ofereça suporte a limites de recursos em nível de tarefa. Para obter mais informações, consulte [Amazon ECS agent on GitHub](https://github.com/aws/amazon-ecs-agent) (Agente do Amazon ECS no GitHub). Os arquivos do agente de contêiner do Amazon ECS mais recentes, por região, para cada arquitetura de sistema, são listados a seguir para referência. | Região | Nome da região | Arquivos de deb init do Amazon ECS | Arquivos de rpm init do Amazon ECS | | --- | --- | --- | --- | | us-east-2 | Leste dos EUA (Ohio) | [Amazon ECS amd64 init](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | us-east-1 | Leste dos EUA (Norte da Virgínia) | [Amazon ECS amd64 init](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | us-west-1 | Oeste dos EUA (N. da Califórnia) | [Amazon ECS amd64 init](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | us-west-2 | Oeste dos EUA (Oregon) | [Amazon ECS amd64 init](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | ap-east-1 | Ásia-Pacífico (Hong Kong) | [Amazon ECS amd64 init](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | ap-northeast-1 | Ásia-Pacífico (Tóquio) | [Amazon ECS amd64 init](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | ap-northeast-2 | Ásia-Pacífico (Seul) | [Amazon ECS amd64 init](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | ap-south-1 | Ásia-Pacífico (Mumbai) | [Amazon ECS amd64 init](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | ap-southeast-1 | Ásia-Pacífico (Singapura) | [Amazon ECS amd64 init](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | ap-southeast-2 | Ásia-Pacífico (Sydney) | [Amazon ECS amd64 init](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | ca-central-1 | Canadá (Central) | [Amazon ECS amd64 init](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | eu-central-1 | Europa (Frankfurt) | [Amazon ECS amd64 init](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | eu-west-1 | Europa (Irlanda) | [Amazon ECS amd64 init](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | eu-west-2 | Europa (Londres) | [Amazon ECS amd64 init](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | eu-west-3 | Europa (Paris) | [Amazon ECS amd64 init](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | sa-east-1 | América do Sul (São Paulo) | [Amazon ECS amd64 init](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init86\$164](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.x86_64.rpm) [Amazon ECS aarch64 init](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | us-gov-east-1 | AWS GovCloud (Leste dos EUA) | [Amazon ECS amd64 init](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | | us-gov-west-1 | AWS GovCloud (Oeste dos EUA) | [Amazon ECS amd64 init](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS arm64 init](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS x86\$164 init](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS aarch64 init](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) | **Para instalar o agente de contêiner do Amazon ECS em uma instância do Amazon EC2 usando uma AMI que não seja do Amazon Linux** 1. Inicie uma instância do Amazon EC2 com uma função do IAM que permita acesso ao Amazon ECS. Para obter mais informações, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md). 1. Conecte-se à sua instância. 1. Instale a versão mais recente do Docker na instância. 1. Verifique a versão do Docker para verificar se seu sistema atende à exigência de versão mínima. Para obter mais informações sobre o suporte do Docker, consulte [Instâncias de contêineres do EC2 para Amazon ECS](ecs-agent-versions.md). ``` docker --version ``` 1. Baixe o arquivo de agente do Amazon ECS apropriado para seu sistema operacional e arquitetura de sistema e instale-o. Para arquiteturas `deb`: ``` ubuntu:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb ubuntu:~$ sudo dpkg -i amazon-ecs-init-latest.amd64.deb ``` Para arquiteturas `rpm`: ``` fedora:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm fedora:~$ sudo yum localinstall -y amazon-ecs-init-latest.x86_64.rpm ``` 1. Edite o arquivo `/lib/systemd/system/ecs.service` e adicione a linha apresentada a seguir no final da seção `[Unit]`. ``` After=cloud-final.service ``` 1. (Opcional) Para registrar a instância com um cluster diferente do cluster `default`, edite o arquive `/etc/ecs/ecs.config` e adicione o seguinte conteúdo. O exemplo seguinte especifica o cluster `MyCluster`. ``` ECS_CLUSTER=MyCluster ``` Para obter mais informações sobre essas e outras opções de runtime de agente, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). **nota** É possível, opcionalmente, armazenar suas variáveis de ambiente do agente no Amazon S3 (que podem ser baixadas para as instâncias de contêiner no momento da inicialização usando os dados de usuário do Amazon EC2). Isso é recomendado para informações confidenciais, como credenciais de autenticação para repositórios privados. Para obter mais informações, consulte [Armazenamento da configuração da instância de contêiner do Amazon ECS no Amazon S3](ecs-config-s3.md) e [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md). 1. Inicie o serviço `ecs`. ``` ubuntu:~$ sudo systemctl start ecs ``` ## Execução do agente do Amazon ECS com o modo de rede de host Durante a execução do agente de contêiner do Amazon ECS, `ecs-init` criará o contêiner do agente de contêiner com o modo de rede de `host`. Esse é o único modo de rede com suporte para o contêiner do agente de contêiner. Isso permite que você bloqueie o acesso ao [Endpoint de serviço de metadados da instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) (`http://169.254.169.254`) para os contêineres iniciados pelo agente de contêiner. Isso garante que os contêineres não possam acessar as credenciais de função do IAM do perfil da instância de contêiner e impõe que as tarefas usem apenas as credenciais de função de tarefa do IAM. Para obter mais informações, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md). Isso também permite que o agente de contêiner não dispute conexões e tráfego de rede na ponte `docker0`. ## Parâmetros de configuração do log do agente de contêiner do Amazon ECS O agente de contêiner do Amazon ECS armazena logs nas instâncias de contêiner. Para o agente de contêiner versão 1.36.0 e posteriores, por padrão, os logs estão localizados em `/var/log/ecs/ecs-agent.log` nas instâncias do Linux e em `C:\ProgramData\Amazon\ECS\log\ecs-agent.log` nas instâncias do Windows. Para o agente de contêiner versão 1.35.0 e posteriores, por padrão, os logs estão localizados em `/var/log/ecs/ecs-agent.log.timestamp` nas instâncias do Linux e em `C:\ProgramData\Amazon\ECS\log\ecs-agent.log.timestamp` nas instâncias do Windows. Por padrão, os logs do agente são rotacionados de hora em hora com o máximo de 24 logs armazenados. Veja a seguir as variáveis de configuração do agente de contêiner que podem ser usadas para alterar o comportamento padrão de log do agente. Para obter informações detalhadas sobre todos os parâmetros de configuração disponíveis, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md) o [README do agente do Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) no GitHub. Para o agente de contêiner versão 1.36.0 e posteriores, veja a seguir um arquivo de log de exemplo quando o formato `logfmt` é usado. ``` level=info time=2019-12-12T23:43:29Z msg="Loading configuration" module=agent.go level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go level=info time=2019-12-12T23:43:29Z msg="Amazon ECS agent Version: 1.36.0, Commit: ca640387" module=agent.go level=info time=2019-12-12T23:43:29Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go level=info time=2019-12-12T23:43:29Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go level=info time=2019-12-12T23:43:29Z msg="Loading state!" module=statemanager.go level=info time=2019-12-12T23:43:29Z msg="Event stream ContainerChange start listening..." module=eventstream.go level=info time=2019-12-12T23:43:29Z msg="Restored cluster 'auto-robc'" module=agent.go level=info time=2019-12-12T23:43:29Z msg="Restored from checkpoint file. I am running as 'arn:aws:ecs:us-west-2:0123456789:container-instance/auto-robc/3330a8a91d15464ea30662d5840164cd' in cluster 'auto-robc'" module=agent.go ``` Veja a seguir um arquivo de log de exemplo quando o formato JSON é usado. ``` {"time": "2019-11-07T22:52:02Z", "level": "info", "msg": "Starting Amazon Elastic Container Service Agent", "module": "engine.go"} ``` # Configuração de instâncias de contêiner do Amazon ECS para imagens do Docker privadas O agente de contêiner do Amazon ECS pode realizar a autenticação com registros privados usando a autenticação básica. Ao ativar a autenticação de registro privado, você pode utilizar imagens de docker privadas nas definições de tarefa. Esse recurso só é compatível com tarefas que usam o EC2. Outro método para habilitar a autenticação de registro privado usa o AWS Secrets Manager para armazenar suas credenciais de registro privado de forma segura e, então, referenciá-las em sua definição de contêiner. Isso permite que suas tarefas usem imagens de repositórios privados. Esse método é compatível com tarefas que usam o EC2 ou o Fargate. 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). O agente de contêiner do Amazon ECS procura duas variáveis de ambiente ao ser iniciado: + `ECS_ENGINE_AUTH_TYPE`, que especifica o tipo de dados de autenticação que está sendo enviado. + `ECS_ENGINE_AUTH_DATA`, que contém as credenciais de autenticação em si. As variantes do Linux da AMI otimizada para Amazon ECS procuram essas variáveis no arquivo `/etc/ecs/ecs.config` quando a instância de contêiner é inicializada, e cada vez que o serviço é iniciado (com o comando **sudo start ecs**). As AMIs que não são otimizadas para Amazon ECS devem armazenar essas variáveis de ambiente em um arquivo e transmiti-las com a opção `--env-file path_to_env_file` para o comando **docker run** que inicia o agente de contêiner. **Importante** Não recomendamos que você injete essas variáveis de ambiente de autenticação na inicialização da instância com os dados de usuário do Amazon EC2 ou as transmita com a opção `--env` para o comando **docker run**. Esses métodos não são adequados para dados confidenciais, como credenciais de autenticação. Para obter informações sobre como adicionar credenciais de autenticação com segurança às instâncias de contêiner, consulte [Armazenamento da configuração da instância de contêiner do Amazon ECS no Amazon S3](ecs-config-s3.md). ## Formatos de autenticação Há dois formatos disponíveis para a autenticação de registro privado, `dockercfg` e `docker`. **Formato de autenticação dockercfg** O formato `dockercfg` usa as informações de autenticação armazenadas no arquivo de configuração criado quando você executa o comando **docker login**. É possível criar esse arquivo executando **docker login** no sistema local e inserindo o nome de usuário, a senha e o endereço de e-mail do registro. Também é possível fazer login em uma instância de contêiner e executar o comando daí. Dependendo de sua versão do Docker, esse arquivo é salvo como `~/.dockercfg` ou `~/.docker/config.json`. ``` cat ~/.docker/config.json ``` Resultado: ``` { "auths": { "https://index.docker.io/v1/": { "auth": "zq212MzEXAMPLE7o6T25Dk0i" } } } ``` **Importante** As versões mais recentes do Docker criam um arquivo de configuração como mostrado acima, com um objeto `auths` externo. O agente do Amazon ECS oferece suporte somente aos dados de autenticação `dockercfg` que estão no formato abaixo, sem o objeto `auths`. Se tiver o utilitário **jq** instalado, será possível extrair esses dados com o comando a seguir: **cat \$1/.docker/config.json \$1 jq .auths** ``` cat ~/.docker/config.json | jq .auths ``` Resultado: ``` { "https://index.docker.io/v1/": { "auth": "zq212MzEXAMPLE7o6T25Dk0i", "email": "email@example.com" } } ``` No exemplo acima, as variáveis de ambiente a seguir devem ser adicionadas ao arquivo de variável de ambiente (`/etc/ecs/ecs.config` para a AMI otimizada para o Amazon ECS) que o agente de contêiner do Amazon ECS carrega no runtime. Se você não estiver usando a AMI otimizada para Amazon ECS e estiver iniciando o agente manualmente com **docker run**, especifique o arquivo de variável de ambiente com a opção `--env-file path_to_env_file` ao iniciar o agente. ``` ECS_ENGINE_AUTH_TYPE=dockercfg ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}} ``` É possível configurar vários registros privados com a sintaxe a seguir: ``` ECS_ENGINE_AUTH_TYPE=dockercfg ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example-01.com"},"repo.example-02.com":{"auth":"fQ172MzEXAMPLEoF7225DU0j","email":"email@example-02.com"}} ``` **Formato de autenticação docker** O formato `docker` usa uma representação JSON do servidor de registro com que o agente deve se autenticar. Ele também inclui os parâmetros de autenticação exigidos por esse registro (como nome de usuário, senha e endereço de e-mail dessa conta). Para uma conta do Docker Hub, a representação JSON terá a seguinte aparência: ``` { "https://index.docker.io/v1/": { "username": "my_name", "password": "my_password", "email": "email@example.com" } } ``` Nesse exemplo as variáveis de ambiente a seguir devem ser adicionadas ao arquivo de variável de ambiente (`/etc/ecs/ecs.config` para a AMI otimizada para o Amazon ECS) que o agente de contêiner do Amazon ECS carrega no runtime. Se você não estiver usando a AMI otimizada para Amazon ECS e estiver iniciando o agente manualmente com **docker run**, especifique o arquivo de variável de ambiente com a opção `--env-file path_to_env_file` ao iniciar o agente. ``` ECS_ENGINE_AUTH_TYPE=docker ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}} ``` É possível configurar vários registros privados com a sintaxe a seguir: ``` ECS_ENGINE_AUTH_TYPE=docker ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"username":"my_name","password":"my_password","email":"email@example-01.com"},"repo.example-02.com":{"username":"another_name","password":"another_password","email":"email@example-02.com"}} ``` ## Procedimento Use o procedimento a seguir para ativar registros privados para as instâncias de contêiner. **Para habilitar registros privados na AMI otimizada para Amazon ECS** 1. Faça login em sua instância de contêiner usando SSH. 1. Abra o arquivo `/etc/ecs/ecs.config` e adicione os valores `ECS_ENGINE_AUTH_TYPE` e `ECS_ENGINE_AUTH_DATA` para o seu registro e conta: ``` sudo vi /etc/ecs/ecs.config ``` Este exemplo autentica uma conta de usuário do Docker Hub: ``` ECS_ENGINE_AUTH_TYPE=docker ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}} ``` 1. Verifique se o seu agente usa a variável de ambiente `ECS_DATADIR` para salvar seu estado: ``` docker inspect ecs-agent | grep ECS_DATADIR ``` Resultado: ``` "ECS_DATADIR=/data", ``` **Importante** Se o comando anterior não retornar a variável de ambiente `ECS_DATADIR`, você deverá interromper todas as tarefas em execução nessa instância de contêiner antes de interromper o agente. Agentes mais novos com a variável de ambiente `ECS_DATADIR` salvam seu estado, e você pode interrompê-los e iniciá-los enquanto as tarefas são executadas sem problemas. Para obter mais informações, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md). 1. Interrompa o serviço `ecs`: ``` sudo stop ecs ``` Resultado: ``` ecs stop/waiting ``` 1. Reinicie o serviço `ecs`. + 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 ``` 1. (Opcional) É possível verificar se o agente está em execução e consultar algumas informações sobre sua nova instância de contêiner consultando a operação da API de introspecção do agente. Para obter mais informações, consulte [Introspecção de contêiner do Amazon ECS](ecs-agent-introspection.md). ``` curl http://localhost:51678/v1/metadata ``` # Limpeza automática de tarefas e de imagens do Amazon ECS Sempre que uma tarefa é colocada em uma instância de contêiner, o agente de contêiner do Amazon ECS verifica se as imagens referenciadas na tarefa são as mais recentes da etiqueta especificada no repositório. Caso contrário, o comportamento padrão permite que o agente execute pull das imagens de seus respectivos repositórios. Se você atualizar frequentemente as imagens em suas tarefas e serviços, o armazenamento de instâncias do contêiner poderá encher rapidamente com imagens do Docker que você não está mais usando e que provavelmente nunca mais usará. Por exemplo, você pode usar um pipeline de integração contínua e implantação contínua (CI/CD). **nota** O comportamento da extração de imagens do agente do Amazon ECS pode ser personalizado por meio do parâmetro `ECS_IMAGE_PULL_BEHAVIOR`. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). Da mesma forma, os contêineres que pertencem a tarefas interrompidas também podem consumir armazenamento de instâncias de contêiner com informações de log, volumes de dados e outros artefatos. Esses artefatos são úteis para os contêineres de depuração que pararam inesperadamente, mas grande parte desse armazenamento pode ser liberado com segurança após um período. Por padrão, o agente de contêiner do Amazon ECS limpa automaticamente tarefas e imagens do Docker interrompidas que não estão sendo usadas por qualquer tarefa nas instâncias de contêiner. **nota** O recurso de limpeza de imagem automatizado requer pelo menos a versão 1.13.0 do agente de contêiner do Amazon ECS. Para atualizar o agente para a versão mais recente, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md). As seguintes variáveis de configuração de agente estão disponíveis para ajustar sua experiência de limpeza automatizada de tarefas e imagens. Para mais informações sobre como definir essas variáveis nas instâncias de contêiner, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` O tempo padrão de espera para excluir contêineres de uma tarefa interrompida. Se o valor for definido para menos de 1 segundo, ele será ignorado. Por padrão, este parâmetro é definido para 3 horas, mas é possível reduzir esse período para até 1 minuto, se isso for necessário para sua aplicação. O processo de limpeza de imagem não pode excluir uma imagem, contanto que haja um contêiner que faça referência a ele. Depois que os contêineres são removidos, todas as imagens não referenciadas se tornam candidatas à limpeza com base nos parâmetros de configuração da limpeza de imagens. `ECS_DISABLE_IMAGE_CLEANUP` Se você definir esta variável como `true`, a limpeza automatizada de imagem será desativada na instância de contêiner e nenhuma imagem será removida automaticamente. `ECS_IMAGE_CLEANUP_INTERVAL` Esta variável especifica a frequência em que o processo de limpeza automatizada de imagem deve procurar as imagens a serem excluídas. O padrão é a cada 30 minutos, mas você pode reduzir esse período para até 10 minutos, a fim de remover as imagens com mais frequência. `ECS_IMAGE_MINIMUM_CLEANUP_AGE` Essa variável especifica o intervalo de tempo mínimo entre o momento em que uma imagem foi obtida e o momento em que ela pode se tornar candidata à remoção. Ela é usada para evitar a limpeza de imagens que acabaram de ser obtidas. O valor padrão é 1 hora. `ECS_NUM_IMAGES_DELETE_PER_CYCLE` Esta variável especifica quantas imagens podem ser removidas em um único ciclo de limpeza. O valor padrão é 5 e o valor mínimo é 1. Quando o agente de contêiner do Amazon ECS estiver em execução e a limpeza automatizada de imagem não estiver desativada, o agente verificará imagens do Docker que não são referenciadas por contêineres interrompidos ou em execução com uma frequência determinada pela variável `ECS_IMAGE_CLEANUP_INTERVAL`. Se as imagens não utilizadas forem localizadas e forem mais antigas do que o tempo mínimo de limpeza especificado pela variável `ECS_IMAGE_MINIMUM_CLEANUP_AGE`, o agente removerá até o número máximo de imagens especificadas com a variável `ECS_NUM_IMAGES_DELETE_PER_CYCLE`. As imagens referenciadas menos recentes são excluídas primeiro. Depois que as imagens forem removidas, o agente esperará até o intervalo seguinte e repetirá o processo novamente.