Algumas ou todas as informações nesta página podem não se aplicar à Trusted Cloud by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

Aplicar automaticamente atualizações de configuração de VM num MIG

Este documento descreve como aplicar automaticamente atualizações de configuração às instâncias de máquinas virtuais (VMs) num grupo de instâncias geridas (GIG).

O Compute Engine mantém as VMs num GIG com base nos componentes de configuração que usa: modelo de instância, configuração opcional de todas as instâncias e configuração opcional com estado.

Sempre que atualiza a configuração de VM de um GIG alterando esses 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, pode configurar uma atualização automática, também conhecida como um tipo de atualização proativa. O GIG implementa automaticamente atualizações de configuração em todas as VMs do grupo ou num subconjunto das mesmas. Pode controlar a velocidade de implementação, o nível de interrupção do seu serviço e, através de uma atualização canary, o número de instâncias que o MIG atualiza com a nova configuração. Depois de especificar a nova configuração, não tem de fornecer informações adicionais e a atualização é concluída automaticamente.

Em alternativa, se quiser aplicar seletivamente uma nova configuração apenas a novas instâncias ou a instâncias específicas num MIG, consulte o artigo Aplique seletivamente atualizações de configuração de VMs num MIG. Para ajudar a decidir, consulte os métodos para aplicar uma nova configuração a VMs existentes.

Antes de começar

Se estiver a atualizar um MIG com estado, reveja o artigo Aplicar, ver e remover a configuração com estado em MIGs.
Se ainda não o tiver feito, configure a autenticação. A autenticação valida a sua identidade para aceder a Trusted Cloud by S3NS 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 Trusted Cloud console to access Trusted Cloud by S3NS services and APIs, you don't need to set up authentication.
gcloud
1. Instale a CLI Google Cloud e, em seguida, inicie sessão na CLI gcloud com a sua identidade federada. Depois de iniciar sessão, inicialize a CLI gcloud executando o seguinte comando:
  gcloud init
  Nota: se instalou a CLI gcloud anteriormente, certifique-se de que tem a versão mais recente executando gcloud components update.
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.
Para mais informações, consulte o artigo Autenticar para usar REST na Trusted Cloud documentação de autenticação.

Limitações

Se tiver um MIG com estado e quiser usar atualizações implementadas automáticas, tem de manter os nomes das instâncias quando substituir instâncias ou, em alternativa, definir o método de substituição como RECREATE.

Inicie uma atualização gradual básica

Uma atualização contínua básica é uma atualização que é aplicada gradualmente a todas as instâncias num MIG até que todas as instâncias tenham sido atualizadas para a configuração mais recente pretendida. A atualização gradual ignora automaticamente as instâncias que já estão na respetiva configuração mais recente.

Pode controlar vários aspetos de uma atualização contínua, como o número de instâncias que podem ser colocadas offline para a atualização, o tempo de espera entre a atualização de instâncias, se o novo modelo afeta todas ou apenas uma parte das instâncias e assim sucessivamente.

Seguem-se alguns aspetos a ter em conta ao fazer uma atualização contínua:

As atualizações baseiam-se na intenção. Quando faz o pedido de atualização inicial, a API Compute Engine devolve uma resposta bem-sucedida para confirmar que o pedido é válido, mas isso não indica que a atualização foi bem-sucedida. Tem de verificar o estado do grupo para determinar se a atualização foi implementada com êxito.
A API Instance Group Updater é uma API declarativa. A API espera que um pedido especifique a configuração desejada após a atualização do MIG, em vez de uma chamada de função explícita.
As atualizações automáticas suportam até duas versões de modelos de instâncias no seu GIG. Isto significa que pode especificar duas versões diferentes do modelo de instância para o seu grupo, o que é útil para realizar atualizações canary.

Para iniciar uma atualização contínua básica em que a atualização é aplicada a todas as instâncias no grupo, selecione uma das seguintes opções:

Autorizações necessárias para esta tarefa

Para realizar esta tarefa, tem de ter as seguintes autorizações:

Para MIGs zonais, todas as autorizações necessárias para chamar o método instanceGroupManagers.patch
Para os MIGs regionais, todas as autorizações necessárias para chamar o método regionInstanceGroupManagers.patch

Consola

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

Aceda a Grupos de instâncias
Selecione o MIG que quer atualizar.
Clique em Edit.
Clique em Modelo de instância e substituições para expandir a secção e adicione um modelo para testes da seguinte forma:
1. Clique em Adicionar um modelo para testes.
2. Na lista Modelo de instância para testes, selecione um novo modelo.
  Se o modelo que quer testar não estiver disponível, use a opção Criar um novo modelo de instância e siga as instruções para criar um.
3. No campo Alvo de execução, introduza o número ou a percentagem de instâncias às quais quer aplicar o novo modelo.
4. No campo Instâncias ou percentagem, selecione instâncias ou percentagem, indicando o número que introduziu no campo Segmentar em execução.
Clique em Atualizar política para expandir a secção e faça o seguinte:
1. Selecione Automático, se ainda não estiver selecionado.
2. Deixe os valores predefinidos para as outras opções ou modifique-os conforme necessário.
Clique em Guardar para iniciar a atualização.

gcloud

Use o comando rolling-action start-update.

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

Substitua o seguinte:

INSTANCE_GROUP_NAME: o nome do MIG
INSTANCE_TEMPLATE_URL: o URL do modelo de instância que quer usar para criar VMs no MIG. O URL pode conter o ID ou o nome do modelo de instância. Especifique um dos seguintes valores:
- Para um modelo de instância regional: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
- Para um modelo de instância global: INSTANCE_TEMPLATE_ID
ZONE: para MIGs zonais, indique a zona
REGION: para GIGs regionais, indique a região

