Argo, InfraBox und Tekton / Jenkins X Kubernetes-basierte Tools – die Erben von Jenkins

Anbieter zum Thema

ConSol Consulting & Solutions Software GmbH

dtm Datentechnik Moll GmbH

Jenkins ist der Platzhirsch unter den CI- und CD-Lösungen, hat aber wohl seine besten Jahre hinter sich. Neue, vielversprechende Tools drängen auf den Markt, die Technologien wie Kubernetes nicht nur als Option, sondern als native Plattform begreifen und daraus immensen Nutzen ziehen.

Jenkins genießt in vielen Softwarehäusern den Status eines De-facto-Standards für Continuous Integration (CI) sowie Continuous Delivery und Deployment (CD). Das kommt nicht von ungefähr, war die Plattform doch dank einer offenen Plug-in-Architektur für lange Zeit flexibel genug, um an geänderte Anforderungen angepasst zu werden.

Viele setzen Jenkins zusammen mit Kubernetes ein. Bei genauerem Hinsehen zeigen sich allerdings Schwächen dieser Kombination, die früheren Design-Entscheidungen geschuldet sind. Aus heutiger Sicht würde das Ergebnis anders ausfallen. Drei Beispiele:

• 1. Das Jenkins-eigene Clustering-Modell, um Pipelines auf Slave-Rechnern auszuführen, ist auf Kubernetes obsolet. Das kann die Cloud-Plattform besser organisieren.

• 2. Pipeline-Skripte in Jenkins sind heute oft komplizierte Gebilde, ebenso komplex wie ein normaler Programmcode. Sie basieren nicht selten auf wiederverwendbaren Pipeline-Modulen Marke Eigenbau.

• 3. Die Jenkins-Plugins, so flexibel sie die Plattform machen, sind oft mehr Fluch als Segen: Gerade bei langgedienten Installationen zeichnen sie sich häufig durch grassierenden Wildwuchs aus.

Wer die Themen CI und CD aus Cloud-nativer Perspektive noch einmal neu konzipiert, kommt zu einem Ergebnis, das sich erheblich von der Jenkins-Architektur unterscheidet. Dreh- und Angelpunkt dieses Konzeptes sind moderne Container-Technologien, die sowohl im Testing als auch Deployment heute den Ton angeben. Folgende Features sind dabei Must-Haves:

• Neue CI/CD-Tools sollten vollumfänglich in Kubernetes laufen, sowohl was das Hosting der Tool-Prozesse selbst als auch was das Scheduling der CI/CD-Pipelines angeht. Es darf keine Abhängigkeiten von bestimmten Public Host Providern geben.

• Als Pipeline-Schritte sollten „Pure Container“ verwendet werden, die unabhängig vom CI-Tool ausführbar sind. Der Container wird ausschließlich über Container-native Interfaces wie Dateisystem-Mounts, Umgebungs-Variablen und das Container-Entrypoint-Kommando parametrisiert.

• Der Ausführungszustand der gelaufenen Pipelines muss über eine Webseite ersichtlich sein.

• Die Pipeline muss als Quellcode definiert und aus Sourcecode-Projekten bezogen werden können.

Zu den Nice-to-Haves zählen folgende Features:

• Die Installation geht leicht über gängige Provisioning-Technologien auf Kubernetes von der Hand. Zwingenden Abhängigkeiten zu externen Systemen sind tunlichst zu vermeiden.

• Das Tool sollte auf den Einsatz von Containern, die unter Berechtigungen des „Root“-Benutzers laufen, verzichten und in eine GitOps-Gesamtlösung eingebunden sein.

• Die Pipelines der Projekte werden dezentral in eigenen Namespaces ausgeführt und ausschließlich über Kubernetes-Ressourcen konfiguriert.

Tatsächlich ist das Feld der passenden Lösungen trotz Zugeständnissen bei den Kriterien nicht allzu groß, weist aber einige interessante Jenkins-Herausforderer auf.

Argo

Das Argo-Projekt besteht im Kern aus der gleichnamigen Workflow-Engine, die explizit für Kubernetes entworfen wurde. Argo-Workflows bestehen aus einer Reihe von beliebigen Containern, die über die üblichen Container-Schnittstellen parametrisiert werden.

Die Bestandteile der Lösung, die Workflow-Engine selbst und das „Argo Events“ getaufte Event-Subprojekt sind sehr schnell installiert. Im Wesentlichen besteht die leichtgewichtige Installation aus vier Controller-Pods und dem UI-Pod. Argo kann problemlos pro Projekt dezentral installiert werden.

