Thema: imaging
-
Generalizing a Windows image with Sysprep: /generalize, /oobe, /shutdown and the rearm limit
Sysprep /generalize removes computer-specific information such as the SID and the configured devices from a Windows installation so the image can be deployed to other computers; on Windows 8.1/Server 2012 and later Sysprep can be run up to 1001 times per image (3 times on Windows 7/Server 2008 R2), and generalize failures leave their trace in the Panther logs under System32\Sysprep.
-
Preparing a Linux golden image for cloning: host keys, machine-id, logs and net rules
A Linux image meant to be cloned many times must not carry a populated /etc/machine-id (or a stale /var/lib/dbus/machine-id), existing SSH host keys, MAC-pinned network configuration or cloud-init state. Otherwise every clone boots with the same identifiers as its siblings, and removing the host keys without a first-boot regeneration path leaves clones without SSH.
-
Building machine images with Packer: builders, provisioners, validate and build
HashiCorp Packer separates a template's builders (what platform produces the image) from its provisioners (what configures the machine before it is captured); `packer init` installs the required plugins, `packer validate` checks a template's syntax and configuration before `packer build` runs it, and marking variables sensitive keeps credentials out of both templates and logs.
-
Configuration management versus image baking: where idempotence and drift decide
Configuration management tools converge a running system toward a declared state on every run, while baking a machine image fixes that state once, at build time; idempotence is what makes the first approach safe to repeat, and the choice between baking and configuring at boot is really a choice about where drift is allowed to happen.
Maschinenlesbar: JSON