Ein Update einer Veranstaltungswebsite veröffentlichen

Einführung

Common Ground ist eine Community-Website zu Demonstrationszwecken. Besucher sehen sich Linux Evening an, öffnen die Details und lesen die Anmeldehinweise. Das nächste Release verlegt die Veranstaltung von Room A in die Community Hall. Du sollst dieses vorbereitete Update veröffentlichen und dabei die aktuelle Version erhalten.

Du unterscheidest ein installiertes von einem laufenden Release, wählst das Update aus und prüfst die echte Website. Anwendung und Veröffentlichungshilfe sind vorhanden; du musst weder programmieren noch Nginx konfigurieren. Grundkenntnisse im Terminal reichen aus. Alle Veranstaltungen und Adressen sind fiktiv.

Jedes Lab startet in einer eigenen vorbereiteten Umgebung. Die Registerkarten sind einsatzbereit.

Lerne die Website kennen und bereite das Update vor

Du prüfst den normalen Zustand der Website und installierst ein neues Release, ohne die Ansicht der Besucher zu verändern. Beginne in Website.

Den normalen Ablauf kennenlernen

Die Startseite stellt Common Ground vor und führt Linux Evening unter On the horizon auf. Aktuell steht dort Location: Room A. Scrolle nach unten: Im kleinen Fußbereich steht Release: event-v1. Ein Release ist ein bestimmter gespeicherter Stand der Website-Dateien.

Klicke in Website auf die Zeile Linux Evening. Die Detailseite zeigt Dienstag um 18:00 Uhr und Room A. Öffne dort Registration instructions; die Seite erklärt den demonstrierten E-Mail-Ablauf. Eine echte Anmeldung ist nicht nötig. Klicke oben auf das Logo COMMON GROUND, um in derselben Registerkarte zur Startseite zurückzukehren.

Diese Nutzerwege müssen erhalten bleiben. Die Startseite allein ist nicht der gesamte Dienst.

Eine getrennte Kopie vorbereiten

Wechsle zu Workstation. Das Terminal befindet sich bereits im bereitgestellten Veröffentlichungsbereich /home/labex/project/website-release. ls listet die Namen im aktuellen Verzeichnis auf:

ls

Du siehst packages, releases, current und release.sh. packages enthält die bereitgestellten, noch zu installierenden Versionen; releases enthält die installierten Versionen. current wählt die Version aus, die Besucher erhalten. Im nächsten Schritt untersuchst du diesen Verweis.

release.sh ist ein kleines bereitgestelltes Hilfsskript. bash führt es aus; die Wörter nach dem Dateinamen wählen eine Aktion und bei Bedarf ein Release. Du bedienst das Skript und musst keinen Bash-Code schreiben.

bash release.sh help

Lies die kurze Hilfe. install kopiert ein Paket in ein eigenes Verzeichnis; deploy wählt eine Version für die Website; rollback wählt eine bereits installierte Version. Keine dieser Aktionen entscheidet, ob die fachlich benötigten Seiten funktionieren.

Liste die bereitgestellten Versionen auf:

bash release.sh list

Sie heißen event-v1 und event-v2. Installiere das Update:

bash release.sh install event-v2

Erwartete Ausgabe:

Installed event-v2. The current website was not changed.

Prüfe, ob beide installierten Verzeichnisse existieren. Mit releases gibst du ls das aufzulistende Verzeichnis an:

ls releases

Du solltest event-v1 und event-v2 finden. Die getrennte Installation erhält die alte Version. Sie veröffentlicht das Update noch nicht.

Wechsle zurück zu Website und lade die Seite neu. Der Ort ist weiterhin Room A, im Fußbereich steht noch event-v1. Das ist beabsichtigt: Erst im nächsten Schritt wählst du das Update aus.

Wähle das Update aus und veröffentliche es

Du änderst das ausgewählte Release der Website und behältst die Version für die Wiederherstellung. Beginne in Workstation.

Die Auswahl verstehen

Ein symbolischer Link verweist im Dateisystem auf einen anderen Ort. Hier zeigt current auf das Verzeichnis eines installierten Release. Der bereitgestellte Webserver Nginx liest die Website-Dateien über diesen Link.

readlink gibt das Ziel eines symbolischen Links aus:

readlink current

Erwartete Ausgabe:

releases/event-v1

Dieser relative Pfad bezeichnet das Verzeichnis event-v1 innerhalb von releases in diesem Arbeitsbereich. Jedes Verzeichnis enthält HTML-Seiten, lokale CSS-Stile, die lokale Illustration und eine kleine Versionsdatei. Zusammen bilden sie ein vollständiges Website-Release.

cat gibt eine Datei aus. Bestätige vor der Veröffentlichung die Identität der Wiederherstellungsversion:

