Einführung
Common Ground hat einen weiteren Release-Kandidaten zur Bewertung. Sein Veröffentlichungsbefehl kann erfolgreich sein, obwohl Besucher eine wichtige Aktion nicht abschließen können. Du sollst diesen Unterschied erkennen und bei Bedarf das bekanntermaßen funktionierende Release wiederherstellen.
Diese wegwerfbare Trainingswebsite hat keine echten Besucher. Du übst die Wiederherstellung absichtlich; in echten Auslieferungsprozessen können Prüfungen vor der Veröffentlichung einen Kandidaten ablehnen, bevor Besucher ihn erhalten.
Dies ist eine frische Umgebung: event-v1 mit Room A läuft unabhängig vom vorherigen Lab. Du bereitest event-v3 vor, prüfst die echten Nutzerwege und stellst den ursprünglichen Dienst ohne Bearbeitung der bereitgestellten Dateien wieder her. Workstation, Website und Topology sind einsatzbereit.
Bereite das Wiederherstellungsziel vor
Du identifizierst die funktionierende Version und installierst den Kandidaten getrennt, bevor du die Website änderst. Beginne in Website.
Den gewünschten Wiederherstellungszustand kennen
Auf der Startseite findet Linux Evening in Room A statt; der Fußbereich nennt event-v1. Klicke auf die Veranstaltungszeile, prüfe die Detailseite und öffne Registration instructions. Diese normalen Funktionen muss eine Wiederherstellung zurückbringen. Kehre mit COMMON GROUND in Website zur Startseite zurück.
Wechsle zu Workstation. Das Terminal befindet sich bereits in /home/labex/project/website-release. Prüfe den aktuellen symbolischen Link:
readlink current
Er zeigt releases/event-v1. Prüfe die erhaltene Versionsdatei:
cat releases/event-v1/version.txt
Sie zeigt event-v1. Dieses Verzeichnis ist hier dein ausdrückliches Wiederherstellungsziel. Die „vorherige“ Version ist nicht in jedem System automatisch die richtige Wahl; in diesem Lab hast du ihre benötigten Seiten als funktionierend bestätigt.
Den Kandidaten vorbereiten
Liste die bereitgestellten Pakete auf:
bash release.sh list
Diese Umgebung enthält event-v1 und event-v3. Der Kandidat verlegt den Ort in die Community Hall. Ein neuer Name oder eine erfolgreiche Installation belegt keine Qualität.
Installiere ihn, ohne ihn auszuwählen:
bash release.sh install event-v3
Die Meldung bestätigt, dass die aktuelle Website unverändert blieb. Liste die installierten Releases auf:
ls releases
event-v1 und event-v3 müssen vorhanden sein. Erhalte beide unverändert: Den Kandidaten bewertest du, die Ausgangsversion kannst du wiederherstellen.
Erkenne ein fehlerhaftes Release
Du veröffentlichst den Kandidaten und unterscheidest eine erfolgreiche Auswahl von funktionierenden Nutzeraktionen. Beginne in Workstation.
Die erfolgreiche Auswahl beobachten
Wähle den Kandidaten aus:
bash release.sh deploy event-v3
Das Skript meldet event-v3 und fordert zur Seitenprüfung auf. Der Befehl hat die Auswahl abgeschlossen, nicht die fachlichen Anforderungen bewertet.
Prüfe den Startseitenstatus mit den curl-Optionen aus dem ersten Lab:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/
Die Antwort ist 200. Auch der Versionsendpunkt funktioniert:
curl -sS http://127.0.0.1:8081/version.txt
Er zeigt event-v3. Keine dieser Beobachtungen bestätigt die Funktion des Veranstaltungslinks.
Den für Besucher sichtbaren Fehler finden
Wechsle zu Website, kehre mit COMMON GROUND zur Startseite zurück und lade neu. Die Startseite wirkt vollständig und zeigt Community Hall. Klicke auf Linux Evening.
Statt der Details siehst du Let's get you back on track. und 404 / A SMALL DETOUR. Das ist die gestaltete Fehlerseite für fehlende Seiten. Sie sieht hochwertig aus, aber das HTTP-Ergebnis bedeutet weiterhin einen Fehler für die angeforderte Veranstaltung.
Der Veranstaltungslink des Kandidaten zeigt auf /events/container-evening.html. Fordere in Workstation genau diesen Pfad an:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/events/container-evening.html
Erwartet wird 404. Das ist ein beabsichtigter Beleg, kein zu reparierender oder zu überspringender Befehl. Ohne die curl-Option zum Fehlschlagen bei HTTP-Fehlern kann curl bei 404 normal enden: Eine Serverantwort unterscheidet sich von einem Verbindungsfehler.
Wechsle zu Topology. Dort kann weiterhin Homepage reachable stehen, weil die eng begrenzte Prüfung erfolgreich ist. Der benötigte Veranstaltungspfad funktioniert nicht. Du musst das Release ablehnen und die bekannte funktionierende Version wiederherstellen, statt den Dienst anzuhalten oder den Kandidaten umzuschreiben.
Stelle die bekannte funktionierende Version wieder her und prüfe sie
Du stellst die ursprüngliche Website wieder her und bestätigst, dass Besucher sie erneut nutzen können. Beginne in Workstation.
Das erhaltene Release auswählen
rollback wählt eine bereits installierte Version aus. Es repariert oder erstellt den fehlerhaften Kandidaten nicht neu. Stelle dein geprüftes Wiederherstellungsziel wieder her:
bash release.sh rollback event-v1
Erwartete Ausgabe:
Selected event-v1. The server reports:
event-v1
Selection finished. Check the required pages before accepting this release.
Prüfe den symbolischen Link:
readlink current
Er wählt releases/event-v1. Das Verzeichnis event-v3 bleibt gespeichert; es für spätere Untersuchungen zu behalten bedeutet nicht, dass es weiterhin Besucher bedient.
Den wiederhergestellten Nutzerweg prüfen
Wechsle zu Website. Der Browser steht möglicherweise noch auf der fehlenden URL des Kandidaten. Klicke auf COMMON GROUND und lade die Startseite neu. Sie sollte Room A und event-v1 zeigen. Klicke erneut auf Linux Evening: Der wiederhergestellte Link öffnet /events/linux-evening.html. Öffne Registration instructions und prüfe, ob die Teilnahmeschritte verfügbar sind.
Die alte URL, die nur der Kandidat verlinkte, würde weiterhin 404 liefern. Die Wiederherstellung bringt die tatsächlichen Links der guten Website zurück, statt jede fehlende URL anzulegen.
Prüfe die wiederhergestellten Pfade in Workstation:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/events/linux-evening.html
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/registration.html
Alle drei liefern 200. Die Browserprüfungen haben auch den richtigen Inhalt bestätigt.
Erhalte beide installierten Versionen:
ls releases
Du solltest weiterhin event-v1 und event-v3 finden. Der Dienst ist wiederhergestellt; der Kandidatenfehler bleibt eine spätere Entwicklungsaufgabe. Diese Übung stellt nur statische Website-Dateien wieder her. Sie macht weder Datenbankänderungen noch Nutzereingaben oder eine gesamte Browsersitzung atomar rückgängig.
Zusammenfassung
Du hast erlebt, dass ein echter Veröffentlichungsbefehl erfolgreich sein kann, während ein Nutzerweg fehlschlägt. Du hast den Kandidaten abgelehnt und die vollständige bekannte funktionierende Website wiederhergestellt. Du hast sowohl echte Seiteninhalte als auch HTTP-Antworten geprüft. Der Kandidat bleibt für Untersuchungen erhalten; die Wiederherstellung hat ihn nicht unbemerkt repariert.
