Déployer des nœuds et VCF à l'aide de Terraform et du kit d'outils

Ce document explique comment utiliser l'automatisation Terraform pour déployer des nœuds ESXi bare metal, des réseaux de diffusion de couche 2, Cloud DNS et des équilibreurs de charge internes régionaux pour la solution VMware sur Google Cloud avec VMware Cloud Foundation (VCF).

L'automatisation provisionne l'infrastructure suivante :

  • Hyperviseurs ESXi bare metal dédiés (z3-highmem-192-highlssd-metal ou z3-highmem-192-metal).
  • Réseaux de diffusion de couche 2 multi-VLAN avec trames géantes (MTU 8896).
  • Zones gérées privées Cloud DNS et règles de transfert des requêtes entrantes.
  • Équilibreurs de charge internes régionaux avec ARP spontané / annonce de routeur (GARP_RA) Haute disponibilité du déplacement rapide d'adresse IP.
  • Groupes de points de terminaison du réseau (NEG) zonaux pour les interfaces de gestion et de chemin d'accès aux données NSX.

Avant de commencer

Avant d'exécuter l'automatisation Terraform, installez les outils requis, activez les API requises, ajoutez à la liste d'autorisation la mise en réseau de sous-réseau de couche 2 et vérifiez les exigences suivantes pour votre projet Google Cloud  :

  1. Assurez-vous que votre projet dispose d'un quota de nœuds bare metal suffisant dans votre région et votre zone cibles. Pour connaître les quotas requis et savoir comment afficher ou demander des augmentations de quota, consultez Quotas et limites.
  2. Assurez-vous de disposer des autorisations IAM (Identity and Access Management) requises, y compris Compute Admin (roles/compute.admin) et, si vous utilisez Cloud DNS, DNS Administrator (roles/dns.admin).
  3. Planifiez votre infrastructure DNS (système de noms de domaine) pour prendre en charge les recherches directes et inversées pour tous les noms d'hôte de nœud ESXi et les points de terminaison d'appareil VCF prévus.
  4. Noms d'hôte des nœuds : indiquez le nom de domaine complet (FQDN) de chaque nœud lors du déploiement. Cela garantit qu'ESXi génère des certificats à l'aide de noms d'hôte.
  5. Règlement relatif aux images de confiance : si votre organisation n'applique pas la règle d'administration constraints/compute.trustedImageProjects, aucune action n'est requise. Si votre organisation applique cette règle, autorisez projects/smve-prod-public-images afin que Compute Engine puisse créer des disques de démarrage bare metal. Pour en savoir plus, consultez Définir des contraintes d'accès aux images.

  6. VPC Service Controls : si votre projet cible ne se trouve pas dans un périmètre de service, aucune action n'est requise. Si votre projet se trouve dans un périmètre de service, ajoutez une règle de sortie qui autorise les opérations compute.googleapis.com sur le projet smve-prod-public-images (projects/999037279871) :

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

    Pour en savoir plus, consultez la documentation de référence sur les règles de sortie.

Installer Terraform

Vous devez installer Terraform CLI version 1.3.0 ou ultérieure. Pour installer Terraform, sélectionnez l'onglet correspondant à votre système d'exploitation :

Debian ou Ubuntu

Pour installer Terraform sur Debian ou Ubuntu, exécutez les commandes suivantes :

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

Pour installer Terraform sur RHEL ou CentOS, exécutez les commandes suivantes :

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 générique

Pour installer Terraform en téléchargeant directement le binaire, exécutez les commandes suivantes :

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'

Activer les API Google Cloud

Activez les API requises suivantes dans votre projet Google Cloud cible :

Point de terminaison de service Objectif
compute.googleapis.com Instances Bare Metal, réseaux de cloud privé virtuel (VPC), sous-réseaux de couche 2, pare-feu, NEG, équilibreurs de charge internes régionaux et réservations d'adresses IP statiques.
dns.googleapis.com Zones gérées DNS privées de transfert et inversées, règles de transfert entrant et jeux d'enregistrements DNS.

Pour activer les API requises à l'aide de la CLI gcloud, exécutez la commande suivante :

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

Remplacez PROJECT_ID par l'ID de votre projet cible Google Cloud .

Vérifier les quotas régionaux

Avant de provisionner des nœuds Bare Metal ou de créer un cluster, vérifiez que votre projet dispose d'un quota Compute Engine régional et mondial suffisant. Ajoutez les ressources de tous les clusters existants de la région aux valeurs incrémentielles suivantes avant de les comparer au quota de votre projet :

