Mudar a AMI que as suas instâncias usam equivale a trocar o alicerce do seu serviço enquanto ele continua a funcionar. Fazê-lo mal significa cortes; fazê-lo bem é quase invisível para o utilizador. A boa notícia: existem padrões comprovados que tornam esta migração segura e reversível.
A base comum é não editar instâncias vivas, mas lançar instâncias novas com a AMI nova e transferir o tráfego de forma controlada.
Antes de migrar: prepare o terreno
- Teste a nova AMI num ambiente de staging idêntico ao de produção.
- Health checks fiáveis: defina verificações que confirmem que uma instância nova está mesmo saudável.
- Plano de rollback: tenha pronta a versão anterior e o procedimento para regressar a ela.
- Observabilidade: métricas e alertas para detetar regressões de imediato.
Estratégias de migração sem downtime
| Estratégia | Como funciona | Ideal para |
|---|---|---|
| Rolling update | Substitui instâncias por lotes, aos poucos | Serviços num Auto Scaling Group |
| Blue/Green | Levanta um ambiente novo e muda o tráfego de uma vez | Migrações com rollback instantâneo |
| Canary | Envia uma pequena percentagem de tráfego para a versão nova | Validar em produção com risco baixo |
Três padrões para mudar de AMI sem interromper o serviço.
Rolling update
Atualiza o Launch Template com a nova AMI e o Auto Scaling Group substitui as instâncias por vagas: lança novas, espera que passem o health check e retira as antigas. Simples e sem infraestrutura extra, ainda que durante algum tempo convivam as duas versões.
Blue/Green
Levanta um ambiente paralelo (green) com a nova AMI enquanto o atual (blue) continua a servir. Quando o green está validado, redireciona o tráfego no balanceador ou no DNS. Se algo falhar, volta ao blue em segundos. É o padrão com rollback mais rápido, em troca de duplicar recursos temporariamente.
Canary
Envia uma pequena fração do tráfego para instâncias com a nova AMI e observa. Se as métricas se mantiverem, aumenta a percentagem progressivamente até 100 %. Minimiza o raio de impacto de um problema inesperado.
Depois de migrar
- Vigie métricas e logs durante um tempo prudente antes de dar a migração por boa.
- Marque a AMI antiga como obsoleta para que não seja relançada por engano.
- Documente a versão implantada e o motivo da mudança.
- Não apague a imagem anterior de imediato: guarde-a caso precise de rollback.
Perguntas frequentes
Que estratégia é melhor para zero downtime?
O blue/green oferece o rollback mais rápido; o rolling update é mais simples e económico; o canary minimiza o risco validando em produção. A escolha depende da sua tolerância ao risco e do seu orçamento de infraestrutura.
Preciso de duplicar a infraestrutura para migrar?
Só com blue/green, e de forma temporária. Com rolling update ou canary reutiliza o mesmo grupo e vai substituindo instâncias, sem duplicar todo o ambiente.
Como garanto que consigo voltar atrás?
Conserve a AMI anterior e o seu Launch Template, defina health checks fiáveis e tenha o procedimento de rollback testado antes de começar a migração.
Na imaxe.cloud versionamos as nossas imagens para que migrar entre versões seja previsível e reversível.
