Technische Produktinformation - ADONIS 19

Übersicht​

Mit ADONIS 19 wird das Produkt für On-Premise-Kunden erstmals in vollständig containerisierter Form ausgeliefert. Damit wird ein wichtiger Schritt in Richtung verbesserter Skalierbarkeit, Portabilität und operativer Flexibilität vollzogen. Durch die Einführung eines modernen, containerbasierten Deployment-Modells kann ADONIS effizient in aktuellen und zukünftigen IT-Umgebungen betrieben werden, während die vertrauten funktionalen Eigenschaften früherer Versionen erhalten bleiben.

Architektur​

Mit ADONIS 19 wird die Anwendung als Set von OCI-konformen Container-Images ausgeliefert. Dieser Ansatz bewahrt die funktionale Architektur früherer ADONIS-Versionen und ermöglicht zugleich ein flexibles und modernes Deployment-Modell.

Die zentralen Anwendungskomponenten werden in zwei separaten Containern ausgeführt:

• Web-Server-Container

• Applikations-Server-Container

Die entsprechenden Images werden über eine OCI-konforme Registry bereitgestellt.

ADONIS unterstützt zwei Deployment-Varianten:

• Kubernetes-Deployment, unter Verwendung des mitgelieferten Helm-Charts

• Docker-Compose-Deployment, unter Verwendung der mitgelieferten Compose-Konfiguration

Beide Deployment-Optionen orchestrieren dieselben zwei containerisierten Anwendungskomponenten. Kubernetes bietet erweiterte Orchestrierungsfunktionen mit spezialisierten Ressourcentypen und Integrationsmöglichkeiten sowie generell eine Cluster-Architektur auf Enterprise-Niveau. Docker Compose hingegen ermöglicht ein vereinfachtes Setup für Umgebungen, die nicht den vollen Funktionsumfang von Kubernetes benötigen.

Die ADONIS-Datenbank wird typischerweise außerhalb des Kubernetes-Clusters bzw. der Docker-Umgebung betrieben. Kunden verwalten ihren bestehenden Datenbankserver weiterhin unabhängig.

Kubernetes-Deployment​

Die folgende Abbildung zeigt, wie ADONIS 19 in einer Kubernetes-Umgebung bereitgestellt wird. Die Anwendungskomponenten werden in einem dedizierten Namespace betrieben, während unterstützende Infrastrukturkomponenten typischerweise in anderen Namespaces bereitgestellt sind.

Voraussetzungen für Kubernetes​

Der Kubernetes-Cluster, in dem ADONIS betrieben werden soll, muss folgende Komponenten bereitstellen:

• Einen Ingress-Controller oder einen Gateway-API-Controller für das Routing des Endbenutzer-Datenverkehrs

• Eine StorageClass zur Provisionierung persistenter Volumes

  • allowVolumeExpansion=true wird dringend empfohlen

Darüber hinaus wird empfohlen, dass der Cluster folgende Komponenten bereitstellt:

• cert-manager zur automatisierten Verwaltung von TLS-Zertifikaten für Ingress oder HTTPRoute
• ClamAV, das einen TCP-Endpoint für Malware-Scans beim Hoch- und Herunterladen von Dateien bereitstellt

Architekturdetails​

ADONIS-Namespace​

Die Anwendungskomponenten von ADONIS werden in einem eigenen Namespace betrieben und umfassen:

• HttpRoute / Ingress, das als Einstiegspunkt für externen Traffic in den ADONIS-Namespace dient

• Web-Server-Ebene, auf der der Web-Server über einen Kubernetes-Service exponiert wird und ein persistentes Volume zum Speichern lokaler Logdateien nutzt

• Applikations-Server-Ebene, auf der der Applikations-Server als separates Deployment betrieben wird, mit eigenem Service sowie persistentem Speicher für den Volltext-Suchindex und lokale Logdateien

Weitere Namespaces​

Cluster-weite Komponenten, die das ADONIS-Deployment unterstützen:

• Ingress-Controller / Gateway-API-Controller zum Routing von externem Datenverkehr

• StorageClass zur Provisionierung persistenter Volumes

• cert-manager (optional) zur automatisierten Verwaltung von TLS-Zertifikaten

• ClamAV (optional) für Malware-Scans

Deployment-Verhalten​

• Sowohl das Web-Server-Deployment als auch das Applikations-Server-Deployment unterstützen vertikale Skalierung durch Memory- und CPU-Requests oder -Limits.

• Ab Kubernetes 1.35 können Requests und Limits auf Pod-Ebene ohne Downtime angepasst werden.

• Jedes Deployment wird mit einer einzelnen Replik betrieben; ADONIS 19 unterstützt keine horizontale Skalierung mit mehreren Replikas.

• Lokale Logdateien sind erforderlich, um innerhalb der Anwendung ein Support Information Package (SIP) erzeugen zu können, das für den technischen Support benötigt wird.

Externe Datenbank​

ADONIS verwendet eine externe PostgreSQL- oder MSSQL-Datenbank, die außerhalb des Kubernetes-Clusters betrieben und unabhängig verwaltet wird.

Docker-Compose-Deployment​

Die folgende Abbildung zeigt, wie ADONIS 19 auf einem einzelnen Host mithilfe von Docker-Compose-kompatiblen Tools wie Docker oder Podman betrieben werden kann.

In diesem Setup laufen der ADONIS Web-Server-Container und der Applikations-Server-Container auf derselben Maschine. Persistente Daten werden in Docker-Volumes gespeichert, und der externe Zugriff erfolgt typischerweise über einen Reverse Proxy.

