Implantar nós e o VCF usando o Terraform e o kit de ferramentas

Neste documento, explicamos como usar a automação do Terraform para implantar nós ESXi bare metal, redes de transmissão de camada 2, Cloud DNS e balanceadores de carga internos (ILBs) regionais para a solução VMware no Google Cloud com o VMware Cloud Foundation (VCF).

A automação provisiona a seguinte infraestrutura:

  • Hipervisores ESXi bare metal dedicados (z3-highmem-192-highlssd-metal ou z3-highmem-192-metal).
  • Redes de transmissão de camada 2 com várias VLANs e frames jumbo (MTU 8896).
  • Zonas gerenciadas particulares do Cloud DNS e políticas de encaminhamento de consultas de entrada.
  • ILBs regionais com ARP incluído / anúncio de roteador (GARP_RA) de alta disponibilidade de movimentação rápida de IP.
  • Grupos de endpoints de rede (NEGs) zonais para interfaces de gerenciamento e caminho de dados do NSX.

Antes de começar

Antes de executar a automação do Terraform, instale as ferramentas necessárias, ative as APIs necessárias, inclua na lista de permissões a rede de sub-rede da camada 2 e verifique os seguintes requisitos para o projeto do Google Cloud :

  1. Verifique se o projeto tem cota suficiente de nós bare metal na região e na zona de destino. Para saber as cotas necessárias e instruções sobre como visualizar ou solicitar aumentos de cota, consulte Cotas e limites.
  2. Verifique se você tem as permissões necessárias do Identity and Access Management (IAM), incluindo Compute Admin (roles/compute.admin) e, se você usa o Cloud DNS, DNS Administrator (roles/dns.admin).
  3. Planeje sua infraestrutura do Sistema de Nomes de Domínio (DNS) para oferecer suporte a pesquisas diretas e reversas para todos os nomes de host de nós do ESXi planejados e endpoints de dispositivos do VCF.
  4. Nomes de host do nó: forneça o nome de domínio totalmente qualificado (FQDN) de cada nó durante a implantação. Isso garante que o ESXi gere certificados usando nomes de host.
  5. Política de imagem confiável: se a organização não aplicar a política da organização constraints/compute.trustedImageProjects, nenhuma ação será necessária. Se a organização aplicar essa política, permita projects/smve-prod-public-images para que o Compute Engine possa criar discos de inicialização bare metal. Para mais informações, consulte Definir restrições de acesso a imagens.

  6. VPC Service Controls: se o projeto de destino não estiver em um perímetro de serviço, nenhuma ação será necessária. Se o projeto estiver em um perímetro de serviço, adicione uma regra de saída que permita operações compute.googleapis.com para o projeto smve-prod-public-images (projects/999037279871):

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

    Para mais informações, consulte Referência de regras de saída.

Instalar o Terraform

É necessário instalar a CLI do Terraform versão 1.3.0 ou mais recente. Para instalar o Terraform, selecione a guia do seu sistema operacional:

Debian ou Ubuntu

Para instalar o Terraform no Debian ou no Ubuntu, execute os seguintes 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 ou CentOS

Para instalar o Terraform no RHEL ou no CentOS, execute os seguintes 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 o Terraform fazendo o download direto do binário, execute os seguintes 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'

Ativar Google Cloud APIs

Ative as seguintes APIs necessárias no projeto de destino do Google Cloud :

Endpoint de serviço Finalidade
compute.googleapis.com Instâncias bare metal, redes de nuvem privada virtual (VPC), sub-redes de camada 2, firewalls, NEGs, ILBs regionais e reservas de IP estático.
dns.googleapis.com Zonas gerenciadas de DNS de encaminhamento e reversas particulares, políticas de encaminhamento de entrada e conjuntos de registros DNS.

Para ativar as APIs necessárias usando a CLI gcloud, execute o seguinte comando:

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

Substitua PROJECT_ID pelo ID do projeto de destino do Google Cloud .

Verificar cota regional

