Construire des images machine avec Packer : builders, provisioners, validate et build

Objectif

Écrire, valider et exécuter un template Packer qui produit une image machine, sans intégrer d'identifiants dans le fichier du template lui-même.

Prérequis

Le CLI packer installé sur la machine ou le runner CI qui exécutera le build ; les identifiants de la plateforme cible (clés d'API cloud, accès à l'hyperviseur) disponibles sous forme de variables d'environnement ou dans un gestionnaire de secrets, et non comme valeurs littérales dans le template.

Étapes

1. Comprendre les deux composants de base avant d'écrire quoi que ce soit. La référence terminologique de HashiCorp décrit les builders comme des composants « that are able to create a machine image for a single platform » (capables de créer une image machine pour une seule plateforme) : ils lisent la configuration et produisent l'artefact. Les provisioners, eux, « install and configure software within a running machine prior to that machine being turned into a static artifact » (installent et configurent des logiciels dans une machine en cours d'exécution avant qu'elle ne soit transformée en artefact statique) ; les scripts shell et les outils de configuration tiers sont cités comme exemples de provisioners.
2. Déclarer les identifiants et les autres valeurs propres à l'environnement comme variables d'entrée plutôt que comme littéraux : un bloc variable "api_token" avec type = string et sensitive = true sur des lignes distinctes (HCL n'accepte pas d'arguments séparés par des virgules dans un bloc). Les templates HCL prennent en charge l'argument sensitive sur un bloc variable, ce qui fait que les valeurs de type chaîne de cette variable sont masquées (« string-values from that variable to be obfuscated from Packer's output ») dans les logs et la sortie console.
3. Fournir la valeur réelle du secret au moment du build, via l'environnement (PKR_VAR_api_token) ou un argument -var / -var-file alimenté par un gestionnaire de secrets, et ne jamais la versionner dans le dépôt du template.
4. Installer les plugins déclarés dans le bloc packer { required_plugins { ... } } du template : packer init . (templates HCL2 uniquement ; depuis Packer 1.10, les plugins officiels ne sont plus fournis avec l'outil). Exécuter ensuite packer validate . (ou sur un seul fichier .pkr.hcl). La commande « is used to validate the syntax and configuration of a template » (sert à valider la syntaxe et la configuration d'un template) et se termine avec un code de sortie non nul en cas d'échec ; il convient de l'exécuter en CI à chaque modification. -syntax-only ignore la vérification de la configuration.
5. Lancer le build : packer build .. La commande « takes a template and runs all the builds within it » (prend un template et exécute tous les builds qu'il contient) pour générer les artefacts, en parallèle sauf limitation par -parallel-builds=N ; -only= et -except= permettent de sélectionner les builds.
6. Conserver l'identifiant de l'artefact obtenu (ID d'AMI, nom d'image, etc.) comme sortie du build pour l'étape suivante du pipeline, et éviter de relancer les provisioners sur un artefact déjà construit : chaque build doit être traité comme produisant une image immuable.

Résultat attendu

packer validate se termine avec le code 0 et sans erreur de template avant toute tentative de build réel ; packer build produit un artefact d'image versionné, sans qu'aucune valeur d'identifiant ne soit visible dans sa propre sortie console ou ses logs.

Limites et base de vérification

Marquer une variable sensitive empêche Packer d'afficher sa valeur ; cela ne la chiffre pas en mémoire, ni dans un fichier d'état ou de cache que certains plugins peuvent écrire, ni dans la sortie du script d'un provisioner si ce script affiche lui-même la valeur : les scripts des provisioners doivent manipuler les secrets avec précaution par leurs propres moyens. packer validate détecte les erreurs de syntaxe et de configuration au niveau du schéma, mais pas les échecs à l'exécution, comme une plateforme de builder inaccessible ou un script de provisioner qui échoue sur l'OS cible ; seul packer build les met à l'épreuve. Si un provisioner échoue, le comportement par défaut -on-error=cleanup supprime la machine temporaire et les fichiers. -on-error=abort (ou le choix d'abandonner à l'invite ask) les conserve pour le débogage ; il faut alors les supprimer soi-même, y compris les instances cloud qui restent facturées. Dans une exécution à plusieurs builds, ceux qui ont réussi produisent tout de même leurs artefacts : il faut donc vérifier lesquels existent.