dockerfilelisted

# Dockerfile Use this skill to write Dockerfiles that rebuild fast and produce small, secure images. ## Core principle: order layers least → most frequently changed Each instruction is a cached layer. Docker reuses a layer only if it **and every layer above it** is unchanged. So put the things that rarely change at the top and the things that change on every commit (your source code) last. The usual order: 1. `FROM` base image (pinned) 2. System packages (`apt-get`/`apk`) 3. Dependency manifests only — `COPY package.json package-lock.json ./` (or `Gemfile`, `requirements.txt`, `go.mod`) 4. `RUN` install dependencies 5. **Then** `COPY . .` — the app source 6. Build step, then `CMD`/`ENTRYPOINT` This way editing source only invalidates the cache from step 5 down; the expensive dependency install in step 4 stays cached. ## Before / after ```dockerfile # ❌ Cache-busting: any source edit re-runs npm install FROM node:22-slim WORKDIR /app COPY . . RUN npm ci CMD ["node", "server.js"] ``` ```dockerfile # ✅ Cache-friendly: npm ci is reused until package*.json changes FROM node:22-slim WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . CMD ["node", "server.js"] ``` ## Gotchas | Do | Why | |----|-----| | Pin the base image (`node:22.3-slim` or a `@sha256:` digest), never `latest` | Reproducible builds; `latest` silently drifts | | Use multi-stage builds (`FROM … AS build` → copy artifacts into a slim final stage) | Keeps compilers/dev deps out of the s