Vom 22. – 25. Oktober besuchte ich die Jenkins World Europe Konferenz im französischen Nizza, was mir die Chance bot, mich intensiv mit anderen internationalen DevOps-Experten aus verschiedensten Bereichen auszutauschen. Als sehr positiv empfand ich die Möglichkeit mit Entwicklern in direkten Kontakt zu treten, um die Umsetzung der gesehenen Features zu diskutieren.
Gleich am ersten Tag habe ich an einem Hackathon teilgenommen, bei dem das Jenkins Configuration as Code (JCasC) Plugin und die Jenkins Kompatibilität mit Java 11 thematisiert wurden. Hier galt es Fehler zu finden und diese zu lösen.
Später erhielt ich das Angebot, Teil der weltweiten „Jenkins Pipeline Authoring Community“ zu werden. Die Special Interest Group trifft sich monatlich über Google Hangouts (Videotelefonie), wobei sich die Terminfestlegung aufgrund der unterschiedlichen Zeitzonen als recht kompliziert gestaltet. Ziel ist es, Best Practices für die Verwaltung der Pipelines zu verfassen. Was wir in den jeweiligen Meetings im Detail behandeln und diskutieren, ist öffentlich auf Youtube einsehbar. Den Link zu meiner ersten Session findet ihr hier.
Ich konnte erste Impressionen in den frühen Entwicklungsstand der „Cloud Native“ Transformation des Jenkins erlangen. Diese wird auch als „Serverless“ Jenkins bezeichnet. Dabei gibt es keine permanent laufende Instanz. Durch einen Trigger, beispielsweise durch einen Commit in einem Git Repository, wird dynamisch eine Jenkins Instanz gestartet und nach der Abarbeitung des Jenkinsfile wieder terminiert. Damit dies reibungslos von statten geht, ist das Zusammenspiel von folgenden Tools nötig:
- Jenkins Custom War Packager (CWP) ( https://github.com/jenkinsci/custom-war-packager)
- Jenkins Configuration as Code (JCasC) ( https://github.com/jenkinsci/configuration-as-code-plugin)
- Jenkinsfile Runner ( https://github.com/jenkinsci/jenkinsfile-runner)
Der Custom War Packager ermöglicht es die einzelnen Komponenten in einer YAML-Konfigurationsdatei zu spezifizieren. In dieser Datei wird die Jenkinsversion, sowie die verwendeten Plugins, eine oder mehre Konfigurationsdateien, die vom JCasC Plugin eingelesen werden definiert. Aus dieser „Bauanleitung“ wird dann ein Docker Image gebaut, dass das Jenkins War mit allen definiert Plugins enthält. Bisher war es nur möglich die Plugins in Txt-Datei zu spezifizieren und diese wurden beim Starten des Containers heruntergeladen. Dies hat den Nachteil, dass dadurch eine viele größere Startzeit entsteht, die in einem „Serverless“ Ansatz nicht hinnehmbar ist. Des Weiteren können Groovy Scripte beim Starten des Jenkins ausgeführt werden. Das Zusammenspiel von CWP und JCasC kann auch ohne Cloud benutzt werden und hat folgende Vorteile:
- Gute Lesbarkeit
- Komplett als Code persistierbar
- Einfache Rollbackmechanismen
Der Jenkinsfile Runner ermöglicht es lokal ein Jenkinsfile abzuarbeiten. Das kann beispielsweise zum Testen einer Pipeline verwendet werden. Durch die Kombination vom Jenkinsfile Runner und dem Custom War Packager kann man eine Container Image erstellen, das eine kurze Startzeit hat, alle benötigten Abhängigkeiten mitbringt und die sofortige Abarbeitung eines Jenkinsfile ermöglicht.
In einer Cloud, wo die Abrechnung nach Zeit geschieht reduziert das auch die Kosten, weil die Jenkins Instanz nur gestartet wird, wenn diese benötigt wird. Allerdings gibt es auch Nachteile, da es momentan noch keine Möglichkeit gibt die grafische Oberfläche zu verwenden. Dadurch kann man auch keine manuellen Freigaben machen, die noch in vielen Projekten benötigt werden.
Neugierig geworden? Noch mehr Konferenz-Erlebnisse gibt es hier:
Mit über 15 Jahren Erfahrung als System Engineer und System Architekt bin ich die “Allzweckwaffe” im Kampf gegen Bugs und Performanceprobleme. Den Rest meiner Arbeitszeit verwende ich zur Verbesserung unseres Monitoringsystems und des Netzwerks in unseren Rechenzentren.
