Testbuchungen von Live-Buchungen trennen

Einführung

STILL STUDIO veranstaltet kleine Töpferkurse. Gäste wählen einen Workshop, buchen einen Platz und sehen ihren Namen auf der Gästeliste. Das Team möchte einen Termin in Garden Room ausprobieren, ohne Plätze der echten Gästeliste von Riverside Room zu belegen. Du gibst derselben Anwendung eine eigene Staging-Umgebung: eine deutlich gekennzeichnete Testwebsite mit getrennten Buchungsdaten.

Grundlegende Terminal-Erfahrung reicht aus. Docker Compose, Konfiguration, Pfade, Ports und Datenvolumes werden hier eingeführt. Anwendung und Image sind vorbereitet; du schreibst keinen Anwendungscode und installierst keine Werkzeuge. Alle Buchungen sind erfunden. E-Mails, Zahlungen, externe Konten oder echte personenbezogene Daten werden nicht verwendet.

Nutze Live Bookings für die vorbereitete Website auf Port 8081, Preview Bookings für deine Staging-Website auf Port 8082 und Workstation für Befehle. Preview Bookings ist erst nach dem Start in Schritt 2 verfügbar. Diese Einheit startet unabhängig.

Das Geschäft kennenlernen und die Vorschau konfigurieren

In diesem Schritt nutzt du den normalen Buchungsablauf und bereitest anschließend einen getrennten Satz von Konfigurationswerten vor. Beginne in Live Bookings.

Einen Platz im normalen Dienst buchen

Die Startseite stellt den Töpferkurs vor und zeigt LIVE BOOKINGS, Riverside Room und 4 of 6 places left. Wähle Explore the clay workshop. Die Workshop-Seite beschreibt den Termin und enthält das Feld Guest name. Gib den erfundenen Namen Live guest ein und wähle Reserve a place.

Der Browser öffnet Guest list mit Maria, Jun und Live guest. Nun steht dort 3 of 6 places left. Dies ist ein echter Schreibvorgang in der Datenbank und keine dekorative Erfolgsmeldung. Wähle STILL STUDIO, um zur Startseite zurückzukehren. Erhalte alle drei Buchungen.

Wenn du denselben Namen versehentlich zweimal sendest, erklärt die Website, dass bereits eine Buchung vorliegt; sie fügt keine zweite hinzu. Bei einem Tippfehler im eigenen Namen öffnest du Guest list, wählst Cancel nur neben deiner falschen Buchung und buchst erneut mit Live guest. Storniere niemals Maria oder Jun und leere nicht die gesamte Liste wegen eines Tippfehlers.

Die Konfigurationsgrenze verstehen

Wechsle zu Workstation, bereits in /home/labex/project/booking. Ein Pfad bezeichnet eine Datei oder ein Verzeichnis. pwd zeigt das aktuelle Verzeichnis, ls dessen Inhalt:

pwd

/home/labex/project/booking

ls

Du solltest compose.yaml und live.env sehen. cat gibt eine Textdatei aus:

cat live.env

PORT=8081
APP_ENV=live
VENUE=Riverside Room
CAPACITY=6
DATA_VOLUME=still-live-data

Konfiguration gibt einer Anwendung Auswahlmöglichkeiten, ohne ihren Code zu ändern. Diese Zeilen mit KEY=value bestimmen den veröffentlichten Port, die Umgebungskennzeichnung, den Ort, die Kapazität und das Datenvolume. VENUE ändert den tatsächlichen Workshop-Ort auf der gesamten Website. CAPACITY begrenzt angenommene Buchungen, statt nur eine Beschriftung zu ändern.

Docker führt eine Anwendung in einem Container aus, der aus einem gespeicherten Image erstellt wird. Beide Websites verwenden das bereitgestellte Image still-booking:1. Jeder Container erhält beim Erstellen eigene Umgebungsvariablen. Ein benanntes Volume speichert die Datenbank außerhalb des austauschbaren Containers. Verschiedene Container können dasselbe Volume verwenden; unterschiedliche Containernamen allein trennen ihre Datensätze daher nicht.

Diese Ressourcen stehen bereit:

Der Volumename wählt den tatsächlichen Speicher. Wähle für Testbuchungen niemals das Live-Volume.

Die kleine Compose-Datei verstehen

Docker Compose beschreibt zusammengehörige Container in einer YAML-Datei. YAML gruppiert Einstellungen durch Einrückung. Behalte die vorgegebenen Abstände bei und verwende Leerzeichen statt Tabulatoren. Lies die bereitgestellte Datei:

cat compose.yaml

Unter services verwendet booking das Image still-booking:1. Der Abschnitt environment übergibt Werte an die Anwendung. ${VENUE} bedeutet, dass Compose vor dem Erstellen des Containers den Wert namens VENUE einsetzt. Eine Umgebungsdatei liefert Eingaben für diese Ersetzung; sie ändert nicht automatisch einen bereits laufenden Prozess.

ports bildet ${PORT}:8000 ab: Vor dem Doppelpunkt steht der veröffentlichte Port der Lab-Instanz; 8000 ist der Port, an dem die Anwendung im Container lauscht. Die beiden Websites benötigen unterschiedliche veröffentlichte Ports.

Der Dienst bindet booking-data unter /data ein, wo die Anwendung ihre Datenbank speichert. Der Volume-Eintrag auf oberster Ebene löst diesen Alias zu ${DATA_VOLUME} auf. external: true bedeutet, dass das Volume schon existiert und Compose genau diese Ressource verwenden muss. Ein Projektname gruppiert Compose-Container; er benennt ein ausdrücklich ausgewähltes externes Volume nicht um.

Vorschauwerte schreiben und auflösen

Lass live.env unverändert. Erstelle preview.env mit den folgenden Werten. cat > preview.env ersetzt diese Datei. Das in Anführungszeichen gesetzte ENV beginnt ein Here-Dokument: Füge den gesamten Block einschließlich des abschließenden ENV in einer eigenen Zeile ein. Die Anführungszeichen erhalten den Text wörtlich.

cat > preview.env <<'ENV'
PORT=8082
APP_ENV=staging
VENUE=Garden Room
CAPACITY=3
DATA_VOLUME=still-trial-data
ENV

Ein Port kennzeichnet einen Netzwerkdienst. Hier gehört 8082 zu Preview Bookings; 8081 bleibt Live Bookings. APP_ENV=staging aktiviert die deutliche Testkennzeichnung. Es wählt nicht selbst getrennten Speicher aus; dafür ist DATA_VOLUME zuständig.

--env-file preview.env sagt Compose, welche Werte es einsetzen soll. -p still-preview wählt das Projekt. config gibt die aufgelöste Konfiguration aus, ohne Container zu starten oder zu ändern:

docker compose --env-file preview.env -p still-preview config

Finde APP_ENV: staging, VENUE: Garden Room, Kapazität 3, veröffentlichten Port 8082 und Volume still-trial-data. Die Formatierung unterscheidet sich je nach Compose-Version. Die aufgelösten Werte sind der Nachweis, nicht allein ein erfolgreicher Befehlsabschluss.

Meldet Compose eine fehlende Variable oder Datei, prüfe pwd und cat preview.env, korrigiere die Schreibweise durch erneutes Ausführen des vollständigen Here-Dokuments und wiederhole config. Hat deine Shell bereits eine Variable wie VENUE exportiert, kann deren Wert die Datei überschreiben. unset VENUE entfernt diesen Shell-Wert; nutze das gleiche Verfahren nur bei einem widersprüchlichen Schlüssel, den du selbst exportiert hast. Starte die Vorschau erst, wenn die aufgelösten Werte stimmen.

Die Vorschau starten und ihre echte Kapazität testen

In diesem Schritt startest du die Staging-Kopie und weist nach, dass ihre Buchungen eine getrennte Liste nutzen. Beginne in Workstation.

Die konfigurierte Anwendung starten

up erstellt oder aktualisiert die Container des Projekts. -d lässt sie im Hintergrund laufen, während der Terminal verfügbar bleibt:

docker compose --env-file preview.env -p still-preview up -d

Die Ausgabe nennt den erstellten Container. ps zeigt den tatsächlichen Projektzustand und veröffentlichten Port:

docker compose --env-file preview.env -p still-preview ps

Suche den laufenden Dienst booking und Port 8082, der mit 8000 verbunden ist. Scheitert der Start, gibt logs die Anwendungsmeldungen aus:

docker compose --env-file preview.env -p still-preview logs

Ein nicht verfügbares externes Volume bedeutet meist einen Tippfehler im Ressourcennamen. Korrigiere preview.env, führe erneut config und dann up -d aus. Erstelle kein Ersatzvolume, um ein falsches Ziel zu verdecken. Ein Portkonflikt bedeutet meist, dass du den Live-Port gewählt hast. Erhalte 8081 und nutze 8082 für diese Vorschau.

Eine Testbuchung vornehmen

Wechsle zu Preview Bookings und lade bei Bedarf neu. Die Startseite muss STAGING · TEST BOOKINGS ONLY, Garden Room und 3 of 3 places left zeigen. Wähle Explore the clay workshop, gib Trial guest ein und wähle Reserve a place. Guest list zeigt nun nur Trial guest mit 2 of 3 places left.

Wechsle zu Live Bookings, wähle Guest list und lade neu. Dort müssen weiterhin Maria, Jun und Live guest sowie 3 of 6 places left erscheinen. Tauchen Testdaten hier auf, lege keine weiteren Testbuchungen an. Korrigiere in Workstation das Vorschau-Volume, wende up -d an und storniere dann nur deinen eindeutig erkennbaren Testeintrag in der Live-Liste. Erhalte alle legitimen Live-Buchungen. Öffne Preview Bookings und erstelle dort nach der Korrektur Trial guest.

Dieser Vergleich ist wichtiger als die Kennzeichnung. Ein Staging-Label mit geteilter Datenbank würde weiterhin echte Plätze verbrauchen.

Die kleinere Kapazität ausprobieren

Bleibe in Preview Bookings. Folge Back to the workshop und buche Capacity A. Kehre erneut zum Workshop zurück und buche Capacity B. Die Liste enthält drei Gäste und zeigt 0 of 3 places left.

Versuche eine weitere Buchung, Overflow guest. Die Seite sollte Every place is taken. und No booking was added. melden. Folge View the guest list: Overflow guest darf nicht enthalten sein. Die kleinere Kapazität hat das Anwendungsverhalten verändert.

Storniere nur Capacity A und Capacity B; behalte Trial guest. Die Vorschau zeigt wieder 2 of 3 places left. Bei einem Tippfehler storniere genau diesen Testeintrag und wiederhole ihn; die Datenbank muss nicht geleert werden. Kehre zu Live Bookings zurück und bestätige, dass Liste und freie Plätze unverändert sind.

Maschinenlesbare Ergebnisse vergleichen

Wechsle zu Workstation. HTTP ist das Anfrage-Antwort-Protokoll deines Browsers. curl sendet eine Anfrage; -sS blendet den Fortschritt aus, zeigt aber Verbindungsfehler. In Workstation bezeichnet 127.0.0.1 diese Lab-Instanz. Eine URL verbindet Protokoll, Adresse, Port und Ressourcenpfad. /api/info liefert die tatsächliche Konfiguration und Datenbankliste als JSON, ein strukturiertes Textformat. Eine Datenbank-Abfragesprache brauchst du nicht.

curl -sS http://127.0.0.1:8081/api/info

Lies live, Riverside Room, Kapazität 6, verbleibende Plätze 3 und die drei Live-Namen. IDs können variieren.

curl -sS http://127.0.0.1:8082/api/info

Lies staging, Garden Room, Kapazität 3, verbleibende Plätze 2 und nur Trial guest. Dies sind zwei verschiedene Endpunkte, nicht zwei Beschriftungen derselben Liste.

