Docker — Advanced Questions and Answers

1. What are multi-stage builds and why do they matter?

A multi-stage build uses several FROM blocks in one Dockerfile: heavy "builder" stages compile and produce artifacts, and a lightweight final stage copies only the artifacts. Build tools, compilers, caches, and test dependencies never reach the shipped image — making it smaller and reducing the attack surface.

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

# ---- Stage 2: runtime ----
FROM node:20-slim
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
EXPOSE 3000
USER node
CMD ["node", "dist/server.js"]

Notes:

• COPY --from=build pulls files from a previous stage instead of the build context.
• Build only one stage with docker build --target build . (useful for CI test stages).
• Same pattern for compiled languages (Go, Rust, Java with jlink) — final images of tens of MB instead of hundreds.

2. How do I analyze and shrink an image?

docker image ls                          # sizes at a glance
docker history my-api:1.0                # size contributed by each layer
docker buildx build --sbom=true .        # SBOM (with BuildKit)
# interactive layer-by-layer exploration:
# dive my-api:1.0   (github.com/wagoodman/dive)

Shrinking techniques, in order of impact:

• Multi-stage builds (see above).
• Smaller base: -slim, -alpine, distroless, or FROM scratch for static binaries.
• Install and clean in the same RUN: apt-get update && apt-get install -y --no-install-recommends ... && rm -rf /var/lib/apt/lists/*; pip install --no-cache-dir.
• A proper .dockerignore so tests, docs, and .git never enter the context.
• Only COPY what the app needs to run — not the whole repository.

3. How do I scan images for vulnerabilities?

Treat images as dependencies: scan them continuously in CI and on schedule.

docker scout cves my-api:1.0        # Docker Scout (built into Docker Desktop)
trivy image my-api:1.0              # Trivy — very common in CI pipelines
grype my-api:1.0                    # Grype (Anchore)

• Fail the build on High/Critical findings with a fix available; triage the rest explicitly.
• Pin base images by digest for reproducibility: FROM node:20-slim@sha256:abcd....
• Rebuild regularly — a "clean" image ages badly as new CVEs are disclosed.
• Prefer official/verified images and minimal bases: fewer packages, fewer CVEs.

4. How do I run containers securely (least privilege)?

• Non-root user: RUN useradd -r app && USER app in the Dockerfile, or docker run --user 1000:1000. Containers running as root can escape more easily on kernel vulnerabilities.
• Read-only root filesystem: docker run --read-only --tmpfs /tmp ... — the app can only write to explicitly mounted volumes.
• Drop capabilities: --cap-drop=ALL --cap-add=NET_BIND_SERVICE — grant back only what is needed (e.g., binding port 80).
• No privilege escalation: --security-opt no-new-privileges.
• Rootless Docker/Podman — the whole daemon runs unprivileged, so a daemon compromise does not mean host root.
• Never mount /var/run/docker.sock into a container unless it is a trusted CI tool — it is effectively root on the host.
• Hardened runtimes (seccomp/AppArmor profiles) for hostile workloads.

5. How should I handle secrets?

Rules of thumb: never COPY secrets into images, never put them in ENV/ARG (they persist in image metadata and docker history), and never commit them. Options:

# Build-time secret via BuildKit — never stored in a layer:
# syntax=docker/dockerfile:1
RUN --mount=type=secret,id=npm_token \
    NPM_TOKEN=$(cat /run/secrets/npm_token) npm ci
# docker build --secret id=npm_token,src=.npmrc .

• Runtime: environment variables from a secret store, mounted files (_FILE convention), Docker Swarm secrets, Kubernetes Secrets (ideally with encryption/external backing), or a vault (Vault, AWS Secrets Manager, Azure Key Vault).
• Rotatable secrets favor files mounted at runtime over env vars, since env vars live for the process lifetime.

6. How do private registries work?

# Self-hosted registry (with basic auth via reverse proxy or htpasswd):
docker run -d -p 5000:5000 --restart always --name registry registry:2

# Cloud registries: AWS ECR, Azure ACR, Google GAR/Artifact Registry
docker login myregistry.corp.com
docker tag my-api:1.0 myregistry.corp.com/team/my-api:1.0
docker push myregistry.corp.com/team/my-api:1.0

• CI/CD machines authenticate with short-lived tokens/OIDC, not personal logins.
• Set retention/immutable-tag policies; use a pull-through cache to proxy Docker Hub (also mitigates Docker Hub rate limits).
• By digest pinning + signature/attestation (cosign) for supply-chain integrity.

7. How does Docker fit into a CI/CD pipeline?

A typical pipeline per commit: build → test (inside containers) → scan → push → deploy.

# GitHub Actions example
- name: Set up Buildx
  uses: docker/setup-buildx-action@v3
- name: Login to registry
  uses: docker/login-action@v3
  with:
    registry: ghcr.io
    username: ${{ github.actor }}
    password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: |
      ghcr.io/org/app:${{ github.sha }}
      ghcr.io/org/app:latest
    cache-from: type=registry,ref=ghcr.io/org/app:cache
    cache-to: type=registry,ref=ghcr.io/org/app:cache,mode=max

• Tagging strategy: immutable tags per commit (git SHA) deployed in production; semantic versions for releases; avoid relying on latest for deployments.
• Layer caching in CI: export/import BuildKit cache to a registry (as above) so builds stay fast.
• Tests run in ephemeral containers with throwaway service databases — identical to production runtime.

8. When do I need orchestration — and which one?

Docker alone manages a single host. You need an orchestrator when you require multi-host scheduling, self-healing, load balancing, rolling deployments, and scaling:

Option	Best for	Notes
Docker Swarm	Small clusters, simplicity	Built into Docker; declining adoption
Kubernetes	The de-facto standard at any serious scale	Steep learning curve, huge ecosystem
Managed services	AWS/Azure workloads without cluster ops	ECS/EKS/Fargate on AWS, AKS on Azure, GKE on GCP

Related pages in this knowledge base:

• AWS ECS (Elastic Container Service)
• AWS EKS (Elastic Kubernetes Service)
• Azure Kubernetes Service (AKS)

9. What exists beyond Docker? (OCI, containerd, Podman)

Images and runtimes are standardized by the Open Container Initiative (OCI): an image spec and a runtime spec. Consequences:

• containerd — the runtime Docker itself uses underneath; also runs standalone (and inside Kubernetes via CRI).
• Podman — daemonless, rootless-by-default Docker CLI replacement; images are OCI-compatible, so docker build output runs unchanged (alias docker=podman).
• CRI-O — Kubernetes-focused lightweight runtime.
• Practical takeaway: an OCI image is portable across all compliant runtimes — Docker is the most common tool, not a lock-in.

10. Production-readiness checklist for a containerized service

1. Runs as a non-root user; read-only root filesystem where possible.
2. Minimal, version-pinned base image (multi-stage if building), scanned with no open Critical/High CVEs.
3. HEALTHCHECK / readiness endpoint implemented.
4. Handles SIGTERM gracefully (drain connections; docker stop grace period / stop_grace_period tuned).
5. Logs to stdout/stderr; logs and metrics collected externally.
6. Resource limits (--memory, --cpus) and a restart policy set.
7. State in volumes or external services only — never in the container layer.
8. Config via environment/secrets, never baked in; secrets rotated, not in image metadata.
9. Deployed by immutable tag (commit SHA or semver), never latest.
10. Defined upgrade path: image rebuild cadence to pick up base-image patches.

← Back to IT Knowledge Base