Como atualizar instâncias em um MIG

Este documento ajuda a decidir como aplicar atualizações de configuração por instância e de modelo de instância às instâncias de máquina virtual (VM, na sigla em inglês) em um grupo gerenciado de instâncias (MIG, na sigla em inglês).

É possível atualizar o modelo de instância de um MIG pelos seguintes motivos:

  • Para atualizar o aplicativo ou o sistema operacional em cada instância.
  • Para realizar um teste A/B para comparar versões diferentes do mesmo aplicativo.
  • Para executar uma atualização canário para minimizar a interrupção ao testar uma nova versão.
  • Para alterar outras especificações das instâncias no MIG, como o tipo de máquina ou as opções de disco.

Aplique uma nova versão de um modelo de instância usando um dos seguintes métodos:

  • Atualização gradual automatizada. O MIG lança automaticamente uma nova versão de um modelo de instância para todas as instâncias ou para um subconjunto aleatório de instâncias gerenciadas no MIG. O escopo da atualização e o nível de interrupção dependem da política de atualização configurada.
  • Atualização seletiva de instâncias específicas. É possível segmentar especificamente as instâncias selecionadas para uma atualização. Use esse método para MIGs com estado ou se quiser orquestrar a atualização manualmente.

Se você tiver um MIG com estado, também poderá usar uma atualização seletiva para aplicar as alterações feitas às configurações por instância.

Se você só precisar redimensionar um MIG, consulte a documentação sobre como adicionar ou remover instâncias em um MIG.

Limitações

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

Como escolher entre atualizações automáticas e seletivas

Para implantar automaticamente um novo modelo para todas as instâncias ou para um subconjunto das instâncias em um MIG sem estado, defina o tipo de atualização do MIG como PROACTIVE. Se você tiver um MIG com estado ou se uma atualização automatizada for potencialmente muito disruptiva, defina o tipo de atualização do MIG como OPPORTUNISTIC e atualize seletivamente instâncias específicas.

Atualizações proativas e automáticas

Definir o tipo de atualização do MIG como PROACTIVE oferece duas vantagens principais:

  • O lançamento de uma atualização acontece automaticamente de acordo com suas especificações, sem a necessidade de contribuição adicional após a solicitação inicial. Você pode especificar a velocidade da implantação, o nível de interrupção do serviço e o escopo da atualização.
  • É possível fazer lançamentos parciais que permitem teste canário.

Quando você inicia uma atualização gradual proativa, o MIG programa ativamente ações para aplicar as atualizações solicitadas às instâncias, conforme necessário. Em muitos casos, isso significa excluir e recriar instâncias proativamente.

Para mais informações, consulte Como implantar atualizações automaticamente para instâncias em um MIG.

Atualizações seletivas

A atualização seletiva de instâncias específicas oferece as seguintes vantagens:

  • É possível selecionar as instâncias que você quer atualizar.
  • É possível uma atualização com a menor quantidade de interrupção necessária para que a atualização 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. Por padrão, a ação mínima necessária é executada de maneira automática.
  • É possível aplicar 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, 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.
  • É possível impedir uma atualização, se ela exigir mais interrupção do que você consegue sustentar.

Para evitar que uma atualização proativa concorra com suas atualizações seletivas, defina o tipo de atualização do MIG como OPPORTUNISTIC.

Atualizações oportunistas

Quando o tipo de atualização é definido como OPPORTUNISTIC, o MIG aplica atualizações somente quando você aplica a atualização a instâncias específicas ou quando novas instâncias são criadas pelo MIG. Um MIG cria novas instâncias quando ele é redimensionado para adicionar instâncias, de modo automático ou manual. 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 MIG que esteja sendo ativamente autoescalonado, realize uma atualização oportunista para que o Compute Engine não elimine as instâncias atuais para aplicar a atualização. Ao redimensionar para menos, o escalonador automático encerra preferencialmente instâncias com o modelo antigo, assim como instâncias que ainda não estão no estado RUNNING.

Para mais informações, consulte Como atualizar seletivamente instâncias em um MIG.

Como configurar uma atualização oportunista ou proativa

Por padrão, as atualizações iniciadas usando o Console do Cloud ou a ferramenta de linha de comando gcloud são proativas, o que significa que elas começam automaticamente, e as atualizações iniciadas usando a API Compute Engine são oportunistas, o que significa que o MIG não aplica proativamente o novo modelo às instâncias atuais.

Para escolher se uma atualização é oportunista ou proativa, defina o modo como oportunista ou proativa usando o Console do Cloud, a ferramenta de linha de comando gcloud ou a API Compute Engine.

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 MIG que você quer atualizar.

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

  4. Em Modo de atualização, escolha entre uma atualização oportunista ou proativa.

gcloud

Use o comando rolling-action start-update e defina a sinalização --type como opportunistic ou proactive.

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

API

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

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

{
  "updatePolicy": {
    "type": "TYPE" # Choose an opportunistic or proactive update
  },
  "versions": [{
    "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
    }]
}

Substitua:

  • NEW_TEMPLATE: o nome do novo modelo do grupo
  • TYPE: o tipo de atualização, OPPORTUNISTIC ou PROACTIVE

Para saber mais sobre como configurar um novo modelo e aplicá-lo a instâncias novas e atuais em um MIG, consulte as seguintes páginas:

Relação entre campos versions e instanceTemplate

Se você usa a API Compute Engine, recomendamos usar os campos instanceGroupManagers.versions e regionInstanceGroupManagers.versions para configurar modelos de instância para MIGs zonais e regionais.

O campo legado instanceTemplate se sobrepõe à funcionalidade com o campo versions porque ambos os campos permitem que você especifique qual modelo de instância o MIG usa para criar 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 MIGs ainda são compatíveis com 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. Nesse caso, ele não gera ambiguidade e o novo modelo de instância é aplicado ao MIG.

    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 MIG é 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 MIG.

    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 update() e fornece os dois campos, mas apenas um campo é atualizado:

    {
     "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 MIG.

    Esta 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 que o método get() retorna 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 anteriormente, permitindo alterar o modelo usado pelo MIG para criar instâncias. Quando você chama este 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 MIG implante ativamente um modelo de instância que não esteja explicitamente especificado no campo versions.

A seguir