Was ist der Build-Kontext und warum wird eine .dockerignore-Datei verwendet?

Question

Accepted Answer

Wenn Sie `docker build` ausführen, sendet Docker den **Build-Kontext** (die Dateien im Build-Verzeichnis) an den Daemon. Eine **.dockerignore**-Datei schließt unnötige Dateien aus diesem Kontext aus — wodurch Builds beschleunigt, die Bildgröße reduziert und das Lecken sensibler Dateien vermieden wird.

## Der Build-Kontext

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

Der **Build-Kontext** ist die Menge der Dateien, die Docker an den Daemon sendet, um das Image zu erstellen. Alles im Build-Verzeichnis ist enthalten, es sei denn, es wird ausgeschlossen — daher verlangsamt ein überladener Kontext jeden Build.

## .dockerignore — unnötige Dateien ausschließen

```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` funktioniert wie `.gitignore` und schließt Dateien aus dem Build-Kontext aus.

## Warum es wichtig ist (drei Vorteile)

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

## Warum es wichtig ist

Das Verständnis des Build-Kontexts und `.dockerignore` ist wertvoll für **effiziente und sichere Docker-Builds** und daher praktisch nützliches Wissen.

Viele Entwickler bemerken nicht, dass `docker build .` das **gesamte Build-Kontext-Verzeichnis an den Daemon sendet**, bevor es erstellt wird — daher verlangsamt ein überladener Kontext (der `node_modules`, `.git`, Build-Artefakte, große Dateien enthält) **jeden Build** (mehr Daten zum Übertragen und Verarbeiten) und riskiert, unerwünschte Dateien in das Image zu kopieren.

Die **`.dockerignore`**-Datei (funktioniert wie `.gitignore`) adressiert dies mit drei konkreten Vorteilen: **schnellere Builds** (ein kleinerer Kontext wird schneller übertragen und verarbeitet, und verbessert auch das Layer-Caching, da `COPY . .` nicht durch Änderungen an irrelevanten Dateien ungültig wird), **kleinere Images** (ausgeschlossene Dateien werden nicht kopiert — z. B. nicht das lokale `node_modules` bündeln, das ohnehin neu installiert wird), und entscheidend **Sicherheit** (wobei **Geheimnisse wie `.env`-Dateien, Schlüssel und Anmeldedaten aus dem Build-Kontext und Image herausgehalten werden** — da ein `COPY . .` sonst eine `.env` in das Image kopiert, ein echtes und häufiges Risiko für Credential-Lecks).

Dieser Sicherheitsvorteil ist besonders wichtig, da das versehentliche Einbinden von Geheimnissen oder sensiblen Dateien in Images über zu breites Kopieren ein echtes Fehlerrisiko ist, das `.dockerignore` hilft zu verhindern.

Da Builds ständig stattfinden und Build-Effizienz, Image-Größe und Vermeidung von Secret-Lecks alle wichtig sind, und da das Verständnis des Build-Kontexts und die Verwendung von `.dockerignore` alle drei direkt verbessert, ist das Verständnis des Build-Kontexts und `.dockerignore` wertvoll, praktisch relevantes Docker-Wissen — eine einfache, aber wichtige Praktik für schnelle, schlanke und sichere Builds, die leicht zu übersehen ist, aber sinnvoll wirkungsvoll, besonders zum Verhindern des versehentlichen Einschlusses von Geheimnissen in Images.