Architekturdetails​

ADONIS Docker-Compose-Stack​

Der Docker-Compose-Stack besteht aus:

• Reverse Proxy (z.B. nginx), der eingehende HTTP(S)-Anfragen entgegennimmt und an den ADONIS Web-Server weiterleitet

• Web-Server-Container

• Applikations-Server-Container

• Volumes, die zur Speicherung lokaler Logdateien und des Volltext-Suchindex verwendet werden

Deployment-Verhalten​

• Sowohl der Web-Server als auch der Applikations-Server werden auf einem einzelnen Host betrieben.

• Container-Volumes stellen die Persistenz für Logdateien und Suchindex-Daten sicher.

• Die Skalierung ist auf ein Single-Node-Setup beschränkt; verteilte Deployments oder der Betrieb mit mehreren Replikas werden nicht unterstützt.

• Lokal in Volumes gespeicherte Logdateien ermöglichen die Erstellung eines Support Information Package (SIP) für den technischen Support.

Externe Datenbank​

ADONIS verwendet eine externe PostgreSQL- oder MSSQL-Datenbank, die typischerweise außerhalb des Docker-Hosts betrieben und unabhängig verwaltet wird.

Registry und Updates​

ADONIS 19 wird in einem containerbasierten Format ausgeliefert. Die folgenden Release-Artefakte werden bereitgestellt.

Container-Images​

Die ADONIS-Anwendung wird als Set von Container-Images ausgeliefert, bestehend aus:

• Web-Server-Image – stellt die Web-Oberfläche bereit und verarbeitet HTTP(S)-Anfragen
• Applikations-Server-Image – führt die ADONIS-Anwendungslogik und Backend-Operationen aus

Helm-Charts​

Für Kubernetes-basierte Deployments stellt ADONIS für jede veröffentlichte ADONIS-Version ein Helm-Chart bereit. Dieses definiert die Kubernetes-Ressourcen und Konfigurationsparameter, die für den Betrieb der ADONIS-Komponenten in einer containerisierten Umgebung erforderlich sind.

Die Auslieferung umfasst ein Umbrella-Chart, das das vollständige ADONIS-Deployment beschreibt.

Das Umbrella-Chart enthält eine zentrale values.yaml-Datei, in der unter anderem folgende Aspekte definiert werden:

• Referenzen auf Container-Images

• Ressourceneinstellungen

• Service-Konfiguration

• umgebungsspezifische Parameter

Diese Werte können an die Anforderungen der Zielumgebung angepasst werden.

Das Helm-Chart enthält ausschließlich Deployment-Konfiguration, beispielsweise:

• Definitionen der Container-Images

• Kubernetes-Ressourcenspezifikationen

• Konfigurationsparameter

Das Helm-Chart enthält keine Applikationsdaten und lädt diese auch nicht vor.

Applikationsdaten werden persistent in der konfigurierten Datenbank gespeichert und sind daher nicht von Deployments, Upgrades oder einem erneuten Deployments des Helm-Charts betroffen. Dadurch bleiben Deployments auf Anwendungsebene zustandslos (stateless), während persistente Daten unabhängig über die Datenbank und konfigurierte Speicher-Ressourcen verwaltet werden.

Artefakt-Distribution​

Container-Registry​

Alle Container-Images und Helm-Charts werden über eine offizielle, von BOC verwaltete OCI-konforme Registry ausgeliefert.

• Kunden erhalten eine E-Mail-Einladung zur Registrierung für die Registry.

• Der Zugriff auf die Registry ist über authentifizierte, rollenbasierte Zugriffskontrollen abgesichert.

• Nach erfolgreichem Onboarding können Kundinnen und Kunden ihre eigenen Zugangsdaten (z.B. Zugriffsschlüssel oder Tokens) verwalten.

Diese Zugangsdaten können verwendet werden, um die erforderlichen ADONIS-Artefakte sicher aus der Registry abzurufen, unter anderem über:

• Container-Runtimes (z.B. Docker, containerd, Podman)

• Kubernetes-Umgebungen

• CI/CD-Pipelines oder Deployment-Automatisierungstools

Air-Gapped-Umgebungen​

Container-Images können in interne Registries gespiegelt werden, um eingeschränkte Umgebungen oder Air-Gapped-Umgebungen zu unterstützen.

Beispiele für interne Registry-Lösungen sind:

• JFrog Artifactory

• Harbor

• Nexus Repository

Updates​

Updates für Container-Images und Helm-Charts folgen dem etablierten ADONIS-Release- und Wartungsprozess. Neue Versionen der Images werden im Rahmen offizieller Produktreleases, Wartungsupdates oder sicherheitsrelevanter Aktualisierungen in der OCI-Registry veröffentlicht.

Kunden werden über neue Releases über die üblichen Kommunikationskanäle (z.B. Release Notes und Kundeninformationen) informiert. Aktualisierte Images können anschließend aus der Registry abgerufen und gemäß den internen Deployment- und Update-Prozessen der jeweiligen Organisation bereitgestellt werden.

Kunden behalten dabei jederzeit die volle Kontrolle darüber, wann Updates in ihren Umgebungen eingespielt werden.

Systemanforderungen​

Client-Anforderungen​

Die Softwareanforderungen für den ADONIS Web-Client bleiben im Vergleich zu früheren ADONIS-Versionen unverändert.

Unterstützte Browser​

