Dockerfiles definieren den Inhalt von Docker-Images als eine Reihe von Anweisungen in einer Textdatei. Die Dockerfile-Syntax ist im Allgemeinen einfach, aber es gibt einige Fallstricke, die es zu vermeiden gilt. Die Einhaltung von Best Practices beim Schreiben komplexer Dockerfiles in einer Teamumgebung kann schwierig sein, es sei denn, Sie validieren den Inhalt Ihrer Datei automatisch.
Hadolint ist ein Dockerfile-Linter, der allgemeine Probleme für Sie erkennen kann. Es verwendet einen abstrakten Syntaxbaum (AST), um Ihr Dockerfile anhand vordefinierter Regelsätze zu analysieren. Hadolint enthält auch ShellCheck, damit es die Shell-Skripte im RUN Ihres Dockerfiles linten kann Anweisungen auch.
Erste Schritte
Hadolint wird in mehreren Formaten vertrieben. Sie können schnell loslegen, indem Sie die neueste vorkompilierte Binärdatei für Ihr Betriebssystem von der GitHub-Release-Seite des Projekts herunterladen.
Hadolint hat auch ein eigenes Docker-Image, hadolint/hadolint , wenn Sie die Binärdatei lieber nicht direkt verwenden möchten. Als letzte Option können Sie zum Experimentieren über das Internet auf Hadolint zugreifen.
Linting einer Dockerfile
Übergeben Sie Hadolint den Pfad zu einer Docker-Datei, um einen neuen Scan zu starten:
hadolint Dockerfile
Wenn Sie die Docker-Version verwenden, ist es am einfachsten, den Inhalt Ihrer Datei in einen Hadolint-Container zu leiten:
docker run --rm -i hadolint/hadolint < Dockerfile
Die Scan-Ergebnisse werden in Ihrem Terminal angezeigt. In diesem Beispiel schlägt Hadolint vor, dass RUN apt-get install der Dockerfile -Anweisung ist unsicher, da sie keine expliziten Paketversionen angibt. Der Inhalt Ihres Bildes könnte sich zwischen Builds ändern, was möglicherweise zu verwirrenden Problemen führen kann.
Wonach sucht Hadolint?
Hadolint verfügt über Dutzende von integrierten Regeln, die nach allgemeinen Konfigurations- und Sicherheitsproblemen suchen. Der Linter zielt darauf ab, Ihre Dockerfiles mit den von Docker vorgeschlagenen Best Practices für die Image-Erstellung kompatibel zu machen.
Eingeschlossene Überprüfungen decken die Verwendung von Nicht-Root-Endbenutzern ab, die auf einen relativen Pfad in einem WORKDIR verweisen -Anweisung, indem mehrere HEALTHCHECK hinzugefügt werden Anweisungen und keine Verwendung explizit angehefteter Tags und Versionen. Da Hadolint auch den ShellCheck-Regelsatz erbt, werden häufige Bash-Skriptprobleme aufgedeckt, die dieses Tool ebenfalls identifiziert.
Regeln werden als Nummern identifiziert, denen entweder HL vorangestellt ist oder SC . HL Regeln sind Teil von Hadolint, wohingegen SC Einträge stammen von ShellCheck. Jeder Überprüfung wird ein Schweregrad von Fehler bis Info zugeordnet. Wenn Sie Fehler in Ihren Scan-Ergebnissen erhalten, sollten diese die ersten Probleme sein, die Sie beheben.
Anpassen der Konfiguration
Hadolint wird über eine .hadolint.yaml konfiguriert Datei. Es durchsucht mehrere Speicherorte, einschließlich Ihrer Arbeitsdatei .config , und Home-Verzeichnisse. Nur die erste gefundene Datei wird verwendet – es gibt kein Zusammenführen zwischen Standorten.
Mit der Konfigurationsdatei können Sie Ihre Scans anpassen, indem Sie Regeln ignorieren und ihre Schweregrade ändern. Während der Standardregelsatz empfohlene Best Practices abdeckt, stellen Sie möglicherweise fest, dass einige Überprüfungen in Ihrer Umgebung nicht zutreffen. Commit einer .hadolint.yaml neben Ihrer Dockerfile-Datei können Sie Hadolint-Scans entsprechend anpassen. Die meisten Felder der Konfigurationsdatei werden auch als CLI-Flags und Umgebungsvariablen unterstützt.
Regeln werden durch den ignored deaktiviert Feld. Dies sollte eine Liste von Regel-IDs sein:
ignored: - DL3010 - DL3020
Wenn Sie den Schweregrad einer Regel verringern müssen, ohne sie vollständig zu deaktivieren, verwenden Sie die Option override Schlüssel statt. Auf diese Weise können Sie auch ein Problem mit niedrigem Schweregrad auf eine höhere Ebene hochstufen. Verwenden Sie dies, wenn Sie ein bestimmtes Thema stärker hervorheben möchten.
override:
warning:
- DL3020
Dadurch wird die Regel DL3020 von ihrer Standardstufe „Fehler“ auf die weniger schwerwiegende Stufe „Warnung“ herabgestuft. Diese Regel erfordert die Verwendung von COPY statt ADD beim Verweisen auf Dateien und Ordner in Ihrem Build-Kontext.
Sie können auch den globalen Schweregrad anpassen. Einstellen der failure-threshold weist Hadolint an, mit einem Fehlerstatus zu beenden, wenn ein Test einen Fehler mit dem angegebenen Schweregrad meldet:
failure-threshold: warning
Diese Anweisung bedeutet, dass der Hadolint-Scan fehlschlägt, wenn entweder ein Fehler oder eine Warnung in seiner Ausgabe enthalten ist.
Sie können das Beenden mit einem Fehlercode mit no-fail: true deaktivieren config-Option oder die --no-fail CLI-Flag. Dadurch wird Hadolint angewiesen, mit einem 0 zu beenden Code unabhängig vom tatsächlichen Testergebnis. Es kann nützlich sein, wenn Sie Hadolint als nicht blockierenden Job in eine CI-Pipeline einbinden möchten.
Vertrauen von Registrierungen
Eine weitere Verwendung der Konfigurationsdatei besteht darin, vertrauenswürdige Registrierungen zu definieren, auf die Sie in Ihren Dockerfiles verweisen können möchten. Wenn die trustedRegistries gesetzt ist, wird Hadolint Sie warnen, wenn ein Bild aus einer anderen Registry verwendet wird:
trustedRegistries: - docker.io - docker-registry.example.com
Label-Schemas
Hadolint bietet auch grundlegende Linting-Etiketten an. Auf diese Weise können Sie erzwingen, dass Labels Ihrem Image von Dockerfile LABEL hinzugefügt werden Anweisungen erfüllen die angegebenen Einschränkungen. Hier ist ein Beispiel dafür, wie es funktioniert:
label-schema: notes: text app-version: semver built-at: rfc3339
Dieses Konfigurations-Snippet definiert Datentypen für vier Labels, die Sie in Ihrer Dockerfile verwenden können. notes wird als beliebiges Textfeld deklariert, während app-version muss eine semver-kompatible Versionskennung sein. built-at ist als RFC-3339-Datetime-String gekennzeichnet. Die vollständige Liste der unterstützten Typen finden Sie in der Hadolint-Dokumentation.
Hadolint erlaubt die Verwendung von Labels, die nicht in Ihrem Schema aufgeführt sind. Sie können dies deaktivieren und LABEL einschränken Anweisungen nur an diejenigen, die im Schema vorhanden sind, indem Sie strict-labels: true festlegen oder mit --strict-labels Flagge.
Ausgabeformate
Über das format werden mehrere Ausgabeformate unterstützt Option oder --format Flagge. Der Standardwert ist tty die eine farbige Ausgabe an Ihr Terminal ausgibt. Farben können mit --no-color deaktiviert werden Flagge.
Die folgenden alternativen Formatierer sind verfügbar:
json– Stellt die Liste der erkannten Probleme als ausführliche JSON-Struktur bereit, die sich ideal für die Verwendung mit Ihren eigenen Skripts eignet.checkstyle– Ein Checkstyle-kompatibler Bericht.codeclimate– Ein mit dem Code Climate kompatibler Bericht.gitlab_codeclimate– Variation des Code Climate-Berichts, der mit den integrierten Code-Qualitätsfunktionen von GitLab funktioniert. Dadurch können Sie Fehler als Widget auf Zusammenführungsanforderungsseiten anzeigen, wenn Hadolint mit GitLab CI ausgeführt wird.
Diese Ausgabeformate sind ideal für die programmatische Verwendung von Hadolint oder als Teil einer CI-Pipeline.
Zusammenfassung
Hadolint automatisiert die Erkennung von Dockerfile-Problemen. Dies hilft Ihren Docker-Images, Best Practices und Organisationsstandards einzuhalten. Die Standardkonfiguration ist ein guter Ausgangspunkt, aber Sie können sie an Ihre Bedürfnisse anpassen, indem Sie Regeln neu klassifizieren und deaktivieren.
Sie sollten erwägen, Hadolint in Ihr CI-Tool zu integrieren, um sofortige Berichte zu erhalten, wenn Dockerfile-Änderungen festgeschrieben werden. Dies beschleunigt die Codeüberprüfung, indem es Entwicklern einen sofortigen Einblick in Probleme gibt. Sie können das Tool auch lokal verwenden, während Sie über von der Community unterstützte Editor-Erweiterungen arbeiten, was eine noch kürzere Feedback-Schleife bietet.