Mi a build context és miért használunk .dockerignore fájlt?

Question

Accepted Answer

Amikor futtatod a `docker build` parancsot, a Docker elküldi a **build contextust** (a build könyvtárban lévő fájlokat) a daemonnak. A **.dockerignore** fájl kizárja a szükségtelen fájlokat ebből a contextusból — felgyorsítja az buildeket, csökkenti a képméretét, és megelőzi az érzékeny fájlok kiszivárgását.

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

A **build context** azoknak a fájloknak a halmaza, amelyeket a Docker elkülد a daemonnak a kép elkészítéséhez. A build könyvtárban lévő minden fájl bekerül, hacsak ki nem zárjuk — ezért egy túlterhelt context lassítja az egyes buildeket.

## .dockerignore — szükségtelen fájlok kizárása

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

A `.dockerignore` a `.gitignore`-hoz hasonlóan működik, fájlokat zárva ki a build contextusból.

## Miért fontos (három előny)

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

## Miért fontos

A build context és a `.dockerignore` megértése értékes az **hatékony és biztonságos Docker buildekhez**, így gyakorlatilag hasznos tudás.

Sok fejlesztő nem tudja, hogy a `docker build .` az **egész build-context könyvtárat elküldi a daemonnak** az építés előtt — ezért egy túlterhelt context (amely tartalmaz `node_modules`-t, `.git`-et, build artifactokat, nagy fájlokat) **minden buildnél lassabbá tesz** (több adat átvitelét és feldolgozását) és kockáztat azzal, hogy nem kívánt fájlok kerüljenek be a képbe.

A **`.dockerignore`** fájl (a `.gitignore`-hez hasonlóan működve) három konkrét előnnyel oldja meg ezt: **gyorsabb buildek** (egy kisebb context gyorsabban kerül átadásra és feldolgozásra, valamint javítja a réteg gyorsítótárazását, mivel a `COPY . .` nem érvénytelenedik az irreleváns fájlok változásai miatt), **kisebb képek** (a kizárt fájlok nem másolódnak be — például nem csomagoljuk a helyi `node_modules`-t, amely úgyis újratelepül), és kritikusan fontos a **biztonság** (titkok, mint a `.env` fájlok, kulcsok és hitelesítő adatok maradnak ki a build contextusból és képből** — mivel egy `COPY . .` egyébként `.env` fájlt másolna be a képbe, igazi és gyakori hitelesítő adatszivárgási kockázat).

Ez a biztonsági előny különösen fontos, mivel a titkok vagy érzékeny fájlok véletlenül történő beépítése a képekbe egy általános másolás révén valódi hiba, amelyet a `.dockerignore` segít megelőzni.

Mivel a buildek folyamatosan történnek, a build hatékonysága, a kép mérete és a titkokból eredő szivárgások megelőzése mind fontosak, valamint a build context és a `.dockerignore` megértése közvetlenül javít mindhárom aspektust, a build context és a `.dockerignore` megértése értékes, gyakorlatilag releváns Docker tudás — egyszerű, de fontos gyakorlat a gyors, lean és biztonságos buildekhez, amely könnyen figyelmen kívül marad, mégis érdemben jelentős hatású, különösen a titkoknak a képekbe történő véletlen bekerülésének megelőzésében.