© Macrovector/Shutterstock.com
Mit der Migration zu Kubernetes wird bei Jenkins alles anders

Jenkins-less CI/CD mit Kubernetes


Jenkins X ist das jüngste Produkt aus dem Hause CloudBees, dem Hersteller von Jenkins. Außer dem Namen bleibt nicht viel von der weitverbreiteten Continuous-Anything-Plattform, die weitere Verwendung des Namens Jenkins ist sowohl Heilsversprechen als auch Menetekel. Zum einen versucht man wohl, die Jünger des altbekannten Butlers mitzunehmen, zum anderen schreckt man leider auch neue potenzielle Nutzer ab.

Mit Jenkins verband viele seiner Fans und Kritiker eine Hassliebe: Das Ökosystem rund um den klassischen Jenkins ist mit seinen über 1 000 Plug-ins sehr leistungsfähig und vielseitig, aber leider auch kompliziert und fehleranfällig. Wird sich das mit Jenkins X ändern? Viele Nutzer suchen (vermeintlich) einfache Build Engines, wie sie z. B. durch das inzwischen eingestellte Travis CI auf Basis einer YAML-Konfigurationsdatei vorlagen. Aber was ist mit komplexeren Build- oder Deployment-Szenarien? Lassen die sich damit realisieren? Sind sie überhaupt noch nötig? Jenkins X versucht, neue Wege zu gehen, aber gleichzeitig konzeptionell an die vielen Jahre Erfahrung der Jenkins-Entwicklung und die daraus gewachsene Gemeinde der Nutzer anzuknüpfen.

Die gute Nachricht: Jenkins X realisiert wie der Vorgänger im weitesten Sinne auch wieder eine Continuous-Integration/Delivery-Plattform – allerdings technisch komplett anders als der Vorgänger. Außerdem ist Jenkins X auch wieder ein Open-Source-Projekt [1] und es gibt kommerziellen Support von CloudBees [2].

So gut wie alles ist technisch neu, wobei die wichtigste Änderung die Ausführungsplattform betrifft. Jenkins X funktioniert ausschließlich auf Kubernetes und Derivaten wie OpenShift. Es kann sich potenziell um ein sehr kleines Kubernetes mit nur einem Knoten handeln, aber die Verwendung von Kubernetes ist unabdingbare Voraussetzung, da Jenkins X in vielen Komponenten eine Erweiterung von Kubernetes ist. Es implementiert viele seiner Funktionen als sogenannte Custom Resource Definitions und erweitert damit das Kubernetes API (Kasten: „Jenkins-X-Background: Kubernetes und Helm“).

Jenkins X wird von einem komplett neu aufgebauten Team rund um James Strachan entwickelt. James gehörte schon zu den Urvätern von Groovy, dem Apache-Camel-Projekt und auch dem von Red Hat getriebenen fabric8. Der Urheber von Jenkins, Kohsuke Kawaguchi, spielt bei Jenkins X keine Rolle mehr und hat CloudBees mittlerweile verlassen.

Ebenso ist der klassische Jenkins kein Bestandteil des Jenkins-X-Universums mehr. Zu Beginn der neuen Plattformentwicklung wurde Jenkins als permanenter Server (Kubernetes Service) deployt, in einer späteren Zwischenvariante wurde Jenkins noch zum Ausführen einer Build Pipeline gestartet. Seit der Version 2.0 von Jenkins X ist die Default-Pipeline-Engine das aus Knative hervorgegangene Tekton-Projekt [3]. Tekton wird über eine YAML-Datei konfiguriert. Somit hat man sich also der neuen Welt der (vermeintlich) einfachen Pipeline Engines angenähert.

