The Dockerfile is the most important Docker artifact. A bad Dockerfile creates large, slow, insecure images. A good Dockerfile creates small, fast, secure images. Interviewers always ask about Dockerfile best practices — this is where junior and senior engineers differ.

The Most Common Mistake — Wrong Layer Order

Docker caches layers. If layer N changes, all layers N+1 onwards are rebuilt. Dependencies change rarely. Code changes every commit. Always copy dependencies before code.

Multi-Stage Builds — Production Standard

Multi-stage builds use multiple FROM instructions. The final image only contains what the last stage copies. Result: a 1.2GB build image becomes a 50MB production image.

.dockerignore — Always Create This

Docker security is one of the most asked topics at senior interviews. Most breaches come from: running as root, using untrusted base images, exposed Docker socket, leaked secrets in image layers.

Security Checklist

Registry Options

Docker Compose defines multi-container applications. It is NOT for production (use Kubernetes for that) but essential for local development and integration testing. Every senior engineer should be able to write a Compose file from scratch.

In production pipelines Docker builds must be: fast (layer caching), secure (no secrets in image), small (multi-stage), and tagged properly (semantic versioning, never :latest in production).

The problem with single-stage builds

A standard Dockerfile includes: the full SDK (JDK, Maven, Node.js), all build tools, source code, test files, and the final compiled artifact. Result: a 600MB image shipped to production containing tools that are never used at runtime. Security risk: larger attack surface. Cost: slower pulls, more registry storage.

Multi-stage build — Java application example

# Stage 1: BUILD — contains Maven, source code, all build tools
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
# Download dependencies separately (cached if pom.xml unchanged)
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn clean package -DskipTests

# Stage 2: RUNTIME — contains ONLY the JRE and the compiled JAR
FROM eclipse-temurin:17-jre-alpine AS runtime
WORKDIR /app
# Security: create non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
# Copy ONLY the artifact from build stage
COPY --from=builder /app/target/myapp-1.0.jar app.jar
USER appuser
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Result: build image is 600MB (never pushed). Runtime image is 180MB (what runs in production). The runtime image has no Maven, no source code, no compiler.

Multi-stage for Node.js

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production   # install only production deps

FROM node:20-alpine AS runtime
WORKDIR /app
RUN addgroup -S app && adduser -S app -G app
COPY --from=builder /app/node_modules ./node_modules
COPY --chown=app:app src ./src
COPY package.json .
USER app
EXPOSE 3000
CMD ["node", "src/index.js"]

Build cache optimisation — order matters

Docker caches each layer. If a layer's input hasn't changed, it uses the cache. Rule: put things that change infrequently (dependencies) BEFORE things that change frequently (source code). Always copy package.json BEFORE copying source code. If you copy source first, the dependency install never uses cache.

BuildKit is the modern Docker build engine (default in Docker 23+)

# Enable BuildKit (older Docker versions)
export DOCKER_BUILDKIT=1

# Build with BuildKit — parallel stages, better caching
docker buildx build -t myapp:v1 .

# Cache mount — cache pip/npm/maven downloads between builds
FROM python:3.11-slim
# --mount=type=cache: this directory is cached between builds
# never included in the image layer
RUN --mount=type=cache,target=/root/.cache/pip     pip install -r requirements.txt

# Secret mount — pass secrets without including them in image layers
RUN --mount=type=secret,id=npm_token     NPM_TOKEN=$(cat /run/secrets/npm_token) npm install

# Build with secret
docker buildx build --secret id=npm_token,src=.npmrc -t myapp .

# Multi-platform build — build for linux/amd64 and linux/arm64
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:v1 --push .

BuildKit advantages

• Parallel stage execution — independent stages build simultaneously
• Cache mounts — package manager caches persist between builds (much faster)
• Secret mounts — secrets never appear in image layers or history
• Multi-platform — build for ARM and AMD64 in one command
• Inline cache — embed cache metadata in the image for CI/CD layer caching

Every image must be scanned before production

Trivy in CI/CD pipeline — fail on HIGH/CRITICAL

# Jenkins/GitHub Actions step
trivy image   --exit-code 1 \          # fail the build if vulnerabilities found
  --severity HIGH,CRITICAL \  # only fail on HIGH or CRITICAL
  --ignore-unfixed \       # ignore CVEs with no fix available
  myapp:${BUILD_NUMBER}

# Output as SARIF for GitHub Security tab
trivy image --format sarif --output trivy-results.sarif myapp:v1

Security best practices — summary

• Never run as root — always add a non-root user in Dockerfile: USER appuser
• Use minimal base images — Alpine, distroless, or slim variants
• No secrets in image layers — use BuildKit secret mounts or inject at runtime via env vars/K8s secrets
• Pin base image versions — FROM node:20.11.0-alpine3.19 not FROM node:latest
• Read-only filesystem — docker run --read-only or Kubernetes readOnlyRootFilesystem: true
• Scan in registry — ACR, ECR, Harbor all support automatic image scanning on push