Aufgabe 12 - Deployment kaputt: Fehlersuche und Rollback

Aufgabe 12 - Deployment kaputt: Fehlersuche und Rollback

Worum geht es?

Sie liefern absichtlich kaputte Versionen aus, grenzen den Fehler entlang der Kette ein und rollen zurück, solange all das noch unwichtig ist (siehe Kapitel Auslieferung mit Containern). Ein Rollback, den man zum ersten Mal unter Druck durchführt, ist kein Rollback, sondern ein Experiment zum ungünstigsten Zeitpunkt.

Was Sie dafür brauchen

• Kapitel Auslieferung mit Containern, Abschnitte Rollback und Wenn das Deployment scheitert.
• Ihr ausgeliefertes Projekt aus Aufgabe 11, mit Vorschauumgebung.
• Die vier Ausfallbeschreibungen aus Aufgabe 11, Teil C Punkt 2.

Welche Kompetenzen Sie erwerben und zeigen

• Sie grenzen ein fehlgeschlagenes Deployment anhand von Build-, Container- und Proxy-Log ein.
• Sie führen ein Rollback durch und benennen seine Grenzen im Zusammenspiel mit Datenbankmigrationen.
• Sie schreiben eine Störungsbehebung so auf, dass eine andere Person sie unter Druck nachvollziehen kann.

Pädagogische Einordnung

• Reproduktion: die vier Stationen der Fehlersuche benennen und die Logs aufrufen (Teil A).
• Reorganisation und Transfer: bekannte Fehlerbilder selbst erzeugen und den Symptomen zuordnen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: ein Rollback durchführen und seine Grenzen beurteilen (Teil C).

Auf der Vorschau, nicht auf der Produktion

Alle absichtlichen Störungen dieser Übung laufen in der Vorschauumgebung aus Aufgabe 11. Nur das Rollback in Teil C wird einmal auch in der Produktion geübt, und zwar zu einem Zeitpunkt, an dem niemand die Anwendung braucht.

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Die vier Stationen

1. Rufen Sie für Ihr laufendes Projekt nacheinander vier Ausgaben auf und notieren Sie zu jeder, wo Sie sie in Dokploy finden: Build-Log, Container-Log, Proxy-Log und den Zustand des Healthchecks.

2. Schreiben Sie zu jeder der vier Stationen in zwei Sätzen auf, welche Frage sie beantwortet.

3. Erklären Sie in drei bis vier Sätzen, warum die Fehlersuche dem Weg der Anfrage rückwärts folgt. Gehen Sie davon aus, dass Sie mit dem Proxy-Log beginnen würden, und beschreiben Sie, was Sie dort bei einem gescheiterten Build sehen und warum Ihnen das nicht weiterhilft.

4. Übertragen Sie die Symptomtabelle des Kapitels in docs/betrieb.md. Ergänzen Sie eine vierte Spalte mit der Überschrift bei mir zuletzt aufgetreten am.

Teil B - Vier Fehlerbilder erzeugen

Erzeugen Sie die folgenden vier Störungen einzeln in der Vorschauumgebung. Zu jeder notieren Sie vier Angaben: das Symptom von außen mit Statuscode, die Station, an der Sie es gefunden haben, die entscheidende Logzeile und die Behebung.

1. Bringen Sie den Build zum Abbruch. Entfernen Sie dafür eine Abhängigkeit aus package.json oder verweisen Sie auf eine Bauzeit-Variable, die nicht gesetzt ist.

2. Sorgen Sie dafür, dass der Container startet und sofort wieder endet. Setzen Sie dazu einen falschen CMD oder entfernen Sie eine Laufzeitvariable, die die Anwendung beim Start braucht.

3. Erzeugen Sie ein 502 vom Proxy. Ändern Sie dafür im Label loadbalancer.server.port die Portnummer auf eine, auf der nichts lauscht.

4. Erzeugen Sie ein 404 vom Proxy. Ändern Sie dafür die Host-Regel des Routers auf einen Namen, der nicht angefragt wird.

5. Stellen Sie die vier Symptome in einer Tabelle gegenüber. Beantworten Sie darunter in drei bis vier Sätzen, was 502 und 404 für die Fehlersuche unterscheidet und woran Sie den Unterschied erkennen, wenn Sie nur den Browser und curl -vI zur Verfügung haben.

Teil C - Rollback und seine Grenze

1. Liefern Sie eine Version aus, die durchbaut, startet und trotzdem falsch antwortet, etwa mit einer vertauschten Sortierung oder einer leeren Liste. Das ist der Fall, den kein Healthcheck abfängt.

2. Führen Sie das Rollback durch. Stoppen Sie die Zeit vom Erkennen des Fehlers bis zur wiederhergestellten Version und notieren Sie jeden Klick.

3. Tragen Sie das Ergebnis in docs/betrieb.md ein, mit Datum, Anlass, Dauer, den durchgeführten Schritten und dem Ergebnis.

4. Erklären Sie in drei bis vier Sätzen, warum ein Rollback Sekunden dauert und kein neuer Build nötig ist. Gehen Sie darauf ein, was Dokploy bei jedem Deployment aufhebt.

5. Wiederholen Sie das Rollback einmal in der Produktion, zu einem Zeitpunkt ohne Benutzer. Vergleichen Sie die Dauer mit der aus Punkt 2.

6. Schreiben Sie eine Kurzanleitung Rollback von höchstens zehn Zeilen, die eine andere Person aus Ihrem Team ohne Rückfrage befolgen kann. Legen Sie sie an den Anfang von docs/betrieb.md.

7. Beschreiben Sie in sechs bis acht Sätzen den folgenden Fall. Eine neue Version führt beim Deployment eine Migration aus, die eine Spalte entfernt. Kurz darauf fällt ein Fehler auf, und Sie rollen zurück. Beantworten Sie dabei drei Fragen: Was holt das Rollback zurück, was holt es nicht zurück, und was passiert danach, wenn die alte Version die entfernte Spalte abfragt?

8. Leiten Sie aus Punkt 7 eine Regel für Ihre eigenen Migrationen ab und formulieren Sie sie in einem Satz. Legen Sie die Regel in docs/entscheidungen.md ab. In Kapitel 6 kommen Sie darauf zurück.

Wissenscheck

1. In welcher Reihenfolge prüfen Sie die vier Stationen, und warum in dieser?
2. Was unterscheidet ein 502 vom Proxy von einem 404, und was sagt jedes über die Ursache?
3. Woran erkennen Sie einen Container, der startet und sofort wieder endet, und wo steht die Ursache fast immer?
4. Warum dauert ein Rollback Sekunden statt Minuten?
5. Was holt ein Rollback zurück, und was ausdrücklich nicht?
6. Warum sind Migrationen, die nur hinzufügen, im Betrieb angenehmer als solche, die wegnehmen?
7. Warum ist ein nie ausprobiertes Rollback im Ernstfall keine Absicherung?

Abgabe

In docs/betrieb.md stehen die Kurzanleitung Rollback, die erweiterte Symptomtabelle und das dokumentierte Rollback mit Zeitangabe. In docs/entscheidungen.md steht die Regel für Migrationen. protokoll.md enthält die vier Fehlerbilder aus Teil B mit Symptom, Fundstelle, Logzeile und Behebung sowie die Antworten aus Teil C.