Installer ClickHouse

Pour savoir ce qu'est ClickHouse et ce qu'exige un déploiement en production, consultez la présentation de ClickHouse.

Prérequis

Avant l'installation, le mot de passe administrateur de ClickHouse et le mot de passe de l'API locale du backup sidecar doivent être transmis via un secret Kubernetes plutôt que définis directement dans les values, selon le même modèle utilisé dans tout 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 : n'en renommez et n'en omettez aucune

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 backup sidecar et son ServiceMonitor. Omettre ou renommer l'un de ces trois éléments casse l'authentification propre à ClickHouse, le backup sidecar ou la connexion de GitGuardian à celui-ci, sauf si vous remplacez également les valeurs correspondantes.

Activer ClickHouse

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 ces deux pages avant de considérer ClickHouse comme installé.

Exemple de configuration complet

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

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

AWS S3

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

Azure Blob Storage

Suppose la configuration Microsoft Entra Workload ID de Stockage → Configuration : l'émetteur OIDC et Workload Identity activés sur le cluster, une identité managée avec un identifiant fédéré pour le ServiceAccount clickhouse, et une affectation de rôle RBAC couvrant les deux conteneurs.

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:
    cluster-autoscaler.kubernetes.io/safe-to-evict: 'false' # 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: managed-csi-premium
  cache:
    storageClass: managed-csi-premium
    size: 100Gi # Large tier shown (see Sizing → Filesystem cache)

  # Data container, authenticated through Workload ID (see Storage → Configuration)
  serviceAccount:
    annotations:
      azure.workload.identity/client-id: '<identity-client-id>'
  podLabels:
    azure.workload.identity/use: 'true'
  objectStorage:
    provider: azblob
    azblob:
      storageAccountUrl: 'https://<storage-account-name>.blob.core.windows.net'
      containerName: '<container-name>'
      credentialless: true

  # Backup destination, a separate container (see Backup and restore → Object storage destination)
  backup:
    objectStorage:
      provider: azblob
      azblob:
        storageAccountName: '<storage-account-name>'
        containerName: '<backup-container-name>'
        prefix: 'backups'
        credentialless: true

GCS

Suppose les deux secrets d'identifiants de Stockage → Configuration et Sauvegarde et restauration : une paire de clés HMAC pour le disque propre à ClickHouse (clickhouse-gcs-credentials), et une clé JSON de compte de service native pour le backup sidecar (clickhouse-backup-gcs-credentials), qui ne peut pas utiliser HMAC.

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:
    cluster-autoscaler.kubernetes.io/safe-to-evict: 'false' # 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: premium-rwo
  cache:
    storageClass: premium-rwo
    size: 100Gi # Large tier shown (see Sizing → Filesystem cache)

  # Data bucket, via GCS's S3-compatible endpoint and an HMAC key pair (see Storage → Configuration)
  objectStorage:
    provider: gcs
    gcs:
      bucket: '<bucket-name>'
      existingSecret: clickhouse-gcs-credentials

  # Backup destination, a separate bucket and its own credential type (see Backup and restore)
  backup:
    objectStorage:
      provider: gcs
      gcs:
        bucket: '<backup-bucket-name>'
        prefix: 'backups'
        existingSecret: 'clickhouse-backup-gcs-credentials'

MinIO

Suppose les secrets d'identifiants statiques de Stockage → Configuration et Sauvegarde et restauration (clés access-key-id/secret-access-key ; une seule paire de clés MinIO peut servir aux deux).

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:
    cluster-autoscaler.kubernetes.io/safe-to-evict: 'false' # 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: '<ssd-backed-storage-class>'
  cache:
    storageClass: '<ssd-backed-storage-class>'
    size: 100Gi # Large tier shown (see Sizing → Filesystem cache)

  # Data bucket, path-style S3 with static keys (see Storage → Configuration)
  objectStorage:
    provider: s3
    s3:
      endpoint: 'http://<minio-host>:<minio-port>'
      bucket: '<bucket-name>'
      region: 'us-east-1' # MinIO ignores the value but the field is required
      forcePathStyle: true
      existingSecret: clickhouse-minio-credentials

  # Backup destination, a separate bucket (see Backup and restore → Object storage destination)
  backup:
    objectStorage:
      provider: s3
      s3:
        endpoint: 'http://<minio-host>:<minio-port>'
        bucket: '<backup-bucket-name>'
        region: 'us-east-1' # required by the S3 client even though MinIO ignores it
        prefix: 'backups'
        forcePathStyle: true
        existingSecret: 'clickhouse-backup-minio-credentials'
    config:
      extraVars:
        S3_DISABLE_SSL: 'true' # omit and use an https:// endpoint above instead if MinIO terminates TLS