Esegui il deployment dei nodi e di VCF utilizzando Terraform e il toolkit

Questo documento spiega come utilizzare l'automazione di Terraform per eseguire il deployment di nodi ESXi bare metal, reti di trasmissione di livello 2, Cloud DNS e bilanciatori del carico interni (ILB) regionali per la soluzione VMware su Google Cloud con VMware Cloud Foundation (VCF).

L'automazione esegue il provisioning della seguente infrastruttura:

  • Hypervisor ESXi bare metal dedicati (z3-highmem-192-highlssd-metal o z3-highmem-192-metal).
  • Reti di trasmissione di livello 2 multi-VLAN con frame jumbo (MTU 8896).
  • Zone Cloud DNS private gestite e policy di forwarding delle query in entrata.
  • ILB regionali con ARP senza costi / annuncio router (GARP_RA) Alta affidabilità con spostamento rapido dell'IP.
  • Gruppi di endpoint di rete (NEG) a livello di zona per le interfacce di gestione e del percorso dati NSX.

Prima di iniziare

Prima di eseguire l'automazione di Terraform, installa gli strumenti richiesti, abilita le API richieste, inserisci nella lista consentita il networking delle subnet di livello 2 e verifica i seguenti requisiti per il tuo progetto Google Cloud :

  1. Assicurati che il tuo progetto disponga di una quota di nodi bare metal sufficiente nella regione e nella zona di destinazione. Per le quote richieste e le istruzioni su come visualizzare o richiedere aumenti delle quote, consulta Quote e limiti.
  2. Assicurati di disporre delle autorizzazioni Identity and Access Management (IAM) richieste, tra cui Compute Admin (roles/compute.admin) e, se utilizzi Cloud DNS, DNS Administrator (roles/dns.admin).
  3. Pianifica l'infrastruttura DNS (Domain Name System) in modo da supportare le ricerche dirette e inverse per tutti i nomi host dei nodi ESXi e gli endpoint delle appliance VCF pianificati.
  4. Nomi host dei nodi: fornisci il nome di dominio completo (FQDN) di ogni nodo durante il deployment. In questo modo, ESXi genera i certificati utilizzando i nomi host.
  5. Policy per immagini attendibili: se la tua organizzazione non applica la policy dell'organizzazione constraints/compute.trustedImageProjects, non è richiesta alcuna azione. Se la tua organizzazione applica questa policy, consenti projects/smve-prod-public-images in modo che Compute Engine possa creare dischi di avvio bare metal. Per saperne di più, consulta Imposta limitazioni di accesso alle immagini.

  6. Controlli di servizio VPC: se il progetto di destinazione non si trova in un perimetro di servizio, non è necessaria alcuna azione. Se il tuo progetto si trova in un perimetro di servizio, aggiungi una regola in uscita che consenta le operazioni compute.googleapis.com sul progetto smve-prod-public-images (projects/999037279871):

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

    Per saperne di più, consulta il Riferimento per le regole in uscita.

Installa Terraform

Devi installare Terraform CLI versione 1.3.0 o successive. Per installare Terraform, seleziona la scheda del tuo sistema operativo:

Debian o Ubuntu

Per installare Terraform su Debian o Ubuntu, esegui questi comandi:

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

Per installare Terraform su RHEL o CentOS, esegui questi comandi:

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 generico

Per installare Terraform scaricando direttamente il file binario, esegui i seguenti comandi:

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'

Abilita le API Google Cloud

Abilita le seguenti API richieste nel progetto Google Cloud di destinazione:

Endpoint di servizio Finalità
compute.googleapis.com Istanze bare metal, reti Virtual Private Cloud (VPC), subnet di livello 2, firewall, NEG, ILB regionali e prenotazioni di IP statici.
dns.googleapis.com Zone gestite DNS di forwarding e DNS inverso private, policy di forwarding in entrata e set di record DNS.

Per abilitare le API richieste utilizzando l'interfaccia a riga di comando gcloud, esegui il seguente comando:

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

Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud target.

Verifica la quota a livello di regione

Prima di eseguire il provisioning dei nodi bare metal o di creare un cluster, verifica che il tuo progetto disponga di una quota Compute Engine regionale e globale sufficiente. Aggiungi le risorse di tutti i cluster esistenti nella regione ai seguenti valori incrementali prima di confrontarli con la quota del progetto:

Metrica di quota Risorse richieste per nodo bare metal Risorse richieste per un cluster a 3 nodi
compute.googleapis.com/cpus_per_vm_family per Z3 192 vCPU 3 x 192 = 576 vCPU
compute.googleapis.com/local_ssd_total_storage_per_vm_family per Z3 72 TB 3 x 72 TB = 216 TB
compute.googleapis.com/hyperdisk_balanced_total_storage 128 GB 3 × 128 GB = 384 GB
compute.googleapis.com/resource_policies 0 quando aggiungi nodi a un cluster esistente 1 policy di posizionamento distribuito per cluster
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0 quando aggiungi nodi o cluster senza nuove appliance 1 per ogni nuovo VIP dell'appliance di gestione VCF o endpoint NSX Edge

Per l'elenco completo delle quote richieste e le istruzioni su come visualizzare o richiedere aumenti delle quote, consulta Quote e limiti.

Consenti il networking di subnet di livello 2 basato su VLAN

La soluzione VMware richiede che le subnet della rete Virtual Private Cloud (VPC) abbiano la proprietà Risolvi subnet mask impostata su Trasmetti solo l'intervallo principale con apprendimento per supportare il networking basato su VLAN. Apri un ticket di assistenza nel Centro assistenza della consoleGoogle Cloud con le seguenti informazioni:

  • Prodotto: Google Cloud VMware Engine
  • Priorità: P2
  • Categoria: connettività di rete
  • Impatto aziendale: domanda tecnica generale
  • Fornisci maggiori dettagli: Allowlist L2 network connectivity for my project, oltre all'ID progetto, al numero di progetto e alla regione e alla zona di destinazione del deployment

Per ulteriori informazioni sul supporto del networking basato su VLAN, consulta Emulazione di livello 2: trasmissione ARP e apprendimento MAC personalizzato.

Configura la policy dell'organizzazione e i Controlli di servizio VPC

Le istanze ESXi bare metal nella soluzione VMware vengono avviate dalle immagini ESXi fornite da Google e ospitate nel progetto smve-prod-public-images, che ha il numero di progetto 999037279871. Per impostazione predefinita, non è richiesta alcuna configurazione aggiuntiva. Applica le seguenti configurazioni solo se la tua organizzazione applica una policy per immagini attendibili o utilizza i Controlli di servizio VPC:

  • Policy per immagini attendibili: se la tua organizzazione non applica la policy dell'organizzazione constraints/compute.trustedImageProjects, non è richiesta alcuna azione. Se la tua organizzazione applica questa policy, consenti projects/smve-prod-public-images in modo che Compute Engine possa creare dischi di avvio bare metal. Per saperne di più, consulta Imposta limitazioni di accesso alle immagini.

  • Regola in uscita dei Controlli di servizio VPC: se il progetto di destinazione non si trova in un perimetro di servizio, non è richiesta alcuna azione. Se il tuo progetto si trova in un perimetro di servizio, aggiungi una regola in uscita che consenta le operazioni compute.googleapis.com sul progetto smve-prod-public-images (projects/999037279871):

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

    Per saperne di più, consulta il Riferimento per le regole in uscita.

Configura i ruoli e le autorizzazioni IAM

L'identità che esegue Terraform (un amministratore umano o un account di servizio CI/CD automatizzato) richiede i seguenti ruoli IAM nel progettoGoogle Cloud di destinazione:

Ruolo ID ruolo Ambito di utilizzo
Amministratore Compute roles/compute.admin Esegui il provisioning di istanze di computing bare metal, collega immagini disco di avvio personalizzate, configura policy di posizionamento e gestisci interfacce multi-NIC. Gestire le reti VPC, le subnet di trasmissione di livello 2, le prenotazioni di IP statici, gli ILB regionali, i servizi di backend, le regole di forwarding e i NEG di zona. Creare e gestire le regole di sicurezza del firewall in entrata VPC.
DNS Administrator roles/dns.admin Gestisci le zone di forwarding privato e inverso di Cloud DNS, le policy di forwarding delle query in entrata e i set di record di risorse A e PTR.
Utente account di servizio roles/iam.serviceAccountUser Concedi questo ruolo al account di servizio Compute Engine predefinito (PROJECT_NUMBER-compute@) per consentire il provisioning delle istanze con l'ambito cloud-platform.

