Tekton Pipelines

Geschreven door Sander Nijhof op

Tekton Pipelines is een component uit Tekton, een cloud-native oplossing voor het bouwen van CI/CD systemen. Tekton bestaat uit verschillende bouwblokken en componenten waarmee het bouwen van pipelines makkelijker en sneller wordt. In principe kan Tekton op elk Kubernetes cluster geïnstalleerd worden.

OpenShift Pipelines

Tijdens het gebruik van OpenShift Pipelines in OpenShift ben ik in aanraking gekomen met Tekton (Pipelines). OpenShift is een container platform en kan gezien worden als een laag bovenop Kubernetes. OpenShift Pipelines is een van de componenten in OpenShift. In versie 3 van OpenShift was de implementatie van OpenShift Pipelines Jenkins en sinds versie 4 is dit Tekton Pipelines.

Componenten

Tekton bestaat uit verschillende componenten, met deze componenten wordt het makkelijker om een Tekton Pipeline te configureren. Tekton bestaat uit de volgende componenten:

  • Tekton Pipelines: Tekton Pipelines bestaan uit de volgende componenten: Tasks, TaskRun, Pipeline, PipelineRun en een Workspace.
  • Tekton Triggers: Met behulp van Tekton Triggers kan een pipeline uitgevoerd worden op basis van events.
  • Tekton Dashboard: Webbased grafische interface voor Tekton Pipelines.
  • Tekton Catalog: Repository waarin Tekton bouwblokken gedefinieerd staan, deze bouwblokken worden door een groot deel onderhouden door de community.
  • Tekton Hub: Webbased grafische interface voor de Tekton Catalog. De online catalogus is hier te vinden.
  • Tekton Operator: De Tekton Operator is een Kubernetes extensie die onder andere gebruikt kan worden voor het onderhouden van Tekton Pipelines componenten.

Tekton Pipelines

Zoals hierboven beschreven bestaat Tekton Pipelines uit verschillende componenten, elk component heeft een eigen verantwoordelijkheid. Tekton Pipelines

Task

Een Task is eigenlijk het begin van een pipeline, zonder een Task kan je geen pipeline bouwen. In een Task definieer je een of meerdere stappen die uitgevoerd moeten worden. Een Task kan bijvoorbeeld het bouwen van je applicatie zijn of het uitvoeren van de testen. Elke Task draait in een eigen container. Een eenvoudige Task kan er bijvoorbeeld zo uitzien:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello-world
spec:
  steps:
    - name: hello-world
      image: ubuntu
      script: |
        #!/bin/bash
        echo "Hello world!"

In bovenstaand voorbeeld zie je dat hiervoor het image "ubuntu" wordt gebruikt. Vervolgens wordt er een "Hello world" geprint. Verder kan een Task ook nog voorzien worden van parameters zodat deze hergebruikt kan worden. Een voorbeeld hiervan is een parameter waarin de C# projectfile gespecifeerd wordt, de parameter kan dan gebruikt worden in het script.

TaskRun

In een TaskRun wordt een Task uitgevoerd en wordt de container gestart. Indien er in de Task parameters gedefineerd staan worden die ingevuld in de TaskRun. Een TaskRun kan door de Pipeline uitgevoerd maar kan ook onafhankelijk van een pipeline uitgevoerd worden.

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: hello-world-run
spec:
  taskRef:
    name: hello-world

Bovenstaand voorbeeld start de "hello-world" Task die we hierboven beschreven hebben.

Pipeline

In een Pipeline worden één of meerdere Tasks gedefinieerd. Afhankelijk van de pipeline configuratie kan een Task achter een andere Task draaien of parallel aan een andere Task. Het parallel uitvoeren van verschillende Tasks kan ervoor zorgen dat de pipeline sneller klaar is. Daarnaast kunnen er ook condities worden beschreven, in bepaalde situaties wil je dat een bepaalde Task wel of niet wordt uitgevoerd.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: hello-world-pipeline
spec:
  tasks:
    - name: hello-world
      taskRef:
        name: hello-world
  finally:
    - name: hello-world
      taskRef:
        name: hello-world

