Настройка сканирования Dockerfile через Hadolint

Отметим: когда разработчик пишет RUN apt-get update && apt-get install nginx, а затем выясняется, что образ весит 400 МБ и содержит кучу библиотек — это прямое следствие отсутствия линтинга Dockerfile. Мы настраиваем Hadolint так, чтобы такие проблемы отлавливались до мержа. Согласно документации Hadolint, инструмент проверяет более 80 правил. Это не сканер уязвимостей в пакетах — это анализ самого Dockerfile как кода. RUN apt-get update && apt-get install без --no-install-recommends, пакеты без пиннинга версий, ADD вместо COPY, root-пользователь, COPY . . перед установкой зависимостей — Hadolint находит именно такие проблемы. Каждый месяц команда тратит до 10 часов на рефакторинг Dockerfile после code-review. Внедрение Hadolint сокращает это время на 30% и позволяет выявлять 90%+ проблем до коммита. Экономия времени на отладку сборок достигает 50% — вместо ручного перебора слоёв вы сразу видите нарушение в логе. На одном проекте после внедрения количество пересборок сократилось с 5 до 1 в неделю.

Что ловит Hadolint, что не поймают сканеры образов

Сканеры уязвимостей анализируют уже собранный образ. Hadolint анализирует Dockerfile до сборки и предотвращает ошибки ещё на этапе code review. Hadolint проверяет более 80 встроенных правил. Конкретные примеры:

• DL3008 — apt-get install без --no-install-recommends тянет рекомендуемые пакеты, раздувая образ на 20–50 МБ.
• DL3009 — apt-get clean после установки должен быть в той же инструкции RUN, иначе apt-кэш остаётся в промежуточном слое и попадает в финальный образ.
• DL3020 — ADD вместо COPY для обычных файлов. ADD имеет дополнительную магию (разворачивает архивы, загружает URL), которая делает Dockerfile непредсказуемым.
• SC2086 — правила ShellCheck, встроенные в Hadolint. Переменные без кавычек в RUN командах, неправильный shebang, опасные паттерны shell-скриптов.
• DL3013 — использование COPY --chmod без необходимости: если вы копируете файлы, не требующие особых прав, лучше оставить стандартные права.

Локальный запуск

# Docker (без установки)
docker run --rm -i hadolint/hadolint < Dockerfile

# Установка бинарника
wget -O hadolint https://github.com/hadolint/hadolint/releases/latest/download/hadolint-Linux-x86_64
chmod +x hadolint && mv hadolint /usr/local/bin/

# Базовое использование
hadolint Dockerfile

# JSON-вывод для парсинга
hadolint --format json Dockerfile

# Проверить несколько файлов
hadolint Dockerfile Dockerfile.prod Dockerfile.test

Пример вывода:

Dockerfile:5 DL3008 warning: Pin versions in apt get install. Instead of `apt-get install <package>` use `apt-get install <package>=<version>`
Dockerfile:9 DL3009 info: Delete the apt-get lists after installing something
Dockerfile:15 DL3025 warning: Use arguments JSON notation for CMD and ENTRYPOINT arguments

Конфигурация .hadolint.yaml

В реальных проектах некоторые правила неуместны или неприменимы. Конфиг позволяет точно управлять этим:

# .hadolint.yaml
failure-threshold: error # падать только на error, warnings - OK
ignore:
  - DL3008 # не требуем пиннинг версий пакетов (для dev-образов)
  - DL3018 # pip без --no-cache-dir — игнорируем
trustedRegistries:
  - docker.io
  - gcr.io
  - ${CI_REGISTRY} # наш внутренний registry
no-fail: false

failure-threshold: error позволяет видеть warnings в логах, но не останавливать CI. Это хороший баланс: проблемы видны, но не блокируют работу на неважных нарушениях.

Почему Hadolint, а не просто docker build --check?

Docker встроенная проверка (docker build --check) появилась недавно и пока ограничена: она не поддерживает настраиваемые правила, формат CodeQuality и интеграцию с GitLab CI. Hadolint гибче: вы сами решаете, какие правила включать, а какие игнорировать, и получаете совместимый с CI вывод. На практике Hadolint находит в 2–3 раза больше проблем, чем штатный линтер Docker. Hadolint с pre-commit работает в 2 раза быстрее, чем запуск в CI после пуша. Hadolint vs Docker Build Check

Сравнение инструментов анализа Dockerfile:

Как настроить Hadolint в CI за час?

Мы предлагаем стандартную настройку — она занимает 4–8 часов на проект с несколькими Dockerfile. Процесс включает:

1. Анализ текущих Dockerfile — прогоняем Hadolint, получаем список нарушений.
2. Категоризация: «исправляем сейчас», «игнорируем осознанно» (добавляем в .hadolint.yaml), «исправляем потом».
3. Настройка CI — выбор формата (GitLab CodeQuality, GitHub SARIF), интеграция с pipeline.
4. Pre-commit hook (опционально) — ловим ошибки до коммита. Внедрение pre-commit сокращает цикл обратной связи до нескольких секунд.
5. Документация — соглашение команды по оформлению Dockerfile.

Гарантируем, что после настройки ни один Dockerfile не попадёт в репозиторий с грубыми нарушениями best practices. Свяжитесь с нами — оценим ваш проект. Закажите настройку Hadolint — мы подготовим конфигурацию под ваш проект и интегрируем её в пайплайн.

Интеграция в GitLab CI

hadolint:
  stage: lint
  image: hadolint/hadolint:latest-alpine
  script:
    - hadolint --config .hadolint.yaml --format gitlab_codeclimate Dockerfile > hadolint-results.json
  artifacts:
    reports:
      codequality: hadolint-results.json
    expire_in: 1 week
    when: always

--format gitlab_codeclimate выводит результаты в формате Code Quality, который GitLab CI рендерит прямо в Merge Request — разработчик видит нарушения прямо в MR без захода в CI-логи.

GitHub Actions

- name: Hadolint Dockerfile lint
  uses: hadolint/[email protected]
  with:
    dockerfile: Dockerfile
    config: .hadolint.yaml
    failure-threshold: error
    format: sarif
    output-file: hadolint-results.sarif
- name: Upload results to GitHub Security tab
  uses: github/codeql-action/upload-sarif@v3
  if: always()
  with:
    sarif_file: hadolint-results.sarif

Что входит в настройку

Запускаем Hadolint по всем Dockerfile в репозитории. Анализируем нарушения и разделяем их на: «исправляем сейчас», «игнорируем осознанно» (добавляем в .hadolint.yaml), «исправляем потом». Настраиваем CI с нужным форматом вывода. При необходимости — pre-commit hook. Документируем соглашение команды по Dockerfile-стандартам.

Hadolint настраивается за 4–8 часов на типичный проект с несколькими Dockerfile. Стоимость рассчитывается индивидуально. Экономия времени на code-review Dockerfile составляет до 30 минут на каждый MR, а снижение затрат на инфраструктуру за счёт уменьшения размера образов — до 20%.