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) que são criadas com o uso de 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 Updater do grupo de instâncias gerenciadas permite a implantação de novas versões do software para instâncias nesses grupos e controla a velocidade da implantação, o nível de interrupção 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 qualquer outra entrada do usuário após a solicitação inicial.
  • A possibilidade de fazer lançamentos parciais que permitem teste canary.

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

Início de 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 intent. Quando você faz a solicitação de atualização inicial, a API retorna uma resposta bem-sucedida para confirmar que a solicitação foi 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 implantada com sucesso.

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

  • O Updater tem suporte para até duas versões de modelo de instância em seu 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 canary.

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, clique na lista suspensa e selecione o novo modelo para atualizar.
  5. Para o tamanho de destino, insira 100% para atualizar todas as instâncias.
  6. 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). Também é possível fornecer as opções surto máximo, máximo de opções indisponíveis e 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 desse grupo de instâncias, se o grupo de instâncias for 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:

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.

Sobrecarga máxima

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 o tempo de espera antes de considerar uma instância nova ou reiniciada conforme a atualização. 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 até o período especificado por autohealingPolicies.initialDelaySec para que a verificação de integridade retorne como HEALTHY;
  2. aguarda, na sequência, o período especificado por minReadySeconds.

Se a verificação de integridade não retornar HEALTHY no initialDelaySec, o Updater declarará a instância de VM como não íntegra e possivelmente interromperá a atualização. Enquanto a instância de VM aguarda a confirmação durante os períodos initialDelaySec e minReadySeconds, a currentAction da instância é o 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 de ação mínima para especificar a ação mínima que o Updater precisa realizar para atualizar as instâncias no grupo. Por exemplo, se você definir REPLACE como a ação mínima, todas as instâncias afetadas serão excluídas e substituídas por novas, seja isso necessário ou não.

Definir uma ação mínima garante que o Updater realize-a, no mínimo. No entanto, se o Updater determinar que a ação mínima especificada não é suficiente para realizar a atualização, ele poderá executar uma ação mais disruptiva. Por exemplo, se você definir RESTART como a ação mínima, o Updater tentará reiniciar as instâncias para aplicar a atualização. No entanto, o Updater executa uma ação mais disruptiva se a atualização exigir. Por exemplo, não é possível alterar o SO de uma instância reiniciando-a. Portanto, o Updater substitui as instâncias no respectivo 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 sua solicitação de atualização exigir que a instância seja substituída para capturar as alterações, por exemplo, a alteração da imagem exige que a instância seja excluída e substituída, então o Updater executará uma REPLACE.

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

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

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

Método de substituição

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

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

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

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

Os valores válidos do updater replacementMethod são:

  • substitute (padrão).

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

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

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

Outros exemplos de atualização

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

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

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

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

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

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

Atualizações canary

O Updater permite a execução de atualizações canary 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 canary é aplicada a um número parcial de instâncias no grupo. Com as atualizações canary, você pode testar novos recursos ou upgrades em um subconjunto aleatório de instâncias, em vez de implantar uma atualização potencialmente disruptiva em todas as instâncias. Se uma atualização não está indo bem, você só precisa reverter um pequeno número de instâncias, minimizando a interrupção para os usuários. Do ponto de vista do servidor, uma atualização canary é 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 canary é 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.

Como iniciar uma atualização canary

Para iniciar uma atualização canary, faça o seguinte:

  • Especifique até duas versões do modelo de instância, normalmente um novo modelo para o canary 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 das instâncias continuará em execução no old-instance-template. Não é possível especificar mais de dois modelos de instância por vez.

  • Sempre especifique um tamanho de destino (targetSize) para a versão canary. Não será possível iniciar uma atualização canary se você omitir o tamanho de destino da versão canary. Por exemplo, se você especificou que 10% das instâncias devem ser usadas para atualização canary, 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 canary.
  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 canary 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 ativamente as instâncias) ou oportunista (o grupo não substitui ativamente as instâncias, mas aplica a atualização quando elas são criadas por outros motivos). Também é possível fornecer as opções sobrecarga máxima, máximo de opções indisponíveis e 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-template \
        --canary-version template=new-template,target-size=size \
        [--zone zone | --region region]
    

