Lorsque nous disons que la cloudformation est "Infrastructure as Code", la prochaine question qui vient immédiatement à l'esprit est de savoir comment tester ce code. Pouvons-nous faire une sorte de test unitaire de base de ce code
Et j'écarte la validation cloudformation parce que c'est juste une façon de faire la validation syntaxique, et que je peux faire avec n'importe quel autre validateur JSON/YAML gratuit.
Je suis plus enclin à une sorte de validation fonctionnelle, testant éventuellement que j'ai défini toutes les variables qui sont utilisées comme références. Peut-être tester que les propriétés que j'utilise sont réellement prises en charge pour ce composant
Je ne m'attendais pas à ce qu'il teste si les autorisations sont correctes ou que je n'ai pas épuisé mes limites. Mais au moins quelque chose au-delà de la validation de base de la syntaxe JSON/YAML
Voici une ventilation de la façon dont plusieurs méthodes de test de logiciels peuvent être appliquées aux modèles/piles CloudFormation:
Pour le linting (vérification de l'exactitude de la syntaxe/grammaire dans le code du modèle CloudFormation), vous pouvez utiliser l'API ValidateTemplate pour vérifier la structure de base du modèle et l'API CreateChangeSet
pour vérifier vos propriétés de ressource plus en détail.
ValidateTemplate
effectue une vérification beaucoup plus approfondie qu'un simple vérificateur de syntaxe JSON/YAML - il valide correctement Anatomie du modèle , syntaxe/utilisation correcte de Fonctions intrinsèques et la résolution correcte de toutes les valeurs Ref
.ValidateTemplate
vérifie la syntaxe de base de CloudFormation, mais ne vérifie pas les ressources de votre modèle par rapport à des schémas de propriété spécifiques. Pour vérifier la structure des paramètres, des ressources et des propriétés de votre modèle par rapport aux types de ressources AWS, CreateChangeSet
doit renvoyer une erreur si des paramètres ou des propriétés de ressource ne sont pas correctement formés.Pour effectuer des tests unitaires, il faut d'abord répondre à la question: quelle est la plus petite unité autonome de fonctionnalités qui peut/devrait être testée? Pour CloudFormation, je crois que la plus petite unité testable est la Resource .
Les officiels AWS Resource Types sont pris en charge/maintenus par AWS (et sont de toute façon des implémentations propriétaires), donc ne nécessitent aucun test unitaire supplémentaire écrit par les développeurs des utilisateurs finaux.
Cependant, votre propre Ressources personnalisées pourrait et devrait être testé à l'unité. Cela peut être fait en utilisant un cadre de test approprié dans le propre langage de l'implémentation (par exemple, pour les ressources personnalisées basées sur Lambda, peut-être une bibliothèque comme lambda-tester
serait un bon point de départ).
Il s'agit du type de test le plus important et le plus pertinent pour les piles CloudFormation (qui servent principalement à lier diverses ressources dans une application intégrée), ainsi que le type qui pourrait utiliser plus de raffinement et de développement des meilleures pratiques. Voici quelques idées initiales sur la façon de tester l'intégration du code CloudFormation en créant/mettant à jour des piles complètes contenant de vraies ressources AWS:
AWS::CloudFormation::WaitCondition
ressources pour représenter les tests/assertions réussis, de sorte qu'une création de pile réussie indique une exécution de test d'intégration réussie et une création de pile échouée indique une exécution de test d'intégration échouée.Au-delà de CloudFormation, un outil intéressant à mentionner dans l'espace de test de l'infrastructure en tant que code est kitchen-terraform
, un ensemble de plugins pour Test Kitchen qui vous permettent d'écrire des suites de tests d'intégration entièrement automatisées pour Terraform modules. Un faisceau de tests d'intégration similaire pourrait éventuellement être construit pour CloudFormation, mais n'existe pas encore.
Cet outil "cfn-nag" analyse une collection de modèles CloudFormation et applique des règles pour trouver des modèles de code qui pourraient conduire à une infrastructure non sécurisée. Les résultats de l'outil incluent les identificateurs de ressources logiques pour la violation des ressources et une explication de la règle qui a été violée. Lectures complémentaires: https://stelligent.com/2016/04/07/finding-security-problems-early-in-the-development-process-of-a-cloudformation-template-with-cfn-nag /
Bien qu'il existe un certain nombre de règles particulières que l'outil tentera de faire correspondre, les catégories approximatives sont les suivantes:
Stratégies IAM et de ressources (S3 Bucket, SQS, etc.)
Règles d'entrée et de sortie du groupe de sécurité Correspond aux règles qui sont trop libérales (par exemple, une règle d'entrée ouverte à 0.0.0.0/0, la plage de ports 1-65535 est ouverte)
Journaux d'accès Recherche les journaux d'accès qui ne sont pas activés pour les ressources applicables (par exemple, Elastic Load Balancers et CloudFront Distributions)
Chiffrement (côté serveur) qui n'est pas activé ou appliqué pour les ressources applicables (par exemple, les volumes EBS ou pour les appels PutObject sur un compartiment S3)
Le test tel que vous l'avez décrit (au moins au-delà de l'analyse JSON) peut être réalisé partiellement en analysant les modèles CloudFormation par des bibliothèques de programmation utilisées pour générer/lire des modèles. Ils ne testent pas le modèle explicitement, mais peuvent lever une exception ou une erreur dans des conditions où vous utilisez une propriété qui n'est pas définie pour une ressource.
Découvrez go-cloudformation: https://github.com/crewjam/go-cloudformation
En dehors de cela, vous devez exécuter la pile pour voir les erreurs. Je pense que tester IaaC est l'un des principaux défis de l'automatisation des infrastructures. Non seulement les tests unitaires mais aussi les tests d'intégration et la validation continue.