Docker и Kubernetes без боли: 12 промтов, которые переводят DevOps с языка документации на человеческий

Docker и Kubernetes без боли: 12 промтов, которые переводят DevOps с языка документации на человеческий

Каждый, кто хоть раз собирал Docker-образ впервые, знает это чувство: docker build падает на шаге 7 из 12, лог обрывается на невнятной ошибке, а официальная документация отправляет читать три соседних раздела и RFC. Kubernetes добавляет к этому YAML с отступами, которые ломают деплой из-за одного пробела. А дебаг CI/CD в GitLab или GitHub Actions порой превращается в археологию: почему пайплайн зелёный локально и красный в CI?

Хорошая новость: LLM (ChatGPT, Claude, Gemini) уже сейчас снимают существенную часть этой рутины — если давать им правильные промты. Плохая новость: «помоги с Dockerfile» даёт результат уровня Stack Overflow 2019 года. Разница — в структуре запроса: роль, контекст, ограничения, формат вывода.

Ниже — 12 готовых промтов с пояснениями и примерами. Копируйте, подставляйте свои данные, адаптируйте. Все примеры команд и синтаксис проверены по официальной документации Docker (docs.docker.com) и Kubernetes (kubernetes.io/docs).

1. Dockerfile с нуля под конкретный стек

Задача: быстро получить production-ready Dockerfile без копипаста из туториалов 2018 года.

Промт:

Ты — senior DevOps-инженер. Напиши production-ready Dockerfile для [стек: например, Python 3.12 + FastAPI + uvicorn].
Требования:
- multi-stage build
- базовый образ: [python:3.12-slim / node:20-alpine и т.п.]
- непривилегированный пользователь (non-root)
- кэширование слоёв: сначала зависимости, потом код
- HEALTHCHECK
- .dockerignore тоже покажи
- итоговый размер образа — минимально возможный
В конце: 3 пункта, что можно улучшить, если нужен ещё меньший размер.

Почему работает: вы явно задаёте роль, стек, ограничения и просите объяснить trade-off. Модель не «фантазирует» стек, а следует чек-листу.

Пример использования: для FastAPI-сервиса получите примерно такой каркас:

FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt

FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
RUN useradd -m appuser && chown -R appuser /app
USER appuser
HEALTHCHECK --interval=30s CMD curl -f http://localhost:8000/health || exit 1
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

2. Разбор ошибки docker build

Задача: превратить невнятный лог сборки в понятный диагноз и фикс.

Промт:

Вот лог ошибки docker build:
---
[вставь полный лог, включая последние 20 строк]
---
Мой Dockerfile:
---
[вставь Dockerfile]
---
1) Объясни простыми словами, что сломалось и на каком шаге.
2) Дай минимальный фикс (diff или исправленный фрагмент).
3) Назови 2 типичные причины этой же ошибки, чтобы я узнавал её в будущем.
4) Если проблема в кэше слоёв — покажи команду для его сброса.

Почему работает: вы даёте и лог, и Dockerfile — модель видит контекст, а не гадает. Пункт 3 превращает промт в обучающий.

