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 est un système d'exploitation déjà installé et configuré, enregistré sous une forme réutilisable (AMI Amazon, image Docker, fichier QCOW2 pour KVM, template Proxmox) à partir de laquelle on instancie des machines identiques. Packer produit ces images à partir d'un fichier de configuration en HCL, sans installation manuelle ni clic dans une interface.

L'apport de Packer est la reproductibilité : le contenu de l'image est décrit dans un fichier versionné, et non dans les souvenirs de la personne qui l'a construite. Deux exécutions du même modèle produisent la même image, sur le poste d'un développeur comme dans une chaîne d'intégration.

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

Construire l'image une seule fois, en amont du déploiement, déplace le travail de configuration hors du démarrage des machines. Chaque serveur démarre alors dans un état déjà validé, ce qui apporte cinq gains mesurables au quotidien.

• 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.

Packer vs Ansible, Chef et Dockerfile : quelles différences ?

Packer se compare souvent à deux familles d'outils que les débutants confondent avec lui : les gestionnaires de configuration (Ansible, Chef, Puppet) et le Dockerfile. La distinction tient au moment où l'outil agit. Packer configure la machine avant le déploiement et fige le résultat dans une image ; les gestionnaires de configuration agissent pendant ou après le déploiement, sur une machine déjà démarrée. Le Dockerfile, lui, ne produit que des images de conteneur, là où Packer cible aussi les VMs et le cloud.

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

Quatre erreurs reviennent chez presque tous les débutants sur Packer. Elles ne cassent pas toujours le build de façon évidente, et certaines coûtent surtout du temps ou exposent un secret. Les connaître avant le premier packer build évite de les découvrir en production.

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 des images reproductibles 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) alors que Dockerfile ne produit que des images Docker. Packer utilise HCL2 et des provisioners variés (shell, Ansible) pour créer des formats natifs (AMI, VMDK). Dockerfile est plus simple mais mono-cible.

Comment installer Packer sur Linux, macOS ou Windows ?

Packer est un binaire unique sans dépendances. Sur Linux, utilisez asdf ou téléchargez depuis releases.hashicorp.com. Sur macOS, Homebrew (brew install packer) ; sur Windows, Chocolatey (choco install packer). Vérifiez l'installation 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 (plugins), source (builder Docker ou AWS), build (provisioners et post-processors), variable et locals. 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, packer fmt -check pour le formatage, puis packer validate pour la syntaxe et la cohérence. En CI/CD, chaînez les trois avec && pour échouer au premier problème. L'option -var passe les variables requises.

Quels sont les principaux builders Packer ?

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

Comment utiliser les variables dans Packer ?

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

Qu'est-ce qu'un provisioner Packer ?

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

Comment débugger un build Packer qui échoue ?

Activez les logs avec PACKER_LOG=1 packer build. Utilisez -debug pour le mode interactif (pause par étape) et -on-error=ask pour choisir en cas d'erreur (abort, retry, cleanup). Le problème vient souvent du script shell ou de la connexion SSH du provisioner.

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

Un post-processor agit sur l'image après le build : compression (compress), métadonnées (manifest), checksum, import Docker (docker-import), tag (docker-tag), push vers un registry (docker-push). Ils se chaînent dans un bloc post-processors pour des workflows complexes.

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

En CI/CD : installez Packer ou l'image hashicorp/packer, puis enchaînez packer init, fmt -check, validate et build. Cachez ~/.packer.d/plugins/ et passez les secrets via PKR_VAR_*. GitHub Actions : hashicorp/setup-packer ; GitLab CI : image Docker officielle.

Comment créer une AMI AWS avec Packer ?

Utilisez le builder amazon-ebs avec source_ami_filter (AMI de base), instance_type et ami_name. Authentifiez via AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY ou un profil AWS. Ajoutez des provisioners pour configurer l'image avant son snapshot.

Comment structurer un projet Packer avec plusieurs templates ?

Organisez par type : common.pkr.hcl (plugins), variables.pkr.hcl, locals.pkr.hcl, docker.pkr.hcl ou aws.pkr.hcl (sources), build.pkr.hcl. Ajoutez un Makefile (cibles validate, build, clean) et séparez les .pkrvars.hcl par environnement (dev, prod).

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

Déclarez les variables avec sensitive = true pour les masquer dans les logs. Passez les valeurs via PKR_VAR_* plutôt que par CLI. En CI/CD, utilisez les secrets natifs (GitHub, GitLab). Ne commitez jamais un .pkrvars.hcl de secrets ; Vault pour l'entreprise.

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éclarez plusieurs sources dans le bloc build. Limitez le parallélisme avec -parallel-builds=N en ligne de commande. Chaque builder produit son artefact indépendamment.

Quelle est la différence entre Packer et Terraform ?

Packer et Terraform sont complémentaires chez HashiCorp. Packer construit des images machine (AMI, image Docker, QCOW2) avant le déploiement. Terraform provisionne et gère l'infrastructure (VM, réseau, stockage) à partir de ces images. Packer fabrique, Terraform déploie.

Packer est-il gratuit ?

Oui, Packer est gratuit et son code est ouvert, distribué sous licence BUSL-1.1 par HashiCorp depuis août 2023. L'usage reste libre pour la quasi-totalité des cas, y compris en entreprise et en CI/CD. Seule une offre concurrente directe des produits HashiCorp est restreinte.

Quelle est la différence entre Packer et Vagrant ?

Packer crée des images machine réutilisables pour la production et le cloud (AMI, Docker, Proxmox). Vagrant orchestre des VMs de développement local à partir de box. Packer peut d'ailleurs générer les box que Vagrant consomme via son post-processor vagrant.

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 →