#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.

#devoxxfr – Microservices IRL: ça fonctionne chez un client, on vous dit comment!

Et donc, des microservices … en prod !

Curieusement, comme d’habitude, ils nous expliquent que les microservices viennent des mouvements agiles, devops, et permettent au SI de s’adapter aux architectures web, cloud grâce aux conteneurs. Et enfin, un microservice, conceptuellement, c’est juste un environement d’exécution d’un bounded context DDD.
Chaque microservice a son propre modèle de persistance et ses propres tables. Du coup, un antipattern est d’avoir des tables partagées entre microservices, comme c’est le cas pour DDD.
Et évidement, dans les microservices, il y a de la répétition.

Donc il y a comme lors de la présentation d’orchestration docker tout un tas d’outils aux noms bizarres : zookeeper, hystrix, … qui permettent toutefois d’assembler « facilement » une application à base de microservices.

Le déploiement se fait par Ansible, mais manuellement.
Heureusement, un outil comme Spinnaker permet de faciliter ça, comme Jenkins 2.

D’une façon amusante, pour le transfert des données, ils utilisent JSON, qui malheureusement ne contient pas de schéma. Ils auraient pu utiliser XML, mais c’est jugé trop verbeux … Ou alors c’est que c’est trop old-school, j’en sais rien.

En tout cas un bel exemple, et le dashboard hystrix est quand même un truc bien agréable à regarder (pour un dév comme pour un ops, en fait).

Erf, la date

Vous avez sans doute lu mon dernier article avec une espèce de curiosité un peu malsaine ….

Bon, je vous explique. J’utilise au bureau Jenkins, très bon outil d’intégration continue. Ce outil, je lui fait faire des trucs pas forcément catholiques (comme par exemple émuler les releases maven).

Bien, dans la release maven, il ya une étape où on crée un tag, et ensuite on change la version maven dans ce tag. Donc pour ça, on crée le tag (ça je crois que je l’ai déja dit), et on fait un checkout du tag.

Et c’est ce checkout qui ne marche pas, ce qui m’a fait m’arracher les cheveux (bon, je n’en ai plus depuis un moment, mais c’est tout comme) depuis une semaine. Pourquoi ?

Vous allez rire, j’en suis sûr.

Parce que, comme toute bonne histoire de DevOps, c’est la couche en laquelle j’avais confiance qui a foiré.

En l’occurence, le serveur Subversion, l’esclave Jenkins et Jenkins ne sont pas à la même heure … il y a même un décalage de 10 minutes entre eux. Jenkins est dans le passé des deux autres. Donc, comme je fais la création de tag dans un job, et le switch dans un autre, eh bien ce deuxième job démarre avec un timestamp fourni par Jenkins (donc 10 minutes dans son propre passé). A cet instant, évidement, le tag n’existe pas, et le switch ne peut que mal se passer.

J’ai donc enfilé mon meilleur costume de Linuxien fou et cherché comment configurer un serveur de temps, sur la machine Subversion (une Ubuntu), sur l’esclave (un XServe sous MacOS), et Jenkins. Hélas, la machine virtuelle hébergeant ce dernier n’a pas d’accès réseau. Je n’ai donc pas pu configurer NTP et j’ai dû, à la main, changer la date de Linux. La honte, non ?

Du coup, je vais devoir ajouter un job dans Jenkins pour vérifier qu’il n’y a pas un décalage trop important (voire, et j’en ai honte, pour  synchroniser la date de la machine Jenkins avec celle de la machine Subversion (comme ça, plus de décalage possible) !