Métrique de quota Ressources requises par nœud Bare Metal Ressources requises pour un cluster à trois nœuds
compute.googleapis.com/cpus_per_vm_family pour Z3 192 vCPU 3 × 192 = 576 vCPU
compute.googleapis.com/local_ssd_total_storage_per_vm_family pour Z3 72 To 3 × 72 To = 216 To
compute.googleapis.com/hyperdisk_balanced_total_storage 128 Go 3 × 128 Go = 384 Go
compute.googleapis.com/resource_policies 0 lors de l'ajout de nœuds à un cluster existant 1 stratégie d'emplacement par répartition par cluster
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0 lors de l'ajout de nœuds ou de clusters sans nouvelles appliances 1 par nouvelle adresse IP virtuelle d'appareil de gestion VCF ou point de terminaison NSX Edge

Pour obtenir la liste complète des quotas requis et des instructions sur la façon d'afficher ou de demander des augmentations de quota, consultez Quotas et limites.

Mettre en liste d'autorisation la mise en réseau de sous-réseaux de couche 2 basée sur les VLAN

La solution VMware nécessite que la propriété Résoudre le masque de sous-réseau des sous-réseaux de votre réseau cloud privé virtuel (VPC) soit définie sur Diffuser la plage principale uniquement avec l'apprentissage pour prendre en charge la mise en réseau basée sur les VLAN. Ouvrez une demande d'assistance dans le Centre d'assistance de la consoleGoogle Cloud en fournissant les informations suivantes :

  • Produit : Google Cloud VMware Engine
  • Priority : P2
  • Catégorie : Connectivité réseau
  • Impact sur l'entreprise : question technique d'ordre général
  • Fournissez plus de détails : Allowlist L2 network connectivity for my project, ainsi que l'ID de votre projet, son numéro, et la région et la zone cibles de votre déploiement.

Pour en savoir plus sur la compatibilité avec la mise en réseau basée sur les VLAN, consultez Émulation de couche 2 : diffusion ARP et apprentissage MAC personnalisé.

Configurer la règle d'administration et VPC Service Controls

Les instances ESXi bare metal de la solution VMware démarrent à partir d'images ESXi fournies par Google et hébergées dans le projet smve-prod-public-images, dont le numéro est 999037279871. Par défaut, aucune configuration supplémentaire n'est requise. N'appliquez les configurations suivantes que si votre organisation applique une règle relative aux images de confiance ou utilise VPC Service Controls :

  • Règlement relatif aux images de confiance : si votre organisation n'applique pas la règle d'administration constraints/compute.trustedImageProjects, aucune action n'est requise. Si votre organisation applique cette règle, autorisez projects/smve-prod-public-images afin que Compute Engine puisse créer des disques de démarrage bare metal. Pour en savoir plus, consultez Définir des contraintes d'accès aux images.

  • Règle de sortie VPC Service Controls : si votre projet cible ne se trouve pas dans un périmètre de service, aucune action n'est requise. Si votre projet se trouve dans un périmètre de service, ajoutez une règle de sortie qui autorise les opérations compute.googleapis.com vers le projet smve-prod-public-images (projects/999037279871) :

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

    Pour en savoir plus, consultez la documentation de référence sur les règles de sortie.

Configurer les autorisations et les rôles IAM

L'identité qui exécute Terraform (un administrateur humain ou un compte de service CI/CD automatisé) nécessite les rôles IAM suivants sur le projetGoogle Cloud cible :

Rôle ID de rôle Champ d'application de l'utilisation
Administrateur de Compute roles/compute.admin Provisionnez des instances de calcul Bare Metal, associez des images disque de démarrage personnalisées, configurez des règles d'emplacement et gérez des interfaces multi-NIC. Gérer les réseaux VPC, les sous-réseaux de diffusion de couche 2, les réservations d'adresses IP statiques, les équilibreurs de charge internes régionaux, les services de backend, les règles de transfert et les NEG zonaux. Créer et gérer des règles de sécurité de pare-feu d'entrée VPC.
Administrateur DNS roles/dns.admin Gérez les zones de transfert et de recherche inversée privées Cloud DNS, les règles de transfert de requêtes entrantes et les jeux d'enregistrements de ressources A et PTR.
Utilisateur du compte de service roles/iam.serviceAccountUser Attribuez ce rôle au compte de service Compute Engine par défaut (PROJECT_NUMBER-compute@) pour autoriser le provisionnement d'instances avec le champ d'application cloud-platform.

