Tekton oder Jenkins: Was ist besser für CI/CD-Pipelines in Red Hat OpenShift?

Tekton ist aus dem Knative-Projekt hervorgegangen und wurde anschließend von Red Hat als Zukunftstechnologie für die Pipeline in Red Hat OpenShift unterstützt. Als ich 2018 zum ersten Mal von Tekton hörte, war meine erste Reaktion: „Welches Problem versuchen wir hier zu lösen?“. Schließlich kenne ich Jenkins, und mir gefällt Jenkins – warum sollte ich mich also auf den Lernprozess neuer Technologien einlassen, wenn das, was ich jetzt habe, schon gut funktioniert?

Red Hat ausgezeichnet als Leader im 2023 Gartner® Magic Quadrant™

Red Hat wurde im Gartner 2023 Magic Quadrant für Container Management hinsichtlich der Ausführungsfähigkeit und der umfassenden Vision bestplatziert.

Bericht lesen

Bei der Frage „Warum ist Tekton besser als Jenkins?“ lautet die häufigste Antwort: „Tekton ist cloudnativ“, gefolgt von einem Schweigen oder einem schnellen Themenwechsel. Also machte ich mich auf die Suche nach einer klaren Definition des Begriffs „cloudnativ“ und erwartete einen Heureka-Moment. 

Im Jahr 2018 veröffentlichte die Cloud Native Computing Foundation (CNCF) folgende Definition: „Mit cloudnativen Technologien können Unternehmen skalierbare Anwendungen in modernen, dynamischen Umgebungen wie Public, Private und Hybrid Clouds erstellen und ausführen.“

Das hat jetzt kein wirkliches Licht ins Dunkel gebracht. Außerdem habe ich eine eindeutig irrationale Bindung an Dinge, die ich seit Jahren nutze und die gut funktionieren. Doch bevor ich dem guten alten Jenkins den Laufpass gebe, musste ich mich noch weiter davon überzeugen, dass das Gras auf der anderen Seite des Zauns wirklich grüner ist. Tekton musste mir etwas bieten, das erheblich über das hinausgeht, was ich bereits hatte, damit ich mich von Jenkins abwende. 

Letztendlich bin ich zu dem Schluss gekommen, dass Tekton sich im Bereich OpenShift/k8s besser integrieren lässt und neue Möglichkeiten eröffnet, die Jenkins meiner Meinung nach nicht unbedingt bieten kann.

Dies wird im weiteren Verlauf dieses Artikels erläutert. Wenn Sie sich die gleichen Fragen stellen, hoffe ich, dass Sie einige der Antworten finden, nach denen Sie suchen.

Meine Erfahrungen mit Jenkins

Seien wir ehrlich: Jenkins, die gute alte Institution, ist veraltet. Es erschien erstmals um das Jahr 2005 und hat sich seitdem nicht wirklich stark verändert. Seine größte Stärke ist die riesige Auswahl an Plugins, mit denen Sie praktisch alles verbinden können. Aber das ist auch eine Schwäche, denn diese Plugins haben einen unbestimmten Software-Lifecycle. Wenn ein Problem mit ihnen auftritt, müssen Sie es in der Regel einfach umgehen. 

Jenkins basiert auf Java und ist bekanntermaßen speicher- und prozessorlastig, da es konstant ausgeführt wird. Angesichts der Gesamtkosten für Compute-Ressourcen kann dies zu einem Problem werden.

In der Zeit vor der Einführung von Containern gab es typischerweise ein „großes“ Jenkins, bei dem die gesamte Entwicklungsabteilung einen einzigen Jenkins-Server nutzte, was folglich zu einem Engpass führte. Da es mit der großen Last, die ihm aufgebürdet wurde, nicht zurechtkam, hieß es oft, dass Jenkins sich aufgehängt hatte und neu gestartet werden musste. Also musste man wieder von vorne anfangen. 

