Como implantar atualizações automaticamente para instâncias em um MIG

Este documento descreve como aplicar automaticamente um novo modelo de instância a todas ou a um subconjunto aleatório das instâncias de máquina virtual (VM, na sigla em inglês) em um grupo gerenciado de instâncias (MIG).

Quando você configura uma atualização automatizada, o MIG lança uma nova versão de um modelo de instância automaticamente de acordo com suas especificações. É possível controlar a velocidade da implantação, o nível de interrupção do serviço e o número de instâncias que o MIG atualiza. Depois de iniciar a atualização, não é preciso fornecer mais entradas para que a atualização seja concluída por conta própria.

Se você quiser aplicar seletivamente um novo modelo somente a instâncias novas ou específicas em um MIG ou se tiver um MIG com estado e precisar aplicar estado por configurações de instância, consulte Como atualizar instâncias seletivamente em um MIG. Para ajudar você a decidir, consulte Como escolher entre atualizações automatizadas e seletivas.

Antes de começar

Limitações

  • Não será possível usar uma atualização gradual automatizada se seu MIG tiver alguma configuração com estado. Em vez disso, é possível controlar as atualizações e limitar a interrupção atualizando instâncias específicas.
  • Se você usa nomes de instâncias personalizados e não configura discos ou metadados com estado, é possível usar atualizações automatizadas. No entanto, para preservar nomes de instâncias, você precisa definir o método de substituição como RECREATE.

Início de uma atualização contínua básica

Uma atualização gradual básica é aplicada a todas as instâncias de um MIG até que todas as instâncias tenham sido atualizadas. Você pode controlar vários aspectos de uma atualização gradual, como quantas instâncias podem ficar off-line para a atualização, quanto tempo esperar entre atualizações de instâncias, se a atualização afeta todas as instâncias ou apenas uma parte delas e assim por diante.

Veja a seguir algumas considerações durante uma atualização gradual:

  • As atualizações são baseadas em intent. Quando você faz a solicitação de atualização inicial, a API Compute Engine retorna uma resposta bem-sucedida para confirmar que a solicitação é válida, mas isso não indica que a atualização foi bem-sucedida. Você precisa verificar o status do grupo para determinar se a atualização foi implantada.

  • A API Instance Group Updater é uma API declarativa. Ela espera que uma solicitação especifique a configuração pós-atualização pretendida do grupo de instâncias gerenciadas, em vez de uma chamada de função explícita.

  • As atualizações automáticas são compatíveis com até duas versões de modelo de instância no MIG. Isso significa que é possível especificar duas versões de modelo de instância diferentes para o grupo, o que é útil para executar atualizações canário.

Para iniciar uma atualização gradual básica com aplicação em 100% das instâncias no grupo, siga as instruções abaixo.

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acesse grupo de instâncias

  2. Selecione o MIG que você quer atualizar.

  3. Na parte superior da página, clique em Atualização gradual.

  4. Em Modelo, clique na lista suspensa e selecione o novo modelo para atualizar.

  5. Para o tamanho de destino, insira 100% para atualizar todas as instâncias.

  6. Em Modo de atualização, selecione proativo.

  7. Clique em Atualizar para iniciar a atualização.

gcloud

Use o comando rolling-action start-update.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=INSTANCE_TEMPLATE_NAME
    [--zone=ZONE | --region=REGION]

Substitua:

  • INSTANCE_GROUP_NAME: o nome do MIG.
  • INSTANCE_TEMPLATE_NAME: o novo modelo de instância
  • ZONE: para MIGs zonais, forneça a zona.
  • REGION: para MIGs regionais, forneça a região

API

Chame o método patch em um recurso MIG regional ou zonal.

Por exemplo, no caso de um MIG regional, a solicitação a seguir mostra a configuração mínima necessária para atualizar automaticamente 100% de instâncias para o novo modelo de instância.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

Depois de fazer uma solicitação, você pode monitorar a atualização para saber quando ela foi concluída.

Para configurações avançadas, inclua outras opções de atualização. Se você não especificar o contrário, as opções maxSurge e maxUnavailable usarão o padrão 1 multiplicado pelo número de zonas afetadas. Isso significa que apenas uma instância é colocada off-line em cada zona afetada e o MIG cria apenas uma instância adicional por zona durante a atualização.

