Opérations

Cette page décrit les opérations après mise en service du ClickHouse Connector sur les deux cibles d’installation. Pour l’installation et l’onboarding, consultez l’onboarding.

Mettez à niveau la release depuis le repository public de charts, en réutilisant 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 0.9.0 correspond au tag v0.9.0). 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.

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 init nécessite toujours l’un de ses points 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).

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, sauvegarde le binaire précédent 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

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

Chaque démon expose un point de terminaison /livez sur son port de santé. Le champ JSON status du corps de la réponse indique l’état de santé, et non le code d’état HTTP ; vérifiez donc le corps plutôt que de vous fier à un code 200. Les métriques Prometheus sont exposées sur le port de métriques de chaque composant. Ports par défaut pour les deux cibles :

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, vous pouvez exécuter 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 (le point de terminaison de l’API et chaque instance ClickHouse), la connectivité à ClickHouse, l’état de l’unité systemd, l’accès à chaque composant, le disque et les motifs de masquage, puis renvoie 2 si l’une de ces vérifications échoue.

Le connecteur renouvelle automatiquement son certificat client : chaque démon vérifie le certificat terminal toutes les 12 heures et le renouvelle lorsqu’il lui reste 10 jours de validité. Il reçoit alors un certificat terminal valable 30 jours via le canal mTLS existant, authentifié par HMAC. Aucune intervention de l’opérateur n’est nécessaire. Dans Kubernetes, le certificat terminal renouvelé est réécrit dans le Secret clicklink-mtls ; sur une VM, il est é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

Demandez un nouveau jeton d’inscription à l’équipe chargée de votre compte ClickHouse, 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. 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

Recréez les utilisateurs en lecture seule du connecteur pour chaque instance. Dans Kubernetes, exécutez la commande 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, sur l’hôte :

sudo clicklink clctl scraper access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --force
sudo clicklink clctl troubleshoot access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --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.

Le renouvellement est automatique (voir certificats). Pour remplacer immédiatement un certificat encore valide, réexécutez init avec --force.

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 ; les identifiants et la chaîne de CA sont remplacés 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 connecteur est préservée, même avec --force.

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.

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 comme indiqué dans Téléchargement et vérification manuels, puis exécutez-le depuis le répertoire extrait :

sudo ./uninstall.sh

Cette opération arrête et désactive les services, puis supprime les unités systemd et le binaire, mais conserve /etc/clicklink, /var/lib/clicklink, /var/log/clicklink et l’utilisateur clicklink, afin qu’une réinstallation ultérieure puisse réutiliser la configuration existante. Pour les supprimer aussi :

sudo ./uninstall.sh --purge

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

Les Secrets créés par init ne sont pas gérés par le chart et sont conservés après la désinstallation. Supprimez-les explicitement, y compris les Secrets d’accès propres à chaque instance que vous avez configurée :

kubectl delete secret clicklink-hmac clicklink-mtls -n "${CONNECTOR_NAMESPACE}"
kubectl delete secret -n "${CONNECTOR_NAMESPACE}" \
  clicklink-connector-scraper-access-<instance> \
  clicklink-connector-troubleshooter-access-<instance>
kubectl delete serviceaccount -n "${CONNECTOR_NAMESPACE}" \
  pcm-scraper-<instance> pcm-troubleshooter-<instance>
# Repeat for every ClickHouse namespace that holds a provisioned instance.
for ns in <clickhouse-namespace-1> <clickhouse-namespace-2>; do
  kubectl delete serviceaccount,role,rolebinding -n "${ns}" \
    pcm-scraper pcm-troubleshooter
done

La désinstallation de l’une ou l’autre des cibles laisse les utilisateurs en lecture seule provisionnés en place. 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;