Ein Dockerfile linten, bevor es ins Review geht.

Siebzehn Regeln, DF001 bis DF017, jede davon ein Fehler, der trotzdem baut: ein Basis-Image ohne Tag oder mit :latest, ein COPY --from auf eine Stage, die es noch nicht gibt, ADD dort, wo COPY hingehört, ein unverifizierter Remote-Download, ein relatives WORKDIR, ein apt-get update allein in seinem eigenen Layer, ein im Image zurückgelassener Paket-Cache, ein per ENV oder ARG in die Image-History geschriebenes Secret, eine letzte Stage, die als root läuft, cd statt WORKDIR, curl in eine Shell gepipet, ein zweites CMD, das stillschweigend gewinnt, eine JSON-Exec-Form, die kein gültiges JSON ist, sudo in einem Build-Schritt, MAINTAINER und ein COPY ., das den Cache der Dependency-Installation zerstört. Jede Regel hat auf dieser Seite ihren eigenen Unterabschnitt mit Vorher-Nachher-Snippet.

Nein, und es versucht es auch nicht zu sein. hadolint ist eine Binary, die Sie installieren, und es kombiniert eigene Regeln mit allem, was ShellCheck über die Shell in Ihren RUN-Zeilen sagt — ausgezeichnet in der CI und die richtige Antwort, wenn Sie eine Toolchain vorschreiben können. Dies hier ist der Fall, den hadolint nicht abdeckt: ein Dockerfile, das Sie jetzt geprüft haben wollen, aus dem Browser, auf einer Maschine, auf der Sie nichts installieren dürfen, ohne die Datei an einen Server zu schicken. Siebzehn Regeln statt eines langen Schwanzes, jede mit einem Fix, und weiter unten eine ausdrückliche Liste dessen, was der Linter bewusst nicht meldet.

Nein. Der Parser und alle siebzehn Regeln sind JavaScript, das in Ihrem Tab läuft — es gibt keinen Server, keinen API-Aufruf und kein Logging, also werden 0 Bytes hochgeladen. Das zählt hier mehr als bei den meisten Tools: Dockerfiles enthalten interne Registry-Hostnamen, private Paket-Indizes, Build-Argumente und gelegentlich ein Credential, das niemand hätte committen sollen.

Weil jedes RUN ein eigenes Layer mit einem eigenen Cache-Eintrag ist. Wenn Sie später nur die Install-Zeile ändern, verwendet Docker das gecachte Update-Layer weiter — es kann Wochen oder Monate alt sein — und führt die Installation gegen diesen veralteten Paket-Index aus. Das Ergebnis ist entweder eine unerwartete Version oder ein 404 für ein Paket, das inzwischen ersetzt wurde. Beides in einem RUN zu verbinden lässt Index und Installation denselben Cache-Eintrag teilen, sodass sie sich nie widersprechen können.

Nichts — bis der Publisher pusht. :latest ist ein wandernder Zeiger, und ein FROM ohne Tag bedeutet :latest. Das Basis-Image, das Ihr Build letzten Monat verwendet hat, und das von heute Nacht können also unterschiedliche Major-Versionen sein, ohne dass Sie etwas geändert haben — und nichts in der Datei hält fest, welche Sie tatsächlich getestet haben. Pinnen Sie einen Tag, den Sie getestet haben. Wenn Sie byte-identische Rebuilds brauchen, ergänzen Sie den Digest (@sha256:…). Dieser Linter verlangt einen Tag und nie einen Digest: diese Abwägung bleibt Ihre.

Weil Docker es nicht ablehnt — es tut stillschweigend etwas anderes. Die Exec-Form wird nur verwendet, wenn das Argument als JSON parst, und JSON verlangt doppelte Anführungszeichen. Mit einfachen Anführungszeichen fällt das Ganze auf die Shell-Form zurück, Docker führt also /bin/sh -c "['nginx']" aus, und Klammern und Anführungszeichen werden Teil des Kommandos. Zur Build-Zeit warnt nichts; der Container startet einfach nicht — oder startet eine Shell, die nicht der Prozess ist, den Sie als PID 1 gemeint haben.

Nicht direkt, und er sagt das lieber, als zu raten. Eine .dockerignore ist eine separate Datei, ein Linter, der nur das Dockerfile liest, kann also nicht wissen, ob node_modules, .git und Ihre Build-Artefakte in den Build-Kontext wandern. Was er kann: das Muster erkennen, das eine fehlende .dockerignore teuer macht — ein COPY . vor der Dependency-Installation, das ist DF017 — und den .dockerignore-Hinweis in den Fix-Text dieser Regel legen.

Beides wurde geprüft und bewusst verworfen. EXPOSE ist Dokumentation: es veröffentlicht von sich aus nichts, ein fehlendes bricht also nichts und ein zusätzliches kostet nichts. HEALTHCHECK wird von Kubernetes komplett ignoriert, und dort laufen diese Images in der Praxis — es zu melden würde dieses Publikum darauf trainieren, den Linter zu ignorieren. Die vollständige Liste dessen, was still bleibt, mit Begründung für jeden Punkt, steht im Abschnitt „Was er bewusst nicht meldet“ über den FAQ.

Bis zu 200.000 Zeichen — grob viertausend Zeilen dichter Text, also zwei Größenordnungen mehr als jedes echte Dockerfile. Darüber verweigert er mit einer Meldung, statt Ihren Tab einzufrieren, denn eine so große Eingabe ist ein Build-Log oder ein gepacktes Archiv, kein Dockerfile. Auch die Funde sind begrenzt, auf 20 pro Regel und 200 insgesamt, und das Panel nennt die Grenze und die echte Anzahl, sobald eine greift.