Die Verwendung der jeweils aktuellsten Browserversionen wird empfohlen, um vollständige Funktionalität und Sicherheit zu gewährleisten.

Server-Anforderungen​

Container-Runtime​

ADONIS 19 unterstützt OCI-konforme Container-Runtimes auf AMD64- (x86_64-)Architektur. Folgende Plattformen werden unterstützt bzw. sind voraussichtlich kompatibel:

Die BOC Group betreibt ADONIS in der eigenen SaaS-Umgebung auf Basis von Kubernetes und nutzt Docker sowie Docker Compose für die interne Entwicklung, Tests und Validierung. Diese Umgebungen sind daher vollständig validiert.

Plattformen, die als "voraussichtlich kompatibel" eingestuft sind, werden nicht einzeln getestet oder validiert, sollten aber ordnungsgemäß funktionieren, sofern sie den jeweiligen Kubernetes- und OCI-Standards entsprechen.

Betriebssystem​

ADONIS 19 kann auf modernen Linux-Distributionen betrieben werden, die Kubernetes oder Docker/containerd unterstützen, beispielsweise:

• Ubuntu

• Debian

• Red Hat Enterprise Linux (RHEL)

• SUSE Linux Enterprise Server (SLES)

Grundsätzlich wird jede moderne Linux-Distribution unterstützt, die die jeweilige Container-Runtime ausführen kann.

Kubernetes und Deployment-Tooling​

ADONIS-19-Deployments werden typischerweise mithilfe von Kubernetes und Helm durchgeführt.

Datenbank​

ADONIS benötigt eine externe Datenbank zur Speicherung sämtlicher persistenter Repository-Daten. Die Datenbankanforderungen bleiben im Vergleich zu früheren ADONIS-Versionen unverändert. Die von ADONIS 17 unterstützten Datenbanken können als Referenz dienen.

Persistenter Speicher​

Persistenter Speicher wird für den Volltext-Suchindex sowie für die Logdateien der Anwendung benötigt. Die Bereitstellung des Speichers erfolgt in der Regel über Kubernetes Persistent Volumes (PV) und Persistent Volume Claims (PVC), die über das bereitgestellte Helm-Chart konfiguriert werden.

Netzwerk​

Container-Images werden über eine OCI-konforme Registry bereitgestellt und über HTTPS abgerufen.

Typische Netzwerkanforderungen sind:

ADONIS wird typischerweise über einen Kubernetes Ingress-Controller, einen Gateway-API-Controller oder einen externen Reverse Proxy exponiert.

Der ADONIS Web-Server-Container stellt Port 8080 bereit und terminiert keine HTTPS-Verbindungen selbst.

Für verschlüsselten Zugriff (HTTPS) muss die TLS-Terminierung daher durch die Ingress-/Gateway-Komponente in Kubernetes oder durch einen Reverse Proxy in Docker-Compose-Deployments erfolgen.

Hardware-Anforderungen​

Allgemeine Grundsätze​

Die Hardware-Anforderungen für ADONIS 19 im Container-Betrieb sind weitgehend vergleichbar mit früheren Windows-basierten Deployments. Die Hardware-Sizing-Empfehlungen aus ADONIS 17 können als Ausgangsbasis verwendet werden.

Typische Ressourcenanforderungen​

Die folgenden Werte stellen typische Anforderungen an CPU und Speicher für die einzelnen ADONIS-Container dar.

Der tatsächliche Ressourcenbedarf hängt unter anderem ab von:

• Anzahl gleichzeitiger Benutzer

• Größe und Komplexität des Repositorys

• Modellierungs- und Reporting-Aktivität

• Anwendungsspezifischen Workload-Mustern

Beispielhafte Ressourcen-Konfiguration​

Die folgenden Werte zeigen, wie typische ADONIS-Sizing-Empfehlungen auf Kubernetes-Ressourceneinstellungen abgebildet werden können. Sie basieren auf den empfohlenen Werten und sollten an die tatsächliche Last angepasst werden.

Web-Server-Container​

Applikations-Server-Container​

Deployment-Konfiguration und Setup​

Konfigurationsansatz​

Die Konfiguration von ADONIS 19 kombiniert zwei komplementäre Mechanismen.

In der Anwendung gespeicherte Einstellungen und Konfiguration​

Diese Einstellungen werden entweder individuell durch Benutzer oder zentral über die ADONIS Administration verwaltet. Sie werden in der ADONIS-Datenbank gespeichert.

Beispiele sind:

• Authentifizierungskonfiguration

• Rechteverwaltung

• REST-API-Einstellungen

• Anwendungsspezifische Präferenzen

Aus der Umgebung gelesene Einstellungen und Konfiguration​

Diese Einstellungen werden von der Anwendung aus der Runtime gelesen.

In früheren ADONIS-Versionen wurden solche Einstellungen in .properties- oder .conf-Dateien innerhalb des Applikations-Servers (z.B. server.conf) oder der Web-Applikation (z.B. adoxx_web.properties) gepflegt.

Mit ADONIS 19 wird die Anwendung als Container-Images für den Applikations-Server und den Web-Server ausgeliefert. Da Container grundsätzlich flüchtig (ephemer) sind, wird dateibasierte Konfiguration nicht mehr unterstützt.

Stattdessen erfolgt die Übergabe sämtlicher deployment-spezifischer Konfigurationen nun über Umgebungsvariablen:

• Kubernetes: Die Variablen werden in der Datei values.yaml definiert und beim Deployment des Helm-Charts an die Container übergeben.

