Enterprise Dockerfile Optimization

A "Hello World" Docker image might be 50MB. A professional production image should be as small as possible to reduce Attack Surface and Transfer Time.

1. Multi-Stage Builds

Use one large image (with compilers and dev tools) to Build your app, and then "Copy" ONLY the final executable/dist folder into a tiny Alpine or Distroless image for production.

# Build Stage
FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# Production Stage
FROM node:20-alpine
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/main.js"]

2. Layer Caching

Order matters! Put commands that change **Rarely** (like install dependencies) at the TOP, and commands that change **Often** (like copy source code) at the BOTTOM. This ensures that a 1-line code change doesn't trigger a 5-minute npm install.

4. Interview Mastery

Q: "Why should you avoid using 'latest' tags in production Dockerfiles?"

Architect Answer: "Because `latest` is non-deterministic. If a base image (e.g., `node:latest`) updates and breaks something, your builds will start failing suddenly and you won't know why. For production, always use **Specific Versions** or even **SHA Hashes** to ensure that your build is 100% reproducible and doesn't change unless you explicitly update it."