Onboarding padrão

A configuração inicial do BYOC pode ser realizada usando um template do CloudFormation (AWS), um módulo do Terraform (GCP) ou um módulo do Terraform (Azure). Ela cria uma identidade com privilégios elevados (IAM role/service account/principal de serviço), permitindo que os controllers do BYOC no ClickHouse Cloud gerenciem sua infraestrutura.

Módulo do Terraform para AWS

Se preferir usar o Terraform em vez do CloudFormation para implantações na AWS, use o módulo terraform-byoc-onboarding:

module "clickhouse_onboarding" {
  source      = "github.com/ClickHouse/terraform-byoc-onboarding.git//modules/aws?ref=<version>"
  external_id = "<external-id-provided-by-clickhouse>"
}

Substitua <version> pela tag mais recente na página de lançamentos do módulo — use sempre o lançamento mais recente.

O módulo retorna clickhouse_management_role_arn. No fluxo padrão, não é necessário fazer nada com ele — o onboarding continua no console do ClickHouse Cloud —, mas mantenha esse valor à mão: o ClickHouse o solicitará se sua configuração diferir dos padrões (por exemplo, devido a um nome de função personalizada coordenada).

ID externo da AWS

Na AWS, a função do IAM criada durante o setup confia no ClickHouse Cloud usando um ID externo (sts:ExternalId) para proteção contra ataques de representante confuso. O console do ClickHouse Cloud gera um ID externo para sua conta AWS quando você inicia o onboarding e o preenche automaticamente no link do CloudFormation; se usar o Terraform, passe o mesmo valor como external_id. Todas as infraestruturas BYOC na mesma conta AWS compartilham o mesmo ID externo.

Você deverá configurar a infraestrutura, incluindo buckets de armazenamento de objetos, VPC/VNet e o cluster do Kubernetes, no console do ClickHouse Cloud. Algumas configurações devem ser definidas nesta etapa, pois não poderão ser alteradas posteriormente. Especificamente:

• Região: Todas as regiões públicas listadas em nossa documentação sobre regiões compatíveis estão disponíveis para implantações BYOC. Atualmente, regiões privadas não são compatíveis.

• Intervalo CIDR da VPC/VNet: Por padrão, usamos 10.0.0.0/16 como intervalo CIDR para a VPC BYOC (AWS/GCP) ou VNet (Azure). Se você planeja usar peering de VPC/VNet com outra conta, certifique-se de que os intervalos CIDR não se sobreponham. O tamanho mínimo varia conforme a Cloud:

  • AWS: /23
  • Azure: /23
  • GCP: /20

  Esses são limites mínimos, não recomendações: cada réplica consome endereços IP; portanto, implantações maiores precisam de um intervalo maior.

• Zonas de disponibilidade: Se você planeja usar peering de VPC, alinhar as zonas de disponibilidade entre as contas de origem e BYOC pode ajudar a reduzir os custos de tráfego entre AZs. Por exemplo, na AWS, os sufixos de zona de disponibilidade (a, b, c) podem representar IDs de zonas físicas diferentes entre contas. Consulte o guia da AWS para mais detalhes.

Validação prévia

Ao clicar em Set up Infrastructure, o ClickHouse Cloud executa um conjunto de verificações prévias read-only na sua conta antes de criar qualquer recurso. Se tudo for aprovado, o provisionamento continua. Se alguma verificação falhar, a configuração é pausada e o console mostra exatamente qual é o problema, para que você possa corrigi-lo antes que qualquer recurso seja criado.

As verificações confirmam que:

• Permissões — a identidade de gerenciamento (IAM role / service account / principal de serviço) tem as permissões necessárias para que o ClickHouse Cloud provisione e opere sua implantação.
• Serviços habilitados (GCP) — as APIs necessárias do Google Cloud (Compute Engine, Kubernetes Engine, Cloud Storage, Network Connectivity, IAM) estão habilitadas no seu projeto.
• Rede (AWS com sua própria VPC) — sua VPC e sub-redes atendem aos requisitos de rede: tamanhos das sub-redes, tags obrigatórias, distribuição entre zonas de disponibilidade, conectividade de saída e endereços IP disponíveis.
• Cotas e proteções (AWS) — sua conta tem cotas de serviço suficientes (VPCs, NAT gateways, Elastic IPs, EKS clusters, vCPUs) e nenhuma política da organização (SCP) bloqueia uma ação necessária.

Quando as verificações falham, cada uma é listada com a ação correspondente e o motivo da falha (por exemplo, iam:CreateRole · explicitDeny). Expanda Show passed checks para revisar tudo o que foi bem-sucedido.

Para resolver as falhas, execute novamente a stack mais recente do CloudFormation ou do Terraform do ClickHouse — ou conceda as actions reportadas à identidade de gerenciamento (IAM role / service account / principal de serviço) — e então escolha uma destas opções:

• Verificar novamente — executa novamente as verificações de pré-requisitos. Use esta opção depois de corrigir os problemas relatados para confirmar que sua configuração está pronta antes do provisionamento.
• Prosseguir mesmo assim — continua o provisionamento apesar das verificações que falharam. Use esta opção somente se tiver certeza de que uma falha relatada é um falso positivo; caso contrário, o provisionamento provavelmente falhará no meio do processo.

Use a tabela abaixo para resolver falhas comuns.