Docker, Kubernetes и Terraform под диктовку: 12 промтов, с которых я начинаю любой инфраструктурный проект

Когда я беру новый проект, первые сутки уходят не на код, а на инфраструктуру: Dockerfile, docker-compose, манифесты Kubernetes, Terraform для облака и CI/CD-пайплайн. Раньше это был день рутины и копипасты из старых репозиториев. Сейчас я открываю чат с LLM и прохожу этот этап за пару часов — но только если промт сформулирован как задача для инженера, а не как «сделай мне DevOps».

Ниже — 12 промтов, которые я реально использую. Каждый проверен на проектах разного масштаба: от пет-проджекта на одном VPS до мультисервисной системы в Kubernetes. Важно понимать: LLM не заменяет DevOps-инженера, но снимает 80% механической работы на старте — генерацию шаблонов, объяснение ошибок, ревью конфигов. Финальные решения и безопасность остаются за вами.

1. Dockerfile с объяснением каждого слоя

Промт: «Напиши production-ready Dockerfile для [стек]. Multi-stage build, non-root user, фиксированные версии базовых образов, healthcheck. После каждого блока объясни, зачем нужен слой и что будет, если его убрать».

Пример использования: для Node.js-сервиса на Fastify я получил двухэтапный Dockerfile — сборка на node:20-alpine, рантайм на том же образе с USER node. Объяснение слоёв помогло поймать ошибку: изначально npm ci копировал весь контекст, и кэш инвалидировался при любом изменении в src/. Исправили на копирование только package*.json перед установкой. Официальная документация по multi-stage: docs.docker.com/build/building/multi-stage/.

2. Диагностика ошибки сборки по логу

Промт: «Вот полный вывод docker build. Найди корневую причину, объясни механизм ошибки и предложи минимальное исправление. Не переписывай Dockerfile целиком — только проблемный участок».

Это самый частый промт в работе. Классический кейс: COPY failed: file not found in build context. LLM сразу указал на .dockerignore, который исключал нужную папку, — я бы искал дольше. Ключевой приём — запрет переписывать файл целиком: иначе получите диффы, которые страшно мержить.

3. docker-compose для локальной разработки

Промт: «Собери docker-compose.yml для локальной разработки: [сервисы]. Hot-reload для приложения, volumes для исходников, depends_on с healthcheck, отдельная сеть. Добавь комментарии, какие переменные окружения нужно задать».

Проверенный результат — compose с postgres:16-alpine, redis:7-alpine и приложением на volume-маунте. Отдельно просите healthcheck для БД: без него приложение стартует раньше базы и падает на миграциях. Документация по depends_on с условиями: docs.docker.com/compose/compose-file/.

4. Манифесты Kubernetes с resource limits

Промт: «Сгенерируй Deployment и Service для [приложение]. Обязательно: requests/limits для CPU и памяти с обоснованием цифр, liveness и readiness probes с разными параметрами, securityContext (runAsNonRoot, readOnlyRootFilesystem). Объясни, почему probes отличаются».

Пример: для API на Go получили readinessProbe с initialDelaySeconds: 5 и livenessProbe с initialDelaySeconds: 30. Объяснение простое: liveness убивает под, поэтому не должен срабатывать на старте. Это ровно то, что описано в официальных доках: kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/.

5. Разбор CrashLoopBackOff и OOMKilled

Промт: «Под в CrashLoopBackOff. Вот вывод kubectl describe pod и последние 100 строк логов. Определи: это ошибка приложения, нехватка ресурсов или проблема с probes. Дай пошаговый план диагностики».

Промт экономит часы. В одном кейсе OOMKilled оказался не из-за лимита, а из-за утечки в кэше — LLM по логам указал на растущий heap, и мы подтвердили метриками. Всегда прикладывайте describe, а не только логи: события пода содержат причины.

6. Terraform-модуль с state и backend

Промт: «Напиши Terraform-конфигурацию для [ресурс, например, VPC + EKS-кластер]. Используй remote backend (S3 + DynamoDB lock), переменные с описаниями и валидацией, outputs. Не хардкодь регион и CIDR — вынеси в variables».

