Кратко
Hadolint помогает писать более аккуратные Dockerfile: он разбирает файл в AST, применяет правила и дополнительно проверяет shell-команды внутри RUN-инструкций.
Что это такое
Hadolint — линтер Dockerfile, написанный на Haskell. Он нужен там, где контейнерные образы должны быть повторяемыми, безопасными и понятными для команды.
Что внутри
Проект парсит Dockerfile в дерево и применяет правила поверх структуры файла. Для shell-кода внутри `RUN` он использует идеи ShellCheck, поэтому проверка не ограничивается только Docker-инструкциями.
Как используют
Hadolint обычно запускают локально, в проверках перед объединением изменений или в сборочной системе. Он быстро показывает, где Dockerfile нарушает практики сборки образов, и помогает удерживать контейнерные правила одинаковыми во всех сервисах команды.
Пример
Проверка Dockerfile
Команда проверяет Dockerfile и возвращает предупреждения по структуре и shell-инструкциям.
hadolint DockerfileСильные стороны
Сильная сторона Hadolint — ранняя обратная связь. Ошибка в Dockerfile часто всплывает поздно и дорого, а линтер ловит многие проблемы еще до сборки образа.
Ограничения
Ограничение — контекст проекта. Не каждое предупреждение одинаково важно: некоторые правила можно осознанно отключить, если команда понимает компромисс.
Контекст проекта
Hadolint ведется в репозитории hadolint/hadolint; публичная история проекта начинается 2015-11-15. Основной язык в метаданных — Haskell, лицензия — GPL-3.0.
Этот контекст помогает читать страницу как разбор конкретного репозитория: у проекта есть владелец, техническая база, лицензия, история изменений и реальные ограничения выбранной экосистемы.
Hadolint стоит оценивать через конкретный сценарий: кто будет поддерживать инструмент, где он встраивается в существующий стек, какие обновления придется отслеживать и что произойдет при ошибке. Такой взгляд лучше простой установки ради популярности, потому что открытый проект приносит пользу только тогда, когда его место в системе понятно команде.
Перед внедрением полезно отдельно проверить документацию, частоту релизов, модель лицензирования, требования к окружению и то, насколько легко проект будет удалить или заменить, если выбранный путь перестанет подходить продукту.