Einführung
Ihr Ticket-Service muss Dringlichkeit abbilden, ohne vorhandene Anfragen zu verlieren. Ein Schema-Rollout kann fehlschlagen, wenn alte Zeilen eine neue Regel nicht erfüllen. Sie erstellen eine geordnete Migration, testen sie lokal und wenden dieselbe Datei remote an. Dabei bleiben Ticket-IDs und Betreffzeilen erhalten.
Dieses Lab beginnt unabhängig mit einer bereitgestellten initialen Migration. Es setzt die Datenbankerstellung und grundlegende SQL-Kenntnisse aus D01 voraus, verwendet aber keine frühere VM und keine frühere Datenbank.
Verwenden Sie Ihr eigenes Lernkonto und eine frische VM. Die Einrichtung installiert zunächst Node.js 22.22.0. Anschließend führt sie im Verzeichnis /home/labex/project/ticket-database npm install für das projektspezifische Wrangler 4.131.1 sowie alle für die Bewertung benötigten Abhängigkeiten aus. Die direkten Abhängigkeitsversionen sind festgelegt; bei der Installation wird eine eigene Lockfile erstellt. Während der Einrichtung erfolgt weder eine Cloud-Anmeldung noch eine bewertete Datenbankoperation. Installieren Sie auf einem persönlichen Rechner dieselbe Wrangler-Version in Ihrem Projekt mit npm install --save-dev wrangler@4.131.1.
Dieses Lab verwendet kleine synthetische Datensätze innerhalb der kostenlosen D1-Kontingente. Die Nutzung Ihres Kontos wird auf diese Kontingente angerechnet. Eine gekaufte Domain ist nicht erforderlich. Behalten Sie diese VM, bis sowohl die Ressourcenlöschung als auch die Abmeldung überprüft wurden.
Diese VM autorisieren und das Konto auswählen
In diesem Schritt verbinden Sie dieses frische Terminal mit Ihrem eigenen Lernkonto. Eine Anmeldung im Dashboard allein autorisiert die VM nicht. D1-Berechtigungen erlauben das Erstellen, Ändern und Löschen von Datenbanken. Prüfen Sie die tatsächliche Einwilligungsseite einschließlich Background Access, bevor Sie die Autorisierung bestätigen.
Öffnen Sie das vorbereitete Projekt und prüfen Sie die festgelegte CLI-Version:
cd /home/labex/project/ticket-database
npx wrangler --version
Erwartet wird 4.131.1. Starten Sie die Geräteautorisierung. --device zeigt einen Browser-Code an, und --browser=false überlässt Ihnen die Wahl des Browsers:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write
Öffnen Sie die angezeigte URL im Browser, geben Sie den aktuellen Code ein, bestätigen Sie Ihr Lernkonto und die Berechtigungen und autorisieren Sie den Zugriff. Warten Sie, bis das Terminal den erfolgreichen Abschluss bestätigt. Fügen Sie niemals Passwörter oder Token in Projektdateien ein.
npx wrangler whoami --json
Prüfen Sie loggedIn: true. Lesen Sie anschließend den Kontonamen name und die Konto-ID id, auch wenn nur ein Konto aufgelistet ist. Übernehmen Sie die gewünschte ID in die folgende Konfiguration. Die folgende Shell-Variable verwendet 6 zufällige Bytes, also 12 Hexadezimalzeichen, damit es nicht zu Kollisionen mit anderen Lernenden kommt. Ein Here-Document schreibt das JSON zwischen den beiden Zeilen JSON; $RUN wird darin expandiert.
Der umgekehrte Schrägstrich vor $schema erhält diesen JSON-Schlüssel unverändert; $RUN wird weiterhin durch den eindeutigen Namen dieses Durchlaufs ersetzt.
RUN=labex-c04-d03-$(openssl rand -hex 6)
cat > wrangler.jsonc <<JSON
{
"\$schema": "./node_modules/wrangler/config-schema.json",
"name": "$RUN",
"account_id": "YOUR_ACCOUNT_ID",
"main": "src/index.js",
"compatibility_date": "2026-09-15",
"workers_dev": true,
"preview_urls": false
}
JSON
Ersetzen Sie YOUR_ACCOUNT_ID, bevor Sie den Block ausführen. Lassen Sie dieses Terminal geöffnet, damit RUN verfügbar bleibt. name identifiziert diesen Durchlauf; account_id legt das Konto für Cloud-Operationen fest. Die Datei ist gewöhnliches JSON und damit zugleich gültiges JSONC. Durch das Schreiben der Datei wird kein Worker bereitgestellt.
Die vorhandene Ticket-Datenbank einrichten
In diesem Schritt bereiten Sie die vorhandene Version der Anwendungsdatenbank vor. Eine Migration ist eine nummerierte SQL-Datei, die eine Änderung am Schema beschreibt. Wrangler speichert die Namen angewendeter Dateien in d1_migrations. Dadurch können spätere Ausführungen abgeschlossene von noch ausstehenden Änderungen unterscheiden. Die Einrichtung stellt 0001_initial.sql als alte Anwendungsversion bereit; das Upgrade erstellen Sie selbst.
Erstellen Sie eine temporäre Cloud-Datenbank. --binding DB gibt dem Anwendungscode einen kurzen Namen, --update-config speichert den tatsächlichen Namen und die UUID in wrangler.jsonc, und --use-remote=false hält die Entwicklung lokal:
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Lesen Sie den erstellten Namen und die ID und prüfen Sie anschließend das gespeicherte Binding:
cat wrangler.jsonc
Der Eintrag DB muss die Datenbank dieses Durchlaufs benennen. Ein Binding ist eine konfigurierte Verbindung zwischen Code und einer Ressource. Die UUID identifiziert die Cloud-Datenbank, während --local eine separate SQLite-Datenbank auf dieser VM verwendet. Geben Sie bei SQL-Befehlen immer entweder --local oder --remote an.
Lesen Sie das alte Schema, bevor Sie es anwenden:
cat migrations/0001_initial.sql
Es enthält zwei vorhandene Tickets und keine Spalte für die Priorität. Wenden Sie es getrennt auf die lokalen und remote Ziele an und bestätigen Sie bei der Abfrage, dass es sich um die Datenbank dieses Labs handelt:
npx wrangler d1 migrations apply DB --local
npx wrangler d1 migrations apply DB --remote
Prüfen Sie die Zeilen und den angewendeten Status:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; SELECT name FROM d1_migrations ORDER BY id;"
Beide ursprünglichen Tickets müssen vorhanden sein; die angewendete Migration ist 0001_initial.sql. Eine angewendete Migration gehört zur Historie. Erstellen Sie für spätere Änderungen eine neue Datei, anstatt diese Historie zu bearbeiten.
Eine eingeschränkte Priorität lokal hinzufügen
In diesem Schritt geben Sie vorhandenen Tickets eine Standardpriorität, ohne die Tabelle zu löschen. ALTER TABLE ... ADD COLUMN ändert eine Tabelle direkt. Eine neu hinzugefügte Spalte ohne NULL benötigt für alte Zeilen einen sinnvollen Standardwert. CHECK beschränkt die Prioritäten auf normal oder urgent.
Erstellen Sie die nächste nummerierte Migration:
npx wrangler d1 migrations create DB add_priority
In diesem frischen Projekt wird dadurch migrations/0002_add_priority.sql erstellt. Prüfen Sie diesen Dateinamen in der Ausgabe. Schreiben Sie die Änderung in die neue Datei:
cat > migrations/0002_add_priority.sql <<'SQL'
ALTER TABLE tickets ADD COLUMN priority TEXT NOT NULL DEFAULT 'normal' CHECK(priority IN ('normal','urgent'));
SQL
Listen Sie ausstehende Migrationen auf und wenden Sie sie anschließend nur lokal an:
npx wrangler d1 migrations list DB --local
npx wrangler d1 migrations apply DB --local
Beide vorhandenen Tickets sollten dadurch normal erhalten. Fügen Sie ein dringendes Ticket hinzu und fragen Sie es ab:
npx wrangler d1 execute DB --local --command "INSERT INTO tickets (id, subject, source, priority) VALUES (3, 'Service unavailable', 'local', 'urgent'); SELECT id, subject, priority FROM tickets ORDER BY id;"
Eine ungültige Priorität muss fehlschlagen, statt unbemerkt in die Tabelle übernommen zu werden:
npx wrangler d1 execute DB --local --command "UPDATE tickets SET priority = 'critical' WHERE id = 3;"
Erwartet wird CHECK constraint failed; dieser absichtlich erzeugte Fehler lässt Ticket 3 auf urgent. Lesen Sie PRAGMA table_info(tickets) in der remote Datenbank aus, um zu sehen, dass das Cloud-Schema noch die alte Version verwendet:
npx wrangler d1 execute DB --remote --command "PRAGMA table_info(tickets);"
Remote gibt es noch keine Spalte priority. Der Erfolg der lokalen Migration aktualisiert die Cloud-Datenbank nicht.
Die getestete Migration remote anwenden
In diesem Schritt führen Sie dieselbe geprüfte Datei in der remote Datenbank ein. Prüfen Sie die ausstehenden Änderungen, bevor Sie bestätigen:
npx wrangler d1 migrations list DB --remote
npx wrangler d1 migrations apply DB --remote
Es sollte nur 0002_add_priority.sql ausstehen. Die vorhandenen Zeilen bleiben erhalten. Fügen Sie ein dringendes Ticket remote hinzu und prüfen Sie anschließend sowohl die Daten als auch die Migrationshistorie:
npx wrangler d1 execute DB --remote --command "INSERT INTO tickets (id, subject, source, priority) VALUES (3, 'Service unavailable', 'remote', 'urgent'); SELECT id, subject, priority FROM tickets ORDER BY id; SELECT name FROM d1_migrations ORDER BY id;"
Die Tickets 1 und 2 behalten ihre Betreffzeilen und erhalten die Priorität normal; Ticket 3 hat die Priorität urgent. Beide nummerierten Dateinamen sind gespeichert. Führen Sie die Anwendung erneut aus:
npx wrangler d1 migrations apply DB --remote
Der Befehl sollte melden, dass keine Migrationen ausstehen, und die Zeilen unverändert lassen. Genau deshalb ist die Verlaufstabelle wichtig: Bei einer erneuten Ausführung des Rollouts werden abgeschlossene Dateien nicht noch einmal ausgeführt. Öffnen Sie im Dashboard die D1-Datenbank dieses Durchlaufs und prüfen Sie in der Schema-/Tabellenansicht die neue Spalte, um das CLI-Ergebnis nachzuvollziehen. Bearbeiten Sie das Schema dort nicht.
Dieses Beispiel zeigt die beiden ursprünglichen Tickets mit der Standardpriorität normal und das neue entfernte Ticket mit der Priorität urgent. Der generierte Datenbankname kennzeichnet diesen Beispieldurchlauf; dein Name wird abweichen. Die obigen SQL-Abfragen, der Migrationsverlauf und die Prüfungen der Einschränkungen bestätigen das Ergebnis; der Screenshot dient als visuelle Referenz.
Die temporären Ressourcen löschen
In diesem Schritt entfernen Sie nur die Ressourcen dieses Labs, solange die VM noch autorisiert ist. Schließen Sie zuerst alle funktionalen Prüfungen ab. Behalten Sie die Konfiguration, bis die Löschung überprüft wurde.
npx wrangler d1 delete DB
Prüfen Sie die Eingabeaufforderung und bestätigen Sie, dass nur die Datenbank dieses Durchlaufs ausgewählt ist. Listen Sie anschließend die Datenbanken auf:
npx wrangler d1 list --json
Der gespeicherte Datenbankname und die UUID müssen in einer erfolgreichen Antwort fehlen. Andere Ressourcen dürfen weiterhin vorhanden sein. Ein Authentifizierungs- oder Netzwerkfehler ist nicht eindeutig: Beheben Sie den Zugriff und wiederholen Sie die Abfrage, bevor Sie fortfahren. Führen Sie die Überprüfung dieses Schritts aus, solange Sie noch angemeldet sind.
Die Autorisierung dieser VM beenden
In diesem Schritt beenden Sie die Autorisierung erst, nachdem die unabhängige Löschprüfung erfolgreich war. logout entfernt die auf dieser VM gespeicherte Wrangler-Autorisierung. Das bloße Schließen einer VM bereinigt keine Cloud-Ressourcen.
npx wrangler logout
npx wrangler whoami --json
Erwartet wird loggedIn: false. Diese nicht authentifizierte Abfrage kann mit einem Status ungleich null enden. Das ist nur dann erwartungsgemäß, wenn die strukturierte Antwort ausdrücklich bestätigt, dass Sie abgemeldet sind. Schließen Sie die Überprüfung ab und beenden Sie anschließend die Lab-Umgebung.
Zusammenfassung
Sie haben das Migrieren eines Ticket-Schemas geübt. Sie haben überprüfbare Datenbankergebnisse kontrolliert, das ausgewählte Konto und den lokalen Status eindeutig gehalten und die temporären Ressourcen vor der Abmeldung entfernt.
