Push & Pull Automation

Tagging Strategy

Tags are mutable pointers, so give each one a defined role:

Push by digest after building, then add tags:

DIGEST=$(docker push registry.example.com/app:sha-4f9c2ab | tail -1)
docker tag app:local registry.example.com/app:1.4.2
docker push registry.example.com/app:1.4.2

One image ID can carry many tags; the registry stores the manifest once.

Authenticating Across Registries

Each registry wants its own credential flow:

# Docker Hub
docker login -u $DH_USER

# ECR: token expires in 12 hours
aws ecr get-login-password --region us-east-1 |   docker login --username AWS --password-stdin 123.dkr.ecr.us-east-1.amazonaws.com

# GHCR: GitHub token with write:packages
echo $GITHUB_TOKEN | docker login ghcr.io -u USER --password-stdin

For multi-registry release, push the same manifest to each target rather than rebuilding: docker buildx imagetools create -t reg2/app:1.4.2 reg1/app:1.4.2 copies references without pulling layers. Always use --password-stdin so the token never lands in shell history or process lists.

Lifecycle, Signing, and Pitfalls

Unbounded growth. Every CI push adds manifests; configure an ECR lifecycle policy (keep the last 30 images) or enable GHCR package cleanup so old tags are pruned automatically.

Mutable tags betray rollback. If latest moves while a deploy references it, yesterday's container may restart on today's code — deployments pin digests (app@sha256:...).

Provenance. Sign releases with cosign sign registry.example.com/app:1.4.2 and verify in admission control; an unsigned tag proves nothing about origin.

Interview: explain tag mutability, walk an ECR auth flow including token expiry, and describe how digest pinning makes rollback deterministic.