Docker Buildx: come creare immagini container multi-piattaforma

Casi d'uso avanzati

Finora ti ho mostrato comandi e casi d’uso base di Buildx. Buildx può fare molto di più, e alcune funzionalità sono impossibili da implementare con il builder classico.

Vediamo alcune tecniche avanzate per portare il tuo workflow di containerizzazione al livello successivo.

Ottimizzazione delle build multi-stage

Le build multi-stage sono una delle caratteristiche più potenti di Docker per creare immagini efficienti, e Buildx le rende ancora migliori.

Per dimostrare, creiamo un’applicazione Python ottimizzata con più stage:

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

Con Buildx, puoi costruire il tutto in modo più efficiente:

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

Immagine 9 - Build multi-stage

Cosa rende speciale questo approccio? Buildx elabora in parallelo gli stage indipendenti. Mentre il builder legacy eseguirebbe ogni stage in sequenza, Buildx identifica che gli stage linter e tester non dipendono l’uno dall’altro e li costruisce simultaneamente.

Un ulteriore vantaggio di questa ottimizzazione è la riduzione delle dimensioni del file. Puoi verificare la dimensione dell’immagine eseguendo:

docker images myappOfferto da

Vedrai qualcosa del genere:

Immagine 10 - Dimensioni delle immagini Docker

L’immagine finale basata su alpine è molto più piccola.

Integrazione nelle pipeline CI/CD

Anche lavorando in locale, puoi impostare configurazioni Buildx che rispecchiano il tuo ambiente CI/CD.

Per iniziare, crea un file .dockerignore per mantenere pulite le build:

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

Poi crea uno script di build che imita ciò che potrebbe fare la tua pipeline CI:

#!/bin/bash
# build.sh - Simulazione CI/CD locale

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

# Setup builder con supporto all'emulazione
echo "Setting up builder..."
docker buildx create --name cibuilder --use || true
docker buildx inspect --bootstrap

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

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

# Build per più piattaforme
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!"Offerto da

In parole semplici, questo script fa quanto segue:

• Crea un builder dedicato per la CI/CD.
• Esegue lo stage di linting.
• Esegue lo stage di testing.
• Compila l’immagine finale multi-piattaforma con tag versionati.

Ora viene il bello: rendi eseguibile lo script ed eseguilo:

chmod +x build.sh
./build.shOfferto da

Modifica locale

Un punto dolente comune quando si lavora con Docker è che ogni volta che cambi un file sorgente devi ricompilare l’immagine ed eseguire il container. Richiede troppo tempo.

La buona notizia è che, per lo sviluppo locale con iterazioni più rapide, puoi creare una versione di sviluppo:

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

RUN pip install flask psutil python-dotenv

# Installa strumenti di sviluppo
RUN pip install pytest pylint watchdog

# Monta il codice dell'app a runtime invece di copiarlo
CMD ["python", "app.py"]Offerto da

Eseguila con un volume mount per il reload del codice in tempo reale:

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

Ora puoi modificare il file app.py in locale e le modifiche saranno immediatamente riflesse nel container in esecuzione!

A seguire, parliamo di performance.

Considerazioni sulle performance

Nessuno ama un workflow di sviluppo lento, e la potenza della parallelizzazione con Docker Buildx può aiutare.

Vediamo come ottimizzare le build e sfruttare le funzionalità di performance di Buildx per creare immagini più rapidamente.

Tecniche di parallelizzazione della build

Uno dei maggiori vantaggi di Buildx è la capacità di costruire gli stage in parallelo. Il builder tradizionale esegue ogni passaggio in sequenza, ma Buildx analizza il tuo Dockerfile e identifica quali step possono essere eseguiti contemporaneamente.

Per dimostrare, userò due file: Dockerfile.standard e Dockerfile.parallel. Ecco i contenuti di entrambi:

Dockerfile.standard

FROM python:3.13-slim
WORKDIR /app

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

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

# Codice dell'applicazione
COPY app.py .

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

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

Dockerfile.parallel

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

