Introduction
Un service d’assistance a besoin d’un espace sûr pour prévisualiser les changements de configuration. Vous exécuterez le même code dans les environnements de prévisualisation et de production, vous séparerez leurs libellés publics et leurs secrets, puis vous protégerez un point de terminaison de maintenance synthétique tout en laissant les contrôles de disponibilité accessibles publiquement.
Utilisez votre propre compte Cloudflare d’apprentissage ainsi que les connaissances sur l’autorisation de l’appareil, le déploiement et les journaux acquises dans les labs précédents. Ce lab démarre indépendamment dans /home/labex/project/worker-config, avec Node.js 22.22.0, Wrangler 4.131.1 installé localement dans le projet et un petit fixture de route de disponibilité. Aucune VM ni ressource cloud précédente n’est réutilisée. Les deux déploiements sont temporaires et l’opération de maintenance est une simulation à blanc. Utilisez uniquement des jetons synthétiques générés pour l’exercice. Workers Free et workers.dev prennent en charge cet exercice simple ; les requêtes sont comptabilisées dans l’utilisation de votre compte. Aucun domaine acheté, aucune base de données et aucune mise à niveau payante ne sont nécessaires.
Vous supprimerez les deux déploiements cloud et les fichiers de jetons locaux, puis vous vous déconnecterez avant d’arrêter la VM. Gardez le même terminal ouvert pendant toute la durée du lab.
Séparer la configuration de prévisualisation et de production
Dans cette étape, vous utiliserez le même gestionnaire de disponibilité fourni avec deux environnements nommés. Ici, live désigne encore un déploiement d’apprentissage temporaire ; aucun des deux environnements ne traite de véritables données de production. Le nom preview désigne un environnement Wrangler, et non une URL de prévisualisation de version.
Accédez au projet préparé et inspectez le fixture de route de disponibilité. Node et Wrangler installé localement dans le projet sont déjà disponibles.
cd /home/labex/project/worker-config
node --version
npx wrangler --version
cat src/index.js
Vous devez obtenir Node v22.22.0 et Wrangler 4.131.1. Le gestionnaire lit dans env les valeurs d’affichage non secrètes. Sur votre propre machine, installez Node et ajoutez wrangler@4.131.1 comme dépendance de développement du projet ; reproduisez les dépendances existantes avec npm ci.
Générez un nom de base temporaire. La substitution de commande insère une valeur hexadécimale aléatoire dans la variable du shell. Gardez ce terminal ouvert pour les commandes suivantes.
WORKER_NAME="labex-config-$(openssl rand -hex 6)"
Écrivez la configuration avec un heredoc ; son marqueur de fermeture non entouré de guillemets permet la substitution de $WORKER_NAME. main sélectionne le code partagé et compatibility_date sélectionne le comportement du runtime. Les objets env remplacent la configuration pour --env preview et --env live. Définissez chaque valeur vars dans chaque environnement, car ces liaisons ne sont pas héritées. Aucune ressource de base de données ou de file d’attente n’est créée : QUEUE_LABEL est uniquement un libellé d’affichage public.
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
Démarrez les deux runtimes locaux. > redirige la sortie, 2>&1 inclut les erreurs et & exécute le processus en arrière-plan. Des ports HTTP et d’inspection distincts évitent les collisions.
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
Attendez que les deux journaux indiquent que les serveurs sont prêts ; réexécutez au besoin la commande cat correspondante. Comparez ensuite les réponses :
curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8081/health
Les deux réponses renvoient 200. Preview renvoie {"status":"ok","environment":"preview","queue":"sandbox"} ; live renvoie {"status":"ok","environment":"live","queue":"primary"}. curl -i inclut le statut et les en-têtes. Utilisez le bouton de vérification pendant que les deux serveurs fonctionnent.
La documentation sur les environnements explique l’héritage des environnements et les noms déployés par défaut au format <name>-<environment>.
Protéger une route de maintenance avec des secrets locaux
Dans cette étape, vous protégerez une opération de maintenance synthétique avec un jeton différent dans chaque environnement. Un secret est une configuration privée accessible via env ; il ne doit apparaître ni dans les vars publics, ni dans le JSON renvoyé, ni dans les journaux de l’application. Cet exemple simple de jeton porteur explique la limite côté serveur, mais ne constitue pas un système complet d’authentification utilisateur.
Arrêtez les deux tâches locales avant d’ajouter les fichiers de secrets. Inspectez les numéros réels des tâches ; les exemples supposent que preview est la tâche 1 et live la tâche 2.
jobs
kill %1 %2
Générez deux jetons aléatoires réservés aux tests sans les afficher. umask 077 rend les nouveaux fichiers lisibles uniquement par l’utilisateur de votre VM. printf écrit une affectation dotenv dans le fichier propre à chaque environnement. N’utilisez jamais ici un véritable jeton API de compte.
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
Vérifiez que .dev.vars* et .env* sont exclus. N’affichez pas et ne validez pas les fichiers de secrets. Wrangler charge .dev.vars.preview pour --env preview et le fichier live distinct pour --env live ; un fichier .dev.vars propre à un environnement remplace le fichier générique. Ces fichiers ne téléversent pas automatiquement les secrets vers Cloudflare. Consultez les secrets locaux et déployés.
Remplacez le gestionnaire. Le heredoc entre guillemets conserve littéralement le JavaScript. Un secret configuré manquant renvoie 503 ; un identifiant de requête manquant ou incorrect renvoie 401. Comparez l’en-tête Authorization côté serveur avant de renvoyer un succès. Seuls un nom d’événement fixe, l’environnement public et un statut numérique sont consignés. L’opération acceptée est une simulation à blanc sans effet persistant.
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
Une fois que les deux serveurs indiquent qu’ils sont prêts, testez la limite d’autorisation. -X POST sélectionne la méthode et -H fournit l’en-tête bearer. N’utilisez pas la sortie verbeuse de curl avec de véritables identifiants.
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
Les trois premières requêtes renvoient 401 unauthorized, y compris avec le jeton valide de l’autre environnement. Les deux suivantes renvoient 200 avec operation: dry-run et leur propre environnement. Le contrôle de disponibilité reste public. Utilisez la vérification pour contrôler l’isolation des jetons dans les deux sens, les méthodes, la configuration publique et l’absence des valeurs de jeton dans les journaux locaux.
Déployer chaque environnement et téléverser son secret
Dans cette étape, vous autoriserez cette nouvelle VM, déploierez chaque environnement nommé et téléverserez explicitement son secret. Arrêtez d’abord les tâches locales ; utilisez leurs numéros réels obtenus avec jobs.
jobs
kill %1 %2
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Utilisez le lien affiché et le code actuel dans votre navigateur connecté. Examinez les autorisations demandées par Wrangler et l’accès en arrière-plan requis (Background Access), sélectionnez uniquement votre compte d’apprentissage et autorisez l’accès comme indiqué dans le lab de connexion. Attendez la fin de l’opération dans le terminal.
npx wrangler whoami --json
Vérifiez que loggedIn: true apparaît, ainsi que le nom et l’ID du compte. Remplacez YOUR_ACCOUNT_ID ci-dessous par cet ID réel ; conservez le nom de ressource d’origine.
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
Incluez toujours --env pour ce projet. Sinon, Wrangler cible l’environnement sans nom de niveau supérieur, qui ne fait pas partie du plan de déploiement de ce lab.
npx wrangler deploy --env preview
npx wrangler deploy --env live
Copiez l’adresse workers.dev exacte de chaque sortie de déploiement. Réutilisez le sous-domaine existant du compte d’apprentissage. Les utilisateurs qui se connectent pour la première fois doivent suivre l’invite de Wrangler concernant le sous-domaine disponible, sans modifier un sous-domaine existant.
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"
Les deux réponses renvoient 503 maintenance_unconfigured : les fichiers de secrets locaux n’ont pas été téléversés par le déploiement standard. Le contrôle de disponibilité est indépendant de l’autorisation de maintenance.
Utilisez la commande groupée standard pour téléverser le fichier dotenv dans l’environnement correspondant. Même un seul secret peut être envoyé avec cette opération basée sur un fichier ; sa sortie indique le nom du secret, et non sa valeur. Une mise à jour de secret crée et déploie immédiatement une version.
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
Chaque liste doit contenir MAINTENANCE_TOKEN avec le type secret_text. Comparez les valeurs publiques et le comportement de l’autorisation :
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"
Le contrôle de disponibilité conserve les valeurs preview/sandbox et live/primary. Les identifiants manquants ou provenant de l’autre environnement renvoient 401 ; les jetons correspondants renvoient 200. Attendez la propagation initiale du nom d’hôte avant de réessayer en cas d’erreur de connexion. Dans le même compte Dashboard, ouvrez Compute → Workers & Pages. Repérez les deux Workers dont le nom se termine par -preview et -live, puis comparez leurs noms complets et leurs URL avec la sortie du déploiement. Dans cet exemple, chaque environnement Wrangler nommé possède son propre Worker déployé ; ne créez pas une autre application dans le Dashboard.
Ouvrez votre Worker -preview et sélectionnez Settings. Dans Runtime variables and secrets (la section Variables and secrets), comparez les colonnes Type, Name et Value. ENVIRONMENT doit être preview et QUEUE_LABEL doit être sandbox. MAINTENANCE_TOKEN doit avoir le type Secret, avec Value encrypted à la place d’une valeur lisible.
Revenez à Workers & Pages, ouvrez votre Worker -live et inspectez la même section. Ses valeurs publiques doivent être live et primary, tandis que son secret téléversé indépendamment utilise le même nom de liaison. Vérifiez le nom du Worker dans le fil d’Ariane supérieur avant de comparer le tableau.
Le suffixe du nom aléatoire et le sous-domaine visibles dans ces images sont des exemples. L’affichage chiffré confirme la présence et le type de la liaison secrète, mais pas que les deux environnements utilisent des valeurs de secret différentes ; les tests HTTP avec des jetons correspondants et croisés ci-dessus établissent ce comportement. Gardez cette vérification en lecture seule : ne modifiez pas les variables et n’affichez, ne remplacez ni ne copiez aucun identifiant dans le Dashboard. Utilisez la vérification : elle contrôle la propriété réelle, les types de liaisons déployées et le comportement public des deux environnements.
Inspecter les journaux de l’application sans exposer les secrets
Dans cette étape, vous inspecterez une requête rejetée et une requête acceptée dans l’environnement preview déployé. Les journaux de l’application doivent expliquer le résultat sans copier les identifiants ni les en-têtes de requête.
Démarrez un flux de journaux avec la commande tail présentée précédemment. La sortie mise en forme affiche les messages de l’application ; enregistrez-la afin de pouvoir inspecter le test limité après avoir arrêté le flux.
npx wrangler tail --env preview --format pretty > preview-tail.log 2>&1 &
cat preview-tail.log
Attendez que le flux indique qu’il est connecté ; réexécutez cat pendant la connexion. Envoyez ensuite de nouvelles requêtes synthétiques :
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer incorrect-token"
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer $PREVIEW_TOKEN"
Utilisez grep pour afficher uniquement les lignes contenant le nom d’événement fixe de l’application :
grep 'maintenance' preview-tail.log
Attendez les événements avec les statuts 401 et 200. Leur environnement public est preview. Aucun jeton ne doit apparaître dans l’un ou l’autre message. La transmission des événements peut être retardée par rapport à la réponse HTTP ; réessayez grep pendant une minute au maximum. Si un événement manque, inspectez l’appel console.log correspondant dans le code source.
jobs
kill %1
Arrêtez la tâche réelle de suivi une fois les deux événements présents ; l’exemple suppose qu’il s’agit de la tâche 1. Utilisez la vérification pour contrôler le journal capturé et revérifier séparément les contrats d’autorisation distants. Cet exercice utilise uniquement des requêtes synthétiques et ne garantit pas la sécurité de futures modifications arbitraires de la journalisation.
Supprimer les déploiements des deux environnements
Dans cette étape, vous supprimerez les deux Workers temporaires des environnements pendant que vous êtes encore autorisé. Confirmez le nom de base et le compte d’apprentissage dans la configuration :
cat wrangler.jsonc
Supprimez uniquement les déploiements preview et live de ce lab. À chaque invite, vérifiez le nom exact <base>-preview ou <base>-live, puis appuyez sur la touche y.
npx wrangler delete --env preview
npx wrangler delete --env live
La suppression de ces Workers supprime également leurs liaisons de secrets associées. Wrangler 4.131.1 peut ensuite signaler l’erreur d’authentification des Workers Sites KV hérités déjà documentée. N’élargissez pas les autorisations et n’interprétez pas cette erreur comme une preuve de suppression. Actualisez Workers & Pages et utilisez la vérification : un inventaire autorisé réussi doit montrer que les deux noms sont absents. Une erreur d’authentification ou de réseau ne permet pas de conclure. Préservez les Workers sans rapport avec ce lab, votre compte d’apprentissage et son sous-domaine existant.
Supprimer les secrets locaux et se déconnecter
Dans cette étape, vous supprimerez les copies locales des secrets de ce lab une fois le nettoyage cloud vérifié, puis vous déconnecterez la VM. rm supprime uniquement les deux fichiers indiqués ci-dessous et unset supprime les deux variables temporaires du shell.
rm .dev.vars.preview .dev.vars.live
unset PREVIEW_TOKEN LIVE_TOKEN
npx wrangler logout
npx wrangler whoami --json
Vous devez obtenir explicitement "loggedIn": false ; l’exécution avec un code de sortie différent de zéro de la commande non authentifiée est attendue lorsque ce résultat structuré est présent. Utilisez la vérification, puis arrêtez la VM. La connexion du navigateur est indépendante et peut rester disponible pour le lab suivant. Ni la déconnexion ni l’arrêt de la VM ne remplacent la suppression préalable des ressources cloud.
Résumé
Vous avez séparé la configuration publique selon l’environnement Wrangler, chargé des secrets locaux propres à chaque environnement, téléversé des liaisons de secrets chiffrées et vérifié les identifiants correspondants, manquants et provenant de l’autre environnement. La route publique de disponibilité a conservé l’identité de son environnement, tandis que le serveur protégeait une route de maintenance en simulation à blanc. Vous avez inspecté des journaux d’application limités sans afficher de jetons, puis vérifié la suppression avant de supprimer les identifiants locaux et de vous déconnecter.
La même discipline de configuration vous aidera plus tard dans ce cours à diagnostiquer les dérives de configuration de prévisualisation.
