🌐 Auch auf: English · Français · Español
Heute habe ich mir in meinem Homelab ein bisschen Zeit für Jenkins genommen.
Für alle, die es irgendwie geschafft haben, Jenkins im letzten Jahrzehnt aus dem Weg zu gehen: Jenkins ist einer der meistgenutzten Open-Source-Automatisierungsserver überhaupt. Ursprünglich 2011 als Fork des Hudson-Projekts veröffentlicht, ist Jenkins zu einem der Grundpfeiler moderner DevOps-Workflows geworden. Eingesetzt wird es vor allem für Continuous Integration (CI) und Continuous Delivery (CD) – es automatisiert Software-Builds, Tests, Deployments und alle möglichen wiederkehrenden Admin-Aufgaben. Wenn sich ein Prozess automatisieren lässt, kann Jenkins das sehr wahrscheinlich übernehmen. 😎
Bisher liefen in meinem Homelab zwei klassische Cronjobs. Ihre Aufgabe ist ziemlich simpel: Jede Nacht erstellen sie per rsync Backups von zwei aus dem Internet erreichbaren Nextcloud-Instanzen.
Das Setup lief schon eine ganze Weile völlig problemlos. Wenn es aber um Monitoring und Logging geht, ist Cron nach wie vor das Werkzeug der Wahl für Kommandozeilen-Fans und Unix-Veteranen. Am Ende wühlst du dich durch Logdateien, prüfst von Hand, ob die Jobs erfolgreich gelaufen sind, und fragst dich gelegentlich, ob ein fehlgeschlagenes Backup nun drei Tage oder drei Wochen her ist.
Natürlich ist Cron unglaublich zuverlässig und schlank. Aber seien wir ehrlich: Ein besonders modernes Nutzererlebnis bietet es nicht gerade.
Da Jenkins in meinem beruflichen Umfeld künftig sehr wahrscheinlich eine größere Rolle spielen wird, habe ich beschlossen, es endlich auch in meinem Homelab auszurollen und praktische Erfahrung zu sammeln.
Ein erwähnenswertes Detail: Jenkins läuft auf derselben Maschine, auf der bereits GitLab läuft. Da GitLab schon auf TCP-Port 8080 lauscht, musste Jenkins auf TCP-Port 8090 umkonfiguriert werden.
Aktuelle Jenkins-Konfiguration
Im Moment ist die Jenkins-Konfiguration bewusst einfach gehalten.
Ich habe zwei Jobs vom Typ Freestyle Project angelegt. Wie bei meinem bisherigen Cron-Setup hat jeder Job seinen eigenen Zeitplan, der festlegt, wann er läuft. Das eigentliche Backup ist nichts anderes als der Aufruf eines lokalen Shell-Skripts.
Bisher funktioniert alles einwandfrei. Jenkins bietet eine praktische Weboberfläche, in der ich sofort sehe, ob Jobs erfolgreich gelaufen sind, wann sie ausgeführt wurden, wie lange sie gedauert haben und welche Ausgabe sie erzeugt haben.
Verglichen mit dem manuellen Durchforsten von Cron-Logs fühlt sich das schon jetzt nach einem deutlichen Komfortgewinn an. 😊
Eine zusätzliche Anpassung war noch nötig. Jenkins selbst läuft unter seinem eigenen Dienstkonto jenkins, während meine Backup-Skripte als Benutzer user3 ausgeführt werden wollen. Statt Berechtigungen und Besitzverhältnisse umzubauen, habe ich den Build-Schritt einfach so konfiguriert, dass er die Skripte über sudo -u user3 startet. So bleibt Jenkins für Zeitplanung und Überwachung der Jobs zuständig, während die eigentliche Backup-Logik unter dem Konto läuft, das ohnehin schon Zugriff auf die benötigten Dateien und Verzeichnisse hat. 😎
Job-Konfigurationen als XML exportieren
Ein besonders nützliches Feature, das ich entdeckt habe: Jenkins erlaubt es, jede Job-Konfiguration als XML zu exportieren.
Um eine Job-Konfiguration abzurufen, hängst du einfach /config.xml an die Job-URL an und authentifizierst dich mit einem gültigen Jenkins-Benutzerkonto:
curl -u <user>:<password> \
http://192.168.10.x:8090/job/Backup-InstanceB/config.xml
Interessanterweise hat der direkte Abruf der XML-Konfiguration im Browser bei mir nicht funktioniert. Mit curl auf der Kommandozeile klappte es dagegen tadellos.
Das resultierende XML enthält die komplette Job-Definition und taugt damit nicht nur zur Dokumentation, sondern auch als schlankes Backup der Jenkins-Konfiguration.
Konfiguration von Backup-InstanceA
user3@hp1:~$ curl -u <user>:<password> http://192.168.10.x:8090/job/Backup-InstanceA/config.xml
<?xml version='1.1' encoding='UTF-8'?>
<project>
<actions/>
<description>rsync</description>
<keepDependencies>false</keepDependencies>
<properties/>
<scm class="hudson.scm.NullSCM"/>
<canRoam>true</canRoam>
<disabled>false</disabled>
<blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
<blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
<triggers>
<hudson.triggers.TimerTrigger>
<spec>H 1 * * *</spec>
</hudson.triggers.TimerTrigger>
</triggers>
<concurrentBuild>false</concurrentBuild>
<builders>
<hudson.tasks.Shell>
<command>sudo -u user3 /raid5/shared/shared/ablage/nextcloud_backup_and_restore/instance-a_backup_nextcloud_remote.sh</command>
<configuredLocalRules/>
</hudson.tasks.Shell>
</builders>
<publishers/>
<buildWrappers/>
</project>
Konfiguration von Backup-InstanceB
user3@hp1:~$ curl -u <user>:<password> http://192.168.10.x:8090/job/Backup-InstanceB/config.xml
<?xml version='1.1' encoding='UTF-8'?>
<project>
<description>rsync</description>
<keepDependencies>false</keepDependencies>
<properties/>
<scm class="hudson.scm.NullSCM"/>
<canRoam>true</canRoam>
<disabled>false</disabled>
<blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
<blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
<triggers>
<hudson.triggers.TimerTrigger>
<spec>H 2 * * *</spec>
</hudson.triggers.TimerTrigger>
</triggers>
<concurrentBuild>false</concurrentBuild>
<builders>
<hudson.tasks.Shell>
<command>sudo -u user3 /raid5/shared/shared/ablage/nextcloud_backup_and_restore/sofie_backup_nextcloud_remote.sh</command>
<configuredLocalRules/>
</hudson.tasks.Shell>
</builders>
<publishers/>
<buildWrappers/>
</project>
Fazit
Rein technisch betrachtet ist es vermutlich ein Lehrbuchbeispiel für Overengineering, zwei tadellos funktionierende Cronjobs durch Jenkins zu ersetzen. 😄
Andererseits bietet Jenkins zentrales Logging, eine Ausführungshistorie, Statusinformationen und eine benutzerfreundliche Weboberfläche, die das Überwachen geplanter Aufgaben deutlich angenehmer macht.
Im Moment ist Jenkins schlicht dafür zuständig, zwei Backup-Skripte zu starten. Aber jedes Homelab-Experiment fängt klein an, und die Erfahrung zeigt: Ist Jenkins erst einmal da, bleibt es selten bei nur zwei Jobs.
Mal sehen, wohin die Reise als Nächstes geht. 🚀