Como configurar opções para a atualização

No caso de atualizações mais complexas, configure outras opções. Essas opções são descritas nas seções a seguir.

Modo

Para atualizações graduais automatizadas, você precisa definir o modo como proativo.

Como alternativa, se uma atualização automatizada é potencialmente muito disruptiva, é possível executar uma atualização oportunista. O MIG aplica uma atualização oportunista apenas quando você a inicia manualmente nas instâncias selecionadas ou quando novas instâncias são criadas. Novas instâncias podem ser criadas quando você ou outro serviço, como um autoescalador, redimensiona o MIG. O Compute Engine não inicia as solicitações ativamente para aplicar as atualizações.

Para mais informações sobre atualizações automáticas e seletivas, consulte Como escolher entre atualizações automatizadas e seletivas.

Sobrecarga máxima

Use a opção maxSurge para configurar quantas instâncias novas o MIG pode criar acima do targetSize durante uma atualização automatizada. Por exemplo, se você definir maxSurge como 5, o MIG usará o novo modelo de instância para criar até cinco novas instâncias acima do tamanho de destino. Se um valor maior de maxSurge for definido, a atualização será acelerada ao custo de mais instâncias, que serão cobradas de acordo com a tabela de preços do Compute Engine.

Especifique um número fixo ou, se o grupo tiver dez ou mais instâncias, uma porcentagem. Se você definir uma porcentagem, o Updater arredondará o número de instâncias para cima, se necessário.

Se você não definir o valor de maxSurge, o padrão será usado. Para MIGs zonais, o padrão para maxSurge é 1. Para MIGs regionais, o padrão é o número de zonas associadas ao grupo, por padrão 3.

maxSurge apenas funcionará se você tiver cota ou recursos suficientes para atender aos recursos extras.

Essa opção é reconhecida somente quando configurada com a ação mínima REPLACE. Porém, não é compatível com a configuração da ação RESTART.

Máximo indisponível

Use a opção maxUnavailable para configurar quantas instâncias não estão disponíveis a qualquer momento durante uma atualização automatizada. Por exemplo, se você definir maxUnavailable como 5, apenas cinco instâncias de cada vez serão colocadas off-line para atualização. Utilize essa opção para controlar o nível de interrupção da atualização para o serviço e a velocidade da implantação da atualização.

Esse número também inclui todas as instâncias que não estão disponíveis por outros motivos. Por exemplo, se o grupo estiver em processo de redimensionamento, as instâncias que ainda estiverem no meio da etapa de criação talvez não estejam disponíveis. Essas instâncias contam para o número maxUnavailable.

Especifique um número fixo ou, se o grupo tiver 10 ou mais instâncias, uma porcentagem. Se você definir uma porcentagem, o Updater arredondará o número de instâncias para baixo, se necessário.

Se você não definir o valor de maxUnavailable, o padrão será usado. Para MIGs zonais, o padrão é 1. Para MIGs regionais, o padrão é o número de zonas associadas ao grupo, por padrão 3.

Tempo de espera mínimo

Use a opção minReadySec para especificar quanto tempo aguardar antes de considerar uma instância nova ou reiniciada como atualizada. Use essa opção para controlar a taxa em que a atualização automatizada é implantada. O timer é iniciado quando ocorrem as duas condições a seguir:

Para que a verificação de integridade retorne o status "integra", o Updater aguarda as seguintes condições:

  1. aguarda até o período especificado pelo valor de autohealingPolicies.initialDelaySec do MIG para que a verificação de integridade retorne como HEALTHY;
  2. aguarda, na sequência, o período especificado por minReadySec.

Se a verificação de integridade não retornar HEALTHY no initialDelaySec, o Updater declarará a instância de VM como não íntegra e possivelmente interromperá a atualização. Enquanto a instância de VM aguarda a confirmação durante os períodos initialDelaySec e minReadySec, a currentAction da instância é VERIFYING. No entanto, o status da instância de VM subjacente permanece como RUNNING.

Se não houver verificações de integridade para o grupo, o timer será iniciado quando o status da instância for RUNNING.

