Run a mock round

Attack the layers, base image, and build context.

• Use a minimal base: alpine, distroless, or scratch for static binaries.
• Use multi-stage builds: compile in one stage and copy only artefacts.
• Combine RUN commands and clear package caches in the same layer:

RUN apt-get update && apt-get install -y --no-install-recommends curl \
  && rm -rf /var/lib/apt/lists/*

• Add a .dockerignore to exclude .git, node_modules, and build output from the context.
• Remove dev dependencies in the final stage, for example npm ci --omit=dev or pip install --no-cache-dir.
• Copy only the files the runtime needs.
• Inspect with docker image history or the dive tool to find the largest layers.

docker images app:1.0
docker history app:1.0

Smaller images pull faster, start faster, and expose fewer vulnerabilities.

A multi-stage build uses several FROM stages in one Dockerfile. You can compile in an early stage and copy only the artefacts into a minimal final stage.

FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server .

FROM gcr.io/distroless/static
COPY --from=build /app/server /server
ENTRYPOINT ["/server"]

Benefits:

• Much smaller final images because build tools, compilers, and source are not shipped.
• A smaller attack surface and fewer CVEs.
• Faster pulls and less registry storage.
• Cleaner separation of build and runtime concerns.

Each stage can be targeted for debugging with --target. Use distroless or alpine base images for the runtime stage, and pin versions for reproducible builds.

Both persist data outside the container's writable layer, but they are managed differently.

• Volumes are stored in a Docker-managed location under /var/lib/docker/volumes. Docker creates and manages them, they work identically on any host, and they are the recommended way to persist data. Volumes support drivers for remote or cloud storage.
• Bind mounts map an arbitrary host path into the container. They depend on the host filesystem layout, are great for development such as mounting source code, and can modify host files.

docker volume create appdata
docker run -d -v appdata:/var/lib/postgresql/data postgres
docker run -d -v "$(pwd)/src:/app/src" node:20

Use volumes for databases and production state, and bind mounts for local development and configuration. tmpfs mounts keep data in memory for sensitive scratch data.

A Docker image is a stack of read-only layers. Each Dockerfile instruction creates a layer, and layers are shared between images and cached.

Build cache:

• Docker checks each instruction in order. If the instruction and its inputs, such as copied files or the base image, are unchanged, it reuses the cached layer.
• The first changed instruction invalidates that layer and all following layers.

COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

Copy dependency manifests and install dependencies before copying source so those layers stay cached when only code changes. Combine related RUN commands and clean caches in the same layer. Use a .dockerignore to avoid sending large or changing files that bust the cache. Multi-stage builds reuse layers across stages and keep the final image lean.

Docker creates network namespaces and connects containers using drivers.

• bridge (default): containers get private IPs on a virtual bridge. Same-network containers resolve each other by name, and external access needs port publishing. User-defined bridges provide automatic DNS.
• host: the container shares the host network stack, so there is no isolation and no port mapping. Best performance, but port conflicts are possible.
• none: no networking except loopback.
• overlay: spans multiple Docker hosts for Swarm services.
• macvlan: assigns a MAC address so containers appear as physical devices on the LAN.

docker network create app-net
docker run -d --network app-net --name api api:1.0
docker run -d --network app-net --name web web:1.0

Prefer user-defined bridge networks over the default bridge for service discovery, and use host mode only when you need raw performance or non-HTTP protocols.

An image is a read-only template; a container is a running instance of that image.

• Image: built from a Dockerfile, composed of immutable layers, and stored in a registry. It contains the filesystem and metadata such as entrypoint, environment, and exposed ports.
• Container: an image plus a writable layer and runtime state, including processes, network, and mounts. You can run many containers from one image.

docker build -t web:1.0 .
docker run -d -p 8080:80 --name web web:1.0
docker ps

Think of the image as a class and the container as an object. Changes made inside a container's writable layer are lost when it is removed unless you use a volume. Rebuild and version images rather than editing running containers, and keep images small for faster pulls.

Both define what runs when a container starts, but they behave differently.

• ENTRYPOINT sets the executable. It is hard to override and defines the container's purpose.
• CMD provides default arguments to ENTRYPOINT, or a default command if no ENTRYPOINT exists. It is easily overridden by arguments passed to docker run.

ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8080"]

Running docker run image --port 9000 replaces the CMD arguments but keeps the ENTRYPOINT. Use the exec form, the JSON array, so signals such as SIGTERM reach your process directly, which matters for graceful shutdown. Avoid the shell form because it wraps the command in /bin/sh -c and can swallow signals. Combine both for a sensible default that users can still customise.