Antes de provisionar nós bare metal ou criar um cluster, verifique se o projeto tem cota regional e global suficiente do Compute Engine. Adicione os recursos de todos os clusters atuais na região aos seguintes valores incrementais antes de compará-los com a cota do projeto:

Métrica de cota Recursos necessários por nó bare metal Recursos necessários para um cluster de três nós
compute.googleapis.com/cpus_per_vm_family para Z3 192 vCPUs 3 × 192 = 576 vCPUs
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 ao adicionar nós a um cluster atual 1 política de posicionamento distribuído por cluster
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0 ao adicionar nós ou clusters sem novos appliances 1 por novo VIP do dispositivo de gerenciamento do VCF ou endpoint do NSX Edge

Para ver a lista completa de cotas necessárias e instruções sobre como visualizar ou solicitar aumentos de cota, consulte Cotas e limites.

Rede de sub-rede da camada 2 baseada em VLAN na lista de permissão

A solução VMware exige que as sub-redes da sua rede de nuvem privada virtual (VPC) tenham a propriedade Resolver máscara de sub-rede definida como Transmitir intervalo principal apenas com aprendizado para oferecer suporte à rede baseada em VLAN. Abra um tíquete de suporte na Central de suporte do console doGoogle Cloud com as seguintes informações:

  • Produto: Google Cloud VMware Engine
  • Prioridade: P2
  • Categoria: conectividade de rede
  • Impacto nos negócios: pergunta técnica geral
  • Forneça mais detalhes: Allowlist L2 network connectivity for my project, além do ID do projeto, do número do projeto e da região e zona de destino da implantação.

Para mais informações sobre o suporte a redes baseadas em VLAN, consulte Emulação de camada 2: transmissão ARP e aprendizado de MAC personalizado.

Configurar a política da organização e o VPC Service Controls

As instâncias bare metal do ESXi na solução VMware são inicializadas com imagens do ESXi fornecidas pelo Google e hospedadas no projeto smve-prod-public-images, que tem o número 999037279871. Por padrão, nenhuma configuração adicional é necessária. Aplique as configurações a seguir somente se a organização aplicar uma política de imagem confiável ou usar o VPC Service Controls:

  • Política de imagem confiável: se a organização não aplicar a política da organização constraints/compute.trustedImageProjects, nenhuma ação será necessária. Se a organização aplicar essa política, permita projects/smve-prod-public-images para que o Compute Engine possa criar discos de inicialização bare metal. Para mais informações, consulte Definir restrições de acesso a imagens.

  • Regra de saída do VPC Service Controls: se o projeto de destino não estiver em um perímetro de serviço, nenhuma ação será necessária. Se o projeto estiver em um perímetro de serviço, adicione uma regra de saída que permita operações de compute.googleapis.com para o projeto smve-prod-public-images (projects/999037279871):

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

    Para mais informações, consulte Referência de regras de saída.

Configurar permissões e papéis do IAM

A identidade que executa o Terraform (um administrador humano ou uma conta de serviço de CI/CD automatizada) requer os seguintes papéis do IAM no projeto de destino doGoogle Cloud :

Papel Código do papel Escopo de uso
Administrador do Compute roles/compute.admin Provisione instâncias de computação bare metal, anexe imagens do disco de inicialização personalizadas, configure políticas de posicionamento e gerencie interfaces com várias NICs. Gerenciar redes VPC, sub-redes de transmissão de camada 2, reservas de IP estático, ILBs regionais, serviços de back-end, regras de encaminhamento e NEGs zonais. Criar e gerenciar regras de segurança de firewall de entrada da VPC.
Administrador do DNS roles/dns.admin Gerenciar zonas de encaminhamento privado e reverso do Cloud DNS, políticas de encaminhamento de consultas de entrada e conjuntos de registros de recursos A e PTR.
Usuário da conta de serviço roles/iam.serviceAccountUser Conceda esse papel na conta de serviço padrão do Compute Engine (PROJECT_NUMBER-compute@) para permitir o provisionamento de instâncias com o escopo cloud-platform.

Conceder papéis usando a CLI gcloud

