Como lançar atualizações para MIGs

Um grupo de instâncias gerenciadas (MIG, na sigla em inglês) contém uma ou mais instâncias de máquina virtual (VM, na sigla em inglês) que são criadas por um modelo de instância. Para atualizar as instâncias em um MIG, faça solicitações de atualização para o grupo como um todo, usando o recurso MIG Updater.

O Managed Instance Group Updater ajuda a implantar novas versões do software em instâncias nos grupos de instâncias gerenciadas e controla a velocidade da implantação, o nível de interrupção de 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 qualquer outra entrada do usuário após a solicitação inicial.
  • É possível fazer lançamentos parciais, o que permite testes.

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 gradual é aplicada 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 gradual, como quantas instâncias podem ficar off-line para a atualização, quanto tempo esperar entre atualizações de instâncias, se a atualização afeta todas as instâncias ou apenas uma parte delas e assim por diante.

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

  • As atualizações são baseadas em 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 foi válida, mas 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 implantada.

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

  • O recurso Updater é compatível com até duas versões de modelo de instância no grupo de instâncias gerenciadas. Desse modo, é 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. No Console do Cloud, acesse a página Grupos de instâncias.

    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, expanda a lista suspensa e selecione o novo modelo que será usado para atualização.
  5. Em "Tamanho do destino", insira 100% para atualizar todas as instâncias.
  6. Se preferir, alterne as opções de configuração, por exemplo, se a atualização é proativa (o grupo substitui as 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 informar o surto máximo, o máximo de opções indisponíveis e o tempo de espera mínimo.
  7. Clique em Atualizar para iniciar a atualização.

gcloud

Com a ferramenta de linha de comando gcloud, execute o comando rolling-action start-update:

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=instance-template-name
    [--zone zone | --region region]

Substitua:

  • instance-group-name o nome do grupo de instâncias a ser atualizado;
  • instance-template-name o novo modelo de instância a ser usado para atualizar o grupo;
  • zone: a zona para esse grupo de instâncias, se o grupo de instâncias for um grupo de instâncias por zona.
  • region: a região desse grupo de instâncias, se o grupo de instâncias for regional.

API

Na API, faça uma solicitação PATCH ao recurso gerenciador de grupos de instância:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

Se o grupo for de instâncias gerenciadas por região, substitua zones/zone por regions/region.

O payload da solicitação contém os seguintes itens:

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 usarão o padrão 1 (um) multiplicado pelo número de zonas afetadas. Isso significa que o Updater cria apenas uma instância não disponível em cada zona afetada e somente uma instância 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, é possível monitorar a atualização para saber quando ela foi concluída.

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

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

Surto máximo

Defina a propriedade maxSurge para permitir que o Updater crie temporariamente novas instâncias acima de targetSize durante a atualização. Por exemplo, se você definir maxSurge como 5, o grupo de instâncias gerenciadas usará o novo modelo para criar até cinco novas instâncias acima do tamanho de destino. Se um valor maior de maxSurge for definido, a atualização será acelerada ao custo de mais instâncias, que serão cobradas de acordo com a tabela de preços do Compute Engine.

Se você não definir o valor de maxSurge, o 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 é o número de zonas associadas ao grupo.

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

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

Máximo indisponível

Defina a configuração maxUnavailable para que apenas um determinado número de instâncias fique indisponível a qualquer momento durante a atualização. Por exemplo, se você definir maxUnavailable como 5, apenas cinco instâncias de cada vez serão colocadas off-line para atualização. Utilize esse parâmetro para controlar o nível de interrupção da atualização para o serviço e a velocidade da implantação da atualização.

Esse número também inclui todas as instâncias que não estão disponíveis por outros motivos. Por exemplo, se o grupo de instâncias estiver no processo de redimensionamento, as instâncias no meio da criação talvez não estejam disponíveis. Essas instâncias são incluídas no número maxUnavailable. Especifique um número fixo ou, se o grupo de instâncias gerenciadas tiver dez ou mais instâncias, uma porcentagem. Se você definir uma porcentagem, o Updater arredondará o número de instâncias para baixo, se necessário.

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 de number-of-zones (o número de zonas selecionadas) é 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 velocidade em que a atualização é implantada. O timer é iniciado quando ocorrem as duas condições a seguir:

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

  1. aguarda o período especificado por autohealingPolicies.initialDelaySec para que a verificação de integridade retorne HEALTHY;
  2. aguarda, na sequência, 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 poderá interromper a atualização. Enquanto a instância de VM aguarda a confirmação durante os períodos 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 da propriedade minReadySeconds é de 3.600 segundos (uma 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. Desse modo, 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). Se a solicitação de atualização exigir que a instância seja substituída para capturar as alterações (por exemplo, a alteração da imagem requer que a instância seja excluída e substituída), ela será forçada a executar REPLACE.

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

No diagrama a seguir, mostramos como essas opções afetam as instâncias.

Como as opções do Updater afetam a solicitação.

Outros exemplos de atualização

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

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

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    --max-surge 5 \
    [--zone zone | --region region]

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

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    --min-ready 3m \
    --max-unavailable 3 \
    [--zone zone | --region region]

Por exemplo, se você tiver 1.000 instâncias e executar esse comando, o Updater criará até 100 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 VM, mas criar até 10% de novas instâncias de cada vez acima do tamanho de destino

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    --max-surge 10% \
    [--zone zone | --region region]

Como iniciar uma atualização canário

O Updater permite a execução de atualizações canário para que você faça o teste delas em um subconjunto aleatório de instâncias antes de confirmar totalmente 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 tiver algum problema, será possível 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 gradual padrão, exceto pelo número de instâncias que precisam ser atualizadas que é menor que o tamanho total do grupo. Como uma atualização gradual 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 e o restante delas continue sendo executado em old-instance-template. Não é possível especificar mais de dois modelos de instância por vez.

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

Console

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

    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. 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 a atualização canário do novo modelo de instância.
  6. Se preferir, alterne as opções de configuração. Por exemplo, se a atualização é proativa (o grupo exclui e substitui as instâncias ativamente) ou oportunista (o grupo não substitui as instâncias, mas aplica a atualização quando elas são criadas por outros motivos). É possível também informar o surto máximo, o máximo de opções indisponíveis e o tempo de espera mínimo.
  7. Clique em Atualizar para iniciar a atualização.

gcloud

Com a ferramenta de linha de comando gcloud, insira o modelo atual e o novo para expressar explicitamente quantas instâncias devem usar cada modelo:

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=current-instance-template \
    --canary-version template=new-template,target-size=size \
    [--zone zone | --region region]

Substitua:

  • current-instance-template: o modelo atual que o grupo de instâncias está executando;
  • new-template: o novo modelo em que você quer fazer a atualização canário;
  • size: o número ou a porcentagem de instâncias a 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;
  • zone: a zona para esse grupo de instâncias, se o grupo de instâncias for um grupo de instâncias por zona.
  • region: a região desse grupo de instâncias, se o grupo de instâncias for regional.

Por exemplo, com o comando a seguir, uma atualização canário é executada para implantar my-template-b em 10% das instâncias no grupo:

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 ao recurso gerenciador de grupos de instância:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

O payload da solicitação deve conter o modelo de instância atual e o novo em que você quer fazer a atualização canário. Exemplo:

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

Substitua:

  • new-template: o nome do novo modelo em que você quer fazer a atualização canário.
  • number|percentage: o número fixo ou a porcentagem de instâncias para fazer essa atualização canário. Somente será possível definir uma porcentagem se o grupo tiver dez ou mais instâncias. Caso contrário, insira um número fixo;
  • current-instance-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, decida se quer confirmar a atualização como 100% do grupo de instâncias ou revertê-la.

Console

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

    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

Se você quer confirmar a atualização canário, avance-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 ao recurso gerenciador de grupos de instância:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

No corpo da solicitação, especifique o novo modelo de instância como version e omita o modelo anterior. Omita a especificação do tamanho de destino para implantar a atualização em 100% das instâncias. Por exemplo, o corpo de solicitação tem a seguinte aparência:

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

Substitua new-template pelo nome do novo modelo de instância que você quer avançar.

Como iniciar uma atualização oportunista ou proativa

Por padrão, as atualizações feitas com 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 é aplicada apenas 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 que está sendo ativamente autoescalonado, realize uma atualização oportunista para que o Compute Engine não desmonte ativamente as instâncias atuais para aplicar a atualização. Ao redimensionar para baixo, o escalonador automático encerra preferencialmente instâncias com o modelo antigo, assim como instâncias que ainda não são RUNNING.

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

Console

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

    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

No payload da solicitação para iniciar uma atualização, inclua a propriedade type em updatePolicy. Substitua new-template pelo nome do novo modelo em que você quer fazer a atualização canário. Para uma atualização oportunista, substitua PROACTIVE por OPPORTUNISTIC.

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

Como atualizar instâncias selecionadas

Ao iniciar uma atualização oportunista, você precisa aguardar o Compute Engine lançar 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.

A inicialização manual de atualizações permite a você:

  • selecionar as instâncias que 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 interrupção do que você consegue sustentar;
  • executar uma atualização de todas as instâncias selecionadas imediatamente, sem restringir o lançamento a 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.

Controle o nível de interrupção usando as sinalizações minimal-action e most-disruptive-allowed-action:

  • minimal-action permite que você force uma ação mais disruptiva do que o necessário.
  • most-disruptive-allowed-action permite que você evite uma atualização, se ela exigir mais interrupção 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, 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, most-disruptive-allowed-action é REPLACE. Se a atualização exigir uma ação mais disruptiva do que a definida por essa sinalização, a solicitação de atualização falhará. 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 (em inglês) para aplicá-la às instâncias específicas.

gcloud beta compute instance-groups managed update-instances instance-group-name \
    --instances instance-names \
    --most-disruptive-allowed-action disruption-level \
    --minimal-action disruption-level

Em que:

  • instance-group-name é 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 interrupção. Os valores podem ser NONE, REFRESH, RESTART ou REPLACE;
    • o minimal-action padrão é NONE.
    • o 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 (em inglês). Para um grupo de instâncias gerenciadas por zona, use o método instanceGroupManagers.applyUpdatesToInstances (em inglês) por zona.

POST https://compute.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 interrupção. Os valores podem ser NONE, REFRESH, RESTART ou REPLACE;
    • o minimalAction padrão é NONE.
    • o mostDisruptiveAllowedAction padrão é REPLACE.

Semelhante a outros métodos de grupo de instâncias gerenciadas, applyUpdatesToInstances é baseado em intenções, o que significa que retorna uma resposta de operação. Depois que a operação for DONE, listManagedInstances (em inglês) incluirá a lista de instâncias com os respectivos campos currentAction alterados para REFRESHING, RESTARTING ou RECREATING. Em caso de falha na operação, por exemplo, devido a alterações simultâneas no grupo, a falha será registrada 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

Se preferir, use os comandos restart ou replace para executar uma reinicialização ou substituição gradual das instâncias de VM no grupo de instâncias gerenciadas. Semelhante ao comando start-update, é possível especificar qualquer uma das opções de configuração para a reinicialização ou substituição. Uma reinicialização ou substituição gradual não altera nada no grupo de instâncias, nem o modelo. Ela simplesmente atualiza as instâncias no grupo usando o método escolhido.

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

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

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

Console

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

    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 gradual.
  4. Escolha se instâncias serão reiniciadas ou substituídas. A reinicialização executa os métodos stop e start (ambos em inglês) nas instâncias, enquanto uma substituição exclui e cria instâncias ativamente.
  5. Se preferir, alterne as opções de configuração, como surto máximo, máximo de opções indisponíveis e tempo de espera mínimo.
  6. Clique no botão Reiniciar ou Substituir para iniciar a atualização.

gcloud

gcloud compute instance-groups managed rolling-action replace instance-group-name

Esse comando substitui todas as instâncias nos grupos de instâncias gerenciadas, uma por vez. Se uma substituição completa for muito disruptiva, especifique uma reinicialização gradual, que não exclui as instâncias, apenas reinicia cada uma.

gcloud compute instance-groups managed rolling-action restart instance-group-name

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

API

Na API, faça uma solicitação PATCH para o grupo e defina uma updatePolicy proativa, em que minimalAction é RESTART ou REPLACE, dependendo da sua opção por executar uma substituição gradual, em que cada instância é excluída e substituída por uma nova, ou uma reinicialização gradual, em que cada instância é interrompida e reiniciada. Tanto no caso de RESTART quanto de REPLACE, sempre especifique um versions.instanceTemplate e uma propriedade versions.name (por exemplo, v2) para acionar a ação.

Uma substituição gradual tem a seguinte aparência:

PATCH https://compute.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://compute.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

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

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

gcloud compute instance-groups managed rolling-action restart instance-group-name \
    --max-unavailable 2 [--zone zone | --region region]

Reinicialização gradual de todas as VMs o mais rápido possível

gcloud compute instance-groups managed rolling-action restart instance-group-name \
    --max-unavailable 100% [--zone zone | --region region]

Substituição gradual de todas as VMs o mais rápido possível

gcloud compute instance-groups managed rolling-action replace instance-group-name  \
    --max-unavailable 100% [--zone zone | --region region]

Como atualizar um grupo de instâncias gerenciadas por região

Um grupo de instâncias gerenciadas por região contém instâncias de VM espalhadas por várias zonas em uma região. Ao contrário de um grupo de instâncias gerenciadas por zona, que contém apenas instâncias em uma zona. Os grupos de instâncias gerenciadas por região permitem distribuir as instâncias por mais de uma zona para melhorar a disponibilidade do app e oferecer suporte a casos extremos em que uma zona falha ou um grupo inteiro de instâncias para de responder.

A atualização de um grupo de instâncias gerenciadas por região usando o recurso Updater é o mesmo que realizar uma atualização em um grupo de instâncias gerenciadas por zona, com algumas exceções descritas abaixo. 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 atualização de grupo de instâncias gerenciadas por região e por zona

Antes de iniciar uma atualização para um grupo de instâncias gerenciadas por região, saiba que há vários elementos que apresentam comportamentos diferentes dos grupos de instâncias gerenciadas por zona:

  • Os parâmetros de atualização padrão para os grupos de instâncias gerenciadas por região são maxUnavailable=[NUMBER_OF_ZONES] e maxSurge=[NUMBER_OF_ZONES], em que [NUMBER_OF_ZONES] é o número de zonas selecionadas para o grupo de instâncias gerenciadas por região. O 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 de instâncias foi distribuído em três zonas, não é possível definir maxSurge como 1 nem como 2, porque o Updater precisa criar uma outra instância 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, ele é dividido pelo número 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á dez pelo número de zonas na região e criará as instâncias com base nesse número. Se o número de instâncias não for dividido uniformemente entre as zonas, o Updater adicionará as instâncias a uma zona aleatória. Portanto, para dez instâncias em três zonas, duas zonas recebem três instâncias e uma recebe quatro instâncias. A mesma lógica é aplicada aos parâmetros maxUnavailable e targetSize para atualizações canário.

Uma porcentagem só pode ser especificada se o grupo de instâncias gerenciadas contém dez ou mais instâncias de VM. As porcentagens são processadas de maneira um pouco diferente dependendo da situação:

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

  • Se você especificar uma porcentagem para as opções de atualização, como maxSurge e maxUnavailable, as porcentagens serão arredondadas de forma independente por zona. As mesmas regras que se aplicam à atualização de grupos de instâncias gerenciadas por zona são aplicadas aqui.

Como monitorar as atualizações

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

Status do grupo

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

Console

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

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

    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.

Na página Detalhes, é exibido o número atual e planejado das instâncias que estão sendo atualizadas para cada modelo, e também os parâmetros de atualização.

gcloud

Use o comando describe:

gcloud beta compute instance-groups managed describe instance-group-name \
    [--zone zone | --region zone]

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

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

gcloud beta compute instance-groups managed wait-until instance-group-name \
    --version-target-reached \
    [--zone zone | --region region]

API

Use o método do gerenciador do grupo de instâncias get:

GET https://compute.googleapis.com/compute/beta/projects/project-d/zones/zone/instanceGroupManagers/instance-group-name/get

Se o grupo for de instâncias gerenciadas por região, substitua regiões zones/<var>zone</var></code> with/região.

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

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

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.

É possível verificar se o lançamento de uma atualização está completo verificando o valor do campo status.versionTarget.isReached:

  • 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[]). No caso de uma atualização canário, é 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).

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

