Skip to main content

Qu’est-ce que l’onboarding standard ?

L’onboarding standard est le workflow guidé par défaut pour déployer ClickHouse dans votre propre compte cloud avec BYOC. Dans cette approche, ClickHouse Cloud provisionne toutes les ressources cloud de base nécessaires à votre déploiement — comme le VPC/VNet, les sous-réseaux, les groupes de sécurité, le cluster Kubernetes (EKS/GKE/AKS), ainsi que les rôles IAM/comptes de service/principaux de service associés — dans votre compte AWS, votre projet GCP ou votre abonnement Azure. Cela garantit une configuration cohérente et sécurisée, tout en réduisant au minimum les interventions manuelles de votre équipe. Avec l’onboarding standard, il vous suffit de fournir un compte AWS, un projet GCP ou un abonnement Azure dédié, puis d’exécuter une stack initiale (via CloudFormation ou Terraform) afin de créer le minimum de permissions et de relations de confiance nécessaire pour permettre à ClickHouse Cloud d’orchestrer la suite de la configuration. Toutes les étapes suivantes — y compris le provisionnement de l’infrastructure et le lancement du service — sont gérées depuis la console web ClickHouse Cloud. Il est fortement recommandé aux clients de préparer un compte AWS, un projet GCP ou un abonnement Azure dédié pour héberger le déploiement BYOC de ClickHouse, afin de garantir une meilleure isolation des permissions et des ressources. ClickHouse déploiera un ensemble dédié de ressources cloud (VPC/VNet, cluster Kubernetes, rôles IAM/comptes de service/principaux de service, buckets de stockage objet, etc.) dans votre compte. Si vous avez besoin d’une configuration plus personnalisée (par exemple, pour déployer dans un VPC existant), consultez la documentation Customized Onboarding.
Un onboarding BYOC standard prend environ 45 à 90 minutes de bout en bout, entre le lancement des étapes CloudFormation ou Terraform et le moment où le premier service ClickHouse devient accessible.

Demander l’accès

Pour démarrer le processus d’onboarding, veuillez nous contacter. Notre équipe vous guidera dans les exigences du BYOC, vous aidera à choisir les options de déploiement les plus adaptées et ajoutera votre compte à la liste d’autorisation.

onboarding

Préparer un compte AWS/projet GCP/abonnement Azure

Préparez un nouveau compte AWS, un projet GCP ou un abonnement Azure au sein de votre organisation.
1

Choisissez un fournisseur de services cloud

2

Configuration du compte, du projet ou de l’abonnement

La configuration initiale de BYOC peut être effectuée à l’aide d’un modèle CloudFormation (AWS), d’un module Terraform (GCP) ou d’un module Terraform (Azure). Elle crée une identité hautement privilégiée (rôle IAM/compte de service/principal de service), permettant aux contrôleurs BYOC de ClickHouse Cloud de gérer votre infrastructure.
Appliquez les artefacts d’onboarding exactement tels qu’ils sont fournis. Ne modifiez rien dans le modèle CloudFormation ou le module Terraform — notamment en renommant des ressources ou en ajoutant des paramètres tels que PermissionsBoundary — sans l’accord explicite de ClickHouse. L’automatisation de ClickHouse dépend des ressources exactes créées par ces artefacts ; les personnalisations prises en charge sont exposées sous forme de paramètres. En particulier, sur AWS, le rôle IAM doit conserver son nom par défaut, ClickHouseManagementRole — sans préfixe ni suffixe — sauf si ClickHouse a explicitement accepté au préalable un autre nom. Le module Terraform expose techniquement une entrée role_name, mais l’automatisation de ClickHouse doit être configurée en conséquence ; la modifier sans coordination (ou renommer le rôle dans le modèle CloudFormation, qui ne propose pas ce paramètre) crée une pile qui s’applique correctement, mais dont le provisionnement de l’infrastructure échoue, car ClickHouse ne peut pas assumer le rôle attendu.
Les buckets de stockage, le VPC/VNet, le cluster Kubernetes et les ressources de calcul nécessaires à l’exécution de ClickHouse ne sont pas inclus dans cette configuration initiale. Ils seront provisionnés à l’étape suivante.

Module Terraform pour AWS

