Build multi-stage per l’efficienza

Benvenuto all'ottimizzazione avanzata dei Dockerfile! Oggi esploreremo le multi-stage build, una tecnica potente per creare immagini Docker più piccole ed efficienti.

Le immagini più piccole consentono download più rapidi, maggiore sicurezza e un migliore utilizzo delle risorse.

Quando si crea un'immagine Docker, spesso include strumenti e dipendenze necessari solo durante il processo di build, ma non durante l'esecuzione finale dell'applicazione.

• Pull più veloci: le immagini più piccole vengono scaricate più rapidamente.
• Minore spazio su disco: si riduce lo spazio di archiviazione necessario nei registry e sugli host.
• Superficie di attacco ridotta: un numero inferiore di componenti comporta meno potenziali vulnerabilità.
• Maggiore sicurezza: l'immagine di produzione contiene solo ciò che è essenziale.

Consideri un'applicazione compilata, ad esempio una scritta in Go. Un Dockerfile tradizionale a singolo stage includerebbe nell'immagine finale l'intero compilatore Go e tutte le dipendenze di sviluppo.

Questo rende l'immagine finale molto più grande del necessario, poiché il compilatore non serve per eseguire il binario compilato.

Ecco una semplice applicazione Go e un Dockerfile che la crea in un singolo stage. Noti che l'ambiente di build è incluso nell'immagine finale.

main.go:

Questo Dockerfile utilizza `golang:1.21-alpine` come base. Dopo la creazione dell'applicazione, questa grande immagine di base, insieme a tutti gli strumenti di build, rimane nell'immagine finale.

Le build multi-stage risolvono questo problema consentendo di definire più istruzioni `FROM` in un singolo Dockerfile. Ogni `FROM` avvia un nuovo stage di build.

• Utilizzare la parola chiave AS per assegnare un nome a uno stage, ad esempio FROM golang:1.21-alpine AS builder.
• È quindi possibile copiare gli artifact da uno stage precedente utilizzando COPY --from=<stage_name>.

Solo lo stage finale viene salvato come immagine.

Un Dockerfile multi-stage tipico comprende almeno due stage:

• Build Stage: contiene tutti gli strumenti e il codice sorgente necessari per compilare l'applicazione.
• Runtime Stage: un'immagine di base minimale che include solo l'applicazione compilata e le relative dipendenze di runtime.

L'immagine intermedia dello stage di build viene eliminata, lasciando un'immagine finale leggera.

Riscriviamo il Dockerfile della nostra applicazione Go utilizzando un approccio multi-stage. Creeremo l'applicazione nel primo stage e copieremo quindi solo il binario compilato in un'immagine di base `alpine` molto più piccola.

Quando si crea questo Dockerfile, Docker esegue ogni stage. Tuttavia, solo il contenuto dell'ultima istruzione `FROM`, insieme ai file copiati dagli stage precedenti, costituisce l'immagine finale.

Il risultato è un'immagine significativamente più piccola rispetto a una build a singolo stage, perché il compilatore Go e gli strumenti di build vengono esclusi.

Le build multi-stage sono estremamente utili per:

• Linguaggi compilati: Go, Java, C++, Rust.
• Framework frontend: creare applicazioni React/Angular e distribuire asset statici con Nginx.
• Applicazioni Node.js: installare `node_modules` in uno stage di build, quindi copiare solo `package.json`, `package-lock.json` e l'applicazione creata in un'immagine di runtime minimale.

Quali dei seguenti sono i principali vantaggi dell'utilizzo delle build Docker multi-stage?

Ha imparato a utilizzare le build Docker multi-stage.

• Prevedono più istruzioni FROM in un singolo Dockerfile.
• La parola chiave AS assegna un nome agli stage e COPY --from= trasferisce gli artifact.
• Il vantaggio principale consiste in immagini finali molto più piccole, sicure ed efficienti.

Questa tecnica è fondamentale per ottimizzare le applicazioni containerizzate. Ora vedremo come sfruttare la cache delle build.