Como lançar atualizações para grupos de instâncias gerenciadas

Um grupo de instâncias gerenciadas contém uma ou mais instâncias de máquina virtual controladas por meio de um modelo de instância. Para atualizar as instâncias gerenciadas em um grupo, é possível fazer solicitações de atualização ao grupo como um todo usando o recurso Managed Instance Group Updater.

Para saber mais sobre grupos de instâncias, leia a Visão geral de grupos de instâncias.

O Managed Instance Group Updater permite implantar facilmente novas versões do software nas instâncias gerenciadas dos seus grupos, além de controlar a velocidade de implantação, o nível de interferência do serviço e o escopo da atualização. O Updater oferece duas vantagens principais:

  • O lançamento de uma atualização acontece automaticamente de acordo com suas especificações, sem a necessidade de contribuição adicional do usuário após a solicitação inicial.
  • É possível fazer lançamentos parciais que permitem teste canário.

Ao permitir que um novo software seja implantado em um grupo atual de instâncias gerenciadas, não será necessário reconfigurar o grupo ou reconectar o balanceamento de carga, o escalonamento automático ou a recuperação automática toda vez que uma nova versão do software for lançada. Sem o Updater, as novas versões do software precisam ser implantadas por meio da criação de um novo grupo de instâncias gerenciadas com uma nova versão do software (o que requer uma configuração adicional toda vez) ou por meio da recriação manual de cada instância iniciada pelo usuário. As duas abordagens requerem etapas manuais significativas ao longo do processo.

Antes de começar

Como iniciar uma atualização contínua básica

Uma atualização contínua é aplicada gradualmente a todas as instâncias de um grupo de instâncias até que todas tenham sido atualizadas. Você pode controlar vários aspectos de uma atualização contínua, 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.

Aqui estão algumas observações para ter em mente durante 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 retorna uma resposta de êxito para confirmar que a solicitação era válida. No entanto, isso não indica que a atualização foi bem-sucedida. Você precisa verificar o status do grupo de instâncias gerenciadas para determinar se a atualização foi realmente implantada.

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

  • O recurso Updater é compatível com até duas versões de modelo de instância no grupo de instâncias gerenciadas. Isso significa que é possível especificar duas versões de modelo de instância diferentes para o grupo de instâncias gerenciadas, 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. Acesse a página "Grupos de instâncias" no Console do GCP.

    Acessar a página "Grupos de instâncias"

  2. Selecione o grupo de instâncias a ser atualizado.
  3. Na parte superior da página, clique em Atualização gradual.
  4. Em Modelo, abra o menu suspenso e selecione o novo modelo de atualização.
  5. Para o tamanho de destino, insira 100% para atualizar todas as instâncias.
  6. Opcionalmente, é possível alternar as opções de configuração, como se a atualização é proativa (o grupo substitui instâncias ativamente) ou oportunista (o grupo não substitui as instâncias ativamente, mas aplica a atualização quando elas são substituídas por outros meios). É possível também inserir as opções de máximo de sobretensão, máximo indisponível e tempo de espera mínimo.
  7. Clique em Atualizar para iniciar a atualização.

gcloud

Usando a ferramenta gcloud, execute o comando rolling-action start-update:

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

em que:

  • [INSTANCE_GROUP] é o nome do grupo de instâncias a ser atualizado.
  • [INSTANCE_TEMPLATE] é o novo modelo de instância para atualizar o grupo de instâncias;
  • é necessário fornecer uma [ZONE] ou [REGION] para esse grupo de instâncias. Se o grupo de instâncias for do tipo zonal, forneça a zona. Se for regional, forneça a região.

API

Na API, faça uma solicitação PATCH para o seguinte URL:

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_INSTANCE_GROUP_NAME]

Se o grupo de instâncias for um grupo regional de instâncias gerenciadas, substitua zones/[ZONE] por regions/[REGION].

A payload da solicitação contém:

No exemplo a seguir, demonstramos a configuração mínima necessária para iniciar uma atualização na API.

Se você não especificar o contrário, as propriedades maxSurge e maxUnavailable serão padronizadas como 1 multiplicado pelo número de zonas afetadas. Isso significa que o Updater torna apenas uma instância indisponível em cada zona afetada e cria somente uma instância adicional por zona durante a atualização.

Nesta solicitação de exemplo, 100% das instâncias são atualizadas para o novo modelo.

{
  "instanceTemplate": "global/instanceTemplates/example-template",
  "updatePolicy": {
    "type": "proactive"
   }
 }

Depois de fazer uma solicitação, será possível monitorar a atualização para saber quando ela foi concluída.

Configuração de opções para a atualização

No caso de atualizações mais complexas, é possível configurar mais opções para uma solicitação de atualização específica. Essas opções estão descritas abaixo.

Máximo de sobretensão

Defina a propriedade maxSurge para permitir que o Updater crie temporariamente novas instâncias acima do targetSize durante a atualização. Por exemplo, se você definir maxSurge como 5, o grupo de instâncias gerenciadas criará até cinco novas instâncias acima do tamanho de destino com o novo modelo de instância. A definição de um valor maxSurge maior acelera a atualização e tem o custo de instâncias extras, que são faturadas de acordo com a tabela de preços do Compute Engine.

Se você não definir o maxSurge, o valor padrão será usado. Para grupos de instâncias gerenciadas por zona, o padrão de maxSurge é 1. Para grupos de instâncias gerenciadas por região, o padrão é [NUMBER_OF_ZONES], em que [NUMBER_OF_ZONES] é o número de zonas associadas ao grupo de instâncias gerenciadas por região.

Essa opção é reconhecida somente quando configurada com a ação mínima REPLACE, mas não é permitida com a configuração da ação RESTART. Especifique um número fixo ou uma porcentagem se o grupo de instâncias gerenciadas tiver 10 ou mais instâncias. Se você definir uma porcentagem, o Updater arredondará o número de instâncias para cima, se necessário.

maxSurge somente funcionará se você tiver cota ou recursos suficientes para acomodar os recursos extras.

Máximo indisponível

Defina a configuração maxUnavailable de modo que somente um certo número de instâncias fique indisponível a qualquer momento durante a atualização. Por exemplo, se definir maxUnavailable como 5, apenas cinco instâncias ficarão off-line para atualização de cada vez. Utilize esse parâmetro para controlar o quanto a atualização é disruptiva para o serviço e controlar a taxa na qual a atualização é implantada.

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 de instâncias estiver em processo de redimensionamento, as instâncias que ainda estiverem no meio da etapa de criação talvez não estejam disponíveis. Elas serão incluídas no número de maxUnavailable. Especifique um número fixo ou uma porcentagem se o grupo de instâncias gerenciadas tiver 10 ou mais instâncias. Se você definir uma porcentagem, o Updater arredondará o número de instâncias para baixo, se necessário.

O valor padrão de maxUnavailable em um grupo de instâncias gerenciadas por zona é 1. Em um grupo de instâncias gerenciadas por região, o padrão é [NUMBER_OF_ZONES]. Por padrão, o número de zonas selecionadas para o grupo de instâncias gerenciadas por região é 3.

Tempo de espera mínimo

Defina minReadySeconds para especificar quanto tempo aguardar antes de considerar uma instância recém-criada ou reiniciada como atualizada. Use esse recurso para controlar a taxa em que a atualização é implantada. O timer é iniciado quando as duas condições a seguir são satisfeitas:

Para que a verificação de integridade retorne o status "healthy", o Updater:

  1. aguardará o período especificado por autohealingPolicies.initialDelaySec até a verificação de integridade retornar HEALTHY;
  2. aguardará o período especificado por minReadySeconds.

Se a verificação de integridade não retornar HEALTHY dentro de 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 está aguardando a verificação durante o período initialDelaySec e minReadySeconds, 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 de instâncias, o timer será iniciado quando o status da instância for RUNNING. O valor máximo para a propriedade minReadySeconds é 3.600 segundos (1 hora).

Ação mínima

Defina a propriedade que controla a ação mínima executada pelo Updater 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 uma nova instância, mesmo que isso não seja necessário.

A definição de uma ação mínima garante que o Updater execute pelo menos essa ação. 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, o Updater executará uma ação mais disruptiva se isso for necessário para a atualização. Por exemplo, não é possível alterar o sistema operacional de uma instância reiniciando-a. Portanto, o Updater substituirá as instâncias no grupo por novas instâncias de VM.

As ações aplicáveis são REPLACE ou RESTART:

  • RESTART: reinicia a instância (executa uma solicitação stop e start). A solicitação de atualização será forçada a executar REPLACE se ela exigir que a instância seja substituída para aplicar as alterações. Por exemplo, alterar a imagem pode exigir que a instância seja excluída e substituída.

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

O diagrama a seguir visualiza como essas opções afetam as instâncias.

Diagrama sobre como as diferentes opções do Updater afetam a solicitação

Exemplos de atualização adicionais

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

Executar uma atualização contínua de todas as instâncias de máquina virtual, mas criar até cinco novas instâncias acima do tamanho de destino de cada vez

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

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

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

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

Como iniciar uma atualização canário

O recurso Instance Group Updater permite a realização de atualizações canário, para que você possa testar as atualizações em um subconjunto aleatório de instâncias antes de se comprometer totalmente com a atualização.

Uma atualização canário é aplicada a um número parcial de instâncias no grupo. As atualizações canário permitem testar novos recursos ou atualizações em um subconjunto 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 um pequeno número de instâncias, minimizando a interrupção para os usuários. Do ponto de vista do servidor, uma atualização canário é idêntica a uma atualização contínua padrão, exceto pelo fato de o número de instâncias que devem ser atualizadas ser menor que o tamanho total do grupo de instâncias. Como uma atualização contínua padrão, uma atualização canário é disruptiva para as instâncias afetadas. Ou seja, as instâncias afetadas são excluídas e substituídas por novas instâncias de VM durante a atualização.

