Machine components

Machine components are Ansible roles from the platform's own collection, applied to a VM or container the platform creates. The catalog spans package management (Nexus), code (Gitea, GitLab, a Node.js runtime), observability (Grafana, Loki, VictoriaMetrics, the Elastic stack), networking (NGINX, Apache, Traefik, BIND9, Kea DHCP) and more — each pinned to an exact software version and hardened the same way: checksum-verified downloads, idempotent tasks, a real convergence test before it enters the catalog.

Two special machines

• Bare machine — the OS image you picked, a refreshed package index, and nothing else. Upgrades and extra packages are opt-in. Use it when the platform's job is to hand over a clean box.
• C development (LFS host) — a machine meeting the Linux From Scratch host requirements: full toolchain, $LFS exported, the lfs user, and the book's own version check run last — the component only reports configured when the check passes.

The component lifecycle

1. Attach it from the catalog to your project.
2. Shape the machine in VM settings: image, VM or container, CPU, memory, disk.
3. Validate app settings — the component's inputs (only what the role declares as overridable) with defaults from the catalog; saving them once is required before the first deploy.
4. Attach a volume for each declared persistent path.
5. Deploy — cloud-init installs the pinned collection and runs the role; a telemetry sidecar (node exporter, and a log collector when the project wants one) rides along.

Versions are immutable

Each catalog entry is an immutable revision: the role, its defaults, its input schema and its file checksums, frozen. Redeploying re-renders the same revision; new revisions arrive with collection releases and never rewrite history.