Grundkenntnisse in Tekton

13.01.2021Stefan Welsch
Cloud tekton CI/CD Cloud native RedHat OpenShift

Was ist Tekton?

Tekton ist eine ‘Pipeline as Code’-Continuous Integration and Delivery Platform, welche für Container optimiert wurde. Tekton wurde initial als Projekt von der CDF (Continuous Delivery Foundation) aufgenommen. Dadurch sollen Hersteller-unabhängige und einheitliche Spezifikationen für CI/CD bereitgestellt werden.

Das Projekt wurde ursprünglich von Google in die Welt gerufen. Mittlerweile haben sich aber auch andere grosse Firmen daran beteiligt (IBM, CloudBees, Red Hat). Es gibt ausserdem eine Community, welche Tag für Tag wächst und so auf eine spannende Zukunft von Tekton hoffen lässt.

Wie funktioniert Tekton?

Tekton funktioniert serverless. Das bringt den grossen Vorteil mit sich, dass man keinen zentralen Buildserver braucht. Allerdings muss einige Logik dadurch in die Pipelines verlagert werden. Die Ressourcen in Tekton sind unterteilt in Deskriptive Ressourcen und Runtime Ressourcen.

Deskriptive Ressourcen dienen, wie der Name schon sagt, zur Beschreibung der jeweiligen Ressource. Dadurch kann ein Task zum Beispiel so definiert werden, dass er wiederverwendbar ist.

Runtime Ressourcen werden dazu verwendet, um den deskriptiven Ressourcen, Informationen zur Laufzeit zur Verfügung zu stellen.

Steps, Tasks und Pipelines

In Tekton gibt es, wie auch in Jenkins, Pipelines. Diese Pipelines bestehen aus mindestens einem Task. Jeder Task hat wiederum ein oder mehrere Steps. Ein Step ist eine Operation in der Pipeline. Hier wird beispielsweise Code kompiliert oder Unit Tests ausgeführt. Jeder Step wird in einem eigenen Container ausgeführt. Dazu darf in jedem Step ein eigenes Image definiert werden. Beispielsweise braucht es zum Builden einer Maven Applikation einen Container, welcher Maven bereits installiert hat. Hierfür stellt Tekton zum Beispiel bereits ein Image zur Verfügung. gcr.io/cloud-builders/mvn

Tekton Pipeline Entities

Tekton Pipelines bestehen im Prinzip aus 5 Objekten, welche wir weiter oben teilweise bereits kennengelernt haben haben.

  • Task: Ein Task beschreibt mehrere Steps, welche im Container ausgeführt werden. Die Task Spezifikation ist ähnlich wie bei einem Kubernetes Pod. Jeder Task wird in einem eigenen Kubernetes Pod ausgeführt. Dadurch werden im Normalfall keine Daten zwischen den Tasks ausgetauscht. Man kann jedoch Daten austauschen, in dem man Outputs an den nächsten Task als Input weitergibt.

  • TaskRun: Ein TaskRun ist ein Objekt, welches einen Task triggert. Hier werden Input und Output Parameter definiert, welche zum Laufen des Tasks erforderlich sind.

  • Pipeline: Eine Pipeline besteht aus mehrere Tasks, die ausgeführt werden.

  • PipelineRun: Analog TaskRun ist ein PipelineRun ein Objekt, welches die Ausführung der Pipeline triggert.

  • PipelineResource: Eine PipelineResource definiert, welche Input- und Outputs für einen Task genutzt werden. Beispielsweise könnte man hier als Input ein Git Repository definieren und als Output eine Image Registry

Es gibt ein weiteres Objekt Run, welches sich aber zum heutigen Datum noch in der Alpha Version befindet. Wir werden hier aber mehr Informationen geben, sobald der Alpha Status verlassen wird.

Input und Output Resources

Jeder Task und jede Pipeline kann Inputs und Outputs definieren. Will man also Software aus einem VCS bauen und anschliessend in einem Artefakt-Repository deployen, so kann man als Input beispielsweise sein Git-Repository angeben und als Output sein Nexus.

Input und Output in Tekton

Nächste Schritte

Als nächstes werden wir uns Tekton in der Praxis anschauen. Hierbei wollen wir insbesondere anschauen, wie man eine Pipeline für ein Projekt aufsetzen kann und welche Hindernisse es dabei vielleicht gibt. Wir lernen Labels, WhenExpressions(vorher Conditions), Pod templates und Tekton Triggers näher kennen und schauen und das Tekton Dashboard und den Tekton Catalog an.

Stefan Welsch

Stefan Welsch – Manitu, Pionier, Stuntman, Mentor. Als Gründer von b-nova ist Stefan immer auf der Suche nach neuen und vielversprechenden Entwicklungsfeldern. Er ist durch und durch Pragmatiker und schreibt daher auch am liebsten Beiträge die sich möglichst nahe an 'real-world' Szenarien anlehnen.