Kennisbank › Docker Containers › Docker images optimaliseren voor productie
docker containers gevorderd 25 August 2026

Docker images optimaliseren voor productie

Docker images optimaliseren voor productieDit artikel legt uit hoe je Docker images optimaliseert voor productieomgevingen volgens de officiële Docker best

Docker images optimaliseren voor productie

Dit artikel legt uit hoe je Docker images optimaliseert voor productieomgevingen volgens de officiële Docker best practices, voor ontwikkelaars en DevOps-engineers die met Docker werken.

Vereisten

- Docker Engine 24.0 of hoger - Basiskennis van Dockerfiles en containerimages - Toegang tot een container registry (bijvoorbeeld Docker Hub of een private registry) - Een applicatie die je in een container wilt draaien

Stappen

1. Gebruik een official base image

Start met een current official image als basis voor elke image. Docker houdt deze images bij met regelmatige security updates en duidelijke documentatie. Officiële images verlagen het risico op kwetsbaarheden in de onderliggende softwarestack.

Kies een specifieke versie in plaats van `latest`:

FROM node:20-alpine

2. Kies de kleinste mogelijke base image

Gebruik voor de runtime-stage de kleinst mogelijke base image. Kleinere images deployen sneller en bevatten minder kwetsbare componenten. Alpine-varianten zijn een goed startpunt voor veel workloads.

Vergelijk:

Groot: node:20 (ongeveer 1 GB)
Klein: node:20-alpine (ongeveer 180 MB)
FROM node:20-alpine

3. Bouw met multi-stage builds

Gebruik multi-stage builds om de build-omgeving te scheiden van de runtime-omgeving. Dit levert een kleinere en veiligere productieimage op.

Stage 1: build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build</p><p>Stage 2: runtime
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm ci --omit=dev
EXPOSE 3000
CMD ["node", "dist/index.js"]

4. Orden Dockerfile-instructies voor optimale caching

Plaats instructies van minst vaak veranderend naar meest vaak veranderend. Zo blijft de cache geldig voor vroegere lagen wanneer je alleen de broncode wijzigt.

FROM node:20-alpine
WORKDIR /app</p><p>Copy package files eerst - deze veranderen zelden
COPY package*.json ./
RUN npm ci</p><p>Copy broncode - deze verandert vaak
COPY . .</p><p>CMD ["node", "src/index.js"]

5. Vermijd `COPY .` en gebruik `.dockerignore`

Kopieer alleen de bestanden die de applicatie nodig heeft. Dit vermindert de image-grootte en verbetert de caching.

Maak een `.dockerignore`-file in de projectroot:

node_modules
npm-debug.log
.git
.gitignore
Dockerfile
.dockerignore
.env
coverage
dist

Gebruik gerichte COPY-instructies:

COPY package*.json ./
COPY src/ ./src/
COPY public/ ./public/

6. Verwijder onnodige dependencies en tools

Laat debugging-tools en development dependencies achterwege in de productieimage. Gebruik `npm ci --omit=dev` of het equivalent voor jouw package manager.

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

7. Bouw images regelmatig opnieuw met geüpdatete dependencies

Oudere images bevatten kwetsbaarheden die opgelost zijn in nieuwere versies van de base image of geïnstalleerde pakketten. Plan herbouwen op een vast moment, bijvoorbeeld wekelijks of bij elke security patch.

docker build --pull -t myapp:$(date +%Y%m%d) .

De `--pull`-flag zorgt dat je altijd de nieuwste versie van de base image ophaalt.

8. Haal remote files op tijdens de build

Download externe bestanden tijdens de build in plaats van ze te kopiëren vanuit de context. Dit voorkomt dat je de Docker build context onnodig groot maakt.

FROM alpine:3.19
RUN wget -O /usr/local/bin/tool https://example.com/tool.tar.gz \
    && tar -xzf /usr/local/bin/tool.tar.gz -C /usr/local/bin/ \
    && rm /usr/local/bin/tool.tar.gz

Verificatie

Controleer of je image correct is geoptimaliseerd:

Toon image-grootte
docker images</p><p>Scan op kwantbaarheden (Docker Scout of Trivy)
docker scout cves myapp:latest</p><p>Toon lagen en hun grootte
docker history myapp:latest

Een productieimage voor een Node.js-applicatie zou typisch kleiner moeten zijn dan 200 MB. Een image met onnodige build-tools overschrijdt dit snel.

Veelgestelde problemen

1. Image blijft groot ondanks multi-stage build

Controleer of je in de runtime-stage geen overbodige bestanden kopieert. Gebruik `docker history ` om de grootte per laag te zien. Verwijder bijvoorbeeld `node_modules` uit de build-context met `.dockerignore` en installeer alleen productie-dependencies.

2. Cache wordt niet gebruikt bij elke build

Zorg dat de volgorde van instructies klopt. Plaats `COPY package*.json ./` en `RUN npm ci` vóór `COPY . .`. Wijzigt je `package.json`, dan wordt de cache ongeldig voor alle volgende lagen — dat is correct gedrag.

3. Alpine base image geeft compatibiliteitsproblemen

Alpine gebruikt musl libc in plaats van glibc. Sommige native modules werken hier niet mee. Gebruik dan een alternatieve kleine image zoals `node:20-slim` (Debian-based) of bouw met een multi-stage build waarin je de native module compileert in de build-stage.

Regelmatig herbouwen is geen eenmalige activiteit maar een doorlopend proces — de security landscape verandert voortdurend, en je images moeten daarin meebewegen.

← Terug naar kennisbank
← Terug naar kennisbank