• Docker: Die Variablen werden in der Datei docker-compose.yml definiert und beim Start der Container gesetzt.

Konfiguration des Applikations-Servers​

Konfigurationsparameter des Applikations-Servers werden als Umgebungsvariablen bereitgestellt, entweder über:

• die Helm-values.yaml-Datei (Kubernetes-Deployments), oder

• die docker-compose.yml-Datei (Docker-Deployments)

Alle Variablen des Applikations-Servers sind mit dem Präfix ADOXX_ versehen.

Die folgenden Beispiele zeigen, wie der Datenbankname und die Ports der Applikations-Worker konfiguriert werden.

Kubernetes:

axx:
  aserver:
    env:
      - name: ADOXX_SERVER_DBNAME
        value: adonis19
      - name: ADOXX_SERVER_PORTS
        value: 5432,5432
  ...

Docker:

...
  aserver:
    image: adonis.image/aserver
    container_name: aserver
    ...
    environment:
      - ADOXX_SERVER_DBNAME=adonisdb
      - ADOXX_SERVER_PORTS=54321,54322
      ...

Konfiguration des Web-Servers​

Auch die Konfigurationsparameter des Web-Servers werden über Umgebungsvariablen in der values.yaml-Datei (Kubernetes) bzw. in der docker-compose.yml-Datei (Docker) definiert.

Web-Server-Variablen sind mit dem Präfix AXW_PROPERTIES_ versehen.

Die folgenden Beispiele zeigen, wie der verwendete Applikations-Server und die aworker-Prozesse konfiguriert sind und wie die maximale Größe für REST-Protokolldateien auf 300 MB erhöht wird.

Kubernetes:

axx:
  ...
  webserver:
    env:
      - name: AXW_PROPERTIES_aservers
        value: AS1:adonis.host
      - name: AXW_PROPERTIES_aworkers
        value: AS1:54321,AS1:54322
      - name: AXW_PROPERTIES_axw_logger_appender_rest_maxfilesize
        value: 300MB
...

Docker:

...
  webserver:
    image: adonis.image/webserver
    container_name: webserver
    ...
    environment:
      - AXW_PROPERTIES_aservers=AS1:adonis.host
      - AXW_PROPERTIES_aworkers=AS1:54321,AS1:54322
      - AXW_PROPERTIES_axw_logger_appender_rest_maxfilesize=300MB
      ...

Eine detaillierte Dokumentation aller verfügbaren Konfigurationsparameter wird mit der offiziellen Dokumentation zu ADONIS 19 bereitgestellt.

Kubernetes-Konfigurationsbeispiel​

Das folgende values.yaml-Beispiel zeigt eine minimale Konfiguration für das Deployment von ADONIS mit:

• einer Applikations-Server-Instanz

• mehreren Worker-Prozessen

• Datenbank-Verbindungseinstellungen

• Logging-Konfiguration

• Laufzeitparametern

Die Konfiguration definiert die Umgebungsvariablen sowohl für den Applikations-Server (aserver) als auch für den Web-Server (webserver) sowie Ressourceneinstellungen und optionale Features. Sie dient als Input für das Kubernetes-Deployment mittels Helm.

axx:
  aserver:
    env:
    - name: ADOXX_SERVER_DBNAME
      value: adonis19
    - name: ADOXX_SERVER_DBTYPE
      value: PostgreSQL
    - name: ADOXX_SERVER_DBPORT
      value: 5432
    - name: ADOXX_SERVER_DBHOST
      value: postgres.company.com
    - name: ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS
      value: 127.0.0.*
    - name: ADOXX_LOG_MODE
      value: MIXED
    resources:
      limits:
        memory: 4096Mi
      requests:
        cpu: 500m
        memory: 2048Mi
    workerConf:
      count: 2
  instance:
    name: adonis19
  webserver:
    env:
    - name: AXW_PROPERTIES_mail_enabled
      value: 'true'
    - name: AXW_PROPERTIES_mail_server
      value: smtp.company.com 
    - name: AXW_PROPERTIES_mail_server_port
      value: '25'
    - name: AXW_PROPERTIES_mail_sender
      value: ADONIS <no-reply@company.com>
    - name: AXW_PROPERTIES_mail_reply_to
      value: no-reply@company.com
    - name: JAVA_OPTS
      value: -Xms512m -Xmx2048m
    - name: AXW_PROPERTIES_base_url
      value: https://adonis19.company.com
    - name: AXW_PROPERTIES_lifecycleops_endpoint_enable
      value: 'true'
    - name: AXW_PROPERTIES_axw_logger_console_enabled
      value: 'true'
    - name: AXW_PROPERTIES_axw_logger_root_level
      value: INFO
    httpRoute:
      hostnames:
      - adonis19.company.com
    resources:
      limits:
        memory: 4096Mi
      requests:
        cpu: 100m
        memory: 2048Mi

Docker-Compose-Konfigurationsbeispiel​

Dieses Docker-Compose-Setup zeigt ein ADONIS-Deployment mit:

• einer Applikations-Server-Instanz

• zwei Worker-Ports

• externer Datenbankanbindung

• lokalem, volumenbasiertem Logging

• gemeinsamem Bridge-Netzwerk

services:
 aserver:
    image: <boc-registry>/adonis/aserver:19.0.0
    container_name: aserver
    user: root
    ports:
      - 54321:54321
      - 54322:54322
    environment:
      - ADOXX_SERVER_PORTS=40180
      - ADOXX_SERVER_DBNAME=<adbname>
      - ADOXX_SERVER_DBTYPE=<PostgreSQL/SQLServer>
      - ADOXX_SERVER_DBHOST=<hostname/IPaddress>