Dann wurden Container eingeführt, und jetzt konnte jedes Team einen Jenkins-Server besitzen und ihn nach seinen Anforderungen konfigurieren. Dadurch ist jedoch ein weiteres Problem entstanden – der sogenannte „Jenkins-Sprawl“. All diese Jenkins-Server rattern vor sich hin, haben die meiste Zeit nicht viel zu tun und generieren Unmengen an Kosten. Ganz zu schweigen von den vielen verschiedenen Arten von Pipeline-Code, die jedes Team propagiert.

Daher wäre es schön, etwas mit einem sehr kleinen Footprint zu haben, das für die einzelnen Teams dezentralisiert werden könnte, während die Pipelines trotzdem ähnlich aussehen. Behalten Sie diese Gedanken im Hinterkopf, denn wir werden später noch einmal darauf zurückkommen.

Modelle zur Prozess-Sequenzierung

In einem Softwaresystem müssen wir eine Möglichkeit haben, die Abfolge von Serviceaufrufen/Prozessphasen zu organisieren, um ein Ergebnis zu erzielen. Dafür gibt es 2 anerkannte Methoden.

Das erste Muster oder Pattern ist der Orchestrierungstyp, der durch das sogenannte Process Manager Pattern typisiert wird.

Quelle (Diese Datei ist gemäß der Creative Commons -Lizenz Attribution-Share Alike 4.0 International lizenziert.)

Der Prozessmanager (Process Manager) verhält sich praktisch wie ein Dirigent in einem Orchester. Daher auch der Name Orchestrierung – Orchester.

Jenkins ist ein Beispiel für dieses Muster. Es fungiert als Prozessmanager – als Dirigent. Sie codieren den Prozess mit dem JenkinsFile und definieren so den Prozess. Alles, was von Jenkins über die vielen pluginbasierten Schnittstellen übergeben wird, wird als abgeschlossen an den Prozessmanager zurückgegeben, und die nächste Phase des Prozesses kann beginnen. Dies scheint in den meisten Fällen ein synchrones Verhalten zu sein. 

Das Process Manager Pattern wird in „Refactoring to Patterns (Kerievsky 2004)“ als „inherently brittle“ (von Natur aus spröde) beschrieben. Denn wenn jemand beschließen würde, den Prozessmanager neu zu starten, dann wäre alles, was er zu diesem Zeitpunkt ausführte, beschädigt. Daher ist das Design dafür bekannt, dass es bei lang andauernden Prozessen nicht besonders gut funktioniert. 

Sehen wir uns nun das zweite Sequenzierungsmuster an. Auf dem folgenden Foto ist eine Menschenmenge in einem Sportstadion bei einer La-Ola-Welle zu sehen.

Quelle (Diese Datei ist gemäß der Creative Commons -Lizenz Attribution-Share Alike 2.0 Generic lizenziert.)

Jede Person in der Menge weiß, wann sie aufstehen und die Arme hochreißen muss – niemand gibt Anweisungen. In einem großen Fußballstadion ist einfach zu viel los, als dass die Orchestrierung dies jemals bewältigen könnte. Dies ist ein Beispiel für den nächsten Sequenzierungsmustertyp, die Choreografie.

Orchestrierung ist die naheliegende Designoption, für die sich die meisten Entwicklerinnen und Entwickler zuerst entscheiden. Dagegen ist die nicht ganz so naheliegende Choreografie im Allgemeinen die stark verbesserte Umschreibung/das Design, das sehr gut in Verbindung mit Events funktioniert.

Dieses Muster ist in einer Welt der Microservices, in der möglicherweise Hunderte von Services sequenziert werden müssen, von großer Bedeutung. Aber auch in einer Welt, in der langwierige Pipeline-Aktivitäten vom Typ Stand-up, Test und Teardown stattfinden, ist der Choreografie-Stil ein weitaus robusteres und praktischeres Modell.