Attribuer des rôles à l'aide de la gcloud CLI

Pour attribuer les rôles et les autorisations de compte de service requis au niveau du projet, exécutez les commandes suivantes :

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

Avant d'exécuter les commandes, remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet Google Cloud cible.
  • PROJECT_NUMBER : numéro de votre projet Google Cloudcible.
  • USER_EMAIL : adresse e-mail de votre identité utilisateur.

Authentifier l'exécuteur Terraform

Choisissez l'une des stratégies d'authentification suivantes en fonction de votre environnement opérationnel :

S'authentifier à l'aide de l'emprunt d'identité d'un compte de service

L'emprunt d'identité d'un compte de service élimine les clés d'identifiants de longue durée en générant des jetons d'accès OAuth 2.0 de courte durée. Votre identité personnelle s'authentifie, tandis que Terraform s'exécute en tant que compte de service désigné.Google Cloud audite les actions effectuées par Terraform sur le compte de service.

  1. Attribuez à votre identité personnelle Google Cloud le rôle Créateur de jetons de compte de service (roles/iam.serviceAccountTokenCreator) sur le compte de service de l'exécuteur :

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

    Avant d'exécuter la commande, remplacez les éléments suivants :

    • SA_EMAIL : adresse e-mail du compte de service de l'exécuteur Terraform.
    • USER_EMAIL : adresse e-mail de votre identité personnelle Google Cloud.
    • PROJECT_ID : ID de votre projet Google Cloud cible.

  2. Authentifiez votre environnement local :

    gcloud auth application-default login

  3. Définissez la variable d'environnement GOOGLE_IMPERSONATE_SERVICE_ACCOUNT pour appliquer l'emprunt d'identité dans les exécutions Terraform :

    export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT='SA_EMAIL'

Définir une authentification basée sur les identifiants par défaut de l'application

Utilisez les identifiants par défaut de l'application (ADC) dans les environnements de développement et de test où votre identité utilisateur détient directement les autorisations requises. Google Cloud audite les actions par rapport à votre identité personnelle :

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

Remplacez PROJECT_ID par l'ID de votre projet cible Google Cloud .

S'authentifier à l'aide d'un fichier de clé de compte de service

Utilisez un fichier de clé de compte de service dans les pipelines CI/CD automatisés (comme Cloud Build, GitHub Actions ou Jenkins) où la connexion interactive des utilisateurs n'est pas possible et où l'authentification repose sur des clés d'identifiants de compte de service de longue durée. Définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS sur le chemin d'accès au fichier de clé de votre compte de service :

export GOOGLE_APPLICATION_CREDENTIALS='KEY_FILE'

Remplacez KEY_FILE par le chemin d'accès à la clé JSON de votre compte de service.

Examiner l'architecture modulaire

Terraform coordonne le provisionnement des ressources en quatre étapes modulaires. Cette conception modulaire applique un ordre de dépendance strict pour s'assurer que les conditions préalables de mise en réseau existent avant de déployer des hôtes de calcul, des équilibreurs de charge et des enregistrements 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   |
+-----------------------------------------------------------------------------------+

Provisionner des ressources pour le cluster de gestion

Le cluster de gestion du domaine de gestion héberge les appareils du plan de contrôle VCF de base (SDDC Manager, vCenter Server, cluster NSX Management et VMware Aria Suite) et les hyperviseurs ESXi.

Configurer l'espace de travail Terraform

Créez un répertoire d'espace de travail dédié et clonez le dépôt du kit d'outils à l'aide de Git :

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

Configurer le fichier de définitions de variables

Créez votre fichier de définitions de variables (management_cluster.tfvars) avec les valeurs de votre environnement cible. Copiez le fichier sample_management_cluster.tfvars du répertoire e2e-terraform dans votre fichier management_cluster.tfvars, puis suivez les instructions et les commentaires intégrés pour mettre à jour les champs si nécessaire :

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

Appliquer la configuration Terraform

Accédez au répertoire self-managed-vmware-solution-toolkit/e2e-terraform, puis initialisez et appliquez la configuration Terraform :

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

Examiner et exporter les résultats Terraform

