Cloud Native CI/CD mit Tekton

Ein neuer Ansatz für die Build Pipeline

Was wäre, wenn man für die Build Pipeline keinen Server mehr bräuchte? Die ganze Pipeline könnte überall ausgeführt werden, sogar auf den PCs der Entwickler.

Tekton ist ein Open Source Projekt der Continuous Delivery Foundation, dass die Build Pipeline in den Kubernetes Cluster verlagert. Die Pipeline wird über Kubernetes Resourcen deklariert. Sie besteht damit nur noch aus ein paar Dateien, die auf jedem Kubernetes Cluster deployed und ausgeführt werden können.

Warum Tekton

Tekton schreibt sich selbst Flexibilität und Wiederverwendbarkeit auf die Fahne. Einzelne Pipeline Schritte können unabhängig definiert werden. Sie lassen sich parametrisieren. Sie können in verschiedenen Pipelines wiederverwendet werden.

Ein mögliches Vorgehen: Es werden Projektübergreifend allgemeine Schritte und Pipeline Vorlagen definiert, einzelne Projekte und Teams können sich aus diesem Pool bedienen und Ressourcen an ihre Bedürfnisse anpassen.

Die Verwaltung des Build Servers fällt weg, dafür ist man aber an Kubernetes gebunden.

Tekton eignet sich, wenn man spezielle Anforderungen an die Pipeline hat, einzelne Teile wiederverwenden will und Kubernetes ohnehin die Deployment Plattform der Wahl ist.

Arbeiten mit Tekton

Die Konzepte

Tekton besteht ausschließlich aus Kubernetes Custom Resource Definitions (CRDs) und Kubernetes Controllern. Zur Installation reicht es, die Resourcen in den eigenen Kubernetes Cluster zu laden.

Es gibt 3 Typen von Resourcen, um eine Build Pipeline zu definieren:

• Steps: Ein Step führt eine einzelne Aufgabe aus, zum Beispiel das Klonen eines Git Repositories.
• Tasks: Ein Task kann einen oder mehrere Steps enthalten, die der Reihe nach ausgeführt werden.
• Pipeline: Eine Pipeline besteht aus mehreren Tasks. Diese werden parallel ausgeführt, solange keine Abhängigkeiten zwischen ihnen definiert werden.

Der Inhalt der einzelnen Steps lässt sich frei implementieren. Am Ende bewirkt jeder Step, dass ein Kubernetes Pod gestartet wird, der eine Anwendung oder ein Skript ausführt.

Die Resourcen TaskRun und PipelineRun werden verwendet, um Tasks oder Pipelines zu starten. Außerdem kann man EventListener erstellen, um Builds automatisch zu starten - zum Beispiel über einen Webhook in der Versionsverwaltung.

Der Tekton Hub

Damit man mit der Erstellung der Build Pipeline nicht von Null beginnen muss, gibt es den Tekton Hub. Hier befindet sich eine Sammlung fertiger Tekton Tasks, die für die eigene Pipeline verwendet werden können. Dazu gehören Tasks für die Kompilierung mit maven oder npm, für das Auschecken aus verschiedenen Versionsverwaltungen, für die Interaktion mit Docker Registries oder dem Kubernetes Cluster selbst und vieles mehr.

Die Tasks auf dem Hub können über Parameter angepasst werden. So lässt sich zum Beispiel ein eigenes Basisimage übergeben, dass den Sicherheitsanforderungen des eigenen Unternehmens entspricht.

Setup in der Praxis

In der Praxis helfen bei der Interaktion mit Tekton 2 weitere Tools. Zum einen das Command Line Interface tkn, zum anderen das Tekton Dashboard.

Tkn arbeitet wie kubectl mit der Kubernetes API. Es bietet spezielle Befehle, um die Arbeit mit Tekton zu vereinfachen.

Auf dem Dashboard kann man sich einen Überblick über Builds und deren Status verschaffen. Zusätzlich enthält es ein paar einfache Funktionen, wie den Restart einer Build Pipeline oder das Löschen eines alten Builds.

Die Definition der Resourcen erfolgt über YAML-Dateien. Ein einfacher Hello World Task würde z.B. so aussehen:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello-with-param
spec:
  params:
  - name: person
    description: Name of person to greet
  steps:
  - name: say-hello
    image: ubuntu
    script: |
      #!/usr/bin/env bash
      echo Hello $(params.person)

Dieser Task definiert einen Parameter. In diesem wird beim Aufruf der Name einer Person übergeben.

Danach wird ein Step definiert, der ein einfaches Bash Skript ausführt, das Hello + <Personenname> ausgibt.

Die meisten komplexeren Tasks funktionieren auch nach diesem Prinzip. Für einen Maven Build Task würde man ein Basisimage verwenden, auf dem Maven installiert ist und den Maven Befehl einfach in einem Skript ausführen.

Der TaskRun, um den Task zu starten, würde so aussehen:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: hello-with-param-run
spec:
  params:
    - name: person
      value: World
  resources: {}
  serviceAccountName: ""
  taskRef:
    name: hello-with-param
status:
  podName: ""

Die Pipeline Definition funktioniert nach dem selben Prinzip. Zu allen Resourcen gibt es ausführliche Dokumentationen mit Beispielen, an denen man sich orientieren kann. Auch die Tasks auf dem Tekton Hub sind gut dokumentiert.

Wie tauschen Tasks Daten miteinander aus?

Zum einen natürlich über Parameter. Aber wie gelingt es, dass ein Maven Build Task die Dateien aus dem Git Clone Task erhält?

Hierfür hat Tekton das Konzept der Workspaces eingeführt. Ein Workspace kann innerhalb einer Pipeline in mehreren Tasks wiederverwendet werden. Der Workspace kann ein PersistentVolume enthalten, auf das lesend und schreibend zugegriffen werden kann. Es können aber auch eine Configmap oder Secret hinterlegt werden.

Fazit

Tekton kann natürlich nur in Kombination mit Kubernetes verwendet werden. Initial muss man recht viel selbst implementieren. Wenn man nur eine einfache Standard-Pipeline benötigt, ist man mit einem anderen Tool vermutlich schneller am Ziel.

Wenn man eine flexible Lösung braucht, die Pipeline komplex wird oder wenn Bausteine der Pipeline häufig wiederverwendet werden, dann eignet sich Tekton. Dazu fällt der Aufwand für die Verwaltung eines Build Servers weg.

Tekton ist ein junges Projekt, in dem viel geschieht. Es bleibt spannend, wie es sich in Zukunft entwickelt.

Links

[1] https://tekton.dev/ - offizielle Seite von Tekton

[2] https://hub.tekton.dev/ - der Tekton Hub

[3] https://cd.foundation/ - Seite der Continuous Delivery Foundation

[4] https://github.com/tektoncd - Tekton auf github