Einführung
Juniper Café beantwortet Anfragen, doch die neueste Karte verlangt $35.00 für einen Oat Latte. Ein fehlerfrei laufender Pod kann trotzdem falsche Geschäftsdaten ausliefern. Du stellst die freigegebene Herbstkarte wieder her und erhältst dabei das Café, seine früheren Versionen und den separaten Service des Lesecafés.
Dies ist eine frische Umgebung mit einem eigenen vorbereiteten Release-Verlauf. Sie verwendet keine Dateien oder Prozesse aus dem vorherigen Lab. Du solltest das Lab zur saisonalen Speisekarte abgeschlossen haben: Diese Lektion verwendet dessen Menüformat, generierte ConfigMaps, Deployment und Download-Prüfungen erneut und führt anschließend die Auswahl und Wiederherstellung einer Revision ein. Die Dauer von 35 Minuten ist eine Schätzung des Autors und keine bei Anfängern gemessene Zeit.
Die freigegebene Revision wiederherstellen
In diesem Schritt wählst du anhand der tatsächlichen Speisekarte und des Deployment-Verlaufs die freigegebene Herbstversion aus und stellst sie wieder her.
Öffne Café Menu, wähle Explore the menu und suche Oat Latte. Der aktuelle Preis von $35.00 ist falsch, obwohl die Website und ihre Getränkedetailseiten laden. Wechsle zu Workspace, dessen Startverzeichnis /home/labex/project/cafe-menu ist.
Lies die vollständige freigegebene Tabelle und die Saisonbezeichnung des Thekenteams. Wie im vorherigen Lab werden Preise als ganzzahlige Cent-Beträge angegeben; 350 bedeutet $3.50:
cat approved/menu.csv
id,name,price_cents,available
espresso,Espresso,250,true
oat-latte,Oat Latte,350,true
cold-brew,Cold Brew,390,false
maple-latte,Maple Latte,450,true
cat approved/season.txt
Autumn at Juniper
Ein erfolgreicher Rollout bedeutet, dass Kubernetes den angeforderten Pod-Zustand erreicht hat. Er prüft nicht jeden Menüpreis. Prüfe das fehlerfrei laufende Deployment und liste dann seine Revisionen auf. rollout history liest die aufbewahrten ReplicaSets; der Text zur Änderungsursache hilft, die vorbereiteten Releases zu identifizieren:
kubectl get deployment cafe -n cafe-menu
kubectl rollout history deployment/cafe -n cafe-menu
Der Verlauf enthält in dieser Reihenfolge die Revisionen everyday, autumn und misprint. Revisionsnummern gehören zu diesem Deployment in dieser frischen Umgebung; betrachte eine Nummer nicht als universellen Release-Namen.
Die vollständigen gespeicherten Versionen stehen ebenfalls bereit. Vergleiche die frühere reguläre Karte mit der freigegebenen Herbstkarte:
cat versions/everyday/menu.json
cat versions/autumn/menu.json
Die reguläre Version hat zwar den richtigen Oat-Latte-Preis, bietet jedoch weiterhin Cold Brew und keinen Maple Latte an. Einfach irgendein älteres Release wiederherzustellen, wäre daher falsch. Die Herbstversion stimmt mit allen Freigabewerten und der Saisonbezeichnung überein.
Untersuche Revision 2, die vorbereitete Herbstrevision in dieser Umgebung. --revision=2 fordert die Details ihrer Pod-Vorlage an:
kubectl rollout history deployment/cafe -n cafe-menu --revision=2
Suche den Verweis auf die generierte ConfigMap im Volume menu. Diese gespeicherte Vorlage kann neue Pods mit genau dieser älteren Konfiguration starten, weil die ConfigMap noch existiert.
Stelle diese Revision wieder her. rollout undo ändert das Deployment auf die ausgewählte frühere Pod-Vorlage; --to-revision=2 wählt ausdrücklich die freigegebene aus:
kubectl rollout undo deployment/cafe -n cafe-menu --to-revision=2
Warte auf beide wiederhergestellten Replikate:
kubectl rollout status deployment/cafe -n cafe-menu --timeout=120s
deployment "cafe" successfully rolled out
Wechsle zu Café Menu, wähle Our menu und aktualisiere bei Bedarf. Bestätige, dass Oat Latte $3.50 kostet, Maple Latte für $4.50 verfügbar und Cold Brew nicht verfügbar ist. Wenn die Wartezeit überschritten wird, nutze den im vorherigen Lab erklärten Ablauf zur Fehlersuche mit kubectl get pods und kubectl describe deployment; setze den Namespace nicht zurück.
Vergleiche alle vier Karten, einschließlich des nicht verfügbaren Cold Brew.
Eine wichtige Grenze: Undo stellt die Pod-Vorlage einschließlich des Konfigurationsnamens wieder her. Es stellt keine beliebigen früheren Inhalte einer direkt bearbeiteten ConfigMap wieder her. Lasse jede aufbewahrte generierte Konfiguration unverändert.
Das gespeicherte Release abgleichen
In diesem Schritt sorgst du dafür, dass dein gespeichertes Release die wiederhergestellte laufende Anwendung reproduziert.
Kehre zu Workspace zurück. Ein Rollback im laufenden Cluster bearbeitet keine lokalen Dateien. Das Verzeichnis release enthält noch den fehlerhaften Kandidaten; wenn du es jetzt anwendest, kehrt der falsche Preis zurück. Lies diese Datei, bevor du sie ersetzt:
cat release/menu.json
Sie enthält für Oat Latte weiterhin 3500 Cent. Kopiere die freigegebene Herbstkarte und die Deployment-Definition in dein Arbeits-Release. Jeder cp-Befehl ersetzt nur seine benannte Zieldatei. Lasse die ursprünglichen Versionsverzeichnisse unverändert:
cp versions/autumn/menu.json release/menu.json
cp versions/autumn/deployment.json release/deployment.json
Die Deployment-Datei enthält außerdem die freigegebene Annotation zur Änderungsursache. Deine vorhandene kustomization.yaml behält denselben Generator und Namespace bei. Rendere das Release erneut:
kubectl kustomize release
Der generierte Konfigurationsname sollte mit dem Verweis in der wiederhergestellten Herbstvorlage übereinstimmen. Eine neue Datenversion ist nicht nötig, weil die Menübytes identisch sind. Wende die abgeglichene Quelle an:
kubectl apply -k release
kubectl rollout status deployment/cafe -n cafe-menu --timeout=120s
Der Rollout wird abgeschlossen, während die freigegebene Karte weiterhin verwendet wird. Ein erneutes Anwenden erhält jetzt die Wiederherstellung, statt sie rückgängig zu machen. Behalte das gesamte Verzeichnis release: Deployment, Menüdatei und Generatorkonfiguration wirken zusammen. Wenn du einen falschen Pfad kopiert hast, helfen dir pwd und ls versions/autumn, die bereitgestellten Dateien zu finden; wiederhole die beiden gezielten Kopiervorgänge, statt den aufbewahrten Verlauf zu bearbeiten.
Die wiederhergestellte Speisekarte übergeben
In diesem Schritt schließt du die Arbeit mit einem echten Menüdownload ab und bestätigst, dass das nicht betroffene Café weiterhin funktioniert.
Wechsle zu Café Menu. Öffne von Our menu aus den Link About this drink für Oat Latte, bestätige den korrigierten Preis von $3.50 auf der Detailseite und kehre mit Back to the menu zurück. Öffne Visit us und bestätige Standort und Öffnungszeiten. Lade mit Download menu die tatsächliche vollständige Speisekarte herunter.
Wechsle zu Reference Menu und wähle Our menu. Willow Reading Room muss weiterhin sein reguläres Angebot zeigen; die Reparatur von Juniper darf diesen separaten Service nicht ändern.
Kehre zu Workspace zurück. Speichere den tatsächlichen Download mit denselben curl-Optionen, die du im ersten Lab kennengelernt hast:
curl --fail --silent --show-error http://127.0.0.1:8081/menu.csv -o menu-handover.csv
Vergleiche ihn mit der freigegebenen Tabelle:
diff -u approved/menu.csv menu-handover.csv
Keine Ausgabe bedeutet, dass der vollständige Download übereinstimmt. Wenn Unterschiede erscheinen, unterscheide anhand der tatsächlichen Zeilen zwischen einer falsch wiederhergestellten Version und einer veralteten gespeicherten Quelle. Korrigiere das Release, warte auf den Rollout und lade erneut herunter; bearbeite die empfangene CSV-Datei nicht von Hand.
Liste die Konfigurationen auf, um zu bestätigen, dass die älteren Versionen verfügbar bleiben:
kubectl get configmaps -n cafe-menu
Die Wiederherstellung ist abgeschlossen, wenn das laufende Café, die wiederverwendbare Quelle und der tatsächliche Download für das Team übereinstimmen. Frühere Quellversionen und generierte Konfigurationsobjekte bleiben intakt.
Zusammenfassung
Du hast zwischen einer fehlerfrei laufenden Anwendung und einer korrekten Speisekarte unterschieden, eine Revision anhand vollständiger fachlicher Belege ausgewählt und ihren aufbewahrten Konfigurationsverweis wiederhergestellt. Außerdem hast du das lokale Release abgeglichen, damit ein späteres Anwenden die Wiederherstellung erhält, und anschließend echte Seiten und den tatsächlichen Menüdownload geprüft, ohne den Referenzservice zu ändern.
Die unabhängige Challenge ändert das Café, die Zusammenhänge der Menüdaten und die freigegebene Version. Sie verwendet dieselben Methoden für Konfiguration, Rollout und Übergabe.
