Argo CD / Tekton · Stand 2026-07-07

07 OpenShift GitOps und Pipelines

OpenShift GitOps nutzt Argo CD, um deklarative Zustände aus Git mit dem Cluster abzugleichen. OpenShift Pipelines basiert auf Tekton und bildet CI/CD als Kubernetes-Ressourcen ab.

Fachliche Erklärung

GitOps macht Git zur Quelle der Wahrheit für Cluster- und App-Konfiguration.

Pipelines bauen, testen, scannen und pushen Artefakte. GitOps synchronisiert danach die freigegebene Konfiguration in die Zielumgebung.

Zwei Repositories

App Repository: Java-Code, Tests, Dockerfile, Build-Konfiguration.

Config Repository: Umgebungskonfiguration, Helm values, Kustomize overlays, Ressourcenlimits, Routes, Secrets-Referenzen.

Diese Trennung verhindert, dass jeder Code-Commit automatisch Produktionskonfiguration verändert.

Enterprise Promotion

Dev darf automatisch synchronisieren.

Test kann automatische Syncs mit Quality Gates bekommen.

Prod sollte Merge Request, Review, Change Ticket und kontrollierte Sync-Fenster haben.

Ausführliches Enterprise-Beispiel

Das Beispiel folgt einer fiktiven Shop-Landschaft mit order-api, billing-api, payment-api, portal-ui, Batch-Export und Messaging. Der Fokus liegt auf sauberem Verständnis statt auf blindem Kopieren.

Fachlicher Ablauf

Kunde bestellt über Portal.
order-api validiert Auftrag.
billing-api erzeugt Rechnung.
payment-api prüft Zahlung.
Events informieren Lager und Reporting.

Technischer Ablauf

Route nimmt HTTPS an.
Service verteilt auf Pods.
Pods lesen ConfigMaps und Secrets.
Readiness schützt Rollout.
Monitoring misst Fehlerquote und Latenz.

Konfigurations- und Codebeispiele

YAML

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-test-push
spec:
  params:
    - name: git-url
      type: string
    - name: image
      type: string
  workspaces:
    - name: source
  tasks:
    - name: clone
      taskRef:
        name: git-clone
      params:
        - name: url
          value: $(params.git-url)
      workspaces:
        - name: output
          workspace: source
    - name: maven-test
      runAfter: [clone]
      taskRef:
        name: maven
      params:
        - name: GOALS
          value: ["test", "package"]
      workspaces:
        - name: source
          workspace: source
    - name: build-image
      runAfter: [maven-test]
      taskRef:
        name: buildah
      params:
        - name: IMAGE
          value: $(params.image)
      workspaces:
        - name: source
          workspace: source

YAML

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: shop-dev
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: https://git.example.com/shop/platform-config.git
    targetRevision: main
    path: environments/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: shop-dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

BASH

tkn pipeline start build-test-push -p git-url=https://git.example.com/shop/order-api.git -p image=registry.example.com/shop/order-api:1.0.0 -w name=source,claimName=source-pvc
oc -n openshift-gitops get applications

Typische Fehlerbilder und Diagnose

Pending Pods

Prüfe Ressourcen, Node-Selector, Taints, PVC und Quotas. Nicht sofort am Java-Code suchen.

CrashLoopBackOff

Prüfe Logs des vorherigen Containers, Config/Secrets, Port, JVM Memory und Health Endpoints.

Route erreichbar, App nicht

Prüfe Service-Selector, Endpoints, Readiness, TLS-Termination und NetworkPolicy.

Praxisaufgabe

Baue einen Promotion-Prozess: Commit erzeugt Image, Security-Scan signiert es, Config Repo erhöht Tag von 1.0.0 auf 1.0.1, Argo CD synchronisiert Dev automatisch und Prod manuell.

Merksätze

Deklarativer Zustand ist wichtiger als manuelle Serveränderung.
Security und Betrieb gehören von Anfang an zum Deployment.
Jede YAML-Datei ist Architekturentscheidung und sollte reviewbar sein.
Produktionsreife entsteht durch Messbarkeit, Rollback und klare Ownership.