Aplique novas configurações de VM num MIG

Esta página explica como pode configurar as instâncias de máquinas virtuais (VMs) num grupo de instâncias geridas (GIG) e os métodos que pode usar para aplicar a configuração às VMs existentes no grupo.

Especifica a configuração pretendida para as VMs num MIG através dos seguintes componentes de configuração de VM:

  • Obrigatório: modelo de instância
  • Opcional: configuração de todas as instâncias
  • Opcional: configuração com estado

Sempre que atualiza a configuração pretendida através desses componentes, o Compute Engine aplica automaticamente a configuração atualizada às novas VMs que são adicionadas ao grupo.

Para aplicar uma configuração atualizada a VMs existentes, use os métodos descritos nesta página:

  • Implementações automáticas com um orçamento de interrupção e atualizações opcionais de teste de novos modelos
  • Atualizações manuais seletivas apenas a VMs específicas para minimizar a interrupção
  • Recriação de VMs específicas

Também pode configurar o MIG para aplicar a configuração mais recente disponível às VMs durante as reparações de VMs. Para mais informações, consulte o artigo Aplique atualizações de configuração durante as reparações.

Se só precisar de redimensionar um MIG, consulte a documentação sobre como adicionar ou remover VMs num MIG. Se quiser saber como configurar funcionalidades dos GIGs, consulte a documentação sobre a escala automática, autorreparação, balanceamento de carga> e cargas de trabalho com estado.

Antes de começar

  • Se ainda não o tiver feito, configure a autenticação. A autenticação valida a sua identidade para aceder a Google Cloud serviços e APIs. Para executar código ou exemplos a partir de um ambiente de desenvolvimento local, pode autenticar-se no Compute Engine selecionando uma das seguintes opções:

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

    Console

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

    gcloud

    1. Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

    2. Set a default region and zone.

    REST

    Para usar os exemplos da API REST nesta página num ambiente de desenvolvimento local, usa as credenciais que fornece à CLI gcloud.

      Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

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

Componentes de configuração para VMs num MIG

Configura as VMs num MIG através dos seguintes componentes:

ComponentePropriedadesExemplo de utilização
Modelo de instância Tipo de máquina, imagem do disco de arranque, etiquetas, script de arranque e outras propriedades da VM Obrigatório: use um modelo de instância para definir as propriedades de instância obrigatórias e opcionais para todas as VMs no grupo.

Opcional: se quiser testar uma segunda configuração de VM com testes canários, pode adicionar um segundo modelo de instância ao grupo e aplicá-lo a um subconjunto das VMs no grupo.
Configuração de todas as instâncias Etiquetas e metadados Opcional: use uma configuração de todas as instâncias para substituir rapidamente as propriedades do modelo de instância para todas as VMs no grupo.
Configuração com estado Discos com estado, endereços IP e metadados Opcional: se precisar de suportar uma carga de trabalho com estado, adicione uma configuração com estado às VMs no grupo.

Se atualizar qualquer configuração do grupo através desses componentes, tem de aplicar a configuração atualizada às VMs existentes no grupo para que a configuração atualizada entre em vigor.

Métodos para aplicar uma nova configuração a VMs existentes

Depois de atualizar a configuração de VM de um MIG, pode aplicar a nova configuração às VMs existentes no grupo através dos seguintes métodos:

  • Automático (proativo): use este método se quiser que o GIG aplique automaticamente novas configurações a todas ou a um subconjunto de VMs existentes no grupo. O nível de interrupção das VMs em execução depende da política de atualização que configurar. Pode usar este método para atualizar o teste beta de novos modelos de instância. Para usar este método, defina o tipo de atualização do MIG como "proativo".
  • Seletiva (oportunista): use este método se quiser aplicar a atualização manualmente ou se quiser atualizar todas as VMs existentes no grupo de uma só vez. Segmenta qualquer VM ou todas as VMs para serem atualizadas para a configuração mais recente. Para usar este método, defina o tipo de atualização do MIG como "oportunista".
  • Recriação de VMs: aplique novas configurações recriando VMs específicas.

Para mais informações sobre como definir o tipo de atualização de um MIG, consulte o artigo Configure uma atualização proativa ou oportuna.

Automático (proativo)

Um tipo de atualização automática também é conhecido como um tipo de atualização proativa. Quando define o tipo de atualização do GIG como proativo, o GIG aplica automaticamente as configurações atualizadas às VMs conforme necessário.

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

  • A implementação de uma atualização ocorre automaticamente de acordo com as suas especificações, sem necessidade de introdução adicional após o pedido inicial. Pode especificar a velocidade de implementação, o nível de interrupção do seu serviço e o âmbito da atualização.
  • Pode automatizar implementações parciais, o que permite testes.

Para saber como definir o tipo de atualização do MIG, consulte o artigo Configure uma atualização proativa ou oportuna.

Para mais informações sobre implementações automáticas, consulte o artigo Aplique automaticamente atualizações de configuração de VMs num MIG.