Het voorbeeld hierboven is een voorbeeld van een pipeline. In het voorbeeld wordt de "hello-world" Task uitgevoerd. Verder is er ook een "finally" te zien, de Tasks die beschreven staan in de finally worden uitgevoerd op het moment dat de pipeline succesvol afgelopen of gefaald is. Ook kunnen hier condities per Task worden gespecificeerd. In de finally zou je bijvoorbeeld onderdelen kunnen opruimen.

PipelineRun

Net zoals de Task een TaskRun heeft heeft de Pipeline een PipelineRun. In de PipelineRun wordt een pipeline gestart met opgegeven parameters, deze parameters worden weer gebruikt in een TaskRun zodat ze in een Task beschikbaar zijn. In onderstaand voorbeeld wordt de Pipeline gestart met de naam "hello-world-pipeline". Het "generateName" attribuut zorgt ervoor dat er een unieke naam gegenereerd wordt voor de PipelineRun.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: hello-world-pipeline-
spec:
  pipelineRef:
    name: hello-world-pipeline

Workspace

Op het moment dat een Task eindigt wordt de daarbij horende container afgesloten en ben je alle (niet opgeslagen) gegevens in de container kwijt. Dit is vervelend als je in Task A een git pull actie doet en in Task B het resultaat van die actie wil gebruiken en de gegevens er niet meer zijn.

Het gebruik van een workspace is hiervoor de oplossing, een Workspace is een volume dat gebruikt kan worden in verschillende Tasks. De Workspace wordt opgegeven in de PipelineRun en in de Task. De workspace wordt gemount onder /workspace in de container van de bijhorende Task.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: print-workspace
spec:
  workspaces:
    - name: source
  steps:
    - name: print-workspace
      image: ubuntu
      script: |
        #!/bin/bash
        ls -R /workspace     

apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      generateName: print-workspace-pipeline-
    spec:
      pipelineRef:
        name: print-workspace
      workspaces:
        - name: pipeline-workspace
          volumeClaimTemplate:
            spec:
              accessModes:
                - ReadWriteOnce
              resources:
                requests:
                  storage: 1Gi

In bovenstaand voorbeeld wordt er een Task en een PipelineRun gedefinieerd. In de Task wordt een Workspace gemount en in PipelineRun wordt de Workspace beschreven. De Workspace heeft in dit voorbeeld een grootte van 1Gi. Op het moment dat dit voorbeeld uitgevoerd zou worden wordt er een volume aangemaakt met een grootte van 1Gi en bij het beëindigen van de pipeline wordt dit volume weer opgeruimd.

Mijn ervaringen

Tekton Pipelines is naar mijn mening een mooie oplossing voor het creëren van CI/CD systemen, zeker met de reeds bestaande Tasks die te vinden zijn in de Tekton catalogus is een eenvoudige pipeline snel opgezet. Voorbeelden hiervan zijn Tasks voor het bouwen van je applicatie, controleren van de kwaliteit (SonarQube) of het bouwen van een DockerImage (Buildah) in een Pipeline.

Echter op het moment dat je wat uitgebreidere functionaliteiten wil gebruiken moet je al snel je eigen Task schrijven en groeien de YAML files erg snel. Indien er geen geschikt Docker image beschikbaar is moet je een eigen Docker image bouwen zodat je Task uitgevoerd kan worden. Een Pipeline specificatie (YAML) is al snel 1000 regels door het gebruik van verschillende parameters, condities en het gebruik van meerdere Tasks.

Verder moet Tekton ook beheerd worden, denk hierbij aan het installeren van updates en ervoor zorgen dat alles up en running blijft. De integratie in OpenShift is goed, het webbased dashboard biedt onder andere functionaliteit om pipelines te starten, stoppen en aan te passen. Voor een demo heb ik Tekton ook geïnstalleerd op Azure Kubernetes, dit gaat ook niet helemaal vanzelf en het dashboard is ook een stuk beperkter dan het dashboard wat te vinden is in OpenShift.

Persoonlijk denk ik dat OpenShift en Tekton Pipelines in combinatie met een beheerteam een sterke combinatie is. Ik zou Tekton niet zo snel als losstaand product gaan gebruiken en in plaats daarvan kiezen voor bijvoorbeeld Azure DevOps of GitHub Actions.

Sander NijhofSander is een .NET expert en houdt zich graag bezig met nieuwe en moderne technologie. Op dit moment werkt hij aan verschillende APIs bij het Rijksinstituut voor Volksgezondheid en Milieu (RIVM).
← Terug
XPRTZ