Docker · Beginner interview

Docker packages an app and its dependencies into a container that runs consistently anywhere. Containers share the host OS kernel and isolate at the process level, so they're lightweight, start in milliseconds, and use less resource. VMs virtualize hardware and run a full guest OS each, making them heavier and slower to start. Containers trade the stronger isolation of VMs for efficiency and density.

An image is a read-only template — the packaged filesystem and metadata for how to run an app. A container is a running (or stopped) instance of an image, with a thin writable layer on top. One image can spawn many containers, like a class and its objects. You build images and run containers.

A registry is a store for Docker images that you push to and pull from, so images can be shared and deployed across machines. Docker Hub is the default public registry; teams also use private registries (ECR, GCR, GitHub Container Registry). Images are referenced by name and tag, e.g. node:20-alpine.

A Dockerfile is a script of instructions to build an image. Common ones: FROM (base image), WORKDIR (set directory), COPY/ADD (bring files in), RUN (execute build commands like installing deps), ENV (environment variables), EXPOSE (document a port), and CMD/ENTRYPOINT (what runs when the container starts). Each instruction is a step in producing the final image.

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]

Each Dockerfile instruction creates a layer, and Docker caches them — on rebuild, it reuses cached layers until it hits one that changed, then rebuilds from there. That's why you copy package files and install dependencies before copying the rest of your source: dependencies only re-install when the manifest changes, not on every code edit. Ordering instructions from least- to most-frequently-changing maximizes cache hits.

ENTRYPOINT defines the executable that always runs; CMD provides default arguments (or a default command) that are easy to override at run time. If both are set, CMD's values become arguments to ENTRYPOINT. Use ENTRYPOINT for the fixed program and CMD for default flags, so docker run image arg overrides the arguments cleanly.

-p maps a host port to a container port (host:container); -v mounts a volume or host path for persistence; -e sets an environment variable; -d runs detached in the background; --name gives the container a name; --rm removes it on exit. So docker run -d -p 8080:80 nginx runs nginx in the background reachable on host port 8080.

Container filesystems are ephemeral — data is lost when the container is removed. You persist with volumes (Docker-managed storage that survives container removal) or bind mounts (mapping a host directory in). Named volumes are preferred for databases and app data because Docker manages them and they're portable; bind mounts are handy for live-editing source in development.

By default a container's ports aren't reachable from the host. Publishing with -p host:container forwards traffic from the host port to the container's port, so -p 3000:3000 lets you hit localhost:3000. EXPOSE in a Dockerfile only documents the port; it's -p (or Compose's ports) that actually publishes it.

Compose defines and runs multi-container applications from a single YAML file — services, networks, and volumes — so docker compose up starts your whole stack (app, database, cache) together with one command. It's ideal for local development and simple deployments where you have several containers that need to talk to each other, replacing long manual docker run commands.

services:
  web:
    build: .
    ports: ["3000:3000"]
  db:
    image: postgres:16

You set them with -e on docker run, an env_file or environment block in Compose, or a .env file Compose reads automatically. Config files can be bind-mounted in. The key practice is keeping configuration and secrets out of the image so the same image runs in any environment with different settings injected at run time.

docker logs <container> shows its stdout/stderr (add -f to follow), which is where containerized apps should write logs. docker exec -it <container> sh (or bash) opens an interactive shell inside the running container to inspect or debug it. These two commands cover most day-to-day troubleshooting.