REST

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

Por exemplo, para um GIG regional, o pedido seguinte mostra a configuração mínima necessária para atualizar automaticamente 100% das instâncias para o novo modelo de instância.

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

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

Depois de fazer um pedido, pode monitorizar a atualização para saber quando esta terminou.

Para configurações avançadas, inclua outras opções de atualização. Se não especificar o contrário, as opções maxSurge e maxUnavailable são predefinidas como 1 multiplicado pelo número de zonas afetadas. Isto significa que apenas 1 instância é colocada offline em cada zona afetada e o MIG cria apenas 1 instância adicional por zona durante a atualização.

Configure as opções para a sua atualização

Para atualizações mais complexas, pode configurar opções adicionais, conforme descrito nas secções seguintes.

Atualizar tipo

Os grupos de instâncias geridas suportam dois tipos de atualizações:

Atualizações automáticas ou proativas
Atualizações seletivas ou oportunistas

Se quiser aplicar atualizações automaticamente, defina o tipo como proativo.

Em alternativa, se uma atualização automática for potencialmente demasiado disruptiva, pode optar por fazer uma atualização oportunista. O MIG aplica uma atualização oportunista apenas quando inicia manualmente a atualização em instâncias selecionadas ou quando são criadas novas instâncias. Podem ser criadas novas instâncias quando o utilizador ou outro serviço, como um escalador automático, redimensiona o MIG. O Compute Engine não inicia ativamente pedidos para aplicar atualizações oportunistas em instâncias existentes.

Para mais informações sobre atualizações automáticas versus seletivas, consulte o artigo Métodos para aplicar uma nova configuração a VMs existentes.

Aumento máximo

Use a opção maxSurge para configurar quantas novas instâncias o GIG pode criar acima do respetivo targetSize durante uma atualização automática. Por exemplo, se definir maxSurge como 5, o MIG usa o novo modelo de instância para criar até 5 novas instâncias acima do tamanho alvo. A definição de um valor maxSurge mais elevado acelera a atualização, ao custo de instâncias adicionais, que são faturadas de acordo com a preços.

Pode especificar um número fixo ou, se o grupo tiver 10 ou mais instâncias, uma percentagem. Se definir uma percentagem, o atualizador arredonda o número de instâncias, se necessário.

Se não definir o valor maxSurge, é usado o valor predefinido. Para os MIGs zonais, a predefinição de maxSurge é 1. Para os MIGs regionais, a predefinição é o número de zonas associadas ao grupo, por predefinição 3.

maxSurge só funciona se tiver quota ou recursos suficientes para suportar os recursos adicionais.

Se a atualização não exigir a substituição de VMs, esta opção é ignorada. Pode forçar a substituição das VMs durante uma atualização definindo a opção ação mínima.

Máximo indisponível

Use a opção maxUnavailable para configurar quantas instâncias estão indisponíveis em qualquer altura durante uma atualização automática. Por exemplo, se definir maxUnavailable como 5, apenas 5 instâncias são colocadas offline para atualização de cada vez. Use esta opção para controlar o quão disruptiva é a atualização para o seu serviço e controlar a taxa de implementação da atualização.

Este número também inclui todas as instâncias que não estão disponíveis por outros motivos. Por exemplo, se o grupo estiver a ser redimensionado, as instâncias em processo de criação podem estar indisponíveis. Estas instâncias contam para o número maxUnavailable.

Pode especificar um número fixo ou, se o grupo tiver 10 ou mais instâncias, uma percentagem. Se definir uma percentagem, o atualizador arredonda para baixo o número de instâncias, se necessário.

Se não quiser nenhuma máquina indisponível durante uma atualização, defina o valor maxUnavailable como 0 e o valor maxSurge como superior a 0. Com estas definições, o Compute Engine remove cada máquina antiga apenas depois de a nova máquina de substituição ser criada e estar em execução.

Se não definir o valor maxUnavailable, é usado o valor predefinido. Para os MIGs zonais, a predefinição é 1. Para os MIGs regionais, a predefinição é o número de zonas associadas ao grupo, por predefinição 3.

Tempo de espera mínimo

Use a opção minReadySec para especificar o tempo de espera antes de considerar uma instância nova ou reiniciada como atualizada. Use esta opção para controlar a taxa de implementação da atualização automática. O temporizador é iniciado quando ambas as seguintes condições forem satisfeitas:

O estado da instância é RUNNING.
Se a verificação de funcionamento estiver ativada, quando a verificação de funcionamento devolve HEALTHY.

Tenha em atenção que, para a verificação de estado devolver um estado saudável, o atualizador aguarda as seguintes condições:

Aguarda até ao período especificado pelo valor autohealingPolicies.initialDelaySec do MIG para que a verificação de estado seja devolvida como HEALTHY.
Em seguida, aguarda o período especificado por minReadySec.

Se a verificação de estado não devolver HEALTHY dentro do período de initialDelaySec, o atualizador declara a instância de VM como não saudável e, potencialmente, para a atualização. Enquanto a instância de VM aguarda a validação durante o período de tempo initialDelaySec e minReadySec, o currentAction da instância é VERIFYING. No entanto, o estado da instância de VM subjacente permanece RUNNING.

Se não existirem verificações de estado para o grupo, o temporizador é iniciado quando o estado da instância é RUNNING.

O valor máximo do campo minReadySec é de 3600 segundos (1 hora).

