Come Migrare il Modello DataSunrise CloudFormation da Launch Configuration (LC) a Risorsa Launch Template (LT) nel Gruppo Auto Scaling
Migrare da un gruppo AWS Launch Configuration (LC basato su Auto Scaling (ASG) a una risorsa Launch Template (LT) offre vantaggi significativi per la gestione delle distribuzioni DataSunrise, come maggiore flessibilità e supporto per funzionalità moderne di AWS e del sistema operativo. In molti casi, la migrazione può essere eseguita semplicemente sostituendo lo stack esistente con un modello da GitHub, a condizione che vengano prese le necessarie precauzioni per prevenire interruzioni, specialmente con le istanze AWS RDS (DSDictionaryDB e DSAuditDB).
Questa guida delinea i passaggi e le considerazioni chiave per migrare il modello CloudFormation, incluso come gestire le istanze RDS e le personalizzazioni per garantire una transizione fluida e senza interruzioni.
Considerazioni Chiave per la Migrazione
- Vantaggi del Launch Template:
- Versioning. Si possono mantenere più versioni di un Launch Template, fornendo flessibilità per futuri aggiornamenti o rollback.
- Supporto delle Funzionalità. Sono supportate nuove funzionalità come T2 Unlimited, rete avanzata e IPv6.
- Compatibilità del Sistema Operativo. LT supporta nuove distribuzioni del sistema operativo come RHEL8 e Amazon Linux 2023, che sono richiesti per eseguire script Python 3 in DataSunrise.
- Aggiornamento Semplificato dello Stack con Modello Pre-Costruito:
- Se non si utilizzano script o strumenti personalizzati, la migrazione può essere eseguita sostituendo semplicemente lo stack CloudFormation esistente con il modello pre-costruito da GitHub.
- Assicurarsi che vengano prese le misure necessarie per evitare che le istanze RDS usate da DataSunrise vengano sostituite o ricreate, poiché questo potrebbe comportare una perdita di dati.
Passaggi per Migrare il Modello CloudFormation
- Backup e Revisione dello Stack Esistente
- Fare un backup del modello CloudFormation corrente e creare snapshot delle tue istanze RDS (DSDictionaryDB e DSAuditDB) per salvaguardare contro la perdita di dati.
- Rivedere eventuali script personalizzati o strumenti di terze parti collegati alla tua Launch Configuration esistente per valutare se saranno necessari ulteriori passaggi oltre all’uso del modello GitHub.
- Scaricare il Nuovo Modello da GitHub
- Scaricare il nuovo modello CloudFormation basato su Launch Template (LT) dal repository ufficiale GitHub di DataSunrise.
- Questo modello è pronto per l’uso se l’attuale configurazione non coinvolge script o strumenti personalizzati, semplificando il processo.
- Assicurarsi che le Istanze RDS Non Vengano Aggiornate
- Il passaggio più critico in questa migrazione è assicurarsi che le istanze AWS RDS (DSDictionaryDB e DSAuditDB) non vengano ricreate o sostituite durante l’aggiornamento dello stack. La sostituzione accidentale potrebbe portare alla perdita di dati.
- Revisione della Mapping dei Consts:
- EngineVersionPg, EngineVersionMs, EngineVersionMy;
- AuditAuroraEngineVersionPg, AuditAuroraEngineVersionMy;
- ParameterGroupFamilyPg, ParameterGroupFamilyMy, DictionaryParameterGroupFamilyMs;
- AuditParameterGroupFamilyMs, ParameterGroupFamilyPgCluster, ParameterGroupFamilyMyCluster.
- Applicare le Politiche di Retention:
- Eseguire l’Aggiornamento dello Stack
- Sostituire lo stack CloudFormation esistente con il nuovo modello basato su LT da GitHub.
- Validare il modello utilizzando gli strumenti di validazione incorporati in AWS CloudFormation per catturare eventuali errori di sintassi o configurazione.
- Procedere con l’aggiornamento dello stack e monitorarlo attentamente per assicurarsi che non avvengano aggiornamenti non intenzionali alle istanze RDS.
- Migrare Script Personalizzati (Se Necessario)
- Aggiornare Script Python per Compatibilità (Se Necessario)
- Verificare la Compatibilità degli Strumenti di Terze Parti (Se Necessario)
- Se gli strumenti di terze parti sono installati tramite script User Data, verificare con i venditori che questi strumenti siano compatibili con i nuovi sistemi operativi (RHEL8 o AL2023).
- Installare eventuali aggiornamenti necessari per garantire la compatibilità con i nuovi ambienti.
- Monitorare l’Aggiornamento dello Stack
- Dopo aver avviato l’aggiornamento dello stack, monitorare lo stato delle istanze EC2 e RDS per assicurarsi che non vengano sostituite o ricreate.
- Verificare che le nuove istanze basate sul Launch Template funzionino come previsto.
- Eseguire Test Post-Migrazione
- Condurre test funzionali per confermare che l’applicazione DataSunrise e i servizi associati funzionino correttamente.
- Controllare che le istanze RDS (DSDictionaryDB e DSAuditDB) mantengano i loro dati e non vengano ricreate.
- Assicurarsi che eventuali script personalizzati o strumenti di terze parti migrati funzionino correttamente nelle nuove istanze.
- Terminare le Istanze Lanciate Utilizzando la Vecchia Launch Configuration (LC)
- Una volta confermato che le nuove istanze EC2 lanciate dal Launch Template (LT) funzionano correttamente, terminare eventuali istanze EC2 che utilizzano ancora la vecchia risorsa Launch Configuration (LC).
- Questo passaggio finale assicura che il gruppo Auto Scaling gestisca solo le istanze create utilizzando il nuovo Launch Template, che supporta funzionalità e configurazioni moderne.
- Piano di Rollback
- Se dovessero sorgere problemi durante l’aggiornamento, iniziare un rollback utilizzando la funzione di rollback di CloudFormation per ripristinare lo stack precedente.
- In caso di problemi relativi a RDS, ripristinare i dati dai snapshot creati prima dell’aggiornamento.
Nel modello, la sezione di mapping dei Consts definisce le versioni del motore e i gruppi di parametri per le istanze RDS. Questi parametri includono:
Assicurarsi che questi valori corrispondano alle impostazioni effettive delle istanze RDS esistenti. Eventuali discrepanze potrebbero innescare la sostituzione delle istanze RDS durante l’aggiornamento.
Usare la politica Retain per le istanze RDS specificando DeletionPolicy: Retain nel modello CloudFormation. Questo assicura che i database non vengano eliminati se lo stack tenta di ricrearli.
Configurare UpdatePolicy per prevenire la sostituzione simultanea di risorse critiche.
Se la tua distribuzione attuale include script personalizzati nella chiave di metadati AWS::CloudFormation::Init, è necessario migrare questi script nel nuovo Launch Template.
Per questo, rivedere gli script esistenti e copiare quelli necessari nelle sezioni corrispondenti del nuovo Launch Template.
Con il nuovo Launch Template, le istanze DataSunrise saranno eseguite su RHEL8 o Amazon Linux 2023, che usano Python 3 per default. Se i tuoi script personalizzati sono stati scritti in Python 2, essi devono essere aggiornati per la compatibilità con Python 3.
Aggiornare le istruzioni print, sostituire xrange() con range(), e risolvere altre sintassi specifiche di Python 2. Testare gli script aggiornati in un ambiente non di produzione per confermare la compatibilità con Python 3.
Conclusione
Migrare da Launch Configuration (LC) a Launch Template (LT) in DataSunrise può spesso essere un processo semplice se non ci sono personalizzazioni dello stack. Nella maggior parte dei casi, è possibile sostituire semplicemente lo stack CloudFormation esistente con il modello pre-costruito da GitHub. Tuttavia, è necessario prestare attenzione alle istanze RDS (DSDictionaryDB e DSAuditDB), poiché sincronizzare la sezione di mapping dei Consts nel modello con i valori effettivi e applicare politiche di retention è cruciale per prevenire la perdita di dati.
Se sono coinvolti script personalizzati o strumenti di terze parti, assicurarsi che siano adeguatamente migrati e compatibili con i nuovi ambienti. Il passaggio finale è terminare eventuali istanze EC2 lanciate utilizzando la vecchia Launch Configuration, garantendo un gruppo Auto Scaling completamente aggiornato gestito dal Launch Template.
Seguendo questi passaggi e precauzioni, è possibile migrare con successo al nuovo modello, sfruttando le funzionalità avanzate di AWS mantenendo l’integrità della distribuzione DataSunrise.