Einführung
Ein Health-Endpunkt ist eine kleine URL, die Ihnen mitteilt, dass eine Anwendung antwortet. In diesem Lab schreiben Sie einen JavaScript-Cloudflare-Worker, testen seine JSON-Antwort in LabEx, veröffentlichen denselben Code unter einer öffentlichen workers.dev-URL, prüfen ein Anforderungsprotokoll und entfernen anschließend die Testbereitstellung.
Verwenden Sie Ihr eigenes Lernkonto mit verifizierter E-Mail-Adresse und Workers Free, das Sie in Prepare Your Cloudflare Learning Account eingerichtet haben. Sie sollten den Ablauf der Geräteautorisierung aus Connect LabEx to Your Cloudflare Account kennen und über grundlegende JavaScript-Kenntnisse verfügen. Diese neue VM benötigt eine eigene Autorisierung, einschließlich der Berechtigung zum Bereitstellen und Löschen von Workern. Eine gekaufte Domain, eine Datenbank oder ein kostenpflichtiges Upgrade sind nicht erforderlich. Ihre Testantwort ist öffentlich und enthält nur Beispieldaten.
Das Setup hat Node.js 22.22.0 und das projektspezifische Wrangler 4.131.1 in /home/labex/project/first-worker installiert. Sie prüfen Kontoinformationen mit Wrangler und testen Antworten mit curl; diese Werkzeuge funktionieren auch außerhalb von LabEx. Den Worker und die Konfiguration schreiben Sie selbst und führen die standardmäßigen Wrangler-Befehle aus. Lassen Sie diese VM geöffnet, bis das Löschen und die Abmeldung bestätigt wurden.
Einen Health-Worker schreiben
In diesem Schritt erstellen Sie den JavaScript-Einstiegspunkt und legen fest, wie Wrangler ihn ausführt. Ein Worker exportiert einen fetch-Handler: Cloudflare ruft ihn für eine eingehende HTTP-Anforderung auf, und die zurückgegebene Response wird zur HTTP-Antwort. Dieser erste Worker gibt für jeden Pfad dieselbe Health-Nachricht zurück. Das Routing behandeln Sie im nächsten Lab.
Wechseln Sie in das vorbereitete Projekt und prüfen Sie die CLI-Version:
cd /home/labex/project/first-worker
npx wrangler --version
Die Version sollte 4.131.1 sein. Wrangler ist eine Projektabhängigkeit. Führen Sie die Befehle deshalb aus diesem Verzeichnis aus. Installieren Sie auf Ihrem eigenen Computer die festgelegten Abhängigkeiten eines Projekts mit npm ci, wenn eine Lockdatei vorhanden ist.
Der nächste Befehl verwendet ein Here-Dokument: cat schreibt die Zeilen zwischen <<'WORKER' und WORKER in src/index.js. Das Zeichen > ersetzt den Inhalt dieser Datei. Durch die Anführungszeichen um den Begrenzungswert bleibt der JavaScript-Text von der Shell unverändert. Fügen Sie den vollständigen Block einschließlich des abschließenden Begrenzungswerts ein.
cat > src/index.js <<'WORKER'
export default {
async fetch(request) {
console.log("health-request", request.method, new URL(request.url).pathname);
return Response.json({ service: "labex-first-worker", status: "ok" });
},
};
WORKER
Response.json erstellt eine JSON-Antwort mit dem Status 200 und dem Content-Type für JSON. Die Konsolennachricht protokolliert Methode und Pfad, aber keine Header oder Zugangsdaten.
Erzeugen Sie einen eindeutigen Namen, damit kein vorhandener Worker überschrieben wird. Das integrierte Crypto-Modul von Node.js erzeugt sechs zufällige Bytes und formatiert sie als zwölf Hexadezimalzeichen. $(...) übernimmt diesen Text in eine Shell-Variable:
WORKER_NAME="labex-first-$(node -p "require('node:crypto').randomBytes(6).toString('hex')")"
Erstellen Sie die Konfiguration. Der Begrenzungswert ist diesmal nicht in Anführungszeichen gesetzt, sodass $WORKER_NAME in den eindeutigen Wert aufgelöst wird:
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false
}
CONFIG
main gibt Ihre JavaScript-Datei an. compatibility_date legt das Kompatibilitätsverhalten der Laufzeit fest; es ist nicht der Zeitpunkt der Bereitstellung. workers_dev aktiviert eine öffentliche Test-URL, während preview_urls zusätzliche Vorschau-URLs für Versionen deaktiviert. JSON ohne Kommentare ist gültiges JSONC. Verwenden Sie in diesem Lab das gezeigte Format.
cat wrangler.jsonc
Bestätigen Sie, dass der Name mit labex-first- beginnt und ein eindeutiges Suffix enthält. Verwenden Sie diesen Namen im gesamten Lab: Die Bereitstellung und das Löschen beziehen sich auf ihn. Die Account-ID fügen Sie nach der Autorisierung hinzu.
Verwenden Sie die Verifizierungsschaltfläche dieses Schritts, um Konfiguration und Handler zu prüfen. Im nächsten Schritt beobachten Sie die Antwort selbst über die lokale Laufzeit.
Den Worker lokal ausführen und testen
In diesem Schritt führen Sie den Worker in der VM aus, bevor Sie ihn veröffentlichen. Die lokale Laufzeit von Wrangler führt Ihren Handler aus, ohne eine Cloud-Bereitstellung zu erstellen.
Starten Sie den Entwicklungsserver im Hintergrund, damit dasselbe Terminal HTTP-Anforderungen senden kann. --ip 0.0.0.0 macht den VM-Dienst für die Weboberfläche von LabEx verfügbar, und --port 8080 legt seinen Port fest. > local.log speichert die Standardausgabe, 2>&1 leitet Fehler in dieselbe Datei um, und & gibt die Eingabeaufforderung zurück, während der Server läuft.
npx wrangler dev --ip 0.0.0.0 --port 8080 > local.log 2>&1 &
cat local.log
Warten Sie, bis das Protokoll meldet, dass der Server auf Port 8080 bereit ist. Wenn der Start noch läuft, wiederholen Sie cat local.log, bevor Sie fortfahren. Lassen Sie den Server bis zum Ende dieses Schritts laufen.
Verwenden Sie curl, um eine Anforderung zu senden. -i fügt die Antwort-Header ein, sodass Sie Status und Content-Type prüfen können:
curl -i http://127.0.0.1:8080/health
Die Antwort enthält diese stabilen Werte. Reihenfolge und Groß-/Kleinschreibung der Header können abweichen:
HTTP/1.1 200 OK
Content-Type: application/json
...
{"service":"labex-first-worker","status":"ok"}
Die Adresse 127.0.0.1 verweist auf diese VM. Sie verweist weder auf Ihren Computer noch auf eine öffentliche Cloudflare-Bereitstellung. Prüfen Sie vor dem Fortfahren den HTTP-Status, den JSON-Content-Type und beide Antwortfelder.
Führen Sie die Verifizierung dieses Schritts durch, solange der Entwicklungsserver noch läuft.
Bei Cloudflare autorisieren und bereitstellen
In diesem Schritt verbinden Sie diese VM mit Ihrem Lernkonto und stellen den getesteten Worker bereit. Prüfen Sie zunächst den Hintergrundprozess. jobs listet die in diesem Terminal gestarteten Jobs auf. Der Eintrag sollte wrangler dev anzeigen.
jobs
Beenden Sie diesen Job mit kill %1. %1 bezeichnet dabei Job 1 in diesem Terminal, nicht die Prozess-ID eines Systemprozesses. Wenn jobs für wrangler dev eine andere Nummer anzeigt, verwenden Sie diese Nummer. Der Befehl sendet ein Beendigungssignal an den Job.
kill %1
Starten Sie die Geräteautorisierung. Die Lese-Bereiche identifizieren Ihr Konto; workers_scripts:write erlaubt das Bereitstellen und Löschen von Skripten, und workers_tail:read erlaubt das Anzeigen von Live-Protokollen. --browser=false gibt den Link aus, den Sie in Ihrem eigenen Browser öffnen.
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Öffnen Sie den angezeigten Link, melden Sie sich bei Aufforderung bei Cloudflare an, geben Sie den aktuellen Gerätecode ein und prüfen Sie die von Wrangler angeforderten Berechtigungen. Wählen Sie Ihr Lernkonto aus, nicht alle Konten. Die Zustimmungsseite enthält außerdem den erforderlichen Background Access. Prüfen Sie Anwendung, Konto und Berechtigungen, bevor Sie zustimmen. Kehren Sie anschließend zum Terminal zurück und warten Sie, bis die Autorisierung abgeschlossen ist. Wenn ein Code abläuft, führen Sie den Login-Befehl erneut aus, um einen neuen Code zu erhalten. Fügen Sie keine Token in das Terminal ein und geben Sie keine Anmeldedateien weiter.
Erweitern Sie Account & Billing und Developer Platform, um die unten gezeigten Berechtigungsnamen zu prüfen. Diese Berechtigungen sind umfassender als bei der schreibgeschützten Verbindungslektion, weil dieses Lab einen Worker bereitstellt und seine Live-Protokolle öffnet.
Bestätigen Sie, dass Ihr Lernkonto ausgewählt ist. Verwenden Sie Edit, wenn das falsche Konto oder alle Konten ausgewählt sind. Prüfen Sie Ihre Auswahl, bevor Sie auf Authorize klicken.
Prüfen Sie, welche Konten für diesen Login verfügbar sind:
npx wrangler whoami --json
Bestätigen Sie "loggedIn": true und "authType": "OAuth Token". Suchen Sie im Array accounts das Objekt mit dem name Ihres Lernkontos und kopieren Sie dessen 32 Zeichen lange id. Andere Kontoeinstellungen werden für dieses Lab nicht benötigt. Wenn nur ein Konto angezeigt wird, bestätigen Sie trotzdem seinen Namen. Wenn mehrere Konten angezeigt werden, verwenden Sie das Dashboard, um sie zu unterscheiden. Fehlt Ihr Konto, wiederholen Sie die Autorisierung mit dem gewünschten Konto.
Fügen Sie account_id zu Ihrer Konfiguration hinzu. Ersetzen Sie in diesem Block YOUR_ACCOUNT_ID durch die kopierte ID, bevor Sie ihn ausführen. Dadurch wird die Konfiguration neu geschrieben, während die Variable $WORKER_NAME aus Schritt 1 erhalten bleibt. Lassen Sie dieses Terminal geöffnet. Wenn die Variable verloren gegangen ist, lesen Sie den ursprünglichen Namen mit cat wrangler.jsonc aus und setzen Sie WORKER_NAME zuerst wieder auf genau diesen Namen. Erzeugen Sie keinen neuen Namen und wechseln Sie nach der Bereitstellung nicht das Konto.
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false,
"account_id": "YOUR_ACCOUNT_ID"
}
CONFIG
cat wrangler.jsonc
Prüfen Sie den eindeutigen Workernamen und vergleichen Sie account_id mit dem Objekt des gewünschten Kontos aus whoami --json. Diese ID ist eine Konfiguration und kein Passwort. Wrangler liest sie beim Bereitstellen und Löschen aus. Veröffentlichen Sie nun den lokalen Quellcode:
npx wrangler deploy
Wenn für dieses Konto noch keine workers.dev-Subdomain existiert, fragt Wrangler, ob eine registriert werden soll. Antworten Sie mit yes, wählen Sie einen verfügbaren Namen in Kleinbuchstaben mit Buchstaben, Zahlen und Bindestrichen und bestätigen Sie ihn. Dieser kontoweite Name wird von Ihren künftigen Workern gemeinsam verwendet und unterscheidet sich vom eindeutigen Workernamen dieses Labs. Wenn bereits eine Subdomain vorhanden ist, verwenden Sie sie erneut. Benennen Sie sie nicht um. Eine eigene Domain oder ein Tarif-Upgrade ist nicht erforderlich.
Warten Sie, bis die Bereitstellung abgeschlossen ist. Wrangler gibt eine URL in dieser Struktur aus:
https://<your-worker-name>.<your-subdomain>.workers.dev
Kopieren Sie die tatsächlich von Ihrer Bereitstellung ausgegebene URL in eine Shell-Variable. Ersetzen Sie die gesamte Beispiel-URL unten, lassen Sie die Anführungszeichen stehen und lassen Sie den abschließenden Schrägstrich weg:
WORKER_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$WORKER_URL/health"
Erwarten Sie HTTP 200 und dieselbe JSON-Antwort wie beim lokalen Test. Wenn der neue Hostname noch nicht überall verfügbar ist, warten Sie kurz und versuchen Sie es erneut. Eine Fehlerseite ist keine erfolgreiche Bereitstellung. Sie können die tatsächliche /health-URL auch in Ihrem Browser öffnen. Wenn Ihr Browser oder Netzwerk workers.dev blockiert, verwenden Sie das curl-Ergebnis der VM. Deaktivieren Sie keine Browsersicherheitseinstellungen. Die VM-Anforderung und die folgende unabhängige Prüfung sind die erforderlichen Antworttests.
Bestätigen Sie dieselbe Bereitstellung nun visuell im Cloudflare Dashboard. Lassen Sie Ihr Terminal geöffnet.
Wählen Sie im Kontowechsler Ihr Lernkonto aus. Seine Identität muss mit dem oben ausgewählten Konto übereinstimmen.
Öffnen Sie Compute → Workers & Pages. Aktualisieren Sie bei Bedarf die Anwendungsliste und suchen Sie den exakten labex-first-...-Namen aus Ihrer Konfiguration. Wenn viele Anwendungen vorhanden sind, suchen Sie nach diesem vollständigen Namen.
Öffnen Sie diesen Worker. Bestätigen Sie seinen Namen und suchen Sie seine workers.dev-Adresse. Vergleichen Sie die Adresse mit der von wrangler deploy ausgegebenen URL.
Die Screenshots zeigen eine beispielhafte Bereitstellung. Ihr zufälliges Worker-Suffix und die Subdomain Ihres Kontos unterscheiden sich davon. Suchen Sie Ihre eigenen Werte, statt das Beispiel zu kopieren. Das Dashboard ist eine weitere Ansicht der Ressource, die Sie im Terminal erstellt haben. Erstellen Sie hier keinen zweiten Worker und bearbeiten Sie seinen Code nicht. Wenn der Worker fehlt, prüfen Sie zuerst das ausgewählte Konto, den exakten Namen und ob der Bereitstellungsbefehl abgeschlossen wurde.
Die Anwendungsliste bestätigt, dass eine Cloud-Ressource vorhanden ist. Die mit curl getestete HTTP-Antwort bestätigt, dass ihr Code funktioniert. Sie müssen keinen eigenen Screenshot erstellen oder einreichen.
Verwenden Sie die Verifizierungsschaltfläche dieses Schritts. Die unabhängige Backend-Prüfung liest die Workereinstellungen im ausgewählten Konto und testet den öffentlichen Endpunkt. Eine andere Website, die einen ähnlichen Text zurückgibt, reicht daher nicht aus.
Ein Live-Anforderungsprotokoll beobachten
In diesem Schritt verbinden Sie einen Live-Protokollstrom und suchen die von Ihrem Handler erzeugte Nachricht. Ein Protokollstrom zeigt nur Anforderungen, die während der bestehenden Verbindung eingehen. Frühere Anforderungen werden nicht erneut ausgegeben.
Starten Sie Wrangler tail im Hintergrund. --format json erzeugt strukturierte Ereignisse. Diesmal werden Standardausgabe und Fehler in getrennte Dateien geschrieben, damit Diagnose-Text nicht in den Ereignisdaten erscheint:
npx wrangler tail --format json > requests.json 2> tail-errors.log &
Warten Sie einige Sekunden, bis die Verbindung initialisiert ist, und senden Sie dann eine neue Anforderung:
curl -i "$WORKER_URL/health"
Die Ereignisdatei enthält außerdem umfangreiche Anforderungsmetadaten. head -n 32 zeigt die ersten 32 Zeilen an, damit Sie sich auf das erste Ereignis und die Anwendungsmeldung konzentrieren können:
head -n 32 requests.json
Suchen Sie nach einem Ereignis mit outcome gleich ok, einer GET-Anforderung, die mit /health endet, und einer Konsolenmeldung mit health-request. Andere Felder, Zeitstempel und Anforderungs-Header können abweichen. Wenn die Datei leer ist, prüfen Sie tail-errors.log, warten Sie auf die Verbindung, senden Sie die Anforderung erneut und lesen Sie die Datei nochmals ein.
Beenden Sie tail, bevor Sie die vollständig gespeicherten Ereignisse verifizieren. Prüfen Sie jobs und verwenden Sie die für wrangler tail angezeigte Nummer, normalerweise 1, nachdem der vorherige Job beendet wurde:
jobs
kill %1
Verwenden Sie die Verifizierungsschaltfläche dieses Schritts, um das aufgezeichnete Ereignis mit dem bereitgestellten Worker abzugleichen.
Die Datei kann Anforderungsmetadaten enthalten. Bewahren Sie sie in dieser VM auf. Veröffentlichen Sie sie nicht als Screenshot und senden Sie sie nicht an ein öffentliches Repository.
Den Test-Worker löschen
In diesem Schritt entfernen Sie nur den Test-Worker und bestätigen das Ergebnis, solange Ihre Verwaltungsautorisierung noch aktiv ist. Das Löschen einer VM würde einen bereitgestellten Worker nicht löschen.
Prüfen Sie die Projektkonfiguration erneut und bestätigen Sie, dass name der eindeutige, in diesem Lab verwendete Name labex-first-... ist:
cat wrangler.jsonc
Löschen Sie diesen Worker mithilfe der Projektkonfiguration:
npx wrangler delete
Lesen Sie die Bestätigungsaufforderung, prüfen Sie den exakten Namen und drücken Sie zur Bestätigung y. Verwenden Sie keine erzwungene Löschung und löschen Sie kein anderes Projekt. Wrangler meldet normalerweise, dass der Worker gelöscht wurde. Bei der festgelegten Version und diesen eingeschränkten Berechtigungen kann stattdessen nach dem Löschen des Workers ein Authentifizierungsfehler für /storage/kv/namespaces erscheinen: Wrangler prüft bei der Bereinigung auch den Speicher der älteren Workers Sites. Dieses Lab erstellt keine KV-Namespaces. Erteilen Sie nicht alle vorgeschlagenen Berechtigungen und wiederholen Sie nicht die Bereitstellung, um diese Diagnose zu beheben. Verwenden Sie die Verifizierungsschaltfläche dieses Schritts, um festzustellen, ob der Worker tatsächlich verschwunden ist. Jeder andere Fehler muss untersucht werden.
Öffnen Sie im Cloudflare Dashboard in Ihrem Lernkonto Workers & Pages und aktualisieren Sie die Liste. Bestätigen Sie, dass Ihr exakter Workername nicht vorhanden ist. Verwenden Sie anschließend die Verifizierungsschaltfläche dieses Schritts für eine unabhängige API-Prüfung.
Die Prüfung erfordert eine erfolgreiche authentifizierte Inventarantwort. Eine fehlgeschlagene Netzwerkanforderung oder ein abgelaufener Login gilt nicht als Löschung. Ihr Lernkonto und seine kontoweite workers.dev-Subdomain bleiben für spätere Labs verfügbar. Führen Sie die Verifizierung dieses Schritts vor der Abmeldung durch.
Die VM trennen
In diesem Schritt entfernen Sie die gespeicherte Autorisierung von Wrangler, nachdem die Bereinigung in der Cloud überprüft wurde. Lokale Quelldateien bleiben in der VM erhalten, autorisieren aber keinen Zugriff auf Ihr Konto mehr.
npx wrangler logout
npx wrangler whoami --json
Suchen Sie nach "loggedIn": false. Diese Wrangler-Version beendet sich im abgemeldeten Zustand mit einem Status ungleich null. Das ist erwartetes Verhalten. Ein Netzwerkfehler ohne diesen ausdrücklichen Status ist kein Beleg für eine Abmeldung. Verwenden Sie die Verifizierungsschaltfläche dieses Schritts zur unabhängigen Bestätigung.
Sie können im Cloudflare Dashboard in Ihrem Browser angemeldet bleiben. Die Browseranmeldung und die Wrangler-Autorisierung dieser VM sind voneinander getrennt. Ein späteres Lab beginnt mit einer neuen VM und fordert eine eigene Autorisierung an.
Zusammenfassung
Sie haben einen Worker-fetch-Handler und eine Konfiguration geschrieben, seine JSON-Antwort lokal getestet, ihn in Ihrem eigenen Lernkonto bereitgestellt und ein Live-Anforderungsprotokoll geprüft. Sie haben die öffentliche Antwort und die Ressourcenzugehörigkeit unabhängig bestätigt, den Test-Worker während bestehender Autorisierung gelöscht und sich von der VM abgemeldet.
Weitere Informationen finden Sie in Cloudflares Wrangler commands, zum fetch handler und zur workers.dev configuration.
