Генерация Docker-конфигураций: промт для мультистейдж сборки
Dockerfile, сгенерированный без требований, обычно выглядит так: базовый образ на всю операционную систему, копирование всего проекта первой строкой, установка зависимостей после, запуск от root. Он работает — и пересобирается три минуты при правке одной строчки кода, весит гигабайт и не проходит проверку безопасности.
Всё это лечится требованиями в промте. Мультистейдж-сборка тут ключевая идея: собираем в одном образе со всеми инструментами, а в финальный переносим только результат.
Промт
Напиши Dockerfile для [язык, фреймворк, версия]. ПРОЕКТ: Менеджер зависимостей: [poetry / pip / npm / go mod / maven] Файлы зависимостей: [названия] Команда сборки: [если есть] Команда запуска: [точная] Порт: [номер] Нужны ли системные библиотеки: [список или «нет»] ТРЕБОВАНИЯ: 1. Мультистейдж: стадия сборки и минимальная финальная стадия. 2. Порядок слоёв под кеш: сначала копируем только файлы зависимостей и ставим их, исходники копируем после. 3. Финальный образ — минимальный из подходящих (slim / alpine / distroless), обоснуй выбор и назови, чем он рискует. 4. Запуск от непривилегированного пользователя, созданного явно. 5. HEALTHCHECK с осмысленной проверкой, не просто «процесс жив». 6. Переменные окружения для настройки, без секретов в образе. 7. .dockerignore — отдельным блоком, с объяснением каждой строки. 8. Никакого apt-get upgrade и никаких latest-тегов. Отдельно: как проверить итоговый размер и что в нём занимает больше всего.
Восьмой пункт про latest стоит держать жёстко: образ, собравшийся сегодня, через месяц соберётся из другой базы, и вы получите невоспроизводимую сборку.
Что проверить в результате
- Пересоберите дважды. Второй раз без изменений должен пройти почти мгновенно — значит, кеш работает.
- Измените одну строку кода и пересоберите. Если переустанавливаются зависимости, порядок слоёв неверный.
- Посмотрите размер. Для веб-приложения на Python или Node нормальный финальный образ — десятки, не сотни мегабайт.
- Проверьте пользователя. Запустите
idвнутри контейнера: root там быть не должно. - Поищите лишнее. Кеши пакетных менеджеров, .git, тесты и артефакты сборки в финальный образ попадать не должны.
Промт для разбора существующего образа
Вот Dockerfile [вставить] и вывод docker history [вставить]. Найди слои, которые занимают больше всего, и объясни, из-за чего. Предложи изменения по порядку: что даст наибольшее сокращение размера при наименьшем риске. Отдельно: что мешает кешированию при типичном изменении — правке одного файла исходников. Не предлагай сменить базовый образ, если это потребует пересборки системных зависимостей — сначала оцени эту работу.
Компоуз и окружение
| Задача | Что попросить |
|---|---|
| Локальная разработка | Отдельная стадия с инструментами и монтированием исходников |
| Зависимые сервисы | compose с healthcheck и depends_on по состоянию, а не по запуску |
| Секреты | Через переменные окружения и файлы, не через ARG в образе |
| Миграции | Отдельная команда, а не в CMD приложения |
Последняя строка — частая ошибка сгенерированных конфигураций: миграции запускают при старте контейнера, и при масштабировании на несколько реплик они стартуют одновременно.
Про безопасность коротко
Модель знает базовые практики и назовёт их, если спросить прямо: непривилегированный пользователь, отсутствие секретов в слоях, фиксированные версии базовых образов, минимальная поверхность. Чего она не знает — уязвимостей в конкретных версиях пакетов, которые вы ставите. Для этого есть сканеры образов, и их место в CI, а не в диалоге с моделью.