Hva er build-konteksten og hvorfor bruke en .dockerignore-fil?

Question

Accepted Answer

Når du kjører `docker build`, sender Docker **build-konteksten** (filene i build-mappen) til daemonen. En **.dockerignore**-fil ekskluderer unødvendige filer fra denne konteksten — og gjør bygg raskere, reduserer bildestørrelsen og forhindrer lekkasje av sensitive filer.

## Build-konteksten

```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-konteksten** er settet med filer Docker sender til daemonen for å bygge bildet. Alt i build-mappen inkluderes med mindre det ekskluderes — så en oppsvulmet kontekst bremser hvert bygg.

## .dockerignore — ekskluder 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` og ekskluderer filer fra build-konteksten.

## Hvorfor det betyr noe (tre fordeler)

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

Å forstå build-konteksten og `.dockerignore` er verdifullt for **effektive og sikre Docker-bygg**, så det er praktisk anvendbar kunnskap.

Mangt utviklere innser ikke at `docker build .` sender **hele build-kontekst-mappen til daemonen** før bygging — så en oppsvulmet kontekst (som inneholder `node_modules`, `.git`, bygg-artefakter, store filer) gjør **hvert bygg langsommere** (mer data å overføre og behandle) og risikerer å kopiere uønskede filer inn i bildet.

**.dockerignore**-filen (som fungerer som `.gitignore`) løser dette med tre konkrete fordeler: **raskere bygg** (en mindre kontekst overføres og behandles raskere, og forbedrer også layer-caching siden `COPY . .` ikke blir ugyldig av endringer i irrelevante filer), **mindre bilder** (ekskluderte filer kopieres ikke — for eksempel bundler vi ikke lokale `node_modules` som blir reinstallert uansett), og kritisk **sikkerhet** (holder **hemmeligheter som `.env`-filer, nøkler og legitimasjon utenfor build-konteksten og bildet** — siden en `COPY . .` ellers ville kopiert en `.env` inn i bildet, en reell og vanlig risiko for legitimasjonslekk).

Denne sikkerhetfordelen er særlig viktig, siden det å utilsiktet bake hemmeligheter eller sensitive filer inn i bilder via en for bred kopi er en genuin feil som `.dockerignore` bidrar til å forhindre.

Siden bygg skjer konstant og bygg-effektivitet, bildestørrelse og unngåelse av hemmelighetslekkasje alle betyr noe, og siden å forstå build-konteksten og bruke `.dockerignore` direkte forbedrer alle tre, er forståelse av build-konteksten og `.dockerignore` verdifull, praktisk relevant Docker-kunnskap — en enkel men viktig praksis for raske, magre og sikre bygg som er lett å overse likevel meningsfullt virkningsfull, spesielt for å forhindre utilsiktet inkludering av hemmeligheter i bilder.