É possível verificar se um grupo de instâncias gerenciadas está íntegro e em execução ao conferir o valor do campo status.isStable.

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 o seguinte:

  • Nenhuma das instâncias no grupo de instâncias gerenciadas está passando por qualquer tipo de alteração e o 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. 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 estão sendo 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.

Ações atuais nas instâncias

É possível ver o currentAction sendo realizado e os status de cada instância em um grupo de instâncias gerenciadas com 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 e os respectivos status e ações atuais. 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  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

API

Na API, faça uma solicitação GET para o método regionInstanceGroupManagers.listManagedInstances . Para um grupo de instâncias gerenciadas por zona, use o método instanceGroupManagers.listManagedInstances (em inglês).

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

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

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.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 respectivo status é descrito no campo instanceStatus. 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 será preenchido com uma das seguintes ações para ajudar você a acompanhar o andamento da alteração. Caso contrário, o campo currentAction será NONE.

Os valores possíveis de currentAction são:

  • ABANDONING: a instância está sendo removida do 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 está sendo substituída.
  • REFRESHING: a instância está sendo removida e adicionada novamente à lista de pools de destino atuais (essa lista pode corresponder ou não aos pools de destino atuais);
  • RESTARTING: a instância está em processo de reinicialização por meio dos métodos stop e start;
  • VERIFYING: a instância foi criada e está em processo de verificação;
  • NONE: nenhuma ação está sendo executada na instância.

