Práticas recomendadas para upgrade do sistema operacional

Neste documento, descrevemos as práticas recomendadas e estratégias para fazer upgrade de sistemas operacionais em instâncias do Compute Engine. Saiba como fazer upgrade das principais versões do SO usando infraestrutura imutável, recriação de instâncias ou fluxos de trabalho no local, e como automatizar a aplicação de patches de segurança rotineira.

Quando uma versão do sistema operacional se aproxima do fim do suporte (EOS) ou do fim da vida útil (EOL), é necessário fazer upgrade para uma versão compatível para manter as atualizações de segurança, a compatibilidade de software e a integração da plataforma Cloud de Confiance by S3NS . Para mais informações sobre as fases de suporte, consulte Ciclo de vida dos sistemas operacionais.

Riscos de upgrades no local da versão principal do SO

Se você fizer um upgrade in-loco importante do sistema operacional, como atualizar o Debian 12 para 13, o RHEL 9 para 10 ou o Ubuntu 24.04 para 26.04 em uma instância de computação em execução, você vai introduzir riscos operacionais significativos em ambientes de nuvem. Ao contrário dos servidores físicos locais, as instâncias de computação dependem de pacotes especializados para que o ambiente guest se comunique com o hipervisor e o servidor de metadados do Compute Engine.

Ao fazer upgrade de um sistema operacional no local, você corre o risco dos seguintes modos de falha:

• Perda da conectividade SSH e RDP:os formatos de configuração para serviços de rede, regras de firewall no nível do convidado, como ufw ou firewalld, ou configurações do daemon SSH podem mudar entre versões do SO, interrompendo o acesso administrativo remoto.
• Interrupção do ambiente convidado:os pacotes google-guest-agent e google-oslogin gerenciam chaves SSH, contas de usuário, interfaces de rede e sincronização com metadados. Se os repositórios ou as dependências de pacotes forem interrompidos durante um upgrade de distribuição, o agente convidado poderá parar de ser executado, impedindo novos logins ou configurações de rede.
• Incompatibilidades com drivers de armazenamento e kernel:mudanças no kernel, no initramfs ou nos drivers para controladores de disco (como virtio-scsi ou NVMe) podem causar falhas de inicialização ou impedir que a instância de computação reconheça os volumes Persistent Disk anexados.
• Configurações inconsistentes para repositórios:os fornecedores de sistemas operacionais geralmente descontinuam ou substituem repositórios de pacotes legados e chaves de assinatura, o que pode fazer com que os gerenciadores de pacotes falhem no meio da atualização e deixem o sistema operacional em um estado irrecuperável e parcialmente instalado.

Para evitar esses riscos, use um modelo de infraestrutura imutável em vez de fazer upgrade das principais versões do SO nas instâncias de computação de produção.

Escolher a estratégia de upgrade certa

Dependendo se as cargas de trabalho são sem estado ou com estado, escolha uma das seguintes estratégias:

Infraestrutura imutável

A maneira mais segura e confiável de fazer upgrade dos sistemas operacionais é usando o modelo de infraestrutura imutável. Em vez de modificar instâncias de computação em execução, você cria novas instâncias de computação com base em imagens de SO públicas ou personalizadas atualizadas e substitui as instâncias legadas.

Se as cargas de trabalho forem executadas em grupos gerenciados de instâncias (MIGs), será possível automatizar esse lançamento sem tempo de inatividade do serviço.

Criar uma imagem atualizada

1. Selecione a imagem pública mais recente do SO na lista de Detalhes do sistema operacional compatíveis ou crie uma imagem de base personalizada usando o Image Builder ou ferramentas automatizadas, como Packer ou Ansible.
2. Verifique se o aplicativo e as dependências foram instalados e executados corretamente na nova versão do SO em um ambiente de teste de não produção.
3. Crie uma imagem de SO personalizada ou faça referência à nova família de imagens públicas. Para mais informações, consulte Práticas recomendadas para famílias de imagens.

Criar um modelo de instância atualizado

Crie um modelo de instância que faça referência à imagem do SO atualizada:

gcloud compute instance-templates create NEW_TEMPLATE_NAME \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --machine-type=MACHINE_TYPE \
    --region=REGION

Substitua:

• NEW_TEMPLATE_NAME: o nome do novo modelo de instância;
• IMAGE_FAMILY: a família de imagens do SO de destino, como debian-12 ou ubuntu-2404-lts.
• IMAGE_PROJECT: o projeto que hospeda a imagem, como debian-cloud ou ubuntu-os-cloud.
• MACHINE_TYPE: o tipo de máquina das instâncias.
• REGION: a região do Compute Engine em que você cria o modelo.

Fazer uma substituição gradual no MIG

