Docker

01Images, containers and how they differ from VMs

An image is a read-only template: a filesystem snapshot plus metadata such as which command to run. A container is a running instance of an image, with a thin writable layer on top. Think of the image as a recipe card and the container as the dish you cooked from it; you can cook many dishes from one card. A virtual machine emulates a whole computer with its own kernel, so it boots an entire operating system and usually takes gigabytes and tens of seconds. A container is just a normal Linux process that the kernel isolates with namespaces (what it can see: files, network, process list) and limits with cgroups (how much CPU and memory it can use). It shares the host kernel, so it starts in milliseconds and adds little overhead. The trade-off: isolation is weaker than a VM, which is why clouds often run containers inside VMs.

• Image = immutable template, identified by name:tag and a content digest.
• Container = image + writable layer + an isolated process.
• Containers share the host kernel; VMs bring their own.

02Layers and build caching

Every instruction in a Dockerfile (FROM, COPY, RUN) creates a layer, and an image is a stack of layers merged by an overlay filesystem. Layers are cached by content: if an instruction and everything before it are unchanged, Docker reuses the cached layer instead of running it again. The moment one layer changes, every layer after it is rebuilt. That rule decides how fast your builds are. Copy the dependency manifest first (package.json and the lockfile, or composer.json and composer.lock), install dependencies, and only then copy the rest of the source. Now editing a component does not trigger a full npm install. A .dockerignore file keeps node_modules, .git, logs and .env files out of the build context, which makes builds faster and stops secrets leaking into images.

1# .dockerignore
2node_modules
3.next
4.git
5*.log
6.env*
7Dockerfile
8compose*.yaml

03A production Dockerfile: multi-stage, small, non-root

A multi-stage build uses one stage with compilers and dev dependencies to build the app, then copies only the result into a clean, small runtime stage. The final image has no source maps you did not intend, no build tools and far fewer packages to patch. Use slim or Alpine base images and pin a major version rather than latest. Run as an unprivileged user: if someone exploits the app, they land as a normal user, not root. The example below builds a Next.js app with output: "standalone" set in next.config, which produces a minimal server.js plus only the node_modules it needs. The same pattern works for Laravel: a Composer stage, a Node stage for assets, and a final PHP-FPM stage.

1FROM node:24-alpine AS deps
2WORKDIR /app
3COPY package.json package-lock.json ./
4RUN npm ci
5 
6FROM node:24-alpine AS build
7WORKDIR /app
8COPY --from=deps /app/node_modules ./node_modules
9COPY . .
10RUN npm run build
11 
12FROM node:24-alpine AS run
13WORKDIR /app
14ENV NODE_ENV=production
15COPY --from=build --chown=node:node /app/.next/standalone ./
16COPY --from=build --chown=node:node /app/.next/static ./.next/static
17COPY --from=build --chown=node:node /app/public ./public
18USER node
19CMD ["node", "server.js"]

04Volumes and networks

A container's writable layer disappears when the container is removed, so anything you want to keep (database files, uploads) must live in a volume. Named volumes are managed by Docker and are the right choice for databases. Bind mounts map a host folder into the container and are ideal in development, when you want code changes to appear instantly. On the network side, containers on the same user-defined network find each other by service name through Docker's built-in DNS: the app connects to db:5432, not localhost. Inside a container, localhost means that container itself, which is the most common beginner confusion. Only publish ports that the outside world truly needs, usually just 80 and 443 on the reverse proxy.

• Named volume: persistent data owned by Docker (databases).
• Bind mount: a host folder, great for live code in development.
• Published ports skip ufw rules on many setups; bind private ports to 127.0.0.1 or do not publish them at all.

05Docker Compose for a full application

Compose describes several containers, their networks and volumes in one compose.yaml, and docker compose up -d starts everything. Below is a typical web app: nginx in front as the only public entry point, the app container, a queue worker built from the same image with a different command, PostgreSQL with a persistent volume and a health check, and Redis for cache and queues. depends_on with condition: service_healthy makes the app wait until the database actually accepts connections, not merely until its container has started. Note that the database and Redis publish no ports at all; only nginx is reachable from outside. Secrets come from an env file that is not committed to Git.

1services:
2  nginx:
3    image: nginx:stable-alpine
4    ports: ["80:80", "443:443"]
5    depends_on: [app]
6  app:
7    build: .
8    env_file: .env
9    depends_on:
10      db: { condition: service_healthy }
11  worker:
12    build: .
13    command: php artisan queue:work --tries=3
14  db:
15    image: postgres:17
16    volumes: [db-data:/var/lib/postgresql/data]
17    healthcheck: { test: ["CMD", "pg_isready", "-U", "postgres"], interval: 5s }
18  redis:
19    image: redis:7-alpine
20volumes: { db-data: {} }

06Development vs production Compose

