Introduction
Un endpoint de vérification d’état est une petite URL qui vous indique si une application répond. Dans ce laboratoire, vous allez écrire un Cloudflare Worker en JavaScript, tester sa réponse JSON dans LabEx, publier le même code sur une URL publique workers.dev, consulter le journal d’une requête, puis supprimer le déploiement de test.
Utilisez votre propre compte d’apprentissage, associé à une adresse e-mail vérifiée et à Workers Free, préparé dans Préparer votre compte Cloudflare d’apprentissage. Vous devez reconnaître le processus d’autorisation de l’appareil présenté dans Connecter LabEx à votre compte Cloudflare et connaître les bases de JavaScript. Cette nouvelle VM doit être autorisée séparément, notamment pour pouvoir déployer et supprimer des Workers. Aucun domaine acheté, aucune base de données et aucune mise à niveau payante ne sont nécessaires. Votre réponse de test est publique et contient uniquement des données d’exemple.
La configuration a installé Node.js 22.22.0 et Wrangler 4.131.1 au niveau du projet dans /home/labex/project/first-worker. Vous allez consulter les informations du compte avec Wrangler et tester les réponses avec curl ; ces outils fonctionnent également en dehors de LabEx. Vous écrirez vous-même le Worker et la configuration, puis exécuterez les commandes Wrangler standard. Laissez cette VM ouverte jusqu’à la vérification de la suppression et de la déconnexion.
Écrire un Worker de vérification d’état
Dans cette étape, vous allez créer le point d’entrée JavaScript et indiquer à Wrangler comment l’exécuter. Un Worker exporte un gestionnaire fetch : Cloudflare l’appelle lorsqu’une requête HTTP arrive, et le Response renvoyé devient la réponse HTTP. Ce premier Worker renvoie le même message d’état pour tous les chemins ; le routage sera abordé dans le prochain laboratoire.
Accédez au projet préparé et vérifiez la version de l’interface de ligne de commande :
cd /home/labex/project/first-worker
npx wrangler --version
La version doit être 4.131.1. Wrangler est une dépendance du projet : exécutez donc les commandes depuis ce répertoire. Sur votre propre ordinateur, installez les dépendances verrouillées d’un projet avec npm ci lorsqu’un fichier de verrouillage est fourni.
La commande suivante utilise un here-document : cat écrit dans src/index.js les lignes situées entre <<'WORKER' et WORKER. Le symbole > remplace le contenu du fichier. Le délimiteur entre apostrophes empêche le shell de modifier le texte JavaScript. Collez le bloc complet, y compris son délimiteur final.
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 crée une réponse JSON avec le statut 200 et le type de contenu JSON. Le message de la console enregistre la méthode et le chemin, sans journaliser les en-têtes ni les identifiants.
Générez un nom unique pour éviter de remplacer un Worker existant. Le module crypto intégré à Node.js génère six octets aléatoires et les formate sous la forme de douze caractères hexadécimaux. $(...) capture ce texte dans une variable du shell :
WORKER_NAME="labex-first-$(node -p "require('node:crypto').randomBytes(6).toString('hex')")"
Créez la configuration. Ici, le délimiteur n’est pas entre apostrophes : $WORKER_NAME est donc remplacé par la valeur unique :
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false
}
CONFIG
main désigne votre fichier JavaScript. compatibility_date sélectionne le comportement de compatibilité du runtime ; il ne s’agit pas de la date du déploiement. workers_dev active une URL de test publique, tandis que preview_urls désactive les URL supplémentaires de prévisualisation des versions. Un fichier JSON sans commentaires est un fichier JSONC valide ; utilisez le format présenté dans ce laboratoire.
cat wrangler.jsonc
Vérifiez que le nom commence par labex-first- et comporte un suffixe unique. Conservez ce nom pendant tout le laboratoire : le déploiement et la suppression viseront ce Worker. Vous ajouterez l’ID du compte après l’autorisation.
Utilisez le bouton de vérification de l’étape pour contrôler la configuration et le gestionnaire. À l’étape suivante, vous observerez vous-même la réponse avec le runtime local.
Exécuter et tester le Worker en local
Dans cette étape, vous allez exécuter le Worker dans la VM avant de le publier. Le runtime local de Wrangler exécute votre gestionnaire sans créer de déploiement cloud.
Démarrez le serveur de développement en arrière-plan afin que le même terminal puisse envoyer des requêtes HTTP. --ip 0.0.0.0 rend le service de la VM accessible depuis l’interface web de LabEx, et --port 8080 sélectionne son port. > local.log enregistre la sortie standard, 2>&1 envoie les erreurs dans le même fichier et & rend l’invite du terminal alors que le serveur continue de fonctionner.
npx wrangler dev --ip 0.0.0.0 --port 8080 > local.log 2>&1 &
cat local.log
Attendez que le journal indique que le serveur est prêt sur le port 8080. Si le démarrage est toujours en cours, répétez cat local.log avant de continuer. Laissez le serveur fonctionner jusqu’à la fin de cette étape.
Utilisez curl pour envoyer une requête. -i inclut les en-têtes de réponse ; vous pouvez ainsi vérifier à la fois le statut et le type de contenu :
curl -i http://127.0.0.1:8080/health
La réponse contient les valeurs stables suivantes ; l’ordre et la casse des en-têtes peuvent différer :
HTTP/1.1 200 OK
Content-Type: application/json
...
{"service":"labex-first-worker","status":"ok"}
L’adresse 127.0.0.1 désigne cette VM. Elle ne désigne ni votre ordinateur ni un déploiement Cloudflare public. Vérifiez le statut HTTP, le type de contenu JSON et les deux champs de la réponse avant de continuer.
Effectuez la vérification de cette étape pendant que le serveur de développement fonctionne encore.
Autoriser et déployer sur Cloudflare
Dans cette étape, vous allez connecter cette VM à votre compte d’apprentissage et déployer le Worker testé. Commencez par examiner le processus en arrière-plan. jobs répertorie les processus lancés dans ce terminal ; son entrée doit afficher wrangler dev.
jobs
Arrêtez ce processus avec kill %1. Ici, %1 désigne le processus 1 dans ce terminal, et non un identifiant de processus système. Si jobs affiche un autre numéro pour wrangler dev, utilisez ce numéro à la place. Cette commande envoie un signal d’arrêt au processus.
kill %1
Démarrez l’autorisation de l’appareil. Les portées de lecture identifient votre compte ; workers_scripts:write autorise le déploiement et la suppression de scripts, et workers_tail:read autorise la consultation des journaux en direct. --browser=false affiche le lien que vous devrez ouvrir dans votre propre navigateur.
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Ouvrez le lien affiché, connectez-vous à Cloudflare si nécessaire, saisissez le code actuel de l’appareil et examinez la demande d’autorisations de Wrangler. Sélectionnez votre compte d’apprentissage, et non tous les comptes. La page de consentement inclut également l’accès requis Background Access. N’approuvez la demande qu’après avoir vérifié l’application, le compte et les autorisations ; revenez ensuite au terminal et attendez la fin de l’autorisation. Si un code expire, relancez la commande de connexion pour obtenir un nouveau code. Ne collez pas de jetons dans le terminal et ne partagez pas les fichiers d’identifiants.
Développez Account & Billing et Developer Platform afin d’examiner les noms des autorisations présentées ci-dessous. Ces autorisations sont plus larges que celles de la leçon de connexion en lecture seule, car ce laboratoire déploie un Worker et ouvre ses journaux en direct.
Vérifiez que votre compte d’apprentissage est sélectionné. Utilisez Edit si le mauvais compte est sélectionné ou si tous les comptes le sont ; vérifiez votre choix avant de cliquer sur Authorize.
Consultez les comptes disponibles pour cette connexion :
npx wrangler whoami --json
Vérifiez "loggedIn": true et "authType": "OAuth Token". Dans le tableau accounts, trouvez l’objet dont name correspond au nom de votre compte d’apprentissage et copiez son id de 32 caractères. Les autres paramètres du compte ne sont pas nécessaires dans ce laboratoire. Si un seul compte apparaît, confirmez tout de même son nom ; si plusieurs comptes apparaissent, utilisez le Dashboard pour les distinguer. Si votre compte est absent, recommencez l’autorisation en sélectionnant le compte voulu.
Ajoutez account_id à votre configuration. Remplacez YOUR_ACCOUNT_ID dans ce bloc par l’ID copié avant de l’exécuter. Cette commande réécrit la configuration tout en conservant la variable $WORKER_NAME de l’étape 1. Gardez ce terminal ouvert ; si vous avez perdu la variable, lisez le nom d’origine avec cat wrangler.jsonc et rétablissez WORKER_NAME avec exactement ce nom. Ne générez pas un autre nom et ne changez pas de compte après le déploiement.
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
Vérifiez le nom unique du Worker et comparez account_id avec l’objet du compte voulu affiché par whoami --json. Cet ID est un paramètre de configuration, pas un mot de passe. Wrangler le lit lors du déploiement et de la suppression. Publiez maintenant le code local :
npx wrangler deploy
Si ce compte ne possède pas encore de sous-domaine workers.dev, Wrangler vous demande si vous souhaitez en enregistrer un. Répondez yes, choisissez un nom disponible en minuscules, composé de lettres, de chiffres et de tirets, puis confirmez. Ce nom associé au compte sera partagé par vos futurs Workers ; il est différent du nom unique du Worker de ce laboratoire. Si un sous-domaine existe déjà, réutilisez-le ; ne le renommez pas. Aucun achat de domaine personnalisé ni aucune mise à niveau de forfait ne sont nécessaires.
Attendez la fin du déploiement. Wrangler affiche une URL avec la structure suivante :
https://<your-worker-name>.<your-subdomain>.workers.dev
Copiez l’URL exacte affichée par votre déploiement dans une variable du shell. Remplacez entièrement l’URL d’exemple ci-dessous, conservez les guillemets et n’ajoutez pas de barre oblique finale :
WORKER_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$WORKER_URL/health"
Vous devez obtenir le statut HTTP 200 et le même JSON que lors du test local. Si le nouveau nom d’hôte est encore en cours de propagation, patientez brièvement et réessayez ; une page d’erreur ne constitue pas un déploiement réussi. Vous pouvez également ouvrir l’URL /health exacte dans votre navigateur. Si votre navigateur ou votre réseau bloque workers.dev, utilisez le résultat de curl dans la VM ; ne désactivez pas les paramètres de sécurité du navigateur. La requête effectuée depuis la VM et la vérification indépendante ci-dessous sont les tests de réponse requis.
Confirmez maintenant visuellement le même déploiement dans le Cloudflare Dashboard. Gardez votre terminal ouvert.
Sélectionnez votre compte d’apprentissage dans le sélecteur de comptes. Son identité doit correspondre au compte sélectionné précédemment.
Ouvrez Compute → Workers & Pages. Actualisez la liste des applications si nécessaire, puis recherchez le nom exact labex-first-... indiqué dans votre configuration. Si de nombreuses applications sont présentes, recherchez ce nom complet.
Ouvrez ce Worker. Vérifiez son nom et repérez son adresse workers.dev; comparez cette adresse avec l’URL affichée par wrangler deploy.
Ces captures présentent un exemple de déploiement. Le suffixe aléatoire de votre Worker et le sous-domaine de votre compte seront différents. Recherchez vos propres valeurs au lieu de copier l’exemple. Le Dashboard est une autre vue de la ressource que vous avez créée depuis le terminal ; ne créez pas de second Worker et ne modifiez pas son code ici. S’il est absent, vérifiez d’abord le compte sélectionné, le nom exact et la fin de la commande de déploiement.
La liste des applications confirme qu’une ressource cloud existe ; la réponse HTTP testée avec curl confirme que son code fonctionne. Vous n’avez pas besoin de prendre ni d’envoyer votre propre capture d’écran.
Utilisez le bouton de vérification de l’étape. Sa vérification indépendante côté serveur lit les paramètres du Worker dans le compte sélectionné et teste l’endpoint public ; le contenu similaire renvoyé par un autre site ne peut donc pas la valider.
Observer un journal de requêtes en direct
Dans cette étape, vous allez connecter un flux de journaux en direct et rechercher le message produit par votre gestionnaire. Un flux de journaux n’affiche que les requêtes reçues pendant qu’il est connecté ; les requêtes précédentes ne sont pas rejouées.
Démarrez Wrangler tail en arrière-plan. --format json produit des événements structurés. Cette fois, la sortie standard et les erreurs sont envoyées dans des fichiers distincts afin que les messages de diagnostic ne se retrouvent pas dans les données d’événement :
npx wrangler tail --format json > requests.json 2> tail-errors.log &
Attendez quelques secondes que la connexion s’initialise, puis envoyez une nouvelle requête :
curl -i "$WORKER_URL/health"
Le fichier d’événements contient également de nombreuses métadonnées de requête. head -n 32 affiche ses 32 premières lignes afin de vous concentrer sur l’événement initial et le message de l’application :
head -n 32 requests.json
Recherchez un événement dont outcome vaut ok, associé à une requête GET se terminant par /health, ainsi qu’un message de console contenant health-request. Les autres champs, les horodatages et les en-têtes de requête peuvent varier. Si le fichier est vide, consultez tail-errors.log, attendez l’établissement de la connexion, envoyez à nouveau la requête, puis relisez le fichier.
Arrêtez tail avant de vérifier les événements enregistrés. Consultez jobs et utilisez le numéro affiché pour wrangler tail — normalement 1 après l’arrêt du processus précédent :
jobs
kill %1
Utilisez le bouton de vérification de l’étape pour contrôler l’événement capturé avec le Worker déployé.
Le fichier peut contenir des métadonnées de requête. Conservez-le dans cette VM ; ne le publiez pas sous forme de capture d’écran et ne l’envoyez pas dans un dépôt public.
Supprimer le Worker de test
Dans cette étape, vous allez supprimer uniquement le Worker de test et confirmer le résultat tant que votre autorisation de gestion est encore active. La suppression d’une VM ne supprimerait pas un Worker déployé.
Examinez à nouveau la configuration du projet et vérifiez que son name correspond au nom unique labex-first-... utilisé dans ce laboratoire :
cat wrangler.jsonc
Supprimez ce Worker à l’aide de la configuration du projet :
npx wrangler delete
Lisez l’invite de confirmation, vérifiez le nom exact et appuyez sur y pour confirmer. N’utilisez pas la suppression forcée et ne supprimez pas un autre projet. Wrangler indique normalement que le Worker a été supprimé. Avec la version verrouillée et ces autorisations limitées, il peut toutefois afficher une erreur d’authentification pour /storage/kv/namespaces après avoir supprimé le Worker : Wrangler vérifie également le stockage historique de Workers Sites pendant le nettoyage. Ce laboratoire ne crée aucun espace de noms KV. N’accordez pas toutes les autorisations suggérées et ne relancez pas le déploiement pour corriger ce diagnostic ; utilisez le bouton de vérification de cette étape pour déterminer si le Worker a réellement disparu. Toute autre erreur doit faire l’objet d’une investigation.
Dans le Cloudflare Dashboard, ouvrez Workers & Pages dans votre compte d’apprentissage et actualisez la liste. Vérifiez que le nom exact de votre Worker est absent. Utilisez ensuite le bouton de vérification de l’étape pour effectuer un contrôle indépendant via l’API.
Le contrôle exige une réponse d’inventaire authentifiée réussie ; une requête réseau échouée ou une connexion expirée ne compte pas comme une suppression. Votre compte d’apprentissage et son sous-domaine workers.dev associé au compte restent disponibles pour les prochains laboratoires. Effectuez la vérification de cette étape avant de vous déconnecter.
Déconnecter la VM
Dans cette étape, vous allez supprimer l’autorisation enregistrée par Wrangler après avoir vérifié le nettoyage cloud. Les fichiers source locaux restent dans la VM, mais ils n’autorisent plus l’accès à votre compte.
npx wrangler logout
npx wrangler whoami --json
Recherchez "loggedIn": false. Cette version de Wrangler renvoie un code différent de zéro lorsqu’elle est déconnectée ; c’est le comportement attendu. Une erreur réseau sans cet état explicite ne prouve pas la déconnexion. Utilisez le bouton de vérification de l’étape pour effectuer une confirmation indépendante.
Votre navigateur peut rester connecté au Cloudflare Dashboard. La connexion du navigateur et l’autorisation Wrangler de cette VM sont distinctes. Un prochain laboratoire commencera avec une nouvelle VM et demandera sa propre autorisation.
Résumé
Vous avez écrit un gestionnaire fetch et une configuration de Worker, testé localement sa réponse JSON, puis déployé le Worker sur votre propre compte d’apprentissage. Vous avez consulté un journal de requête en direct, vérifié indépendamment la réponse publique et la propriété de la ressource, supprimé le Worker de test alors que vous étiez autorisé, puis déconnecté la VM.
Pour référence, consultez les commandes Wrangler, le gestionnaire fetch et la configuration workers.dev.
