Files
hcornet ee0a1766f4
Terraform - plan / plan (push) Failing after 6s
first
2026-09-16 10:16:01 +02:00

2.5 KiB

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.

vms/
└── ubuntu-01.tfvars    VM 122, Ubuntu 24.04, 10.0.5.22

Dans le bucket S3, les états se rangent sous env:/<nom>/backend/terraform-proxmox-serveur-ubuntu-24-04/…, automatiquement.

Ajouter une VM

Copier vms/ubuntu-01.tfvars, le renommer, puis adapter. Trois valeurs doivent être uniques sur l'ensemble de l'infrastructure, y compris vis-à-vis du dépôt Debian, et rien ne le vérifie :

  • vm_id
  • vm_hostname
  • vm_ipv4_address

Répartition actuelle : le dépôt Debian occupe 120 / 10.0.5.20 et 121 / 10.0.5.21, celui-ci démarre à 122 / 10.0.5.22.

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 d'Ubuntu

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

ubuntu_image_url       = "https://cloud-images.ubuntu.com/releases/26.04/release/ubuntu-26.04-server-cloudimg-amd64.img"
ubuntu_image_file_name = "ubuntu-26.04-server-cloudimg-amd64.qcow2"

Le nom de fichier doit garder une extension .qcow2, .raw ou .vmdk : Canonical publie en .img, que le contenu import de Proxmox refuse, alors que le format réel est bien un qcow2. Le renommage suffit, il n'y a pas de conversion.

Les versions LTS disponibles au moment de l'écriture : 24.04 (Noble Numbat) et 26.04 (Resolute Raccoon). Remplacer 24.04 par la version voulue dans les deux lignes, le numéro apparaissant à la fois dans le chemin et dans le nom du fichier.

Commandes hors CI

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

Chaque commande doit ensuite recevoir -var-file=vms/<nom>.tfvars, avec l'espace de travail correspondant sélectionné. Se tromper de couple espace/fichier est la seule vraie façon de se faire mal : Terraform comparerait l'état d'une VM à la définition d'une autre et proposerait de tout recréer. C'est pour cela que les workflows dérivent toujours les deux du même nom.