Continuous Load Testing
Lasttest mit GitLab, Jenkins und Gatling in DevOps integrieren
Stephan Dannewitz - Juli 2018Zielstellung des Continuous Integration und Deployment Prozesses
Der finale Schritt bei Continuous-Prozessen in der Softwareentwicklung ist letztendlich
die Kombination aus Continuous Integration (CI) und Continuous Deployment (CD). Ist
dieser Schritt erreicht, wird die Anwendung nach jedem erfolgreichen Build deployed.
Im Gegensatz zum Coninuous Delivery geschieht dies beim Continuous Deployment vollautomatisch
und nicht mehr auf Knopfdruck eines Entwicklers oder DevOps.
Am Beispiel unserer Homepage möchte ich diesen Prozess gerne mit Hilfe von Gitlab,
Jenkins und Gatling darstellen. Wir nutzen GitLab als Repository und Auslöser für
das Continuous Deployment, Jenkins für die Automatisierung des Build- und Deploy-Prozesses
und Gatling als Testwerkzeug, um die Erreichbarkeit aller Seiten zu gewährleisten.
Konfiguration von Jenkins und GitLab
Widmen wir uns zunächst der Konfiguration von Jenkins. Ihr benötigt das Git und
GitLab Plugin für Jenkins. Zudem solltet Ihr das Gatling-Plugin installieren, wenn
Ihr Eure Lasttestergebnisse von Gatling direkt in Jenkins nachvollziehen wollt.
GitLab Plugin
Git Plugin
Gatling Plugin
Im Anschluss legen wir ein Projekt mit einem aussagekräftigen Titel an und konfigurieren
als erstes im Bereich "Source-Code-Management" den Pull aus dem Git-Repository. Dafür
benötigt Ihr die URL eures Gits sowie die notwendigen Zugangsdaten. Hierfür kann es
sich lohnen, einen eigenen GitLab-Account für Jenkins zu erstellen. Ihr könnt natürlich
auch Eure eigenen Benutzerdaten verwenden. Wichtig ist nur: Ihr müsst die notwendigen
Zugriffsrechte am Repository besitzen.
Abbildung 2: Git Konfiguration in Jenkins
Eine weitere Möglichkeit wäre, Euch ein GitLab-API Token zu generien und dieses
statt Eurer Nutzerdaten zu verwenden. Hierbei kann auch die Gültigkeitsdauer und der
Scope des Tokens eingestellt werden. Das dafür notwendige Menü findet Ihr unter "User
=> Settings => Access Tokens".
Abbildung 3: Erstellung eines API GitLab Tokens
Jetzt kommt der interessante Part: Um ein Continuous Deployment umzusetzen, müssen
natürlich die entsprechenden Trigger konfiguriert werden. In unserem Fall gelten als
Build-Trigger Push- sowie Merge-Events. Weiterhin könnt Ihr beim Push ins Repository
auch einen Kommentar hinterlegen, der automatisch Eure Job-Pipeline in Gang setzt.
Wichtig ist weiterhin die Generierung eines Secret-Tokens, um GitLab zu authorisieren,
Push- und Merge-Events an Jenkins zu senden.
Abbildung 4: Konfiguration der Build-Trigger in Jenkins
Wie bereits erwähnt ist es notwendig, GitLab so zu konfigurieren, dass Jenkins
über das Push- oder Merge-Event in Kenntnis gesetzt wird. Die dafür notwendigen Einstellungen
findet Ihr in dem dafür vorgesehenen GitLab Repository => Settings => Integrations.
Hier findet die Konfiguration der "Webhooks" statt. Die Jenkins-Job-URL, das Secret-Token
(welches wir in Jenkins generiert haben) sowie die Event-Trigger werden hier konfiguriert
und gespeichert. Ob das Ganze bereits erfolgreich funktioniert, könnt Ihr über den
Button "Test" ausprobieren.
Abbildung 5: Konfiguration der Webhooks in GitLab
Lasttest mit Gatling
Den Build-Prozess unserer Homepage und den Upload werde ich in diesem Blog-Beitrag
nicht weiter erläutern. Der Lasttest mit Gatling ist in unserem Fall eher ein Erreichbarkeitstest
aller hochgeladenen Webseiten sowie der eingebundenen Bilder. Dafür wird während des
Build-Prozesses eine .csv-Datei erstellt, die alle hochgeladenen HTML-Seiten und deren
URLs enthält.
Für die Ausführung des Gatling-Scripts wird dieses zusammen mit der Projekt-Vorlage
aus dem GitHub im Repository hinterlegt:
Gatling Maven Plugin
Im Build-Bereich von Jenkins muss nun lediglich auf die "pom.html" gepointed und
das "Goal" festgelegt werden. Damit die Lasttestergebnisse von dem Gatling-Jenkins-Plugin
gefunden und archiviert werden können, solltet Ihr zunächst in den Post-Build-Aktionen
das "Enable simulation tracking" aktivieren. Weiterhin muss in der "pom.html" der Pfad
zum Root-Verzeichnis Eures Projektes festgelegt werden.
<plugin>
<groupId>io.gatling</groupId>
<artifactId>gatling-maven-plugin</artifactId>
<version>${gatling-plugin.version}</version>
<configuration>
<resultsFolder>../</resultsFolder>
</configuration>
</plugin>
Abbildung 6: Konfiguration des Gatling-Lasttests via Jenkins
Build-Tags und Notifications
Im Bereich "Post-Build-Actions" in Jenkins kann über den Git-Publisher der Build
mit einem Tag versehen werden. Empfehlenswert ist hier das Datum in den Tag zu integrieren.
Da Jenkins seit Version 1.597 keine integrierten Zeitstempel als Umgebungsvariable
bereitstellt, benötigen wir auch hier wieder ein Plugin. Hierfür empfehlen wir:
Build Timestamp Plugin
Achtet darauf, dass das Plugin unter "Jenkins verwalten => System konfigurieren"
aktiviert und korrekt konfiguriert ist.
Der letzte Schritt ist die Konfiguration der Benachrichtung - in unserem Fall
via Mattermost. Darüber wird sichergestellt, dass der zuständige Mitarbeiter jederzeit
über einen erfolgreichen oder fehlerhaften Build in Kenntnis gesetzt wird. QMETHODS
nutzt - wie bereits erwähnt - Mattermost als Chat- und Benachrichtigungsdienst. Auch
hier gibt es ein passendes Plugin für Jenkins. Dafür müsst Ihr lediglich den Endpoint
(Webhook) zu Eurem Mattermost-Chatroom hinterlegen. Bei Bedarf könnt Ihr noch ein
Icon hinzufügen.
Mattermost Plugin
Fazit & Empfehlungen
Continuous Load Testing leicht gemacht
-
Die Integration und Kombination aller verwendeten Tools gestaltete sich als überraschend
einfach. Durch die hohe Marktdurchdringung stellt Jenkins für jedes Tool das passende
Plugin bereit und erleichter somit die Umsetzung von solchen Projekten.
-
Das Lasttest Werkzeug Gatling eignet sich auch für Einsteiger hervoragend, um
Continuous Prozesse einzubinden. Das Script wird mit versioniert und besteht in unserem
Fall aus gerade einmal 43 Zeilen. Außerdem reicht ein Text-Editor (besser eine IDE
wie bspw. IntelliJ), um das Script anzupassen. Weiterhin stellt Gatling ein Plugin
bereit, um den Verlauf der Ergebnisse zu tracken. Die erzeugten HTML Reports können
direkt in Jenkins geöffnet werden.
-
GitLab hat uns von Anfang an überzeugt! Daher war es keine Überraschung, dass
sich die Webhooks mit Jenkins einfach umsetzen ließen.
Vereinzelte Stolpersteine
-
Es hat eine Weile gedauert, bis mir auffiel, dass Jenkins den Zeitstempel aus
der Umgebungsvariable ${BUILD_ID} entfernt hat und dafür jetzt ein Plugin benötigt
wird.
Continuous Integration, Delivery und Deployment
Jenkins
Gatling
Mattermost
Keywords
API
CD
CI
DevOps
Gatling
GitLab
Jenkins
Mattermost
Repository
Scrum
WebHook