Cambiare la AMI usata dalle tue istanze equivale a cambiare le fondamenta del servizio mentre continua a funzionare. Farlo male significa interruzioni; farlo bene è quasi invisibile per l’utente. La buona notizia: esistono modelli collaudati che rendono questa migrazione sicura e reversibile.
La base comune è non modificare istanze vive, ma lanciare istanze nuove con la AMI nuova e spostare il traffico in modo controllato.
Prima di migrare: prepara il terreno
- Prova la nuova AMI in un ambiente di staging identico alla produzione.
- Health check affidabili: definisci controlli che confermino che una nuova istanza è davvero sana.
- Piano di rollback: tieni pronta la versione precedente e la procedura per tornarci.
- Osservabilità: metriche e allarmi per rilevare regressioni all’istante.
Strategie di migrazione senza downtime
| Strategia | Come funziona | Ideale per |
|---|---|---|
| Rolling update | Sostituisce le istanze a lotti, poco alla volta | Servizi in un Auto Scaling Group |
| Blue/Green | Alzi un ambiente nuovo e sposti il traffico in un colpo | Migrazioni con rollback istantaneo |
| Canary | Invii una piccola percentuale di traffico alla versione nuova | Validare in produzione a basso rischio |
Tre modelli per cambiare AMI senza interrompere il servizio.
Rolling update
Aggiorni il Launch Template con la nuova AMI e l’Auto Scaling Group sostituisce le istanze a ondate: ne lancia di nuove, aspetta che superino l’health check e ritira le vecchie. Semplice e senza infrastruttura extra, anche se per un po’ convivono entrambe le versioni.
Blue/Green
Alzi un ambiente parallelo (green) con la nuova AMI mentre quello attuale (blue) continua a servire. Quando green è validato, reindirizzi il traffico sul bilanciatore o nel DNS. Se qualcosa va storto, torni a blue in pochi secondi. È il modello con il rollback più rapido, al prezzo di duplicare temporaneamente le risorse.
Canary
Invii una piccola frazione del traffico a istanze con la nuova AMI e osservi. Se le metriche tengono, aumenti la percentuale progressivamente fino al 100 %. Minimizza il raggio d’impatto di un problema inatteso.
Dopo la migrazione
- Sorveglia metriche e log per un tempo ragionevole prima di dare la migrazione per buona.
- Marca la vecchia AMI come deprecata perché non venga rilanciata per errore.
- Documenta la versione rilasciata e il motivo del cambiamento.
- Non cancellare subito l’immagine precedente: conservala in caso di rollback.
Domande frequenti
Quale strategia è la migliore per zero downtime?
Blue/Green offre il rollback più rapido; il rolling update è più semplice ed economico; il canary minimizza il rischio validando in produzione. La scelta dipende dalla tua tolleranza al rischio e dal budget di infrastruttura.
Devo duplicare l’infrastruttura per migrare?
Solo con blue/green, e in modo temporaneo. Con rolling update o canary riusi lo stesso gruppo e sostituisci le istanze via via, senza duplicare l’intero ambiente.
Come garantisco di poter tornare indietro?
Conserva la AMI precedente e il suo Launch Template, definisci health check affidabili e prova la procedura di rollback prima di iniziare la migrazione.
In imaxe.cloud versioniamo le nostre immagini perché migrare tra versioni sia prevedibile e reversibile.