Para atribuir os papéis necessários para envolvidos no projeto e as permissões da conta de serviço, execute os seguintes 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 executar os comandos, substitua o seguinte:

  • PROJECT_ID: o ID do projeto de destino do Google Cloud .
  • PROJECT_NUMBER: o número do projeto de destino do Google Cloud.
  • USER_EMAIL: o endereço de e-mail da sua identidade de usuário.

Autenticar o executor do Terraform

Escolha uma das seguintes estratégias de autenticação com base no seu ambiente operacional:

Autenticar usando a identidade temporária de conta de serviço

A identidade temporária de conta de serviço elimina as chaves de credencial de longa duração gerando tokens de acesso OAuth 2.0 de curta duração. Sua identidade pessoal é autenticada, enquanto o Terraform é executado como a conta de serviço designada. OGoogle Cloud audita as ações realizadas pelo Terraform na conta de serviço.

  1. Conceda à sua identidade pessoal do Google Cloud o papel de Criador de token da conta de serviço (roles/iam.serviceAccountTokenCreator) na conta de serviço do executor:

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

    Antes de executar o comando, substitua o seguinte:

    • SA_EMAIL: o endereço de e-mail da conta de serviço do executor do Terraform.
    • USER_EMAIL: o endereço de e-mail da sua identidade pessoal do Google Cloud.
    • PROJECT_ID: o ID do projeto de destino do Google Cloud .

  2. Autentique seu ambiente local:

    gcloud auth application-default login

  3. Defina a variável de ambiente GOOGLE_IMPERSONATE_SERVICE_ACCOUNT para aplicar a personificação em todas as execuções do Terraform:

    export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT='SA_EMAIL'

Autenticar usando o Application Default Credentials

Use o Application Default Credentials (ADC) em ambientes de desenvolvimento e teste em que sua identidade de usuário tem as permissões necessárias diretamente. OGoogle Cloud audita ações em relação à sua identidade pessoal:

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

Substitua PROJECT_ID pelo ID do projeto de destino do Google Cloud .

Autenticar usando um arquivo de chave de conta de serviço

Use um arquivo de chave de conta de serviço em pipelines de CI/CD automatizados (como Cloud Build, GitHub Actions ou Jenkins) em que o login interativo do usuário não é compatível e a autenticação depende de chaves de credenciais da conta de serviço de longa duração. Defina a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS como o caminho do arquivo de chave da conta de serviço:

export GOOGLE_APPLICATION_CREDENTIALS='KEY_FILE'

Substitua KEY_FILE pelo caminho para a chave JSON da sua conta de serviço.

Analisar a arquitetura modular

O Terraform coordena o provisionamento de recursos em quatro etapas modulares. Esse design modular impõe uma ordem de dependência estrita para garantir que os pré-requisitos de rede existam antes de implantar hosts de computação, balanceadores de carga e 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   |
+-----------------------------------------------------------------------------------+

Provisionar recursos para o cluster de gerenciamento

O cluster de gerenciamento do domínio de gerenciamento hospeda os principais dispositivos do plano de controle do VCF (SDDC Manager, vCenter Server, cluster de gerenciamento do NSX e VMware Aria Suite) e hipervisores ESXi.

Configurar o espaço de trabalho do Terraform

Crie um diretório de espaço de trabalho dedicado e clone o repositório do kit de ferramentas usando o Git:

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

Configurar o arquivo de definições de variáveis

Crie o arquivo de definições de variáveis (management_cluster.tfvars) com os valores do ambiente de destino. Copie o arquivo sample_management_cluster.tfvars do diretório e2e-terraform para o arquivo management_cluster.tfvars e siga as instruções e os comentários inline para atualizar os campos conforme necessário:

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

Aplique a configuração do Terraform:

Acesse o diretório self-managed-vmware-solution-toolkit/e2e-terraform, inicialize e aplique a configuração do Terraform:

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

Analisar e exportar saídas do Terraform

