Getting the slim Driftwood image off the laptop and onto a production host it can trust. How a registry stores and ships images, which registry to put them in, a tagging discipline that survives a release process, one image that runs on both amd64 and arm64, signatures that prove who built the bytes, and a scanner that catches CVEs before they ship.
6 topics
Layer B opens here. Through the first eight chapters Driftwood became a slim, well-built image, but it never left the machine that built it. This chapter follows that image out the door — tagged driftwood/web:1.4.0, built for both amd64 and arm64, scanned, signed, and pushed to a private registry that production hosts pull from by digest.
A registry is the hinge between building an image and running it somewhere else, and most of distribution is understanding that one HTTP service well: what it stores, what a push and a pull actually transfer, how access is scoped, and how a host ends up trusting the exact bytes it pulls. This chapter builds on the manifests and digests from Chapter 2 — it assumes you know an image is named by its content — and turns that into a release pipeline a team can run.