Self-hosting der Omnidocs Platform (Generic)

INHALTSVERZEICHNIS

• Überblick
• Services
• Speicherabhängigkeiten
• Zugriff auf Container-Images

Überblick

Die Omnidocs-Umgebung besteht aus mehreren zentralen Services, die zusammenarbeiten, um die Gesamtfunktionalität zu unterstützen:

• Kernservices
• Create API, Internal API und Backup API
• Transformation Service
• JMES Engine
• Templating Services
• Docx, Pptx, Xlsx, Html
• PDF Output Service
• PDF Conversion Engine

Für die Speicherung verwendet die Umgebung sowohl Objekt-/Blob-Speicher als auch eine MongoDB-basierte Datenbank.

Es wird außerdem empfohlen, die Netzwerkgrenze sowohl mit einem Ingress Gateway als auch mit einem Egress Gateway abzusichern. Dies hilft, das System vor externen Bedrohungen zu schützen, und vereinfacht die Konfiguration bei der Interaktion mit externen Services (z. B. beim Hinzufügen von Firewall-Ausnahmen für MongoDB Atlas).

Self-hosting_Omnidocs_Platform_(Generic)-create-arch

Beispielsweise kann das Setup bei einer Bereitstellung auf Azure Folgendes umfassen:

• Application Gateway: Fungiert als eingehender Reverse-Proxy mit Web Application Firewall-Schutz.
• NAT Gateway: Verwaltet die ausgehende Kommunikation über Network Address Translation.

Services

Kernservices

Create API

Die Create API ist der zentrale Einstiegspunkt und Orchestrator für die Umgebung. Sie dient sowohl als Workflow-Orchestrator, der andere Services koordiniert, um verschiedene Funktionen auszuführen (z. B. das Generieren eines Dokuments), als auch als einziger Ingress für das System, der die vollständige API-Oberfläche und WebAssembly-Clients bereitstellt.

• Eingehende Kommunikation: Der einzige Service, der extern für eingehende Anfragen verfügbar gemacht wird.
• Serviceabhängigkeiten: Erfordert Erreichbarkeit zu allen anderen Services und Abhängigkeiten (mit Ausnahme der Backup API). Diese Endpunkte werden über Umgebungsvariablen konfiguriert.
• Ressourcenzuweisung: Durch die Auslagerung rechenintensiver Aufgaben an WebAssembly- und Templating-Engines benötigt der Service nur moderate Ressourcen, um typische Anfragelasten zu bewältigen.

Internal API

Die Internal API unterstützt die Create API bei bestimmten Workflows, beispielsweise beim Generieren von Dokumenten und bei der Interaktion mit Externe Datenquellen. Sie benötigt keinen externen eingehenden Zugriff, sondern nur ausgehende Kommunikation.

• Serviceabhängigkeiten: Erfordert eine ähnliche Auffindbarkeit wie die Create API.
• Ressourcenzuweisung: Vergleichbar mit der Create API, jedoch mit insgesamt geringerem Bedarf.

Backup API

Die Backup API ist für die Ausführung von Sicherungs- und Wiederherstellungsvorgängen auf den Speicherkomponenten verantwortlich.

• API-Exposition: Dieser Service stellt keinen API-Endpunkt bereit und benötigt keine Auffindbarkeit anderer Services, abgesehen von den Speicherkomponenten.
• Ressourcenzuweisung: Leichtgewichtig mit minimalem CPU- und Speicherbedarf.

Transformation Service

JMES Engine

Die JMES Engine verarbeitet Transformationen während der Anfangsphase eines Workflows unter Verwendung einer erweiterten Version von JMESPath.

• Serviceabhängigkeiten: Keine Serviceauffindbarkeit erforderlich.
• Ressourcenzuweisung: Geringe CPU-Auslastung, jedoch hoher Speicherbedarf, wobei mindestens 3GB RAM und 1 CPU empfohlen werden.

Templating Services

Die Templating-Engines werden in der nächsten Phase des Workflows verwendet. Abhängig vom Typ des zu generierenden Dokuments wird entweder die Docx-Engine für Word-Dokumente, die Pptx-Engine für PowerPoint-Präsentationen, die Xlsx-Engine für Excel-Tabellen oder die Html-Engine für HTML-Dokumente verwendet.

• Serviceabhängigkeiten: Keine Serviceauffindbarkeit erforderlich.
• Ressourcenzuweisung: Diese Services sind im Allgemeinen leichtgewichtig. Office-Engines benötigen jeweils bis zu 1GB Speicher, während die HTML-Engine nur minimalen Speicherbedarf hat.

PDF Output Service

PDF Engine

Die PDF Engine ist für die Konvertierung von Office- und HTML-Dokumenten in PDF als letzten Schritt eines Workflows verantwortlich.

• Serviceabhängigkeiten: Keine Serviceauffindbarkeit erforderlich.
• Ressourcenzuweisung: CPU-intensive Verarbeitung, die von der Zuweisung ganzer CPU-Einheiten (z. B. 1 CPU, 2 CPUs) für optimale Leistung profitiert. Dies gewährleistet eine effiziente Ressourcennutzung, da fraktionierte CPU-Zuweisungen möglicherweise keine ausreichende Leistung bieten. Die Speicheranforderungen variieren je nach Dokumentkomplexität.
• Empfehlungen: Weisen Sie pro Instanz 1 CPU und mindestens 2GB Speicher zu. Dieser Service skaliert horizontal effizienter als vertikal.
• Skalierungshinweise: Wenn horizontale Skalierung eingeschränkt ist, sollten Sie zunächst den Speicher erhöhen, bevor Sie zusätzliche CPUs hinzufügen (bis zu 2 CPUs). Eine Skalierung über diese Anzahl hinaus führt zu abnehmendem Nutzen.

Speicherabhängigkeiten

Objektspeicher

Die Umgebung unterstützt mehrere Objektspeicheroptionen:

• Azure Storage: Geeignet für Bereitstellungen in Azure-Umgebungen.
• S3-Compatible Storage: Nützlich für Nicht-Azure- oder Drittanbieterumgebungen (z. B. Ceph oder MinIO).
• MongoDB GridFS: Eine Fallback-Lösung, die verwendet wird, wenn kein anderer Objektspeicher verfügbar ist.

Datenbankspeicher

Das System basiert auf einer MongoDB-kompatiblen Datenbank für die strukturierte Datenspeicherung. Unterstützte Optionen umfassen:

• MongoDB Atlas: Ein cloudbasierter Managed Service.
• Azure CosmosDB for MongoDB: Ein verwalteter Datenbankservice mit Kompatibilität zu MongoDB.
• Self-Managed MongoDB Instance: Ein manuell verwaltetes Setup.

Zugriff auf Container-Images

Um auf die für die Omnidocs-Umgebung erforderlichen Container-Images zuzugreifen, wenden Sie sich bitte an Ihren zuständigen technischen Ansprechpartner bei Omnidocs. Dieser unterstützt Sie bei der Bereitstellung eines Authentifizierungstokens für unsere Azure Container Registry, damit Sie die erforderlichen Images für die verschiedenen in dieser Dokumentation beschriebenen Services abrufen können.