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á. # Alterações de configuração Quando você modifica as definições das opções de **configuração na seção Configuração** do [console de gerenciamento do ambiente](environments-console.md), a alteração é AWS Elastic Beanstalk propagada para todos os recursos afetados. Esses recursos incluem o balanceador de carga que distribui o tráfego para as EC2 instâncias da Amazon que executam seu aplicativo, o grupo Auto Scaling que gerencia essas instâncias e EC2 as próprias instâncias. Várias alterações de configuração podem ser aplicadas a um ambiente em execução sem substituir as instâncias existentes. Por exemplo, a configuração de um [URL de verificação de integridade](environments-cfg-clb.md#using-features.managing.elb.healthchecks) aciona uma atualização de ambiente para modificar as configurações do load balancer, mas não causa tempo de inatividade, porque as instâncias que executam seu aplicativo continuam atendendo às solicitações enquanto a atualização é propagada. As alterações de configuração que modificam a [configuração de execução](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) ou [configurações de VPC](command-options-general.md#command-options-general-ec2vpc) exigem o encerramento de todas as instâncias no ambiente e a substituição. Por exemplo, quando você altera o tipo de instância ou a configuração da chave SSH do seu ambiente, as EC2 instâncias devem ser encerradas e substituídas. O Elastic Beanstalk fornece várias políticas que determinam como essa substituição é feita. + **Atualizações contínuas**: o Elastic Beanstalk aplica as alterações de configuração em lotes, mantendo um número mínimo de instâncias em execução e distribuindo o tráfego o tempo todo. Essa abordagem evita o tempo de inatividade durante o processo de atualização. Para obter detalhes, consulte [Atualizações contínuas](using-features.rollingupdates.md). + **Atualizações imutáveis**: o Elastic Beanstalk inicia um grupo temporário de Auto Scaling fora do ambiente com um conjunto separado de instâncias em execução com a nova configuração. Depois, o Elastic Beanstalk coloca essas instâncias atrás do balanceador de carga do ambiente. As instâncias antigas e novas distribuem o tráfego até que as novas instâncias passem nas verificações de integridade. Naquele momento, o Elastic Beanstalk move as novas instâncias para o grupo de Auto Scaling do ambiente e encerra o grupo temporário e as instâncias antigas. Para obter detalhes, consulte [Atualizações imutáveis](environmentmgmt-updates-immutable.md). + **Desativado**: o Elastic Beanstalk não tenta evitar o tempo de inatividade. Ele encerra as instâncias existentes do ambiente e as substitui por novas instâncias em execução com a nova configuração. **Atenção** Algumas políticas substituem todas as instâncias durante a implantação ou a atualização. Isso faz com que todos os [saldos EC2 estourados acumulados da Amazon](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html) sejam perdidos. Isso acontece nos seguintes casos: Atualizações de plataforma gerenciada com substituição de instância habilitada Atualizações imutáveis Implantações com atualizações imutáveis ou divisão de tráfego habilitada **Tipos de atualização compatíveis** | Contínua da configuração de atualização | Ambientes de carga equilibrada | Ambientes de instância única | Ambientes legados do Windows Server† | | --- | --- | --- | --- | | Desabilitado | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | | Contínua com base na integridade | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | ![\[No\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-no.png) Não | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | | Contínua com base no tempo | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | ![\[No\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-no.png) Não | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | | Imutável | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | ![\[Yes\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-yes.png) Sim | ![\[No\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/icon-no.png) Não | † Para a finalidade dessa tabela, um *ambiente legado do Windows Server* é um ambiente com base em uma [configuração de plataforma do Windows Server](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) que usa uma versão anterior do IIS 8.5. **Topics** + [Atualizações de configuração de ambiente contínuas do Elastic Beanstalk](using-features.rollingupdates.md) + [Atualizações de ambiente imutáveis](environmentmgmt-updates-immutable.md) # Atualizações de configuração de ambiente contínuas do Elastic Beanstalk Quando uma [alteração de configuração exige a substituição de instâncias](environments-updating.md), o Elastic Beanstalk pode executar a atualização em lotes para evitar tempo de inatividade enquanto a modificação é propagada. Durante uma atualização contínua, a capacidade só é reduzida pelo tamanho de um único lote, o qual você pode configurar. O Elastic Beanstalk coloca um lote de instâncias fora de serviço e as encerra, para, depois, iniciar um lote com a nova configuração. Depois que o novo lote começar a atender a solicitações, o Elastic Beanstalk passa para o próximo lote. Os lotes de atualização contínua da configuração podem ser processados periodicamente (com base no tempo), com um atraso entre cada lote ou de acordo com a integridade. Para atualizações contínuas baseadas no tempo, você pode configurar a quantidade de tempo que o Elastic Beanstalk aguarda depois de concluir a inicialização de um lote de instâncias antes de passar para o próximo. Essa pausa permite que seu aplicativo faça o bootstrap e comece a atender às solicitações. De acordo com as atualizações contínuas baseadas na integridade, o Elastic Beanstalk aguarda até que as instâncias em um lote passem por verificações de integridade antes de mudar para o próximo lote. A integridade de uma instância é determinada pelo sistema de relatórios de integridade, o qual pode ser básico ou aprimorado. Com a [integridade básica](using-features.healthstatus.md), um lote é considerado íntegro assim que todas as suas instâncias passem nas verificações de integridade do Elastic Load Balancing (ELB). Com os [relatórios de integridade aprimorada](health-enhanced.md), todas as instâncias em um lote devem passar por várias verificações de integridade consecutivas antes que o Elastic Beanstalk vá para o próximo lote. Além das verificações de integridade do ELB, que verificam somente suas instâncias, a integridade aprimorada monitora os logs do aplicativo e o estado de outros recursos do ambiente. Em um ambiente de servidor web com integridade aprimorada, todas as instâncias devem passar por 12 verificações de integridade durante o período de dois minutos (18 verificações em três minutos para ambientes de operador). Se qualquer instância falhar em uma verificação de integridade, a contagem recomeça. Se um lote não se tornar íntegro dentro do tempo limite da atualização contínua (o padrão é 30 minutos), a atualização será cancelada. O timeout de atualização contínua é uma [opção de configuração](command-options.md) que está disponível no namespace `aws:autoscaling:updatepolicy:rollingupdate`. Caso a aplicação não passe nas verificações de integridade com o status `Ok`, mas esteja estável em outro nível, você pode definir a opção `HealthCheckSuccessThreshold` no namespace [`aws:elasticbeanstalk:healthreporting:system`](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) para alterar o nível no qual o Elastic Beanstalk considera uma instância como íntegra. Se o processo de atualização contínua falhar, o Elastic Beanstalk iniciará outra atualização contínua para retornar à configuração anterior. Uma atualização contínua pode falhar devido a verificações de integridade com falha ou caso a execução de novas instâncias fizer com que você exceda as cotas na sua conta. Se você atingir uma cota no número de EC2 instâncias da Amazon, por exemplo, a atualização contínua pode falhar ao tentar provisionar um lote de novas instâncias. Nesse caso, a reversão também falhará. Uma de reversão com falha encerra o processo de atualização e deixa o ambiente em um estado não íntegro. Os lotes não processados ainda estão executando instâncias com a configuração antiga, enquanto todos os lotes concluídos com êxito têm a nova configuração. Para corrigir um ambiente após uma reversão com falha, primeiro resolva o problema subjacente que causou a falha da atualização e, depois, inicie outra atualização do ambiente. Um método alternativo é implantar a nova versão do aplicativo em um ambiente diferente e, depois, executar uma troca do CNAME para redirecionar o tráfego sem qualquer inatividade. Consulte [Implantações azuis/verdes com o Elastic Beanstalk](using-features.CNAMESwap.md) para obter mais informações. ## Atualizações contínuas versus implantações contínuas As atualizações contínuas ocorrem quando você altera as configurações que exigem que novas EC2 instâncias da Amazon sejam provisionadas para o seu ambiente. Isso inclui alterações na configuração do grupo de Auto Scaling como as configurações do tipo de instância e do par de chaves, bem como alterações nas configurações da VPC. Em uma atualização contínua, cada lote de instâncias é encerrado antes que um novo lote seja provisionado para substituí-lo. As [implantações contínuas](using-features.rolling-version-deploy.md) ocorrem sempre que você implanta a aplicação e normalmente podem ser executadas sem a substituição de instâncias no ambiente. O Elastic Beanstalk coloca cada lote fora de serviço, implanta a nova versão da aplicação e, depois, coloca-o novamente em serviço. A exceção é se você alterar as configurações que exigem a substituição da instância enquanto implanta uma nova versão do aplicativo. Por exemplo, se você alterar as configurações de [nome da chave](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) em um [arquivo de configuração](ebextensions.md) em seu pacote de origem e o implantar em seu ambiente, vai acionar uma atualização contínua. Em vez de implantar a nova versão do aplicativo para cada lote de instâncias existentes, um novo lote de instâncias é provisionado com a nova configuração. Nesse caso, uma implantação separada não ocorre, pois as novas instâncias são ativadas com a nova versão do aplicativo. Sempre que novas instâncias são provisionadas como parte de uma atualização de ambiente, há uma fase de implantação em que o código-fonte do aplicativo é implantado nas novas instâncias, e qualquer definição da configuração que modifica o sistema operacional ou o software em instâncias é aplicada. As [Configurações de verificação de integridade da implantação](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console) (**Ignore health check** (Ignorar verificação de integridade), **Healthy threshold** (Limite da integridade) **Command timeout** (Tempo limite do comando)) também se aplicam a atualizações contínuas baseadas na integridade e a atualizações imutáveis durante a fase de implantação. ## Configurar atualizações contínuas É possível habilitar e configurar atualizações contínuas no console do Elastic Beanstalk. **Para habilitar atualizações contínuas** 1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS 1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista. 1. No painel de navegação, escolha **Configuration (Configuração)**. 1. Na categoria de configuração **Rolling updates and deployments (Atualizações e implantações contínuas)**, escolha **Edit (Editar)**. 1. Na seção **Configuration updates (Atualizações da configuração)**, para **Rolling update type (Tipo de atualização contínua)**, selecione uma das opções de **Rolling (Contínua)**. ![\[A seção de atualizações de configuração na página de modificação de atualizações e implantações contínuas\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/aeb-config-rolling-updates-health.png) 1. Selecione as configurações **Batch size (Tamanho do lote)**, **Minimum capacity (Capacidade mínima)**, e **Pause time (Tempo de pausa)**. 1. Para salvar as alterações, escolha **Apply (Aplicar)** na parte inferior da página. A seção **Configuration updates (Atualizações da configuração)** da página **Rolling updates and deployments (Atualizações contínuas e implantações)** tem as seguintes opções para atualizações contínuas: + **Rolling update type (Tipo de atualização contínua)**: o Elastic Beanstalk aguarda a conclusão da atualização de um lote de instâncias para passar para o próximo lote e permitir que essas instâncias concluam o bootstrapping e comecem a atender ao tráfego. Escolha uma das seguintes opções: + **Rolling based on Health (Contínua com base na integridade)**: aguarde até que as instâncias no lote atual se tornem íntegras antes de colocar instâncias em serviço e iniciar o próximo lote. + **Rolling based on Time (Contínua com base no tempo)**: especifique um tempo de espera entre o início de novas instâncias e sua colocação em serviço para iniciar o próximo lote. + **Immutable (Imutável)**: aplique a alteração de configuração a um novo grupo de instâncias executando uma [atualização imutável](environmentmgmt-updates-immutable.md). + **Batch size (Tamanho do lote)**: o número de instâncias a serem substituídas em cada lote, entre **1** e **10000**. Por padrão, esse valor é um terço do tamanho mínimo do grupo de Auto Scaling arredondado para um número inteiro. + **Minimum capacity (Capacidade mínima)**: o número mínimo de instâncias para manter em execução enquanto outras instâncias estão sendo atualizadas, entre **0** e **9999**. O valor padrão é o tamanho mínimo do grupo de Auto Scaling ou um a menos do que o tamanho máximo do grupo de Auto Scaling, qualquer que seja o número menor. + **Pause time (Tempo de pausa)** (somente baseado no tempo): a quantidade de tempo de espera após um lote ser atualizado antes de passar para o próximo lote para permitir que a aplicação comece a receber tráfego. Entre zero segundo e uma hora. ## O namespace aws:autoscaling:updatepolicy:rollingupdate Você também pode usar as [opções de configuração](command-options.md) no namespace `aws:autoscaling:updatepolicy:rollingupdate` para configurar as atualizações contínuas. Use a opção `RollingUpdateEnabled` para habilitar atualizações contínuas e `RollingUpdateType` para escolher o tipo de atualização. Os valores a seguir são compatíveis com `RollingUpdateType`: + `Health` – aguarde até que as instâncias no lote atual se tornem íntegras antes de colocá-las em serviço e iniciar o próximo lote. + `Time` – especifique um tempo de espera entre a inicialização das novas instâncias e sua colocação em serviço para iniciar o próximo lote. + `Immutable`: aplique a alteração de configuração a um novo grupo de instâncias executando uma [atualização imutável](environmentmgmt-updates-immutable.md). Quando você habilitar as atualizações constantes, defina as opções `MaxBatchSize` e `MinInstancesInService` para configurar o tamanho de cada lote. Para atualizações contínuas baseadas no tempo, também é possível configurar `PauseTime` e `Timeout`, respectivamente. Por exemplo, para iniciar até cinco instâncias por vez mantendo pelo menos duas instâncias em serviço e aguardar cinco minutos e 30 segundos entre cada lote, especifique as opções e os valores a seguir. **Example .ebextensions/timebased.config** ``` option_settings: aws:autoscaling:updatepolicy:rollingupdate: RollingUpdateEnabled: true MaxBatchSize: 5 MinInstancesInService: 2 RollingUpdateType: Time PauseTime: PT5M30S ``` Para habilitar atualizações contínuas baseadas na integridade, com um tempo limite de 45 minutos para cada lote, especifique as opções e os valores a seguir. **Example .ebextensions/healthbased.config** ``` option_settings: aws:autoscaling:updatepolicy:rollingupdate: RollingUpdateEnabled: true MaxBatchSize: 5 MinInstancesInService: 2 RollingUpdateType: Health Timeout: PT45M ``` `Timeout`e `PauseTime` os valores devem ser especificados em [ISO8601 duration](http://en.wikipedia.org/wiki/ISO_8601#Durations):`PT#H#M#S`, onde cada \$1 é o número de horas, minutos ou segundos, respectivamente. A CLI do EB e o console do Elastic Beanstalk aplicam os valores recomendados para as opções anteriores. Se quiser usar arquivos de configuração para definir a mesma coisa, você precisa remover essas configurações. Para mais detalhes, consulte [Valores recomendados](command-options.md#configuration-options-recommendedvalues). # Atualizações de ambiente imutáveis Atualizações de ambiente imutável são uma alternativa a [atualizações contínuas](using-features.rollingupdates.md). As atualizações de ambiente imutável garantem que as alterações de configuração que exigem a substituição de instâncias sejam aplicadas de forma eficiente e segura. Se uma atualização de ambiente imutável falhar, o processo de reversão precisará apenas do encerramento de um grupo de Auto Scaling. Uma atualização contínua com falha, por outro lado, requer a execução de uma atualização contínua adicional para reverter as alterações. Para executar uma atualização de ambiente imutável, o Elastic Beanstalk cria um segundo grupo temporário de Auto Scaling por trás do balanceador de carga do ambiente para conter as novas instâncias. Primeiro, o Elastic Beanstalk inicia uma única instância com a nova configuração no novo grupo. Essa instância serve o tráfego junto com todas as instâncias no grupo original de Auto Scaling que estão executando a configuração anterior. Depois que a primeira instância passa pelas verificações de integridade, o Elastic Beanstalk executa instâncias adicionais com a nova configuração que correspondem ao número de instâncias em execução no grupo original de Auto Scaling. Quando todas as novas instâncias passam por verificações de integridade, o Elastic Beanstalk as transfere para o grupo original de Auto Scaling e encerra o grupo temporário de Auto Scaling e as instâncias antigas. **nota** Durante a atualização de ambiente imutável, a capacidade do ambiente dobra por um curto período quando as instâncias no novo grupo de Auto Scaling começam a atender às solicitações e antes de as instâncias do grupo original de Auto Scaling serem encerradas. Se o ambiente tiver muitas instâncias ou você tiver uma [cota de instância sob demanda](https://aws.amazon.com/ec2/faqs/#How_many_instances_can_I_run_in_Amazon_EC2) baixa, verifique se há capacidade suficiente para executar uma atualização de ambiente imutável. Se você estiver perto da cota, considere o uso de atualizações contínuas. As atualizações imutáveis exigem um [relatório de integridade aprimorada](health-enhanced.md) para avaliar a integridade de seu ambiente durante a atualização. Relatórios de integridade aprimorados combinam verificações de integridade padrão do load balancer com monitoramento de instância. Desse modo, ele verifica se as instâncias com a nova configuração estão [atendendo às solicitações com êxito](health-enhanced.md#health-enhanced-factors). Você também pode usar as atualizações imutáveis para implantar novas versões do seu aplicativo, como uma alternativa para implantações contínuas. Quando você [configura o Elastic Beanstalk para usar as atualizações imutáveis para implantações de aplicações](using-features.rolling-version-deploy.md), ele substitui todas as instâncias no ambiente cada vez que uma nova versão da aplicação é implantada. Se uma implantação de aplicação imutável falhar, o Elastic Beanstalk reverterá as alterações imediatamente ao encerrar o novo grupo de Auto Scaling. Isso pode impedir as implantações de frota parcial, que podem ocorrer quando uma implantação contínua falha após alguns lotes terem sido concluídos. **Atenção** Algumas políticas substituem todas as instâncias durante a implantação ou a atualização. Isso faz com que todos os [saldos EC2 estourados acumulados da Amazon](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html) sejam perdidos. Isso acontece nos seguintes casos: Atualizações de plataforma gerenciada com substituição de instância habilitada Atualizações imutáveis Implantações com atualizações imutáveis ou divisão de tráfego habilitada Se uma atualização imutável falhar, as novas instâncias farão upload de [logs do pacote](using-features.logging.md) para o Amazon S3 antes que o Elastic Beanstalk as encerre. O Elastic Beanstalk deixa logs de uma atualização imutável com falha no Amazon S3 por uma hora antes de excluí-los, em vez de o padrão de 15 minutos para logs finais e em pacote. **nota** Se você usar as atualizações imutáveis para implantações de versão do aplicativo, mas não para a configuração, poderá encontrar um erro se tentar implantar uma versão do aplicativo com alterações de configuração que normalmente acionariam uma atualização contínua (por exemplo, configurações que alteram o tipo de instância). Para evitar isso, faça a alteração de configuração em uma atualização separada ou configure as atualizações imutáveis tanto para implantações quanto para alterações de configuração. Não é possível realizar uma atualização imutável em conjunto com as alterações de configuração de recurso. Por exemplo, não é possível alterar [as configurações que exigem substituição de instância](environments-updating.md) e, ao mesmo tempo, atualizar outras configurações ou realizar uma implantação imutável com arquivos de configuração que alteram as definições de configuração ou recursos adicionais em seu código-fonte. Se você tentar alterar as configurações de recurso (por exemplo, as configurações do balanceador de carga) e simultaneamente executar uma atualização imutável, o Elastic Beanstalk retornará um erro. Se as alterações de configuração de recurso não são dependente de alteração em seu código-fonte ou na configuração de instância, execute-as em duas atualizações. Se elas são dependentes, realize uma [implantação azul/verde](using-features.CNAMESwap.md). ## Configurar as atualizações imutáveis É possível habilitar e configurar atualizações imutáveis no console do Elastic Beanstalk. **Para habilitar as atualizações imutáveis (console)** 1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS 1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista. 1. No painel de navegação, escolha **Configuration (Configuração)**. 1. Na categoria de configuração **Rolling updates and deployments (Atualizações e implantações contínuas)**, escolha **Edit (Editar)**. 1. Na seção **Configuration Updates**, defina o **Rolling update type** para **Immutable**. ![\[A seção de atualizações de configuração na página de modificação de atualizações e implantações contínuas\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/environments-mgmt-updates-immutable.png) 1. Para salvar as alterações, escolha **Apply (Aplicar)** na parte inferior da página. ## O namespace aws:autoscaling:updatepolicy:rollingupdate Você também pode usar as opções de configuração no namespace `aws:autoscaling:updatepolicy:rollingupdate` para configurar as atualizações imutáveis. O exemplo de [arquivo de configuração](ebextensions.md) a seguir permite atualizações imutáveis para alterações de configuração. **Example .ebextensions/immutable-updates.config** ``` option_settings: aws:autoscaling:updatepolicy:rollingupdate: RollingUpdateType: Immutable ``` O exemplo a seguir permite atualizações imutáveis tanto para alterações de configuração quanto para implantações. **Example .ebextensions/immutable-all.config** ``` option_settings: aws:autoscaling:updatepolicy:rollingupdate: RollingUpdateType: Immutable aws:elasticbeanstalk:command: DeploymentPolicy: Immutable ``` A CLI do EB e o console do Elastic Beanstalk aplicam os valores recomendados para as opções anteriores. Se quiser usar arquivos de configuração para definir a mesma coisa, você precisa remover essas configurações. Para mais detalhes, consulte [Valores recomendados](command-options.md#configuration-options-recommendedvalues).