7 промтов для Docker: от Dockerfile до оптимизации образов и multi-stage сборок

Введение

Docker — стандарт де-факто для контейнеризации приложений. Но даже опытные разработчики часто тратят часы на написание эффективных Dockerfile и docker-compose.yml, а затем — на отладку и оптимизацию образов. В 2026 году, когда каждый мегабайт образа влияет на скорость деплоя и стоимость хранения в registry, умение быстро генерировать правильные конфиги — ключевой навык.

Я собрал 7 проверенных промтов, которые использую сам каждый день. Они помогают:
- Создать Dockerfile под конкретный язык и фреймворк за 10 секунд.
- Настроить docker-compose для микросервисной архитектуры.
- Применить multi-stage сборки и уменьшить образ в 3–5 раз.
- Избежать типовых ошибок безопасности (например, запуск от root, лишние слои).

Все промты — с реальными примерами применения. Бери и используй.

1. Промт: «Напиши production-ready Dockerfile для [язык/фреймворк]»

Когда использовать: нужно быстро получить рабочий Dockerfile с учётом best practices (не root, минимальный образ, кэширование зависимостей).

Промт:

Напиши production-ready Dockerfile для Node.js (Express) приложения. Используй официальный образ node:20-alpine. Установи зависимости отдельно от кода для кэширования слоёв. Запускай приложение от непривилегированного пользователя (node). Укажи HEALTHCHECK. Минимизируй количество слоёв.

Результат (пример вывода):

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1
CMD ["node", "server.js"]

Почему это работает:
- Разделение установки зависимостей и копирования кода позволяет кэшировать слой с node_modules — пересборка при изменении кода не переустанавливает пакеты.
- Alpine образ даёт ~5 МБ базового размера против ~150 МБ у полного Node.
- Запуск от appuser (UID 1000) вместо root снижает риски при компрометации контейнера.

2. Промт: «Сгенерируй docker-compose для микросервисов: API, БД, Redis, очередь»

Когда использовать: настройка локального окружения для разработки или тестирования.

Промт:

Создай docker-compose.yml для микросервисного приложения: 
- сервис api (Node.js, порт 3000)
- сервис auth (Go, порт 8080)
- PostgreSQL 16
- Redis 7
- RabbitMQ 3.12
Используй сети: frontend (для api и auth) и backend (для БД, Redis, RabbitMQ). Укажи volumes для персистентности данных. Добавь healthcheck для каждого сервиса.

Результат (фрагмент):

version: '3.9'
services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    networks:
      - frontend
      - backend
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      retries: 3
      start_period: 10s
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - backend
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      retries: 5
  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    networks:
      - backend
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      retries: 5
  rabbitmq:
    image: rabbitmq:3.12-management-alpine
    networks:
      - backend
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "check_running"]
      interval: 30s
      retries: 3

volumes:
  postgres_data:
  redis_data:

networks:
  frontend:
  backend:

Почему это важно:
- Разделение сетей изолирует сервисы: api и auth видят только друг друга, но не имеют доступа к Redis напрямую (кроме как через backend).
- Healthcheck с condition: service_healthy гарантирует, что api не запустится, пока БД не готова принимать соединения.
- Переменная ${DB_PASSWORD} позволяет не хранить секреты в репозитории.

3. Промт: «Оптимизируй Dockerfile через multi-stage для Go приложения»

Когда использовать: нужно собрать бинарник Go и упаковать его в минимальный образ (scratch или distroless).

Промт:

Напиши multi-stage Dockerfile для Go-приложения на основе официального образа golang:1.22-alpine для сборки. Второй этап — scratch или gcr.io/distroless/static-debian12. Скопируй только скомпилированный бинарник. Укажи CGO_ENABLED=0 для статической линковки, чтобы не тащить libc. Добавь метку org.opencontainers.image.source с ссылкой на репозиторий.

Результат:

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server ./cmd/server

FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
LABEL org.opencontainers.image.source="https://github.com/yourorg/yourrepo"
ENTRYPOINT ["/server"]

Результат оптимизации:
- Образ с scratch — около 7 МБ (против ~300 МБ с полным Go).
- -ldflags="-s -w" удаляет таблицу символов и DWARF-отладочную информацию, уменьшая бинарник на 20–30%.
- Статическая линковка (CGO_ENABLED=0) делает бинарник независимым от библиотек хоста.

4. Промт: «Добавь .dockerignore и проверь на утечку секретов»

Когда использовать: перед публикацией образа в registry нужно исключить лишние файлы и случайные секреты.

Промт:

