Sieben Tipps und Best Practices für effiziente Jenkins-Umgebungen

Jenkins hat sich zum Standard-Tool für Continuous Integration entwickelt. Diese sieben Best Practices sorgen für eine effiziente Jenkins-Umgebung.

Dies ist die verkürzte Mitschrift eines Vortrags von Andrew Meyer auf der Jenkins User Conference 2015 in London zum Thema „7 Habits of effective Jenkins Users“. Andrew Bayer ist Build and Tools Architect bei Cloudera und seit 2009 Contributor für den Jenkins Core und für zahlreiche Plug-ins. Seine Tipps sind verallgemeinerte Empfehlungen, die nicht zwangsläufig für alle Jenkins-Umgebungen optimal sein müssen.

Jenkins hat sich mit mehr als 100.000 aktiven Installationen und mehr als 1.000 vorhandenen Plug-ins zu einer Art De-facto-Standard im Bereich Continuous Integration/Continuous Delivery entwickelt. Gerade für Einsteiger stellt sich dabei oft die Frage, wie sich Jenkins sicher, stabil und dabei trotzdem flexibel betreiben lässt und wie man am besten mit der großen Anzahl verfügbarer Plug-ins umgeht. Die folgenden sieben Best Practices geben Jenkins-Nutzern Anhaltspunkte für eine effiziente Jenkins-Umgebung.

1. Master-Instanz stabil und wiederherstellbar halten

Ohne Jenkins-Master steht meist die gesamte Produktivumgebung still, daher gehört die Verfügbarkeit des Masters mit zu den wichtigsten Dingen, die für eine Jenkins-Umgebung sichergestellt werden müssen. Hierzu gehört natürlich auch die Möglichkeit zur Wiederherstellung, da zum Beispiel Hardwareausfälle nie ganz ausgeschlossen werden können.

Als Best Practice empfiehlt sich hier die Verwendung von LTS-Produkten (Long Term Support), da diese vor der Veröffentlichung verschiedene manuelle und automatische Tests durchlaufen müssen und daher ein hohes Maß an Stabilität aufweisen. Neuere Jenkins-Releases außerhalb des Long Term Supports sollten daher nur in Ausnahmefällen eingesetzt werden, etwa wenn eine bestimmte Funktion aus wichtigen Gründen noch vor dem LTS-Release benötigt wird.

Anders als man dies aus Sicherheitsgründen vielleicht vermuten könnte, sollten Plug-ins zudem sehr konservativ mit Updates versorgt werden. In vielen Fällen stehen nur unzureichende Release Notes zur Verfügung, wodurch oft nicht klar ist, was mit der neuen Version verändert wurde. 

Das Resultat kann erneut eine instabile Jenkins-Umgebung sein, zusätzlich kann es aber auch zu Inkompatibilitäten mit bestehenden Workflows, Plug-ins oder anderen Tools kommen. Aus diesem Grund sollten Plug-ins nur aktualisiert werden, wenn dies unbedingt erforderlich ist und die aktualisierte Version in einer Testumgebung auch mit hoher Last und über einen längeren Zeitraum getestet wurde.

Eine weitere Best-Practice-Empfehlung für eine stabile Jenkins-Bereitstellung sieht Backups der Jenkins-Konfiguration vor. Dies kann entweder innerhalb von Jenkins über eines der zahlreichen Backup-Plug-ins erfolgen, beispielsweise über thinBackup, oder durch eine vollständige Kopie von $JENKINS_HOME. Da gerade letzteres meist recht lange dauert und viel Festplattenspeicher belegt, gibt es noch eine dritte Alternative, bei der nur die Konfigurationsdateien ohne alle Builds etc. gesichert werden.

2. Komplexität durch multiple Master verringern

Vor allem bei Jenkins-Bereitstellungen für viele verschiedene Projekte und Teams können multiple Jenkins-Master die Komplexität verringern und für mehr Agilität und Kontrolle sorgen. Eine Möglichkeit besteht darin, die Master nach Teams, Funktionen oder auch Zugriffsberechtigungen aufzuteilen.

Auf diese Weise ist der Neustart von Plug-in-Installation oder -Aktualisierungen einfacher und vor allem ohne Störungen anderer Teams möglich. Mehrere Master mit weniger darauf ausgeführten Jobs führen zudem zu einer höheren Stabilität und Flexibilität. In gleicher Weise sollten auch Jobs modularisiert und aufgeteilt werden, da Multi-Job-Builds beispielsweise die Wiederverwendbarkeit generischer Jobs über verschiedene Projekte oder Releases möglich machen.

3. Jenkins-Tasks automatisieren

In der gesamten IT nimmt das Maß an Automatisierung immer weiter zu, warum also nicht auch Jenkins-Tasks so weit wie möglich automatisieren? Zu diesem Zweck bietet sich das Scriptler-Plug-in für Jenkins an, mit dem sich Jobs nach gewissen Vorgaben aktivieren oder deaktivieren lassen oder die Build-Queue gelöscht werden kann. Mit Scriptler läst sich aber auch SCM-Polling beispielsweise nachts für alle Jobs deaktivieren oder der Log-Rotator für alle Jobs anstoßen.

