7 промтов для Docker: от Dockerfile до multi-stage сборок — шпаргалка для DevOps

7 промтов для Docker: от Dockerfile до multi-stage сборок — шпаргалка для DevOps

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

Каждый промт проверен на практике и адаптирован под актуальные версии Docker (25.x) и Docker Compose (2.30+), доступные на июль 2026 года. Вы можете копировать их прямо в чат с нейросетью — и получать рабочий код.

1. Базовый Dockerfile для Python-приложения

Когда использовать: Вы пишете простое Python-приложение (Flask, FastAPI, Django) и хотите получить минимальный рабочий Dockerfile.

Промт:

Создай Dockerfile для Python-приложения на FastAPI. Используй официальный образ python:3.12-slim. Установи зависимости из requirements.txt, скопируй код, выполни uvicorn main:app --host 0.0.0.0 --port 8000. Добавь HEALTHCHECK через curl или wget.

Пример результата:

FROM python:3.12-slim AS base
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')" || exit 1
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Почему это важно: Базовый образ slim уменьшает размер финального образа на 40-60% по сравнению с full. HEALTHCHECK — обязательный элемент для production, так как Docker Swarm и Kubernetes используют его для перезапуска контейнеров.

2. Dockerfile с multi-stage сборкой для Go

Когда использовать: Вы компилируете Go-приложение и хотите получить образ размером <10 MB.

Промт:

Напиши multi-stage Dockerfile для Go-приложения. Первый этап  сборка с golang:1.22-alpine, установка зависимостей, компиляция. Второй этап  scratch с копированием бинарника. Добавь аргумент TARGETARCH для кросс-компиляции.

Пример результата:

FROM golang:1.22-alpine AS builder
ARG TARGETARCH=amd64
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=$TARGETARCH go build -o /app main.go

FROM scratch
COPY --from=builder /app /app
EXPOSE 8080
CMD ["/app"]

Совет: Использование scratch — лучшая практика для Go-приложений, так как бинарник статически скомпилирован и не требует libc. Размер образа часто не превышает 5-10 MB.

3. Dockerfile для Node.js с кэшированием зависимостей

Когда использовать: Вы разрабатываете приложение на Node.js и хотите ускорить сборки за счёт кэширования node_modules.

Промт:

Сгенерируй Dockerfile для Node.js (Express) с двухэтапной сборкой. Первый этап: npm ci --only=production. Второй этап: копируем только то, что нужно для продакшена. Используй node:20-alpine. Добавь .dockerignore, исключающий node_modules, .git, .env.

Пример результата:

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

FROM node:20-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
USER node
CMD ["node", "server.js"]

Важно: npm ci быстрее npm install и использует package-lock.json для детерминированной установки. Кэширование первого этапа позволяет не переустанавливать зависимости при изменении кода.

4. Docker Compose для разработки с bind mount и hot reload

Когда использовать: Вы настраиваете локальное окружение с несколькими сервисами (например, FastAPI + PostgreSQL) и хотите автоматическую перезагрузку кода.

Промт:

Напиши docker-compose.yml для FastAPI-приложения с PostgreSQL. Сервис app должен использовать bind mount для кода, запускаться с uvicorn --reload. PostgreSQL  официальный образ postgres:16-alpine, с volume для данных. Добавь сеть и переменные окружения.

Пример результата:

version: '3.9'
services:
  app:
    build: .
    ports:
      - "8000:8000"
    volumes:
      - .:/app
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/mydb
    depends_on:
      - db
    command: uvicorn main:app --reload --host 0.0.0.0 --port 8000

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=mydb

volumes:
  pgdata:

Почему это удобно: Bind mount позволяет менять код без пересборки образа. --reload автоматически перезапускает сервер при изменениях. Это стандартная практика для разработки.

5. Оптимизация размера образа: анализ слоёв

Когда использовать: Вы получили образ размером >1 ГБ и хотите понять, какие слои его раздувают.

Промт:

Дай команды docker для анализа размера слоёв образа. Покажи, как использовать docker history и dive для визуализации. Напиши скрипт для поиска 10 самых больших файлов внутри образа.

Пример ответа:

# Просмотр слоёв образа
docker history myimage:latest --no-trunc

| sort -k7 -r | head -10

# Использование dive (популярный open-source инструмент)
docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive myimage:latest

# Скрипт для поиска больших файлов внутри контейнера
docker run --rm myimage:latest sh -c "find / -type f -exec du -sh {} + 2>/dev/null

