Comment Migrer un Modèle CloudFormation DataSunrise d’une Configuration de Lancement (LC) à une Ressource Launch Template (LT) dans un Groupe de Mise à l’Échelle Automatique
La migration d’un groupe de mise à l’échelle automatique (ASG) basé sur AWS Launch Configuration (LC) à une ressource Launch Template (LT) offre des avantages significatifs pour la gestion des déploiements DataSunrise, tels qu’une flexibilité accrue et une prise en charge des 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 la pile existante par un modèle à partir de GitHub, à condition de prendre les précautions nécessaires pour éviter toute interruption, 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 comment gérer les instances RDS et les personnalisation, pour assurer une transition en douceur et sans heurts.
Considérations Clés pour la Migration
- Avantages du Launch Template :
- Versioning. Plusieurs versions d’un Launch Template peuvent être maintenues, offrant une flexibilité pour les mises à jour ou les retours en arrière futurs.
- Prise en Charge des Fonctionnalités. De 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 OS plus récentes telles que RHEL8 et Amazon Linux 2023, nécessaires pour exécuter des scripts Python 3 dans DataSunrise.
- Mise à Jour Simplifiée de la Pile avec un Modèle Préconstruit :
- S’il n’y a pas de scripts ou d’outils personnalisés en cours d’utilisation, la migration peut être effectuée simplement en remplaçant la pile CloudFormation existante par le modèle préconstruit à partir 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
- Sauvegarde et Revue de la Pile Existante
- Sauvegardez le modèle CloudFormation actuel et créez des instantanés de vos instances RDS (DSDictionaryDB et DSAuditDB) pour vous protéger contre la perte de données.
- Passez en revue les scripts personnalisés ou les outils tiers liés à votre configuration de lancement actuelle pour déterminer si des étapes supplémentaires seront nécessaires au-delà de l’utilisation du modèle GitHub.
- Télécharger le Nouveau Modèle à partir de GitHub
- Téléchargez le nouveau modèle CloudFormation basé sur le Launch Template (LT) à partir du dépôt officiel de DataSunrise sur GitHub.
- 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 garantir que les instances AWS RDS (DSDictionaryDB et DSAuditDB) ne sont pas recréées ou remplacées lors de la mise à jour de la pile. Le remplacement accidentel pourrait entraîner une perte de données.
- Revue du Mapping Consts :
- 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 à l’aide des outils de validation intégrés de AWS CloudFormation pour détecter les erreurs de syntaxe ou de configuration.
- Poursuivez 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 produit.
- Migration des Scripts Personnalisés (si Nécessaire)
- Mettre à Jour les Scripts Python pour Compatibilité (si Nécessaire)
- Vérifier 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 les mises à jour nécessaires pour assurer la compatibilité avec les nouveaux environnements.
- Surveiller la Mise à Jour de la Pile
- Après avoir lancé la mise à jour de la pile, surveillez le statut 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 Launch Template fonctionnent comme prévu.
- Effectuer les Tests Post-Migration
- Effectuez 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 à l’Aide de l’Ancienne Configuration de Lancement (LC)
- Une fois que les nouvelles instances EC2 lancées à partir de la Launch Template (LT) sont confirmées comme fonctionnant correctement, terminez toutes les instances EC2 encore utilisant l’ancienne ressource Launch Configuration (LC).
- Cette étape finale garantit que le groupe de mise à l’échelle automatique gère uniquement les instances créées à l’aide du nouveau Launch Template, qui prend en charge les fonctionnalités et configurations modernes.
- Plan de Repli
- Si des problèmes surviennent lors de la mise à jour, lancez un rollback en utilisant la fonctionnalité de rollback de CloudFormation pour restaurer l’ancienne pile.
- 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 mapping Consts définit les versions de l’engin 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 éviter le remplacement simultané des ressources critiques.
Si votre déploiement actuel inclut des scripts personnalisés dans la clé de métadonnées AWS::CloudFormation::Init, vous devez migrer ces scripts vers le nouveau Launch Template.
Pour ce faire, examinez les scripts existants et copiez ceux nécessaires dans les sections correspondantes du nouveau Launch Template.
Avec le nouveau Launch Template, vos instances DataSunrise fonctionneront sur RHEL8 ou Amazon Linux 2023, qui utilisent par défaut Python 3. 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 print statements, remplacez xrange() par range(), et adressez-vous aux autres syntaxes spécifiques à 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 lancement de modèle (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 à partir de GitHub. Cependant, il est crucial de prêter attention aux instances RDS (DSDictionaryDB et DSAuditDB), car la synchronisation de la section de mapping Consts dans le modèle avec les valeurs réelles et l’application des politiques de rétention est essentielle 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, assurant ainsi un groupe de mise à l’échelle automatique pleinement à jour géré par le Launch Template.
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 AWS améliorées tout en maintenant l’intégrité de votre déploiement DataSunrise.