Substitua:

  • instance-group-name: o nome do grupo para a instância.
  • current-template: o modelo de instância que o grupo de instâncias está executando.
  • new-template: o novo modelo em que você quer fazer a atualização canary;
  • size: o número ou a porcentagem de instâncias às quais 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 dez ou mais instâncias.
  • zone: uma zona para este grupo de instâncias. Se o grupo de instâncias for do tipo zonal, insira a zona.
  • region: uma região para este grupo de instâncias. Se o grupo de instâncias for regional, forneça a região.

Por exemplo, com o comando a seguir, uma atualização canary é 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
    

No payload da solicitação, inclua os modelos de instância atual e novo que você quer fazer a atualização canary. 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"
      }
     ]
    }

Substitua:

  • new-template: o nome do novo modelo em que você quer fazer a atualização canary.
  • number|percentage: o número fixo ou a porcentagem de instâncias para fazer essa atualização canary. Só será possível definir uma porcentagem se o grupo tiver dez ou mais instâncias. Caso contrário, insira um número fixo;
  • current-template: o nome do modelo de instância atual que o grupo de instâncias está executando.

Como avançar uma atualização canary

Depois de executar uma atualização canary, 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 do canary como 100% para implementar o modelo em todas as instâncias. Se preferir, substitua o modelo principal pelo canary 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 canary, 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 da sua solicitação teria a seguinte aparência. Substitua new-template pelo nome do novo modelo de instância que você quer avançar.

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

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 escalonador automático, ou manualmente por um usuário. O Compute Engine não inicia as solicitações ativamente para aplicar as atualizações oportunistas.

Em certos cenários, uma atualização oportunista é útil, porque instabilidade no sistema é algo que se deve evitar. 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. 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 canary. 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 automaticamente;
  • aplicar a reinicialização ou a recriação da instância, mesmo que essas ações não sejam necessárias para aplicar a atualização. Por exemplo, talvez você queira reiniciar uma VM mesmo se estiver atualizando apenas os metadados dela, porque o software convidado precisa coletar os novos metadados na 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 usando a ferramenta gcloud ou a API.

gcloud

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

gcloud 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 regionInstanceGroupManagers.applyUpdatesToInstances. Para um grupo de instâncias gerenciadas por zona, use o método instanceGroupManagers.applyUpdatesToInstances por zona.

POST https://compute.googleapis.com/compute/v1/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. Se a operação falhar, 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 só 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, é possível atualizar as 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.

Você pode usar o Console do Google Cloud, a ferramenta de linha de comando gcloud ou a API para realizar 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, você poderá especificar uma reinicialização contínua, que não exclui instâncias, apenas reinicia todas as instâncias.

    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/my-project/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]

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

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

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

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

Como preservar nomes de instância

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

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

Especifique o método de substituição usando a ferramenta de linha de comando gcloud ou a API.

gcloud

Ao emitir um comando rolling-action, inclua --replacement-method=recreate.

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

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

Crie uma solicitação para o método patch do grupo de instâncias gerenciadas e inclua o campo updatePolicy.replacementMethod. Para um MIG regional, use o método patch regional.

PATCH /compute/v1/projects/project/zones/zone/instanceGroupManagers/instance-group-name
    {
        "updatePolicy": {
            "type": "PROACTIVE",
            "maxUnavailable": { "fixed": 5 },
            "replacementMethod": "RECREATE"
        },
        "versions": [ {
            "instanceTemplate": "global/instanceTemplates/new-template"
        } ]
    }

Atualizar um grupo de instâncias regionais gerenciado

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.