Para iniciar uma atualização canário, faça o seguinte:

  • Especifique até duas versões do modelo de instância, normalmente um novo modelo para canário e outro atual para o restante das instâncias. Por exemplo, é possível especificar que 20% das instâncias sejam criadas com base em new-instance-template, enquanto o restante delas continuará a ser executada em old-instance-template. Não é possível especificar mais de dois modelos de instância de cada vez.

  • Sempre especifique um tamanho de destino (targetSize) para a versão canário. Não é 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 precisam ser usadas para o teste canário, os 90% restantes permanecerão intactos e usarão o modelo atual.

Console

  1. Acesse a página "Grupos de instâncias" no Console do GCP.

    Acessar a página "Grupos de instâncias"

  2. Selecione o grupo de instâncias a ser atualizado.
  3. Na parte superior da página, clique em Atualização contínua.
  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. Opcionalmente, é possível alternar as opções de configuração, como se a atualização é proativa (o grupo exclui e substitui instâncias ativamente) ou oportunista (o grupo não substitui as instâncias ativamente, mas aplica a atualização quando elas são criadas por outros meios). É possível também inserir as opções de máximo de sobretensão, máximo indisponível e tempo de espera mínimo.
  7. Clique em Atualizar para iniciar a atualização.

gcloud

Usando a ferramenta de linha de comando gcloud, forneça o modelo atual e o modelo novo para expressar explicitamente quantas instâncias cada modelo deve usar:

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

em que:

  • [CURRENT_TEMPLATE] é o modelo atual que o grupo de instâncias está executando;
  • [NEW_TEMPLATE] é o novo modelo no qual você quer fazer a atualização canário;
  • [SIZE] é o número ou a porcentagem de instâncias em que você quer aplicar essa atualização. Aplique a propriedade target-size ao modelo --canary-version. Só será possível definir uma porcentagem se o grupo tiver 10 instâncias ou mais;
  • é necessário fornecer uma [ZONE] ou [REGION] para esse grupo de instâncias. Se o grupo de instâncias for do tipo zonal, forneça a zona. Se for regional, forneça a região.

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

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

API

Na API, faça uma solicitação PATCH para o seguinte URI:

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

A payload da solicitação deve conter o modelo de instância atual e o novo modelo de instância no qual você quer fazer a atualização canário. Por exemplo:

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

em que:

  • [NEW_TEMPLATE] é o nome do novo modelo no qual você quer fazer a atualização canário;
  • [NUMBER|PERCENTAGE] é o número fixo ou a porcentagem de instâncias para fazer o canário nessa atualização. Só será possível definir uma porcentagem se o grupo tiver 10 instâncias ou mais. Caso contrário, forneça um número fixo;
  • [CURRENT_TEMPLATE] é o nome do modelo atual que o grupo de instâncias está executando.

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

Depois de executar uma atualização canário, é possível decidir se você quer confirmar a atualização para 100% do grupo de instâncias ou revertê-la.

Console

  1. Acesse a página "Grupos de instâncias" no Console do GCP.

    Acessar a página "Grupos de instâncias"

  2. Selecione o grupo de instâncias a ser atualizado.
  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

Caso queira fazer o commit da atualização canário, implante-a fazendo a mesma solicitação de atualização, mas definindo apenas version e omitindo --canary-version. Com a ferramenta de linha de comando gcloud:

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

API

Na API, faça uma solicitação PATCH para o seguinte URI:

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

No corpo de solicitação, especifique o novo modelo de instância como uma version e omita o modelo de instância antigo do corpo de solicitação. Omita a especificação do tamanho de destino para implantar a atualização em 100% das instâncias. Por exemplo, o corpo de solicitação ficaria assim:

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

Substitua [NEW_TEMPLATE] pelo nome do novo modelo de instância que você quer implantar.

Como iniciar uma atualização oportunista ou proativa

Por padrão, as atualizações feitas usando a ferramenta de linha de comando gcloud são proativas e as atualizações iniciadas na API são oportunistas.

Para as atualizações proativas, o Compute Engine programa ativamente ações para aplicar as atualizações solicitadas às instâncias, conforme necessário. Em muitos casos, isso geralmente significa excluir e recriar instâncias proativamente.

Se preferir, execute uma atualização oportunista, se a atualização proativa for potencialmente muito disruptiva. Uma atualização oportunista apenas é aplicada quando você a inicia manualmente nas instâncias selecionadas ou quando novas instâncias são criadas pelo grupo de instâncias gerenciadas. O grupo de instâncias gerenciadas cria novas instâncias ao ser redimensionado por outro serviço, como um autoescalador, ou manualmente por um usuário. O Compute Engine não inicia as solicitações ativamente para aplicar as atualizações.

Em certos cenários, a atualização oportunista é útil para evitar instabilidade no sistema. Por exemplo, se você tiver uma atualização não crítica que pode ser aplicada conforme necessário e sem urgência, e tiver um grupo de instâncias gerenciadas cujo tamanho está sendo ativamente autoajustado, realize uma atualização oportunista para que o Compute Engine não desmonte ativamente as instâncias existentes para aplicar a atualização.

