Warum ein Deploy wirklich fehlschlägt, Ursache für Ursache
“Der Deploy ist fehlgeschlagen” ist kein einzelnes Problem – es sind mindestens ein Dutzend verschiedene, die sich jemandem, der nur kurz auf ein Dashboard blickt, zufällig gleich darstellen. Zu wissen, welches davon tatsächlich passiert ist, ist der größte Teil der Lösung, deshalb führt die Seite eines fehlgeschlagenen Deploys mit warum er fehlgeschlagen ist: die Ursache, die Lösung und die Log-Zeile, die es beweist.
Die zwei, die identisch aussehen, es aber nicht sind
Die mit Abstand häufigste Verwechslung: “dem Build ist die Zeit ausgegangen” (bei einem Limit von 60 Minuten gestoppt; der nächste Versuch nutzt bereits Gebautes weiter) gegenüber “dem Build ist der Speicher ausgegangen” (ein Build-Schritt wurde hart abgebrochen, weil er überschritten hat, was der Build-Server hat). Beide sehen aus der Ferne mit einem roten Status wie “der Build ist einfach nicht fertig geworden” aus – die Lösung für das eine ist Geduld und die Wiederverwendung teilweise erledigter Arbeit, die Lösung für das andere ist ein größerer Build-Server oder ein Deploy eines bereits gebauten Images statt überhaupt auf der Plattform zu bauen.
Die App läuft, antwortet aber irgendwie nicht
Das hier verdient einen eigenen Absatz, weil es selten aus dem eigenen Code der App offensichtlich wird: der Container läuft, aber nichts antwortet auf HTTP. Nicht abgestürzt – läuft, nach jeder Metrik gesund außer der einen, die zählt. Die eigentliche Ursache ist fast immer eine Ein-Zeilen-Lösung: Die App muss auf 0.0.0.0 lauschen, nicht auf 127.0.0.1, und auf dem Port in $PORT, nicht auf einem hartcodierten. Eine völlig korrekte App, die völlig korrekt läuft, die nur immer mit sich selbst spricht.
Ein naher Verwandter: der Befehl lief im falschen Verzeichnis – das Image enthält die App nicht dort, wo der Start-Befehl sie erwartet, meist weil ein Dockerfile, das für die lokale Entwicklung geschrieben wurde (und einen Bind-Mount erwartet), für einen echten Build benutzt wurde. Der Wechsel zu Railpack statt dem eigenen Dockerfile des Repos ist die Lösung, wenn das die tatsächliche Situation ist.
Die datenbankförmigen Fehler, auf drei verschiedene Arten
- Die Datenbank war nicht erreichbar – am verwirrendsten, wenn das während des Builds passiert, weil eine App, die während der Kompilierung von Assets oder einer Build-Zeit-Prüfung eine Verbindung zu ihrer Datenbank aufbaut, versucht, Infrastruktur zu erreichen, auf die dieser Build-Schritt nie Zugriff haben sollte.
- Dem Datenbank-Benutzer fehlt eine Berechtigung – eine Migration braucht etwas, das der Datenbank-Benutzer der App noch nicht hat. Die Lösung ist fast verdächtig einfach: einmal erneut deployen, da sich Rechte bei jedem Deploy aktualisieren.
- Der Release-Schritt ist fehlgeschlagen – meist Migrationen, einmal ausgeführt, bevor die neue Version Traffic annimmt. Die erste Zeile des tatsächlichen Fehlers wird direkt auf der Deploy-Seite angezeigt, nicht in einem vollständigen Log-Dump versteckt.
Die zwei, die eigentlich dasselbe Problem in anderer Verkleidung sind
Eine erforderliche Variable ist nicht gesetzt (die App stoppt beim Start, weil etwas, das sie braucht, leer ist) und die App braucht Zugangsdaten für einen externen Service (eine Drittanbieter-API, Cloud-Speicher, E-Mail, Zahlungen – kein Schlüssel konfiguriert) haben dieselbe Grundursache – eine fehlende Umgebungsvariable – mit unterschiedlicher Spezifität. Das eine ist “etwas fehlt”, das andere benennt, welche Kategorie von etwas.
Das Image konnte nicht gezogen werden (existiert nicht, falscher Tag, oder privat ohne Zugangsdaten) und der Image-Name ist ungültig (Zeichen, die Docker nicht akzeptiert) sind das entsprechende Paar für Image-basierte Deploys statt Build-basierte.
Warum die genaue Ursache zu benennen wichtiger ist, als es klingt
Jedes dieser Probleme erzeugt dasselbe sichtbare Symptom für jemanden, der nur kurz auf ein Dashboard blickt: einen roten Status und einen fehlgeschlagenen Deploy. Die eigentliche Lösung wird erst offensichtlich, wenn die konkrete Ursache benannt ist – “Zeit ausgegangen” und “Speicher ausgegangen” brauchen entgegengesetzte Reaktionen; eine verlässliche Deploy-Pipeline hängt weniger davon ab, nie zu scheitern, sondern mehr davon, dass ein Fehlschlag dir sofort und konkret sagt, was als Nächstes zu tun ist.
Vollständige Referenz, jede Ursache: Fehlgeschlagene Deploys beheben.