1.9 KiB
ctrl/Dockerfile.deps
Purpose
The toolchain installer image. It does NOT run the cluster — it installs a toolchain onto the host and gets out of the way.
This exists to kill a bootstrap paradox: a plain bash installer needs curl, jq and sha256sum to already be present, and a minimal Debian has none of them. It carries its own toolchain, so the only host prerequisite is Docker.
Variants
Two variants from one file:
docker build -f ctrl/Dockerfile.deps --target deps -t <slug>-deps .
docker build -f ctrl/Dockerfile.deps --target deps-full -t <slug>-deps:full .
deps-full bakes every pinned binary in at build time, and the manifests rig's own addons apply (metallb, cert-manager, metrics-server). docker save it and you have the whole installer as one file to carry into an air-gapped network. There, put the manifests where the addons look for them:
docker run --rm -v "$PWD/vendor:/out/vendor" rig-deps:full manifests --to /out/vendor/manifests
Each is verified against its pin on the way out, and again when an addon uses it. The addons' container images still have to be preloaded into the local registry: the manifests reference quay.io and registry.k8s.io, and registry mirroring covers docker.io only.
Packages
ca-certificates + curl: fetch and verify. graphviz + python3: render diagrams and validate the arch model, so the host never needs an apt package.
docker-cli, NOT docker.io: we only ever talk to the host's daemon through the mounted socket, and under --no-install-recommends the docker.io package ships docker-init without the actual docker binary.
The installer is the standalone kit
The installer is the generated standalone kit, not deps.sh plus the files it reads. A kit is one file with its pins frozen in and is proven to run with nothing else from rig present — which is exactly what an image needs, and make standalone keeps it current. Pins are the same in every profile's kit.