Para escolher se uma atualização é oportunista ou proativa, defina a propriedade como OPPORTUNISTIC ou PROACTIVE usando a ferramenta de linha de comando gcloud ou a API.

Console

  1. Acesse a página "Grupos de instâncias" no Console do GCP.

    Acessar a página "Grupos de instâncias"

  2. Selecione o grupo de instâncias a ser atualizado.
  3. Na parte superior da página, clique em Atualização gradual.
  4. Em Modelo, escolha um modelo para atualizar o grupo de instâncias e selecione um tamanho de destino para o modelo.
  5. Em Modo de atualização, escolha entre uma atualização oportunista ou proativa.
  6. Clique em Atualizar para iniciar a atualização.

gcloud

Com a ferramenta de linha de comando gcloud:

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

API

Na payload da solicitação para iniciar uma atualização, inclua a propriedade type em updatePolicy:

{
"updatePolicy": {
  "type": "PROACTIVE" # Performs a proactive update
},
"versions": [{
  "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]",
  }]
}

em que [NEW_TEMPLATE] é o nome do novo modelo no qual você quer fazer a atualização canário. Para uma atualização oportunista, substitua PROACTIVE por OPPORTUNISTIC.

Como atualizar instâncias selecionadas

Ao iniciar uma atualização oportunista, você precisa aguardar que o Compute Engine lance a atualização conforme surgem as oportunidades. No entanto, para ter mais controle sobre o lançamento, é possível iniciar manualmente essa atualização de imediato nas instâncias específicas do grupo de instâncias gerenciadas.

Quando você inicia as atualizações manualmente, é possível:

  • selecionar as instâncias que você quer atualizar;
  • aplicar uma atualização com o mínimo de interferência necessária para que ela seja concluída. Por exemplo, se você estiver apenas atualizando metadados, talvez não seja necessário reiniciar a instância para concluir a atualização. Ao iniciar manualmente a atualização, a ação mínima necessária é executada de maneira automática;
  • forçar a reinicialização ou recriação da instância, mesmo que essas ações não sejam necessárias para aplicar a atualização. Por exemplo, para reiniciar uma VM mesmo que você esteja apenas atualizando os metadados, já que o software convidado precisa recuperar os novos metadados durante a inicialização da VM.
  • impedir uma atualização, se ela exigir mais interferência do que você consegue sustentar;
  • executar uma atualização de todas as instâncias selecionadas imediatamente, sem restringir o lançamento por meio das restrições maxSurge e maxUnavailable.

Ação mínima e ação permitida mais disruptiva

Dependendo da natureza da atualização, ela pode interferir no estado da instância. Por exemplo, a alteração do tipo de máquina de uma instância requer que a VM seja reiniciada, já a alteração da imagem de inicialização dela requer a exclusão e a substituição da instância.

É possível controlar o nível de interferência usando as sinalizações minimal-action e most-disruptive-allowed-action:

  • minimal-action permite forçar uma ação mais disruptiva do que é necessário.
  • most-disruptive-allowed-action permite impedir uma atualização se ela exigir mais interferência do que você consegue sustentar.

Ao atualizar as instâncias selecionadas, essas duas sinalizações aceitam as seguintes ações:

AçãoDescriçãoQue propriedades da instância podem ser atualizadas?
NONENão interrompa a instância de modo algum.Nenhuma
REFRESHNão pare a instância.Discos secundários, metadados de instância, rótulos
RESTARTPare a instância e inicie-a novamente.Tipo de máquina
REPLACEExclua a instância e crie-a novamente.Todas as propriedades da instância armazenadas no modelo.

Por padrão, a minimal-action é NONE. Se a atualização exigir uma ação mais disruptiva do que a definida por essa sinalização, o Compute Engine executará a ação necessária para executar a atualização.

Por padrão, a most-disruptive-allowed-action é REPLACE. Se a atualização exigir uma ação mais disruptiva do que a definida por essa sinalização, haverá falha na solicitação de atualização. Por exemplo, se você definir "reiniciar" como a ação mais disruptiva permitida, haverá falha na tentativa de atualizar a imagem do disco de inicialização, já que essa atualização exige a recriação da instância, uma ação mais disruptiva que a reinicialização.

É possível atualizar as instâncias selecionadas com a ferramenta gcloud ou a API.

gcloud

Depois de iniciar uma atualização oportunista, use o subcomando update-instances para aplicá-la a instâncias específicas.

gcloud beta compute instance-groups managed update-instances [INSTANCE_GROUP] \
    --instances [INSTANCE_NAMES] \
    --most-disruptive-allowed-action [DISRUPTION_LEVEL] \
    --minimal-action [DISRUPTION_LEVEL]

Em que:

  • [INSTANCE_GROUP] é o nome do grupo de instâncias com atualizações pendentes;
  • [INSTANCE_NAMES] é uma lista de instâncias a serem atualizadas imediatamente;
  • [DISRUPTION_LEVEL] é o nível mínimo ou máximo de interferência: NONE, REFRESH, RESTART e REPLACE
    • A minimal-action padrão é NONE.
    • A most-disruptive-allowed-action padrão é REPLACE.

