Best practices voor Dockerfiles: het bouwen van slankere, snellere en veiligere Docker-images

Docker is uitgegroeid tot een onmisbaar hulpmiddel in moderne softwareontwikkeling, waardoor teams applicaties met ongekende consistentie en gemak kunnen bouwen, distribueren en uitvoeren. De kern van deze containerisatiemagie wordt gevormd door het Dockerfile, een eenvoudig maar krachtig script dat fungeert als blauwdruk voor het creëren van je Docker-images.

Het schrijven van een effectief Dockerfile-buildproces is meer dan alleen een technische oefening; het is een manier om snellere ontwikkelcycli, kleinere en veiligere applicatie-footprints en betrouwbaardere implementaties te realiseren. Of je nu nieuw bent met Docker of je vaardigheden wilt verfijnen, deze handleiding leidt je door de essentie van het schrijven van praktische, efficiënte en veilige Dockerfiles.

Inzicht in het Docker-ecosysteem: een korte opfrissing

Voordat we dieper ingaan op Dockerfiles, bespreken we eerst kort de belangrijkste Docker-concepten:

• Afbeeldingen: Een afbeelding is een lichtgewicht, op zichzelf staand, uitvoerbaar pakket dat alles bevat wat nodig is om software uit te voeren, inclusief de code, een runtime, bibliotheken, omgevingsvariabelen en configuratiebestanden. Afbeeldingen zijn onveranderlijke sjablonen.
• Containers: Een container is een uitvoerbare instantie van een image. Je kunt containers maken, starten, stoppen, verplaatsen of verwijderen. Ze bieden geïsoleerde omgevingen voor je applicaties.
• Dockerfile: Hier ligt onze focus. Een Dockerfile is een tekstbestand met een reeks commando's die Docker gebruikt om automatisch een image samen te stellen.
• Docker Hub/Registries: Dit zijn repositories voor het opslaan en delen van Docker-images, vergelijkbaar met GitHub voor code.

Een goed geschreven Dockerfile heeft als doel een image te produceren die zo compact, snel te bouwen en veilig mogelijk is.

Docker-buildvlaggen uitgelegd

• -t myapp:1.0 : Deze vlag tagt uw image met een naam (myapp) en een versie (1.0). Tagging helpt bij versiebeheer en maakt het later gemakkelijker om naar specifieke image-builds te verwijzen, vooral bij het implementeren of uploaden naar een register.

• . (punt) : Dit verwijst naar de buildcontext, de map waar Docker moet zoeken naar het Dockerfile en alle andere bestanden die nodig zijn tijdens het bouwproces (bijvoorbeeld bestanden die naar de image moeten worden gekopieerd).
  Docker comprimeert de inhoud van deze map en stuurt deze naar de Docker-daemon. Het is belangrijk om te weten dat alleen bestanden binnen de buildcontext toegankelijk zijn tijdens het bouwproces.

Essentiële instructies voor Dockerfiles: De bouwstenen

Laten we de meest voorkomende instructies en hoe je ze effectief kunt gebruiken eens nader bekijken.

1. VAN: Elk Dockerfile moet beginnen met een FROM-instructie. Deze specificeert de basisimage waarop uw image zal worden gebouwd.
   • Doel: Een startpunt selecteren, vaak een besturingssysteem (zoals Ubuntu:22.04) of een vooraf geconfigureerde applicatie-runtime (zoals node:18-alpine).
   • Voorbeeld : FROM python:3.9-slim
   • Beste praktijk: Kies de minimale basisimage die aan de behoeften van uw applicatie voldoet. Alpine-versies zijn klein, maar gebruiken musl libc, wat compatibiliteitsproblemen kan veroorzaken met sommige C-afhankelijke pakketten. Slim-versies zijn een goed compromis en bieden een uitgeklede versie van een standaarddistributie (zoals Debian) met glibc.
2. WORKDIR: Deze instelling bepaalt de werkmapWerkmap voor alle daaropvolgende RUN-, CMD-, ENTRYPOINT-, COPY- en ADD-instructies.
   • Doel: De huidige directorycontext binnen de image definiëren voor latere bestandsbewerkingen en commando-uitvoeringen. Als de directory niet bestaat, maakt Docker deze aan.
   • Voorbeeld: WORKDIR /usr/src/app
   • Beste werkwijze: Gebruik absolute paden voor WORKDIR. Meerdere keren van directory wisselen met WORKDIR is over het algemeen overzichtelijker dan het aaneenschakelen van cd-opdrachten binnen RUN-instructies.
