Référence de la CLI

Le connector est fourni sous la forme d’un unique binaire nommé clicklink ; les commandes à exécuter se trouvent sous clicklink clctl. Cette page présente les commandes utilisées lors de l’installation et des opérations quotidiennes. Exécutez n’importe quelle commande avec --help pour afficher son aide complète. Les flags des sous-arborescences troubleshoot et preflight peuvent également être fournis via les variables d’environnement CLCTL_* (dont le nom est indiqué dans l’aide de chaque flag) ou le fichier ~/.clicklink/clctl.yaml.

Initialise le connecteur à partir d’un jeton d’inscription, d’un bundle d’inscription enregistré ou d’un certificat signé transmis hors bande. Une seule exécution prépare la configuration, provisionne l’accès à ClickHouse, obtient le certificat client mTLS, effectue le déploiement (chart Helm ou unités systemd) et vérifie l’état de santé. Vous pouvez relancer la commande sans risque : la configuration et l’UUID du cluster sont conservés, les informations d’identification sont remplacées de façon atomique et une clé client existante est réutilisée, sauf si vous spécifiez --force. Consultez l’onboarding pour connaître le processus complet.

Un seul des trois points d'entrée est obligatoire ; ils s'excluent mutuellement.

Valables uniquement avec --target helm.

Valable uniquement avec --target systemd.

• --handoff, --enroll et --signed-cert s’excluent mutuellement ; un seul doit être spécifié.
• Les indicateurs propres à Kubernetes sont rejetés sauf avec --target helm ; --server et --ca-data sont rejetés avec --target helm (le processus Helm lit le kubeconfig du poste de travail).
• --no-auto-sign et --sign-endpoint s’excluent mutuellement, et tous deux (ainsi que --api-private-ca) sont rejetés avec --signed-cert.
• --operators et --no-gateway s’excluent mutuellement.
• --skip-provision rejette --ch-pod, --ch-user-suffix, --server, --ca-data et --ch-admin-password-stdin (aucun provisionnement n’est effectué).

Exécute la suite de vérifications du connecteur, regroupées par catégorie : configuration, fichiers, réseau, ClickHouse, systemd, accès, disque, masquage. Chaque vérification indique une réussite, un avertissement, un échec ou une omission. Le code de sortie 0 signifie que toutes les vérifications ont réussi (les avertissements ne sont pas bloquants) ; le code de sortie 2 signifie qu'une ou plusieurs vérifications ont échoué.

Par défaut, la commande s'exécute localement. Avec --k8s-namespace, elle exécute le binaire du connecteur dans son propre pod via kubectl exec et affiche le rapport localement (les vérifications systemd sont toujours ignorées dans les pods). Avec les options du canal distant, elle exécute à la place le binaire installé sur une VM distante.

Les options --k8s-* et les options du canal distant s'excluent mutuellement ; choisissez une cible.

Active, désactive et inspecte la session de support : la période limitée pendant laquelle le composant de dépannage accepte les commandes. Lorsqu'aucune session n'est active, le démon refuse toutes les commandes, même lorsque son WebSocket est connecté. Consultez les sessions de support.

Les commandes fonctionnent dans l'un des deux modes suivants :

• Fichier local (par défaut) : lit et écrit le fichier d'état de session sur l'hôte sur lequel le composant de dépannage s'exécute (par défaut, /var/lib/clicklink/session.json).
• Gateway : avec --gateway-url, obtient un jeton d'ID OIDC et appelle à la place la gateway de session du composant de dépannage depuis votre poste de travail.

L’activation échoue si une session est déjà active ; désactivez-la d’abord ou attendez qu’elle expire.

Désactive immédiatement la session. Cette commande est sans effet lorsqu’aucune session n’est active.

Indique si la session est active, qui l’a activée et à quelle date elle expire. --output (-o) sélectionne table (par défaut) ou json.

Sur Kubernetes, accédez à la passerelle à l’aide d’un transfert de port :

kubectl -n <connector-namespace> port-forward \
  statefulset/clicklink-connector-troubleshooter 8443:8443
clicklink clctl troubleshoot session enable \
  --gateway-url http://localhost:8443 \
  --duration 1h --reason "support ticket 1234"

Sur une VM, la passerelle de session utilise un certificat TLS auto-signé. Cette commande enregistre l’empreinte SHA-256 du certificat dans ~/.clicklink/clctl.yaml afin que les commandes session puissent le vérifier ; si une empreinte épinglée ne correspond plus, la vérification échoue de manière sécurisée. La relation de confiance est établie hors bande de l’une des deux manières suivantes :

• Avec les options du canal distant, le certificat est lu directement sur la VM via le canal déjà authentifié, puis épinglé.
• Sans canal, transmettez --gateway-fingerprint avec la valeur SHA-256 journalisée par le connecteur lors de la génération du certificat ; le certificat récupéré n’est épinglé que s’il correspond. Si vous omettez l’option, l’empreinte présentée s’affiche sans qu’aucune empreinte ne soit épinglée.

clicklink clctl troubleshoot gateway trust \
  --gateway-url https://<vm-host>:8443 \
  --gateway-fingerprint <sha256-from-connector-log>

Sur Kubernetes, le pinning n’est pas utilisé : exposez la passerelle via un Ingress avec un certificat émis par une CA, ou utilisez un port-forward.

Affiche les dernières entrées du journal d’audit de l’utilitaire de dépannage : JSON délimité par des sauts de ligne, avec une entrée pour chaque commande acceptée ou bloquée par le démon. La commande ouvre le journal en lecture seule et ne le modifie jamais.

L’image d’exécution du connecteur ne contient pas de shell ; sur Kubernetes, cette commande est donc le lecteur pris en charge :

kubectl -n <connector-namespace> exec <troubleshooter-pod> -- \
  /clicklink clctl troubleshoot audit tail

clicklink clctl scraper access provision et clicklink clctl troubleshoot access provision créent et, avec --force, renouvellent le bundle d'accès par instance d'un composant : l'utilisateur ClickHouse en lecture seule et ses privilèges, ainsi que le ServiceAccount Kubernetes, les RBAC et le jeton utilisés par le composant. init exécute cette opération directement lors de l'installation ; les commandes autonomes permettent de la relancer ou de renouveler les identifiants.

Renouvelez les identifiants d'une instance pour un composant :

clicklink clctl scraper access provision --target helm \
  --target-namespace <connector-namespace> \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force

preflight, gateway trust et access provision acceptent un ensemble commun d'options qui déterminent comment accéder à une VM cible :