Die Skript-Sprache Groovy wiederum bietet sich für Skripte innerhalb des eigentlichen Builds an, allerdings sollte hierbei der volle Zugriff von Groovy auf den Build bedacht werden, weswegen man vorsichtig mit den Groovy-Berechtigungen umgehen sollte. Groovy-Skripte stellen allerdings eine gute Möglichkeit zum Ausprobieren von Plug-in-Ideen dar und eignen sich auch für Aufgaben, die die Installation eines eigenständigen Plug-ins nicht rechtfertigen.

Zusätzlich zu den beiden genannten Möglichkeiten lassen sich Jobs aber auch über die REST API oder über die Kommandozeile in Jenkins anstoßen. Als weitere Alternative können ganze Jobs oder Workflows multipler Jobs als DSL definiert werden. Als Tools stehen hierzu beispielsweise das Job DSL Plug-in, das DotCI-Plug-in oder das noch recht neue und daher aktuell noch nicht mit Long Term Support erhältliche Workflow-Plug-in zur Verfügung.

4. So wenig Plug-ins wie möglich nutzen

Vor allem auf dem Master sollten keine Plug-ins installiert werden, die später gar nicht genutzt werden. Zudem gibt es oft funktionale Überschneidungen zwischen verschiedenen Plug-ins, weswegen gut überlegt sein sollte, welches Plug-in man für welche Aufgabe nutzt. Generell sollten so wenig Plug-ins wie möglich installiert und nicht mehr benötigte Plug-ins sauber deinstalliert werden.

In der Management-Übersicht von Jenkins gibt es Benachrichtigungen über alte Daten, die nach der Deinstallation eines Plug-ins gelöscht werden sollten. Auf diese Weise können Jobs und Build-Konfigurationsdateien verkleinert werden, was den Master und individuelle Jobs schneller macht. Zwar hat jede Jenkins-Bereitstellung eigene Anforderungen und Problemstellen, trotzdem gibt es einige empfehlenswerte Plug-ins, die für die meisten Jenkins-Nutzer einen genaueren Blick wert sein dürften, beispielsweise Tool Environment, EnvInject, Rebuild oder auch Build Timeout.

5. Integration mit weiteren Tools und Services

Als Open-Source-Software mit großer Community, weit mehr als 1.000 Plug-ins und der REST API lässt sich Jenkins sehr leicht mit anderen Tools und Services verbinden, seit kurzem beispielsweise auch mit Docker und Amazon AWS EC2. Weitere populäre Services wären GitHub, JIRA, Artifactory oder auch Gerrit. Den meisten Nutzen zieht man aus Jenkins erst in der Kombination mit anderen Tools, daher sollten sich Jenkins-Nutzer über Möglichkeiten und Plug-ins für ihre speziellen Anforderungen informieren. Das Jenkins-Wiki ist hierfür eine ideale erste Anlaufstation.

6. Slaves müssen austauschbar sein

Wenn ein Slave nicht mehr erreichbar ist, dann führt das zwar nicht zwangsläufig zu Problemen für die gesamte Produktivumgebung, setzt aber zumindest bestimmte Teams außer Gefecht. Aus diesem Grund sollten Jenkins-Slaves so austauschbar wie möglich sein. Im Fall der Fälle lässt sich der Jenkins-Umgebung dann anstelle des ausgefallenen einfach ein neuer Slave hinzufügen.

Im Grunde gibt es zwei Bereiche, durch die sich eine hohe Austauschbarkeit von Jenkins-Slaves erreichen lässt: Die Verwendung von Tools zum Konfigurations-Management wie Puppet, Chef oder Ansible sowie darauf aufbauend die Nutzung vorgefertigter Images über PXE-Umgebungen (Preboot Execution Environment) oder Cloud-Umgebungen.

Generell sollten Slaves als Best-Practice-Empfehlung so weit wie möglich generischen Aufgaben dienen, anstatt extra für spezielle Jobs erstellt zu werden. Dies sorgt nicht nur für eine höhere Austauschbarkeit, sondern ermöglicht meist auch eine höhere Auslastung der Slaves. Sofern trotzdem speziell angepasste Slaves benötigt werden, sollten sie nur bei Bedarf erstellt werden. Zudem sollten nie statisch Ressourcen einem Slave zugewiesen werden, der nur selten genutzt wird. Die effizienteste Ressourcen-Nutzung ergibt sich natürlich über die Cloud, egal ob Private oder Public Cloud.

7. Vorteile der Community nutzen

Open-Source-Software lebt von und mit der Community. Das Engagement in der Jenkins-Community führt so nicht nur zu einem größeren Verständnis des Continuous-Integration-Tools, sondern hilft auf der anderen Seite auch anderen Jenkins-Nutzern und damit dem Projekt als Ganzem. Möglichkeiten der Teilnahme gibt es dabei viele, vom Erfahrungsaustausch in Foren über Bug-Fixing bis hin zum Schreiben oder Erweitern von Jenkins-Plug-ins.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Juni 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über SOA

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close