Come ottimizzi le dimensioni delle immagini Docker e le prestazioni di build?

Question

Accepted Answer

L'ottimizzazione delle immagini Docker implica ridurre le **dimensioni** (più piccole, più veloci, più sicure) e migliorare le **prestazioni di build** (build più veloci tramite caching). Le tecniche includono immagini base minime, build multi-stage, ottimizzazione dei layer, BuildKit e un design attento del Dockerfile.

## Riduzione delle dimensioni dell'immagine

```text
✓ MINIMAL base images:
  - alpine (tiny, ~5MB) — but musl libc can cause compatibility issues for some apps
  - slim variants (e.g. python:3.12-slim) — smaller than full, fewer compat issues
  - DISTROLESS — only the app + runtime, NO shell/package manager (smallest, most secure)
  - scratch — empty base (for static binaries, e.g. Go) → minimal image
✓ MULTI-STAGE builds — build with tools, ship only the artifact (huge size savings)
✓ Combine RUN layers + clean up IN the same layer:
  RUN apt-get update && apt-get install -y x && rm -rf /var/lib/apt/lists/*
  (cleanup in a SEPARATE layer doesn't shrink the image — the files are in the earlier layer)
✓ .dockerignore — keep junk out of the context/image
✓ Remove caches, temp files, dev dependencies in production images
```

## Miglioramento delle prestazioni di build

```text
✓ LAYER CACHING — order Dockerfile so stable layers (deps) come before volatile (code)
✓ BUILDKIT (DOCKER_BUILDKIT=1 / default in modern Docker) — faster, parallel builds,
  better caching, build secrets, cache mounts
✓ CACHE MOUNTS — RUN --mount=type=cache,target=/root/.npm npm install
  → persist package-manager caches BETWEEN builds (don't re-download every time)
✓ Registry cache / --cache-from — reuse cached layers in CI (where the cache is cold)
```

## Esempio multi-stage + distroless

```dockerfile
FROM golang:1.22 AS build
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o app .

FROM gcr.io/distroless/static     # no shell, no OS — tiny and secure
COPY --from=build /app/app /app
ENTRYPOINT ["/app"]
# → final image is a few MB: just the static binary (vs ~800MB with the full golang image)
```

## Perché è importante

L'ottimizzazione delle dimensioni delle immagini Docker e delle prestazioni di build è una conoscenza di livello senior preziosa perché impatta direttamente su **velocità di deployment, costi di archiviazione, sicurezza e produttività degli sviluppatori**, quindi è praticamente importante per la containerizzazione di qualità produttiva. **Ridurre le dimensioni dell'immagine** è importante perché le immagini più piccole si deployano e si scaricano più velocemente, costano meno da archiviare e sono **più sicure** (meno pacchetti = superficie di attacco più piccola): utilizzare **immagini base minime** (alpine, slim e soprattutto **distroless** — contenenti solo l'app e il runtime senza shell o package manager, le più piccole e sicure — oppure `scratch` per binari statici), **build multi-stage** (spedire solo gli artefatti) e un'**ottimizzazione attenta dei layer** (combinare i comandi RUN con la pulizia nello *stesso* layer, poiché la pulizia in un layer separato non riduce effettivamente l'immagine — un malinteso comune) possono ridurre drasticamente le immagini (ad es. da ~800MB a pochi MB). **Migliorare le prestazioni di build** è importante perché i build lenti danneggiano la produttività degli sviluppatori e il throughput della CI: sfruttare la **cache dei layer** (ordinare per stabile-prima-volatile), **BuildKit** (build paralleli più veloci con caching migliore) e soprattutto i **cache mount** (persistere le cache del package manager tra i build in modo che le dipendenze non vengono scaricate di nuovo ogni volta — un miglioramento significativo) e la cache del registro per la CI rendono tutti i build più veloci.

Comprendere queste tecniche — e punti sottili come perché la pulizia nello stesso layer è importante e come distroless migliora sia le dimensioni che la sicurezza — riflette la profondità necessaria per produrre immagini veramente ottimizzate.

Poiché le dimensioni dell'immagine e la velocità di build hanno un impatto reale e continuo sul deployment, sui costi, sulla sicurezza e sulla produttività, e poiché queste tecniche di ottimizzazione (basi minime/distroless, build multi-stage, pulizia corretta dei layer, cache mount di BuildKit) sono ciò che raggiunge immagini lean, veloci e sicure, la comprensione dell'ottimizzazione delle immagini e dei build Docker è una conoscenza di livello senior preziosa per la containerizzazione produttiva, una competenza chiave che distingue l'uso Docker professionale e ottimizzato e riflette l'expertise attesa per costruire immagini container efficienti e sicure su larga scala.