Читать книгу: «Gemini CLI – исчерпывающее руководство», страница 4

Name: Gemini CLI – исчерпывающее руководство
Rating: 3.7 (3 reviews)
Author: Ранас Мукминов

Ранас Мукминов

Шрифт:

4.2.3. Специфические переменные Gemini CLI

Агент имеет собственный набор настроек, которые можно передавать через `env`:

`GEMINI_API_KEY`: Очевидная, но критическая переменная.

`GEMINI_MAX_STEPS`: Лимит шагов рассуждения (защита от зацикливания).

`GEMINI_TEMP_DIR`: Путь к временным файлам, которые агент создает во время работы.

4.2.4. Передача контекста через Кастомные Переменные

Вы можете "подсказать" агенту особенности вашей архитектуры, используя кастомные префиксы:

export INFRA_GATEWAY_IP="10.252.1.1"

export INFRA_BACKEND_PORT="8080"

Когда агент видит такие переменные (через команду `env`), он автоматически включает их в свой контекст планирования. Это избавляет вас от необходимости каждый раз писать IP-адреса в промпте.

4.2.5. Секреты и безопасность переменных

Переменные окружения часто видны в выводе `ps aux` или через `/proc/`.

Правило безопасности: Никогда не храните мастер-пароли баз данных в `$ENV`. Используйте переменные только для хранения путей к секретам (например, `DB_PASSWORD_FILE=/run/secrets/db_pass`). Агент достаточно умен, чтобы прочитать файл, когда ему это понадобится.

4.2.6. Динамическое управление средой (dotenv)

Использование файлов `.env` в корне ваших проектов позволяет изолировать настройки разных приложений для агента. Когда агент заходит в папку `project-a/`, он подгружает специфические переменные этого проекта.

––

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

Правильная настройка переменных окружения превращает хаотичную систему в упорядоченную среду, где агент ориентируется с закрытыми глазами. Помните: чем меньше "шума" в вашем `env` и чем больше в нем структурированной информации о вашей инфраструктуре, тем точнее будут действия Gemini CLI. В следующей секции мы научим агента работать "в тени" с помощью Tmux и Screen.

Секция 4.3: Терминальные мультиплееры (Tmux, Screen): Агент, который никогда не спит

Работая с Gemini CLI, вы часто будете сталкиваться с задачами, которые длятся часы (например, полная пересборка инфраструктуры или миграция данных). Вы не можете держать терминал открытым всё это время. В этой секции мы изучим, как использовать Tmux и Screen для создания персистентных агентских сессий.

4.3.1. Философия "Отложенного Сознания"

Классический запуск агента в консоли – это интерактивный процесс. Если интернет пропал, сессия SSH рвется, и агент погибает на полпути.

Терминальный мультиплеер позволяет агенту продолжать рассуждения в фоне. Вы можете отключиться от сервера, пойти спать, а утром подключиться и увидеть выполненную задачу.

4.3.2. Tmux: Профессиональный выбор для ИИ

Tmux (Terminal Multiplexer) – это стандарт индустрии. Он позволяет создавать окна, панели и, главное, сессии.

Как агент использует Tmux:

1. Создание сессии: `tmux new -s gemini-audit`

2. Запуск задачи: Внутри сессии запускается Gemini CLI.

3. Отключение (Detach): `Ctrl+B, D`. Агент продолжает работать.

4. Подключение (Attach): `tmux attach -t gemini-audit`. Вы возвращаетесь в тот же контекст.

Технический нюанс: Агенту не обязательно знать, что он внутри Tmux. Однако, если вы даете ему инструменты управления Tmux (через кастомные MCP), он может сам создавать новые окна для параллельных задач. Один агент дебажит базу в окне 1, а в окне 2 следит за логами Nginx.

4.3.3. Screen: Старая школа жизни

GNU Screen – предшественник Tmux. Он проще, но надежен как танк. Его часто используют на старых серверах или в минималистичных дистрибутивах.

**Команда запуска:*`screen -S gemini-task1`.

**Преимущество:*Screen лучше справляется с очень старыми типами терминалов и требует меньше ресурсов.

4.3.4. Автоматизация: Агент, запускающий сессии

Продвинутый сценарий – когда вы просите агента: "Запусти пересборку Docker-образов во второй сессии Tmux, а здесь продолжай следить за инцидентом".

