dockerignore richtig nutzen - was nicht ins Image gehört

.dockerignore ist eine der unterschätztesten Optimierungen beim Docker-Build — sie hält unnötige Dateien aus dem Image heraus und beschleunigt den Build-Prozess messbar.

Was ist der Build-Kontext?

Wenn man docker build . ausführt, sendet Docker den gesamten Inhalt des angegebenen Verzeichnisses (.) als Build-Kontext an den Daemon. Alles in diesem Verzeichnis ist potenziell im Image — unabhängig davon, ob man COPY . . hat oder nicht. Erst die Übertragung selbst kostet Zeit und Speicher.

Ohne .dockerignore:

Sending build context to Docker daemon  450MB   ← node_modules, .git, Logs...

Mit .dockerignore:

Sending build context to Docker daemon  2.3MB

Syntax

.dockerignore funktioniert wie .gitignore:

# Kommentar
.git
node_modules
*.log
.env
.env.*
__pycache__
*.pyc
dist/
coverage/
.DS_Store

Negation mit !:

# Alles ignorieren außer src/ und package.json
*
!src/
!package.json
!package-lock.json

Typische Einträge

Node.js:

node_modules
npm-debug.log
.npm
dist
coverage

Python:

__pycache__
*.pyc
*.pyo
.venv
venv
.pytest_cache

Allgemein (fast immer sinnvoll):

.git
.gitignore
.env
.env.*
*.log
.DS_Store
Thumbs.db
README.md
docs/
tests/

Warum .env besonders wichtig ist

Eine .env-Datei, die API-Keys oder Datenbankpasswörter enthält, landet ohne .dockerignore im Build-Kontext. Falls COPY . . im Dockerfile steht, landet sie im Image — und damit in jeder Registry, in die das Image gepusht wird.

.env
.env.local
.env.production

Diese Zeilen gehören in jede .dockerignore.

Einfluss auf den Layer-Cache

.dockerignore beeinflusst auch, wann der Cache für COPY . . invalidiert wird. Dateien, die ausgeschlossen sind, können sich ändern ohne den Cache zu brechen — was gerade bei großen node_modules-Verzeichnissen den Build deutlich schneller macht.