#      - ADOXX_SERVER_DBPORT=5432 (for PostgreSQL)
      - ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS=*.*.*.*
      - ADOXX_LOG_MODE=MIXED
      - TZ=Europe/Vienna
    volumes:
      - ./logs/aserver:/aserver/logs
    shm_size: "300mb"
    networks:
      aserver_webserver:

 webserver:
    image: <boc-registry>/adonis/webserver:19.0.0
    container_name: webserver
    user: root
    ports:
      - 8888:8080
    environment:
      - JAVA_OPTS=-Xms512m -Xmx2048m -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000
      - AXW_PROPERTIES_aworkers=AS1:54321,AS1:54322
      - AXW_PROPERTIES_aservers=AS1:aserver
      - AXW_PROPERTIES_axw_logger_console_enabled=true
      - AXW_PROPERTIES_axw_webserver_debug_enabled=false
      - AXW_PROPERTIES_axw_logger_root_level=INFO
      - AXW_PROPERTIES_base_url=https://adonis19.company.com
      - AXW_PROPERTIES_lifecycleops_endpoint_enable=true
      - AXW_PROPERTIES_mail_enabled=true
      - AXW_PROPERTIES_mail_server=smtp.company.com
      - AXW_PROPERTIES_mail_server_port=25
      - AXW_PROPERTIES_mail_sender=ADONIS <no-reply@company.com>
      - AXW_PROPERTIES_mail_reply_to=no-reply@company.com
      - TZ=Europe/Vienna
    volumes:
      - ./logs/webserver:/tomcat/logs
    networks:
      aserver_webserver

networks:
  aserver_webserver:
    driver: bridge
    enable_ipv6: true

Authentifizierung und Identitätsintegration​

Authentifizierung in ADONIS erfolgt auf Ebene der Web-Applikation und ist unabhängig vom zugrunde liegenden Betriebssystem. Die Web-Applikation unterstützt seit jeher den Betrieb auf unterschiedlichen Plattformen, darunter Linux, Solaris und Windows.

LDAP- und SAML-Authentifizierung​

LDAP- und SAML-Authentifizierung sind von der Migration auf ein Linux-basiertes, containerisiertes Deployment nicht betroffen.

Die Kommunikation mit Identitäts- und Verzeichnisdiensten erfolgt über standardisierte Netzwerkprotokolle (LDAP, HTTP, HTTPS), die betriebssystemunabhängig sind.

Bestehende LDAP- oder SAML-Konfigurationen können daher ohne betriebssystemspezifische Anpassungen weiterverwendet werden.

Auswirkungen auf die Konfiguration​

Da die Authentifizierung in der Web-Applikation implementiert ist und auf betriebssystemunabhängiger Kommunikation basiert, ergeben sich durch den Wechsel auf ein containerisiertes Deployment keine funktionalen Änderungen für unterstützte Authentifizierungsmechanismen.

Lediglich umgebungsspezifische Anpassungen (z.B. Hostnamen oder Netzwerkeinstellungen) können erforderlich sein.

Upgrade von ADONIS 16.x/17.x auf ADONIS 19​

Dieser Guide bietet einen Überblick über das Upgrade von ADONIS 16.x/17.x auf ADONIS 19.

Er beschreibt die zentralen Konzepte, die wichtigsten architektonischen Änderungen sowie die grundlegenden Schritte des Upgrade-Prozesses.

Wichtige konzeptionelle Änderungen in ADONIS 19​

Mit ADONIS 19 erfolgt ein grundlegender technischer Wandel: Der ADONIS Applikations-Server läuft nicht mehr unter Windows, sondern ist jetzt ein Linux-basierter, OCI-konformer Container.

In diesem Guide skizzierter Migrationsansatz​

Die folgende Liste fasst den gesamten Migrationsablauf zusammen, der in diesem Leitfaden (unter Upgrade-Prozess) beschrieben wird:

1. Komponenteneinstellungen exportieren, alte ADONIS 16.x/17.x Dienste stoppen und deployment-spezifische Konfigurationswerte sichern.

2. Bestehende Datenbank weiterverwenden und nach Erstellung eines Backups ein In-Place-Schema-Upgrade durchführen.

3. ADONIS 19 mittels Kubernetes (Helm) oder Docker Compose bereitstellen und alle Werte auf Deployment-Ebene als Umgebungsvariablen konfigurieren (basierend auf den zuvor gesicherten Werten).

4. Aufgaben nach der Installation innerhalb der Applikation durchführen (Bibliothek aktualisieren, Einstellungen migrieren, Skripte ausführen).

Die Schritte 1, 2 und 4 folgen dabei weitgehend dem bekannten Muster früherer ADONIS-Upgrade-Anleitungen. Schritt 3 führt das neue containerbasierte Deployment-Modell ein, das die bisherige Windows-basierte Installation und Konfiguration ersetzt.

Voraussetzungen​

Bevor Sie mit dem Upgrade beginnen, müssen folgende Voraussetzungen erfüllt sein.

System- und Umgebungsanforderungen:

• Eine unterstützte Runtime ist verfügbar (Kubernetes oder Docker Compose).

• Ausreichende Ressourcen für beide ADONIS-Container (CPU, Arbeitsspeicher, Speicherplatz) sind vorhanden.

• Weitere Details sind im Abschnitt Systemanforderungen beschrieben.

Datenbank- und Backup-Anforderungen:

