Einmal bauen, per Digest befördern: eine Delivery-Pipeline mit Rollback
Ein Referenzweg für die Auslieferung, bei dem das in Staging getestete Artefakt genau das in Produktion ist und ein Rollback das erneute Deployment des vorherigen Digests.
Die Beispiele sind generisch und dienen der Veranschaulichung. Sie stammen aus keiner Kundenumgebung: Passen Sie Schwellenwerte und Einstellungen an Ihr eigenes System an.
Das Problem mit Neu-Builds pro Umgebung
Pipelines, die die Anwendung für jede Umgebung neu bauen, testen ein Artefakt und liefern ein anderes aus. Abhängigkeiten werden anders aufgelöst, ein Basis-Image ändert sich, ein Build-Flag weicht ab — und die Version in Produktion wurde nirgends getestet. Bauen Sie einmal, geben Sie dem Artefakt eine unveränderliche Identität und befördern Sie diese Identität.
Referenzweg
Ein generischer Weg vom Commit bis in die Produktion. Jede Stufe reicht dasselbe Artefakt weiter oder stoppt es.
- 01CommitPull Request mit Review und Pflichtprüfungen.
- 02BuildEin Build pro Commit; das Image wird gepusht und sein Digest festgehalten.
- 03PrüfungTests, Abhängigkeits- und Image-Scans, Signatur.
- 04StagingDer Digest wird deployt; Smoke- und Integrationstests laufen.
- 05ProduktionDerselbe Digest, schrittweise ausgerollt.
- 06BeobachtungError Budget und Alerts entscheiden: weiter oder Rollback.
Digests statt Tags
Tags wie latest oder v2 sind veränderliche Etiketten; ein Digest (sha256:…) ist der Hash des Image-Inhalts. Deployment-Manifeste sollten den Digest referenzieren, und die Pipeline befördert eine Umgebung, indem sie genau diesen einen Wert ändert — idealerweise als Commit im Deployment-Repository, damit jedes Release eine geprüfte, umkehrbare Änderung ist.
# build once and record the digest
docker buildx build --push --metadata-file meta.json \
-t registry.example.com/api:"$GIT_SHA" .
DIGEST=$(jq -r '."containerimage.digest"' meta.json)
# promote: every environment receives the same digest
kustomize edit set image api=registry.example.com/api@"$DIGEST"Datenbankänderungen: erweitern, dann zurückbauen
Ein Code-Rollback ist nur einfach, wenn das Schema noch zur vorherigen Version passt. Teilen Sie inkompatible Migrationen in Schritte, die jeweils mit dem laufenden Code kompatibel sind: neue Spalte oder Tabelle hinzufügen, Code deployen, der in beide schreibt, Daten nachfüllen, Lesezugriffe umstellen und erst in einem späteren Release die alte Struktur entfernen.
Schrittweise Auslieferung und Rollback
- Rollen Sie zuerst auf einen Teil des Traffics oder der Replikate aus und vergleichen Sie Fehlerrate und Latenz mit der aktuellen Version.
- Koppeln Sie die Entscheidung an das SLO: Eine hohe Burn Rate während des Rollouts stoppt die Beförderung automatisch.
- Ein Rollback ist das erneute Deployment des vorherigen Digests — derselbe, bereits getestete Weg —, kein unter Druck geschriebener Hotfix.
- Halten Sie Konfiguration und Secrets aus dem Image heraus, damit dasselbe Artefakt in jeder Umgebung läuft.