Technische Produktinformation - ADOGRC 15

Übersicht​

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

Architektur​

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

ADOGRC 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 ADOGRC-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 ADOGRC 15 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 ADOGRC 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​

ADOGRC-Namespace​

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

• HttpRoute / Ingress, das als Einstiegspunkt für externen Traffic in den ADOGRC-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 ADOGRC-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; ADOGRC 15 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​

ADOGRC 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 ADOGRC 15 auf einem einzelnen Host mithilfe von Docker-Compose-kompatiblen Tools wie Docker oder Podman betrieben werden kann.

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

ADOGRC Docker-Compose-Stack​

Der Docker-Compose-Stack besteht aus:

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

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

Registry und Updates​

ADOGRC 15 wird in einem containerbasierten Format ausgeliefert. Die folgenden Release-Artefakte werden bereitgestellt.

Container-Images​

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

Helm-Charts​

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

Die Auslieferung umfasst ein Umbrella-Chart, das das vollständige ADOGRC-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.

Wie Sie Zugriff auf die BOC OCI Registry erhalten, erfahren Sie unter Zugang Container Registry für containerisierte Deployments.

• 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 ADOGRC-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 ADOGRC-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 ADOGRC Web-Client bleiben im Vergleich zu früheren ADOGRC-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​

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

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

ADOGRC 15 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​

ADOGRC-15-Deployments werden typischerweise mithilfe von Kubernetes und Helm durchgeführt.

Datenbank​

ADOGRC benötigt eine externe Datenbank zur Speicherung sämtlicher persistenter Repository-Daten. Die Datenbankanforderungen bleiben im Vergleich zu früheren ADOGRC-Versionen unverändert. Die Datenbankanforderungen sind in den ADOGRC 15 Hardware-/Software-Anforderungen dokumentiert.

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:

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

Der ADOGRC 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 ADOGRC 15 im Container-Betrieb sind weitgehend vergleichbar mit früheren Windows-basierten Deployments. Die Hardware-/Software-Anforderungen für ADOGRC 15 enthalten allgemeine Empfehlungen zur Hardware-Dimensionierung.

Typische Ressourcenanforderungen​

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

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

• Anzahl gleichzeitiger Benutzer

• Größe und Komplexität des Repositorys

• Freigabeworkflow- und Reporting-Aktivität

• Anwendungsspezifischen Workload-Mustern

Deployment-Konfiguration und Setup​

Konfigurationsansatz​

Die Konfiguration von ADOGRC 15 kombiniert zwei komplementäre Mechanismen.

In der Anwendung gespeicherte Einstellungen und Konfiguration​

Diese Einstellungen werden entweder individuell durch Benutzer oder zentral über die ADOGRC Administration verwaltet. Sie werden in der ADOGRC-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 ADOGRC-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 ADOGRC 15 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.yaml 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.yaml-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: 54321,54322

Docker:

aserver:
  image: ADOGRC.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.yaml-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:ADOGRC.host
    - name: AXW_PROPERTIES_aworkers
      value: AS1:54321,AS1:54322
    - name: AXW_PROPERTIES_axw_logger_appender_rest_maxfilesize
      value: 300MB

Docker:

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

Kubernetes-Konfigurationsbeispiel​

Das Installationshandbuch enthält ein Beispiel für eine values.yaml, welche eine minimale Konfiguration für das Deployment von ADOGRC zeigt: Konfigurationsdatei erstellen. Dieses Beispiel konfiguriert:

• eine Applikations-Server-Instanz

• mehrere aworker-Prozesse

• Datenbank-Verbindungseinstellungen

• Logging-Konfiguration

• Laufzeitparameter

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

Docker-Compose-Konfigurationsbeispiel​

Für ein Docker-Compose-Setup finden Sie ein Beispiel in unserem Github Repository. Dieses zeigt ein ADOGRC-Deployment mit:

• einer Applikations-Server-Instanz

• zwei aworker-Ports

• externer Datenbankanbindung

• lokalem, volumenbasiertem Logging

• gemeinsamem Bridge-Netzwerk

Authentifizierung und Identitätsintegration​

Authentifizierung in ADOGRC 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 ADOGRC 13.x/14.x auf ADOGRC 15​

Das Installationshandbuch enthält eine Migrationsanleitung, die Sie beim Upgrade von ADOGRC von einer älteren Version auf die Version 15.0 unterstützt. Diese Anleitung enthält alle Schritte, die Sie durchführen müssen, und erklärt alles im Detail:

• Upgrade von ADOGRC 13.0 – 13.6 oder 14.0 – 14.4 auf ADOGRC 15.0

Sicherheit​

Rechte und Berechtigungen​

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

ADOGRC-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 ADOGRC-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 ADOGRC 15 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 ADOGRC-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 ADOGRC 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 ADOGRC 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​

ADOGRC verwendet die folgenden Log-Level:

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

Log-Konfiguration​

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

• values.yaml (Kubernetes)

• docker-compose.yaml (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 ADOGRC-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.

Monitoring​

Monitoring von Logs​

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

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

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

ADOGRC 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.

Lizenzierung​

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

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