Was einen Deploy wirklich zero-downtime macht

“Zero-Downtime-Deploy” wird locker genug verwendet, dass es sich lohnt, präzise zu sein, was es mechanisch tatsächlich erfordert, nicht nur, was es verspricht. Es ist kein einzelnes Feature – es sind fünf Schritte, die alle in der richtigen Reihenfolge und jedes Mal halten müssen.

Die fünf Schritte

1. Bauen oder ziehen. Mit einem Repository baut das neue Image auf einem dedizierten Build-Server, falls das Team einen hat, sonst auf dem eigenen Server der App oder einem temporären, den Railyard für den Job startet. Eine image://-Quelle überspringt das Bauen komplett und zieht einfach.
2. Release-Befehl. Falls die App einen hat, läuft er einmal gegen das neue Image, bevor irgendetwas Traffic annimmt – hier gehören Migrationen hin. Schlägt er fehl, stoppt der Deploy genau hier, und die App läuft weiter mit ihrer alten Version. Am Live-System hat sich noch nichts geändert.
3. Health-Check. Der neue Container startet neben dem bereits laufenden, nicht an dessen Stelle. Falls die App einen konfigurierten Health-Check-Pfad hat, muss der neue Container darauf innerhalb des konfigurierten Timeouts tatsächlich antworten, bevor irgendetwas anderes passiert.
4. Traffic-Switch. Erst wenn der neue Container seinen Health-Check besteht, wechselt Traffic zu ihm – alles auf einmal bei einem Standard-Deploy, oder ein Anteil nach dem anderen bei einem Canary-Deploy, beobachtet gegen die übrige Fehlerrate der App, bevor er weiter hochgefahren wird.
5. Alte Version stoppt. Der vorherige Container läuft weiter, bis der neue bestätigt ist, und wird erst dann entfernt.

Diese Reihenfolge ist der gesamte Mechanismus. Es gibt nie einen Punkt zwischen den Schritten, an dem die App null funktionierende Container hat – der alte verschwindet nicht, bevor sich der neue bereits bewiesen hat.

Was passiert, wenn etwas fehlschlägt

Das ist der Teil, der eigentlich wichtiger ist als der Happy Path: Wenn der Build, der Release-Befehl oder der Health-Check fehlschlägt, lässt Railyard die vorherige Version genau so weiterlaufen, wie sie war, und markiert den Deploy als fehlgeschlagen. Ein schlechter Deploy legt die App nicht lahm – er geht einfach nicht raus. Die Deploy-Seite benennt die genaue Ursache und verlinkt die Lösung – siehe warum ein Deploy wirklich fehlschlägt, Ursache für Ursache dafür, was jede davon bedeutet.

Ein Rollback ist derselbe Mechanismus, kein anderer

Ein Rollback ist keine Sonderfall-Notlösung – es ist ein Deploy des Commits oder Images eines früheren Releases, was bedeutet, dass es exakt denselben Bau-oder-Zieh-Schritt, Release-Befehl, Health-Check und Traffic-Switch durchläuft wie jeder andere Deploy. Das ist absichtlich so: Ein Rollback, das den Health-Check übersprungen hätte, wäre der eine Deploy-Pfad, der tatsächlich genau die Downtime verursachen könnte, die der Rest des Systems vermeiden soll.

railyard releases my-app          # list releases to roll back to
railyard rollback my-app <version> [--code-only]

--code-only stellt den Code wieder her, behält aber die heutigen Umgebungsvariablen – nützlich, wenn ein Release selbst in Ordnung war, aber seitdem eine Variable geändert wurde, die du nicht auch rückgängig machen willst.

Warum die Reihenfolge nicht überspringbar ist

Jeder dieser Schritte existiert wegen einer bestimmten Fehlerart, die er ausschließt. Überspringe den Health-Check, und eine abstürzende neue Version nimmt trotzdem Traffic an. Überspringe das Lebendhalten des alten Containers während der Prüfung, und es gibt eine Lücke, in der nichts antwortet. Führe den Release-Befehl nach dem Switch statt davor aus, und eine anstehende Migration trifft Live-Traffic mitten im Lauf. Nichts davon ist exotisches Engineering – es geht nur darum, unter Zeitdruck keine Schritte zu überspringen.

Vollständige Details, einschließlich Canary-Deploys und Deploy-Fenstern: Deploys und Rollbacks.