Caching. If an instruction and its inputs have not changed, Docker reuses the existing layer instead of re-running it. This is why build order matters enormously.
Sharing. Ten images built FROM node:22-alpine store that base once. Pulling the tenth downloads only its unique layers.
The trap: layers are append-only. A file added in one layer and deleted in a later one is still present in the earlier layer, and anyone with the image can extract it.
Order instructions from least likely to change to most likely:
Ordered for caching
FROM node:22-alpine
WORKDIR /app
# Changes rarely → stays cached across every source edit
COPY package*.json ./
RUN npm ci --omit=dev
# Changes constantly → put it last
COPY . .
CMD ["node", "server.js"]
Compile with a full toolchain, then copy only the result into a clean image:
Multi-stage: compilers never reach production
# ---- stage 1: build (has the full toolchain) ----
FROM node:22 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# ---- stage 2: runtime (only what is needed to run) ----
FROM node:22-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
CMD ["node", "dist/server.js"]
Nothing from stage 1 exists in the final image — no compilers, no build caches, no dev dependencies. Typically a 5–10× size reduction, and a much smaller attack surface.
# Pin exactly, by digest — the same bytes forever
docker pull myapp@sha256:abc123...
# Find the digest of what you have
docker inspect --format='{{index .RepoDigests 0}}' myapp:1.4.2
An image name is really registry/namespace/name:tag. When the registry is omitted, Docker assumes Docker Hub — which is why nginx works and why hitting Docker Hub's anonymous rate limit in CI is so common. Authenticate, or use a mirror.
docker images # sizes
docker history myapp:1.4.2 # SIZE PER LAYER — find the fat one
docker image inspect myapp:1.4.2
# What is actually inside? A shell in a throwaway container.
docker run --rm -it --entrypoint sh myapp:1.4.2
docker system df # what is using disk
docker builder prune # clear the build cache
docker system prune -a # remove unused images too
docker history is the tool for size problems. It shows exactly which instruction added the 400 MB.
# Run as a non-root user. Many base images provide one.
USER node
# Or create one
RUN adduser -D -u 10001 appuser
USER appuser
docker scout cves myapp:1.4.2 # scan for known vulnerabilities
# or: trivy image myapp:1.4.2
Containers run as root by default. If an attacker escapes the process, root inside the container is a much better starting position than an unprivileged user. Adding two lines removes that.
Explain Docker layer caching, and how you would order a Dockerfile for a monorepo.
Each instruction produces a layer keyed on the instruction plus its inputs. If the key is unchanged the layer is reused — but invalidating one layer invalidates every layer after it, whether or not those would have changed.
So the rule is: order least-likely-to-change first.
For a monorepo the naive COPY . . is fatal, because a change to any package invalidates the install for every package:
# Copy only the manifests first — one COPY per package, or a glob that
# matches manifests only. A change in service B's source no longer
# invalidates service A's dependency install.
COPY package.json pnpm-lock.yaml ./
COPY packages/a/package.json packages/a/
COPY packages/b/package.json packages/b/
RUN pnpm install --frozen-lockfile
# Only now bring in source
COPY . .
RUN pnpm --filter a build
Alpine or Debian slim for production? · نستخدم alpine ولا slim؟
The expected answer is a trade-off, not a winner.
alpine
-slim (Debian)
Size
~150 MB
~250 MB
libc
musl
glibc
Native modules
Sometimes break
Work
DNS resolution
musl historically weaker (no search fallback for some cases)
Standard glibc behaviour
Package availability
apk, smaller ecosystem
apt, everything
When alpine is right: Go or Rust static binaries (where libc barely matters), simple interpreted apps, and anywhere image size genuinely dominates — huge fleets, tight bandwidth.
When to use slim: anything with native modules (Python wheels with C extensions, node-gyp builds), anything latency-sensitive to DNS, and any time you find yourself debugging musl for more than half an hour.