• Die bestehende ADONIS-Datenbank (SQL Server oder PostgreSQL) ist aus der Zielumgebung erreichbar.

• Vor Beginn des Upgrades wurde ein vollständiges Datenbank-Backup erstellt.

Zugriff und Berechtigungen:

• Administrativer Zugriff auf die bestehende ADONIS 16.x/17.x-Umgebung.

• Deployment-Zugangsdaten für Kubernetes oder Docker Compose.

• Datenbank-Zugangsdaten mit ausreichenden Berechtigungen, um eine Verbindung zur ADONIS-Datenbank herzustellen und das ADONIS 19-Schema-Upgrade-Skript auszuführen.

• Container-Registry-Zugangsdaten zur Authentifizierung an der BOC-Container-Registry und optional an der Registry Ihrer Organisation.

Container-Images und Installationspaket:

Aus der BOC-Container-Registry:

• OCI-Container-Images für:

  • Applikations-Server

  • Web-Server

• Deployment-Manifeste:

  • values.yaml (Kubernetes)

  • docker-compose.yml (Docker)

Aus dem Installationspaket (Download):

• Bibliotheksdatei (wenn Sie die ADONIS BPMS-Anwendungsbibliothek verwenden)

• Datenbank-Upgrade-Skript

• Migrationsskript (bei einem Upgrade von ADONIS 16.x)

Anwendungsbibliothek für ADONIS 19:

• Bei Verwendung der Standardbibliothek (ADONIS BPMS-Anwendungsbibliothek) kann das Upgrade direkt durchgeführt werden.

• Wenden Sie sich an Ihren ADONIS-Kundenbetreuer, wenn Sie eine andere Anwendungsbibliothek verwenden.

Upgrade-Prozess​

Die folgenden Abschnitte beschreiben die wichtigsten Migrationsschritte in der Reihenfolge ihrer Durchführung. Sie bieten einen Überblick über die erforderlichen Tätigkeiten, vom Abschalten der bestehenden Umgebung zum Deployment von ADONIS 19 und den abschließenden Aufgaben innerhalb der Anwendung.

Komponenteneinstellungen exportieren​

Zunächst müssen die Komponenteneinstellungen aus der bestehenden ADONIS 16.x/17.x-Umgebung exportiert werden:

• Exportieren Sie die Komponenteneinstellungen, damit diese nach der Aktualisierung der Anwendungsbibliothek wieder importiert werden können.

• Exportieren Sie alle Einstellungen auf einmal oder alternativ die gewünschten Einstellungen.

Dienste stoppen​

Nach dem Export der Einstellungen kann die bestehende ADONIS 16.x/17.x-Umgebung gestoppt werden:

• Stoppen Sie den ADONIS Applikations-Server-Service auf dem Host-System.

• Stoppen Sie den Apache Tomcat-Service, der die bestehende ADONIS-Web-Applikation bereitstellt.

• Falls ein Monitoring-System im Einsatz ist, sollte dieses temporär deaktiviert werden.

Deployment-spezifische Daten sichern​

Sichern Sie anschließend deployment-spezifische Daten aus der bestehenden ADONIS 16.x/17.x-Umgebung. Diese Informationen werden später für die Konfiguration von ADONIS 19 benötigt.

• Sichern Sie Konfigurationsdateien, die umgebungsspezifische Werte enthalten (z. B. Datenbankname, Ports, Host-/IP-Einstellungen, angepasste Parameter), wie beispielsweise server.conf und adoxx_web.properties.

• Halten Sie alle gesicherten Dateien griffbereit, damit Sie die relevanten Werte in die Umgebungsvariablen von ADONIS 19 übertragen können.

Datenbankschema aktualisieren​

Aktualisieren Sie die bestehende ADONIS-Datenbank auf das ADONIS 19-Schema:

• Erstellen Sie jetzt ein Datenbank-Backup, falls Sie dies noch nicht getan haben.

• Führen Sie das ADONIS 19-Datenbank-Upgrade-Skript für Ihr Datenbanksystem (SQL Server oder PostgreSQL) aus.

Runtime vorbereiten​

Befolgen Sie die untenstehenden Schritte für Ihre Ziel-Orchestrierungsplattform:

Kubernetes-Deployment​

Bereiten Sie die Kubernetes-Umgebung vor:

• Erstellen oder wählen Sie einen Namespace für ADONIS aus.

• Stellen Sie sicher, dass die erforderlichen StorageClasses für persistente Volumes verfügbar sind.

• Stellen Sie sicher, dass ein Ingress-Controller oder ein Gateway-API-Controller verfügbar ist. Das Helm-Chart unterstützt sowohl Ingress als auch HTTPRoute.

Docker-Compose-Deployment​

Bereiten Sie die Docker-Umgebung vor:

• Stellen Sie sicher, dass eine Container-Runtime verfügbar ist (z. B. Docker, containerd, Podman)

• Bereiten Sie die Docker-Volumes für Logs und den Suchindex vor.

• Stellen Sie sicher, dass ein Reverse-Proxy für die HTTPS-Terminierung verfügbar ist.

Konfiguration vorbereiten (values.yaml oder docker-compose.yml)​

Bereiten Sie die Konfiguration der Umgebungsvariablen vor:

• Fügen Sie die Datenbank-Verbindungseinstellungen hinzu.

• Konfigurieren Sie Worker-Ports, Trusted Hosts und umgebungsspezifischen Parameter. Übertragen Sie dazu die relevanten Werte aus Ihren Backup-Konfigurationsdateien (z. B. server.conf und adoxx_web.properties).

