ChatGPT как DevOps-инженер: 12 промтов для Docker, Kubernetes, Terraform и CI/CD, которые реально работают

ChatGPT как DevOps-инженер: 12 промтов для Docker, Kubernetes, Terraform и CI/CD, которые реально работают

DevOps-инженер сегодня проводит часы на рутине: пишет Dockerfile под очередной сервис, читает kubectl describe на 200 строк, копается в ошибках Terraform-планирования, дёргает коллег ради ревью YAML. По данным опроса Stack Overflow Developer Survey, конфигурация и инфраструктура стабильно входят в число самых раздражающих задач разработчика — и именно здесь LLM дают максимальный выигрыш, если давать им правильные вводные.

Проблема в том, что «напиши мне Dockerfile» даёт посредственный результат: модель не знает вашу версию Python, размер образа, требования безопасности и то, что вы уже третий день дебажите падающий под. Промт должен содержать контекст, ограничения и формат ответа — как тикет в Jira, только для модели.

Ниже — 12 промтов, проверенных на реальных задачах. Каждый устроен одинаково: задача → шаблон для копипаста → пример входа и выхода → какую рутину закрывает. Все примеры кода рабочие и соответствуют актуальным версиям инструментов (Docker Engine 27+, Kubernetes 1.30+, Terraform 1.9+, GitHub Actions).

Промты для Docker: образы, которые не стыдно пушить

1. Production-ready Dockerfile с multi-stage сборкой и non-root

Задача: быстро получить минимальный безопасный образ вместо FROM python:latest с COPY . ..

Ты senior DevOps-инженер. Напиши production Dockerfile для [язык/фреймворк] приложения.
Требования:
- multi-stage сборка (builder + runtime)
- базовый образ: [образ и тег, например python:3.12-slim]
- запуск от non-root пользователя
- кэширование зависимостей отдельным слоем
- HEALTHCHECK
- финальный образ < [N] МБ
Приложение: [краткое описание, менеджер зависимостей, точка входа].
Выведи Dockerfile с комментариями, почему выбран каждый слой, и команду сборки.

Пример выхода (фрагмент):

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
RUN useradd -m appuser
WORKDIR /app
COPY --from=builder /root/.local /home/appuser/.local
COPY --chown=appuser . .
USER appuser
ENV PATH=/home/appuser/.local/bin:$PATH
HEALTHCHECK CMD curl -f http://localhost:8000/health || exit 1
CMD ["uvicorn", "main:app", "--host", "0.0.0.0"]

Закрывает: 20–30 минут ручной сборки образа, попытки уложиться в лимиты registry и забытый USER root на ревью.

2. Разбор ошибки сборки Docker с гипотезами и фиксами

Задача: сборка падает на шаге npm ci или pip install, и непонятно почему.

Сборка Docker падает. Вот Dockerfile и последние 50 строк вывода ошибки.
Определи корневую причину, предложи 3 варианта фикса с плюсами/минусами
и дай исправленный Dockerfile.
Dockerfile: [вставить]
Лог: [вставить]
Окружение: [ОС хоста, архитектура, версия Docker].

Закрывает: поиск по Stack Overflow по тексту ошибки и пересборки «на удачу» — модель сразу указывает на несовместимость архитектур (arm64 vs amd64), отсутствие build-зависимостей или неверный .dockerignore.

3. Оптимизация размера и времени сборки существующего образа

Проанализируй Dockerfile и предложи оптимизации: размер образа, слои, кэш, безопасность.
Для каждого изменения укажи ожидаемый эффект (МБ / секунды) и риск.
Dockerfile: [вставить]
Текущий размер образа: [X] МБ, время сборки: [Y] сек.

Закрывает: регулярный аудит образов, который обычно откладывают до момента, когда registry начинает ругаться на лимиты.

Kubernetes: диагностика и манифесты без боли

4. Диагностика падающего пода по describe и логам

Задача: под в CrashLoopBackOff, а причина неочевидна.

Ты SRE. Под в Kubernetes не стартует. Вот вывод `kubectl describe pod` и последние 100 строк логов.
Дай: 1) наиболее вероятную причину, 2) альтернативные гипотезы, 3) конкретные команды для проверки каждой,
4) исправленный манифест или команду для устранения.
Describe: [вставить]
Логи: [вставить]

