80 lines
3.3 KiB
Markdown
80 lines
3.3 KiB
Markdown
# 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.
|