Introduction

Dans mon homelab, j’ai récemment travaillé sur un projet qui m’a permis de créer des templates de machines virtuelles (VM) sur Proxmox en utilisant une combinaison d’outils tels que Packer, Cloud-Init et Terraform. L’objectif était de pouvoir créer des VMs de manière automatisée et répétable, tout en minimisant les interventions manuelles.

Contexte

Gérer les VMs et leurs configurations manuellement peut vite devenir une tâche fastidieuse, surtout lorsqu’il s’agit de déployer plusieurs instances avec des configurations quasiment identiques à chaque fois. J’avais donc besoin d’une solution pour standardiser tout ce processus et ainsi avoir un template de VM prêt à l’emploi afin de l’utiliser comme base dans toutes mes VMs.

Je vais expliquer dans la suite de cet article comment j’ai atteint mon objectif grâce à différents outils dans le but d’optimiser les déploiements sur mon homelab.

Composants

• Proxmox : Fournit l’infrastructure pour exécuter et gérer des machines virtuelles.
• Packer : Automatise l’installation et la configuration de l’OS pour produire une image ou un template standardisé.
• Terraform : Permet de définir, provisionner et gérer des infrastructures via du code déclaratif.
• Cloud-Init : Permet la configuration dynamique des machines au premier démarrage.

Packer

Packer est un outil communautaire permettant de créer des images de machines identiques pour plusieurs plateformes à partir d’une configuration source unique. Pour se faire Packer va utiliser ce qui s’appelle des builders qui sont des composants de Packer capables de créer un template/ une image de machine virtuelle sur une plateforme spécifique.

Dans mon cas, je vais simplement utiliser Packer sur mon environnement Proxmox grâce à son builder dédié.

1
2
3
4
5
6
7
8
9

#packer.pkr.hcl
packer {
  required_plugins {
    name = {
      version = "1.2.2"
      source  = "github.com/hashicorp/Proxmox"
    }
  }
}

Configuration du template

Ce builder permet de soit cloner une machine virtuelle pour en faire une template (Proxmox-clone) ou bien de créer un template de machine virtuelle depuis un ISO source (Proxmox-iso). Afin de répondre à mon besoin initial, je vais utiliser le builder Proxmox-iso. Pour ce qui est de la configuration, j’ai utilisé la documentation du builder.

Exemple de fichier packer.pkr.hcl :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

#packer.pkr.hcl
source "Proxmox-iso" "debian12" {
    # Proxmox server
    Proxmox_url              = "proxmox_api_url"
    node                     = "pve"
    username                 = "<Proxmox_token_id>"
    token                    = "<Proxmox_token>"
    insecure_skip_tls_verify = true

    # VM Info
    template_name        = "pckr-debian-12"
    vm_name              = "pckr-debian-12"
    template_description = "Debian 12.9.0, generated on ${timestamp()}"
    tags                 = "template;debian12"
    vm_id                = 1101
    pool                 = "TEMPLATE"
    os                   = "l26"
    machine              = "q35"

    # Boot
    boot_iso {
        type         = "scsi"
        iso_file     = "local:iso/debian-12.9.0-amd64-netinst.iso"
        unmount      = true
        iso_checksum = "none"
    }
    boot_command   = ["<esc><wait>auto console-keymaps-at/keymap=fr console-setup/ask_detect=false debconf/frontend=noninteractive fb=false url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg<enter>"]
    boot_wait  	   = "10s"
    http_directory = "http"

    # Disks
    disks {
        type         = "scsi"
        storage_pool = "local-lvm"
        disk_size    = "30G"
        format       = "raw"
    }

    # Networks
    network_adapters {
        bridge = "vmbr0"
        model  = "virtio"
    }

    # Spec
    bios               = "seabios"
    qemu_agent         = true
    scsi_controller    = "virtio-scsi-pci"
    cpu_type           = "x86-64-v2-AES"
    sockets            = 1
    cores              = 1
    memory             = 1024
    ballooning_minimum = 1024

    # Communication
    communicator           = "ssh"
    ssh_handshake_attempts = 5
    ssh_pty                = true
    ssh_timeout            = "10m"
    ssh_username           = <username>
    ssh_password           = <password>

    # Cloud-init
    cloud_init              = "true"
    cloud_init_storage_pool = "local-lvm"
}