Seletiva (oportunista)

Um tipo de atualização seletiva também é conhecido como um tipo de atualização oportunista. Quando define o tipo de atualização do GIG como oportunista, o GIG aplica novas configurações às VMs existentes apenas quando segmenta seletivamente VMs específicas para serem atualizadas.

Definir o tipo de atualização do MIG como oportunista oferece as seguintes vantagens:

  • Pode selecionar as VMs que quer atualizar.
  • Pode controlar a hora e a sequência das atualizações.
  • Pode usar a CLI gcloud ou a API REST para atualizar todas as instâncias imediatamente.

Em determinados cenários, um tipo de atualização seletiva é útil porque não quer causar instabilidade ao sistema se puder ser evitado. Por exemplo, considere o seguinte:

  • Uma das VMs no seu MIG fica inativa e precisa de ser reparada, mas não quer que a respetiva configuração seja alterada. Se definir o tipo de atualização do GIG como oportunista e não aplicar à força atualizações durante as reparações, o Compute Engine repara a VM com a mesma configuração que foi usada para criar essa VM, mesmo que o modelo de instância original já não exista.

  • Tem um MIG com escalamento automático e quer aplicar uma atualização não crítica sem urgência. Para garantir que o Compute Engine não desativa as VMs existentes para aplicar a atualização, defina o tipo de atualização do MIG como oportunista. Quando reduz a escala, o redimensionador automático termina preferencialmente as VMs com a configuração antiga. Quando o grupo é expandido, cria VMs com a configuração mais recente.

Para saber como definir o tipo de atualização do MIG, consulte o artigo Configure uma atualização proativa ou oportuna.

Para mais informações sobre a atualização seletiva de VMs, consulte o artigo Aplique seletivamente atualizações de configuração de VMs num MIG.

Recriação de VMs

Pode recriar qualquer VM num MIG. Quando o faz, o MIG aplica qualquer configuração atualizada que ainda não tenha sido aplicada a essa VM. Para mais informações, consulte Recriar VMs num MIG.

Configure uma atualização proativa ou oportuna

Para aplicar novas configurações às VMs existentes automaticamente, defina o tipo de atualização do GIG como "proativo". Para aplicar novas configurações a VMs existentes apenas quando seleciona uma VM a ser atualizada, defina o tipo de atualização do MIG como "oportunista".

Use a Google Cloud consola, a Google Cloud CLI ou o REST.

Consola

  1. Na Google Cloud consola, aceda à página Grupos de instâncias.

    Aceda à página Grupos de instâncias

  2. Selecione o MIG que quer atualizar.

  3. Clique em Edit.

  4. Clique em Atualizar política para expandir a secção.

  5. Escolha a atualização Seletiva ou Automática.

  6. Opcional: se escolher Automático, pode definir as opções adicionais ou usar os valores predefinidos.

  7. Clique em Guardar.

gcloud

Use o comando rolling-action start-update e defina o sinalizador --type como opportunistic ou proactive.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --type=TYPE

Também pode usar o comando beta update e incluir a flag --update-policy-type.

gcloud beta compute instance-groups managed update INSTANCE_GROUP_NAME \
    --update-policy-type=TYPE

Substitua o seguinte:

  • INSTANCE_GROUP_NAME: o nome do grupo
  • NEW_TEMPLATE: o nome do novo modelo para o grupo
  • TYPE: o tipo de atualização, opportunistic ou proactive

REST

Chame o método patch num recurso de GIG zonal ou regional.

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

  • PROJECT_ID: o projeto no qual o MIG existe.
  • REGION: a região onde o seu MIG está localizado. Para um MIG zonal, substitua regions/REGION por zones/ZONE.
  • INSTANCE_GROUP_NAME: o nome do grupo.
  • NEW_TEMPLATE: o nome do novo modelo para o grupo.
  • TYPE: o tipo de atualização, OPPORTUNISTIC ou PROACTIVE.

Para saber como definir um novo modelo e, em seguida, aplicá-lo a VMs novas e existentes num MIG, consulte as seguintes páginas:

Verifique o tipo de política de atualização do seu grupo

Pode ver o tipo de política de atualização do MIG configurado atualmente ("oportunista" ou "proativa") e outras definições da política de atualização através da CLI gcloud ou da API REST.

gcloud

Use o comando describe e inclua a flag --format para listar apenas as definições de updatePolicy.

gcloud beta compute instance-groups managed describe INSTANCE_GROUP_NAME \
    --format="(updatePolicy)"

REST

Faça um pedido GET num GIG zonal ou regional e verifique o campo updatePolicy.

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

Para alterar o tipo de política, consulte o artigo Configure uma atualização proativa ou oportuna.

Atualizações para VMs suspensas e paradas

Se tiver suspendido e parado conjuntos de VMs num MIG, pode atualizar seletivamente (oportunisticamente) as VMs suspensas ou paradas, tal como atualiza outras VMs em execução. Se configurar atualizações automáticas (proativas), o GIG atualiza as VMs pela seguinte ordem:

  1. VMs em execução, suspensas e paradas
  2. VMs com o estado SUSPENDING ou STOPPING

Para uma atualização automática, o MIG calcula o aumento máximo e o máximo indisponível com base apenas no número de VMs em execução pretendido e não considera as VMs no conjunto de espera.

Se a atualização automática exigir a substituição de VMs no grupo, o GIG faz o seguinte:

  1. Elimina as VMs suspensas e paradas.
  2. Cria novas VMs com o novo modelo de instância.
  3. Executa o processo de inicialização.
  4. Suspende ou para as VMs.

Se a atualização automática exigir apenas a atualização ou o reinício das VMs no grupo, o GIG faz o seguinte:

  1. Retoma ou inicia as VMs.
  2. Executa a atualização nas VMs quando estão em execução.
  3. Executa o processo de inicialização.
  4. Suspende ou para as VMs.

Atualizações de teste

Se quiser iniciar atualizações canary num MIG que tenha VMs suspensas ou paradas, aplica-se o seguinte:

  • No manualmodo de política de espera, o MIG atualiza apenas as VMs em execução com base no número ou na percentagem de VMs às quais quer aplicar a atualização. As VMs suspensas e paradas permanecem nas versões anteriores.
  • No scale-out-poolmodo de política de espera, não pode iniciar uma atualização canária no MIG.

Relação entre os campos versions e instanceTemplate

Se usar REST, recomendamos que use os campos instanceGroupManagers.versions e regionInstanceGroupManagers.versions para configurar modelos de instâncias para MIGs zonais e regionais.

O campo instanceTemplate antigo sobrepõe-se em termos de funcionalidade ao campo versions, uma vez que ambos os campos permitem especificar que modelo de instância o MIG usa para criar VMs. No entanto, apenas o campo versions permite especificar uma configuração avançada de dois modelos (canário).

Para retrocompatibilidade, os MIGs continuam a suportar a definição do campo instanceTemplate de nível superior, embora recomendemos que mude para usar apenas o campo versions. A utilização do campo instanceTemplate de nível superior e do campo versions ao mesmo tempo pode gerar ambiguidade e confusão.

Se especificar o campo instanceTemplate e o campo versions quando chamar o método update() ou patch(), existem três resultados possíveis:

  • Definir ambos os campos com o mesmo valor.

    Este é um pedido válido. Neste caso, não cria ambiguidade e o novo modelo de instância é aplicado ao MIG.

    Por exemplo, no pedido seguinte, o campo instanceTemplate de nível superior e o campo versions especificam o mesmo modelo de instância, que é diferente do modelo atual existente. Por isso, o MIG é atualizado para o novo modelo de instância:

    {
 "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
  }
 ],
 "updatePolicy": {
   "type": "PROACTIVE"
 }
}

  • Definiu ambos os campos para valores que não correspondem, mas apenas um valor difere do modelo de instância atual no MIG.

    Este é um pedido válido. O campo que é diferente da definição atual é considerado o valor pretendido. Por exemplo, chama o método update() e fornece ambos os campos, mas apenas um campo é atualizado:

    {
 "instanceTemplate": "global/instanceTemplates/CURRENT_TEMPLATE",
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
  }
 ],
 "updatePolicy": {
   "type": "PROACTIVE"
 }
}

  • Definiu ambos os campos para valores que não correspondem e ambos os valores diferem do modelo de instância atual no MIG.

    Esta definição é inválida e devolve um erro porque não existe uma intenção clara.

    {
 "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/A_DIFFERENT_NEW_TEMPLATE"
  }
 ],
 "updatePolicy": {
   "type": "PROACTIVE"
 }
}

O campo versions, o campo instanceTemplate e o método get()

Se especificar apenas um modelo de instância, através do campo instanceTemplate de nível superior, do campo versions ou de ambos, o método get() devolve ambos os campos na respetiva resposta. Isto torna o novo campo versions retrocompatível. Desde que especifique um modelo de instância única num destes campos, não há alterações ao que o método get() retorna no campo instanceTemplate.

Se o campo versions tiver dois modelos de instância especificados, o método get() devolve um campo instanceTemplate de nível superior vazio. Não existe forma de expressar de forma inequívoca uma configuração de modelo de duas instâncias de teste beta no campo instanceTemplate de nível superior, pelo que o campo não é usado durante uma atualização de teste beta.

O campo versions e o método setInstanceTemplate()

Para retrocompatibilidade, o método setInstanceTemplate() comporta-se como anteriormente, permitindo-lhe alterar o modelo que o MIG usa para criar VMs. Quando 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 o valor de updatePolicy como OPPORTUNISTIC. Isto impede que o MIG implemente ativamente um modelo de instância que não esteja explicitamente especificado no campo versions.

O que se segue?