Hvad er build context, og hvorfor skal man bruge en .dockerignore-fil?

Question

Accepted Answer

Når du kører `docker build`, sender Docker **build context** (filerne i build-mappen) til daemon'en. En **.dockerignore**-fil udelukker unødvendige filer fra denne kontekst — hvilket accelererer builds, reducerer image-størrelse og undgår at lække følsomme filer.

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

**Build context** er det sæt af filer, som Docker sender til daemon'en for at bygge image'et. Alt i build-mappen inkluderes, medmindre det udelukkes — så en oppustet kontekst bremser hvert build.

## .dockerignore — udeluk unødvendige filer

```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` fungerer som `.gitignore`, idet den udelukker filer fra build context.

## Hvorfor det betyder noget (tre fordele)

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

## Hvorfor det betyder noget

At forstå build context og `.dockerignore` er værdifuldt for **effektive og sikre Docker-builds**, så det er praktisk brugbar viden.

Mange udvikler indser ikke, at `docker build .` sender **hele build-context-mappen til daemon'en** før bygningen starter — så en oppustet kontekst (indeholdende `node_modules`, `.git`, build-artefakter, store filer) gør **hvert build langsommere** (mere data at overføre og behandle) og risikerer at kopiere uønskede filer ind i image'et.

**.dockerignore**-filen (der fungerer som `.gitignore`) løser dette med tre konkrete fordele: **hurtigere builds** (en mindre kontekst overføres og behandles hurtigere, og forbedrer også layer-caching, da `COPY . .` ikke bliver invalideret af ændringer i irrelevante filer), **mindre images** (udelukkede filer bliver ikke kopieret ind — f.eks. ikke bundling af lokale `node_modules`, som alligevel bliver geninstalleret), og afgørende **sikkerhed** (at holde **hemmeligheder som `.env`-filer, nøgler og loginoplysninger ud af build context og image** — da en `COPY . .` ellers ville kopiere en `.env` ind i image'et, en reel og almindelig lækage af loginoplysninger).

Denne sikkerhedsfordel er særlig vigtig, da det at versehentligt bage hemmeligheder eller følsomme filer ind i images via en for bred copy er en ægte fejl, som `.dockerignore` hjælper med at forhindre.

Da builds sker konstant, og build-effektivitet, image-størrelse og undgåelse af lækage af hemmeligheder betyder noget, og da forståelse af build context og brugen af `.dockerignore` direkte forbedrer alle tre, er forståelse af build context og `.dockerignore` værdifuld, praktisk relevant Docker-viden — en simpel men vigtig praksis for hurtige, slanke og sikre builds, som er let at overse, men som har betydelig indflydelse, især for at forhindre utilsigtet medtagelse af hemmeligheder i images.