Dans ce fichier packer.pkr.hcl, je donne au builder les informations à propos de la machine cible ainsi que les spécifications de celle-ci pour Proxmox, mais également les informations à propos du boot (chemin du fichier ISO, commande lors du boot, etc).

Fichier preseed

La partie boot va permettre de donner à la machine virtuelle, futur template, le chemin du fichier preseed.cfg auto-hébergé sur un serveur web lancé par Packer lors du processus. Ce fichier permet de répondre aux questions posées au cours du processus d’installation de l’OS, sans avoir à saisir manuellement les réponses pendant que l’installation, cela permet d’automatiser entièrement l’installation. Un exemple de ce fichier est disponible sur la documentation debian.

Création du template

Une fois la configuration prête, il faut lancer la construction du template via la CLI de Packer avec les commandes ci-dessous :

1
2
3
4
5
6
7
8

# Initialisation du dépôt pour récupérer les dépendances
packer init packer.pkr.hcl

# Validation de la syntaxe et configuration
packer validate packer.pkr.hcl

# Construiction de l'image, en remplaçant le template si déjà existant
packer build -on-error=ask -force packer.pkr.hcl

Le template est désormais bien présent dans Proxmox avec toutes les caractéristiques que j’ai indiquées dans le fichier packer.pkr.hcl et il est désormais prêt à être utilisé pour de futurs déploiements de machine virtuelle.

Maintenant passons à l’étape suivante : la configuration dynamique avec Cloud-Init !

Cloud-init

Cloud-Init est un outil open-source permettant d’automatiser la configuration initiale des machines virtuelles lors de leur premier démarrage. En utilisant des fichiers de configuration (user-data et meta-data), Cloud-Init peut effectuer diverses tâches comme la création d’utilisateurs, l’injection de clés SSH, la configuration réseau ou encore l’installation de paquets. Cet outil est compatible avec de nombreuses plateformes cloud et environnements de virtualisation, offrant ainsi une méthode agnostique pour personnaliser dynamiquement les instances sans intervention manuelle.

Exemple de fichier user-data :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#user-data.yml
#cloud-config
ssh_pwauth: false
disable_root: true
users:
  - name: user
    gecos: user
    groups: users, sudo
    shell: /bin/bash
    ssh_authorized_keys:
        - ssh-ed25519 AAAA.......
    sudo: ALL=(ALL) NOPASSWD:ALL
    lock_passwd: true
package_update: true
package_upgrade: true

Dans mon cas, j’ai choisi d’utiliser cloud-init pour me permettre de :

• Désactiver l’authentification par mot de passe via SSH et également le compte root.
• Créer un utilisateur avec une clé SSH autorisé, un accès sudo sans mot de passe et un mot de passe verrouillé.
• Effectuer automatiquement les mises à jour et les montées de version des paquets.

Une fois appliqué au premier démarrage de la machine, celle-ci est prête à l’emploi, et aussi prête à recevoir du provisionnement via un outil comme Ansible. C’était l’objectif recherché de mon côté, car je souhaitais pouvoir lancer mes playbooks Ansible via une connexion par clé SSH une fois la machine virtuelle déployée sans avoir à copier manuellement ma clé ou bien devoir me connecter une première fois via un mot de passe.

Terraform

Afin de pouvoir déployer ma machine virtuelle grâce à mon template et au fichier cloud-init, j’ai fait le choix d’utiliser terraform. Terraform est un outil d’infrastucture as code, c’est-à-dire un outil qui permet de définir son infrastructure via des fichiers de configuration déclaratifs au format HCL (Hashicorp Configuration Language). Pour réaliser ceci, Terraform se repose sur des providers qui vont permettre la communication avec l’infrastructure sous-jacente. Cette méthode permet de gérer l’infrastructure comme du code, ce qui simplifie la gestion des versions et la reproductibilité des déploiements.

