Prévisualiser la dérive de configuration

CloudflareBeginner
Pratiquer maintenant

Introduction

L’API de prévisualisation d’une équipe de support renvoie la configuration de production, et son exécution à blanc de maintenance refuse l’identifiant de prévisualisation. L’environnement de production fonctionne toujours. Votre objectif est de rétablir la séparation de la prévisualisation sans affaiblir l’autorisation de maintenance ni modifier le comportement de la production.

Ce défi autonome fournit un petit Worker, deux environnements locaux nommés et des identifiants synthétiques dans une VM neuve. Appliquez les pratiques de configuration, de chargement des secrets et de test à l’exécution étudiées dans les laboratoires guidés. La réussite signifie que les deux environnements locaux respectent le contrat ci-dessous, puis que les serveurs temporaires et les fichiers de secrets sont supprimés. Ici, les noms preview et live désignent des environnements de test locaux ; ce défi ne nécessite ni connexion à Cloudflare ni déploiement.

Rétablir l’isolation de la prévisualisation

Situation actuelle

Le projet préparé se trouve dans /home/labex/project/preview-drift. Node 22.22.0, Wrangler 4.131.1 installé localement dans le projet et l’environnement d’exécution de test indépendant sont installés. Les serveurs de développement ne sont pas encore lancés. Le gestionnaire fourni implémente un état de santé public et une exécution à blanc de maintenance synthétique ; le problème se trouve dans la configuration publique de l’environnement de prévisualisation et dans le chargement de ses identifiants.

Périmètre

Travaillez avec wrangler.jsonc, src/index.js, .dev.vars.preview, .dev.vars.live et .gitignore. Inspectez le gestionnaire et la configuration pour identifier le contrat des bindings. Les deux fichiers dotenv contiennent des identifiants de test aléatoires et différents. Vous pouvez inspecter leurs noms de clés sans afficher leurs valeurs. Gardez les identifiants privés dans cette VM et excluez-les de Git.

Lancez l’environnement Wrangler preview sur le port loopback 8080 et live sur le port 8081. Attribuez des ports d’inspection différents aux deux exécutions simultanées. Utilisez les commandes ordinaires de développement de Wrangler installé localement dans le projet ; ce défi ne crée aucune ressource distante. QUEUE_LABEL est une chaîne d’affichage, pas un service de file d’attente.

Votre objectif

Les deux environnements locaux doivent exposer l’identité publique qui leur est destinée et n’autoriser la maintenance qu’avec leur propre identifiant configuré. L’environnement de prévisualisation doit être isolé de la production, et l’état de santé public ainsi que le comportement d’échec sécurisé existants doivent rester disponibles.

Critères d’acceptation

  • GET /health renvoie du JSON avec le statut ok. La prévisualisation identifie l’environnement preview et la file sandbox ; la production identifie l’environnement live et la file primary.
  • Chaque environnement charge son propre identifiant synthétique via le binding MAINTENANCE_TOKEN du gestionnaire. Les deux valeurs d’identifiant doivent rester distinctes, en dehors du code source et des variables publiques de Wrangler. Les fichiers dotenv locaux restent lisibles uniquement par l’utilisateur de la VM et sont exclus de Git.
  • POST /maintenance renvoie 200 avec operation: dry-run et le nom de l’environnement uniquement lorsque la requête contient un identifiant Bearer valide pour cet environnement. Les identifiants absents, invalides ou provenant de l’autre environnement renvoient 401 avec error: unauthorized.
  • Lorsqu’un secret configuré est absent, l’échec doit être sécurisé : le service renvoie 503 avec error: maintenance_unconfigured. GET /maintenance reste en 405 avec error: method_not_allowed ; une route inconnue reste en 404 avec error: not_found.
  • Les réponses et les journaux de l’application ne contiennent aucune valeur d’identifiant. Les deux serveurs locaux restent actifs pour les deux vérifications de cette étape. Aucune autorisation cloud, aucun déploiement, aucun rapport ni marqueur de réussite copié n’est requis.

Indications

Comparer la source de chaque valeur publique

Lisez les recherches d’environnement dans le gestionnaire, puis comparez-les aux objets d’environnement nommés dans wrangler.jsonc. Les variables d’environnement Wrangler ne sont pas héritées automatiquement. L’environnement sélectionné par une exécution et les valeurs contenues dans cet environnement sont deux éléments distincts.

Analyser une réponse maintenance_unconfigured

Faites la distinction entre un binding configuré manquant et un identifiant entrant refusé. Comparez le nom du binding utilisé par le gestionnaire avec les noms de clés du fichier dotenv propre à l’environnement. L’existence d’un fichier local ne garantit pas qu’il définit le binding lu par le gestionnaire. Après toute modification de configuration, vérifiez à nouveau que l’exécution est prête.

Préserver le comportement de la production et la limite de sécurité

Testez l’état de santé et la maintenance dans les deux sens. Un identifiant valide dans un environnement doit être invalide dans l’autre. L’opération de maintenance fournie est une exécution à blanc ; une requête correctement autorisée ne modifie donc aucune donnée de l’application.

Laisser un espace de travail propre

Situation actuelle

Les environnements locaux corrigés ont réussi les vérifications fonctionnelles. Leurs processus de développement et leurs fichiers d’identifiants synthétiques sont encore présents dans cette VM.

Périmètre

Seuls les processus de développement de ce défi sur les ports 8080 et 8081, ses fichiers .dev.vars.preview et .dev.vars.live, ainsi que les variables du shell contenant leurs valeurs sont temporaires. Préservez le code source corrigé, la configuration, les dépendances et les services LabEx.

Votre objectif

Le projet corrigé reste disponible, sans serveur du défi en cours d’exécution ni fichier de secret local restant.

Critères d’acceptation

  • Aucun serveur de développement n’écoute sur le port 8080 ou 8081.
  • Aucun fichier de secret .dev.vars* ou .env* ne reste dans le projet du défi.
  • Effacez les variables du shell utilisées pour les identifiants synthétiques. Il s’agit d’une action de nettoyage côté apprenant ; le backend ne peut pas inspecter l’état de votre shell interactif.
  • Préservez les processus et fichiers sans rapport avec ce défi. Aucune ressource cloud ni aucun identifiant Cloudflare ne doit être supprimé dans ce défi local uniquement.

Indications

Cibler les tâches que vous avez lancées

Utilisez la liste des tâches de votre shell pour identifier les deux processus de développement Wrangler. Les numéros de tâches peuvent changer après le redémarrage d’un serveur. Effectuez les vérifications fonctionnelles avant le nettoyage ; supprimer les secrets en premier rendrait les vérifications précédentes non concluantes.

Résumé

Vous avez relié le décalage d’identité de preview aux valeurs de l’environnement nommé et l’échec de maintenance au nom du binding d’identifiant. La correction a rétabli l’isolation de preview tout en conservant le comportement de live, l’état de santé public et l’autorisation côté serveur.

Les tests avec des identifiants absents, invalides, provenant de l’autre environnement et valides ont établi la limite de sécurité plus complètement qu’une seule réponse positive. Le nettoyage final a supprimé les processus locaux et les secrets synthétiques tout en conservant le projet corrigé.

✨ Vérifier la solution et pratiquer✨ Vérifier la solution et pratiquer