Machine Images mit Packer erstellen: Builder, Provisioner, validate und build

Ziel

Ein Packer-Template schreiben, validieren und ausführen, das ein Machine Image erzeugt, ohne dass Zugangsdaten in der Template-Datei selbst stehen.

Voraussetzungen

Die packer-CLI ist auf dem Rechner oder CI-Runner installiert, der den Build ausführt. Zugangsdaten für die Zielplattform (Cloud-API-Schlüssel, Hypervisor-Zugang) liegen als Umgebungsvariablen oder in einem Secrets Manager vor, nicht als Literale im Template.

Schritte

1. Vor dem Schreiben die beiden zentralen Bausteine verstehen. Die Terminologie-Referenz von HashiCorp beschreibt Builder als Komponenten, die ein Machine Image für eine einzelne Plattform erzeugen können ("that are able to create a machine image for a single platform"); sie lesen die Konfiguration und erzeugen das Artefakt. Provisioner dagegen installieren und konfigurieren Software in einer laufenden Maschine, bevor diese in ein statisches Artefakt überführt wird ("install and configure software within a running machine prior to that machine being turned into a static artifact"). Als Beispiele für Provisioner werden Shell-Skripte und Konfigurationswerkzeuge von Drittanbietern genannt.
2. Zugangsdaten und andere umgebungsspezifische Werte als Eingabevariablen deklarieren statt als Literale: ein variable "api_token"-Block mit type = string und sensitive = true auf getrennten Zeilen (HCL akzeptiert innerhalb eines Blocks keine kommagetrennten Argumente). HCL-Templates unterstützen in Variablenblöcken das Argument sensitive; es bewirkt, dass String-Werte dieser Variable in der Ausgabe von Packer unkenntlich gemacht werden ("string-values from that variable to be obfuscated from Packer's output"), also in Logs und Konsolenausgaben.
3. Den tatsächlichen geheimen Wert erst zur Build-Zeit aus der Umgebung (PKR_VAR_api_token) oder über ein -var- bzw. -var-file-Argument bereitstellen, das aus einem Secrets Manager stammt. Er wird nie im Template-Repository eingecheckt.
4. Die im Block packer { required_plugins { ... } } des Templates deklarierten Plugins installieren: packer init . (nur für HCL2-Templates; seit Packer 1.10 sind offizielle Plugins nicht mehr gebündelt). Danach packer validate . ausführen (oder für eine einzelne .pkr.hcl-Datei). Der Befehl "is used to validate the syntax and configuration of a template" (dient dazu, Syntax und Konfiguration eines Templates zu prüfen) und endet bei einem Fehler mit einem Exit-Code ungleich null; er sollte in der CI bei jeder Änderung laufen. -syntax-only überspringt die Konfigurationsprüfung.
5. Den Build starten: packer build .. Der Befehl "takes a template and runs all the builds within it" (nimmt ein Template und führt alle darin enthaltenen Builds aus), um Artefakte zu erzeugen. Die Builds laufen parallel, sofern nicht mit -parallel-builds=N begrenzt, und mit -only= bzw. -except= lassen sich Builds auswählen.
6. Die Kennung des erzeugten Artefakts (AMI-ID, Image-Name usw.) als Build-Ausgabe für die nächste Stufe der Pipeline speichern. Provisioner nicht erneut gegen ein bereits gebautes Artefakt laufen lassen; jeder Build gilt als Erzeugung eines unveränderlichen (immutable) Images.

Erwartetes Ergebnis

packer validate endet mit Exit-Code 0 und ohne Template-Fehler, bevor ein echter Build versucht wird. packer build erzeugt ein versioniertes Image-Artefakt, und in der eigenen Konsolenausgabe und den Logs ist kein Zugangsdatenwert sichtbar.

Grenzen und Prüfbasis

Das Markieren einer Variable als sensitive verhindert, dass Packer ihren Wert ausgibt. Es verschlüsselt den Wert jedoch weder im Arbeitsspeicher noch in einer State- oder Cache-Datei, die manche Plugins schreiben, noch in der Ausgabe eines Provisioner-Skripts, falls dieses den Wert selbst ausgibt; Provisioner-Skripte müssen Secrets eigenständig sorgfältig behandeln. packer validate findet Syntax- und Schemafehler in der Konfiguration, aber keine Laufzeitfehler wie eine nicht erreichbare Builder-Plattform oder ein Provisioner-Skript, das auf dem Ziel-OS fehlschlägt; das zeigt erst packer build. Schlägt ein Provisioner fehl, löscht die Voreinstellung -on-error=cleanup die temporäre Maschine und die temporären Dateien. -on-error=abort (oder die Wahl von abort bei der Rückfrage von ask) lässt sie zur Fehlersuche bestehen; sie müssen dann selbst entfernt werden, einschliesslich Cloud-Instanzen, die weiterhin berechnet werden. Bei einem Lauf mit mehreren Builds erzeugen erfolgreiche Builds trotzdem Artefakte, daher ist zu prüfen, welche vorhanden sind.