Dockerfile-generator

Varför multi-stage-byggen

En naiv Dockerfile installerar hela kompilatorverktygskedjan i slutbilden. Multi-stage-byggen ger dig ett “builder”-steg som kompilerar och ett slutsteg som bara innehåller den kompilerade artefakten:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

Slutbilden släpper alla utvecklingsberoenden, källfiler och byggcache, vilket ofta minskar bildstorleken med 60-80 procent.

Varianter av basbild

Mallarna använder slim- eller alpinebilder där det är möjligt. Om du justerar basbilden själv är dessa de typiska alternativen:

Regler för lager-cachning

Docker cachar varje rad; när ett lager ändras byggs allt nedanför om. Ordning från minst till mest föränderligt:

1. Basbilden FROM (ändras sällan).
2. Systempaket (apt-get install), sällsynta ändringar.
3. Beroendemanifest (package.json, requirements.txt, composer.json).
4. Installationssteget för beroenden. Körs bara när manifestet ändras.
5. Kopiering av källkod. Det mest aktiva lagret; allt efter det byggs om vid varje commit.
6. Kompilering och slutligt CMD.

Att bryta den här ordningen är den vanligaste orsaken till långsamma CI-byggen.

Säkerhetschecklista

• Kör som icke-root. Sätt USER appuser (eller USER 1000) mot slutet.
• Lås versioner. python:3.12.7-slim slår python:3.12 som slår python:latest.
• Sätt ett tydligt WORKDIR i stället för att förlita dig på /.
• Använd COPY, inte ADD för lokala filer; ADD har bieffekter med automatisk uppackning.
• Lägg till en HEALTHCHECK så orkestrerare kan upptäcka en fastkörd process.
• Rensa paketcachar på samma RUN-rad: apt-get install ... && rm -rf /var/lib/apt/lists/*.