Insgesamt setzt Jenkins X auf verschiedene Grundprinzipien, die sich an vielen Punkten der Umsetzung wiederfinden, unter anderem:

  • Infrastructure as Code: Jegliche Infrastruktur (auch Jenkins X selbst) wird als deklarativer Code (Konfigurationen) beschrieben und automatisiert von Tools ausgerollt. Eine manuelle Konfiguration, z. B. über ein UI oder gar (Web-)GUI erfolgt nicht. Selbst die Verwendung von Parametern bei der initialen Konfiguration führt zur Hinterlegung der Parameter in einer Datei, die dann von einem Tool zur Installation der jeweiligen Komponente genutzt wird.

  • Jenkins X ist opinionated: Das Jenkins-X-Team versucht, typische Abläufe und Methoden zu formalisieren und auf standardisierte Komponenten (Kubernetes, Docker, Tekton, Helm, GitOps etc.) zurückzuführen. Das Team operationalisiert diese Standards (im Jenkins-X-Universum), z. B. Build und Deployment einer Anwendung oder den Umgang mit Feature Branches. Folgt man der Standardisierung (also der „Meinung“ des Teams), muss man in der Regel wenig machen und vieles zunächst nicht in aller Tiefe verstehen – es sollte einfach funktionieren. Erst wenn man von den vorgegebenen Standards abweichen und Abläufe an eigene Erfordernisse anpassen will, muss man sich mit den Details auseinandersetzen.

Diese Grundprinzipien erlauben einerseits, ein mächtiges Werkzeug sowohl aus Entwickler- als auch aus Betriebssicht mit wenig Aufwand nutzen zu können, andererseits erfordern sie aber eine Auseinandersetzung mit den Tiefen der Umsetzung, die unter Umständen über den Einsatz der einzelnen Komponenten hinausgeht, wenn man eigene Anpassungen vornehmen möchte. Man kann beispielsweise nicht – wie im klassischen Jenkins – schnell mal einen Build-Job (per UI) aufsetzen und explorativ entwickeln, sondern das muss immer auf dem Umweg über Code erfolgen (bei näherem Hinsehen gibt es allerdings auch hier Mittel und Wege, das zu vereinfachen).

Werfen wir nun einen Blick auf die Installation von Jenkins X und die Initialisierung eines Projekts zur Nutzung im Entwicklungsprojekt. Anschließend zeigen wir typische Abläufe im Betrieb von Jenkins: den Bau von Artefakten bis zum Deployment in Kubernetes inklusive der Konfiguration der Pipelines.

Jenkins-X-Background: Kubernetes und Helm

Jenkins X läuft ausschließlich auf Kubernetes und nutzt für viele Dinge den Kubernetes-Package-Manager Helm. Beide Technologien können wir hier nur kurz und relativ allgemein anreißen.

Kubernetes

Kubernetes ist eine Abstraktion über verschiedene Cloud-Provider. Es basiert auf der Docker-Technologie und ermöglicht die Orchestrierung von Anwendungscontainern (Feinheiten wie die Verwendung von anderen leichtgewichtigen Containertechnologien ignorieren wir der Einfachheit halber). Jede Anwendung besteht in Kubernetes aus einem oder mehreren (Docker-)Container(n), den sogenannten Pods. Kubernetes kann so konfiguriert werden, dass mehrere Instanzen der Anwendung gestartet werden, auch dynamisch z. B. je nach Last oder Verfügbarkeitsanforderungen. Die Schnittstelle einer Anwendung wird in Kubernetes als Service bezeichnet. Die Anwendungen/Services können sich untereinander aufrufen und sind auch von außerhalb eines Kubernetes-Containers aufrufbar. Ein Kubernetes-System (eine Instanz) wird auch als Kubernetes-Cluster bezeichnet. Der Cluster besteht in der Regel aus mehreren realen oder virtuellen Maschinen des zugrunde liegenden Cloud-Providers und Kubernetes verteilt (orchestriert) die Anwendungen darauf. Dabei berücksichtigt Kubernetes die Auslastung (Speicher, CPU, Netz, I/O) der einzelnen Knoten des sie verbindenden Netzwerks und der verfügbaren Speichermedien.

Alle Kubernetes-Implementierungen der verschiedenen Cloud-Anbieter bieten (je nach Kubernetes-Version) neben ihren spezifischen Diensten eine einheitliche Laufzeitschnittstelle (Docker) und allgemeine Kubernetes-Dienste an, z. B. den Kubernetes-API-Server. Der API-Server implementiert eine REST-Schnittstelle, über die ein Cluster verwaltet wird. Alle Ressourcen (Anwendungen, Pods, Deployments und viele weitere) si...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang