Docker-images optimaliseren voor productie

Docker-images optimaliseren voor productie

Dit artikel legt uit hoe u 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 containerregistry (bijvoorbeeld Docker Hub of een privéregister) - Een applicatie die u in een container wilt laten draaien

Stappen

1. Gebruik een officieel basisimage

Start met een huidig officieel image als basis voor elk image. Docker houdt deze images bij met regelmatige beveiligingsupdates 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 het kleinste mogelijke basisimage

Gebruik voor de runtime-fase het kleinst mogelijke basisimage. Kleinere images deployen sneller en bevatten minder kwetsbare componenten. Alpine-varianten vormen 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 buildomgeving te scheiden van de runtime-omgeving. Dit levert een kleiner en veiliger productieimage op.

Fase 1: build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build</p><p>Fase 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 wijzigend naar meest vaak wijzigend. Zo blijft de cache geldig voor vroegere lagen wanneer u alleen de broncode wijzigt.

FROM node:20-alpine
WORKDIR /app</p><p>Kopieer packagebestanden eerst - deze wijzigen zelden
COPY package*.json ./
RUN npm ci</p><p>Kopieer broncode - deze wijzigt 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 imagegrootte en verbetert de caching.

Maak een `.dockerignore`-bestand 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 overbodige dependencies en tools

Laat debuggingtools en development dependencies achterwege in het productieimage. Gebruik `npm ci --omit=dev` of het equivalent voor uw packagemanager.

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 het basisimage of van geïnstalleerde pakketten. Plan herbouwen op een vast moment, bijvoorbeeld wekelijks of bij elke securitypatch.

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

De `--pull`-vlag zorgt ervoor dat u altijd de nieuwste versie van het basisimage ophaalt.

8. Haal externe bestanden op tijdens de build

Download externe bestanden tijdens de build in plaats van ze te kopiëren vanuit de context. Dit voorkomt dat u de Docker-buildcontext 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 uw image correct is geoptimaliseerd:

Toon imagegrootte
docker images</p><p>Scan op kwetsbaarheden (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 overbodige buildtools overschrijdt dit snel.

Veelgestelde problemen

1. Image blijft groot ondanks multi-stage build

Controleer of u in de runtime-fase geen overbodige bestanden kopieert. Gebruik `docker history ` om de grootte per laag te zien. Verwijder bijvoorbeeld `node_modules` uit de buildcontext met `.dockerignore` en installeer alleen productiedependencies.

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 uw `package.json`, dan wordt de cache ongeldig voor alle volgende lagen — dat is correct gedrag.

3. Alpine-basisimage geeft compatibiliteitsproblemen

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

Regelmatig herbouwen is geen eenmalige activiteit maar een doorlopend proces — het beveiligingslandschap verandert voortdurend, en uw images moeten daarin meebewegen.