Docker Buildx: zo bouw je multi-platform containerimages

Geavanceerde use-cases

Tot nu toe liet ik je basiscommando’s en use-cases van Buildx zien. Buildx kan nog veel meer, met features die met de klassieke builder onmogelijk zijn.

Laten we een paar geavanceerde technieken verkennen om je containerworkflow naar een hoger niveau te tillen.

Optimalisatie van multi-stage builds

Multi-stage builds zijn een van de krachtigste Dockerfeatures om efficiënte images te maken, en Buildx maakt ze nog beter.

Ter demonstratie maken we een geoptimaliseerde Python-applicatie met meerdere stages:

# Dockerfile.optimized
FROM python:3.13-slim AS base
WORKDIR /app
COPY requirements.txt .

FROM base AS builder
RUN pip install --no-cache-dir --target=/install -r requirements.txt

FROM base AS linter
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
RUN pip install pylint && pylint app.py || exit 0

FROM base AS tester
COPY --from=builder /install /usr/local/lib/python3.9/site-packages
COPY app.py .
RUN pip install pytest && python -m pytest app.py -v || exit 0

FROM python:3.13-alpine AS final
WORKDIR /app
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]Mogelijk gemaakt door

Met Buildx kun je dit efficiënter bouwen:

docker buildx build --file Dockerfile.optimized -t myapp:optimized --load .Mogelijk gemaakt door

Afbeelding 9 - Multi-stage builds

Wat maakt dit bijzonder? Buildx verwerkt onafhankelijke stages parallel. Waar de legacy builder elke stage sequentieel uitvoert, ziet Buildx dat de linter en tester-stages niet van elkaar afhankelijk zijn en ze tegelijk kan bouwen.

Een extra voordeel van deze bouwoptimalisatie is reductie van bestandsgrootte. Je kunt de imagegrootte verifiëren met:

docker images myappMogelijk gemaakt door

Je ziet iets als dit:

Afbeelding 10 - Docker imagegroottes

Het op Alpine gebaseerde eindimage is veel kleiner.

Integratie in CI/CD-pijplijnen

Ook al werk je lokaal, je kunt Buildx-configuraties opzetten die je CI/CD-omgeving weerspiegelen.

Begin met een .dockerignore-bestand om builds schoon te houden:

.git
__pycache__
*.pyc
*.pyo
*.pyd
.Python
env
venv
*.so
.coverage
htmlcovMogelijk gemaakt door

Maak daarna een buildscript dat lijkt op wat je CI-pijplijn doet:

#!/bin/bash
# build.sh - Lokale CI/CD-simulatie

echo "Starting CI/CD build process..."

# Builder instellen met emulatieondersteuning
echo "Setting up builder..."
docker buildx create --name cibuilder --use || true
docker buildx inspect --bootstrap

# Linting uitvoeren
echo "Running lint stage..."
docker buildx build --file Dockerfile.optimized --target linter .

# Tests uitvoeren
echo "Running test stage..."
docker buildx build --file Dockerfile.optimized --target tester .

# Bouwen voor meerdere platforms
echo "Building multi-platform image..."
docker buildx build --file Dockerfile.optimized \
  --platform linux/amd64,linux/arm64 \
  --tag myapp:$(date +%Y%m%d) \
  --tag myapp:latest \
  --load \
  --progress=plain \
  .

echo "Build process complete!"Mogelijk gemaakt door

In gewone taal doet dit script het volgende:

• Maakt een dedicated builder voor CI/CD.
• Draait de lintingstage.
• Draait de teststage.
• Bouwt het uiteindelijke multi-platform image met versietags.

En nu het leuke deel — maak het script uitvoerbaar en draai het:

chmod +x build.sh
./build.shMogelijk gemaakt door

Lokaal bewerken

Een veelvoorkomende frustratie met Docker is dat je bij iedere broncodewijziging het image opnieuw moet bouwen en de container starten. Dat kost gewoon te veel tijd.

Goed nieuws: voor lokale ontwikkeling met snellere iteraties kun je een ontwikkelversie maken:

# Dockerfile.dev
FROM python:3.13-slim
WORKDIR /app

RUN pip install flask psutil python-dotenv

# Ontwikkeltools installeren
RUN pip install pytest pylint watchdog

# Mount applicatiecode tijdens runtime in plaats van kopiëren
CMD ["python", "app.py"]Mogelijk gemaakt door

Draai deze met een volumemount voor live herladen van code:

