Глава 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 секунд, если агент не подтвердит свою связность.