Cas pratique : l’automatisation de tests avec Puppet

Temps de lecture : 4 minutes
D2SI8Blog_Image_LogoDeveryware
Quel est le rapport entre les applications de géolocalisation et l’automatisation de déploiement d’infrastructures via Puppet ? Aujourd’hui nous revenons sur une expérience client couvrant ces deux sujets. Deveryware fournit des solutions applicatives autour de la géolocalisation : commande d’un taxi en moins de 3 minutes grâce à votre position géographique, localisation et surveillance des flottes, personnes et biens, géosurveillance, etc.

Dans l’optique de l’automatisation de leur nouvelle plateforme PF4, quatrième version de l’infrastructure matérielle qui supporte la plateforme logicielle de production, toutes les applications de géolocalisation doivent migrer. Cette plateforme offre des solutions en mode SAAS, elle doit donc fonctionner 24h/24 et 7j/7. Ce projet nécessite de mettre à jour tous les modules Puppet existants (passer à la version 3.5 de Puppet), et d’en créer de nouveaux : Puppet permet ici de déployer et de configurer des applications sur des VM pour les équipes Infrastructure et Développement.

L’objectif est de tout automatiser de façon à ne pas perdre de temps à chaque fois qu’il faut déployer une infrastructure ou une application. Le double avantage de cette démarche est de réduire la charge de travail, et de s’assurer que l’état de l’infrastructure soit 100% conforme au besoin.

Dans ce projet, François Gouteroux est intervenu sur le développement de modules pour des logiciels spécifiques, par exemple pour s’approprier les fonctionnalités d’un module précis (My SQL pour faire une configuration maître-esclave, par exemple). Chaque module a ainsi des listes de fonctionnalités par défaut, qu’il faut adapter à son besoin spécifique. Cela suppose de reprendre le module, voir ce qu’il fait en détail, et de vérifier les modules ajoutés par d’autres utilisateurs sur GitHub afin de pouvoir ensuite apporter un conseil sur les choix de modules.

Pour la partie développement, François est également intervenu sur la mise en place des rôles et des profils de serveurs. Par exemple, le rôle DNS/DHCP peut être déployé de façon à obtenir un serveur avec un DHCP, un DNS, un NTP serveur… : il n’y a plus qu’à provisionner la VM pour que tous les packages descendent. Lors de la création d’une nouvelle VM, en fonction de son nom, elle a un rôle spécifique, ainsi elle récupère la configuration nécessaire.

D2SI_Blog_Image_Puppet - Node Configuration

Les rôles et les profils sont développés sur mesure, et le workflow permet de gérer et d’automatiser leur évolution, de les tester directement sans intervention humaine. Par exemple, un développeur fait évoluer le rôle d’un serveur web pour une application. Le code est poussé sur Git, un évènement est déclenché pour lancer un pipeline de Continuous Delivery Jenkins. Les rôles et profils impactés sont ensuite contrôlés. La partie automatisation de tests est déclenchée par Beaker, un outil de tests et de provisioning de VM developpé par PuppetLabs. Après le provisionning, les tests sont exécutés par rapport au rôle lancé, puis on passe à la destruction des VM et au reporting : success ou fail. Si la modification a été validée, elle passe alors en production.

D2SI_Blog_Image_Workflow_automatise

L’avantage de cette solution est de tester les rôles/profils/modules sur des VM mais aussi des environnements complets : tout se fait automatiquement. Dans ce cas d’utilisation (provisionner les VM, se connecter sur chaque machine, faire les tests pour chaque logiciel), le processus non automatisé peut prendre jusqu’à 2 heures. Le processus s’appuyant sur Beaker prend par exemple 17 minutes*, sans intervention humaine pour un test complet d’un environnement web avec loadbalancers . En 17 minutes, 6 VM sont construites : 1 puppetmaster, deux load balancer haproxy, deux web servers apache et un client. Le scénario est le suivant : le client se connecte sur le frontend du loadbalancer, récupère une page web et vérifie que le contenu correspond avec celui attendu.

L’utilisateur définit exactement ce qui doit être testé, comment l’environnement est considéré comme viable (quel service Web démarré, quelles applications, quels redirects, etc.). Deveryware dispose maintenant d’un système complet d’automatisation des tests, permettant de créer de nouveaux cas d’usage, et de dérouler le workflow automatisé pour tout tester.

D2SI_Blog_Image_Puppet-Use-Case - New Page

* Dépend des performances de la machine qui exécute les tests avec Beaker

Commentaires :

A lire également sur le sujet :