Development and production want different things. In development you want bind-mounted source code, hot reload, debug tools and maybe a mail catcher. In production you want built images with the code baked in, restart: unless-stopped, resource limits, log rotation, TLS and monitoring. Do not maintain two divergent files. Keep a base compose.yaml with what is shared, and layer override files on top: compose.override.yaml is loaded automatically in development, while production is started explicitly with the base plus a production file. You can add more layers, such as a TLS file or an observability file that adds Prometheus, Grafana and Loki. Validate the merged result with docker compose config before deploying.

1# development: compose.yaml + compose.override.yaml (auto-loaded)
2docker compose up -d
3 
4# production: explicit files, no override
5docker compose -f compose.yaml -f compose.prod.yaml config --quiet
6docker compose -f compose.yaml -f compose.prod.yaml up -d --build
7 
8# useful day to day
9docker compose ps
10docker compose logs -f --tail=100 app
11docker compose exec app sh

07What a container really is: the runtime chain and PID 1

When you type docker run, the CLI talks to the Docker daemon (dockerd), which hands the job to containerd, which uses a low-level OCI runtime, usually runc, to create the process. runc asks the kernel for new namespaces, attaches the process to a cgroup, mounts the image layers through overlayfs, and then gets out of the way. The image and runtime formats are open OCI standards, which is why Podman, Kubernetes and Docker can all run the same image. One detail bites people in production: the first process in a container is PID 1. The kernel gives PID 1 no default signal handlers, so a process that never installed a SIGTERM handler simply ignores it, and PID 1 is also expected to reap zombie child processes. A tiny init such as tini, enabled in Compose with init: true, forwards signals and reaps zombies for you.

1services:
2  app:
3    image: registry.example.com/app:1.8.0
4    init: true               # tini as PID 1: forwards signals, reaps zombies
5    stop_grace_period: 30s   # time between SIGTERM and SIGKILL (default 10s)
6    stop_signal: SIGTERM

08Hardening a container at runtime

A non-root user is the first step, not the last. By default a container still gets a set of Linux capabilities, a writable root filesystem and the ability to gain privileges through setuid binaries. Drop all capabilities and add back only what is needed (a web server binding to port 80 needs NET_BIND_SERVICE; most Node and PHP apps behind a proxy need nothing). Make the root filesystem read-only and give the app a small tmpfs for scratch files, so an attacker cannot drop tools onto disk. Set no-new-privileges so setuid tricks fail. Docker's default seccomp profile already blocks dozens of dangerous system calls; never disable it with seccomp=unconfined. Above all, never mount /var/run/docker.sock into an app container: access to the socket is equivalent to root on the host. For an extra layer, rootless mode runs the daemon itself as a normal user.

1services:
2  app:
3    user: "1000:1000"
4    read_only: true
5    tmpfs: [/tmp]
6    cap_drop: [ALL]
7    security_opt: ["no-new-privileges:true"]
8    deploy:
9      resources:
10        limits: { cpus: "1.0", memory: 512M }
11    pids_limit: 200

09Docker, iptables and the firewall surprise

When you publish a port with ports: "5432:5432", Docker writes NAT rules into iptables so that traffic to the host's port is forwarded to the container. Those rules are evaluated in the PREROUTING and FORWARD paths, before the INPUT chain where ufw keeps its rules. The result: ufw status says port 5432 is denied, yet the database answers from the internet. There are three safe answers. Do not publish internal services at all; containers on the same network do not need it. If a host tool must reach a container, bind to loopback with 127.0.0.1:5432:5432. If you really must filter published ports, put your rules in the DOCKER-USER chain, which Docker evaluates before its own rules and never overwrites. After any change, verify from outside with a port scan rather than trusting the firewall's own report.

1services:
2  db:
3    image: postgres:17
4    # reachable only from the host itself, never from the internet
5    ports: ["127.0.0.1:5432:5432"]
6  redis:
7    image: redis:7-alpine
8    # no ports at all: only containers on the same network can connect
9 
10# from another machine: nmap -Pn -p 5432,6379 203.0.113.10

10Faster and safer builds with BuildKit

BuildKit, the default builder in current Docker, adds features that plain layer caching cannot. A cache mount keeps the package manager's download cache between builds without putting it into any layer, so a lockfile change re-installs from a warm cache instead of the network. A secret mount exposes a token (for a private npm registry or Composer auth) to a single RUN step; it never appears in the image history, unlike ARG or ENV values, which anyone can read with docker history. In CI, runners start empty, so export the cache to your registry and import it on the next run. For reproducibility, pin base images by digest as well as tag, and let automation such as Renovate or Dependabot open pull requests when the digest changes. BuildKit can also attach an SBOM and provenance attestation, which security scanners and auditors increasingly expect.

1# syntax=docker/dockerfile:1
2FROM node:24-alpine AS deps
3WORKDIR /app
4COPY package.json package-lock.json ./
5RUN --mount=type=cache,target=/root/.npm \
6    --mount=type=secret,id=npmrc,target=/root/.npmrc \
7    npm ci
8 
9# build: docker build --secret id=npmrc,src=$HOME/.npmrc .
10# CI:    docker buildx build --cache-from type=registry,ref=registry.example.com/app:cache \
11#          --cache-to type=registry,ref=registry.example.com/app:cache,mode=max --push .