Implementa nodos y VCF con Terraform y el kit de herramientas

En este documento, se explica cómo usar la automatización de Terraform para implementar nodos de ESXi en equipos físicos, redes de transmisión de capa 2, Cloud DNS y balanceadores de cargas internos regionales (ILB) para la solución de VMware en Google Cloud con VMware Cloud Foundation (VCF).

La automatización aprovisiona la siguiente infraestructura:

  • Hipervisores de ESXi dedicados de Bare Metal (z3-highmem-192-highlssd-metal o z3-highmem-192-metal).
  • Redes de transmisión de capa 2 con varias VLAN y marcos jumbo (MTU 8896)
  • Zonas administradas privadas de Cloud DNS y políticas de reenvío de consultas entrantes.
  • ILB regionales con ARP gratuito / anuncio de router (GARP_RA) Alta disponibilidad de movimiento rápido de IP.
  • Grupos de extremos de red (NEG) zonales para las interfaces de administración y de ruta de datos de NSX.

Antes de comenzar

Antes de ejecutar la automatización de Terraform, instala las herramientas necesarias, habilita las APIs requeridas, incluye en la lista de entidades permitidas las redes de subredes de capa 2 y verifica los siguientes requisitos para tu proyecto de Google Cloud :

  1. Asegúrate de que tu proyecto tenga suficiente cuota de nodos de equipos físicos en la región y la zona de destino. Para conocer las cuotas requeridas y obtener instrucciones sobre cómo ver o solicitar aumentos de cuota, consulta Cuotas y límites.
  2. Asegúrate de tener los permisos de Identity and Access Management (IAM) necesarios, incluidos Compute Admin (roles/compute.admin) y, si usas Cloud DNS, DNS Administrator (roles/dns.admin).
  3. Planifica tu infraestructura del Sistema de nombres de dominio (DNS) para admitir búsquedas directas y reversas de todos los nombres de host de nodos de ESXi y extremos de dispositivos de VCF planificados.
  4. Nombres de host de los nodos: Proporciona el nombre de dominio completamente calificado (FQDN) de cada nodo durante la implementación. Esto garantiza que ESXi genere certificados con nombres de host.
  5. Política de imágenes confiables: Si tu organización no aplica la política de la organización constraints/compute.trustedImageProjects, no se requiere ninguna acción. Si tu organización aplica esta política, permite projects/smve-prod-public-images para que Compute Engine pueda crear discos de arranque de Bare Metal. Para obtener más información, consulta Configura restricciones de acceso a imágenes.

  6. Controles del servicio de VPC: Si tu proyecto de destino no está en un perímetro de servicio, no se requiere ninguna acción. Si tu proyecto está en un perímetro de servicio, agrega una regla de salida que permita las operaciones de compute.googleapis.com en el proyecto smve-prod-public-images (projects/999037279871):

    - egressFrom:
    identityType: ANY_IDENTITY
  egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/999037279871

    Para obtener más información, consulta la referencia de las reglas de salida.

Instala Terraform

Debes instalar la versión 1.3.0 o posterior de la CLI de Terraform. Para instalar Terraform, selecciona la pestaña de tu sistema operativo:

DEBIAN o UBUNTU

Para instalar Terraform en Debian o Ubuntu, ejecuta los siguientes comandos:

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com '"$(lsb_release -cs)"' main' | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt-get update && sudo apt-get install -y terraform

RHEL o CentOS

Para instalar Terraform en RHEL o CentOS, ejecuta los siguientes comandos:

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install terraform

Linux genérico

Para instalar Terraform descargando directamente el objeto binario, ejecuta los siguientes comandos:

export TERRAFORM_VERSION='1.9.5'
curl -fsSLO 'https://releases.hashicorp.com/terraform/'"${TERRAFORM_VERSION}"'/terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'
unzip 'terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'
sudo mv terraform /usr/local/bin/
rm 'terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'

Habilita las APIs de Google Cloud

Habilita las siguientes APIs obligatorias en tu proyecto de Google Cloud de destino:

Extremo de servicio Objetivo
compute.googleapis.com Instancias de equipos físicos, redes de nube privada virtual (VPC), subredes de capa 2, firewalls, NEG, ILB regionales y reservas de IP estáticas.
dns.googleapis.com Zonas administradas de DNS inversas y de reenvío privadas, políticas de reenvío entrante y conjuntos de registros DNS.

Para habilitar las APIs requeridas con la CLI de gcloud, ejecuta el siguiente comando:

