7 Dockerfile-Fehler, die dein System still und leise sabotieren

Ein funktionierendes Dockerfile ist nur die halbe Miete. Was wie ein erfolgreicher Build aussieht, kaschiert oft langfristige Probleme: übermäßigen Ressourcenverbrauch, Sicherheitslücken oder unerwartete Kompatibilitätsprobleme. Die folgenden sieben Fallstricke fallen selten sofort auf – bis ein Audit, ein Incident oder die nächste Cloud-Rechnung sie unangenehm offenbart.

Unnötige Root-Rechte vermeiden

Standardmäßig läuft der Hauptprozess eines Containers mit Root-Rechten – ein potenziell gefährliches Szenario. Bei einem erfolgreichen Ausbruch aus dem Container erhält der Angreifer Root-Zugriff auf das Host-System. Die Lösung ist einfach: einen dedizierten, nicht-privilegierten Nutzer anlegen und die Anwendung unter dessen Rechten ausführen.

RUN useradd --system --uid 10001 appuser
USER appuser

Diese minimale Änderung schließt eine ganze Klasse von Sicherheitsrisiken aus, ohne die Funktionalität zu beeinträchtigen.

Veraltete Basisimages durch feste Versionen ersetzen

Die Verwendung von latest-Tags mag bequem erscheinen, doch sie führt zu unvorhersehbaren Build-Ergebnissen. Ein Container, der heute gebaut wird, kann morgen mit einer anderen Version desselben Basisimages enden – ohne dass sich das im Dockerfile ändert. Die Konsequenz sind inkonsistente Deployments und potenzielle Inkompatibilitäten.

FROM node:20.11.1-slim

Durch das explizite Festlegen einer Version oder sogar eines Image-Digests wird die Reproduzierbarkeit sichergestellt. Builds bleiben stabil, und plötzliche Änderungen in Abhängigkeiten werden vermieden.

Geheimnisse niemals im Image speichern

Umgebungsvariablen oder Konfigurationsdateien wie .env-Dateien in das Image zu kopieren, ist ein häufiger Fehler. Geheimnisse, die während des Builds eingebettet werden, verbleiben dauerhaft in den Image-Layern – selbst wenn sie später gelöscht werden. Jeder, der das Image pullt, kann diese Informationen extrahieren.

Stattdessen sollten Geheimnisse entweder über Build-Secrets (--mount=type=secret) oder erst zur Laufzeit injiziert werden. Diese Methode stellt sicher, dass sensible Daten niemals dauerhaft im Image gespeichert werden.

Die .dockerignore-Datei nicht unterschätzen

Ohne eine .dockerignore-Datei kopiert das Kommando COPY . . ungewollt sensible Daten wie .git-Verzeichnisse, lokale Konfigurationsdateien oder Testdaten in den Build-Kontext. Dies führt nicht nur zu einer unnötigen Vergrößerung des Images, sondern birgt auch das Risiko, dass sensible Informationen in die Image-Layer gelangen.

Eine einfache .dockerignore-Datei mit wenigen Einträgen kann hier Abhilfe schaffen:

• .git/
• node_modules/
• *.env
• *.log
• .vscode/

Diese Praxis spart Speicherplatz und reduziert potenzielle Sicherheitsrisiken.

Falsche Layer-Reihenfolge bremst den Build-Prozess aus

Ein häufiger Fehler ist die falsche Reihenfolge von Befehlen im Dockerfile. Wenn Abhängigkeiten wie package.json und node_modules nach dem eigentlichen Quellcode kopiert werden, führt jede Code-Änderung zu einem vollständigen Neuaufbau aller Abhängigkeiten. Dies verlängert die Build-Zeiten unnötig.

Die Lösung: Zuerst die statischen Dateien wie die Paketdatei und Abhängigkeiten kopieren und installieren, bevor der Rest des Quellcodes hinzugefügt wird.

COPY package*.json ./
RUN npm ci
COPY . .

Diese kleine Anpassung spart Zeit und optimiert den Build-Prozess erheblich.

Unnötige Paketmanager-Reste im Image belassen

Ein häufiger Fehler ist das Installieren von Paketen ohne anschließende Bereinigung der Cache-Dateien. Jede apt-get- oder apk add-Anweisung hinterlässt temporäre Dateien, die unnötig Speicherplatz verbrauchen und die Image-Größe vergrößern.

Die Lösung: Alle Befehle in einer einzigen RUN-Anweisung kombinieren und den Cache direkt nach der Installation bereinigen.

RUN apt-get update \
 && apt-get install -y --no-install-recommends curl \
 && rm -rf /var/lib/apt/lists/*

Diese Vorgehensweise reduziert die Image-Größe und verbessert die Effizienz.

Fehlende Healthchecks ignorieren

Ein Container gilt als "running", sobald der Hauptprozess gestartet ist – doch das bedeutet nicht, dass die Anwendung tatsächlich funktionsfähig ist. Ohne einen Healthcheck kann ein Container in einem fehlerhaften Zustand verharren, ohne dass das Orchestrierungssystem dies erkennt.

Ein Healthcheck überprüft regelmäßig den tatsächlichen Zustand der Anwendung und ermöglicht es dem System, nicht funktionsfähige Container automatisch neu zu starten.

HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f  || exit 1

Wichtig: Der Healthcheck sollte einen echten Endpunkt überprüfen, nicht nur die Verfügbarkeit des Webservers.

Fazit: Kleine Änderungen, große Wirkung

Keiner dieser Fehler führt zu einem Build-Fehler – sie manifestieren sich erst später in Form von Sicherheitslücken, langsamen Pipelines oder unerwartet großen Images. Die Lösungen sind jeweils nur wenige Zeilen Code lang, doch ihre Wirkung ist nachhaltig.

Um solche Fehler zu vermeiden, können Tools wie ein clientseitiger Validator oder eine Docker-Troubleshooting-Bibliothek helfen. Sie ermöglichen es, potenzielle Probleme bereits vor dem Deployment zu erkennen und zu beheben. Welcher dieser Fehler hat dich in der Vergangenheit am meisten überrascht?