Jenkins-Konfiguration als Code

Job DSL oder skriptbasierte/deklarative Pipelines werden zum Standard, wenn es darum geht, Jobs in Jenkins zu definieren. Jetzt brauchen wir eine ähnliche Lösung, um Jenkins selbst zu verwalten.

Jenkins kann über native Systempakete oder Docker installiert oder eigenständig auf jeder Maschine mit installierter Java Runtime Environment (JRE) ausgeführt werden. Doch die Konfiguration von Jenkins ist unabhängig von der gewählten Ausführungsart aufwendig – und je mehr Plugins ihr verwendet, desto aufwendiger wird sie. Bei mehr als 1.400 verfügbaren Plugins ist ein schwer verwaltbarer Zustand schnell erreicht.

Sowohl Jenkins als auch seine Plugins erfordern eine manuelle Konfiguration, die standardmäßig nur über die UI verfügbar ist. Das Plugin Jenkins Configuration as Code (JCasC) ermöglicht uns, diese Konfiguration über menschenlesbare Konfigurationsdateien zu verwalten.

Warum haben wir (noch ein weiteres!) Jenkins-Plugin entwickelt?

Configuration as Code ist kein neues Konzept, und Jenkins bietet bereits Möglichkeiten zur Automatisierung seines Deployments, etwa durch Unterstützung für Init-Skripte, die in Groovy geschrieben sind. Das Problem: Ihr müsst Groovy kennen und die Funktionsweise von Jenkins und seinen Plugins verstehen. Außerdem werden Skripte und Konfiguration vermischt, was einem unserer wichtigen Prinzipien widerspricht: das „Was“ vom „Wie“ zu trennen.

Ein konkretes Beispiel ist JenkinsAsCodeReference, das bei Praqma entwickelt wurde. Ich arbeitete mit einem Kunden, der diesen Ansatz einführen wollte, und war von Anfang an begeistert. Damals hatte ich wenig Erfahrung mit Jenkins. Daher war es eine große Erleichterung, die bestehende Konfiguration bewahren zu können, ohne unlesbare XML-Dateien speichern oder Screenshots des bestehenden Setups für die Dokumentation erstellen zu müssen. Außerdem konnte ich dadurch ohne Bedenken experimentieren und implementieren.

JenkinsAsCodeReference wird inzwischen von mehreren Unternehmen eingesetzt, hat aber auch Nachteile. Es zwingt euch zur Nutzung von Docker und übernimmt zudem das Deployment von Jenkins. Ein erneutes Deployment ist zeitaufwendig, und die eigentliche Konfiguration wird mit Groovy-Skripten vermischt. Das wurde zunehmend störend. Deshalb entschieden wir uns für eine neue, bessere Lösung mit denselben Funktionen – und vielen weiteren. Sie sollte einfacher zu warten, schneller und in unterschiedlichen Szenarien einsetzbar sein, nicht nur mit Docker.

Mit wir meine ich mich und andere Entwickler von Praqma, zu denen später Ingenieure von CloudBees hinzukamen. Und mit besserer Lösung meine ich ein Plugin.

Bei der Vorbereitung des Plugin-Prototyps fanden wir bereits bestehende Lösungen. Ingenieure von CloudBees und regelmäßige Jenkins-Nutzer versuchten, genau dasselbe zu erreichen. Wir sahen darin eine großartige Gelegenheit zur Zusammenarbeit, nahmen Kontakt mit CloudBees auf und stellten fest, dass unsere Visionen, Ziele und Motivationen sehr gut übereinstimmten.

Jetzt arbeiten wir gemeinsam daran, diese Lösung zur Configuration-as-Code-Lösung für Jenkins zu machen.

Welche Vorteile bietet Jenkins Configuration as Code?

Ziel des Plugins ist es, für die Jenkins-Konfiguration das zu tun, was Job DSL einst für Jobs getan hat: Sie in Code zu überführen! Außerdem möchten wir aus den Herausforderungen bei der Entwicklung von Job DSL lernen. Damit das Plugin erfolgreich ist, muss es möglichst viele Plugins direkt unterstützen – ohne dass für jedes Plugin Verbindungscode geschrieben werden muss. Denken wir daran: Es gibt weit mehr als 1.000 davon. Nicht ALLE benötigen eine globale Konfiguration, doch die Anzahl der Plugins, die vom Jenkins-Configuration-as-Code-Plugin unterstützt werden müssen, ist dennoch beträchtlich.

