• Accueil
  • Automatisation
  • Performance
  • Sécurité
  • Intelligence
  • Recrutement
  • Contact
  • Blog
WAPSIWAPSIWAPSIWAPSI
  • W
  • A
  • P
  • S
  • I

Dockerisation ou l’automatisation de ses outils de test de performance

    Home Articles Dockerisation ou l’automatisation de ses outils de test de performance
    NextPrevious

    Dockerisation ou l’automatisation de ses outils de test de performance

    By WAPSI | Articles, Automatisation, Tests | Comments are Closed | 28 novembre, 2019 | 2

    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

    API, Docker, Dockerfile, Dockerisation, Gitlab, Jenkins, Neoload, test

    Related Post

    • Les principes des tests logiciels

      By WAPSI | Comments are Closed

      Cet article a pour finalité de définir les tests logiciels et de mettre en avant les principes des tests logiciels.  Tout d’abord, Qu’est-ce qu’un Test logiciel ?  Contrairement aux idées reçues, le test logiciel ne se limite pas àRead more

    • Quand l’infrastructure dynamique rencontre Neoload dans le cloud

      By WAPSI | Comments are Closed

      Les dépenses dues à la maintenance et la configuration de centaines de machines sont aux cœurs des débats dans les entreprises. En effet, afin de faire face à ces problématiques de coûts d’infrastructures et seRead more

    • Boite à outil : GIT

      By WAPSI | Comments are Closed

      Il est des incontournables dans la boite à outils des dev /devOps et affiliés et git fait partis de ceux-là… Mais qu’est-ce que git ? Essayons d’imager un peu. N’avez-vous jamais eu ce fameux document WordRead more

    • Selenium – les étapes vers l’automatisation

      By WAPSI | Comments are Closed

      Selenium est un framework dédié à l’automatisation de test disposant d’une version IDE et d’une version API nommé Selenium WebDriver qui peut être exploité avec plusieurs langages : PHP, Javascript, C#, Python, Ruby, Perl etRead more

    • Auto Deploy Custom Actions avec Gitlab

      By WAPSI | Comments are Closed

      Dans Neoload, les Custom Actions sont des modules développés en Java qui permettent de répondre à des besoins spécifiques. Ils s’intègrent à vos scénarios de tirs, on peut y définir des paramètres à prendre pour ensuiteRead more

    • Test de charge et IOT, comment faire ?

      By WAPSI | Comments are Closed

      Basiquement le test de charge est le principe de simuler des utilisateurs humains qui utilisent un navigateur pour vérifier que le serveur tient la charge.  Tous les outils de tests sont conçus pour reproduire le dialogue inhérent à ce type de conversationRead more

    NextPrevious
    WAPSI logo blanc

    NAVIGATION

    • WAPSI
    • Automatisation
    • Performance
    • Sécurité
    • Intelligence
    • Contact
    • Blog

    NOUS CONTACTER

    contact@wapsi.fr

    +33 6 72 35 13 26

    16 rue Washington 75008 Paris

    Tous droits réservés © 2019 WAPSI

    Mentions légales | Politique de Confidentialité
    • Accueil
    • Automatisation
    • Performance
    • Sécurité
    • Intelligence
    • Recrutement
    • Contact
    • Blog
    WAPSI