Si vous préférez utiliser Terraform plutôt que CloudFormation pour les déploiements AWS, utilisez le module terraform-byoc-onboarding :
Remplacez <version> par le dernier tag de la page des versions du module — utilisez toujours la version la plus récente.Le module génère clickhouse_management_role_arn. Dans le flux standard, vous n’avez rien à faire avec cette sortie — l’onboarding se poursuit dans la console ClickHouse Cloud — mais conservez-la à portée de main : ClickHouse vous la demandera si votre configuration diffère des valeurs par défaut (par exemple, si vous utilisez un nom de rôle personnalisé coordonné).
Le module était auparavant distribué sous forme de tarball à l’adresse https://s3.us-east-2.amazonaws.com/clickhouse-public-resources.clickhouse.cloud/tf/byoc.tar.gz. Cette URL reste disponible, mais est obsolète — utilisez le module GitHub ci-dessus.

ID externe AWS

Sur AWS, le rôle IAM créé lors de la configuration fait confiance à ClickHouse Cloud via un ID externe (sts:ExternalId) afin de se protéger contre les attaques de délégation confuse. La console ClickHouse Cloud génère un ID externe pour votre compte AWS lorsque vous démarrez l’onboarding et le préremplit dans le lien CloudFormation ; si vous utilisez Terraform, transmettez cette même valeur dans external_id. Toutes les infrastructures BYOC d’un même compte AWS partagent le même ID externe.
Les infrastructures BYOC intégrées avant l’introduction des ID externes utilisent la valeur d’espace réservé emptyid pour assurer la compatibilité ascendante. La console affiche cette valeur lorsque vous ajoutez une infrastructure à un compte AWS disposant déjà d’un déploiement legacy, afin que toutes les infrastructures du compte conservent une configuration de confiance cohérente. Si vous souhaitez passer à un ID externe unique, contactez ClickHouse Support.
3

Configurez l’infrastructure BYOC

Vous serez invité à configurer l’infrastructure, notamment les buckets de stockage d’objets, le VPC/VNet et le cluster Kubernetes, depuis la console ClickHouse Cloud. Certains paramètres doivent être définis à ce stade, car ils ne pourront pas être modifiés ultérieurement. Plus précisément :
  • Région : toutes les régions publiques répertoriées dans notre documentation sur les régions prises en charge sont disponibles pour les déploiements BYOC. Les régions privées ne sont actuellement pas prises en charge.
  • Plage CIDR du VPC/VNet : par défaut, nous utilisons 10.0.0.0/16 pour la plage CIDR du VPC BYOC (AWS/GCP) ou du VNet (Azure). Si vous prévoyez d’utiliser le peering VPC/VNet avec un autre compte, assurez-vous que les plages CIDR ne se chevauchent pas. La taille minimale varie selon le cloud :
    • AWS : /23
    • Azure : /23
    • GCP : /20
    Ces valeurs sont des minimums, et non des recommandations : chaque réplique consomme des adresses IP, les déploiements plus importants nécessitent donc une plage plus large.
  • Zones de disponibilité : si vous prévoyez d’utiliser le peering VPC, l’alignement des zones de disponibilité entre les comptes source et BYOC peut contribuer à réduire les coûts de trafic inter-AZ. Par exemple, dans AWS, les suffixes de zone de disponibilité (a, b, c) peuvent correspondre à différents ID de zones physiques selon les comptes. Consultez le guide AWS pour plus de détails.

Créez votre premier service ClickHouse BYOC

Une fois votre infrastructure BYOC provisionnée, vous êtes prêt à lancer votre premier service ClickHouse. Ouvrez la console ClickHouse Cloud, sélectionnez votre environnement BYOC et suivez les instructions pour créer un nouveau service. Lors de la création du service, vous configurerez les options suivantes :
  • Nom du service : saisissez un nom clair et explicite pour votre service ClickHouse.
  • Infrastructure BYOC : sélectionnez l’environnement BYOC, y compris le compte cloud et la région, dans lesquels votre service s’exécutera.
  • Configuration des ressources : choisissez la quantité de CPU et de mémoire allouée à vos réplicas ClickHouse.
  • Nombre de réplicas : définissez le nombre de réplicas pour renforcer la haute disponibilité.
Dernière modification le 14 août 2026