Tekton

Im Rahmen der /mid Week habe ich mich vertieft mit dem Cloud Native CI/CD Tool Tekton auseinandergesetzt. In diesem Blogpost möchte ich einen groben Überblick zu Tekton, den zugrundeliegenden Ideen und seinem Ökosystem geben.

Tekton

Tekton ist eine für Container optimierte Continuous Integration and Delivery Plattform und erlaubt es, mittels Custom Resource Definitions die Pipelines als Code abzubilden und als integralen Bestandteil der Softwarekomponenten zu versionieren und zu bündeln.

Das Projekt ist unter der neuen Continuous Delivery Foundation (CDF) angesiedelt und verfolgt das Ziel, einheitliche Spezifikationen für CI/CD Pipelines über die Hersteller-neutrale CDF bereitzustellen.

Tekton existiert seit gut einem Jahr und wurde von Knative als eigenständiges Projekt abgespaltet. Das Projekt wurde von Google lanciert und mittlerweile beteiligen sich verschiedene grössere Players wie Red Hat, IBM und CloudBees aktiv daran. Per Februar 2020 haben rund 120 Contributors mitgewirkt, wobei ca. 20 davon wirklich aktive Committer sind.

Grundsätze von Tekton

Cloud Native

Container bilden die Building-Blocks einer Pipeline. Die Blocks werden als übliche Workloads auf einer Container-Plattform ausgeführt und benötigen keine dedizierte CI/CD Infrastruktur.

Pipeline as Code

Die Pipelines werden komplett als Custom Resource Definitions (CRDs) als yaml/json unter Versionskontrolle abgelegt und ist ein integraler Bestandteil des Deliverables.

Wiederverwendbarkeit

Es wird eine hohe Wiederverwendbarkeit von Pipelines und Tasks ermöglicht, da diese keine umgebungsspezifischen Parameter enthalten. Erst bei Ausführung einer Pipeline oder eines Tasks werden diese mit den umgebungsspezifischen Werten parametriert.

Portabilität

Pipelines sind portabel und können auf verschiedenen Umgebungen und Kubernetes-basierten Container-Plattformen wiederverwendet werden.

Deklarativ

Die Pipelines und deren Building-Blocks werden deklarativ als CRDs definiert. Dadurch sind die Pipelines first-class citizens der Container Plattform und können von einem erweiterten Featureset der Plattform profitieren (bspw. Autorisierung via Kubernetes RBAC Mechanismen).

Installation

Tekton kann auf jeder Kubernetes-basierten Plattform installiert werden. Unter OpenShift 4.2 gestaltet sich die Installation von Tekton straightforward. Via OpenShift Pipelines Operator wird Tekton in den gewünschten Namespace installiert. Einerseits werden die Controllers in Form von Deployments installiert sowie die CustomResourceDefinitions, welche die K8s API um die Tekton Spezifikas erweitert.

Tekton wird clusterwide installiert, was bedeutet, dass alle Pipelines durch dieselbe Tekton Installation gemanaged und ausgeführt werden. Für die Installation und Upgrades werden Cluster-Admin Rechte benötigt. Die Ressourcen CustomResourceDefinition, ClusterRole und ClusterRoleBinding. Die Pipelines können die Entwickler autonom in eigenen Namespaces verwalten, ohne dass dafür erhöhte Privilegien auf Cluster-Ebene nötig sind.

Funktionsweise

Tekton läuft serverless, was einem die Verwaltung eines zentralen Build-Servers erspart. Dafür verlagert sich gewisse Komplexität in die Pipelines, da das Publizieren und die Visualisierung von Build-Artefakten wie bspw. Testing Reports (zumindest Stand heute) noch etwas mehr Handarbeit benötigen, verglichen mit Jenkins.

Eine Pipeline besteht in Tekton aus 1..n Tasks welche jeweils aus 1..n Steps bestehen. Wird eine Pipeline ausgeführt, entsteht aus einem Task ein Pod, und aus einem Step ein Container. Die Steps werden dabei sequentiell ausgeführt. Mit Conditions können Tasks abhängig von definierten Bedingungen ausgeführt werden oder eben nicht.

Figure 1. Statische Definition einer Pipeline
Figure 2. Runtime view einer Pipeline mit dem Mapping auf Pods und Containers. Diese CRDs werden pro Ausführung der Pipeline erzeugt.