Пример: ошибка failed to solve: process "/bin/sh -c apt-get install -y curl" did not complete successfully: exit code: 100 — модель объяснит, что apt не нашёл пакет или нет apt-get update перед install, и предложит добавить RUN apt-get update && apt-get install -y --no-install-recommends curl && rm -rf /var/lib/apt/lists/*.

3. Отладка docker-compose

Задача: сервисы не видят друг друга, порты заняты, volumes не монтируются.

Промт:

Ты — DevOps. У меня docker-compose.yml с сервисами [перечисли: app, db, redis, nginx].
Файл:
---
[вставь docker-compose.yml]
---
Симптом: [например, app не может подключиться к db по hostname 'db']
Проверь:
- корректность network (все ли сервисы в одной сети)
- healthcheck и depends_on: condition
- проброс портов (ports vs expose)
- переменные окружения для подключения (host, port)
Выведи таблицу:

| проблема | где в файле | как исправить | и дай исправленный фрагмент.

Почему работает: вы просите таблицу — это заставляет модель систематизировать, а не выдавать поток сознания. Таблица из 5-7 строк легко проверяется глазами.

Пример: типичный кейс — app использует localhost:5432 вместо db:5432. Модель укажет на переменную DATABASE_URL и предложит postgresql://user:pass@db:5432/mydb.

4. Генерация Kubernetes Deployment + Service

Задача: получить корректные манифесты, которые реально применяются без ошибок валидации.

Промт:

Сгенерируй Kubernetes-манифесты (apiVersion apps/v1 и v1) для сервиса:
- образ: registry.example.com/app:1.4.2
- 3 реплики
- requests: cpu 100m, memory 128Mi; limits: cpu 500m, memory 512Mi
- livenessProbe и readinessProbe на /health (порт 8000)
- Service типа ClusterIP, порт 80 -> 8000
- labels: app=myapp, env=prod
Требования:
- используй recommended labels (kubernetes.io/name)
- добавь securityContext: runAsNonRoot, readOnlyRootFilesystem
- верни ОДИН YAML-файл с разделителем ---
В конце: как проверить через kubectl apply --dry-run=server.

Почему работает: --dry-run=server — реальная команда (см. kubernetes.io/docs/reference/kubectl/), она валидирует против живого API-сервера. Модель, которую вы просите её упомянуть, чаще выдаёт синтаксически чище манифесты.

Пример проверки:

kubectl apply --dry-run=server -f deployment.yaml

5. Диагностика CrashLoopBackOff

Задача: под падает и рестартится, а причина непонятна.

Промт:

Под в Kubernetes в состоянии CrashLoopBackOff. Вот вывод команд:
---
kubectl describe pod [имя]
[вставь]
---
kubectl logs [имя] --previous
[вставь]
---
Составь пошаговый план диагностики (что смотреть и в каком порядке: events, logs, probes, resources, image pull, configmap/secret).
Для каждого шага — конкретная команда kubectl.
В конце — 3 наиболее вероятные причины для моего случая с обоснованием.

Почему работает: kubectl logs --previous — настоящий флаг для логов предыдущего контейнера. Промт заставляет модель не гадать, а строить дерево диагностики.

Пример: частый сценарий — приложение стартует дольше, чем initialDelaySeconds в livenessProbe. Модель посоветует увеличить задержку или добавить startupProbe.

6. Объяснение «страшного» YAML

Задача: разобрать чужой Helm-чарт или манифест, который «работает, но непонятно почему».

Промт:

Объясни этот Kubernetes-манифест построчно человеку, который знает Docker, но только начинает с K8s:
---
[вставь YAML]
---
Формат: комментарий к каждой ключевой строке + блок «что произойдёт при kubectl apply» (какие объекты создадутся, в каком порядке).
Отдельно объясни: зачем здесь [initContainers / volumes / affinity] и что будет, если убрать.

Почему работает: «человеку, который знает Docker, но только начинает» — это точная калибровка уровня. Без неё модель либо льёт воду, либо сыпет терминами.

7. CI/CD пайплайн для GitHub Actions

Задача: собрать пайплайн build → test → push в registry → деплой в кластер.

Промт:

Напиши GitHub Actions workflow (.github/workflows/deploy.yml) для проекта [стек].
Этапы:
1) checkout + setup [языка]
2) кэш зависимостей
3) тесты
4) docker buildx build и push в [ghcr.io / Docker Hub] с тегом = git SHA
5) деплой в Kubernetes через kubectl set image (или helm upgrade)
Требования:
- секреты через ${{ secrets.* }}
- concurrency для отмены старых запусков
- матрица тестов: [версии]
- комментарии к неочевидным шагам
В конце: список секретов, которые нужно завести в репозитории.

Почему работает: concurrency — реальный ключ в GitHub Actions (docs.github.com/actions), тег по git SHA — стандартная практика immutable-образов. Модель, которую просят перечислить секреты, не забудет про GITHUB_TOKEN.

8. GitLab CI: разбор упавшего джоба

Задача: пайплайн падает в CI, но проходит локально.

Промт:

Ты — CI/CD инженер. Джоб [имя] в GitLab CI падает, локально всё работает.
.gitlab-ci.yml:
---
[вставь]
---
Лог джоба (tail -100):
---
[вставь]
---
Верни:
1) гипотезы различий локально vs CI (окружение, переменные, кэш, права, сеть)
2) для каждой — как проверить (конкретная команда или изменение в yml)
3) исправленный фрагмент .gitlab-ci.yml

Почему работает: «локально vs CI» — известный класс проблем (другой образ, другой пользователь, отсутствие переменной). Промт явно просит сравнить окружения, а не просто «починить».

9. Секреты и переменные окружения — аудит

Задача: не закоммитить пароль и правильно пробросить секреты в K8s/Docker.

Промт:

Проведи аудит безопасности конфигурации:
---
[вставь docker-compose.yml / deployment.yaml / .env.example]
---
Найди:
- захардкоженные секреты (пароли, токены, ключи)
- секреты в ENV вместо Secret/K8s Secret
- отсутствие .gitignore для .env
Для каждой находки: severity (high/medium/low), чем опасно, как исправить (пример с docker secrets или K8s Secret).
Верни таблицу:

| находка | severity | фикс |

Почему работает: формат «severity + фикс» — стандарт security-ревью. Таблица удобна для трекера задач.

10. Оптимизация образа: «почему он весит 2 ГБ»

Задача: образ раздулся, pull в кластере занимает минуты.

Промт:

Мой Docker-образ весит [X ГБ]. Dockerfile:
---
[вставь]
---
1) оцени, какие слои дают основной вклад (обоснованно)
2) предложи 5 конкретных оптимизаций с ожидаемым эффектом
3) покажи diff Dockerfile
4) какие инструменты проверить размер слоёв (dive, docker history — с командой)

Пром почему полезен: docker history <image> — реальная команда для просмотра слоёв, dive — реальный инструмент (github.com/wagoodman/dive). Модель, которую просят конкретные команды, реже уходит в абстракции.

11. Перевод «с Docker Compose на Kubernetes»

Задача: переехать с compose на кластер без сюрпризов.

Промт:

У меня docker-compose.yml:
---
[вставь]
---
Составь план миграции в Kubernetes:
- какие K8s-объекты соответствуют каждому сервису (Deployment/StatefulSet/Service/Ingress/PVC/ConfigMap/Secret)
- что нельзя перенести 1:1 и почему (volumes, depends_on, build)
- порядок применения (что раньше: Secret, ConfigMap, DB, app)
- чек-лист «готово к прод» (probes, resources, PDB, HPA)
Выведи таблицу соответствия и пошаговый план.

Почему работает: depends_on в compose не имеет прямого аналога в K8s — модель, которую просят объяснить «что нельзя 1:1», честно назовёт это ограничение вместо выдумки.

12. Регулярный «health-check» инфраструктуры

Задача: периодически прогонять конфиги на типовые ошибки и антипаттерны.

Промт:

Выступи в роли ревьюера production-инфраструктуры. Проверь набор файлов:
---
[вставь Dockerfile, compose, k8s-манифесты, CI-yml]
---
Дай отчёт по чек-листу:
- нет ли :latest тегов в проде
- заданы ли resources.requests/limits
- есть ли liveness/readiness probes
- non-root пользователь в контейнере
- секреты не в открытом виде
- есть ли откат (rollback) в CI/CD
Каждый пункт: ✅/❌ + строка с местом проблемы + рекомендация.

Почему работает: чек-лист — это способ зафиксировать экспертизу в промте. Такой отчёт можно гонять раз в спринт как «линтер» инфраструктуры.

Как адаптировать эти промты под себя

Пара практических советов. Во-первых, всегда давайте модели полный контекст: лог + конфиг + симптом. Половина плохих ответов — из-за неполного ввода. Во-вторых, проверяйте команды и синтаксис по официальной документации: LLM ошибаются в деталях, особенно в новых версиях K8s и в специфичных флагах. В-третьих, храните удачные промты в репозитории рядом с конфигами — через месяц вы скажете себе спасибо.

Docker и Kubernetes не станут проще, но перестанут быть «чёрным ящиком». Промт — это не замена пониманию, а ускоритель: он превращает невнятную ошибку в гипотезу, а гипотезу — в проверяемый шаг. Начните с одного промта из списка — например, с разбора упавшего docker build — и посмотрите, сколько времени освободится. А если хотите системно прокачать DevOps-базу, совмещайте такие промты с практикой на реальных конфигах: именно повторяемые сценарии (сборка, деплой, дебаг) дают навык, который остаётся с вами.

Полезные источники:
- Docker Docs: docs.docker.com (Dockerfile reference, buildx, compose)
- Kubernetes Docs: kubernetes.io/docs (kubectl, probes, resources)
- GitHub Actions: docs.github.com/actions
- GitLab CI: docs.gitlab.com/ee/ci/
- dive (анализ слоёв образа): github.com/wagoodman/dive