Aplique o modelo atualizado ao grupo gerenciado de instâncias e inicie uma substituição gradual:

gcloud compute instance-groups managed rolling-action replace MIG_NAME \
    --max-surge=20% \
    --max-unavailable=0 \
    --region=REGION

Substitua:

• MIG_NAME: o nome do seu grupo gerenciado de instâncias.
• REGION: a região em que o MIG está localizado. Para MIGs zonais, substitua --region=REGION por --zone=ZONE.

Recriar instâncias de computação com Persistent Disk

Se você executar instâncias de computação autônomas com estado em que os aplicativos armazenam configuração e dados em volumes de Persistent Disk, será possível fazer upgrade do sistema operacional recriando a instância de computação com um disco de inicialização novo e preservando os discos de dados.

Fazer backup de todos os discos

Antes de modificar a infraestrutura, crie snapshots padrão ou regionais do disco de inicialização e de todos os volumes do Persistent Disk anexados:

gcloud compute disks snapshot BOOT_DISK_NAME \
    --snapshot-names=SNAPSHOT_NAME \
    --zone=ZONE

Substitua:

• BOOT_DISK_NAME: o nome do disco de inicialização a ser copiado.
• SNAPSHOT_NAME: o nome do novo snapshot do Persistent Disk.
• ZONE: a zona em que o disco está localizado.

Para mais informações, consulte Criar e gerenciar snapshots.

Separar os dados do aplicativo do disco de inicialização

Verifique se os dados do aplicativo, os arquivos de banco de dados e os registros de transações estão em volumes secundários do Persistent Disk ou em serviços externos, como o Cloud Storage ou o Cloud SQL, e não no disco de inicialização.

Criar a instância de computação substituta

1. Pare a instância de computação legada para garantir que os dados permaneçam consistentes:

   gcloud compute instances stop LEGACY_INSTANCE_NAME --zone=ZONE
   

2. Remova os discos de dados secundários da instância de computação legada:

   gcloud compute instances detach-disk LEGACY_INSTANCE_NAME \
       --disk=DATA_DISK_NAME \
       --zone=ZONE
   

3. Crie uma instância de computação com a versão do SO de destino:

   gcloud compute instances create NEW_INSTANCE_NAME \
       --image-family=IMAGE_FAMILY \
       --image-project=IMAGE_PROJECT \
       --zone=ZONE \
       --machine-type=MACHINE_TYPE
   

4. Anexe os discos de dados secundários atuais à nova instância de computação:

   gcloud compute instances attach-disk NEW_INSTANCE_NAME \
       --disk=DATA_DISK_NAME \
       --zone=ZONE
   

5. Conecte-se à nova instância de computação, ative os sistemas de arquivos nos discos de dados e inicie os serviços de aplicativos.

6. Se necessário, reatribua os endereços IP externo estáticos ou registros DNS para apontar para a nova instância de computação.

Substitua:

• LEGACY_INSTANCE_NAME: o nome da instância de computação que você está atualizando.
• DATA_DISK_NAME: o nome do volume secundário do Persistent Disk a ser removido e anexado novamente.
• NEW_INSTANCE_NAME: o nome da nova instância de computação de substituição.
• IMAGE_FAMILY: a família de imagens da versão do SO de destino, como debian-13 ou ubuntu-2604-lts.
• IMAGE_PROJECT: o projeto que fornece a imagem, como debian-cloud ou ubuntu-os-cloud.
• MACHINE_TYPE: o tipo de máquina da nova instância de computação.
• ZONE: a zona em que as instâncias de computação estão localizadas.

Upgrades no local do SO

Se você não puder recriar a instância de computação devido a configurações manuais complexas e precisar fazer um upgrade no local, conclua estas verificações pré-upgrade e siga as instruções específicas da distribuição com cuidado.

Lista de verificação pré-upgrade

Conclua todas as etapas desta lista de verificação antes de iniciar um upgrade no local:

1. Tire um snapshot do disco de inicialização antes de executar qualquer comando de upgrade. Esse é seu principal mecanismo de recuperação se o upgrade falhar.

2. Atualize todos os pacotes atuais e o ambiente convidado para Cloud de Confiance com as versões mais recentes disponíveis para sua versão atual do SO:

   • Para Debian e Ubuntu: sudo apt update && sudo apt dist-upgrade -y
   • Para RHEL, CentOS e Rocky Linux: sudo dnf upgrade -y
   • Para SLES: sudo zypper update

   Verifique se os pacotes google-guest-agent e google-oslogin estão ativos:

   sudo systemctl status google-guest-agent
   