Como reverter uma atualização

Não há um comando explícito para reverter uma atualização a uma versão anterior, mas se você decidir revertê-la (seja ela totalmente confirmada ou canário), faça uma nova solicitação de atualização e insira o modelo de instância ao qual 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-name --max-unavailable 100% [--zone zone | --region region]

Substitua old-instance-template-name pelo nome do modelo de instância ao qual você quer reverter.

Na API, faça uma solicitação PATCH ao recurso gerenciador de grupos de instância:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

Se o grupo for de instâncias gerenciadas por região, substitua zones/zone por regions/region.

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

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

Se ele for um grupo de instâncias gerenciadas por região com menos de dez instâncias, use um valor fixo de 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 Updater considera esse comando como uma solicitação de atualização normal 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. Caso não tenha certeza se quer aplicar uma atualização integralmente ou se estiver apenas testando as alterações, controle a velocidade da atualização usando os métodos a seguir.

  1. Inicie uma atualização canário em vez de uma atualização completa.
  2. Defina um valor minReadySeconds alto. 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 app e emita um sinal de estado íntegro antes de considerar a instância atualizada e avançar para a próxima.
  4. Defina valores maxUnavailable e maxSurge baixos. Isso garante que somente um número mínimo de instâncias seja atualizado de cada vez.
  5. 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 velocidade da atualização.

