Opérations

Cette page décrit les opérations après mise en service du connector sur les deux cibles d’installation. Pour l’installation et l’inscription, consultez l’onboarding. L’exploitation des services eux-mêmes (création, scale, suppression et mises à jour de la plateforme) est traitée dans services managés et mises à jour de la plateforme.

Mises à niveau

Kubernetes

Les opérations Kubernetes post-déploiement utilisent la CLI helm sur votre poste de travail. Seul init inclut un client Helm intégré ; installez donc helm avant votre première mise à niveau.

Mettez à niveau la release depuis le repository public de charts avec la surcouche de valeurs préparée par init :

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm upgrade --install clicklink-connector clicklink-connector \
  --repo https://releases.clicklink.clickhouse.com/charts \
  --version <version> \
  -n "${CONNECTOR_NAMESPACE}" \
  -f clicklink-values.yaml

Les versions du chart correspondent aux tags de release sans le préfixe v (le chart X.Y.Z correspond au tag vX.Y.Z). Le chart publié pointe déjà vers l’image de conteneur publique. Les installations et mises à niveau standard ne nécessitent donc aucune valeur d’image. Pour consulter les valeurs par défaut du chart, exécutez helm show values clicklink-connector --repo https://releases.clicklink.clickhouse.com/charts. L’executor s’exécute sous la forme d’une réplique unique avec la strategy Recreate ; une mise à niveau le déconnecte donc brièvement. Voir quand le connector est hors ligne pour savoir ce qu’il advient des commandes durant cette window. Une installation à partir d’une référence directe au chart (oci://, une URL, une archive locale ou un répertoire local) n’est associée à aucun repository à partir duquel résoudre le chart. Exécutez plutôt helm upgrade clicklink-connector <same-chart-reference> avec la nouvelle version. Réexécuter init avec une CLI plus récente permet également d’aboutir au même résultat, mais nécessite un point d’entrée : --handoff si vous avez conservé le bundle, ou un nouveau jeton d’inscription avec --force après le nettoyage documenté. La commande helm upgrade ci-dessus est la procédure habituelle (voir réexécutions et récupération).

VM Linux

Réexécutez le programme d’installation sur l’hôte. Il télécharge et vérifie la nouvelle version comme lors de l’onboarding. Il sauvegarde le binaire précédent, installe les unités systemd actuelles et préserve vos motifs de masquage actifs ainsi que votre fichier d’environnement. Redémarrez ensuite les démons :

curl -fsSL https://releases.clicklink.clickhouse.com/install.sh | sudo bash -s -- --host
sudo systemctl restart clicklink-scraper clicklink-troubleshooter clicklink-executor

Pour installer une version spécifique plutôt que la plus récente, ajoutez --version vX.Y.Z à la commande d’installation.

État de santé

Chaque démon expose un point de terminaison /livez sur son port de santé. Le signal de santé est le champ JSON status du corps de la réponse, et non le code d’état HTTP. Les métriques Prometheus sont exposées sur /metrics sur le même port ; il n’y a pas de port de métriques distinct. Ports par défaut pour les deux cibles :

Composant	Port de santé
Scraper	8082
Troubleshooter	8084
Executor	8086

L’executor expose également son API de commandes locale sur 127.0.0.1:9999. Elle ne dispose d’aucune authentification propre et n’est jamais exposée en dehors de l’hôte ou du pod ; les commandes de service clicklink clctl l’atteignent en local. Lorsque les sessions d’assistance sont activées, la passerelle écoute également sur le port 8443 : TLS auto-signé sur une VM, HTTP local au pod via kubectl port-forward ou un Ingress Kubernetes assurant la terminaison TLS. Sur une VM, exécutez l’ensemble complet des vérifications à tout moment :

sudo clicklink clctl preflight

Il vérifie la configuration, les fichiers, les conflits de ports, l’accessibilité réseau, la connectivité à ClickHouse, l’état de l’unité systemd, l’accès à chaque composant, le disque et les motifs de masquage. Il renvoie 2 si l’une de ces vérifications échoue.

Certificats

