Comment puis-je déboguer rapidement et efficacement les modèles CloudFormation?
CloudFormation est une offre AWS puissante qui permet la création par programme de piles de ressources AWS, telles que le niveau Web d’une application, a un cluster de calcul hautes performances, ou une pile d’applications complète, avec un seul appel d'API. C'est immensément puissant. Son utilisation est sûrement considérée comme une bonne pratique AWS, surtout si elle est associée à Chef,Puppet, ou cloud-init. Le débogage me conduit au vice.
Prenons un exemple de production: les modèles de cluster stock mongodb ne fonctionneront pas pour moi. Je ne sais pas pourquoi. Je suis sûr que c'est quelque chose de simple comme c'est presque toujours le cas. Mon problème n'est pas que je ne peux pas comprendre ce qui ne va pas. C’est qu’il faut 20 à 30 minutes à la pile pour échouer, puis trois ou quatre minutes supplémentaires pour la supprimer, en supposant que les ressources soient supprimées correctement.
Qu'est-ce que je rate? Je connais le drapeau --disable-rollback et l’utilise comme oxygène. J'ai appris il y a longtemps à envelopper les messages de sortie avec cfn-signal et à les jeter comme du ballast sur un navire en perdition. Comment puis-je accélérer le processus de débogage des modèles, ou suis-je toujours coincé à remarquer mes erreurs une demi-heure après les avoir faites?
Utilisez la commande aws cloudformation validate-template dans l'outil AWS CLI. Il vérifie uniquement si votre modèle est valide au format JSON ou YAML, pas si vos clés et valeurs sont correctes (par exemple, ne vérifie pas les fautes de frappe dans les clés).
Une autre option, un an plus tard, consiste à résumer ces modèles à une bibliothèque tierce, telle que troposphère . Cette bibliothèque construit la charge JSON pour vous et effectue beaucoup de validation en cours de route. Cela résout également le problème "Wow de la gestion d’un fichier JSON de 1 000 lignes, ce qui est bien triste".
Avez-vous examiné l'éditeur de modèle AWS CloudFormation inclus dans le AWS Toolkit for Eclipse ? Il comporte la coloration syntaxique, l'achèvement des instructions et le déploiement vers AWS CloudFormation.
En retard pour la fête, mais je pourrais aussi ajouter qu'il vaut la peine de passer un peu de temps à configurer et à apprendre votre éditeur. Je sais que cela peut sembler ridiculement basique mais essayez-le.
Dans mon cas, avec vim, j’ai obtenu de bien meilleurs résultats une fois que j’ai pris du temps à installer des plugins pour la syntaxe json et que (enfin) j'ai compris les techniques de pliage pour naviguer facilement dans de gros fichiers CF. Le mien suggère maintenant des fautes de frappe (des virgules où elles ne devraient pas être, etc.) et la mise en surbrillance des couleurs permet de gagner beaucoup de temps en donnant des indices visuels clairs.
Cela peut aider à atténuer les erreurs de syntaxe, mais les erreurs de logique dans le modèle sont mieux corrigées par d'autres outils. Espérons qu'un jour, il y aura un mode "aperçu" sur CF.
Comment puis-je accélérer le processus de débogage des modèles, ou suis-je toujours coincé à remarquer mes erreurs une demi-heure après les avoir faites?
Voici quelques suggestions de meilleures pratiques, visant en particulier à améliorer la vitesse d'itération du développement complexe de modèles CloudFormation:
Utiliser les outils CloudFormation pour valider les modèles et mettre à jour les piles
AWS a déjà décrit ces éléments dans son propre document Meilleures pratiques , aussi je ne les répéterai pas:
- Valider les modèles avant de les utiliser
- Créer des ensembles de modifications avant de mettre à jour vos piles
Le but de cette étape est de détecter les erreurs de syntaxe ou logiques évidentes avant d’effectuer une création/mise à jour de pile.
Tester les ressources isolément
Avant d'utiliser une ressource CloudFormation individuelle dans une pile complexe, assurez-vous de bien comprendre toute l'étendue du comportement de cette ressource en matière de création/mise à jour/suppression, y compris les limites d'utilisation et les temps de démarrage/démontage habituels, en testant leur comportement dans des piles plus petites et autonomes. premier.
- Si vous développez ou utilisez des ressources personnalisées tierces, écrivez des tests unitaires à l'aide des bibliothèques appropriées pour la plate-forme linguistique, afin de vous assurer que la logique de l'application se comporte comme prévu dans tous les cas d'utilisation.
- Sachez que le temps nécessaire à une ressource individuelle pour créer/mettre à jour/supprimer peut varier considérablement entre les types de ressources, en fonction du comportement des appels d'API sous-jacents. Par exemple, une ressource
AWS::CloudFront::Distributioncomplexe peut parfois prendre 30 à 60 minutes pour créer/mettre à jour/supprimer, tandis qu'unAWS::EC2::SecurityGroupse met à jour en quelques secondes. - Les ressources individuelles peuvent avoir des bogues/problèmes/limitations dans leur implémentation, qui sont beaucoup plus faciles à déboguer et à développer des solutions de contournement pour les tests effectués isolément plutôt que dans une pile beaucoup plus grande. Tenez compte des limitations telles que limites du service AWS en fonction de vos paramètres de compte AWS individuels ou disponibilité des services dans la région en fonction de la région dans laquelle vous créez votre pile.
Construisez des piles compliquées par petits incréments
Lors de la création/mise à jour d'une pile, une défaillance de l'une des ressources entraîne son annulation de l'ensemble des modifications apportées aux ressources, ce qui peut détruire inutilement d'autres ressources créées avec succès et prendre beaucoup de temps lors de la création d'une pile complexe avec une longue dépendance graphique des ressources associées.
La solution consiste à construire votre pile de manière incrémentielle en lots de mises à jour plus petits, en ajoutant des ressources une à une à la fois. Ainsi, si/lorsqu'une défaillance survient lors de la création/mise à jour d'une ressource, la restauration ne provoque pas la destruction de l'ensemble des ressources de votre pile, mais uniquement de l'ensemble des ressources modifiées dans la dernière mise à jour.
Surveiller la progression des mises à jour de la pile
Assurez-vous de (surveiller la progression de votre mise à jour de la pile) en affichant les événements de la pile pendant la création/la mise à jour. Ce sera le point de départ pour déboguer d'autres problèmes avec des ressources individuelles.
Pour les IDE JetBrains (IntelliJ IDEA PhpStorm WebStorm PyCharm RubyMine AppCode CLion Gogland DataGrip Rider Studio Android ), Il existe un AWS CloudFormation plugin qui prend en charge la vérification approfondie des modèles CFN JSON et YAML.
Si vous utilisez des machines EC2, je vous recommanderais alors de vous connecter à la machine EC2 et de terminer le fichier boot.log (/var/log/boot.log dans RHEL6/Centos). Ce fichier est mis à jour avec toutes vos activités Shell (activités telles que: installation, téléchargement de fichiers, copie de fichiers, etc.).
Utilisez également des éditeurs tels que http://www.jsoneditoronline.org/ pour obtenir une représentation TREE de votre JSON. Cela vous aide à vérifier l'ordre des éléments JSON.
Et lorsque vous mettez à jour des fichiers, utilisez toujours des outils tels que http://www.git-tower.com/blog/diff-tools-mac/ ou un système de contrôle de version actuel pour vous assurer que vous n'avez pas modifié accidentellement casser votre script.
Une nouvelle fonctionnalité récemment ajoutée à Cloudformation en décembre dernier est l’ajout de types de paramètres supplémentaires . Ces nouveaux types permettent à vos modèles d’effectuer une vérification plus rigoureuse des données et peuvent également "échouer" lors de la création de ressources et de piles Cloudformation imbriquées. Vous pouvez également fournir de meilleurs messages d'erreur personnalisés lisibles par l'homme lorsque des valeurs non valides sont passées à l'aide du nouvel attribut ConstraintDescription .
Les nouveaux types sont particulièrement utiles lorsque vous utilisez diverses ressources VPC. Vous pouvez vous assurer que les paramètres de vos modèles sont du type correct et expliquent clairement l'attente d'une valeur unique par rapport à une liste.
Par exemple:
"Parameters" : {
"SingleGroup": { "Type": "AWS::EC2::SecurityGroup::Id", ...},
"GroupList": {"Type": "List<AWS::EC2::SecurityGroup::Id>", ...}
}
Le linter AWS CloudFormation, cfn-python-lint, fournit une analyse statique supplémentaire au-delà de aws cloudformation validate-template:
En plus de la commande AWS CLI aws cloudformation validate-template , il existe un outil cfn-check basé sur les noeuds qui effectue une validation plus approfondie.
Vous pouvez également utiliser le concepteur CloudFormation disponible sur Amazon à l’adresse suivante: https://console.aws.Amazon.com/cloudformation/designer/home?region=us-east-1
Il vous suffit de coller votre modèle (JSON) dans le volet "Modèle", puis de cliquer sur le symbole en forme de coche pour valider votre modèle. Toutes les erreurs apparaîtront dans le volet "Erreur".
J'espère que cela t'aides.
Veuillez vérifier mon validateur cloudformation à https://pypi.org/project/cloudformation-validator/
Cela validera le schéma, puis validera à nouveau une liste de règles et autorisera des règles personnalisées. I permet également une intégration facile avec les outils de déploiement.