Was dieser Linter macht
Ein Dockerfile, das technisch baut, ist nicht dasselbe wie ein Dockerfile, das ausgeliefert werden sollte. Das Image kann ein paar hundert MB apt-Cache-Reste mitziehen, die niemand nutzt. Es kann als root ohne HEALTHCHECK laufen, K8s erfaehrt also nie, dass der Container kaputt ist. Es kann `:latest`-Tags nutzen, die sich unter den Fuessen aendern. Es kann `ADD` nutzen, wo `COPY` sicherer waere. Nichts davon stoppt den Build, jedes Einzelne erzeugt in Produktion Schmerzen.
Dieser Linter laeuft hadolint-aehnliche Regeln im Browser. Dockerfile einfuegen, du bekommst eine Liste von Issues pro Zeile mit Rule-ID, Schweregrad, Beschreibung und einem Fix-Hinweis. Rund 20 Regeln aus dem Standard-hadolint-Katalog (`DL3000`, `DL3007`, `DL3008`, ...) plus ein paar Custom-Checks fuer fehlendes USER, fehlenden HEALTHCHECK und Image nicht per Digest gepinnt.
Alles laeuft client-seitig. Kein Upload, kein Build, kein Kontakt zum Docker-Daemon. Der Output ist die Art Feedback, die du von `hadolint Dockerfile` lokal bekommen wuerdest, nur im Browser-Tab.
So benutzt du es
- Dein Dockerfile ins Input-Panel einfuegen oder eines der Beispiele oben waehlen, um das Output-Format zu sehen.
- Die Error-/Warning-/Info-Zaehler oben rechts lesen. Klick auf ein Issue zeigt Zeilennummer und Fix-Hinweis. Jedes Issue traegt eine Rule-ID wie `DL3007`, mit der du die volle hadolint-Doku finden kannst.
- Typische Warnungen, die der Linter flaggt: `:latest`-Tag (`DL3007`), `apt-get install` ohne gepinnte Versionen (`DL3008`) und **ohne `rm -rf /var/lib/apt/lists/*` (`DL3009`), `MAINTAINER` (deprecated, `DL4000`), `ADD` fuer lokale Dateien, wo `COPY` sicherer ist (`DL3020`), `CMD` in Shell-Form statt JSON-Exec-Form (`DL3025`), `RUN cd ...`** statt `WORKDIR` (`DL3003`).
- Security-Checks: Container laeuft als root, wenn kein `USER` gesetzt ist, `privileged: true`-Patterns, Image nicht per Digest gepinnt, `HEALTHCHECK` fehlt in der finalen Stage.
- Das "fixed"-Panel unter den Issues nutzen, um eine Best-Effort-Umschrift der einfachen Faelle zu sehen: `MAINTAINER` wird zu `LABEL maintainer`, `ADD` wird zu `COPY`, wenn die Quelle lokal ist. Komplexere Fixes (Versionspinning, HEALTHCHECK ergaenzen, RUN aufspalten) brauchen einen menschlichen Blick.
- Im "fixed"-Panel Copy klicken, um die neugeschriebene Version zu greifen, oder Copy im Input-Panel, um das Original in die Zwischenablage zu legen.
- Sagt der Linter "all clean", hast du ein Dockerfile, das den bekannten Best Practices folgt. Es kann projektspezifische Punkte geben (Image-Groesse, Layer-Reihenfolge fuer Build-Cache), aber die Basics sitzen.
Wann das nuetzlich ist
Sieben konkrete Situationen, in denen Dockerfile-Linting vor `docker build` echte Kopfschmerzen spart:
- PR-Review eines Kollegen mit neuem Dockerfile. Der Linter gibt eine schnelle objektive Liste: Versionen pinnen, `:latest` weg, Cleanup ergaenzen, Non-Root-User. Code-Review konzentriert sich auf Logik, nicht auf jede typische Falle.
- First-Pass-Cleanup eines Legacy-Dockerfiles. Viele alte Dockerfiles nutzen `MAINTAINER`, `ADD` fuer lokale Dateien, `apt-get install` ohne Cleanup und ein finales Image doppelt so gross wie noetig. Der Linter zeigt die schnellen Gewinne.
- Image-Groesse optimieren. `DL3009` (apt-Cache-Cleanup) und `DL3015` (`--no-install-recommends`) koennen Images zusammen um 100+ MB schrumpfen. `DL3059` (aufeinanderfolgende RUNs zusammenfuehren) reduziert Layer, was im Massstab zaehlt.
- Security-Pass. `CUSTOM_USER` flaggt jede Stage, die als root endet. Kombiniert mit `CUSTOM_HEALTH` fuer die finale Stage ist das die Minimum-Baseline vor dem Ausliefern.
- Versionen fuer Reproduzierbarkeit pinnen. `DL3007` (kein `:latest`), `DL3008` (apt-Versionen), `DL3018` (apk-Versionen), `DL3028` (gem-Versionen), `CUSTOM_DIGEST` (Image per sha256). Zusammen machen sie Builds deterministisch.
- Juniors lehren, was hadolint faengt. Die Rule-IDs mappen 1:1 auf den oeffentlichen hadolint-Katalog, jeder kann sie nachschlagen und die Begruendung lernen.
- Schneller Browser-Check vor dem Push. `docker build` dauert Minuten; der Linter ist sofort. Schnelle Feedback-Schleife beim Iterieren am Dockerfile.