Агент сгенерирует примерно такой скрипт:

tmux new-window -n "docker-build" "cd /app && docker-compose build"

Это делает агента многозадачным. Он может эффективно распределять когнитивную нагрузку между несколькими процессами.

4.3.5. Ловушки фоновых сессий

Главная опасность – забыть про работающего агента. ИИ-агент потребляет токены API. Если вы оставили его в бесконечном цикле в сессии Tmux, которую "забыли", вы можете получить огромный счет.

Меры предосторожности:

Используйте `tmux-logging` плагины, чтобы все действия из скрытых окон писались в файлы.

Всегда ставьте лимит времени в самом промпте: "Работай не более 30 минут, после чего остановись, даже если задача не решена".

4.3.6. Сравнительная таблица мультиплееров

| Характеристика | Tmux | Screen |

| :– | :– | :– |

| Гибкость панелей | Высокая (разбиение окон) | Низкая (только полноэкранные) |

| Скриптуемость | Отличная (команда `tmux`) | Средняя |

| Ресурсы | Чуть выше | Минимальные |

| Контекст ИИ | Идеален для мультизадачности | Хорош для простых фоновых дел |

––

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

Терминальные мультиплееры – это способ дать агенту "тело", которое не зависит от вашего присутствия. Используя Tmux, вы превращаете Gemini CLI в настоящего демона (daemon), который может управлять миром, пока вы не смотрите.

Этим мы завершаем Модуль 4. В следующем модуле мы перейдем к одной из самых захватывающих тем – Сетевой Ткани (WireGuard, SSH, VPN) через призму агентского управления.

Глава 4: Hello World в Терминале: Первый запуск и быстрые победы

Забудьте о классическом принте "Hello World". Для агентской CLI настоящий "привет мир" – это автономное исследование системы и решение первой реальной задачи. В этой главе мы проведем ваш первый сеанс связи.

4.1. Первый запуск: Интроспекция

После установки введите простую команду:

gemini "Кто ты и что ты видишь в этой системе?"

Что произойдет под капотом?

1. Агент проанализирует переменные окружения.

2. Запустит `whoami`, `hostname` и, возможно, `ls`.

3. Ответит: "Я – агент Gemini. Я нахожусь на узле `vPSrasil`, у меня есть доступ к Docker и файлам в `/home/noc`. Я вижу 3 активных проекта…"

4.2. Задача №1: Инвентаризация Docker

Допустим, вы забыли, какие контейнеры запущены на удаленном узле 1.3.

Запрос: "Зайди на 1.3 и перечисли все Docker-контейнеры, которые потребляют больше 200Мб памяти."

Лог действий агента:

`run_command("ssh 1.3 'docker stats –no-stream –format \"{{.Name}}\t{{.MemUsage}}\"'")`

Анализ вывода (например, `gitlab-ee 2.4GB`, `nginx 15MB`).

Ответ: "На узле 1.3 только контейнер `gitlab-ee` превышает лимит…"

4.3. Задача №2: Поиск "иголки в стоге сена"

Попробуем найти ошибку в логах Nginx, которая случилась 10 минут назад.

Запрос: "Найди в логах /var/log/nginx/error.log все упоминания 'upstream timed out' за последние 15 минут и скажи, какой IP был источником."

Инструменты, которые использует агент:

`run_command("date -d '15 minutes ago' +'%Y/%m/%d %H:%M:%S'")`

`grep_search` или `awk` для фильтрации лога по времени.

Извлечение IP из строки лога.

4.4. Интерактивный режим vs One-off команды

Gemini CLI поддерживает два режима:

1. CLI Mode (`gemini "task"`): Запустил, получил результат, вышел. Идеально для скриптов Bash.

2. REPL Mode (`gemini`): Живой диалог. Контекст сохраняется между командами. Вы можете сказать "А теперь перезапусти этот сервис", и агент поймет, о каком сервисе шла речь ранее.

4.5. Золотое правило первой сессии

Никогда не доверяйте агенту на 100% в первый день. Используйте флаг `–dry-run` или просто внимательно читайте "Thought" блок. Если агент хочет выполнить `rm -rf`, а вы просили "почистить логи", остановите его.

> [!TIP]

> Начните с команд "Read-only". Попросите агента объяснить структуру вашего проекта или проанализировать `docker-compose.yml`.