O diagrama seguinte mostra como as opções de tamanho desejado, máximo indisponível, máximo de picos e tempo de espera mínimo afetam as suas instâncias. Para mais informações acerca do tamanho do destino, consulte o artigo Atualizações Canary.

Como as opções da política de atualização afetam o seu pedido.

Ação mínima

Use a opção de ação mínima para minimizar a interrupção o máximo possível ou para aplicar uma ação mais disruptiva do que o estritamente necessário. Por exemplo, o Compute Engine não precisa de reiniciar uma VM para alterar os respetivos metadados. No entanto, se a sua aplicação ler os metadados da instância apenas quando uma VM é reiniciada, pode definir a ação mínima para reiniciar de modo a detetar as alterações de metadados.

Se a sua atualização exigir uma ação mais disruptiva do que a definida com esta flag, o Compute Engine executa a ação necessária para executar a atualização. Por exemplo, se especificar um reinício como a ação mínima, o atualizador tenta reiniciar as instâncias para aplicar a atualização. No entanto, se estiver a alterar o SO, o que não pode ser feito reiniciando a instância, o atualizador substitui as instâncias no grupo por novas instâncias de VM.

Para mais informações, incluindo opções válidas, consulte o artigo Controle o nível de interrupção durante uma atualização contínua.

Ação permitida mais disruptiva

Use a opção de ação permitida mais disruptiva para impedir uma atualização se esta exigir mais disrupção do que pode suportar. Se não for possível concluir uma atualização devido a esta definição, a atualização falha e as suas VMs mantêm a configuração anterior.

Para mais informações, consulte o artigo Controlar o nível de interrupção durante uma atualização contínua.

Método de substituição

Por predefinição, quando atualiza proativamente um GIG, o grupo elimina as instâncias de VM e troca-as por novas instâncias com novos nomes. Se precisar de preservar os nomes das suas instâncias de VM, use a opção replacementMethod.

A preservação dos nomes das instâncias existentes pode ser útil se tiver aplicações ou sistemas que dependam da utilização de nomes de instâncias específicos. Por exemplo, algumas aplicações, como o Memcached, dependem dos nomes das instâncias porque não têm um serviço de deteção. Consequentemente, sempre que um nome de instância muda, a aplicação perde a ligação a essa VM específica.

Para preservar os nomes das instâncias, defina o método de substituição como RECREATE em vez de SUBSTITUTE se atualizar o MIG com a CLI gcloud ou a API Compute Engine. Em alternativa, se atualizar o MIG a partir da Trusted Cloud consola, selecione a caixa de verificação Manter nomes ao substituir VMs.

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

Os valores replacementMethod válidos são:

SUBSTITUTE (predefinição). Substitui as instâncias de VM mais rapidamente durante as atualizações porque são criadas novas VMs antes de as antigas serem encerradas. No entanto, os nomes das instâncias não são preservados porque os nomes ainda estão a ser usados pelas instâncias antigas.
RECREATE. Preserva os nomes das instâncias através de uma atualização. O Compute Engine liberta o nome da instância quando a VM antiga é encerrada. Em seguida, o Compute Engine cria uma nova instância com o mesmo nome. Para usar este modo, tem de definir maxSurge como 0.

Para mais informações, consulte o artigo Preservar nomes de instâncias.

Exemplos de atualizações adicionais

Seguem-se alguns exemplos de linhas de comandos com opções de configuração comuns.

Fazer uma atualização contínua de todas as instâncias de VM, mas criar até 5 novas instâncias acima do tamanho de destino de cada vez

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

Faça uma atualização contínua com, no máximo, 3 máquinas indisponíveis e um tempo de espera mínimo de 3 minutos antes de marcar uma nova instância como disponível

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

Fazer uma atualização contínua de todas as instâncias de VM, mas criar até 10% de novas instâncias acima do tamanho alvo de cada vez

Por exemplo, se tiver 1000 instâncias e executar o seguinte comando, o atualizador cria até 100 instâncias antes de começar a remover instâncias que estão a executar o modelo de instância anterior.

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 do Canary

Uma atualização canary é uma atualização aplicada a um subconjunto de instâncias no grupo. Com uma atualização canary, pode testar novas funcionalidades ou atualizações num subconjunto aleatório de instâncias, em vez de implementar uma atualização potencialmente disruptiva em todas as suas instâncias. Se uma atualização não estiver a decorrer bem, só tem de reverter o subconjunto de instâncias, minimizando a interrupção para os seus utilizadores.

Uma atualização canary é igual a uma atualização contínua padrão, exceto que o número de instâncias que devem ser atualizadas é inferior ao tamanho total do grupo de instâncias. Tal como numa atualização contínua padrão, pode configurar opções adicionais para controlar o nível de interrupção do seu serviço.

Inicie uma atualização canary

Para iniciar uma atualização de teste beta, especifique até duas versões do modelo de instância, normalmente um novo modelo de instância para teste beta e o modelo de instância atual para as restantes instâncias. Por exemplo, pode especificar que 20% das suas instâncias sejam criadas com base em NEW_INSTANCE_TEMPLATE, enquanto as restantes instâncias continuam a ser executadas em OLD_INSTANCE_TEMPLATE. Não pode especificar mais de dois modelos de instância de cada vez. O NEW_INSTANCE_TEMPLATE pode ser um modelo de instância regional da mesma região que a do seu MIG ou um modelo de instância global.

Tem de especificar sempre um tamanho de destino (targetSize) para a versão de teste. Não pode iniciar uma atualização canary se omitir a dimensão do alvo para a versão canary. Por exemplo, se especificou que 10% das instâncias devem ser usadas para testes canary, os restantes 90% não são afetados e usam o modelo de instância atual.

Autorizações necessárias para esta tarefa

