44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
# Gemeinsamer Stack
|
|
|
|
`docker-compose.full.yml` ist auf deine beiden gelieferten Projekte zugeschnitten. Standardmäßig erwartet die Datei drei Geschwisterordner. Pfade und Ports lassen sich über Umgebungsvariablen überschreiben.
|
|
|
|
Vor dem Start:
|
|
|
|
1. beide optionalen Telemetrie-Patches anwenden, falls echte Suchanfragen live erscheinen sollen;
|
|
2. Agent-`.env` mit GLPI-Zugangsdaten bereitstellen;
|
|
3. Knowledge-, Staging- und Backup-Pfade prüfen;
|
|
4. Stack starten und Modelle laden.
|
|
|
|
```bash
|
|
docker compose -f deployment/docker-compose.full.yml up -d --build ollama
|
|
docker compose -f deployment/docker-compose.full.yml exec ollama ollama pull qwen3:8b
|
|
docker compose -f deployment/docker-compose.full.yml exec ollama ollama pull embeddinggemma
|
|
docker compose -f deployment/docker-compose.full.yml up -d --build
|
|
```
|
|
|
|
Ports: Agent `8080`, Editor `8081`, Suche `8082`, Brain `8090`.
|
|
|
|
|
|
## Staging-Isolation
|
|
|
|
Der Editor und das Brain teilen sich das echte Knowledgebase-Staging. `kb-search` erhält absichtlich nur ein leeres, flüchtiges Verzeichnis unter `/tmp/empty-staging`; der Agent mountet das Staging überhaupt nicht. AI-THINK-Drafts sind dadurch im Brain und im Prüf-Editor sichtbar, aber weder für Agent-Antworten noch für die produktive Knowledgebase-Suche verfügbar. Erst die bestehende Promotion im Editor kopiert einen freigegebenen Entwurf in die produktive Knowledge-Basis.
|
|
|
|
## Externer Ollama-Pool
|
|
|
|
Für mehrere Instanzen `OLLAMA_URLS`, `OLLAMA_NODE_NAMES` und optional `OLLAMA_NODE_WEIGHTS` in der Umgebung des Compose-Aufrufs setzen. Die lokale `ollama`-Service-Instanz ist keine harte Startabhängigkeit mehr; sie wird nur verwendet, wenn ihre URL im effektiven Pool steht.
|
|
|
|
```env
|
|
OLLAMA_URLS=http://gpu-01:11434,http://gpu-02:11434
|
|
OLLAMA_NODE_NAMES=gpu-01,gpu-02
|
|
OLLAMA_NODE_WEIGHTS=1,2
|
|
OLLAMA_ROUTING_MODE=least_inflight
|
|
```
|
|
|
|
## GLPI-KB für das Brain
|
|
|
|
`GLPI_KB_ENABLED=true` aktiviert einen zusätzlichen read-only Sync aus GLPI. Die gleichen GLPI-Zugangsdaten wie beim Agenten können verwendet werden, sofern der Service-Account Leserechte auf die Knowledgebase besitzt. Das Brain schreibt nicht nach GLPI zurück.
|
|
|
|
## Persistenz
|
|
|
|
`BRAIN_PERSIST_INTERVAL=5m` bündelt Graph-, Cache- und Staging-Schreibvorgänge. Bei einem geplanten Container-Stopp wird zusätzlich ein finaler Flush ausgeführt.
|