Concedi i ruoli utilizzando gcloud CLI

Per assegnare i ruoli a livello di progetto e le autorizzazioni dei account di servizio richiesti, esegui i seguenti comandi:

# 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'

Prima di eseguire i comandi, sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto Google Cloud target.
  • PROJECT_NUMBER: il numero del progetto Google Cloud di destinazione.
  • USER_EMAIL: l'indirizzo email della tua identità utente.

Autentica il runner Terraform

Scegli una delle seguenti strategie di autenticazione in base al tuo ambiente operativo:

Esegui l'autenticazione utilizzando la simulazione dell'identità dei account di servizio

La simulazione dell'identità dei service account elimina le chiavi delle credenziali di lunga durata generando token di accesso OAuth 2.0 di breve durata. La tua identità personale esegue l'autenticazione, mentre Terraform viene eseguito come account di servizio designato. Google Cloud controlla le azioni eseguite da Terraform rispetto al account di servizio.

  1. Concedi alla tua identità Google Cloud personale il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) sul service account runner:

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

    Prima di eseguire il comando, sostituisci quanto segue:

    • SA_EMAIL: l'indirizzo email del service account runner di Terraform.
    • USER_EMAIL: l'indirizzo email della tua identità Google Cloud personale.
    • PROJECT_ID: l'ID del progetto Google Cloud target.

  2. Autentica il tuo ambiente locale:

    gcloud auth application-default login

  3. Imposta la variabile di ambiente GOOGLE_IMPERSONATE_SERVICE_ACCOUNT per applicare la simulazione dell'identità tra le esecuzioni di Terraform:

    export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT='SA_EMAIL'

Esegui l'autenticazione utilizzando le Credenziali predefinite dell'applicazione

Utilizza le Credenziali predefinite dell'applicazione (ADC) negli ambienti di sviluppo e test in cui la tua identità utente dispone direttamente delle autorizzazioni richieste. Google Cloud controlla le azioni rispetto alla tua identità personale:

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

Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud target.

Esegui l'autenticazione utilizzando un file di chiavi del account di servizio

Utilizza un file della chiave del account di servizio nelle pipeline CI/CD automatizzate (come Cloud Build, GitHub Actions o Jenkins) in cui l'accesso interattivo dell'utente non è supportato e l'autenticazione si basa su chiavi delle credenziali del account di servizio di lunga durata. Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS sul percorso del file della chiave del account di servizio:

export GOOGLE_APPLICATION_CREDENTIALS='KEY_FILE'

Sostituisci KEY_FILE con il percorso della chiave JSON del account di servizio.

Esamina l'architettura modulare

Terraform coordina il provisioning delle risorse in quattro fasi modulari. Questo design modulare applica un ordine di dipendenza rigoroso per garantire che i prerequisiti di networking esistano prima di eseguire il deployment di host di computing, bilanciatori del carico e record 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   |
+-----------------------------------------------------------------------------------+

Esegui il provisioning delle risorse per il cluster di gestione

Il cluster di gestione del dominio di gestione ospita le appliance del control plane VCF principali (SDDC Manager, vCenter Server, cluster di gestione NSX e VMware Aria Suite) e gli hypervisor ESXi.

Configura l'area di lavoro Terraform

Crea una directory dell'area di lavoro dedicata e clona il repository del toolkit utilizzando Git:

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

Configura il file delle definizioni delle variabili

Crea il file di definizione delle variabili (management_cluster.tfvars) con i valori dell'ambiente di destinazione. Copia il file sample_management_cluster.tfvars dalla directory e2e-terraform nel file management_cluster.tfvars e segui le istruzioni e i commenti incorporati per aggiornare i campi in base alle esigenze:

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

Applica la configurazione Terraform

Vai alla directory self-managed-vmware-solution-toolkit/e2e-terraform, quindi inizializza e applica la configurazione Terraform:

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

Esamina ed esporta gli output di Terraform

