Docker & Containerization Vocabulary

Docker Dockerfile vocabulary — CMD vs ENTRYPOINT:

CMD
Provides default arguments for the container. Entirely overridden when you pass arguments to docker run:
CMD ["node", "server.js"]
docker run myimage python debug.py → runs python debug.py, ignoring CMD

ENTRYPOINT
Defines the executable. Not overridden by docker run arguments (use --entrypoint to override):
ENTRYPOINT ["node"]
CMD ["server.js"]
docker run myimage debug.js → runs node debug.js (uses ENTRYPOINT + passed argument instead of CMD)

Shell form vs exec form:
• Shell form: CMD node server.js → runs as /bin/sh -c "node server.js"; shell becomes PID 1 (bad for signals)
• Exec form: CMD ["node", "server.js"] → node is PID 1; receives signals directly (SIGTERM for graceful shutdown)

Always use exec form (JSON array) for CMD and ENTRYPOINT!

Other Dockerfile vocabulary:
• FROM — base image
• RUN — executes during build; creates a new layer
• COPY — copies files from build context into the image
• ADD — like COPY but also unpacks archives and fetches URLs; prefer COPY for predictability
• ARG — build-time variable (not in final image); docker build --build-arg KEY=VALUE
• ENV — runtime environment variable (baked into image layer); avoid for secrets
• EXPOSE — documentation only; does not publish ports (use docker run -p)
• WORKDIR — sets working directory for subsequent instructions; creates dir if missing
• VOLUME — declares a mount point; creates anonymous volume at runtime

Docker multi-stage build vocabulary:

Multi-stage builds use multiple FROM statements in one Dockerfile. Each FROM starts a new build stage. You can copy artifacts between stages with COPY --from=stagename.

Go example:

## Stage 1: builder (large — includes Go compiler ~300MB)
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN go build -o server .

## Stage 2: final (tiny — just the binary)
FROM scratch
COPY --from=builder /app/server /server
ENTRYPOINT ["/server"]

Result: the final image contains only the server binary (~10-20 MB), not the 300 MB Go toolchain.

Common base images for final stages:
• scratch — completely empty; the smallest possible; no shell, no OS libraries
• distroless — Google's minimal images; no package manager, no shell; includes libc and CA certs
• alpine — ~5 MB; has a shell and package manager; good for debugging

Node.js example:

FROM node:20 AS deps
RUN npm ci --only=production

FROM node:20-alpine AS final
COPY --from=deps /app/node_modules ./node_modules
COPY src/ ./src
CMD ["node", "src/index.js"]

Named stages and selective builds:
docker build --target builder . — build only up to the named stage (useful for running tests in CI)

Vocabulary:
• stage — a single FROM section in a multi-stage Dockerfile
• builder stage — a stage used to compile or bundle; not part of the final image
• final stage — the last FROM; determines what the final image contains
• distroless — base images with no shell or package manager (improved security surface)

Docker layer caching vocabulary:

A Docker image is a stack of read-only layers. Each Dockerfile instruction that modifies the filesystem creates a new layer.

Cache invalidation rule:
When a layer is invalidated (its inputs changed), ALL subsequent layers are also invalidated and rebuilt.

Anti-pattern (slow builds)::

COPY . .              # copies ALL source — any file change invalidates next layer
RUN npm install       # always reruns — can't use cached node_modules

Optimised pattern (fast builds):

COPY package*.json .  # only copy lock file first
RUN npm install       # cached if package*.json unchanged
COPY . .              # copy source last — frequent changes only rebuild final layer

Result: npm install only reruns when package.json or package-lock.json changes — not on every source code change.

Best practices for cache efficiency:
1. Install dependencies before copying source
2. Pin dependency versions (npm ci instead of npm install)
3. Use .dockerignore to exclude files that shouldn't trigger rebuilds (node_modules, .git, test reports)
4. Combine RUN commands: RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/* (one layer, cleans up)

Cache sources (BuildKit):
RUN --mount=type=cache,target=/root/.npm npm ci — persistent cache mount, survives image layers

Vocabulary:
• layer — one Dockerfile instruction's filesystem delta
• layer cache — Docker's store of layers by content hash
• cache invalidation — when a layer must be rebuilt (its inputs changed)
• .dockerignore — file listing paths excluded from build context (like .gitignore)
• build context — files sent to Docker daemon during build (should be minimised)

Docker volume vocabulary:

Named volume
Created and managed by Docker. Stored in Docker's volume area (typically /var/lib/docker/volumes/ on Linux).

docker run -v my-db-data:/var/lib/postgresql/data postgres
volumes: my-db-data: # named volume in compose file

Lifecycle: survives container stop/restart. Deleted only explicitly (docker volume rm my-db-data or docker compose down -v).

Use for: database data, persistent application state — anything that should outlive the container but doesn't need to be a specific host path.

Bind mount
Maps a specific host directory/file into the container. The data lives on the host at the specified path.

docker run -v /home/user/app:/app node
or Docker Compose: - ./app:/app

The data is at the host path regardless of Docker.
Use for: development (mount source code so changes are instant), configuration files, secrets injected from the host.

tmpfs mount
In-memory filesystem — not persisted anywhere. Use for sensitive data that must not touch disk.

docker compose down -v:
-v deletes all named volumes defined in the compose file. Data loss risk! Remove it to preserve database volumes:
docker compose down (no -v) — stops containers, removes network, keeps volumes.

Vocabulary:
• volume — Docker-managed persistent storage
• bind mount — host path mapped into container
• anonymous volume — created by VOLUME Dockerfile instruction; no name; harder to manage
• docker volume ls / inspect / rm — volume management commands
• volume driver — plugins for remote storage (NFS, AWS EBS, etc.)

Docker image tagging and digest vocabulary:

Tag
A mutable human-readable pointer to an image version (e.g., node:20, node:latest, my-app:v1.2.3).
A tag can be updated (re-pushed) to point to a different image at any time by the publisher.

The latest tag problem:
• latest does not mean "the most recent version" automatically — it is just whatever tag the publisher chose to call latest most recently
• Different team members pulling FROM node:latest at different times may get different Node.js versions
• "It works on my machine" → different base image pulled in CI
• Supply chain attack vector: a malicious actor who compromises a registry account can push a new image to :latest

Best practice: pin specific version tags
FROM node:20.11.0-alpine3.19 instead of FROM node:latest

Image digest — immutable content hash
A SHA-256 hash of the exact image manifest. Cannot be changed — a different image = a different digest.
FROM node@sha256:a1b2c3d4... — guarantees byte-for-byte identical image on every pull

Viewing a digest:
docker pull node:20 --platform linux/amd64
docker inspect node:20 | grep Id
docker images --digests

Image signing (Notation, Cosign):
Tools like Sigstore Cosign sign image digests so consumers can verify the image was published by the expected organisation.

SBOM (Software Bill of Materials):
A manifest of all packages and dependencies in an image — generated with docker sbom or Syft. Required by many compliance frameworks (SLSA, SSDF).

Vocabulary:
• tag — mutable label pointing to an image version
• digest — immutable SHA-256 hash of an image manifest
• pin — lock to a specific version or digest
• image manifest — JSON document describing image layers and metadata
• multi-arch image — one tag covering multiple CPU architectures (linux/amd64, linux/arm64)
• image signing — cryptographic proof of publisher identity (Cosign, Notation)
• SBOM — inventory of all software components in an image