Czym jest kontekst kompilacji i dlaczego używać pliku .dockerignore?

Question

Accepted Answer

Kiedy uruchamiasz `docker build`, Docker wysyła **kontekst kompilacji** (pliki w katalogu kompilacji) do demona. Plik **.dockerignore** wyklucza niepotrzebne pliki z tego kontekstu — przyspieszając kompilacje, zmniejszając rozmiar obrazu i unikając wycieków wrażliwych plików.

## Kontekst kompilacji

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

**Kontekst kompilacji** to zbiór plików, które Docker wysyła do demona w celu zbudowania obrazu. Wszystkie pliki w katalogu kompilacji są uwzględniane, chyba że zostaną wykluczone — zatem napuchnięty kontekst spowalnia każdą kompilację.

## .dockerignore — wyklucz niepotrzebne pliki

```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` działa jak `.gitignore`, wykluczając pliki z kontekstu kompilacji.

## Dlaczego to ważne (trzy korzyści)

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

## Dlaczego to ważne

Zrozumienie kontekstu kompilacji i `.dockerignore` jest wartościowe dla **wydajnych i bezpiecznych kompilacji Docker**, więc to praktycznie przydatna wiedza.

Wielu deweloperów nie zdaje sobie sprawy, że `docker build .` wysyła **cały katalog kontekstu kompilacji do demona** przed rozpoczęciem budowania — więc napuchnięty kontekst (zawierający `node_modules`, `.git`, artefakty kompilacji, duże pliki) sprawia, że **każda kompilacja jest wolniejsza** (więcej danych do przesłania i przetworzenia) i grozi skopiowaniem niechcianych plików do obrazu.

Plik **`.dockerignore`** (działający jak `.gitignore`) rozwiązuje ten problem dzięki trzem konkretnym korzyściom: **szybsze kompilacje** (mniejszy kontekst przesyła się i przetwarza szybciej, a także poprawia cachowanie warstw, ponieważ `COPY . .` nie zostanie unieważniony przez zmiany w nieistotnych plikach), **mniejsze obrazy** (wykluczone pliki nie są kopiowane — np. nie pakowanie lokalnego `node_modules`, który i tak zostanie przeinstalowany), i co ważne **bezpieczeństwo** (utrzymywanie **sekretów takich jak pliki `.env`, klucze i dane uwierzytelniające poza kontekstem kompilacji i obrazem** — ponieważ `COPY . .` skopiowałby inaczej `.env` do obrazu, to rzeczywiste i częste ryzyko wycieku poświadczeń).

Ta korzyść bezpieczeństwa jest szczególnie ważna, ponieważ przypadkowe zawieranie sekretów lub wrażliwych plików w obrazach poprzez zbyt szerokie kopiowanie to rzeczywisty błąd, któremu `.dockerignore` pomaga zapobiec.

Ponieważ kompilacje zachodzą stale, a wydajność kompilacji, rozmiar obrazu i unikanie wycieków sekretów wszystkie są ważne, i ponieważ zrozumienie kontekstu kompilacji i używanie `.dockerignore` bezpośrednio poprawia wszystkie trzy aspekty, zrozumienie kontekstu kompilacji i `.dockerignore` jest wartościową, praktycznie istotnią wiedzą Docker — prostą ale ważną praktyką dla szybkich, zwartych i bezpiecznych kompilacji, którą łatwo przeoczyć, a która ma znaczący wpływ, zwłaszcza w zapobieganiu przypadkowemu uwzględnieniu sekretów w obrazach.