docker buildx build -f Dockerfile.dev -t myapp:dev --load .
docker run -it --rm -p 5000:5000 -v $(pwd):/app myapp:devMogelijk gemaakt door

Je kunt nu lokaal je app.py-bestand bewerken en de wijzigingen zijn direct zichtbaar in de draaiende container!

Hierna bespreken we prestaties.

Prestatie-overwegingen

Niemand houdt van een trage ontwikkelworkflow, en de kracht van parallelisatie met Docker Buildx kan helpen.

Laten we verkennen hoe je je builds optimaliseert en profiteert van de prestatiefeatures van Buildx om sneller images te maken.

Technieken voor buildparallelisatie

Een van de grootste voordelen van Buildx is dat het stages parallel kan bouwen. De traditionele Dockerbuilder voert elke stap sequentieel uit, maar Buildx analyseert je Dockerfile en ziet welke stappen tegelijk kunnen draaien.

Om dat te laten zien, gebruik ik twee bestanden — Dockerfile.standard en Dockerfile.parallel. Dit zijn de inhoudelijke voorbeelden van beide:

Dockerfile.standard

FROM python:3.13-slim
WORKDIR /app

# Systeemafhankelijkheden
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Python-afhankelijkheden
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Applicatiecode
COPY app.py .

# Linting
RUN pip install pylint && pylint app.py || true

EXPOSE 5000
CMD ["python", "app.py"]Mogelijk gemaakt door

Dockerfile.parallel

FROM python:3.13-slim AS python-base
WORKDIR /app

# Onafhankelijke stage voor installatie van systeemafhankelijkheden
FROM python-base AS system-deps
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Onafhankelijke stage voor installatie van Python-afhankelijkheden
FROM python-base AS python-deps
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Onafhankelijke stage voor statische code-analyse
FROM python-deps AS linting
COPY app.py .
RUN pip install pylint && pylint app.py || true

# Eindstage die afhankelijkheden combineert
FROM python-base AS final
# Kopieer vanuit system-deps stage
COPY --from=system-deps /usr/bin/gcc /usr/bin/gcc
# Kopieer vanuit python-deps stage
COPY --from=python-deps /usr/local/lib/python3.13/site-packages /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]Mogelijk gemaakt door

Laten we meten hoe deze parallelle structuur de buildtijd verbetert:

# Meet de standaard sequentiële build
time docker build -t myapp:standard -f Dockerfile.standard .

# Meet de parallel geoptimaliseerde build met Buildx
time docker buildx build --load -t myapp:parallel -f Dockerfile.parallel .Mogelijk gemaakt door

Ter referentie: de standaardbuild duurde 18,48 seconden, terwijl de parallelle build slechts 1,17 seconde duurde!

Voor nog betere prestaties kun je de flags --cache-from en --cache-to gebruiken om lokale schijfcaching te benutten:

# Eerste build - maak cache aan
docker buildx build --load -t myapp:latest --cache-to type=local,dest=./buildcache .

# Volgende builds - gebruik cache
docker buildx build --load -t myapp:latest --cache-from type=local,src=./buildcache .Mogelijk gemaakt door

Je kunt ook de contextgrootte beperken met zorgvuldig opgestelde .dockerignore-bestanden:

# Maak een uitgebreide .dockerignore
cat > .dockerignore << 'EOF'
.git
.github
.dockerignore
.pytest_cache
__pycache__
*.pyc
*.pyo
*.pyd
.Python
venv
env
node_modules
.coverage
htmlcov
.DS_Store
EOFMogelijk gemaakt door

Kortom: door je Dockerfiles op te zetten met parallelisatie in gedachten en gebruik te maken van de geavanceerde caching van Buildx, wacht je minder op builds en besteed je meer tijd aan features ontwikkelen.

Ecosysteemintegratie

Docker Buildx staat niet op zichzelf. Het is gemaakt om naadloos te integreren met andere tools in je ontwikkelomgeving.

Laten we bekijken hoe Buildx samenwerkt met lokale ontwikkeltools en je containerworkflow efficiënter maakt.

Kubernetes-buildclusters

Kubernetes biedt krachtige mogelijkheden om gedistribueerde Docker Buildx-operaties over een cluster te draaien. Door Buildx met Kubernetes te integreren, krijg je snellere en veerkrachtigere builds die met je project mee opschalen.

> Nieuw met Kubernetes? De post Kubernetes vs Docker: verschillen die elke developer moet kennen is je volgende halte.

Kubernetes gebruiken voor je buildinfrastructuur biedt diverse voordelen:

1. Automatische schaalbaarheid: Kubernetes kan je buildernodes op- of afschalen op basis van vraag en resources efficiënt toewijzen. Je kunt zelfs autoscalingregels instellen op CPU-gebruik.
2. Resource-optimalisatie: Kubernetes-scheduling zorgt dat je builds de benodigde resources krijgen zonder individuele nodes te overbelasten. Je kunt limieten en requests instellen voor consistente prestaties.
3. Hoge beschikbaarheid: Door BuildKit-instances over meerdere nodes te verdelen, blijft je buildinfrastructuur beschikbaar, zelfs als er nodes uitvallen.
4. Consistente omgevingen: Iedereen in het team koppelt naar dezelfde buildinfrastructuur, waardoor "works on my machine"-problemen verdwijnen.
5. Parallelle uitvoering: Complexe builds met veel stages kunnen parallel over meerdere nodes draaien, wat de buildtijd flink reduceert. Een project dat lokaal 15 minuten duurt, kan gedistribueerd in 3–4 minuten klaar zijn.

Beschouw dit als een meer "theoretisch" onderdeel, want dieper ingaan op Kubernetes is op zichzelf al een geavanceerd onderwerp.

Begin met een bestand buildkit-deployment.yaml met de volgende inhoud:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: buildkit
  namespace: buildkit
spec:
  replicas: 3
  selector:
    matchLabels:
      app: buildkit
  template:
    metadata:
      labels:
        app: buildkit
    spec:
      containers:
      - name: buildkit
        image: moby/buildkit:latest
        args:
        - --addr
        - tcp://0.0.0.0:1234
        ports:
        - containerPort: 1234
        securityContext:
          privileged: true
---
apiVersion: v1
kind: Service
metadata:
  name: buildkit
  namespace: buildkit
spec:
  type: ClusterIP
  ports:
  - port: 1234
    targetPort: 1234
  selector:
    app: buildkitMogelijk gemaakt door

Voer dit bestand vervolgens uit op je Kubernetes-cluster:

kubectl create namespace buildkit
kubectl apply -f buildkit-deployment.yamlMogelijk gemaakt door

Maak tot slot vanaf je lokale machine verbinding met deze deployment:

docker buildx create --name k8s-builder \
  --driver remote \
  --driver-opt endpoint=tcp://<cluster-ip>:1234 \
  --useMogelijk gemaakt door

En dat is het — je bent klaar om te gaan!

IDE-plug-inondersteuning

IDE’s zoals Visual Studio Code bieden uitstekende integratie met Docker Buildx via de Docker-extensie. Zo beheer je je Buildx-workflows makkelijker rechtstreeks vanuit je ontwikkelomgeving.

Om te beginnen met Docker Buildx in VS Code, installeer je de "Docker"-extensie uit de VS Code-marktplaats.

Na installatie krijg je diverse Buildx-specifieke features:

• Rechtsklik op een Dockerfile voor een contextmenu met de optie "Build Image..." die Buildx ondersteunt.
• Toegang tot buildarguments, platformdoelen en outputopties via de UI.
• Mogelijkheid om verschillende builderinstances te beheren en daartussen te wisselen.
• Integratie met de VS Code-terminal voor het draaien van complexe Buildx-commando’s.

Afbeelding 11 - Docker-extensie voor VSCode

Hier is een voorbeeld van het aanpassen van VS Code-taken om Buildx te gebruiken door een bestand .vscode/tasks.json te maken:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Docker: Buildx Build",
      "type": "shell",
      "command": "docker buildx build --load -t ${input:imageName} .",
      "group": {
        "kind": "build",
        "isDefault": true
      }
    },
    {
      "label": "Docker: Buildx Multi-Platform",
      "type": "shell",
      "command": "docker buildx build --platform linux/amd64,linux/arm64 -t ${input:imageName} ."
    }
  ],
  "inputs": [
    {
      "id": "imageName",
      "description": "Image name (with tag):",
      "default": "myapp:latest",
      "type": "promptString"
    }
  ]
}Mogelijk gemaakt door

Met deze configuratie heb je snel toegang tot veelvoorkomende Buildx-commando’s via het Tasks-menu in VS Code (Terminal > Run Task). De extensie levert ook handige syntax highlighting voor Dockerfiles en autocompletion voor veelgebruikte Dockercommando’s, wat je Buildx-workflow productiever maakt.

