VM Extension Manager dispensa scripts — mas a política errada escala o erro

Para usar o VM Extension Manager com risco controlado, habilite as APIs necessárias, confirme os pré-requisitos das VMs, delimite um grupo piloto por rótulos e aplique primeiro uma política zonal. Só depois de validar instalação, saúde e impacto nos recursos, replique a especificação em uma política global com rollout lento.

O serviço dispensa scripts de instalação por VM apenas para as extensões compatíveis: a política declara o estado desejado e o guest agent o aplica às máquinas selecionadas. A mesma automação amplia um erro de escopo; sem seletores, uma política pode alcançar todas as VMs da zona ou, no caso de uma política global, todas as zonas do projeto.

1. Confirme o que pode ser migrado

Comece pelo inventário da instalação atual: extensão, versão, configuração, projeto, zonas, sistemas operacionais e automação que hoje administra cada VM. Não retire o script legado antes de estabilizar a política, mas também não deixe os dois mecanismos alterarem o mesmo componente durante o teste; defina qual deles será a autoridade em cada etapa.

A documentação atual do VM Extension Manager limita o catálogo ao Ops Agent, à Extension for SAP e à Extension for Compute Workloads. Ela exige Cloud Monitoring API e Cloud Logging API para o Ops Agent, Workload Manager API para as outras duas extensões, não oferece suporte a SLES e Ubuntu e estabelece o limite de 100 políticas por zona em cada projeto.

Habilite também a Compute Engine API, confirme que o guest agent está na versão 20241209.01 ou posterior e conceda ao responsável pela criação o papel VM Extension Policy Admin, ou permissões equivalentes. O sistema operacional ainda precisa ser aceito pela extensão escolhida. Componentes fora do catálogo continuam dependentes da automação mantida pela equipe.

2. Faça dos rótulos o limite do erro

Crie um rótulo exclusivo para o anel piloto, como vm-extension-ring=pilot, e aplique-o a poucas VMs representativas. Inclua variações reais de sistema, tamanho e carga, mas não comece por máquinas cuja interrupção derrube um serviço crítico. Um rótulo amplo como env=prod não separa validação de distribuição.

Dentro de um seletor, a VM precisa corresponder a todos os rótulos definidos. Seletores adicionais ampliam o conjunto, pois basta corresponder a um deles. Antes de criar a política, gere uma lista das instâncias que atendem à expressão planejada; omitir os seletores faz a política atingir todas as VMs de seu escopo.

Trate a prioridade como parte da especificação e não como detalhe operacional. Use valores distintos para políticas que possam declarar a mesma extensão, registre a finalidade de cada uma e verifique qual política venceu em uma VM do piloto. Isso evita que uma regra antiga ou temporária substitua silenciosamente a configuração pretendida.

3. Valide a especificação em uma única zona

A política zonal reduz o primeiro raio de impacto a uma zona. Crie-a com o rótulo do piloto, a extensão desejada, a configuração registrada em controle de versão e, quando houver suporte, uma versão fixada. Não use a ausência de erros no comando de criação como prova de que a extensão foi instalada.

1. Escolha uma zona que contenha as VMs do piloto.
2. Associe somente o seletor exclusivo desse anel.
3. Declare extensão, configuração e versão pretendidas.
4. Registre a especificação anterior e a nova no mesmo processo de mudança.
5. Aguarde a aplicação e investigue qualquer falha antes de ampliar o grupo.

A aplicação da política, incluindo novas tentativas, pode levar até uma hora. Reserve esse período na janela de validação e não altere os rótulos enquanto ainda houver máquinas pendentes. Para o Ops Agent, é possível fixar uma versão compatível; nas extensões de SAP e Compute Workloads, o serviço trabalha com a versão mais recente.

4. Passe ao escopo global sem perder o freio

Reproduza no escopo global somente a especificação aprovada no piloto e mantenha slow_rollout. O procedimento oficial de criação de políticas informa que esse é o plano padrão e distribui a mudança ao longo de cinco dias; fast_rollout envia a política imediatamente a todas as zonas. Um plano personalizado pode definir ondas, locais, espera de validação e limites de concorrência, mas sua criação usa a API REST, e o console não permite selecioná-lo.

A política global não é aplicada diretamente às VMs. Durante o rollout, o serviço cria políticas nas zonas abrangidas pelo plano; por isso, atualizar uma especificação global incorreta propaga o mesmo defeito entre locais. Revise extensão, configuração, seletores e conflitos antes de cada atualização.

A documentação de criação contém uma inconsistência que merece cautela: a seção geral, o console e a referência zonal dizem que números menores representam prioridade maior, enquanto a descrição do parâmetro do comando global afirma o contrário. Adote a regra geral de número menor como prioridade maior, mas confirme a política efetiva em uma VM do piloto antes de liberar outras zonas.

5. Defina o avanço e a reversão antes da produção

O gate de avanço deve combinar três sinais: aplicação concluída, extensão saudável e consumo de CPU e memória dentro da linha de base definida pela equipe. Consulte o estado por VM, os registros do guest agent e a telemetria da carga. Uma instalação concluída não basta se a extensão reinicia, perde saúde ou pressiona recursos da máquina.

Não trate a exclusão da política como restauração da configuração anterior. Para desfazer uma mudança de versão ou configuração, reaplique a especificação previamente registrada por meio de uma atualização da política e valide novamente no piloto. Se a intenção for retirar a extensão, exclua a política.

As regras de atualização e desinstalação indicam que a exclusão remove a extensão das VMs acessíveis, normalmente em até um minuto; ela permanece quando outra política aplicável também declara a mesma extensão. Uma VM inacessível é tratada quando volta a se comunicar com o serviço.

Para recuperar apenas máquinas com falha, acrescente a elas um rótulo temporário e crie uma política mais prioritária com a configuração corretiva. Depois da recuperação, exclua essa política e remova o rótulo adicional, verificando antes que a política normal continue aplicável. O script antigo só pode ser aposentado quando instalação, observabilidade e reversão tiverem funcionado no piloto e no rollout controlado.

Leia também:

• Gemini chega aos bancos com mais de 50 habilidades — mas ainda em prévia
• Twitch libera patrocínios para afiliados, mas exige certificação
• Política de IA no trabalho: o documento mínimo para proteger dados e decisões