Packer
| Fiche express | |
|---|---|
| Type | Outil de construction d'images machine (Infrastructure as Code, en amont du provisionnement) |
| Éditeur | HashiCorp |
| Langage | HCL2 (JSON accepté en alternative) |
| Cycle de vie | init · validate · build |
| Sorties typiques | AMI, image vSphere/OVF, image Proxmox, image cloud (Azure/GCP), image container |
| Voir aussi | Terraform — Concepts fondamentaux · Vsphere · Proxmox · Vagrant |
Packer est un outil d'HashiCorp qui automatise la construction d'images machine identiques à partir d'un template déclaratif unique : images cloud (AMI AWS, images Azure/GCP), images de machine virtuelle on-prem (VMware vSphere, Proxmox), voire images de conteneur (Docker). Il se positionne en amont du provisionnement d'infrastructure : Packer fabrique l'image, Terraform (ou OpenTofu) provisionne l'infrastructure qui consomme cette image. Les deux outils sont complémentaires et souvent utilisés en pipeline l'un après l'autre.
Principe : golden image
L'idée centrale est celle de la golden image (ou image dorée) : plutôt que de partir d'une image nue et de tout configurer au démarrage de chaque machine (via cloud-init, Ansible ou un script), on construit une fois une image déjà durcie et pré-configurée (paquets installés, correctifs appliqués, agents de supervision présents), puis on la duplique. Cette approche réduit le temps de démarrage des instances, garantit la reproductibilité, et déplace une partie du provisioning « jour 1 » vers un pipeline versionné et testable.
<mermaid> flowchart LR
T[Template Packer
*.pkr.hcl] --> B[packer build] B --> S[Source image
ISO / image cloud existante] S --> P[Provisioners
shell, Ansible...] P --> I[(Image finalisée
AMI / OVF / snapshot)] I --> TF[Terraform / OpenTofu
consomme l'image en resource/data]
</mermaid>
Anatomie d'un template
Un template Packer (fichier .pkr.hcl) déclare trois types de blocs principaux :
- source — l'image de départ et la cible de construction (ex. une AMI de base, un ISO, un template vSphere existant).
- build — associe une ou plusieurs sources à une liste de provisioners et de post-processors.
- provisioner — étape de configuration exécutée pendant le build (shell, Ansible, PowerShell...).
packer {
required_plugins {
amazon = {
source = "github.com/hashicorp/amazon"
version = "~> 1.3"
}
}
}
source "amazon-ebs" "debian" {
ami_name = "debian-bookworm-hardened-{{timestamp}}"
instance_type = "t3.micro"
region = "eu-west-3"
source_ami_filter {
filters = {
name = "debian-12-amd64-*"
virtualization-type = "hvm"
}
owners = ["136693071363"]
most_recent = true
}
ssh_username = "admin"
}
build {
sources = ["source.amazon-ebs.debian"]
provisioner "shell" {
inline = [
"sudo apt-get update",
"sudo apt-get upgrade -y",
"sudo apt-get install -y fail2ban unattended-upgrades"
]
}
provisioner "ansible" {
playbook_file = "./hardening.yml"
}
post-processor "manifest" {
output = "manifest.json"
}
}
Builders (source)
Le builder détermine où et comment l'image est construite. Principaux exemples :
- amazon-ebs / amazon-chroot — AMI AWS.
- vsphere-iso / vsphere-clone — image VMware vSphere, à partir d'un ISO ou d'un template existant (voir Vsphere).
- proxmox-iso / proxmox-clone — image Proxmox VE (voir Proxmox).
- azure-arm, googlecompute — images cloud public.
- docker — image de conteneur (moins central dans les usages Packer que les images VM/cloud).
- qemu — image générique KVM/QEMU (fichier qcow2/raw), utile pour construire une image indépendante de tout hyperviseur cible.
Provisioners
Le provisioner configure l'image pendant le build, avant capture. Les plus courants :
- shell / powershell — scripts inline ou fichiers, le plus simple et le plus universel.
- ansible — exécute un playbook Ansible local à l'intérieur de la machine en construction ; permet de réutiliser exactement les mêmes rôles que ceux appliqués en post-déploiement, réduisant la duplication de logique entre golden image et configuration runtime.
- file — copie de fichiers dans l'image.
Post-processors
Étape exécutée après le build : compression, conversion de format (ex. OVF vers un autre format), publication d'un manifeste JSON récapitulatif (utile pour tracer l'AMI/ID générée et la réinjecter dans une variable Terraform en aval), ou export vers un registre (Vagrant box, registre de conteneurs).
Articulation avec Terraform / OpenTofu
Le motif classique en pipeline CI :
- Packer build produit une image versionnée (ex. AMI horodatée, ou template vSphere/Proxmox nommé).
- L'identifiant de l'image (ID d'AMI, nom du template) est publié (via le post-processor
manifest, une variable de pipeline, ou un registre d'images). - Terraform (ou OpenTofu) consomme cet identifiant, typiquement via un bloc
dataqui recherche l'image la plus récente correspondant à un filtre de nom, puis instancie les machines à partir de cette image.
Cette séparation évite qu'un terraform apply déclenche une reconstruction d'image à chaque exécution : le cycle de build d'image (plus lent, moins fréquent) est découplé du cycle de provisionnement d'infrastructure (plus rapide, plus fréquent).