Le connecteur renouvelle automatiquement son certificat client. Le scraper, le troubleshooter et l’executor vérifient chacun le certificat terminal toutes les 12 heures et le renouvellent lorsqu’il lui reste 10 jours de validité. Le renouvellement renvoie un certificat terminal valable 30 jours via le canal mTLS existant, authentifié par HMAC ; aucune intervention de l’opérateur n’est donc nécessaire. Dans Kubernetes, le démon réécrit le certificat terminal renouvelé dans le Secret clicklink-mtls ; sur une VM, il l’écrit dans /etc/clicklink/tls/. Pour vérifier la date d’expiration actuelle :

# Linux VM
sudo openssl x509 -in /etc/clicklink/tls/client.crt -noout -enddate

# Kubernetes
CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
kubectl get secret clicklink-mtls -n "${CONNECTOR_NAMESPACE}" -o jsonpath='{.data.tls\.crt}' \
  | base64 -d | openssl x509 -noout -enddate

Rotation des identifiants

Identifiants API (HMAC)

Demandez un nouveau jeton d’inscription à l’équipe chargée de votre compte, puis réexécutez votre commande init initiale avec --enroll et --force. Conservez tous les indicateurs spécifiques à la cible utilisés lors de la première installation (--target-namespace, --values, ainsi que les éventuels indicateurs de miroir --chart, --chart-repo ou --chart-version), car --force restaure la configuration conservée. Le mode Managed est repris de la configuration remplacée, --managed est donc facultatif ici. Pour une installation par défaut :

# Kubernetes, from your workstation
clicklink clctl init --enroll https://<subdomain>.<connector-domain> --target helm --force

# Linux VM, on the host
sudo clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force

Sur une VM, init active et démarre uniquement les unités qui ne sont pas encore en cours d’exécution ; redémarrez donc les démons après la rotation :

sudo systemctl restart clicklink-scraper clicklink-troubleshooter clicklink-executor

Sur Kubernetes, init crée à l’avance les Secrets clicklink-hmac et clicklink-mtls renouvelés ; le chart ne les génère pas. Son annotation de checksum ne les couvre pas, si bien que les pods en cours d’exécution conservent les identifiants avec lesquels ils ont démarré. Redémarrez chaque composant après la rotation :

kubectl rollout restart deployment,statefulset -n "${CONNECTOR_NAMESPACE}" \
  -l app.kubernetes.io/part-of=clicklink-connector

Pour une rotation automatisée nécessitant un mot de passe pour le provisionnement SQL, stdin transmet les deux secrets dans l’ordre : le jeton sur la première ligne, le mot de passe sur la seconde. La lecture du jeton consomme exactement une ligne.

printf '%s\n' "$ENROLLMENT_TOKEN" "$CH_ADMIN_PASSWORD" | \
  clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force --ch-admin-password-stdin

Utilisateurs ClickHouse

Recréez les utilisateurs en lecture seule du connector pour chaque instance que vous avez enregistrée vous-même. Dans Kubernetes, exécutez les commandes depuis votre poste de travail. --apply-ch-grants réapplique les privilèges régénérés dans le pod afin que les nouvelles informations d’identification parviennent à ClickHouse ; si l’utilisateur administrateur a un mot de passe, ajoutez --ch-admin-password-stdin et fournissez-le via un pipe :

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
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
clicklink clctl troubleshoot 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

Sur une VM, exécutez-les sur l’hôte en fournissant le mot de passe administrateur via un pipe ; dans ce cas, le mot de passe est obligatoire sauf si vous passez --ch-user-via cr :

printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl scraper access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --ch-admin-password-stdin --force
printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl troubleshoot access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --ch-admin-password-stdin --force

Pour les instances gérées par l’opérateur, ajoutez --ch-user-via cr et les options de sélection des pods à l’une ou l’autre syntaxe ; consultez la référence de la CLI.

Certificat client

Le renouvellement est automatique (voir certificats). Pour remplacer immédiatement un certificat encore valide, réexécutez init avec --force. Redémarrez ensuite chaque composant afin que les démons présentent le nouveau certificat terminal : sur Kubernetes, comme décrit à la section identifiant d’API ; sur une VM, les trois unités.

Réexécutions et récupération

Les réexécutions de init convergent : la première chose à faire est donc toujours de relancer la même commande. Sans --force, le fichier /etc/clicklink/config.yaml (VM) ou la surcouche clicklink-values.yaml (Kubernetes) existant est conservé, et une clé client existante est réutilisée ; init remplace les identifiants et la chaîne de CA de manière atomique. Les commandes de récupération affichées par la CLI après un échec partiel peuvent être exécutées à nouveau sans risque. --force remplace la configuration ou la surcouche conservée, régénère la clé client et remplace un certificat client non expiré. Il ne génère jamais de nouvel UUID de cluster : l’identité du connector est donc préservée. La posture du mode managé de la configuration remplacée est conservée lors des réexécutions non interactives et proposée comme valeur par défaut sur un terminal, sauf si vous passez --managed ou --no-managed. Si la signature du certificat a échoué après la phase de préparation, ou si le point de terminaison de signature a renvoyé 409 parce qu’un certificat non expiré existe déjà, vous n’avez besoin ni d’un nouveau jeton ni d’une seconde émission. Terminez l’installation avec les éléments signés déjà présents sur le disque :

sudo clicklink clctl init --signed-cert client.crt --chain ca-chain.crt

Il s’agit du format pour VM (root réécrit /etc/clicklink et gère les services). Sur Kubernetes, la CLI affiche le format complet, y compris --target helm, --target-namespace et --values ; utilisez la commande affichée telle quelle. Connector hors ligne. Lorsque le connector est arrêté ou injoignable, les services qu’il gère continuent de fonctionner. Le ClickHouse Operator de votre cluster les maintient actifs, et l’executor ne se trouve pas sur le data path. Les changements de cycle de vie nécessitent que l’executor soit connecté : aucun n’est donc appliqué tant qu’il ne s’est pas reconnecté. Au redémarrage, l’executor récupère depuis sa base de données de commandes celles qui étaient en cours. Une commande que ClickHouse Cloud transmet de nouveau reçoit une réponse issue du résultat enregistré ; seule une commande ayant échoué est réexécutée. Pour les commandes de cycle de vie lorsqu’aucun executor n’est connecté, consultez lorsque le connector est hors ligne.

Désinstallation

Supprimez chaque service managé avant de désinstaller, en suivant supprimer un service, et attendez la fin de chaque suppression. Si vous supprimez le connector en premier, les services se retrouvent sans aucun component capable de gérer leur cycle de vie.

VM Linux

uninstall.sh est inclus dans l’archive tar de la version. Si aucune archive tar extraite ne se trouve encore sur l’hôte, téléchargez-en et extrayez-en une (voir Téléchargement et vérification manuels). Exécutez uninstall.sh depuis le répertoire extrait :

sudo ./uninstall.sh

Cette opération arrête et désactive les unités clicklink-scraper, clicklink-troubleshooter et clicklink-executor, puis supprime les unités systemd et le binaire. Elle conserve les éléments suivants, afin qu’une réinstallation ultérieure puisse réutiliser la configuration existante :

/etc/clicklink, y compris les ensembles d’accès de l’executor sous /etc/clicklink/access/executor
/var/lib/clicklink, y compris la base de données de commandes de l’executor executor.db et le registre de services
/var/log/clicklink
l’utilisateur clicklink

Pour les supprimer aussi :

sudo ./uninstall.sh --purge

Le grant à l’échelle du cluster de l’executor réside dans votre cluster, et non sur l’hôte. Supprimez-le en tant qu’admin du cluster une fois qu’il ne reste plus aucun service managé :

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n clicklink-system

Le grant a également créé le namespace clicklink-system ; supprimez-le lorsque plus rien ne l’utilise.

Kubernetes

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm uninstall clicklink-connector -n "${CONNECTOR_NAMESPACE}"

Le PersistentVolumeClaim de l’executor porte l’annotation helm.sh/resource-policy: keep : la désinstallation le conserve donc, avec la base de données de commandes et le registre de services qu’il contient. Les Secrets créés par init, le Secret du platform bundle écrit par platform approve et le ConfigMap du registre de services maintenu par l’executor n’appartiennent pas non plus au chart et survivent eux aussi à la désinstallation. Supprimez-les explicitement. Incluez la paire Secret d’accès / ServiceAccount de chaque instance que vous avez enregistrée vous-même, et de chaque service managé pour lequel vous avez provisionné le troubleshooter (nommée d’après le service). --ignore-not-found couvre les objects qui n’ont jamais été créés, comme le Secret du platform bundle avant une première approbation :

kubectl delete pvc -n "${CONNECTOR_NAMESPACE}" -l app.kubernetes.io/instance=clicklink-connector --ignore-not-found
kubectl delete secret clicklink-hmac clicklink-mtls clicklink-platform-bundle -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete configmap clicklink-instance-registry -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete secret -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  clicklink-connector-scraper-access-<instance> \
  clicklink-connector-troubleshooter-access-<instance>
kubectl delete serviceaccount -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  pcm-scraper-<instance> pcm-troubleshooter-<instance>
# Repeat for every ClickHouse namespace that holds an instance you registered yourself;
# a managed service's namespace went away with the service.
for ns in <clickhouse-namespace-1> <clickhouse-namespace-2>; do
  kubectl delete serviceaccount,role,rolebinding -n "${ns}" --ignore-not-found \
    pcm-scraper pcm-troubleshooter
done

init a appliqué le grant cluster-wide de l’executor, et non celui du chart. Supprimez-le en tant qu’admin du cluster une fois qu’il ne reste plus aucun service managé :

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n "${CONNECTOR_NAMESPACE}"

La couche plateforme

La désinstallation du connector ne supprime pas la couche plateforme. Les namespaces et charges de travail de la plateforme, le RBAC pcm-platform ainsi que les objects d’admission installés par vos approbations restent dans le cluster, tout comme l’ensemble des services managés. Supprimez d’abord les services ; voir supprimer un service. Sur un cluster de test dépourvu de services, clicklink clctl platform reset désinstalle les releases de la plateforme. Les CustomResourceDefinitions, le RBAC et la StorageClass qu’elle laisse subsister doivent être supprimés manuellement ; voir réinitialiser un cluster de test. En dehors d’un cluster de test, convenez d’un plan de suppression avec votre account team avant toute intervention sur la couche plateforme.

Utilisateurs ClickHouse

La désinstallation de l’une ou l’autre des cibles laisse les utilisateurs en lecture seule provisionnés en place sur les instances que vous avez enregistrées vous-même. Supprimez-les en tant qu’administrateur sur chaque instance (ajoutez votre --ch-user-suffix aux noms si vous en avez défini un) :

DROP USER IF EXISTS pcm_scraper, pcm_troubleshooter;

Premiers pas

Services et infrastructure

Bring Your Own Cloud

Données et intégrations

Se connecter et exécuter des requêtes

Gestion des accès

Sécurité et conformité

Supervision et sauvegardes

Outils et agents d’IA

API Cloud

Facturation

Assistance

ClickHouse Private

Mises à niveau

Kubernetes

VM Linux

État de santé

Certificats

Rotation des identifiants

Identifiants API (HMAC)

Utilisateurs ClickHouse

Certificat client

Réexécutions et récupération

Désinstallation

VM Linux

Kubernetes

La couche plateforme

Utilisateurs ClickHouse

​Mises à niveau

​Kubernetes

​VM Linux

​État de santé

​Certificats

​Rotation des identifiants

​Identifiants API (HMAC)

​Utilisateurs ClickHouse

​Certificat client

​Réexécutions et récupération

​Désinstallation

​VM Linux

​Kubernetes

​La couche plateforme

​Utilisateurs ClickHouse

Mises à niveau

Kubernetes

VM Linux

État de santé

Certificats

Rotation des identifiants

Identifiants API (HMAC)

Utilisateurs ClickHouse

Certificat client

Réexécutions et récupération

Désinstallation

VM Linux

Kubernetes

La couche plateforme

Utilisateurs ClickHouse