cat releases/event-v1/version.txt

Die Ausgabe ist event-v1. Erhalte das gesamte Verzeichnis. Falls das Update die Prüfungen nicht besteht, soll dieses Verzeichnis wieder ausgewählt werden; ein Neuaufbau oder Löschen würde diesen Plan gefährden.

Die installierte Version veröffentlichen

Wähle das Update aus:

bash release.sh deploy event-v2

Erwartete Ausgabe:

Selected event-v2. The server reports:
event-v2
Selection finished. Check the required pages before accepting this release.

Das Hilfsskript verwendet das installierte Verzeichnis, schaltet current über einen temporären Link und eine Umbenennung um und fragt die Version tatsächlich beim Server ab. So werden die alten Website-Dateien nicht überschrieben. Das beweist weder die Funktion aller Seiten noch garantiert es, dass eine ganze Browsersitzung gleichzeitig die Version wechselt.

Prüfe die Auswahl:

readlink current

Jetzt erscheint releases/event-v2.

Wechsle zu Website. Falls eine andere Seite geöffnet ist, klicke auf COMMON GROUND und lade die Startseite neu. Unter On the horizon steht nun Location: Community Hall. Der Fußbereich nennt event-v2.

Neuer Ort und Fußbereich bestätigen die Änderung. Vor der Freigabe musst du noch die wichtigen Nutzerwege prüfen.

Prüfe die Website und halte die Wiederherstellung bereit

Du prüfst das neue Release als Besucher und als HTTP-Client und bestätigst anschließend, dass die alte Version verfügbar bleibt. Beginne in Website.

Den Nutzerwegen folgen

Klicke auf Linux Evening. In der Seitenleiste muss Community Hall statt Room A stehen. Öffne dort Registration instructions. Die Seite muss die Teilnahmeschritte und events@example.test anzeigen, keinen Hinweis auf eine fehlende Seite.

Klicke in Website auf COMMON GROUND, um zur Startseite zurückzukehren.

Tatsächliche HTTP-Antworten prüfen

Wechsle zu Workstation. HTTP ist das Anfrage-Antwort-Protokoll dieser Website. Eine Anfrage nennt einen Pfad wie /registration.html; der Server liefert Status und Inhalt zurück. 200 bedeutet, dass die angeforderte Antwort erfolgreich war. 404 bedeutet, dass die angeforderte Seite nicht gefunden wurde.

curl sendet eine Anfrage. -sS blendet die Fortschrittsanzeige aus, zeigt aber Verbindungsfehler an. -o /dev/null verwirft den Antwortinhalt; /dev/null ist das Verwerfungsziel des Systems. -w gibt das nachfolgende Format aus. Die einfachen Anführungszeichen halten das Format zusammen, %{http_code} wählt den Status aus und \n beendet die Ausgabezeile.

127.0.0.1 bezeichnet diese Lab-Umgebung; Port 8081 ist der vorbereitete Website-Endpunkt. Nutze diese Adresse in Workstation, nicht im Terminal deines eigenen Computers. Der abschließende / fordert die Startseite an.

Prüfe die Startseite:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/

Das Ergebnis ist 200.

Prüfe Detail- und Anmeldepfad getrennt:

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

Beide müssen 200 liefern. Auch die Inhaltsprüfung in Website zählt: Eine Antwort mit 200, die die falsche Seite enthält, ist kein Erfolg.

Du kannst auch die kleine Versionsantwort abrufen, ohne ihren Inhalt zu verwerfen:

curl -sS http://127.0.0.1:8081/version.txt

Sie zeigt event-v2. Das ist ein nützlicher Beleg, ersetzt aber nicht die Prüfung von Seiten und Links.

Die Wiederherstellungsmöglichkeit erhalten

Das ursprüngliche Release muss intakt bleiben:

cat releases/event-v1/version.txt

Es erscheint weiterhin event-v1. Erhalte auch Seiten, Stile und Illustration; nur eine Versionsbezeichnung zu ändern bewahrt keine Website.

Wechsle zu Topology. Homepage reachable besagt lediglich, dass die Startseite antwortet. Es ist keine Freigabe des gesamten Release. Du hast die Nutzerwege unabhängig geprüft und eine vollständige Wiederherstellungsversion erhalten.

Zusammenfassung

Du hast ein getrenntes Release installiert, es ohne Überschreiben alter Dateien ausgewählt und echte Seiten und Links geprüft. Außerdem bleibt eine vollständige, bekanntermaßen funktionierende Version für die Wiederherstellung verfügbar. Im nächsten Lab nutzt du diese Möglichkeit, wenn die Startseite eines Release funktioniert, aber ein wichtiger Nutzerweg ausfällt.