#devoxxfr – Infra as Code, choisissez vous la pilule rouge ou la pilule bleue ?

Après cette blockchain en délire, revenons à du concret avec l’infra as code.

Mais qu’est-ce que l’infra as code ? c’est surtout le moyen de sortir une copie complète de l’infra sans péter la prod actuelle.
En théorie, ça doit permettre d’aller plus vite. En pratique, c’est plus de code, donc il faut le maintenir sinon il ne fait pas gagner de temps.

Donc on peut très bien tenter de faire vivre l’existant avec des bouts de ficelle et des scripts bash, ou on peut tenter de prendre conscience que l’infra as code, ça reste du code, et il faut s’en occuper comme du code.

Donc pour réduire la boucle de feedback lorsqu’on monte une infra, on isole pour débugger plus vite. Avec des outils comme

  • Vagrant
  • Docker

Et on va faire du feature filpping pour éviter les besoins de prod en dév.

Evidement, avec ces outils, on essaye toujours de se contenter de déclarer l’état désiré plutôt que le mode de transition. Donc pas d’ajout manuel dans le /etc/hosts, par exemple. Et pas non plus à grands coups de grep qui ne seront jamais suffisants.

Vient ensuite la super analogie de l’ascenseur : ne déclarer que l’état désiré. C’est ce qui permet l’idempotence. Idempotence qui est vraiment bien pratique pour rendre des configurations reproductibles.

Pour chaque profil de dév, il y a des outils qui vont permettre de les faire bosser mieux et plus vite. Je vous laisse regarder les détails et la vidéo, mais ça met bien face à chaque profil l’outil approprié.

L’un des meilleurs outils pour la prod est Gitlab/Github, parce que si on y met l’infra as code, ça permet aux développeurs de le lire et de comprendre comment marche la prod.

La dette technique peut également apparaître dans l’infra as code comme dans le code, et doit être gérée comme dans le code, c’est-à-dire comme à Tetris : si on ne veut pas s’y noyer, il faut éliminer les blocs dès qu’on peut.

Et l’un des endroits clé, c’est le bash, pour lequel il y a aussi des bonnes pratiques : interdire les unset, arrêter le script quand une commande échoue. Et comme dans le code, les caractères sont gratuits, donc priviliégiez les flags avec des noms longs.

Pour aller en prod sereinement

D’abord il faut savoir ce qu’il y a en prod … en loggant les résultats de chaque install en prod. Parce que la prod est faite du code de déploiement ET de l’état actuel de la prod … qui ne sera visible que dans les logs.

Ensuite, pour garantir la prédictibilité du déploiement, il vaut mieux enlever tous les sleeps du script de déploiement et les remplacer (quelque soit l’outil) par des tests de démarrage des services.

Et puis ne mettez pas tous vos scripts directement dans Jenkins, testez-les d’abord en ligne de commande avant de les mettre dans Jenkins, pour pouvoir versionner ce script d’une part, et pouvoir l’utiliser même quand jenkins est down ensuite.

Pour tester son environnement, on utilise les mêmes méthodes que les dévs (oui oui, on parle bien de pyramide des tests et de TDD). Malheureusement, il n’y a de l’outillage de test unitaire que dans chef et puppet. Là, il s’agira vraiment de tester le script chef/puppet et pas le code applicatif. Pour le test d’intégration, on peut très bien tout piloter dans Jenkins en quatre étapes d’un build.

Publicités

Infinitest ? Done

Vous le savez peut-être, au bureau, on utilise un langage qui n’est pas le Java. Qui n’est pas non plus le C#. Qui n’est pas non plus le {langage bien connu qui figure dans le Tiobe index}. En fait, pour être honnête, il n’y aucune espèce de chance que vous le connaissiez si vous n’avez pas travaillé dans l’entreprise qui m’emploie actuellement, ou en avez été un client.
C’est une situation assez difficile, parce que les outils qui existent pour les langages plus connus n’existent pas chez nous. Pas plus, d’ailleurs, que n’existent les frameworks de développement que vous utilisez, ou même les outils de build qui vous sont imposés. Les outils dont on dispose, ce sont ceux qu’on crée nous-mêmes.
Je suis donc assez fier de pouvoir affirmer que, nous aussi, nous pouvons écrire des tests unitaires à la JUnit (éventuellement paramétrés). J’en suis fier, parce que c’est moi qui ai écrit (avec l’aide d’un expert local, évidement), l’outil d’exécution des tests unitaires. D’ailleurs, dans une optique d’intégration continue, on a depuis des mois un job Hudson qui les exécute à distance pour agréger leurs résultats.
Mais bon, tout ça, c’est de la rigolade, ça vaut pas mieux que le plugin JUnit pour Eclipse.
Ce qui serait vraiment canon, ce serait de disposer d’un outillage à la Infinitest qui, quand on modifie un fichier source, repère les tests intéressants, les exécute, et affiche les résultats. Enfin, Infinitest, c’est peut-être un peu ambitieux, on pourrait peut-être se contenter de quelque chose comme JUnitFlux.
Et bien devinez quoi ? C’est ce qu’on a fait.

 

En fait, on a ajouté à nos fichiers un commentaire

 

@testedBy UneClasseDeTest

 

Et, quand le fichier est compilé, toutes ces annotations sont lues, les tests unitaires de ces classes sont exécutés, et les résultats sont affichés dans la vue JUnit d’Eclipse (grâce à un bon coup de reverse engineering sur le format XML de JUnit/Ant – merci encore à StackOverflow). Et franchement, c’est incroyablement pratique : à la sauvegarde d’un fichier, on sait tout de suite si le test unitaire fonctionne encore. On a donc, en plus de la compilation, une information supplémentaire sur la qualité du code produit. Et ça, ça donne envie d’aller encore plus loin, justement en essayant enfin Infinitest … mais évidement, c’est beaucoup plus compliqué d’analyser quels tests unitaires s’appliquent à un fichier donné quand on ne dispose pas des innombrables librairies d’analyse de code dont dispose Java.