Mover uma VM de zona: ache tudo que aponta para o IP antes de mudar

Sábado, 10h, a VM do ERP foi recriada na zona nova a partir do snapshot, subiu limpa e o painel abriu. Às 10h40 o financeiro liga: a conciliação com o banco parou. A API do banco só aceita chamadas de um IP liberado no contrato, e a VM nova saía por outro. Às 11h, o e-mail de cobrança começou a cair no spam porque o registro SPF listava o IP antigo. Nada disso estava no plano, porque ninguém sabia que dependia do endereço.

A resposta curta: mover a VM é fácil; o trabalho é descobrir tudo que aponta para o endereço dela. Antes da janela, levante quem chega na máquina (DNS, outras VMs, configurações com IP escrito) e para onde ela sai com o próprio IP (parceiros que liberam o seu IP, SPF, listas de acesso). Reserve os IPs como estáticos quando possível, teste o destino sem mexer no DNS e só então vire o tráfego.

Por que o endereço não vai junto

No Google Cloud, a zona é parte da identidade da VM. Na prática, mover é recriar: você cria uma instância nova a partir de um snapshot ou imagem do disco e depois apaga a antiga. Disco, interface de rede e endereço efêmero pertencem à instância antiga. O passo a passo com gcloud, incluindo disco e tags de firewall, está em Mover VM de zona no Google Cloud. Este guia cuida do que vem antes: o mapa de dependências.

Duas regras ajudam a planejar. Endereços IP externos estáticos são regionais, então dentro da mesma região dá para reaproveitar o endereço reservado na VM nova; se ele for efêmero, ele se perde junto com a VM antiga. E o IP interno também muda, a menos que você reserve o mesmo endereço na sub-rede. Mudar de região é mais drástico: o IP externo muda de qualquer jeito, e o mapa abaixo deixa de ser opcional.

Exemplo: o ERP em São Paulo

O caso é a VM erp-01, na zona southamerica-east1-a, que vai para southamerica-east1-b. Ela tem IP externo 203.0.113.20 e IP interno 10.158.0.12, roda o ERP, envia e-mail de cobrança e consulta a API do banco. Os endereços aqui são fictícios.

1. Descubra quem conversa com a máquina

Na própria VM, durante um dia útil, veja as conexões estabelecidas. Cada IP de origem é alguém que vai precisar achar a máquina nova:

sudo ss -tnp state established
sudo ss -tn state established '( sport = :3306 or sport = :443 )'

No ERP, isso revelou duas VMs de relatório conectando direto no MySQL pelo IP interno, sem nome nenhum.

2. Ache o IP escrito em configurações

Procure os dois endereços nas configurações desta e das outras máquinas do projeto:

sudo grep -rIn --exclude-dir=.git -e "203.0.113.20" -e "10.158.0.12" /etc /srv /opt 2>/dev/null

Arquivos de ambiente da aplicação, /etc/hosts, configuração de proxy reverso e scripts de cron são os suspeitos de sempre. Cada ocorrência vira uma linha no plano: trocar por um nome DNS antes da migração, ou atualizar na janela.

3. Liste os registros DNS que apontam para ela

gcloud dns record-sets list --zone=exemplo-com-br --format="table(name,type,rrdatas)" | grep 203.0.113.20
dig +short TXT exemplo.com.br

O primeiro comando acha os registros A da zona hospedada no Cloud DNS; se o DNS estiver em outro provedor, exporte a zona de lá. O segundo mostra o SPF: se aparecer ip4:203.0.113.20, o e-mail enviado pela VM depende desse IP. Se o nome vai mudar de alvo, baixe o TTL com dias de antecedência, como em Antes de mudar o DNS, baixe o TTL.

4. Descubra com que IP a máquina sai

curl -s https://ifconfig.me

Esse é o endereço que parceiros veem. Se a VM sai pelo próprio IP externo, ele muda junto com ela, a menos que seja estático e reaproveitado. Se a saída é por Cloud NAT, o IP de saída é o do NAT e não muda com a VM. Pergunte ao financeiro, ao fiscal e a quem cuida das integrações quem liberou "o IP do servidor": banco, gateway de pagamento, fornecedor de EDI, firewall de cliente.

5. Prenda os endereços antes de mexer

Se o IP externo é efêmero, promova-o a estático antes de desligar a VM antiga; o console e o gcloud permitem fazer isso com o endereço em uso. Faça o mesmo com o IP interno, reservando-o na sub-rede. Com os dois reservados, a VM nova pode recebê-los, e boa parte do mapa deixa de importar. Guarde também as tags de rede e a conta de serviço da VM antiga, porque as regras de firewall dependem delas.

Testar o destino antes de virar o nome

Com a VM nova no ar, e antes de mexer no DNS ou mover o IP, teste a aplicação forçando o nome a resolver para o endereço novo só no seu comando:

curl -sv --resolve erp.exemplo.com.br:443:198.51.100.40 https://erp.exemplo.com.br/health

O --resolve faz o curl usar 198.51.100.40 para aquele nome e porta, com o certificado e o cabeçalho de host corretos. Assim você vê o ERP novo respondendo como os usuários vão ver, sem que eles vejam ainda. Teste também as saídas: da VM nova, chame a API do banco em homologação e confirme que ela aceita.

Se o disco foi recriado de snapshot, as chaves de host do SSH vêm junto e nada muda. Se a VM foi montada do zero, os clientes SSH vão alertar que a identidade do host mudou. Confirme que a troca é sua e só então limpe a entrada antiga com ssh-keygen -R erp.exemplo.com.br. Mais sobre acesso em Chave SSH na VM.

A planilha que sai desse levantamento

No fim, o ERP tinha nove dependências do endereço: três registros DNS, o SPF, duas VMs de relatório com IP interno fixo, a API do banco, o gateway de pagamento e um /etc/hosts num servidor de backup. Cada uma ganhou dono, ação e teste. A migração seguinte levou 25 minutos e ninguém ligou no sábado.

Erros comuns

• Tratar a mudança de zona como um clique. A VM nova sobe, e tudo que dependia do endereço antigo para sem aviso.
• Esquecer o IP de saída. Bancos, gateways e clientes que liberaram o seu IP recusam as chamadas da máquina nova.
• Esquecer o SPF. O e-mail enviado pela VM passa a falhar na verificação e vai para o spam.
• Deixar o IP efêmero. Ao apagar a VM antiga, o endereço some e não volta.
• Virar o DNS sem testar o destino. Os usuários descobrem o erro de configuração antes de você.
• Apagar a VM antiga na mesma janela. Sem ela, não há caminho de volta se algo aparecer na segunda-feira.

Checklist

• Conexões de entrada levantadas com ss em dia útil.
• IPs externo e interno procurados em configurações de todas as máquinas do projeto.
• Registros DNS e SPF que citam o IP listados.
• IP de saída conhecido e parceiros que o liberaram identificados.
• Endereços promovidos a estáticos ou plano de troca combinado com cada parceiro.
• Destino testado com curl --resolve e saídas testadas antes do corte.
• VM antiga mantida desligada, não apagada, por alguns dias.

Se o IP da sua VM principal mudasse hoje, quais sistemas parariam? Se a lista que vem à cabeça tem só o DNS, rode o ss e o grep desta página antes de responder.