Argo merkt man an, dass es sich generisch auf Workflows spezialisiert hat. Dennoch kann man mit etwas Einsatz aus den Argo-Komponenten eine effektive und vor allem flexible CI-Pipeline bauen. Für die Konfiguration sowohl der Workflows als auch der Event-Handler verwendet Argo ausschließlich Kubernetes-Objekte und Custom Resources. Das relativ spartanische aber funktionale Web-Dashboard informiert über den aktuellen Stand der Workflows. Ein Command-Line-Client für das Definieren und Starten der Pipelines und ein separates Tool namens „Argo CD“ für GitOps-kompatibles Delivery runden das Angebot ab.

InfraBox

InfraBox von SAP SE wird als „Cloud Native Continuous Integration System“ positioniert, und setzt ebenfalls auf Kubernetes auf. Weder der Plattform-unabhängige Installations-Prozess noch das resultierende System mit zwölf Pods und zwei externen Abhängigkeiten, einem S3-Object-Storage und einer PostgreSQL-Datenbank können jedoch als leichtgewichtig bezeichnet werden.

Dafür ist InfraBox wohl das Tool mit der breitesten Feature-Palette. Es bringt bereits eine eigene Docker-Registry mit. Laut Dokumentation werden viele Einsatzszenarios unterstützt, unter anderem eine Multi-Cluster-Installation, die auch mehrere Cloud Provider überspannen kann. Es besitzt sogar eine integrierte Unterstützung für die Provisionierung von End-2-End-Testumgebungen. Wer etwas mehr Komfort und schlüsselfertige Funktionalitäten wünscht, sollte sich InfraBox genauer anschauen.

InfraBox setzt auf Custom Resource Definitions, um Pipelines, Funktionen und die Ausführung dieser Artefakte zu verwalten. Die Pipelines laufen in einem dedizierten Namespace „infrabox-worker“, was eher schlecht zu dezentralen Pipelines passt.

Pipeline-Schritte nennt Infrabox „Jobs“. Es gibt mehrere Job-Typen mit vorgefertigten Funktionen, zum Beispiel um Repositories auszuchecken oder um Images in die Registry zu übertragen. Es existiert aber auch ein generischer Job-Typ „docker-image“, der beliebige Images ausführen kann.

Tekton / Jenkins X

Tekton ist ein sehr junges Projekt. Ursprünglich ging es aus dem „Knative“-Produkt von Google hervor, einer standardisierten Plattform für Serverless-Applikationen auf Kubernetes. Tekton ist der extrahierte Kern der „Build“-Komponente von Knative. Der Hersteller von Jenkins plant, Tekton als alternative Engine seiner eigenen Cloud-nativen CI/CD-Lösung „Jenkins X“ zu nutzen.

Als dedizierte Cloud-native Lösung macht Tekton einiges richtig. Es basiert vollkommen auf Kubernetes Scheduling. Pipelines werden als einzelne Pods mit mehreren Containern als Build-Schritte ausgeführt, die unter voller Kontrolle der Pipeline-Definition stehen. Das Interfacing ist sauber, das heißt es gibt keine proprietären Kommunikationswege zwischen CI und Containern. Die Installation fällt leichtgewichtig aus: Es gibt zwei zentrale Verwaltungs-Pods, von denen einer, der Webhook-verarbeitende Pod, aber noch unter „root“ laufen muss.

Die Spezifikation von Tekton liest sich weitestgehend wie eine genaue Entsprechung der genannten Kriterien. Es ist jedoch nicht übersehbar, dass es sich in der aktuellen Version 0.11. um ein Projekt im Aufbau handelt. Konzepte wie Webhook-Verarbeitung und ein Command Line Interface sind vorgesehen. Ein Web-Dashboard existiert bereits. „Pipeline as Code“ mit Bezug der Definition aus einem Code-Repository wird zumindest im Zusammenspiel mit Jenkins X wohl möglich sein. CloudBees hat bereits in Aussicht gestellt, eine automatische Migration der herkömmlichen Jenkins-Files in das neue Format anzubieten.

Zukunft von Jenkins

Allen Lösungen gemein ist, dass sie sich auf einem guten Weg befinden, das CI/CD-Erbe von Jenkins anzutreten, da sie die erforderlichen Kriterien im Wesentlichen verinnerlicht haben. Dabei verfolgen sie durchaus unterschiedliche Ansätze und bedienen verschiedene Anforderungen.

• Das Argo-Projekt ist ein hochinteressantes Toolset für Workflows auf Kubernetes, bei dem CI nur ein Anwendungsfall unter anderen ist. Argo ist kein schlüsselfertiges CI-Produkt.

• InfraBox ist im Gegensatz dazu eine klassische, zentralistische Lösung mit einem reichen Set an Features und dem von Jenkins gewohnten Komfort.

• Tekton als zukünftige Engine von Jenkins X muss aktuell eher als eine perspektivische Lösung gelten, die aber noch einen produktionstauglichen Stand erreichen muss.

* Oliver Weise ist Senior Software Engineer bei der ConSol Software GmbH und leitet das Software Engineering-Team am Standort Düsseldorf.

(ID:46411104)