Dockerfile: online linten und formatieren (Hadolint)

Dockerfile: online linten und formatieren (Hadolint)

Erkennen Sie Docker-Anti-Patterns (Root-User, Cache-Layer, Tag `latest`) und formatieren Sie Dockerfiles vor der CI.

14.07.2026
10 Min. Lektüre
Teilen Sie diesen Artikel:
docker
dockerfile
hadolint
DevOps
lint
containers
Anleitung

Warum Dockerfile vor der CI linten und formatieren?

Ein Dockerfile baut Ihr Image Schicht für Schicht. Ein vergessenes `USER root`, ein schwimmendes Tag `latest` oder viele hintereinander folgende `RUN`-Schritte blähen das Image auf, schwächen den BuildKit-Cache und lassen Hadolint in der Pipeline scheitern — oft zu spät. Formatieren und Linten vor dem Öffnen der PR reduziert CI-Rauschen und hält das Team auf denselben Konventionen. Auf FastMinify können Sie ein Dockerfile online linten (DL-Regeln im Hadolint-Stil) und online formatieren — vollständig im Browser. Der gesamte Cluster liegt im Hub DevOps-Werkzeuge, neben Terraform, Compose und `.env`.

Docker-Anti-Patterns vor dem Hadolint-CI-Job erkennen
Sauberere PR-Diffs durch normalisierte Schreibweise und Abstände
Schneller Workflow für Dockerfiles außerhalb des Monorepos
Nützliche Ergänzung zu lokalem Hadolint / dockerfile-utils
Gleicher Hub wie HCL, Compose und `.env`-Validierung

Häufige DL-Regeln und Workflow vor der PR

Anti-Patterns, die Lint oft findet

Einige Codes tauchen in fast jedem Team auf. Früh korrigieren verhindert eine Wand aus Hadolint-Warnungen in der CI.

DL3007 — Tag oder Digest pinnen; `FROM …:latest` vermeiden
DL3002 — letzter USER sollte nicht root sein (außer begründet)
DL3020 — COPY statt ADD für lokale Dateien
DL3059 — aufeinanderfolgende RUN-Schritte zusammenführen
DL3008 / DL3013 — apt- / pip-Versionen pinnen, wenn es zählt
Team und CI

Pinnen Sie Hadolint (Image oder Binary) und lassen Sie die Pipeline bei Ihrer Severity-Policy scheitern. Der Browser bleibt ein schneller Filter außerhalb des Monorepos.

Hadolint auf jede PR ausführen, die ein Dockerfile berührt
Ausnahme-Ignores (`.hadolint.yaml`) in der PR dokumentieren
Vor dem Lint formatieren für klarere Meldungen
Zugehöriges Terraform / HCL über den Guide Terraform und HCL online verknüpfen
Frontend-Assets in derselben Pipeline automatisieren — siehe Minifizierung in CI/CD
Den FastMinify-DevOps-Hub für Compose und `.env` nutzen

Lint vs. Format vs. Build

Die richtige Aktion wählen

Format, Lint und `docker build` ergänzen sich. Im Review: formatieren, linten, dann die CI bauen lassen.

Ziel

format:Lesbarkeit und stabile Diffs
validate:DL-Best-Practices (Hadolint-Stil)
minify:Echtes Image + BuildKit-Cache

Wann nutzen

format:Nach manuellen Edits / Konflikten
validate:Vor jeder Dockerfile-PR
minify:In der CI oder auf einem Test-Workspace
Empfohlene Reihenfolge

Eine einfache Sequenz vermeidet, Stil nach dem Lint im Kreis zu korrigieren.

Dockerfile schreiben oder einfügen
Formatieren für stabile Schreibweise und Abstände
Linten (Browser, dann Hadolint-CLI wenn möglich)
Zugehörige Compose- / `.env`-Dateien bei Bedarf validieren
`docker build` (oder buildx) in einer Testumgebung ausführen

Wann das Browser-Tool genügt

Häufige Szenarien

Sie müssen das Monorepo nicht klonen, um drei aus Slack eingefügte Anweisungen zu korrigieren.

Dockerfile aus einem Ticket neu formatieren
DL-Regeln prüfen, bevor eine PR ohne lokales Hadolint geöffnet wird
Lehrbeispiel oder öffentlichen Gist vorbereiten
Zwei Versionen nach einem Merge-Konflikt schnell vergleichen
Kurz-Review eines Vendor- / Template-Dockerfiles

Grenzen: was der Browser nicht ersetzt

Hadolint-CLI und der echte Build

Sobald Sie Team-Config (Ignores, Severity), tiefere Shell-Analyse in RUN oder Multi-Stage-Builds mit BuildKit-Secrets brauchen, bleiben CLI und CI Pflicht.

Hadolint mit `.hadolint.yaml` und Ignore-Policy
ShellCheck / tiefere Analyse von Skripten in RUN
`docker build` / buildx mit Cache und gemounteten Secrets
Image-CVE-Scan (Trivy, Grype…) außerhalb des DL-Lint-Scopes
Registry-Credentials: nur CI-Secrets — nie online einfügen
Benachbarte Dateien

Ein Service kommt oft mit Compose, `.env` und HCL. Dockerfile-Format/Lint + Compose/Env-Validate + Terraform-Format decken den täglichen DevOps-Pfad ab.

Compose vor `compose up` validieren
`.env` auf Syntaxfehler prüfen
Zugehöriges Terraform-HCL formatieren / validieren
Gemeinsame Einrückungskonvention im Repo halten
Das formatierte Dockerfile als Git-Quelle behandeln, nicht als Build-Log-Rauschen

CLI und Ökosystem

Lokale Referenz-Tools

