hadolintは、Dockerfileを対象に専用ルールで静的解析を行うコマンドラインツールである。2016年にスイスのLukas Martinelli氏らが開発を始めたOSSで、名前は「Haskell Dockerfile Linter」の頭字語に由来する。コンテナイメージはレイヤーごとに積み上がる特性から、書き方ひとつで肥大化や脆弱性混入につながりやすい。hadolintは、内部でShellCheckの解析エンジンを呼び出してRUN命令のシェルスクリプトまで踏み込み、Docker公式が推奨するベストプラクティスへの追従を機械的にチェックしてくれる。
この記事の目次
- Dockerfileに特有の落とし穴
- ルール体系と代表的なコード
- ローカル実行とコンテナ実行
- 近接ツールとの比較
- まとめ
Dockerfileに特有の落とし穴
Dockerfileは一見シンプルなDSLに見えるが、コンテナイメージの安全性とサイズに直結する落とし穴が多い。FROMでlatestタグを指定するとビルド再現性が損なわれ、apt-get update単独でcleanを忘れると不要なキャッシュレイヤーが残ってイメージが肥大化する。ADDとCOPYは似ているが、ADDはURL展開やtarの自動解凍など副作用が強く、安易に使うと意図せぬ動作になりやすい。USER命令で非rootユーザを明示しなければ、デフォルトでrootで起動するイメージが量産されてしまう。
Docker社は公式ドキュメントでこれらをまとめた「Best practices for writing Dockerfiles」を提供しているが、内容は分量が多く、すべて頭に入れて毎回守るのは現実的でない。Lukas Martinelli氏は、こうした暗黙のルールを機械的に強制したいというモチベーションからhadolintを立ち上げた。実装言語にHaskellを選んだ理由は、ShellCheckと共通でパーサが堅牢に書けるためで、結果として彼はRUN命令の内部解析にShellCheckを直接呼び出す形でツールを構築した。
ルール体系と代表的なコード
hadolintのルールにはDLxxxxという独自コードが振られ、それぞれDocker公式ベストプラクティスやコミュニティの知見に対応する。代表例のDL3007は「FROM image:latestを避ける」、DL3008は「apt-get installで明示的なバージョン固定を行う」、DL3009は「apt-getの後にrm -rf /var/lib/apt/lists/*でキャッシュを削除する」といった内容になる。イメージサイズの肥大化を防ぐRUN命令の連結（&&でつなぐ、行末のバックスラッシュで改行する）や、CMD命令のJSON配列形式を推奨するDL3025なども含まれる。
さらに、RUN命令内のシェルスクリプトはShellCheckのSCコードでチェックされる。つまり、RUN if [ "$VAR" = "foo" ]のような行があれば、SC2086（変数未クォート）などのShellCheck警告がhadolintの出力に混ざって現れる。この二段構えにより、Dockerfile独自の問題とシェルスクリプト共通の問題を同時に検出できるのがhadolintの特徴的な強みだ。ルールごとに--ignore DL3008のような形で個別無効化でき、プロジェクトの方針に合わせた調整も容易である。
ローカル実行とコンテナ実行
hadolintは静的バイナリとして配布されており、brew installやapt install、あるいは公式GitHub Releasesから単一ファイルをダウンロードしてそのまま実行できる。公式Docker Hubにはhadolint/hadolintイメージも用意されており、docker run --rm -i hadolint/hadolint < Dockerfileとパイプで読み込ませる使い方も一般的だ。言語ランタイムを必要としないので、CIランナーの種類を問わず簡単に導入できる利点がある。
プロジェクト固有のルール設定は.hadolint.yamlに記述する。ignoredルールの列挙、trustedRegistriesの指定（社内レジストリのみ許可する場合）、failure-thresholdの設定などが書け、CIではこのYAMLを置くだけでチーム全体の方針を統一できる。出力形式はtty、checkstyle、json、sarifなど多彩で、SARIF形式で吐き出せばGitHub Code Scanningと連携してPRに直接警告を付けることも可能だ。Dockerfileを書くたびにhadolintを通すことが、コンテナ品質の底上げに直結する。
近接ツールとの比較
Dockerfile周辺の品質確認ツールは複数あり、それぞれ守備範囲が異なる。hadolintは「書き方」を担う静的解析ツールであり、Dockerfileの構文と慣習に特化する。AquaSecurity社のTrivyや、Docker公式のDocker Scoutは「出来上がったイメージ」のCVEスキャンを担当し、ベースイメージや導入ライブラリの脆弱性情報を提供する。Diveはレイヤーごとのファイル差分を可視化するTUIツールで、無駄なレイヤーを発見するのに役立つ。
これらは併用が前提で、現代的なコンテナCIは「hadolintで書き方を整え、Trivy/Docker Scoutで脆弱性を洗い、Diveでサイズを点検する」という三段構えになりやすい。GitHub Actionsではhadolint/hadolint-actionが公式に整備され、Pull Request上でDockerfileの変更行に対するインライン警告を簡単に実現できる。DevOpsの文脈では、コンテナイメージの安全性と再現性がそのままプロダクトの信頼性に直結するため、hadolintのような「書く側を支援する」ツールの存在感はじわじわと増している。
まとめ
hadolintは、Lukas Martinelli氏が2016年に立ち上げたDockerfile専用リンターで、ShellCheck連携によりRUN命令内のシェルスクリプトまで深く検査する。DLxxxx/SCxxxxという統一されたコード体系、軽量なバイナリ配布、CIへの組み込みやすさなど、コンテナ品質を底上げするうえで頼りになる定番ツールとして広く採用が進んでいる。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント