Aller au contenu principal

ClickHouse

GitGuardian utilise ClickHouse, une base de données open source orientée colonnes, pour alimenter les fonctionnalités qui nécessitent une analytique rapide sur de gros volumes de données (par exemple, l'analytique des occurrences de secrets pour les machines et les endpoints). PostgreSQL reste le datastore principal pour le reste de l'application ; ClickHouse n'intervient que pour les fonctionnalités spécifiques qui en ont besoin.

Obligatoire à partir de 2027.1

À partir de la version 2027.1.0, ClickHouse et son backend de stockage objet deviennent obligatoires pour chaque déploiement Self-Hosted. Consultez la note client pour savoir ce qui change et comment vous préparer.

Modèle de déploiement​

ClickHouse s'exécute en tant que composant stateful dédié au sein du cluster, et s'appuie sur un stockage objet externe (compatible S3, Azure Blob Storage ou Google Cloud Storage) pour le stockage durable des données. Ce n'est pas une base de données entièrement gérée en externe comme PostgreSQL ou Redis. Consultez Stockage ClickHouse pour plus de détails.

Topologie par défaut​

ClickHouse est déployé en tant que nœud unique. C'est l'option la plus simple et la plus légère, et elle suffit pour la grande majorité des déploiements, même si elle n'est pas hautement disponible : il n'y a pas d'autre réplica vers lequel basculer.

Version prise en charge​

GitGuardian épingle la version de ClickHouse livrée avec chaque release à la même version que celle qui fait tourner notre offre SaaS, et la valide avec notre suite de tests avant la release. N'essayez pas d'exécuter une version de ClickHouse différente de celle livrée avec votre release.

Stockage​

ClickHouse répartit son stockage en trois parties : les volumes locaux de métadonnées et de cache de système de fichiers, et le stockage objet qui contient les données réelles des tables, où réside l'essentiel de l'empreinte de stockage et où clickhouse-backup écrit lors des sauvegardes.

Consultez Stockage ClickHouse pour les volumes locaux et la configuration du stockage objet spécifique à chaque fournisseur, Dimensionnement et durcissement pour le dimensionnement matériel, Sauvegarde et restauration pour la procédure de sauvegarde, et Surveillance et alerting pour détecter une sauvegarde en échec que la santé du pod ne vous montrera pas.

Configuration requise​

Un déploiement ClickHouse prêt pour la production nécessite la configuration de tous les éléments suivants :

Que configurerDétailsOù
Dimensionnement et durcissement du calculRessources du nœud et de l'instance, planification, stabilité du nœudDimensionnement et durcissement
Identifiants ClickHouseMot de passe de l'instancePrérequis
Configuration du stockage objetBackend S3 / Azure Blob / GCS, authentification du disqueStockage → Configuration
Configuration des volumes au sein du clusterVolumes de métadonnées et de cache, storage classStockage → Volumes locaux
Configuration de la sauvegardeBucket de destination, secret d'identifiants, planification et rétentionSauvegarde et restauration

Prérequis​

Avant l'installation, le mot de passe admin de ClickHouse et le mot de passe de l'API locale du sidecar de sauvegarde doivent être transmis via un secret Kubernetes plutôt que définis en ligne dans les values, le même modèle utilisé partout dans GitGuardian Self-Hosted. Il peut être créé directement ou synchronisé depuis votre propre coffre de secrets. Consultez Gestion des informations sensibles Helm pour savoir comment le renseigner.

Si vous le créez directement :

kubectl create secret generic clickhouse-credentials \
  --namespace <namespace> \
  --from-literal=admin-password=<a-strong-password> \
  --from-literal=api-password=<a-strong-password> \
  --from-literal=api-username=<a-username>
Les trois clés sont requises : ne renommez ni n'omettez aucune d'entre elles

clickhouse-credentials, admin-password, api-password et api-username sont câblés dans les valeurs par défaut du chart sous ces noms exacts : admin-password via clickhouse.auth.existingSecret/existingSecretKey (GitGuardian dérive son propre CLICKHOUSE_PASSWORD du même secret), et api-password/api-username consommés directement par le sidecar de sauvegarde et son ServiceMonitor. Omettre ou renommer l'un des trois casse l'authentification propre à ClickHouse, le sidecar de sauvegarde, ou la connexion de GitGuardian à celui-ci, à moins que vous ne surchargiez également les values correspondantes.

Une fois le secret en place, activez ClickHouse lui-même :

clickhouse:
  enabled: true

Cela seul ne suffit pas pour un déploiement fonctionnel : le backend de stockage objet de ClickHouse n'a pas de valeur par défaut et doit être configuré pour votre fournisseur (voir Stockage ClickHouse), et la destination de sauvegarde nécessite la même chose avant que les sauvegardes puissent s'exécuter (voir Sauvegarde et restauration). Suivez les deux pages avant de considérer ClickHouse comme installé.

Exemple de configuration complète​

Les exemples ci-dessous assemblent les éléments de chaque page de configuration de cette section en un seul bloc de values clickhouse.

Tous les fournisseurs nécessitent également le secret clickhouse-credentials décrit dans Prérequis ci-dessus.

Suppose la configuration IRSA de Stockage → Configuration : un fournisseur OIDC IAM sur le cluster, et un rôle IAM approuvé pour le ServiceAccount clickhouse avec une politique couvrant les deux buckets.

clickhouse:
  enabled: true

  # Sizing and hardening (see Sizing → Hardware recommendations)
  resources: # Large tier shown; match your own tier, requests = limits
    requests:
      cpu: 8
      memory: 32Gi
    limits:
      cpu: 8
      memory: 32Gi
  podAnnotations:
    karpenter.sh/do-not-disrupt: 'true' # adjust for your cluster autoscaler
  nodeSelector: # assumes a dedicated on-demand node pool (see Sizing → Node stability)
    workload: clickhouse
  tolerations:
    - key: workload
      operator: Equal
      value: clickhouse
      effect: NoSchedule

  # Local volumes (see Storage → Local persistent volumes)
  persistence:
    storageClass: gp3
  cache:
    storageClass: gp3
    size: 100Gi # Large tier shown (see Sizing → Filesystem cache)

  # Data bucket, authenticated through IRSA (see Storage → Configuration)
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: 'arn:aws:iam::<account-id>:role/<role-name>'
  objectStorage:
    provider: s3
    s3:
      endpoint: 'https://<bucket-name>.s3.<region>.amazonaws.com'
      bucket: '<bucket-name>'
      region: '<region>'
      credentialless: true

  # Backup destination, a separate bucket (see Backup and restore → Object storage destination)
  backup:
    objectStorage:
      provider: s3
      s3:
        bucket: '<backup-bucket-name>'
        region: '<region>'
        prefix: 'backups'
        credentialless: true
Dernière mise à jour le

Il manque quelque chose ?

Voir notre feuille de route
S'abonner sur GitHub
Soumettre une demande
Statut de l’API