Aplicar automaticamente atualizações de configuração de VM em um MIG

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Este documento descreve como aplicar automaticamente atualizações de configuração às instâncias de máquina virtual (VM) em um grupo de instâncias gerenciadas (MIG) .

O Compute Engine mantém as VMs em um MIG com base nos componentes de configuração que você usa: modelo de instância, configuração opcional de todas as instâncias e configuração opcional com estado.

Sempre que você atualiza a configuração da VM de um MIG alterando esses componentes, o Compute Engine aplica automaticamente a configuração atualizada às novas VMs adicionadas ao grupo.

Para aplicar uma configuração atualizada às VMs existentes, você pode configurar uma atualização automática, também conhecida como tipo de atualização proativa . O MIG distribui automaticamente atualizações de configuração para todas ou para um subconjunto das VMs do grupo. Você pode controlar a velocidade de implantação, o nível de interrupção do serviço e, usando uma atualização canário, o número de instâncias que o MIG atualiza com a nova configuração. Depois de especificar a nova configuração, não será necessário fornecer informações adicionais e a atualização será concluída sozinha.

Como alternativa, se você quiser aplicar seletivamente uma nova configuração apenas a instâncias novas ou específicas em um MIG, consulte Aplicar seletivamente atualizações de configuração de VM em um MIG . Para ajudá-lo a decidir, consulte Métodos para aplicar uma nova configuração a VMs existentes .

Antes de começar

• Se você estiver atualizando um MIG com estado, revise Aplicar, visualizar e remover configurações com estado em MIGs .
• Se ainda não o fez, configure a autenticação. Autenticação é o processo pelo qual sua identidade é verificada para acesso a Google Cloud serviços e APIs. Para executar códigos ou amostras em um ambiente de desenvolvimento local, você pode se autenticar no Compute Engine selecionando uma das seguintes opções:
  

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. After installing the Google Cloud CLI, initialize it by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  2. Set a default region and zone.

  REST

  Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

  After installing the Google Cloud CLI, initialize it by running the following command:

  gcloud init

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud.

Limitações

• Se você tiver um MIG com estado e quiser usar atualizações contínuas automatizadas, deverá manter os nomes das instâncias ao substituir as instâncias ou, de forma equivalente, definir o método de substituição como RECREATE .

Iniciando uma atualização contínua básica

Uma atualização contínua básica é uma atualização aplicada gradualmente a todas as instâncias em um MIG até que todas as instâncias tenham sido atualizadas para a configuração pretendida mais recente. A atualização contínua ignora automaticamente as instâncias que já estão na configuração mais recente.

Você pode controlar vários aspectos de uma atualização contínua, como quantas instâncias podem ser colocadas off-line para a atualização, quanto tempo esperar entre a atualização das instâncias, se o novo modelo afeta todas ou apenas uma parte das instâncias e assim por diante.

Aqui estão algumas coisas que você deve ter em mente ao fazer uma atualização contínua:

• As atualizações são baseadas em intenções. 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ê deve verificar o status do grupo para determinar se a atualização foi implantada com êxito.

• A API Instance Group Updater é uma API declarativa. A API espera uma solicitação para especificar a configuração pós-atualização desejada do MIG, em vez de uma chamada de função explícita.

• As atualizações automatizadas suportam até duas versões de modelo de instância no seu MIG. Isso significa que você pode especificar duas versões diferentes do modelo de instância para o seu grupo, o que é útil para realizar atualizações canário .

Para iniciar uma atualização contínua básica em que a atualização é aplicada a todas as instâncias do grupo, siga as instruções abaixo.

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

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ê poderá monitorar a atualização para saber quando ela for 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 serão padronizadas como 1 multiplicado pelo número de zonas afetadas. Isso significa que apenas 1 instância é colocada offline em cada zona afetada e o MIG cria apenas 1 instância adicional por zona, durante a atualização.

Configurando opções para sua atualização

Para atualizações mais complexas você pode configurar opções adicionais, conforme descrito nas seções a seguir.

Tipo de atualização

Os grupos de instâncias gerenciadas oferecem suporte a dois tipos de atualização:

• Atualizações automáticas ou proativas
• Atualizações seletivas ou oportunistas

Se quiser aplicar atualizações automaticamente, defina o tipo como proactive .

