Qu'est-ce que le contexte de build et pourquoi utiliser un fichier .dockerignore ?

Question

Accepted Answer

Quand vous exécutez `docker build`, Docker envoie le **contexte de build** (les fichiers du répertoire de build) au daemon. Un fichier **.dockerignore** exclut les fichiers inutiles de ce contexte — accélérant les builds, réduisant la taille de l'image et évitant de divulguer des fichiers sensibles.

## Le contexte de build

```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
```

Le **contexte de build** est l'ensemble des fichiers que Docker envoie au daemon pour construire l'image. Tout ce qui se trouve dans le répertoire de build est inclus sauf s'il est exclu — donc un contexte surdimensionné ralentit chaque build.

## .dockerignore — exclure les fichiers inutiles

```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` fonctionne comme `.gitignore`, excluant les fichiers du contexte de build.

## Pourquoi c'est important (trois bénéfices)

```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)
```

## Pourquoi c'est important

Comprendre le contexte de build et `.dockerignore` est précieux pour **des builds Docker efficaces et sécurisés**, c'est donc une connaissance pratiquement utile.

Beaucoup de développeurs ne réalisent pas que `docker build .` envoie **le répertoire entier du contexte de build au daemon** avant de construire — donc un contexte surdimensionné (contenant `node_modules`, `.git`, des artefacts de build, de grands fichiers) rend **chaque build plus lent** (plus de données à transférer et traiter) et risque de copier des fichiers non souhaités dans l'image.

Le fichier **`.dockerignore`** (fonctionnant comme `.gitignore`) résout cela avec trois bénéfices concrets : **des builds plus rapides** (un contexte plus petit se transfère et se traite plus vite, et améliore aussi la mise en cache des couches puisque `COPY . .` ne sera pas invalidé par les modifications de fichiers non pertinents), **des images plus petites** (les fichiers exclus ne sont pas copiés — par exemple, ne pas empaqueter les `node_modules` locaux qui sont réinstallés de toute façon), et crucialmente **la sécurité** (garder **les secrets comme les fichiers `.env`, les clés et les identifiants en dehors du contexte de build et de l'image** — puisqu'un `COPY . .` copierait sinon un `.env` dans l'image, un vrai risque courant de fuite d'identifiants).

Ce bénéfice de sécurité est particulièrement important, car intégrer accidentellement des secrets ou des fichiers sensibles dans les images via une copie trop permissive est une erreur réelle que `.dockerignore` aide à prévenir.

Puisque les builds se produisent constamment et que l'efficacité des builds, la taille de l'image et l'évitement des fuites de secrets importent tous, et puisque comprendre le contexte de build et utiliser `.dockerignore` améliore directement tous les trois, comprendre le contexte de build et `.dockerignore` est une connaissance Docker précieuse et pratiquement pertinente — une pratique simple mais importante pour des builds rapides, légers et sécurisés qui est facile à négliger mais pourtant significativement impactante, particulièrement pour prévenir l'inclusion accidentelle de secrets dans les images.