Zum Hauptinhalt springen

On-Premises Infrastruktur und Hardware-Anforderungen

Dieses Kapitel beschreibt die technischen Voraussetzungen und architektonischen Annahmen für den On-Premises-Betrieb von Bubble Chat. Ziel ist es, Kunden eine klare Grundlage für Planung, Betrieb und Skalierung der Lösung in der eigenen Infrastruktur bereitzustellen.

Bubble Chat ist vollständig containerisiert und wird als Docker-Image ausgeliefert. Externe AI-Services (z. B. Large Language Models und Vektorsuche) werden nicht on-premises betrieben, sondern über gesicherte Netzwerkverbindungen konsumiert.

Scope und Abgrenzung​

Bestandteil der On-Premises-Installation

  • Bubble Chat Applikation (Docker Container)
  • MongoDB (Containerisiert oder als dedizierte VM)
  • Persistente Storage-Volumes
  • Optional: Reverse Proxy (z. B. Traefik, NGINX)
  • Optional: Load Balancer und Monitoring

Nicht Bestandteil der On-Premises-Installation

  • Large Language Models (LLM)
  • Vektor-Datenbanken / AI Search
  • Embedding-Services

Diese Komponenten werden über gesicherte HTTPS-Verbindungen als externe Services angebunden.

Hardware-Anforderungen​

Die folgenden Anforderungen basieren auf realen Betriebsdaten mit geringer bis mittlerer Nutzung und sind bewusst konservativ ausgelegt.

Minimal (PoC / kleiner Betrieb)​

Geeignet für Proof-of-Concepts, Tests oder sehr geringe Nutzung.

  • CPU: 2 vCPU
  • RAM: 4 GB
  • Storage: 100 GB SSD oder NVMe
  • Netzwerk: 1 Gbit/s
  • Betriebssystem: Linux (z. B. Ubuntu LTS)
  • Container Runtime: Docker

App und MongoDB dürfen auf derselben VM betrieben werden.

Empfohlen (Produktion, Single Node)​

Geeignet für kleine bis mittlere produktive Installationen ohne Hochverfügbarkeitsanforderungen.

  • CPU: 4 vCPU
  • RAM: 8 GB
  • Storage: 200 GB SSD oder NVMe
  • Netzwerk: 1 Gbit/s

Optional wird empfohlen, Applikation und MongoDB logisch oder physisch zu trennen.

Produktion mit Hochverfügbarkeit (HA)​

Empfohlen für geschäftskritische Anwendungen.

Applikations-Layer

  • 2 Nodes
    • je 3 vCPU
    • je 8 GB RAM
    • je 200 GB SSD

Datenbank-Layer (MongoDB Replica Set)

  • 3 Nodes
    • je 2 vCPU
    • je 16 GB RAM
    • je 500 GB – 1 TB NVMe/SSD

Ein Load Balancer oder Reverse Proxy verteilt den Traffic auf die Applikations-Nodes.

Zusammenfassung​

BetriebsartCPURAMStorage
Minimal (PoC)2 vCPU4 GB100 GB SSD
Produktion (Single Node)4 vCPU8 GB200 GB SSD
Produktion (HA)12 vCPU64 GB2 TB SSD

Container-Image und Bereitstellung​

Bubble Chat wird als versioniertes Docker-Image bereitgestellt.

Das Docker-Image wird durch Apptiva in einer gesicherten Container Registry bereitgestellt. Kunden erhalten lesenden Zugriff, um das Image in ihre On-Premises-Umgebung zu deployen.

Alternativ kann das Docker-Image nach Absprache:

  • in eine kundeneigene Container Registry repliziert oder
  • als signiertes Image zur Verfügung gestellt werden.

Technische Details

  • Image-Format: OCI-kompatibles Docker-Image
  • Zugriff: Authentifiziert (Read-only)
  • Versionierung: Semantische Versionierung (z. B. vX.Y.Z)
  • Updates: Durch den Kunden steuerbar (Rolling Update oder manuell)

Netzwerk-Anforderungen​

Outbound (zwingend erforderlich)

  • HTTPS (TCP 443) zu externen AI-Services
  • Funktionierende DNS-Auflösung

Inbound (typisch)

  • HTTPS (443) fuer Benutzerzugriffe
  • Optional HTTP (80) fuer Weiterleitungen

Sicherheit

  • TLS-Termination im Reverse Proxy oder Applikations-Container
  • Firewall-Allowlisting fuer externe Services empfohlen
  • Keine eingehenden Verbindungen von externen AI-Services erforderlich

Betrieb und Verantwortlichkeiten​

Verantwortlichkeiten Kunde

  • Betrieb der Infrastruktur (VMs, Netzwerk, Storage)
  • Betrieb von Docker bzw. Container-Plattform
  • Backups und Wiederherstellung
  • Monitoring der Systemressourcen

Verantwortlichkeiten Apptiva

  • Bereitstellung und Pflege des Docker-Images
  • Applikations-Updates
  • Technische Dokumentation und Betriebsempfehlungen

Sicherheit und Datenschutz​

Ein Teil der durch Bubble Chat verarbeiteten Daten wird zur Verarbeitung an externe AI-Services übermittelt.

Datenverarbeitung​

  • Persistente Betriebs- und Konversationsdaten werden innerhalb der On-Premises-Infrastruktur des Kunden gespeichert (MongoDB).
  • Zur Beantwortung von Anfragen werden relevante Inhalte (z. B. Suchanfragen, Konversationsteile oder Dokumentenausschnitte) über gesicherte HTTPS-Verbindungen an externe AI-Services übermittelt.
  • Diese externen Services umfassen insbesondere:
    • AI Search (Suchindex)
    • Large Language Models (LLM)

Datenhaltung bei externen Services​

  • Die externe Verarbeitung erfolgt ausschliesslich zweckgebunden zur Anfragebearbeitung.
  • Es findet keine dauerhafte Speicherung von Konversationsdaten in der On-Premises-Umgebung durch externe Services statt, ausserhalb der dafür vorgesehenen Suchindizes.
  • Die Datenverarbeitung unterliegt den Datenschutz- und Compliance-Vorgaben der jeweiligen Service-Anbieter.

Sicherheit​

  • Die Kommunikation mit externen AI-Services erfolgt ausschliesslich verschlüsselt (HTTPS/TLS).
  • Es bestehen keine eingehenden Verbindungen von externen AI-Services in die Kundeninfrastruktur.
  • Secrets und Zugangsdaten werden nicht im Code gespeichert, sondern über sichere Konfigurationsmechanismen eingebunden.

Backup, Restore und Monitoring​

Backup

  • Regelmässige Sicherung der MongoDB-Daten
  • Mindestens tägliche Backups empfohlen
  • Regelmässige Restore-Tests empfohlen

Monitoring

  • CPU-, RAM- und Storage-Auslastung
  • MongoDB-Verbindungen und Speicherverbrauch
  • Container-Health-Checks

Skalierung und Wachstum​

  • Horizontale Skalierung: Hinzufügen weiterer Applikations-Container
  • Vertikale Skalierung: Erhöhung von RAM und Storage für MongoDB
  • MongoDB-Sharding ist bei typischen Nutzungsmustern in der Regel nicht erforderlich

Updates und Wartung​

  • Neue Versionen werden als Docker-Image bereitgestellt
  • Updates erfolgen kontrolliert durch den Kunden
  • Rollback auf frühere Versionen ist jederzeit möglich
  • Wartungsfenster liegen in der Verantwortung des Kunden