Terraform + Proxmox
Déploiement de VMs sur proxmox avec terraform à partir d'un template CloudInit
Last updated
Was this helpful?
Déploiement de VMs sur proxmox avec terraform à partir d'un template CloudInit
Last updated
Was this helpful?
Cette doc permet le déploiement automatisé de machines virtuelles (VM) sur un cluster Proxmox VE à l’aide de Terraform et du provider . Bonus :
Un serveur Proxmox VE en version 8.x
Une machine Linux avec Terraform (>= 1.5) ou OpenTofu (>= 1.6) installé
Un utilisateur dédié sur Proxmox avec un API Token configuré
Un templaye de vm
Les accès SSH configurés si nécessaire pour la provision des VM
Docs officielle :
Ce rôle regroupe toutes les permissions recommandées pour piloter des VM, disques, réseaux, cloud-init, migration, etc.
Remplacer <votre_mot_de_passe>
par un mot de passe fort.
Le /
cible l’ensemble du cluster, ajustez si besoin pour limiter à un nœud ou un pool spécifique.
Créer un token API pour l’utilisateur
-expire 0
: pas d’expiration automatique
-privsep 0
: désactive la séparation de privilèges, nécessaire pour Terraform
Notez immédiatement le secret du token affiché : il ne sera plus visible ensuite.
Créer un token API pour l’utilisateur (ici nommé terraform
) et accorder les roles necessaire au token :
Notez bien le token secret affiché : il ne sera plus visible ensuite.
Ajouter ces variables à votre shell avant d’utiliser Terraform :
A faire apres chaque fermerture de la session
ID : 9000
nom de la VM : debian-cloudinit
RAM : 2Go
Interface réseau : vmbr1
Utiliser une ISO minimale, par exemple via netinst
, ou directement une image cloud-init-ready comme :
Où local représente le nom du Datastore. Ensuite, attacher le disque au contrôleur :
On pourra directement l’utiliser comme vm_id = 9000
dans ta config clone
.
Cette clé ssh sera déployée sur les vms qu'on créera
Cela génèrera deux fichiers :
id_rsa
→ Clé privée (à garder secrète).
id_rsa.pub
→ Clé publique (à injecter dans les VMs).
Place la clé publique dans le dossier Terraform :
Le fichier id_rsa.pub
doit se trouver dans le dossier contenant ton projet Terraform.
Ce fichier initialise le projet Terraform et définit le provider principal utilisé : bpg/proxmox (version 0.66.2). Cette configuration est nécessaire pour permettre à Terraform d’interagir avec l’API Proxmox.
Ce fichier permet à terrafom de récupérer une clé publique en data source et de lire le contenu du fichier id_rsa.pub
et de l’utiliser dans la configuration via data.local_file.ssh_public_key.content
C’est la méthode recommandée pour importer une clé publique locale dans Terraform
local_file
est un data source qui lit le contenu d’un fichier local.
trimspace(...)
est utilisé ensuite dans le vm.tf
pour s'assurer qu'aucun saut de ligne inutile ne soit injecté dans le cloud-init.
Vous pouvez remplacer ${path.module} par le chemin où se trouve la clé. Moi je l'ai dans le répertoire de mon projet. donc mon data.tf devient :
Ce fichier définit l’ensemble des variables d’entrée utilisées dans le projet Terraform pour la création de machines virtuelles sur Proxmox. Modifiez ces variables selon votre environnement et vos besoins.
Le bloc suivant :
définit une variable appelée vm_names
, qui est une liste de chaînes de caractères (donc un tableau de noms). Chaque élément de cette liste représente le nom d'une VM à créer avec Terraform.
Par exemple :
Cela permet de créer une VM pour chaque nom fourni dans la liste, avec des paramètres propres (nom, IP, ID, etc.).
⚠️ Important : cette liste reflète l’état réel des VMs gérées par Terraform. Si on supprime un nom de la liste, Terraform considérera que la VM correspondante doit être détruite. Donc, pour ajouter de nouvelles VMs sans toucher aux existantes, il faut ajouter les nouveaux noms à la liste sans retirer les anciens
Ce fichier définit les sorties (outputs) de Terraform pour ce projet. Ici, on expose les adresses IPv4 de toutes les VMs créées, ce qui permet de les retrouver facilement après un apply.
Ce fichier définit la ressource principale de machine virtuelle (VM) à déployer sur Proxmox via Terraform. Il s’appuie sur les variables du projet et la clé publique SSH importée en data source.
Dans Terraform, le mot de passe fourni à user_account
doit être hashé .
Génération du mot de passe chiffré
Exemple de résultat
Le mot de passe haché est à utiliser dans :
Le fichier vm.tf devrait ressembler à ca
Pourquoi for_each
?
Contrairement à count
, for_each
permet de :
Nommer chaque ressource individuellement (via une clé explicite),
Ajouter/retirer des ressources sans destruction des autres,
Gérer une configuration plus flexible.
Ce que ça fait :
Crée une VM nommée vm1
, une autre vm2
, etc.
Chaque VM est traitée indépendamment.
vm_id
et adresses IP→ Cela génère :
vm1
→ 900
vm2
→ 901
vm3
→ 902
→ IPs attribuées :
bastion
→ 10.10.10.50
kube-master
→ 10.10.10.51
kube-worker
→ 10.10.10.52
lifecycle.ignore_changes
Pouvoir modifier manuellement ces paramètres (RAM, CPU, IP, etc.) via l’interface Proxmox sans que Terraform essaie de les remettre à leur état initial à chaque apply
.
Le champ prevent_destroy
dans Terraform est une protection qui empêche la suppression accidentelle d'une ressource, même si elle n’existe plus dans le code ou si tu fais un terraform destroy
.
terraform init
→ Prépare l’environnement
terraform fmt
→ Formate le code
terraform validate
→ Vérifie la validité de la configuration
terraform plan
→ Prévisualise les changements
terraform apply
→ Applique les changements sur l’infrastructure
Pour ajouter de nouvelles VMs à défaut de modifier le fichier variables.tf :
proxmox-bpg-terraform/ ├── README.md ├── main.tf ├── data.tf ├── variables.tf ├── outputs.tf ├── vm.tf Tout ça est disponible sur mon
Ce format est essentiel car il permet d'utiliser for_each
dans le fichier , ce qui offre un meilleur contrôle sur chaque ressource individuellement (contrairement à count
, qui fonctionne avec des index numériques sans lien direct avec le nom).
Avec keys = [trimspace(data.local_file.ssh_public_key.content)]
qui représente la clé public récupéré en data source dans et username
le nom d'utilisateur des vms qui seront déployés
Une fois les Vms créées on peut leur appliquer des configs spécifiques avec ansible.