Tekton-Pipelines werden aus separaten Containern erstellt, die über interne Kubernetes-Events auf dem K8-API-Server sequenziert werden. Sie sind ein Beispiel für den Sequenzierungstyp „eventgesteuerte Choreografie“. Es gibt keinen einzelnen Prozessmanager, der gesperrt oder neu gestartet wird, Ressourcen verbraucht oder auf andere Weise ausfällt. Mit Tekton kann jeder Pod dann instanziiert werden, wenn er benötigt wird, um die jeweilige Phase des Pipeline-Prozesses auszuführen, für die er verantwortlich ist. Anschließend wird er heruntergefahren und gibt die verwendeten Ressourcen für andere Zwecke frei.

Das Ideal der losen Kopplung und der Kadenz durch Wiederverwendung

Tekton weist auch ein Merkmal auf, das in der Softwarearchitektur als „lose Kopplung“ bezeichnet wird. Das folgende Bild zeigt eine Kindereisenbahn:

„Toy train for wood tracks“ von Ultra-lab ist gemäß CC BY-SA 2.0 lizenziert. 

Die Lokomotive ist durch Magnete mit den Waggons verbunden, sodass das Kind die Lok alleine oder mit einem oder mehreren Waggons verwenden kann. 

Das Kind kann auch die Reihenfolge der Waggons ändern: Der hellblaue und der gelbe Waggon können beispielsweise auf Wunsch getauscht werden. Hätte das Kind ein zweites, ähnliches Eisenbahnset, könnten alle Waggons eines Sets zu dem anderen hinzugefügt werden, um einen „Superzug“ zu bilden.

Dieses Beispiel zeigt, warum die „lose Kopplung“ die optimale Architektur für das Softwaredesign ist. Dabei wird die Wiederverwendung gefördert, was wiederum ein wichtiger Bestandteil des Tekton-Ethos ist. Die erstellten Komponenten können sehr einfach zwischen Projekten geteilt werden.

Wenn wir schon beim Thema Kopplung sind, sollten wir uns auch mit dem Gegenteil der losen Kopplung beschäftigen, nämlich mit der engen Kopplung. Betrachten wir nun ein weiteres Kinderspielzeug:

„09506_Pull-Along Caterpillar“ von PINTOY^® ist gemäß CC BY-SA 2.0 lizenziert. 

Die Raupe besteht auch aus mehreren Abschnitten, die jedoch fest miteinander verbunden sind, d. h. die Reihenfolge kann nicht geändert werden. Sie können nicht weniger Segmente verwenden oder mehr Segmente hinzufügen, um eine „Superraupe“ zu erhalten. Wenn das Kind nur 3 Segmente an seiner Raupe haben möchte, muss es seine Eltern davon überzeugen, eine andere Raupe zu kaufen.

Dieses Beispiel zeigt, dass eine enge Kopplung die Wiederverwendung nicht fördert, sondern tatsächlich die Duplizierung erzwingt.

Ja, ich stimme zu, dass Jenkins-Pipelines lose gekoppelt werden können und Code zwischen Projekten geteilt werden kann. Das ist jedoch keine Selbstverständlichkeit, sondern hängt weitgehend davon ab, wie die Pipelines konzipiert wurden. 

Die Alternative wäre, eine Jenkins-Pipeline für alle Projekte zu verwenden. Dadurch wären Ihre Möglichkeiten jedoch sehr eingeschränkt, und Sie würden sehr schnell auf ein Projekt stoßen, dessen Anforderungen vom Standardansatz abweichen. Das heißt, dass die Integrität des Designs der einzelnen Pipeline-Designs verletzt wird. 

Tekton ist von Natur aus deklarativ, und seine Pipelines ähneln sehr stark dem Beispiel mit der Holzeisenbahn. Oberflächlich betrachtet können Sie sich das allgemeine Objekt „Pipeline“ von Tekton als die Lokomotive vorstellen. Die Pipeline enthält eine Reihe von Aufgaben, die Sie sich als die Waggons vorstellen können. Verschiedene Pipelines können die gleichen Aufgaben enthalten, die nur neu parametrisiert und wiederverwendet werden. Lose gekoppelte, parametrisierbare Aufgaben werden also zu Pipelines verkettet. Tekton fördert stark die lose Kopplung. Daher ergibt sich direkt die Möglichkeit zur Wiederverwendung. Das heißt, die Arbeit aus einem Projekt kann übernommen, übertragen und an anderer Stelle verwendet werden.

