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

The problem lies in installing dependencies *before* deploying the application code. Many applications require specific libraries or tools that must be installed before they can function correctly. If Python isn't ready to execute the application, it will crash. The other options represent potential issues but don't directly explain the immediate failure described.

docker image prune -a is a powerful command that removes *all* Docker images that are not currently being used by any running containers or tagged. This includes 'dangling' images (images without tags) and unused layers. It's crucial for freeing up disk space and speeding up builds, but be mindful of accidentally deleting images you still need.

Docker Compose excels at managing multi-container applications. The docker-compose.yml file allows you to define dependencies between services (in this case, the Redis container) and configure their settings in a declarative way, making deployment, scaling, and management significantly easier than running individual Docker commands.

Containerized environments isolate applications. The CI build server, by default, often runs under a user account with limited permissions. This can lead to 'permission denied' errors when the application tries to write files to a directory where that user doesn't have access. It's crucial to ensure the CI build server has appropriate access rights.

The 'image' field in this API response represents a unique identifier assigned by the Docker Engine to the container. It's a hexadecimal string used to track and manage containers based on their image. While the 'my-app:latest' tag is present, that's the *name* of the image, not the ID itself.