Deployment von ADONIS mit Kubernetes

Diese Anleitung führt Sie durch das Deployment von ADONIS in einer Kubernetes-Umgebung mit Helm-Charts.

Hinweis

Vor dem Deployment stellen Sie bitte sicher, dass alle Hardware-/Softwareanforderungen erfüllt sind.

Ablauf des Deployments

Der Deployment-Prozess besteht aus den folgenden Schritten:

1. Bereiten Sie Ihre Umgebung vor - Stellen Sie sicher, dass alle erforderlichen Werkzeuge und Anmeldedaten vorhanden sind.

2. Erstellen Sie eine Datenbank - Richten Sie die Datenbank ein, die ADONIS zum Speichern Ihrer Daten verwendet.

3. Konfigurieren Sie das Deployment - Bereiten Sie die Registry-Authentifizierung und eine Datei mit Variablen für Helm mit Ihren spezifischen Einstellungen vor.

4. Stellen Sie ADONIS bereit - Stellen Sie ADONIS auf Ihrem Kubernetes-Cluster bereit.

5. Verwalten Sie Ihr Deployment - Greifen Sie auf Protokolle zu, überwachen Sie Ihre Anwendung und führen Sie häufige Aufgaben durch.

Wichtige Informationen zu diesem Deployment

Diese Anleitung beschreibt eine minimale Konfiguration, die für Entwicklung, Tests und Evaluierung geeignet ist. Die bereitgestellte Konfiguration ist funktionsfähig, muss aber je nach Ihrer Cluster-Konfiguration und Ihrer verwendeten Werkzeuge für den Produktivbetrieb angepasst werden. Dies ist besonders wichtig für die folgenden Punkte, bei denen unser Beispiel im Vergleich zu Best Practices stark vereinfacht ist:

• Speicher für Daten: Wir verwenden persistenten Speicherplatz für Daten rein mit Kubernetes-Mitteln; Produktiv-Deployments erfordern typischerweise robustere Speicherlösungen.

• Zugriff auf die Software: Wir verwenden eine Port-Weiterleitung für den Zugriff; Produktiv-Deployments verwenden Ingress-Controller oder ähnliche Mittel, um Benutzern Zugriff auf die Software zu geben.

• Netzwerk: Wir geben keine spezifischen Netzwerkeinstellungen vor; Produktiv-Deployments erfordern sorgfältige Konfiguration der Netzwerkrichtlinien, um die Sicherheit zu gewährleisten.

Für den Produktivbetrieb konsultieren Sie Ihren Kubernetes-Administrator und die offiziellen Dokumentationen von Kubernetes, Helm und Ihrer Infrastruktur-Plattform.

Hinweis

Diese Deployment-Anleitung setzt voraus, dass Sie Folgendes bereits haben:

• Einen bereits eingerichteten und zugänglichen Kubernetes-Cluster

• kubectl, helm und docker Befehlszeilenwerkzeuge auf Ihrem Administrationsrechner installiert

• Netzwerkzugriff von Ihrem Administrationsrechner auf den Kubernetes-Cluster, Ihren Datenbankserver und die BOC OCI-Registry.

• Geeignete Anmeldedaten für die BOC OCI-Registry und den Datenbankserver

Vorbereitung und Voraussetzungen

Bereiten Sie Ihre Umgebung für das Deployment von ADONIS auf Kubernetes vor, indem Sie die Voraussetzungen überprüfen.

Bevor Sie mit dem Deployment von ADONIS beginnen, müssen Sie überprüfen, ob Ihre Umgebung alle Anforderungen erfüllt und dass alle erforderlichen Werkzeuge, Dateien und Anmeldedaten vorhanden sind.

Erforderliche Werkzeuge und Zugriff

Sie benötigen die folgenden Werkzeuge auf Ihrem Administrationsrechner installiert:

• Kubernetes (kubectl): Befehlszeilenwerkzeug zur Interaktion mit Ihrem Kubernetes-Cluster.

• Helm: Paketmanager für Kubernetes, wird verwendet, um ADONIS bereitzustellen.

• Docker: Container-Runtime, wird für einige einmalige Operationen benötigt, wie das Erstellen einer Datenbank.

Überprüfen Sie Ihre Werkzeuge

Überprüfen Sie, ob alle Werkzeuge installiert sind und korrekt funktionieren:

docker version
kubectl version --client
helm version

Jeder Befehl sollte Versionsinformationen zurückgeben. Wenn ein Werkzeug fehlt, installieren Sie es nach der offiziellen Dokumentation für Ihre Plattform.

Zugriff auf Ihren Kubernetes-Cluster

Überprüfen Sie, dass Sie auf Ihren Kubernetes-Cluster zugreifen können:

kubectl cluster-info

Dieser Befehl sollte Informationen über Ihren Cluster anzeigen. Wenn er fehlschlägt, stellen Sie sicher, dass Ihre kubeconfig-Datei ordnungsgemäß konfiguriert ist und dass Sie Netzwerkzugriff auf den Cluster haben.

Datenbankserver

Für das Deployment von ADONIS muss ein Datenbankserver vorhanden und von Ihrem Kubernetes-Cluster aus zugänglich sein:

• Datenbanktyp: Eine unterstützte Version von PostgreSQL oder MS SQL Server gemäß der Hardware-/Softwareanforderungen

• Netzwerkzugriff: Ihr Kubernetes-Cluster muss Netzwerkzugriff auf den Datenbankserver haben

• Administrator-Anmeldedaten: Sie benötigen Benutzernamen und Passwort für ein Datenbank-Administrator-Konto mit Berechtigung zum Erstellen neuer Datenbanken

Schreiben Sie die folgenden Informationen für die spätere Verwendung auf:

• Hostname oder IP-Adresse des Datenbankservers

• Port des Datenbankservers

• Admin-Benutzername des Datenbankservers