Après l'exécution de terraform apply, Terraform expose des sorties structurées dans quatre catégories :

  • gcp_resources_self_links : URL de lien d'auto-référencement de ressource Google Cloud complètes pour les réseaux VPC, les sous-réseaux, les instances, les règles d'emplacement, les NEG, les services de backend, les règles de transfert, les pare-feu et les zones Cloud DNS.
  • neg_attachment_commands :
    • Lorsque la variable deployment_mode est définie sur "cluster_creation" : renvoie un message d'état indiquant que Terraform associe automatiquement des NEG lors de la création du cluster.
    • Lorsque la variable deployment_mode est définie sur "node_addition" : fournit les commandes gcloud compute network-endpoint-groups update requises pour associer les instances d'hôte ESXi nouvellement provisionnées aux NEG de gestion et NSX.
    • Lorsque la variable deployment_mode est définie sur "appliance_addition" : renvoie un message d'état indiquant que les NEG restent associés aux nœuds de cluster existants et que Terraform ne les modifie pas lors de l'ajout de l'appareil.
  • python_scripts_input_config : charge utile de configuration des paramètres structurés pour les scripts d'automatisation du déploiement du programme d'installation VCF en aval dans le répertoire python du kit d'outils. Vous pouvez convertir ce résultat au format JSON attendu par les scripts Python du kit d'outils en exécutant le script d'aide décrit dans la section suivante.
  • management_domain_deployment_input_config : entrée structurée pour le déploiement du domaine de gestion, avec la plupart des champs préremplis à partir du provisionnement de bout en bout. Vous pouvez modifier cette entrée si nécessaire ou si cela est indiqué, puis la convertir en fichier JSON pour le déploiement du domaine de gestion à l'aide du script d'exportation décrit dans la section suivante.

Exporter des configurations de déploiement

Le kit d'outils inclut un script d'assistance (scripts/export_deployment_config.py) qui extrait les blocs de configuration des sorties Terraform et les exporte dans des fichiers JSON formatés et conformes au schéma pour les workflows en aval :

  • management_domain_deployment_input_config : JSON d'entrée pour le déploiement du domaine de gestion VCF.
  • python_scripts_input_config : JSON d'entrée (config.json) pour les scripts d'automatisation Python du kit d'outils (vcf_deployer).

Exécuter le script d'assistance

Exécutez le script d'assistance à partir du répertoire e2e-terraform (ou spécifiez les options -d ou -i) en choisissant l'une des options suivantes :

  • Exportez les deux configurations simultanément :

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

    Cette commande génère les fichiers suivants :

    • management_domain_deployment_input.json
    • python_scripts_input_config.json

  • Exportez uniquement le fichier JSON d'entrée de déploiement du domaine de gestion VCF :

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

  • Exportez uniquement le fichier JSON d'entrée du kit d'outils Python :

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

  • Exportez à partir des sorties Terraform enregistrées ou de l'entrée standard redirigée (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 .

Étapes suivantes

  1. Exécutez le kit d'outils de préparation des nœuds pour réinitialiser le mot de passe ESXi root initial sur chaque hôte, préparer les nœuds pour le déploiement VCF et déployer l'appareil d'installation VCF à l'aide de la sortie python_scripts_input_config de la configuration Terraform de bout en bout (convertie en JSON à l'aide du script d'assistance). Pour obtenir des instructions, consultez Préparer les nœuds et déployer VCF à l'aide du kit d'outils.
  2. Configurez la connexion au dépôt régional hors connexion dans le programme d'installation VCF pour télécharger les bundles logiciels requis :
    • Protocole : HTTPS
    • FQDN (n'utilisez pas d'adresse IP) : offline-depot.REGION.selfmanagedvmwareengine.goog (remplacez REGION par la région Google Cloud où résident vos nœuds Bare Metal)
    • Port : 443
    • Nom d'utilisateur : vcf-depot-user
    • Mot de passe : Google1!
  3. Déployez le domaine de gestion en fournissant le fichier JSON management_domain_deployment_input_config (exporté à l'aide du script d'assistance) au programme d'installation de VCF. Veillez à remplacer tous les champs marqués comme user_should_input dans la configuration d'entrée par vos valeurs cibles. Pour savoir comment effectuer le workflow de mise en service de VCF, consultez Déployer un nouveau parc VCF ou une nouvelle instance VCF dans la documentation Broadcom.
  4. Augmentez la capacité du cluster en ajoutant des nœuds dans Gérer la capacité des nœuds à l'aide de Terraform.
  5. Provisionnez des équilibreurs de charge et des enregistrements DNS pour des appareils VCF supplémentaires dans Ajouter des appareils VCF à l'aide de Terraform.