Docker Buildx: Wie man plattformübergreifende Container-Images erstellt

Erweiterte Anwendungsfälle

Bis jetzt habe ich dir die grundlegenden Buildx-Befehle und Anwendungsfälle gezeigt. Buildx kann noch viel mehr, und einige der Funktionen sind mit dem klassischen Builder nicht umsetzbar.

Lass uns einige fortgeschrittene Techniken erforschen, um deinen Containerisierungs-Workflow auf die nächste Stufe zu heben.

Mehrstufige Bauoptimierung

Mehrstufige Builds sind eine der mächtigsten Funktionen von Docker, um effiziente Images zu erstellen, und Buildx macht sie noch besser.

Zur Veranschaulichung wollen wir eine optimierte Python-Anwendung mit mehreren Stufen erstellen:

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

Mit Buildx kannst du diese effizienter bauen:

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

Bild 9 - Mehrstufige Bauwerke

Was ist also das Besondere daran? Buildx verarbeitet unabhängige Phasen parallel. Während der Legacy-Builder die einzelnen Phasen nacheinander ausführen würde, erkennt Buildx, dass die Phasen linter und tester nicht voneinander abhängen und baut sie gleichzeitig auf.

Ein weiterer Vorteil dieser Build-Optimierung ist die Verringerung der Dateigröße. Du kannst die Bildgröße überprüfen, indem du Folgendes ausführst:

docker images myapp

Du siehst dann so etwas wie das hier:

Abbildung 10 - Docker-Abbildgrößen

Das endgültige Bild in den Alpen ist viel kleiner.

Integration von CI/CD-Pipelines

Auch wenn du lokal arbeitest, kannst du Buildx-Konfigurationen einrichten, die deine CI/CD-Umgebung widerspiegeln.

Erstelle zunächst eine .dockerignore Datei, um die Builds sauber zu halten:

.git
__pycache__
*.pyc
*.pyo
*.pyd
.Python
env
venv
*.so
.coverage
htmlcov

Dann erstellst du ein Build-Skript, das nachahmt, was deine CI-Pipeline tun könnte:

#!/bin/bash
# build.sh - Local CI/CD simulation

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

# Setup builder with emulation support
echo "Setting up builder..."
docker buildx create --name cibuilder --use || true
docker buildx inspect --bootstrap

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

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

# Build for multiple 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!"

Im Klartext bedeutet das, dass dieses Skript Folgendes tut:

• Schafft einen eigenen Builder für CI/CD.
• Führt die Linting-Phase durch.
• Führt die Testphase durch.
• Erstellt das endgültige Multiplattform-Bild mit versionierten Tags.

Jetzt kommt der spaßige Teil: Mach das Skript ausführbar und führe es aus:

chmod +x build.sh
./build.sh

Lokale Redaktion

Ein häufiges Problem bei der Arbeit mit Docker ist, dass du jedes Mal, wenn du die Quelldatei änderst, das Image neu erstellen und den Container starten musst. Es braucht einfach zu viel Zeit.

Hier ist die gute Nachricht: Für die lokale Entwicklung mit schnelleren Iterationen kannst du eine Entwicklungsversion erstellen:

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

RUN pip install flask psutil python-dotenv

# Install development tools
RUN pip install pytest pylint watchdog

# Mount app code at runtime instead of copying
CMD ["python", "app.py"]

Führe ihn mit einem Volume Mount aus, um den Code live nachzuladen:

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

Jetzt kannst du deine app.py Datei lokal bearbeiten, und die Änderungen werden sofort in den laufenden Container übernommen!

Als Nächstes wollen wir über die Leistung sprechen.

Leistungsüberlegungen

Niemand mag einen langsamen Entwicklungsworkflow, und die Parallelisierung mit Docker Buildx kann dabei helfen.

Lass uns herausfinden, wie du deine Builds optimierst und die Leistungsfunktionen von Buildx nutzt, um Bilder schneller zu erstellen.

Parallelisierungstechniken aufbauen

