FAQ — Docker explained: images, containers and volumes

An image is a read-only blueprint — a stack of filesystem layers built from a Dockerfile. A container is a running instance of that image, with its own writable layer. Multiple containers can run from the same image simultaneously, each isolated from the others.

Volumes are Docker-managed directories that persist outside the container's filesystem. Use them for any data that must survive container restarts or replacements: databases, uploaded files, generated assets. Named volumes are preferred over bind mounts in production because they are portable across any host path.

The 'latest' tag does not guarantee you get the same image when you pull again. A new push to the upstream repository silently changes what 'latest' points to, breaking reproducibility. Pin to a specific digest (sha256:…) or a semantic version tag so your deployments are deterministic.

A multi-stage build uses multiple FROM statements in a single Dockerfile. Earlier stages compile or build the application; the final stage copies only the runtime artefacts. This typically reduces image size by 60–80 % and excludes build tools, source code, and credentials from the production image.

Four practices cover most risks: run containers as a non-root user, scan images for known CVEs before pushing (Trivy or Docker Scout), use minimal base images (distroless or Alpine), and never bake secrets into layers — pass them via environment variables or runtime secrets mounts.

ENTRYPOINT sets the executable that always runs; CMD provides default arguments that can be overridden at 'docker run'. Use ENTRYPOINT for the main process and CMD for its default flags. If only CMD is set, the entire command can be replaced by arguments passed at 'docker run'.