Come Migrare il Template CloudFormation di DataSunrise da Launch Configuration (LC) a Launch Template (LT) nella Risorsa del Gruppo di Auto Scaling
La migrazione da un AWS Launch Configuration (LC basato su un Auto Scaling Group (ASG) a una risorsa Launch Template (LT) offre significativi vantaggi nella gestione delle distribuzioni di DataSunrise, come maggiore flessibilità e supporto per funzionalità moderne di AWS e OS. In molti casi, la migrazione può essere eseguita semplicemente sostituendo il stack esistente con un template da GitHub, a condizione che vengano prese le necessarie precauzioni per evitare interruzioni, specialmente con le istanze AWS RDS (DSDictionaryDB e DSAuditDB).
Questa guida delinea i passaggi chiave e le considerazioni per migrare il template CloudFormation, incluso come gestire le istanze RDS e le personalizzazioni, garantendo una transizione fluida e senza soluzione di continuità.
Considerazioni Chiave per la Migrazione
- Vantaggi del Launch Template:
- Versionamento. È possibile mantenere più versioni di un Launch Template, fornendo flessibilità per futuri aggiornamenti o rollback.
- Supporto Funzionalità. Sono supportate nuove funzionalità come T2 Unlimited, networking avanzato e IPv6.
- Compatibilità OS. LT supporta le nuove distribuzioni OS come RHEL8 e Amazon Linux 2023, che sono necessarie per eseguire script Python 3 in DataSunrise.
- Aggiornamento Semplificato dello Stack con Template Pre-Costruito:
- Se non si utilizzano script o strumenti personalizzati, la migrazione può essere eseguita semplicemente sostituendo lo stack CloudFormation esistente con il template pre-costruito da GitHub.
- Assicurarsi di prendere i passaggi necessari per impedire la sostituzione o la ricreazione delle istanze RDS utilizzate da DataSunrise, poiché ciò potrebbe comportare la perdita di dati.
Passaggi per Migrare il Template CloudFormation
- Backup e Revisione dello Stack Esistente
- Eseguire il backup del template CloudFormation corrente e creare snapshot delle istanze RDS (DSDictionaryDB e DSAuditDB) per proteggersi dalla perdita di dati.
- Rivedere eventuali script personalizzati o strumenti di terze parti collegati al Launch Configuration esistente per valutare se saranno necessari ulteriori passaggi oltre all’utilizzo del template di GitHub.
- Scaricare il Nuovo Template da GitHub
- Scaricare il nuovo template CloudFormation basato su Launch Template (LT) dal repository ufficiale GitHub di DataSunrise.
- Questo template è pronto per l’uso se l’impostazione corrente 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. Una sostituzione accidentale potrebbe portare alla perdita di dati.
- Revisione della Mappatura delle Costanti:
- 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 template basato su LT da GitHub.
- Convalidare il template utilizzando gli strumenti di validazione integrati di AWS CloudFormation per catturare eventuali errori di sintassi o configurazione.
- Procedere con l’aggiornamento dello stack e monitorarlo attentamente per assicurarsi che non si verifichino aggiornamenti non intenzionali alle istanze RDS.
- Migrare gli Script Personalizzati (Se Necessario)
- Aggiornare gli Script Python per la 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 fornitori che tali 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 delle istanze 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
- Eseguire test funzionali per confermare che l’applicazione DataSunrise e i servizi associati funzionino correttamente.
- Verificare che le istanze RDS (DSDictionaryDB e DSAuditDB) conservino i loro dati e non vengano ricreate.
- Assicurarsi che eventuali script personalizzati o strumenti di terze parti migrati funzionino correttamente sulle 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 ancora utilizzando la risorsa Launch Configuration (LC) vecchio.
- Questo passaggio finale assicura che il Gruppo di Auto Scaling gestisca solo le istanze create utilizzando il nuovo Launch Template, che supporta funzionalità e configurazioni moderne.
- Piano di Rollback
- Se si verificano problemi durante l’aggiornamento, iniziare un rollback utilizzando la funzione di rollback di CloudFormation per ripristinare lo stack precedente.
- In caso di problemi legati a RDS, ripristinare i dati dagli snapshot presi prima dell’aggiornamento.
Nel template, la sezione di mappatura delle Costanti 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. Qualsiasi discrepanza potrebbe innescare la sostituzione delle istanze RDS durante l’aggiornamento.
Utilizzare la politica Retain per le istanze RDS specificando DeletionPolicy: Retain nel template CloudFormation. Questo garantisce che i database non vengano cancellati se lo stack tenta di ricrearli.
Configurare una UpdatePolicy per prevenire la sostituzione simultanea delle risorse critiche.
Se l’attuale distribuzione include script personalizzati nella chiave di metadati AWS::CloudFormation::Init, è necessario migrare questi script al 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 utilizzano Python 3 per impostazione predefinita. Se gli script personalizzati erano scritti in Python 2, devono essere aggiornati per la compatibilità con Python 3.
Aggiornare le istruzioni print, sostituire xrange() con range(), e affrontare altre sintassi specifiche di Python 2. Testare gli script aggiornati in un ambiente non di produzione per confermare la compatibilità con Python 3.
Conclusione
La migrazione da Launch Configuration (LC) a Launch Template (LT) in DataSunrise può spesso essere un processo semplice se non ci sono personalizzazioni allo stack. Nella maggior parte dei casi, è possibile semplicemente sostituire lo stack CloudFormation esistente con il template pre-costruito da GitHub. Tuttavia, è essenziale prestare attenzione alle istanze RDS (DSDictionaryDB e DSAuditDB), poiché sincronizzare la sezione di mappatura delle Costanti nel template con valori effettivi e applicare politiche di retention è cruciale per evitare la perdita di dati.
Se sono coinvolti script personalizzati o strumenti di terze parti, assicurarsi che siano correttamente migrati e compatibili con i nuovi ambienti. L’ultimo passaggio è terminare eventuali istanze EC2 lanciate utilizzando la vecchia Launch Configuration, assicurando un Gruppo di Auto Scaling completamente aggiornato gestito dal Launch Template.
Seguendo questi passaggi e precauzioni, è possibile migrare con successo al nuovo template, sfruttando le funzionalità avanzate di AWS mantenendo l’integrità della distribuzione DataSunrise.