Build a configured server, create an image or template, and use it to spin up new instances. Automate post-boot config (secrets, hostname) with cloud-init or config management. Keep the golden image updated and tested.
Golden image workflow
- Build once: Install OS, packages, and app bits on a "golden" server. Harden (users, SSH, firewall). No secrets in the image—inject at boot or from a vault.
- Create image: Use provider API or dashboard to create an image/template from the server. Optionally generalize (e.g. remove host-specific IDs) if the provider does not do it.
- Deploy: New instances boot from the image. They get the same base OS and software; differ by hostname, IP, and secrets applied at boot.
Post-boot automation
- cloud-init: Scripts or cloud-init config run at first boot. Set hostname, mount volumes, pull secrets, register with config management or join a cluster. Stored in image or passed as user-data when creating the instance.
- Config management: Ansible, Puppet, Chef, or similar can run after boot to apply role-specific config or the latest state. Image gives a consistent starting point; config management keeps it aligned with policy.
- Secrets: Never bake secrets into the image. Use instance metadata, vault (e.g. HashiCorp Vault), or env vars injected at runtime. Rotate without rebuilding the image.
Maintenance
- Update golden image: On a schedule or after major changes, update the golden server, test, and create a new image. Version images (name or tag) so you can roll back.
- Test: Run smoke tests or integration tests against a newly deployed instance before using the image in production. Catch drift and packaging errors early.
- Document: Document what is in the image, how to build it, and how to request a new one. Reduces "snowflake" setups and speeds onboarding.
Summary
Build a configured server, create an image, and use it to deploy new instances. Automate post-boot config (secrets, hostname) with cloud-init or config management. Keep the golden image updated, tested, and versioned.
