dockerfile-review

Этот skill предназначен для построчного ревью Dockerfile или Containerfile. Его задача — не заменить сборку контейнера общими советами, а провести проверяемый разбор корректности, кэширования слоёв, возможностей multi-stage-сборки, размера образа, безопасности и воспроизводимости. Источник предлагает идти по файлу сверху вниз и указывать номера строк в каждом замечании, чтобы рекомендацию можно было связать с конкретным FROM, RUN, COPY, ENV, ARG, CMD или ENTRYPOINT. Такой формат удобен для ревью pull request, диагностики неожиданно большого образа и проверки Dockerfile перед публикацией или запуском в CI/CD. Проверка начинается с базового образа. Нужно выяснить, закреплён ли тег: latest, edge и образ без тега считаются источником дрейфа, а для воспроизводимой сборки предлагается digest; как минимум нужен конкретный тег. Затем оценивается соответствие размера образа рабочей нагрузке. В источнике отдельно сопоставляются варианты Python: полный образ может быть значительно тяжелее slim, а Alpine меньше, но способен создавать проблемы для пакетов с C-расширениями, собранными не под musl. Для Go и Rust со статическим бинарником финальный этап должен быть минимальным, например scratch или distroless/static-debian12. Если приложение запускается на M-series Mac, AWS Graviton или Raspberry Pi, проверяется поддержка linux/arm64; разделение BUILDPLATFORM и TARGETPLATFORM помогает явно разделить платформу сборки и целевую платформу. Отдельный блок посвящён порядку слоёв и cache invalidation. Рекомендуемая последовательность начинается с FROM и WORKDIR, затем устанавливаются системные зависимости в одном RUN: apt-get update, apt-get install с --no-install-recommends и очистка /var/lib/apt/lists/ в том же слое. После этого копируются только package manifests и устанавливаются зависимости, а исходники копируются позже, перед build-командой. Это сохраняет кэш установки, когда меняется только код. Skill просит отдельно отмечать ранний COPY . ., раздельные RUN apt-get update и apt-get install, отсутствие очистки apt-кэша и лишних рекомендуемых пакетов. В каждом случае замечание должно объяснить, какой последующий слой будет пересобираться или что попадёт в итоговый образ. Multi-stage-анализ ищет инструменты, которые нужны для сборки, но не нужны при запуске. Компиляторы gcc, go, rustc и javac в финальном образе, а также package managers, dev-зависимости, node_modules/.cache, pip и build tools в runtime-слое являются поводом разделить build и final stages. Для статического Go-бинарника источник показывает модель: скачать зависимости в build-стадии, собрать бинарник, затем скопировать только результат в минимальный runtime-образ. Это уменьшает поверхность финального образа и не смешивает компиляцию с эксплуатационным окружением. Безопасность проверяется конкретными признаками. Запуск от root следует заменить отдельным пользователем приложения до CMD или ENTRYPOINT. Секреты нельзя запекать через ENV API_KEY или ARG SECRET с последующим использованием в RUN, потому что такие значения могут остаться видимыми в docker history; для сборки предлагается secret-механизм, а для runtime — переменные окружения. В COPY нужно искать .env, приватные ключи и SSH-конфигурацию и сверять, исключены ли они через .dockerignore. ADD удалённого URL требует отдельной проверки checksum, а конструкция RUN curl | sh — закрепления и проверки удалённого скрипта. Для старого базового образа, которому больше примерно шести месяцев, skill рекомендует предложить обновление. Воспроизводимость рассматривается отдельно от безопасности. pip install, npm install и аналогичные команды без lockfile делают зависимости недетерминированными; для Python источник требует полностью закреплённый requirements.txt и установку без повторного разрешения зависимостей. Для долгоживущих образов apt-пакеты предлагается фиксировать по версии. Build arguments, которые меняются между запусками, нужно документировать, потому что они сбрасывают кэш с соответствующего слоя вниз. Это даёт конкретную проверку, а не обещание, что одинаковый Dockerfile всегда даст одинаковый результат без фиксации входных зависимостей и платформы. Размер образа дополняет предыдущие проверки. Несколько RUN apt-get install создают лишние слои, поэтому связанные установки нужно объединять и завершать очисткой apt-списков. Каталог .git в build context обычно не нужен runtime-образу; node_modules, тестовые fixtures, локальные build artifacts и файлы IDE также должны быть исключены из контекста через подробный .dockerignore. Skill не предлагает удалять такие файлы вслепую: сначала нужно установить, что они не нужны сборке и запуску, затем проверить границу контекста. Для долгоживущих сервисов проверяется HEALTHCHECK, потому что отсутствие проверки ломает оркестраторы, которые на неё рассчитывают. Для запуска процессов предпочтительна exec-форма ENTRYPOINT ["/app"] вместо shell-формы CMD /app, чтобы сигналы доходили до приложения. STOPSIGNAL нужен только когда приложению требуется сигнал, отличный от SIGTERM, поэтому его отсутствие само по себе не является дефектом. В итоговом ревью замечания делятся на Critical для проблем безопасности или поломки сборки и runtime, Strong recommendation для существенного выигрыша размера или кэша и обязательного healthcheck у сервиса, а также Nits для небольших улучшений. Каждое замечание оформляется одной строкой с номером строки, проблемой и исправлением. Практический сценарий использования прост: передать Dockerfile или Containerfile на review, пройти разделы сверху вниз, привязать findings к строкам и выбрать только применимые изменения. Skill охватывает устройство файла и типовые решения для Linux-контейнера, но не подменяет фактическую проверку конкретного проекта: рекомендации о размере, multi-arch, healthcheck, lockfile и runtime-зависимостях нужно сопоставить с реальной нагрузкой, целевой платформой и способом запуска. Поэтому результатом должен быть список конкретных строк и предложений, а не универсальное требование добавить все возможные директивы. Источник также не утверждает, что любая рекомендация обязательна для каждого контейнера: STOPSIGNAL, distroless, HEALTHCHECK и multi-stage зависят от характера приложения и его жизненного цикла.