Einer der größten Vorteile von Buildx ist die Möglichkeit, Stufen parallel zu bauen. Der traditionelle Docker-Builder führt jeden Schritt nacheinander aus, aber Buildx analysiert dein Dockerfile und erkennt, welche Schritte gleichzeitig ausgeführt werden können.

Zur Veranschaulichung nehme ich zwei Dateien - Dockerfile.standard und Dockerfile.parallel. Hier sind die Inhalte für beide:

Dockerfile.standard

FROM python:3.13-slim
WORKDIR /app

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

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

# Application code
COPY app.py .

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

EXPOSE 5000
CMD ["python", "app.py"]

Dockerfile.parallel

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

# Independent stage for installing system dependencies
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/*

# Independent stage for installing Python dependencies
FROM python-base AS python-deps
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Independent stage for static code analysis
FROM python-deps AS linting
COPY app.py .
RUN pip install pylint && pylint app.py || true

# Final stage that combines dependencies
FROM python-base AS final
# Copy from system deps stage
COPY --from=system-deps /usr/bin/gcc /usr/bin/gcc
# Copy from 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"]

Lass uns messen, wie diese parallele Struktur die Bauzeiten verbessert:

# Time the standard sequential build
time docker build -t myapp:standard -f Dockerfile.standard .

# Time the parallel-optimized build with Buildx
time docker buildx build --load -t myapp:parallel -f Dockerfile.parallel .

Zum Vergleich: Der Standard-Build dauerte 18,48 Sekunden, während der parallele Build nur 1,17 Sekunden benötigte!

Für eine noch bessere Leistung kannst du versuchen, die Flags --cache-from und --cache-to zu verwenden, um das lokale Festplatten-Caching zu nutzen:

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

# Subsequent builds - use cache
docker buildx build --load -t myapp:latest --cache-from type=local,src=./buildcache .

Du kannst die Größe des Kontexts auch mit sorgfältigen .dockerignore Dateien begrenzen:

# Create a comprehensive .dockerignore
cat > .dockerignore << 'EOF'
.git
.github
.dockerignore
.pytest_cache
__pycache__
*.pyc
*.pyo
*.pyd
.Python
venv
env
node_modules
.coverage
htmlcov
.DS_Store
EOF

Kurz gesagt: Wenn du deine Dockerdateien mit Blick auf die Parallelisierung strukturierst und das fortschrittliche Caching von Buildx nutzt, verbringst du weniger Zeit mit dem Warten auf Builds und mehr Zeit mit der Entwicklung von Funktionen.

Ökosystem-Integration

Docker Buildx existiert nicht in Isolation. Es ist so konzipiert, dass es sich nahtlos in andere Tools in deiner Entwicklungsumgebung integrieren lässt.

Lass uns herausfinden, wie Buildx mit lokalen Entwickler-Tools zusammenarbeitet und deinen Container-Workflow effizienter macht.

Kubernetes-Cluster erstellen

Kubernetes bietet leistungsstarke Funktionen für die Ausführung verteilter Docker Buildx-Operationen in einem Cluster. Wenn du Buildx mit Kubernetes integrierst, kannst du schnellere und stabilere Builds erstellen, die mit den Anforderungen deines Projekts skalieren.

> Bist du neu bei Kubernetes? Die Kubernetes vs. Docker: Unterschiede, die jeder Entwickler kennen sollte post ist dein nächster Halt.

Die Verwendung von Kubernetes für deine Build-Infrastruktur bietet eine Reihe von Vorteilen:

1. Automatische Skalierung: Kubernetes kann deine Builder Nodes je nach Bedarf hoch- oder runterskalieren und so die Ressourcen in deinem Cluster effizient zuweisen. Du kannst sogar Regeln für die automatische Skalierung basierend auf der CPU-Auslastung einrichten.
2. Ressourcenoptimierung: Das Kubernetes-Scheduling sorgt dafür, dass deine Builds die benötigten Ressourcen erhalten, ohne dass einzelne Nodes überlastet werden. Du kannst Ressourcenlimits und Anforderungen festlegen, um eine gleichbleibende Leistung zu gewährleisten.
3. Hohe Verfügbarkeit: Durch die Verteilung von BuildKit-Instanzen auf mehrere Nodes bleibt deine Build-Infrastruktur auch dann verfügbar, wenn einzelne Nodes ausfallen.
4. Konsistente Umgebungen: Jedes Teammitglied verbindet sich mit der gleichen Build-Infrastruktur, wodurch Probleme wie "funktioniert auf meinem Rechner" vermieden werden.
5. Parallele Ausführung: Komplexe Builds mit vielen Phasen können parallel auf mehreren Nodes ausgeführt werden, was die Buildzeiten erheblich verkürzt. Ein Projekt, das vor Ort vielleicht 15 Minuten dauert, kann bei der Verteilung in 3-4 Minuten fertig sein.

Betrachte dies als einen eher "theoretischen" Abschnitt, da ein tieferes Eintauchen in Kubernetes ein fortgeschrittenes Thema für sich ist.

Um loszulegen, erstelle eine Datei namens buildkit-deployment.yaml mit folgendem Inhalt:

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: buildkit

Der nächste Schritt besteht darin, diese Datei auf deinen Kubernetes-Cluster anzuwenden:

kubectl create namespace buildkit
kubectl apply -f buildkit-deployment.yaml

Verbinde dich schließlich von deinem lokalen Rechner aus mit dieser Bereitstellung:

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

Und das war's, du bist startklar!

IDE-Plugin-Unterstützung

IDEs wie Visual Studio Code bieten eine hervorragende Integration mit Docker Buildx durch die Docker-Erweiterung. Diese Integration macht es einfacher, deine Buildx-Workflows direkt von deiner Entwicklungsumgebung aus zu verwalten.

Um mit Docker Buildx in VS Code loszulegen, installiere die "Docker"-Erweiterung aus dem VS Code Marketplace.

Nach der Installation stehen dir mehrere Buildx-spezifische Funktionen zur Verfügung:

• Wenn du mit der rechten Maustaste auf eine Dockerdatei klickst, erscheint ein Kontextmenü mit der Option "Build Image...", die Buildx unterstützt.
• Zugriff auf Build-Argumente, Plattformziele und Ausgabeoptionen über die Benutzeroberfläche.
• Die Möglichkeit, zwischen verschiedenen Builder-Instanzen zu wechseln und diese zu verwalten.
• Integration mit dem VS Code-Terminal zur Ausführung komplexer Buildx-Befehle.

Abbildung 11 - Docker-Erweiterung für VSCode

Hier ist ein Beispiel für die Anpassung von VS Code-Aufgaben zur Verwendung von Buildx durch die Erstellung einer .vscode/tasks.json Datei:

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

Mit dieser Konfiguration kannst du schnell auf gängige Buildx-Befehle über das Menü VS Code Tasks(Terminal > Run Task) zugreifen. Die Erweiterung bietet außerdem eine hilfreiche Syntaxhervorhebung für Dockerdateien und eine Autovervollständigung für gängige Docker-Befehle, die deinen Buildx-Workflow noch produktiver machen.

Fehlerbehebung und Fehlersuche

Jedes Entwicklungswerkzeug benötigt manchmal (zu oft) eine Fehlerbehebung, und Docker Buildx ist da keine Ausnahme. In diesem Abschnitt gehe ich mit dir ein paar häufige Probleme durch, damit du sie schnell selbst diagnostizieren kannst und wieder auf den richtigen Weg kommst.

Häufige Probleme und Lösungen

Wenn du mit Buildx arbeitest, stößt du vielleicht auf ein paar gängige Herausforderungen. Hier sind die häufigsten Probleme und ihre Lösungen:

• Die Erstellung des Builders scheitert. Wenn du beim Erstellen eines Builders mit docker buildx create Fehler siehst, überprüfe deine Docker-Version:

docker version

Buildx erfordert Docker 19.03 oder neuer. Wenn du eine ältere Version verwendest, aktualisiere Docker, um die Buildx-Funktionen nutzen zu können.

Vergewissere dich bei Fehlern wie "kein solches Plugin", dass Buildx richtig installiert ist, indem du es ausführst:

docker buildx version

• Multiplattform-Build-Fehler. Wenn bei der Erstellung für mehrere Plattformen Fehler wie "exec format error" oder "no matching manifest" auftreten, prüfe, ob QEMU installiert ist:

docker buildx inspect --bootstrap

Falls nötig, installiere Plattform-Emulatoren:

docker run --privileged --rm tonistiigi/binfmt --install all

• Probleme mit dem Cache. Bei Problemen mit dem Caching kannst du versuchen, deinen lokalen Build-Cache zu löschen:

# Remove specific builder's cache
docker buildx prune -b mybuilder

# Remove all build cache
docker buildx prune --all

> Was genau ist der Docker-Befehl prune? Lerne mit einer Menge praktischer Beispiele.

• BuildKit Daemon Verbindungsprobleme. Wenn du "fehlgeschlagene Lösung" oder Verbindungsfehler siehst, starte den Builder neu:

docker buildx rm mybuilder
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrap

• Leistungsbezogene Fragen. Bei langsamen Builds kannst du die Debug-Ausgabe nutzen, um Engpässe zu identifizieren:

docker buildx build --progress=plain --no-cache .

Diese ausführliche Ausgabe hilft dir dabei, herauszufinden, welche Build-Phasen die meiste Zeit in Anspruch nehmen, damit du dein Dockerfile entsprechend optimieren kannst.

• Der Befehl "Laden" schlägt fehl. Wenn du bei der Verwendung von --load mit Multiplattform-Builds die Meldung "error: docker exporter does not currently support exporting manifest lists" erhältst, denke daran, dass das gleichzeitige Laden mehrerer Plattformen in den Docker-Daemon nicht unterstützt wird. Stattdessen:

# Build for your current platform and load it
docker buildx build --platform linux/amd64 --load -t myapp:latest .

• Praktiken der Fehlersuche. Bei komplexeren Problemen helfen diese Debugging-Ansätze:

# Enable BuildKit debug logs
BUILDKIT_DEBUG=1 docker buildx build .

# Inspect the builder's internal state
docker buildx inspect

# Check system requirements
docker info

# For specific stage failures, build only up to that stage
docker buildx build --target problem-stage .

# Verify your Docker context
docker context ls

Wenn du diese Schritte zur Fehlerbehebung systematisch durchgehst, kannst du die meisten Buildx-Probleme beheben und einen effizienten Container-Build-Workflow aufrechterhalten.

Zusammenfassung des Docker Buildx Guide

In diesem Docker Buildx-Artikel haben wir eine ganze Menge behandelt! Du hast gesehen, wie dieses leistungsstarke Tool deine Container-Builds schneller und flexibler machen kann.

Erinnere dich an die wichtigsten Vorteile: Du kannst Bilder für mehrere Plattformen mit einem einzigen Befehl erstellen, deine Builds mit fortschrittlichem Caching beschleunigen und deine Bilder mit einer angemessenen Geheimhaltung schützen. Die Leistungsverbesserungen sind real, vor allem wenn du deine Dockerdateien so strukturierst, dass du die Vorteile der parallelen Erstellung nutzen kannst.

Ich benutze sie ständig auf meinem M-Chip Macbook, da nicht alle Bilder für ARM verfügbar sind.

Egal, ob du ein Einzelentwickler oder Teil eines großen Teams bist, Buildx gibt dir Werkzeuge, die zu deinem Arbeitsablauf passen. Du kannst Builds lokal ausführen, sie auf Container verteilen oder sogar auf Kubernetes-Cluster skalieren, wenn dein Bedarf wächst.

Um mehr über Docker und Docker Buildx zu erfahren, empfehle ich dir, die folgenden DataCamp-Kurse zu besuchen:

• Konzepte für Containerisierung und Virtualisierung
• Einführung in Docker
• Docker für Fortgeschrittene
• Containerisierung und Virtualisierung mit Docker und Kubernetes
• CI/CD für maschinelles Lernen