Dockerfile-generator

Waarom multi-stage builds

Een naïef Dockerfile installeert de hele compiler-toolchain in de uiteindelijke image. Multi-stage builds geven je een “builder”-fase die compileert en een eindfase die alleen het gecompileerde artefact bevat:

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"]

De eindimage laat elke ontwikkelafhankelijkheid, elk bronbestand en de buildcache weg, waardoor de image vaak 60-80 procent kleiner wordt.

Basis-imagevarianten

De sjablonen gebruiken waar mogelijk slim- of alpine-images. Pas je het basis-image zelf aan, dan zijn dit de gebruikelijke opties:

Regels voor laagcaching

Docker cached elke regel; zodra een laag verandert, wordt alles eronder opnieuw gebouwd. Volgorde van minst naar meest veranderlijk:

1. Basis-image FROM (verandert zelden).
2. Systeempakketten (apt-get install), zeldzame wijzigingen.
3. Afhankelijkheidsmanifests (package.json, requirements.txt, composer.json).
4. Installatiestap voor afhankelijkheden. Draait alleen wanneer het manifest verandert.
5. Kopie van de broncode. De drukste laag; alles erna wordt bij elke commit herbouwd.
6. Compileren en uiteindelijke CMD.

Deze volgorde doorbreken is de meest voorkomende reden dat CI-builds traag worden.

Beveiligingscontrolelijst

• Uitvoeren als niet-root. Zet USER appuser (of USER 1000) aan het einde.
• Versies vastpinnen. python:3.12.7-slim verslaat python:3.12, dat python:latest verslaat.
• Stel een expliciete WORKDIR in in plaats van op / te vertrouwen.
• Gebruik COPY in plaats van ADD voor lokale bestanden; ADD heeft bijwerkingen door automatische extractie.
• Voeg een HEALTHCHECK toe zodat orchestrators een vastgelopen proces kunnen detecteren.
• Ruim pakketcaches op in dezelfde RUN-regel: apt-get install ... && rm -rf /var/lib/apt/lists/*.