Renommer le repertoire cles en key

VMS.md

@@ -0,0 +1,79 @@
+# 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 :
+
+```hcl
+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 :
+
+```bash
+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.