Atualizar um grupo de instâncias gerenciadas regional usando o 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 grupos de instâncias gerenciadas por região são maxUnavailable=number-of-zones e maxSurge=number-of-zones, onde number-of-zones é o número de zonas selecionados 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 0 ou iguais ou maiores que o número de zonas associadas ao grupo regional de instâncias gerenciadas. Por exemplo, se o grupo de instâncias estiver distribuído entre três zonas, não será possível definir maxSurge como 1 ou como 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 pelo número de zonas no grupo regional de instâncias gerenciadas 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 canary.

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 canary, 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 zonais de instâncias gerenciadas se aplicam 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 (links 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

Para verificar se a atualização do grupo de instâncias foi concluída, use o comando describe para verificar status.versionTarget.isReached==true. Para verificar se todas as instâncias no grupo estão em execução e íntegras, ou seja, a currentAction de cada instância gerenciada é NONE, verifique status.isStable==true.

A estabilidade de um grupo de instâncias gerenciadas depende das configurações do grupo, não apenas do Updater. Por exemplo, se o grupo for escalonado automaticamente e estiver no processo de escalonamento vertical, isStable==false por causa da operação do escalonador automático.

gcloud 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 compute instance-groups managed wait-until (em inglês) com a sinalização --version-target-reached para aguardar que status.versionTarget.isReached seja definido como true no grupo:

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

API

Para verificar se sua atualização para o grupo de instâncias foi implementada, use o método do administrador do grupo de instâncias get para verificar status.versionTarget.isReached==true. Para verificar se todas as instâncias no grupo estão em execução e íntegras, ou seja, a currentAction de cada instância gerenciada é NONE, verifique status.isStable==true.

A estabilidade de um grupo de instâncias gerenciadas depende das configurações do grupo, não apenas do Updater. Por exemplo, se o grupo for escalonado automaticamente e estiver no processo de escalonamento vertical, isStable==false por causa da operação do escalonador automático.

GET https://compute.googleapis.com/compute/v1/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

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.

Confirme se o lançamento de uma atualização foi concluído consultando 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 usa a versão de destino (versions[]). Ou, no caso de uma atualização canary, 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).

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. 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 escalonador automático 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 regional, algumas das instâncias estão sendo redistribuídas.

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

Ações atuais nas instâncias

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

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. 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  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 zonais, use o método instanceGroupManagers.listManagedInstances.

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 está 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 ser igual ou diferente dos pools de destino atuais.
  • RESTARTING: a instância está em processo de reinicialização por meio dos métodos stop e start.
  • VERIFYING: a instância foi criada e está em processo de verificação.
  • NONE: nenhuma ação está sendo executada na instância.

Como reverter uma atualização

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

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

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

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 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 Updater trata isso como uma solicitação de atualização regular. Portanto, todas as opções de atualização descritas neste documento podem ser especificadas com sua 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 você 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 canary 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 atualização da instância bem-sucedida 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 escalonador automático, 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 que inclui uma lista de instâncias no grupo de instâncias e seus status atuais:

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

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

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

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

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

Relação entre versões e propriedades do 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 à funcionalidade com versions porque ambos os campos permitem que você especifique qual modelo de instância o grupo de instâncias gerenciado usa para criar instâncias. No entanto, somente o campo versions permite especificar uma configuração avançada de dois modelos (canary).

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 o campo instanceTemplate e o campo versions ao chamar o método update() ou patch(), há três resultados possíveis:

  • 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, os campos de nível superior instanceTemplate e versions especificam o mesmo modelo de instância que é diferente do modelo atual. Portanto, o grupo de instâncias gerenciadas é atualizado para o novo modelo de instância:

        {
         "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 é inválida e retorna um erro, porque não há uma intent 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 do canary de duas instâncias no campo instanceTemplate de nível superior. Portanto, o campo não é usado durante uma atualização do canary.

O campo versions e o método setInstanceTemplate()

Para compatibilidade com versões anteriores, o método setInstanceTemplate() se comporta como antes, permitindo alterar o modelo que o grupo de instâncias gerenciadas usa para criar 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