• Admin-Passwort des Datenbankservers

Anmeldedaten für Container-Registry

ADONIS Container-Images werden in einer BOC-Registry zur Verfügung gestellt. Sie bekommen von Ihrem ADONIS-Kundenbetreuer die notwendigen Anmeldedaten:

• Registry-URL: Die BOC-Container-Registry-URL

• Access Identifier: Identität, mit welcher auf die Container Images zugegriffen wird.

• Access Token: Der Schlüssel zur Authentifizierung an der Container Registry.

Diese Anmeldedaten werden sowohl von Helm zum Zugriff auf das Helm-Chart-Repository als auch von Kubernetes zum Abrufen der Container-Images verwendet.

Benötigte Dateien

Bereiten Sie die folgenden Dateien auf Ihrem Administrationsrechner vor. In diesem Handbuch erstellen wir ein Verzeichnis /opt/data zum Speichern dieser Dateien. Wenn Sie sie in ein anderes Verzeichnis ablegen möchten, passen Sie die Pfade entsprechend an:

mkdir -p /opt/data/license /opt/data/library /opt/data/logs

Legen Sie die folgenden Dateien in den entsprechenden Verzeichnissen ab:

• Lizenzdatei: Legen Sie Ihre ADONIS Lizenzdatei (z. B. license.xxl) in /opt/data/license/ ab

• Anwendungsbibliothek (optional): Wenn Sie eine kundenspezifische ADONIS Anwendungsbibliothek anstelle der Standardbibliothek verwenden, legen Sie Ihre Bibliotheksdatei (z. B. library.axl) in /opt/data/library/ ab

Hinweis

Die Standard-Anwendungsbibliothek für ADONIS steckt bereits im Container-Image, Sie müssen daher keine Bibliotheksdatei bereitstellen.

Von BOC bereitgestellte Informationen

Sie sollten Folgendes von Ihrem ADONIS-Kundenbetreuer erhalten haben:

• ADONIS Lizenzdatei (license.xxl)

• Anmeldedaten für die Container-Registry

• Container-Registry-URL

• Kundenspezifische Anwendungsbibliothek (falls zutreffend)

Checkliste

Bevor Sie mit den nächsten Schritten fortfahren, überprüfen Sie folgende Punkte:

• kubectl, helm und docker sind installiert und funktionsfähig

• Sie können auf Ihren Kubernetes-Cluster mit kubectl cluster-info zugreifen

• Sie kennen Ihren Datenbankserver-Hostname, Port und Administrator-Anmeldedaten

• Sie haben Container-Registry-Benutzername, Passwort und Registry-URL erhalten

• Sie haben das Verzeichnis /opt/data mit entsprechenden Unterverzeichnissen erstellt

• Sie haben Ihre Lizenzdatei in /opt/data/license/ abgelegt

• Sie haben Ihre kundenspezifische Bibliotheksdatei in /opt/data/library/ abgelegt (falls zutreffend)

Erstellen oder Aktualisieren einer Datenbank für ADONIS

Erstellen oder aktualisieren Sie eine Datenbank für ADONIS vor dem Deployment in Kubernetes.

Bevor Sie ADONIS auf Ihrem Kubernetes-Cluster bereitstellen können, müssen Sie sicherstellen, dass Sie über eine dedizierte Datenbank mit dem korrekten Schema für ADONIS 19.0 verfügen. Diese Datenbank speichert alle ADONIS Daten und Konfiguration.

Wenn Sie:

• Ein neues Deployment von ADONIS durchführen: Bitte lesen Sie das Kapitel Datenbank erstellen für weitere Informationen.

• Ein vorhandenes Deployment von ADONIS aktualisieren: Bitte lesen Sie das Kapitel ADONIS aktualisieren für weitere Informationen.

Konfiguration des Deployments

Erstellen Sie die Datei mit Variablen, welche Helm für das Deployment von ADONIS auf Kubernetes verwendet.

Bevor Sie ADONIS auf Ihrem Kubernetes-Cluster bereitstellen, müssen Sie den Zugriff auf das Helm-Chart und Images aus der BOC OCI-Registry einrichten und eine Datei mit Variablen (Konfigurationsdatei) erstellen, die Helm während des Deployments verwendet. Diese Datei gibt Container-Image-Standorte, Datenbankverbindungsdetails, Einstellungen des Datenspeichers und andere Optionen an.

Authentifizierung an der Container-Registry

Helm benötigt Anmeldedaten für den Zugriff auf die BOC-Container-Registry, in der das ADONIS Helm-Chart gespeichert ist. Sie bekommen die für die Anmeldung benötigten Daten von Ihrem ADONIS-Kundenbetreuer. Es gibt verschiedene Möglichkeiten, neben der hier beschriebenen, wie Zugangsdaten sicher gespeichert und an Helm weitergegeben werden können, darunter auch die Nutzung von Drittanbieter-Software.

Falls Sie gerade eine neue Datenbank erstellt oder ein Upgrade einer bestehenden Datenbank durchgeführt haben, dann haben Sie noch die Docker config.json-Datei mit den Zugangsdaten, die Sie in diesem Schritt direkt verwenden können. Falls nicht, können Sie diese Datei auch mit einem Texteditor Ihrer Wahl manuell erstellen. Der folgende Befehl führt den Login an der BOC Container Registry durch und liest die Anmeldedaten aus der angegebenen Datei:

helm registry login <boc-registry-url> --registry-config <config.json>

Ersetzen Sie die Platzhalter:

• <boc-registry-url> - Die BOC OCI Registry-URL

• <config.json> - Eine JSON-Datei, welche die Anmeldedaten enthält, die Sie von Ihrem ADONIS-Kundenbetreuer erhalten haben.

Achtung

Die Datei config.json enthält Ihre Anmeldedaten im Klartext und sollte daher am Ende des Deployments sicher gelöscht werden.

Hinweis