Como alternativa, se uma atualização automatizada for potencialmente muito perturbadora, você poderá optar por realizar uma atualização oportunista . O MIG aplica uma atualização oportunista somente quando você inicia manualmente a atualização 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 escalonador automático, redimensiona o MIG. O Compute Engine não inicia ativamente solicitações para aplicar atualizações oportunistas em instâncias existentes.

Para obter mais informações sobre atualizações automatizadas versus atualizações seletivas, consulte Métodos para aplicar uma nova configuração a VMs existentes .

Surto máximo

Use a opção maxSurge para configurar quantas novas instâncias o MIG pode criar acima de seu 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é 5 novas instâncias acima do tamanho desejado. Definir um valor maxSurge mais alto acelera a atualização, ao custo de instâncias adicionais, que são cobradas de acordo com o Compute Engineplanilha de preços .

Você pode especificar um número fixo ou, se o grupo tiver 10 ou mais instâncias, uma porcentagem. Se você definir uma porcentagem, o atualizador arredondará o número de instâncias, se necessário.

Se você não definir o valor maxSurge , o valor 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 só funciona se você tiver cota ou recursos suficientes para suportar os recursos adicionais.

Se a sua atualização não exigir a substituição das VMs, esta opção será ignorada. Você pode forçar a substituição das VMs durante uma atualização definindo a opção de ação mínima .

Máximo indisponível

Use a opção maxUnavailable para configurar quantas instâncias estão indisponíveis a qualquer momento durante uma atualização automatizada. Por exemplo, se você definir maxUnavailable como 5, apenas 5 instâncias serão colocadas off-line para atualização por vez. Use esta opção para controlar o nível de interrupção da atualização em seu serviço e para controlar a taxa na qual a atualização é implantada.

Este número também inclui quaisquer instâncias que não estejam disponíveis por outros motivos. Por exemplo, se o grupo estiver em processo de redimensionamento , as instâncias no meio da criação poderão ficar indisponíveis. Essas instâncias contam para o número maxUnavailable .

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

Se você não quiser nenhuma máquina indisponível durante uma atualização, defina o valor maxUnavailable como 0 e o valor maxSurge como maior que 0. Com essas configurações, o Compute Engine remove cada máquina antiga somente depois que a nova máquina substituta for criada e executada.

Se você não definir o valor maxUnavailable , o valor 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 mínimo de espera

Use a opção minReadySec para especificar o tempo de espera antes de considerar uma instância nova ou reiniciada como atualizada. Use esta opção para controlar a taxa na qual a atualização automatizada é implantada. O cronômetro inicia quando ambas as condições a seguir forem satisfeitas:

• O status da instância é RUNNING .
• Se a verificação de integridade estiver habilitada, quando a verificação de integridade retornar HEALTHY .

Observe que para que a verificação de integridade retorne íntegra, o atualizador aguarda as seguintes condições:

1. Aguarda até o período especificado pelo valor autohealingPolicies.initialDelaySec do MIG para que a verificação de integridade retorne como HEALTHY .
2. Em seguida, aguarda o período de tempo especificado por minReadySec .

Se a verificação de integridade não retornar HEALTHY dentro do initialDelaySec , o atualizador declarará a instância da VM como não íntegra e potencialmente interromperá a atualização. Enquanto a instância de VM aguarda verificação durante o período initialDelaySec e minReadySec , a currentAction da instância é VERIFYING . No entanto, o status da instância de VM subjacente permanece RUNNING .

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

O valor máximo para o campo minReadySec é 3.600 segundos (1 hora).

O diagrama a seguir mostra como as opções de tamanho de destino, indisponibilidade máxima, pico máximo e tempo de espera mínimo afetam suas instâncias. Para obter mais informações sobre o tamanho do destino, consulte Atualizações Canary .

Ação mínima

Use a opção de ação mínima para minimizar ao máximo a interrupção ou para aplicar uma ação mais perturbadora do que o estritamente necessário. Por exemplo, o Compute Engine não precisa reiniciar uma VM para alterar seus metadados. Mas se seu aplicativo ler metadados de instância somente quando uma VM for reiniciada, você poderá definir a ação mínima para reiniciar a fim de captar alterações de metadados.

