Packer : concepts et architecture

Version actuelle

Ce guide utilise Packer v1.15.0 (février 2026). Principales nouveautés récentes : HCP Packer registry channels (v1.15), plugins depuis releases.hashicorp.com (v1.14), évaluation DAG des locals/datasources (v1.12), fonctions alltrue/anytrue/strcontains (v1.12).

Ce guide vous explique les concepts fondamentaux de Packer pour que vous puissiez créer vos premières images machine reproductibles. Vous comprendrez comment Packer automatise la création d'images identiques pour le cloud, les VMs locales ou les conteneurs, le tout à partir d'un simple fichier de configuration.

Ce que vous allez apprendre

• Ce qu'est Packer et pourquoi l'utiliser
• Les trois composants clés : builders, provisioners, post-processors
• Le workflow complet : init → validate → build
• Quand choisir Packer plutôt qu'une autre approche

Prérequis : aucun. Ce guide est une introduction aux concepts.

Qu'est-ce que Packer ?

Packer est un outil open source créé par HashiCorp qui automatise la création d'images machine. Une image machine, c'est une "photo" d'un système d'exploitation configuré et prêt à l'emploi, pensez-y comme un moule pour créer des VMs ou des conteneurs identiques.

Pour faire une analogie simple : si votre infrastructure était une cuisine, Packer serait la recette écrite qui permet de reproduire exactement le même plat à chaque fois, peu importe qui cuisine et dans quelle cuisine.

Aspect	Sans Packer	Avec Packer
Création d'image	Installation manuelle, clics dans l'interface	Une commande : packer build
Reproductibilité	"Ça marchait la dernière fois..."	Image identique à chaque build
Documentation	Notes personnelles, wiki obsolète	Le template HCL EST la documentation
Multi-plateforme	Refaire le travail pour chaque cible	Un template, plusieurs images
Versioning	Difficile à tracer	Template versionné avec Git

Glissez pour voir

Pourquoi utiliser Packer ?

Imaginez que vous devez déployer une application sur 50 serveurs. Sans Packer, vous avez deux options :

1. Configurer chaque serveur manuellement, long, source d'erreurs, impossible à reproduire
2. Utiliser un outil de configuration à chaque démarrage, lent, dépendant du réseau

Avec Packer, vous créez une seule fois une image "golden" qui contient tout : système d'exploitation, dépendances, configuration de sécurité. Ensuite, vous déployez cette image sur vos 50 serveurs en quelques minutes.

Golden Image

Une golden image (ou "image dorée") est une image de référence pré-configurée et validée. Elle sert de base pour tous les déploiements, garantissant que chaque machine démarre dans un état connu et sécurisé.

Les bénéfices concrets

• Déploiement rapide : une VM prête en secondes au lieu de minutes de configuration
• Cohérence : tous les serveurs sont identiques, pas de "configuration drift"
• Sécurité : les correctifs sont intégrés dans l'image, pas appliqués après coup
• Audit : le template décrit exactement ce qui est installé
• Multi-cloud : une même configuration pour AWS, Azure, GCP, on-premise

Architecture de Packer

Packer fonctionne avec trois types de composants qui s'exécutent dans un ordre précis. Comprendre cette architecture est essentiel pour écrire des templates efficaces.

Les Builders : créer la machine de base

Le builder est responsable de créer une machine temporaire et de produire une image à partir de celle-ci. Chaque builder est spécifique à une plateforme :

Builder	Plateforme	Usage typique
amazon-ebs	AWS	AMI pour EC2
azure-arm	Azure	Images managées
googlecompute	GCP	Images Compute Engine
qemu	KVM/libvirt	Images locales Linux
proxmox-iso	Proxmox	Templates VM
docker	Docker	Images conteneur
virtualbox-iso	VirtualBox	Images de dev

Glissez pour voir

Packer supporte plus de 52 builders via son système de plugins. Les builders officiels maintenu par HashiCorp sont téléchargés depuis releases.hashicorp.com.

Un template, plusieurs builders

Un même template peut utiliser plusieurs builders pour générer des images sur différentes plateformes en parallèle. Par exemple, créer simultanément une AMI AWS et une image Docker à partir de la même configuration.

Les Provisioners : configurer l'image

Les provisioners s'exécutent après que le builder a créé la machine temporaire. Ils configurent le système : installer des paquets, copier des fichiers, exécuter des scripts.