Bitte verwenden Sie Zugangsdaten nicht als Parameter im Befehl; die Bash-Historie speichert eine Liste an zuletzt eingegebenen Befehlen und würde damit indirekt die Zugangsdaten im Klartext anzeigen, wenn man die History aufruft.

ImagePullSecret für Container-Registry erstellen

Kubernetes benötigt Anmeldedaten zum Abrufen der ADONIS Container-Images. Der einfachste Weg besteht im Erstellen eines ImagePullSecret in Ihrem Cluster, indem es die Zugangsdaten aus einer Datei einliest.

Falls Sie gerade eine neue Datenbank erstellt oder ein Upgrade einer bestehenden Datenbank durchgeführt haben, dann haben Sie noch die Docker config.json-Datei mit den Zugangsdaten, die Sie in diesem Schritt direkt verwenden können. Falls nicht, können Sie diese Datei auch mit einem Texteditor Ihrer Wahl manuell erstellen. Der folgende Befehl führt den Login an der BOC Container Registry durch und liest die Anmeldedaten aus der angegebenen Datei:

kubectl create secret generic <geheimer-name> --from-file=.dockerconfigjson=<config.json> --type=kubernetes.io/dockerconfigjson

Ersetzen Sie die Platzhalter:

• <geheimer-name> - Ein aussagekräftiger Name für die geheimen Anmeldedaten (z. B. boc-registry-secret). Dies muss mit dem Wert imagePullSecrets in der Konfigurationsdatei übereinstimmen, die Sie im nächsten Schritt erstellen.

• <config.json> - Eine JSON-Datei, welche Ihre Anmeldedaten für die BOC OCI Container Registry enthält. Sie bekommen diese Daten von Ihrem ADONIS-Kundenbetreuer.

Die Anmeldedaten werden nun in Ihrem Kubernetes-Cluster gespeichert und beim Abrufen von Images verwendet.

Achtung

Die Datei config.json enthält Ihre Anmeldedaten im Klartext und sollte daher am Ende des Deployments sicher gelöscht werden.

Hinweis

Bitte verwenden Sie Zugangsdaten nicht als Parameter im Befehl; die Bash-Historie speichert eine Liste an zuletzt eingegebenen Befehlen und würde damit indirekt die Zugangsdaten im Klartext anzeigen, wenn man die History aufruft.

Hinweis

Es gibt verschiedene Wege, wie Anmeldedaten in einem Kubernetes-Cluster gespeichert werden können, darunter auch Drittanbieter-Software, die die Daten Kubernetes erst zur Laufzeit zur Verfügung stellt. Bitte stellen Sie sicher, dass Sie eine Methode wählen, die Anmeldedaten entsprechend Ihrer Sicherheitserfordernisse speichert.

Konfigurationsdatei erstellen

Erstellen Sie eine neue Datei namens setup.yaml im Verzeichnis /opt/data:

touch /opt/data/setup.yaml

Bearbeiten Sie diese Datei mit Ihrem bevorzugten Text-Editor und kopieren Sie die folgende Konfigurationsvorlage hinein. Ersetzen Sie alle Platzhalterwerte (in spitzen Klammern dargestellt) mit Ihren Daten:

axx:
  imagePullSecrets:
    - name: <Name-des-ImagePullSecret>

  logMode: <STD|MIXED|FILES>
  aserver:
    env:
      - name: ADOXX_SERVER_DBHOST
        value: <Datenbankserver-Hostname>
      - name: ADOXX_SERVER_DBPORT
        value: <Datenbankserver-Port>
      - name: ADOXX_SERVER_DBTYPE
        value: <PostgreSQL|SQLServer>
      - name: ADOXX_SERVER_DBNAME
        value: <Datenbank-Name>
      - name: ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS
        value: <IP-oder-Bereich-des-Webservers>
    image:
      repository: <boc-registry>/<produkt>/aserver
      tag: <Produkt-Version>
    persistence:
      enabled: true
      mountPath: "/mnt"
      accessMode: "ReadWriteOnce"
      size: <Maximale-Größe-des-Speicherplatzes>
      storageClass: ""
      annotations: {}
  webserver:
    env:
      - name: AXW_PROPERTIES_aworker_purpose_scheduler
        value: "AS1:41900"
    image:
      repository: "<boc-registry>/<produkt>/webserver"
      tag: <produkt-version>
    persistence:
      enabled: true
      mountPath: "/mnt"
      accessMode: "ReadWriteOnce"
      size: <Maximale-Größe-des-Speicherplatzes>
      storageClass: ""
      annotations: {}

Erklärungen zu Platzhaltern

Ersetzen Sie die Platzhalter in Ihrer Konfigurationsdatei durch die entsprechenden Werte. Jeder Platzhalter wird im Folgenden erklärt:

ImagePullSecret

<Name-des-ImagePullSecret>: Der Name des Kubernetes ImagePullSecrets, das Ihre Container-Registry-Anmeldedaten enthält. Dies muss exakt dem Namen entsprechen, den Sie im vorherigen Schritt definiert haben.

Hinweis

Es gibt mehrere Möglichkeiten, wie Sie Anmeldedaten mit Kubernetes verwalten können, einschließlich externer Werkzeuge, die die Anmeldedaten speichern und zur Laufzeit Kubernetes bereitstellen. Bitte stellen Sie sicher, dass alle Anmeldedaten auf sichere Weise gespeichert werden.

Log-Dateien

<STD|MIXED|FILES>: ADONIS unterstützt verschiedene Arten, Logs zur Verfügung zu stellen. Wählen Sie eine der folgenden Optionen:

• MIXED: Schreibt Logs sowohl auf die Standardausgabe als auch in persistente Dateien im Container-Volume. Dies ist der empfohlene Wert für alle Anwendungsfälle. Sie können Logs entweder mit einer externen Log-Management-Software verarbeiten oder mit dem in Kubernetes integrierten Befehl kubectl logs anzeigen. Sie können auch, je nach Kubernetes-Speicherlösung, direkt auf die Dateien zugreifen.

