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: домейнът и портовете, сертификатът, имейлът на първия администратор, моделите на всеки продукт, бекендът за 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 искат имейла и паролата на администратора, началната страница не назовава администратора, а токените за разработка на платформата за агенти са изключени.

За демо само на една машина задайте 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 работни пространства, Maven компилация, няколко Python образа и две SvelteKit приложения, и отнема от 30 до 60 минути. Следващите стартирания отнемат около две минути.

make down спира стека и запазва данните; make clean премахва всичко, което демото е създало. README съдържа всички настройки и таблица за отстраняване на проблеми.