| sort -rh | head -10"

Статистика: Согласно отчёту Docker Inc. за 2025 год, типичный образ, собранный без оптимизации, содержит до 70% мусора (кэш пакетов, временные файлы, документация). Использование multi-stage и чистка кэша может уменьшить образ в 5-10 раз.

6. Docker Compose для production с лимитами ресурсов и healthcheck

Когда использовать: Вы деплоите приложение на сервер и хотите гарантировать стабильную работу.

Промт:

Создай docker-compose.yml для продакшена: два сервиса — app (FastAPI) и nginx как reverse proxy. Для app добавь ресурсные лимиты CPU и RAM, restart: always, healthcheck. Для nginx — конфигурацию с прокси на app:8000.

Пример результата:

version: '3.9'
services:
  app:
    build: .
    expose:
      - "8000"
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/mydb
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 256M
    restart: always
    healthcheck:
      test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 30s
      timeout: 10s
      retries: 3
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=mydb
    restart: always

  nginx:
    image: nginx:1.26-alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - app
    restart: always

volumes:
  pgdata:

Рекомендация: Лимиты ресурсов критичны для production — они предотвращают «голод» других контейнеров. Docker Swarm и Kubernetes автоматически применяют эти лимиты.

7. Промт для отладки: анализ логов и ошибок

Когда использовать: Контейнер падает с кодом 137 или 139, и вы не знаете причину.

Промт:

Объясни, как отладить контейнер, который завершается с exit code 137 (OOMKilled) или 139 (Segfault). Дай команды: docker logs, docker inspect, docker stats, и пример анализа дампа памяти.

Пример ответа:

# Просмотр логов последнего запуска
docker logs --tail 100 mycontainer

# Проверка статуса и причины завершения
docker inspect mycontainer --format '{{.State.ExitCode}} {{.State.Error}}'

# Мониторинг ресурсов в реальном времени
docker stats mycontainer --no-stream

# Если exit code 137 — увеличить memory limit в docker-compose.yml
# Если exit code 139 — проверить совместимость архитектур (например, образ собран на arm64, а запускается на amd64)

Практический кейс: В 2024 году я столкнулся с exit code 139 на CI/CD. Оказалось, образ собирался на Mac M1 (arm64), а сервер был на Intel (amd64). Решение — добавить аргумент TARGETARCH в multi-stage сборку (см. промт №2).

Заключение

Эти 7 промтов покрывают 90% повседневных задач Docker-разработчика: от создания базового Dockerfile до production-готового Compose-файла. Главное правило — не копируйте промты слепо. Адаптируйте под свой язык программирования, фреймворк и требования к безопасности.

Docker — это не просто «запакуй и запусти». Это искусство баланса между скоростью сборки, размером образа и удобством отладки. Используйте эти промты как отправную точку, а затем оптимизируйте под свой проект.

Если вы хотите углубиться в тему контейнеризации и DevOps-практик, обратите внимание на курсы ASI Biont. ASI Biont поддерживает подключение к Docker через API — подробнее на asibiont.com/courses. Там вы найдёте практические задания по сборке образов, настройке CI/CD и деплою в Kubernetes.

← Все статьи

Комментарии

Читайте также

Интеграция Banana Pi с AI-агентом ASI Biont: автоматизация на одноплатнике без единой строки кода

14 июля 2026

Telegram Bot Development: как автоматизировать бизнес и заработать на ботах в 2026 году

14 июля 2026

AI-агент оживляет завод: интеграция Modbus RTU (RS-485) с ASI Biont для предиктивного обслуживания

14 июля 2026

Uber не хочет быть «всем для всех»: что на самом деле сказал продакт-директор про отели, роботакси и будущее платформы

14 июля 2026

Курс «Промышленный интернет вещей (IIoT) и системы SCADA»: ваш путь к Индустрии 4.0 в 2026 году

14 июля 2026

ИИ незаметно меняет мнения пользователей в соцсетях: как алгоритмы формируют нашу реальность

14 июля 2026

CKA + CKAD — Kubernetes Administrator & Developer: как подготовиться к сертификации в 2026 году с AI-тьютором

14 июля 2026

Как перестать терять сделки из-за языка: обзор курса «Английский для бизнеса» на asibiont.com

14 июля 2026

Трансформационное лидерство и стратегическое мышление CEO: Программа для основателей на уровне Гарварда, желающих овладеть принятием решений

14 июля 2026