Provisioner	Description	Cas d'usage
shell	Exécute des commandes shell	Scripts bash simples
ansible	Exécute des playbooks Ansible	Configuration complexe
file	Copie des fichiers vers l'image	Fichiers de config
powershell	Scripts PowerShell	Images Windows
chef / puppet	Outils de configuration	Écosystèmes existants

Glissez pour voir

L'ordre des provisioners dans le template détermine leur ordre d'exécution. Packer les exécute séquentiellement.

Les Post-Processors : finaliser l'artefact

Les post-processors s'exécutent après la création de l'image pour effectuer des actions supplémentaires :

Post-Processor	Action
manifest	Génère un fichier JSON avec les métadonnées du build
compress	Compresse l'image en archive
docker-push	Pousse l'image vers Docker Hub ou un registry
checksum	Calcule les checksums (sha256, md5)
vagrant	Convertit en box Vagrant

Glissez pour voir

Le workflow Packer

Packer suit un workflow en trois étapes que vous utiliserez systématiquement :

1. packer init, Télécharge les plugins requis

   Cette commande lit le bloc required_plugins de votre template et télécharge les plugins nécessaires. À exécuter une seule fois par projet (ou quand vous ajoutez un nouveau plugin).

   packer init mon-template.pkr.hcl

2. packer validate, Vérifie la syntaxe du template

   Valide que le template HCL est syntaxiquement correct et que toutes les références sont valides. Cette commande ne crée rien, elle vérifie simplement.

   packer validate mon-template.pkr.hcl

3. packer build, Construit l'image

   Exécute le builder, les provisioners et les post-processors pour créer l'image finale.

   packer build mon-template.pkr.hcl

Ce qui se passe pendant un build

Quand vous lancez packer build, voici ce qui se passe en coulisses :

1. Création : le builder démarre une machine temporaire (VM, conteneur...)
2. Connexion : Packer se connecte via SSH ou WinRM
3. Provisionnement : les provisioners configurent la machine
4. Capture : le builder crée une image à partir de la machine
5. Nettoyage : la machine temporaire est détruite
6. Post-traitement : les post-processors s'exécutent sur l'image

Structure d'un template Packer

Un template Packer en HCL (HashiCorp Configuration Language) se compose de plusieurs blocs :

# 1. Bloc packer : version et plugins requis
packer {
  required_version = ">= 1.15.0"

  required_plugins {
    docker = {
      version = ">= 1.1.0"
      source  = "github.com/hashicorp/docker"
    }
  }
}

# 2. Variables : rendent le template configurable
variable "image_name" {
  type        = string
  default     = "mon-app"
  description = "Nom de l'image finale"
}

# 3. Source : définit le builder et sa configuration
source "docker" "ubuntu" {
  image  = "ubuntu:22.04"
  commit = true
}

# 4. Build : assemble sources, provisioners et post-processors
build {
  sources = ["source.docker.ubuntu"]

  provisioner "shell" {
    inline = ["apt-get update", "apt-get install -y curl"]
  }
}

HCL vs JSON

Depuis Packer v1.7.0, HCL2 est le format recommandé. L'ancien format JSON est toujours supporté mais considéré comme legacy. Si vous avez des templates JSON existants, utilisez packer hcl2_upgrade pour les convertir.

Comparaison avec d'autres approches

Packer vs Configuration Management (Ansible, Chef, Puppet)

Aspect	Packer	Ansible/Chef/Puppet
Quand	Avant le déploiement (build time)	Pendant/après le déploiement (run time)
Résultat	Image figée	Configuration dynamique
Temps de démarrage	Instantané	Dépend de la complexité
Dépendances réseau	Non	Oui (repos, registries)

Glissez pour voir

En pratique : utilisez les deux ensemble. Packer avec Ansible en provisioner pour créer des images, puis Ansible pour les mises à jour légères post-déploiement.

Packer vs Dockerfile

Aspect	Packer	Dockerfile
Scope	VMs + conteneurs	Conteneurs uniquement
Multi-plateforme	Oui (AWS, Azure, QEMU...)	Non
Provisioners	Shell, Ansible, Chef...	Shell uniquement
Écosystème	Intégration Terraform/Vault	Écosystème Docker

Glissez pour voir

En pratique : pour des conteneurs simples, Dockerfile suffit. Pour des VMs ou des images multi-plateformes, utilisez Packer.

