Cos'è il build context e perché usare un file .dockerignore?

Question

Accepted Answer

Quando esegui `docker build`, Docker invia il **build context** (i file nella directory di build) al daemon. Un file **.dockerignore** esclude i file non necessari da questo context — accelerando le build, riducendo la dimensione dell'immagine e evitando di esporre file sensibili.

## Il build context

```bash
docker build -t myapp .     # the "." is the build context — the directory sent to the daemon
# → Docker tarballs the ENTIRE context directory and sends it to the daemon BEFORE building
# → a big context (node_modules, .git, large files) = slow builds, more data transferred
```

Il **build context** è l'insieme di file che Docker invia al daemon per costruire l'immagine. Tutto nella directory di build è incluso a meno che non sia escluso — quindi un context sovraccarico rallenta ogni build.

## .dockerignore — escludere file non necessari

```text
# .dockerignore (like .gitignore, for the build context)
node_modules        # don't send local deps (they're installed in the image anyway)
.git                # don't send version history
*.log
.env                # ⚠️ don't send SECRETS into the build context/image
Dockerfile
dist
.vscode
```

`.dockerignore` funziona come `.gitignore`, escludendo file dal build context.

## Perché è importante (tre vantaggi)

```text
✓ FASTER builds — a smaller context transfers faster; fewer files to process
  (also helps caching: COPY . . won't be invalidated by irrelevant file changes)
✓ SMALLER images — excluded files (node_modules, .git) don't get COPYed into the image
✓ SECURITY — keep SECRETS (.env, keys, credentials) out of the context AND the image
  (a COPY . . could otherwise copy a .env file into the image — a real leak risk)
```

## Perché è importante

Comprendere il build context e `.dockerignore` è prezioso per **build Docker efficienti e sicure**, quindi è una conoscenza praticamente utile.

Molti sviluppatori non si rendono conto che `docker build .` invia **l'intera directory di build context al daemon** prima di costruire — quindi un context sovraccarico (contenente `node_modules`, `.git`, artefatti di build, file di grandi dimensioni) rende **ogni build più lenta** (più dati da trasferire ed elaborare) e rischia di copiare file indesiderati nell'immagine.

Il file **`.dockerignore`** (funzionando come `.gitignore`) affronta questo con tre vantaggi concreti: **build più veloce** (un context più piccolo si trasferisce ed elabora più velocemente, e migliora anche il caching dei layer poiché `COPY . .` non sarà invalidato da cambiamenti a file irrilevanti), **immagini più piccole** (i file esclusi non vengono copiati — per esempio non bundlando i `node_modules` locali che verranno reinstallati comunque), e crucialmente **sicurezza** (mantenendo **segreti come file `.env`, chiavi e credenziali fuori dal build context e dall'immagine** — poiché un `COPY . .` copierebbe altrimenti un `.env` nell'immagine, un rischio reale e comune di perdita di credenziali).

Questo beneficio di sicurezza è particolarmente importante, poiché incorporare accidentalmente segreti o file sensibili nelle immagini tramite una copia troppo ampia è un errore genuino che `.dockerignore` aiuta a prevenire.

Poiché le build accadono costantemente e l'efficienza della build, la dimensione dell'immagine e l'evitare perdite di segreti sono tutti importanti, e poiché la comprensione del build context e l'uso di `.dockerignore` migliorano direttamente tutti e tre, la comprensione del build context e `.dockerignore` è una conoscenza Docker preziosa e praticamente rilevante — una pratica semplice ma importante per build veloci, snelle e sicure che è facile trascurare ma significativamente impattante, specialmente per prevenire l'inclusione accidentale di segreti nelle immagini.