Hadolint und dockerfile-utils bleiben der Enterprise-Standard. FastMinify-Tools ergänzen Exploration und One-Shots.

Hadolint

Referenz-Dockerfile-Linter mit DL-Regeln und CI-Integration.

Pros:
Reifes Ökosystem und dokumentierte DL-IDs
`.hadolint.yaml` für Team-Policy
Docker-Image / Binary / GitHub Action
Cons:
Installation oder CI-Packaging nötig
Unpraktischer für Snippets außerhalb des Repos

dockerfile-utils / Formatierer

Stil-Normalisierung (Großschreibung, Abstände) im Editor oder CLI.

Pros:
Stabile Review-Diffs
Ergänzt Lint ohne den Build zu ändern
Passt zu Pre-Commit-Hooks
Cons:
Ersetzt keine DL-Regeln
Tooling variiert je nach Editor

BuildKit / buildx

Moderne Build-Engine: Cache, Multi-Platform, Secrets.

Pros:
Schnellere, reproduzierbarere Builds
Secrets ohne Einbrennen in einen Layer
Aktueller Docker-Standard
Cons:
Außerhalb des Text-Linter-Scopes
Braucht konfigurierten Daemon / CI

Dockerfile-Anatomie: Anweisungen und Layer

Häufige Anweisungen

Ein Dockerfile ist eine Folge von Anweisungen (`FROM`, `RUN`, `COPY`, `WORKDIR`, `USER`, `CMD`…). Anweisungen, die das Dateisystem ändern, erzeugen Layer. Die Reihenfolge zählt für den Cache: häufige Änderungen (App-Code) sollten nach stabilen Layern (OS-Pakete) kommen. Für benachbartes YAML (`compose.yml`) die Struktur vor `docker compose up` prüfen.

FROM pinnt eine Basis (image:tag oder Digest) — vermeiden Sie `latest` in Produktion
RUN kombiniert oft apt/apk + Aufräumen in einem Layer
COPY statt ADD für einfache lokale Dateien
Nicht-root USER am Ende verringert die Angriffsfläche
CMD / ENTRYPOINT in JSON-Exec-Form (`["node", "app.js"]`)
Was Browser-Lint nicht ersetzt

Der FastMinify-Linter wendet eine <strong>dokumentierte Teilmenge</strong> der Hadolint-DL-Regeln an (Wiki-IDs). Er führt kein ShellCheck in jedem `RUN` aus, baut kein Image und spricht nicht mit einer Remote-Registry. In der CI bleibt die Hadolint-CLI (oder die GitHub Action) die Quelle der Wahrheit.

Keine vollständige ShellCheck-Analyse von Shell-Skripten in RUN
Kein `docker build` und kein Image-CVE-Scan
Keine Compose-Schema-Validierung in diesem Tool (eigene Seite)
Gut als erster DL- + Format-Filter; die CI bleibt maßgeblich
Niemals Secrets / Tokens in ein öffentliches Textfeld einfügen

Lint und Format: zwei unterschiedliche Absichten

Linten (DL-Regeln im Hadolint-Stil)

Der Linter meldet Issues mit DL-Codes (z. B. DL3007 für `latest`, DL3002 für finalen Root-User) und Links zum Hadolint-Wiki. Ideal zum Einfügen eines Dockerfiles und Korrigieren vor der PR. Probieren Sie den Online-Dockerfile-Linter.

DL-IDs an Hadolint angelehnt für umsetzbare Meldungen
Warn-/Info-Stufen je nach Regel
Hadolint-Wiki-Links zu jedem Code
Gut für ein Single-Stage-Dockerfile oder einen Ausschnitt
Ersetzt nicht Hadolint-CLI + Team-Policy in der CI
Formatieren (dockerfile-utils-Normalisierung)

Der Formatierer normalisiert Großschreibung der Anweisungen und Abstände für stabile Diffs — ohne die Build-Semantik zu ändern. Nutzen Sie den Online-Dockerfile-Formatierer, bevor Sie eine manuell bearbeitete Datei committen.

Konsistente Großschreibung der Anweisungen
Normalisierte Abstände und Ausrichtung
Ideal nach einem Merge-Konflikt am Dockerfile
Passt zum Lint: zuerst formatieren, dann linten
Im Repo mit lokalem Format oder CI-Gate kombinieren
Compose und `.env` desselben Projekts

Ein Dockerfile steht selten allein. Validieren Sie auch Docker Compose online und prüfen Sie `.env`-Dateien vor einem lokalen Deploy.

Compose-Struktur (services, image) — nicht die vollständige Spec
`.env`-Syntax ohne fortgeschrittenen Secret-Scan
Gleicher DevOps-Hub für einen täglichen Pfad
Nützlich vor `docker compose up` auf einer neuen Maschine
Secrets aus dem Repo und aus Online-Tools fernhalten

Fazit

Dockerfile vor der CI zu linten und zu formatieren vermeidet unnötige Roundtrips bei DL-Regeln und Stil. Nutzen Sie den Browser für Snippets und den ersten Hadolint-Stil-Filter, dann Hadolint-CLI und `docker build` für die Pipeline-Wahrheit. Weiter mit Compose, `.env` und Terraform im selben DevOps-Hub.

Linten oder formatieren Sie Ihr Dockerfile jetzt

Vor dem Lint formatieren für klare Diffs und Meldungen
DL3007 / DL3002 / DL3020 früh im Review korrigieren
Hadolint pinnen und CI an der Team-Policy scheitern lassen
Compose und `.env` desselben Services validieren
Niemals Secrets in ein Online-Tool einfügen
Teilen Sie diesen Artikel
Teilen Sie diesen Artikel: