Week 5: Container Registries & Image Scanning

1. Tagging Conventions & Registries

An image name is really [registry-host/]repository:tag. Leave the registry host off and Docker assumes Docker Hub; leave the tag off and Docker assumes :latest. Neither default is something you want to rely on in a real pipeline — :latest tells you nothing about which commit produced the image, and omitting the registry host silently points you at the wrong place once you start using more than one registry.

docker.io/adalovelace/orders-api:1.4.2      # Docker Hub, explicit
123456789012.dkr.ecr.us-east-1.amazonaws.com/orders-api:1.4.2  # AWS ECR
ghcr.io/adalovelace/orders-api:1.4.2        # GitHub Container Registry

A common, durable tagging scheme combines a build identifier with a mutable "floating" tag so both precision and convenience are available:

# Tag the same built image twice: once immutable, once floating
docker build -t orders-api:git-a1b2c3d .
docker tag orders-api:git-a1b2c3d orders-api:latest

# Or bake the git SHA in directly from CI
docker build -t orders-api:$(git rev-parse --short HEAD) .

Docker Hub is the default public registry and the simplest place to start — free public repositories, one private repository on the free tier. AWS ECR (Elastic Container Registry) is what you'll actually deploy from once your workloads run on AWS starting Week 8: it's private by default, integrates with IAM for access control instead of a separate login, and keeps images in the same region as the ECS or EKS workloads that pull them, which avoids cross-region transfer time and cost. Most real projects use both — Docker Hub or GHCR for anything public, ECR for anything that runs in production.

2. Authenticating & Pushing/Pulling Images

Pushing to Docker Hub uses a personal access token instead of your account password — Docker Hub deprecated password-based CLI login for exactly the reason you'd expect: a token can be scoped and revoked without touching the account itself.

# Generate a token at hub.docker.com > Account Settings > Security first
docker login -u adalovelace
Password: <paste access token, not your account password>

docker tag orders-api:1.4.2 adalovelace/orders-api:1.4.2
docker push adalovelace/orders-api:1.4.2
docker pull adalovelace/orders-api:1.4.2

ECR authentication works differently: there's no long-lived password at all. The AWS CLI mints a short-lived authorization token (valid 12 hours) that you pipe straight into docker login, which is the same mechanism your CI runner will use in Week 6 instead of storing a registry password as a secret.

# Create the repository once
aws ecr create-repository --repository-name orders-api --region us-east-1

# Authenticate Docker against ECR using a short-lived token
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin \
    123456789012.dkr.ecr.us-east-1.amazonaws.com

# Tag with the full ECR repository URI and push
docker tag orders-api:1.4.2 \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/orders-api:1.4.2
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/orders-api:1.4.2

docker login writes credentials to ~/.docker/config.json — on a shared or CI machine, prefer a credential helper (docker-credential-ecr-login for ECR) over letting a plaintext token sit in that file longer than the current session needs it.

3. Image Vulnerability Scanning

Every base image bundles an operating system's worth of packages, and those packages accumulate published CVEs (Common Vulnerabilities and Exposures) over time. Scanning turns "we hope our base image is fine" into a specific, actionable list of known issues, ranked by severity, before that image ever reaches production. Two tools cover almost every workflow you'll meet: Docker Scout, built into the Docker CLI, and Trivy, an open-source scanner from Aqua Security that's easy to drop into any CI pipeline.

docker scout quickview orders-api:1.4.2
docker scout cves orders-api:1.4.2

# Compare against the currently deployed tag to see what a rebuild would fix
docker scout compare orders-api:1.4.2 --to orders-api:1.4.1

# Install: https://aquasecurity.github.io/trivy — or run via the Trivy image itself
trivy image orders-api:1.4.2

# Fail the command (useful as a CI gate) only on HIGH/CRITICAL findings
trivy image --severity HIGH,CRITICAL --exit-code 1 orders-api:1.4.2

# Scan the Dockerfile itself for misconfigurations, separately from the built image
trivy config .

A scan report lists each vulnerable package, its installed version, the fixed version (if one exists), and a severity rating. Most findings resolve by rebuilding against a newer base image tag rather than patching packages by hand — which is why scanning a stale image weekly, not just at build time, matters: the code hasn't changed, but new CVEs get published against the packages already baked into it every day it sits in the registry.

4. Keeping Image Size Down

A smaller image pulls faster, scans faster, and carries a smaller attack surface — fewer installed packages means fewer possible CVEs. Three habits get you most of the way there, and you already met two of them building your Dockerfile in Week 3.

# Stage 1: build with full tooling
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: ship only the runtime, on a slim base
FROM node:20-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
CMD ["node", "dist/server.js"]

node:20 carries a full Debian userland and build toolchain — fine for compiling, wasteful for running. node:20-slim (or -alpine for an even smaller, musl-based image) strips that down to roughly a tenth of the size. The multi-stage build lets stage 1 use the fat image for compiling while only stage 2's output — the slim image plus your built artifacts — actually gets pushed.

The third habit is a .dockerignore file, which keeps the build context — everything sent to the Docker daemon before a build even starts — from including files that bloat layers or leak secrets into the image:

node_modules
.git
.env
*.log
dist
coverage
Dockerfile
.dockerignore

Check the real impact with docker images, and confirm a build didn't silently regress with docker history, which prints the size each instruction in the Dockerfile added:

docker images orders-api
docker history orders-api:1.4.2

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.