3. Ative o console serial interativo na instância de computação para poder resolver problemas e fazer login se o SSH ou a rede pararem de funcionar durante o upgrade:

   gcloud compute instances add-metadata INSTANCE_NAME \
       --metadata=serial-port-enable=TRUE \
       --zone=ZONE
   

   Substitua:

   • INSTANCE_NAME: o nome da instância de computação.
   • ZONE: a zona em que a instância de computação está localizada.

   Para mais informações, consulte Como interagir com o console serial.

4. Se você usa o Login do SO ou chaves SSH gerenciadas pelo agente convidado, defina uma senha para uma conta de usuário local com privilégios administrativos, como com sudo passwd USERNAME, para que você possa fazer login pelo console serial se o Login do SO estiver temporariamente indisponível durante o upgrade. Substitua USERNAME pelo nome da sua conta de usuário local.

5. Verifique se a partição raiz / e a partição de inicialização /boot têm espaço livre suficiente, com pelo menos 5 GB recomendados, para baixar e descompactar novos pacotes:

   df -h / /boot
   

6. Verifique se os agentes de terceiros para segurança, backup ou monitoramento (incluindo o agente de operações do Google Cloud) são compatíveis com a versão de destino do sistema operacional.

Procedimentos de upgrade no local

As seções a seguir fornecem fluxos de trabalho de alto nível para sistemas operacionais comuns. Sempre consulte a documentação oficial de upgrade do seu sistema operacional antes de fazer o upgrade.

Automatizar o gerenciamento de patches para atualizações secundárias

Distinga upgrades de versões principais do SO de atualizações secundárias e patches de segurança de rotina. Para manutenção regular de software, atualizações de pacotes e aplicação de patches em CVEs, use o patch do VM Manager para automatizar a implantação de patches em toda a sua frota de instâncias de computação.

Siga estas práticas recomendadas para gerenciar patches automaticamente:

• Organize instâncias com rótulos:atribua rótulos com metadados, como env:dev, env:prod e tier:frontend, para segmentar grupos específicos de instâncias de computação para patches.
• Implante zona por zona:faça o escalonamento dos jobs de patch em zonas e regiões. Nunca aplique jobs de patch a todas as zonas simultaneamente em ambientes de produção.
• Use scripts pré-patch e pós-patch:configure scripts pré-patch para drenar conexões ou pausar serviços com segurança e configure scripts pós-patch para executar verificações de integridade antes de retornar instâncias ao serviço.
• Monitorar a conformidade de patches:use o painel do VM Manager no Cloud de Confiance console para acompanhar a conformidade com patches e o status das vulnerabilidades em toda a sua frota de instâncias de computação.

Para mais informações, consulte Criar jobs de patch.

Verificação e solução de problemas pós-upgrade

Depois de concluir um upgrade, siga estas etapas de verificação:

1. Confirme se o SSH ou o RDP se conecta normalmente.

2. Verifique se o agente convidado e o serviço do Login do SO estão ativos e informando um status íntegro:

   sudo systemctl status google-guest-agent
   sudo systemctl status google-oslogin-cache
   

3. Verifique se a instância de computação pode consultar o servidor de metadados da instância:

   curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/id
   

4. Confirme se os serviços de aplicativo foram iniciados e se as verificações de integridade dos balanceadores de carga informam instâncias íntegras.

Resolver problemas de perda de conexão

Se você perder o acesso SSH ou RDP à instância de computação após um upgrade no local, siga estas etapas de solução de problemas:

1. Verifique o registro do console para ver se há kernel panics, erros durante a inicialização do serviço ou falhas durante a inicialização da rede:

   gcloud compute instances tail-serial-port-output INSTANCE_NAME \
       --zone=ZONE
   

2. Se você ativou o console serial interativo antes do upgrade, conecte-se diretamente ao terminal:

   gcloud compute connect-to-serial-port INSTANCE_NAME \
       --zone=ZONE
   

   Faça login usando as credenciais do usuário local, inspecione os registros do sistema com journalctl -xe e reinicie a rede ou o serviço google-guest-agent.

   Substitua:

   • INSTANCE_NAME: o nome da instância de computação com o problema a ser solucionado.
   • ZONE: a zona em que a instância de computação está localizada.

3. Se o sistema operacional não puder ser inicializado ou recuperado, crie um novo volume de Persistent Disk com o snapshot que você fez antes do upgrade e anexe-o como o disco de inicialização da instância de computação. Para conferir as etapas detalhadas de recuperação, consulte Restaurar um snapshot em um novo disco.

A seguir

• Saiba mais sobre os estágios do ciclo de vida do sistema operacional e as políticas de descontinuação.
• Revise as práticas recomendadas de gerenciamento de imagens.
• Entenda os componentes e daemons do ambiente de convidado.
• Configure jobs de patch automatizados usando o VM Manager.
• Faça um upgrade no local do Windows Server.