3. KOPIËREN: Kopieert bestanden of mappen vanuit uw buildcontext naar het bestandssysteem van de image.
   • Doel: Voeg uw applicatiecode, configuratiebestanden en andere benodigde bestanden toe aan de image.
   • Voorbeeld:

Dockerfile

WORKDIR /usr/src/app
COPY package.json ./
COPY src/ ./src/

• Beste werkwijze: Voor het eenvoudig kopiëren van bestanden kunt u beter COPY gebruiken dan ADD. COPY is transparanter. ADD heeft extra functies zoals downloaden via URL en het uitpakken van tar-bestanden, wat minder voorspelbaar kan zijn. Voor duidelijkheid en veiligheid is het vaak beter om RUN te gebruiken met curl, wget en tar als u bestanden moet downloaden en uitpakken.

4. LOOP: Voert commando's uit in een nieuwe laag bovenop de huidige image en slaat de resultaten op. Dit wordt gebruikt voor het installeren van software, het aanmaken van mappen, het compileren van code, enzovoort.
   • Doel: Het bestandssysteem van de image wijzigen door pakketten te installeren, buildscripts uit te voeren of configuraties in te stellen.
   • Voorbeeld:

Dockerfile

RUN apt-get update && apt-get install -y –no-install-recommends \
nginx \
curl \
&& rm -rf /var/lib/apt/lists/*

• Beste werkwijze: Koppel gerelateerde opdrachten aan elkaar met && en ruim tijdelijke bestanden of caches van pakketbeheerders op (zoals rm -rf /var/lib/apt/lists/* voor Debian/Ubuntu of yum clean all voor CentOS/RHEL) in dezelfde RUN-instructie. Dit minimaliseert het aantal lagen en verkleint de imagegrootte, aangezien elke RUN-instructie een nieuwe laag creëert.

5. OMGEVING: Hiermee worden omgevingsvariabelen ingesteld die beschikbaar zijn tijdens het bouwproces (nadat ze zijn gedefinieerd) en wanneer containers vanuit de image worden uitgevoerd.
   • Doel: Het verstrekken van configuratiewaarden, paden of instellingen die nodig zijn voor uw applicatie of buildscripts.
   • Voorbeeld:

Dockerfile

ENV NODE_ENV=production
ENV APP_PORT=3000

• Aanbevolen werkwijze: Gebruik ENV voor niet-gevoelige configuratiegegevens. Gebruik runtime-injectiemethoden in plaats van geheime gegevens in de image op te nemen met ENV.

6. ARG: Definieert een build-time variabele die gebruikers kunnen doorgeven met behulp van de `--build-arg` vlag tijdens het Docker-buildproces.
   • Doel: Het mogelijk maken om het bouwproces te parameteriseren zonder het Dockerfile aan te passen.
   • Voorbeeld: Dockerfile

Dockerfile

ARG APP_VERSION=1.0.0
ENV APP_VERSION_ENV=${APP_VERSION}
RUN echo “Bouwen van versie ${APP_VERSION_ENV}”

• Bouwen met: rammen docker build – build-arg APP_VERSION=1.2.3 -t myapp.
• Opmerking: ARG-variabelen zijn niet beschikbaar in de actieve container, tenzij ze expliciet zijn ingesteld als een omgevingsvariabele, zoals hierboven weergegeven.

7. ONTMASKERD: Hiermee wordt Docker geïnformeerd dat de container tijdens de uitvoering luistert op de opgegeven netwerkpoorten.
   • Doel: Dit document dient voornamelijk als documentatie voor de image builder en de gebruiker. Het publiceert de poort niet.

Voorbeeld:

Dockerfile

EXPOSE 8080

• Opmerking: Om de poort vanaf de host toegankelijk te maken, gebruikt u de vlag -p of -P bij docker run (bijvoorbeeld: docker run -p 8080:8080 myimage).

8. CMD En INGANGSPUNT: Definieer welk commando wordt uitgevoerd wanneer een container start.
   • CMD [“uitvoerbaar bestand”, “parameter1”, “parameter2”] : Hiermee worden standaardwaarden ingesteld voor een container die wordt uitgevoerd. Deze standaardwaarden kunnen eenvoudig worden overschreven door een commando toe te voegen aan `docker run`. Als u meerdere CMD's hebt, is alleen de laatste van toepassing.
   • ENTRYPOINT [“uitvoerbaar bestand”, “parameter1”, “parameter2”] : Configureert een container om als uitvoerbaar bestand te draaien. Argumenten die aan docker run worden doorgegeven, worden aan de ENTRYPOINT-opdracht toegevoegd.
   • Voorbeeld (typisch patroon):

Dockerfile

ENTRYPOINT [“python”, “app.py”] # Hoofdopdracht
CMD [“–help”] # Standaardargument als er geen argument wordt opgegeven bij docker run

• Beste werkwijze: Gebruik CMD als u een eenvoudig aanpasbare standaardopdracht wilt. Gebruik ENTRYPOINT om een ​​image te creëren die zich gedraagt ​​als een specifiek uitvoerbaar bestand, waarbij CMD vaak wordt gebruikt om standaardargumenten op te geven. Voor webapplicaties zijn CMD [“npm”, “start”] of CMD [“python”, “manage.py”, “runserver”] standaard.

Belangrijkste best practices voor geoptimaliseerde Dockerfiles

Het schrijven van een functioneel Dockerfile is slechts het begin. Het optimaliseren ervan levert aanzienlijke voordelen op.

• Maak effectief gebruik van de buildcache: Docker bouwt images in lagen en probeert, indien mogelijk, lagen van eerdere builds te hergebruiken (caching). Om het aantal cache-hits te maximaliseren:
  • Rangschik de instructies van minst vaak veranderend naar meest vaak veranderend. Installeer bijvoorbeeld eerst de afhankelijkheden (die minder vaak veranderen) voordat u de broncode van uw applicatie kopieert (die vaak verandert).

Dockerfile

# Goed voorbeeld van caching voor een Node.js-app
FROM node:18-alpine
WORKDIR /app
COPY package.json package-lock.json ./ # Afhankelijkheden veranderen minder vaak
RUN npm ci –omit=dev # Deze laag wordt in de cache opgeslagen als pakketbestanden niet veranderen
COPY . . # Broncode verandert vaak, dus deze wordt als laatste opgeslagen
CMD [“node”, “server.js”]

• Houd uw afbeeldingen klein: Kleinere images kunnen sneller worden gedownload, geüpload en geïmplementeerd, en hebben een kleiner aanvalsoppervlak.
  • Gebruik minimale basisimages: Alpine-, slim- of distroless-varianten zijn aanzienlijk kleiner dan volledige OS-images.
  • Opruimen in dezelfde RUN-laag: Verwijder onnodige caches of tijdelijke bestanden met dezelfde RUN-instructie na het installeren van pakketten. Bijvoorbeeld:
    • Debian/Ubuntu: apt-get clean && rm -rf /var/lib/apt/lists/*
    • CentOS/RHEL: yum clean all of dnf clean all
    • Alpine: rm -rf /var/cache/apk/*
• Omarm bouwprojecten in meerdere fasen: Dit is een van de meest effectieve manieren om de afbeeldingsgrootte te verkleinen, met name voor gecompileerde talen of applicaties met buildstappen (zoals JavaScript-frontends).
  • Concept: Gebruik één fase (een FROM-blok) met al je buildtools en ontwikkelingsafhankelijkheden om je applicatie te compileren/bouwen. Start vervolgens een nieuwe fase vanuit een minimale runtime-basisimage en gebruik COPY – from= … om alleen de noodzakelijke gecompileerde artefacten naar deze laatste, schone fase te kopiëren.
  • Voorbeeld (vereenvoudigde Go-applicatie): Dockerfile

Dockerfile

# Fase 1: Bouwen
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Fase 2: Uitvoeren
FROM debian:bullseye-slim
WORKDIR /app
COPY –from=builder /app/myapp .
CMD [“./myapp”]

• De builderfase bevat de Go SDK, maar de uiteindelijke image bevat alleen het gecompileerde binaire bestand en het minimale Alpine OS.
• Veiligheid staat voorop:
  • Uitvoeren als een niet-rootgebruiker: Containers worden standaard als root uitgevoerd. Dit vormt een beveiligingsrisico. Maak een aparte, niet-bevoorrechte gebruiker en groep aan in uw Dockerfile en gebruik de USER-instructie om hiernaar over te schakelen. Dockerfile

Dockerfile

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
# … Kopieer bestanden en wijzig de eigenaar naar appuser:appgroup …
Gebruiker appuser

• Installeer alleen noodzakelijke pakketten: elk pakket is een potentiële kwetsbaarheid. Vermijd het installeren van debugtools of ontwikkelhulpprogramma's in productie-images (gebruik hiervoor multistage builds).
• Hardcode geen geheimen: Vermijd het opnemen van wachtwoorden, API-sleutels of andere geheimen in uw Dockerfile (bijvoorbeeld in omgevingsvariabelen). Gebruik runtime-injectiemethoden zoals Docker-geheimen, Kubernetes-geheimen of omgevingsvariabelen die veilig tijdens runtime worden verstrekt.
• Gebruik .dockerignore effectief: Maak een .dockerignore-bestand aan in de hoofdmap van je build-context (op hetzelfde niveau als je Dockerfile). Geef daarin de bestanden en mappen op die niet naar de Docker-daemon mogen worden verzonden (bijv. .git, node_modules indien geïnstalleerd in de image, lokale IDE-configuraties, *.log).
• Voordelen: Versnel het Docker -bouwproces door de grootte van de bouwcontext te verkleinen en te voorkomen dat gevoelige of onnodige bestanden in uw image worden opgenomen.

Voorbij de basis: verdere verbeteringen

Als je hiermee vertrouwd bent, kun je de volgende suggesties overwegen voor nog betere Dockerfiles:

• BuildKit: Docker's nieuwere build-engine, vaak standaard ingeschakeld. Het biedt betere prestaties (parallelle builds), verbeterde caching en geavanceerde functies zoals build secrets (RUN– mount=type=secret,…) en cache mounts (RUN– mount=type=cache,…) voor pakketbeheerders. Zorg ervoor dat het actief is of schakel het in met DOCKER_BUILDKIT=1.
• Dockerfiles controleren: Gebruik tools zoals Hadolint (hadolint Dockerfile) om je Dockerfile statisch te analyseren op fouten, stijlregels en naleving van best practices voordat je gaat bouwen.

Veelvoorkomende tips voor probleemoplossing

• Foutmelding "Bestand niet gevonden" tijdens COPY of ADD : Controleer het bronpad (het is relatief ten opzichte van de root van de buildcontext) en zorg ervoor dat het bestand niet is uitgesloten door .dockerignore.
• Trage builds: Controleer de volgorde van instructies voor cacheoptimalisatie. Combineer RUN-opdrachten waar mogelijk. Zorg ervoor dat uw .dockerignore-bestand volledig is.
• Grote afbeeldingen: Gebruik een meertraps opbouw! Ruim op in de RUN-lagen. Kies minimale basisafbeeldingen.

Dockerfiles in uw DevOps-workflow

Een Dockerfile is een essentieel onderdeel van "Infrastructure as Code"

• Versiebeheer: Commit je Dockerfile altijd samen met je applicatiecode naar je Git-repository.
• CI/CD-integratie: Automatiseer uw Docker-build- en image-pushproces binnen uw Continuous Integration/Continuous Delivery-pipelines (bijv. GitHub Actions, Jenkins, GitLab CI). Dit zorgt voor consistente, herhaalbare builds en implementaties.

Conclusie: Een fundament leggen voor succes

Het creëren van effectieve Dockerfiles is een investering die aanzienlijke voordelen oplevert op het gebied van ontwikkelsnelheid, operationele betrouwbaarheid en applicatiebeveiliging. Door de basisinstructies onder de knie te krijgen, best practices zoals multi-stage builds en zorgvuldig beheer van imagelagen toe te passen en prioriteit te geven aan beveiliging, kunt u Docker-images produceren die compact, efficiënt en robuust zijn.

Deze handleiding biedt een solide basis. Ga tijdens je Docker-avontuur verder met verkennen, experimenteren en het verfijnen van je Dockerfiles.

Ben je klaar om je Docker- en DevOps-praktijken naar een hoger niveau te tillen?

Bij Seahawk Media zijn we gespecialiseerd in het helpen van bedrijven om het volledige potentieel van containerisatie, cloudtechnologieën en gestroomlijnde CI/CD-pipelines te benutten. Ons team van experts staat klaar om u te helpen bij het optimaliseren van uw applicatie-implementaties, het verbeteren van de beveiliging of het versnellen van uw ontwikkelcyclus.