Cas d'usage typiques

Golden Images pour le cloud

Créez une AMI AWS pré-configurée avec vos outils de monitoring, agents de sécurité et configurations réseau. Chaque nouvelle instance démarre avec tout ce qu'il faut.

Templates pour homelab

Automatisez la création de templates Proxmox ou VMware pour votre infrastructure personnelle. Un seul template pour créer des VMs identiques.

Images Docker standardisées

Créez des images de base avec vos standards d'entreprise : outils de debug, certificats, configuration réseau.

Environnements de développement

Produisez des boxes Vagrant cohérentes pour que tous les développeurs travaillent dans le même environnement.

En pratique : apprendre Packer sans cloud

Pour prendre Packer en main sans compte cloud ni facture, je démarre mes labs avec le builder Docker (ou le null builder) plutôt qu'avec AWS ou Proxmox : un packer build tourne en local en quelques secondes, et on valide tout le workflow (init, validate, provisioners, post-processors) à coût zéro. Une fois les réflexes acquis, on bascule sur un builder cloud. C'est l'ordre que je recommande pour ne pas mélanger l'apprentissage de l'outil et les galères d'identifiants cloud.

Pièges courants

Erreurs fréquentes

1. Oublier packer init, Les plugins ne sont pas installés automatiquement. Sans init, le build échoue.

2. Ne pas valider avant de builder, packer validate détecte les erreurs de syntaxe en secondes. Un build raté peut prendre des minutes.

3. Hardcoder les secrets, Ne mettez jamais de mots de passe dans le template. Utilisez des variables d'environnement ou Vault.

4. Ignorer les logs, Packer affiche des informations précieuses. En cas d'erreur, lisez les logs avant de chercher sur internet.

À retenir

• Packer automatise la création d'images machine reproductibles (VMs, conteneurs)
• Builders créent la machine temporaire (AWS, Docker, QEMU, Proxmox...)
• Provisioners configurent l'image (Shell, Ansible, File...)
• Post-processors finalisent l'artefact (compress, push, manifest...)
• Workflow : packer init → packer validate → packer build
• HCL2 est le format de template recommandé depuis v1.7.0
• Golden images = images de référence pré-configurées et validées

FAQ : questions fréquentes

Qu'est-ce que Packer et à quoi sert-il ?

Packer est un outil open source HashiCorp qui crée des images machine identiques pour plusieurs plateformes (Docker, AWS AMI, Azure, GCP, Proxmox) à partir d'une configuration unique. Il automatise la création d'images reproductibles et élimine la dérive de configuration. Utilisé pour les golden images et l'immutable infrastructure.

Quelle est la différence entre Packer et un Dockerfile ?

Packer est multi-plateforme (Docker, AWS, Azure, GCP) tandis que Dockerfile ne produit que des images Docker. Packer utilise HCL2, supporte des provisioners variés (shell, Ansible, Chef) et crée des formats natifs (AMI, VMDK). Dockerfile est plus simple pour Docker seul mais ne répond pas au besoin multi-cloud d'immutable infrastructure.

Comment installer Packer sur Linux, macOS ou Windows ?

Packer est un binaire unique sans dépendances. Sur Linux, utilisez asdf (asdf plugin add packer && asdf install packer latest) ou téléchargez depuis releases.hashicorp.com. Sur macOS, utilisez Homebrew (brew install packer). Sur Windows, utilisez Chocolatey (choco install packer). Vérifiez avec packer --version.

Qu'est-ce qu'un template HCL2 Packer ?

Un template HCL2 est un fichier .pkr.hcl qui définit comment créer une image. Il contient des blocs : packer (configuration et plugins), source (définition du builder comme Docker ou AWS), build (orchestration des sources, provisioners et post-processors), variable et locals (paramètres). HCL2 remplace le format JSON depuis Packer 1.5.

Comment valider un template Packer avant le build ?

Utilisez packer init . pour télécharger les plugins, puis packer fmt -check . pour vérifier le formatage, et packer validate . pour valider la syntaxe et la cohérence. En CI/CD, combinez les trois commandes avec && pour échouer au premier problème. Option -var pour passer des variables requises lors de la validation.

Quels sont les principaux builders Packer ?