O valor máximo do campo minReadySec é de 3.600 segundos (1 hora).

Ação mínima

Use a opção de ação mínima para especificar a ação mínima que uma atualização automatizada precisa executar para atualizar as instâncias no grupo. Por exemplo, se você definir REPLACE como a ação mínima, todas as instâncias afetadas serão excluídas e substituídas por novas, seja isso necessário ou não.

Definir uma ação mínima garante que o Updater realize-a, no mínimo. No entanto, se o Updater determinar que a ação mínima especificada não é suficiente para realizar a atualização, ele poderá executar uma ação mais disruptiva. Por exemplo, se você definir RESTART como a ação mínima, o Updater tentará reiniciar as instâncias para aplicar a atualização. No entanto, se você estiver alterando o SO, o que não pode ser feito reiniciando a instância, o Updater substituirá as instâncias no grupo por novas instâncias de VM.

As possíveis ações são REPLACE ou RESTART:

  • RESTART Reinicia a instância realizando uma solicitação stop e start. Se sua solicitação de atualização exigir que a instância seja substituída para capturar as alterações, por exemplo, a alteração da imagem exige que a instância seja excluída e substituída, então o Updater executará uma REPLACE.

  • REPLACE. Exclui a instância atual e cria uma nova com base no modelo de destino. O Updater cria uma instância com todas as novas propriedades dela, como novos endereços IP internos e externos.

No diagrama a seguir, você verá como essas opções afetam as instâncias.

Como as opções de política de atualização afetam sua solicitação.

Método de substituição

Por padrão, quando você atualiza um MIG proativamente, o grupo exclui as instâncias de VM e as troca por novas com novos nomes. Se você precisar preservar os nomes das instâncias de VM, use a opção replacementMethod.

Preservar nomes de instâncias existentes pode ser útil se você tiver aplicativos ou sistemas que dependem do uso de nomes de instância específicos. Por exemplo, alguns aplicativos, como o Memcached, dependem de nomes de instância porque não têm um serviço de descoberta; como resultado, sempre que um nome de instância é alterado, o aplicativo perde a conexão com essa VM específica.

Para preservar nomes de instâncias, defina o método de substituição como RECREATE em vez de SUBSTITUTE.

Métodos de substituição de instâncias gerenciadas.

Os valores replacementMethod válidos são:

  • SUBSTITUTE (padrão). Substitui as instâncias de VM mais rapidamente durante as atualizações porque novas VMs são criadas antes que as antigas sejam encerradas. No entanto, os nomes das instâncias não são preservados porque os nomes ainda estão sendo usados pelas instâncias antigas.

  • RECREATE. Preserva os nomes de instâncias por meio de uma atualização. O Compute Engine libera o nome da instância quando a VM antiga é encerrada. Em seguida, o Compute Engine cria uma nova instância usando esse mesmo nome. Para usar este modo, defina maxSurge para 0.

Para mais informações, consulte como preservar nomes de instâncias.

Outros exemplos de atualização

Veja a seguir alguns exemplos de linha de comando com opções de configuração comuns.

Executar uma atualização gradual de todas as instâncias de VM, mas criar até cinco novas instâncias de cada vez acima do tamanho de destino

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=5 \
    [--zone=ZONE | --region=REGION]

Executar uma atualização gradual com no máximo três máquinas indisponíveis e um tempo de espera mínimo de três minutos antes de marcar uma nova instância como disponível

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --min-ready=3m \
    --max-unavailable=3 \
    [--zone=ZONE | --region=REGION]

Executar uma atualização gradual de todas as instâncias de VM, mas criar até 10% de novas instâncias de cada vez acima do tamanho de destino

Por exemplo, se você tiver 1.000 instâncias e executar o comando a seguir, o Updater criará até 100 instâncias antes de começar a remover aquelas que executam o modelo anterior.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=10% \
    [--zone=ZONE | --region=REGION]

Atualizações Canary

Uma atualização canário é aplicada a um subconjunto de instâncias no grupo. Com uma atualização canário, é possível testar novos recursos ou upgrades em um subconjunto aleatório de instâncias, em vez de implantar uma atualização potencialmente disruptiva em todas as instâncias. Se uma atualização não está indo bem, você só precisa reverter o subconjunto de instâncias, minimizando a interrupção para os usuários.

