Nous connaissons l’utilité et l’efficacité des tests avec NeoLoad. Mais connaissons-nous-en vraiment les limites ? N’est-il pas possible d’aller plus loin ?
Pour répondre à ces questions, nous avons imaginé des tests NeoLoad automatisés simultanés qui remonterait les données sur un serveur Neoload Web (NLWeb) dédié et qui nous notifierait de chaque erreur de script et permettrait ainsi un suivi en temps réel et sur le long terme des infrastructures du client.
Ainsi, nous mixerions tests fonctionnels et de performance !
Vue d’ensemble
Souhaitant tout mettre en place en local, nous utiliserons Docker sur une VM sous Linux et créerons différents containers :
- Un ou plusieurs containers NeoLoad à usage unique pour l’exécution du/des test(s)
- Un container Jenkins, chargé d’orchestrer les containers NeoLoad
- Un container GitLab, qui regroupera les scripts (NeoLoad et Jenkins)
- Trois containers NLWeb (Front, Back et Bdd), qui recueilleront les résultats de tests
- Un container Portainer, interface graphique permettant une utilisation clarifiée de Docker
Ainsi, nous avons un contrôle total sur la maintenance de cette infrastructure. De plus, chaque environnement est isolé et n’impacte pas le reste.
L’avantage des micro-services
Mettre en place une telle infrastructure nous permet de lancer en simultané autant de tests que nous le souhaitons : un container NeoLoad Contrôleur + Neoload injecteur pour chaque test programmé.
Chaque container est parfaitement indépendant, temporaire (disparait à la fin du test) et n’impacte en aucun cas les autres tests en cours.
Au revoir la contrainte d’attendre la fin d’un tir pour lancer le suivant !
Quel type de test ?
Nos scripts NeoLoad utilisés peuvent effectuer :
- Des tests de charge/performance à intervalles réguliers
- Ou simplement un tir d’1 VU pour vérifier l’intégrité fonctionnelle des infrastructures cibles.
On fait de l’automation avec un outil de performance !
Qui orchestre tout ça ?
Ce micmac de containers et de scripts nécessite d’être régit. Nous utiliserons pour cela un orchestrateur bien connu et facile à manier : Jenkins.
Son rôle est de créer et d’exécuter un script (appelé « pipeline ») qui contient une séquence d’étapes telles que :
- La récupération des scripts sur GitLab
- La création et le paramétrage d’un container NeoLoad à l’aide d’un Dockerfile préalablement rédigé
- Injection et exécution des scripts
- Fermeture et nettoyage
Quid des licences ?
Seule Neoload nécessite une licence, les autres composants sont usuellement utilisés en licence libre. Les licences partagées sont, quant à elles, stockées non pas dans le GitLab mais dans NLWeb.
Elles seront appelées depuis le container NeoLoad et utilisées lors de l’exécution des tests, puis libérées.
Où stocker les résultats ?
Pour éviter de perdre les résultats de test lors de la suppression du container NeoLoad, ils sont enregistrés dans la base de données MongoDB (NLWeb).
Il suffit donc d’accéder au NLWeb pour retrouver ces résultats et pouvoir les analyser, les comparer, etc.
Les APIs de contrôle
Nous avons donc mis en place des tests s’exécutant en continu, sans nécessiter d’intervention une fois lancé. Ainsi, si une erreur survient, il nous faut être notifiés. Sans quoi, je ne préfère pas penser à la suite…
C’est pourquoi nous avons utilisé les appels API WebHook de Slack pour que nos tests puissent remonter leurs erreurs et informations complémentaires et que l’on puisse immédiatement intervenir sur les parties endommagées, qu’elles viennent des scripts ou de l’infra testée.
Et voilà comment monter en 1 à 2 jours un outil de suivi des performances en production sur un petit Docker.
Antoine MASCHI
Consultant Automatisation et Performance