Ces plugins mettent à disposition des types de ressources (créer/modifier des ressources) et des sources de données (lecture d’informations existantes) qui permettent à Terraform de manager l’infrastructure derrière ce plugin. Les providers passent par le SDK ou bien l’API du fournisseur afin de réaliser toutes les actions indiquées par la configuration Terraform.

Dans le cas de mon homelab, j’ai fait le choix d’utiliser le provider bpg, qui est un provider réalisé par un membre de la communauté et qui permet de gérer tout son environnement Proxmox (resource pool, users, VM, ISO).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#providers.tf
provider "proxmox" {
  endpoint  = var.endpoint
  api_token = var.api_token
  insecure  = true
  ssh {
    agent       = false
    username    = "root"
    private_key = var.private_key
  }
}

Pour le déploiement de la machine virtuelle en utilisant le template et cloud-init pour le provisionnement, j’ai utilisé la ressource proxmox_virtual_environment_vm, qui permet de créer/gérer une machine virtuelle en lui passant toutes les caractéristiques nécessaires.

Exemple de ressource terraform pour une machine virtuelle dans Proxmox :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

#virtual_machine.tf
resource "proxmox_virtual_environment_vm" "example_vm" {
    name                = "example"
    description         = "example VM"
    tags                = ["debian12", "terraform"]
    node_name           = "pve"
    vm_id               = 101
    pool_id             = "example"
    reboot_after_update = false
  
    agent {
      enabled = true
    }
  
    cpu {
      cores   = 2
      sockets = 1
      type    = "x86-64-v2-AES"
    }
  
    memory {
      dedicated = 4096
      floating  = 4096
    }

  initialization {
    user_data_file_id = proxmox_virtual_environment_file.user_data_cloud_config.id
    dns {
      servers = ["9.9.9.9", "1.1.1.1"]
    }
    ip_config {
      ipv4 {
        address = "192.168.1.101/24"
        gateway = "192.168.1.1"
      }
    }
  }

  clone {
    vm_id        = 1101
    datastore_id = "local-lvm"
    full         = true
    node_name    = "pve"
  }
}

Mais dans mon cas les paramètres qui m’intéressent sont :

• initialization : Configuration pour cloud-init où je spécifie la configuration DNS, l’adresse IP de ma machine et je donne l’ID de mon fichier cloud-init également managé via terraform via la ressource proxmox_virtual_environment_file

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

initialization {
  user_data_file_id = proxmox_virtual_environment_file.user_data_cloud_config.id
  dns {
    servers = ["9.9.9.9", "1.1.1.1"]
  }
  ip_config {
    ipv4 {
      address = "192.168.1.101/24"
      gateway = "192.168.1.1"
    }
  }
}

• clone : Configuration du clonage où je donne les informations à propos de mon template présent dans Promox.

1
2
3
4
5
6

clone {
  vm_id        = 1101
  datastore_id = "local-lvm"
  full         = true
  node_name    = "pve"
}

Je peux déclencher mon projet qui contient mon Infrastructure as Code, en y ajoutant la nouvelle ressource. Et terraform va s’occuper de cloner le template et de lui fournir la configuration cloud-init afin de provisionner la machine virtuelle.

J’ai donc comme résultat une VM avec une configuration standard que j’ai défini pour correspondre à mon besoin et qui est prête à recevoir du provisionnement avec un outil comme Ansible.

Diagramme de séquence

Conclusion

En conclusion, la mise en place d’un processus automatisé pour la création et le déploiement de machines virtuelles sur Proxmox via Packer, Cloud-Init et Terraform m’a permis de gagner en efficacité, en reproductibilité et en flexibilité dans mon homelab.

Ce workflow garantit une standardisation des environnements, réduit le risque d’erreurs manuelles et facilite le provisionnement des machines avec Ansible ou d’autres outils d’automatisation. Grâce à cette solution, je peux désormais déployer rapidement des machines virtuelles prêtes à l’emploi, tout en adaptant leur configuration selon mes besoins.