Para realizar esta tarefa, tem de ter as seguintes autorizações:

Para MIGs zonais, todas as autorizações necessárias para chamar o método instanceGroupManagers.patch
Para os MIGs regionais, todas as autorizações necessárias para chamar o método regionInstanceGroupManagers.patch

Consola

Na Trusted Cloud consola, aceda à página Grupos de instâncias.
Aceda a Grupos de instâncias
Selecione o grupo de instâncias gerido que quer atualizar.
Clique em Edit.
Clique em Modelo de instância e substituições para expandir a secção.
1. Clique em Adicionar um modelo para testes.
2. Na lista Modelo de instância para testes, selecione um novo modelo.
  Se o modelo que quer testar não estiver disponível, use a opção Criar um novo modelo de instância e siga as instruções para criar um.
3. No campo Alvo de execução, introduza o número ou a percentagem de instâncias às quais quer aplicar o novo modelo.
4. No campo Instâncias ou percentagem, selecione instâncias ou percentagem, indicando o número que introduziu no campo Segmentar em execução.
Opcional: para configurar outras opções para as atualizações, clique em Política de atualização para expandir a secção. Modifique os campos conforme necessário.
Clique em Guardar para iniciar a atualização.

gcloud

Use o comando rolling-action start-update. Forneça o modelo atual e o novo modelo 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 o seguinte:

INSTANCE_GROUP_NAME: o nome do grupo de instâncias.
CURRENT_INSTANCE_TEMPLATE: a instância atual do modelo usado pelo grupo.
NEW_TEMPLATE: o novo modelo que quer testar.
SIZE: o número ou a percentagem de instâncias às quais quer aplicar esta atualização. Tem de aplicar a propriedade target-size ao modelo --canary-version. Só pode definir uma percentagem se o grupo contiver 10 ou mais instâncias.
ZONE: para MIGs zonais, indique a zona.
REGION: para GIGs regionais, indique a região.

Por exemplo, o seguinte comando executa uma atualização canary que é implementada example-template-B em 10% das instâncias no grupo:

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

REST

Chame o método patch num recurso de GIG regional ou zonal. No corpo do pedido, inclua o modelo de instância atual e o novo modelo de instância que quer testar com o lançamento canário. Por exemplo:

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

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

NEW_TEMPLATE: o nome do novo modelo que quer testar com a versão canary.
NUMBER|PERCENTAGE: o número fixo ou a percentagem de instâncias para testar esta atualização. Só pode definir uma percentagem se o grupo contiver 10 ou mais instâncias. Caso contrário, indique um número fixo.
CURRENT_INSTANCE_TEMPLATE: o modelo de instância atual usado pelo grupo.

Para mais opções, consulte o artigo Configurar opções para a sua atualização.

Depois de fazer um pedido, pode monitorizar a atualização para saber quando esta foi concluída.

Implemente uma atualização canary

Depois de executar uma atualização canary, pode decidir se quer confirmar a atualização para 100% do MIG ou revertê-la.

Consola

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