Se a atualização exigir uma ação mais perturbadora do que a definida com essa sinalização, o Compute Engine executará a ação necessária para executar a atualização. Por exemplo, se você especificar uma reinicialização como ação mínima, o Atualizador tentará reiniciar as instâncias para aplicar a atualização. Mas, se você estiver alterando o sistema operacional, o que não pode ser feito reiniciando a instância, o atualizador substituirá as instâncias do grupo por novas instâncias de VM.

Para obter mais informações, incluindo opções válidas, consulte Controlando o nível de interrupção durante uma atualização contínua .

Ação permitida mais perturbadora

Use a opção de ação permitida mais perturbadora para evitar uma atualização se ela exigir mais interrupções do que você pode pagar. Se uma atualização não puder ser concluída devido a esta configuração, a atualização falhará e suas VMs manterão a configuração anterior.

Para obter mais informações, consulte Controlando o nível de interrupção durante uma atualização contínua .

Método de substituição

Por padrão, quando você atualiza proativamente um MIG, o grupo exclui suas instâncias de VM e as troca por novas instâncias com novos nomes. Se você precisar preservar os nomes das suas 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âncias específicos. Por exemplo, alguns aplicativos, como o Memcached, dependem de nomes de instâncias porque não possuem um serviço de descoberta; como resultado, sempre que o nome de uma instância é alterado, o aplicativo perde a conexão com essa VM específica.

Para preservar os nomes das instâncias, defina o método de substituição como RECREATE em vez de SUBSTITUTE se você atualizar o MIG com a CLI gcloud ou a API Compute Engine. Como alternativa, se você atualizar o MIG no console do Google Cloud, marque a caixa de seleção Manter nomes ao substituir VMs .

Os valores replacementMethod válidos são:

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

• RECREATE . Preserva 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 o mesmo nome. Para usar este modo, você deve definir maxSurge como 0 .

Para obter mais informações, consulte Preservando nomes de instâncias .

Exemplos adicionais de atualização

Aqui estão alguns exemplos de linha de comando com opções de configuração comuns.

Execute uma atualização contínua de todas as instâncias de VM, mas crie até cinco novas instâncias acima do tamanho desejado por vez

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

Execute uma atualização contínua com no máximo 3 máquinas indisponíveis e um tempo de espera mínimo de 3 minutos antes de marcar uma nova instância como disponível

gcloud beta 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]

Execute uma atualização contínua de todas as instâncias de VM, mas crie até 10% de novas instâncias acima do tamanho desejado por vez

Por exemplo, se você tiver 1.000 instâncias e executar o comando a seguir, o atualizador criará até 100 instâncias antes de começar a remover instâncias que estão executando o modelo de instância 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 canário

Uma atualização canário é uma atualização aplicada a um subconjunto de instâncias no grupo. Com uma atualização canário, você pode testar novos recursos ou atualizações em um subconjunto aleatório de instâncias, em vez de lançar uma atualização potencialmente perturbadora para todas as suas instâncias. Se uma atualização não estiver indo bem, você só precisará reverter o subconjunto de instâncias, minimizando a interrupção para seus usuários.

Uma atualização canário é igual a uma atualização contínua padrão, exceto que o número de instâncias que devem ser atualizadas é menor que o tamanho total do grupo de instâncias. Como uma atualização contínua padrão, você pode configurar opções adicionais para controlar o nível de interrupção do seu serviço.

Iniciando uma atualização canário

Para iniciar uma atualização canário, especifique até duas versões de modelo de instância, normalmente um novo modelo de instância para canário e o modelo de instância atual para o restante das instâncias. Por exemplo, você pode especificar que 20% de suas instâncias sejam criadas com base em NEW_INSTANCE_TEMPLATE enquanto o restante das instâncias continua a ser executado em OLD_INSTANCE_TEMPLATE . Não é possível especificar mais de dois modelos de instância por vez. O NEW_INSTANCE_TEMPLATE pode ser um modelo de instância regional da mesma região do seu MIG ou um modelo de instância global.

Você deve sempre especificar um tamanho de destino ( targetSize ) para a versão canário. Você não poderá iniciar uma atualização canário se omitir o tamanho de destino da versão canário. Por exemplo, se você especificou que 10% das instâncias devem ser usadas para canarying, os 90% restantes permanecerão intactos e usarão o modelo de instância atual.

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]

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

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"
  }
 ]
}

