Comment migrer le modèle CloudFormation DataSunrise de la configuration de lancement (LC) à la ressource de modèle de lancement (LT) dans le groupe Auto Scaling
La migration d’un groupe Auto Scaling (ASG) basé sur une configuration de lancement (LC) AWS à une ressource Launch Template (LT) offre des avantages significatifs pour la gestion des déploiements DataSunrise, tels qu’une flexibilité accrue et un support pour les fonctionnalités modernes d’AWS et des systèmes d’exploitation. Dans de nombreux cas, la migration peut être effectuée simplement en remplaçant l’empilement existant par un modèle de GitHub, à condition de prendre les précautions nécessaires pour éviter les perturbations, en particulier avec les instances AWS RDS (DSDictionaryDB et DSAuditDB).
Ce guide présente les étapes clés et les considérations pour migrer le modèle CloudFormation, y compris la gestion des instances RDS et des personnalisations, afin d’assurer une transition fluide et sans heurts.
Considérations clés pour la migration
- Avantages du modèle de lancement :
- Versionnage. Plusieurs versions d’un modèle de lancement peuvent être maintenues, offrant une flexibilité pour les futures mises à jour ou les retours en arrière.
- Support des fonctionnalités. Les nouvelles fonctionnalités telles que T2 Unlimited, le réseau avancé et IPv6 sont prises en charge.
- Compatibilité avec les systèmes d’exploitation. LT prend en charge les distributions de systèmes d’exploitation plus récentes telles que RHEL8 et Amazon Linux 2023, qui sont nécessaires pour exécuter des scripts Python 3 dans DataSunrise.
- Mise à jour de pile simplifiée avec un modèle préconstruit :
- Si aucun script ou outil personnalisé n’est utilisé, la migration peut être effectuée en remplaçant simplement la pile CloudFormation existante par le modèle préconstruit de GitHub.
- Assurez-vous que les étapes nécessaires sont prises pour empêcher les instances RDS utilisées par DataSunrise d’être remplacées ou recréées, car cela pourrait entraîner une perte de données.
Étapes pour migrer le modèle CloudFormation
- Sauvegardez et examinez la pile existante
- Sauvegardez le modèle CloudFormation actuel et créez des instantanés de vos instances RDS (DSDictionaryDB et DSAuditDB) pour vous prémunir contre une perte de données.
- Examinez les scripts personnalisés ou les outils tiers associés à votre configuration de lancement actuelle pour évaluer si des étapes supplémentaires seront nécessaires au-delà de l’utilisation du modèle GitHub.
- Téléchargez le nouveau modèle de GitHub
- Téléchargez le nouveau modèle de lancement (LT) basé sur CloudFormation du dépôt GitHub officiel de DataSunrise.
- Ce modèle est prêt à l’emploi si votre configuration actuelle n’implique pas de scripts ou d’outils personnalisés, simplifiant ainsi le processus.
- Assurez-vous que les instances RDS ne sont pas mises à jour
- L’étape la plus critique de cette migration est de s’assurer que les instances AWS RDS (DSDictionaryDB et DSAuditDB) ne soient pas recréées ou remplacées lors de la mise à jour de la pile. Un remplacement accidentel pourrait entraîner une perte de données.
- Examen du mappage des constantes :
- EngineVersionPg, EngineVersionMs, EngineVersionMy ;
- AuditAuroraEngineVersionPg, AuditAuroraEngineVersionMy ;
- ParameterGroupFamilyPg, ParameterGroupFamilyMy, DictionaryParameterGroupFamilyMs ;
- AuditParameterGroupFamilyMs, ParameterGroupFamilyPgCluster, ParameterGroupFamilyMyCluster.
- Appliquer les politiques de rétention :
- Effectuer la mise à jour de la pile
- Remplacez la pile CloudFormation existante par le nouveau modèle basé sur LT de GitHub.
- Validez le modèle en utilisant les outils de validation intégrés de AWS CloudFormation pour détecter toute erreur de syntaxe ou de configuration.
- Poursuivez avec la mise à jour de la pile et surveillez-la de près pour vous assurer qu’aucune mise à jour non intentionnelle des instances RDS ne se produise.
- Migrer les scripts personnalisés (si nécessaire)
- Mettre à jour les scripts Python pour compatibilité (si nécessaire)
- Vérifiez la compatibilité des outils tiers (si nécessaire)
- Si des outils tiers sont installés via des scripts User Data, vérifiez auprès des fournisseurs que ces outils sont compatibles avec les nouveaux systèmes d’exploitation (RHEL8 ou AL2023).
- Installez toutes les mises à jour nécessaires pour assurer la compatibilité avec les nouveaux environnements.
- Surveiller la mise à jour de la pile
- Après avoir initié la mise à jour de la pile, surveillez l’état des instances EC2 et des instances RDS pour vous assurer qu’elles ne sont pas remplacées ou recréées.
- Vérifiez que les nouvelles instances basées sur le modèle de lancement fonctionnent comme prévu.
- Effectuer des tests post-migration
- Réalisez des tests fonctionnels pour confirmer que l’application DataSunrise et les services associés fonctionnent correctement.
- Vérifiez que les instances RDS (DSDictionaryDB et DSAuditDB) conservent leurs données et ne sont pas recréées.
- Assurez-vous que les scripts personnalisés ou les outils tiers migrés fonctionnent correctement sur les nouvelles instances.
- Terminer les instances lancées en utilisant l’ancienne configuration de lancement (LC)
- Une fois que les nouvelles instances EC2 lancées à partir du modèle de lancement (LT) sont confirmées comme fonctionnant correctement, terminez toutes les instances EC2 utilisant encore l’ancienne configuration de lancement (LC).
- Cette dernière étape garantit que le groupe Auto Scaling ne gère que les instances créées à l’aide du nouveau modèle de lancement, qui prend en charge les fonctionnalités et configurations modernes.
- Plan de rollback
- Si des problèmes surviennent lors de la mise à jour, lancez un rollback en utilisant la fonctionnalité de rollback de CloudFormation pour restaurer la pile précédente.
- En cas de problèmes liés aux RDS, restaurez les données à partir des instantanés pris avant la mise à jour.
Dans le modèle, la section de mappage des constantes définit les versions des moteurs et les groupes de paramètres pour les instances RDS. Ces paramètres incluent :
Assurez-vous que ces valeurs correspondent aux paramètres réels de vos instances RDS existantes. Toute divergence pourrait déclencher le remplacement des instances RDS lors de la mise à jour.
Utilisez la politique Retain pour les instances RDS en spécifiant DeletionPolicy: Retain dans le modèle CloudFormation. Cela garantit que les bases de données ne sont pas supprimées si la pile tente de les recréer.
Configurez UpdatePolicy pour empêcher le remplacement simultané des ressources critiques.
Si votre déploiement actuel comprend des scripts personnalisés dans la clé de métadonnées AWS::CloudFormation::Init, vous devez migrer ces scripts vers le nouveau modèle de lancement.
Pour cela, passez en revue les scripts existants et copiez les nécessaires d’entre eux dans les sections correspondantes du nouveau modèle de lancement.
Avec le nouveau modèle de lancement, vos instances DataSunrise fonctionneront sur RHEL8 ou Amazon Linux 2023, qui utilisent Python 3 par défaut. Si vos scripts personnalisés ont été écrits en Python 2, ils doivent être mis à jour pour être compatibles avec Python 3.
Mettez à jour les instructions print, remplacez xrange() par range(), et adressez-vous à toute autre syntaxe spécifique à Python 2. Testez vos scripts mis à jour dans un environnement non production pour confirmer leur compatibilité avec Python 3.
Conclusion
La migration d’une configuration de lancement (LC) à un modèle de lancement (LT) dans DataSunrise peut souvent être un processus simple s’il n’y a pas de personnalisations de la pile. Dans la plupart des cas, vous pouvez simplement remplacer la pile CloudFormation existante par le modèle préconstruit de GitHub. Cependant, une attention particulière doit être portée aux instances RDS (DSDictionaryDB et DSAuditDB), car synchroniser la section de mappage des constantes dans le modèle avec les valeurs réelles et appliquer les politiques de rétention est essentiel pour éviter la perte de données.
Si des scripts personnalisés ou des outils tiers sont impliqués, assurez-vous qu’ils sont correctement migrés et compatibles avec les nouveaux environnements. La dernière étape consiste à terminer toutes les instances EC2 lancées en utilisant l’ancienne configuration de lancement, garantissant un groupe Auto Scaling entièrement à jour géré par le modèle de lancement.
En suivant ces étapes et ces précautions, vous pouvez migrer avec succès vers le nouveau modèle, en tirant parti des fonctionnalités améliorées d’AWS tout en maintenant l’intégrité de votre déploiement DataSunrise.