EvoBGP/docs/manual.md

Полное руководство по EvoBGP

Этот документ объединяет эксплуатационное и разработческое описание системы: что делает каждый процесс, как двигаются данные, какие API использовать и где искать причины инцидентов.

1. Назначение системы

EvoBGP управляет генерацией и применением BGP-конфигураций на основе модулей источников префиксов (AS_PREFIXES, CDN_CIDRS, DOMAINS, IP_RANGES).

Система разделена на:

• control plane: API, БД, jobs, рендер ревизий, публикация и подписание бандлов;
• data plane: BIRD и связанный агент/нода для применения ревизий.

2. Компоненты и роли бинарников (cmd/*)

evobgp-api

• Основной HTTP API.
• Поднимает маршруты из internal/httpapi.
• Работает с store/repository, jobs и аутентификацией.

evobgp-all

• Монолитный режим: API + scheduler + ingest + render + deploy в одном процессе.
• Удобен для компактных окружений (microvps).

evobgp-scheduler

• Периодически запускает module_refresh по расписанию/интервалам.
• В reference-профиле может стучаться в API и/или работать через store.

evobgp-ingest

• Периодически делает prefetch внешних CDN-источников (ETag/доступность).

evobgp-render

• Ведёт рендер-цикл; в режиме autopublish может назначать последнюю ревизию на спикеры.

evobgp-deploy

• Диагностирует drift: различия между опубликованной и применённой ревизией.

evobgp-node

• CLI-нода для edge: загрузка бандла, верификация подписи, применение.

evobgp-agent

• Локальный агент рядом с BIRD (наблюдение и служебные операции).

3. Карта внутренних модулей (internal/*)

API и доступ

• internal/httpapi: маршруты, auth, CORS, problem+json, CRUD, jobs endpoints.

Данные

• internal/store: бизнес-контракты бэкенда.
• internal/repository: PostgreSQL-реализация.
• internal/db: коннект и миграции.

Jobs/pipeline

• internal/jobs: очередь задач и worker.
• internal/pipeline: module_refresh, сбор источников, материализация, рендер-превью.
• internal/scheduler, internal/ingest, internal/render, internal/deploy: фоновые циклы.

BIRD и бандлы

• internal/birdfmt: генерация конфигурации BIRD.
• internal/birddeploy: применение конфигурации и интеграция с birdc.
• internal/bundle, internal/signing: упаковка и криптографическая проверка.

Наблюдаемость и служебные

• internal/observability: метрики/middleware.
• internal/asnresolve: внешние резолвы ASN.
• internal/broker: задел под внешний брокер.
• internal/config, internal/platform: параметры среды и платформенные адаптеры.

4. Сквозной поток данных

1. Оператор меняет данные модуля (CRUD источников, peers/speakers, настройки).
2. Включённый модуль триггерит module_refresh.
3. jobs.Worker вызывает pipeline.RefreshModule.
4. Pipeline собирает префиксы всех enabled-модулей tenant, строит materialized snapshot.
5. Создаётся ревизия и BIRD preview.
6. По операциям deploy/apply ревизия применяется на спикере.
7. Нода получает бандл, проверяет подпись, применяет локально.

5. API: ключевые группы и сценарии

Источник истины контракта: docs/openapi.yaml.

Основные группы endpoint-ов

• Modules: модули и их общие параметры.
• AS Entries, CDN Sources, Domain Entries, IP Range Entries: источники префиксов.
• Peers, Speakers: сетевая топология применения.
• Revisions, Deploy, Jobs: жизненный цикл ревизий и фоновых задач.
• Settings: глобальные KV-настройки.
• Node: edge-флоу бандлов/enrollment.

Типовой сценарий оператора

1. Создать/обновить модуль и его источники.
2. Дождаться или инициировать refresh.
3. Проверить ревизию и diff.
4. Выполнить apply на целевой спикер.
5. Проверить health/monitoring/jobs.

6. Настройки и доступ

Аутентификация/роли

• Роли и правила доступа: docs/access.md.
• Для мутаций критичных сущностей требуется editor/operator.

Настройки (/v1/settings)

• KV c ключами BIRD и дополнительными feature flags.
• Ключевые параметры BIRD: bird_router_id, bird_local_ipv4, bird_local_ipv6, bird_local_asn, bird_bgp_source_ipv4, bird_bgp_source_ipv6.
• Tenant settings — глобальный default. Per-speaker override: meta_json.bird_bgp_source_ipv4 / node_ipv4 в карточке спикера (Web UI → Сеть → Спикеры); pipeline накладывает overlay при сборке бандла для реплики. См. remote-speakers.md.

7. Эксплуатация и runbook

Что проверять при инцидентах

1. Статус API и БД.
2. Состояние jobs (module_refresh, deploy_apply), ошибки в job meta.
3. Состояние внешних источников (CDN/DoH/ASN).
4. Состояние BIRD и применённой ревизии на спикере.

Частые причины проблем

• Невалидные данные источников (непарсящийся JSON/plaintext для CDN).
• Неполные настройки BIRD.
• Ошибки внешних upstream (RIPEstat/DoH/CDN).
• Расхождение published/applied ревизии.

8. Разработка и расширение

Где вносить изменения

• Новый endpoint: internal/httpapi + обновление docs/openapi.yaml.
• Новая логика источника: internal/pipeline + соответствующие CRUD/store/repository.
• Новая операция UI: web/src/routes/* и web/src/lib/components/*.

Рекомендации по качеству

• Для изменений API всегда обновлять docs/openapi.yaml.
• Для изменений UI держаться единого набора компонентов shadcn-svelte и Lucide.
• Для pipeline-изменений добавлять метрики стадии и явные trigger-метки job.

9. Индекс исходников (быстрый вход)

• Архитектура: docs/architecture.md
• API обзор: docs/api.md
• Контракт API: docs/openapi.yaml
• Доступ/роли: docs/access.md
• Web запуск: web/README.md
• Compose: deploy/compose/docker-compose.yaml
• Runtime log-файлы (sidecar + API): EVOBGP_RUNTIME_LOGS_HOST_DIR на хосте, mount в evobgp-all → /opt/evobgp/runtime-logs; см. access.md и quickstart.md