Ein Deploy ist nicht fertig, wenn der Container startet
Es gibt eine bestimmte Klasse von Deployment-Bugs, die sich nachträglich fast unmöglich debuggen lässt: Der Deploy meldet Erfolg, der Container ist gesund, und trotzdem liefern Anfragen für eine Weile 502. Bis jemand hinschaut, ist alles wieder in Ordnung.
Die Ursache ist meist die Lücke zwischen einem Container, der bereit ist und deiner App, die an ihrer echten URL tatsächlich erreichbar ist.
Zwei verschiedene Fragen
“Ist der Container oben?” ist eine nützliche Frage, und Railyard stellt sie, bevor eine neue Version Traffic annehmen darf. Aber es ist nicht die Frage, die deine Nutzer stellen. Sie erreichen deine Anwendung über ihre echte Domain, über HTTPS, und dieser Pfad hat nach einem Release sein eigenes Nachziehen.
Deshalb prüft ein Railyard-Deploy beides: Die neue Version muss zuerst selbst antworten, und dann muss sie tatsächlich so erreichbar sein, wie ein Besucher sie erreichen würde, bevor der Deploy als fertig markiert wird.
Was passiert, wenn das nicht so ist
Wenn die neue Version nie gesund wird, bewegt sich nichts: Die alte Version bedient weiterhin Traffic, der neue Container wird entfernt, und der Deploy wird mit der Ursache als fehlgeschlagen markiert, einschließlich der eigenen Log-Zeilen der neuen Version, damit du siehst, warum sie nicht hochkam.
Wenn die neue Version gesund ist, aber nie innerhalb einiger Minuten an der echten URL erreichbar wird, macht Railyard von selbst ein Rollback: Die vorherige Version wird erneut gestartet, und der Deploy wird mit der Ursache als fehlgeschlagen markiert, statt eine App halb umgeschaltet zurückzulassen.
Der Lohn
Worum es bei alldem geht, ist nicht der Deploy selbst. Ein Deploy, der abschließt, bedeutet, dass die URL funktioniert, und ein Fehler in deinen Logs danach bedeutet, dass tatsächlich etwas mit deiner Anwendung nicht stimmt, nicht ein Überbleibsel vom letzten Release. Das ist es, was Zero-Downtime-Deploys zu etwas macht, dem man vertrauen kann, statt es nur zu hoffen.