Docker Fundamentals

Overview

Docker packages an application together with everything it needs to run - a base OS layer, a runtime, dependencies, and the app itself - into a single, portable image. Running that image starts a container: an isolated process with its own filesystem view, network namespace, and process tree, sharing the host's kernel rather than virtualizing an entire OS the way a VM does. That's the core mental shift for anyone coming from "installing software": you don't configure a machine to run your app, you build an image once and run it, identically, on a laptop, a CI runner, or a production host. Everything else - volumes for persistent data, networks for container-to-container communication, Compose for running several containers as one unit - exists to manage the boundary between that disposable, reproducible container and the stateful, connected world around it.

Quick Reference

The commands below are grouped the way you'd reach for them day to day, not an exhaustive CLI reference (see the official Docker CLI reference for every flag), but the ones that cover almost all daily Docker work.

Syntax

FROM node:20-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

# compose.yaml
services:
  api:
    build: .
    ports:
      - '3000:3000'
    environment:
      DATABASE_URL: postgres://db:5432/app
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data
volumes:
  db-data:

Examples

docker build -t app:1.0 .
docker run -d -p 3000:3000 --name app app:1.0
docker logs -f app

docker exec -it app sh

Visual Diagram

Common Mistakes

• Writing data a container needs to keep into its own writable layer instead of a volume or bind mount; it's gone the moment docker rm runs.
• Confusing EXPOSE in a Dockerfile with actually publishing a port; EXPOSE only documents intent, -p host:container on docker run is what makes a port reachable from outside.
• Running containers as the default root user in production images, which turns a container escape into a host-level root compromise.
• Tagging every build latest and deploying that tag, so "which version is actually running" becomes unanswerable - pin explicit version tags instead.
• Running docker system prune -a on a shared host without checking what's still in use; it deletes any image not backing a currently running container.

Performance

• Docker layers a Dockerfile top to bottom and caches each layer; ordering rarely-changing steps (installing dependencies) before frequently-changing ones (copying source code) means most rebuilds only re-run the last few layers.
• Multi-stage builds (FROM ... AS build, then a second FROM that copies only the compiled output) keep the final image small by discarding build-time tooling that isn't needed at runtime.
• Smaller base images (alpine, distroless) reduce image pull time and attack surface, but can lack libraries (like glibc) that some binaries assume are present - worth checking before committing to one.
• Unbounded containers can starve a host of memory or CPU; --memory and --cpus on docker run (or deploy.resources.limits in Compose) cap what a single container can consume.

Best Practices

• Use multi-stage builds and a .dockerignore file so build context and final images only contain what's actually needed at runtime.
• Pin base image and dependency versions explicitly; never rely on a moving latest tag for anything beyond local experimentation.
• Run as a non-root user inside the container (USER node, or an equivalent line for your base image) unless there's a specific reason not to.
• Keep one primary process per container; if two unrelated services need to scale or fail independently, they belong in two containers, not one with a supervisor process.
• Reach for volumes (not bind mounts) for data a container owns and manages itself, and bind mounts mainly for local development, where you want host file changes to show up instantly.