Troubleshooting en debuggen

Elk ontwikkeltool heeft soms (te vaak) troubleshooting nodig, en Docker Buildx is geen uitzondering. In dit onderdeel laat ik je een paar veelvoorkomende issues zien, zodat je ze snel zelf kunt diagnosticeren en verder kunt.

Veelvoorkomende issues en oplossingen

Bij het werken met Buildx kun je een paar veelvoorkomende uitdagingen tegenkomen. Dit zijn de meest frequente issues en hun oplossingen:

• Aanmaken van builder faalt. Krijg je fouten bij docker buildx create, check dan je Docker-versie:

docker versionMogelijk gemaakt door

Buildx vereist Docker 19.03 of nieuwer. Gebruik je een oudere versie, upgrade dan Docker om Buildx-features te gebruiken.

Krijg je "no such plugin"-fouten, controleer dan of Buildx correct is geïnstalleerd met:

docker buildx versionMogelijk gemaakt door

• Fouten bij multi-platform builds. Bij fouten als "exec format error" of "no matching manifest" tijdens multi-platform builds, check of QEMU is geïnstalleerd:

docker buildx inspect --bootstrapMogelijk gemaakt door

Installeer indien nodig platformemulators:

docker run --privileged --rm tonistiigi/binfmt --install allMogelijk gemaakt door

• Cache-gerelateerde issues. Bij problemen met caching kun je je lokale buildcache opschonen:

# Verwijder cache van een specifieke builder
docker buildx prune -b mybuilder

# Verwijder alle buildcache
docker buildx prune --allMogelijk gemaakt door

> Wat doet het Docker prune-commando precies? Leer het met veel hands-on voorbeelden.

• Problemen met verbinding naar de BuildKit-daemon. Zie je "failed to solve" of verbindingsfouten, herstart dan de builder:

docker buildx rm mybuilder
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrapMogelijk gemaakt door

• Prestatieproblemen. Bij trage builds kun je de debugoutput gebruiken om bottlenecks te vinden:

docker buildx build --progress=plain --no-cache .Mogelijk gemaakt door

Deze uitgebreide output helpt te achterhalen welke buildstages het meest tijd kosten, zodat je je Dockerfile gericht kunt optimaliseren.

• Fouten bij "load"-commando. Krijg je "error: docker exporter does not currently support exporting manifest lists" bij --load met multi-platform builds, onthoud dan dat het tegelijk laden van meerdere platforms in de Docker-daemon niet wordt ondersteund. In plaats daarvan:

# Bouw voor je huidige platform en laad het
docker buildx build --platform linux/amd64 --load -t myapp:latest .Mogelijk gemaakt door

• Debugpraktijken. Voor complexere issues helpen deze debugaanpakken:

# Schakel BuildKit-debuglogs in
BUILDKIT_DEBUG=1 docker buildx build .

# Inspecteer de interne status van de builder
docker buildx inspect

# Check systeemeisen
docker info

# Bouw alleen tot de problematische stage
docker buildx build --target problem-stage .

# Verifieer je Dockercontext
docker context lsMogelijk gemaakt door

Door deze troubleshootingstappen systematisch te doorlopen, los je de meeste Buildx-issues op en houd je een efficiënte containerbuildworkflow in stand.

Samenvatting van de Docker Buildx-gids

We hebben veel behandeld in dit Docker Buildx-artikel! Je hebt gezien hoe deze krachtige tool je containerbuilds sneller en flexibeler maakt.

Onthoud de belangrijkste voordelen: je kunt met één commando images voor meerdere platforms bouwen, je builds versnellen met geavanceerde caching en je images veilig houden met goed secretbeheer. De prestatieverbeteringen zijn echt, vooral als je je Dockerfiles zo structureert dat parallel bouwen mogelijk is.

Ik gebruik het voortdurend op mijn MacBook met M-chip, omdat niet alle images beschikbaar zijn voor ARM.

Of je nu solodeveloper bent of onderdeel van een groot team, Buildx biedt tools die bij je workflow passen. Je kunt lokaal bouwen, builds over containers verdelen of zelfs opschalen naar Kubernetes-clusters naarmate je behoeften groeien.

Wil je meer leren over Docker en Docker Buildx, dan raad ik de volgende DataCamp-cursussen aan:

• Containerization and Virtualization Concepts
• Introduction to Docker
• Intermediate Docker
• Containerization and Virtualization with Docker and Kubernetes
• CI/CD for Machine Learning