BuildConfig / S2I / ImageStream · Stand 2026-07-07

04 Builds, Source-to-Image und ImageStreams

BuildConfig beschreibt, wie aus Source Code ein Image entsteht. S2I injiziert Source Code in ein Builder Image. ImageStreams verwalten Tags und können Deployments triggern.

Fachliche Erklärung

OpenShift kann Images innerhalb des Clusters bauen. Das ist praktisch für Developer Experience, aber in vielen Enterprises werden Images heute auch außerhalb über Tekton, Jenkins, GitHub Actions oder GitLab CI gebaut.

ImageStreams sind eine OpenShift-Abstraktion über Image-Tags. Sie helfen bei internen Promotion-Flows und ImageChange-Triggern.

S2I Denkmodell

Builder Image enthält Laufzeit, Build-Tools und S2I-Skripte.

Source Code kommt aus Git oder Binary Build.

assemble baut Artefakte, run startet die Anwendung, save-artifacts beschleunigt Folge-Builds.

Das Ergebnis landet als neues Image in Registry oder ImageStream.

Enterprise-Entscheidung

Für einfache interne Apps ist S2I schnell und bequem.

Für regulierte Umgebungen sind externe Build-Pipelines mit SBOM, Signaturen, Scans und Promotion oft besser kontrollierbar.

Wichtig ist nicht die Tool-Frage, sondern Nachvollziehbarkeit: Wer hat welches Image aus welchem Commit mit welchen Dependencies gebaut?

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: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: order-api-s2i
spec:
  source:
    type: Git
    git:
      uri: https://git.example.com/shop/order-api.git
    contextDir: .
  strategy:
    type: Source
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: ubi8-openjdk-21:latest
      env:
        - name: MAVEN_ARGS_APPEND
          value: "-DskipTests=false"
  output:
    to:
      kind: ImageStreamTag
      name: order-api:1.0.0
  triggers:
    - type: ConfigChange
    - type: GitHub
      github:
        secretReference:
          name: github-webhook-secret

BASH

oc new-build --name order-api ubi8-openjdk-21~https://git.example.com/shop/order-api.git
oc start-build order-api-s2i --follow
oc get builds
oc get imagestreamtags

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

Vergleiche S2I, Dockerfile/Buildah und Tekton-Build. Entscheide für jede Variante: Geschwindigkeit, Governance, Reproduzierbarkeit, Auditierbarkeit.

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.