Infrastructure en tant que code et TDD

L'infrastructure en tant que code nous dit d'utiliser des outils qui automatisent vos builds. Génial. Des outils comme ansible , chef , marionnette , pile de sel et autres nous poussent à écrire à quoi ressemble l'infrastructure, tout en résolvant les différences.

Dans Salt Stack, ces bits sont appelés états . Si l'état ne correspond pas à la réalité, l'outil le résoudra pour nous. En d'autres termes - nous écrivons un test pour notre infrastructure et si le test échoue, l'outil le réparera de lui-même. C'est du moins l'idée.

XP nous apprend à utiliser TDD et la question est de savoir s'il est applicable à l'infrastructure? L'outillage le suggère.

Je peux imaginer quelques types de tests qui peuvent être très utiles.

Nous rédigeons des tests de fumée fournis avec le service déployé pour garantir que le service déployé de bout en bout fonctionne et s'exécute comme prévu. Ce serait un appel d'API ou / et une vérification de systemctl pour vous assurer que ce que nous venons de déployer fonctionne. Une grande partie de cette fonctionnalité peut être couverte dans les mêmes états car des outils comme ansible ont des états pour s'assurer qu'un service est en cours d'exécution.

Il existe un projet Molecule qui permet d'exécuter des rôles individuels (comme l'appelle ansible ses états) contre Docker ou un autre moteur de virtualisation temporaire. Cela oblige à découpler les rôles et permet de les exécuter indépendamment du playbook tout en travaillant dessus. Les tests permettent principalement de se moquer des variables avec lesquelles le rôle est censé fonctionner. Cependant, d'autres exemples semblent être une duplication du moteur ansible (affirmer qu'un fichier appartient à un utilisateur ...).

Le radar technologique de ThoughtWorks vante en ce moment des outils comme inspec , serverspec ou goss pour valider que le serveur répond aux spécifications. Mais nous écrivons une spécification, n'est-ce pas?

Alors, y a-t-il un intérêt à tester davantage l'infrastructure si nous décrivons l'infrastructure dans les états / rôles? Je pourrais soupçonner que cela devient plus nécessaire dans les grandes organisations où une équipe fournit les spécifications et d'autres suit, ou s'il y a un grand ensemble de rôles, vous voudrez peut-être exécuter un sous-ensemble de ceux-ci et bénéficier de la vitesse des tests? J'ai du mal à voir pourquoi vous écririez un test si vous pouviez avoir un rôle / état pour la même question à l'esprit.

En bref, je vois deux catégories de tests pour votre infrastructure: 1) a-t-il tout ce dont vous avez besoin pour exécuter votre application et 2) n'a-t-il rien de superflu.

Tout d'abord, vous pouvez traiter la suite de tests de votre logiciel réel comme une sorte de «méta-test» pour votre infrastructure. Tant que vous créez l'infrastructure à partir de zéro pour chaque exécution de test et que la suite de tests s'exécute complètement sur cette infrastructure (c'est-à-dire qu'elle n'utilise pas de services externes), le fait que toute la suite soit verte signifie que votre infrastructure codifiée est également suffisante. .

Deuxièmement, en particulier du point de vue de la sécurité, vous pouvez écrire des tests sur votre infrastructure. C'est-à-dire, si une partie de votre infrastructure est une machine virtuelle exécutant Linux, vous pouvez écrire un test qui effectue une analyse des ports par rapport à cette machine virtuelle, pour vous assurer qu'aucun port involontaire n'est ouvert, ce qui peut avoir été installé par un apt-get installeffet secondaire involontaire. . Ou vous pouvez écrire des tests qui vérifient si des fichiers inattendus ont été modifiés après la fin de votre suite de tests appropriée. Ou vous pouvez vérifier les pssorties de vos machines virtuelles ou conteneurs Docker pour les processus inattendus et autres, créer des listes blanches, etc., et ainsi obtenir une notification automatique si un package tiers a changé de manière non documentée (ou inaperçue) dans une mise à niveau.

