Fournisseur Terraform vSphere

Le fournisseur Terraform vSphere gère Kyvernon par les points de terminaison SOAP, REST et de stratégies de stockage du contrôleur. La vérification enregistrée a utilisé Terraform 1.17.1 avec le fournisseur hashicorp/vsphere 2.17.1. Le fournisseur est documenté sur registry.terraform.io.

Avant de commencer

• Activez les points de terminaison de compatibilité : Paramètres des points de terminaison de compatibilité.
• Déterminez si votre configuration utilise des étiquettes (vsphere_tag_category, vsphere_tag et l'argument tags). Le fournisseur n'active les étiquettes que lorsque le point de terminaison signale le nom du produit vCenter Server du fabricant. Dans Kyvernon, cela demande le paramètre product_name, désactivé par défaut. Tout le reste fonctionne avec le nom par défaut.
• Le contrôleur utilise un certificat que le fournisseur ne connaît pas par défaut : définissez allow_unverified_ssl = true pour un test, ou faites confiance au certificat sur la machine qui exécute Terraform.

Avec la CLI

Une configuration telle qu'on l'écrit pour vSphere. Les noms des objets de l'inventaire sont ceux que la console affiche :

terraform {
  required_providers {
    vsphere = {
      source  = "hashicorp/vsphere"
      version = "2.17.1"
    }
  }
}

provider "vsphere" {
  vsphere_server       = "controller.example.com:8443"
  user                 = var.vsphere_user
  password             = var.vsphere_password
  allow_unverified_ssl = true
}

data "vsphere_datacenter" "dc" {
  name = "Datacenter"
}

data "vsphere_compute_cluster" "cluster" {
  name          = "Cluster-01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_datastore" "ds" {
  name          = "ds-local-01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_network" "net" {
  name          = "vm-net-01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

resource "vsphere_virtual_machine" "web" {
  name                       = "prod-web-01"
  resource_pool_id           = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id               = data.vsphere_datastore.ds.id
  num_cpus                   = 2
  memory                     = 2048
  guest_id                   = "otherLinux64Guest"
  firmware                   = "efi"
  wait_for_guest_net_timeout = 0

  network_interface {
    network_id = data.vsphere_network.net.id
  }

  disk {
    label = "disk0"
    size  = 20
  }
}

terraform init
terraform plan
terraform apply

Définissez wait_for_guest_net_timeout = 0 quand l'invité n'a aucun agent invité en cours d'exécution : sinon le fournisseur attendrait une adresse que la machine virtuelle ne peut pas signaler. Sans adresse signalée, le fournisseur planifie un changement de default_ip_address à chaque plan.

Ressources vérifiées

La séquence enregistrée est init, plan, apply, plan (aucun changement), apply d'une modification, plan (aucun changement) et destroy. La configuration utilisait les sources de données pour le datacenter, le cluster, l'hôte, le datastore, le réseau et le groupe de ressources, et les ressources vsphere_folder, vsphere_virtual_machine (UEFI, un disque à allocation dynamique, une carte réseau, une annotation), vsphere_virtual_machine_snapshot, vsphere_tag_category et vsphere_tag. La modification a ajouté un vCPU, de la mémoire, un deuxième disque, un disque agrandi, une étiquette et un instantané. Le détail par étape figure dans outils vérifiés.

Avec le nom de produit par défaut, les étapes init, plan et destroy réussissent. apply s'arrête avec le message indiquant que les étiquettes exigent le vCenter Server du fabricant, car la configuration utilisait des étiquettes. Avec product_name défini, la séquence complète a réussi.

Limites connues

• Les étiquettes demandent product_name (voir ci-dessus).
• Les types de carte vmxnet3, e1000e et e1000 sont acceptés et présentés à l'invité comme des cartes réseau virtio. Le type sriov est refusé.
• Les ressources de stratégies de stockage et les vApps du fournisseur ne sont pas servis. Le service de stratégies de stockage ne répond qu'à la demande de contenu du service.
• Les paramètres sans signification dans Kyvernon, par exemple la sensibilité à la latence ou l'ajout à chaud de mémoire, sont stockés et relus, et n'ont aucun effet.
• Une modification du CPU ou de la mémoire d'une machine virtuelle en cours d'exécution met d'abord la machine hors tension.

Voir aussi

• Vue d'ensemble de la compatibilité
• Paramètres des points de terminaison de compatibilité