• Für Kubernetes: Tragen Sie die Werte in die values.yaml ein.

• Für Docker: Tragen Sie die Werte in die docker-compose.yml ein.

ADONIS 19 bereitstellen​

Befolgen Sie die untenstehenden Schritte für Ihre Ziel-Orchestrierungsplattform:

Kubernetes​

Stellen Sie ADONIS 19 in Ihrer Kubernetes-Umgebung unter Verwendung des bereitgestellten Helm-Charts und der OCI-Container-Images bereit:

• Stellen Sie sicher, dass die finale Datei values.yaml für das Deployment bereitsteht.

• Führen Sie den Befehl helm install aus, um das Chart in Ihrem vorgesehenen Namespace bereitzustellen.

• Das Chart installiert den Applikations-Server-Container und den Web-Server-Container zusammen mit allen erforderlichen Kubernetes-Ressourcen (Services, Ingress usw.).

Docker Compose​

Stellen Sie ADONIS 19 in Ihrer Docker-Umgebung unter Verwendung der bereitgestellten Docker-Compose-Konfiguration bereit:

• Stellen Sie sicher, dass die finale Datei docker-compose.yml in Ihrem Arbeitsverzeichnis bereitsteht.

• Führen Sie docker-compose up -d aus, um die OCI-Images zu laden und die Dienste zu initialisieren.

Deployment verifizieren​

Überprüfen Sie nach dem Deployment von ADONIS 19, ob die Umgebung ordnungsgemäß läuft:

• Stellen Sie sicher, dass alle Container (Kubernetes-Pods oder Docker-Services) erfolgreich gestartet wurden.

• Rufen Sie die ADONIS-URL auf, um zu bestätigen, dass die Anwendung erreichbar ist.

• Überprüfen Sie die Logs über die persistenten Volumes oder die Container-Logs.

Aufgaben nach der Installation​

Sobald ADONIS 19 läuft, führen Sie die verbleibenden Aufgaben in der ADONIS 19 Administration durch:

• Aktualisieren Sie die Anwendungsbibliothek.

• Importieren Sie die Komponenteneinstellungen zurück, die Sie aus Ihrer alten ADONIS 16.x/17.x-Umgebung exportiert haben.

• Wenn Sie ein Upgrade von ADONIS 16.x durchführen, führen Sie das Migrationsskript 17.0 - repo.js aus, um die Repository-Inhalte an die neue Methode anzupassen.

Abschließende Prüfungen​

Führen Sie letzte Prüfungen durch, um sicherzustellen, dass ADONIS 19 voll einsatzbereit ist:

• Verifizieren Sie, dass Benutzer wie erwartet auf ADONIS zugreifen können.

• Bestätigen Sie, dass die Repository-Inhalte verfügbar sind und korrekt angezeigt werden.

• Führen Sie Standardoperationen in ADONIS aus (z. B. Modellierung, Reporting, Suche), um die Basisfunktionalität zu validieren.

• Optional: Integrieren Sie das Deployment in Ihre Monitoring-Lösung.

ADONIS 16.x/17.x deinstallieren​

Da ADONIS 19 nun voll einsatzbereit ist, kann die alte ADONIS 16.x/17.x-Umgebung entfernt werden:

• Deinstallieren Sie den ADONIS über die Systemsteuerung Applikations-Server über die Systemsteuerung.

• Entfernen Sie die ADONIS 16.x/17.x Webapplikation aus Apache Tomcat.

Fertig! Das Upgrade auf ADONIS 19 ist nun abgeschlossen.

Sicherheit​

Rechte und Berechtigungen​

Die ADONIS-Container-Images benötigen keine Root-Privilegien.

Alle Prozesse innerhalb der Container laufen unter einem vordefinierten Non-Root-Benutzer (ADO).

Es sind keine zusätzlichen Berechtigungen auf Host-Ebene oder erweiterten Kubernetes-Privilegien erforderlich.

Minimal-Image-Prinzip​

ADONIS-Container-Images folgen dem Distroless-Ansatz.

Nicht benötigte Betriebssystem-Komponenten und Hilfsprogramme wurden entfernt, was die Angriffsfläche reduziert und das Prinzip der Minimalität konsequent umsetzt.

Cluster-Ressourcen​

Das ADONIS-Deployment benötigt keine privilegierten Container oder globalen Kubernetes-Ressourcen. Insbesondere werden folgende Komponenten nicht benötigt:

• kein privilegierter Modus (privileged mode)

• keine NodePorts

• keine Kubernetes-Operatoren

• keine clusterweiten Zugriffsrechte

Dadurch ist der Betrieb auch in restriktiven Enterprise-Clustern mit strengen Sicherheitsrichtlinien möglich.

Namespaces und Ressourcen-Isolierung​

Alle erforderlichen Kubernetes-Ressourcen können vollständig innerhalb eines einzelnen Namespaces bereitgestellt und betrieben werden.

Dies unterstützt eine saubere Namespace-basierte Isolation sowie die Umsetzung von rollenbasierter Zugriffskontrolle (RBAC) und organisationsspezifischen Sicherheitskonzepten.

Speicherberechtigungen​

Persistenter Speicher wird nur für spezifische Komponenten benötigt, wie den Volltext-Suchindex und die Applikations-Logs.

Die erforderlichen Persistent Volumes (PV) und Persistent Volume Claims (PVC) werden über das Helm-Chart definiert und erfordern keine erweiterten Cluster-Berechtigungen.