• FILES: Schreibt Logs nur in persistente Dateien im Container-Volume. Dies wird häufig verwendet, wenn Sie eine Log-Management-Software einsetzen, die nur Dateien verarbeitet und Sie nicht möchten, dass Logs in den Kubernetes-eigenen Logs enthalten sind. Es gibt eine Reihe von Software für diesen Zweck, welche oft Dashboards oder andere Methoden zur Analyse der Logs bereitstellen.

• STD: Schreibt alle Logse auf die Standardausgabe. Dies wird häufig verwendet, wenn Sie eine Log-Management-Software im Einsatz haben, welche Logs in Echtzeit erfasst und verarbeitet und Sie die Log-Dateien nicht auf der Festplatte speichern möchten. Es gibt eine Reihe von Software für diesen Zweck, welche oft Dashboards oder automatisierte Warnungen bereitstellen. Bitte beachten Sie, dass Sie in diesem Fall die Funktion zum Herunterladen eines Support-Informationspakets (SIP), um Logs der BOC Support Hotline zur Verfügung zu stellen, nicht verwenden können, wenn die Logs nicht persistent gespeichert werden.

Hinweis

Zur Kontaktaufnahme mit der BOC Support Hotline können Sie die ADONIS Funktionalität verwenden, um ein Support-Informationspaket (SIP) in der ADONIS Administrations-Seite herunterzuladen, um Logs bereitzustellen. Dies erstellt eine verschlüsselte ZIP-Datei zur sicheren Übertragung der Logs.

Datenbankkonfiguration

<Datenbank-Hostname>: Der Hostname oder die IP-Adresse Ihres Datenbankservers. Beispiel: db-server.example.com oder 192.168.1.100.

Datenbank-Port

<Datenbank-Port>: Der Port, auf dem Ihr Datenbankserver erreichbar ist. Übliche Werte, je nach Datenbanksystem:

• PostgreSQL: 5432

• MS SQL Server: 1433

Datenbankname

<Datenbank-Name>: Der Name der ADONIS Datenbank, die Sie im vorherigen Schritt erstellt haben. Beispiel: produktdb oder produkt.

Hinweis

Wenn der Name der Datenbank Sonderzeichen enthält, muss dieser in der YAML-Konfiguration in doppelten Anführungszeichen eingetragen werden.

Datenbanktyp

PostgreSQL oder SQLServer: Geben Sie an, welches Datenbanksystem Sie verwenden. Unterstützte Versionen finden Sie in den HW/SW-Anforderungen.

Webserver-Zugriff

<IP-oder-Bereich-des-Webservers>: Die IP-Adresse oder der IP-Bereich, von dem aus sich der Webserver mit dem Anwendungsserver verbindet. In diesem minimalen Setup laufen beide im selben Cluster, daher können Sie normalerweise die Pod-IP oder den Service-Namen verwenden. In Produktivbetrieb hängt dies von Ihrer Netzwerkkonfiguration des Kubernetes-Clusters ab. Häufige Werte sind der Service-Name wie produkt-webserver oder 10.0.*.*

Container-Images

<boc-registry>/<Produkt>: Die URL der BOC-Container-Registry. Dieser Wert wird von Ihrem BOC-Berater bereitgestellt.

ADONIS Version

<Produkt-Version>: Die Version von ADONIS zum Bereitstellen. Dies ist der Versions-Tag des Images und der Helm-Chart in der BOC OCI-Registry und muss mit der Version übereinstimmen, die Sie bereitstellen möchten, z. B. 19.0.

Konfiguration des Datenspeichers

Für Entwicklung und Tests

Die in diesem Beispiel gezeigte Speicherkonfiguration ist für Tests, Evaluierung und Entwicklung geeignet:

• enabled: true - Aktivieren Sie persistenten Speicher für Logs und andere Daten

• size: <Maximale-Größe-des-Speicherplatzes> - Weisen Sie mindestens 1 GB Speicher für die Dateien des Volltext-Suchindex (FTS) und der Logs zu. Die Größe hängt davon ab, wie groß Ihre Umgebung ist und insbesondere von der Anzahl der in die Datenbank hochgeladenen Dokumentdateien.

• storageClass: "" - Verwenden Sie die Standard-Speicherklasse des Clusters

Achtung

Es wird nicht empfohlen, diesen Speichertyp in Produktivumgebungen zu verwenden. Kubernetes kann mit einer Reihe verschiedener Lösungen arbeiten, um verteilten und hochverfügbaren Speicher für einen Pod bereitzustellen.

Für Produktivbetrieb

In einer Produktivumgebung verwenden Sie normalerweise einen Speicher-Provider, der verteilten, hochverfügbaren Speicher für einen Pod bietet. Es gibt eine Reihe verschiedener verfügbarer Dienste. Welcher für Ihren Cluster geeignet ist, hängt von verschiedenen Faktoren ab, einschließlich Typ und Standort Ihres Speichers, Größe des Clusters und anderen. Beispiele für solche Dienste sind CEPH/Rook, Longhorn und andere.

Wichtige Punkte für die Konfiguration des Speichers von ADONIS:

• Die Speichergröße für den Volltext-Suchindex (FTS) kann in großen Umgebungen mit vielen indizierten Dokumenten mehrere Gigabyte betragen.

• Der Volltext-Suchindex (FTS) kann zwar jederzeit neu erstellt werden, aber in großen Umgebungen kann dies lange dauern und währenddessen liefert die Suche in ADONIS keine oder unvollständige Ergebnisse. Erwägen Sie eine robuste Lösung mit einfacher Wiederherstellung.

• Wenn Sie eine zentrale Log-Management-Software verwenden, erwägen Sie einen separaten, dedizierten Speicher für Logs.

