Diagnostics Customer Edge
Un Customer Edge (CE) est le nœud F5 Distributed Cloud que ce dépôt provisionne dans
Azure — terraform/modules/ce-node, construit à partir de l’image de place de marché
volterraedgeservices/volterra-node.
Il exécute le plan de données (Argo), le plan de contrôle (Vega), un proxy Envoy, une pile
Kubernetes et vpm, l’agent qui enregistre le nœud et gère tout le reste sur
celui-ci.
Lorsqu’un CE dysfonctionne, la Site CLI est l’instrument à utiliser. La première décision consiste à déterminer quel chemin d’accès s’applique, et se tromper fait perdre du temps d’une manière qui donne l’impression d’un nœud défaillant.
Quatre chemins d’accès, et ils ne sont pas interchangeables
Section intitulée « Quatre chemins d’accès, et ils ne sont pas interchangeables »ONLINE. Scriptable, en lecture seule, et couvre 34 commandes.La debug API atteint le nœud via le plan de contrôle F5 Distributed Cloud.
C’est toute la raison pour laquelle cette distinction importe : l’API ne peut répondre
qu’une fois le nœud enregistré et signalé ONLINE.
Un nœud qui n’a pas réussi à s’enregistrer — cloud-init incorrect, jeton expiré, absence de
route vers register.ves.volterra.io — correspond précisément au cas où vous avez besoin de
diagnostics, et précisément au cas que l’API ne peut pas traiter.
Site Console est l’option à essayer en premier lorsque vous souhaitez
l’interface de dépannage propre à F5 plutôt que des commandes spécifiques. C’est celle qui exige
le moins de vous — aucune clé, aucun hôte de rebond, aucune IP publique sur le nœud — car la
question de savoir qui peut se connecter devient une décision Azure RBAC, et elle répond que le
site soit enregistré ou non. Elle nécessite Azure Bastion, que ce déploiement conditionne à
enable_bastion et qui n’est pas déployé par défaut.
SSH est la seule voie qui atteint la totalité de la surface de commandes de
l’appliance — la debug API expose 34 commandes et le nœud lui-même en offre bien davantage. Deux
éléments la contraignent. sshd ne répond que sur l’adresse interne (SLI) du nœud, il faut donc
un hôte au sein du VNet ; et la clé est écrite par cloud-init au premier démarrage, car le champ
ssh_key de l’objet site est inerte — vpm ignore l’utilisateur admin et ne l’applique jamais.
L’activer sur des nœuds en fonctionnement implique donc de les remplacer.
Donc : si le site est ONLINE et que 34 commandes suffisent, utilisez la debug API. Pour une
interface, ou pour un nœud qui ne s’est jamais enregistré mais qui conserve un chemin réseau,
utilisez Site Console. Si vous avez besoin du reste de la surface de commandes et que vous pouvez
atteindre le VNet, utilisez SSH. Si le nœud n’a aucun chemin réseau fonctionnel, la console série
est la seule entrée possible.
Règles de sécurité
Section intitulée « Règles de sécurité »Elles s’appliquent à toutes les commandes de chacune des pages ci-dessous.
- Lecture seule sauf si vous êtes certain. La surface de commandes est répartie en deux
niveaux de privilèges, et le niveau
Execmodifie le nœud ou lit un marqueur d’état. Rien sur ces pages n’exécute une commandeExec, et le harnais de capture n’en exécute pas davantage. - Ne présumez jamais qu’une commande est sûre d’après son nom.
ip-link-setse lit comme une requête et désactive une interface.systemctl-restart-crioredémarre le runtime de conteneurs sous un plan de données actif. - Préférez la commande la plus restreinte qui réponde à la question.
healthetdiagnosisrésument le nœud à faible coût ;flow-lvide tous les flux actifs, etflow-l-matchrépond à la même question pour une seule connexion. - Un CE sert du trafic réel. Il s’agit d’environnements de démonstration partagés. Supposez que quelqu’un est en train de présenter depuis le site que vous déboguez.
Ce qui est documenté ici
Section intitulée « Ce qui est documenté ici »Toutes les commandes accessibles via la debug API sur la version logicielle utilisée par ce tenant, chacune accompagnée d’une sortie capturée sur un nœud réel plutôt que transcrite d’ailleurs.
La référence des commandes les répertorie toutes avec leur catégorie, leur niveau de privilèges et leur transport ; les workflows les enchaînent dans les séquences que vous utilisez réellement lorsque quelque chose ne va pas.
Les parties de la Site CLI accessibles uniquement sur la machine — configure, configure-network,
factory-reset, upgrade et environ soixante autres commandes ExecCLI — ne sont pas
couvertes, car leur sortie n’a pas été capturée depuis un nœud réel comme l’a été celle de chaque
page ci-dessous.
Elles ne sont toutefois plus hors de portée. scripts/sitecli_ssh_harvest.py pilote le
menu de complétion de l’appliance via SSH et enregistre la description que
l’appliance fournit pour chaque commande, de sorte que la surface peut être mesurée plutôt que
devinée. Son exécution est refusée par défaut — elle énumère tout et n’exécute qu’une liste
d’autorisation — car une syntaxe de commande non vérifiée, et des effets de commande non vérifiés,
constituent le défaut que cette documentation existe pour éviter de reproduire.