Ces deuxièmes types de tests sont, en quelque sorte, similaires à ce que vous feriez de toute façon dans un environnement d'opérations classique, c'est-à-dire durcir vos serveurs et vérifier les intrusions, éviter la pleine ressource et autres.

À mon humble avis, il est plutôt redondant d'écrire des tests TDD pour des éléments entièrement couverts par la spécification d'état IaaC. Cela implique que l'efficacité de l'IaaC est discutable - pourquoi l'utiliseriez-vous dans ce cas?

Le regarder d'un autre IaaC prospectif lui-même (si / quand fait correctement) intègre des capacités déjà testées et considérées comme fonctionnant de manière fiable. C'est ce qui le rend attractif et rend redondant l'écriture de tests d'appariement TDD.

Par exemple, une configuration IaaC spécifiant un système avec SSH en cours d'installation intègre déjà une vérification fiable de la bonne installation de SSH et, sinon, des mécanismes pour l'installer correctement. Ce qui rend un test TDD pour vérifier si SSH est installé redondant. Si votre configuration IaaC spécifie également que sshd doit être démarré et écouté sur un port spécifique, les tests TDD pour l'exécution de sshd et l'écoute du port respectif seraient également redondants.

Notez que ma réponse ne cible pas TDD ou tout autre type de test qui vérifie si votre configuration IaaC dans son ensemble correspond à un certain objectif. Cela reste valable et peut être utilisé dans les vérifications TDD, CI ou similaires pendant le développement de cette spécification IaaC - je crois que la réponse de @ AnoE est applicable dans ce cas.

Il semble que tout le monde ici suppose qu'un outil IAC fonctionne toujours comme prévu, mais je peux dire (d'après ma propre expérience) que ce n'est pas toujours le cas, sinon le test unitaire serait en fait inutile.

Je me souviens d'une photo disant "Ansible playbook a couru, tout va bien" avec un bâtiment brûlant en arrière-plan ...

Exécuter un état déclaratif et avoir le serveur dans cet état déclaré réel sont au moins deux choses différentes de mon point de vue et de mon expérience.

Un environnement large et hétérogène, réparti sur plusieurs DC, accessible via le réseau public, etc.

Pour toutes ces raisons, il y a de la place pour des tests unitaires permettant d'obtenir un instantané de l'état réel du serveur, qui, encore une fois, peut différer de l'état visé.

Je dirais donc oui, les tests unitaires sont utiles même dans un environnement géré par IAC.

ÉDITER

Qu'en est-il du côté non-régression de la branche dev de la base de code IaC? donc vous feriez des changements à votre code dans la branche dev et le fusionneriez à la branche prod en espérant ne pas tout casser? les tests unitaires sont si précieux, et généralement simples à mettre en œuvre Je ne vois pas pourquoi on coderait sans cette fonctionnalité.

Référence (désolé pour ça): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

D'après mon expérience, l'une des principales différences entre Dev et Ops sont les "fortes dépendances de temps d'exécution". L'installation de packages dépend fortement des référentiels, des réseaux ou des clés valides, ou disons l'instanciation d'un nouveau serveur cloud - cela dépend des ressources de votre fournisseur.

En termes de provisionnement de serveur même si vous n'avez pas changé votre code de provision, votre image sera valide la plupart du temps mais parfois non. Je pense donc que les tests sont vraiment essentiels pour fournir des images de travail.

Si vous allez au-delà de serveurs uniques, les choses empirent encore ... comment allez-vous tester l'accessibilité dans des configurations de réseau entières? Y compris la résolution DNS, le routage et le pare-feu? Même si votre API de fournisseurs IaaC fonctionne comme prévu (j'ai vu des problèmes de câblage dans ce domaine), j'aime vraiment TDD dans ce cas.

Comme je n'ai trouvé aucun outil de test dans ce domaine, nous en avons rédigé un dans notre temps libre: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

Je pense donc que TDD est vraiment important dans le monde DevOps!