Создай .dockerignore для Python-проекта. Исключи: .git, __pycache__, .env, .venv, .idea, *.log, node_modules (если есть), Dockerfile. Проверь, что не пропущены файлы с паролями (ключи, токены).

Результат:

.git
__pycache__/
*.pyc
.env
.venv/
.idea/
*.log
Dockerfile
.gitignore
secrets/
*.key
*.pem

Почему это критично:
- Без .dockerignore в образ попадает весь контекст сборки, включая .env с паролями. Docker-образ — это архив, который легко скачать и распаковать.
- __pycache__ и *.pyc — мусор, увеличивающий размер образа без пользы.
- Файлы .key и .pem (приватные ключи) никогда не должны быть в образе.

5. Промт: «Настрой логирование и мониторинг для контейнеров»

Когда использовать: нужно, чтобы логи из контейнеров отправлялись в централизованную систему (например, ELK или Grafana Loki).

Промт:

Напиши docker-compose.yml с сервисами: app (Node.js), fluentd (сборщик логов), elasticsearch 8, kibana. Настрой драйвер логов fluentd для сервиса app. Укажи volumes для персистентности Elasticsearch и конфигурацию fluentd.conf для парсинга JSON-логов.

Результат (фрагмент конфигурации fluentd.conf):

<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

<filter **>
  @type parser
  key_name log
  reserve_data true
  remove_key_name_field true
  <parse>
    @type json
  </parse>
</filter>

<match **>
  @type elasticsearch
  host elasticsearch
  port 9200
  logstash_format true
  logstash_prefix dockerlogs
</match>

Почему это удобно:
- Fluentd автоматически парсит JSON-логи (например, {"level":"error","message":"DB timeout"}) и отправляет в Elasticsearch.
- Kibana позволяет строить дашборды: количество ошибок за последний час, топ-5 эндпоинтов по latency.
- Драйвер логов fluentd — встроен в Docker, не требует установки дополнительных агентов.

6. Промт: «Проверь Dockerfile на уязвимости и best practices»

Когда использовать: перед merge request нужно убедиться, что Dockerfile соответствует OWASP и Docker best practices.

Промт:

Проанализируй следующий Dockerfile на уязвимости и нарушения best practices:
FROM ubuntu:latest
RUN apt-get update
RUN apt-get install -y python3
COPY . /app
CMD python3 /app/app.py

Найди проблемы: отсутствие конкретной версии, запуск от root, установка пакетов без очистки кэша, отсутствие HEALTHCHECK, большой образ. Предложи исправленный вариант.

Результат:
- Проблемы:
- ubuntu:latest — плавающий тег, образ может внезапно измениться.
- Два RUN можно объединить в один, чтобы уменьшить количество слоёв.
- Отсутствует очистка кэша apt (rm -rf /var/lib/apt/lists/*).
- Запуск от root.
- Нет HEALTHCHECK.

• Исправленный вариант:

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y --no-install-recommends python3 && rm -rf /var/lib/apt/lists/*
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
WORKDIR /app
COPY . .
USER appuser
HEALTHCHECK --interval=30s --timeout=3s CMD python3 -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')" || exit 1
CMD ["python3", "app.py"]

7. Промт: «Сравни инструменты для сканирования образов: Trivy vs Docker Scout vs Snyk»

Когда использовать: выбираешь инструмент для CI/CD-пайплайна.

Промт:

Сравни Trivy, Docker Scout и Snyk для сканирования Docker-образов на уязвимости. Укажи: способ интеграции в GitHub Actions, типы уязвимостей (OS, библиотеки), скорость сканирования, цена для open-source проектов. Дай рекомендацию для небольшой команды (5 человек).

Результат (таблица):

Рекомендация: Для небольшой команды — Trivy. Он быстрее, полностью бесплатен, не требует регистрации, легко встраивается в CI. Docker Scout удобен, если используешь Docker Hub и хочешь видеть уязвимости прямо в UI. Snyk — если нужен единый инструмент для кода, контейнеров и IaC (Terraform, Kubernetes).

Заключение

Эти 7 промтов закрывают 90% повседневных задач с Docker: от генерации Dockerfile до анализа безопасности. Главное — не копировать слепо, а адаптировать под свой проект.

Что запомнить:
1. Multi-stage — ваш главный инструмент для уменьшения образов.
2. Healthcheck и non-root — обязательны для production.
3. .dockerignore — спасёт от утечки секретов.
4. Trivy — лучший бесплатный сканер на 2026 год.
5. Логи через Fluentd — стандарт для централизованного сбора.

Теперь возьми любой из промтов, подставь свои параметры и получи готовый конфиг за минуту. Экономия времени — часы в неделю.