terraform-proxmox-serveur-debian-12/VMS.md

Créer plusieurs VM avec ce dépôt

Une VM = un fichier vms/<nom>.tfvars + un espace de travail Terraform du même nom. Chaque VM a donc son propre état : en détruire une ne touche pas aux autres, et un plan raté sur l'une n'a aucun effet sur l'autre.

vms/
├── centreon.tfvars           VM 120, Debian 12, 10.0.5.20
└── exemple-debian13.tfvars   VM 121, Debian 13, 10.0.5.21

Dans le bucket S3, les états se rangent sous env:/<nom>/backend/…, automatiquement.

Ajouter une VM

Copier un fichier existant, le renommer, puis adapter. Trois valeurs doivent être uniques sur l'infrastructure, et rien ne le vérifie — deux VM avec le même vm_id provoquent un échec à la création, deux avec la même IP un conflit silencieux :

• vm_id
• vm_hostname
• vm_ipv4_address

Un git push déclenche le plan de toutes les VM déclarées : c'est le filet qui attrape une erreur de syntaxe ou un fichier de clé manquant avant tout déploiement.

Pour créer la VM, lancer deploy en saisissant son nom dans le champ vm. Le workflow refuse un nom sans fichier correspondant et liste les VM connues.

Changer de version de Debian

Deux lignes, dans le fichier de la VM concernée :

debian_image_url       = "https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2"
debian_image_file_name = "debian-13-genericcloud-amd64.qcow2"

Le reste du code n'en dépend pas : comptes, durcissement SSH, nftables, agent invité et mises à jour automatiques sont identiques d'une version à l'autre. Le nom du fichier doit garder une extension .qcow2, .raw ou .vmdk, seules acceptées par le contenu import de Proxmox.

Une limite à connaître : Centreon 25.10 n'existe que pour Debian 12. Le dépôt ansible-centreon refuse d'ailleurs de s'exécuter sur autre chose. Une VM Debian 13 convient pour tout le reste.

Migration de l'existant

La VM centreon a été créée avant ce découpage, son état vit donc dans l'espace default. Le workflow migrer-espaces le recopie une fois pour toutes dans l'espace centreon, sans rien détruire : confirmation MIGRER, puis il vérifie qu'aucune modification n'est proposée ensuite.

À lancer avant tout autre workflow. Sans cette migration, un deploy sur la VM centreon la verrait comme inexistante et tenterait de la recréer — avec un VMID déjà pris, donc un échec, mais autant l'éviter.

L'espace default conservera une copie de l'état après migration. Terraform interdit de le supprimer, et plus aucun workflow ne l'utilise : il devient inerte.

Commandes hors CI

Pour un essai ponctuel, par conteneur :

docker run --rm -it -v "$PWD":/work -w /work \
  -e TF_VAR_pve_api_token -e TF_VAR_pve_ssh_password \
  -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY \
  hashicorp/terraform:latest workspace list

workspace list montre les espaces existants, workspace select <nom> bascule, et chaque commande doit ensuite recevoir -var-file=vms/<nom>.tfvars. Se tromper de couple espace/fichier est la seule vraie façon de se faire mal ici : Terraform comparerait l'état d'une VM à la définition d'une autre et proposerait de tout recréer. C'est la raison pour laquelle les workflows sélectionnent toujours les deux ensemble, à partir du même nom.