gcloud services enable \
    compute.googleapis.com \
    dns.googleapis.com \
    --project='PROJECT_ID'

Reemplaza PROJECT_ID por el ID de tu proyecto de Google Cloud de destino.

Verifica la cuota regional

Antes de aprovisionar nodos de equipos físicos o crear un clúster, verifica que tu proyecto tenga suficiente cuota regional y global de Compute Engine. Agrega los recursos de todos los clústeres existentes en la región a los siguientes valores incrementales antes de compararlos con la cuota de tu proyecto:

Métrica de cuota Recursos necesarios por nodo de Bare Metal Recursos necesarios para un clúster de 3 nodos
compute.googleapis.com/cpus_per_vm_family para Z3 192 CPUs virtuales 3 × 192 = 576 CPUs virtuales
compute.googleapis.com/local_ssd_total_storage_per_vm_family para Z3 72 TB 3 × 72 TB = 216 TB
compute.googleapis.com/hyperdisk_balanced_total_storage 128 GB 3 × 128 GB = 384 GB
compute.googleapis.com/resource_policies 0 cuando se agregan nodos a un clúster existente 1 política de posición distribuida por clúster
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0 cuando se agregan nodos o clústeres sin dispositivos nuevos 1 por cada nueva VIP del dispositivo de administración de VCF o extremo de NSX Edge

Para obtener la lista completa de las cuotas requeridas y las instrucciones para ver o solicitar aumentos de cuota, consulta Cuotas y límites.

Permite las redes de subredes de capa 2 basadas en VLAN incluidas en la lista de entidades permitidas

La solución de VMware requiere que las subredes de tu red de nube privada virtual (VPC) tengan la propiedad Resolver máscara de subred configurada en Transmitir solo el rango principal con aprendizaje para admitir las herramientas de redes basadas en VLAN. Abre un ticket de asistencia en el Centro de asistencia de la consola deGoogle Cloud con la siguiente información:

  • Producto: Google Cloud VMware Engine
  • Prioridad: P2
  • Categoría: Conectividad de red
  • Impacto comercial: Pregunta técnica general
  • Proporciona más detalles: Allowlist L2 network connectivity for my project, junto con el ID del proyecto, el número del proyecto y la región y la zona de destino para la implementación

Para obtener más información sobre la compatibilidad con las redes basadas en VLAN, consulta Emulación de capa 2: transmisión de ARP y aprendizaje de MAC personalizado.

Configura la política de la organización y los Controles del servicio de VPC

Las instancias de ESXi de Bare Metal en la solución de VMware se inician desde imágenes de ESXi proporcionadas por Google alojadas en el proyecto smve-prod-public-images, que tiene el número de proyecto 999037279871. De forma predeterminada, no se requiere ninguna configuración adicional. Aplica las siguientes opciones de configuración solo si tu organización aplica una política de imágenes confiables o usa los Controles del servicio de VPC:

  • Política de imágenes confiables: Si tu organización no aplica la política de la organización constraints/compute.trustedImageProjects, no se requiere ninguna acción. Si tu organización aplica esta política, permite projects/smve-prod-public-images para que Compute Engine pueda crear discos de arranque de Bare Metal. Para obtener más información, consulta Configura restricciones de acceso a imágenes.

  • Regla de salida de los Controles del servicio de VPC: Si tu proyecto de destino no está en un perímetro de servicio, no se requiere ninguna acción. Si tu proyecto está en un perímetro de servicio, agrega una regla de salida que permita las operaciones de compute.googleapis.com en el proyecto smve-prod-public-images (projects/999037279871):

    - egressFrom:
    identityType: ANY_IDENTITY
  egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/999037279871

    Para obtener más información, consulta la referencia de las reglas de salida.

Configura los permisos y roles de IAM

La identidad que ejecuta Terraform (un administrador humano o una cuenta de servicio de CI/CD automatizada) requiere los siguientes roles de IAM en el proyecto Google Cloud de destino:

Rol ID del rol Alcance de uso
Administrador de Compute roles/compute.admin Aprovisiona instancias de procesamiento de equipos físicos, adjunta imágenes de discos de arranque personalizadas, configura políticas de posición y administra interfaces multi-NIC. Administra redes de VPC, subredes de transmisión de capa 2, reservas de IP estáticas, ILB regionales, servicios de backend, reglas de reenvío y NEG zonales. Crear y administrar reglas de seguridad de firewall de entrada de VPC
Administrador de DNS roles/dns.admin Administra las zonas privadas de reenvío y reversas de Cloud DNS, las políticas de reenvío de consultas entrantes y los conjuntos de registros de recursos A y PTR.
Usuario de cuenta de servicio roles/iam.serviceAccountUser Otorga este rol en la cuenta de servicio predeterminada de Compute Engine (PROJECT_NUMBER-compute@) para permitir el aprovisionamiento de instancias con el permiso cloud-platform.