Dopo aver eseguito terraform apply, Terraform espone output strutturati in quattro categorie:

  • gcp_resources_self_links: URL completi dei link alla pagina corrente delle risorse Google Cloud per reti VPC, subnet, istanze, policy di posizionamento, NEG, servizi di backend, regole di forwarding, firewall e zone Cloud DNS.
  • neg_attachment_commands:
    • Quando la variabile deployment_mode è impostata su "cluster_creation": restituisce un messaggio di stato che indica che Terraform collega automaticamente i NEG durante la creazione del cluster.
    • Quando la variabile deployment_mode è impostata su "node_addition": fornisce i comandi gcloud compute network-endpoint-groups update necessari per collegare le istanze host ESXi di cui è stato appena eseguito il provisioning ai NEG di gestione e NSX.
    • Quando la variabile deployment_mode è impostata su "appliance_addition": restituisce un messaggio di stato che indica che i NEG rimangono collegati ai nodi del cluster esistenti e che Terraform non li modifica durante l'aggiunta dell'appliance.
  • python_scripts_input_config: payload di configurazione dei parametri strutturati per gli script di automazione del deployment del programma di installazione VCF downstream nella directory python del toolkit. Puoi convertire questo output nel formato JSON previsto dagli script Python del toolkit eseguendo lo script di supporto descritto nella sezione successiva.
  • management_domain_deployment_input_config: input strutturato per il deployment del dominio di gestione con la maggior parte dei campi precompilati dal provisioning end-to-end. Puoi modificare questo input dove richiesto o indicato e convertirlo in un file JSON per il deployment del dominio di gestione utilizzando lo script di esportazione descritto nella sezione successiva.

Esporta le configurazioni di deployment

Il toolkit include uno script di supporto (scripts/export_deployment_config.py) che estrae i blocchi di configurazione dagli output di Terraform e li esporta in file JSON formattati e conformi allo schema per i workflow downstream:

  • management_domain_deployment_input_config: JSON di input per il deployment del dominio di gestione VCF.
  • python_scripts_input_config: input JSON (config.json) per gli script di automazione Python del toolkit (vcf_deployer).

Esegui lo script helper

Esegui lo script helper dalla directory e2e-terraform (o specifica i flag -d o -i) scegliendo una delle seguenti opzioni:

  • Esporta entrambe le configurazioni contemporaneamente:

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

    Questo comando genera i seguenti file:

    • management_domain_deployment_input.json
    • python_scripts_input_config.json

  • Esporta solo il file JSON di input del deployment del dominio di gestione VCF:

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

  • Esporta solo il JSON di input del toolkit Python:

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

  • Esporta dagli output Terraform salvati o dall'input standard con pipe (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 .

Passaggi successivi

  1. Esegui il toolkit di preparazione dei nodi per reimpostare la password iniziale di ESXi root su ogni host, preparare i nodi per il deployment di VCF ed eseguire il deployment dell'appliance di installazione VCF utilizzando l'output python_scripts_input_config della configurazione Terraform end-to-end (convertito in JSON utilizzando lo script helper). Per istruzioni, consulta Prepara i nodi ed esegui il deployment di VCF utilizzando il toolkit.
  2. Configura la connessione al repository offline regionale nel programma di installazione VCF per scaricare i bundle software richiesti:
    • Protocollo: HTTPS
    • FQDN (non utilizzare un indirizzo IP): offline-depot.REGION.selfmanagedvmwareengine.goog (sostituisci REGION con la regione Google Cloud in cui si trovano i nodi bare metal)
    • Porta: 443
    • Nome utente: vcf-depot-user
    • Password: Google1!
  3. Esegui il deployment del dominio di gestione fornendo il file JSON management_domain_deployment_input_config (esportato utilizzando lo script di supporto) al programma di installazione di VCF. Assicurati di sostituire tutti i campi contrassegnati come user_should_input nella configurazione di input con i valori di destinazione. Per istruzioni su come completare il flusso di lavoro di attivazione di VCF, consulta Esegui il deployment di un nuovo parco risorse VCF o di una nuova istanza VCF nella documentazione di Broadcom.
  4. Espandi la capacità del cluster aggiungendo nodi in Gestisci la capacità dei nodi utilizzando Terraform.
  5. Esegui il provisioning dei bilanciatori del carico e dei record DNS per appliance VCF aggiuntive in Aggiungi appliance VCF utilizzando Terraform.