Technische Produktinformation - ADOIT 21

Übersicht​

Mit ADOIT 21 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 ADOIT effizient in aktuellen und zukünftigen IT-Umgebungen betrieben werden, während die vertrauten funktionalen Eigenschaften früherer Versionen erhalten bleiben.

Architektur​

Mit ADOIT 21 wird die Anwendung als Set von OCI-konformen Container-Images ausgeliefert. Dieser Ansatz bewahrt die funktionale Architektur früherer ADOIT-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.

ADOIT 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 ADOIT-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 ADOIT 21 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 ADOIT 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​

ADOIT-Namespace​

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

• HttpRoute / Ingress, das als Einstiegspunkt für externen Traffic in den ADOIT-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 ADOIT-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 den Pod neu zu erstellen angepasst werden.

• Jedes Deployment wird mit einer einzelnen Replik betrieben; ADOIT 21 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​

ADOIT verwendet eine externe PostgreSQL- oder Microsoft SQL Server-Datenbank, die außerhalb des Kubernetes-Clusters betrieben und unabhängig verwaltet wird.

Docker-Compose-Deployment​

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

In diesem Setup laufen der ADOIT 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​

ADOIT Docker-Compose-Stack​

Der Docker-Compose-Stack besteht aus:

• Reverse Proxy (z.B. nginx), der eingehende HTTP(S)-Anfragen entgegennimmt und an den ADOIT 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​

ADOIT verwendet eine externe PostgreSQL- oder Microsoft SQL Server-Datenbank, die außerhalb des Kubernetes-Clusters betrieben und unabhängig verwaltet wird.

Registry und Updates​

ADOIT 21 wird in einem containerbasierten Format ausgeliefert. Die folgenden Release-Artefakte werden bereitgestellt.

Container-Images​

Die ADOIT-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 ADOIT-Anwendungslogik und Backend-Operationen aus

Helm-Charts​

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

Die Auslieferung umfasst ein Umbrella-Chart, das das vollständige ADOIT-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 ADOIT-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 ADOIT-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 ADOIT Web-Client bleiben im Vergleich zu früheren ADOIT-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​

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

Die BOC Group betreibt ADOIT 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​

ADOIT 21 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​

ADOIT-21-Deployments werden typischerweise mithilfe von Kubernetes und Helm durchgeführt.

Datenbank​

ADOIT benötigt eine externe Datenbank zur Speicherung sämtlicher persistenter Repository-Daten. Die Datenbankanforderungen bleiben im Vergleich zu früheren ADOIT-Versionen unverändert. Die von ADOIT 19 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:

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

Der ADOIT 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 ADOIT 21 im Container-Betrieb sind weitgehend vergleichbar mit früheren Windows-basierten Deployments. Die Hardware-Sizing-Empfehlungen aus ADOIT 19 können als Ausgangsbasis verwendet werden.

Typische Ressourcenanforderungen​

Die folgenden Werte stellen typische Anforderungen an CPU und Speicher für die einzelnen ADOIT-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 ADOIT-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 ADOIT 21 kombiniert zwei komplementäre Mechanismen.

In der Anwendung gespeicherte Einstellungen und Konfiguration​

Diese Einstellungen werden entweder individuell durch Benutzer oder zentral über die ADOIT Administration verwaltet. Sie werden in der ADOIT-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 ADOIT-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 ADOIT 21 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 (aworker) konfiguriert werden.

Kubernetes:

aserver:
  env:
    - name: ADOXX_SERVER_DBNAME
      value: adodb
    - name: ADOXX_SERVER_PORTS
      value: 5432,5432

Docker:

aserver:
  image: adoit.image/aserver
  container_name: aserver
  ...
  environment:
    - ADOXX_SERVER_DBNAME=adodb
    - 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:

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

Docker:

webserver:
  image: adoit.image/webserver
  container_name: webserver
  ...
  environment:
    - AXW_PROPERTIES_aservers=AS1:adoit.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 ADOIT 21 bereitgestellt.

Kubernetes-Konfigurationsbeispiel​

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

• einer Applikations-Server-Instanz

• mehreren aworker-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.