[Aceda a Grupos de instâncias](https://console.cloud.s3nscloud.fr/compute/instanceGroups){: target="console" track-type="tasks" track-name="consoleLink" track-metadata-position="body" track-metadata-end-goal="rollForwardCanaryUpdate" class="button button-primary"}
Selecione o grupo de instâncias gerido que quer atualizar.
Clique em Edit.
Para o modelo de instância que selecionou para testes, atualize o valor Target running do modelo de teste para 100% para implementar o modelo de teste em todas as suas instâncias.

Em alternativa, pode substituir o modelo original pelo modelo de teste e eliminar o modelo de instância para testes.
Clique em Guardar para iniciar a atualização.

gcloud

Se quiser confirmar a atualização de teste beta, implemente a atualização emitindo outro comando rolling-action start-update, mas defina apenas a flag version e omita a flag --canary-version.

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

REST

Chame o método patch num recurso de GIG regional ou zonal. No corpo do pedido, especifique o novo modelo de instância como um version e omita o modelo de instância anterior do corpo do pedido. Omita a especificação do tamanho de destino para implementar a atualização em 100% das instâncias. Por exemplo:

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

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

Monitorize atualizações

Depois de iniciar uma atualização, pode demorar algum tempo até que a nova configuração seja implementada em todas as instâncias afetadas. Pode monitorizar o progresso de uma atualização verificando o seguinte:

Para verificar se todas as VMs atingiram a versão do modelo de destino, veja o estado do grupo.
Para verificar se VMs específicas atingiram a versão do modelo de destino, veja as ações atuais nas instâncias.
Para MIGs com estado, consulte também o artigo Verificar se as configurações por instância foram aplicadas.

Estado do grupo

Ao nível do grupo, o Compute Engine preenche um campo só de leitura denominado status que contém uma versionTarget.isReached flag e uma isStable flag. Pode usar a CLI gcloud ou a REST para aceder a estas flags. Também pode usar a Trusted Cloud consola para ver o número atual e planeado de instâncias que estão a ser atualizadas.

Autorizações necessárias para esta tarefa

Para realizar esta tarefa, tem de ter as seguintes autorizações:

compute.instanceGroupManagers.get no MIG

Consola

Pode monitorizar uma atualização contínua de um grupo acedendo à página de detalhes do grupo.

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

[Aceda a Grupos de instâncias](https://console.cloud.s3nscloud.fr/compute/instanceGroups){: target="console" track-type="tasks" track-name="consoleLink" track-metadata-position="body" track-metadata-end-goal="monitorUpdates" class="button button-primary"}
Selecione o grupo de instâncias gerido que quer monitorizar. A página Vista geral do grupo mostra o modelo que cada instância está a usar.
Para ver os detalhes, clique no separador Detalhes.
Na secção Modelo de instância, pode ver o número atual e o número alvo de instâncias para cada modelo de instância.
Para ver as definições de atualização, clique em Atualizar parâmetros para expandir.

gcloud

Use o comando describe.

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

Também pode usar o comando gcloud compute instance-groups managed wait-until com a flag --version-target-reached para aguardar até que status.versionTarget.isReached esteja definido como true para o grupo:

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

REST

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

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

Verifique se a implementação de uma atualização está concluída

Verifique se a implementação de uma atualização está concluída verificando o valor do campo status.versionTarget.isReached do MIG:

status.versionTarget.isReached definido como true indica que todas as instâncias de VM foram ou estão a ser criadas com a versão de destino.
status.versionTarget.isReached definido como false indica que, pelo menos, uma MV ainda não está a usar a versão de destino. Em alternativa, no caso de uma atualização canary, false indica que o número de VMs que usam uma versão de destino não corresponde ao respetivo tamanho de destino.

Verifique se um grupo de instâncias geridas é estável

Verifique se todas as instâncias num grupo de instâncias gerido estão em execução e em bom estado de funcionamento através da verificação do valor do campo status.isStable do grupo.

status.isStable definido como false indica que as alterações estão ativas, pendentes ou que o próprio MIG está a ser modificado.

status.isStable definido como true indica o seguinte:

Nenhuma das instâncias no MIG está a sofrer qualquer tipo de alteração e o valor de currentAction para todas as instâncias é NONE.
Não existem alterações pendentes para instâncias no MIG.
O MIG não está a ser modificado.

Lembre-se de que a estabilidade de um MIG depende de vários fatores, uma vez que um MIG pode ser modificado de várias formas. Por exemplo:

Faz um pedido para implementar um novo modelo de instância.
Faz um pedido para criar, eliminar, redimensionar ou atualizar instâncias no MIG.
Um escalador automático pede para redimensionar o GIG.
Um recurso de recuperação automática está a substituir uma ou mais instâncias não íntegras no MIG.
Num MIG regional, algumas das instâncias estão a ser redistribuídas.

Assim que todas as ações estiverem concluídas, status.isStable volta a ser definido como true para esse MIG.

Ações atuais nas instâncias

Use a Google Cloud CLI ou a REST para ver detalhes sobre as instâncias num grupo de instâncias gerido. Os detalhes incluem o estado da instância e as ações atuais que o grupo está a realizar nas respetivas instâncias.

Autorizações necessárias para esta tarefa

Para realizar esta tarefa, tem de ter as seguintes autorizações:

compute.instanceGroupManagers.get no grupo
compute.instanceGroupManagers.list no grupo

gcloud

Todas as instâncias geridas

Para verificar o estado e as ações atuais em todas as instâncias no grupo, use o comando list-instances.

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

O comando devolve uma lista de instâncias no grupo, incluindo o respetivo estado, ações atuais e outros detalhes:

NAME: vm-instances-9pk4
ZONE: us-central1-f
STATUS:
HEALTH_STATE:
ACTION: CREATING
INSTANCE_TEMPLATE: my-new-template
VERSION_NAME:
LAST_ERROR:

NAME: vm-instances-h2r1
ZONE: us-central1-f
STATUS: STOPPING
HEALTH_STATE:
ACTION: DELETING
INSTANCE_TEMPLATE: my-old-template
VERSION_NAME:
LAST_ERROR:

A coluna HEALTH_STATE aparece vazia, a menos que tenha configurado a verificação de funcionamento.

Uma instância gerida específica

Para verificar o estado e a ação atual de uma instância específica no grupo, use o comando describe-instance.

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

O comando devolve detalhes sobre a instância, incluindo o estado da instância, a ação atual e, para os MIGs com estado, o estado preservado:

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

REST

Chame o método listManagedInstances num recurso de GIG regional ou zonal. Por exemplo, para ver detalhes sobre as instâncias num recurso de MIG zonal, pode fazer o seguinte pedido:

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

A chamada devolve uma lista de instâncias para o MIG, incluindo o instanceStatus e o currentAction de cada instância.

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
      "instanceStatus": "RUNNING",
      "currentAction": "REFRESHING",
      "id": "5317605642920955957",
      "version": {
        instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template"
      },
      "name": "vm-instances-prvp"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
      "instanceStatus": "RUNNING",
      "currentAction": "REFRESHING",
      "id": "2800161036826218547",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template"
      },
      "name": "vm-instances-w2t5"
    }
  ]
}

Se configurar a verificação de funcionamento, a resposta também inclui o campo instanceHealth.

Para ver uma lista de valores de campo instanceStatus válidos, consulte o artigo Ciclo de vida da instância de VM.

Se uma instância estiver a sofrer algum tipo de alteração, o grupo de instâncias gerido define o campo currentAction da instância para uma das seguintes ações para ajudar a acompanhar o progresso da alteração. Caso contrário, o campo currentAction é definido como NONE.

Os valores currentAction possíveis são:

