Consol testet moderne CI- und CD-Tools

Cloud-native Alternativen zu Jenkins

| Redakteur: Stephan Augsten

Bei der Cloud-nativen Entwicklung hat Jenkins möglicherweise ausgedient, Jenkins X könnte diese Lücke mit einigen Anpassungen aber füllen.
Bei der Cloud-nativen Entwicklung hat Jenkins möglicherweise ausgedient, Jenkins X könnte diese Lücke mit einigen Anpassungen aber füllen. (Bild: Jenkins-X.io)

Beim Cloud-native Development stoßen gängige Continuous-Integration- und -Delivery-Tools an ihre Grenzen. Auf Microservice-Architekturen sind diese Werkzeuge schlicht nicht ausgerichtet, meint das Consulting-Unternehmen Consol, das einige Alternativen identifiziert hat.

Cloud-native Anwendungen setzen verstärkt auf Microservices-Architekturen, die von einer höheren Geschwindigkeit und Komplexität als klassische Umgebungen geprägt sind. Sowohl Werkzeuge als auch Workflows für Continuous Integration (CI) und Continuous Delivery (CD) müssen grundlegend überdacht werden.

Laut dem Beratungsunternehmen Consol sind „klassische“ CI- und CD-Tools wie Jenkins an dieser Stelle weniger geeignet. Das Unternehmen empfiehlt Lösungen, die ihrerseits einen Cloud-native-Hintergrund haben und dementsprechend auf Function-as-a-Service-Plattformen ausgerichtet sind.

Wichtige Kriterien, die solche Tools erfüllen sollten, sind unter anderem Hosting und Scheduling auf Kubernetes, Container als Pipeline-Schritte, Web-UI und „Pipeline as Code“. Consol hat sich drei moderne CI/CD-Projekte beziehungsweise -Tools genauer angesehen.

Laut Oliver Weise, Senior Software Engineer bei Consol, könnten alle der hier genannten Tools das CI- und CD-Erbe von Jenkins antreten: „Aus unserer Sicht [erfüllen sie] alle erforderlichen Kriterien […], auch wenn sie verschiedene Ansätze verfolgen und unterschiedliche Anforderungen abdecken.“ Die Ergebnisse von Consol greifen wir hier im Wortlaut auf:

1. 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“ genannte Event-Subprojekt, sind sehr schnell installiert. Die Installation umfasst im Wesentlichen vier Controller-Pods und das UI-Pod und ist somit leichtgewichtig. Argo kann problemlos dezentral pro Projekt installiert werden.

Dem Projekt ist anzumerken, dass es sich generisch auf Workflows spezialisiert und nicht speziell auf Continuous Integration zugeschnitten ist. Dennoch ist es möglich, aus den Argo-Komponenten eine effektive und vor allem flexible CI-Pipeline aufzubauen. Dazu existieren diverse Beispiele in den Repositories des Herstellers. So kann etwa via Argo Events eine Webhook-URL eingerichtet werden. Bei Aufruf startet sie einen Argo-Workflow als Pipeline, dessen Definition aus dem Git-Repository zu laden ist. Das Repository wird im Payload des Aufrufs angegeben. Damit ergibt sich letztlich eine „Pipeline as Code“-Funktionalität.

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 den Aspekt Delivery runden das Angebot ab.

2. InfraBox

InfraBox von SAP wird als „Cloud Native Continuous Integration System“ positioniert und setzt ebenfalls auf Kubernetes auf. Das Deployment besteht aus einer größeren Menge an Pods inklusive einiger externer Abhängigkeiten und ist deswegen nicht mehr wirklich leichtgewichtig zu nennen.

Allerdings ist InfraBox das Tool mit der breitesten Feature-Palette. Es bringt bereits eine eigene Docker-Registry mit und laut Dokumentation werden viele Einsatzszenarien unterstützt, unter anderem auch eine Multi-Cluster-Installation, die sich über mehrere Cloud Provider erstrecken kann. Sogar eine integrierte Unterstützung für die Provisionierung von End-2-End-Testumgebungen ist vorhanden.

Auch 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 aber eher schlecht zu dezentralen Pipelines passt.

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

Nicht zuletzt sind noch erwähnenswert das Web-UI, das vergleichsweise komfortabel ist und die Möglichkeit benutzerdefinierter Darstellungen bietet, und das Command Line Interface „infraboxcli“, das den Entwickler beim lokalen Debugging von Jobs unterstützt.

3. Tekton und Jenkins X

Tekton ist ein sehr junges Projekt. Ursprünglich ging es aus Googles „Knative“-Produkt hervor, einer standardisierten Plattform für Serverless-Applikationen auf Kubernetes. Tekton ist der extrahierte Kern der „Build“-Komponente von Knative. Das Projekt wird von der ebenfalls erst vor Kurzem gegründeten „Continuous Delivery Foundation“ verwaltet, die nach eigenen Aussagen der Fragmentierung der CI- und CD-Landschaft entgegentreten will.

Neben Google und weiteren Unternehmen ist hier auch CloudBees Mitglied. Der Jenkins-Hersteller plant, Tekton als alternative Engine seiner eigenen Cloud-nativen CI- und CD-Lösung „Jenkins X“ zu nutzen. Jenkins X besteht bisher aus dem bekannten Jenkins plus Kubernetes-Anbindung und speziellem Tooling. Aktuell ist diese Integration aber noch experimentell.

Als dedizierte Cloud-native Lösung macht Tekton einiges richtig. Sie basiert vollkommen auf Kubernetes-Scheduling und 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 Container. Als Image-Build-Tool wird „Kaniko“ propagiert. Die Installation ist leichtgewichtig und es gibt zwei zentrale Verwaltungs-Pods. Die Pipelines selbst werden als Custom Resources in den jeweiligen Projekten definiert und dort auch ausgeführt.

Bei Tekton handelt es sich allerdings noch um ein Projekt im Aufbau – die aktuelle Version ist 0.8.0 – vor allem auch im Hinblick auf die Dokumentation. Konzepte wie Webhook-Verarbeitung und ein Command Line Interface sind vorgesehen. „Pipeline as Code“ mit Bezug der Definition aus einem Code-Repository wird zumindest im Zusammenspiel mit Jenkins X vermutlich möglich sein. CloudBees hat bereits in Aussicht gestellt, eine automatische Migration der herkömmlichen Jenkins-Files in das neue Format anzubieten.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46216381 / CI / CD)