Einführung
Ein Feature-Flag ist eine Einstellung, mit der Sie eine Funktion ein- oder ausschalten können, ohne den Anwendungscode zu ändern. Stellen Sie sich vor, Sie bereiten ein neues Ankündigungsbanner vor: Sie möchten es in Ihrer Übungsumgebung testen, während es in der öffentlichen Version deaktiviert bleibt. Workers KV speichert kleine Werte unter Namen, die Schlüssel genannt werden. Ein Worker kann einen Schlüssel wie banner:new lesen, wenn er entscheiden muss, welche Antwort er senden soll. Das eignet sich für Einstellungen, die häufig gelesen und nur gelegentlich geändert werden.
Bevor Sie diesen Kurs beginnen, absolvieren Sie LabEx mit Ihrem Cloudflare-Konto verbinden. Dort werden das Terminal der LabEx-VM, die Geräteautorisierung, die Kontobestätigung und account_id erklärt. Wenn Sie direkt in diesen Kurs eingestiegen sind, absolvieren Sie zuerst dieses Lab. Sie sollten außerdem wissen, wie Sie einen kleinen JavaScript-Worker schreiben und ihn mit Wrangler aus dem Kurs für Cloudflare-Workers-Einsteiger bereitstellen. Ein Worker führt Ihren Code zur Verarbeitung von Anfragen auf Cloudflare aus, ohne dass Sie einen Server verwalten müssen.
Hier erstellen Sie einen Namespace, also einen benannten Container, der eine Sammlung von Schlüsseln von anderen Sammlungen trennt. Über ein Binding verbinden Sie ihn mit einem Worker. Das Binding ist der konfigurierte Name, über den Ihr Code auf diese Ressource zugreift. Sie üben lokale und Cloud-Operationen, veröffentlichen einen schreibgeschützten Banner-Endpunkt und löschen anschließend die nur für dieses Lab erstellten Ressourcen.
Verwenden Sie Ihr eigenes Lernkonto. Diese neue VM benötigt eine eigene Anmeldung mit Berechtigungen für Workers und KV. Die Übung verwendet einen Worker, einen Namespace und einige künstliche Werte innerhalb der kostenlosen KV-Kontingente; für diese kleine Übung benötigen Sie weder eine gekaufte Domain noch ein kostenpflichtiges Upgrade. Vorhandene Nutzung Ihres Kontos wird weiterhin auf das Kontingent angerechnet. Der öffentliche Endpunkt enthält keine privaten Informationen.
Die Einrichtung installiert Node.js 22.22.0 sowie Wrangler 4.131.1 lokal im Projekt unter /home/labex/project/feature-flags. Sie legt die Versionen der direkten Abhängigkeiten fest und führt npm install aus. Sie müssen die Werkzeuge nicht erneut installieren. Lassen Sie die VM geöffnet, bis die Löschung in der Cloud und die Abmeldung überprüft wurden.
Einen eigenen Flag-Namespace verbinden
In diesem Schritt geben Sie diesem Lab eigene Ressourcennamen und verbinden einen Cloud-Namespace mit Ihrem Projekt. Ein separater Namespace verhindert, dass sich Übungsschlüssel mit den Schlüsseln einer bestehenden Anwendung vermischen.
Wechseln Sie in das vorbereitete Projekt:
cd /home/labex/project/feature-flags
Generieren Sie einmalig einen eindeutigen Namen. openssl rand -hex 6 gibt ein zufälliges Suffix aus; $(...) fügt dieses in den Namen ein. Die Shell-Variable stellt den Namen für die folgenden Befehle in diesem Terminal bereit.
WORKER_NAME="labex-flags-$(openssl rand -hex 6)"
printf '%s\n' "$WORKER_NAME"
Autorisieren Sie diese VM. Neben dem Lesen Ihrer Kontoidentität ermöglichen Workers Scripts Write die Bereitstellung und Löschung sowie Workers KV Write die Verwaltung des Namespace und der Schlüssel dieses Labs.
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_kv:write
Öffnen Sie den angezeigten Geräte-Link in Ihrem Browser, geben Sie den aktuellen Code ein, überprüfen Sie die angeforderten Berechtigungen und das Lernkonto und autorisieren Sie Wrangler. Auf der Zustimmungsseite kann außerdem Zugriff im Hintergrund angezeigt werden. Kehren Sie zum Terminal zurück und warten Sie, bis die Anmeldung abgeschlossen ist.
Klappen Sie auf der Zustimmungsseite Developer Platform auf und vergleichen Sie die angeforderten Berechtigungen mit diesem Beispiel. Beide Schreibberechtigungen werden für dieses Lab benötigt; sie decken die Ressourcenverwaltung ab und nicht nur das Lesen eines Flags.
npx wrangler whoami --json
Bestätigen Sie loggedIn: true und den name des Lernkontos, auch wenn nur ein Konto aufgelistet ist. Kopieren Sie die id dieses Kontos. Tragen Sie sie in der folgenden Konfiguration ein und ersetzen Sie YOUR_ACCOUNT_ID, bevor Sie den Befehl ausführen. Das Here-Dokument von cat schreibt alles zwischen den beiden JSON-Zeilen in eine Datei; > ersetzt die Datei. Der nicht maskierte Trenner ermöglicht es der Shell, $WORKER_NAME einzusetzen.
cat > wrangler.jsonc <<JSON
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"account_id": "YOUR_ACCOUNT_ID",
"workers_dev": true
}
JSON
Erstellen Sie in diesem Konto einen Namespace. Sein Titel enthält denselben eindeutigen Namen wie der Worker, damit Sie beide später einander zuordnen können. --update-config=false sorgt dafür, dass Sie das Binding selbst eintragen, anstatt die Datei automatisch ändern zu lassen.
npx wrangler kv namespace create "$WORKER_NAME-flags" --update-config=false
Die Ausgabe enthält die ID des neuen Namespace. Kopieren Sie sie und ersetzen Sie anschließend YOUR_ACCOUNT_ID und YOUR_NAMESPACE_ID in dieser vollständigen Konfiguration. Der Binding-Name FLAGS wird für Ihren Code gewählt; die ID identifiziert die tatsächliche Cloudflare-Ressource.
cat > wrangler.jsonc <<JSON
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"account_id": "YOUR_ACCOUNT_ID",
"workers_dev": true,
"kv_namespaces": [
{ "binding": "FLAGS", "id": "YOUR_NAMESPACE_ID" }
]
}
JSON
npx wrangler kv namespace list
Suchen Sie den Titel des Namespace dieses Labs und vergleichen Sie seine ID mit der ID in der Datei. Andere Namespaces können vorhanden sein; lassen Sie diese unverändert. Diese Konfiguration legt fest, welches Konto und welche Ressource die folgenden Befehle verwenden sollen. Ein Binding ist eine Referenz auf einen Namespace, keine Kopie seiner Daten.
Lokale und entfernte Flags getrennt halten
In diesem Schritt speichern Sie unterschiedliche Werte unter demselben Schlüssel und weisen nach, dass lokale Änderungen die Daten in der Cloud nicht verändern. Lokal bedeutet: Der Speicher befindet sich innerhalb dieser LabEx-VM. Entfernt bedeutet: Der Namespace in Ihrem Cloudflare-Konto. Wrangler verwendet das Binding, um den Speicher zu bestimmen; die ausdrückliche Option --local oder --remote legt fest, wo die Operation ausgeführt wird.
Deaktivieren Sie zunächst die öffentliche Funktion:
npx wrangler kv key put banner:new disabled --binding FLAGS --remote
Aktivieren Sie dieselbe Funktion im lokalen Speicher der VM:
npx wrangler kv key put banner:new enabled --binding FLAGS --local
Lesen Sie beide Werte. put schreibt einen Schlüssel, und get ruft seinen Wert ab. Der Doppelpunkt in banner:new ist eine Namenskonvention zur Gruppierung zusammengehöriger Schlüssel; er erstellt kein Verzeichnis.
Mit --text wird der gespeicherte Wert als UTF-8 dekodiert und in einer eigenen Zeile angezeigt.
npx wrangler kv key get banner:new --binding FLAGS --local --text
Erwarten Sie enabled.
npx wrangler kv key get banner:new --binding FLAGS --remote --text
Erwarten Sie disabled. Falls Sie den entfernten Wert versehentlich geändert haben, wiederholen Sie den zugehörigen put-Befehl mit disabled und lesen Sie den Wert anschließend erneut. Leiten Sie das Ziel nicht allein aus dem Projektordner ab.
Üben Sie nun das Entfernen eines nicht mehr verwendeten Flags. Diese Befehle wirken ausschließlich auf den nur für dieses Lab erstellten entfernten Namespace, der an FLAGS gebunden ist.
npx wrangler kv key put banner:old retired --binding FLAGS --remote
npx wrangler kv key list --binding FLAGS --remote
Die Liste enthält Namen wie banner:new und banner:old, nicht die darin gespeicherten Werte. Verwenden Sie get, wenn Sie einen Wert benötigen.
npx wrangler kv key delete banner:old --binding FLAGS --remote
npx wrangler kv key list --binding FLAGS --remote
npx wrangler kv key list --binding FLAGS --local
Beide Listen sollten jetzt nur noch banner:new enthalten. Lesen Sie die beiden Werte erneut, wenn Sie bestätigen möchten, dass sie weiterhin unterschiedlich sind. Beim Löschen eines Schlüssels wird ein Eintrag entfernt; beim späteren Löschen eines Namespace wird der gesamte Container entfernt.
KV ist eventuell konsistent: Es kann einige Zeit dauern, bis eine Änderung an anderen Orten in Lesevorgängen sichtbar wird. Ein Worker kann vorübergehend noch einen älteren Wert sehen, einschließlich eines zuvor fehlenden Schlüssels. Überschreiben Sie einen Wert nicht wiederholt, um sein Erscheinen zu erzwingen. Diese unkritischen Anzeige-Flags tolerieren die Verzögerung; für eine sofortige Entscheidung zum Entzug eines Zugriffs wären sie ungeeignet. In einem späteren Lab untersuchen Sie dieses Verhalten genauer. Weitere Informationen zum Speichermodell finden Sie unter Funktionsweise von KV.
Ein Flag aus einem lokalen Worker lesen
In diesem Schritt machen Sie das Verhalten der Anwendung von der gespeicherten Einstellung abhängig. Der Worker liest env.FLAGS, wobei env die konfigurierten Ressourcenbindungen enthält. get() arbeitet asynchron; await wartet daher auf den Wert, bevor Sie entscheiden, welche Antwort zurückgegeben wird.
Schreiben Sie den Handler. Der in Anführungszeichen gesetzte Trenner JS bewahrt den JavaScript-Code unverändert und verhindert die Expansion von Shell-Variablen.
cat > src/index.js <<'JS'
export default {
async fetch(request, env) {
if (new URL(request.url).pathname !== "/banner") {
return new Response("Not found", { status: 404 });
}
const value = await env.FLAGS.get("banner:new");
return Response.json({
feature: "new-banner",
enabled: value === "enabled"
});
}
};
JS
Wenn ein Schlüssel fehlt, wird null zurückgegeben. Der spezifische Vergleich mit "enabled" sorgt dafür, dass ein fehlender oder unerwarteter Wert dieses optionale Banner deaktiviert lässt. Das ist ein kleines sicheres Standardverhalten: Die Anwendung bleibt nutzbar, wenn die Einstellung nicht bereitgestellt wurde. Verbindungsfehler werden dadurch nicht verborgen; sie unterscheiden sich von einem fehlenden Schlüssel.
Starten Sie die lokale Entwicklung. --local führt den Worker mit lokalen Bindings in dieser VM aus. > local.log 2>&1 leitet Ausgaben und Fehler in die Protokolldatei um; & ermöglicht die Eingabe weiterer Befehle im Terminal. $! ist die Prozess-ID des Hintergrundprozesses und wird hier gespeichert, damit Sie diesen Prozess später beenden können.
npx wrangler dev --local --ip 0.0.0.0 --port 8080 > local.log 2>&1 &
DEV_PID=$!
cat local.log
Warten Sie auf die Meldung, dass der Dienst an Port 8080 bereit ist. Wenn der Start noch läuft, lesen Sie das Protokoll erneut, bevor Sie fortfahren.
curl -i http://127.0.0.1:8080/banner
curl -i zeigt die Antwort-Header und den Antworttext an. Erwarten Sie HTTP 200, einen JSON-Content-Type und:
{"feature":"new-banner","enabled":true}
Der Wert true stammt aus dem lokalen KV-Speicher. Durch das Starten des Entwicklungsservers haben Sie den entfernten Wert disabled nicht in die VM kopiert. Lassen Sie den Server für den nächsten Vergleich weiterlaufen.
Die öffentliche Antwort bereitstellen und vergleichen
In diesem Schritt veröffentlichen Sie denselben Code und beobachten, wie er den Cloud-Namespace liest. Die Bereitstellung lädt den Worker und seine Binding-Konfiguration hoch; lokale KV-Einträge werden dabei nicht hochgeladen.
npx wrangler deploy
Lesen Sie die Ausgabe der Bereitstellung. Bestätigen Sie den Worker-Namen, das Binding FLAGS und die öffentliche workers.dev-Adresse. Speichern Sie die tatsächliche Adresse in der folgenden Variable und ersetzen Sie das Beispiel, bevor Sie den Befehl ausführen. Eine Shell-Variable verhindert, dass Sie eine lange URL erneut eingeben müssen.
WORKER_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$WORKER_URL/banner"
Erwarten Sie HTTP 200 und:
{"feature":"new-banner","enabled":false}
Die Cloud-Einstellung lautet disabled, daher ist der Wert in der öffentlichen Antwort false. Wenn der neue Hostname noch nicht erreichbar ist, warten Sie kurz und versuchen Sie es erneut. Wenn die Antwort einen älteren Wert enthält, überprüfen Sie den entfernten Schlüssel einmal und warten Sie, bis KV die Änderung sichtbar gemacht hat, anstatt den Wert schnell wiederholt zu überschreiben. Ein Netzwerkfehler ist kein erfolgreicher Test.
curl -i http://127.0.0.1:8080/banner
Die lokale Antwort lautet weiterhin true. Sie haben einen Handler und zwei getrennte Datenspeicher: Die lokale Entwicklung liest die Daten der VM, während der bereitgestellte Worker den Namespace liest, der durch das Binding identifiziert wird.
Wählen Sie im Cloudflare-Dashboard dasselbe Lernkonto aus und öffnen Sie Storage & databases → Workers KV. Suchen Sie den Namespace, dessen Name zu diesem Lab gehört, und sehen Sie sich seine Schlüssel an. Bestätigen Sie, dass nur banner:new vorhanden ist und den entfernten Wert disabled enthält. Öffnen Sie anschließend Workers & Pages, wählen Sie den Worker dieses Labs aus und öffnen Sie die Ansicht Bindings. Vergleichen Sie das Binding FLAGS mit dem Namespace, den Sie gerade überprüft haben. Dies sind schreibgeschützte Kontrollpunkte: Änderungen nehmen Sie weiterhin im Terminal vor.
Der Namespace öffnet sich unter Metrics. Wählen Sie KV Pairs, um die tatsächlichen Einträge zu prüfen; Nutzungszähler können Schreibvorgängen zeitlich hinterherhinken. Fehlt der neue Worker unter Workers & Pages, klicken Sie auf Refresh. Scrollen Sie unter Bindings zur Tabelle und vergleichen Sie den Binding-Namen mit dem Namespace.
Der generierte Name, die Namespace-ID und die öffentliche Subdomain unterscheiden sich von den Beispielen. Dass ein Namespace im Dashboard sichtbar ist, bestätigt seinen Speicherort; die erfolgreiche HTTP-Antwort bestätigt, dass die Anwendung ihn verwenden kann.
Die nur für dieses Lab erstellten Cloud-Ressourcen löschen
In diesem Schritt entfernen Sie beide Ressourcen, solange Wrangler noch autorisiert ist. Ein Namespace kann länger bestehen bleiben als sein Worker. Wenn Sie nur die Anwendung löschen, werden ihre Daten daher nicht automatisch bereinigt.
Beenden Sie den lokalen Entwicklungsprozess, den Sie in diesem Terminal gestartet haben:
kill "$DEV_PID"
Überprüfen Sie Ihre gespeicherten Ressourcenreferenzen, bevor Sie etwas löschen:
cat wrangler.jsonc
Bestätigen Sie den Worker-Namen labex-flags-... und die Namespace-ID für FLAGS. Löschen Sie den Worker, der durch diese Konfiguration ausgewählt wird:
npx wrangler delete
Wenn Sie dazu aufgefordert werden, prüfen Sie, ob der angezeigte Name zu diesem Lab gehört, und bestätigen Sie mit y. Löschen Sie anschließend nur den Namespace, auf den FLAGS verweist:
npx wrangler kv namespace delete --binding FLAGS
Prüfen Sie den Namespace in einer eventuellen Bestätigungsabfrage, bevor Sie zustimmen. Lassen Sie wrangler.jsonc unverändert, damit die unabhängige Überprüfung erkennen kann, welche Ressourcen nicht mehr vorhanden sein dürfen.
npx wrangler kv namespace list
Der Namespace dieses Labs sollte nicht mehr vorhanden sein; nicht zugehörige Namespaces sollten erhalten bleiben. Aktualisieren Sie die Listen im Dashboard, um zu bestätigen, dass der Worker und der Namespace dieses Labs verschwunden sind. Eine fehlgeschlagene Anfrage oder eine abgelaufene Anmeldung beweist nicht, dass die Löschung erfolgreich war. Führen Sie die Überprüfung dieses Schritts vor der Abmeldung aus, damit sie ein autorisiertes Ressourcenverzeichnis untersuchen kann.
Die Autorisierung der VM beenden
In diesem Schritt trennen Sie Wrangler, nachdem die Bereinigungsprüfung erfolgreich war. Durch die Abmeldung wird die gespeicherte Wrangler-Autorisierung dieser VM beendet. Cloud-Ressourcen werden dadurch nicht gelöscht, und Ihre normale Dashboard-Sitzung im Browser bleibt bestehen.
npx wrangler logout
npx wrangler whoami --json
Bestätigen Sie, dass das strukturierte Ergebnis "loggedIn": false meldet. Dieser nicht authentifizierte Befehl kann mit einem Status ungleich null enden; das ist hier zu erwarten. Wenn nur ein Verbindungsfehler und kein ausdrücklicher Authentifizierungsstatus angezeigt wird, wiederholen Sie den Befehl, sobald die Verbindung funktioniert.
Die verbleibenden lokalen Dateien und der lokale KV-Zustand gehören zu dieser nur für die Übung verwendeten VM. Sie sind von den Cloud-Ressourcen getrennt, die Sie bereits gelöscht haben. Sie können das Lab nun beenden.
Zusammenfassung
Sie haben einen isolierten KV-Namespace erstellt, ihn über ein Binding verbunden und mit ausdrücklichen lokalen und entfernten Befehlen Schlüssel geschrieben, gelesen, aufgelistet und gelöscht. Ihr Worker hat denselben Schlüssel aus getrennten Speichern gelesen: Das lokale Banner war aktiviert, während das öffentliche Banner deaktiviert blieb. Außerdem haben Sie ein sicheres Standardverhalten für ein fehlendes Flag verwendet und gelernt, warum KV-Aktualisierungen nicht als sofort global wirksamer Schalter behandelt werden sollten.
Zum Abschluss haben Sie die öffentliche Antwort überprüft, den Worker und den Namespace während der bestehenden Autorisierung entfernt und sich von Wrangler abgemeldet. Als Nächstes verwenden Sie strukturierte JSON-Werte, um nicht sensible Kontoeinstellungen bereitzustellen.