Packer supporte de nombreux builders : Docker (conteneurs), Amazon EBS (AMI AWS), Azure ARM (images Azure), Google Compute (images GCP), QEMU (images QCOW2 pour KVM/Proxmox), VMware ISO (machines virtuelles VMware), VirtualBox ISO (machines virtuelles VirtualBox), LXC/LXD (conteneurs Linux), Null (test de provisioners sans créer d'image).

Comment utiliser les variables dans Packer ?

Déclarez avec variable "nom" { default = "valeur" }, utilisez avec var.nom. Types supportés : string (défaut), number, bool, list, map, object. Passez des valeurs via CLI (-var "nom=val"), fichier .pkrvars.hcl (-var-file), ou variables d'environnement (PKR_VAR_nom). Les locals sont des valeurs calculées avec local { nom = expression }.

Qu'est-ce qu'un provisioner Packer ?

Un provisioner configure l'image après sa création : installation de paquets, copie de fichiers, exécution de scripts. Types principaux : shell (commandes bash), file (copie de fichiers), ansible (playbooks Ansible), shell-local (commandes sur l'hôte). Les provisioners s'exécutent dans l'ordre de déclaration dans le bloc build.

Comment débugger un build Packer qui échoue ?

Activez les logs détaillés avec PACKER_LOG=1 packer build . pour voir toutes les opérations. Utilisez -debug pour le mode interactif (pause entre chaque étape). Ajoutez -on-error=ask pour choisir quoi faire en cas d'erreur (abort, retry, cleanup). Vérifiez les logs du provisioner, souvent le problème est dans le script shell ou la connexion SSH.

Qu'est-ce qu'un post-processor Packer ?

Un post-processor agit sur l'image après le build : compression (compress), génération de métadonnées (manifest), calcul de checksum, import dans Docker (docker-import), tagging (docker-tag), push vers registry (docker-push). Ils peuvent être chaînés avec la syntaxe post-processors { post-processor {} post-processor {} } pour des workflows complexes.

Comment intégrer Packer dans un pipeline CI/CD ?

En CI/CD : installez Packer (ou utilisez l'image hashicorp/packer), exécutez packer init, packer fmt -check, packer validate, puis packer build. Cachez le répertoire ~/.packer.d/plugins/. Passez les secrets via variables d'environnement (PKR_VAR_*). Pour GitHub Actions, utilisez hashicorp/setup-packer. Pour GitLab CI, utilisez l'image Docker officielle.

Comment créer une AMI AWS avec Packer ?

Utilisez le builder amazon-ebs avec source_ami_filter pour trouver l'AMI de base, instance_type pour le type d'instance de build, et ami_name pour le nom de sortie. Authentifiez via variables d'environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY ou profil AWS. Ajoutez des provisioners pour configurer l'image avant qu'elle ne soit snapshotée.

Comment structurer un projet Packer avec plusieurs templates ?

Organisez par type : common.pkr.hcl (plugins et variables partagées), variables.pkr.hcl (déclarations de variables), locals.pkr.hcl (valeurs calculées), docker.pkr.hcl ou aws.pkr.hcl (sources par builder), build.pkr.hcl (blocs build). Utilisez un Makefile avec cibles validate, build, clean. Séparez les fichiers .pkrvars.hcl par environnement (dev, prod).

Comment gérer les secrets dans Packer sans les exposer ?

Utilisez des variables sensibles avec sensitive = true pour masquer dans les logs. Passez les valeurs via variables d'environnement (PKR_VAR_secret) plutôt que CLI ou fichiers. En CI/CD, utilisez les secrets natifs (GitHub Secrets, GitLab CI Variables). Ne commitez jamais de fichiers .pkrvars.hcl contenant des secrets. Utilisez Vault pour les environnements enterprise.

Packer peut-il créer plusieurs images en parallèle ?

Oui, Packer exécute les builds de plusieurs sources en parallèle par défaut. Définissez plusieurs sources dans le bloc build : sources = ["source.docker.app", "source.amazon-ebs.app"]. Limitez le parallélisme avec -parallel-builds=N sur la ligne de commande. Chaque builder produit son artefact indépendamment.

Prochaines étapes

Installation de Packer Installez Packer et créez votre première image

Templates HCL2 Maîtrisez la syntaxe des templates Packer

Variables et fonctions Paramétrez vos templates avec des variables et locals

Provisioners Configurez vos images avec Shell, Ansible et File

Post-processors Transformez vos artefacts : compression, checksums, Docker

×

📖 Voir la documentation →