Un site qui n'est jamais passé en ligne

Capturé le 2026-07-28 depuis un CE de ce déploiement. sitecli/capture-manifest.json indique quel nœud, et scripts/capture-sitecli.sh --check revérifie la surface de commandes contre un CE actif.

L'API ne peut pas déboguer ceci

L’API de débogage atteint le nœud via le plan de contrôle F5 Distributed Cloud, à travers le tunnel que l’enregistrement établit. Si l’enregistrement a échoué, il n’y a pas de tunnel, donc toutes les commandes de ce site sont indisponibles pour cette défaillance précise. Travaillez depuis la Console du site si le nœud dispose encore d’un chemin réseau, et depuis la console série si ce n’est pas le cas.

1. Vérifiez que vous interrogez le bon tenant. Cela coûte une seule commande et vient en premier parce qu’une erreur ici fausse toutes les étapes suivantes : une flotte saine dans le tenant que vous ne regardez pas est indiscernable d’une flotte qui ne s’est jamais enregistrée.

   cd terraform
   terraform output -raw xc_tenant       # the tenant this deployment belongs to
   terraform output -raw xc_env_tenant   # the tenant your shell is exporting

   f5-sales-demo
   f5-sales-demo

   Discordance, ou un identifiant que vous croyez valide renvoyant un simple 401 ? C’est le symptôme d’un jeton généré pour un autre tenant, et cela a déjà coûté à ce déploiement une reconstruction complète (issue 696).

2. Vérifiez ce que pense le tenant. Être absent de la liste des sites est un problème différent d’être présent mais pas ONLINE.

   curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
     "$XCSH_API_URL/api/config/namespaces/system/sites" | jq -r '.items[].name'

   Si le site existe et signale ONLINE, l’enregistrement a réussi et vous êtes dans le mauvais workflow.

3. Trouvez l’enregistrement du site et son état. Un nœud peut s’enregistrer puis attendre une approbation, ce qui, vu de l’extérieur, ressemble exactement à un échec.

   curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
     "$XCSH_API_URL/api/register/namespaces/system/registrations_by_site/<site>" \
     | jq -r '.items[] | "\(.name)  \(.object.status.current_state)  \(.object.spec.gc_spec.infra.hostname)"'

   r-a97e20c8-b7e1-483d-bd76-34a64ff8bc78  ONLINE  f5-xc-ce-vm-01

   Aucun élément du tout signifie que le nœud ne s’est pas encore enregistré — passez à la console série. Un élément dans un état autre que ONLINE signifie qu’il s’est enregistré et que quelque chose ensuite a échoué, ce qui constitue une autre investigation.

   Pour balayer l’ensemble du namespace à la recherche de tout ce qui attend une approbation, listregistrationsbystate prend l’état dans un corps POST :

   curl -sS -X POST -H "Authorization: APIToken $XCSH_API_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"namespace":"system","state":"PENDING"}' \
     "$XCSH_API_URL/api/register/namespaces/system/listregistrationsbystate" | jq -r '.items[].name'

   Sur une flotte saine, cela ne renvoie rien, car l’approbation est automatisée.

4. Vérifiez que la VM est réellement en cours d’exécution, avant de supposer une panne logicielle.

   az vm list -d -g <resource-group> --query "[].{name:name,power:powerState}" -o table

   Name              Power
   ----------------  ----------
   f5-xc-ce-vm-01    VM running
   f5-xc-ce-vm-02    VM running
   f5-xc-ce-vm-03    VM running
   mcn-ce-ha-client  VM running

5. Attachez la console série. De manière interactive, cela nécessite un véritable terminal ; l’attachement lui-même peut être scripté via le websocket — voir console série.

   az serial-console connect -g <resource-group> -n <vm-name>

   En cas de refus, vérifiez que les diagnostics de démarrage sont activés sur la VM avant de conclure que le nœud est inaccessible ; ce prérequis et ses modes de défaillance sont traités sur la page console série.

6. Lisez ce que la console affiche, dans cet ordre. cloud-init d’abord — un nœud dont cloud-init ne s’est jamais terminé n’a aucune configuration avec laquelle s’enregistrer. Puis les tentatives d’enregistrement elles-mêmes, puis le DNS : si le nœud ne peut pas résoudre register.ves.volterra.io, rien en aval ne peut fonctionner.

7. Une fois le nœud ONLINE, vérifiez avec health et attendez-vous à state: PROVISIONED.

Un enregistrement est nommé d'après un UUID, jamais d'après son site

Les enregistrements sont nommés r-<uuid>, et il n’existe aucun point de terminaison acceptant un nom de site là où un nom d’enregistrement est attendu. GET .../registrations/<site> renvoie 404, ce qui se lit comme « ce site n’a aucun enregistrement » alors que cela signifie en réalité « ce n’est pas un nom d’enregistrement ». La correspondance site-vers-enregistrement ne vient que de registrations_by_site/<site>, comme à l’étape 3, ou en listant registrations et en faisant correspondre gc_spec.passport.cluster_name.

Le même piège a donné l’impression qu’une flotte saine n’avait aucun enregistrement.

Les causes habituelles

• Vous visez le mauvais tenant, donc une flotte en bon état semble absente. Étape 1.
• cloud-init ne s’est pas terminé, donc /etc/vpm/config.yaml est absent ou incorrect.
• Le jeton d’enregistrement est expiré, déjà consommé, ou provient d’un autre tenant.
• Aucune route de sortie vers register.ves.volterra.io.
• Une dérive d’horloge suffisamment importante pour invalider les certificats — rapide à écarter plus tard avec chronyc-sources, mais inaccessible tant que le nœud n’est pas en ligne. La bannière de connexion SSH indique NTP: Synced et l’état du résolveur avant même que vous n’exécutiez quoi que ce soit, lorsque SSH est disponible.