Depois de executar terraform apply, o Terraform expõe saídas estruturadas em quatro categorias:

  • gcp_resources_self_links: URLs de self link de recursos Google Cloud completos para redes VPC, sub-redes, instâncias, políticas de posicionamento, NEGs, serviços de back-end, regras de encaminhamento, firewalls e zonas de DNS do Cloud DNS.
  • neg_attachment_commands:
    • Quando a variável deployment_mode é definida como "cluster_creation": retorna uma mensagem de status indicando que o Terraform anexa automaticamente NEGs durante a criação do cluster.
    • Quando a variável deployment_mode é definida como "node_addition": fornece os comandos gcloud compute network-endpoint-groups update necessários para anexar instâncias de host ESXi recém-provisionadas aos NEGs de gerenciamento e do NSX.
    • Quando a variável deployment_mode é definida como "appliance_addition": retorna uma mensagem de status indicando que os NEGs permanecem anexados aos nós de cluster atuais e que o Terraform não os modifica durante a adição do appliance.
  • python_scripts_input_config: payload de configuração de parâmetro estruturado para os scripts de automação de implantação do instalador do VCF downstream no diretório python do kit de ferramentas. É possível converter essa saída no formato JSON esperado pelos scripts Python do kit de ferramentas executando o script auxiliar descrito na próxima seção.
  • management_domain_deployment_input_config: entrada estruturada para implantação de domínio de gerenciamento com a maioria dos campos pré-preenchidos do provisionamento de ponta a ponta. É possível editar essa entrada quando necessário ou indicado e convertê-la em um arquivo JSON para implantação de domínio de gerenciamento usando o script de exportação descrito na próxima seção.

Exportar configurações de implantação

O kit de ferramentas inclui um script auxiliar (scripts/export_deployment_config.py) que extrai blocos de configuração das saídas do Terraform e os exporta para arquivos JSON formatados e compatíveis com o esquema para fluxos de trabalho downstream:

  • management_domain_deployment_input_config: JSON de entrada para a implantação do domínio de gerenciamento do VCF.
  • python_scripts_input_config: JSON de entrada (config.json) para os scripts de automação do Python do kit de ferramentas (vcf_deployer).

Executar o script auxiliar

Execute o script auxiliar no diretório e2e-terraform (ou especifique as flags -d ou -i) escolhendo uma das seguintes opções:

  • Exporte as duas configurações simultaneamente:

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

    Esse comando gera os seguintes arquivos:

    • management_domain_deployment_input.json
    • python_scripts_input_config.json

  • Exporte apenas o JSON de entrada de implantação do domínio de gerenciamento do VCF:

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

  • Exporte apenas o JSON de entrada do kit de ferramentas do Python:

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

  • Exportar de saídas salvas do Terraform ou de entrada padrão 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 .

A seguir

  1. Execute o kit de ferramentas de preparação de nós para redefinir a senha inicial do ESXi root em cada host, preparar os nós para a implantação do VCF e implantar o dispositivo instalador do VCF usando a saída python_scripts_input_config da configuração completa do Terraform (convertida em JSON usando o script auxiliar). Para instruções, consulte Preparar nós e implantar o VCF usando o kit de ferramentas.
  2. Configure a conexão com o repositório regional off-line no instalador do VCF para fazer o download dos pacotes de software necessários:
    • Protocolo: HTTPS
    • FQDN (não use um endereço IP): offline-depot.REGION.selfmanagedvmwareengine.goog (substitua REGION pela região do Google Cloud em que os nós bare metal estão)
    • Porta: 443
    • Nome de usuário: vcf-depot-user
    • Senha: Google1!
  3. Implante o domínio de gerenciamento fornecendo o arquivo JSON management_domain_deployment_input_config (exportado usando o script auxiliar) ao instalador do VCF. Substitua todos os campos marcados como user_should_input na configuração de entrada pelos valores de destino. Para instruções sobre como concluir o fluxo de trabalho de ativação do VCF, consulte Implantar uma nova frota do VCF ou uma nova instância do VCF na documentação da Broadcom.
  4. Expanda a capacidade do cluster adicionando nós em Gerenciar a capacidade de nós usando o Terraform.
  5. Provisione balanceadores de carga e registros DNS para outros dispositivos VCF em Adicionar dispositivos VCF usando o Terraform.