Como parar uma atualização

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

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

gcloud compute instance-groups managed rolling-action stop-proactive-update instance-group-name \
    [--zone zone | --region region]

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

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

    gcloud compute instance-groups managed list-instances instance-group-name \
        [--zone zone | --region region]

    A ferramenta gcloud retorna uma resposta com uma lista de instâncias no grupo e os respectivos status atuais:

    >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 o uso do campo versions para configurar modelos de instância em grupos de instâncias gerenciadas.

O campo legado instanceTemplate se sobrepõe ao versions em termos de funcionalidade porque os dois permitem especificar qual modelo o grupo de instâncias gerenciadas usará para criar novas instâncias. No entanto, somente 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 aceitando a configuração do campo instanceTemplate de nível superior, embora seja recomendável passar a usar apenas o campo versions. O uso do campo instanceTemplate de nível superior e do campo versions ao mesmo tempo pode gerar ambiguidade e confusão.

Se você especificar ambos os campos instanceTemplate e versions ao chamar o método update() ou patch(), haverá três possíveis situações:

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

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

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

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
  • Você define ambos os campos com valores que não correspondem, 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 que é diferente da configuração atual é usado 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 ambos os campos com valores que não correspondem, e os dois valores são diferentes do modelo de instância atual no grupo de instâncias gerenciadas.

    Essa configuração não é válida e retorna um erro porque não há uma 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 somente 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 torna o novo campo versions compatível com versões anteriores. Desde que você especifique um modelo de instância único em um desses campos, não haverá alteração no valor de get() retornado no campo instanceTemplate.

Se forem especificados dois modelos de instância no campo versions, o método get() retornará um campo instanceTemplate de nível superior vazio. Não há como expressar sem ambiguidade uma configuração de modelo canário de duas instâncias no 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 antes, permitindo que você altere o modelo que o grupo de instâncias gerenciadas usa para criar novas instâncias. Quando você chama esse método, o campo versions é substituído pelo modelo de instância especificado pelo método setInstanceTemplate().

O método setInstanceTemplate() também define a updatePolicy como OPPORTUNISTIC. Isso impede que o grupo de instâncias gerenciadas implante ativamente um modelo que não seja explicitamente especificado no campo versions.

A seguir