Otorga roles con gcloud CLI

Para asignar los roles a nivel de proyecto y los permisos de la cuenta de servicio necesarios, ejecuta los siguientes comandos:

# Assign required project-level roles (use 'serviceAccount:SA_EMAIL' if granting to a service account)
for ROLE in \
    roles/compute.admin \
    roles/dns.admin; do
  gcloud projects add-iam-policy-binding 'PROJECT_ID' \
      --member='user:USER_EMAIL' \
      --role=${ROLE}
done
# Grant Service Account User role on the Compute Engine default service account
gcloud iam service-accounts add-iam-policy-binding \
    'PROJECT_NUMBER-compute@' \
    --member='user:USER_EMAIL' \
    --role='roles/iam.serviceAccountUser' \
    --project='PROJECT_ID'

Antes de ejecutar los comandos, reemplaza lo siguiente:

  • PROJECT_ID: Es el ID de tu proyecto de Google Cloud de destino.
  • PROJECT_NUMBER: Es el número de tu proyecto de Google Cloud de destino.
  • USER_EMAIL: Es la dirección de correo electrónico de tu identidad de usuario.

Autentica el ejecutor de Terraform

Elige una de las siguientes estrategias de autenticación según tu entorno operativo:

Autentica con identidad temporal como cuenta de servicio

La identidad temporal como cuenta de servicio elimina las claves de credenciales de larga duración generando tokens de acceso de OAuth 2.0 de corta duración. Tu identidad personal se autentica, mientras que Terraform se ejecuta como la cuenta de servicio designada. Google Cloud audita las acciones que realiza Terraform en la cuenta de servicio.

  1. Otorga a tu identidad personal de Google Cloud el rol de creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en la cuenta de servicio del ejecutor:

    gcloud iam service-accounts add-iam-policy-binding 'SA_EMAIL' \
   --member='user:USER_EMAIL' \
   --role='roles/iam.serviceAccountTokenCreator' \
   --project='PROJECT_ID'

    Antes de ejecutar el comando, reemplaza lo siguiente:

    • SA_EMAIL: Es la dirección de correo electrónico de la cuenta de servicio del ejecutor de Terraform.
    • USER_EMAIL: Es la dirección de correo electrónico de tu identidad personal de Google Cloud.
    • PROJECT_ID: Es el ID de tu proyecto de Google Cloud de destino.

  2. Autentica tu entorno local:

    gcloud auth application-default login

  3. Establece la variable de entorno GOOGLE_IMPERSONATE_SERVICE_ACCOUNT para aplicar la identidad temporal en las ejecuciones de Terraform:

    export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT='SA_EMAIL'

Autentica mediante credenciales predeterminadas de la aplicación

Usa las credenciales predeterminadas de la aplicación (ADC) en entornos de desarrollo y pruebas en los que tu identidad de usuario tenga los permisos necesarios directamente. Google Cloud audita las acciones en función de tu identidad personal:

gcloud auth application-default login
gcloud config set project 'PROJECT_ID'

Reemplaza PROJECT_ID por el ID de tu proyecto de Google Cloud de destino.

Autentica con un archivo de claves de cuenta de servicio

Usa un archivo de claves de cuenta de servicio en canalizaciones de CI/CD automatizadas (como Cloud Build, GitHub Actions o Jenkins) en las que no se admite el acceso interactivo de los usuarios y la autenticación se basa en claves de credenciales de cuentas de servicio de larga duración. Configura la variable de entorno GOOGLE_APPLICATION_CREDENTIALS en la ruta del archivo de claves de tu cuenta de servicio:

export GOOGLE_APPLICATION_CREDENTIALS='KEY_FILE'

Reemplaza KEY_FILE por la ruta de acceso a la clave JSON de tu cuenta de servicio.

Revisa la arquitectura modular

Terraform coordina el aprovisionamiento de recursos en cuatro etapas modulares. Este diseño modular aplica un orden estricto de dependencias para garantizar que existan los requisitos previos de las redes antes de implementar hosts de procesamiento, balanceadores de cargas y registros DNS:

+-----------------------------------------------------------------------------------+
| STAGE 1: VPC Network Infrastructure, Firewalls & Cloud DNS (modules/vpc)          |
| - Custom VPC Network (MTU 8896 jumbo frames)                                      |
| - VPC Ingress Allow-All Firewall Rule                                             |
| - Dedicated Standard Subnetwork (for DNS inbound resolver)                        |
| - Cloud DNS Private Forward & Reverse Managed Zones                               |
| - Cloud DNS Inbound Forwarding Policy (Dynamic DNS_RESOLVER IP discovery)         |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 2: L2 Broadcast Subnetworks & Zonal NEGs (modules/subnets)                  |
| - Primary Management Subnet (Untagged Native VLAN, ARP broadcast learning)        |
| - Storage & Infrastructure Subnets: vSAN (VLAN tagged), vMotion, NSX TEP          |
| - Optional Dynamic Workload Subnets                                               |
| - Zonal Network Endpoint Groups (GCE_VM_IP_DEDICATED_BACKEND) for Mgmt & NSX TEP   |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 3: Bare-Metal ESXi Hosts, IP Allocations & Host DNS (modules/hosts)         |
| - Compute Resource Placement Policy (Availability Domain Count: 5-8, default: 6)  |
| - Universal IP Allocator: Static reservations & dynamic allocation for all NICs   |
| - Bare-Metal ESXi Instances (z3-highmem-192-highlssd-metal, 4+ Multi-NICs)        |
| - Automated NEG Endpoint Attachments (in cluster_creation mode)                   |
| - Cloud DNS Forward (A) and Reverse (PTR) Records for all ESXi Hosts              |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 4: Regional Internal Load Balancers & Appliances (modules/appliances)       |
| - Regional Backend Services (GARP_RA Fast IP Move HA Policy)                      |
| - Regional Forwarding Rules (L3_DEFAULT / ALL_PORTS / allow_global_access)        |
| - Automated Cloud DNS Forward (A) and Reverse (PTR) Records for Mgmt Appliances   |
+-----------------------------------------------------------------------------------+

Aprovisiona recursos para el clúster de administración

El clúster de administración del dominio de administración aloja los dispositivos principales del plano de control de VCF (SDDC Manager, vCenter Server, el clúster de NSX Management y VMware Aria Suite) y los hipervisores de ESXi.

Configura el espacio de trabajo de Terraform

Crea un directorio de espacio de trabajo dedicado y clona el repositorio del kit de herramientas con Git:

mkdir -p ~/vcf-deployments/mgmt-cluster
cd ~/vcf-deployments/mgmt-cluster
git clone https://github.com/GoogleCloudPlatform/self-managed-vmware-solution-toolkit

Configura el archivo de definiciones de variables

Crea tu archivo de definiciones de variables (management_cluster.tfvars) con los valores de tu entorno de destino. Copia el archivo sample_management_cluster.tfvars del directorio e2e-terraform en tu archivo management_cluster.tfvars y sigue las instrucciones y los comentarios intercalados para actualizar los campos según sea necesario:

cp self-managed-vmware-solution-toolkit/e2e-terraform/sample_management_cluster.tfvars \
    self-managed-vmware-solution-toolkit/e2e-terraform/management_cluster.tfvars

Aplica la configuración de Terraform

Ve al directorio self-managed-vmware-solution-toolkit/e2e-terraform, inicializa y aplica la configuración de Terraform:

cd self-managed-vmware-solution-toolkit/e2e-terraform
terraform init
terraform plan -var-file='management_cluster.tfvars' -out=tfplan
terraform apply tfplan

Revisa y exporta los resultados de Terraform

Después de ejecutar terraform apply, Terraform expone resultados estructurados en cuatro categorías:

  • gcp_resources_self_links: Son las URLs de vínculo propio de recursos de Google Cloud completas para las redes de VPC, las subredes, las instancias, las políticas de posición, los NEG, los servicios de backend, las reglas de reenvío, los firewalls y las zonas de Cloud DNS.
  • neg_attachment_commands:
    • Cuando la variable deployment_mode se establece en "cluster_creation", se devuelve un mensaje de estado que indica que Terraform adjunta automáticamente los NEG durante la creación del clúster.
    • Cuando la variable deployment_mode se establece en "node_addition": Proporciona los comandos gcloud compute network-endpoint-groups update necesarios para conectar las instancias de host de ESXi recién aprovisionadas a los NEG de administración y NSX.
    • Cuando la variable deployment_mode se establece en "appliance_addition": Devuelve un mensaje de estado que indica que los NEG permanecen conectados a los nodos de clúster existentes y que Terraform no los modifica durante la adición del dispositivo.
  • python_scripts_input_config: Es la carga útil de configuración de parámetros estructurados para las secuencias de comandos de automatización de la implementación del instalador de VCF descendente en el directorio python del kit de herramientas. Puedes convertir este resultado en el formato JSON que esperan las secuencias de comandos de Python del kit de herramientas ejecutando la secuencia de comandos auxiliar que se describe en la siguiente sección.
  • management_domain_deployment_input_config: Es la entrada estructurada para la implementación del dominio de administración con la mayoría de los campos completados previamente a partir del aprovisionamiento de extremo a extremo. Puedes editar esta entrada cuando sea necesario o se indique, y convertirla en un archivo JSON para la implementación del dominio de administración con la secuencia de comandos de exportación que se describe en la siguiente sección.

Exporta parámetros de configuración de implementación

El kit de herramientas incluye una secuencia de comandos auxiliar (scripts/export_deployment_config.py) que extrae bloques de configuración de los resultados de Terraform y los exporta a archivos JSON con formato que cumplen con el esquema para los flujos de trabajo posteriores:

  • management_domain_deployment_input_config: Es el JSON de entrada para la implementación del dominio de administración de VCF.
  • python_scripts_input_config: Es el JSON de entrada (config.json) para las secuencias de comandos de automatización de Python del kit de herramientas (vcf_deployer).

Ejecuta la secuencia de comandos auxiliar

Ejecuta la secuencia de comandos auxiliar desde el directorio e2e-terraform (o especifica las marcas -d o -i) eligiendo una de las siguientes opciones:

  • Exporta ambas configuraciones de forma simultánea:

    python3 ../scripts/export_deployment_config.py --config all --output-dir .

    Este comando genera los siguientes archivos:

    • management_domain_deployment_input.json
    • python_scripts_input_config.json

  • Exporta solo el JSON de entrada de implementación del dominio de administración de VCF:

    python3 ../scripts/export_deployment_config.py --config mgmt -o management_domain_deployment_input.json

  • Exporta solo el JSON de entrada del kit de herramientas de Python:

    python3 ../scripts/export_deployment_config.py --config python -o config.json

  • Exporta desde salidas de Terraform guardadas o entrada estándar canalizada (stdin):

    # From stdin pipe:
terraform output -json | python3 ../scripts/export_deployment_config.py --config all --output-dir .

# From a saved JSON file:
terraform output -json > outputs.json
python3 ../scripts/export_deployment_config.py -i outputs.json --config all --output-dir .

¿Qué sigue?

  1. Ejecuta el kit de herramientas de preparación de nodos para restablecer la contraseña inicial de ESXi root en cada host, preparar los nodos para la implementación de VCF y, luego, implementar el dispositivo de instalación de VCF con el resultado de python_scripts_input_config de la configuración de Terraform de extremo a extremo (convertido en JSON con la secuencia de comandos auxiliar). Para obtener instrucciones, consulta Prepara nodos e implementa VCF con el kit de herramientas.
  2. Configura la conexión al depósito regional sin conexión en el instalador de VCF para descargar los paquetes de software necesarios:
    • Protocolo: HTTPS
    • FQDN (no uses una dirección IP): offline-depot.REGION.selfmanagedvmwareengine.goog (reemplaza REGION por la región de Google Cloud en la que residen tus nodos de equipos físicos)
    • Puerto: 443
    • Nombre de usuario: vcf-depot-user
    • Contraseña: Google1!
  3. Implementa el dominio de administración proporcionando el archivo JSON management_domain_deployment_input_config (exportado con la secuencia de comandos auxiliar) al instalador de VCF. Asegúrate de reemplazar todos los campos marcados como user_should_input en la configuración de entrada por tus valores de destino. Para obtener instrucciones sobre cómo completar el flujo de trabajo de inicio de VCF, consulta Implementa una flota de VCF nueva o una instancia de VCF nueva en la documentación de Broadcom.
  4. Expande la capacidad del clúster agregando nodos en Administra la capacidad de los nodos con Terraform.
  5. Aprovisiona balanceadores de cargas y registros DNS para dispositivos de VCF adicionales en Agrega dispositivos de VCF con Terraform.