––

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

Агентский Hello World – это **действие**, а не текст.

**SSH + Docker + Grep*– святая троица первого запуска.

Используйте **REPL*для сложных многошаговых задач.

Секция 5.1: SSH-туннели как артерии агента: Магия невидимых связей

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

5.1.1. SSH как RPC для Агентов

В классическом администрировании SSH используется интерактивно. Для агента SSH – это механизм удаленного вызова процедур (Remote Procedure Call).

Типичный сценарий:

Вы просите агента: "Проверь статус БД на сервере 1.3".

Агент не просто заходит туда. Он выполняет цепочку:

`Local -> Jump Host (1.1) -> Target (1.3)`.

5.1.2. Проксирование и Jump Hosts (ProxyJump)

Когда ваша сеть сегментирована, агент должен знать, как проходить через "шлюзы".

Использование директивы `ProxyJump` в `~/.ssh/config` – лучший способ сделать это для агента.

Пример конфигурации для ИИ-агента:

Host backend-node

HostName 10.252.1.3

ProxyJump gateway-node

User noc

IdentityFile ~/.ssh/id_ed25519_agent

Благодаря этой записи, агент в промпте может просто написать: `ssh backend-node "uptime"`. Ему не нужно знать всю топологию сети, SSH-клиент сделает это за него. Это экономит контекстное окно модели!

5.1.3. SSH-туннелирование (Port Forwarding)

Иногда агенту нужно получить доступ к сервису, который доступен только локально на удаленном узле (например, административный порт Redis).

**Local Forwarding:*`ssh -L 6379:localhost:6379 backend-node`. Агент "прокидывает" порт себе и может работать с Redis так, будто он запущен локально.

**Использование агентом:*Агент сам понимает, когда нужно поднять туннель: "Сервис доступен только на 127.0.0.1 удаленного узла. Я создам временный SSH-туннель для анализа".

5.1.4. Key-based Auth и SSH Agent

Автономному агенту нельзя вводить пароли. Использование SSH-ключей (ED25519) – единственный путь.

Важно: Чтобы агент мог переходить с одного сервера на другой без копирования приватных ключей везде, используйте `ForwardAgent yes`. Это позволяет агенту использовать свои локальные ключи на любом удаленном сервере.

5.1.5. Решение проблемы "Зависших соединений"

SSH-сессии могут "подвисать". Агент может ждать вывода вечно.

Настройки для надежности:

ServerAliveInterval 60

ServerAliveCountMax 3

Эти опции заставляют SSH-клиент завершаться, если сервер перестал отвечать, что позволяет агенту получить ошибку и перепланировать свои действия (например, попробовать другой маршрут).

5.1.6. SCP и SFTP: Руки Агента для файлов

Передаче файлов между узлами агент отдает приоритет `scp` или `rsync`. Для него это атомарная операция.

> "Я вижу, что патч готов на Gateway. Я перенесу его на Backend через scp и применю там".

––

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

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

Секция 5.2: WireGuard для агентов: Создание безопасной сети

В то время как SSH идеален для точечных "уколов", для полноценной жизни агенту нужна целостная сетевая среда. WireGuard – это современный протокол VPN, который работает быстрее всех конкурентов и имеет минимальную поверхность атаки. В этой секции мы научим агента Gemini CLI управлять меш-сетью.

5.2.1. Почему WireGuard – это "VPN для роботов"?

В отличие от OpenVPN c его сложным процессом рукопожатия и медленным переключением, WireGuard работает по принципу Peer-to-Peer. Он не держит постоянного соединения, когда нет трафика.

**Для агента это означает:*Минимальные задержки (Latency). Агент получает ответ от удаленного узла так же быстро, как от соседа по стойке.

**Безопасность:*Если агент видит, что VPN-интерфейс `wg0` упал, он блокирует все свои сетевые попытки до восстановления связи.

5.2.2. Архитектура "Плоской Сети" (Flat Mesh Network)

Главная проблема администрирования – сложная адресация. Агенту сложно помнить, что сервер `A` доступен через `10.0.1.5`, а сервер `B` через `192.168.50.22`.

Решение через WireGuard: Все узлы объединяются в одну подсеть (например, `10.8.0.0/24`).

