Zum Inhalt springen
SP.
EN DE
Zurück zu Projekte
Referenzentwurf

Eine Plattform für verlässliche Releases

Einen fragilen Release-Prozess in einen wiederholbaren, beobachtbaren Weg vom Commit bis in die Produktion verwandeln.

  • Kubernetes
  • Terraform
  • Argo CD
  • GitHub Actions
  • Prometheus
Deployment-Ziel
< 10 min
Rollback-Ziel
< 5 min
Artefakt pro Release
1

Entwurfsziele · keine Produktionsmessungen

Das Problem

Ein Release ist schwer nachzuvollziehen, wenn sein Zustand auf CI-Jobs, Shell-Skripte und einzelne Terminals verteilt ist. Diese Referenzarchitektur beschreibt eine kleine, überprüfbare Delivery-Plattform. Die Kennzahlen oben sind Entwurfsziele, keine gemessenen Kundenergebnisse.

Das System

Einmal bauen, dasselbe unveränderliche Artefakt weiterreichen und den Cluster seinen Sollzustand aus Git abgleichen lassen. Zugangsdaten für Build und Laufzeit bleiben getrennt.

Ein Commit startet Prüfungen und Image-Build. Eine geprüfte Konfigurationsänderung wird von Argo CD auf Kubernetes angewendet. Prometheus beobachtet den Cluster.

Die Pipeline veröffentlicht ein Image. Eine geprüfte Konfigurationsänderung wählt dessen Digest aus. Argo CD setzt den Sollzustand um, Prometheus liefert das Feedback zur Bewertung des Releases.

Entscheidungen und Abwägungen

  • Terraform verwaltet die Basis. Netzwerk, Cluster und Identitäten haben einen eigenen Plan- und Review-Prozess.
  • Git verwaltet den Anwendungszustand. Änderungen bleiben prüfbar und umkehrbar. Der Abgleich verursacht eine kleine Verzögerung.
  • Gesundheitskriterien sind explizit. Readiness-Probes schützen den Traffic; die Fehlerrate der Anwendung entscheidet über den Erfolg.
  • Ein Artefakt für alle Umgebungen. Ein erneuter Build würde die Erkenntnisse aus Staging entwerten.
# Deployment-Auszug: an gemessene Anwendungsanforderungen anpassen.
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1
minReadySeconds: 15
progressDeadlineSeconds: 600

Fehler und Wiederherstellung

Den Image-Digest in Git zurücksetzen und den Controller abgleichen lassen. Automatische Promotion pausieren, wenn das Fehlerbudget schneller verbraucht wird. Datenbankmigrationen müssen in diesem Zeitraum abwärtskompatibel sein: Ein Container-Rollback macht keine inkompatible Schemaänderung rückgängig.

Was gemessen werden sollte

Zeit vom Commit bis zum gesunden Deployment, Anteil fehlgeschlagener Änderungen und Wiederherstellungszeit erfassen. Die Ziele vor der Einführung durch Ausfallübungen in Staging prüfen.

Zurück zu Projekte