Dockerfileは、Dockerイメージのコンテンツをテキストファイル内の一連の命令として定義します。 Dockerfileの構文は一般的に単純ですが、避けるべきいくつかの落とし穴があります。チーム設定で複雑なDockerfileを作成する際にベストプラクティスを順守することは、ファイルのコンテンツを自動的に検証しない限り、注意が必要な場合があります。
Hadolintは、一般的な問題を見つけることができるDockerfileリンターです。抽象構文木（AST）を使用して、事前定義されたルールセットに対してDockerfileを解析します。 HadolintにはShellCheckも組み込まれているため、Dockerfileの RUNでシェルスクリプトをリントできます。 指示も。
Hadolintは複数の形式で配布されています。プロジェクトのGitHubリリースページからオペレーティングシステム用にコンパイル済みの最新のバイナリをダウンロードすることで、すぐに開始できます。
Hadolintには、独自のDockerイメージ hadolint / hadolintもあります。 、バイナリを直接使用したくない場合。最後のオプションとして、実験のためにWeb経由でHadolintにアクセスできます。
Dockerfileのリンティング
HadolintにDockerfileへのパスを渡して、新しいスキャンを開始します。
hadolint Dockerfile
Dockerizedバージョンを使用している場合は、ファイルの内容をHadolintコンテナにパイプするのが最も簡単です。
docker run --rm -i hadolint/hadolint < Dockerfile
スキャン結果が端末に表示されます。この例では、HadolintはDockerfileの RUN apt-get installを提案しています。 ステートメントは明示的なパッケージバージョンを指定していないため、安全ではありません。イメージのコンテンツはビルドの合間に変更され、混乱を招く可能性があります。
ハドリントは何を探しますか？
Hadolintには、一般的な構成とセキュリティの問題をチェックする多数の組み込みルールがあります。リンターは、DockerfileをDockerが提案するイメージ構築のベストプラクティスに準拠させることを目的としています。
含まれているチェックは、 WORKDIR 内の相対パスを参照して、root以外の最終ユーザーの使用をカバーします ステートメント、複数の HEALTHCHECKを追加 指示、および明示的に固定されたタグとバージョンを使用しない。 HadolintはShellCheckルールセットも継承するため、そのツールで特定される一般的なBashスクリプトの問題が明らかになります。
ルールは、 HLのいずれかが前に付いた番号として識別されます またはSC 。 HL ルールはHadolintの一部ですが、 SC エントリはShellCheckから取得されます。各チェックには、エラーから情報までの重大度が与えられます。スキャン結果にエラーが発生した場合は、それが最初に解決する問題です。
Hadolintは.hadolint.yamlを介して構成されます ファイル。作業中の.configを含む複数の場所を検索します 、およびホームディレクトリ。最初に見つかったファイルのみが使用されます。場所間でのマージはありません。
構成ファイルを使用すると、ルールを無視して重大度を変更することにより、スキャンをカスタマイズできます。デフォルトのルールセットは推奨されるベストプラクティスをカバーしていますが、一部のチェックがご使用の環境に適用されない場合があります。 .hadolint.yamlをコミットする Dockerfileと一緒にファイルを使用すると、それに応じてHadolintスキャンを調整できます。ほとんどの構成ファイルフィールドは、CLIフラグおよび環境変数としてもサポートされています。
ルールはignoredによって無効にされます 分野。これはルールIDのリストである必要があります：
ignored: - DL3010 - DL3020
ルールを完全に無効にせずにルールの重大度を下げる必要がある場合は、 overrideを使用してください 代わりにキー。これにより、重大度の低い問題をより高いレベルに昇格させることもできます。特定の問題にさらに重点を置きたい場合は、これを使用してください。
override:
warning:
- DL3020
これにより、ルールDL3020がデフォルトの「エラー」レベルからそれほど深刻ではない「警告」に降格されます。このルールでは、 COPYを使用する必要があります ADDの代わりに ビルドコンテキストでファイルとフォルダを参照する場合。
グローバル重大度レベルも調整できます。 failure-thresholdの設定 フィールドは、テストで特定の重大度レベルのエラーが報告された場合に、失敗ステータスで終了するようにHadolintに指示します。
failure-threshold: warning
この命令は、出力にエラーまたは警告がある場合、Hadolintスキャンが失敗することを意味します。
no-fail：true を使用して、失敗コードでの終了を無効にすることができます 構成オプションまたは--no-fail CLIフラグ。これにより、Hadolintは 0で終了するように指示されます。 実際のテスト結果に関係なくコード。ハドリントを非ブロッキングジョブとしてCIパイプラインに含めたい場合に便利です。
構成ファイルのもう1つの使用法は、Dockerfileで参照できるようにする信頼できるレジストリーを定義することです。 trustedRegistriesの場合 フィールドが設定されている場合、別のレジストリの画像が使用されると、Hadolintは警告を表示します：
trustedRegistries: - docker.io - docker-registry.example.com
Hadolintは基本的なラベルリンティングも提供しています。これにより、Dockerfile LABELによって画像に追加されたラベルを適用できます。 命令は指定された制約に準拠しています。仕組みの例を次に示します。
label-schema: notes: text app-version: semver built-at: rfc3339
この構成スニペットは、Dockerfileで使用できる4つのラベルのデータ型を定義します。 メモ app-version の間、任意のテキストフィールドとして宣言されます semver互換のバージョン識別子である必要があります。 built-at RFC-3339日時文字列としてマークされています。サポートされているタイプの完全なリストは、Hadolintドキュメントで入手できます。
Hadolintは、スキーマにリストされていないラベルの使用を許可します。これを無効にして、 LABELを制限することができます strict-labels：true を設定して、スキーマに存在するものだけに指示する または--strict-labelsを使用します フラグ。
formatを介していくつかの出力フォーマットがサポートされています オプションまたは--format 国旗。デフォルトはttyです これは、色付きの出力を端末に送信します。 -no-colorを使用して色を無効にすることができます フラグ。
次の代替フォーマッタが利用可能です：
-
json–検出された問題のリストを、独自のスクリプトで使用するのに理想的な詳細なJSON構造として提供します。 チェックスタイル–Checkstyle互換のレポート。-
codeclimate–コード気候と互換性のあるレポート。 -
gitlab_codeclimate–GitLabの統合されたコード品質機能と連携するCodeClimateレポートのバリエーション。これにより、GitLab CIでHadolintを実行しているときに、マージリクエストページのウィジェットとしてエラーを表示できます。
これらの出力形式は、プログラムで、またはCIパイプラインの一部としてHadolintを使用するのに理想的です。
Hadolintは、Dockerfileの問題の検出を自動化します。これにより、Dockerイメージがベストプラクティスと組織の標準に準拠するのに役立ちます。デフォルトの構成は良い出発点ですが、ルールを再分類して無効にすることで、ニーズに合わせてカスタマイズできます。
Dockerfileの変更がコミットされたときにインスタントレポートを取得するには、HadolintをCIツールと統合することを検討する必要があります。これにより、開発者は問題を即座に把握できるため、コードレビューが高速化されます。コミュニティでサポートされているエディター拡張機能を介して作業しているときにツールをローカルで使用することもでき、フィードバックループがさらに短くなります。