Se você precisa aguardar até que todas as instâncias especificadas sejam atualizadas, verifique o status do grupo e espere-o ficar estável.

API

Depois de iniciar uma atualização oportunista, crie uma solicitação POST para o método Beta regionInstanceGroupManagers.applyUpdatesToInstances. Para um grupo de instâncias gerenciadas por zona, use o método instanceGroupManagers.applyUpdatesToInstances por zona.

POST https://www.googleapis.com/compute/beta/projects/[PROJECT]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/applyUpdatesToInstances
{
  "instances": "zones/[ZONE]/instances/[INSTANCE_NAME]","zones/[ZONE]/instances/[INSTANCE_NAME]"
  "minimalAction": [DISRUPTION_LEVEL],
  "mostDisruptiveAllowedAction": [DISRUPTION_LEVEL]
}

Em que:

  • [INSTANCE_GROUP_NAME] é o nome do grupo de instâncias com atualizações pendentes;
  • [ZONE] é a zona de uma instância a ser atualizada imediatamente;
  • [INSTANCE_NAME] é o nome de uma instância a ser atualizada imediatamente;
  • [DISRUPTION_LEVEL] é o nível mínimo ou máximo de interferência: NONE, REFRESH, RESTART e REPLACE
    • A minimalAction padrão é NONE.
    • A mostDisruptiveAllowedAction padrão é REPLACE.

Do mesmo modo que outros métodos de grupo de instâncias gerenciadas, applyUpdatesToInstances é baseado na intenção. Isso significa que ele retorna uma resposta de operação. Depois que a operação for DONE, listManagedInstances incluirá a lista de instâncias com os respectivos campos currentAction alterados para REFRESHING, RESTARTING ou RECREATING. Caso haja falha na operação (por exemplo, devido a alterações simultâneas no grupo) a falha será anotada no campo lastAttempt.errors.

Se você precisa aguardar até que todas as instâncias especificadas concluam a atualização, verifique o status do grupo e espere que ele fique estável.

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

Como alternativa, você pode usar os comandos restart ou replace para executar uma reinicialização ou uma substituição contínua de instâncias de VM no grupo de instâncias gerenciadas. Do mesmo modo que o comando start-update, especifique qualquer uma das opções de configuração para uma reinicialização ou substituição. Uma reinicialização ou substituição contínua não altera nada do grupo de instâncias, incluindo o modelo de instância. Ela simplesmente atualiza as instâncias no grupo usando o método escolhido.

Há vários motivos para realizar uma substituição contínua ou uma reinicialização contínua. Por exemplo, pode ser conveniente atualizar suas instâncias de VM de vez em quando para:

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

Para fazer uma substituição em que todas as instâncias são excluídas e substituídas por novas instâncias:

Console

  1. Acesse a página "Grupos de instâncias" no Console do GCP.

    Acessar a página "Grupos de instâncias"

  2. Selecione o grupo de instâncias a ser atualizado.
  3. Na parte superior da página, clique em Reinicialização/substituição contínua.
  4. Escolha se instâncias serão reiniciadas ou substituídas. A reinicialização executa os métodos stop e start nas instâncias, enquanto uma substituição exclui e cria instâncias ativamente.
  5. Se preferir, alterne as opções de configuração, como máximo de sobretensão, máximo indisponível e tempo de espera mínimo.
  6. Clique no botão Reiniciar ou Substituir para iniciar a atualização.

gcloud

gcloud compute instance-groups managed rolling-action replace [INSTANCE_GROUP]

Esse comando substitui todas as instâncias nos grupos de instâncias gerenciadas, uma por vez. Se uma substituição for muito disruptiva, você pode especificar uma reinicialização contínua, que reinicia todas as instâncias sem excluir nenhuma delas.

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP]

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

API

Na API, faça uma solicitação PATCH para o grupo e defina uma updatePolicy proativa com minimalAction definido como RESTART ou REPLACE de acordo com a opção de fazer uma substituição contínua, em que cada instância é excluída e substituída por uma nova instância, ou uma reinicialização contínua, em que cada instância é interrompida e reiniciada. Tanto no caso de RESTART quanto de REPLACE, sempre é necessário fornecer um versions.instanceTemplate e uma propriedade versions.name (por exemplo, v2) para acionar a ação.

Uma substituição contínua tem a seguinte aparência:

PATCH https://www.googleapis.com/compute/v1/projects/myproject/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "REPLACE",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

Para uma reinicialização contínua:

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

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

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

Realizar uma reinicialização contínua de todas as máquinas virtuais, duas de cada vez

Esse comando reinicia todas as máquinas virtuais no grupo de instâncias, duas de cada 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]]

Reinicialização contínua de todas as VMs o mais rapidamente possível

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

Substituição contínua de todas as VMs o mais rapidamente possível

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

Como atualizar um grupo regional de instâncias gerenciadas

Um grupo regional de instâncias gerenciadas contém instâncias de máquinas virtuais espalhadas por várias zonas dentro de uma região, em oposição aos grupos zonais de instâncias gerenciadas, que contêm apenas instâncias em uma zona. Os grupos regionais de instâncias gerenciadas permitem distribuir instâncias em mais de uma zona para melhorar a disponibilidade do aplicativo e permitir casos extremos em que uma zona falha ou todo um grupo de instâncias deixa de responder.

A atualização de um grupo de instâncias gerenciadas por região usando o recurso Instance Group Updater é semelhante a uma atualização de um grupo por zona, com algumas exceções descritas a seguir. Quando você inicia uma atualização em um grupo de instâncias por região, o Updater sempre atualiza as instâncias de modo proporcional e uniforme em cada zona. Não é possível escolher as instâncias e as zonas que serão atualizadas primeiro nem atualizar as instâncias em apenas uma zona.

Diferenças entre a atualização de um grupo de instâncias gerenciadas por região e por zona

Antes de iniciar uma atualização para um grupo regional de instâncias gerenciadas, esteja ciente de que há vários itens que se comportam de maneira diferente dos grupos zonais de instâncias gerenciadas.

  • Os parâmetros de atualização padrão em grupos de instâncias gerenciadas por região são maxUnavailable=[NUMBER_OF_ZONES] e maxSurge=[NUMBER_OF_ZONES]. [NUMBER_OF_ZONES] é o número de zonas selecionadas para o grupo de instâncias gerenciadas por região que, por padrão, é 3.

  • Se você usa números fixos ao especificar uma atualização, eles precisam ser zero ou igual ou maior que o número de zonas associadas ao grupo de instâncias gerenciadas por região. Por exemplo, se o grupo for distribuído em três zonas, não é possível definir maxSurge como 1 ou 2 porque o Updater precisa criar uma instância extra em cada uma 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 pela quantidade de zonas no grupo de instâncias gerenciadas por região e distribuído uniformemente. Por exemplo, se você especificar maxSurge=10, o Updater dividirá 10 pelo número de zonas na região e criará novas 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á outras instâncias a uma zona aleatória. Portanto, para dez instâncias em três zonas, duas das zonas receberão três instâncias e uma zona receberá quatro instâncias. A mesma lógica é aplicada aos parâmetros maxUnavailable e targetSize para atualizações canário.

Uma porcentagem só pode ser especificada se o grupo de instâncias gerenciadas contém 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á distribuir as instâncias uniformemente entre as zonas. O restante será arredondado para mais ou para menos em cada zona, mas a diferença total não será maior que uma instância de VM por grupo. Por exemplo, em um grupo de instâncias gerenciadas com dez instâncias e uma porcentagem de tamanho de destino de 25%, a atualização será implementada em duas a três instâncias de VM.

  • Se você especificar uma porcentagem para opções de atualização como maxSurge e maxUnavailable, ela será arredondada independentemente por zona. As mesmas regras que se aplicam à atualização de grupos de instâncias gerenciadas por zona se aplicam nesse caso.

Como monitorar as atualizações

Uma atualização gradual pode levar algum tempo para ser concluída depois que você a inicia. Inspecione o status do grupo de instâncias gerenciadas ou verifique a currentAction em cada instância no grupo para monitorar o andamento de uma atualização.

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 outra isStable. Use a ferramenta gcloud ou a API para acessar essas sinalizações.

Para verificar se a atualização do grupo de instâncias foi concluída, confirme se status.versionTarget.isReached==true. Para verificar se todas as instâncias do grupo estão em execução e são íntegras, ou seja, se a currentAction de cada instância gerenciada é NONE, confirme se status.isStable==true. A estabilidade de um grupo de instâncias gerenciadas depende das configurações de grupo além do Updater. Por exemplo, se o grupo for escalonado automaticamente e estiver no processo de expansão, isStable==false em virtude da operação do autoescalador.

É possível também usar o console para ver o número atual e de destino das instâncias que estão sendo atualizadas.

Console

Para monitorar a atualização contínua de um grupo, acesse a página de detalhes do grupo de instâncias específico.

  1. Acesse a página "Grupos de instâncias" no Console do GCP.

    Acessar a página "Grupos de instâncias"

  2. Selecione o grupo de instâncias que você quer monitorar. Na página de visão geral do grupo de instâncias, aparece o modelo que cada instância usa.
  3. Para ver os detalhes, clique na guia Detalhes.

A página Detalhes mostra o número atual e de destino de instâncias sendo atualizadas para cada modelo de instância e também exibe os parâmetros de atualização.

gcloud

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

A ferramenta gcloud retorna informações detalhadas sobre o grupo de instâncias, incluindo os campos status.versionTarget.isReached e status.isStable.

API

Na API, faça uma solicitação POST para o seguinte URI:

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/get

Se o grupo for de instâncias gerenciadas por região, substitua zones/[ZONE] por regions/[REGION].

A API retorna informações detalhadas sobre o grupo de instâncias, incluindo os campos status.versionTarget.isReached e status.isStable.