Der Zugriff ist auf den Applikations-Server-Container und den Web-Server-Container beschränkt.

Betrieb​

Skalierung​

Horizontal Pod Autoscaling (HPA) wird in ADONIS 19 nicht unterstützt.

Die Skalierung erfolgt daher primär durch vertikale Skalierung, indem zugewiesenen CPU- und Speicher-Ressourcen für die Anwendungscontainer angepasst werden.

Die mitgelieferten Helm-Charts unterstützen die Bereitstellung mehrerer Applikations-Server-Instanzen. Wie bei früheren ADONIS-Versionen wird der Betrieb von zwei oder mehr Applikations-Servern für Hochverfügbarkeit unterstützt und empfohlen.

Die Ressourcenzuweisung sollte wie folgt dimensioniert werden:

• erwartete Arbeitslast (Workload)

• Anzahl gleichzeitiger Benutzer

• Gesamtlast des Systems

Logging und Monitoring​

Logging​

Sowohl der Web-Server-Container als auch der Applikations-Server-Container erzeugen Logeinträge zu Systemereignissen und Fehlern.

Um innerhalb von ADONIS ein Support Information Package (SIP) erstellen zu können, werden Logdateien auf persistenten Speicher geschrieben. Für diese Logs ist ein dediziertes persistentes Volume erforderlich.

Das SIP wird für Support und Fehlersuche benötigt.

Zusätzlich zum dateibasierten Logging gibt ADONIS Logeinträge auch über die standardmäßigen Container-Logging-Streams (stdout/stderr) aus.

Dadurch ist eine Integration in externe Logging-Lösungen wie zentrale Log-Collector-Systeme, SIEM-Plattformen oder Data Lakes möglich.

Aufbewahrung und Speicherung von Logs​

Log-Dateien werden auf dem konfigurierten persistenten Volume gespeichert.

Aufbewahrungsdauer, Rotation und Roll-Over-Verhalten können über die Logging-Konfiguration gesteuert werden.

Die effektive Aufbewahrungsfrist hängt ab von:

• der Logging-Konfiguration

• der Kundeninfrastruktur

• den betrieblichen Richtlinien der Organisation

Log-Level​

ADONIS verwendet die folgenden Log-Level:

Die Log-Level verhalten sich genauso wie in früheren Windows-basierten Versionen von ADONIS (ADONIS 17 und älter).

Log-Konfiguration​

Das Logging-Verhalten kann über Umgebungsvariablen konfiguriert werden, die über folgende Dateien bereitgestellt werden:

• values.yaml (Kubernetes)

• docker-compose.yml (Docker)

Zu den konfigurierbaren Parametern gehören:

• Log-Level

• maximale Dateigröße

• maximale Anzahl historischer Logdateien

• Gesamtgröße der Logs

Details zu den verfügbaren Parametern sind im Konfigurationsabschnitt beschrieben.

Datenschutz in Logdateien​

Sensible Werte und personenbezogene Daten, die in Logdateien geschrieben werden, werden nach Möglichkeit pseudonymisiert.

Dieses Verhalten ist konsistent mit früheren ADONIS-Versionen.

Log-Ausgabeformat​

Die grundlegende Struktur der Logausgaben bleibt weitgehend konsistent mit früheren Releases.

Einige Anpassungen wurden vorgenommen, um die Konsistenz über unterschiedliche Logtypen hinweg zu verbessert.

Ein detailliertes Schema wird in der offiziellen ADONIS 19-Dokumentation enthalten sein.

Monitoring​

Monitoring von Logs​

ADONIS stellt keinen integrierten Logging- oder Monitoring-Stack bereit.

Kunden integrieren ADONIS daher in ihre bestehende Observability- oder Monitoring-Infrastruktur.

ADONIS unterstützt dies durch:

• Ausgabe von Logs über standardisierte Container-Logging-Mechanismen (stdout/stderr)

• Kompatibilität mit gängigen Log-Collection-Agents (z.B. Fluent Bit)

• Weiterleitung von Logs an Systeme wie OpenSearch, Elasticsearch oder vergleichbare Plattformen

In Kubernetes-Umgebungen werden Container-Logs typischerweise temporär auf den Nodes gespeichert und anschließend von einem Log-Prozessor erfasst und an ein zentrales Log-System weitergeleitet.

Metriken und Betriebsmonitoring können in bestehende Tools wie Prometheus, Grafana oder andere Enterprise-Monitoring-Plattformen integriert werden.

Monitoring-Mechanismen​

ADONIS bietet integrierte Monitoring-Mechanismen für Health-Checks auf Plattformebene.

Die ausgelieferten Container-Images enthalten Funktionalität, die für Kubernetes Liveness- und Readiness-Probes verwendet werden.

Weitere detaillierte Informationen werden in der offiziellen ADONIS 19-Dokumentation enthalten sein.

Lizenzierung​

Bestehende ADONIS-Lizenzen bleiben für alle aktuellen Nutzungsszenarien gültig.

Das jeweilige Deployment-Modell – ob Windows-basiert oder containerisiert – hat keinen Einfluss auf die geltenden Lizenzbedingungen.

Support & Lifecycle​

Die Einführung des containerbasierten Deployment-Modells ändert nichts an den bestehenden Support- oder Produkt-Lifecycle-Richtlinien von ADONIS.

Alle Supportbedingungen, Wartungsservices und Lifecycle-Regeln gelten weiterhin so, wie sie für frühere ADONIS-Versionen gültig waren.