Wat is de build context en waarom een .dockerignore bestand gebruiken?

Question

Accepted Answer

Wanneer je `docker build` uitvoert, stuurt Docker de **build context** (de bestanden in de build directory) naar de daemon. Een **.dockerignore** bestand sluit onbenodigde bestanden uit deze context uit — waardoor builds sneller gaan, de image kleiner wordt, en het voorkomen van het lekken van gevoelige bestanden.

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

De **build context** is de set bestanden die Docker naar de daemon stuurt om de image te bouwen. Alles in de build directory is inbegrepen, tenzij uitgesloten — dus een omvangrijke context vertraagt elke build.

## .dockerignore — onbenodigde bestanden uitsluiten

```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` werkt net als `.gitignore` en sluit bestanden uit de build context uit.

## Waarom het belangrijk is (drie voordelen)

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

## Waarom het belangrijk is

Inzicht in de build context en `.dockerignore` is waardevol voor **efficiënte en veilige Docker builds**, dus het is praktisch bruikbare kennis.

Veel ontwikkelaars beseffen niet dat `docker build .` de **volledige build-context directory naar de daemon stuurt** voordat gebouwd wordt — dus een omvangrijke context (bevat `node_modules`, `.git`, build artifacts, grote bestanden) maakt **elke build langzamer** (meer data om over te dragen en te verwerken) en riskeert het kopieëren van ongewenste bestanden in de image.

Het **`.dockerignore`** bestand (werkend als `.gitignore`) lost dit op met drie concrete voordelen: **snellere builds** (een kleinere context draagt en verwerkt sneller over, en verbetert ook layer caching omdat `COPY . .` niet ongeldig wordt gemaakt door wijzigingen in irrelevante bestanden), **kleinere images** (uitgesloten bestanden worden niet gekopieerd — bijvoorbeeld niet bundelen van lokale `node_modules` die toch opnieuw worden geïnstalleerd), en cruciaal **beveiliging** (houden van **geheimen zoals `.env` bestanden, sleutels en inloggegevens uit de build context en image** — omdat een `COPY . .` anders een `.env` in de image zou kopieëren, een echt en veelvoorkomend risico voor het lekken van inloggegevens).

Dit beveiligingsvoordeel is bijzonder belangrijk, omdat per ongeluk geheimen of gevoelige bestanden in images inbakken via een te brede kopie een echt probleem is dat `.dockerignore` helpt voorkomen.

Omdat builds constant plaatsvinden en build efficiëntie, image grootte, en het voorkomen van het lekken van geheimen allemaal belangrijk zijn, en omdat het begrijpen van de build context en het gebruiken van `.dockerignore` alle drie direct verbetert, is het begrijpen van de build context en `.dockerignore` waardevol, praktisch relevant Docker-kennis — een eenvoudige maar belangrijke praktijk voor snelle, efficiënte en veilige builds die gemakkelijk over het hoofd kan worden gezien maar toch betekenisvol van invloed is, vooral voor het voorkomen van het onopzettelijk opnemen van geheimen in images.