status.versionTarget.isReached

O lançamento de uma atualização é considerado concluído quando todas as instâncias de VM no grupo foram ou estão sendo criadas na respectiva versão de destino. No caso de um lançamento completo, todas as instâncias são configuradas para usar o novo modelo. No caso de um lançamento parcial, as instâncias são configuradas de acordo com a divisão de destino especificada entre os modelos.

Para verificar se o lançamento de uma atualização foi concluído, verifique o valor do campo status.versionTarget.isReached de um recurso instanceGroupManagers (ou regionInstanceGroupManagers).

status.versionTarget.isReached é definido como true se todas as instâncias de VM foram ou estão sendo criadas usando a versão de destino (versions[]).

status.versionTarget.isReached é definido como false quando pelo menos uma VM ainda não está usando a versão de destino (versions[]). Ou, no caso de uma atualização canário, status.versionTarget.isReached é definido como false quando o número de VMs que usam uma versão de destino (versions[].instanceTemplates) não corresponde ao tamanho de destino (versions[].targetSize).

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

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

status.isStable

É possível verificar se um grupo de instâncias gerenciadas está em execução e é íntegro confirmando o valor do campo status.isStable do recurso instanceGroupManagers ou regionInstanceGroupManagers associado.

status.isStable definido como false indica que as alterações estão ativas, pendentes ou que o próprio grupo de instâncias gerenciadas está sendo modificado.

status.isStable definido como true indica as seguintes condições:

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

Os grupos de instâncias gerenciadas podem ser modificados de várias maneiras. Por 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 grupo.
  • Um autoescalador solicita o redimensionamento do grupo.
  • Um recurso de recuperação automática está substituindo uma ou mais instâncias não íntegras do grupo de instâncias gerenciadas.
  • Em um grupo de instâncias gerenciadas por região, algumas das instâncias são redistribuídas.

Assim que todas as ações forem concluídas, status.isStable será definido como true novamente para esse grupo de instâncias gerenciadas.

Também é possível usar o comando gcloud beta compute instance-groups managed wait-until com a sinalização --stable para aguardar até que status.isStable seja configurado como true para o grupo:

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

Ações atuais nas instâncias

Para visualizar a currentAction sendo executada e o status de cada instância em um grupo de instâncias gerenciadas, use a ferramenta de linha de comando gcloud ou a API.

gcloud

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud retorna uma lista de instâncias no grupo de instâncias e seus respectivos status e ações atuais. Por exemplo:

NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f           CREATING  my-new-template
vm-instances-h2r1  us-central1-f           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

API

Na API, faça uma solicitação POST para o método regionInstanceGroupManagers.listManagedInstances. Para um grupo de instâncias gerenciadas por zonas, use o método instanceGroupManagers.listManagedInstances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

A API retorna uma lista de instâncias do grupo, incluindo instanceStatus e currentAction de cada instância.

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

Para cada instância em um grupo de instâncias gerenciadas, o campo instanceStatus descreve o status dela. Para ver uma lista de valores válidos do campo instanceStatus, consulte Como verificar o status de uma instância.

Se a instância estiver passando por algum tipo de alteração, o campo currentAction também será preenchido com uma das ações a seguir 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 estes:

  • ABANDONING: a instância está sendo removida do grupo de instâncias gerenciadas.
  • CREATING: a instância está em processo de criação.
  • CREATING_WITHOUT_RETRIES: a instância está sendo criada sem novas tentativas. Se ela não for criada na primeira tentativa, o grupo de instâncias gerenciadas não tentará substituí-la novamente.
  • DELETING: a instância está em processo de exclusão.
  • RECREATING: a instância foi excluída e está sendo substituída.
  • REFRESHING: a instância está sendo removida e adicionada novamente à lista de pools de destino atuais. Essa lista pode ser a mesma dos pools de destino atuais ou diferente.
  • RESTARTING: a instância está em processo de reinicialização com o uso 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.

Quando a atualização de uma instância é concluída, seu campo instanceStatus reflete o estado atual da instância.

Como reverter uma atualização

Não há um comando explícito para reverter uma atualização para uma versão anterior. Porém, se você decidir que quer reverter uma atualização, seja ela permanente ou canário, faça uma nova solicitação de atualização e passe o modelo de instância para o qual você quer reverter.

Por exemplo, o seguinte comando reverte uma atualização o mais rápido possível:

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

Substitua [OLD_INSTANCE_TEMPLATE] pelo nome do modelo de instância antigo para o qual você quer reverter.

Na API, faça uma solicitação PATCH para o seguinte URI:

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Se o grupo de instâncias for um grupo regional de instâncias gerenciadas, substitua zones/[ZONE] por regions/[REGION].

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

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

Se o grupo for de instâncias gerenciadas por região com menos de 10 instâncias, use um valor fixo para maxUnavailable e defina-o como o número de instâncias no grupo:

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "fixed": [NUMBER_OF_INSTANCES_IN_GROUP]
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[OLD_TEMPLATE]" # Old instance template
    }
   ]
}