Das ist eine Herausforderung, und wir wissen bereits, dass wir nicht alle Plugins unterstützen können. Es werden etwas Verbindungscode und eine Reihe von Pull Requests nötig sein, damit die Plugins unsere Anforderungen unterstützen. Wir sind jedoch überzeugt, dass es sich lohnt.

Jenkins Configuration as Code hilft euch nicht beim Deployment von Jenkins – dafür nutzt ihr weiterhin euren bevorzugten Weg über Container, Kubernetes, native Systempakete, Ansible oder Ähnliches. Aber sobald Jenkins startet, ist JCasC da, um euch zu unterstützen. Nach dem Deployment müsst ihr die globale Jenkins-Konfiguration unter „Manage Jenkins“ nicht mehr manuell bearbeiten.

Sobald ihr eure Konfigurationsdatei vorbereitet habt, kann Jenkins beim Start automatisch konfiguriert werden. Ihr könnt Jenkins innerhalb von Sekunden einfach wiederherstellen. Dieselbe Datei lässt sich auch für die Konfiguration mehrerer Jenkins-Instanzen verwenden. Oder ihr startet eine lokale Instanz, um Änderungen zu testen, bevor ihr sie in die Produktionsumgebung übernehmt.

Wenn ihr eure Konfigurationsdatei in einem VCS, beispielsweise einem Git-Repository, speichert – was ihr meiner Meinung nach tun solltet –, könnt ihr Änderungen an der globalen Jenkins-Konfiguration nachverfolgen. So könnt ihr eine vorherige Konfiguration schnell wiederherstellen, falls sich die neue als unzureichend erweist. Wenn etwas nicht funktioniert, lassen sich Änderungen außerdem einfach vergleichen und nachvollziehen.

Jenkins Configuration as Code ist das letzte fehlende Puzzleteil, um eure Jenkins-Instanz vollständig als Code zu verwalten. Ihr könnt jetzt eure Infrastruktur als Code verwalten.

Warum JCasC meiner Meinung nach einfach besser ist

Eine der vielen Herausforderungen, die wir uns gesetzt haben, war, die Jenkins-UI in einer Konfigurationsdatei möglichst genau nachzubilden. Wir wollten nicht durch lange Dokumentationsseiten scrollen müssen, um herauszufinden, wie das Mailer-Plugin oder die Details des Artifactory Servers konfiguriert werden. Und natürlich wollten wir auch nicht für jedes Plugin eine eigene Lösung implementieren. Wenn ihr also Erfahrung mit der Verwaltung von Jenkins habt, wird euch das Schreiben einer solchen Datei leichtfallen. Falls nicht, keine Sorge: Wir sind keine Gegner von Dokumentation – sie kann sich weiterhin selbst generieren! Darüber hinaus wird sie auf Grundlage eures tatsächlichen Jenkins-Setups erstellt und ist direkt auf eurem eigenen Server verfügbar.

Die Konfigurationsdateien für die globale Jenkins-Konfiguration sollten menschenlesbar sein. Sie sollen nicht an eine bestimmte Programmiersprache gebunden sein, kein spezifisches Wissen voraussetzen und Kommentare unterstützen. Deshalb haben wir YAML gewählt. Es lässt sich einfach schreiben, und dank verfügbarer Schemas könnt ihr auch Unterstützung in eurer IDE erhalten und eure Konfiguration prüfen, ohne eine Jenkins-Instanz auszuführen.

Und vor allem: Sobald ihr die Änderung in eurer Konfigurationsdatei vorgenommen habt, könnt ihr sie neu laden, ohne Jenkins neu zu starten. Keine zeitaufwendigen Redeployments mehr!

Möchtet ihr mithelfen?

Ich habe die Beteiligung von CloudBees-Ingenieuren am Plugin erwähnt, aber die Geschichte geht noch weiter. Wir haben das Konzept auf mehreren Meet-ups vorgestellt, und CloudBees hat Anfang Februar während der FOSDEM dafür geworben. Die Resonanz war groß – wir gewinnen bereits externe Mitwirkende. Pull Requests und Ideen für neue Features kommen laufend!

Auch ihr könnt euch beteiligen – je mehr PRs, desto besser. Erstellt gern Issues für Features oder Bugs. Wir wollen nicht nur unsere Probleme lösen, sondern auch eure!

https://github.com/jenkinsci/configuration-as-code-plugin ist jetzt die richtige Anlaufstelle!