ABANDONING. A instância está a ser removida do MIG.
CREATING. A instância está em processo de criação.
CREATING_WITHOUT_RETRIES. A instância está a ser criada sem novas tentativas. Se a instância não for criada na primeira tentativa, o MIG não tenta substituí-la novamente.
DELETING. A instância está a ser eliminada.
RECREATING. A instância está a ser substituída.
REFRESHING. A instância está a ser removida dos conjuntos de destino atuais e está a ser adicionada novamente à lista de conjuntos de destino atuais (esta lista pode ser igual ou diferente dos conjuntos de destino existentes).
RESTARTING. A instância está a ser reiniciada através dos métodos stop e start.
RESUMING. A instância está a ser retomada após ter sido suspensa.
STARTING. A instância está a ser iniciada depois de ter sido parada.
STOPPING. A instância está a ser parada.
SUSPENDING. A instância está a ser suspensa.
VERIFYING. A instância foi criada e está em processo de validação.
NONE. Não estão a ser realizadas ações na instância.

Reverta uma atualização

Não existe um comando explícito para reverter uma atualização para uma versão anterior, mas, se decidir reverter uma atualização (uma atualização totalmente comprometida ou uma atualização canary), pode fazê-lo criando um novo pedido de atualização e transmitindo o modelo de instância para o qual quer reverter.

gcloud

Por exemplo, o seguinte comando da CLI gcloud reverte uma atualização o mais rapidamente possível. Substitua OLD_INSTANCE_TEMPLATE pelo nome do modelo de instância para o qual quer reverter.

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

REST

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

No corpo do pedido, especifique o modelo de instância anterior como version:

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

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

Para um MIG regional com menos de 10 instâncias, tem de usar um valor fixo para maxUnavailable e definir o valor para o número de instâncias no grupo.

O Updater trata um pedido de reversão da mesma forma que um pedido de atualização normal, pelo que pode especificar opções de atualização adicionais.

Pare uma atualização

Não existe um método ou um comando explícito para parar uma atualização. Pode alterar uma atualização de proativa para oportuna e, se o grupo não estiver a ser redimensionado por outros serviços, como o escalamento automático, a alteração para oportuna interrompe efetivamente a atualização.

Para alterar uma atualização de proativa para oportunista através da CLI gcloud, execute o seguinte comando:

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

Para parar completamente a atualização depois de a converter de proativa para oportunista, siga estes passos:

Faça um pedido para determinar quantas instâncias foram atualizadas:

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
   [--zone=ZONE | --region=REGION]

A CLI gcloud devolve uma resposta que inclui uma lista de instâncias no grupo e os respetivos estados atuais:

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

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

Em seguida, faça um pedido para realizar 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=OLD_INSTANCE_TEMPLATE \
   --canary-version template=NEW_INSTANCE_TEMPLATE,target-size=2 \
   [--zone=ZONE | --region=REGION]
