Container Registries & Shipping Images

A registry is where built images live between being built and being run - Docker Hub, Amazon ECR, Google Artifact Registry, and plenty of self-hosted options all do the same essential job.

The full loop, start to finish

This lesson is the capstone that ties the whole track together - CI/CD, cloud, and containers all meet right here:

1. Jenkins (or any CI) builds the image from your Dockerfile
2. CI tags it and pushes it to a registry
3. A Kubernetes cluster (running in the cloud) pulls that exact image
4. A Deployment rolls it out across the cluster

Nothing in steps 3-4 rebuilds anything - the cluster runs the literal image CI already built and tested, the same "build once, promote everywhere" principle from the Jenkins deploy lesson.

Tagging conventions

A tag is just a label on an image - myapp:1.4.2, myapp:latest. A few conventions that matter in practice:

• Semantic version tags (1.4.2) - clear, human-readable, easy to roll back to by name.
• Git SHA tags (myapp:a3f9c21) - ties an image to the exact commit it was built from, no ambiguity.
• :latest - deceptively named; it just means "whatever was pushed most recently without an explicit tag," not "the newest stable release." Relying on it in production is a common source of "which version is actually running right now?" confusion.

Pushing and pulling

docker tag myapp:a3f9c21 registry.example.com/myapp:a3f9c21
docker push registry.example.com/myapp:a3f9c21
docker pull registry.example.com/myapp:a3f9c21

A push uploads any layers the registry doesn't already have (the same layer-caching idea from the Docker deep-dive lesson applies here too - most pushes only upload the one or two layers that actually changed).

Try it

docker images

When you're ready, hit Mark complete. You've completed the DevOps track!