# Stage indipendente per installare le dipendenze di sistema
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/*

# Stage indipendente per installare le dipendenze Python
FROM python-base AS python-deps
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Stage indipendente per l'analisi statica del codice
FROM python-deps AS linting
COPY app.py .
RUN pip install pylint && pylint app.py || true

# Stage finale che combina le dipendenze
FROM python-base AS final
# Copia dallo stage delle dipendenze di sistema
COPY --from=system-deps /usr/bin/gcc /usr/bin/gcc
# Copia dallo stage delle dipendenze Python
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"]Offerto da

Misuriamo come questa struttura parallela migliori i tempi di build:

# Misura la build sequenziale standard
time docker build -t myapp:standard -f Dockerfile.standard .

# Misura la build ottimizzata in parallelo con Buildx
time docker buildx build --load -t myapp:parallel -f Dockerfile.parallel .Offerto da

Per riferimento, la build standard ha impiegato 18,48 secondi mentre quella parallela solo 1,17 secondi!

Per prestazioni ancora migliori, puoi provare a usare i flag --cache-from e --cache-to per sfruttare la cache su disco locale:

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

# Build successive - usa la cache
docker buildx build --load -t myapp:latest --cache-from type=local,src=./buildcache .Offerto da

Puoi anche limitare la dimensione del contesto con file .dockerignore ben curati:

# Crea un .dockerignore completo
cat > .dockerignore << 'EOF'
.git
.github
.dockerignore
.pytest_cache
__pycache__
*.pyc
*.pyo
*.pyd
.Python
venv
env
node_modules
.coverage
htmlcov
.DS_Store
EOFOfferto da

In poche parole, strutturando i Dockerfile con la parallelizzazione in mente e sfruttando il caching avanzato di Buildx, passerai meno tempo ad aspettare le build e più tempo a sviluppare funzionalità.

Integrazione nell'ecosistema

Docker Buildx non vive in isolamento. È progettato per integrarsi senza attriti con gli altri strumenti del tuo ambiente di sviluppo.

Vediamo come Buildx lavora con gli strumenti locali per sviluppatori e rende più efficiente il tuo workflow con i container.

Cluster di build Kubernetes

Kubernetes offre potenti capacità per eseguire operazioni Docker Buildx distribuite su un cluster. Integrando Buildx con Kubernetes, ottieni build più veloci e resilienti che scalano con le esigenze del progetto.

> Sei nuovo a Kubernetes? Il post Kubernetes vs Docker: differenze che ogni sviluppatore dovrebbe conoscere è la tua prossima tappa.

Usare Kubernetes per l’infrastruttura di build offre alcuni vantaggi:

1. Scalabilità automatica: Kubernetes può scalare i nodi builder in base alla domanda, allocando efficientemente le risorse nel cluster. Puoi anche impostare regole di autoscaling basate sull’utilizzo della CPU.
2. Ottimizzazione delle risorse: Il scheduling di Kubernetes assicura che le build ottengano le risorse necessarie senza sovraccaricare i singoli nodi. Puoi impostare limiti e richieste di risorse per prestazioni costanti.
3. Alta disponibilità: Distribuendo le istanze BuildKit su più nodi, l’infrastruttura di build resta disponibile anche se alcuni nodi vanno in errore.
4. Ambienti coerenti: Ogni membro del team si connette alla stessa infrastruttura di build, eliminando i problemi “sul mio PC funziona”.
5. Esecuzione in parallelo: Build complesse con molti stage possono essere eseguite in parallelo su più nodi, riducendo sensibilmente i tempi. Un progetto che localmente richiederebbe 15 minuti può essere completato in 3-4 minuti se distribuito.

Considera questa sezione più “teorica”, perché approfondire Kubernetes è di per sé un argomento avanzato.

Per iniziare, crea un file chiamato buildkit-deployment.yaml con il seguente contenuto:

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: buildkitOfferto da

Il passo successivo è applicare questo file al tuo cluster Kubernetes:

kubectl create namespace buildkit
kubectl apply -f buildkit-deployment.yamlOfferto da

Infine, connettiti a questa deployment dalla tua macchina locale:

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

E questo è tutto, sei pronto per partire!

Supporto dei plugin IDE

IDE come Visual Studio Code offrono un’eccellente integrazione con Docker Buildx tramite l’estensione Docker. Questa integrazione facilita la gestione dei workflow Buildx direttamente dall’ambiente di sviluppo.

Per iniziare con Docker Buildx in VS Code, installa l’estensione “Docker” dal marketplace di VS Code.

Una volta installata, avrai a disposizione diverse funzionalità specifiche per Buildx:

• Clic destro su qualsiasi Dockerfile per vedere un menu contestuale con l’opzione “Build Image...” che supporta Buildx.
• Accesso ad argomenti di build, target di piattaforma e opzioni di output tramite l’interfaccia.
• Possibilità di gestire e passare tra diverse istanze builder.
• Integrazione con il terminale di VS Code per eseguire comandi Buildx complessi.

Immagine 11 - Estensione Docker per VSCode

Ecco un esempio di personalizzazione dei task di VS Code per usare Buildx creando un file .vscode/tasks.json:

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

Con questa configurazione, puoi accedere rapidamente ai comandi Buildx più comuni dal menu Tasks di VS Code (Terminal > Run Task). L’estensione fornisce anche un utile syntax highlighting per i Dockerfile e l’autocompletamento per i comandi Docker più comuni, il tutto rendendo più produttivo il workflow con Buildx.

Risoluzione dei problemi e debug

Ogni strumento di sviluppo richiede talvolta (troppo spesso) una risoluzione dei problemi, e Docker Buildx non fa eccezione. In questa sezione, ti guiderò attraverso alcuni problemi comuni così potrai diagnosticarli rapidamente e tornare al lavoro.

Problemi comuni e soluzioni

Lavorando con Buildx potresti incontrare alcune sfide comuni. Ecco i problemi più frequenti e le loro soluzioni:

• Creazione del builder fallita. Se vedi errori creando un builder con docker buildx create, controlla la versione di Docker:

docker versionOfferto da

Buildx richiede Docker 19.03 o successivo. Se usi una versione precedente, aggiorna Docker per accedere alle funzionalità di Buildx.

Per errori “no such plugin”, assicurati che Buildx sia installato correttamente eseguendo:

docker buildx versionOfferto da

• Errore nelle build multi-piattaforma. Quando crei build per più piattaforme con errori come “exec format error” o “no matching manifest”, verifica se QEMU è installato:

docker buildx inspect --bootstrapOfferto da

Se necessario, installa gli emulatori di piattaforma:

docker run --privileged --rm tonistiigi/binfmt --install allOfferto da

• Problemi legati alla cache. In caso di problemi con la cache, prova a pulire la cache di build locale:

# Rimuovi la cache di uno specifico builder
docker buildx prune -b mybuilder

# Rimuovi tutta la cache di build
docker buildx prune --allOfferto da

> Cos’è esattamente il comando Docker prune? Scoprilo con una valanga di esempi pratici.

• Problemi di connessione al demone BuildKit. Se vedi “failed to solve” o errori di connessione, riavvia il builder:

docker buildx rm mybuilder
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrapOfferto da

• Problemi di performance. Per build lente, prova l’output di debug per identificare i colli di bottiglia:

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

Questo output dettagliato aiuta a individuare quali stage impiegano più tempo, permettendoti di ottimizzare di conseguenza il Dockerfile.

• Errori con il comando "load". Se incontri “error: docker exporter does not currently support exporting manifest lists” usando --load con build multi-piattaforma, ricorda che il caricamento di più piattaforme nel demone Docker simultaneamente non è supportato. In alternativa:

# Crea la build per la tua piattaforma corrente e caricala
docker buildx build --platform linux/amd64 --load -t myapp:latest .Offerto da

• Pratiche di debug. Per problemi più complessi, questi approcci di debug aiutano:

# Attiva i log di debug di BuildKit
BUILDKIT_DEBUG=1 docker buildx build .

# Ispeziona lo stato interno del builder
docker buildx inspect

# Verifica i requisiti di sistema
docker info

# Per errori in uno specifico stage, compila solo fino a quello stage
docker buildx build --target problem-stage .

# Verifica il tuo contesto Docker
docker context lsOfferto da

Lavorando in modo sistematico attraverso questi passaggi, puoi risolvere la maggior parte dei problemi con Buildx e mantenere efficiente il workflow di build dei container.

Riepilogo della guida a Docker Buildx

Abbiamo coperto un bel po’ di terreno in questo articolo su Docker Buildx! Hai visto come questo potente strumento può rendere le build dei container più rapide e flessibili.

Ricorda i vantaggi chiave: puoi creare immagini per più piattaforme con un solo comando, accelerare le build con caching avanzato e mantenere sicure le immagini con una corretta gestione dei secret. I miglioramenti prestazionali sono reali, soprattutto se strutturi i Dockerfile per sfruttare la build in parallelo.

Io lo uso sempre sul mio Macbook con chip M, dato che non tutte le immagini sono disponibili per ARM.

Che tu sia uno sviluppatore solista o parte di un grande team, Buildx ti offre strumenti che si adattano al tuo workflow. Puoi eseguire build in locale, distribuirle tra container o persino scalare su cluster Kubernetes man mano che le esigenze crescono.

Per approfondire Docker e Docker Buildx, ti consiglio di iscriverti ai seguenti corsi DataCamp:

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