Para obter mais opções, consulte Configurando opções para sua atualização .

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

Avançando uma atualização canário

Depois de executar uma atualização canário , você pode decidir se deseja confirmar a atualização para 100% do MIG ou revertê-la.

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

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
   }
 ]
}

Monitorando atualizações

Depois de iniciar uma atualização, pode levar algum tempo para que a nova configuração seja concluída em todas as instâncias afetadas. Você pode monitorar o progresso de uma atualização verificando o seguinte:

• Para verificar se todas as VMs atingiram a versão do modelo de destino, visualize o status do grupo .
• Para verificar se VMs específicas atingiram a versão do modelo de destino, visualize as ações atuais nas instâncias .
• Para MIGs com estado, consulte também Verificando se as configurações por instância foram aplicadas .

Status do grupo

No nível do grupo, o Compute Engine preenche um campo somente leitura chamado status que contém uma sinalização versionTarget.isReached e uma sinalização isStable . Você pode usar a CLI gcloud ou REST para acessar esses sinalizadores. Você também pode usar o console do Google Cloud para ver o número atual e planejado de instâncias que estão sendo atualizadas.

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

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

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

Verificando se uma implementação de atualização foi concluída

Verifique se a implementação de uma atualização foi concluída 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 do destino.

Verificando se um grupo gerenciado de instâncias é estável

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 do MIG está passando por qualquer tipo de alteração e a currentAction para todas as instâncias é NONE .
• Não há alterações pendentes para instâncias do MIG.
• O MIG em si não está sendo modificado.

Lembre-se de que a estabilidade de um MIG depende de vários fatores porque um MIG pode ser modificado de diversas maneiras. Por exemplo:

• Você faz uma solicitação para implementar 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 no MIG.
• Num 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 em instâncias

Use a Google Cloud CLI ou REST para ver detalhes sobre as instâncias em um grupo de instâncias gerenciadas. Os detalhes incluem o status da instância e as ações atuais que o grupo está executando em suas instâncias.

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

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

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

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

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

{
 "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 Ciclo de vida da instância de VM .

Se uma instância estiver passando por algum tipo de alteração, o grupo de instâncias gerenciadas definirá o campo currentAction da instância como uma das ações a seguir para ajudar você a acompanhar o progresso da alteração. Caso contrário, o campo currentAction será definido como NONE .

Os possíveis valores 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 de seus pools de destino atuais e sendo readicionada à lista de pools de destino atuais (essa lista pode ser igual ou diferente dos pools de destino existentes).
• RESTARTING . A instância está sendo reiniciada usando os métodos stop e start .
• RESUMING . A instância está em processo de retomada após ser suspensa.
• STARTING . A instância está em processo de inicialização após ser interrompida.
• STOPPING . A instância está sendo interrompida.
• SUSPENDING . A instância está sendo suspensa.
• VERIFYING . A instância foi criada e está em processo de verificação.
• NONE . Nenhuma ação está sendo executada na instância.

Revertendo uma atualização

Não há nenhum 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 confirmada ou uma atualização canário), poderá fazer isso fazendo uma nova solicitação de atualização e passando o modelo de instância para o qual deseja 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]

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
    }
  ]
}

O Updater trata uma solicitação de reversão da mesma forma que uma solicitação de atualização normal, portanto você pode especificar opções de atualização adicionais.

Parando uma atualização

Não existe um método ou comando explícito para interromper uma atualização. Você pode alterar uma atualização de proativa para oportunista e, se o grupo não estiver sendo redimensionado por outros serviços, como o escalonador automático, a mudança para oportunista interromperá efetivamente a atualização.

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

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

Para interromper completamente a atualização após convertê-la de proativa em oportunista, siga estas etapas:

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 CLI gcloud retorna uma resposta que inclui uma lista de instâncias no grupo e seus status atuais:

   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 realizar uma nova atualização, mas passe o número de instâncias que já foram atualizadas como tamanho alvo:

   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 Atualizador, esta atualização parece concluída, portanto nenhuma outra instância é atualizada, interrompendo efetivamente a atualização.

Controlando a velocidade de uma atualização contínua