Die Vorschau ersetzen und Buchungen erhalten

In diesem Schritt ersetzt du den Vorschau-Container und bestätigst, dass seine getrennten Daten erhalten bleiben. Beginne in Workstation.

Die tatsächliche Speichereinbindung prüfen

ps -q gibt nur die Container-ID des Projekts aus. docker inspect liest die tatsächlichen Einstellungen eines Containers. --format wählt ein Feld; die Vorlage in Anführungszeichen wandelt dessen Einbindungen in JSON um. Der Shell-Ausdruck $(...) führt den inneren Befehl aus und fügt dessen Ausgabe als Containerargument ein:

docker inspect $(docker compose --env-file preview.env -p still-preview ps -q booking) --format '{{json .Mounts}}'

Finde eine Einbindung vom Typ volume mit Namen still-trial-data und Ziel /data. Ein anderer Projektname würde Live-Daten nicht schützen, wenn diese Einbindung still-live-data hieße.

Nur den Vorschau-Container neu erstellen

--force-recreate weist up an, den Container auch bei unveränderter Konfiguration zu ersetzen. Eingebundene benannte Volumes bleiben erhalten. Dies zeigt auch, wie die Konfiguration einen neuen Prozess erreicht: Nur die Umgebungsdatei zu bearbeiten würde einen laufenden Container nicht aktualisieren.

docker compose --env-file preview.env -p still-preview up -d --force-recreate

Warte, bis ps den laufenden Dienst zeigt:

docker compose --env-file preview.env -p still-preview ps

Wechsle zu Preview Bookings und lade Guest list neu. Trial guest muss in Garden Room mit 2 of 3 places left erhalten bleiben. Wechsle zu Live Bookings und lade dessen Liste neu. Maria, Jun und Live guest müssen in Riverside Room mit 3 of 6 places left bleiben. Weder Containerersatz noch Testbuchung dürfen die andere Umgebung leeren.

Verwende weder Volumelöschung noch down -v als Wiederherstellung. Startet die Vorschau nicht, nutze logs desselben Projekts, korrigiere die Werte und wende erneut up -d an. Die vorbereitete Live-Umgebung liegt außerhalb deines Änderungsbereichs.

Seiten und Antworten gemeinsam prüfen

Wähle in Preview Bookings STILL STUDIO, öffne den Workshop und dann Guest list. Lokale Illustration, Details und Navigation müssen weiterhin funktionieren. Eine funktionierende Startseite allein ist nicht der vollständige Buchungsdienst.

Wechsle zu Workstation. HTTP-Status 200 bedeutet eine erfolgreiche Antwort; 404, dass der angefragte Pfad nicht existiert. -o /dev/null verwirft den Antwortinhalt; -w gibt das Format in Anführungszeichen aus. %{http_code} ist der HTTP-Status, \n beendet die Ausgabezeile:

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

Erwarte 200 und bestätige die richtige Liste im Browser. Ein 200 mit der falschen Seite ist kein Erfolg.

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

Erwarte 200: Der Live-Workshop bleibt verfügbar. Ein Verbindungsfehler unterscheidet sich von einer HTTP-Fehlerantwort; prüfe ps und logs, wenn kein Server antwortet. Du hast nun ein Image, zwei unabhängig konfigurierte Prozesse und zwei getrennte dauerhafte Gästelisten. Dies ist Trainingsisolation auf einer Instanz, keine Sicherheitsgrenze gegenüber einem Administrator mit Docker-Zugriff.

Zusammenfassung

Du hast eine Staging-Kopie derselben Buchungs-App konfiguriert und gestartet, ein getrenntes benanntes Volume gewählt, die echte Kapazität getestet und beide Listen verglichen. Die Neuerstellung erhielt die Vorschau-Buchung, während der Live-Dienst seine ursprünglichen Gäste behielt. Ein anderes Label oder Compose-Projekt half bei der Organisation; das tatsächliche Datenziel stellte die Isolation her.