10. Registries, tagging, and multi-arch builds

10.1 Tagging strategy

Tag	Mutable?	Use
`sha-3f9c2a1`	no	what you deploy; traceable to a commit
`1.4.2`	should not be	releases
`1.4`, `1`	yes	convenience for consumers of public images
`latest`	yes	never in deployment manifests
`@sha256:...` (digest)	immutable by definition	what GitOps should pin; what you sign

Best practice: enable tag immutability in your registry (ECR, GAR, Harbor support it), so 1.4.2 can never silently point to a different image.

10.2 Multi-arch with buildx

docker buildx create --name orbit-builder --use --bootstrap
docker buildx build --platform linux/amd64,linux/arm64 \
  --build-arg SERVICE=orders \
  --cache-from type=registry,ref=ghcr.io/acme/orbit-orders:buildcache \
  --cache-to   type=registry,ref=ghcr.io/acme/orbit-orders:buildcache,mode=max \
  -t ghcr.io/acme/orbit-orders:sha-$(git rev-parse --short HEAD) --push .
docker buildx imagetools inspect ghcr.io/acme/orbit-orders:sha-...   # shows the manifest list

Multi-arch matters because arm64 nodes (AWS Graviton, GCP Axion/Tau T2A, Azure Cobalt) are typically 20–40% cheaper per unit of performance. A multi-arch image lets the scheduler place a pod on either.

The registry cache (--cache-to type=registry) gives ephemeral CI runners a warm cache. It commonly takes a 6-minute build down to under 1 minute.

10.3 Private registry credentials

echo "$GHCR_TOKEN" | docker login ghcr.io -u <user> --password-stdin
# Kubernetes pulls via an imagePullSecret (§16) or, on cloud, node/workload identity (better: no static creds)