Terraform — Providers on-prem

Fiche express
Type	Providers Terraform pour l'on-prem
Providers couverts	vsphere, rancher2
Articulation	Terraform (jour 0) → Ansible (jour 1) → GitOps (jour 2)
Secrets	Vault provider, state chiffré au repos
Voir aussi	Terraform — Concepts fondamentaux · Terraform — Modules et variables · Frontière IaC — Terraform, Ansible, GitOps

Deux providers structurants pour un socle on-prem : vsphere (provisionnement des machines virtuelles sur VMware) et rancher2 (provisionnement de clusters RKE2/Rancher). Le motif récurrent : Terraform provisionne, Ansible configure, GitOps déploie.

Provider vsphere

Cible un vCenter. Ressources typiques : machines virtuelles (souvent par clonage d'un template), resource pools, folders, réseaux distribués, datastores.

data "vsphere_datacenter"      "dc"   { name = "DC-Toulouse" }
data "vsphere_datastore"       "ds"   { name = "vsan", datacenter_id = data.vsphere_datacenter.dc.id }
data "vsphere_virtual_machine" "tpl"  { name = "ubuntu-2404-template", datacenter_id = data.vsphere_datacenter.dc.id }

resource "vsphere_virtual_machine" "node" {
  count            = var.node_count
  name             = "rke2-${count.index}"
  resource_pool_id = var.pool_id
  datastore_id     = data.vsphere_datastore.ds.id
  num_cpus         = 4
  memory           = 8192

  clone { template_uuid = data.vsphere_virtual_machine.tpl.id }
}

Points d'attention : personnalisation cloud-init/guestinfo au clonage, gestion des disques (thin/thick), et cohérence avec le SDN sous-jacent (port-groups NSX-T).

Provider rancher2

Pilote un Rancher Manager. Deux usages :

1. Provisionner un cluster RKE2 (import de nœuds, ou intégration avec un node driver/machine pool).
2. Configurer Rancher : projets, namespaces, cluster/project role template bindings, catalogues, secrets.

resource "rancher2_cluster_v2" "rke2" {
  name               = "prod-toulouse"
  kubernetes_version = "v1.30.5+rke2r1"

  rke_config {
    machine_global_config = <<-EOT
      cni: cilium
      disable: [rke2-ingress-nginx]
    EOT
  }
}

output "kubeconfig" {
  value     = rancher2_cluster_v2.rke2.kube_config
  sensitive = true
}

Motif d'articulation

<mermaid> flowchart LR

   TF[Terraform
vsphere + rancher2] -->|VM + cluster RKE2| INFRA[(Nœuds + K8s)]
   ANS[Ansible] -->|durcissement OS,
paquets, conf| INFRA
   ARGO[ArgoCD] -->|workloads, addons| INFRA

</mermaid>

Terraform s'arrête au jour 0 (l'infra et le cluster existent). Le durcissement système (CIS, AIDE, ClamAV) relève d'Ansible ; le déploiement applicatif et des addons (cert-manager, ESO, Cilium via Helm) relève d'ArgoCD. Voir la fiche d'arbitrage : Frontière IaC — Terraform, Ansible, GitOps.

State & secrets on-prem

• Backend distant recommandé : PostgreSQL, Consul, ou stockage objet MinIO (verrouillage à vérifier selon le backend).
• Les kubeconfig et mots de passe vCenter finissent dans le state → chiffrement au repos obligatoire, accès restreint.
• Injecter les secrets sensibles via HashiCorp Vault (provider vault) plutôt qu'en tfvars.

Voir aussi

• Terraform — Concepts fondamentaux
• Terraform — Modules et variables
• Terraform — Provider AWS
• Terraform — Provider Azure
• Terraform — Provider GCP
• Terraform — Provisioners
• Terraform — Tests et validation
• Terraform — Intégration CI/CD
• Frontière IaC — Terraform, Ansible, GitOps
• SDN datacenter vs overlay CNI