Пример: модуль VPC с тремя подсетями и NAT-шлюзом. Отдельный промт — на объяснение: «почему DynamoDB для lock и что будет без него». Ответ: параллельный terraform apply повредит state. Документация: developer.hashicorp.com/terraform/language/settings/backends/s3.

7. Ревью Terraform-плана

Промт: «Вот вывод terraform plan. Найди опасные изменения: удаление ресурсов, пересоздание (force replacement) баз данных и хранилищ. Отсортируй по риску и предложи, как избежать простоя».

Этот промт я запускаю перед каждым apply в prod. Однажды он подсветил, что изменение имени security group ведёт к пересозданию — а значит, к обрыву трафика. План был скорректирован через create_before_destroy.

8. CI/CD-пайплайн с кэшем и матрицей

Промт: «Напиши GitHub Actions workflow для [стек]: сборка образа, тесты, пуш в registry, деплой в Kubernetes. Кэш слоёв Docker через buildx, матрица по версиям, отдельные job'ы с needs. Объясни, где хранить секреты».

Пример: пайплайн с docker/setup-buildx-action и cache-from: type=gha. Кэш сократил сборку заметно — точные цифры зависят от проекта, но эффект виден сразу. Секреты — только через GitHub Secrets и OIDC, без пушей токенов в код. Документация: docs.github.com/actions.

9. Helm-чарт из манифестов

Промт: «Преобразуй эти Kubernetes-манифесты в Helm-чарт. Вынеси образ, теги, реплики и ресурсы в values.yaml. Добавь _helpers.tpl для общих лейблов. Покажи, как переопределить values для staging и prod».

Промт хорош тем, что просит сразу два окружения — это выявляет хардкод. Helm-документация: helm.sh/docs/chart_template_guide/.

10. Безопасность контейнеров

Промт: «Проверь этот Dockerfile и манифесты на типичные проблемы безопасности: root-пользователь, лишние capabilities, отсутствие read-only FS, секреты в ENV, устаревшие базовые образы. Для каждой найденной — объясни риск и дай исправление».

Это ревью-промт. Часто находит FROM ubuntu:latest и ENV API_KEY=.... В Kubernetes — отсутствие securityContext. Практика: прогоняйте результат через trivy и kube-linter, LLM помогает понять отчёты. Документация: kubernetes.io/docs/concepts/security/.

11. Сеть и Ingress

Промт: «Объясни, как настроить Ingress с TLS для [домен]. Нужны: cert-manager с Let's Encrypt, аннотации для nginx-ingress, редирект с HTTP. Покажи полный набор манифестов и порядок применения».

Пример: ClusterIssuer + Ingress с аннотацией cert-manager.io/cluster-issuer. LLM верно указал порядок: сначала ingress-controller, затем cert-manager, затем ресурсы. Документация: cert-manager.io/docs/.

12. Разбор инцидента и постмортем

Промт: «Сервис упал в 03:14, восстановлен в 03:40. Вот логи, метрики и события Kubernetes за этот период. Составь таймлайн, гипотезы причин с приоритетом и черновик постмортема без обвинений».

Это промт для дежурного. Он структурирует хаос в таймлайн и не даёт забыть про action items. Важно: LLM не знает вашу систему — все гипотезы проверяются по метрикам.

Главный принцип этих промтов один: вы просите не «сделай», а «сделай и объясни, почему так». Объяснение — это ваша страховка от слепого копирования. LLM ошибается в деталях: путает версии API Kubernetes, предлагает устаревшие аннотации, забывает про state в Terraform. Поэтому каждый сгенерированный конфиг проходит через terraform plan, kubectl apply --dry-run=server и линтеры.

Если вы только начинаете — начните с промтов 1, 3 и 8: они дают максимум пользы при минимальном риске. Дальше добавляйте ревью-промты (7, 10) — именно они экономят время на код-ревью инфраструктуры. А промт 12 держите наготове: когда что-то упадёт в три ночи, структурированный разбор сэкономит вам нервы.