Packer (HashiCorp) construit des images de VM immuables à partir d’une définition déclarative (.pkr.hcl) : il boote une VM temporaire, exécute des provisioners dessus, publie le disque résultant comme image, puis détruit la VM temporaire. Contrairement à Terraform qui gère de l’infrastructure vivante, Packer ne produit qu’un artefact — l’image — ensuite consommée par un Instance Template.
Le problème que Packer résout
Sans Packer, une image « custom » se construit à la main : on boote une VM, on installe tout dessus au clavier, puis on la fige avec gcloud compute images create. Ça marche une fois, mais c’est irrémédiablement non reproductible — impossible de savoir exactement ce qui a été fait, impossible de reconstruire la même image dans six mois ou sur un autre projet GCP, impossible de la relire/reviewer comme du code.
Packer remplace ce geste manuel par un fichier déclaratif versionné : le même .pkr.hcl reconstruit toujours la même image, peut être relu en revue de code, et tourne aussi bien sur le poste d’un développeur qu’en CI. C’est le même changement de paradigme que celui d’un Dockerfile par rapport à un conteneur configuré à la main — sauf que l’artefact produit ici est une image de VM entière, pas un layer de conteneur.
Ce qu’il se passe concrètement pendant un packer build
1. Packer lit le template, résout les variables
2. Le builder (ex. googlecompute) crée une VM temporaire dans le projet GCP
— avec une IP publique temporaire, sauf configuration contraire
3. Packer attend que la VM soit joignable en SSH (ou WinRM)
4. Chaque provisioner s'exécute dans l'ordre sur cette VM (shell, ansible, file...)
5. Le builder arrête la VM, crée une image à partir de son disque
6. Les post-processors s'exécutent (ex. écrire manifest.json)
7. La VM et les ressources temporaires (disque, règles firewall auto-créées) sont détruites
Si le build échoue à l’étape 4, Packer détruit quand même la VM temporaire par défaut (sauf -on-error=ask ou -on-error=abort, voir Commandes Packer) — pas de VM orpheline qui traîne et continue à être facturée.
Prérequis pour builder sur GCP
- Authentification disponible pour Packer : soit
gcloud auth application-default loginen local, soit un compte de service (clé JSON ou Workload Identity en CI). - Le compte utilisé a besoin des droits pour créer/supprimer une VM temporaire, un disque, et créer une image dans le projet cible (
roles/compute.instanceAdmin.v1+roles/compute.storageAdmincouvrent le besoin, ou un rôle custom plus restreint). - L’API Compute Engine activée sur le projet.
- Un réseau/subnet existant pour la VM temporaire (
networkdans le blocsource) — la VM de build a besoin de sortir sur Internet ou d’un accès privé pour installer des paquets (apt-get, etc.), sauf si l’image de base et les dépendances sont déjà tout accessibles en interne.
Piège courant pour un premier build
image_name doit être unique dans le projet : relancer un build avec le même nom échoue si l’image existe déjà (sauf -force, qui la supprime avant de reconstruire). C’est voulu — ça force à versionner explicitement (app-v1-0-0, app-v1-0-1…) plutôt que d’écraser silencieusement une image que d’autres composants utilisent peut-être déjà en production.
Où se situe Packer dans le pipeline
Packer → construit et publie une image versionnée (artefact)
Terraform → déploie l'infrastructure qui consomme cette image (Instance Template, MIG)
Les deux outils sont complémentaires et volontairement séparés : Packer ne connaît rien de l’infrastructure cible, Terraform ne sait pas construire d’image.
Image pré-construite vs startup-script
| Startup-script (au boot) | Image pré-construite (Packer) | |
|---|---|---|
| Démarrage | Dépend du téléchargement/installation à chaque VM | VM prête immédiatement, rien à installer |
| Reproductibilité | Dépend de la disponibilité des dépôts au moment du boot | Figée une fois pour toutes dans l’image |
| Testabilité | Difficile à tester hors production | Image versionnée, testable en CI avant promotion |
| Rollback | Revenir à un script précédent ne suffit pas toujours | Revenir à une version d’image antérieure |
C’est le modèle utilisé pour un health check en mode « endpoint déjà fourni par l’image » : l’agent de santé tourne déjà en systemd dans l’image, le module Terraform n’a plus qu’à sonder le port exposé via Managed Instance Group (MIG) — il n’installe rien lui-même au démarrage.
En relation avec
- Synthèse Packer — hub principal
- Création d’une image custom — le résultat produit par Packer côté GCP
- Instance Template — consomme ensuite l’image publiée
- Synthèse Terraform — outil complémentaire, gère l’infrastructure qui consomme l’image