Thema: imaging
-
Windows-Image mit Sysprep generalisieren: /generalize, /oobe, /shutdown und das Rearm-Limit
Sysprep /generalize entfernt computerspezifische Informationen wie die SID und die konfigurierten Geräte aus einer Windows-Installation, damit sich das Image auf andere Computer verteilen lässt. Ab Windows 8.1/Server 2012 kann Sysprep bis zu 1001-mal pro Image ausgeführt werden (unter Windows 7/Server 2008 R2 dreimal); Fehler beim Generalisieren hinterlassen Spuren in den Panther-Logs unter System32\Sysprep.
-
Linux-Golden-Image fürs Klonen vorbereiten: Host Keys, machine-id, Logs und Netzwerkregeln
Ein Linux-Image, das mehrfach geklont werden soll, darf weder eine befüllte /etc/machine-id (oder eine veraltete /var/lib/dbus/machine-id) noch vorhandene SSH-Host-Keys, an die MAC-Adresse gebundene Netzwerkkonfiguration oder cloud-init-Zustand enthalten. Sonst starten alle Klone mit denselben Kennungen wie ihre Geschwister; und wer die Host Keys entfernt, ohne sie beim ersten Start neu erzeugen zu lassen, hinterlässt Klone ohne SSH-Zugang.
-
Machine Images mit Packer erstellen: Builder, Provisioner, validate und build
HashiCorp Packer trennt die Builder eines Templates (welche Plattform das Image erzeugt) von den Provisionern (was die Maschine konfiguriert, bevor sie als Image festgehalten wird). `packer init` installiert die benötigten Plugins, `packer validate` prüft Syntax und Konfiguration, bevor `packer build` das Template ausführt, und als sensitive markierte Variablen halten Zugangsdaten aus Templates und Logs fern.
-
Konfigurationsmanagement versus Image Baking: Wo Idempotenz und Drift entscheiden
Konfigurationsmanagement-Tools führen ein laufendes System bei jedem Lauf wieder auf einen deklarierten Zustand zurück, während Image Baking diesen Zustand einmalig beim Build festschreibt. Idempotenz macht die wiederholte Ausführung des ersten Ansatzes sicher; die Wahl zwischen Baking und Konfiguration beim Boot ist letztlich die Entscheidung, wo Drift auftreten darf.
Maschinenlesbar: JSON