Einführung
Ein Supportdienst benötigt einen sicheren Ort, um Konfigurationsänderungen zu testen. Sie führen denselben Code in einer Preview- und einer Live-Umgebung aus, halten deren öffentliche Bezeichnungen und Secrets getrennt und schützen einen simulierten Wartungsendpunkt, während die Health-Checks öffentlich bleiben.
Verwenden Sie Ihr eigenes Cloudflare-Lernkonto sowie die Kenntnisse zur Geräteautorisierung, zum Deployment und zur Protokollierung aus den vorherigen Übungen. Diese Übung startet unabhängig in /home/labex/project/worker-config mit Node.js 22.22.0, dem lokalen Wrangler 4.131.1 und einer kleinen Fixture für die Health-Route. Es werden keine vorherigen VM- oder Cloud-Ressourcen wiederverwendet. Beide Deployments sind kurzlebig, und der Wartungsvorgang ist ein Dry Run. Verwenden Sie ausschließlich generierte simulierte Tokens. Workers Free und workers.dev reichen für diese kleine Übung aus; Anfragen werden auf Ihre Kontonutzung angerechnet. Eine gekaufte Domain, eine Datenbank oder ein kostenpflichtiges Upgrade sind nicht erforderlich.
Sie löschen beide Cloud-Deployments und die lokalen Token-Dateien und melden sich ab, bevor Sie die VM beenden. Lassen Sie während der gesamten Übung dasselbe Terminal geöffnet.
Preview- und Live-Konfiguration trennen
In diesem Schritt verwenden Sie denselben bereitgestellten Health-Handler mit zwei benannten Umgebungen. live ist weiterhin ein kurzlebiges Lern-Deployment; keine der beiden Umgebungen verarbeitet echte Produktionsdaten. Der Name preview bezeichnet eine Wrangler-Umgebung und keine Preview-URL einer Version.
Wechseln Sie in das vorbereitete Projekt und sehen Sie sich die Fixture für die Health-Route an. Node und der lokale Wrangler sind bereits installiert.
cd /home/labex/project/worker-config
node --version
npx wrangler --version
cat src/index.js
Erwarten Sie Node v22.22.0 und Wrangler 4.131.1. Der Handler liest nicht geheime Anzeigewerte aus env. Installieren Sie auf Ihrem eigenen Rechner Node und fügen Sie wrangler@4.131.1 als Entwicklungsabhängigkeit des Projekts hinzu. Stellen Sie vorhandene Abhängigkeiten mit npm ci wieder her.
Erzeugen Sie einen kurzlebigen Basisnamen. Die Befehlsersetzung fügt die zufällige hexadezimale Ausgabe in die Shell-Variable ein. Lassen Sie dieses Terminal für die späteren Befehle geöffnet.
WORKER_NAME="labex-config-$(openssl rand -hex 6)"
Schreiben Sie die Konfiguration mit einem Here-Dokument. Durch die nicht quotierte Abschlussmarke wird $WORKER_NAME ersetzt. main wählt den gemeinsamen Code aus, und compatibility_date legt das Laufzeitverhalten fest. Die env-Objekte überschreiben die Konfiguration für --env preview und --env live. Definieren Sie jeden vars-Wert in jeder Umgebung, weil diese Bindings nicht vererbt werden. Es gibt weder eine Datenbank noch eine Queue-Ressource: QUEUE_LABEL ist lediglich eine öffentliche Anzeigebezeichnung.
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false,
"env": {
"preview": {"vars": {"ENVIRONMENT": "preview", "QUEUE_LABEL": "sandbox"}},
"live": {"vars": {"ENVIRONMENT": "live", "QUEUE_LABEL": "primary"}}
}
}
CONFIG
Starten Sie beide lokalen Laufzeiten. > leitet die Ausgabe um, 2>&1 schließt Fehlermeldungen ein, und & führt den Prozess im Hintergrund aus. Unterschiedliche HTTP- und Inspector-Ports verhindern Konflikte.
npx wrangler dev --env preview --port 8080 > preview.log 2>&1 &
npx wrangler dev --env live --port 8081 --inspector-port 9230 > live.log 2>&1 &
cat preview.log
cat live.log
Warten Sie, bis beide Logs die Bereitschaft melden. Wiederholen Sie bei Bedarf das entsprechende cat. Vergleichen Sie anschließend die Antworten:
curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8081/health
Beide Anfragen geben 200 zurück. Preview gibt {"status":"ok","environment":"preview","queue":"sandbox"} zurück, Live gibt {"status":"ok","environment":"live","queue":"primary"} zurück. curl -i zeigt Status und Header an. Verwenden Sie bei laufenden Servern die Verifizierungsschaltfläche.
Die Dokumentation zu Umgebungen erläutert die Vererbung von Umgebungen und die standardmäßigen Deployment-Namen <name>-<environment>.
Eine Wartungsroute mit lokalen Secrets schützen
In diesem Schritt schützen Sie einen simulierten Wartungsvorgang mit einem unterschiedlichen Token in jeder Umgebung. Ein Secret ist eine private Konfiguration, die über env verfügbar ist. Es darf nicht in öffentlichen vars, in zurückgegebenem JSON oder in Anwendungslogs erscheinen. Dieses kleine Beispiel mit Bearer-Token vermittelt die serverseitige Grenze, ist aber kein vollständiges Benutzerauthentifizierungssystem.
Beenden Sie die beiden lokalen Jobs, bevor Sie Secret-Dateien hinzufügen. Prüfen Sie die tatsächlichen Jobnummern. Die Beispiele gehen davon aus, dass Preview Job 1 und Live Job 2 ist.
jobs
kill %1 %2
Erzeugen Sie zwei zufällige Tokens ausschließlich für Tests, ohne sie anzuzeigen. umask 077 sorgt dafür, dass neue Dateien nur für Ihren VM-Benutzer lesbar sind. printf schreibt jeweils eine dotenv-Zuweisung in die umgebungsspezifische Datei. Verwenden Sie hier niemals ein echtes API-Token eines Kontos.
umask 077
PREVIEW_TOKEN=$(openssl rand -hex 24)
LIVE_TOKEN=$(openssl rand -hex 24)
printf 'MAINTENANCE_TOKEN=%s\n' "$PREVIEW_TOKEN" > .dev.vars.preview
printf 'MAINTENANCE_TOKEN=%s\n' "$LIVE_TOKEN" > .dev.vars.live
cat .gitignore
Vergewissern Sie sich, dass .dev.vars* und .env* ausgeschlossen sind. Geben Sie Secret-Dateien nicht aus und committen Sie sie nicht. Wrangler lädt .dev.vars.preview für --env preview und die separate Live-Datei für --env live. Eine umgebungsspezifische .dev.vars-Datei ersetzt die generische Datei. Diese Dateien laden Secrets nicht automatisch zu Cloudflare hoch. Siehe lokale und bereitgestellte Secrets.
Ersetzen Sie den Handler. Das quotierte Here-Dokument bewahrt den JavaScript-Code unverändert. Ein fehlendes konfiguriertes Secret gibt 503 zurück; ein fehlendes oder falsches Anmeldeverfahren der Anfrage gibt 401 zurück. Vergleichen Sie den Authorization-Header auf dem Server, bevor Sie einen Erfolg zurückgeben. Protokolliert werden nur ein festgelegter Ereignisname, die öffentliche Umgebung und ein numerischer Status. Die akzeptierte Operation ist ein Dry Run ohne gespeicherte Nebenwirkung.
cat > src/index.js <<'JS'
export default {
async fetch(request, env) {
const path = new URL(request.url).pathname;
if (path === '/health' && request.method === 'GET') {
return Response.json({status: 'ok', environment: env.ENVIRONMENT, queue: env.QUEUE_LABEL});
}
if (path !== '/maintenance') return Response.json({error: 'not_found'}, {status: 404});
if (request.method !== 'POST') {
return Response.json({error: 'method_not_allowed'}, {status: 405, headers: {Allow: 'POST'}});
}
// Fail closed if this environment has no configured secret.
if (!env.MAINTENANCE_TOKEN) {
return Response.json({error: 'maintenance_unconfigured'}, {status: 503});
}
const authorized = request.headers.get('Authorization') === `Bearer ${env.MAINTENANCE_TOKEN}`;
const status = authorized ? 200 : 401;
console.log(JSON.stringify({event: 'maintenance', environment: env.ENVIRONMENT, status}));
if (!authorized) return Response.json({error: 'unauthorized'}, {status});
return Response.json({operation: 'dry-run', environment: env.ENVIRONMENT});
}
};
JS
npx wrangler dev --env preview --port 8080 > preview.log 2>&1 &
npx wrangler dev --env live --port 8081 --inspector-port 9230 > live.log 2>&1 &
cat preview.log
cat live.log
Nachdem beide Server ihre Bereitschaft melden, testen Sie die Zugriffsschranke. -X POST wählt die Methode aus, und -H übergibt den Bearer-Header. Verwenden Sie bei echten Zugangsdaten keine ausführliche curl-Ausgabe.
curl -i -X POST http://127.0.0.1:8080/maintenance
curl -i -X POST http://127.0.0.1:8080/maintenance -H "Authorization: Bearer incorrect-token"
curl -i -X POST http://127.0.0.1:8080/maintenance -H "Authorization: Bearer $LIVE_TOKEN"
curl -i -X POST http://127.0.0.1:8080/maintenance -H "Authorization: Bearer $PREVIEW_TOKEN"
curl -i -X POST http://127.0.0.1:8081/maintenance -H "Authorization: Bearer $LIVE_TOKEN"
curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8081/health
Die ersten drei Anfragen geben 401 unauthorized zurück. Das gilt auch für das ansonsten gültige Token der jeweils anderen Umgebung. Die nächsten beiden geben 200 mit operation: dry-run und der jeweiligen eigenen Umgebung zurück. Health bleibt öffentlich. Verwenden Sie die Verifizierung, um beide Richtungen der Token-Isolierung, die Methoden, die öffentliche Konfiguration und das Fehlen von Tokenwerten in den lokalen Logs zu prüfen.
Jede Umgebung deployen und ihr Secret hochladen
In diesem Schritt autorisieren Sie diese frische VM, deployen jede benannte Umgebung und laden ihr Secret ausdrücklich hoch. Beenden Sie zuerst die lokalen Jobs und verwenden Sie deren tatsächliche Nummern aus jobs.
jobs
kill %1 %2
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Verwenden Sie den angezeigten Link und den aktuellen Code in Ihrem angemeldeten Browser. Prüfen Sie Wranglers Berechtigungen und den erforderlichen Background Access, wählen Sie nur Ihr Lernkonto aus und autorisieren Sie den Zugriff wie in der Verbindungsübung gezeigt. Warten Sie, bis der Vorgang im Terminal abgeschlossen ist.
npx wrangler whoami --json
Bestätigen Sie loggedIn: true sowie den Kontonamen und die Konto-ID. Ersetzen Sie unten YOUR_ACCOUNT_ID durch diese tatsächliche ID. Behalten Sie den ursprünglichen Ressourcennamen bei.
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"account_id": "YOUR_ACCOUNT_ID",
"workers_dev": true,
"preview_urls": false,
"env": {
"preview": {"vars": {"ENVIRONMENT": "preview", "QUEUE_LABEL": "sandbox"}},
"live": {"vars": {"ENVIRONMENT": "live", "QUEUE_LABEL": "primary"}}
}
}
CONFIG
Geben Sie für dieses Projekt immer --env an. Andernfalls zielt Wrangler auf die unbenannte Umgebung der obersten Ebene. Diese ist nicht Teil des Deployment-Plans dieser Übung.
npx wrangler deploy --env preview
npx wrangler deploy --env live
Kopieren Sie die exakte workers.dev-Adresse aus der Ausgabe jedes Deployments. Verwenden Sie die vorhandene Subdomain des Lernkontos erneut. Wenn Sie Wrangler zum ersten Mal verwenden, folgen Sie der Aufforderung für eine verfügbare Subdomain, ohne eine bestehende Subdomain zu ändern.
PREVIEW_URL="https://YOUR_BASE-preview.YOUR_SUBDOMAIN.workers.dev"
LIVE_URL="https://YOUR_BASE-live.YOUR_SUBDOMAIN.workers.dev"
curl -i -X POST "$PREVIEW_URL/maintenance"
curl -i -X POST "$LIVE_URL/maintenance"
Beide Anfragen geben 503 maintenance_unconfigured zurück: Lokale Secret-Dateien wurden durch ein gewöhnliches Deployment nicht hochgeladen. Health ist unabhängig von der Wartungsautorisierung.
Verwenden Sie den standardmäßigen Bulk-Befehl, um die dotenv-Datei in die passende Umgebung hochzuladen. Auch ein einzelnes Secret kann mit dieser dateibasierten Operation hochgeladen werden. Die Ausgabe nennt den Namen des Secrets, nicht dessen Wert. Eine Secret-Aktualisierung erstellt sofort eine Version und deployt sie.
npx wrangler secret bulk .dev.vars.preview --env preview
npx wrangler secret bulk .dev.vars.live --env live
npx wrangler secret list --env preview
npx wrangler secret list --env live
Jede Liste sollte MAINTENANCE_TOKEN mit dem Typ secret_text enthalten. Vergleichen Sie die öffentlichen Werte und das Autorisierungsverhalten:
curl -i "$PREVIEW_URL/health"
curl -i "$LIVE_URL/health"
curl -i -X POST "$PREVIEW_URL/maintenance"
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer $LIVE_TOKEN"
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer $PREVIEW_TOKEN"
curl -i -X POST "$LIVE_URL/maintenance" -H "Authorization: Bearer $LIVE_TOKEN"
Health behält die Werte preview/sandbox und live/primary. Fehlende und umgebungsübergreifende Zugangsdaten geben 401 zurück; passende Tokens geben 200 zurück. Warten Sie bei Verbindungsfehlern auf die anfängliche Verbreitung des Hostnamens, bevor Sie die Anfrage wiederholen. Öffnen Sie im selben Dashboard-Konto Compute → Workers & Pages. Suchen Sie die beiden Worker mit den Endungen -preview und -live, und vergleichen Sie ihre vollständigen Namen und URLs mit der Deployment-Ausgabe. Jede benannte Wrangler-Umgebung besitzt in diesem Beispiel einen eigenen bereitgestellten Worker. Erstellen Sie im Dashboard keine weitere Anwendung.
Öffnen Sie Ihren -preview-Worker und wählen Sie Settings. Vergleichen Sie unter Runtime variables and secrets (im Abschnitt Variables and secrets) die Spalten Type, Name und Value. ENVIRONMENT sollte preview und QUEUE_LABEL sollte sandbox sein. MAINTENANCE_TOKEN sollte den Typ Secret haben; unter Value sollte Value encrypted statt eines lesbaren Werts angezeigt werden.
Gehen Sie zurück zu Workers & Pages, öffnen Sie Ihren -live-Worker und prüfen Sie denselben Abschnitt. Seine öffentlichen Werte sollten live und primary sein, während sein unabhängig hochgeladenes Secret denselben Binding-Namen verwendet. Prüfen Sie den Worker-Namen in der Breadcrumb-Navigation oben, bevor Sie die Tabelle vergleichen.
Der zufällige Namenssuffix und die Subdomain in diesen Bildern sind Beispielwerte. Die verschlüsselte Anzeige bestätigt das Vorhandensein und den Typ des Secret-Bindings, nicht, dass die beiden Umgebungen unterschiedliche Secret-Werte besitzen. Das Verhalten wird durch die obigen HTTP-Prüfungen mit passenden und umgebungsübergreifenden Tokens bestätigt. Lassen Sie diesen Kontrollpunkt schreibgeschützt: Bearbeiten Sie im Dashboard keine Variablen und zeigen, ersetzen oder kopieren Sie dort keine Zugangsdaten. Verwenden Sie die Verifizierung. Sie prüft den tatsächlichen Besitz, die bereitgestellten Binding-Typen und das öffentliche Verhalten beider Umgebungen.
Anwendungslogs prüfen, ohne Secrets offenzulegen
In diesem Schritt prüfen Sie im bereitgestellten Preview-Worker eine abgelehnte und eine akzeptierte Anfrage. Anwendungslogs sollen das Ergebnis erklären, ohne Zugangsdaten oder Request-Header zu kopieren.
Starten Sie einen Log-Stream mit dem zuvor gezeigten tail-Befehl. Die formatierte Ausgabe zeigt Anwendungsnachrichten an. Speichern Sie sie, damit Sie den begrenzten Test nach dem Beenden des Streams prüfen können.
npx wrangler tail --env preview --format pretty > preview-tail.log 2>&1 &
cat preview-tail.log
Warten Sie, bis der Stream seine Verbindung meldet. Wiederholen Sie cat, während die Verbindung hergestellt wird. Senden Sie anschließend neue simulierte Anfragen:
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer incorrect-token"
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer $PREVIEW_TOKEN"
Verwenden Sie grep, um nur Zeilen mit dem festgelegten Anwendungsereignisnamen anzuzeigen:
grep 'maintenance' preview-tail.log
Warten Sie auf Ereignisse mit den Statuswerten 401 und 200. Die öffentliche Umgebung ist jeweils preview. In keiner der beiden Nachrichten darf ein Tokenwert enthalten sein. Die Zustellung von Ereignissen kann hinter der HTTP-Antwort zurückbleiben. Wiederholen Sie grep bis zu einer Minute lang. Wenn ein Ereignis fehlt, prüfen Sie den passenden console.log im Quellcode.
jobs
kill %1
Beenden Sie den tatsächlichen Tail-Job, sobald beide Ereignisse vorhanden sind. Das Beispiel geht davon aus, dass es Job 1 ist. Verwenden Sie die Verifizierung, um das aufgezeichnete Log zu prüfen und die Autorisierungsverträge der Remote-Umgebung unabhängig erneut zu testen. Damit werden nur simulierte Anfragen ausgeführt. Die Prüfung bestätigt nicht die Sicherheit beliebiger zukünftiger Änderungen an der Protokollierung.
Beide Umgebungs-Deployments entfernen
In diesem Schritt löschen Sie beide kurzlebigen Umgebungs-Worker, solange Sie noch autorisiert sind. Bestätigen Sie den Basisnamen und das Lernkonto in der Konfiguration:
cat wrangler.jsonc
Löschen Sie nur die Preview- und Live-Deployments dieser Übung. Prüfen Sie bei jeder Abfrage den exakten Namen <base>-preview oder <base>-live und drücken Sie die einzelne Taste y.
npx wrangler delete --env preview
npx wrangler delete --env live
Durch das Löschen dieser Worker werden auch die zugehörigen Secret-Bindings entfernt. Wrangler 4.131.1 meldet danach möglicherweise den bereits dokumentierten Authentifizierungsfehler für das veraltete Workers-Sites-KV. Erweitern Sie deshalb nicht die Berechtigungen und interpretieren Sie diesen Fehler nicht als Nachweis für die Löschung. Aktualisieren Sie Workers & Pages und verwenden Sie die Verifizierung: Ein erfolgreich autorisiertes Inventar muss zeigen, dass beide Namen fehlen. Ein Authentifizierungs- oder Netzwerkfehler ist nicht aussagekräftig. Lassen Sie andere Worker, Ihr Lernkonto und dessen vorhandene Subdomain unverändert.
Lokale Secrets entfernen und Verbindung trennen
In diesem Schritt entfernen Sie nach der bestätigten Cloud-Bereinigung die lokalen Kopien der Secrets und trennen anschließend die VM. rm entfernt nur die beiden unten genannten Dateien, und unset entfernt die beiden temporären Shell-Variablen.
rm .dev.vars.preview .dev.vars.live
unset PREVIEW_TOKEN LIVE_TOKEN
npx wrangler logout
npx wrangler whoami --json
Erwarten Sie ausdrücklich "loggedIn": false. Der nicht erfolgreiche Exit-Status des nicht authentifizierten Befehls ist normal, wenn dieses strukturierte Ergebnis vorhanden ist. Verwenden Sie die Verifizierung und beenden Sie anschließend die VM. Die Browser-Anmeldung ist davon unabhängig und kann für die nächste Übung bestehen bleiben. Weder das Abmelden noch das Beenden der VM ersetzt das vorherige Löschen der Cloud-Ressourcen.
Zusammenfassung
Sie haben die öffentliche Konfiguration nach Wrangler-Umgebung getrennt, umgebungsspezifische lokale Secrets geladen, verschlüsselte Secret-Bindings hochgeladen und passende, fehlende sowie umgebungsübergreifende Zugangsdaten geprüft. Die öffentliche Health-Route behielt ihre Umgebungsidentität bei, während der Server eine Wartungsroute im Dry-Run-Modus schützte. Sie haben begrenzte Anwendungslogs geprüft, ohne Tokens auszugeben, und anschließend die Löschung verifiziert, bevor Sie lokale Zugangsdaten entfernten und sich abmeldeten.
Dieselbe sorgfältige Konfiguration hilft Ihnen später in diesem Kurs, Abweichungen in Preview-Konfigurationen zu diagnostizieren.