Diese Themen sind spezifisch für Ihre Infrastruktur und Kubernetes-Cluster-Konfiguration. Konsultieren Sie Ihren Kubernetes-Administrator oder Ihr Infrastruktur-Team für produktionsgerechte Speicherkonfiguration.

Häufig verwendete Umgebungsvariablen

Neben den erforderlichen Umgebungsvariablen in unserem Beispiel gibt es eine Liste häufig verwendeter Variablen für spezifische Zwecke. Bitte überprüfen Sie, ob sie auf Ihren Fall zutreffen, und fügen Sie sie zur setup.yaml-Datei hinzu. In der Tabelle unten geben wir an, auf welchen Container sich die jeweilige Variable bezieht. Variablen für den Anwendungsserver müssen zum Abschnitt aserver: der Datei hinzugefügt werden, während Variablen für den Webserver zum Abschnitt webserver: hinzugefügt werden müssen.

Container	Umgebungsvariable	Beschreibung
Anwendungsserver	ADOXX_ACCENT_INSENSITIVE	Bestimmt, ob die Suche Akzente ignoriert, z. B. (ä = a), so dass die Suche nach Test oder Têst dieselben Ergebnisse liefert. Typ: BOOL Default: True
Anwendungsserver	ADOXX_DBMS_ENCRYPTION	Wenn Microsoft SQL Server mit ODBC-Treiber Version 18 und höher verwendet wird, wird verschlüsselte Kommunikation standardmäßig vorausgesetzt. Wenn Ihr Server ODBC-Verbindungen nicht verschlüsselt, muss dieser Wert auf optional gesetzt werden, sonst schlägt die Verbindung fehl. Gültige Werte: optional, mandatory, strict Default: mandatory
Anwendungsserver	ADOXX_DBMS_TRUST_SERVER_CERTIFICATE	Legt fest, ob dem Serverzertifikat beim Öffnen einer verschlüsselten ODBC-Verbindung vertraut werden sollte. Gültige Werte: yes, no Default: no
Anwendungsserver	ADOXX_LOG_MODE	Die Protokollierung kann in Log-Dateien, auf der Standardausgabe oder auf beiden erfolgen. Gültige Werte: FILES, STD, MIXED Default: FILES
Anwendungsserver	ADOXX_SECURITY_DISABLE_AUDIT_LOG_SENSITIVE_DATA_ENCRYPTION	Standardmäßig sind Benutzernamen und andere PII in Audit-Logs verschlüsselt, um vertrauliche Informationen zu schützen. Dies kann deaktiviert werden, damit Administratoren diese Informationen prüfen können. Typ: BOOL Default: False (= Verschlüsselung ist AKTIV)
Anwendungsserver	ADOXX_SECURITY_DISABLE_SENSITIVE_DATA_ENCRYPTION	Standardmäßig sind Benutzernamen und andere PII in regulären Logs verschlüsselt, um vertrauliche Informationen zu schützen. Dies kann deaktiviert werden, damit Administratoren diese Informationen prüfen können. Typ: BOOL Default: False (= Verschlüsselung ist AKTIV)
Anwendungsserver	ADOXX_SERVER_DBNAME	Name der Datenbank. Pflichtwert. Muss angegeben werden
Anwendungsserver	ADOXX_SERVER_DBTYPE	Datenbanksystem. Pflichtwert. Gültige Werte: PostgreSQL oder SQLServer Muss angegeben werden
Anwendungsserver	ADOXX_SERVER_PORTS	Dies bestimmt, wie viele aworker-Instanzen erstellt werden. Jede Portnummer ist eine separate aworker-Instanz. Komma getrennt. Pflichtwert Gültige Werte: Portnummern Muss angegeben werden
Anwendungsserver	SERVER_AUTO_CLEANUP	Startet die aworker automatisch zum geplanten Tag und zur geplanten Zeit neu. Typ: BOOL Default: True
Anwendungsserver	SERVER_AUTO_CLEANUP_DAY	Liste der durch Leerzeichen getrennten Nummern, die die Wochentage bezeichnen. Gültige Werte, z. B. 1 2 3 Default: 1 2 3 4 5 6 7 (= täglich)
Anwendungsserver	SERVER_AUTO_CLEANUP_TIME	Zeit, zu der der Neustart ausgeführt werden soll. Gültiges Format: 00:00 Default: 00:00
Webserver	AXW_PROPERTIES_aservers	Liste der aserver, getrennt durch Kommas in der Form <Server-Nummer>:<Server-Name/IP>. Pflichtwert. Gültiges Format, z. B. AS1:127.0.0.1 Muss angegeben werden
Webserver	AXW_PROPERTIES_aworkers	Liste der aworker-Instanzen und Ports in der Form <Server-Nummer>:<Port>. Pflichtwert. Gültiges Format, z. B AS1:54321 Muss angegeben werden
Webserver	AXW_PROPERTIES_aworker_purpose_mail	Designiert einen bestimmten aworker, auf dem Mail-Jobs ausgeführt werden. Gültiges Format, z. B AS1:54321 Default: leer
Webserver	AXW_PROPERTIES_aworker_purpose.scheduler	Designiert einen bestimmten aworker, auf dem Hintergrund-Jobs ausgeführt werden Gültiges Format, z. B AS1:54321 Default: leer
Webserver	AXW_PROPERTIES_aworker_purpose_system	Designiert einen bestimmten aworker, auf dem System-Hintergrund-Jobs ausgeführt werden Gültiges Format, z. B AS1:54321 Default: leer
Webserver	AXW_PROPERTIES_aworker_purpose_user	Designiert einen bestimmten aworker, auf dem Benutzersitzungen ausgeführt werden Gültiges Format, z. B AS1:54321 Default: leer
Webserver	AXW_PROPERTIES_custom_version	Optionale Version, die bereitgestellt werden kann, um Browser anzuweisen, Skripte und Styles neu zu laden, wenn einige Dateien geändert wurden, obwohl die Revision nicht geändert wurde. Default: leer
Webserver	AXW_PROPERTIES_http_proxy_ip	IP des Proxy, der Verbindungen zum Internet für bestimmte Funktionen und Dienste von Drittanbietern zur Verfügung stellt. Gültiges Format: IP-Adresse Default: leer
Webserver	AXW_PROPERTIES_http_proxy_port	Port des Proxy. Typ: INTEGER Default: leer
Webserver	AXW_PROPERTIES_mail_enable_security	Aktivieren/Deaktivieren von Sicherheitsbeschränkungen beim Versenden von E-Mails. Typ: BOOL Default: True
Webserver	AXW_PROPERTIES_mail_max_mail_size	Die maximale Größe einer E-Mail (kB), die zum Versenden zulässig ist. Wenn dieser Wert zu klein gewählt wird, kann das dazu führen, dass E-Mails nicht versendet werden können. Unsere Empfehlung ist mindestens 500 kB für E-Mails mit vielen Links. Typ: INTEGER Default: 50
Webserver	AXW_PROPERTIES_mail_max_mails_per_hour	Maximale Anzahl von E-Mails, die in einer Stunde versendet werden dürfen. Typ: INTEGER Default: 500
Webserver	AXW_PROPERTIES_mail_max_recipients_per_mail	Maximale Anzahl von Empfängern pro E-Mail. Typ: INTEGER Default: 500
Webserver	AXW_PROPERTIES_mail_send_smtp_localhost	Falls E-Mail über SMTP des localhost versendet werden soll. Typ: BOOL Default: False
Webserver	AXW_PROPERTIES_mail_sender_verbose	Wie viele Informationen zu Fehlern protokolliert werden. Typ: BOOL Default: False
Webserver	AXW_PROPERTIES_mail_trusted_recipient_domains	Legt fest, dass E-Mails nur an Empfänger in der Liste der Domänen versendet werden können. Gültige Werte: Domänen Default: leer
Webserver	AXW_PROPERTIES_report_parallel_execution	Dies begrenzt, wie viele Reports gleichzeitig erstellt werden können. Wenn dieser Wert zu hoch gewählt wird, kann dies die Performance für Benutzer beeinträchtigen. Werden mehr Reports von Benutzern angefordert werden, werden sie in die Warteschlange eingereiht. Typ: INTEGER Default: 3
Webserver	AXW_PROPERTIES_search_result_max_size	Begrenzt die Anzahl der Ergebnisse, die eine Suche liefern kann. Wird dieser Wert zu niedrig gewählt, können Suchergebnisse unvollständig sein. Typ: INTEGER Default: 10000
Webserver	AXW_PROPERTIES_security_csp	Setzt die Content Security Policy. Entweder kann die gesamte Richtlinie in dieser Variable gesetzt werden oder eine oder mehrere der folgenden _src_ Variablen können für spezifische Zwecke verwendet werden. default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src * data: filesystem:; frame-src 'self'; media-src 'self'; connect-src 'self'; font-src data: 'self'; frame-ancestors 'none'; Detaillierte Informationen zu diesen Policies finden Sie auf https://content-security-policy.com/
Webserver	AXW_PROPERTIES_security_encrypt_usernames	Legt fest, ob Benutzernamen in den Logs verschlüsselt werden. Dies hat Auswirkungen auf den Datenschutz von PII und sollte daher mit Sorgfalt gewählt werden. Typ: BOOL Default: True
Webserver	AXW_PROPERTIES_security_src_connect_src	Setzt die Content Security Policy für AJAX-Anfragen. Default: connect-src 'self';
Webserver	AXW_PROPERTIES_security_src_frame_ancestors	Setzt die Content Security Policy für eingebettete Ressourcen. Default: frame-ancestors 'none';
Webserver	AXW_PROPERTIES_security_src_frame_src	Setzt die Content Security Policy für eingebettete Frames. Default: frame-src 'self';
Webserver	AXW_PROPERTIES_security_src_img_src	Setzt die Content Security Policy für Bilder. Default: img-src * data: filesystem:;
Webserver	AXW_PROPERTIES_security_src_media_src	Setzt die Content Security Policy für Medien-Dateien. Default: media-src 'self';
Webserver	AXW_PROPERTIES_security_src_script_src	Setzt die Content Security Policy für Skript-Tags. Default: script-src 'self' 'unsafe-inline' 'unsafe-eval';
Webserver	AXW_PROPERTIES_security_src_style_src	Setzt die Content Security Policy für Style-Tags. Default: style-src 'self' 'unsafe-inline';
Webserver	AXW_PROPERTIES_translationsvc_microsoft_azure_api_key	Die automatische Übersetzung mit dem Microsoft Azure Translation Service kann durch Hinzufügen des verschlüsselten API-Key aktiviert werden. Default: leer (= Übersetzung deaktiviert)
Webserver	AXW_PROPERTIES_translationsvc_microsoft_azure_region	Die Region für den Microsoft Azure Translation Service. Standard: leer
Webserver	AXW_PROPERTIES_translationsvc_microsoft_azure_subdomain	Die benutzerdefinierte Subdomain für den Microsoft Azure Translation Service. Standard: leer