Закрывает: 30-минутные сессии kubectl get events -w, когда проблема в забытом resources.limits (OOMKilled), неправильном readinessProbe или отсутствующем Secret. Модель читает события и указывает на конкретный Reason.

5. Манифест Deployment + Service + Ingress с probes и ресурсами

Сгенерируй Kubernetes-манифесты (Deployment, Service, Ingress, HPA) для сервиса.
Параметры: образ [image:tag], реплики [N], порт [P], домен [domain], CPU/RAM лимиты [значения].
Обязательно: liveness/readiness/startup probes, securityContext (non-root, readOnlyRootFilesystem),
resource requests/limits, topologySpreadConstraints для HA.
Выведи YAML с комментариями и объясни, почему выбраны пороги probes.

Закрывает: копирование манифестов из соседнего проекта и забытые probes, из-за которых трафик идёт на непрогретые поды.

6. Аудит безопасности манифеста (RBAC, NetworkPolicy, secrets)

Проведи security review Kubernetes-манифестов. Найди: избыточные права RBAC, отсутствие NetworkPolicy,
секреты в открытом виде, privileged/allowPrivilegeEscalation, hostPath.
Дай таблицу: проблема

| риск | исправление.
Манифесты: [вставить]

Закрывает: ручной чек-лист перед релизом в прод — полезно как второй глаз перед kubectl apply.

7. Объяснение сложного YAML простым языком

Объясни построчно, что делает этот Kubernetes-манифест, и укажи потенциальные проблемы при деплое.
Манифест: [вставить]

Закрывает: онбординг новых инженеров и разбор чужого Helm-чарта перед правкой.

Terraform: инфраструктура как код без сюрпризов

8. Генерация Terraform-модуля с best practices

Напиши Terraform-модуль для [ресурс, например AWS VPC с приватными и публичными сабнетами].
Требования: переменные с типами и описаниями, валидация, outputs, версии провайдеров закреплены,
никаких хардкодов, тегирование через locals. Совместимость с Terraform 1.9+.
Выведи структуру файлов и содержимое каждого.

Закрывает: полдня на копирование примеров из документации провайдера и приведение их к единому стилю проекта.

9. Чтение terraform plan и объяснение диффа

Вот вывод `terraform plan`. Объясни, какие изменения произойдут с инфраструктурой,
что будет пересоздано (recreate) и какие риски это несёт для продакшена.
Отдельно выдели изменения, которые приведут к downtime.
Plan: [вставить]

Закрывает: страх нажать apply — модель подсвечивает forces replacement и ресурсы, которые исчезнут.

10. Миграция ручной инфраструктуры в Terraform (import)

У меня есть ресурсы, созданные вручную в [cloud]. Составь пошаговый план импорта их в Terraform:
какие блоки `import` и `resource` написать, как проверить `plan` без изменений, как избежать удаления.
Список ресурсов: [перечислить ID и типы]

Закрывает: самый нервозный этап внедрения IaC — перенос существующего прод-окружения без простоя.

CI/CD: пайплайны, которые не ломаются на пятницу

11. GitHub Actions workflow с кэшем, матрицей и деплоем

Сгенерируй GitHub Actions workflow для [проект].
Шаги: lint → тесты → сборка Docker-образа → push в registry → деплой в [Kubernetes/сервер].
Требования: кэш зависимостей, matrix по [версии], secrets через env, concurrency-группа,
запуск только на нужных ветках. Выведи YAML и список secrets, которые нужно завести.

Закрывает: сборку пайплайна с нуля и типичные ошибки — отсутствие кэша (сборка в 3 раза дольше), деплой из PR-ветки, утечка токенов в логах.

12. Разбор упавшего CI-джоба по логу

CI-пайплайн упал. Вот лог упавшего шага и YAML workflow.
Определи причину, предложи фикс и объясни, как предотвратить повторение (добавить проверку/кэш/таймаут).
Лог: [вставить]
Workflow: [вставить]

Закрывает: дебаг «зелёного локально, красного в CI» — обычно дело в окружении, версиях или отсутствующих переменных.

Как выжимать максимум из этих промтов

Промты — это не замена инженеру, а ускоритель: модель отлично генерирует черновики и объясняет чужой код, но финальное решение, ревью и ответственность за прод остаются за вами. Всегда проверяйте сгенерированные манифесты и plan перед применением — особенно в продакшене. Начните с одного промта из тех, что закрывают вашу самую частую рутину, и постепенно соберите личную библиотеку шаблонов под свой стек.