Onboarding estándar

La configuración inicial de BYOC se puede realizar mediante una plantilla de CloudFormation (AWS), un módulo de Terraform (GCP) o un módulo de Terraform (Azure). Crea una identidad con privilegios elevados (rol de IAM/cuenta de servicio/entidad de servicio), lo que permite a los controladores de BYOC de ClickHouse Cloud administrar su infraestructura.

Módulo de Terraform para AWS

Si prefiere usar Terraform en lugar de CloudFormation para las implementaciones de AWS, use el 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>"
}

Sustituya <version> por la etiqueta más reciente de la página de releases del módulo; utilice siempre la release más reciente.

El módulo genera clickhouse_management_role_arn. En el flujo estándar, no es necesario realizar ninguna acción con él: el onboarding continúa en la ClickHouse Cloud console. No obstante, téngalo a mano: ClickHouse se lo solicitará si su configuración se desvía de los valores predeterminados (por ejemplo, si se coordina un nombre de rol personalizado).

ID externo de AWS

En AWS, el rol de IAM creado durante la configuración establece una relación de confianza con ClickHouse Cloud mediante un ID externo (sts:ExternalId) para protegerse contra ataques de suplantación de autoridad. La ClickHouse Cloud console genera un ID externo para su cuenta de AWS al iniciar el onboarding y lo rellena previamente en el enlace de CloudFormation; si utiliza Terraform, proporcione el mismo valor como external_id. Todas las infraestructuras BYOC de la misma cuenta de AWS comparten el mismo ID externo.

Se le pedirá que configure la infraestructura —incluidos los buckets de almacenamiento de objetos, la VPC/VNet y el clúster de Kubernetes— desde la consola de ClickHouse Cloud. Algunas configuraciones deben definirse en esta etapa, ya que no podrán modificarse posteriormente. En concreto:

• Región: Todas las regiones públicas incluidas en nuestra documentación sobre regiones compatibles están disponibles para implementaciones de BYOC. Actualmente, las regiones privadas no son compatibles.

• Rango CIDR de VPC/VNet: De forma predeterminada, usamos 10.0.0.0/16 como rango CIDR para la VPC de BYOC (AWS/GCP) o la VNet (Azure). Si planea usar peering de VPC/VNet con otra cuenta, asegúrese de que los rangos CIDR no se superpongan. El tamaño mínimo difiere según la nube:

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

  Estos son mínimos, no recomendaciones: cada réplica consume direcciones IP, por lo que las implementaciones más grandes necesitan un rango mayor.

• Zonas de disponibilidad: Si planea usar peering de VPC, alinear las zonas de disponibilidad entre las cuentas de origen y de BYOC puede ayudar a reducir los costos de tráfico entre zonas de disponibilidad. Por ejemplo, en AWS, los sufijos de las zonas de disponibilidad (a, b, c) pueden representar distintos ID de zonas físicas en diferentes cuentas. Consulte la guía de AWS para obtener más información.

Validación previa

Al hacer clic en Set up Infrastructure, ClickHouse Cloud ejecuta un conjunto de comprobaciones previas de solo lectura sobre su cuenta antes de crear ningún recurso. Si todas se superan, el aprovisionamiento continúa. Si una comprobación falla, la configuración se pausa y la consola muestra exactamente cuál es el problema, de modo que pueda corregirlo antes de que se cree ningún recurso.

Las comprobaciones confirman que:

• Permisos — la identidad de administración (rol de IAM / cuenta de servicio / entidad de servicio) cuenta con los permisos que ClickHouse Cloud necesita para aprovisionar y operar su implementación.
• Servicios habilitados (GCP) — las API de Google Cloud requeridas (Compute Engine, Kubernetes Engine, Cloud Storage, Network Connectivity, IAM) están habilitadas en su proyecto.
• Red (AWS con VPC propia) — su VPC y sus subredes cumplen los requisitos de red: tamaños de subred, tags obligatorios, distribución entre zonas de disponibilidad, conectividad saliente y direcciones IP disponibles.
• Cuotas y limitaciones (AWS) — su cuenta dispone de cuotas de servicio suficientes (VPC, gateways NAT, Elastic IP, clústeres de EKS, vCPU) y ninguna política de la organización (SCP) bloquea una acción necesaria.

Cuando fallan comprobaciones, cada una aparece con la acción a la que corresponde y el motivo del fallo (por ejemplo, iam:CreateRole · explicitDeny). Despliegue Show passed checks para revisar todo lo que se completó correctamente.

Para resolver los fallos, vuelva a ejecutar la última pila de CloudFormation o de Terraform de ClickHouse —o conceda las acciones notificadas a la identidad de administración (rol de IAM / cuenta de servicio / entidad de servicio)— y, a continuación, elija una de estas opciones:

• Volver a verificar — vuelve a ejecutar las comprobaciones previas. Úselo después de corregir los problemas notificados para confirmar que la configuración está lista antes del aprovisionamiento.
• Continuar de todos modos — continúa con el aprovisionamiento a pesar de que algunas comprobaciones hayan fallado. Úselo solo si está seguro de que el fallo notificado es un falso positivo; de lo contrario, es probable que el aprovisionamiento falle a mitad del proceso.

Utilice la siguiente tabla para resolver los fallos más habituales.