Por padrão, quando você faz uma solicitação de atualização, o Atualizador executa a atualização o mais rápido possível. Se não tiver certeza se deseja aplicar uma atualização totalmente ou estiver testando suas alterações, você pode controlar 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 grande. Definir esse valor faz com que o atualizador aguarde esse número de segundos antes de considerar a instância atualizada com êxito e prosseguir para a próxima instância.
3. Habilite a verificação de integridade para fazer com que o atualizador aguarde o início do seu aplicativo e relate um sinal íntegro antes de considerar a instância atualizada com êxito e prosseguir para a próxima instância.
4. Defina valores baixos maxUnavailable e maxSurge . Isso garante que apenas um número mínimo de instâncias seja atualizado por vez.
5. Atualize seletivamente as instâncias em um MIG em vez de usar uma atualização automatizada.

Você também pode usar uma combinação desses métodos para controlar a taxa de atualização.

Controlando o nível de interrupção durante uma atualização contínua

Dependendo da natureza de uma atualização, ela poderá interromper o estado do ciclo de vida de uma instância. Por exemplo, alterar o disco de inicialização de uma instância requer a substituição da instância. Você pode controlar o nível de interrupção durante uma atualização contínua definindo as seguintes opções:

• Ação mínima : Use esta opção para minimizar ao máximo a interrupção ou para aplicar uma ação mais perturbadora do que o necessário.

  • Para limitar ao máximo a interrupção, defina a ação mínima como REFRESH . Se a atualização exigir uma ação mais disruptiva, o Compute Engine executará a ação necessária para executar a atualização.
  • Para aplicar uma ação mais perturbadora do que o estritamente necessário, defina a ação mínima como RESTART ou REPLACE . Por exemplo, o Compute Engine não precisa reiniciar uma VM para alterar seus metadados. Mas se seu aplicativo ler metadados de instância somente quando uma VM for reiniciada, você poderá definir a ação mínima como RESTART para captar alterações de metadados.

• Ação permitida mais perturbadora : use esta opção para evitar uma atualização se ela exigir mais interrupções do que você pode pagar. Se a sua atualização exigir uma ação mais perturbadora do que a definida com esse sinalizador, a solicitação de atualização falhará. Por exemplo, se você definir a ação permitida mais perturbadora como RESTART , uma tentativa de atualizar a imagem do disco de inicialização falhará porque essa atualização requer a substituição da instância, uma ação mais perturbadora do que uma reinicialização.

Ambas as opções aceitam os seguintes valores:

A ação permitida mais perturbadora não pode ser menos perturbadora do que a ação mínima.

Quando você distribui atualizações automaticamente, os seguintes padrões se aplicam:

• A ação mínima padrão é REPLACE . Se quiser evitar interrupções desnecessárias, defina a ação mínima para ser menos perturbadora.
• A ação padrão mais perturbadora permitida é REPLACE . Se você não puder tolerar tal interrupção, defina a ação permitida mais perturbadora para ser menos perturbadora.

Você pode alterar o comportamento padrão usando a API Compute Engine para definir os campos updatePolicy.minimalAction e updatePolicy.mostDisruptiveAllowedAction no seu recurso MIG, por exemplo, chamando o método regionInstanceGroupManagers.patch . Como alternativa, você pode selecionar as ações específicas permitidas para atualizar VMs ao atualizar seu MIG no console do Google Cloud. Para visualizar as configurações atuais, consulte Obtendo as propriedades de um MIG .

Uma atualização falhará se exigir uma ação mais perturbadora do que a permitida. Se isso acontecer, você poderá tentar a atualização novamente com uma ação permitida mais perturbadora ou poderá atualizar a instância seletivamente . O Compute Engine realiza a validação de melhor esforço para verificar se as instâncias podem ser atualizadas com o limite de interrupção especificado. Mas devido a mudanças simultâneas no sistema, a situação pode mudar após o início da atualização. Se uma operação em uma instância específica falhar, liste os erros da instância para ver o erro.

Executando uma reviravolta ou reiniciar

Um reinício de rolamento para e reinicia todas as instâncias, enquanto um Rolling substitui as instâncias de acordo com a opção Método de Substituição . Um reinício ou substituição de rolamento não altera mais nada sobre o grupo, incluindo o modelo de instância.

