Tekton Pipelines in OpenShift

Voraussetzung: oc login als cluster-admin für Schritt 2 (Operator-Installation), danach reicht der Zugang zum Namespace library. Baut auf operator-installieren-olm.html auf – dort steht das allgemeine OLM-Verfahren.

1 Wer baut, verbraucht CPU

Baust du im Cluster, kostet jeder Build CPU und RAM, die den Diensten fehlen.

Modell	was läuft	Last auf der Steuerungsebene
Jenkins im Cluster	ein Master-Pod (dauerhaft) + Agent-Pods je Build, PVC für `$JENKINS_HOME`	hoch, konkurriert mit den Diensten
Tekton (dieser Guide)	ein Pod je `TaskRun`, danach weg – kein Master, kein PVC für einen Server	nur während des Laufs
CI ausserhalb (die Bibliothek)	baut komplett extern, deployt nur über ein SA-Token	praktisch keine

Faustregel aus dem Atlas: baue dort, wo CPU billig ist, deploye dort, wo die App läuft. Tekton ist der Mittelweg – Build-Last im Cluster, aber flüchtig statt dauerhaft. Die alte OpenShift-Jenkins-Vorlage (Templates, OAuth-Login, S2I-Jenkinsfile) wird nicht mehr gepflegt, keine Neuanlage.

2 Den Pipelines-Operator installieren

Tekton kommt als OpenShift-Pipelines-Operator – Standard-Tekton darunter, plus Konsolen-Integration.

Laptop · Bash

oc get csv -A | grep -i pipelines   # schon installiert?

cat <<'EOF' | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-pipelines-operator
  namespace: openshift-operators
spec:
  channel: latest
  name: openshift-pipelines-operator-rh
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

oc get csv -n openshift-operators -w   # bis Phase Succeeded

Der Operator bringt die CRDs Task, Pipeline, TaskRun, PipelineRun mit, und den pipeline-ServiceAccount, der in jedem Namespace automatisch entsteht, sobald der erste Tekton-Lauf dort startet.

3 Einen Task schreiben und laufen lassen

Ein Task ist eine geordnete Liste von steps – jeder Step ein Container.

Laptop · Bash

cat <<'EOF' | oc apply -f -
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: demo-check
  namespace: library
spec:
  params:
    - name: nachricht
      type: string
      default: "Tekton laeuft"
  steps:
    - name: begruessen
      image: registry.access.redhat.com/ubi9/ubi-minimal:latest
      script: |
        #!/bin/sh
        echo "$(params.nachricht)"
    - name: umgebung-zeigen
      image: registry.access.redhat.com/ubi9/ubi-minimal:latest
      script: |
        #!/bin/sh
        echo "laeuft als: $(whoami 2>/dev/null || id -u)"
        cat /etc/os-release | head -3
EOF

cat <<'EOF' | oc apply -f -
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: demo-check-run-1
  namespace: library
spec:
  taskRef:
    name: demo-check
  params:
    - name: nachricht
      value: "Hallo aus dem ersten TaskRun"
EOF

tkn taskrun logs demo-check-run-1 -n library -f
# ohne tkn-CLI: oc logs -f -l tekton.dev/taskRun=demo-check-run-1 -n library --all-containers

Die zwei Steps teilen sich einen Pod, laufen aber nacheinander – im Pod stehen sie als step-begruessen und step-umgebung-zeigen. Nach dem Lauf bleibt der TaskRun als Objekt für die Historie, der Pod selbst verschwindet nach kurzer Zeit (Completion-TTL).

4 Zwei Tasks zu einer Pipeline verketten

Eine Pipeline ordnet Tasks, ein Workspace gibt ihnen geteilten Speicher – genau das Muster, das git-clone → build in der echten Build-Kette nutzt.

Laptop · Bash

cat <<'EOF' | oc apply -f -
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: demo-schreiben
  namespace: library
spec:
  workspaces:
    - name: teilen
  steps:
    - name: datei-schreiben
      image: registry.access.redhat.com/ubi9/ubi-minimal:latest
      script: |
        #!/bin/sh
        echo "erzeugt um $(date -Iseconds)" > $(workspaces.teilen.path)/marker.txt
---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: demo-lesen
  namespace: library
spec:
  workspaces:
    - name: teilen
  steps:
    - name: datei-lesen
      image: registry.access.redhat.com/ubi9/ubi-minimal:latest
      script: |
        #!/bin/sh
        echo "gefunden:"
        cat $(workspaces.teilen.path)/marker.txt
EOF

cat <<'EOF' | oc apply -f -
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: demo-pipeline
  namespace: library
spec:
  workspaces:
    - name: geteilt
  tasks:
    - name: schreiben
      taskRef: { name: demo-schreiben }
      workspaces:
        - { name: teilen, workspace: geteilt }
    - name: lesen
      taskRef: { name: demo-lesen }
      runAfter: ["schreiben"]
      workspaces:
        - { name: teilen, workspace: geteilt }
EOF

runAfter erzwingt die Reihenfolge – ohne die Zeile würden schreiben und lesen parallel starten, und lesen fände die Datei noch nicht.

5 Den PipelineRun live beobachten

Ein PipelineRun ist ein Lauf – er erzeugt je Task einen TaskRun, je TaskRun einen Pod.

Laptop · Bash

cat <<'EOF' | oc apply -f -
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: demo-pipeline-run-1
  namespace: library
spec:
  pipelineRef:
    name: demo-pipeline
  workspaces:
    - name: geteilt
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources: { requests: { storage: 1Gi } }
EOF

tkn pipelinerun logs demo-pipeline-run-1 -n library -f
oc get taskrun -n library -l tekton.dev/pipelineRun=demo-pipeline-run-1
oc get pipelinerun demo-pipeline-run-1 -n library -o jsonpath='{.status.conditions[0].status} {.status.conditions[0].reason}{"\n"}'

Das volumeClaimTemplate im Workspace erzeugt ein frisches PVC nur für diesen Lauf – nach dem Löschen des PipelineRuns bleibt es stehen (Aufräumen unten). In der Konsole zeigt der Pipelines-Tab den DAG live, grün sobald ein Task fertig ist.

MerkeNach dem Lauf sind die Pods weg – kein Server-Prozess wie bei Jenkins. Die Objekte TaskRun und PipelineRun bleiben für die Historie, bis sie aufgeräumt werden.

6 Typische Fallen

Symptom	meist
`PipelineRun` hängt in `PipelinePending`	der `pipeline`-ServiceAccount fehlt oder das PVC im Workspace kann nicht gebunden werden
`lesen`-Task findet die Datei nicht	`runAfter` fehlt – Tasks liefen parallel, nicht nacheinander
Step schlägt mit `permission denied` fehl	SCC-Restriktion (A7) – das Skript versucht etwas, das der Pod-Security-Kontext nicht erlaubt
TaskRun bleibt ewig `Pending`	ResourceQuota im Namespace ist voll (B7) – kein Platz für einen weiteren Pod
Operator-Installation hängt	CSV in `openshift-operators` prüfen, oft ein fehlender Katalog-Sync

7 Wie das Projekt es macht

Die Bibliothek baut nicht mit Tekton – Jenkins läuft ausserhalb in einem lokalen docker-compose, pusht Images nach ghcr.io und ruft helm upgrade --install catalog ./chart -n library --atomic als system:serviceaccount:library:pipeline (build-kette-openshift.html). Der Cluster sieht dabei keine Build-Pods. Diese Anleitung zeigt das Alternativmuster, das der Atlas als nächsten Schritt nennt: dieselben Stufen git-clone → mvn test → buildah → helm upgrade als Tekton-Pipeline statt als Jenkinsfile – mit git-clone als wiederverwendbarem ClusterTask aus dem Tekton Hub anstelle von demo-schreiben.

+ Die Kurzfassung

Taskeine geordnete Liste von Steps, jeder Step ein Container, alle teilen sich einen Pod

Pipelineordnet Tasks per runAfter, sonst laufen sie parallel

PipelineRunein Lauf, erzeugt Pods, danach ist alles wieder weg – kein Server, kein Master

Workspacegeteilter Speicher zwischen Tasks – ein PVC, emptyDir oder ein Secret