JMeter (Jenkins + GitHub)

Qu’est-ce que Jenkins? #

Jenkins est un outil de continuité continue basé sur le projet open source Hudson, qui a été initié en 2004 par Sun Microsystems. Cependant, comme nous l’avons tous compris, Sun Microsystems a été acquis par Oracle Corporation en 2010, donc les droits sur Hudson ont été prétendus par Oracle, et le 2 janvier 2011, il a été décidé de changer le nom à Jenkins, bien que les deux projets continuent jusqu’à ce jour. Il y a des similitudes entre ces deux outils, mais la communauté de Jenkins est beaucoup plus grande. Certains outils alternatives de continuité continue incluent :

• Travis CI ( https://travis-ci.org/)
• Circle CI ( https://circleci.com/)
• Codeship ( https://codeship.com/)

Comment fonctionne Jenkins? #

Basiquement avec Jenkins, vous pouvez créer des flux ou des pipelines avec plusieurs étapes. Cela signifie que les actions (jobs) peuvent être automatisées, ce qui pourrait être connectés par des étapes et soumis à des conditions spécifiques, comme si l’action était réussie ou non. Par exemple, si une action a un code de sortie d’exécution égal à zéro, cela indiquerait que la tâche s’est terminée correctement ; sinon, si le code de sortie d’exécution différent de zéro, cela pourrait indiquer une faute de compilation, de construction ou d’exécution dans l’action. Par conséquent, vous pourriez arrêter ou arrêter entièrement le flux ou le pipeline.

Rappelez-vous que plusieurs plugins peuvent être installés dans Jenkins pour intégrer diverses canaux de communication pour les alertes des personnes impliquées lorsque le poteau ou la chaîne sont bloqués pour quelque raison. En fonction du processus et de la gestion de celui-ci, il commencera à nouveau à partir de la fin ou continuera avec les erreurs, ce qui est possible si y a une tolérance aux échecs.

Qu’est-ce que Github ? #

GitHub ( https://github.com/) est un plateforme distribuée et collaboratif pour le contrôle de version Git ( https://es.wikipedia.org/wiki/Git), spécifiquement conçu pour gérer et administrer les sources de code. GitHub est basé sur la framework Ruby on Rails ( https://es.wikipedia.org/wiki/Ruby_on_Rails) et écrit en langage de programmation Ruby ( https://www.ruby-lang.org/es/). En 2018, GitHub a été acquis par Microsoft et avec cela plusieurs entreprises qui avaient leurs sources de code sur GitHub ont migré vers des outils similaires comme :

• Git
• GitLab
• Gitea

Something worth mentioning about GitHub that contributed greatly to its popularity was the fact that it supported one of the largest DDoS (denial of service distributed) attacks in history. On February 28, 2018, it handled up to 1.35 Tbps (terabits per second) sent through 126.9 million packets per second via a vector attack from apparently 100,000 Memcached servers, and this was successfully contained thanks to the Akamai Prolexic service. There are strong suspicions that the main reason for the attack was to steal the source code of large software companies.

Comment fonctionne GitHub? #

GitHub est principalement basé sur les dépôts de fichiers, chaque dépôt ayant sa propre page web sur le plateau ainsi qu’un Wiki. Une fois que le dépôt est créé, les fichiers sont uploadés à lui via les commandes git add, git commit et git push. Vous pouvez consulter toutes les bases de Git ici : Bases de Git. Cela concerne la version des codes. Le logiciel a d’autres fonctionnalités, comme une interface graphique (GUI) disponible sur les plateformes Linux, MacOS et Windows, le site GitHub.com, Wiki, Kanban et interaction sociale, entre autres. Ce que nous cherchons pour cette publication est de créer un dépôt public pour notre intégration.

Comment fonctionne l’intégration de Jenkins et GitHub avec JMeter? #

La intégration est simple; vous devez simplement créer une répertoire public sur GitHub où nous avons nos scripts de JMeter hébergés, afin que Jenkins puisse cloner ce répertoire local et avoir la version désirée du script pour exécuter le test. L’exécution sera réalisée via le schéma distribué master-slave, qui peut être effectué sur une réseau privé (local) ou public. Les résultats seront sauvegardés dans l’espace de travail de Jenkins pour être consultés ultérieurement et également publiés en tant que HTML à travers un serveur Web Apache.

1. Mettre à jour notre script JMeter (JMX) sur GitHub.
2. Le projet Jenkins demande la localisation du cloning de cette répertoire.
3. GitHub permet le téléchargement des répertoires (peut-être un répertoire privé).
4. Jenkins exécute localement le JMeter (controleur) en mode distribué sur le node.
5. Le node transmet les résultats via RMI au serveur conteneur (Jenkins), et ces résultats sont stockés dans l’espace de travail.
6. Les résultats sont publiés dans la répertoire Apache et partagés sous forme HTML.

Pourquoi utiliser GitHub dans l’intégration? #

La principale raison pour laquelle nous recommandons l’utilisation d’un outil de contrôle des versions est de prévenir les erreurs envers l’update directe du script JMeter (JMX) sur le serveur Jenkins ou le générateur de charge. Cela peut conduire à des erreurs, comme manuellement placer un fichier incorrect ou une version erronée. Rappelons que moins d’accès points signifie plus de confiance dans les résultats.

Rappelez-vous que le dépôt utilisé peut également être privé, mais pour cela vous devrez configurer les identifiants d’accès pour le dépôt.

Pourquoi utiliser une script distribuée avec JMeter ? #

Je vous recommande fortement de ne pas exécuter le test sur la même machine que Jenkins est hébergée. C’est un très populaire mauvais pratique et je ne devrais pas lister toutes les raisons pour quoi c’est mauvais ; mais si il y a des doutes concernant cette publication, n’hésitez pas à consulter-la.

Oui, la publication couvre la configuration et l’idée générale, donc vous pouvez remplacer Jenkins par n’importe quel autre outil de continuité intégrée, ou également échanger GitHub par n’importe quelle autre système de contrôle des versions.

Qu’est-ce que nous avons besoin de ? #

Nous avons besoin d’un serveur web Apache installé que ce soit juste un petit script de commandes; il doit également avoir Jenkins installé et configuré pour pouvoir installer manuellement l’ intégration Git. Nous avons également besoin d’un dépôt de code Git où notre script JMeter sera hébergé, si il est public alors aucune installation supplémentaire n’est nécessaire; dans le cas contraire, vous devrez installer plugin d’authentification GitHub. Enfin, installez et configurez JMeter en mode distribué sur Jenkins (contrôleur) et l’ordinateur (générateur de charge) suivant les instructions mentionnées plus tôt.

Recette pour cuire #

1 - Créer un Projet #

Craignons une initiative open source et y configurerons le dépôt de code GitHub. Pour cet exemple, j’ai utilisé le dépôt de code JMeter_Script.

2.- Configurez le projet. #

Nous allons également configurer quatre paramètres qui ajusteront le nombre de utilisateurs concurrents, la durée du ramp-up et l’exécution des tests. Enfin, nous introduirons l’adresse IP locale où les tests seront exécutés. Pour accomplir cette tâche, vous devez suivre les publications ci-dessous selon que vous êtes dans un réseau privé ou réseau local ou public réseau. De plus, le script doit être prêt à accepter des paramètres comme indiqué dans cette publication.

Command line pour exécuter JMeter, car le rapport est automatiquement généré à la fin de la simulation dans l’espace de travail. Pour cette simulation, JMeter a été téléchargé et installé dans le conteneur Jenkins via le chemin JENKINS_HOME afin d’éviter les problèmes de permissions.

Command for Jenkins Linux/Unix/MacOS

$JENKINS_HOME/JMeter/apache-jmeter-5.3/bin/jmeter.sh -n -t $WORKSPACE/JMeter_Script_Plugins.jmx -l $WORKSPACE/JMeter_Script_Plugins-$BUILD_NUMBER.jtl -Jthreads=$Threads -Jrampup=$RampUp -Jduration=$Duration -R $RemoteEngine -e -o $WORKSPACE/$BUILD_NUMBER

Command for Jenkins Windows

%JENKINS_HOME%/JMeter/apache-jmeter-5.3/bin/jmeter.bat -n -t %WORKSPACE%/JMeter_Script_Plugins.jmx -l %WORKSPACE%/JMeter_Script_Plugins-%BUILD_NUMBER%.jtl -Jthreads=%Threads% -Jrampup=%RampUp% -Jduration=%Duration% -R %RemoteEngine% -e -o %WORKSPACE%/%BUILD_NUMBER%

Command pour copier les résultats de la Workspace vers le serveur Apache, afin qu’ils soient disponibles pour tous les utilisateurs depuis n’importe quel endroit. Il doit être noté que vous devez créer un dossier rapports et accorder aux utilisateurs Jenkins les permissions nécessaires pour écrire dedans.

cp -R $WORKSPACE/$BUILD_NUMBER /var/www/html/reports/

3.- Exécutez le projet #

Exécution du test, pour ce but nous sélectionnerons l’option “Construire avec des paramètres” (Construir con parámetros), ces paramètres seront pré-remplis avec les valeurs définies par nous. Une fois en exécution, nous entrerons les résultats de la build id (en ce cas #2) et examinerons l’output du “Console Output”. Après avoir terminé le test, nous vérifierons que les résultats sont stockés dans la workspace.

Le plus recommandé est de générer une image du noeud serveur afin que celui-ci puisse être arrêté lorsque le test n’est pas en cours (pour économiser les coûts) et lorsqu’il est nécessaire, on peut lancer-le et obtenir la nouvelle adresse IP du node serveur pour mettre à jour le paramètre avant chaque exécution.

4 - Évaluation des résultats #

Rappelez-vous de vérifier le rapport via un navigateur Web:

Concluison #

Cette solution semble être la meilleure façon de vous assurer d’exécuter votre test de charge avec une validité et des résultats que vous pouvez partager ou visualiser hors du Jenkins, car si vous avez besoin de revérifier les graphiques spécifiques ou les résultats, vous n’avez pas à entrer dans le Jenkins pour obtenir ces éléments. Cela aurait également été très simple d’obtenir les tableaux de résultats, puisque nous pourrions observer la dernière image web, ce qui rendrait comparaison et exportation des tables de résultats extrêmement utiles. Si nous avions plusieurs applications, nous pourrions créer différents répertoires comme /reportes/app1/ /reportes/app2/ etc., et facilement accéder à centaines de résultats depuis un navigateur.

Nous devons assurer que les fichiers de résultats JTL provenant du espace de travail (Workspace) sont protégés et sauvegardés. C’est très important car si le serveur Jenkins échoue, il est crucial d’avoir des copies de ces résultats historiques précieux. Il faut noter qu’il s’agit d’une opportunité en matière de sécurité et d’exposition de tels résultats. Il n’est pas conseillé de travailler toujours avec les administrateurs gérant Jenkins, Git ou services Web pour renforcer la sécurité et les permissions avant d’exposer des informations sensibles internes ou externes.