aserver:
  env:
  - name: ADOXX_SERVER_DBNAME
    value: adodb
  - 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: adoit21
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: ADOIT <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://adoit21.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:
    - adoit21.company.com
  resources:
    limits:
      memory: 4096Mi
    requests:
      cpu: 100m
      memory: 2048Mi

Docker-Compose-Konfigurationsbeispiel​

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

• einer Applikations-Server-Instanz

• zwei aworker-Ports

• externer Datenbankanbindung

• lokalem, volumenbasiertem Logging

• gemeinsamem Bridge-Netzwerk

services:
 aserver:
    image: <boc-registry>/adoit/aserver:21.0.0
    container_name: aserver
    user: ado
    ports:
      - 54321:54321
      - 54322:54322
    environment:
      - ADOXX_SERVER_PORTS=54321,54322
      - ADOXX_SERVER_DBNAME=adodb
      - ADOXX_SERVER_DBTYPE=PostgreSQL
      - ADOXX_SERVER_DBHOST=postgres.company.com
#      - ADOXX_SERVER_DBPORT=5432
      - 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>/adoit/webserver:21.0.0
    container_name: webserver
    user: ado
    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://adoit21.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=ADOIT <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 ADOIT 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 ADOIT 17.x/18.x auf ADOIT 21​

Eine Migrationsanleitung, die Sie beim Upgrade von ADOIT von Version 17.0 – 17.7 oder 18.0 – 18.2 auf Version 21.0 in einer Kubernetes-Umgebung unterstützt, wird im ADOIT 21 Installationshandbuch bereitgestellt.

Der Upgrade-Prozess unterscheidet sich erheblich von früheren ADOIT-Versionen. Sowohl der Applikations-Server als auch der Web-Server werden als containerisierte Services bereitgestellt. Zur Vereinfachung des Migrationsprozesses stellt ADOIT 21.0 das Management-Tool aupgrade_product bereit. Dieses Werkzeug aktualisiert eine bestehende Datenbank auf die neue Version und führt automatisch die erforderlichen Migrationsschritte aus, einschließlich der Aktualisierung des Datenbankschemas, des Updates der Anwendungsbibliothek, der Ausführung von Migrationsskripten sowie der Sicherung und Wiederherstellung von Komponenteneinstellungen.

Der Migrationsprozess umfasst folgende grundlegenden Schritte:

1. Stoppen der bestehenden ADOIT-Dienste.

2. Sichern der deploymentspezifischen Konfigurationsdateien.

3. Aktualisieren der Datenbank mithilfe von aupgrade_product.

4. Bereitstellen von ADOIT 21.0 in Kubernetes mithilfe der gesicherten Konfiguration.

5. Überprüfen der Bereitstellung und Entfernen der alten Installation.

Migration von allen übrigen Versionen nach ADOIT 21.0​

ADOIT 20.0 ist ausschließlich für SaaS-Kunden verfügbar, die auf AWS gehostet werden. Da alle Upgrades von 20.0 auf 21.0 vom BOC Cloud Operations Team durchgeführt werden, wird für diese Version kein Migrationsleitfaden bereitgestellt. Wenn Sie ADOIT 16.0 oder eine ältere Version verwenden, wenden Sie sich bitte an Ihren ADOIT-Berater, um Unterstützung bei den erforderlichen Upgrade-Schritten zu erhalten.

Sicherheit​

Rechte und Berechtigungen​

Die ADOIT-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​

ADOIT-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 ADOIT-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 ADOIT 21 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 ADOIT-Versionen wird der Betrieb von zwei oder mehr Applikations-Servern unterstützt und empfohlen, um die Arbeitslast auf mehrere Server zu verteilen.

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 ADOIT 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 ADOIT 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​

ADOIT verwendet die folgenden Log-Level:

Die Log-Level verhalten sich genauso wie in früheren Windows-basierten Versionen von ADOIT.

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 ADOIT-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 ADOIT 21-Dokumentation enthalten sein.

Monitoring​

Monitoring von Logs​

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

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

ADOIT 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​

ADOIT 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 ADOIT 21-Dokumentation enthalten sein.

Lizenzierung​

Bestehende ADOIT-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 ADOIT.

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