centreon-terraform — VM Debian 12 minimale pour Centreon

Crée sur le nœud Proxmox pve une VM Debian 12 réduite au strict nécessaire, durcie par cloud-init, et prête à être reprise par Ansible (dépôt centreon-ansible).

Ce dépôt ne connaît rien de Centreon : il produit un serveur, rien d'autre.

Ce que le code met en place

Point	Choix retenu
Système	Debian 12 genericcloud (image officielle, ~350 Mo, sans noyau cloud-specific inutile)
Pourquoi pas Debian 13	Centreon 25.10 ne supporte que Debian 12
Comptes	un seul compte unix (`ansible`), sans mot de passe, sudo NOPASSWD, clé publique uniquement
root	connexion SSH refusée, mot de passe verrouillé
SSH	mot de passe et clavier-interactif désactivés, `AuthenticationMethods publickey`, `AllowUsers` limité au compte d'administration
Services exposés	22/tcp et ICMP uniquement, et seulement depuis `ssh_allowed_cidrs`
Pare-feu	nftables, politique `drop` en entrée et en transit, avec un répertoire `/etc/nftables.d/` qu'Ansible viendra compléter
Mises à jour	`unattended-upgrades` activé
Sysctl	redirections ICMP, source routing, dmesg et kptr restreints
Agent	`qemu-guest-agent` (remontée des IP et arrêt propre côté Proxmox)

Rien d'autre n'écoute : pas de serveur mail local, pas de rpcbind, pas d'exim — l'image genericcloud n'en embarque aucun.

Prérequis

Jeton d'API Proxmox. Le jeton terraform@pve!provisioner existant convient, à condition que son rôle porte au minimum : VM.Allocate, VM.Config.*, VM.PowerMgmt, VM.Audit, VM.Console, VM.GuestAgent.Audit, Datastore.Allocate, Datastore.AllocateSpace, Datastore.AllocateTemplate, Datastore.Audit, Sys.Audit, SDN.Use. SDN.Use est nécessaire depuis PVE 8.2 pour attacher une carte à un bridge.
Accès SSH au nœud. Le dépôt du snippet cloud-init passe par SSH : l'API Proxmox ne sait pas téléverser dans le contenu snippets. Le compte utilisé doit pouvoir écrire dans /var/lib/vz/snippets.
Contenu snippets activé sur le stockage local : pvesm set local --content images,rootdir,vztmpl,backup,iso,snippets (à vérifier une fois : pvesm status --storage local).
Réservation d'adresse. 10.0.5.20 doit être exclue de la plage DHCP d'OPNsense, sinon le bail pourra être attribué à une autre machine.

Secrets

Aucun secret n'est écrit dans les fichiers .tf ni dans terraform.tfvars :

export TF_VAR_pve_api_token='terraform@pve!provisioner=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
export TF_VAR_pve_ssh_password='...'

Si le projet rejoint la CI Gitea, ces deux valeurs se lisent dans OpenBao comme pour proxmox-create-vm, en réutilisant secret/proxmox.

Une VM par fichier

Ce dépôt gère plusieurs VM : un fichier vms/<nom>.tfvars et un espace de travail Terraform par machine, chacune avec son propre état. La version de Debian se choisit dans ce fichier. Tout est décrit dans VMS.md.

Déclenchement habituel : la CI

Le déploiement passe par Gitea Actions (.gitea/workflows/), l'état vit sur le backend S3 et les secrets dans OpenBao. Tout est décrit dans CICD.md.

Les valeurs non sensibles sont versionnées dans vms/<nom>.tfvars, un fichier par VM (voir VMS.md) — dont la clé publique d'administration, à remplacer avant le premier déploiement.

Exécution ponctuelle, sans installer Terraform

Pour un essai hors CI, avec un backend.hcl local non versionné décrivant le bucket :

export TF_VAR_pve_api_token='...' TF_VAR_pve_ssh_password='...'
export AWS_ACCESS_KEY_ID='...' AWS_SECRET_ACCESS_KEY='...'

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 init -backend-config=backend.hcl

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 apply -var-file=vms/centreon.tfvars

Sous PowerShell, remplacer "$PWD" par ${PWD} et passer les variables avec -e TF_VAR_pve_api_token=$env:TF_VAR_pve_api_token.

Attention à ne pas jouer un apply local pendant qu'un job tourne : l'état est partagé, le verrou S3 est là pour ça mais mieux vaut ne pas le provoquer.

Après l'apply

terraform apply produit :

la VM 120 démarrée, qui exécute cloud-init pendant 3 à 6 minutes (mise à jour complète du système comprise) ;
generated/inventory.yml, l'inventaire Ansible correspondant.

Vérification :

ssh [email protected] 'cloud-init status --wait && sudo nft list chain inet filter input'

La sortie attendue ne contient que lo, established,related, l'ICMP et le port 22.

Points d'attention

cloud-init ne rejoue rien. Modifier templates/user-data.yaml.tftpl après création ne change pas la VM existante : le snippet garde le même nom, donc le même identifiant, et Terraform ne voit même pas de différence. Pour repartir d'un système propre : terraform destroy puis apply.
Image Debian. overwrite = false évite de retélécharger 350 Mo à chaque apply. Debian republie régulièrement l'image latest sous le même nom : si une version plus récente est souhaitée, supprimer le fichier sur le nœud et relancer l'apply. Le paramètre debian_image_checksum est disponible mais laissé vide, une empreinte figée cassant à chaque respin de l'image.
Extension .img. Proxmox n'accepte que .iso et .img dans le contenu iso : le .qcow2 téléchargé est donc renommé, son format réel étant inchangé.
Redémarrage. Si cloud-init installe un nouveau noyau, la VM continue de tourner sur l'ancien. Un sudo reboot avant de lancer Ansible est une bonne habitude.

Suite

cp generated/inventory.yml ../centreon-ansible/inventory/hosts.yml

6.0 KiB Raw Permalink Blame History