Агент теперь может обращаться к узлам по простым IP: `10.8.0.1`, `10.8.0.3` и т.д. Это упрощает его логику планирования почти в 10 раз.

5.2.3. Генерация конфигурации агентом

Агент может сам управлять расширением вашей сети.

> "Я вижу новый узел 1.5. Я сгенерирую для него пару ключей WireGuard, добавлю его публичный ключ в конфиг шлюза и пришлю вам команду для настройки узла".

Код, который может сгенерировать агент:

wg genkey | tee privatekey | wg pubkey > publickey

Агент понимает структуру `wg0.conf` и может безошибочно вносить в него изменения с помощью `sed` или `awk`.

5.2.4. Роутинг и IP-форвардинг

Если вы хотите, чтобы агент имел доступ к интернету через защищенный узел, он должен настроить форвардинг трафика.

**Задача агента:*"Настрой `wg0` так, чтобы весь трафик на `8.8.8.8` шел через туннель".

**Действие агента:*Проверка `/proc/sys/net/ipv4/ip_forward` и настройка таблиц роутинга.

5.2.5. Проблема "Roaming" (Бродячие агенты)

WireGuard позволяет агенту менять свои IP-адреса на лету (например, если вы переносите Gateway с одного провайдера на другой). Трафик не рвется. Агент просто продолжает выполнять свою задачу в фоне, даже если его внешний IP изменился 10 раз за сессию.

5.2.6. Мониторинг здоровья сети

Агент в фоне может периодически выполнять `wg show` и анализировать время синхронизации (Latest Handshake). Если он видит, что узел молчит более 3 минут, он может инициировать процедуру рестарта VPN или поднять тревогу.

––

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

WireGuard превращает разрозненные серверы в единый, защищенный "цифровой организм". Для Gemini CLI это означает упрощение навигации и гарантированную безопасность коммуникаций. В следующей секции мы разберем, как защитить этот организм от внешнего мира с помощью мощных фаерволов IPTables и NFTables.

Секция 5.3: Управление фаерволами (IPTables, NFTables): Огненный щит Агента

Безопасность сетевой ткани (которую мы построили в прошлых секциях) бесполезна, если её периметр не защищен фаерволом. В этой секции мы научим агента Gemini CLI работать с "низкоуровневой гвардией" ядра Linux – IPTables и современным NFTables.

5.3.1. Фаервол как Декларативная Политика

Для обычного человека правила фаервола – это запутанные цепочки команд. Для агента это набор логических условий.

Агент воспринимает задачу так: "Запрети всё по умолчанию (DROP), кроме порта 22 для моего IP и порта 51820 для WireGuard".

5.3.2. IPTables: Старая школа фильтрации

Несмотря на возраст, IPTables остается самым распространенным инструментом. Агент использует его для быстрых манипуляций.

Сценарий блокировки атаки:

Если агент видит в логах Nginx атаку типа "грубая сила" (Brute-force), он может мгновенно выполнить:

iptables -A INPUT -s [ATTACKER_IP] -j DROP

Это происходит на порядок быстрее, чем если бы это делал человек. Агент "чувствует" атаку через логи и реагирует на уровне ядра.

5.3.3. NFTables: Будущее сетевого управления

NFTables – это замена IPTables с более чистым синтаксисом и высокой производительностью.

Агент отдает предпочтение NFTables, если он доступен в системе, так как его конфиги более структурированы и легче поддаются автоматическому анализу.

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

`nft list ruleset` для агента – это JSON-подобная структура знаний, по которой он понимает, какие "дыры" открыты в вашей системе.

5.3.4. State Management (Conntrack)

Агент учитывает состояние соединений (Stateful Inspection). Он знает, что если он инициировал исходящий запрос к API Gemini, то ответ должен быть пропущен фаерволом автоматически.

**Правило агента:*"Разреши входящий трафик для уже установленных соединений (RELATED, ESTABLISHED)".

5.3.5. Опасности автоматического управления фаерволом

Главный риск – агент может заблокировать сам себя (и вас).

> "Я закрою порт 22, чтобы никто не ломался. Ой, я сам теперь не могу зайти по SSH".

Механизм защиты в Gemini CLI:

Перед применением правил фаервола агент обязан добавить правило "Безопасного окна" или использовать временное применение скрипта (например, через `cron`), который откатит правила назад через 60 секунд, если агент не подтвердит свою связность.

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).