Der State zwischen den verschiedenen Steps kann als ephemeral Volume vom Typ emptyDir geshared werden. Die Steps werden sequentiell als Container innerhalb desselben Pod ausgeführt. Damit der State zwischen verschiedenen Tasks geshared werden kann, muss auf PersistentVolumes oder auf Buckets der Cloud Provider (S3, GCP) zurückgegriffen werden.

Tasks können auch standalone gestartet werden. Dies kann gerade für Testing-Zwecke sehr nützlich sein.

Der Entwickler definiert seine Pipeline, instanziiert diese als PipelineRun, woraufhin der Pipeline Controller von Tekton die Pods entsprechend erzeugt. Den Status aktualisiert der Controller in den jeweiligen PipelineRun und TaskRun CRDs.

Für Code Samples und Details empfehle ich das offizielle Tutorial sowie die Dokumentation.

Custom Resources von Tekton

Tekton unterscheidet grundsätzlich zwischen zwei verschiedenen Typen von CRDs. Die Ressourcen, welche zur Beschreibung einer Pipeline dienen und die Ressourcen, welche die Runtime einer Pipeline oder eines Tasks abbilden:

 

Table 1. CRDs zur Definition von Pipelines
Table 2. CRDs zur runtime Repräsentation der Pipelines

Weitere Komponenten von Tekton

Tekton Triggers

Automatisches Triggering von Pipelines ist in Tekton core nicht enthalten. Dafür wird die Komponente Tekton Triggers benötigt, die auf GitHub als eigenständiges Projekt geführt wird. Die Komponente kann auf Events verschiedener Arten reagieren und daraufhin eine CRD erstellen. Im Fall von Tekton werden PipelineRuns oder TaskRuns erstellt, um eine Pipeline oder einen Task zu starten.

CLI Tool tkn

Tekton bringt das in Golang implementierte CLI Tool tkn mit, welches den Zugriff auf die CRDs abstrahiert, und die Steuerung der Pipelines vereinfacht. tkn kann auch als Plugin für die kubectl und oc Clients installiert werden.

Btw. für Visual Studio Code gibt es eine nette Integration des tkn CLI Tools: https://github.com/redhat-developer/vscode-tekton

Catalog

Der Tekton Catalog ist ein zentrales Repository, welches zum Sharen von Tasks und Pipelines innerhalb der Community dient.

Dashboard

Das Dashboard bringt ein UI mit, welches die Konfigurationen der Pipelines und deren Executions visualisiert. Über das Dashboard können auch Pipelines gestartet werden. Aktuell ist die Usability jedoch noch etwas eingeschränkt, da sich das UI stark an der Struktur der zugrundeliegenden CRDs orientiert. Das Dashboard ist erweiterbar gebaut und lässt sich mittels Extensions durch weitere Features erweitern. Aktuell existiert erst eine experimentelle Extension.

Figure 3. Übersicht der Ausführungen einer Pipeline
Figure 4. Starten einer Pipeline mit Parametrierung der Resourcen
Figure 5. Definition eines Tasks

Integration in Open Shift 4

In der aktuellen OpenShift Version 4.3 ist Tekton unter dem Namen OpenShift Pipelines als Tech Preview bereits enthalten. Sobald in einer der neuen 4.x Versionen Tekton als GA integriert ist, kann es eine Alternative zu Jenkins bieten. Jedoch wird es noch andauern bis Tekton ein solch umfangreiches Featureset anbieten kann, wie es Jenkins heute verfügt. Ich gehe auch nicht davon aus, dass Tekton auf OpenShift Jenkins mittelfristig ersetzen wird.

Eine einfache Integration in die OpenShift Webconsole existiert bereits. Folgend wenige Screenshots:

Figure 6. Übersicht der Pipelines eines Projektes
Figure 7. Details eines konkreten PipelineRuns
Figure 8. Log output der Tasks und Steps einer Pipeline

Ausblick

Tekton ist noch ein relativ junges Projekt, was sich bei der Verbreitung zeigt. Best Practices zu alltäglichen Problemen sind noch kaum auffindbar, die Anzahl von vordefinierten Tasks sind überschaubar. Aktuell existieren vor allem Pipelines von simplen „Happy Path“ Beispielen. Wenn es ans Eingemachte geht und eine etwas umfangreichere Pipeline mit Edge-Cases umzusetzen gilt, muss man verglichen mit etablierten CI/CD Systemen mit erhöhtem Aufwand rechnen.

Die Community wächst jedoch stetig und auch der Pace der Entwicklung stimmt positiv, so dass Tekton mittelfristig eine sehr interessante Cloud Native CI/CD Technologie bieten wird.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.