Existem muitas razões pelas quais você pode querer uma reinicialização ou uma substituição. Por exemplo, você pode reiniciar ou substituir suas instâncias de VM de tempos em tempos por um dos seguintes motivos:

• Limpe os vazamentos de memória.
• Reinicie seu aplicativo para que ele possa funcionar de uma máquina fresca.
• Aplique uma substituição periódica como uma prática recomendada para testar suas VMs.
• Atualize a imagem do sistema operacional da sua VM ou os scripts de inicialização executada para atualizar seu software.

Use o Google Cloud Console, o Google Cloud CLI ou descanse para executar uma reinicialização ou substituição.

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

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-1705499403"
  }
 ]
}

Exemplos adicionais de substituição/reinicialização

Realize um reinício de todas as VMs, duas de cada vez

Este comando reinicia todas as VMs do grupo, duas de cada vez. Observe que nenhum novo modelo de instância está especificado.

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

Realize um reinício 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]

Execute uma substituição 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]

Preservando nomes de instância

Se você precisar preservar os nomes de suas instâncias da VM em uma atualização, defina o replacementMethod para RECREATE . Você também deve definir maxUnavailable como maior que 0 e maxSurge como 0 . A recriação de instâncias em vez de substituí -las faz com que sua atualização demore mais tempo, mas as instâncias atualizadas mantêm seus nomes.

Se você não especificar um método de substituição, o valor atual da updatePolicy.replacementMethod . Se não estiver definido, o valor padrão do substitute será usado, que substitui as instâncias da VM por novas instâncias que geraram nomes aleatoriamente.

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]

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 a atualização terminar.

Atualizando um grupo de instância gerenciado regional

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

A execução de uma atualização em um MIG regional é o mesmo que executar uma atualização em um MIG zonal, com algumas exceções descritas abaixo. Quando você inicia uma atualização para um MIG regional, o atualizador sempre atualiza instâncias proporcionalmente e uniformemente em cada zona. Você não pode escolher quais instâncias em que as zonas são atualizadas primeiro nem pode optar por atualizar instâncias em apenas uma zona.

Diferenças entre atualizar MIGs regionais versus zonais

Os 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 para um MIG regional é 3 . Mas você pode selecionar um número diferente.

Se você estiver usando números fixos ao especificar uma atualização, o número fixo deverá ser 0 ou igual ou superior ao número de zonas associadas ao MIG regional. Por exemplo, se o grupo for distribuído em três zonas, você não poderá definir maxSurge como 1 ou 2 porque o atualizador deve criar uma instância adicional em cada uma das três zonas.

Usando um número fixo ou uma porcentagem em solicitações de atualização

Se você especificar um número fixo em suas solicitações de atualização, o número que você especificará é dividido pelo número de zonas no MIG regional e distribuído uniformemente. Por exemplo, se você especificar maxSurge=10 , o atualizador divide 10 através do número de zonas na região e cria instâncias com base nesse número. Se o número de instâncias não se dividir uniformemente nas zonas, o atualizador adicionará as instâncias restantes a uma zona aleatória. Assim, para 10 instâncias em três zonas, duas das zonas recebem 3 instâncias e uma zona recebe 4 instâncias. A mesma lógica é aplicada aos parâmetros maxUnavailable e os parâmetros targetSize para as atualizações do Canary.

Você pode especificar uma porcentagem apenas se o seu MIG contiver 10 ou mais instâncias de VM. As porcentagens são tratadas de maneira um pouco diferente, dependendo da situação:

• Se você especificar uma porcentagem de instâncias da VM para uma atualização do Canary, o atualizador tenta distribuir as instâncias uniformemente através das zonas. O restante é arredondado para cima ou para baixo em cada zona, mas a diferença total não é superior a uma instância de 1 VM por grupo. Por exemplo, para um MIG com 10 instâncias e uma porcentagem de tamanho de alvo de 25%, a atualização é lançada para 2 a 3 instâncias de VM.

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

O que vem a seguir

• Aprenda sobre a visualização de informações sobre MIGs e instâncias gerenciadas .
• Aprenda sobre a criação de modelos de instância .
• Aprenda a usar as famílias de imagens e um Rolling Substituir para atualizar a imagem do sistema operacional em todas as VMs em um MIG.