Uma atualização canário é igual a uma atualização gradual padrão, exceto pelo número de instâncias que precisam ser atualizadas que é menor que o tamanho total do grupo. Assim como uma atualização gradual padrão, é possível configurar outras opções (em inglês) para controlar o nível de interrupção no serviço.

Como iniciar uma atualização canário

Para iniciar uma atualização canário, especifique até duas versões do modelo de instância, normalmente um novo modelo para canário e outro atual para o restante. Por exemplo, é possível especificar que 20% das instâncias sejam criadas com base em NEW_INSTANCE_TEMPLATE, enquanto o restante das instâncias continuará em execução no OLD_INSTANCE_TEMPLATE. Não é possível especificar mais de dois modelos de instância por vez.

Sempre especifique um tamanho de destino (targetSize) para a versão canary. Não será possível iniciar uma atualização canário se você omitir o tamanho de destino da versão canário. Por exemplo, se você especificou que 10% das instâncias devem ser usadas para atualização canário, os 90% restantes não são alterados e usam o modelo de instância atual.

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acesse grupo de instâncias

  2. Selecione o grupo de instâncias gerenciadas que você quer atualizar.
  3. Na parte superior da página, clique em Atualização gradual.
  4. Clique em Adicionar modelo e escolha o novo modelo de instância para o teste canário.
  5. Em Tamanho do destino, insira a porcentagem ou o número fixo de instâncias que você quer usar para fazer o teste canário do novo modelo de instância.
  6. Se você quiser, poderá configurar outras opções de atualização.
  7. Clique em Atualizar para iniciar a atualização.

gcloud

Use o comando rolling-action start-update. Forneça o modelo atual e o novo para expressar explicitamente quantas instâncias devem usar cada modelo:

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=CURRENT_INSTANCE_TEMPLATE_NAME \
    --canary-version=template=NEW_TEMPLATE,target-size=SIZE \
    [--zone=ZONE | --region=REGION]

Substitua:

  • INSTANCE_GROUP_NAME: o nome do grupo de instâncias.
  • CURRENT_INSTANCE_TEMPLATE_NAME: o modelo de instância que o grupo de instâncias está executando.
  • NEW_TEMPLATE: o novo modelo em que você quer fazer a atualização canário;
  • SIZE: o número ou a porcentagem de instâncias às quais você quer aplicar esta atualização. Aplique a propriedade target-size ao modelo --canary-version. Somente será possível definir uma porcentagem se o grupo tiver dez ou mais instâncias.
  • ZONE: para MIGs zonais, forneça a zona.
  • REGION: para MIGs regionais, forneça a região.

Por exemplo, o comando a seguir executa uma atualização canário que implanta example-template-B em 10% das instâncias no grupo:

gcloud compute instance-groups managed rolling-action start-update example-mig \
    --version=emplate=example-template-A \
    --canary-version=template=example-template-B,target-size=10%

API

Chame o método patch em um recurso MIG regional ou zonal. No corpo da solicitação, inclua os modelos de instância atual e novo que você quer fazer a atualização canary. Exemplo:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
   "targetSize": {
    "[percent|fixed]": NUMBER|PERCENTAGE # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME"
  }
 ]
}

Substitua:

  • NEW_TEMPLATE: o nome do novo modelo em que você quer fazer a atualização canário.
  • NUMBER|PERCENTAGE: o número fixo ou a porcentagem de instâncias para fazer essa atualização canário. Somente será possível definir uma porcentagem se o grupo tiver dez ou mais instâncias. Caso contrário, forneça um número fixo.
  • CURRENT_INSTANCE_TEMPLATE_NAME: o nome do modelo de instância atual que o grupo está executando.

Depois de fazer uma solicitação, você pode monitorar a atualização para saber quando ela foi concluída.

Como avançar uma atualização canário

Depois de executar uma atualização canário, decida se quer confirmar a atualização como 100% do MIG ou revertê-la.

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acesse grupo de instâncias

  2. Selecione o grupo de instâncias gerenciadas que você quer atualizar.
  3. Na parte superior da página, clique em Atualização gradual.
  4. Em Modelo, atualize o tamanho de destino do modelo canário como 100% para implementar o modelo em todas as instâncias. Se preferir, substitua o modelo principal pelo canário e defina o tamanho de destino como 100%. Em seguida, remova completamente o segundo campo de modelo.
  5. Clique em Atualizar para iniciar a atualização.

gcloud

Se você quer confirmar a atualização canário, avance-a emitindo outrocomandorolling-action start-update mas defina somente a sinalização version e omitir a sinalização --canary-version.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    [--zone=ZONE | --region=REGION]

API

Chame o método patch em um recurso MIG regional ou zonal. No corpo da solicitação, especifique o novo modelo de instância como version e omita o modelo anterior. Omita a especificação do tamanho de destino para implantar a atualização em 100% das instâncias. Exemplo:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE" # New instance template
   }
 ]
}

Como monitorar as atualizações

Uma atualização pode levar algum tempo para ser concluída para todas as instâncias afetadas após o início de uma atualização. É possível monitorar o progresso de uma atualização inspecionando o status do grupo ou verificando as ações atuais nas instâncias.

Status do grupo

No nível do grupo, o Compute Engine preenche um campo somente leitura denominado status, que contém uma sinalização versionTarget.isReached e uma sinalização isStable. Use a ferramenta gcloud ou a API do Compute Engine para acessar essas sinalizações. Também é possível usar o Console do Cloud para ver o número atual e planejado das instâncias que estão sendo atualizadas.

Console

Para monitorar a atualização gradual de um grupo, acesse a página de detalhes do grupo.

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acesse grupo de instâncias

  2. Selecione o grupo de instâncias gerenciadas que você quer monitorar. Na página de visão geral do grupo, aparece o modelo que cada instância usa.
  3. Para ver os detalhes, clique na guia Detalhes.
  4. Em Modelo de instância, é possível ver o número atual e de destino de instâncias para cada modelo, bem como os parâmetros de atualização.

gcloud

Use o comando describe.

gcloud compute instance-groups managed describe INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

É possível também usar o comando gcloud compute instance-groups managed wait-until (em inglês) com a sinalização --version-target-reached para aguardar que status.versionTarget.isReached seja definido como true no grupo:

gcloud compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --version-target-reached \
    [--zone=ZONE | --region=REGION]

API

Chame o método get em um recurso MIG regional ou zonal.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

Como verificar se um lançamento de atualização foi concluído

Verifique se o lançamento de uma atualização está completo verificando o valor do campo status.versionTarget.isReached do MIG:

status.versionTarget.isReached definido como true indica que todas as instâncias de VM foram ou estão sendo criadas usando a versão de destino.

status.versionTarget.isReached definido como false indica que pelo menos uma VM ainda não está usando a versão de destino. Ou, no caso de uma atualização canário, false indica que o número de VMs que usam uma versão de destino não corresponde ao tamanho de destino.

Como verificar se o grupo de instâncias gerenciadas é estável

Verifique se todas as instâncias em um grupo de instâncias gerenciadas estão em execução e íntegras verificando o valor do campo status.isStable do grupo.

status.isStable definido como false indica que as alterações estão ativas, pendentes ou que o próprio MIG está sendo modificado.

status.isStable definido como true indica o seguinte:

  • Nenhuma das instâncias no MIG está passando por qualquer tipo de alteração, e o currentAction de todas as instâncias é NONE.
  • Nenhuma alteração pendente para instâncias no MIG.
  • O MIG não está sendo modificado.

A estabilidade de um MIG depende de vários fatores porque ele pode ser modificado de várias maneiras. Exemplo:

  • Você faz uma solicitação para lançar um novo modelo de instância.
  • Você faz uma solicitação para criar, excluir, redimensionar ou atualizar instâncias no MIG.
  • Um escalonador automático solicita o redimensionamento do MIG.
  • Um recurso de recuperação automática está substituindo uma ou mais instâncias não íntegras do MIG.
  • Em um MIG regional, algumas das instâncias estão sendo redistribuídas.

Assim que todas as ações forem concluídas, status.isStable será definido como true novamente para esse MIG.

Ações atuais nas instâncias

É possível ver a currentAction sendo realizada e os status de cada instância em um grupo de instâncias gerenciadas usando a ferramenta de linha de comando gcloud ou a API Compute Engine.

gcloud

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

O comando retorna uma lista de instâncias no MIG e os status e ações atuais delas. Exemplo:

NAME               ZONE           STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f                          CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING                DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING                 NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING                 NONE      my-old-template

A coluna HEALTH_STATE aparece vazia, a menos que você tenha configurado a verificação de integridade.

API

Chame o método listManagedInstances em um recurso MIG regional ou zonal. Exemplo:

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

A chamada retorna uma lista de instâncias para o MIG, incluindo instanceStatus e currentAction de cada instância.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  }
 ]
}

Para ver uma lista de valores válidos do campo instanceStatus, consulte Como verificar o status de uma instância.

Se uma instância estiver passando por algum tipo de alteração, o campo currentAction será preenchido com uma das seguintes ações para ajudar você a acompanhar o andamento da alteração. Caso contrário, o campo currentAction será NONE.

Os valores possíveis de currentAction são:

  • ABANDONING. A instância está sendo removida do MIG.
  • CREATING: a instância está em processo de criação;
  • CREATING_WITHOUT_RETRIES. A instância está sendo criada sem novas tentativas. Se a instância não for criada na primeira tentativa, o MIG não tentará substituí-la novamente.
  • DELETING: a instância está em processo de exclusão;
  • RECREATING: a instância está sendo substituída;
  • REFRESHING: a instância está sendo removida e adicionada novamente à lista de pools de destino atuais (essa lista pode corresponder ou não aos pools de destino atuais);
  • RESTARTING: a instância está em processo de reinicialização por meio dos métodos stop e start;
  • VERIFYING: a instância foi criada e está em processo de verificação;
  • NONE: nenhuma ação está sendo executada na instância.

Como reverter uma atualização

Não há comando explícito para reverter uma atualização para uma versão anterior, mas se você decidir reverter uma atualização (uma atualização totalmente consolidada ou Canary), poderá fazer uma nova solicitação de atualização e passar o modelo de instância para o que você quer reverter.

gcloud

Por exemplo, o seguinte comando da ferramenta gcloud reverte uma atualização o mais rápido possível. Substitua OLD_INSTANCE_TEMPLATE pelo nome do modelo de instância ao qual você quer reverter.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=OLD_INSTANCE_TEMPLATE_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

API

Chame o método patch em um recurso MIG regional ou zonal.

No corpo da solicitação, especifique o modelo de instância anterior como uma version:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
  "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/OLD_INSTANCE_TEMPLATE_NAME" # Old instance template
    }
  ]
}

Para um MIG regional com menos de 10 instâncias, use um valor fixo de maxUnavailable e defina o valor como o número de instâncias no grupo.

O Updater trata uma solicitação de reversão da mesma maneira que uma solicitação de atualização regular, para que você possa especificar outras opções de atualização.

Como parar uma atualização

Não há nenhum método ou comando explícito para interromper uma atualização. Altere uma atualização de proativa para oportunista e, se o grupo de não estiver sendo redimensionado por outros serviços, como o autoescalador, a alteração para oportunista interromperá a atualização de maneira efetiva.

Para alterar uma atualização de proativa para oportunista usando a ferramenta gcloud, execute o seguinte comando:

gcloud compute instance-groups managed rolling-action stop-proactive-update INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

Para interromper a atualização completamente após convertê-la de proativa em oportunista, faça isso seguindo as etapas abaixo:

  1. Faça uma solicitação para determinar quantas instâncias foram atualizadas:

    gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
        [--zone=ZONE | --region=REGION]

    A ferramenta gcloud retorna uma resposta que inclui uma lista de instâncias no grupo e os status atuais delas:

    NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
    vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      example-new-template
    vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      example-old-template
    vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  example-new-template
    

    Neste exemplo, duas instâncias já foram atualizadas.

  2. Em seguida, faça uma solicitação para executar uma nova atualização, mas transmita o número de instâncias que já foram atualizadas como o tamanho de destino:

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
        --version template=OLD_INSTANCE_TEMPLATE_NAME \
        --canary-version template=NEW_INSTANCE_TEMPLATE_NAME,target-size=2 \
        [--zone=ZONE | --region=REGION]

    Para o Updater, esta atualização parece completa, por isso nenhuma outra instância é atualizada, interrompendo efetivamente a atualização.

Como controlar a velocidade de uma atualização gradual

Por padrão, quando você faz uma solicitação de atualização, o Updater realiza a atualização o mais rápido possível. Caso não tenha certeza se quer aplicar uma atualização integralmente ou se estiver apenas testando as alterações, controle a velocidade da atualização usando os métodos a seguir.

  1. Inicie uma atualização canário em vez de uma atualização completa.
  2. Defina um valor minReadySec alto. Isso faz com que o Updater aguarde esse número de segundos antes de considerar a atualização da instância concluída e avançar para a próxima.
  3. Ative a verificação de integridade para fazer com que o Updater aguarde a inicialização do aplicativo e informe um sinal de integridade antes de considerar a atualização da instância concluída e avançar para a próxima.
  4. Defina valores maxUnavailable e maxSurge baixos. Isso garante que somente um número mínimo de instâncias seja atualizado de cada vez.
  5. Atualização seletiva de instâncias em um MIG em vez de usar uma atualização automatizada.

Também é possível usar uma combinação desses métodos para controlar a taxa de atualização.

Como realizar uma substituição ou reinicialização gradual

A reinicialização executa os métodos stop e start (ambos em inglês) nas instâncias, enquanto uma substituição exclui e cria instâncias ativamente.

Uma reinicialização ou substituição gradual não altera mais nada no grupo, incluindo o modelo da instância. Ela só atualiza as instâncias no grupo usando o método escolhido.

Há vários motivos para realizar uma reinicialização gradual ou uma substituição gradual. Por exemplo, pode ser necessário atualizar suas instâncias de VM de vez em quando por um dos seguintes motivos:

  • limpar vazamentos de memória;
  • reiniciar seu aplicativo para que ele possa ser executado a partir de uma máquina renovada;
  • aplicar uma substituição periódica como prática recomendada para testar as VMs;
  • atualizar a imagem do sistema operacional da VM ou executar novamente os scripts de inicialização para atualizar o software.

Use o Console do Cloud, a ferramenta de linha de comando gcloud ou a API do Compute Engine para executar uma reinicialização ou substituição.

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acesse grupo de instâncias

  2. Selecione o grupo de instâncias gerenciadas que você quer atualizar.
  3. Na parte superior da página, clique em Reinicialização/substituição gradual.
  4. Escolha se instâncias serão reiniciadas ou substituídas.
  5. Se preferir, alterne as opções de configuração, como surto máximo, máximo de opções indisponíveis e tempo de espera mínimo.
  6. Clique no botão Reiniciar ou Substituir para iniciar a atualização.

gcloud

Use o comando restart ou comando replace.

O seguinte comando substitui todas as instâncias no MIG, uma por vez:

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

O comando a seguir reinicia cada instância, uma de cada vez:

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

É possível personalizar ainda mais cada um desses comandos com as mesmas opções disponíveis para as atualizações. Por exemplo, maxSurge e maxUnavailable.

API

Chame o método patch em um recurso MIG regional ou zonal.

No campo updatePolicy.minimalAction, especifique RESTART ou REPLACE. Em ambos os casos, também é necessário fornecer as propriedades versions.instanceTemplate e versions.name para acionar a ação.

Por exemplo, para um MIG zonal, a solicitação a seguir mostra a configuração mínima necessária para reiniciar automaticamente todas as instâncias.

PATCH https://compute.googleapis.com/compute/v1/projects/example-project/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME",
   "name": "v2"
  }
 ]
}

Outros exemplos de substituição e reinicialização

Executar uma reinicialização gradual de todas as VMs, duas de cada vez

No comando a seguir, todas as VMs no grupo são reiniciadas, duas por vez. Observe que nenhum modelo de instância novo é especificado.

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=2 \
    [--zone=ZONE | --region=REGION]

Realizar uma reinicialização gradual de todas as VMs o mais rápido possível

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Executar uma substituição gradual de todas as VMs o mais rápido possível

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME  \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Como preservar nomes de instância

Se for necessário manter os nomes das instâncias de VM em uma atualização, defina replacementMethod para RECREATE. Você também precisa definir maxUnavailable para ser maior que 0 e maxSurge como 0. Recriar instâncias em vez de substituí-las faz com que a atualização leve mais tempo para ser concluída, mas as instâncias atualizadas mantêm seus nomes.

Se você não especificar um método de substituição, o valor updatePolicy.replacementMethod atual do MIG será usado. Se ele não estiver definido, o valor padrão (substitute) será usado, substituindo as instâncias de VM por novas instâncias com nomes gerados aleatoriamente.

gcloud

Ao emitir um comando rolling-action, inclua a sinalização --replacement-method=recreate.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --replacement-method=recreate \
    --version=template=NEW_TEMPLATE \
    --max-unavailable=5 \
    [--zone=ZONE | --region=REGION]

API

Chame o método patch em um recurso MIG regional ou zonal. No corpo da solicitação, inclua o campo updatePolicy.replacementMethod.

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

Depois de fazer uma solicitação, você pode monitorar a atualização para saber quando ela foi concluída.

Como atualizar um grupo regional de instâncias gerenciadas

Um MIG regional contém instâncias de VM espalhadas por várias zonas em uma região, em oposição a um MIG zonal, que contém apenas instâncias em uma zona. Os MIGs regionais permitem distribuir as instâncias por mais de uma zona para melhorar a disponibilidade do aplicativo e oferecer suporte a casos extremos em que uma zona falha ou um grupo inteiro de instâncias para de responder.

Executar uma atualização em um MIG regional é igual a uma atualização em um MIG zonal, com algumas exceções descritas abaixo. Quando você inicia uma atualização em um MIG regional, o Updater sempre atualiza as instâncias de modo proporcional e uniforme em cada zona. Não é possível escolher as instâncias em que as zonas são atualizadas primeiro nem atualizar as instâncias em apenas uma zona.

Diferenças entre a atualização de MIGs regionais e zonais

MIGs regionais têm os seguintes valores de atualização padrão:

  • maxUnavailable=NUMBER_OF_ZONES
  • maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES é o número de zonas associadas ao MIG regional. Por padrão, o número de zonas de um MIG regional é 3. Mas é possível selecionar um número diferente.

Se você usa números fixos ao especificar uma atualização, eles precisam ser 0 ou iguais ou maiores que o número de zonas associadas ao MIG regional. Por exemplo, se o grupo for distribuído em três zonas, não é possível definir maxSurge como 1 ou como 2, porque o Updater precisa criar uma instância extra em cada uma delas das três zonas.

Como usar um número fixo ou uma porcentagem nas solicitações de atualização

Se você especifica um número fixo em suas solicitações de atualização, esse número é dividido pelo número de zonas no MIG regional e distribuído uniformemente. Por exemplo, se você especificar maxSurge=10, o Updater dividirá dez pelo número de zonas na região e criará as instâncias com base nesse número. Se o número de instâncias não for dividido uniformemente entre as zonas, o Updater adicionará as instâncias restantes a uma zona aleatória. Portanto, para dez instâncias em três zonas, duas zonas recebem três instâncias e uma recebe quatro instâncias. A mesma lógica é aplicada aos parâmetros maxUnavailable e targetSize para atualizações canary.

Só será possível especificar uma porcentagem se o MIG contiver 10 ou mais instâncias de VM. As porcentagens são processadas de maneira um pouco diferente dependendo da situação:

  • Se você especificar uma porcentagem de instâncias de VM em uma atualização canário, o Updater tentará distribuí-las uniformemente entre as zonas. O restante será arredondado para cima ou para baixo em cada zona, mas a diferença total não será mais do que uma instância de VM por grupo. Por exemplo, para um MIG com 10 instâncias e uma porcentagem de tamanho de destino de 25%, a atualização é implementada em duas a três instâncias de VM.

  • Se você especificar uma porcentagem para as opções de atualização, como maxSurge e maxUnavailable, as porcentagens serão arredondadas de forma independente por zona.

A seguir