Tekton umfasst außerdem nur zusätzliche Kubernetes-Objektdefinitionen, die sich problemlos in einen Everything as Code-Ansatz und GitOps integrieren lassen. Der Pipeline-Code kann ganz einfach zusammen mit den anderen Cluster/Namespace-Konfigurationen auf den Cluster angewendet werden. 

Warum ist das alles so wichtig?

Es ist wichtig, weil die Vorstellung von formalen Entwicklungs-, Test- und UAT-Umgebungen größtenteils ein veraltetes Konzept ist. Diese festen Umgebungen stammen aus der Zeit, als man physische Server kaufen und ihre Verwendung festlegen musste. 

So wurde es früher gemacht. In der Welt von OpenShift und „Everything as Code“, „Pets vs. Cattle“ usw. gibt es keinen Grund, warum diese Umgebungen nicht dynamisch mithilfe von Pipelines instanziiert und anschließend Tests ausgeführt werden können. Anschließend können sie ggf. wieder komplett abgebaut werden, um Platz für weitere Tests usw. zu schaffen. 

Dies ist bei den meisten Unternehmen definitiv noch nicht der Fall. Einer der Gründe dafür ist vielleicht, dass die bisher verfügbaren Tools nicht besonders gut geeignet waren.

Fazit

Wir sind immer noch dabei, die Rückstände bezüglich der Möglichkeiten aufzuholen, die Technologien wie OpenShift uns bieten und die in der Vergangenheit einfach nicht möglich waren. 

Angesichts all dieser Compute-Ressourcen, die zumindest abends häufig ungenutzt bleiben, gibt es unzählige Möglichkeiten, Tests zu automatisieren und so bessere Software bereitzustellen. Ich habe mich schon lange mit solchen Ideen beschäftigt, hatte aber nie das Gefühl, dass Jenkins das richtige Tool für diese Art von Arbeit ist. Als ich Tekton zum ersten Mal aufgeschlossen begegnete, wurde mir schnell klar, dass es perfekt passt. 

Tekton lässt sich von Grund auf in die Kubernetes-API und das Sicherheitsmodell integrieren und fördert die lose Kopplung/Wiederverwendung. Es ist eventgesteuert und arbeitet nach dem Choreografiemodell. Daher eignet es sich gut für die Steuerung langwieriger Testprozesse. Bei den Pipeline-Artefakten handelt es sich lediglich um zusätzliche Kubernetes-Ressourcen (Pod-Definitionen, Servicekonten, Secrets usw.), die sich für die Verwendung mit einem Everything as Code-Ansatz eignen und an den Rest des k8-Ökosystems angepasst werden können.

Anwendungsteams können jeweils eigene Pipeline-Codes schreiben, die sich, wenn sie nicht ausgeführt werden, auf ein Minimum reduzieren, sodass die Vorteile von „verteiltem Jenkins“ ohne die im Leerlauf befindlichen Lasten genutzt werden können. Apache Maven wurde so schnell erfolgreich, weil es ein Game Changer war. Es führte eine reglementierte Vorgehensweise beim Layout von Java-Projekten ein, wodurch Entwicklungsteams die Build-Konfiguration zwischen Projekten problemlos herausfinden konnten. Tekton macht das Gleiche mit Pipelines und macht die Wiederverwendung von Aufgaben einfach und offensichtlich.

Cruise Control war das erste CI-Tool in den frühen 2000er Jahren. Aus eigener Erfahrung war es schwer zu bedienen. Damals fühlte sich Jenkins wie eine radikale Verbesserung gegenüber den Vorgängern an. In der Welt von OpenShift/k8s fühlt sich Tekton wie der nächste Schritt in der Pipeline-Technologie an.

Mehr erfahren

• Cloudnative CI/CD in Red Hat OpenShift