Deployment von ADONIS

Stellen Sie ADONIS auf Ihrem Kubernetes-Cluster mit Helm bereit.

Dieser Abschnitt führt Sie durch das Deployment von ADONIS auf Ihrem Kubernetes-Cluster mit Helm. Sie haben sich bereits mit Helm an der BOC Registry angemeldet und für Kubernetes ein ImagePullSecret zum Abruf der Images erstellt. Als nächstes laden Sie das Helm-Chart herunter und führen das Deployment von ADONIS durch.

Helm-Chart abrufen und extrahieren

Rufen Sie das ADONIS Helm-Chart aus der Registry ab und extrahieren Sie sie auf Ihrem Administrationsrechner:

helm pull oci://<boc-registry>/<helm-repository>
tar zxvf <produkt>-<produkt-version>.tgz

Ersetzen Sie:

• <boc-registry> - Die BOC-Registry-URL. Sie erhalten diese von Ihrem ADONIS-Kundenbetreuer.

• <helm-repository> - Der Bereich, in dem das Helm-Chart zum Herunterladen bereit steht. Sie erhalten diesen von Ihrem ADONIS-Kundenbetreuer.

Konfiguration im Dry-Run (Probelauf) überprüfen

Bevor Sie das tatsächliche Deployment durchführen, überprüfen Sie, ob Ihre Konfiguration korrekt und vollständig ist:

helm install <Ihr-Produkt> ./<Chart-Dateiname> -f /opt/data/setup.yaml --dry-run

Ersetzen Sie:

• <Ihr-Produkt> - Wählen Sie einen geeigneten Namen für das Deployment. Dieser Name wird als Präfix für alle erstellten Ressourcen verwendet.

• <Chart-Dateiname> - Dies ist der Dateiname das Helm-Chart, die Sie im vorherigen Schritt extrahiert haben.

Dieser Befehl simuliert das Deployment ohne tatsächlich Änderungen vorzunehmen:

• Er validiert Ihre YAML-Konfiguration auf Syntaxfehler

• Er zeigt, welche Ressourcen erstellt werden

• Er zeigt Validierungsfehler oder Warnungen an

Überprüfen Sie die Ausgabe sorgfältig. Wenn es Fehler gibt, korrigieren Sie Ihre setup.yaml-Datei und führen Sie den Dry-Run Befehl erneut aus.

Stellen Sie ADONIS bereit

Sobald der Probelauf erfolgreich abgeschlossen ist, stellen Sie ADONIS in Ihrem Cluster bereit:

helm install <Ihr-Produkt> ./<Chart-Dateiname> -f /opt/data/setup.yaml

Helm erstellt die erforderlichen Kubernetes-Ressourcen und beginnt mit dem Deployment von ADONIS. Dieser Vorgang kann einige Minuten dauern.

Optional: In einem bestimmten Namespace bereitstellen

Um ADONIS in einem bestimmten Kubernetes-Namespace anstelle des Standard-Namespaces bereitzustellen:

helm install <Ihr-Produkt> ./<Chart-Dateiname> -f /opt/data/setup.yaml --namespace <Ihr-Namespace>

Falls der Namespace nicht existiert, fügen Sie das Flag --create-namespace hinzu:

helm install <Ihr-Produkt> ./<Chart-Dateiname> -f /opt/data/setup.yaml --namespace <Ihr-Namespace> --create-namespace

Überprüfen Sie das Deployment

Überprüfen Sie nach dem Deployment, dass die ADONIS-Pods laufen und sind der Zustand korrekt (healthy) ist:

kubectl get pods --watch

Dieser Befehl zeigt den Status aller Pods an. Überwachen Sie die Ausgabe, bis Sie sehen, dass sowohl die aserver- als auch die webserver-Pods den Status 1/1 erreichen (was bedeutet, dass sie laufen und bereit sind).

Drücken Sie Ctrl+C, um den Watch-Befehl zu beenden, sobald beide Pods bereit sind.

Erwarteter Pod-Status Output

NAME READY STATUS RESTARTS AGE Ihr-Produkt-aserver-0 1/1 Running 0 45s Ihr-Produkt-webserver-0 1/1 Running 0 40s

Wenn Pods in einem Status Pending oder CrashLoopBackOff bleiben, überprüfen Sie die Logs auf Fehler:

kubectl logs <pod-name>

Weitere Schritte zur Prüfung des Cluster-Zustands finden Sie im Abschnitt Verwalten Sie Ihr Deployment.

Hinweis

Sobald die Pods gestartet sind und der Zustand korrekt (healthy) ist, lädt der Applikations-Server und der Web-Server die Konfiguration und Ausführungsdaten (Bootstrapping). Es wird einige Zeit dauern, bevor die Login-Seite verfügbar ist.

Zugriff auf ADONIS

Minimale Konfiguration für den Zugriff (Entwicklung/Tests)

Für Entwicklungs- und Testzwecke können Sie eine Port-Weiterleitung verwenden, um auf ADONIS zuzugreifen:

kubectl port-forward service/Ihr-Produkt-webserver 8080:8080 --address 0.0.0.0

Dieser Befehl leitet Port 8080 auf Ihrem Administrationsrechner an Port 8080 des Webserver-Service weiter. Sie können dann über folgende URL auf ADONIS zugreifen:

http://localhost:8080/

Achtung

Wichtig: Port-Weiterleitung ist nicht für den Produktivbetrieb geeignet. Sie bietet direkten Zugriff von einem einzelnen Administrationsrechner und ist nur zum Testen der Umgebung nach dem Deployment gedacht. Port-Weiterleitungen sind nur temporär und überleben keine Neustarts des Pods oder des Rechners, auf dem die Port-Weiterleitung läuft.

Produktivbetrieb: Service Exposure

In einer Produktivumgebung benötigen Sie eine ordnungsgemäße Service Exposure-Methode, um die Anwendung für Benutzer zur Verfügung zu stellen. Der Webserver wird standardmäßig nur als ClusterIP Service eingerichtet.

Es gibt verschiedene Service Exposure-Methoden für den Produktivbetrieb. Die folgende Liste nennt nur einige gebräuchliche, aber es gibt auch andere Optionen abhängig von Ihrem Kubernetes-Setup und Anforderungen:

• Ingress-Controller: Verwenden Sie eine Ingress-Resource mit einem Controller wie Nginx, Traefik oder dem Ingress-Controller Ihres Cloud-Providers. Dies bietet URL-basiertes Routing, TLS-Terminierung und Lastverteilung.

