pacod-demo

Попробовать

Демо работает на demo.pacod.io. Его стартовая страница показывает каждый продукт с описанием, скриншотом и ссылками на его администрирование и сайты. У каждого продукта свой поддомен:

Один вход действует для всех продуктов: войдя в один, вы входите во все.

Зачем он нужен

Каждый проект pacod работает и сам по себе, со своими копиями всего, что ему нужно: базы данных, входной точки, входа, шлюза. Так удобно попробовать один из них. Но вместе они задуманы не так, и так не видно, что они дают в сумме.

pacod-demo устроен наоборот. Он ставит пять продуктов на одну машину, как одну платформу, с одним экземпляром каждого общего компонента, и показывает то, что появляется только при совместной работе: один вход, который признаёт каждый продукт, один шлюз, через который идёт каждый вызов модели и который тарифицирует их все, и один набор дашбордов для всего стека.

Как он устроен

• Одна сеть, уникальные имена. Все пять репозиториев следуют одному соглашению: каждый контейнер подключается к внешней Docker-сети pacod-net под именем, уникальным среди всех репозиториев. Общие компоненты называются pacod-*; всё остальное носит префикс владельца (gw-, ap-, cms-, kb-).
• Собственные compose-файлы репозиториев. Каждый репозиторий делит свою compose-конфигурацию на файл приложения, со своими сервисами, и автономный файл, со своими копиями общих компонентов для самостоятельного запуска. Демо подключает пять файлов приложений без изменений. Небольшой overlay на каждый репозиторий только убирает опубликованные порты, направляет настройки на файлы демо и задаёт публичные адреса.
• По одному каждого общего компонента. Один Caddy, один PostgreSQL с базой данных и ролью владельца для каждого продукта, один Qdrant, один сервис embeddings, один pacod-id, один шлюз, один приёмник почты и один стек мониторинга (Prometheus, Alertmanager, Grafana, коллектор OpenTelemetry). Каждый опирается на определение, которое уже поставляет один из репозиториев, и берёт вклад продуктов из их каталогов platform/: блоки сайтов Caddy, скрипты баз данных, задания Prometheus, правила и дашборды.
• Хранилища продуктов остаются при них. ClickHouse шлюза, MongoDB CMS (по базе данных на сайт) и Gotenberg, Redis и pgbouncer платформы агентов.
• Bootstrap управляет собственными скриптами продуктов: bootstrap шлюза и идентификации из pacod-ap и provisioner из pacod-cms. Он создаёт ключи шлюза и сервисные токены, с которыми продукты обращаются друг к другу.

Конфигурация

Два файла. demo.env — это конфигурация, она хранится в git: домен и порты, сертификат, email первого администратора, модели каждого продукта, бэкенд embeddings и необязательные компоненты. demo.local.env хранит секреты машины, пароль администратора и ключи LLM-провайдеров; git его игнорирует, и то, что в нём задано, имеет приоритет.

# demo.local.env
DEMO_ADMIN_PASSWORD=a-long-passphrase
ANTHROPIC_API_KEY=sk-...

LLM-провайдеры. Без ключа каждый вызов модели уходит к mock-провайдеру шлюза: демо работает офлайн и make verify детерминирован, но ответы в чате заготовлены. Добавьте ключ и запустите make bootstrap — шлюз будет настроен с настоящим провайдером.

Бэкенд embeddings фиксируется при первом make up, потому что от него зависят сохранённые векторы. По умолчанию, auto, используется настоящая модель BGE-M3, если у Docker хватает памяти, а иначе — лёгкая замена.

Необязательный компонент ingestion запускает приём документов платформы агентов и загружает базу знаний стартового агента. Это большой образ, ему нужно 16 GB памяти для Docker.

На домене или на ноутбуке

С сертификатом для домена и его поддоменов стек отвечает по HTTPS, а обычный HTTP только перенаправляет. При публикации за пределами машины демо закрывает то, что безопасно только на ноутбуке: просмотр почты, Prometheus и Grafana запрашивают email и пароль администратора, стартовая страница не называет администратора, а токены разработки платформы агентов отключены.

Для демо только на одной машине задайте DEMO_DOMAIN=localhost и DEMO_HTTP_PORT=8800 и оставьте сертификат пустым. Тогда всё работает по обычному HTTP на http://<name>.localhost:8800, и браузеры находят эти адреса без DNS.

Что ему нужно

• Docker с Compose 2.24 или новее, и make. Всё остальное, от генерации секретов до проверок, работает в контейнерах.
• Пять репозиториев проектов, склонированных рядом с этим.
• Около 8 GB памяти для Docker. Весь стек с настоящей моделью embeddings использует около 5 GiB, с лёгкой заменой — около 4 GiB.
• Около 30 GiB диска под образы. Первый make up собирает каждый образ из исходников, два Rust-workspace, сборку Maven, несколько Python-образов и два приложения на SvelteKit, и занимает от 30 до 60 минут. Последующие запуски занимают около двух минут.

make down останавливает стек и сохраняет данные; make clean удаляет всё, что создало демо. В README есть все настройки и таблица решения проблем.