

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á.

# Atualize um ambiente computacional no AWS Batch
<a name="updating-compute-environments"></a>

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
<a name="update-strategies"></a>

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
<a name="choosing-update-strategies"></a>

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
<a name="scaling-updates-when"></a>

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
<a name="infrastructure-updates-when"></a>

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
<a name="blue-green-updates-when"></a>

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 name="ami-update-considerations"></a>

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
<a name="automatic-ami-updates"></a>

AWS Batch pode atualizar para a AMI otimizada para Amazon ECS mais recente durante as atualizações de [infraestrutura](infrastructure-updates.md#infrastructure-updates.title) 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`
+ Nenhum ID AMI está explicitamente especificado em `imageId`, `imageIdOverride` ou no modelo de lançamento
+ `updateToLatestImageVersion` é definido como `true`

### Atualizações da AMI usando a blue/green implantação
<a name="manual-ami-updates-blue-green"></a>

Você deve usar a blue/green implantação para atualizar AMIs nesses cenários:
+ Ao usar a estratégia de alocação `BEST_FIT` (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
<a name="manual-ami-updates-custom-ami"></a>

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
<a name="scaling-updates"></a>

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
<a name="scaling-updates-triggers"></a>

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#infrastructure-updates.title).

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
<a name="scaling-updates-monitoring"></a>

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
<a name="infrastructure-updates"></a>

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
<a name="infrastructure-updates-triggers"></a>

Quando você modifica qualquer uma das configurações a seguir, AWS Batch realiza 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
<a name="updating-compute-environments-ami"></a>

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
<a name="infrastructure-updates-job-handling"></a>

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 ]

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
<a name="infrastructure-updates-monitoring"></a>

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 da instância 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
<a name="blue-green-updates"></a>

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
<a name="blue-green-overview"></a>

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
<a name="blue-green-when-required"></a>

Você deve usar blue/green as atualizações nas seguintes situações:
+ Quando seu ambiente computacional usa a estratégia de alocação `BEST_FIT` (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 perfil de serviço

### Quando blue/green as atualizações são recomendadas
<a name="blue-green-when-recommended"></a>

Blue/green updates are particularly recommended for production environments where zero downtime is critical for your workloads. This approach works well when you need to test new configurations before transitioning production workloads, ensuring that changes meet your performance and reliability requirements. Choose blue/greenatualiza quando a capacidade de reversão rápida é 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
<a name="blue-green-prerequisites"></a>

Antes de realizar uma blue/green atualização, verifique se você tem:
+ [Permissões do IAM](IAM_policies.md#IAM_policies.title) apropriadas para criar e gerenciar ambientes de computação
+ 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 de ID de imagem** na configuração do EC2
    + Especificando em um modelo de inicialização

    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 <<EOF > ./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
   ```

------