Docker · Intermediate interview

A multi-stage build uses multiple FROM stages in one Dockerfile — a build stage with compilers and dev dependencies, and a final stage that copies only the built artifacts. This keeps build tooling out of the runtime image, dramatically shrinking it and reducing attack surface. You get a small, clean production image without a separate build script.

FROM node:20 AS build
WORKDIR /app
COPY . . 
RUN npm ci && npm run build
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

Use a small base (alpine or distroless), multi-stage builds to drop build tooling, combine and clean up in RUN layers (remove caches/apt lists), copy only what you need, and add a .dockerignore to keep junk out of the build context. Fewer and smaller layers mean faster pulls, less storage, and a smaller attack surface.

Order instructions so rarely-changing steps (installing dependencies) come before frequently-changing ones (copying source), so a code change doesn't invalidate the dependency layer. .dockerignore excludes files (node_modules, .git, build output) from the build context, which speeds the build, avoids cache busting from irrelevant changes, and keeps secrets out of the image. Together they make rebuilds fast.

bridge is the default for standalone containers on a host — they get a private network and can talk to each other if on the same user-defined bridge. host removes network isolation so the container shares the host's network stack directly. none disables networking. overlay networks span multiple hosts for Swarm/clustered setups. Most app setups use a user-defined bridge network.

On a user-defined bridge network (which Compose creates automatically), Docker provides DNS so containers can reach each other by service/container name instead of IP — your app connects to db:5432 because 'db' resolves to that container. The default legacy bridge doesn't give name resolution, which is why user-defined networks (or Compose) are recommended.

EXPOSE in a Dockerfile is documentation/metadata that a container listens on a port; it doesn't make it reachable from the host. Publishing with -p (or Compose ports) actually maps a host port to the container port. Containers on the same network can reach each other's exposed ports without publishing; publishing is only needed to reach a container from the host or outside.

Named volumes are Docker-managed storage, portable and ideal for persistent app/database data. Bind mounts map a specific host path into the container — great for live-editing source in dev but tied to the host layout. tmpfs mounts live in memory and vanish on stop, for sensitive or scratch data. You pick based on whether you need managed persistence, host access, or ephemeral memory storage.

Keep stateful data in named volumes rather than the container's writable layer, so removing/recreating the container doesn't lose data. To back up, you run a temporary container that mounts the volume and tars its contents out (or use the database's own dump tools), and restore by reversing it. The principle is that containers are disposable and state lives in volumes you manage and back up.

Inject configuration at run time via environment variables, mounted config files, or Compose env files — never bake environment-specific config into the image. Secrets shouldn't go in the image or plain env if avoidable; use Docker/Swarm secrets, a secrets manager, or mounted files with restricted access, and keep them out of build args and image history. The image stays generic and portable across environments.

A HEALTHCHECK runs a command periodically to report whether the container is healthy, which orchestrators and Compose use to gate traffic or restarts. Restart policies (--restart no/on-failure/always/unless-stopped) tell Docker whether to automatically restart a container that exits, improving resilience. Together they keep a service available and let the platform react to failures.

You cap CPU (--cpus) and memory (--memory) so one container can't starve others or take down the host — important for density and stability. Without limits, a memory leak or runaway process can exhaust the machine. In production these limits map to the orchestrator's resource requests/limits, which also drive scheduling decisions.

Containerized apps should log to stdout/stderr, and Docker captures that via a logging driver (json-file by default, or syslog, fluentd, etc.). In production you ship those logs to a central system (ELK, Loki, a cloud logging service) rather than reading them per-container, and you configure log rotation to stop json-file logs filling the disk. The app stays stateless; logs flow out to the platform.