O serviço Instance Group Updater considera esse comando como uma solicitação de atualização regular para que todas as opções de atualização descritas neste documento possam ser especificadas com a solicitação.

Controle da velocidade de uma atualização

Por padrão, quando você faz uma solicitação de atualização, o serviço realiza a atualização o mais rápido possível. Se você não tiver certeza de que quer aplicar uma atualização completa ou se estiver tentando testar suas alterações, poderá 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 alto para minReadySeconds. Isso faz com que o serviço 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 serviço 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 um valor baixo para maxUnavailable e maxSurge. Isso garante que somente um número mínimo de instâncias seja atualizado de cada vez.
  5. Inicie manualmente as atualizações nas instâncias específicas para atualizá-las de imediato.

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

Interrupção de uma atualização

Não há nenhum método ou comando explícito para interromper uma atualização. Você pode alterar uma atualização de proativa para oportunista. Se o grupo de instâncias gerenciadas não estiver sendo redimensionado por outros serviços, como o autoescalador, a alteração para oportunista efetivamente "interromperá" a atualização.

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

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

Se você decidir que quer interromper completamente a atualização após convertê-la de proativa para oportunista, poderá interrompê-la usando 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 ferramenta gcloud retorna uma resposta com uma lista de instâncias no grupo de instâncias e os status atuais delas:

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

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

  2. Em seguida, faça uma solicitação para realizar uma nova "atualização", mas informe 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=my-old-template \
        --canary-version template=my-new-template,target-size=2 \
        [--zone [ZONE] | --region [REGION]]

    Para o serviço Updater, essa atualização aparece como "concluída". Portanto, nenhuma outra instância é atualizada, o que interrompe efetivamente a atualização.

Relação entre versões e propriedades instanceTemplate para um grupo de instâncias gerenciadas

O Google recomenda usar o campo versions a fim de configurar modelos de instância para grupos de instâncias gerenciadas.

O campo instanceTemplate legado se equipara a versions em termos de funcionalidade, porque ambos os campos permitem especificar qual modelo o grupo de instâncias gerenciadas usará para criar novas instâncias. No entanto, apenas o campo versions permite especificar uma configuração avançada de dois modelos (canário).

Para compatibilidade com versões anteriores, os grupos de instâncias gerenciadas continuam permitindo a configuração do campo instanceTemplate de nível superior. No entanto, é recomendável passar a usar somente o campo versions. O uso dos dois campos ao mesmo tempo pode provocar ambiguidade e confusão.

Se você especificar os dois campos, instanceTemplate e versions, ao chamar o método update() ou patch(), três situações podem ocorrer:

  • Você define ambos os campos para o mesmo valor.

    Essa é uma solicitação válida. Nesse caso, ela não cria ambiguidade e o novo modelo de instância é aplicado ao grupo de instâncias gerenciadas.

    Por exemplo, na solicitação a seguir, os campos instanceTemplate de nível superior e versions especificam o mesmo modelo de instância, que é diferente do modelo existente atualmente. O grupo de instâncias gerenciadas será atualizado para o novo modelo de instância.

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Você define os dois campos não correspondentes, mas apenas um valor é diferente do modelo de instância atual no grupo de instâncias gerenciadas.

    Essa é uma solicitação válida. O campo diferente da configuração atual é assumido como o valor pretendido. Por exemplo, você chama o método get(), altera um dos dois campos e, em seguida, chama update(), com apenas um campo alterado.

    {
     "instanceTemplate": "global/instanceTemplates/current-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Você define os dois campos, mas eles não são correspondentes, têm valores diferentes e são distintos do modelo de instância atual no grupo de instâncias gerenciadas.

    Essa configuração é inválida e retornará um erro por falta de intenção clara.

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/a-different-new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    

Os campos versions e instanceTemplate e o método get()

Se você especificar apenas um modelo de instância, seja por meio do campo instanceTemplate de nível superior, do campo versions ou de ambos, o método get() retornará os dois campos na resposta. Isso faz com que o novo campo versions seja compatível com versões anteriores. Enquanto você especificar um único modelo de instância em cada um desses campos, não haverá alteração no que get() retorna no campo instanceTemplate.

Se o campo versions tiver dois modelos de instância especificados, o método get() retornará um campo instanceTemplate de nível superior vazio. Não há como expressar uma configuração canário de dois modelos de instância sem ambiguidade em um campo instanceTemplate de nível superior, portanto o campo não é usado durante uma atualização canário.

O campo versions e o método setInstanceTemplate()

Para compatibilidade com versões anteriores, o método setInstanceTemplate() se comporta como da maneira anterior, permitindo alterar o modelo usado pelo grupo de instâncias gerenciadas para criar novas instâncias. Ao chamar esse método, o campo versions é modificado com o modelo de instância especificado pelo método setInstanceTemplate().

Além disso, o método define updatePolicy como OPPORTUNISTIC. Isso impede que o grupo de instâncias gerenciadas implante ativamente um modelo de instância que não foi explicitamente especificado no campo versions.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine