As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Ambientes computacionais para AWS Batch
As filas de trabalho são mapeadas para um ou mais ambientes de computação. Os ambientes de computação contêm as instâncias de contêiner do Amazon ECS que são usadas para executar trabalhos em lote em contêineres. Um ambiente de computação específico também podem ser mapeado para uma ou mais filas de trabalho. Em uma fila de trabalho, cada ambiente de computação associado tem um pedido que é usado pelo programador para determinar onde os trabalhos que estão prontos para serem executados serão executados. Se o primeiro ambiente de computação tiver um status de `VALID` e recursos disponíveis, o trabalho será agendado para uma instância de contêiner nesse ambiente de computação. Se o primeiro ambiente de computação tiver um status de `INVALID` ou não puder fornecer um recurso de computação adequado, o agendador tentará executar o trabalho no próximo ambiente de computação.
**Topics**
+ [Ambientes de computação gerenciados](managed_compute_environments.md)
+ [Ambientes de computação não gerenciados](unmanaged_compute_environments.md)
+ [Crie um ambiente de computação](create-compute-environment.md)
+ [Atualize um ambiente computacional no AWS Batch](updating-compute-environments.md)
+ [Recurso computacional AMIs](compute_resource_AMIs.md)
+ [Use os modelos de lançamento do Amazon EC2 com AWS Batch](launch-templates.md)
+ [Configuração do serviço de metadados de instância (IMDS)](imds-compute-environments.md)
+ [Configurações do EC2](ec2-configurations.md)
+ [Estratégias de alocação de tipo de instância para AWS Batch](allocation-strategies.md)
+ [Gerenciamento de memória de recursos de computação](memory-management.md)
+ [Ambientes de computação Fargate](fargate.md)
+ [Ambientes de computação Amazon EKS](eks.md)
# Ambientes de computação gerenciados
Você pode usar um ambiente computacional gerenciado para AWS Batch gerenciar a capacidade e os tipos de instância dos recursos computacionais dentro do ambiente. Isso se baseia nas especificações do recurso de computação que você define ao criar o ambiente de computação. Você pode optar por usar instâncias sob demanda do Amazon EC2 e instâncias spot do Amazon EC2. Como alternativa, você pode usar a capacidade do Fargate e do Fargate Spot em seu ambiente de computação gerenciado. Ao usar instâncias spot, você pode, como opção, definir um preço máximo. Assim, as instâncias spot são iniciadas apenas quando o preço da instância spot estiver abaixo de uma porcentagem especificada do preço sob demanda.
**Importante**
As instâncias Fargate Spot não são suportadas no. Windows containers on AWS Fargate Uma fila de trabalhos será bloqueada se um FargateWindows trabalho for enviado a uma fila de trabalhos que usa somente ambientes computacionais Fargate Spot.
**Importante**
AWS Batch cria e gerencia vários AWS recursos em seu nome e dentro da sua conta, incluindo modelos de lançamento do Amazon EC2, grupos do Amazon EC2 Auto Scaling, frotas spot do Amazon EC2 e clusters do Amazon ECS. Esses recursos gerenciados são configurados especificamente para garantir a operação ideal do AWS Batch . A modificação manual desses recursos AWS Batch gerenciados, a menos que seja explicitamente declarada na AWS Batch documentação, pode resultar em comportamento inesperado, incluindo ambientes `INVALID` computacionais, comportamento de escalabilidade de instâncias abaixo do ideal, atraso no processamento da carga de trabalho ou custos inesperados. Essas modificações manuais não podem ser sustentadas de forma determinística pelo AWS Batch serviço. Sempre use o AWS Batch console compatível AWS Batch APIs ou para gerenciar seus ambientes computacionais.
As modificações manuais não suportadas incluem executar suas próprias tarefas ou serviços do Amazon ECS em clusters AWS Batch gerenciados do Amazon ECS ou iniciar processos, daemons ou serviços adicionais diretamente em instâncias gerenciadas. AWS Batch AWS Batch assume controle total dos recursos computacionais em um ambiente computacional gerenciado e pode encerrar instâncias, interromper tarefas ou escalar o cluster a qualquer momento. Qualquer carga de trabalho executada fora do envio de AWS Batch trabalhos nesses recursos gerenciados pode ser interrompida sem aviso prévio. A execução de AWS Batch cargas de trabalho que não são em clusters e instâncias AWS Batch gerenciados também pode interferir no agendamento de AWS Batch trabalhos e no escalonamento de instâncias.
Ambientes de computação gerenciados iniciam instâncias do Amazon EC2 na VPC e nas sub-redes que você especifica e, em seguida, as registram em um cluster do Amazon ECS. As instâncias do Amazon EC2 precisam de acesso de rede externo para se comunicar com o endpoint de serviço do Amazon ECS. Algumas sub-redes não fornecem às instâncias do Amazon EC2 endereços IP públicos. Se suas instâncias do Amazon EC2 não tiverem um endereço IP público, elas deverão usar a conversão de endereço de rede (NAT) para obter 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*. Para obter mais informações sobre como criar uma VPC, consulte [Criar uma nuvem privada virtual](create-public-private-vpc.md).
Por padrão, os ambientes computacionais AWS Batch gerenciados usam uma versão recente e aprovada da AMI otimizada do Amazon ECS para recursos computacionais. No entanto, você pode querer criar sua própria AMI a ser usada para seus ambientes de computação gerenciados por vários motivos. Para obter mais informações, consulte [Recurso computacional AMIs](compute_resource_AMIs.md).
**nota**
AWS Batch não atualiza automaticamente o AMIs em um ambiente computacional após sua criação. Por exemplo, ele não atualiza o AMIs em seu ambiente computacional quando uma versão mais recente da AMI otimizada do Amazon ECS é lançada. Você é responsável pelo gerenciamento do sistema operacional convidado. Isso inclui quaisquer atualizações e patches de segurança. Você também é responsável por quaisquer outros utilitários ou aplicativos de software que instalar nos recursos de computação. Há duas maneiras de usar uma nova AMI para seus AWS Batch trabalhos. O método original é concluir as seguintes etapas:
Crie um novo ambiente de computação com a nova AMI.
Adicione o ambiente de computação a uma fila de trabalhos existente.
Remova o antigo ambiente de computação da fila de trabalhos.
Exclua o ambiente de computação anterior.
Em abril de 2022, AWS Batch foi adicionado suporte aprimorado para atualização de ambientes computacionais. Para obter mais informações, consulte [Atualize um ambiente computacional no AWS Batch](updating-compute-environments.md). Para usar a atualização aprimorada de ambientes computacionais para atualizar AMIs, siga estas regras:
Não defina o parâmetro da função de serviço ([https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole)) nem o defina como a função **AWSServiceRoleForBatch**vinculada ao serviço.
Defina o parâmetro da estratégia de alocação ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy)) como `BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` ou `SPOT_PRICE_CAPACITY_OPTIMIZED`.
Defina o parâmetro de atualização para a versão mais recente da imagem ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)) como `true`.
Não especifique uma ID de AMI em [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId), [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride) (em [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)) ou no modelo de execução ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)). Nesse caso, AWS Batch seleciona a AMI otimizada mais recente do Amazon ECS que é suportada AWS Batch no momento em que a atualização da infraestrutura é iniciada. Como alternativa, é possível especificar o ID da AMI os parâmetros `imageId` ou `imageIdOverride` ou o modelo de inicialização identificado pelas propriedades `LaunchTemplate`. A alteração de qualquer uma dessas propriedades inicia uma atualização da infraestrutura. Se a ID da AMI for especificada no modelo de execução, ela não poderá ser substituída pela especificação de uma ID da AMI nos parâmetros `imageId` ou `imageIdOverride`. Ela só pode ser substituída especificando um modelo de lançamento diferente. Ou, se a versão do modelo de lançamento estiver definida como `$Default` ou `$Latest`, definindo uma nova versão padrão para o modelo de execução (se for `$Default`) ou adicionando uma nova versão ao modelo de execução (se for `$Latest`).
Se essas regras forem seguidas, qualquer atualização que inicie uma atualização de infraestrutura fará com que o ID da AMI seja novamente selecionado. Se a configuração da [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version) no modelo de execução ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) for definida como `$Latest` ou `$Default`, a versão mais recente ou padrão do modelo de inicialização será avaliada no momento da atualização da infraestrutura, mesmo que o [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate) não tenha sido atualizado.
## Consideração ao criar trabalhos paralelos de vários nós
AWS Batch recomenda a criação de ambientes de computação dedicados para executar trabalhos paralelos de vários nós (MNP) e trabalhos não MNP. Isso se deve à forma como a capacidade de computação é criada em seu ambiente de computação gerenciado. Ao criar um novo ambiente de computação gerenciado, se você especificar um `minvCpu` valor maior que zero, AWS Batch criará um pool de instâncias para uso somente com trabalhos não MNP. Se um trabalho paralelo de vários nós for enviado, AWS Batch criará uma nova capacidade de instância para executar os trabalhos paralelos de vários nós. Nos casos em que há trabalhos paralelos de um e vários nós em execução no mesmo ambiente computacional em que um `maxvCpus` valor `minvCpus` ou é definido, se os recursos computacionais necessários não estiverem disponíveis, AWS Batch aguardará a conclusão dos trabalhos atuais antes de criar os recursos computacionais necessários para executar os novos trabalhos.
# Ambientes de computação não gerenciados
Em um ambiente computacional não gerenciado, você gerencia seus próprios recursos computacionais. AWS Batch oferece suporte a ambientes computacionais não gerenciados para o Amazon ECS e o Amazon EKS, permitindo que você mantenha o controle sobre sua infraestrutura enquanto aproveita os recursos de agendamento de tarefas do Batch.
**nota**
AWS Os recursos do Fargate não são suportados em ambientes computacionais não gerenciados.
Para ambientes computacionais não gerenciados do Amazon ECS, você deve verificar se a AMI que você usa para seus recursos computacionais atende à especificação da AMI da instância de contêiner do Amazon ECS. Para obter mais informações, consulte [Especificação da AMI do recurso de computação](batch-ami-spec.md) e [Tutorial: criar uma AMI de recurso de computação](create-batch-ami.md).
Depois de criar seu ambiente computacional não gerenciado, use a operação de [DescribeComputeEnvironments](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeComputeEnvironments.html)API para ver os detalhes do ambiente computacional. Encontre o cluster do Amazon ECS que está associado ao ambiente, e inicie manualmente suas instâncias de contêiner nesse cluster do Amazon ECS.
O AWS CLI comando a seguir também fornece o ARN do cluster Amazon ECS.
```
$ aws batch describe-compute-environments \
--compute-environments unmanagedCE \
--query "computeEnvironments[].ecsClusterArn"
```
Para obter mais informações, consulte [Iniciando uma instância de contêiner do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_container_instance.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Ao executar os recursos de computação, especifique o ARN do cluster do Amazon ECS que os recursos devem registrar com os seguintes dados de usuário do Amazon EC2. *ecsClusterArn*Substitua pelo ARN do cluster que você obteve com o comando anterior.
```
#!/bin/bash
echo "ECS_CLUSTER=ecsClusterArn" >> /etc/ecs/ecs.config
```
Em um ambiente computacional não gerenciado do Amazon EKS, você gerencia seus próprios nós do Kubernetes enquanto AWS Batch gerencia o agendamento e a colocação de trabalhos. Ele permite que você controle diretamente sua infraestrutura Kubernetes quanto aos requisitos operacionais, de segurança ou de conformidade. Você é responsável por provisionar e configurar seus nós do Amazon EKS, ao mesmo tempo em que AWS Batch se integra ao seu cluster Amazon EKS existente para agendar e executar trabalhos.
Para obter mais informações, consulte [Tutorial: Crie um ambiente computacional não gerenciado usando os recursos do Amazon EKS](https://docs.aws.amazon.com/batch/latest/userguide/create-compute-environment-unmanaged-eks.html).
# Crie um ambiente de computação
Antes de executar trabalhos no AWS Batch, você precisa criar um ambiente computacional. Você pode criar um ambiente computacional gerenciado onde AWS Batch gerencia as instâncias do Amazon EC2 ou os recursos do AWS Fargate dentro do ambiente com base em suas especificações. Ou, como alternativa, você pode criar um ambiente de computação não gerenciado onde você gerencia a configuração da instância do Amazon EC2 dentro do ambiente.
**Importante**
As instâncias Fargate Spot não são suportadas nos seguintes cenários:
Windows containers on AWS Fargate
Uma fila de trabalhos será bloqueada nesses cenários se um trabalho for enviado a uma fila de trabalhos que usa somente ambientes de computação Fargate Spot.
**Topics**
+ [Tutorial: criar um ambiente de computação gerenciado usando recursos do Fargate](create-compute-environment-fargate.md)
+ [Tutorial: criar um ambiente de computação gerenciado usando recursos do Amazon EC2](create-compute-environment-managed-ec2.md)
+ [Tutorial: criar um ambiente de computação não gerenciado usando recursos do Amazon EC2](create-compute-environment-unmanaged-ec2.md)
+ [Tutorial: criar um ambiente de computação gerenciado usando recursos do Amazon EKS](create-compute-environment-managed-eks.md)
+ [Tutorial: Crie um ambiente computacional não gerenciado usando os recursos do Amazon EKS](create-compute-environment-unmanaged-eks.md)
+ [Recurso: modelo de ambiente de computação](compute-environment-template.md)
+ [Tabela de computação do tipo de instância](instance-type-compute-table.md)
# Tutorial: criar um ambiente de computação gerenciado usando recursos do Fargate
Conclua as etapas a seguir para criar um ambiente computacional gerenciado usando recursos do AWS Fargate .
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Na barra de navegação, selecione o Região da AWS a ser usado.
1. No painel de navegação, escolha **Ambientes de computação**.
1. Escolha **Criar**.
1. Configure o ambiente de computação.
**nota**
Os ambientes de computação para Windows containers on AWS Fargate trabalhos devem ter pelo menos uma vCPU.
1. Para **configuração do ambiente de computação**, escolha **Fargate**.
1. Para **Nome**, especifique um nome exclusivo para seu ambiente de computação. O nome pode conter até 128 caracteres. Pode conter letras minúsculas, maiúsculas, números, hifens e (-) e sublinhados (\$1).
1. Em **Função de serviço**, escolha a função vinculada ao serviço que permite que o AWS Batch serviço faça chamadas para as operações de AWS API necessárias em seu nome. Para este exemplo, selecione **AWSServiceRoleForBatch**. Para obter mais informações, consulte [Usando funções vinculadas a serviços para AWS Batch](using-service-linked-roles.md).
1. (Opcional) Expanda as **Tags**. Para adicionar uma tag, escolha **Adicionar tag**. Insira uma **chave** e um **Valor** opcional. Escolha **Adicionar Tag**.
1. Escolha **Próxima página**.
1. Na seção **Instance configuration**:
1. (Opcional) Para **usar a capacidade do Fargate Spot**, ative o Fargate Spot. Para obter informações sobre o Fargate Spot, consulte [Usando o Amazon EC2](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/ec2-and-fargate-spot.html) Spot e o Fargate\$1Spot.
1. Em **Máximo v CPUs**, escolha o número máximo de v para o CPUs qual seu ambiente computacional pode ser expandido, independentemente da demanda da fila de trabalhos.
1. Escolha **Próxima página**.
1. Configure redes.
**Importante**
Recursos de computação precisam de acesso para se comunicar com o endpoint de serviço do Amazon ECS. Isso pode ser feito por meio de uma interface do endpoint da VPC ou por meio dos das instâncias de contêiner que tenham endereços IP públicos.
Para obter mais informações sobre endpoints da VPC de interface, consulte [Endpoints da VPC de interface do Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) no *Manual do Desenvolvedor do Amazon Elastic Container Service*.
Se você não tiver um endpoint da VPC de interface configurado e seus das instâncias de contêiner não tiverem endereços IP públicos, eles 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*. Para obter mais informações, consulte [Crie uma VPC](create-a-vpc.md).
1. Para **ID de Nuvem Privada Virtual (VPC)**, escolha uma VPC na qual você deseja iniciar suas instâncias.
1. Em **Sub-redes,** selecione a sub-rede que será usada. Por padrão, todas as sub-redes dentro da VPC selecionadas estão disponíveis.
**nota**
AWS Batch No momento, o on Fargate não oferece suporte a Locais Zones. Para obter mais informações, consulte [ Amazon ECS clusters em Local Zones, Wavelength Zones, e AWS Outposts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html#clusters-local-zones) no *Amazon Elastic Container Service Developer Guide*.
1. Para **Security groups**, escolha um security group a ser anexado às suas instâncias. Por padrão, o grupo de segurança padrão para sua VPC é escolhido.
1. Escolha **Próxima página**.
1. Para **Revisar**, reveja as etapas de configuração. Se precisar fazer alterações, escolha **Edit** (Editar). Quando terminar, escolha **Criar ambiente de computação.**
# Tutorial: criar um ambiente de computação gerenciado usando recursos do Amazon EC2
Conclua as etapas a seguir para criar um ambiente computacional gerenciado usando recursos do Amazon Elastic Compute Cloud (Amazon EC2).
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Na barra de navegação, selecione o Região da AWS a ser usado.
1. No painel de navegação, escolha **Ambientes**.
1. Selecione **Seus ambientes** e, depois, selecione **Criar ambiente**.
1. Configure o ambiente.
1. Em **configuração do ambiente de computação**, escolha **Amazon Elastic Compute Cloud (Amazon EC2).**
1. Em **Tipo de orquestração**, escolha **Gerenciado.**
1. Para **Nome**, especifique um nome exclusivo para seu ambiente de computação. O nome pode conter até 128 caracteres. Pode conter letras minúsculas, maiúsculas, números, hifens e (-) e sublinhados (\$1).
1. Em **Função de serviço**, escolha a função vinculada ao serviço que permite que o AWS Batch serviço faça chamadas para as operações de AWS API necessárias em seu nome. Para este exemplo, selecione **AWSServiceRoleForBatch**. Para obter mais informações, consulte [Usando funções vinculadas a serviços para AWS Batch](using-service-linked-roles.md).
1. Para o **Instance role**, escolha criar um novo perfil de instância ou use um perfil de instância existente que tenha as permissões de IAM necessárias anexadas. Esse perfil de instância permite que as instâncias de contêiner do Amazon ECS criadas para seu ambiente computacional façam chamadas para as operações de AWS API necessárias em seu nome. Para obter mais informações, consulte [Perfil de instância do Amazon ECS](instance_IAM_role.md). Se você optou por criar um novo perfil de instância, a função necessária (`ecsInstanceRole`) será criada para você.
1. (Opcional) Expanda as **Tags**.
1. (Opcional) Para **tags EC2**, escolha **Adicionar tag** para adicionar uma tag aos recursos que são lançados no ambiente computacional. Insira uma **chave** e um **Valor** opcional. Escolha **Adicionar Tag**.
1. (Opcional) Em **Tags**, escolha **Adicionar tag**. Insira uma **chave** e um **Valor** opcional. Escolha **Adicionar Tag**.
Para obter mais informações, consulte [Marcar com tag os recursos do AWS Batch](using-tags.md).
1. Escolha **Próximo**.
1. Na seção **Instance configuration**:
1. (Opcional) Para **Habilitar o uso de instâncias Spot**, ative o Spot. Para obter mais informações, consulte [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html).
1. (Somente Spot) Em **Maximum % on-demand price**, escolha a porcentagem máxima que o preço que uma instância spot deve ter em comparação com o preço sob demanda para esse tipo de instância antes que as instâncias sejam executadas. Por exemplo, se o preço máximo for 20%, o preço spot deverá estar abaixo de 20% do preço atual sob demanda para essa instância do EC2. Você sempre paga o menor preço (mercado) e nunca mais do que sua porcentagem máxima. Se você deixar esse campo em branco, o valor padrão será 100% do preço sob demanda.
1. (Somente Spot) Para o **perfil frota Spot**, escolha uma função de IAM existente do Amazon EC2 Frota Spot para aplicar ao seu ambiente de computação Spot. Se você ainda não tiver um perfil do IAM da frota spot do Amazon EC2 existente, crie um primeiro. Para obter mais informações, consulte [Perfil de frota spot Amazon EC2](spot_fleet_IAM_role.md).
**Importante**
Para marcar suas Instâncias Spot na criação, sua função IAM do Amazon EC2 Spot Fleet deve usar a política gerenciada mais recente da **EC2SpotFleetTaggingRoleAmazon**. A política EC2 SpotFleetRole gerenciada da **Amazon** não tem as permissões necessárias para marcar instâncias spot. Para obter mais informações, consulte [Instâncias spot sem tags na criação](spot-instance-no-tag.md) e [Marcar com tag os recursos do](tag-resources.md).
1. Em **Minimum v CPUs**, escolha o número mínimo de v CPUs que seu ambiente computacional mantém, independentemente da demanda da fila de trabalhos.
1. Em **Desired v CPUs**, escolha o número de v com o CPUs qual seu ambiente computacional é iniciado. À medida que a demanda da fila de trabalhos aumenta, AWS Batch você pode aumentar o número desejado de vCPUs em seu ambiente computacional e adicionar instâncias do EC2, até o máximo v. CPUs À medida que a demanda diminui, AWS Batch pode diminuir o número desejado de v CPUs em seu ambiente computacional e remover instâncias, até o mínimo v. CPUs
1. Em **Máximo v CPUs**, escolha o número máximo de v para o CPUs qual seu ambiente computacional pode ser expandido, independentemente da demanda da fila de trabalhos.
1. (Opcional) Para **reduzir o atraso (minutos)**, escolha o tempo mínimo (em minutos) que AWS Batch mantém as instâncias em execução no ambiente computacional após a conclusão dos trabalhos.
1. Para **Tipos de instância permitidos**, escolha os tipos de instância do Amazon EC2 que podem ser iniciados. Você pode especificar famílias de instâncias para iniciar qualquer tipo de instância dentro dessas famílias (por exemplo `c5`, `c5n`, ou `p3`). Ou você pode especificar tamanhos específicos dentro de uma família (como `c5.8xlarge`). Os tipos de instância Metal não estão nas famílias de instâncias. Por exemplo, `c5` não inclui `c5.metal`.
AWS Batch pode selecionar o tipo de instância para você se você escolher uma das seguintes opções:
+ `optimal` para selecionar tipos de instância (das famílias de instâncias `c4`, `m4`, `r4`, `c5`, `m5` e `r5`) que correspondam à demanda de suas filas de trabalho.
+ `default_x86_64` para selecionar tipos de instância baseados em x86 (das famílias de instâncias m6i, c6i, r6i e c7i) que correspondam à demanda de suas filas de trabalho.
+ `default_arm64` para selecionar tipos de instância baseados em x86 (das famílias de instâncias m6g, c6g, r6g e c7g) que correspondam à demanda de suas filas de trabalho.
**nota**
A partir de 01/11/2025, o comportamento do `optimal` será alterado para corresponder com `default_x86_64`. Durante a mudança, suas famílias de instâncias podem ser atualizadas para uma nova geração. Não há necessidade de realizar nenhuma ação para que a atualização ocorra. Para obter mais informações sobre mudanças, consulte [Configuração ideal do tipo de instância para receber atualizações automáticas da família de instâncias](optimal-default-instance-troubleshooting.md).
**nota**
A disponibilidade da família de instâncias varia por Região da AWS. Por exemplo, alguns Região da AWS s podem não ter nenhuma família de instâncias de quarta geração, mas ter famílias de instâncias de quinta e sexta geração.
Ao usar os pacotes de instâncias `default_x86_64` ou `default_arm64`, AWS Batch seleciona famílias de instâncias com base em um equilíbrio entre custo-benefício e desempenho. Embora as instâncias de nova geração geralmente ofereçam melhor relação preço-desempenho, você AWS Batch pode escolher uma família de instâncias de geração anterior se ela fornecer a combinação ideal de disponibilidade, custo e desempenho para sua carga de trabalho. Por exemplo, em um Região da AWS local em que as instâncias c6i e c7i estejam disponíveis, AWS Batch pode selecionar instâncias c6i se elas oferecerem melhor custo-benefício para seus requisitos específicos de trabalho. Para obter mais informações sobre tipos e Região da AWS disponibilidade de AWS Batch instâncias, consulte [Tabela de computação do tipo de instância](instance-type-compute-table.md).
AWS Batch atualiza periodicamente suas instâncias em pacotes padrão para opções mais novas e econômicas. As atualizações acontecem automaticamente sem exigir nenhuma ação de sua parte. Seus workloads continuam em execução durante as atualizações sem interrupção.
**nota**
Ao criar um ambiente de computação, os tipos de instância selecionados para ele devem compartilhar a mesma arquitetura. Por exemplo, você não pode misturar instâncias ARM e x86 no mesmo ambiente de computação.
**nota**
AWS Batch será dimensionado GPUs com base na quantidade necessária em suas filas de trabalho. Para usar o agendamento de GPU, o ambiente computacional deve incluir tipos de instância das famílias `p3`, `p4`, `p5`, `p6`, `g3`, `g3s`, `g4`, `g5` ou `g6`.
1. Para **Estratégia de alocação**, escolha a estratégia de alocação a ser usada ao selecionar tipos de instância na lista de tipos de instância permitidos. **O **BEST\$1FIT\$1PROGRESSIVE** geralmente é a melhor opção para ambientes de computação sob demanda do EC2, SPOT\$1CAPACITY\$1OPTIMIZED e **SPOT\$1PRICE\$1CAPACITY\$1OPTIMIZED** para ambientes de computação EC2 Spot.** Para obter mais informações, consulte [Estratégias de alocação de tipo de instância para AWS Batch](allocation-strategies.md).
1. Expanda **Additional configuration**.
1. (Opcional) Em **Grupo de posicionamento**, insira um nome de grupo de posicionamento para agrupar recursos no ambiente de computação.
1. (Opcional) Em **Par de chaves do EC2**, escolha um par de chaves pública e privada como credenciais de segurança ao se conectar à instância. Para obter mais informações sobre pares de chaves do Amazon EC2, consulte [Pares de chaves do Amazon EC2 e instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html).
1. (Opcional) Para a **configuração do EC2**, escolha o **tipo de imagem** **e os valores de substituição do ID** da imagem para fornecer informações AWS Batch para selecionar Amazon Machine Images (AMIs) para instâncias no ambiente computacional. Se a **substituição do ID da imagem** não for especificada para cada **tipo de imagem**, AWS Batch seleciona uma AMI [otimizada recente do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). Se nenhum **tipo de imagem** for especificado, o padrão será **Amazon Linux 2 para instância** sem GPU e sem AWS Graviton.
**Importante**
Para usar uma AMI personalizada, escolha o tipo de imagem e insira a ID da AMI personalizada na caixa de **substituição de ID da imagem**.
[Amazon Linux 2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2ami)
Padrão para todas as famílias de instâncias AWS baseadas em Graviton (por exemplo,, `C6g` `M6g``R6g`, e`T4g`) e pode ser usado para todos os tipos de instâncias que não sejam de GPU.
[Amazon Linux 2 (GPU)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#gpuami)
Padrão para todas as famílias de instâncias de GPU (por exemplo, `P4` e`G4`) e pode ser usado para todos os tipos de instância não AWS baseados em Graviton.
[Amazon Linux 2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)
AWS Batch é compatível com o Amazon Linux 2023.
O Amazon Linux 2023 não é compatível com instâncias `A1`.
[Amazon Linux 2023 (GPU)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#gpuami)
Padrão para todas as famílias de instâncias de GPU (por exemplo, `P4` e`G4`) e pode ser usado para todos os tipos de instância não AWS baseados em Graviton.
**nota**
A AMI que você escolher para um ambiente de computação deve corresponder à arquitetura dos tipos de instância que você pretende usar para este ambiente. Por exemplo, se o ambiente de computação usar tipos de instância A1, a AMI de recursos de computação escolhida deverá oferecer suporte a instâncias ARM. O Amazon ECS vende as versões x86 e ARM da AMI do Amazon Linux 2 otimizada para Amazon ECS. Para obter mais informações, consulte [AMI do Amazon Linux 2 otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
1. (Opcional) Expandir **Modelos de execução**
1. Em **Modelo de execução padrão**, selecione um modelo de execução existente do Amazon EC2 para configurar seus recursos de computação. A versão padrão do modelo é preenchida automaticamente. Para obter mais informações, consulte [Use os modelos de lançamento do Amazon EC2 com AWS Batch](launch-templates.md).
**nota**
Em um modelo de execução, é possível especificar uma AMI personalizada que você tenha criado.
1. (Opcional) Em **Versão padrão**, insira `$Default`, `$Latest` ou um número de versão específico para ser usado.
**nota**
Nota: se você usar uma variável de substituição (\$1Default ou \$1Latest), será aplicado o número da versão padrão atual ou o número da versão mais recente no momento em que essa configuração for salva. Se a versão padrão ou mais recente mudar no futuro, você deverá atualizar as informações. Elas não serão atualizadas automaticamente.
**Importante**
Se o parâmetro de versão do modelo de execução for `$Default` ou `$Latest`, a versão padrão ou mais recente do modelo de execução especificado será avaliada durante uma atualização de infraestrutura. Se uma ID de AMI diferente for selecionada por padrão ou se a versão mais recente do modelo de execução for selecionada, essa ID de AMI será usada na atualização. Para obter mais informações, consulte [Seleção da AMI durante atualizações de infraestrutura](infrastructure-updates.md#updating-compute-environments-ami).
1. (Opcional) Em **Modelo de execução de substituição**, escolha **Adicionar modelo de execução de substituição**.
1. (Opcional) Em **Modelo de execução**, selecione um modelo de execução existente do Amazon EC2 para usar em tipos e famílias de instâncias específicos.
1. (Opcional) Em **Versão padrão**, insira um número de versão específico para ser usado, `$Default` ou `$Latest`.
**nota**
Se você usar a variável `$Default` ou `$Latest`, o AWS Batch aplicará as informações atuais no momento em que o ambiente computacional for criado. Se a versão padrão ou a versão mais recente forem alteradas no futuro, você deverá atualizar as informações por meio do - [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)ou por meio do Console de gerenciamento da AWS - AWS Batch.
1. (Opcional) Para **Tipos de instância de destino**, selecione o tipo de instância ou a família à qual você deseja aplicar o modelo de execução de substituição.
**nota**
Se você especificar um modelo de execução de substituição, os **Tipos de instância de destino** serão obrigatórios. Para obter mais informações, consulte [LaunchTemplateSpecificationOverride. targetInstanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes).
**nota**
Se o tipo de instância ou a família que você deseja selecionar não aparecer nessa lista, revise as seleções feitas em `Allowed instance types`.
1. Escolha **Próximo**.
1. Na seção **Configuração de rede**:
**Importante**
Recursos de computação precisam de acesso para se comunicar com o endpoint de serviço do Amazon ECS. Isso pode ser feito por meio de uma interface do endpoint da VPC ou por meio dos das instâncias de contêiner que tenham endereços IP públicos.
Para obter mais informações sobre endpoints da VPC de interface, consulte [Endpoints da VPC de interface do Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) no *Manual do Desenvolvedor do Amazon Elastic Container Service*.
Se você não tiver um endpoint da VPC de interface configurado e seus das instâncias de contêiner não tiverem endereços IP públicos, eles 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*. Para obter mais informações, consulte [Crie uma VPC](create-a-vpc.md).
1. Em **Virtual Private Cloud (VPC) ID (Nuvem Privada Virtual Private Cloud)**, escolha uma VPC na qual executar suas instâncias.
1. Em **Sub-redes,** selecione a sub-rede que será usada. Por padrão, todas as sub-redes dentro da VPC selecionadas estão disponíveis.
**nota**
AWS Batch no Amazon EC2 oferece suporte a Locais Zones. Para obter mais informações, consulte [ Zonas Locais](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html?icmpid=docs_ec2_console#concepts-local-zones) no *Guia do usuário do Amazon EC2* e [Clusters do Amazon ECS en zonas locais, zonas do Wavelength, e AWS Outposts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html#clusters-local-zones) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
1. (Opcional) Para **Security groups**, escolha um grupo de segurança a ser anexado às suas instâncias. Por padrão, o grupo de segurança padrão para sua VPC é escolhido.
**nota**
Nota: se você usar uma variável de substituição (\$1Default ou \$1Latest), será aplicado o número da versão padrão atual ou o número da versão mais recente no momento em que essa configuração for salva. Se a versão padrão ou mais recente mudar no futuro, você deverá atualizar as informações. Elas não serão atualizadas automaticamente.
1. Escolha **Próxima página**.
1. Para **Revisar**, reveja as etapas de configuração. Se precisar fazer alterações, escolha **Edit** (Editar). Quando terminar, escolha **Criar ambiente de computação.**
# Tutorial: criar um ambiente de computação não gerenciado usando recursos do Amazon EC2
Conclua as etapas a seguir para criar um ambiente computacional não gerenciado usando recursos do Amazon Elastic Compute Cloud (Amazon EC2).
****
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Na barra de navegação, selecione o Região da AWS a ser usado.
1. Na página **Ambientes de computação** selecione **Criar**.
1. Configure o ambiente.
1. Em **configuração do ambiente de computação**, escolha **Amazon Elastic Compute Cloud (Amazon EC2).**
1. **Em **Tipo de orquestração**, escolha Não gerenciado.**
1. Para **Nome**, especifique um nome exclusivo para seu ambiente de computação. Os nomes podem ter até 128 caracteres. Podem conter letras minúsculas, maiúsculas, números, hifens e (-) e sublinhados (\$1).
1. Em **Função de serviço**, escolha uma função que permita que o AWS Batch serviço faça chamadas para as operações de AWS API necessárias em seu nome.
**nota**
Não é possível usar `AWSServiceRoleForBatch` para ambientes de computação não gerenciados.
1. Em **Máximo v CPUs**, escolha o número máximo de v para o CPUs qual seu ambiente computacional pode ser expandido, independentemente da demanda da fila de trabalhos.
1. (Opcional) Expanda as **Tags**. Para adicionar uma tag, escolha **Adicionar tag**. Insira uma **chave** e um **Valor** opcional. Escolha **Adicionar Tag**. Para obter mais informações, consulte [Marcar com tag os recursos do AWS Batch](using-tags.md).
1. Escolha **Próxima página**.
1. Para **Revisar**, reveja as etapas de configuração. Se precisar fazer alterações, escolha **Edit** (Editar). Quando terminar, escolha **Criar ambiente de computação.**
# Tutorial: criar um ambiente de computação gerenciado usando recursos do Amazon EKS
Conclua as seguintes etapas para criar um ambiente computacional gerenciada usando recursos do Amazon Elastic Kubernetes Service (Amazon EKS).
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Na barra de navegação, selecione o Região da AWS a ser usado.
1. No painel de navegação, escolha **Ambientes de computação**.
1. Escolha **Criar**.
1. Para a **configuração do ambiente de computação**, escolha **Amazon Elastic Kubernetes Service (Amazon EKS**).
1. Para **Nome**, especifique um nome exclusivo para seu ambiente de computação. Os nomes podem ter até 128 caracteres. Podem conter letras minúsculas, maiúsculas, números, hifens e (-) e sublinhados (\$1).
1. Em **Perfil de instância**, escolha um perfil de instância existente que tenha as permissões de IAM necessárias anexadas.
**nota**
Para criar um ambiente computacional no AWS Batch console, escolha um perfil de instância que tenha as `eks:DescribeCluster` permissões `eks:ListClusters` e.
1. Para o **cluster EKS**, escolha um cluster existente do Amazon EKS.
1. Em **Namespace**, insira um Kubernetes namespace para agrupar seus AWS Batch processos no cluster.
1. (Opcional) Expanda as **Tags**. Escolha **Adicionar tag** e, em seguida, insira um par chave-valor.
1. Escolha **Próxima página**.
1. (Opcional) Para **usar instâncias spot do EC2**, ative **Habilitar o uso de instâncias spot** para usar instâncias spot do Amazon EC2.
1. (Somente Spot) Em **Maximum % on-demand price**, escolha a porcentagem máxima que o preço que uma instância spot deve ter em comparação com o preço sob demanda para esse tipo de instância antes que as instâncias sejam executadas. Por exemplo, se o preço máximo for 20%, o preço spot deverá estar abaixo de 20% do preço atual sob demanda para essa instância do EC2. Você sempre paga o menor preço (mercado) e nunca mais do que sua porcentagem máxima. Se você deixar esse campo em branco, o valor padrão será 100% do preço sob demanda.
1. (Somente spot) Para o **perfil de frota spot**, escolha o perfil IAM da frota spot do Amazon EC2 para o ambiente `SPOT` de computação.
**Importante**
Esse perfil é necessário se a estratégia de alocação definida para o `BEST_FIT` ou se a estratégia de alocação não for especificada.
1. (Opcional) Em **Mínimo v CPUs**, escolha o número mínimo de v CPUs que seu ambiente computacional mantém, independentemente da demanda da fila de trabalhos.
1. (Opcional) Em **Máximo v CPUs**, escolha o número máximo de v para CPUs o qual seu ambiente computacional pode ser expandido, independentemente da demanda da fila de trabalhos.
1. (Opcional) Para **reduzir o atraso (minutos)**, escolha o tempo mínimo (em minutos) que AWS Batch mantém as instâncias em execução no ambiente computacional após a conclusão dos trabalhos.
1. Para **Tipos de instância permitidos**, escolha os tipos de instância do Amazon EC2 que podem ser iniciados. Você pode especificar famílias de instâncias para iniciar qualquer tipo de instância dentro dessas famílias (por exemplo `c5`, `c5n`, ou `p3`). Ou você pode especificar tamanhos específicos dentro de uma família (como `c5.8xlarge`). Os tipos de instância Metal não estão nas famílias de instâncias. Por exemplo, `c5` não inclui `c5.metal`.
AWS Batch pode selecionar o tipo de instância para você se você escolher uma das seguintes opções:
+ `optimal` para selecionar tipos de instância (das famílias de instâncias `c4`, `m4`, `r4`, `c5`, `m5` e `r5`) que correspondam à demanda de suas filas de trabalho.
+ `default_x86_64` para selecionar tipos de instância baseados em x86 (das famílias de instâncias m6i, c6i, r6i e c7i) que correspondam à demanda de suas filas de trabalho.
+ `default_arm64` para selecionar tipos de instância baseados em x86 (das famílias de instâncias m6g, c6g, r6g e c7g) que correspondam à demanda de suas filas de trabalho.
**nota**
A partir de 01/11/2025, o comportamento do `optimal` será alterado para corresponder com `default_x86_64`. Durante a mudança, suas famílias de instâncias podem ser atualizadas para uma nova geração. Não há necessidade de realizar nenhuma ação para que a atualização ocorra. Para obter mais informações sobre mudanças, consulte [Configuração ideal do tipo de instância para receber atualizações automáticas da família de instâncias](optimal-default-instance-troubleshooting.md).
**nota**
A disponibilidade da família de instâncias varia por Região da AWS. Por exemplo, alguns Região da AWS s podem não ter nenhuma família de instâncias de quarta geração, mas ter famílias de instâncias de quinta e sexta geração.
Ao usar `default_x86_64` nossos pacotes de `default_arm64` instâncias, AWS Batch seleciona famílias de instâncias com base em um equilíbrio entre custo-benefício e desempenho. Embora as instâncias de nova geração geralmente ofereçam melhor relação preço-desempenho, você AWS Batch pode escolher uma família de instâncias de geração anterior se ela fornecer a combinação ideal de disponibilidade, custo e desempenho para sua carga de trabalho. Por exemplo, em um Região da AWS local em que as instâncias c6i e c7i estejam disponíveis, AWS Batch pode selecionar instâncias c6i se elas oferecerem melhor custo-benefício para seus requisitos específicos de trabalho. Para obter mais informações sobre tipos e Região da AWS disponibilidade de AWS Batch instâncias, consulte [Tabela de computação do tipo de instância](instance-type-compute-table.md).
AWS Batch atualiza periodicamente suas instâncias em pacotes padrão para opções mais novas e econômicas. As atualizações acontecem automaticamente sem exigir nenhuma ação de sua parte. Seus workloads continuam em execução durante as atualizações sem interrupção
**nota**
Ao criar um ambiente de computação, os tipos de instância selecionados para ele devem compartilhar a mesma arquitetura. Por exemplo, você não pode misturar instâncias ARM e x86 no mesmo ambiente de computação.
**nota**
AWS Batch será dimensionado GPUs com base na quantidade necessária em suas filas de trabalho. Para usar o agendamento de GPU, o ambiente computacional deve incluir tipos de instância das famílias `p3`, `p4`, `p5`, `p6`, `g3`, `g3s`, `g4`, `g5` ou `g6`.
1. (Opcional) Expanda **Configuração adicional**.
1. (Opcional) Em **Grupo de posicionamento**, insira um nome de grupo de posicionamento para agrupar recursos no ambiente de computação.
1. Em **Estratégia de alocação**, escolha **BEST\$1FIT\$1PROGRESSIVE**.
1. (Opcional) Para a configuração **Amazon Machine Images (AMIs), escolha Adicionar a configuração** **Amazon Machine Images (amis)**.
Você pode usar uma AMI Amazon Linux otimizada para Amazon EKS ou uma AMI personalizada.
1. Para usar uma [AMI do Amazon Linux otimizada para Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html):
1. Em **Tipo de imagem**, selecione uma das opções a seguir.
+ [Amazon Linux 2](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): padrão para todas as famílias de instâncias AWS baseadas em Graviton (por exemplo,, `C6g` `M6g``R6g`, e`T4g`) e pode ser usado para todos os tipos de instâncias que não sejam de GPU.
+ [Amazon Linux 2 (acelerado)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): padrão para todas as famílias de instâncias de GPU (por exemplo, `P4` e`G4`) e pode ser usado para todos os tipos de instância que não sejam AWS baseados em Graviton.
+ [Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): AWS Batch suporta Amazon Linux 2023 (AL2023).
+ [Amazon Linux 2023 (acelerado)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): famílias de instâncias de GPU e pode ser usado para todos os tipos de instâncias não baseadas no AWS Graviton.
1. Em **Versão Kubernetes**, insira um [número de versão Kubernetes](supported_kubernetes_version.md).
1. Para usar uma AMI personalizada:
1. Em **Tipo de imagem**, escolha o tipo de AMI no qual a AMI personalizada se baseia:
+ [Amazon Linux 2](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): padrão para todas as famílias de instâncias AWS baseadas em Graviton (por exemplo,, `C6g` `M6g``R6g`, e`T4g`) e pode ser usado para todos os tipos de instâncias que não sejam de GPU.
+ [Amazon Linux 2 (acelerado)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): padrão para todas as famílias de instâncias de GPU (por exemplo, `P4` e`G4`) e pode ser usado para todos os tipos de instância que não sejam AWS baseados em Graviton.
+ [Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): AWS Batch suporte AL2023.
+ [Amazon Linux 2023 (acelerado)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): famílias de instâncias de GPU e pode ser usado para todos os tipos de instâncias não baseadas no AWS Graviton.
1. Para **Substituição de ID da imagem**, insira o ID da AMI personalizada.
1. Em **Versão Kubernetes**, insira um [número de versão Kubernetes](supported_kubernetes_version.md).
1. (Opcional) Em **Modelo de execução**, escolha um [modelo de execução](eks-launch-templates.md) existente.
1. (Opcional) Em **Launch template version**, insira **\$1Default**, **\$1Latest** ou um número de versão.
1. (Opcional) Em **Modelo de execução de substituição**, para adicionar uma substituição, escolha **Adicionar Modelo de execução de substituição**:
1. (Opcional) Em **Modelo de execução**, escolha o modelo de execução ao qual adicionar a substituição.
1. (Opcional) Em **Versão do modelo de lançamento**, escolha o número da versão do modelo de lançamento, `$Default` ou `$Latest`.
1. (Opcional) Em **tipos de instâncias de destino**, escolha o tipo de instância ou a família à qual essa substituição deve ser aplicada. Isso pode ser direcionado somente aos tipos e famílias de instâncias que estão incluídos nos **Tipos de instância permitidos**.
1. (Opcional) Em **userdataType**, escolha a inicialização do nó EKS. Use esse campo somente se você tiver uma AMI especificada no modelo de execução ou como substituição do modelo de execução. **Escolha **EKS\$1NODEADM para personalizar com AMIs base em `EKS_AL2023` ou `EKS_AL2023_NVIDIA` EKS\$1BOOSTRAP\$1SH** para e.** `EKS_AL2` `EKS_AL_NVIDIA` O valor padrão é **EKS\$1BOOSTRAP\$1SH**.
Você usaria **UserDataType** quando tivesse um [ambiente misto](mixed-ami-environments.md) em que estivesse usando ambos AL2 e de forma personalizada AMIs no mesmo ambiente AL2023 computacional.
1. Escolha **Próxima página**.
1. Em **Virtual Private Cloud (VPC) ID (Nuvem Privada Virtual Private Cloud)**, escolha uma VPC na qual executar as instâncias.
1. Em **Sub-redes,** selecione a sub-rede que será usada. Por padrão, todas as sub-redes dentro da VPC selecionadas estão disponíveis.
**nota**
AWS Batch no Amazon EKS é compatível com Locais Zones. Para obter mais informações, consulte [Amazon EKS and AWS Local Zones](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html) no *Guia do usuário do Amazon EKS*.
1. (Opcional) Para **Security groups**, escolha um grupo de segurança a ser anexado às suas instâncias. Por padrão, o grupo de segurança padrão para sua VPC é escolhido.
1. Escolha **Próxima página**.
1. Para **Revisar**, reveja as etapas de configuração. Se precisar fazer alterações, escolha **Edit** (Editar). Quando terminar, escolha **Criar ambiente de computação.**
# Tutorial: Crie um ambiente computacional não gerenciado usando os recursos do Amazon EKS
Conclua as etapas a seguir para criar um ambiente computacional não gerenciado usando os recursos do Amazon Elastic Kubernetes Service (Amazon EKS).
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Na barra de navegação na parte superior da página, selecione a opção Região da AWS a ser usada.
1. No painel de navegação, escolha **Ambientes de computação**.
1. Escolha **Criar**.
1. Configure o ambiente.
1. Para a **configuração do ambiente de computação**, escolha **Amazon Elastic Kubernetes Service (Amazon EKS**).
1. **Em **Tipo de orquestração**, escolha Não gerenciado.**
1. Para **Nome**, especifique um nome exclusivo para seu ambiente de computação. Os nomes podem ter até 128 caracteres. Podem conter letras minúsculas, maiúsculas, números, hifens e (-) e sublinhados (\$1).
1. Para o **cluster EKS**, escolha um cluster existente do Amazon EKS. Para criar um novo cluster EKS, siga as etapas na [página Criar um cluster do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html).
1. Em **Namespace**, insira um Kubernetes namespace para agrupar seus AWS Batch processos no cluster.
1. (Opcional) Para **Máximo v CPUs**, especifique o número máximo de v CPUs disponível para agendamento de trabalhos a partir de sua capacidade provisionada.
1. (Opcional) Expanda as **Tags**. Escolha **Adicionar tag** e, em seguida, insira um par chave-valor.
1. Escolha **Próxima página**.
1. Para **Revisar**, reveja as etapas de configuração. Se precisar fazer alterações, escolha **Edit** (Editar). Quando terminar, escolha **Criar ambiente de computação.**
**Atribuição de nós de cluster do Amazon EKS a um ambiente computacional não gerenciado**
Depois de criar o ambiente computacional não gerenciado, você precisa rotular seus nós do Amazon EKS com o ambiente computacional UUID.
Primeiro, obtenha o UUID do ambiente computacional a partir do resultado da `DescribeComputeEnvironments` API:
```
$ aws batch describe-compute-environments \
--compute-environments unmanagedEksCE \
--query "computeEnvironments[].{name: computeEnvironmentName, uuid: uuid}"
```
Obtenha as informações do nó:
```
kubectl get nodes -o name
```
Identifique os nós com o UUID do ambiente AWS Batch computacional:
```
kubectl label batch.amazonaws.com/compute-environment-uuid=uuid
```
# Recurso: modelo de ambiente de computação
O exemplo a seguir mostra um Modelo do Ambiente de Computação vazio. É possível usar esse modelo para criar seu ambiente de computação que pode ser salvo em um arquivo e usado com a opção `--cli-input-json` AWS CLI. Para obter mais informações sobre esses parâmetros, consulte [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) no *AWS Batch API Reference*.
**nota**
Você pode gerar o modelo de ambiente de computação com o comando da AWS CLI a seguir.
```
$ aws batch create-compute-environment --generate-cli-skeleton
```
```
{
"computeEnvironmentName": "",
"type": "UNMANAGED",
"state": "DISABLED",
"unmanagedvCpus": 0,
"computeResources": {
"type": "EC2",
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"minvCpus": 0,
"maxvCpus": 0,
"desiredvCpus": 0,
"instanceTypes": [
""
],
"imageId": "",
"subnets": [
""
],
"securityGroupIds": [
""
],
"ec2KeyPair": "",
"instanceRole": "",
"tags": {
"KeyName": ""
},
"placementGroup": "",
"bidPercentage": 0,
"spotIamFleetRole": "",
"launchTemplate": {
"launchTemplateId": "",
"launchTemplateName": "",
"version": ""
},
"ec2Configuration": [
{
"imageType": "",
"imageIdOverride": "",
"imageKubernetesVersion": ""
}
]
},
"serviceRole": "",
"tags": {
"KeyName": ""
},
"eksConfiguration": {
"eksClusterArn": "",
"kubernetesNamespace": ""
}
}
```
# Tabela de computação do tipo de instância
A tabela a seguir lista a Região da AWS palavra-chave da família de instâncias e as famílias de instâncias disponíveis. AWS Batch tentará alocar uma instância da família mais recente, mas como a disponibilidade da família de instâncias varia, Região da AWS você pode obter uma geração anterior da família de instâncias.
**default\$1x86\$164**
| Região | Famílias de instâncias |
| --- | --- |
| Tudo isso Região da AWSé esse apoio [AWS Batch](https://docs.aws.amazon.com/general/latest/gr/batch.html) | m6i, c6i, r6i c7i |
**default\$1arm64**
| Região | Famílias de instâncias |
| --- | --- |
| Tudo isso Região da AWSé esse apoio [AWS Batch](https://docs.aws.amazon.com/general/latest/gr/batch.html) | m6g, c6g, r6g c7g |
**Ideal**
| Região | Famílias de instâncias |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/instance-type-compute-table.html) | m4, c4, r4 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/instance-type-compute-table.html) | m5, c5, r5 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/instance-type-compute-table.html) | m6, c6, r6 |
# Atualize um ambiente computacional no AWS Batch
AWS Batch fornece várias estratégias para atualizar ambientes computacionais, cada uma projetada para cenários e requisitos específicos de atualização. Essas abordagens usam a mesma API de atualização subjacente, mas representam métodos prescritivos diferentes para gerenciar atualizações de forma eficaz. Você pode gerenciar essas atualizações usando o AWS Batch console ou AWS CLI o. A compreensão dessas estratégias ajuda você a escolher o método mais adequado às suas necessidades e, ao mesmo tempo, minimizar a interrupção de seus workloads.
Este tópico dá uma visão geral das estratégias de atualização disponíveis e dá orientações sobre quando cada abordagem deve ser usada. Para obter procedimentos detalhados, consulte as seções individuais de cada estratégia de atualização.
**Importante**
AWS Batch cria e gerencia vários AWS recursos em seu nome e dentro da sua conta, incluindo modelos de lançamento do Amazon EC2, grupos do Amazon EC2 Auto Scaling, frotas spot do Amazon EC2 e clusters do Amazon ECS. Esses recursos gerenciados são configurados especificamente para garantir a operação ideal do AWS Batch . A modificação manual desses recursos AWS Batch gerenciados, a menos que seja explicitamente declarada na AWS Batch documentação, pode resultar em comportamento inesperado, incluindo ambientes `INVALID` computacionais, comportamento de escalabilidade de instâncias abaixo do ideal, atraso no processamento da carga de trabalho ou custos inesperados. Essas modificações manuais não podem ser sustentadas de forma determinística pelo serviço do AWS Batch . Sempre use o AWS Batch console compatível AWS Batch APIs ou para gerenciar seus ambientes computacionais.
As modificações manuais não suportadas incluem executar suas próprias tarefas ou serviços do Amazon ECS em clusters AWS Batch gerenciados do Amazon ECS ou iniciar processos, daemons ou serviços adicionais diretamente em instâncias gerenciadas. AWS Batch AWS Batch assume controle total dos recursos computacionais em um ambiente computacional gerenciado e pode encerrar instâncias, interromper tarefas ou escalar o cluster a qualquer momento. Qualquer carga de trabalho executada fora do envio de AWS Batch trabalhos nesses recursos gerenciados pode ser interrompida sem aviso prévio. A execução de AWS Batch cargas de trabalho que não são em clusters e instâncias AWS Batch gerenciados também pode interferir no agendamento de AWS Batch trabalhos e no escalonamento de instâncias.
**Topics**
+ [Estratégias de atualização do ambiente computacional](#update-strategies)
+ [Escolhendo a estratégia de atualização correta](#choosing-update-strategies)
+ [Considerações sobre a atualização AMI](#ami-update-considerations)
+ [Executar atualizações de escalabilidade](scaling-updates.md)
+ [Realizar atualizações da infraestrutura](infrastructure-updates.md)
+ [Execute blue/green atualizações para ambientes computacionais](blue-green-updates.md)
## Estratégias de atualização do ambiente computacional
Quando você usa atualizações de escalabilidade ou infraestrutura, seu ambiente computacional é atualizado no local. Para a estratégia de blue/green atualização, você está criando um novo ambiente computacional (verde) e, em seguida, migrando sua carga de trabalho do ambiente computacional antigo (azul) para o novo ambiente computacional (verde).
AWS Batch fornece três estratégias diferentes para atualizações do ambiente computacional:
Atualizações de escalabilidade
As atualizações de escalabilidade ajustam a capacidade do seu ambiente computacional adicionando ou removendo instâncias sem substituir as existentes. Esse é o cenário de atualização mais rápido e não requer tempo de inatividade. Use atualizações de escalabilidade quando precisar alterar as configurações de capacidade (vCPUs). Essas atualizações geralmente são concluídas em minutos.
As atualizações Fargate são realizadas usando os mesmos procedimentos das atualizações de escalabilidade. Para obter mais informações, consulte [Executar atualizações de escalabilidade](scaling-updates.md).
Atualizações da infraestrutura
As atualizações de infraestrutura substituem as instâncias em seu ambiente computacional por novas instâncias com configurações atualizadas. Essas atualizações exigem configurações específicas de perfil de serviço e estratégia de alocação, mas oferecem um tempo de inatividade mínimo, com a possibilidade de interrupção dos trabalhos em execução. Use atualizações de infraestrutura quando precisar modificar tipos de instância, configuração de AMI, configurações de rede, perfil de serviço, estado do ambiente ou outros componentes da infraestrutura. Essas atualizações geralmente são concluídas em 10 a 30 minutos, dependendo da conclusão do trabalho.
Para obter mais informações, consulte [Realizar atualizações da infraestrutura](infrastructure-updates.md).
Atualizações azul/verdes
Blue/green updates create a new compute environment alongside your existing environment, allowing gradual workload transition with zero downtime. This approach provides the safest update path but requires running two environments temporarily. Use blue/greenatualiza quando você não precisa de tempo de inatividade, quer testar as alterações antes da implantação completa, exige capacidade de reversão rápida ou está usando configurações não suportadas para atualizações de infraestrutura. O tempo de conclusão é variável e controlado por você.
Para obter mais informações, consulte [Execute blue/green atualizações para ambientes computacionais](blue-green-updates.md).
## Escolhendo a estratégia de atualização correta
Use este guia de decisão para selecionar a estratégia de atualização mais adequada às suas necessidades:
### Escolha atualizações de escalabilidade quando
Escolha a estratégia de atualização de escalabilidade quando precisar apenas ajustar a capacidade computacional (vCPUs). As atualizações de escalabilidade são ideais quando você precisa de atualizações rápidas, sem tempo de inatividade e sem necessidade de alterações na configuração da infraestrutura.
Para ver os procedimentos detalhados, consulte [Executar atualizações de escalabilidade](scaling-updates.md).
### Escolha atualizações de infraestrutura quando
Escolha a estratégia de atualização da infraestrutura quando precisar modificar tipos de instância, configurações de AMI, perfil de serviço, estado do ambiente ou configuração de rede. Seu ambiente deve usar a função *AWSServiceRoleForBatch*vinculada ao serviço e uma estratégia de alocação de`BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` ou. `SPOT_PRICE_CAPACITY_OPTIMIZED` As atualizações de infraestrutura funcionam bem quando alguma interrupção do trabalho é aceitável durante a atualização e você deseja atualizações automáticas para a AMI mais recente otimizada para Amazon ECS.
Para ver os procedimentos detalhados, consulte [Realizar atualizações da infraestrutura](infrastructure-updates.md).
### Escolha blue/green atualizações quando
Escolha a estratégia de blue/green atualização quando não for necessário tempo de inatividade para suas cargas de trabalho ou quando você precisar testar as alterações antes de fazer a transição das cargas de trabalho de produção. Essa abordagem é essencial quando a capacidade de reversão rápida é importante, seu ambiente usa a estratégia de `BEST_FIT` alocação ou seu ambiente não usa a função vinculada ao *AWSServiceRoleForBatch*serviço. Blue/green atualizações também são a melhor opção quando você usa atualizações personalizadas AMIs que exigem atualizações manuais ou precisam fazer grandes alterações na configuração.
Para ver os procedimentos detalhados, consulte [Execute blue/green atualizações para ambientes computacionais](blue-green-updates.md).
## Considerações sobre a atualização AMI
A abordagem de atualização AMIs depende da configuração do seu ambiente computacional.
### Atualização da AMI padrão AWS Batch fornecida para a mais recente
AWS Batch pode atualizar para a AMI otimizada para Amazon ECS mais recente durante as atualizações de [infraestrutura](infrastructure-updates.md) quando todas essas condições forem atendidas:
**nota**
Após a conclusão da atualização da infraestrutura, `updateToLatestImageVersion` é definido como `false`. Para iniciar outra atualização, `updateToLatestImageVersion` deve ser definido como `true`.
+ O ambiente computacional usa a função vinculada ao *AWSServiceRoleForBatch*serviço.
+ A estratégia de alocação está definida como`BEST_FIT_PROGRESSIVE`,`SPOT_CAPACITY_OPTIMIZED`, ou`SPOT_PRICE_CAPACITY_OPTIMIZED`.
+ Nenhuma ID de AMI está explicitamente especificada em`imageId`,`imageIdOverride`, ou modelo de lançamento.
+ A `updateToLatestImageVersion` é definida como `true`.
### Atualizações da AMI usando a blue/green implantação
Você deve usar a blue/green implantação para atualizar AMIs nesses cenários:
+ Ao usar uma versão específica da AMI otimizada para Amazon ECS.
+ Quando o ID AMI é especificado em qualquer um dos seguintes:
+ Modelo de lançamento (é necessário atualizar o modelo ou removê-lo).
+ O `imageId` parâmetro.
+ O `imageIdOverride` parâmetro na configuração do EC2.
+ Ao usar a estratégia de `BEST_FIT` alocação (não suporta atualizações de infraestrutura).
+ Quando não estiver usando a função *AWSServiceRoleForBatch*[vinculada ao serviço](using-service-linked-roles-batch-general.md).
### Atualizações de AMI para uma AMI personalizada
Se você especificar uma AMI personalizada no modelo de execução do ambiente computacional, o `imageId` parâmetro ou o `imageIdOverride` parâmetro na configuração do EC2 não AWS Batch atualizará automaticamente sua AMI personalizada durante as atualizações da infraestrutura. Você pode atualizar um ID de AMI personalizado especificando o novo ID no parâmetro usado originalmente durante a criação do Compute Environment. Se quiser mudar para o uso de uma AMI AWS Batch fornecida, você pode fazer isso removendo a ID personalizada da AMI na atualização do seu ambiente computacional.
# Executar atualizações de escalabilidade
As atualizações de escalabilidade ajustam a capacidade do seu ambiente computacional adicionando ou removendo instâncias. Essa é a estratégia de atualização mais rápida e não exige a substituição das instâncias existentes. As atualizações de escalabilidade funcionam com qualquer tipo de perfil de serviço e estratégia de alocação, tornando-as a opção de atualização mais flexível.
## Alterações que acionam uma atualização de escalabilidade
Quando você modifica somente as configurações a seguir, AWS Batch executa uma atualização de escalabilidade. Se você modificar qualquer uma dessas configurações junto com outras configurações do ambiente computacional, em vez disso, AWS Batch executará uma [atualização de infraestrutura](infrastructure-updates.md).
As configurações a seguir acionam atualizações de escalabilidade quando modificadas exclusivamente:
+ `desiredvCpus`— Define o número alvo de v CPUs para o ambiente.
+ `maxvCpus`— Define o número máximo de v CPUs que pode ser lançado.
+ `minvCpus`— Especifica o número mínimo de v CPUs a ser mantido.
+ `minScaleDownDelayMinutes`— especifica o tempo mínimo (em minutos) que AWS Batch mantém as instâncias em execução no ambiente computacional após a conclusão dos trabalhos.
**nota**
`minScaleDownDelayMinutes`não se aplica às instâncias que estão sendo substituídas durante as atualizações da infraestrutura.
Para ambientes de computação Fargate, você também pode modificar essas configurações para atualizações de escalabilidade:
+ `securityGroupIds`— Grupo de segurança IDs para o ambiente computacional.
+ `subnets`: sub-redes para o ambiente de computação.
**nota**
Recomendamos não usar `desiredvCpus` para iniciar uma atualização de escalabilidade, pois AWS Batch isso se ajustará dinamicamente. `desiredvCpus` Em vez disso, você deve atualizar o `minvCpus`.
Ao atualizar o `desiredvCpus`, o valor deve estar entre `minvCpus` e `maxvCpus`. O novo valor deve ser maior ou igual ao valor `desiredvCpus` atual. Para obter mais informações, consulte [Mensagem de erro ao atualizar a configuração `desiredvCpus`](error-desired-vcpus-update.md).
**Importante**
Se você modificar qualquer uma dessas configurações de escalabilidade junto com outras configurações do ambiente computacional (como tipos de instância IDs, AMI ou modelos de execução), AWS Batch executará uma atualização de infraestrutura em vez de uma atualização de escalabilidade. As atualizações da infraestrutura demoram mais e podem substituir as instâncias existentes.
------
#### [ Performing scaling updates using the Console de gerenciamento da AWS ]
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. No painel de navegação, escolha **Ambientes** e, então, a aba **Ambientes de computação**.
1. Selecione o ambiente computacional a atualizar.
1. Escolha **Ações** e então **Editar**.
1. Modifique uma ou mais das [configurações que oferecem suporte a atualizações de escalabilidade](#scaling-updates-triggers). Por exemplo:
+ Em **Mínimo v CPUs**, insira o número mínimo de CPUs v.
+ Em **Desejado v CPUs**, insira o número desejado de CPUs v.
+ Em **Máximo v CPUs**, insira o número máximo de CPUs v.
1. Escolha **Salvar alterações**.
1. Monitore o status do ambiente de computação. A atualização deve ser concluída rapidamente, pois envolve apenas operações de escalonamento.
------
#### [ Performing scaling updates using the AWS CLI ]
Use o comando **update-compute-environment** para realizar atualizações de escalabilidade. Os dois exemplos a seguir demonstram operações comuns de escalabilidade. Você pode modificar uma ou mais das seguintes [configurações que oferecem suporte a atualizações de escalabilidade](#scaling-updates-triggers)
+ Este exemplo atualiza o v desejado, mínimo e máximoCPUs:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources minvCpus=2,maxvCpus=8
```
------
## Monitorar atualizações de escalabilidade
Monitore suas atualizações de escalabilidade usando o AWS Batch console para ver o status do ambiente computacional e verificar a contagem de instâncias e as métricas da vCPU. Você também pode usar o **describe-compute-environments** comando AWS CLI with the para verificar o status e monitorar contagens de instâncias e valores de vCPU.
# Realizar atualizações da infraestrutura
As atualizações de infraestrutura substituem as instâncias em seu ambiente computacional por novas instâncias com configurações atualizadas. Essa estratégia de atualização leva mais tempo do que escalar as atualizações e exige configurações específicas do perfil de serviço e da estratégia de alocação. As atualizações de infraestrutura fornecem uma maneira de modificar as configurações fundamentais do ambiente computacional e, ao mesmo tempo, manter a disponibilidade do serviço.
**Importante**
As atualizações de infraestrutura exigem a função *AWSServiceRoleForBatch*vinculada ao serviço e uma estratégia de alocação de`BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` ou. `SPOT_PRICE_CAPACITY_OPTIMIZED` Se seu ambiente não atender a esses requisitos, use blue/green atualizações em vez disso.
## Mudanças que acionam atualizações de infraestrutura
Quando você modifica qualquer uma das configurações a seguir, AWS Batch executa uma atualização de infraestrutura. As atualizações de infraestrutura também ocorrem quando você modifica essas configurações junto com as configurações de atualização de escala.
As configurações a seguir acionam atualizações de infraestrutura:
**Configuração de computação**
+ `allocationStrategy`— Determina como AWS Batch seleciona os tipos de instância.
+ `instanceTypes`: especifica quais tipos de instância do EC2 usar.
+ `bidPercentage`: porcentagem máxima do preço sob demanda para instâncias spot.
+ `type`: tipo de ambiente computacional (`EC2` ou `SPOT`).
**Configuração da AMI e lançamento**
+ `imageId`: AMI específica para usar em instâncias.
+ `ec2Configuration`: configuração do EC2, incluindo `imageIdOverride`.
+ `launchTemplate`: configurações do modelo de execução do EC2.
+ `ec2KeyPair`: par de chaves SSH para acesso a instância.
+ `updateToLatestImageVersion`: configuração de atualizações automáticas da AMI.
**Redes e segurança**
+ `subnets`: sub-redes VPC em que as instâncias são lançadas (para ambientes de computação EC2).
+ `securityGroupIds`: grupos de segurança para instâncias (para ambientes de computação EC2).
+ `placementGroup`: configuração do grupo de posicionamento do EC2.
**Outras configurações**
+ `instanceRole`: perfil do IAM para instâncias do EC2.
+ `tags`: tags aplicadas a instâncias do EC2.
**Importante**
Se você modificar qualquer configuração de atualização de infraestrutura junto com as configurações de atualização de escalabilidade (como `desiredvCpus`, `maxvCpus` ou `minvCpus`), AWS Batch executará uma atualização de infraestrutura. Atualizações de infraestrutura levam mais tempo do que atualizações de escalabilidade.
## Seleção da AMI durante atualizações de infraestrutura
Durante uma atualização de infraestrutura, o ID da AMI do ambiente computacional pode mudar, dependendo se AMIs está especificado em qualquer uma dessas três configurações. AMIs são especificados em `imageId` (in`computeResources`), `imageIdOverride` (in`ec2Configuration`) ou no modelo de lançamento especificado em`launchTemplate`. Suponha que nenhuma AMI IDs esteja especificada em nenhuma dessas configurações e a `updateToLatestImageVersion` configuração seja`true`. Em seguida, a AMI otimizada mais recente do Amazon ECS suportada pela AWS Batch é usada para qualquer atualização de infraestrutura.
Se uma ID de AMI for especificada em pelo menos uma dessas configurações, a atualização dependerá de qual configuração forneceu a ID de AMI usada antes da atualização. Quando você cria um ambiente de computação, a prioridade para selecionar uma ID de AMI é primeiro o modelo de execução, depois a configuração `imageId` e, finalmente, a configuração `imageIdOverride`. No entanto, se a ID da AMI usado for do modelo de execução, a atualização das configurações `imageIdOverride` ou `imageId` não a atualizará. A única maneira de atualizar uma ID de AMI selecionada no modelo de execução é atualizando o modelo de execução. Se o parâmetro de versão do modelo de execução for `$Default` ou `$Latest`, a versão padrão ou mais recente do modelo de execução especificado será avaliada. Se uma ID de AMI diferente for selecionada por padrão ou se a versão mais recente do modelo de execução for selecionada, essa ID de AMI será usada na atualização.
Se o modelo de execução não foi usado para selecionar a ID da AMI, a ID da AMI especificada nos parâmetros `imageId` ou `imageIdOverride` será usada. Se ambos forem especificados, a ID da AMI especificada no parâmetro `imageIdOverride` será usada.
Suponha que o ambiente de computação use uma ID de AMI especificada pelos parâmetros `imageId`, `imageIdOverride`, ou `launchTemplate` e você queira usar a AMI otimizada mais recente do Amazon ECS compatível com AWS Batch. Em seguida, a atualização deve remover as configurações que forneceram a AMI IDs. Para `imageId`, isso requer a especificação de uma string vazia para esse parâmetro. Para `imageIdOverride`, isso requer a especificação de uma string vazia para o parâmetro `ec2Configuration`.
Se o ID da AMI veio do modelo de lançamento, você pode mudar para a AMI otimizada mais recente do Amazon ECS que é suportada AWS Batch por uma das seguintes formas:
+ Remova o modelo de execução especificando uma string vazia para o parâmetro `launchTemplateId` ou `launchTemplateName`. Isso remove todo o modelo de lançamento, em vez de apenas a ID da AMI.
+ Se a versão atualizada do modelo de lançamento não especificar uma ID de AMI, o parâmetro `updateToLatestImageVersion` deverá ser definido como `true`.
## Manuseio de trabalhos durante atualizações
Configure como os trabalhos em execução são tratados durante uma atualização de infraestrutura usando a política de atualização. Quando você define `terminateJobsOnUpdate=true`, os trabalhos em execução são encerrados imediatamente, a configuração `jobExecutionTimeoutMinutes` é ignorada e a atualização prossegue assim que as instâncias podem ser substituídas. Quando você define `terminateJobsOnUpdate=false`, os trabalhos em execução continuam pelo período de tempo limite especificado com um tempo limite padrão de 30 minutos, e os trabalhos são encerrados se excederem o tempo limite.
**nota**
Para repetir trabalhos que são encerrados durante uma atualização, configure uma estratégia de repetição do trabalho. Para obter mais informações, consulte [Repetições de trabalho automatizadas](job_retries.md).
------
#### [ Performing infrastructure updates using the Console de gerenciamento da AWS ]
**nota**
Para apenas atualizar para a versão mais recente da AMI no console, consulte[Atualização das versões da AMI](managing-ami-versions.md#updating-ami-versions).
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. No painel de navegação, escolha **Ambientes** e, em seguida, **Ambientes de computação**.
1. Selecione o ambiente computacional a atualizar.
1. Escolha **Ações** e então **Editar**.
1. Na seção **Atualizar comportamento**, configure como os trabalhos em execução são tratados:
+ Escolha **Atualizar AMI para a versão mais recente** para atualizar a AMI para a versão mais recente.
+ Escolha **Encerrar trabalhos imediatamente na atualização** para encerrar trabalhos quando o processo de atualização for executado.
+ Em **Tempo limite de execução do trabalho**, insira o número de minutos de espera antes de iniciar o processo de atualização.
1. Modifique uma ou mais das [configurações que exigem atualizações de infraestrutura](#infrastructure-updates-triggers). Por exemplo:
+ **Função da instância**
+ **Usar instâncias spot EC2**
+ **Tipos de instância permitidos**
+ **Grupo de colocação**
+ **EC2 key pair**
+ **Configuração do EC2**
+ **Modelos de inicialização**
+ **Sub-redes**
+ **Grupos de segurança**
1. Escolha **Salvar alterações**.
1. Monitore o status do ambiente de computação. O ambiente exibirá `UPDATING` durante o processo de atualização.
------
#### [ Performing infrastructure updates using the AWS CLI ]
Use o comando **update-compute-environment** com uma alteração em uma ou mais das [configurações que exigem atualizações de infraestrutura](#infrastructure-updates-triggers). Os três exemplos a seguir são operações comuns de infraestrutura.
+ Este exemplo atualiza os tipos de instância e configura a política de atualização:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources instanceTypes=default_x86_64 \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=30
```
+ Este exemplo atualiza as sub-redes e os grupos de segurança da VPC:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources subnets=subnet-abcd1234,subnet-efgh5678 securityGroupIds=sg-abcd1234 \
--update-policy terminateJobsOnUpdate=true
```
+ Este exemplo permite atualizações automáticas da AMI mais recente, otimizada para o Amazon ECS:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources updateToLatestImageVersion=true \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=60
```
------
## Monitorando as atualizações da infraestrutura
Monitore suas atualizações de infraestrutura usando o AWS Batch console para observar a alteração do status do ambiente computacional`UPDATING`, monitorar o progresso da substituição da instância e verificar se há falhas nas atualizações. A atualização é bem-sucedida quando o estado do ambiente computacional é `VAILD`. Você também pode usar CloudWatch para rastrear eventos de encerramento de instâncias e monitorar os estados do trabalho durante a atualização. Com o AWS CLI, use o **describe-compute-environments** comando para verificar o status e monitorar os eventos do ciclo de vida da instância.
# Execute blue/green atualizações para ambientes computacionais
Uma blue/green atualização é uma estratégia de atualização que reduz o tempo de inatividade e o risco criando um novo ambiente computacional (verde) junto com seu ambiente computacional existente (azul). Essa abordagem permite que você faça a transição gradual das cargas de trabalho para o novo ambiente, mantendo o ambiente existente operacional. Blue/green as atualizações fornecem o caminho de atualização mais seguro e funcionam com qualquer tipo de função de serviço ou estratégia de alocação.
## Visão geral do
As atualizações azul/verde oferecem várias vantagens que as tornam ideais para ambientes de produção. Elas fornecem *zero tempo de inatividade*, mantendo seus workloads em execução contínua durante o processo de atualização. A abordagem permite recursos como *reversão fácil*, permitindo que você volte rapidamente para o ambiente original se surgirem problemas. Você pode implementar uma estratégia de *transição gradual*, verificando o desempenho do novo ambiente antes de mudar totalmente seus workloads de produção. Esse método também oferece excelente *mitigação de riscos*, pois o ambiente original permanece inalterado e operacional até que você decida removê-lo.
### Quando blue/green atualizações são necessárias
Você deve usar blue/green as atualizações nas seguintes situações:
+ Quando seu ambiente computacional usa a estratégia de `BEST_FIT` alocação (não suporta atualizações de infraestrutura).
+ Quando seu ambiente computacional não usa a função vinculada ao *AWSServiceRoleForBatch*serviço.
+ Quando você precisa fazer a transição entre diferentes tipos de função de serviço.
### Quando blue/green as atualizações são recomendadas
Recomendamos blue/green atualizações para ambientes de produção em que o tempo de inatividade zero é essencial para suas cargas de trabalho. Essa abordagem funciona bem quando você precisa testar novas configurações antes de fazer a transição dos workloads de produção, garantindo que as alterações atendam aos seus requisitos de desempenho e confiabilidade. Escolha blue/green atualizações quando a capacidade de reversão rápida for importante para suas operações, especialmente se você estiver atualizando de forma personalizada AMIs com alterações significativas. Esse método também é ideal quando você deseja validar as características de desempenho e o comportamento antes de se comprometer totalmente com as mudanças, proporcionando confiança em seu processo de atualização.
### Pré-requisitos
Antes de realizar uma blue/green atualização, verifique se você tem:
+ [Permissões apropriadas do IAM](IAM_policies.md) para criar e gerenciar ambientes computacionais.
+ Acesso para visualizar e modificar as configurações da fila de trabalhos.
+ Estratégias de repetição de trabalhos configurados para suas definições de trabalhos para lidar com possíveis falhas durante a transição. Para obter mais informações, consulte [Repetições de trabalho automatizadas](job_retries.md).
+ O AMI ID para o novo ambiente computacional. Ele pode ser:
+ Uma versão recente e aprovada da AMI otimizada do Amazon ECS (usada por padrão).
+ Uma AMI personalizada que atende à especificação da AMI da instância de contêiner do Amazon ECS. Ao usar uma AMI personalizada, você pode especificá-la em uma das formas a seguir:
+ Usando o campo de **substituição do ID da imagem** na configuração do EC2.
+ Especificando isso em um modelo de lançamento.
Para obter mais informações sobre a criação personalizada AMIs, consulte[Tutorial: criar uma AMI de recurso de computação](create-batch-ami.md).
Antes de criar o novo ambiente, você precisa registrar a configuração do seu ambiente computacional existente. Você pode fazer isso usando o Console de gerenciamento da AWS ou AWS CLI o.
**nota**
Os procedimentos a seguir detalham como realizar uma blue/green atualização que só altera a AMI. Você pode atualizar outras configurações para o novo ambiente.
**Importante**
Quando você remove o ambiente computacional antigo (azul), qualquer trabalho atualmente em execução nessas instâncias falhará porque as instâncias serão encerradas. Configure estratégias de repetição de trabalhos em suas definições de trabalhos para lidar com essas falhas automaticamente. Para obter mais informações, consulte [Repetições de trabalho automatizadas](job_retries.md).
Quando você estiver confiante no novo ambiente:
Remova o antigo ambiente computacional da fila de trabalhos.
Aguarde a conclusão de qualquer trabalho em execução no ambiente antigo.
Exclua o antigo ambiente de computação.
------
#### [ Performing blue/green updates using the Console de gerenciamento da AWS ]
1. Clone seu ambiente computacional atual
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Selecione seu ambiente computacional existente.
1. Escolha **Ações** e então **Clonar**.
1. Para **Nome**, insira um nome exclusivo para seu novo ambiente computacional.
1. Escolha **Próximo**.
1. Na seção **Configuração da instância**, defina estes valores:
1. Expanda **Configuração Adicional**.
1. Para a **Configuração EC2**, especifique o novo tipo de AMI em **Tipo de imagem** e ID de AMI no campo **Substituição de ID de imagem**.
1. Escolha **Próximo**.
1. Para **Configuração de rede**, escolha **Avançar**.
1. Revise as outras configurações que são copiadas automaticamente do seu ambiente existente.
1. Escolha **Criar ambiente computacional**.
1. Aguarde até que o novo status do ambiente computacional se torne `VALID`.
1. Alterar a ordem da fila de trabalhos
1. No painel de navegação, escolha **Filas de Tarefas**.
1. Selecione a fila de trabalhos associada ao seu ambiente computacional existente.
1. Escolha **Editar**.
1. Em **Ambiente computacional conectado**, adicione o novo ambiente computacional:
+ Adicione o novo ambiente computacional com um número de pedido maior do que o ambiente existente para fazer a transição do workload.
+ Depois de verificar se o novo ambiente está funcionando corretamente, você pode torná-lo o ambiente principal fornecendo a ele um número de pedido menor.
1. Escolha **Atualizar fila de trabalhos**.
1. Limpeza
1. Monitore a execução do trabalho no novo ambiente para garantir que tudo esteja funcionando conforme o esperado.
1. Quando você estiver confiante no novo ambiente:
1. Remova o antigo ambiente computacional da fila de trabalhos.
1. Aguarde a conclusão de qualquer trabalho em execução no ambiente antigo.
1. Exclua o antigo ambiente de computação.
------
#### [ Performing blue/green updates using the AWS CLI ]
1. Para obter a configuração usando o AWS CLI, use o seguinte comando:
```
aws batch describe-compute-environments \
--compute-environments your-compute-environment-name
```
Salve a saída para referência ao criar o novo ambiente.
1. Crie um novo ambiente computacional usando a configuração do seu ambiente atual, mas com a nova AMI. Veja um exemplo de estrutura de comando:
Substitua os valores de exemplo pela configuração real da etapa anterior:
```
cat < ./blue-green-compute-environment.json
{
"computeEnvironmentName": "your-new-compute-environment-name",
"type": "MANAGED",
"state": "ENABLED",
"computeResources": {
"instanceRole": "arn:aws:iam::012345678901:instance-profile/ecsInstanceRole",
"type": "EC2",
"minvCpus": 2,
"desiredvCpus": 2,
"maxvCpus": 256,
"instanceTypes": [
"optimal"
],
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"ec2Configuration": [
{
"imageType": "ECS_AL2023",
"imageIdOverride": "ami-0abcdef1234567890"
}
],
"subnets": [,
"subnet-0abcdef1234567890"
],
"securityGroupIds": [
"sg-0abcdef1234567890"
]
}
}
EOF
```
```
$ aws batch create-compute-environment --cli-input-json file://./blue-green-compute-environment.json
```
1. Aguarde até que o novo ambiente fique disponível:
```
aws batch describe-compute-environments \
--compute-environments your-new-compute-environment-name \
--query 'computeEnvironments[].status'
```
1. Adicione o ambiente computacional a sua fila de trabalhos:
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-existing-environment \
order=2,computeEnvironment=your-new-compute-environment-name
```
1. Depois de verificado, atualize novamente para tornar o novo ambiente primário:
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-new-compute-environment-name
```
Depois que todos os trabalhos forem concluídos no ambiente antigo, desative e exclua o ambiente antigo:
```
aws batch update-compute-environment \
--compute-environment your-existing-environment \
--state DISABLED
```
```
aws batch delete-compute-environment \
--compute-environment your-existing-environment
```
------
# Recurso computacional AMIs
Por padrão, os ambientes computacionais AWS Batch gerenciados usam uma versão recente e aprovada da AMI otimizada do Amazon ECS para recursos computacionais. No entanto, você pode querer criar sua própria AMI a ser usada para seus ambientes de computação gerenciados. Se você precisar de alguma das opções a seguir, recomendamos que crie sua própria AMI:
+ Aumentar o tamanho do armazenamento da raiz ou dos volumes de dados da AMI.
+ Adicionar volumes de armazenamento de instâncias para tipos de instância compatíveis do Amazon EC2.
+ Personalização do agente de contêineres do Amazon ECS.
+ Personalizando o Docker
+ Configurar uma AMI de workload de GPU que permite que os contêineres acessem o hardware de GPU nos tipos de instância do Amazon EC2 compatíveis
**nota**
Depois que um ambiente computacional é criado, AWS Batch não atualiza o AMIs no ambiente computacional. AWS Batch também não atualiza o AMIs em seu ambiente computacional quando uma versão mais recente da AMI otimizada do Amazon ECS está disponível. Você é responsável pelo gerenciamento do sistema operacional convidado. Isso inclui quaisquer atualizações e patches de segurança. Você também é responsável por quaisquer outros utilitários ou aplicativos de software que instalar nos recursos de computação. Para usar uma nova AMI para seus AWS Batch trabalhos, faça o seguinte:
Crie um novo ambiente de computação com a nova AMI.
Adicione o ambiente de computação a uma fila de trabalhos existente.
Remova o antigo ambiente de computação da fila de trabalhos.
Exclua o ambiente de computação anterior.
Em abril de 2022, AWS Batch foi adicionado suporte aprimorado para atualização de ambientes computacionais. Para obter mais informações, consulte [Atualize um ambiente computacional no AWS Batch](updating-compute-environments.md). Para usar a atualização aprimorada de ambientes computacionais para atualizar AMIs, siga estas regras:
Não defina o parâmetro da função de serviço ([https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole)) nem o defina como a função **AWSServiceRoleForBatch**vinculada ao serviço.
Defina o parâmetro da estratégia de alocação ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy)) como `BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` ou `SPOT_PRICE_CAPACITY_OPTIMIZED`.
Defina o parâmetro de atualização para a versão mais recente da imagem ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)) como `true`.
Não especifique uma ID de AMI em [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId), [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride) (em [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)) ou no modelo de execução ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)). Quando você não especifica uma ID de AMI, AWS Batch seleciona a última AMI otimizada do Amazon ECS que AWS Batch oferece suporte no momento em que a atualização da infraestrutura é iniciada. Como alternativa, você pode especificar a ID da AMI nos parâmetros `imageId` ou `imageIdOverride`. Ou pode especificar o modelo de execução que é identificado pelas propriedades `LaunchTemplate`. A alteração de qualquer uma dessas propriedades inicia uma atualização da infraestrutura. Se a ID da AMI for especificada no modelo de lançamento, a ID da AMI não poderá ser substituída pela especificação de uma ID da AMI nos parâmetros `imageId` ou `imageIdOverride`. A ID da AMI só pode ser substituída pela especificação de um modelo de lançamento diferente. Se a versão do modelo de lançamento estiver definida como `$Default` ou `$Latest`, a ID da AMI poderá ser substituída definindo uma nova versão padrão para o modelo de lançamento (se `$Default`) ou adicionando uma nova versão ao modelo de lançamento (se `$Latest`).
Se essas regras forem seguidas, qualquer atualização que acione uma atualização de infraestrutura fará com que a ID da AMI seja novamente selecionada. Se a configuração da [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version) no modelo de execução ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) for definida como `$Latest` ou `$Default`, a versão mais recente ou padrão do modelo de inicialização será avaliada no momento da atualização da infraestrutura, mesmo que o [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate) não tenha sido atualizado.
**Topics**
+ [Especificação da AMI do recurso de computação](batch-ami-spec.md)
+ [Ordem de seleção da AMI](ami-selection-order.md)
+ [Gerenciando versões da AMI em ambientes computacionais](managing-ami-versions.md)
+ [Tutorial: criar uma AMI de recurso de computação](create-batch-ami.md)
+ [Usar uma AMI de workload de GPU](batch-gpu-ami.md)
+ [Depreciação do Amazon Linux](al1-ami-deprecation.md)
+ [Descontinuação da AMI Amazon EKS Amazon Linux 2](eks-al2-ami-deprecation.md)
+ [Descontinuação da AMI Amazon ECS Amazon Linux 2](ecs-al2-ami-deprecation.md)
# Especificação da AMI do recurso de computação
A especificação básica da AMI de recursos AWS Batch computacionais consiste no seguinte:
Obrigatório
+ A distribuição Linux moderna executando pelo menos a versão 3.10 do Linux kernel em uma AMI de tipo de virtualização HVM. Não há suporte para contêineres do Windows.
**Importante**
Tarefas paralelas de vários nós só podem ser executadas em recursos de computação que foram iniciados em uma instância do Amazon Linux com o pacote `ecs-init` instalado. Recomendamos que você use a AMI otimizada para Amazon ECS ao criar o ambiente de computação. Você pode fazer isso sem especificar uma AMI personalizada. Para obter mais informações, consulte [Trabalhos em paralelo de vários nós](multi-node-parallel-jobs.md).
+ O atendente de contêiner do Amazon ECS. É recomendável usar a versão mais recente. Para obter mais informações, consulte [Instalar o atendente de contêiner do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
+ O driver de log `awslogs` deve ser especificado como um driver de log disponível com a variável de ambiente `ECS_AVAILABLE_LOGGING_DRIVERS` quando o atendente de contêiner do Amazon ECS é iniciado. Para obter mais informações, consulte [Configuração do atendente de Contêineres do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
+ Um daemon do Docker em execução, pelo menos, na versão 1.9 e quaisquer dependências de runtime do Docker. Para mais informações, consulte [Verificar dependências do runtime](https://docs.docker.com/engine/installation/binaries/#check-runtime-dependencies) na documentação do Docker.
**nota**
Recomendamos a versão do Docker que é fornecida e testada com a versão de atendente de contêiner do Amazon ECS que você está usando. O Amazon ECS fornece um changelog para a variante Linux da AMI otimizada para Amazon ECS em. GitHub Para obter mais informações, consulte [Log de alterações](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md).
Recomendado
+ Um processo de inicialização e de nanny para executar e monitorar o atendente do Amazon ECS. A AMI otimizada para Amazon ECS usa o processo de inicialização `ecs-init` e outros sistemas operacionais podem usar `systemd`. Para obter mais informações e exemplos, consulte [Example container instance User Data Configuration Scripts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Para obter mais informações sobre`ecs-init`, consulte o [`ecs-init`projeto](https://github.com/aws/amazon-ecs-init) em GitHub. No mínimo, os ambientes de computação gerenciados exigem que o atendente do Amazon ECS seja iniciado na inicialização. Se o agente do Amazon ECS não estiver em execução no seu recurso computacional, ele não poderá aceitar trabalhos do. AWS Batch
As AMIs otimizadas para Amazon ECS são pré-configuradas com esses requisitos e com essas recomendações. Recomendamos que você use a AMI otimizada para Amazon ECS ou uma AMI do Amazon Linux com o pacote `ecs-init` que está instalado para seus recursos de computação. Escolha outra AMI se seu aplicativo exigir um sistema operacional específico ou uma versão do Docker que ainda não esteja disponível nesses AMIs sistemas. Para obter mais informações, consulte [Amazon ECS-Optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
# Ordem de seleção da AMI
AWS Batch determina a Amazon Machine Image (AMI) para recursos computacionais usando a seguinte ordem de prioridade. Compreender essa ordem ajuda você a entender por que AWS Batch escolher uma AMI específica para seu ambiente computacional:
1. **AMI de substituição do modelo** de execução: se uma substituição do modelo de execução da instância executada tiver uma imagem, essa imagem será usada.
1. **ID da imagem de recursos computacionais (obsoleto)** — se definido, essa AMI de ambiente computacional será usada. *Nota: Campo obsoleto; use EC2Configuration. imageIdOverride em vez disso.*
1. **Substituição da ID da imagem de configuração do EC2** - Se especificada, a imagem nesse campo será usada.
1. **AMI do modelo de execução**: se o ambiente computacional tiver um modelo de execução associado a uma imagem, essa imagem será usada.
1. **AWS AMI padrão** - Se nenhuma das opções acima estiver configurada, AWS Batch seleciona uma AMI padrão com base no tipo de imagem especificado na configuração do EC2.
**nota**
O parâmetro EC2Configuration é opcional. Quando omitido, seleciona AWS Batch automaticamente uma configuração EC2 apropriada e uma AMI padrão com base nos tipos de instância executados no ambiente computacional.
**nota**
Essa ordem de seleção da AMI não se aplica aos ambientes computacionais Fargate.
## Ordem de seleção da AMI da maior para a menor prioridade
1. **O modelo de lançamento substitui a AMI** (precedência mais alta)
**Campo de API:** `overrides[].launchTemplateId` com tipos de instância de destino
**Referência: [LaunchTemplateSpecification](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html)**
Os modelos de substituição têm como alvo tipos de instância específicos e fornecem um controle mais granular do que o modelo de execução padrão. Elas têm precedência sobre todas as outras especificações da AMI para combinar os tipos de instância.
```
{
"computeResources": {
"launchTemplate": {
"launchTemplateId": "lt-default",
"overrides": [
{
"launchTemplateId": "lt-gpu-optimized",
"targetInstanceTypes": ["p3.2xlarge", "g4dn.xlarge"]
}
]
}
}
}
```
1. **ID da imagem dos recursos de computação**
**Campo da API:** `computeResources.imageId`
**Referência: [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)**
Você pode especificar uma AMI diretamente no nível do ambiente computacional. Isso tem precedência sobre as substituições de configuração e os modelos de execução do EC2 (exceto os modelos de substituição).
Em um ambiente computacional com várias configurações do EC2 (por exemplo, para `ECS_AL2023` e`ECS_AL2023_NVIDIA`), o ID da AMI especificado aqui é usado para todas as configurações do EC2.
**Importante**
O `imageId` campo está obsoleto. Por favor, use `ec2Configuration.imageIdOverride` em vez disso.
```
{
"computeResources": {
"imageId": "ami-12345678",
"instanceTypes": ["m5.large", "m5.xlarge"]
}
}
```
1. **Substituição do ID da imagem de configuração do EC2**
**Campo da API:** `computeResources.ec2Configuration[].imageIdOverride`
**Referência: [Ec2Configuration](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)**
A configuração do EC2 fornece substituições específicas do tipo de imagem. Essa configuração substitui a seleção padrão da AMI e o modelo de execução da AMI para o tipo de imagem especificado.
```
{
"computeResources": {
"ec2Configuration": [
{
"imageType": "ECS_AL2",
"imageIdOverride": "ami-87654321"
}
]
}
}
```
1. **Inicie o modelo AMI**
**Campo API:** `ImageId` no modelo de lançamento do Amazon EC2
**Referência:** [Use os modelos de lançamento do Amazon EC2 com AWS Batch](launch-templates.md)
Quando você especifica uma AMI no modelo de execução, ela tem precedência sobre a seleção padrão da AMI, mas é substituída por configurações de precedência mais altas.
```
// EC2 Launch Template content
{
"LaunchTemplateName": "my-batch-template",
"LaunchTemplateData": {
"ImageId": "ami-12345678"
}
}
```
Referenciado pelo modelo de AWS Batch lançamento:
```
// Batch Launch Template content
{
"computeResources": {
"launchTemplate": {
"launchTemplateName": "my-batch-template",
"version": "$Latest"
}
}
}
```
1. **AWS AMI padrão** (precedência mais baixa)
**Campo da API:** determinado por `computeResources.ec2Configuration[].imageType`
**Referência: Ec2 Configuration** [ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)
Quando nenhuma AMI personalizada é especificada, seleciona AWS Batch automaticamente a última AMI otimizada para Amazon Amazon ECS aprovada com base no tipo de imagem.
**nota**
O `ec2Configuration` é opcional. AWS Batch selecionará uma AMI padrão apropriada se nenhuma `ec2Configuration` for especificada.
```
{
"computeResources": {
"ec2Configuration": [
{
"imageType": "ECS_AL2023"
}
]
}
}
```
# Gerenciando versões da AMI em ambientes computacionais
AWS Batch fornece visibilidade das Amazon Machine Images (AMIs) que seus ambientes computacionais usam.
## Visualizando o status da AMI
Você pode ver o status de AMIs usado em seus ambientes de computação por meio do AWS Batch console ou usando o [describe-compute-environments](https://docs.aws.amazon.com/cli/latest/reference/batch/describe-compute-environments.html)comando.
------
#### [ Console ]
No AWS Batch console, as informações de status da AMI aparecem em dois locais com os seguintes valores de status:
+ **Mais recente** — Usando a AMI mais recente suportada pelo AWS Batch.
+ **Atualização disponível** — Uma atualização está disponível.
**nota**
As informações de status da AMI aparecem somente para AWS Batch-managed AMIs. O status não aparece quando as imagens são especificadas em `imageId` (obsoleto) ou no `imageIdOverride` modelo de lançamento padrão. O status não aparece quando o ambiente computacional tem uma substituição do modelo de execução. Para obter mais informações sobre a seleção de AMI, consulte[Ordem de seleção da AMI](ami-selection-order.md).
A página de ambientes computacionais exibe uma coluna de **status da imagem Batch** que mostra o geral `batchImageStatus` de cada ambiente computacional. Se um ambiente computacional tiver várias AMIs e qualquer uma AMI tiver **atualização disponível**, o console mostrará a **atualização disponível** para todo o ambiente computacional.
**nota**
O status aparece depois que o ambiente computacional começa a escalar para qualquer tipo de **imagem**.
Na página de detalhes do ambiente computacional, a seção de **configuração do Ec2** da guia **Recursos de computação mostra** o **status da imagem em lote** para cada **tipo de imagem** no ambiente computacional. Se um **tipo de imagem** tiver vários AMIs e qualquer AMI tiver **atualização disponível**, o console mostrará a **atualização disponível** para esse **tipo de imagem**.
**nota**
O status aparece para cada **tipo de imagem** somente depois que o ambiente computacional começa a escalar instâncias para esse tipo de **imagem** específico.
------
#### [ CLI ]
Quando você liga [describe-compute-environments](https://docs.aws.amazon.com/cli/latest/reference/batch/describe-compute-environments.html), a resposta inclui o `batchImageStatus` campo que fornece visibilidade da AMI com os seguintes valores:
+ `LATEST`— Usando a AMI mais recente suportada pelo AWS Batch.
+ `UPDATE_AVAILABLE`— Uma atualização está disponível.
**nota**
O `batchImageStatus` campo aparece somente para AWS Batch-managed AMIs. Ele não aparece quando AMIs os personalizados são especificados em `imageId` (obsoleto) ou no `imageIdOverride` modelo de lançamento padrão. O status não aparece quando o ambiente computacional tem uma substituição do modelo de execução. Para obter mais informações sobre como AWS Batch selecionar AMIs, consulte[Ordem de seleção da AMI](ami-selection-order.md).
O campo aparece de forma independente para cada um `Ec2Configuration` e somente depois que o ambiente computacional começa a escalar as instâncias usando isso. `imageType`
```
{
"computeEnvironments": [
{
"computeEnvironmentName": "my-compute-environment",
"computeResources": {
"ec2Configuration": [
{
"imageType": "ECS_AL2023"
},
{
"imageType": "ECS_AL2023_NVIDIA",
"batchImageStatus": "UPDATE_AVAILABLE"
}
]
}
}
]
}
```
------
## Atualização das versões da AMI
Quando AWS Batch indica que uma atualização da AMI está disponível, você pode atualizar seu ambiente computacional para usar o mais novo AMIs atualizando o ambiente computacional com a opção Atualizar **AMI para a versão mais recente definida como verdadeira**.
Você não precisa especificar uma nova AMI IDs — seleciona AWS Batch automaticamente a mais recente compatível AMIs quando você define **Atualizar AMI para a versão mais recente**.
**Importante**
A atualização AMIs aciona uma atualização de [infraestrutura, não uma atualização](infrastructure-updates.md) de escalabilidade. Isso significa AWS Batch substituir as instâncias existentes por novas instâncias que usam a AMI atualizada. O processo de atualização demora mais do que uma atualização de escalabilidade e pode interromper a execução dos trabalhos, dependendo da configuração da política de atualização.
**Importante**
Se sua estratégia de alocação `BEST_FIT` for, você precisará realizar uma atualização [azul/verde](blue-green-updates.md).
------
#### [ Console ]
Para atualizar AMIs usando o AWS Batch console:
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. No painel de navegação, escolha **Ambientes**.
1. Selecione o ambiente computacional que mostra o status da AMI com uma atualização.
1. Escolha **Atualizar agora** (pelo status da AMI) ou **Ações** > **Editar** para abrir o modal de atualização.
1. No modal de atualização da AMI, analise as versões atuais da AMI e seus status.
1. Escolha **Confirmar** ou **Salvar** para iniciar a atualização da infraestrutura.
O status do ambiente computacional muda para `UPDATING` durante a atualização da infraestrutura. Você pode monitorar o progresso no console do .
------
#### [ CLI ]
Para atualizar AMIs usando a AWS CLI, use o `update-compute-environment` comando.
```
aws batch update-compute-environment \
--compute-environment my-compute-environment \
--compute-resources updateToLatestImageVersion=true
```
Esse comando aciona uma atualização de infraestrutura que substitui instâncias por novas instâncias usando a versão mais recente -supported. AWS Batch AMIs
------
## Considerações sobre AMI personalizadas
Se seu ambiente computacional usa configurações personalizadas AMIs, ou seja, AMIs especificadas em `ComputeResources.imageId` (obsoleto)`Ec2Configuration.imageIdOverride`, o modelo de execução padrão ou as substituições do modelo de execução AWS Batch não podem fornecer informações de status para elas. AMIs
+ **Visibilidade do status** — AMIs Mostre "**-**" de forma personalizada o **status da imagem em lote** no console e não inclua o `batchImageStatus` campo nas respostas da API.
+ **Gerenciamento manual** — Você é responsável por manter e atualizar a personalização AMIs. Mantenha-se informado sobre os patches de segurança e software do seu provedor de AMI e atualize sua personalização AMIs adequadamente.
+ **Gerenciamento do EC2** — Use o console do Amazon EC2 APIs ou gerencie o ciclo de vida personalizado da AMI, incluindo a criação de novas versões e a descontinuação das antigas.
Para obter mais informações sobre o gerenciamento personalizado AMIs, consulte[Recurso computacional AMIs](compute_resource_AMIs.md).
## Melhores práticas para atualizações da AMI
Esta seção se aplica tanto ao personalizado quanto ao padrão AMIs.
+ **Monitoramento regular** — verifique regularmente o status da AMI de seus ambientes computacionais para identificar quando as atualizações estão disponíveis. Por padrão AMIs, `batchImageStatus` ele será exibido quando uma atualização estiver disponível. Para personalizar AMIs, você precisará usar outros recursos, como boletins AWS de segurança.
+ **Janelas de manutenção** — Agende atualizações da AMI durante as janelas de manutenção, quando a interrupção do trabalho for aceitável, pois as atualizações de infraestrutura substituem as instâncias existentes.
+ **Estratégia de repetição** de tarefas — configure estratégias de repetição de tarefas para lidar com tarefas que possam ser interrompidas durante as atualizações da infraestrutura. Para obter mais informações, consulte [Repetições de trabalho automatizadas](job_retries.md).
+ **Configuração da política de atualização** — configure as políticas de atualização apropriadas para controlar como os trabalhos em execução são tratados durante as atualizações da infraestrutura. Para obter mais informações, consulte [Realizar atualizações da infraestrutura](infrastructure-updates.md).
+ **Teste** — teste as atualizações da AMI em ambientes de desenvolvimento antes de aplicá-las aos ambientes computacionais de produção.
# Tutorial: criar uma AMI de recurso de computação
É possível criar uma AMI personalizada de recursos de computação para usar em seus ambientes de computação gerenciados e não gerenciados. Para obter instruções, consulte o [Especificação da AMI do recurso de computação](batch-ami-spec.md). Então, depois de criar uma AMI personalizada, você pode criar um ambiente de computação que usa essa AMI, a que você pode associar uma fila de trabalhos. Por fim, comece a enviar trabalhos para essa fila.
**Para criar uma AMI de recursos de computação personalizada**
1. Escolha uma AMI base para começar. A AMI básica deve usar virtualização de HVM. A AMI básica não pode ser uma AMI do Windows.
**nota**
A AMI que você escolher para um ambiente de computação deve corresponder à arquitetura dos tipos de instância que você pretende usar para este ambiente. Por exemplo, se o ambiente de computação usar tipos de instância A1, a AMI de recursos de computação escolhida deverá oferecer suporte a instâncias ARM. O Amazon ECS vende as versões x86 e ARM da AMI do Amazon Linux 2 otimizada para Amazon ECS. Para obter mais informações, consulte [AMI do Amazon Linux 2 otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
A AMI do Amazon Linux 2 otimizada para Amazon ECS é a AMI padrão para recursos de computação em ambientes de computação gerenciados. O Amazon Linux 2 AMI otimizado para Amazon ECS é pré-configurado e testado AWS Batch por AWS engenheiros. É uma AMI mínima com a qual você pode começar a usar e fazer com que seus recursos computacionais sejam executados AWS rapidamente. Para obter mais informações, consulte [AMI otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
Como alternativa, você pode escolher outra variante do Amazon Linux 2 e instalar o pacote `ecs-init` com os seguintes comandos. Para obter mais informações, consulte [Instalação do agente de contêiner do Amazon ECS em uma EC2 instância do Amazon Linux 2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html#ecs-agent-install-al2) no *Guia do desenvolvedor do Amazon Elastic Container Service*:
```
$ sudo amazon-linux-extras disable docker
$ sudo amazon-linux-extras install ecs-init
```
Por exemplo, se você quiser executar cargas de trabalho de GPU em seus recursos AWS Batch computacionais, você pode começar com a [Amazon Linux Deep Learning](https://aws.amazon.com/marketplace/pp/B01M0AXXQB) AMI. Em seguida, configure a AMI para executar AWS Batch trabalhos. Para obter mais informações, consulte [Usar uma AMI de workload de GPU](batch-gpu-ami.md).
**Importante**
Você pode escolher uma AMI básica que não seja compatível com o pacote `ecs-init`. No entanto, se fizer isso, você deverá configurar uma forma de iniciar o atendente do Amazon ECS na inicialização e mantê-lo em execução. Você também pode ver vários exemplos de scripts de configuração de dados do usuário que usam `systemd` para iniciar e monitorar o agente de contêiner do Amazon ECS. Para obter mais informações, consulte [Scripts de configuração de dados de usuário de instância de contêiner de exemplo](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
1. Execute uma instância de sua AMI base selecionada com as opções de armazenamento adequadas para sua AMI. Você pode configurar o tamanho e o número de volumes do Amazon EBS conectados ou volumes de armazenamento de instância se o tipo de instância selecionado for compatível com eles. Para obter mais informações, consulte [Lançamento de uma instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html) e [Amazon EC2 Instance Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) no *Guia EC2 do usuário da Amazon*.
1. Conecte-se à sua instância com o SSH e execute todas as tarefas de configuração necessárias. Isso pode incluir qualquer uma das ou todas as seguintes etapas:
+ Como instalar o agente de contêiner do Amazon ECS. Para obter mais informações, consulte [Instalar o agente de contêiner do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
+ Configuração de um script para formatar volumes de armazenamento de instâncias.
+ Adição de volume de armazenamento de instância ou sistemas de arquivos Amazon EFS para o arquivo `/etc/fstab` para que eles sejam montados na inicialização.
+ Configuração de opções do Docker, como habilitar a depuração ou ajustar o tamanho da imagem base.
+ Instalação de pacotes ou cópia de arquivos.
Para obter mais informações, consulte [Conectando-se à sua instância Linux usando SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html) no *Guia do EC2 usuário da Amazon*.
1. Se você iniciou o agente de contêiner do Amazon ECS em sua instância, deve interrompê-lo e remover todos os arquivos persistentes do ponto de verificação de dados antes de criar sua AMI. Caso contrário, se você não fizer isso, o atendente não iniciará nas instâncias que são executadas a partir da sua AMI.
1. Interrompa o agente de contêiner do Amazon ECS.
+ AMI do Amazon Linux 2 otimizada para Amazon ECS:
```
sudo systemctl stop ecs
```
+ AMI do Amazon Linux otimizada para Amazon ECS:
```
sudo stop ecs
```
1. Remova os arquivos de ponto de verificação de dados persistentes. Por padrão, esses arquivos estão localizados no diretório `/var/lib/ecs/data/`. Use o comando a seguir para remover esses arquivos, se houver algum.
```
sudo rm -rf /var/lib/ecs/data/*
```
1. Crie uma nova AMI da sua instância em execução. Para obter mais informações, consulte [Criação de uma AMI Linux suportada pelo Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) no *guia EC2 do usuário da Amazon*.
**Para usar sua nova AMI com AWS Batch**
1. Após a criação da nova AMI, crie um ambiente de computação com a nova AMI. Para fazer isso, escolha o tipo de imagem e insira a ID de AMI personalizada na caixa de **substituição da ID de imagem** ao criar o ambiente AWS Batch computacional. Para obter mais informações, consulte [Tutorial: criar um ambiente de computação gerenciado usando recursos do Amazon EC2](create-compute-environment-managed-ec2.md).
**nota**
A AMI que você escolher para um ambiente de computação deve corresponder à arquitetura dos tipos de instância que você pretende usar para este ambiente. Por exemplo, se o ambiente de computação usar tipos de instância A1, a AMI de recursos de computação escolhida deverá oferecer suporte a instâncias ARM. O Amazon ECS vende as versões x86 e ARM da AMI do Amazon Linux 2 otimizada para Amazon ECS. Para obter mais informações, consulte [AMI do Amazon Linux 2 otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
1. Crie uma fila de trabalhos e associe seu novo ambiente de computação. Para obter mais informações, consulte [Crie uma fila de trabalhos](create-job-queue.md).
**nota**
Todos os ambientes de computação associados a uma fila de trabalhos devem compartilhar a mesma arquitetura. AWS Batch não oferece suporte à mistura de tipos de arquitetura de ambiente de computação em uma única fila de tarefas.
1. (Opcional) Envie um trabalho de amostra para sua nova fila de trabalhos. Para obter mais informações, consulte [Exemplo de definição de trabalhos](example-job-definitions.md), [Criar uma definição de tarefa de nó único](create-job-definition.md) e [Tutorial: enviar um trabalho](submit_job.md).
# Usar uma AMI de workload de GPU
Para executar cargas de trabalho de GPU em seus recursos de computação do AWS Batch, você deve usar uma AMI com suporte para GPU. Para obter mais informações, consulte [Como trabalhar com GPUs no Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html) e [AMIs otimizadas para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
Em ambientes computacionais gerenciados, se o ambiente computacional epecificar qualquer família de instância ou tipo de instância `p6`, `p3`, `p4`, `p5`, `g3`, `g3s`, `g4`, `g5` ou `g6`, o AWS Batch usa uma AMI otimizada para GPU do Amazon ECS.
Em ambientes de computação não gerenciados, é recomendada uma AMI otimizada para GPU do Amazon ECS. Você pode usar as operações AWS Command Line Interface ou AWS Systems Manager Parameter Store [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html), [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) para recuperar os metadados para as AMIs otimizadas para GPU do Amazon ECS recomendadas.
**nota**
A família de `p5` instância só é compatível com versões iguais ou posteriores à AMI otimizada para GPU `20230912` do Amazon ECS, e elas são incompatíveis com os tipos de instância `p2` e `g2`. Se você precisar usar instâncias `p5`, certifique-se de que seu ambiente computacional não contenha instâncias `p2` ou `g2` e use o Batch AMI padrão mais recente. A criação de um novo ambiente de computação usará a AMI mais recente, mas se você estiver atualizando seu ambiente de computação para incluir `p5`, você pode garantir que está usando a AMI mais recente configurando o [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion) como `true` nas propriedades `ComputeResource`. Para obter mais informações sobre a compatibilidade do AMI com instâncias de GPU, consulte [Como trabalhar com GPUs no Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
Os exemplos a seguir mostram como usar o comando [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html).
------
#### [ AWS CLI ]
```
$ aws ssm get-parameter --name /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \
--region us-east-2 --output json
```
A saída inclui as informações de AMI no parâmetro `Value`.
```
{
"Parameter": {
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended",
"LastModifiedDate": 1555434128.664,
"Value": "{\"schema_version\":1,\"image_name\":\"amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs\",\"image_id\":\"ami-083c800fe4211192f\",\"os\":\"Amazon Linux 2\",\"ecs_runtime_version\":\"Docker version 18.06.1-ce\",\"ecs_agent_version\":\"1.27.0\"}",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended"
}
}
```
------
#### [ Python ]
```
from __future__ import print_function
import json
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameter(Name='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended')
jsonVal = json.loads(response['Parameter']['Value'])
print("image_id = " + jsonVal['image_id'])
print("image_name = " + jsonVal['image_name'])
```
A saída inclui apenas o ID da AMI e nome da AMI:
```
image_id = ami-083c800fe4211192f
image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
```
------
Os exemplos a seguir demonstram o uso de [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html).
------
#### [ AWS CLI ]
```
$ aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name \
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id \
--region us-east-2 --output json
```
A saída inclui os metadados completos para cada um dos parâmetros:
```
{
"InvalidParameters": [],
"Parameters": [
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id",
"LastModifiedDate": 1555434128.749,
"Value": "ami-083c800fe4211192f",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name",
"LastModifiedDate": 1555434128.712,
"Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name"
}
]
}
```
------
#### [ Python ]
```
from __future__ import print_function
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameters(
Names=['/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name',
'/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id'])
for parameter in response['Parameters']:
print(parameter['Name'] + " = " + parameter['Value'])
```
A saída inclui o ID da AMI e nome da AMI, usando o caminho completo para os nomes.
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
```
------
Os exemplos a seguir mostram como usar o comando [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).
------
#### [ AWS CLI ]
```
$ aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \
--region us-east-2 --output json
```
A saída inclui todos os metadados completos para todos os parâmetros no caminho especificado.
```
{
"Parameters": [
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version",
"LastModifiedDate": 1555434128.801,
"Value": "1.27.0",
"Version": 8,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version",
"LastModifiedDate": 1548368308.213,
"Value": "Docker version 18.06.1-ce",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id",
"LastModifiedDate": 1555434128.749,
"Value": "ami-083c800fe4211192f",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name",
"LastModifiedDate": 1555434128.712,
"Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os",
"LastModifiedDate": 1548368308.143,
"Value": "Amazon Linux 2",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version",
"LastModifiedDate": 1548368307.914,
"Value": "1",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version"
}
]
}
```
------
#### [ Python ]
```
from __future__ import print_function
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameters_by_path(Path='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended')
for parameter in response['Parameters']:
print(parameter['Name'] + " = " + parameter['Value'])
```
A saída inclui os valores de todos os nomes de parâmetro no caminho especificado, usando o caminho completo para os nomes.
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version = 1.27.0
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version = Docker version 18.06.1-ce
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os = Amazon Linux 2
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version = 1
```
------
Para obter mais informações, consulte [Recuperar os metadados da AMI otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
# Depreciação do Amazon Linux
O Amazon Linux AMI (também chamado de Amazon Linux 1) chegou ao fim em 31 de dezembro de 2023. AWS Batch encerrou o suporte para o Amazon Linux AMI, pois não receberá nenhuma atualização de segurança ou correção de erros a partir de 1º de janeiro de 2024. Para obter mais informações sobre o Amazon Linux end-of-life, consulte as [perguntas frequentes da AL](https://aws.amazon.com/amazon-linux-ami/faqs/).
Recomendamos que você atualize os ambientes de computação existentes baseados no Amazon Linux para o Amazon Linux 2023 para evitar interrupções imprevistas da workload e continuar a receber atualizações de segurança e outras.
Seus ambientes computacionais usando o Amazon Linux AMI podem continuar funcionando além da end-of-life data de 31 de dezembro de 2023. No entanto, esses ambientes computacionais não receberão mais novas atualizações de software, patches de segurança ou correções de bugs da AWS. É sua responsabilidade manter esses ambientes computacionais na Amazon Linux AMI posteriormente end-of-life. Recomendamos a migração de ambientes de computação do AWS Batch para o Amazon Linux 2023 ou Amazon Linux 2 para manter o desempenho e a segurança ideais.
Para obter ajuda na migração AWS Batch do Amazon Linux AMI para o Amazon Linux 2023 ou Amazon Linux 2, consulte [Atualização de ambientes computacionais -](https://docs.aws.amazon.com/batch/latest/userguide/updating-compute-environments.html). AWS Batch
# Descontinuação da AMI Amazon EKS Amazon Linux 2
AWS encerrou o suporte para Amazon Linux 2 otimizado para Amazon EKS AMIs em 26 de novembro de 2025. Em 27 de outubro de 2025, AWS Batch alterou a AMI padrão para novos ambientes computacionais Amazon EKS para Amazon Linux 2023. O Amazon Linux 2 otimizado para Amazon EKS AMIs não recebe mais atualizações de software, patches de segurança ou correções de bugs do AWS.
**Importante**
Se você tem ambientes computacionais AWS Batch Amazon EKS que ainda usam o Amazon Linux 2, é altamente recomendável migrar para o Amazon Linux 2023. É sua responsabilidade manter os ambientes computacionais Amazon Linux 2 otimizados para Amazon EKS posteriormente end-of-life.
Para obter mais informações sobre o Amazon EKS AL2 end-of-life, consulte a suspensão de uso da [AMI do Amazon EKS no Guia FAQs](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) do usuário do *Amazon EKS*.
Para obter ajuda AWS Batch na migração dos ambientes computacionais do Amazon EKS do Amazon Linux 2 para o Amazon Linux 2023, consulte. [Como fazer o upgrade do EKS AL2 para o EKS AL2023](eks-migration-2023.md)
# Descontinuação da AMI Amazon ECS Amazon Linux 2
AWS está encerrando o suporte para o Amazon ECS Amazon Linux 2 otimizado e acelerado AMIs em 30 de junho de 2026. Em 12 de janeiro de 2026, AWS Batch alterou a AMI padrão para novos ambientes computacionais do Amazon ECS do Amazon Linux 2 para o Amazon Linux 2023. A partir de 30 de junho de 2026, AWS Batch bloqueará a criação de novos ambientes computacionais do Amazon ECS usando o Amazon Linux 2 fornecido em lote. AMIs Após essa data, você só pode criar novos ambientes computacionais do Amazon ECS usando o Amazon Linux 2023 ou fornecido pelo cliente. AMIs
**Importante**
É altamente recomendável migrar seus ambientes computacionais existentes do AWS Batch Amazon ECS para o Amazon Linux 2023 antes de 30 de junho de 2026. Os ambientes computacionais existentes continuarão operando após essa data, mas não receberão mais atualizações de software, patches de segurança ou correções de bugs da AWS. É sua responsabilidade manter os ambientes computacionais do Amazon Linux 2 posteriormente end-of-life.
Você pode acompanhar o status de migração dos seus ambientes computacionais afetados do Amazon ECS usando eventos de ciclo de vida planejados AWS da Health. Para obter mais informações, consulte [AWS Eventos do ciclo de vida do Health Planned](batch-planned-lifecycle-events.md).
Para obter mais informações sobre o Amazon Linux 2 end-of-life, consulte [Amazon Linux 2 FAQs](https://aws.amazon.com/amazon-linux-2/faqs/).
Para saber mais sobre as diferenças entre o Amazon Linux 2 e o Amazon Linux 2023, consulte [Comparação entre o Amazon Linux 2023 e o Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) no *Guia do usuário do Amazon Linux 2023*.
Para obter informações sobre mudanças do Amazon Linux 2023 para o AMI Amazon otimizado para ECS, consulte [Migrar de um Amazon Linux 2 para um Amazon Linuz 2023 AMI otimizado para ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html) no *Guia do usuário Amazon ECS*.
Para obter ajuda AWS Batch na migração dos ambientes computacionais do Amazon ECS do Amazon Linux 2 para o Amazon Linux 2023, consulte. [Como migrar do ECS para o ECS AL2 AL2023](ecs-migration-2023.md)
# Use os modelos de lançamento do Amazon EC2 com AWS Batch
AWS Batch suporta o uso de modelos de lançamento do Amazon EC2 com seus ambientes computacionais do EC2. Com os modelos de lançamento, você pode modificar a configuração padrão dos seus recursos AWS Batch computacionais sem precisar criar modelos personalizados. AMIs
Os modelos de lançamento podem especificar AMIs que têm precedência na ordem de seleção da AMI. Para obter mais informações, consulte [Ordem de seleção da AMI](ami-selection-order.md).
**nota**
Quando você especifica um modelo de execução personalizado para um ambiente AWS Batch computacional, AWS Batch não anexa diretamente seu modelo de execução ao grupo de Auto Scaling subjacente. Em vez disso, AWS Batch cria um modelo de lançamento separado e gerenciado em lote para o grupo Auto Scaling e incorpora nele as configurações relevantes do seu modelo de lançamento personalizado. Como resultado, o modelo de execução que você vê associado ao grupo Auto Scaling é diferente daquele que você especificou originalmente. Esse comportamento é esperado.
**nota**
Os modelos de lançamento não são compatíveis com os recursos do AWS Fargate.
Você deve criar um modelo de execução antes de associá-lo a um ambiente de computação. É possível criar um modelo de execução usando o console Amazon EC2. Ou você pode usar o AWS CLI ou um AWS SDK. Por exemplo, o arquivo JSON a seguir representa um modelo de execução que redimensiona o volume de dados do Docker para o recurso de AWS Batch computação padrão AMI e também o define para ser criptografado.
```
{
"LaunchTemplateName": "increase-container-volume-encrypt",
"LaunchTemplateData": {
"BlockDeviceMappings": [
{
"DeviceName": "/dev/xvda",
"Ebs": {
"Encrypted": true,
"VolumeSize": 100,
"VolumeType": "gp2"
}
}
]
}
}
```
Você pode criar o modelo de execução anterior salvando o JSON em um arquivo chamado `lt-data.json` e executando o AWS CLI comando a seguir.
```
aws ec2 --region create-launch-template --cli-input-json file://lt-data.json
```
Para obter mais informações sobre modelos de execução, consulte [Executar uma instância de um modelo de execução](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html), no *Guia do usuário do Amazon EC2*.
Se você usar um modelo de execução para criar seu ambiente de computação, poderá mover os seguintes parâmetros de ambiente de computação existentes para o seu modelo de execução:
**nota**
Suponha que qualquer um desses parâmetros (exceto as tags do Amazon EC2) seja especificado no modelo de execução e na configuração do ambiente de computação. Então, os parâmetros do ambiente de computação têm precedência. As tags do Amazon EC2 são mescladas entre o modelo de lançamento e a configuração do ambiente de computação. Se houver uma colisão na chave de tag, o valor na configuração do ambiente de computação tem precedência.
+ Pares de chaves do Amazon EC2
+ ID da AMI do Amazon EC2
+ Grupo de segurança IDs
+ Etiquetas do Amazon EC2
Os seguintes parâmetros do modelo de lançamento são **ignorados** por AWS Batch:
+ Tipo de instância (especifique os tipos de instâncias desejados ao criar o ambiente de computação)
+ Função de instância (especifique a função de instância desejada ao criar o ambiente de computação)
+ Sub-redes de interface de rede (especifique as sub-redes desejadas ao criar seu ambiente de computação)
+ Opções de mercado de instâncias (AWS Batch deve controlar a configuração da instância spot)
+ Desativar o encerramento da API (AWS Batch deve controlar o ciclo de vida da instância)
AWS Batch somente atualiza o modelo de lançamento com uma nova versão do modelo de lançamento durante as atualizações da infraestrutura. Para obter mais informações, consulte [Atualize um ambiente computacional no AWS Batch](updating-compute-environments.md).
## Modelos de execução padrão e substituídos
Você pode definir um modelo de execução padrão para o ambiente computacional e um modelo de execução substituto para tipos e famílias de instâncias específicos. Isso pode ser útil para que o modelo padrão seja usado para a maioria dos tipos de instância nos ambientes de computação.
As variáveis de substituição `$Default` e `$Latest` podem ser usadas em vez de nomear uma versão específica. Se você não fornecer um modelo de execução substituto, o modelo de execução padrão será aplicado automaticamente.
Se você usar a `$Latest` variável `$Default` ou, AWS Batch aplicará as informações atuais no momento em que o ambiente computacional for criado. Se a versão padrão ou mais recente mudar no futuro, você deverá atualizar as informações por meio do - [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)ou por meio do Console de gerenciamento da AWS - AWS Batch.
Para fornecer flexibilidade adicional, você pode definir modelos de execução substitutivos aplicados a tipos ou famílias de instâncias computacionais específicos.
**nota**
Você pode especificar até dez (10) modelos de substituições de execução para cada ambiente computacional.
Use o parâmetro `targetInstanceTypes` para selecionar o tipo de instância ou a família que deve usar esse modelo de execução substituto. O tipo de instância ou família deve ser identificado primeiro pelo parâmetro [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes).
Se você definir substituições do modelo de execução e decidir removê-las posteriormente, poderá passar uma matriz vazia para cancelar a definição do parâmetro [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides) na operação da API [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html). Você também pode optar por não incluir o parâmetro `overrides` ao enviar a operação da API `UpdateComputeEnvironment`. Para obter mais informações, consulte [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides)
Para obter mais informações, consulte [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes)o Guia de referência AWS Batch da API.
## Dados de usuário do Amazon EC2 em modelos de execução
Você pode fornecer os dados de usuário do Amazon EC2 em seu modelo de execução que é executado por [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html) quando suas instâncias são iniciadas. Seus dados de usuário podem executar cenários de configuração comuns, incluindo, dentre outros:
+ [Incluindo usuários ou grupos](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [Instalar pacotes](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
+ [Criar partições e sistemas de arquivos](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#create-partitions-and-filesystems)
Os dados do usuário do Amazon EC2 em modelos de execução devem estar no formato [MIME multi-part archive](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive). Isso ocorre porque seus dados de usuário são mesclados com outros dados de AWS Batch usuário necessários para configurar seus recursos computacionais. É possível combinar vários blocos de dados de usuário em um único arquivo MIME de várias partes. Por exemplo, convém combinar um boothook de nuvem que configure o daemon do Docker com um script do shell de dados do usuário que grave informações do atendente de contêiner do Amazon ECS.
Se você estiver usando AWS CloudFormation, o [AWS::CloudFormation::Init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html)tipo pode ser usado com o script auxiliar [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html) para realizar cenários de configuração comuns.
Um arquivo em várias partes MIME consiste nos seguintes componentes:
+ O tipo de conteúdo e a declaração de limite da parte: `Content-Type: multipart/mixed; boundary="==BOUNDARY=="`
+ A declaração da versão MIME: `MIME-Version: 1.0`
+ Um ou mais blocos de dados do usuário que contêm os seguintes componentes:
+ O limite de abertura, que sinaliza o início de um bloco de dados do usuário: `--==BOUNDARY==`. Você deve manter a linha antes desse limite em branco.
+ A declaração de tipo de conteúdo para o bloco: `Content-Type: text/cloud-config; charset="us-ascii"`. Para mais informações sobre tipos de conteúdo, consulte a [documentação do Cloud-Init](https://cloudinit.readthedocs.io/en/latest/topics/format.html). Você deve manter a linha após o branco da declaração do tipo de conteúdo.
+ O conteúdo de dados do usuário, por exemplo, uma lista de comandos de shell ou diretivas do `cloud-init`.
+ O limite de fechamento que sinaliza o fim do arquivo MIME de várias partes: `--==BOUNDARY==--`. Você deve manter a linha antes do branco do limite de fechamento.
**nota**
Se você adicionar dados de usuário a um modelo de execução no console do Amazon EC2, você pode colá-los como texto simples ou fazer upload de um arquivo. Ou você pode fazer o upload de um arquivo. Se você usa o AWS CLI ou um AWS SDK, deve primeiro `base64` codificar os dados do usuário e enviar essa string como o valor do `UserData` parâmetro ao chamar [CreateLaunchTemplate](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateLaunchTemplate.html), conforme mostrado neste arquivo JSON.
```
{
"LaunchTemplateName": "base64-user-data",
"LaunchTemplateData": {
"UserData": "ewogICAgIkxhdW5jaFRlbXBsYXRlTmFtZSI6ICJpbmNyZWFzZS1jb250YWluZXItdm9sdW..."
}
}
```
**Topics**
+ [Modelos de execução padrão e substituídos](#default-lt-and-overrides)
+ [Dados de usuário do Amazon EC2 em modelos de execução](#lt-user-data)
+ [Referência: exemplos de modelos de inicialização do Amazon EC2](launch-template-examples.md)
# Referência: exemplos de modelos de inicialização do Amazon EC2
Veja a seguir um exemplo de arquivo MIME com várias partes que você pode usar para criar seus próprios modelos.
**Topics**
+ [Exemplo: montar um sistema de arquivos existente do Amazon EFS](#example-mount-an-existing-amazon-efs-file-system)
+ [Exemplo: substituir a configuração padrão do atendente de contêiner do Amazon ECS](#example-override-default-amazon-ecs-container-agent-configuration)
+ [Exemplo: montar um sistema de arquivos Amazon FSx for Lustre existente](#example-mount-an-existing-amazon-fsx-for-lustre-file-system)
## Exemplo: montar um sistema de arquivos existente do Amazon EFS
**Example**
Este exemplo de arquivo MIME de várias partes configura o recurso de computação para instalar o pacote `amazon-efs-utils` e montar um sistema de arquivos existente do Amazon EFS em `/mnt/efs`.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
packages:
- amazon-efs-utils
runcmd:
- file_system_id_01=fs-abcdef123
- efs_directory=/mnt/efs
- mkdir -p ${efs_directory}
- echo "${file_system_id_01}:/ ${efs_directory} efs tls,_netdev" >> /etc/fstab
- mount -a -t efs defaults
--==MYBOUNDARY==--
```
## Exemplo: substituir a configuração padrão do atendente de contêiner do Amazon ECS
**Example**
Este exemplo de arquivo MIME de várias partes substitui as configurações padrão de limpeza de imagem de docker para um recurso de computação.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo ECS_IMAGE_CLEANUP_INTERVAL=60m >> /etc/ecs/ecs.config
echo ECS_IMAGE_MINIMUM_CLEANUP_AGE=60m >> /etc/ecs/ecs.config
--==MYBOUNDARY==--
```
## Exemplo: montar um sistema de arquivos Amazon FSx for Lustre existente
**Example**
Este exemplo de arquivo MIME de várias partes configura o recurso computacional para instalar o `lustre2.10` pacote da Biblioteca Extras e montar um sistema de arquivos existente FSx para Lustre em `/scratch` e um nome de montagem de. `fsx` Este exemplo é para o Amazon Linux 2. Para obter instruções de instalação para outras distribuições Linux, consulte [Instalando o Lustre Client no Guia do usuário do](https://docs.aws.amazon.com/fsx/latest/LustreGuide/install-lustre-client.html) *Amazon FSx for Lustre.* Para obter mais informações, consulte [Montar seu sistema de FSx arquivos Amazon automaticamente](https://docs.aws.amazon.com/fsx/latest/LustreGuide/mount-fs-auto-mount-onreboot.html) no *Guia do usuário do Amazon FSx for Lustre*.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
runcmd:
- file_system_id_01=fs-0abcdef1234567890
- region=us-east-2
- fsx_directory=/scratch
- amazon-linux-extras install -y lustre2.10
- mkdir -p ${fsx_directory}
- mount -t lustre ${file_system_id_01}.fsx.${region}.amazonaws.com@tcp:fsx ${fsx_directory}
--==MYBOUNDARY==--
```
Nos membros [volumes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerProperties.html#Batch-Type-ContainerProperties-volumes) e [mountPoints](https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerProperties.html#Batch-Type-ContainerProperties-mountPoints) das propriedades do contêiner, os pontos de montagem devem ser mapeados para o contêiner.
```
{
"volumes": [
{
"host": {
"sourcePath": "/scratch"
},
"name": "Scratch"
}
],
"mountPoints": [
{
"containerPath": "/scratch",
"sourceVolume": "Scratch"
}
],
}
```
# Configuração do serviço de metadados de instância (IMDS)
O Serviço de metadados de instância (IMDS) fornece metadados sobre suas instâncias do EC2 aos aplicativos em execução nessas instâncias. Use o IMDSv2 para todos os novos workloads e migre os workloads existentes do IMDSv1 para o IMDSv2 para melhorar a segurança. Para obter mais informações sobre o IMDS e a configuração do IMDS, consulte [Usar metadados de instância para gerenciar sua instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) e [Configurar opções de metadados de instância para novas instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html) no *Guia do usuário do Amazon EC2*.
## Cenários de configuração
Escolha o método de configuração apropriado com base na configuração do seu ambiente computacional:
### AMI padrão sem modelo de execução
Ao usar a AMI AWS Batch padrão e não especificar um modelo de execução, escolha uma das seguintes opções:
1. **Usar a AMI padrão do Amazon Linux 2023** — O Amazon Linux 2023 exige o IMDSv2 por padrão. Ao criar seu ambiente computacional, selecione **Amazon Linux 2023** como o tipo de imagem.
1. **Definir a configuração do IMDSv2 em nível de conta** — Configure sua conta AWS para exigir o IMDSv2 para todas as novas instâncias. Essa configuração afeta todas as novas instâncias que você executa na conta. Para obter instruções, consulte [Definir IMDSv2 como padrão para a conta](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#set-imdsv2-account-defaults) no *Guia do usuário do Amazon EC2*.
**nota**
A configuração do IMDS no nível da conta pode ser substituída pelo modelo de execução ou pela configuração da AMI. As configurações do modelo do execução têm precedência sobre as configurações em nível de conta.
### AMI personalizada sem modelo de execução
Ao usar uma AMI personalizada sem um modelo de execução, escolha uma das seguintes opções:
1. **Usar o Amazon Linux 2023 como base** — Crie sua AMI personalizada usando o Amazon Linux 2023 como imagem base. Para obter informações sobre como criar AMIs personalizadas para o Batch, consulte [Tutorial: criar uma AMI de recurso de computação](create-batch-ami.md).
1. **Configurar IMDSv2 em sua AMI personalizada** — Ao criar sua AMI personalizada, configure-a para exigir o IMDSv2. Para as instruções, consulte [Configurar opções de metadados da instância para AMI personalizada](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#configure-IMDS-new-instances-ami-configuration) no *Guia do usuário do Amazon EC2*.
1. **Definir a configuração do IMDSv2 em nível de conta** — Configure sua conta AWS para exigir o IMDSv2 para todas as novas instâncias. Essa configuração afeta todas as novas instâncias que você executa na conta. Para obter instruções, consulte [Definir IMDSv2 como padrão para a conta](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#set-imdsv2-account-defaults) no *Guia do usuário do Amazon EC2*.
**nota**
A configuração do IMDS no nível da conta pode ser substituída pelo modelo de execução ou pela configuração da AMI. As configurações do modelo do execução têm precedência sobre as configurações em nível de conta.
### Usando modelos de execução
Ao usar modelos de execução em seu ambiente computacional, adicione opções de metadados ao seu modelo de execução para exigir o IMDSv2. Para obter mais informações sobre como usar modelos de execução com o Batch, consulte [Use os modelos de lançamento do Amazon EC2 com AWS Batch](launch-templates.md).
```
{
"LaunchTemplateName": "batch-imdsv2-template",
"VersionDescription": "IMDSv2 only template for Batch",
"LaunchTemplateData": {
"MetadataOptions": {
"HttpTokens": "required"
}
}
}
```
Como criar o modelo de execução usando o AWS CLI:
```
aws ec2 create-launch-template --cli-input-json file://imds-template.json
```
# Configurações do EC2
AWS Batch usa AMIs otimizadas do Amazon ECS para ambientes de computação EC2 e EC2 Spot. O padrão é o [Amazon Linux 2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2ami) (`ECS_AL2`). A partir de janeiro de 2026, o padrão mudará para [AL2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2023ami) (`ECS_AL2023`).
AWS encerrará o suporte para o Amazon Linux 2. Recomendamos a migração dos ambientes de computação AWS Batch Amazon ECS para o Amazon Linux 2023 para manter o desempenho e a segurança ideais. Para obter mais informações, consulte [Descontinuação da AMI Amazon ECS Amazon Linux 2](ecs-al2-ami-deprecation.md).
Recomendamos que você atualize os ambientes de computação existentes baseados no Amazon Linux para o Amazon Linux 2023 para evitar interrupções imprevistas da workload e continuar a receber atualizações de segurança e outras.
Para obter ajuda para migrar o AWS Batch do Amazon Linux AMI para o Amazon Linux 2023, consulte [Como migrar do ECS para o ECS AL2 AL2023](ecs-migration-2023.md)
**Topics**
+ [Como migrar do ECS para o ECS AL2 AL2023](ecs-migration-2023.md)
# Como migrar do ECS para o ECS AL2 AL2023
AL2023 é um sistema operacional baseado em Linux projetado para fornecer um ambiente seguro, estável e de alto desempenho para seus aplicativos em nuvem. Para obter mais informações sobre as diferenças entre AL2 e AL2023 consulte [Compare o Amazon Linux 2023 e o Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) no *Guia do usuário do Amazon Linux 2023*.
**Importante**
A partir de 30 de junho de 2026, AWS Batch bloqueará a criação de novos ambientes computacionais do Amazon ECS usando o Amazon Linux 2 fornecido em lote. AMIs É altamente recomendável migrar seus ambientes computacionais existentes do AWS Batch Amazon ECS para o Amazon Linux 2023 antes dessa data. Para obter mais informações, consulte [Descontinuação da AMI Amazon ECS Amazon Linux 2](ecs-al2-ami-deprecation.md).
Em 12 de janeiro de 2026, AWS Batch alterou a AMI padrão para novos ambientes computacionais do Amazon ECS do Amazon Linux 2 para o Amazon Linux 2023 porque AWS está [encerrando o suporte para o Amazon](https://aws.amazon.com/amazon-linux-2/faqs/) Linux 2. A AMI padrão é usada quando você não especifica um valor para o campo [ImageType.ec2Configuration](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html) ao criar um novo ambiente computacional. Recomendamos migrar os ambientes computacionais do AWS Batch Amazon ECS para o Amazon Linux 2023 para manter o desempenho e a segurança ideais.
Você pode acompanhar o status de migração dos seus ambientes computacionais afetados do Amazon ECS usando eventos de ciclo de vida planejados AWS da Health. Para obter mais informações, consulte [AWS Eventos do ciclo de vida do Health Planned](batch-planned-lifecycle-events.md).
Dependendo de como seu ambiente computacional está configurado, você pode usar um dos seguintes caminhos de atualização de AL2 para AL2023.
**Atualize usando o Ec2Configuration. ImageType**
+ [Se você não estiver usando um modelo de execução ou substituições de modelo de execução, altere Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)para `ECS_AL2023` (ou `ECS_AL2023_NVIDIA` ao usar instâncias de GPU) e depois executar [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html).
+ Se você especificar uma configuração [Ec2. ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)depois [Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)deve corresponder ao tipo de AMI especificado em [Ec2Configuration. ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride).
Se você não fizer a correspondência entre `ImageIdOverride` e `ImageType`, o ambiente computacional poderá não funcionar corretamente.
**Atualizar usando modelos de execução**
+ Se você usar um modelo de lançamento que especifica uma AMI com base em `ECS_AL2023`, certifique-se de que seu modelo de lançamento seja compatível com o Amazon Linux 2023. Para obter informações sobre mudanças do Amazon Linux 2023 para o AMI Amazon otimizado para ECS, consulte [Migrar de um Amazon Linux 2 para um Amazon Linuz 2023 AMI otimizado para ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html) no *Guia do usuário Amazon ECS*.
+ Para AL2023 AMIs, verifique se todos os dados personalizados do usuário ou scripts de inicialização são compatíveis com o AL2023 ambiente e o sistema de gerenciamento de pacotes.
**Atualize usando CloudFormation**
+ Se você usa CloudFormation para gerenciar seus ambientes de computação, atualize seu modelo para alterar a `ImageType` propriedade em `Ec2Configuration` from `ECS_AL2` to `ECS_AL2023` (ou `ECS_AL2023_NVIDIA` ao usar instâncias de GPU):
```
ComputeEnvironment:
Type: AWS::Batch::ComputeEnvironment
Properties:
ComputeResources:
Ec2Configuration:
- ImageType: ECS_AL2023
```
Em seguida, atualize sua CloudFormation pilha para aplicar as alterações.
+ Se seu CloudFormation modelo especificar uma AMI personalizada usando`ImageIdOverride`, certifique-se de que a ID da AMI corresponda a uma AMI AL2023 baseada e corresponda à `ImageType` configuração.
## Considerações sobre a migração
Ao migrar do Amazon Linux 2 para o Amazon Linux 2023, considere o seguinte:
+ **Gerenciamento de pacotes**: o Amazon Linux 2023 usa `dnf` em vez de `yum` para gerenciamento de pacotes.
+ **Serviços do sistema** — Alguns serviços do sistema e suas configurações podem diferir entre AL2 e. AL2023
+ **Tempo de execução do contêiner** — Ambos AL2 AL2023 oferecem suporte ao Docker, mas AL2023 podem ter configurações padrão diferentes.
+ **Segurança** — AL2023 inclui recursos de segurança aprimorados e pode exigir atualizações nas configurações relacionadas à segurança.
+ **Serviço de metadados de instância versão 2 (IMDSv2)** — O IMDSv2 é um serviço orientado a sessões que requer autenticação baseada em token para acessar os metadados da instância EC2, fornecendo segurança aprimorada. Para obter mais informações sobre o IMDS, consulte [Como funciona o Instance Metadata Service versão 2 no Guia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#instance-metadata-v2-how-it-works) do usuário do *Amazon EC2*.
Para obter uma lista abrangente de alterações e considerações de migração, consulte [Migrar de uma AMI do Amazon Linux 2 para uma AMI do Amazon Linux 2023 otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html) no *Guia do usuário Amazon ECS*.
# Estratégias de alocação de tipo de instância para AWS Batch
Quando um ambiente de computação gerenciado é criado, AWS Batch seleciona os tipos de instância `[instanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes)` especificados que melhor atendem às necessidades dos trabalhos. A estratégia de alocação define o comportamento quando AWS Batch precisa de capacidade adicional. Este parâmetro não é aplicável a trabalhos executados em recursos do Fargate. Não especifique este parâmetro.
`BEST_FIT` (padrão)
AWS Batch seleciona o tipo de instância que melhor se adapta às necessidades dos trabalhos, preferindo o tipo de instância de menor custo. Se instâncias adicionais do tipo de instância selecionado não estiverem disponíveis, AWS Batch aguarda até que as instâncias adicionais estejam disponíveis. Se não houver instâncias suficientes disponíveis ou se o usuário estiver atingindo os [limites de service quotas do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html), não serão executados trabalhos adicionais até que os trabalhos em execução no momento estejam concluídos. Essa estratégia de alocação mantém os custos mais baixos, mas pode limitar a escalabilidade. Se você estiver usando frota spot com o `BEST_FIT`, o perfil do IAM de frota spot deve ser especificada. O `BEST_FIT` não é compatível com a atualização de ambientes de computação. Para obter mais informações, consulte [Atualize um ambiente computacional no AWS Batch](updating-compute-environments.md).
AWS Batch gerencia AWS recursos em sua conta. Ambientes de computação com a estratégia de alocação BEST\$1FIT utilizavam originalmente configurações de lançamento por padrão. No entanto, o uso de configurações de lançamento com novas AWS contas será restrito ao longo do tempo. Portanto, a contar do final de abril de 2024, os ambientes de computação BEST\$1FIT recém-criados terão como padrão os modelos de lançamento. Se sua função de serviço não tiver permissões para gerenciar modelos de lançamento, AWS Batch poderá continuar a utilizar as configurações de lançamento. Os ambientes de computação existentes continuarão a usar as configurações de inicialização.
`BEST_FIT_PROGRESSIVE`
AWS Batch seleciona tipos de instância adicionais que são grandes o suficiente para atender aos requisitos dos trabalhos na fila. Os tipos de instância com um custo menor para cada unidade vCPU são preferidos. Se as instâncias adicionais dos tipos de instância selecionados anteriormente não estiverem disponíveis, o AWS Batch selecionará novos tipos de instância.
Para [trabalhos paralelos de vários nós](multi-node-parallel-jobs.md), o AWS Batch escolhe o tipo de instância ideal disponível. Se o tipo de instância ficar indisponível devido à capacidade insuficiente, outros tipos de instância da família não serão executados.
`SPOT_CAPACITY_OPTIMIZED`
AWS Batch seleciona um ou mais tipos de instância grandes o suficiente para atender aos requisitos dos trabalhos na fila. Os tipos de instância com menor probabilidade de serem interrompidos são preferidos. Essa estratégia de alocação só está disponível para recursos de computação de instâncias spot.
`SPOT_PRICE_CAPACITY_OPTIMIZED`
A estratégia de alocação otimizada para preço e capacidade analisa o preço e a capacidade para selecionar os grupos de instâncias spot com menor probabilidade de interrupção e com o preço mais baixo possível. Essa estratégia de alocação só está disponível para recursos de computação de instâncias spot.
Em vez disso, recomendamos utilizar `SPOT_PRICE_CAPACITY_OPTIMIZED` em vez de `SPOT_CAPACITY_OPTIMIZED` na maioria das instâncias.
As estratégias `BEST_FIT_PROGRESSIVE` e `BEST_FIT` usam instâncias spot ou sob demanda, e as estratégias `SPOT_CAPACITY_OPTIMIZED` e `SPOT_PRICE_CAPACITY_OPTIMIZED` usam instâncias spot. No entanto, AWS Batch talvez seja necessário exceder `maxvCpus` para atender aos seus requisitos de capacidade. Nesse caso, AWS Batch nunca `maxvCpus` excede em mais de uma única instância.
# Gerenciamento de memória de recursos de computação
Quando o agente de contêiner do Amazon ECS registra um recurso de computação da instância de contêiner em um ambiente de computação do cluster, o atendente deve determinar a quantidade de memória que o recurso de computação da instância de contêiner tem disponível para reservá-la para os seus trabalhos da tarefa. Devido à sobrecarga de memória da plataforma e a memória ocupada pelo kernel do sistema, esse número é diferente da quantidade de memória instalada 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 traduz para 8192 MiB de memória disponível para trabalhos nos quais o recurso de computação é registrado.
Suponha que você especifique 8192 MiB para o trabalho e que nenhum dos seus recursos de computação tenha 8192 MiB de memória disponível ou maior para satisfazer a esse requisito. O trabalho não poderá ser colocado em seu ambiente de computação. Se você estiver usando um ambiente de computação gerenciado, o AWS Batch deverá executar um tipo de instância maior para acomodar a solicitação.
A AMI padrão de recursos de computação AWS Batch também reserva 32 MiB de memória para o agente de contêiner do Amazon ECS e outros processos críticos do sistema. Essa memória não está disponível para alocação de trabalhos. Para obter mais informações, consulte [Reservar memória do sistema](ecs-reserved-memory.md).
O agente 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. O Linux oferece 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
```
O exemplo a seguir é um 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 8373026816 bytes de memória total. Isso significa que há 7985 MiB disponíveis para tarefas.
**Topics**
+ [Reservar memória do sistema](ecs-reserved-memory.md)
+ [Tutorial: visualizar memória de recursos de computação](viewing-memory.md)
+ [Considerações sobre memória e vCPU para AWS Batch no Amazon EKS](memory-cpu-batch-eks.md)
# Reservar memória do sistema
Se você ocupar toda a memória de um recurso de computação com seus trabalhos, é possível que os trabalhos disputem a memória com processos críticos do sistema e causem uma falha do sistema. O agente de contêiner do Amazon ECS fornece uma variável de configuração chamada `ECS_RESERVED_MEMORY`. Você pode usar essa variável de configuração para remover um número específico de MiB de memória do grupo alocado aos seus trabalhos. Isso reserva de forma efetiva a memória para processos críticos do sistema.
A AMI AWS Batch padrão de recursos de computação reserva 32 MiB de memória para o agente de contêiner do Amazon ECS e outros processos críticos do sistema. Recomendamos reservar um buffer de memória de 5% para o atendente de contêiner do Amazon ECS e outros processos críticos do sistema.
# Tutorial: visualizar memória de recursos de computação
É possível visualizar a quantidade de memória que um recurso de computação registra no campo do console do Amazon ECS ou por meio da operação da API [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html). Se você estiver tentando maximizar a sua utilização de recursos fornecendo aos trabalhos o máximo de memória possível para um tipo de instância específico, você poderá observar a memória disponível para esse recurso de computação e atribuir essa quantidade de memória aos seus trabalhos.
**Para visualizar a memória dos recursos de computação**
1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Escolha os **Clusters** e, em seguida, escolha o cluster que hospeda os recursos de computação a serem visualizados.
O nome do cluster do seu ambiente de computação começa com o seu nome do ambiente computacional.
1. Escolha **Infraestrutura**.
1. Em **Instâncias de Contêiner**, escolha a opção de instância de contêiner com a qual deseja estabelecer conexão.
1. A seção **Recursos e Rede** exibe a memória disponível registrada para o recurso de computação.
O valor da memória de **Capacidade total** é o mesmo registrado pelo recurso de computação com o Amazon ECS quando a instância foi executada primeiro, e o valor da memória **Disponível** é o valor ainda não atribuído aos trabalhos.
# Considerações sobre memória e vCPU para AWS Batch no Amazon EKS
No AWS Batch do Amazon EKS, você pode especificar os recursos que forem disponibilizados para um contêiner. Por exemplo, você pode especificar valores `requests` ou `limits` para recursos de vCPU e memória.
Os seguintes são as restrições para especificar os recursos de vCPU:
+ Pelo menos um valor de `requests` ou `limits` de vCPU deve ser especificado.
+ Uma unidade de vCPU é equivalente a um núcleo físico ou virtual.
+ O valor da vCPU deve ser inserido em números inteiros ou em acréscimos de 0,25.
+ O menor valor válido de vCPU é 0,25.
+ Se ambos forem especificados, o valor de `requests` deverá ser menor que ou igual ao valor de `limits`. Dessa forma, você pode configurar as configurações de vCPU flexíveis e rígidas.
+ Os valores de vCPU não podem ser especificados no formato milliCPU. Por exemplo, `100m` não é um valor válido.
+ AWS Batch utiliza o valor `requests` para decisões em escala. Se um valor `requests` não for especificado, o valor `limits` será copiado para o valor `requests`.
Os seguintes são as restrições para especificar os recursos de memória:
+ Pelo menos um valor de `requests` ou `limits` de memória deve ser especificado.
+ Os valores de memória devem estar em mebibytes (MiBs).
+ Se ambos forem especificados, o valor de `requests` deverá ser igual ao valor de `limits`.
+ AWS Batch utiliza o valor `requests` para decisões em escala. Se um valor de `requests` não for especificado, o valor de `limits` será copiado para o valor de `requests`.
Os seguintes são as restrições para especificar os recursos de GPU:
+ Se ambos forem especificados, o valor de `requests` deverá ser igual ao valor de `limits`.
+ AWS Batch utiliza o valor `requests` para decisões em escala. Se um valor `requests` não for especificado, o valor `limits` será copiado para o valor `requests`.
## Exemplos: definições de trabalho
O seguinte AWS Batch sobre a configuração de definição de trabalho do Amazon EKS configura compartilhamentos flexíveis de vCPU. Isso permite que o AWS Batch no Amazon EKS use toda a capacidade da vCPU para o tipo de instância. No entanto, caso existam outros trabalhos em execução, ao trabalho será alocado um máximo de `2` vCPUs. A memória é limitada a 2 GB.
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"requests": {
"cpu": "2",
"memory": "2048Mi"
}
}
}
]
}
}
}
```
O seguinte AWS Batch na definição de trabalho do Amazon EKS tem um valor `request` de `1` e aloca um máximo de `4` vCPUs para o trabalho.
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"requests": {
"cpu": "1"
},
"limits": {
"cpu": "4",
"memory": "2048Mi"
}
}
}
]
}
}
}
```
O seguinte AWS Batch na configuração de definição de trabalho do Amazon EKS define um valor `limits` de vCPU de `1` e um valor de `limits` de memória de 1 GB.
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
}
}
]
}
}
}
```
Quando o AWS Batch traduz um AWS Batch no trabalho do Amazon EKS em um pod do Amazon EKS, o AWS Batch copia o valor de `limits` para o valor de `requests`. Isso ocorre quando um valor de `requests` não é especificado. Quando você envia o exemplo de definição de trabalho de precedência, o pod `spec` é o seguinte.
```
apiVersion: v1
kind: Pod
...
spec:
...
containers:
- command:
- sleep
- 60
image: public.ecr.aws/amazonlinux/amazonlinux:2
resources:
limits:
cpu: 1
memory: 1024Mi
requests:
cpu: 1
memory: 1024Mi
...
```
## Reserva de Memória e Reserva de Nó de CPU
AWS Batch depende da lógica padrão do arquivo `bootstrap.sh` para reservas de vCPU e reservas de memória. Para mais informações sobre o arquivo `bootstrap.sh`, consulte [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh). Ao medir o tamanho dos seus recursos de vCPU e memória, considere os exemplos a seguir.
**nota**
Se nenhuma instância estiver em execução, as reservas de vCPU e reservas de memória podem, de início, afetar a lógica em escala do AWS Batch e a tomada de decisões. Depois que as instâncias estiverem em execução, o AWS Batch ajusta as alocações iniciais.
## Exemplo: reserva de nó de CPU
O valor da reserva de CPU é calculado em milicores usando o número de vCPUs total disponível para a instância.
| Número da vCPU | Porcentagem reservada |
| --- | --- |
| 1 | 6% |
| 2 | 1% |
| 3-4 | 0,5% |
| 4 e acima | 0.25% |
Usando os valores que precedem, o seguinte é verdadeiro:
+ O valor da reserva de CPU para uma instância `c5.large` com 2 vCPUs é 70 m. Isso é calculado da seguinte maneira: *(1\$160) \$1 (1\$110) = 70 m*.
+ O valor da reserva de CPU para uma instância `c5.24xlarge` com 96 vCPUs é 310 m. Isso é calculado da seguinte maneira: (1\$160) \$1 (1\$110) \$1 (2\$15) \$1 (92\$12.5) = 310 m.
Neste exemplo, há 1930 (calculadas de 2000-70) unidades de vCPU de milicore disponíveis para executar trabalhos em uma instância `c5.large`. Suponha que seu trabalho requeira `2` unidades de vCPU (2\$11000 m). O trabalho não caberá em uma instância única `c5.large`. No entanto, um trabalho que exige `1.75` unidades de vCPU é adequado.
## Exemplo: reserva de memória do nó
O valor da reserva de memória é calculado em mebibytes usando o seguinte:
+ a capacidade da instância em mebibytes. Por exemplo, uma instância de 8 GB tem 7.748 MiB.
+ O valor de `kubeReserved`. O valor de `kubeReserved` é a quantidade de memória a ser reservada para os daemons do sistema. O valor de `kubeReserved` é calculado no campo da seguinte forma: *((11 \$1 número de pods máximo compatível pelo tipo de instância) \$1 255)*. Para informações sobre o número máximo de pods compatível com cada tipo de instância, consulte [eni-max-pods.txt](https://github.com/awslabs/amazon-eks-ami/blob/main/nodeadm/internal/kubelet/eni-max-pods.txt)
+ O valor `HardEvictionLimit`. Quando a memória disponível fica abaixo do valor `HardEvictionLimit`, a instância tenta remover os pods.
A fórmula para calcular a memória disponível para alocação é a seguinte: (*instance\$1capacity\$1in\$1MiB*) - (11 \$1 (*maximum\$1number\$1of\$1pods*)) - 255 - (*`HardEvictionLimit`valor*)).
Uma instância `c5.large` suporta até 29 pods. Para uma instância `c5.large` de 8 GB com um valor `HardEvictionLimit` de 100 MiB, a memória disponível para alocação é 7074 MiB. Isso é calculado da seguinte maneira: *(7748 - (11 \$1 29) -255 -100) = 7074 MiB*. Neste exemplo, um trabalho MiB de 8.192 não cabe nessa instância, embora seja uma instância de 8 gibibyte (GiB).
## DaemonSets
Ao usar DaemonSets, considere o seguinte:
+ Se nenhum AWS Batch nas instâncias do Amazon EKS estiver em execução, DaemonSets pode afetar inicialmente a lógica em escala do AWS Batch e a tomada de decisões. Inicialmente, AWS Batch aloca 0,5 unidades de vCPU e 500 MiB para o DaemonSets esperado. Depois que as instâncias estiverem em execução, o AWS Batch ajusta as alocações iniciais.
+ Se um DaemonSet definir limites de vCPU ou limite de memória, os trabalhos AWS Batch no Amazon EKS terão menos recursos. Recomendamos que você mantenha o número de DaemonSets atribuídos a trabalhos AWS Batch o mais baixo possível.
# Ambientes de computação Fargate
O Fargate é uma tecnologia que você pode usar AWS Batch para executar [contêineres](https://aws.amazon.com/what-are-containers) sem precisar gerenciar servidores ou clusters de instâncias do Amazon EC2. Com o Fargate, não é mais necessário provisionar, configurar nem escalar os clusters de máquinas virtuais para executar contêineres. Isso elimina a necessidade de escolher tipos de servidor, decidir quando dimensionar clusters ou otimizar o agrupamento de clusters.
Ao executar seus trabalhos com recursos do Fargate, você empacota sua aplicação em contêineres, especifica os requisitos de CPU e de memória, define as políticas do IAM e de rede e inicia a aplicação. Cada trabalho do Fargate tem seu próprio limite de isolamento e não compartilha o kernel subjacente, os recursos de CPU, os recursos de memória nem a interface de rede elástica com outro trabalho.
O Fargate só está disponível para ambientes AWS Batch computacionais que usam o Amazon ECS como orquestrador. O Fargate não é compatível com os ambientes computacionais AWS Batch Amazon EKS. Para obter mais informações, consulte [Ambientes de computação Amazon EKS](eks.md).
**Topics**
+ [Quando usar o Fargate](when-to-use-fargate.md)
+ [Definições de trabalho no Fargate](fargate-job-definitions.md)
+ [Filas de trabalhos no Fargate](fargate-job-queues.md)
+ [Ambientes de computação no Fargate](fargate-compute-environments.md)
# Quando usar o Fargate
Recomendamos usar o Fargate na maioria dos cenários. O Fargate inicia e escala a computação de acordo com os requisitos de recursos que você especifica para o contêiner. Com o Fargate, você não precisa provisionar em excesso nem pagar por servidores adicionais. Você também não precisa se preocupar com as especificidades dos parâmetros relacionados à infraestrutura, como o tipo de instância. Quando o ambiente de computação precisa ter a escala aumentada verticalmente, os trabalhos executados nos recursos do Fargate podem ser iniciados mais rapidamente. Normalmente, são necessários alguns minutos para ativar uma nova instância do Amazon EC2. No entanto, as tarefas executadas no Fargate podem ser provisionadas em cerca de 30 segundos. O tempo exato necessário depende de vários fatores, incluindo o tamanho da imagem do contêiner e o número de trabalhos.
No entanto, recomendamos que você use o Amazon EC2 se seus trabalhos exigirem qualquer um dos seguintes:
+ Mais de 16 v CPUs
+ Mais de 120 gibibytes (GiB) de memória
+ UMA GPU
+ Imagem de máquina da Amazon (AMI) personalizada
+ Qualquer um dos parâmetros do [linuxParameters](job_definition_parameters.md#ContainerProperties-linuxParameters)
Se você tem um grande número de trabalhos, recomendamos usar a infraestrutura do Amazon EC2. Por exemplo, se o número de trabalhos em execução simultânea exceder os limites de controle de utilização do Fargate. Isso ocorre porque, com o EC2, os trabalhos podem ser enviados em uma taxa maior para os recursos do EC2 do que para os recursos do Fargate. Além disso, mais trabalhos podem ser executados simultaneamente quando você usa o EC2. Para obter mais informações, consulte [Service quotas Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html#service-quotas-fargate) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
# Definições de trabalho no Fargate
AWS Batch as tarefas AWS Fargate ativadas não oferecem suporte a todos os parâmetros de definição de tarefas disponíveis. Alguns parâmetros são totalmente incompatíveis e outros se comportam de maneira diferente nos trabalhos do Fargate.
A lista a seguir descreve os parâmetros de definição de tarefa que não são válidos ou são restritos nos trabalhos do Fargate.
`platformCapabilities`
Deve ser especificado como `FARGATE`.
```
"platformCapabilities": [ "FARGATE" ]
```
`type`
Deve ser especificado como `container`.
```
"type": "container"
```
Parâmetros em `containerProperties`
`executionRoleArn`
Deve ser especificado para trabalhos em execução nos recursos do Fargate. Para mais informações, consulte [Funções do IAM para Tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) no *Guia de Desenvolvedor Amazon Elastic Container Service*.
```
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
```
`fargatePlatformConfiguration`
(Opcional, somente para definições de trabalho do Fargate). Especifica a versão da plataforma do Fargate a `LATEST` ou de uma versão da plataforma recente. Valores possíveis para `platformVersion` são `1.3.0`, `1.4.0` e `LATEST` (padrão).
```
"fargatePlatformConfiguration": { "platformVersion": "1.4.0" }
```
`instanceType``ulimits`
Não é aplicável a trabalhos executados nos recursos do Fargate.
`memory``vcpus`
Essas configurações devem ser especificadas em `resourceRequirements`
`privileged`
Não especifique esse parâmetro ou especifique `false`.
```
"privileged": false
```
`resourceRequirements`
Os requisitos de memória e vCPU devem ser especificados usando [valores compatíveis](job_definition_parameters.md#ContainerProperties-resourceRequirements-Fargate-memory-vcpu). Os recursos de GPU não são compatíveis com trabalhos executados nos recursos do Fargate.
Se você usa o GuardDuty Runtime Monitoring, há uma pequena sobrecarga de memória para o agente GuardDuty de segurança. Portanto, o limite de memória deve incluir o tamanho do agente GuardDuty de segurança. Para obter informações sobre os limites de memória do GuardDuty Security Agent, consulte [Limites de CPU e memória](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html#ecs-runtime-agent-cpu-memory-limits) no *Guia GuardDuty do usuário*. Para obter informações sobre as práticas recomendadas, consulte [Como corrigir erros de falta de memória nas minhas tarefas do Fargate após habilitar o Monitoramento de runtime](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-guard-duty-troubleshooting.html#memory-error), no *Guia do desenvolvedor do Amazon ECS*.
```
"resourceRequirements": [
{"type": "MEMORY", "value": "512"},
{"type": "VCPU", "value": "0.25"}
]
```
Parâmetros em `linuxParameters`
`devices``maxSwap``sharedMemorySize``swappiness``tmpfs`
Não é aplicável a trabalhos que sejam executados nos recursos do Fargate.
Parâmetros em `logConfiguration`
`logDriver`
Somente `awslogs` e `splunk` são compatíveis. Para obter mais informações, consulte [Usar o driver de log awslogs.](using_awslogs.md).
Membros em `networkConfiguration`
`assignPublicIp`
Se a sub-rede privada não tiver um gateway NAT conectado para enviar tráfego para a Internet, `[assignPublicIp](https://docs.aws.amazon.com/batch/latest/APIReference/API_NetworkConfiguration.html#Batch-Type-NetworkConfiguration-assignPublicIp)` deverá ser “`ENABLED`”. Para obter mais informações, consulte [AWS Batch Função de execução do IAM](execution-IAM-role.md).
# Filas de trabalhos no Fargate
AWS Batch as filas de trabalho AWS Fargate ativadas permanecem essencialmente inalteradas. A única restrição é que os ambientes de computação listados em `computeEnvironmentOrder` devem ser todos ambientes de computação Fargate (`FARGATE` ou `FARGATE_SPOT`). Os ambientes de computação EC2 e Fargate não podem ser misturados.
# Ambientes de computação no Fargate
AWS Batch os ambientes computacionais ativados AWS Fargate não oferecem suporte a todos os parâmetros do ambiente computacional disponíveis. Alguns parâmetros são totalmente incompatíveis. Outros têm requisitos específicos para o Fargate.
A lista a seguir descreve os parâmetros do ambiente de computação que não são válidos ou são restritos nos trabalhos do Fargate.
`type`
Esse parâmetro precisa ser `MANAGED`.
```
"type": "MANAGED"
```
Parâmetros no objeto `computeResources`
`allocationStrategy``bidPercentage``desiredvCpus``imageId``instanceTypes``ec2Configuration``ec2KeyPair``instanceRole``launchTemplate``minvCpus``placementGroup``spotIamFleetRole`
Eles não são aplicáveis aos ambientes de computação Fargate e não podem ser fornecidos.
`subnets`
Se as sub-redes listadas nesse parâmetro não tiverem gateways NAT conectados, o parâmetro `assignPublicIp` na definição do trabalho deverá ser definido como `ENABLED`.
`tags`
Isso não é aplicável aos ambientes de computação Fargate e não pode ser fornecido. Para especificar tags para ambientes de computação Fargate, use o parâmetro `tags` que não está no objeto `computeResources`.
`type`
Isso deve ser `FARGATE` ou `FARGATE_SPOT`.
```
"type": "FARGATE_SPOT"
```
# Ambientes de computação Amazon EKS
[Começando a usar AWS Batch no Amazon EKS](getting-started-eks.md)fornece um pequeno guia para criar ambientes de computação EKS. Esta seção fornece mais detalhes sobre os ambientes de computação do Amazon EKS.
![\[AWS Batch workflow diagram showing integration with Amazon EKS, ECS, Fargate, and EC2.\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/images/batch-on-eks.png)
AWS Batch simplifica suas cargas de trabalho em lotes nos clusters do Amazon EKS fornecendo recursos gerenciados em lotes. Isso inclui filas, rastreamento de dependências, tentativas e prioridades gerenciadas de tarefas, gerenciamento de pods e escalabilidade de nós. AWS Batch pode lidar com várias zonas de disponibilidade e vários tipos e tamanhos de instâncias do Amazon EC2. AWS Batch integra várias das melhores práticas do Amazon EC2 Spot para executar suas cargas de trabalho de forma tolerante a falhas, permitindo menos interrupções. Você pode usar o AWS Batch para executar um punhado de trabalhos noturnos ou milhões de trabalhos essenciais à missão com confiança.
![\[AWS Batch workflow on Amazon EKS, showing job queue, compute environment, and EC2 instances.\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/images/batch-on-eks-detail.png)
AWS Batch é um serviço gerenciado que orquestra cargas de trabalho em lotes em seus Kubernetes clusters que são gerenciados pelo Amazon Elastic Kubernetes Service (Amazon EKS). AWS Batch conduz essa orquestração externamente aos seus clusters usando um modelo de “sobreposição”. Como AWS Batch é um serviço gerenciado, não há Kubernetes componentes (por exemplo, operadores ou recursos personalizados) para instalar ou gerenciar em seu cluster. AWS Batch só precisa que seu cluster seja configurado com controles de acesso baseados em funções (RBAC) que permitem AWS Batch a comunicação com o servidor da API. Kubernetes AWS Batch chamadas Kubernetes APIs para criar, monitorar e excluir Kubernetes pods e nós.
AWS Batch tem lógica de escalabilidade integrada para escalar Kubernetes nós com base na carga da fila de trabalhos com otimizações em termos de alocações de capacidade de trabalho. Quando a fila de trabalhos está vazia AWS Batch , reduz os nós até a capacidade mínima que você define, que por padrão é zero. AWS Batch gerencia todo o ciclo de vida desses nós e decora os nós com rótulos e manchas. Dessa forma, outras Kubernetes cargas de trabalho não são colocadas nos nós gerenciados pelo AWS Batch. A exceção a isso é`DaemonSets`, que pode direcionar AWS Batch os nós para fornecer monitoramento e outras funcionalidades necessárias para a execução adequada dos trabalhos. Além disso, AWS Batch não executa trabalhos, especificamente pods, em nós do seu cluster que ele não gerencia. Assim, você pode usar lógica e serviços de escalabilidade separadamente para outros aplicativos no cluster.
Para enviar trabalhos para AWS Batch, você interage diretamente com a AWS Batch API. AWS Batch traduz trabalhos em `podspecs` e, em seguida, cria as solicitações para colocar pods em nós gerenciados pelo seu AWS Batch cluster Amazon EKS. Você pode usar ferramentas como `kubectl` para visualizar pods e nós em execução. Quando um pod conclui sua execução, AWS Batch exclui o pod criado para manter uma carga menor no Kubernetes sistema.
Você pode começar conectando um cluster válido do Amazon EKS com AWS Batch o. Em seguida, anexe uma fila de AWS Batch trabalhos a ela e registre uma definição de trabalho do Amazon EKS usando atributos `podspec` equivalentes. Por fim, envie trabalhos usando a operação [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)da API que faz referência à definição do trabalho. Para obter mais informações, consulte [Começando a usar AWS Batch no Amazon EKS](getting-started-eks.md).
AWS Batch no Amazon EKS oferece suporte a instâncias do Amazon EC2 (sob demanda e spot) como recursos computacionais. Para usar o Fargate com AWS Batch, use um ambiente computacional Amazon ECS em vez disso. Para obter mais informações, consulte [Ambientes de computação Fargate](fargate.md).
## Amazon EKS
**Topics**
+ [Amazon EKS](#compute-environments-eks)
+ [AMI padrão do Amazon EKS](eks-ce-ami-selection.md)
+ [Ambientes AMI mistos](mixed-ami-environments.md)
+ [Versões do Kubernetes com suporte](supported_kubernetes_version.md)
+ [Atualizar a versão Kubernetes do ambiente de computação](updating-k8s-version-ce.md)
+ [Responsabilidade compartilhada dos nós Kubernetes](eks-ce-shared-responsibility.md)
+ [Execute um DaemonSet em nós AWS Batch gerenciados](daemonset-on-batch-eks-nodes.md)
+ [Personalize os modelos de lançamento do Amazon EKS](eks-launch-templates.md)
+ [Como fazer o upgrade do EKS AL2 para o EKS AL2023](eks-migration-2023.md)
# AMI padrão do Amazon EKS
Ao criar um ambiente computacional Amazon EKS, você não precisa especificar uma Amazon Machine Image (AMI). AWS Batch seleciona uma AMI otimizada para Amazon EKS com base na Kubernetes versão e nos tipos de instância especificados na sua [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)solicitação. Em geral, recomendamos usar a seleção AMI do padrão. Para obter informações sobre a precedência da seleção de AMI, consulte[Ordem de seleção da AMI](ami-selection-order.md). Para obter mais informações sobre o Amazon EKS otimizado AMIs, consulte [Amazon Linux otimizado para Amazon EKS AMIs](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) no *Guia do usuário do Amazon EKS*.
**Importante**
O Amazon Linux 2023 AMIs é o padrão AWS Batch para o Amazon EKS.
AWS encerrará o suporte para o Amazon EKS AL2 otimizado e AL2 acelerado a partir de 26/11/25 AMIs. Você pode continuar usando o Amazon Linux 2 otimizado para Amazon EKS AWS Batch fornecido AMIs em seus ambientes computacionais do Amazon EKS após a end-of-support data de 26/11/25. No entanto, esses ambientes computacionais não receberão mais novas atualizações de software, patches de segurança ou correções de bugs. AWS Para obter mais informações sobre a atualização de AL2 para AL2023, consulte [Como fazer o upgrade do EKS AL2 para o EKS AL2023](eks-migration-2023.md) o *Guia do AWS Batch usuário*.
Execute o comando a seguir para ver qual tipo de AMI AWS Batch foi selecionado para seu ambiente computacional Amazon EKS. O exemplo a seguir é um tipo de instância sem GPU.
```
# compute CE example: indicates Batch has chosen the AL2 x86 or ARM EKS 1.32 AMI, depending on instance types
$ aws batch describe-compute-environments --compute-environments My-Eks-CE1 \
| jq '.computeEnvironments[].computeResources.ec2Configuration'
[
{
"imageType": "EKS_AL2",
"imageKubernetesVersion": "1.32"
}
]
```
O exemplo a seguir é um tipo de instância de GPU.
```
# GPU CE example: indicates Batch has choosen the AL2 x86 EKS Accelerated 1.32 AMI
$ aws batch describe-compute-environments --compute-environments My-Eks-GPU-CE \
| jq '.computeEnvironments[].computeResources.ec2Configuration'
[
{
"imageType": "EKS_AL2_NVIDIA",
"imageKubernetesVersion": "1.32"
}
]
```
# Ambientes AMI mistos
Você pode usar substituições de modelos de lançamento para criar ambientes computacionais com o Amazon Linux 2 () AL2 e o Amazon Linux 2023 (). AL2023 AMIs Isso é útil para usar diferentes AMIs arquiteturas ou durante períodos de migração durante a transição de para. AL2 AL2023
**nota**
AWS encerrará o suporte para o Amazon EKS AL2 otimizado e AL2 acelerado a partir de 26/11/25 AMIs. Embora você possa continuar usando o Amazon Linux 2 otimizado para Amazon EKS AWS Batch fornecido AMIs em seus ambientes computacionais do Amazon EKS após a end-of-support data de 26/11/25, esses ambientes computacionais não receberão mais novas atualizações de software, patches de segurança ou correções de bugs. AWS Ambientes mistos de AMI podem ser úteis durante o período de transição, permitindo que você migre gradualmente as cargas de trabalho e AL2023 mantenha a compatibilidade com as cargas de trabalho AL2 baseadas existentes.
Exemplo de configuração usando os dois tipos de AMI:
```
{
"computeResources": {
"launchTemplate": {
"launchTemplateId": "TemplateId",
"version": "1",
"userdataType": "EKS_BOOTSTRAP_SH",
"overrides": [
{
"instanceType": "c5.large",
"imageId": "ami-al2-custom",
"userdataType": "EKS_BOOTSTRAP_SH"
},
{
"instanceType": "c6a.large",
"imageId": "ami-al2023-custom",
"userdataType": "EKS_NODEADM"
}
]
},
"instanceTypes": ["c5.large", "c6a.large"]
}
}
```
# Versões do Kubernetes com suporte
AWS Batch no Amazon EKS atualmente oferece suporte às seguintes Kubernetes versões:
+ `1.34`
+ `1.33`
+ `1.32`
+ `1.31`
+ `1.30`
+ `1.29`
Talvez você veja uma mensagem de erro semelhante à seguinte ao usar a operação de `CreateComputeEnvironment` API ou a operação de `UpdateComputeEnvironment` API para criar ou atualizar um ambiente de computação. Esse problema ocorre se você especificar uma versão Kubernetes não suportada em `EC2Configuration`.
```
At least one imageKubernetesVersion in EC2Configuration is not supported.
```
Para resolver esse problema, exclua o ambiente de computação e recrie-o com uma versão Kubernetes compatível.
Você pode realizar uma pequena atualização de versão no seu cluster Amazon EKS. Por exemplo, você pode atualizar o cluster de `1.xx` para, `1.yy` mesmo que a versão secundária não seja compatível.
No entanto, o status do ambiente de computação pode mudar para `INVALID` depois de uma atualização de versão principal. Por exemplo, se você realizar uma atualização de versão principal de `1.xx` para `2.yy`. Se a versão principal não for compatível com AWS Batch, você verá uma mensagem de erro semelhante à seguinte.
```
reason=CLIENT_ERROR - ... EKS Cluster version [2.yy] is unsupported
```
# Atualizar a versão Kubernetes do ambiente de computação
Com AWS Batch, você pode atualizar a Kubernetes versão de um ambiente computacional para oferecer suporte às atualizações de cluster do Amazon EKS. A Kubernetes versão de um ambiente computacional é a versão do Amazon EKS AMI para os Kubernetes nós que são AWS Batch iniciados para executar trabalhos. Você pode realizar uma atualização de versão Kubernetes em seus nós do Amazon EKS antes ou depois de atualizar a versão do ambiente de gerenciamento do cluster do Amazon EKS. Recomendamos que você atualize os nós após atualizar o plano de controle. Para obter mais informações, consulte [Atualizando uma versão Kubernetes do cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html) no *Guia do usuário do Amazon EKS*.
Para atualizar a versão Kubernetes de um ambiente de computação, use a operação API [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html).
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources \
'ec2Configuration=[{imageType=EKS_AL2,imageKubernetesVersion=1.32}]'
```
# Responsabilidade compartilhada dos nós Kubernetes
A manutenção dos ambientes de computação é uma responsabilidade compartilhada.
+ Não altere nem remova AWS Batch nós, rótulos, manchas, namespaces, modelos de lançamento ou grupos de escalonamento automático. Não adicione manchas aos nós AWS Batch gerenciados. Se você fizer alguma dessas alterações, seu ambiente de computação não poderá ser compatível e ocorrerão falhas, incluindo instâncias ociosas.
+ Não direcione seus pods para nós AWS Batch gerenciados. Se você direcionar seus pods para os nós gerenciados, ocorrerão falhas no escalonamento e filas de trabalhos paralisadas. Execute cargas de trabalho que não são usadas AWS Batch em nós autogerenciados ou grupos de nós gerenciados. Para obter mais informações, consulte [Grupos de nós gerenciados](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) no *Guia do usuário do Amazon EKS*.
+ Você pode DaemonSet direcionar um para ser executado em nós AWS Batch gerenciados. Para obter mais informações, consulte [Execute um DaemonSet em nós AWS Batch gerenciados](daemonset-on-batch-eks-nodes.md).
AWS Batch não atualiza automaticamente o ambiente AMIs computacional. É sua responsabilidade atualizá-las. Execute o comando a seguir para atualizá-lo AMIs para a versão mais recente da AMI.
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources 'updateToLatestImageVersion=true'
```
AWS Batch não atualiza automaticamente a Kubernetes versão. Execute o comando a seguir para atualizar a Kubernetes versão do ambiente do seu computador para *1.32* o.
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources \
'ec2Configuration=[{imageType=EKS_AL2,imageKubernetesVersion=1.32}]'
```
Ao atualizar para uma AMI ou versão Kubernetes mais recente, você pode especificar se os trabalhos serão encerrados quando eles forem atualizados (`terminateJobsOnUpdate`) e quanto tempo esperar até que uma instância seja substituída se os trabalhos em execução não forem concluídos (`jobExecutionTimeoutMinutes`.) Para obter mais informações, consulte [Atualize um ambiente computacional no AWS Batch](updating-compute-environments.md) e a política de atualização de infraestrutura ([https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdatePolicy.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdatePolicy.html)) definida na operação da API [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html).
# Execute um DaemonSet em nós AWS Batch gerenciados
AWS Batch define manchas nos Kubernetes nós AWS Batch gerenciados. Você pode DaemonSet direcionar um para ser executado em nós AWS Batch gerenciados com o seguinte`tolerations`.
```
tolerations:
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
```
Outra maneira de fazer isso é com o `tolerations` a seguir.
```
tolerations:
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
effect: "NoSchedule"
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
effect: "NoExecute"
```
# Personalize os modelos de lançamento do Amazon EKS
AWS Batch no Amazon EKS oferece suporte a modelos de lançamento. Há restrições sobre o que seu modelo de lançamento pode fazer.
**Importante**
Para EKS AL2 AMIs, AWS Batch funciona`/etc/eks/bootstrap.sh`. Não execute `/etc/eks/bootstrap.sh` em seu modelo de lançamento ou scripts cloud-init user-data. Você pode adicionar outros parâmetros além do parâmetro `--kubelet-extra-args` ao [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh). Para fazer isso, defina a variável `AWS_BATCH_KUBELET_EXTRA_ARGS` no arquivo `/etc/aws-batch/batch.config`. Consulte o código a seguir para ver um exemplo.
Para o EKS AL2023, AWS Batch utiliza o [NodeConfigSpec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)do EKS para fazer com que as instâncias se juntem ao cluster EKS. AWS Batch é [ClusterDetails](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#clusterdetails)preenchido [NodeConfigSpec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)para o cluster EKS e você não precisa especificá-los.
**nota**
Recomendamos que você não defina nenhuma das [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)configurações a seguir no modelo de lançamento, pois AWS Batch substituirá seus valores. Para obter mais informações, consulte [Responsabilidade compartilhada dos nós Kubernetes](eks-ce-shared-responsibility.md).
`Taints`
`Cluster Name`
`apiServerEndpoint`
`certificatAuthority`
`CIDR`
Não crie rótulos com o prefixo `batch.amazonaws.com/`
**nota**
Se o modelo de lançamento for alterado após [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)ser chamado, [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)deverá ser chamado para avaliar a versão do modelo de lançamento para substituição.
**Topics**
+ [Adicionar argumentos extras de `kubelet`](#kubelet-extra-args)
+ [Configurar o runtime do contêiner](#change-container-runtime)
+ [Montar um volume do Amazon EFS](#mounting-efs-volume)
+ [IPv6 apoio](#eks-ipv6-support)
## Adicionar argumentos extras de `kubelet`
AWS Batch suporta a adição de argumentos extras ao `kubelet` comando. Para obter a lista completa de parâmetros compatíveis, consulte [https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) na *documentação Kubernetes*. No exemplo a seguir para EKS AL2 AMIs, `--node-labels mylabel=helloworld` é adicionado à linha de `kubelet` comando.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
mkdir -p /etc/aws-batch
echo AWS_BATCH_KUBELET_EXTRA_ARGS=\"--node-labels mylabel=helloworld\" >> /etc/aws-batch/batch.config
--==MYBOUNDARY==--
```
Para EKS AL2023 AMIs , o formato do arquivo é YAML. Para obter a lista completa de parâmetros compatíveis, consulte [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec) na *documentação Kubernetes*. No exemplo a seguir para EKS AL2023 AMIs, `--node-labels mylabel=helloworld` é adicionado à linha de `kubelet` comando.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=mylabel=helloworld
--==MYBOUNDARY==--
```
## Configurar o runtime do contêiner
Você pode usar a variável de AWS Batch `CONTAINER_RUNTIME` ambiente para configurar o tempo de execução do contêiner em um nó gerenciado. O exemplo a seguir define o runtime do contêiner para `containerd` quando `bootstrap.sh` for executado. Para obter mais informações, consulte [https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd) *na documentação Kubernetes*.
Se você estiver usando uma AMI otimizada `EKS_AL2023` ou `EKS_AL2023_NVIDIA`, não precisará especificar o runtime do contêiner, pois somente **containerd** é compatível.
**nota**
A variável de ambiente `CONTAINER_RUNTIME` é equivalente à opção `--container-runtime` de `bootstrap.sh`. Para obter mais informações, consulte [https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options) *na documentação Kubernetes*.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
mkdir -p /etc/aws-batch
echo CONTAINER_RUNTIME=containerd >> /etc/aws-batch/batch.config
--==MYBOUNDARY==--
```
## Montar um volume do Amazon EFS
Você pode usar modelos de execução para montar volumes no nó. No exemplo a seguir, as configurações `cloud-config` `packages` e `runcmd` são usadas. Para obter mais informações, consulte [Exemplos de configuração de Nuvem](https://cloudinit.readthedocs.io/en/latest/topics/examples.html) na *documentação cloud-init*.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
packages:
- amazon-efs-utils
runcmd:
- file_system_id_01=fs-abcdef123
- efs_directory=/mnt/efs
- mkdir -p ${efs_directory}
- echo "${file_system_id_01}:/ ${efs_directory} efs _netdev,noresvport,tls,iam 0 0" >> /etc/fstab
- mount -t efs -o tls ${file_system_id_01}:/ ${efs_directory}
--==MYBOUNDARY==--
```
Para usar esse volume na tarefa, ele deve ser adicionado ao parâmetro [EksProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) a. [RegisterJobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html) O exemplo a seguir é uma grande parte da definição do trabalho.
```
{
"jobDefinitionName": "MyJobOnEks_EFS",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["ls", "-la", "/efs"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
},
"volumeMounts": [
{
"name": "efs-volume",
"mountPath": "/efs"
}
]
}
],
"volumes": [
{
"name": "efs-volume",
"hostPath": {
"path": "/mnt/efs"
}
}
]
}
}
}
```
No nó, o volume do Amazon EFS é montado no diretório `/mnt/efs`. No contêiner do trabalho do Amazon EKS, o volume é montado no diretório `/efs`.
## IPv6 apoio
AWS Batch é compatível com clusters Amazon EKS que têm IPv6 endereços. Nenhuma personalização é necessária para AWS Batch suporte. No entanto, antes de começar, recomendamos que você analise as considerações e condições descritas em [Atribuição de IPv6 endereços a pods e serviços no](https://docs.aws.amazon.com/eks/latest/userguide/cni-ipv6.html) Guia do usuário do *Amazon* EKS.
# Como fazer o upgrade do EKS AL2 para o EKS AL2023
Os Amazon EKS otimizados AMIs estão disponíveis em duas famílias com base no Amazon Linux 2 (AL2) e no Amazon Linux 2023 (AL2023). AL2023 é um sistema operacional baseado em Linux projetado para fornecer um ambiente seguro, estável e de alto desempenho para seus aplicativos em nuvem. Para obter mais informações sobre as diferenças entre AL2 e AL2023 consulte [Atualização do Amazon Linux 2 para o Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/al2023.html) no *Guia do usuário do Amazon EKS*.
**Importante**
AWS encerrou o suporte para o Amazon EKS AL2 -otimizado e AL2 acelerado AMIs em 26 de novembro de 2025. AWS Batch Os ambientes computacionais do Amazon EKS que usam o Amazon Linux 2 não recebem mais atualizações de software, patches de segurança ou correções de bugs do AWS. Recomendamos migrar os ambientes computacionais do AWS Batch Amazon EKS para o Amazon Linux 2023 para manter o desempenho e a segurança ideais. Posteriormente end-of-life, é sua [responsabilidade manter](eks-ce-shared-responsibility.md) esses ambientes computacionais na AMI Amazon Linux 2 otimizada para Amazon EKS.
Dependendo de como seu ambiente computacional está configurado, você pode usar um dos seguintes caminhos de atualização de AL2 para AL2023.
**Atualize usando o Ec2Configuration. ImageType**
+ [Se você não estiver usando um modelo de execução ou substituições de modelo de execução, altere Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)para `EKS_AL2023` ou `EKS_AL2023_NVIDIA` e depois execute [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html).
+ Se você especificar uma configuração [Ec2. ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)depois [Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)deve corresponder ao tipo de AMI especificado em [Ec2Configuration. ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride).
Se você não corresponder `ImageIdOverride` e `ImageType`, o nó não se juntará ao cluster.
**Atualizar usando modelos de execução**
+ Se você tiver argumentos `kubelet` extras definidos em um modelo de execução ou substituição de modelo de execução, eles precisarão ser atualizados para o novo [formato de argumentos `kubelet` extras](eks-launch-templates.md#kubelet-extra-args).
Se você não corresponder ao formato dos argumentos extras `kubelet`, os argumentos extras não serão aplicados.
+ Pois AL2023 AMIs, **containerd** é o único ambiente de execução de contêiner compatível. Você não precisa especificar um runtime de contêiner para `EKS_AL2023` no modelo de execução.
Você não pode especificar um tempo de execução de contêiner personalizado com`EKS_AL2023`.
+ Se você usar um modelo de execução ou uma substituição de modelo de execução que especifique uma AMI com base em `EKS_AL2023`, você precisará definir [userDataType](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html) como `EKS_NODEADM`.
Se você não corresponder `userdataType` e AMI, o nó não se juntará ao cluster EKS.