```
Para o Updater, esta atualização aparece como concluída, pelo que não são atualizadas outras instâncias, o que impede a atualização.

Controle a velocidade de uma atualização contínua

Por predefinição, quando faz um pedido de atualização, o atualizador executa a atualização o mais rapidamente possível. Se não tiver a certeza de que quer aplicar uma atualização na totalidade ou estiver a testar as alterações de forma provisória, pode controlar a velocidade da atualização através dos seguintes métodos.

Comece com uma atualização canary em vez de uma atualização completa.
Defina um valor minReadySec elevado. A definição deste valor faz com que o atualizador aguarde este número de segundos antes de considerar que a instância foi atualizada com êxito e avançar para a instância seguinte.
Ative a verificação de estado para fazer com que o atualizador aguarde que a sua aplicação seja iniciada e comunique um sinal de bom estado antes de considerar a instância atualizada com êxito e avançar para a instância seguinte.
Defina valores baixos de maxUnavailable e maxSurge. Isto garante que apenas um número mínimo de instâncias é atualizado de cada vez.
Atualizar seletivamente instâncias num MIG em vez de usar uma atualização automática.

Também pode usar uma combinação destes métodos para controlar a taxa de atualização.

Controle o nível de interrupção durante uma atualização contínua

Consoante a natureza de uma atualização, esta pode interromper o estado do ciclo de vida de uma instância. Por exemplo, alterar o disco de arranque de uma instância requer a substituição da instância. Pode controlar o nível de interrupção durante uma atualização contínua definindo as seguintes opções:

Ação mínima: use esta opção para minimizar a interrupção o máximo possível ou para aplicar uma ação mais disruptiva do que o necessário.
- Para limitar a interrupção o máximo possível, defina a ação mínima como REFRESH. Se a atualização exigir uma ação mais disruptiva, o Compute Engine executa a ação necessária para executar a atualização.
- Para aplicar uma ação mais disruptiva do que o estritamente necessário, defina a ação mínima como RESTART ou REPLACE. Por exemplo, o Compute Engine não precisa de reiniciar uma VM para alterar os respetivos metadados. No entanto, se a sua aplicação ler os metadados da instância apenas quando uma VM é reiniciada, pode definir a ação mínima como RESTART para detetar alterações aos metadados.
Ação permitida mais disruptiva: use esta opção para impedir uma atualização se exigir mais interrupções do que pode suportar. Se a sua atualização exigir uma ação mais disruptiva do que a definida com esta flag, o pedido de atualização falha. Por exemplo, se definir a ação permitida mais disruptiva como RESTART, então uma tentativa de atualizar a imagem do disco de arranque falha porque essa atualização requer a substituição da instância, uma ação mais disruptiva do que um reinício.

Ambas as opções aceitam os seguintes valores:

Valor	Descrição	Que propriedades de instância podem ser atualizadas?
`REFRESH`	Não pare a instância.	Discos adicionais, metadados de instâncias, etiquetas e tags
`RESTART`	Pare a instância e inicie-a novamente.	Discos adicionais, metadados de instâncias, etiquetas, etiquetas, tipo de máquina
`REPLACE`	(Predefinição.) Substitua a instância de acordo com a opção método de substituição.	Todas as propriedades da instância armazenadas no modelo de instância ou na configuração por instância

A ação permitida mais disruptiva não pode ser menos disruptiva do que a ação mínima.

Quando implementa atualizações automaticamente, aplicam-se as seguintes predefinições:

A ação mínima predefinida é REPLACE. Se quiser evitar interrupções desnecessárias, defina a ação mínima para ser menos disruptiva.
A ação mais disruptiva permitida predefinida é REPLACE. Se não conseguir tolerar essa interrupção, defina a ação permitida mais disruptiva para ser menos disruptiva.

Pode alterar o comportamento predefinido através da API Compute Engine para definir os campos updatePolicy.minimalAction e updatePolicy.mostDisruptiveAllowedAction no recurso MIG, por exemplo, chamando o método regionInstanceGroupManagers.patch. Em alternativa, pode selecionar as ações permitidas para atualizar VMs quando atualiza o MIG a partir da Trusted Cloud consola. Para ver as definições atuais, consulte o artigo Obter as propriedades de um MIG.

Uma atualização falha se exigir uma ação mais disruptiva do que a permitida. Se isto acontecer, pode tentar a atualização novamente com uma ação permitida mais disruptiva ou pode atualizar seletivamente a instância. O Compute Engine realiza uma validação de melhor esforço para ver se as instâncias podem ser atualizadas com o limite de interrupção especificado. No entanto, devido a alterações simultâneas no sistema, a situação pode mudar após o início da atualização. Se uma operação numa instância específica falhar, liste os erros da instância para ver o erro.

Faça um reinício contínuo ou uma substituição

Um reinício contínuo para e reinicia todas as instâncias, e uma substituição contínua substitui todas as instâncias de acordo com a opção método de substituição. Pode querer fazer um reinício contínuo ou uma substituição pelos seguintes motivos:

Limpar fugas de memória.
Reinicie a aplicação para que possa ser executada a partir de uma máquina nova.
Aplique uma substituição periódica como prática recomendada para testar as suas instâncias.
Atualize a imagem do sistema operativo da instância ou volte a executar scripts de arranque para atualizar o software.

Quando faz um reinício contínuo ou uma substituição das instâncias através da Trusted Cloud consola ou da CLI Google Cloud, as seguintes ações subjacentes ocorrem no MIG. No entanto, se usar REST, tem de definir estes campos no pedido para acionar uma operação de substituição ou reinício.

Se o valor for updatePolicy.type, o MIG altera o tipo para AUTOMATIC.OPPORTUNISTIC
O MIG atualiza o versions.name de cada instância.

Para fazer um reinício progressivo ou uma substituição, selecione uma das seguintes opções:

Consola

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

Aceda a Grupos de instâncias
Selecione o grupo de instâncias gerido que tem as VMs que quer reiniciar ou substituir.
Clique em Reiniciar/substituir VMs.
Na secção Operação, selecione Reiniciar ou Substituir.
- Se selecionar Reiniciar, modifique os seguintes parâmetros ou use os valores predefinidos:
  - Número máximo de instâncias indisponíveis
  - Tempo de espera mínimo
- Se selecionar Substituir, faça o seguinte:
  1. Escolha se quer manter os nomes das instâncias quando substituir instâncias.
  2. Especifique os seguintes parâmetros ou use os valores predefinidos:
Para iniciar a operação, clique em Reiniciar VMs ou Substituir VMs.

gcloud

Use o comando restart ou o comando replace.

Os comandos seguintes executam um reinício contínuo ou uma substituição de instâncias num MIG zonal. Para um MIG regional, substitua a flag --zone=ZONE por --region=REGION.

Para reiniciar todas as instâncias num MIG zonal, uma de cada vez:

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --zone=ZONE

Para substituir todas as instâncias num MIG zonal, uma de cada vez:

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME \
    --zone=ZONE

Pode personalizar ainda mais estes comandos com as mesmas opções disponíveis para atualizações, por exemplo, --max-surge e --max-unavailable.

REST

Envie um pedido PATCH através de um dos seguintes métodos:

Para um MIG regional, use o método regionInstanceGroupManagers.patch.
Para um MIG zonal, use o método instanceGroupManagers.patch.

No corpo do pedido, tem de definir os seguintes campos. Se não especificar estes campos, o pedido pode continuar a ser bem-sucedido, mas o MIG não executa a operação de reinício nem de substituição.

Defina o campo updatePolicy.minimalAction como RESTART ou REPLACE.
Defina o campo versions.name. Por exemplo, especifique um número da versão com uma data/hora: v2-ddmmyyhhmm.
Defina o campo versions.instanceTemplate para o URL do modelo atual.

Para reiniciar todas as instâncias num MIG zonal, faça o seguinte pedido. Para substituir todas as instâncias, defina o campo minimialAction como REPLACE no mesmo pedido.

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/CURRENT_INSTANCE_TEMPLATE",
   "name": "v2-1705499403"
  }
 ]
}

Pode personalizar ainda mais o pedido com as mesmas opções disponíveis para atualizações, por exemplo, maxSurge e maxUnavailable.

Depois de concluir uma operação de reinício ou substituição, pode listar as VMs do MIG e inspecionar o campo versions.name de cada VM para determinar que VMs foram reiniciadas ou substituídas.

Exemplos adicionais de substituição/reinício

Faça um reinício contínuo de todas as VMs, duas de cada vez

O comando seguinte reinicia todas as VMs no grupo, duas de cada vez. Tenha em atenção que não é especificado um novo modelo de instância.

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

Faça um reinício contínuo de todas as VMs o mais rapidamente possível

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

Faça uma substituição progressiva de todas as VMs o mais rapidamente possível

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

Preserve instance names

Se precisar de preservar os nomes das suas instâncias de VM numa atualização, defina o valor de replacementMethod como RECREATE. Também tem de definir maxUnavailable como superior a 0 e maxSurge como 0. A recriação de instâncias em vez da substituição faz com que a atualização demore mais tempo a ser concluída, mas as instâncias atualizadas mantêm os respetivos nomes.

Se não especificar um método de substituição, é usado o valor atual do MIG.updatePolicy.replacementMethod Se não estiver definido, é usado o valor predefinido de substitute, que substitui as instâncias de VM por novas instâncias com nomes gerados aleatoriamente.

gcloud

Quando emitir um comando rolling-action, inclua a flag --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]

REST

Chame o método patch num recurso de GIG regional ou zonal. No corpo do pedido, inclua o campo updatePolicy.replacementMethod:

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

Depois de fazer um pedido, pode monitorizar a atualização para saber quando esta terminou.

Atualize um grupo de instâncias geridas regional

Um GIG regional contém instâncias de VM distribuídas por várias zonas numa região, ao contrário de um GIG zonal, que contém apenas instâncias numa zona. Os MIGs regionais permitem distribuir as instâncias por mais do que uma zona para melhorar a disponibilidade da aplicação e suportar casos extremos em que uma zona falha ou um grupo inteiro de instâncias deixa de responder.

A execução de uma atualização num MIG regional é igual à execução de uma atualização num MIG zonal, com algumas exceções descritas abaixo. Quando inicia uma atualização de um MIG regional, o atualizador atualiza sempre as instâncias proporcionalmente e de forma uniforme em cada zona. Não pode escolher que instâncias em que zonas são atualizadas primeiro, nem pode optar por atualizar instâncias apenas numa zona.

Diferenças entre a atualização de MIGs regionais e zonais

Os MIGs regionais têm os seguintes valores de atualização predefinidos:

maxUnavailable=NUMBER_OF_ZONES
maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES é o número de zonas associadas ao MIG regional. Por predefinição, o número de zonas para um MIG regional é 3. No entanto, pode selecionar um número diferente.

Se estiver a usar números fixos ao especificar uma atualização, o número fixo tem de ser 0 ou igual ou superior ao número de zonas associadas ao MIG regional. Por exemplo, se o grupo estiver distribuído por três zonas, não pode definir maxSurge como 1 ou 2, porque o atualizador tem de criar uma instância adicional em cada uma das três zonas.

Use um número fixo ou uma percentagem em pedidos de atualização

Se especificar um número fixo nos pedidos de atualização, o número especificado é dividido pelo número de zonas no MIG regional e distribuído uniformemente. Por exemplo, se especificar maxSurge=10, o atualizador divide 10 pelo número de zonas na região e cria instâncias com base nesse número. Se o número de instâncias não for divisível uniformemente entre as zonas, o atualizador adiciona as instâncias restantes a uma zona aleatória. Assim, para 10 instâncias em três zonas, duas das zonas recebem 3 instâncias e uma zona recebe 4 instâncias. A mesma lógica é aplicada aos parâmetros maxUnavailable e targetSize para atualizações canary.

Só pode especificar uma percentagem se o MIG contiver 10 ou mais instâncias de VM. As percentagens são processadas de forma ligeiramente diferente consoante a situação:

Se especificar uma percentagem de instâncias de VM para uma atualização canary, o atualizador tenta distribuir as instâncias uniformemente pelas zonas. O resto é arredondado para cima ou para baixo em cada zona, mas a diferença total não é superior a 1 instância de VM por grupo. Por exemplo, para um MIG com 10 instâncias e uma percentagem de tamanho alvo de 25%, a implementação é feita em 2 a 3 instâncias de VM.
Se especificar uma percentagem para opções de atualização, como maxSurge e maxUnavailable, as percentagens são arredondadas de forma independente por zona.

O que se segue?

Saiba como ver informações sobre MIGs e instâncias geridas.
Saiba como criar modelos de instâncias.
Saiba como usar famílias de imagens e uma substituição contínua para atualizar a imagem do SO em todas as VMs num MIG.

Aplicar automaticamente atualizações de configuração de VM num MIG

Antes de começar

Console

gcloud

REST

Limitações

Inicie uma atualização gradual básica

Autorizações necessárias para esta tarefa

Consola

gcloud

REST

Configure as opções para a sua atualização

Atualizar tipo

Aumento máximo

Máximo indisponível

Tempo de espera mínimo

Ação mínima

Ação permitida mais disruptiva

Método de substituição

Exemplos de atualizações adicionais

Atualizações do Canary

Inicie uma atualização canary

Autorizações necessárias para esta tarefa

Consola

gcloud

REST

Implemente uma atualização canary

Consola

gcloud

REST

Monitorize atualizações

Estado do grupo

Autorizações necessárias para esta tarefa

Consola

gcloud

REST

Verifique se a implementação de uma atualização está concluída

Verifique se um grupo de instâncias geridas é estável

Ações atuais nas instâncias

Autorizações necessárias para esta tarefa

gcloud

REST

Reverta uma atualização

gcloud

REST

Pare uma atualização

Controle a velocidade de uma atualização contínua

Controle o nível de interrupção durante uma atualização contínua

Faça um reinício contínuo ou uma substituição

Consola

gcloud

REST

Exemplos adicionais de substituição/reinício

Preserve instance names

gcloud

REST

Atualize um grupo de instâncias geridas regional

Diferenças entre a atualização de MIGs regionais e zonais

Use um número fixo ou uma percentagem em pedidos de atualização

O que se segue?