• LoadBalancer Service: Verwenden Sie den Service-Typ LoadBalancer, falls Ihr Kubernetes-Cluster-Provider dies unterstützt. Dies exponiert den Service über den Lastverteilungs-Service Ihres Cloud-Providers.

Jeder Ansatz erfordert spezifische Konfiguration und Kenntnisse Ihrer Kubernetes-Umgebung. Konsultieren Sie Ihren Kubernetes-Administrator und Ihr Infrastruktur-Team, um die geeignete Methode für Ihre Organisation zu bestimmen.

Service-Exposure ist eine Cluster-Management-Entscheidung und liegt außerhalb des Umfangs dieser Anleitung. Ihr Infrastruktur-Team sollte entscheiden, wie das ADONIS Service basierend auf Ihren Organisationsanforderungen und der Infrastruktur-Plattform den Benutzern zur Verfügung gestellt wird.

Verwalten Sie Ihr Deployment

Verwalten und warten Sie Ihr Deployment von ADONIS auf Kubernetes.

Nach erfolgreichem Deployment und Starten von ADONIS können Sie diese Befehle verwenden, um Ihr Deployment zu verwalten und zu überwachen.

Status des Deployments anzeigen

Pod-Status prüfen

Mit diesem Befehl können Sie sich den Status der ADONIS-Pods anzeigen lassen:

kubectl get pods

Dies listet alle laufenden Pods auf. Sowohl der Anwendungsserver (aserver) als auch der Web-Server Pod sollten den Status Running mit 1/1 Ready anzeigen.

Für weitere Details verwenden Sie:

kubectl describe pod <pod-name>

Logs und Ressourcen anzeigen

Logs in Kubernetes direkt anzeigen

Falls Sie keine dedizierte Lösung zur Verwaltung und Aggregation von Logs im Einsatz haben und der Log-Mode auf logMode: MIXED oder logMode: STD gesetzt ist, können Sie den integrierten Kubernetes-Befehl zum Zugriff auf Logs verwenden.

kubectl logs <pod-name>

Prüfen Sie die Logs in Echtzeit (Streaming) mit dem Flag -f:

kubectl logs -f <pod-name>

Vorherige Logs anzeigen

Wenn ein Pod abgestürzt ist und neu gestartet wurde, zeigen Sie Logs aus der vorherigen Instanz mit diesem Befehl an:

kubectl logs --previous <pod-name>

Ressourcennutzung

Folgender Befehl zeigt Ihnen die CPU- und Speichernutzung von Pods:

kubectl top pods

Dies zeigt den Ressourcenverbrauch von Cluster-Knoten und einzelnen Pods.

Datenbank-Sicherungen

Regelmäßige Sicherungen Ihrer ADONIS Datenbank sind essenziell. Wir empfehlen die Einrichtung von automatischen Backups mit Ihrer Backup-Lösung oder den Verwaltungswerkzeugen Ihres Datenbanksystems. Definieren Sie auch eine für Ihre Organisation angemessene Vorhaltedauer von Backups.

Sicherungsverfahren sind datenbankspezifisch und liegen außerhalb des Umfangs dieser Anleitung. Konsultieren Sie Ihren Datenbankadministrator oder die Datenbank-Dokumentation für ordnungsgemäße Sicherungsstrategien.

Unterstützung erhalten

Wenn Sie auf Probleme stoßen, die nicht in dieser Anleitung behandelt werden:

1. Überprüfen Sie die ADONIS Logs auf detaillierte Fehlermeldungen

2. Konsultieren Sie Ihren Kubernetes-Administrator für Cluster-spezifische Probleme

3. Kontaktieren Sie Ihren ADONIS-Kundenbetreuer für ADONIS spezifische Probleme

4. Kontaktieren Sie die BOC Support-Hotline für Software-Probleme

Entfernen von ADONIS

Entfernen Sie ADONIS von Ihrem Kubernetes-Cluster.

Um ADONIS zu entfernen, können Sie den entsprechenden Helm-Befehl verwenden. Dies entfernt ADONIS aus dem Cluster und löscht — abhängig von den Optionen, die Sie diesem Befehl mitgeben — Ressourcen, die während des Deployments erstellt wurden.

Deployment löschen

Um ADONIS aus Ihrem Cluster zu entfernen:

helm uninstall <your-product>

Optional: Deployment aus einem bestimmten Namespace löschen

Wenn Sie ADONIS in einen bestimmten Kubernetes-Namespace anstelle des Standard-Namespaces bereitgestellt haben, geben Sie den Namespace beim Entfernen an:

helm uninstall <your-product> --namespace <your-namespace>

Dies entfernt ADONIS aus dem Cluster. Ihre Datenbank bleibt unverändert und kann für ein zukünftiges Deployment von ADONIS wiederverwendet werden.

Persistenten Speicher löschen

Persistenter Speicher wird für Volltext-Suche-Daten (FTS) und Logs verwendet. Abhängig von der Konfiguration, Ihrer Speicherlösung und den Befehlsoptionen kann es erforderlich sein, persistenten Speicher manuell zu entfernen.

Images aufräumen

Nach dem Entfernen von ADONIS bereinigt Kubernetes normalerweise alte Images automatisch. Dies hängt von Ihrer Cluster-Konfiguration ab.

Weitere Informationen dazu, wie Kubernetes mit ungenutzten Daten umgeht, finden Sie im Kapitel Garbage Collection.

Datenbank aufräumen

Die Datenbank wird während des Entfernens von ADONIS normalerweise nicht gelöscht. Das Entfernen der Datenbank ist eine manuelle Aufgabe, die vom Typ des Dasenbanksystems abhängt, das Sie im Einsatz haben (PostgreSQL oder MS SQL Server), und dem Datenbank-Administrationswerkzeug, das Sie verwenden.