Formation Packer : du template de base à l'automatisation complète

Présentation de cette formation

Packer est l'outil HashiCorp de référence pour créer des images machine identiques sur de multiples plateformes (Docker, AWS, Azure, GCP, Proxmox, etc.). Cette formation vous accompagne du premier template jusqu'à l'automatisation complète de vos workflows de création d'images.

Contrairement à une documentation classique, cette formation suit une progression pédagogique : chaque module s'appuie sur les précédents, avec des exemples pratiques testables immédiatement.

En bref

Avant de démarrer, voici le profil visé, les prérequis et le volume de cette formation Packer. Ce tableau vous dit en un coup d'oeil si le parcours correspond à votre niveau et au temps que vous pouvez y consacrer.


Public	Développeurs, DevOps, SRE, équipes plateforme
Prérequis	Terminal Linux, bases Docker (pour les exemples)
Durée totale	~4 heures (7 modules)
Approche	Théorie + templates `.pkr.hcl` + labs Docker

Ce que vous apprendrez

À la fin de cette formation, vous serez capable de :

Créer des images reproductibles multi-plateformes
Écrire des templates HCL2 clairs et maintenables
Paramétrer avec variables, locals et fonctions built-in
Configurer provisioners (shell, file, Ansible)
Enchaîner des post-processors (compress, manifest, Docker)
Intégrer Packer dans vos pipelines CI/CD

Vue d'ensemble de la formation

Les 7 modules suivent une progression du concept à l'industrialisation. Chaque ligne indique le niveau, la durée estimée et la capacité concrète acquise à la fin du module. Suivez-les dans l'ordre si vous débutez, ou sautez directement au module qui vous manque.

Module	Titre	Niveau	Durée	Ce que vous saurez faire
1	Concepts et cas d'usage	Débutant	30 min	« Je comprends pourquoi Packer et quand l'utiliser »
2	Installation multi-plateforme	Débutant	20 min	« Packer est installé et je peux l'exécuter »
3	Templates HCL2	Débutant	45 min	« Je sais écrire un template HCL2 de base »
4	Variables et fonctions	Intermédiaire	45 min	« Je paramètre mes builds avec variables et fonctions »
5	Provisioners	Intermédiaire	45 min	« Je configure mes images avec shell, file ou Ansible »
6	Post-processors	Intermédiaire	45 min	« J'enchaîne des actions post-build (compress, push Docker) »
7	Bonnes pratiques	Intermédiaire	40 min	« Mes templates sont maintenables et intégrés en CI/CD »

Le parcours de formation

Module 1 · Concepts

Comprendre Packer et son écosystème

Golden images, philosophie HashiCorp, comparaison avec Dockerfile, principaux builders.

Commencer les concepts →

Module 2 · Installation

Installer Packer sur votre système

Binaire officiel, asdf, gestionnaires de paquets, validation de l'installation.

Installer Packer →

Module 3 · Templates HCL2

Écrire votre premier template

Anatomie d'un template, blocs source et build, builder Docker, premier build.

Écrire des templates →

Module 4 · Variables et fonctions

Paramétrer vos builds

Variables, locals, pkrvars, fonctions built-in, expressions conditionnelles.

Utiliser les variables →

Module 5 · Provisioners

Configurer vos images

Shell, file, Ansible, provisioner de nettoyage, bonnes pratiques de configuration.

Configurer avec provisioners →

Module 6 · Post-processors

Actions post-build

Compress, manifest, checksum, docker-import, docker-tag, docker-push, chaînage.

Enchaîner des post-processors →

Module 7 · Bonnes pratiques

Industrialiser vos templates

Structure projet, Makefile, debug, sécurité des secrets, intégration CI/CD.

Appliquer les bonnes pratiques →

FAQ Packer

Questions fréquentes

Réponses aux questions courantes sur Packer, dépannage, comparaisons avec d'autres outils.

Consulter la FAQ →

Programme détaillé

Module 1, Concepts et cas d'usage

Le premier module pose les fondations. Vous comprendrez pourquoi Packer existe, ce qu'est une « golden image », et quand utiliser Packer plutôt qu'un Dockerfile ou un script shell.

Thème	Contenu
Problématique	Dérive de configuration, images non reproductibles
Golden images	Définition, avantages, immutable infrastructure
Philosophie HashiCorp	Workflow Plan → Apply, idempotence
Builders	Docker, AWS, Azure, GCP, Proxmox, QEMU
Comparaison	Packer vs Dockerfile vs scripts shell

Commencer le Module 1 Comprendre Packer et pourquoi l'utiliser

Module 2, Installation multi-plateforme

Installation de Packer sur Linux, macOS et Windows. Nous recommandons asdf pour gérer plusieurs versions côte à côte.

Méthode	Commande
asdf (recommandé)	`asdf plugin add packer && asdf install packer latest`
Binaire officiel	Téléchargement depuis releases.hashicorp.com
Homebrew (macOS)	`brew install packer`
Chocolatey (Windows)	`choco install packer`

Installer Packer Choisir la méthode d'installation adaptée à votre système

Module 3, Templates HCL2

Le cœur de Packer : les templates HCL2. Vous apprendrez la structure d'un fichier .pkr.hcl, les blocs source et build, et comment créer votre première image Docker.

Bloc	Rôle
`packer {}`	Configuration Packer, plugins requis
`source`	Définition du builder (Docker, AWS, etc.)
`build`	Orchestration des sources, provisioners, post-processors

source "docker" "ubuntu" {
  image  = "ubuntu:24.04"
  commit = true
}

build {
  sources = ["source.docker.ubuntu"]
}

Écrire des templates HCL2 Anatomie d'un template et premier build Docker

Module 4, Variables et fonctions

Rendez vos templates flexibles et réutilisables avec les variables, locals et fonctions built-in.

Concept	Exemple
Variables	`variable "image_tag" { default = "latest" }`
Locals	`local { timestamp = formatdate("YYYYMMDDhhmmss", timestamp()) }`
Fonctions	`upper()`, `lower()`, `replace()`, `join()`, `file()`
Conditionnelles	`condition ? true_val : false_val`

Paramétrer avec variables et fonctions Variables, locals, fichiers .pkrvars.hcl et fonctions built-in

Module 5, Provisioners

Les provisioners configurent l'image après sa création : installation de paquets, copie de fichiers, exécution de playbooks Ansible.

Provisioner	Usage
shell	Commandes bash/sh, scripts
file	Copie de fichiers locaux vers l'image
ansible	Exécution de playbooks Ansible
shell-local	Commandes sur la machine hôte

Configurer avec provisioners Shell, file, Ansible et bonnes pratiques de configuration

Module 6, Post-processors

Les post-processors agissent après le build : compression, génération de manifest, push vers un registry Docker.

Post-processor	Résultat
compress	Archive `.tar.gz` de l'image
manifest	Fichier JSON avec métadonnées du build
checksum	Hash SHA256 pour vérification d'intégrité
docker-import	Importation dans Docker Engine
docker-tag	Tag de l'image Docker
docker-push	Push vers Docker Hub/Registry privé

Enchaîner des post-processors Actions post-build et chaînage de post-processors

Module 7, Bonnes pratiques

Industrialisez vos templates avec une structure projet propre, un Makefile, des techniques de debug et l'intégration CI/CD.

Thème	Contenu
Structure projet	Organisation des fichiers `.pkr.hcl`
Makefile	Cibles `validate`, `build`, `clean`
Debug	Variables `PACKER_LOG`, mode step-by-step
Secrets	Variables d'environnement, pas de hardcode
CI/CD	GitHub Actions, GitLab CI/CD

Appliquer les bonnes pratiques Structure, Makefile, debug et intégration CI/CD

Par où commencer ?

Suivez les modules dans l'ordre, en commençant par les concepts. Prenez le temps de créer les labs Docker pour chaque module.

Premier module : Concepts et cas d'usage

FAQ : questions fréquentes

Les questions les plus posées sur Packer : différence avec Dockerfile ou Terraform, licence, installation, provisioners et intégration CI/CD.

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.

Packer est un outil open source développé par HashiCorp qui crée des images machine identiques pour plusieurs plateformes à partir d'une configuration unique.

Ce que Packer fait

Fonction	Exemple
Création d'images	AMI AWS, images Docker, VM Azure
Multi-plateforme	1 template → plusieurs images
Automatisation	Build reproductible sans intervention
Golden images	Image de base standardisée

Exemple rapide

source "docker" "ubuntu" {
  image  = "ubuntu:24.04"
  commit = true
}

build {
  sources = ["source.docker.ubuntu"]
  provisioner "shell" {
    inline = ["apt-get update && apt-get install -y curl"]
  }
}

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.

La différence principale est le périmètre d'utilisation :

Comparaison

Critère	Packer	Dockerfile
Cible	Multi-plateforme	Docker uniquement
Format	HCL2	DSL spécifique
Provisioners	Shell, Ansible, Chef, Puppet	RUN uniquement
Sortie	AMI, VMDK, OCI, Docker...	Image Docker
Écosystème	HashiCorp	Docker/OCI
Cas d'usage	Golden images multi-cloud	Conteneurs applicatifs

Quand utiliser quoi ?

Dockerfile : applications conteneurisées, développement local
Packer : golden images multi-cloud, immutable infrastructure
Les deux : Packer peut utiliser Docker comme builder de test

Exemple identique

# Dockerfile
FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl

# Packer HCL2
source "docker" "ubuntu" {
  image  = "ubuntu:24.04"
  commit = true
}
build {
  sources = ["source.docker.ubuntu"]
  provisioner "shell" {
    inline = ["apt-get update && apt-get install -y curl"]
  }
}

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.

Packer s'installe facilement car c'est un binaire unique sans dépendances.

Linux (recommandé : asdf)

# Avec asdf (gestion de versions)
asdf plugin add packer
asdf install packer latest
asdf set --home packer latest

# Ou téléchargement direct
wget https://releases.hashicorp.com/packer/1.15.0/packer_1.15.0_linux_amd64.zip
unzip packer_1.15.0_linux_amd64.zip
sudo mv packer /usr/local/bin/

macOS

# Homebrew
brew install packer

Windows

# Chocolatey
choco install packer

# Ou Scoop
scoop install packer

Vérification

packer --version
# Packer v1.15.0

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.

Un template HCL2 est un fichier .pkr.hcl qui définit comment créer une image.

Blocs principaux

Bloc	Rôle	Obligatoire
`packer {}`	Configuration, plugins requis	Optionnel
`source`	Définition du builder	Oui
`build`	Orchestration du build	Oui
`variable`	Paramètres d'entrée	Optionnel
`locals`	Valeurs calculées	Optionnel

Exemple minimal

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

source "docker" "ubuntu" {
  image  = "ubuntu:24.04"
  commit = true
}

build {
  sources = ["source.docker.ubuntu"]
}

HCL2 vs JSON

Aspect	HCL2	JSON (legacy)
Lisibilité	Excellente	Difficile
Commentaires	`#` ou `//`	Non supportés
Fonctions	Built-in	Limitées
Statut	Recommandé	Déprécié

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.

Packer propose plusieurs commandes pour valider vos templates avant de builder.

Workflow de validation

# 1. Télécharger les plugins requis
packer init .

# 2. Vérifier le formatage
packer fmt -check .

# 3. Valider la syntaxe et la cohérence
packer validate .

# Optionnel : avec des variables
packer validate -var "image_tag=latest" .

Ce que valide Packer

Commande	Vérifie
`packer init`	Plugins disponibles et téléchargés
`packer fmt -check`	Formatage HCL conforme
`packer validate`	Syntaxe, références, cohérence

En CI/CD

# Échouer au premier problème
packer init . && packer fmt -check . && packer validate .

Exemple de sortie

$ packer validate .
The configuration is valid.

$ packer validate broken.pkr.hcl
Error: Unknown source type "docker.ubuntu"

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

Packer supporte de nombreux builders pour créer des images sur différentes plateformes.

Builders principaux

Builder	Plateforme	Sortie
docker	Docker Engine	Image OCI
amazon-ebs	AWS	AMI
azure-arm	Azure	Managed Image
googlecompute	GCP	Compute Image
qemu	KVM/Proxmox	QCOW2
vmware-iso	VMware	VMDK
virtualbox-iso	VirtualBox	OVA
lxc / lxd	Conteneurs Linux	Image LXC/LXD
null	Test	Aucune (dry-run)

Installation des plugins

packer {
  required_plugins {
    docker = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/docker"
    }
    amazon = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

Multi-plateforme

Un même template peut cibler plusieurs builders :

build {
  sources = [
    "source.docker.ubuntu",
    "source.amazon-ebs.ubuntu"
  ]
}

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.

Les variables rendent vos templates flexibles et réutilisables.

Déclaration

variable "image_tag" {
  type        = string
  default     = "latest"
  description = "Tag de l'image Docker"
}

variable "packages" {
  type    = list(string)
  default = ["curl", "wget", "vim"]
}

Utilisation

source "docker" "app" {
  image  = "ubuntu:${var.image_tag}"
  commit = true
}

Fournir des valeurs

Méthode	Exemple
CLI	`packer build -var "image_tag=1.0" .`
Fichier	`packer build -var-file=prod.pkrvars.hcl .`
Environnement	`export PKR_VAR_image_tag=1.0`

Locals (valeurs calculées)

locals {
  timestamp  = formatdate("YYYYMMDDhhmmss", timestamp())
  image_name = "app-${var.image_tag}-${local.timestamp}"
}

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.

Un provisioner configure l'image après sa création par le builder.

Provisioners principaux

Provisioner	Usage
shell	Commandes bash/sh, scripts
file	Copie de fichiers vers l'image
ansible	Exécution de playbooks
shell-local	Commandes sur la machine hôte

Exemple

build {
  sources = ["source.docker.ubuntu"]

  provisioner "file" {
    source      = "config/app.conf"
    destination = "/etc/app/app.conf"
  }

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

  provisioner "ansible" {
    playbook_file = "playbooks/configure.yml"
  }
}

Ordre d'exécution

Les provisioners s'exécutent dans l'ordre de déclaration :

file → copie les fichiers
shell → installe les paquets
ansible → configure l'application

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.

Plusieurs techniques pour débugger un build qui échoue.

Logs détaillés

# Activer tous les logs
export PACKER_LOG=1
packer build .

# Ou en une ligne
PACKER_LOG=1 packer build .

Mode interactif

# Pause entre chaque étape
packer build -debug .

# Pause configurable
PACKER_LOG=1 PACKER_LOG_PATH=packer.log packer build -debug .

Gestion des erreurs

# Demander quoi faire en cas d'erreur
packer build -on-error=ask .
# Options : abort, retry, cleanup

Problèmes courants

Symptôme	Cause probable
Timeout SSH	Firewall, clé SSH incorrecte
Command not found	Chemin non dans PATH
Permission denied	Utilisateur non root, sudo requis
Plugin not found	`packer init .` pas exécuté
Variable undefined	Variable déclarée mais non valorisée

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.

Un post-processor agit sur l'image après le build : transformation, métadonnées, publication.

Post-processors principaux

Post-processor	Action
compress	Archive `.tar.gz` de l'image
manifest	Fichier JSON avec métadonnées
checksum	Hash SHA256 pour intégrité
docker-import	Import dans Docker Engine
docker-tag	Ajout de tags à l'image
docker-push	Push vers registry

Exemple simple

build {
  sources = ["source.docker.ubuntu"]

  post-processor "manifest" {
    output = "manifest.json"
  }
}

Chaînage de post-processors

post-processors {
  post-processor "docker-import" {
    repository = "myapp"
    tag        = "latest"
  }
  post-processor "docker-push" {
    login          = true
    login_server   = "registry.example.com"
    login_username = var.registry_user
    login_password = var.registry_pass
  }
}

Le chaînage garantit que chaque étape utilise le résultat de la précédente.

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.

GitHub Actions

name: Build Image
on: [push]

jobs:
  packer:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Packer
        uses: hashicorp/setup-packer@v3
        with:
          version: "1.15.0"

      - name: Init
        run: packer init .

      - name: Validate
        run: packer fmt -check . && packer validate .

      - name: Build
        run: packer build .
        env:
          PKR_VAR_image_tag: ${{ github.sha }}

GitLab CI/CD

packer-build:
  image: hashicorp/packer:1.15.0
  script:
    - packer init .
    - packer fmt -check .
    - packer validate .
    - packer build .
  variables:
    PKR_VAR_image_tag: $CI_COMMIT_SHORT_SHA
  cache:
    paths:
      - .packer.d/

Bonnes pratiques CI/CD

Cacher le répertoire des plugins
Variables d'environnement pour les secrets
Validation avant le build
Manifest pour traçabilité

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.

Créer une AMI AWS avec le builder amazon-ebs.

Template minimal

packer {
  required_plugins {
    amazon = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

variable "aws_region" {
  default = "eu-west-3"
}

source "amazon-ebs" "ubuntu" {
  region        = var.aws_region
  instance_type = "t3.micro"

  source_ami_filter {
    filters = {
      name                = "ubuntu/images/*ubuntu-jammy-22.04-amd64-server-*"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["099720109477"]  # Canonical
  }

  ssh_username = "ubuntu"
  ami_name     = "my-app-{{timestamp}}"
}

build {
  sources = ["source.amazon-ebs.ubuntu"]

  provisioner "shell" {
    inline = ["sudo apt-get update && sudo apt-get install -y nginx"]
  }
}

Authentification

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG..."
packer build .

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

Structure recommandée pour un projet Packer maintenable.

Arborescence

projet-packer/
├── common.pkr.hcl       # Plugins, config commune
├── variables.pkr.hcl    # Déclarations de variables
├── locals.pkr.hcl       # Valeurs calculées
├── docker.pkr.hcl       # Source Docker
├── aws.pkr.hcl          # Source AWS (optionnel)
├── build.pkr.hcl        # Blocs build
├── dev.pkrvars.hcl      # Variables dev
├── prod.pkrvars.hcl     # Variables prod
├── scripts/
│   ├── setup.sh
│   └── cleanup.sh
├── config/
│   └── app.conf
└── Makefile

Makefile

.PHONY: init validate build clean

init:
	packer init .

validate: init
	packer fmt -check .
	packer validate .

build: validate
	packer build -var-file=dev.pkrvars.hcl .

build-prod: validate
	packer build -var-file=prod.pkrvars.hcl .

clean:
	rm -f manifest.json *.tar.gz

Utilisation

make build        # Build dev
make build-prod   # Build 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.

Plusieurs techniques pour sécuriser les secrets dans Packer.

Variables sensibles

variable "docker_password" {
  type      = string
  sensitive = true  # Masqué dans les logs
}

Bonnes pratiques

Méthode	Sécurité	Usage
Env vars	✅ Bonne	`PKR_VAR_password=xxx packer build .`
CI Secrets	✅ Excellente	GitHub Secrets, GitLab CI Variables
Vault	✅ Enterprise	HashiCorp Vault integration
CLI -var	⚠️ Risquée	Visible dans historique shell
Fichier committé	❌ Dangereuse	Jamais en production

En CI/CD

# GitHub Actions
env:
  PKR_VAR_docker_password: ${{ secrets.DOCKER_PASSWORD }}

# GitLab CI
variables:
  PKR_VAR_docker_password: $DOCKER_PASSWORD

.gitignore

# Ne jamais committer
*.pkrvars.hcl
!example.pkrvars.hcl

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.

Oui ! Packer exécute les builds de plusieurs sources en parallèle par défaut.

Multi-sources

source "docker" "app" {
  image  = "ubuntu:24.04"
  commit = true
}

source "amazon-ebs" "app" {
  region        = "eu-west-3"
  instance_type = "t3.micro"
  # ...
}

build {
  sources = [
    "source.docker.app",
    "source.amazon-ebs.app"
  ]

  provisioner "shell" {
    inline = ["echo 'Hello from ${source.type}'"]
  }
}

Contrôle du parallélisme

# Limiter à 2 builds simultanés
packer build -parallel-builds=2 .

# Un seul build à la fois
packer build -parallel-builds=1 .

Avantages

Gain de temps : Docker et AWS se buildent simultanément
Même configuration : provisioners partagés
Artefacts séparés : chaque builder produit son image

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 et Terraform sont deux outils HashiCorp complémentaires, pas concurrents.

Critère	Packer	Terraform
Rôle	Construire des images machine	Provisionner l'infrastructure
Produit	AMI, image Docker, QCOW2, VMDK	VM, réseau, stockage, DNS
Moment	Avant le déploiement (build)	Au déploiement (apply)
Langage	HCL2	HCL2

Workflow combiné

Packer crée une image durcie et pré-configurée (golden image).
Terraform déploie des instances à partir de cette image.

Cette séparation applique le principe d'immutable infrastructure : on ne modifie pas un serveur en place, on redéploie une nouvelle image versionnée.

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.

Les deux sont signés HashiCorp mais répondent à des besoins différents.

Aspect	Packer	Vagrant
Objectif	Construire des images machine	Orchestrer des VMs de dev
Cible	Production, cloud, multi-plateforme	Poste de développement local
Produit	AMI, image Docker, QCOW2, box	VM lancée depuis une box
Cycle de vie	Build ponctuel d'un artefact	`up`, `ssh`, `halt`, `destroy`

Comment ils s'articulent

Packer peut générer les box que Vagrant consomme, grâce à son post-processor vagrant :

post-processor "vagrant" {
  output = "ma-box.box"
}

En pratique : Packer standardise l'image de base une fois pour toutes, Vagrant l'instancie en local pour que chaque développeur travaille dans le même environnement.

Ressources complémentaires

Site officiel : packer.io
Documentation : developer.hashicorp.com/packer/docs
Référence HCL2 : developer.hashicorp.com/packer/docs/templates/hcl_templates
Builders : developer.hashicorp.com/packer/integrations
GitHub Packer : github.com/hashicorp/packer

Formation Packer : du template de base à l'automatisation complète

Présentation de cette formation

En bref

Ce que vous apprendrez

Vue d'ensemble de la formation

Le parcours de formation

Programme détaillé

Module 1, Concepts et cas d'usage

Module 2, Installation multi-plateforme

Module 3, Templates HCL2

Module 4, Variables et fonctions

Module 5, Provisioners

Module 6, Post-processors

Module 7, Bonnes pratiques

Par où commencer ?

FAQ : questions fréquentes

Ce que Packer fait

Exemple rapide

Comparaison

Quand utiliser quoi ?

Exemple identique

Linux (recommandé : asdf)

macOS

Windows

Vérification

Blocs principaux

Exemple minimal

HCL2 vs JSON

Workflow de validation

Ce que valide Packer

En CI/CD

Exemple de sortie

Builders principaux

Installation des plugins

Multi-plateforme

Déclaration

Utilisation

Fournir des valeurs

Locals (valeurs calculées)

Provisioners principaux

Exemple

Ordre d'exécution

Logs détaillés

Mode interactif

Gestion des erreurs

Problèmes courants

Post-processors principaux

Exemple simple

Chaînage de post-processors

GitHub Actions

GitLab CI/CD

Bonnes pratiques CI/CD

Template minimal

Authentification

Arborescence

Makefile

Utilisation

Variables sensibles

Bonnes pratiques

En CI/CD

.gitignore

Multi-sources

Contrôle du parallélisme

Avantages

Workflow combiné

Licence

Comment ils s'articulent

Ressources complémentaires