5.3.6. NAT и Проброс Портов

Агент может выступать в роли сетевого инженера, настраивая доступ к внутренним сервисам извне:

> "Я настрою DNAT на шлюзе 1.1, чтобы трафик на порт 8080 перенаправлялся напрямую на Backend 1.3".

5.3.7. Логирование и алертинг фаервола

Агент может настроить фаервол так, чтобы подозрительные пакеты писались в `dmesg`, а сам агент следил за этим выводом. Это создает замкнутую систему: Обнаружение -> Блокировка -> Логирование -> Анализ.

––

Резюме раздела:

Управление фаерволом через Gemini CLI превращает пассивную защиту в активную иммунную систему. Агент не просто "ставит правила", он динамически адаптирует их под текущую обстановку.

Этим разделом мы завершаем Модуль 5. В следующем модуле мы перейдем к управлению Вычислительными Мощностями – Docker, Kubernetes и процессорам.

Глава 5: Философия минималистичного промптинга: Как говорить, чтобы вас понимали

В мире агентских CLI промпт – это не просто вопрос, это техническое задание. Но есть ловушка: многие пользователи пишут либо слишком мало ("Почини"), либо слишком много ("Я хочу, чтобы ты пошел на сервер, проверил диск, если он полный, удали логи, но только те, что старые…"). В этой главе мы разберем искусство "золотой середины".

5.1. Принцип "Намерение вместо Инструкций"

Главная ошибка – пытаться микро-менеджить агента. Помните, у него есть паттерн ReAct. Если вы скажете ему "как" делать, вы лишите его возможности найти более оптимальный путь.

**Плохо:*"Запусти `df -h`, найди `/var/log` и удали файлы `.log`."

**Хорошо:*"Освободи 5ГБ места в разделе `/var`, удалив только старые архивы логов. Не трогай активные файлы."

Во втором случае агент сам решит, использовать `find`, `du` или `rm`, и проверит дескрипторы открытых файлов.

5.2. Контекстная плотность (Contextual Density)

Агент видит систему, но он не знает ваших бизнес-процессов. Добавляйте только тот контекст, который он не может получить из командной строки.

Пример эффективного промпта:

> "Мы переходим на схему 1.3 для GitLab. Проверь, готов ли текущий конфиг Caddy к приему трафика на порту 8080."

Здесь "схема 1.3" – это контекст, который агент сопоставит с вашим README или Knowledge Items, а всё остальное он проверит сам.

5.3. Структура идеального запроса

Используйте формулу [Цель] + [Ограничения] + [Ожидаемый результат]:

1. Цель: "Обнови Docker-образ фронтенда."

2. Ограничения: "Используй тег `latest`, не перезапускай контейнер в рабочее время (сейчас 14:00)."

3. Результат: "После сборки пришли мне хеш нового образа."

5.4. Магия "Уточняющих вопросов"

Хороший агент – это тот, кто спрашивает, если не уверен. Если ваш промпт двусмысленен, агент может остановиться.

*Совет:Если вы хотите, чтобы агент был более смелым, добавьте "Accepting risks: low". Если вы в критической среде – "High-stakes mode".

5.5. Как избегать "галлюцинаций в командах"

Иногда ИИ придумывает флаги команд, которых не существует (например, `ls –sort-by-magic`).

Метод защиты: Просите агента сначала вызвать `–help` для незнакомого инструмента.

> "Прежде чем настраивать WireGuard, проверь версию `wg` и доступные параметры."

––

Ключевые мысли главы:

Описывайте **желаемое состояние**, а не список команд.

**Меньше слов – больше смысла.*Избегайте вежливости ("Пожалуйста, если тебе не трудно…"), это мусорные токены.

Давайте четкие **границы допустимого**.

> [!TIP]

> Промпт в терминале – это код. Пишите его так, как если бы вы писали чистую функцию: понятное имя (команда), четкие аргументы (контекст).

В следующей главе мы перейдем к Инструментарию: глубокому разбору того, как агент "щупает" вашу систему через SSH, Grep и Docker.

Секция 6.1: Docker для агентов: Создание неизменяемых сущностей

Контейнеризация – это то, что превращает хаотичные серверы в предсказуемые блоки конструктора. Для Gemini CLI Docker является не просто инструментом, а фундаментом стабильности. В этой секции мы разберем, как агент использует Docker для создания "неизменяемой инфраструктуры" (Immutable Infrastructure).

6.1.1. Философия "Контейнер как Атомарная Мысль"

Когда вы просите агента развернуть приложение, он не устанавливает зависимости в систему. Он упаковывает их в `Dockerfile`.

**Для агента это означает:*Гарантия результата. Если образ собрался на Gateway, он будет работать и на Backend.

**Изоляция зависимостей:*Агент может запускать Python 2.7 и Python 3.12 на одной машине одновременно, не вызывая конфликтов в `pip`.

6.1.2. Промпт-инжиниринг Docker-образов

Агент Gemini CLI – виртуоз в написании `Dockerfile`. Он знает лучшие практики (Multi-stage builds, минимизация слоев, использование Alpine/Distroless).

Пример диалога с агентом:

> "Напиши Dockerfile для Go-приложения, максимально безопасный и легкий".

> *Действие агента:* Создание файла с использованием `builder` стейджа и копированием бинарника в `scratch` или `alpine`.

6.1.3. Управление жизненным циклом (Docker Compose)

Для сложных систем агент использует Docker Compose. Он видит в этом YAML-файле описание целой экосистемы (БД + API + Frontend).

Агентский инсайт:

Агент может анализировать `docker-compose.yml` и находить ошибки в сетях (например, забытый `links` или неправильное имя сервиса), которые человек может пропустить.

6.1.4. Отладка внутри контейнера (Docker Exec)

Если сервис внутри контейнера не работает, агент не гадает. Он "входит" внутрь через `run_command(cmd="docker exec -it … bash")`.

Это дает ему доступ к "микромиру" приложения. Он может проверить внутренние логи, доступность портов и переменные окружения именно так, как их видит само приложение.

6.1.5. Реестры образов и Безопасность

Агент понимает важность приватных реестров (Private Registry).

> "Я соберу образ локально, повешу на него тег вашей компании и пушну в GitLab Registry, чтобы другие узлы могли его скачать".

Проверка на уязвимости:

Агент может интегрировать инструменты типа `trivy` или `snyk` в свой цикл сборки.

**Thought:*"Перед публикацией образа я должен убедиться, что в нем нет критических уязвимостей (CVE)".

**Observation:*"Найдено 3 ошибки High. Я заменю базовый образ на более свежий".

6.1.6. Оптимизация ресурсов: Docker Prune

Автономные агенты могут генерировать много мусора (неиспользуемые слои, остановленные контейнеры).

Гигиена агента: Хорошо обученный агент Gemini CLI всегда завершает сессию очисткой: `docker system prune -f`, чтобы не забивать диск инфраструктуры.

––

Резюме раздела:

Docker дает агенту "суперсилу" воспроизводимости. Используя контейнеры, Gemini CLI перестает быть просто помощником и становится настоящим архитектором, создающим надежные и масштабируемые системы. В следующей секции мы пойдем еще дальше и разберем, как агент управляет целыми кластерами серверов через Kubernetes.

Секция 6.2: Kubernetes: Управление кластерным разумом

Если Docker – это книга, то Kubernetes – это огромная библиотека с миллионами томов, где всё движется и переставляется само собой. Для ИИ-агента Kubernetes является "естественной средой обитания", так как оба они основаны на декларативном описании желаемого состояния. В этой секции мы научим Gemini CLI управлять кластером как единым мозгом.

6.2.1. Агент против Кубернетеса: Кто кем управляет?

Kubernetes сам по себе является "агентом" (Core Controllers). Он следит за тем, чтобы количество подов совпадало с описанием.

Gemini CLI добавляет когнитивный слой над этим. Он не просто "перезапускает под", он анализирует: "Почему под падает? Связано ли это с недостатком памяти на узле 1.2 или с ошибкой в новом конфиге?".

6.2.2. Навигация в Океане Манифестов (YAML Engineering)

Одна из главных задач агента – написание и коррекция YAML-манифестов.

**Deployment:*Агент описывает, как обновлять приложение (RollingUpdate).

**Service & Ingress:*Агент настраивает внешние пути доступа.

**ConfigMaps & Secrets:*Агент управляет динамическими настройками.

Преимущество ИИ: Агент может быстро найти ошибку в `indentation` (отступах) или неправильное использование `Selectors`, на что человек может потратить 20 минут дебага.

6.2.3. Оперативное управление через `kubectl`

Агент использует `kubectl` как свои глаза.

> "Проанализируй события (events) в неймспейсе 'production'. Найди все поды со статусом ImagePullBackOff".

Агент мгновенно парсит вывод `kubectl get events -o json` и сопоставляет ошибки с конкретными действиями (например, опечатка в имени образа в Docker Registry).

6.2.4. Регрессионное тестирование в Кластере

Агент может выполнять "Канареечные релизы" (Canary Releases) в автоматическом режиме:

1. Агент разворачивает новую версию (V2) рядом с V1.

2. Направляет 5% трафика на V2.

3. Следит за метриками ошибок.

4. Если всё хорошо – делает Full Rollout. Если нет – делает моментальный Rollback.

6.2.5. Управление ресурсами: ЦПУ и Память

Агент играет роль "экономки" кластера. Он анализирует `ResourceQuotas` и `Limits`.

**Действие:*"Я вижу, что под `legal-bot` потребляет 90% лимита памяти. Я увеличу лимиты в манифесте и применю изменения".

**Размышление:*"Достаточно ли места на физических узлах для этого расширения?".

6.2.6. Кастомные ресурсы (CRDs) и Операторы

Продвинутый агент может писать собственные Kubernetes Operators на Python или Go. Это позволяет создавать абсолютно автономную инфраструктуру, которая не только чинит себя, но и эволюционирует на основе данных о нагрузке.

––

Резюме раздела:

Kubernetes для Gemini CLI – это не инструмент, это манифест его воли. Используя мощь оркестрации, агент превращает разрозненные серверы в гибкую и неубиваемую систему. В следующей секции мы разберем, как не допустить "выгорания" этой системы через глубокий мониторинг ресурсов.

Секция 6.3: Мониторинг ресурсов и борьба с "утечками памяти" ИИ

Автономный агент – это "жадное" существо. Он потребляет ЦПУ для выполнения команд, память для хранения контекста и пропускную способность сети для доступа к API. Если не следить за его "аппетитом", он может привести к отказу всей системы. В этой финальной секции Модуля 6 мы научимся мониторить "метаболизм" агента и предотвращать ресурсные катастрофы.