Zum Inhalt springen
MCP-Server eingebautWie das funktioniert

Architektur

Eine Installation besteht aus neun Diensten hinter einem einzigen Reverse-Proxy. Erreichbar ist nur dieser Proxy; alles andere bleibt im internen Netz.

Auf dieser Seite

Der Aufbau auf einen Blick

Datenfluss einer Abfrage
                       ┌──────────── nginx-Gateway (:8080) ────────────┐
 Browser  ───────────▶ │  /  → Konsole    /api/agent → Agent   /auth → KC │
                       └──────────────────────────────────────────────────┘
                                    │                 │
                             Konsole (React/Vite)     Agent (Fastify/TS)
                                                       │  delegiertes Token (RFC 8693)
                                                       ▼
   Keycloak (OIDC)   PostgreSQL + pgvector   Trino ── Iceberg ── Nessie   MinIO (S3)
   Identität         Plattformzustand,       SQL-Engine  Tabellen  Katalog  Objektspeicher
                     Vektoren
                                                       │
                                              Ollama (lokale Einbettungen, CPU)

Die Dienste im Einzelnen

DienstAufgabe
gatewaynginx. Die einzige erreichbare Tür. Verteilt nach Pfad: Konsole, Agent-API, Keycloak.
consoleDie Weboberfläche als React/Vite-SPA. Meldet sich per OIDC mit PKCE an.
agentDas Backend (Fastify/TypeScript): Werkzeuge, Gates, Ingestion, Einbettungen, Herkunft, Audit.
keycloakAnmeldung und Identität. Stellt die Token aus, die alle anderen Dienste prüfen.
trinoDie SQL-Engine. Führt jede Anweisung unter dem eingetauschten Token des Aufrufers aus.
nessieVersionierter Iceberg-Katalog – Verzweigungen und Zeitreisen wie in Git.
minioS3-kompatibler Objektspeicher. Buckets: warehouse für Tabellendaten, audit für das Protokoll.
postgresPlattformzustand und, über pgvector, der Einbettungsindex. Dazu die Datenbanken von Keycloak und Nessie.
ollamaDas lokale Einbettungsmodell (nomic-embed-text) über eine OpenAI-kompatible Schnittstelle. Ohne Cloud-Schlüssel.

Delegierte Identität

Der Agent hat kein eigenes Datenkonto. Kommt eine Anfrage herein, tauscht er das Token des Nutzers über den Standard-Token-Exchange von Keycloak (RFC 8693) gegen ein Token für das Publikum trino und stellt damit die Abfrage. Trinos eigene Rechte und die Zeilen- und Spaltenrichtlinien entscheiden, was zurückkommt.

Ein Aussteller, im Gleichschritt

Keycloak liegt unter /auth und legt damit den öffentlichen Aussteller fest. Jedes Token trägt genau diesen – auch das für Trino, während die Backchannel-Aufrufe intern bleiben.

Warum der Vektorindex nur ein Index ist

Einbettungen liegen in PostgreSQL, nicht die Nutzdaten. Eine Suche ermittelt dort nur, welche Zeilen passen könnten; deren Inhalt wird anschließend unter der Kennung des Suchenden aus Trino nachgeladen. Das kostet einen zweiten Weg, hält aber die Governance an einer Stelle – statt sie im Suchindex ein zweites Mal nachbauen zu müssen.

Betriebsformen

  • Docker Compose – alles auf einem Rechner, für Entwicklung und Vorführung.
  • Kubernetes über das Helm-Umbrella-Chart infra/helm/flaky-platform – der Weg für den Betrieb.

Der Katalog kommt mit

Eine Installation bringt ihren Iceberg-Katalog selbst mit (Nessie auf s3://warehouse/). Bestehende Kataloge daneben einzuhängen, geht heute noch nicht.

Stand: Diese Seite beschreibt lavalake 0.16.0. Produkt und Dokumentation liegen in getrennten Repositories – im Zweifel gilt, was die Konsole zeigt.

Etwas fehlt?

Wenn diese Seiten Ihre Frage nicht beantworten, zeigen wir die Plattform in einer halben Stunde an Ihrem Fall.

Demo vereinbaren