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.
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:
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.
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:
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.