Plattformbasis konfigurieren

Das Inventory ist die Soll-Konfiguration einer konkreten UDSP-Installation. Es legt Zielcluster, Plattformdomain, gemeinsame Dienste, Mandanten, aktivierte Komponenten, Persistenz und externe Zugänge fest.

Erstellen Sie ein Inventory immer aus der Vorlage des ausgewählten Releases:

cp 02_core_platform/default_inventory.yml \
  inventories/customer-prod.yml

Ein Inventory aus einem anderen Release kann fehlende, umbenannte oder nicht mehr unterstützte Variablen enthalten. Erstellen Sie deshalb kein reduziertes Inventory vollständig von Hand.

Diese Seite führt zunächst durch die Entscheidungen des Standardpfads. Die vollständige Parameterreferenz am Ende bildet zusätzlich alle globalen Felder der releasegebundenen Vorlage ab – einschließlich optionaler und nur aus Kompatibilitätsgründen mitgeführter Werte.

Konfigurationsmodell

Eine Soll-Konfiguration

Drei Ebenen bestimmen die Installation

Werte werden von der Umgebung über die gemeinsame Plattformbasis bis zu den einzelnen Mandanten zunehmend spezifischer.

01

all.vars

Umgebung

Definiert die technische Identität und den Zugriff auf den Zielcluster.

• DOMAIN
• ENVIRONMENT
• kubeconfig_file
• Proxywerte

→

02

controller.vars

Plattformweite Basis

Konfiguriert Infrastrukturbezug und gemeinsam genutzte Plattformdienste.

• inv_k8s
• inv_email & inv_registry
• Operatoren & Security
• Observability & Backup

→

03

inv_tenants[]

Mandanten

Beschreibt Identität, Domain und aktivierte Komponenten jedes Mandanten.

• Realm & Präfix
• Mandantendomain
• Datenpfade
• Anwendungen

Ausgeführt auf localhost: full_install.yml liest die Werte unter controller; der Abschnitt kubernetes gehört ausschließlich zum separaten MicroK8s-Basiscluster.

Wiederkehrende Konventionen

Ein direkt unter einer Komponente stehendes enable ist immer deren Aktivierungsschalter:

• enable: true nimmt die Komponente oder optionale Funktion in den Rollout auf.
• enable: false überspringt sie beim Ausführen des Playbooks.

Beispielsweise stehen apisix, stellio, frost, grafana und pgadmin jeweils für die gleichnamigen UDSP-Komponenten. Ihre enable-Schalter werden deshalb in den folgenden Feldtabellen nicht wiederholt. Wichtig: Das spätere Umschalten auf false deinstalliert eine bereits vorhandene Komponente nicht automatisch.

Davon zu unterscheiden sind fachlich benannte Schalter wie mqtt_enable, ui_enabled, use_quantumleap oder enforce_policies. Sie verändern eine konkrete Funktion und werden deshalb bei der jeweiligen Komponente erläutert.

1. Globale Identität der Umgebung

all:
  vars:
    DOMAIN: "platform.example.org"
    ENVIRONMENT: "prd"
    kubeconfig_file: "customer-prod.conf"

    HTTPS_PROXY: ""
    HTTP_PROXY: ""
    NO_PROXY: ""
    https_proxy: ""
    http_proxy: ""
    no_proxy: ""

Variable	Bedeutung	Änderbarkeit nach Erstinstallation
DOMAIN	zentrale Plattformdomain für gemeinsame Dienste	nur mit Migrationsplanung
ENVIRONMENT	technischer Umgebungspräfix, beispielsweise dev, stg oder prd	nicht nachträglich umbenennen
kubeconfig_file	Datei unter $HOME/.kube/	änderbar, wenn sie auf denselben Zielcluster zeigt
Proxyvariablen	ausgehender HTTP-/HTTPS-Zugriff für Deployment und Komponenten	änderbar; no_proxy sorgfältig pflegen

Verwenden Sie für DOMAIN und Mandantendomains nur Hostnamen, kein https:// und keinen abschließenden Slash.

2. Deployment-Umgebung und Cluster

children:
  controller:
    hosts:
      localhost:
        ansible_host: 127.0.0.1
        ansible_connection: local
        ansible_python_interpreter: "{{ ansible_playbook_python }}"
    vars:
      inv_k8s:
        config:
          context: "customer-prod"
        ingress_class: "public"
        disable_ipv6: false
        storage_class:
          rwo: "fast-rwo"
          rwo_retain: "fast-rwo-retain"
          provisioner: "csi.example.org"
        cert_manager:
          le_email: "platform-operations@example.org"
          staging_issuer_name: "letsencrypt-staging"
          prod_issuer_name: "letsencrypt-production"

Die Namen für Context, IngressClass und StorageClasses müssen exakt mit dem Zielcluster übereinstimmen. Die StorageClasses werden vor dem Rollout automatisch geprüft.

Feld	Bedeutung	Was Sie eintragen
ansible_host	Adresse der Deployment-Umgebung	für den offiziellen lokalen Bereitstellungspfad 127.0.0.1 beibehalten
ansible_connection	Art der Ansible-Verbindung	local, weil das Playbook auf derselben Deployment-Umgebung ausgeführt wird
ansible_python_interpreter	Python-Laufzeit für die Ansible-Module	{{ ansible_playbook_python }} verwendet dieselbe Python-Umgebung wie das gestartete Playbook
inv_k8s.config.context	Kubeconfig-Context des Zielclusters	exakt den mit kubectl config get-contexts geprüften Context
inv_k8s.ingress_class	bereits vorhandene IngressClass für alle öffentlichen UDSP-Endpunkte	beispielsweise public oder nginx
inv_k8s.disable_ipv6	deaktiviert IPv6 in den dafür vorgesehenen APISIX-, Loki- und pgAdmin-Einstellungen	nur auf true setzen, wenn der Zielcluster beziehungsweise das Netzwerk kein IPv6 unterstützt
inv_k8s.storage_class.rwo	StorageClass für reguläre ReadWriteOnce-Volumes	den exakten Namen einer vorhandenen StorageClass
inv_k8s.storage_class.rwo_retain	StorageClass für persistente Daten, die beim Löschen des Claims erhalten bleiben sollen	eine vorhandene StorageClass mit passender Retain-Strategie; in einer Sandbox kann sie mit rwo identisch sein
inv_k8s.storage_class.provisioner	dokumentierter technischer CSI- beziehungsweise Storage-Provisioner	den Provisioner der ausgewählten StorageClass eintragen, beispielsweise ebs.csi.aws.com; der aktuelle Rollout wählt seine Volumes über die beiden StorageClass-Namen aus

Zertifikatsausstellung konfigurieren

Der standardmäßige Bereitstellungspfad installiert cert-manager und erzeugt einen Staging- sowie einen Produktions-Issuer für Let's Encrypt. Die Namen und die Kontaktadresse werden im Clusterabschnitt des Inventory festgelegt:

inv_k8s:
  ingress_class: "public"
  cert_manager:
    le_email: "platform-operations@example.org"
    staging_issuer_name: "letsencrypt-staging"
    prod_issuer_name: "letsencrypt-production"

Die konfigurierte IngressClass muss Port 80 für die ACME-HTTP-01-Challenge und Port 443 für die späteren HTTPS-Zugriffe erreichen. Die unter Voraussetzungen prüfen festgelegten Domains müssen bereits auf diesen Ingress-Endpunkt zeigen.

Prüfen Sie die Zertifikatsausstellung zunächst über den Staging-Issuer. Verwenden Sie den Produktions-Issuer erst, nachdem DNS, Ingress und die Challenge erfolgreich verifiziert wurden.

Feld	Bedeutung
le_email	Kontaktadresse für das Let's-Encrypt-Konto und wichtige Zertifikatsmeldungen
staging_issuer_name	Name des ClusterIssuers für Tests ohne produktive Rate Limits
prod_issuer_name	Name des ClusterIssuers, den die öffentlichen UDSP-Ingresses für gültige Zertifikate referenzieren

3. Mail und Registries

SMTP-Konfiguration

inv_email beschreibt das zentrale SMTP-Konto, über das Keycloak und aktivierte Anwendungen beispielsweise Einladungen, Passwort-Resets, Benachrichtigungen oder Alarmmeldungen versenden.

inv_email:
  server: "smtp.example.org"
  port: "587"
  user: "udsp-mailer"
  password: "<secret>"
  email_from: "no-reply@example.org"

Feld	Bedeutung	Was Sie eintragen
server	Hostname des SMTP-Servers	nur den DNS-Namen, beispielsweise smtp.example.org, ohne https://
port	Netzwerkport des SMTP-Dienstes	üblicherweise 587 für authentifiziertes SMTP mit STARTTLS
user	technischer SMTP-Benutzer	das eigens für die UDSP angelegte Versandkonto
password	Passwort dieses Benutzers	das zugehörige Secret; verschlüsselt übergeben und nicht offen committen
email_from	sichtbare Absenderadresse	eine vom SMTP-Server für dieses Konto erlaubte Adresse, beispielsweise no-reply@example.org

Der aktuelle Standardpfad erwartet SMTP-Authentifizierung und STARTTLS. Lassen Sie deshalb vorab prüfen, dass Konto, Port und Absenderadresse in dieser Kombination zugelassen sind.

Ein tatsächlich erreichbarer SMTP-Dienst ist nur erforderlich, wenn Keycloak oder eine aktivierte Anwendung E-Mails versenden soll. Der Block inv_email muss im aktuellen Inventory dennoch strukturell vorhanden bleiben: full_install.yml liest seine fünf Felder zu Beginn jedes Laufs ein. Für eine Umgebung ohne Mailversand können bewusst neutrale Platzhalter verwendet werden; produktive Zugangsdaten sind erst mit aktivierter E-Mail-Funktion erforderlich.

Container-Registries

inv_registry legt fest, von welchen Registry-Adressen die im UDSP-Release referenzierten Container-Images geladen werden.

inv_registry:
  dockerio: "docker.io"
  quayio: "quay.io"
  github: "ghcr.io"

Feld	Verwendet für	Standardwert
dockerio	Images, deren Quellrepository auf Docker Hub liegt, beispielsweise Node-RED oder Velero	docker.io
quayio	Images aus Quay.io, beispielsweise MinIO- oder cert-manager-Komponenten	quay.io
github	Images aus der GitHub Container Registry; gemeint ist nicht ein Git-Repository	ghcr.io

Wenn der Cluster diese öffentlichen Registries direkt erreichen darf, bleiben die Standardwerte unverändert. In abgeschotteten Umgebungen können hier interne Mirrors oder Registry-Präfixe eingetragen werden.

Beispiel: Aus dockerio: "docker.io" und dem im Release definierten Repository nodered/node-red entsteht der vollständige Imagepfad docker.io/nodered/node-red. Bei einem internen Mirror muss derselbe nachgelagerte Repositorypfad dort verfügbar sein.

Die Werte werden vor die im Release definierten Imagepfade gesetzt. Tragen Sie deshalb kein https:// und keinen abschließenden Slash ein. Ein interner Mirror muss die erwarteten Repositorypfade vollständig bereitstellen. Diese drei Werte konfigurieren außerdem keine Zugangsdaten; erforderliche Image-Pull-Credentials und Netzwerkfreigaben müssen separat vorhanden sein.

4. Gemeinsame Plattformdienste

Gemeinsame Dienste werden einmal je Umgebung eingerichtet und stehen vor den Mandanten bereit.

inv_op_stack:
  ns_name: "{{ ENVIRONMENT }}-operator-stack"
  cert_manager_operator:
    enable: true
    ns_name: "{{ ENVIRONMENT }}-operator-stack"
  postgres_operator:
    enable: true
    ns_name: "{{ ENVIRONMENT }}-operator-stack"
    logical_backup:
      enabled: false
      endpoint: "https://s3.example.org"
      bucket: "udsp-postgres-backups"
      region: "eu-central-1"
      access_key: "<secret>"
      secret: "<secret>"
      schedule: "0 0 * * *"
      retention_time: "7 days"
  minio_operator:
    enable: true
    enable_console_ingress: false
    ns_name: "{{ ENVIRONMENT }}-operator-stack"
  keycloak_operator:
    enable: true
    ns_name: "{{ ENVIRONMENT }}-operator-stack"
  keel_operator:
    enable: false
    ns_name: "{{ ENVIRONMENT }}-operator-stack"
    admin: "admin@{{ DOMAIN }}"
    password: "<secret>"

inv_security:
  ns_name: "{{ ENVIRONMENT }}-security-stack"
  kyverno:
    enable: true
    enforce_policies: false
  policy_reporter:
    enable: true
    ui_enabled: true
    kyverno_plugin_enabled: true

Welche Komponenten damit konfiguriert werden

Inventory-Block	Komponente der UDSP	Aufgabe
cert_manager_operator	cert-manager	stellt Zertifikatsressourcen und die automatische TLS-Erneuerung bereit
postgres_operator	PostgreSQL	erzeugt und verwaltet über den Zalando PostgreSQL Operator die Datenbank-Cluster der Plattformkomponenten
minio_operator	MinIO	verwaltet über den MinIO Operator mandantenbezogene MinIO-Instanzen und deren Speicher
keycloak_operator	Keycloak	stellt über den Keycloak Operator die zentrale Keycloak-Instanz im Cluster bereit und gleicht deren Kubernetes-Zustand ab
keel_operator	Keel	automatisiert – sofern bewusst aktiviert – Image-Aktualisierungen von Workloads
kyverno	Kyverno	prüft Kubernetes-Ressourcen gegen die mitgelieferten Sicherheitsrichtlinien
policy_reporter	Policy Reporter	sammelt und visualisiert die Ergebnisse der Kyverno-Prüfungen

Weitere Variablen

Feld	Bedeutung
inv_op_stack.ns_name	gemeinsamer Namespace der Operatoren; die komponentenspezifischen ns_name-Werte sollten im Standardpfad darauf zeigen
postgres_operator.logical_backup.enabled	aktiviert das gemeinsame S3-Ziel für alle komponentenbezogenen Schalter enable_logical_backup
postgres_operator.logical_backup.endpoint	S3-kompatibler Endpunkt des globalen PostgreSQL-Backupziels
postgres_operator.logical_backup.bucket	vorhandener Bucket für logische Datenbank-Backups
postgres_operator.logical_backup.region	vom S3-Anbieter erwartete Region
postgres_operator.logical_backup.access_key / secret	Zugangsdaten eines technischen Kontos mit minimal erforderlichen Bucket-Rechten
postgres_operator.logical_backup.schedule	Standardzeitplan als Cron-Ausdruck
postgres_operator.logical_backup.retention_time	Aufbewahrungsangabe des PostgreSQL-Operators, beispielsweise 7 days
minio_operator.enable_console_ingress	veröffentlicht die MinIO-Operator-Konsole; nur nach bewusster Zugriffs- und Schutzbewertung aktivieren
keel_operator.admin / password	administrativer Zugang für Keel, sofern die Komponente aktiviert wird
inv_security.ns_name	Namespace für Kyverno und Policy Reporter, beispielsweise prd-security-stack
kyverno.enforce_policies: false	Audit-Modus: Verstöße werden gemeldet, neue oder geänderte Ressourcen aber nicht deshalb abgelehnt
kyverno.enforce_policies: true	Enforce-Modus: Kubernetes-Anfragen, die gegen die meisten mitgelieferten Regeln verstoßen, können blockiert werden
policy_reporter.ui_enabled	stellt zusätzlich zur Reporter-API die administrative Weboberfläche bereit
policy_reporter.kyverno_plugin_enabled	aktiviert die erweiterte Kyverno-Integration in der Reporter-Oberfläche

Der Policy Reporter wird im aktuellen Playbook innerhalb des Kyverno-Pfads installiert. Wird Kyverno deaktiviert, wird deshalb auch ein separat auf true gesetzter Policy Reporter nicht ausgerollt.

Die Reporter-UI wird nicht automatisch öffentlich bereitgestellt; das Playbook nennt nach der Installation einen kubectl port-forward-Aufruf für den administrativen Zugriff.

Für eine neue Umgebung sollte enforce_policies zunächst auf false bleiben. Prüfen Sie die entstehenden Reports, beheben oder begründen Sie Abweichungen und testen Sie anschließend true in Staging. Eine direkte Aktivierung kann verhindern, dass UDSP-Komponenten mit noch nicht policykonformen Manifests ausgerollt werden.

Aktuelle Ausnahme

Die Policy require-namespace-labels ist im derzeitigen Plattformcode fest auf Audit gesetzt. Sie blockiert deshalb auch bei enforce_policies: true keine Namespaces. Die übrigen mitgelieferten Validierungsregeln verwenden den Schalter.

Wichtige Beziehungen:

• Keycloak, TimescaleDB, Stellio, FROST, GeoStack, Superset und CKAN verwenden den PostgreSQL-Operator.
• Mandantenbezogene MinIO-Instanzen benötigen den MinIO-Operator.
• Der Keycloak-Operator stellt die Keycloak-Instanz im Cluster bereit und hält deren Kubernetes-Ressourcen im gewünschten Zustand.
• Realms, Clients, Rollen, Gruppen und Mappings werden anschließend durch die Ansible-Konfiguration des jeweiligen Mandanten beziehungsweise der jeweiligen Komponente über die Keycloak Admin API angelegt. Diese fachliche Keycloak-Konfiguration übernimmt nicht der Operator.
• cert-manager wird von den standardmäßigen TLS-Ingresses erwartet.
• Policy Reporter wird nur zusammen mit Kyverno installiert.

Aktivieren Sie postgres_operator.logical_backup.enabled erst, wenn das S3-Ziel vollständig eingerichtet und aus dem Cluster erreichbar ist. Dieses Ziel wird nicht nur für die mandantenbezogene PostgreSQL-/TimescaleDB verwendet, sondern auch für aktivierte logische Backups von Keycloak, Stellio, FROST, KomMonitor, Superset, CKAN und der Geo-Datenbank.

5. Observability und Backup

In diesem Abschnitt entscheiden Sie,

• ob die UDSP Metriken, Logs, Dashboards und Alarmierungen selbst bereitstellt,
• wie lange Metriken und Logs aufbewahrt werden,
• wie viel persistenter Speicher die einzelnen Dienste anfordern und
• ob Kubernetes-Ressourcen zusätzlich mit Velero gesichert werden.

Die Konfiguration hat zwei voneinander unabhängige Bereiche: inv_ml installiert den Observability-Stack, inv_velero den Backup-Dienst. Das folgende Beispiel zeigt nur die wichtigsten Stellgrößen. Behalten Sie die übrigen Felder aus dem default_inventory.yml des verwendeten Releases bei.

inv_ml:
  enable: true
  ns_name: "{{ ENVIRONMENT }}-observability-stack"
  prometheus:
    enable: true
    replicas: 1
    storage_size: 20Gi
    retention_days: 14d
  grafana:
    enable: true
    storage_size: 10Gi
  alertmanager:
    enable: true
    replicas: 1
    storage_size: 5Gi
  loki:
    enable: true
    replicas: 1
    retention_period: "168h"
    storage_size: 20Gi
  alloy:
    enable: true
    replicas: 1

inv_velero:
  enable: false
  ns_name: "velero"
  operations_backup:
    backup_storage_location: "primary-s3"
    schedule: "0 0 * * *"
    ttl: "168h0m0s"
  exclude_namespaces:
    - "velero"
    - "kube-system"
    - "kube-public"
    - "kube-node-lease"
    - "cloud-init-settings"
  backup_storage_locations:
    - location_name: "primary-s3"
      endpoint: "https://s3.example.org"
      bucket: "udsp-backups"
      region: "eu-central-1"
      access_key: "<secret>"
      secret_key: "<secret>"
      s3ForcePathStyle: "true"

Welche Komponenten damit konfiguriert werden

Inventory-Block	Komponente der UDSP	Aufgabe
prometheus	Prometheus	sammelt und speichert Metriken aus Kubernetes und den Plattformdiensten
grafana	Grafana Monitoring	visualisiert zentrale Metriken und Logs für den Plattformbetrieb
alertmanager	Alertmanager	gruppiert Alarme und leitet sie an konfigurierte Empfänger weiter
loki	Loki	speichert und durchsucht zentral gesammelte Container-Logs
alloy	Grafana Alloy	liest Logs auf den Cluster-Nodes und sendet sie an Loki
inv_velero	Velero	sichert Kubernetes-Ressourcen nach einem Zeitplan in ein externes S3-Backend

inv_ml.ns_name bestimmt den gemeinsamen Namespace des Observability-Stacks, beispielsweise prd-observability-stack. Prometheus, Grafana und Alertmanager werden gemeinsam über den Prometheus-Kube-Stack installiert. Wird Prometheus deaktiviert, werden dadurch auch Grafana und Alertmanager aus diesem Helm-Release nicht ausgerollt. Loki und Alloy werden dagegen separat installiert.

Metriken, Dashboards und Alarmierung

Feld	Bedeutung	Auswirkung des Beispielwerts
prometheus.replicas	Anzahl der Prometheus-Instanzen	1: keine redundante Prometheus-Instanz
prometheus.storage_size	angeforderte PVC-Größe je Prometheus-Instanz	20Gi: bei einer Replik ein PVC mit 20 GiB
prometheus.retention_days	zeitliche Aufbewahrung der Metriken	14d: Messwerte werden 14 Tage vorgehalten
grafana.storage_size	PVC für Grafana-Konfiguration, Plugins und lokale Zustände	10Gi; die eigentlichen Prometheus-Metriken liegen nicht in diesem Volume
alertmanager.replicas	Anzahl der Alertmanager-Instanzen	1: keine redundante Alertmanager-Instanz
alertmanager.storage_size	angeforderte PVC-Größe je Alertmanager-Instanz	5Gi für Alarmzustände und Silences

retention_days begrenzt die Aufbewahrungszeit, nicht automatisch den maximal belegten Speicher. Ist das PVC vorher voll, gehen keine zusätzlichen 14 Tage hinein. Dimensionieren Sie storage_size deshalb anhand der Anzahl überwachter Targets, der Scrape-Intervalle und des gemessenen Wachstums in einer Testumgebung.

Logs sammeln und speichern

Feld	Bedeutung	Auswirkung des Beispielwerts
loki.replicas	Anzahl der Loki-Single-Binary-Instanzen	1: eine Loki-Instanz; das aktuelle Profil verwendet einen Replikationsfaktor von 1
loki.retention_period	zeitliche Aufbewahrung der Logs	168h: sieben Tage
loki.storage_size	angeforderte PVC-Größe je Loki-Instanz	20Gi für Index- und Logdaten
alloy.replicas	im Inventory vorhandener Chartwert	Im aktuellen UDSP-Profil läuft Alloy als DaemonSet. Die tatsächliche Pod-Anzahl folgt daher den geeigneten Cluster-Nodes und nicht diesem Wert.

Loki und Alloy erfüllen unterschiedliche Aufgaben: Alloy sammelt, Loki speichert und durchsucht. Wird Loki aktiviert, Alloy aber deaktiviert, entsteht dadurch noch kein automatischer Logfluss. Umgekehrt benötigt Alloy ein konfiguriertes Ziel für die gesammelten Logs.

Backup mit Velero

Feld	Bedeutung	Was Sie festlegen
ns_name	Namespace der Velero-Installation	im Standard velero; dieser Namespace gehört auch in die Ausschlussliste
operations_backup.backup_storage_location	logischer Name des S3-Ziels für den primären Sicherungsplan	muss auf location_name eines Eintrags unter backup_storage_locations verweisen
operations_backup.schedule	Ausführungszeit als Cron-Ausdruck	0 0 * * * startet die Sicherung täglich um Mitternacht
operations_backup.ttl	Aufbewahrungsdauer eines Velero-Backups	168h0m0s entspricht sieben Tagen
operations_backup_2	optionaler zweiter Sicherungsplan mit denselben Feldern	für ein unabhängiges zweites S3-Ziel verwenden; dessen eigener Aktivierungsschalter bleibt andernfalls false
exclude_namespaces	Namespaces, die nicht in den Sicherungsplan aufgenommen werden	mindestens Velero selbst und die bewusst nicht zu sichernden System-Namespaces
location_name	interne Kennung eines S3-Backends	ohne das automatisch angehängte Suffix -backup eintragen
endpoint	vollständige URL der S3-kompatiblen API	beispielsweise https://s3.example.org
bucket	vorhandener Bucket für die Backupobjekte	eigener, ausschließlich für diesen Sicherungspfad vorgesehener Bucket
region	vom S3-Anbieter erwartete Region	den exakten Anbieterwert verwenden
access_key / secret_key	Zugangsdaten des technischen S3-Kontos	nur mit minimal erforderlichen Bucket-Rechten und verschlüsselt ablegen
s3ForcePathStyle	erzwingt S3-Pfadstil statt virtueller Bucket-Hostnamen	für viele S3-kompatible Dienste "true"; nach Vorgabe des Anbieters setzen

Ist Velero deaktiviert, werden weder der Dienst noch seine Zeitpläne installiert. Das deaktiviert nicht automatisch separate logische Datenbank-Backups. Aktivieren Sie Velero erst, wenn alle oben genannten Werte gepflegt sind, und führen Sie anschließend einen dokumentierten Wiederherstellungstest durch.

Velero ersetzt im aktuellen Rollout kein Datenbank-Backup

Die erzeugten Zeitpläne setzen snapshotVolumes: false. Sie sichern Kubernetes-Ressourcen, erstellen aber keine Snapshots der Persistent Volumes. Für PostgreSQL-Daten und andere zustandsbehaftete Dienste müssen deshalb zusätzlich die vorgesehenen logischen oder storage-spezifischen Backups aktiviert und separat wiederhergestellt werden können.

Startwerte sind keine Produktionsdimensionierung

Die angegebenen Replik- und Speicherwerte eignen sich als Ausgangspunkt für eine kleine Umgebung. Für Produktion müssen Ausfallsicherheit, PVC-Gesamtbedarf, Metrik- und Logwachstum, Aufbewahrungsfristen sowie das Backupziel gemeinsam geplant werden. Mehrere Repliken ersetzen kein Backup.

6. Identität, Verfügbarkeit und HYPERSENSUS

Die folgenden drei Blöcke schließen die gemeinsame Plattformbasis ab:

• inv_idm legt den zentralen Keycloak-Zugang und dessen Betriebswerte fest.
• inv_replicas übersetzt das gewählte Betriebsprofil in tatsächliche Komponenteninstanzen.
• inv_hypersensus konfiguriert die nach den Mandanten installierte gemeinsame Plattformoberfläche.

inv_idm:
  ns_name: "{{ ENVIRONMENT }}-idm-stack"
  db_ns_name: "{{ ENVIRONMENT }}-idm-db-stack"
  platform:
    admin_first_name: "Platform"
    admin_surname: "Admin"
    admin_email: "admin@{{ DOMAIN }}"
    master_username: "admin@{{ DOMAIN }}"
    master_password: "<secret>"
  keycloak:
    realm_name: "operations"
    k8s_secret_name: "master-secret"
    scope: "openid"
    enable_events: false
    enable_adminEvents: false
    log_level: "INFO"
    theme: "ocp-custom"
    theme_url: "https://gitlab.com/urban-dataspace-platform/customization/-/raw/htag_26/keycloak/minimum/theme.jar"
    enable_logical_backup: false
  group:
    default_tenant_name: "default_dataspace"

inv_replicas:
  keycloak:
    db: 1
    app: 1
  gravitee:
    api_mgmt: 1
    gateway: 1
  api_mgmt:
    apisix: 1
    etcd: 1
  frost:
    db: 1
    mqtt: 1
    http: 1
  timescale:
    db: 1
  cm:
    api_gateway: 1
    kafka: 1
    postgresql: 1
    search_service: 1
    subscription_service: 1

inv_hypersensus:
  enable: true
  version: "v2.0.0"
  # backend_flask_secret: "<secret>"
  frontend:
    common_url: "{{ DOMAIN }}"
    # nextauth_secret: "<secret>"
    tenant_dropdown_enabled: false
  registry:
    username: ""
    password: ""
  # proxy:
  #   http: "http://proxy.example.org:3128"
  #   https: "http://proxy.example.org:3128"
  #   no_proxy: "localhost,127.0.0.1,.svc,.cluster.local"

Die Standardwerte mit jeweils einer Instanz erzeugen keine vollständige Redundanz der Plattformdienste – auch dann nicht, wenn der Kubernetes-Cluster selbst aus mehreren Workern besteht. Legen Sie Replikate deshalb zusammen mit Quorum-Anforderungen, verfügbarer Kapazität und der tatsächlichen Ausfallsicherheitsstrategie fest.

Für Keycloak und HYPERSENSUS müssen stabile Secrets vor dem produktiven Rollout festgelegt und verschlüsselt abgelegt werden. Automatisch erzeugte Laufzeitwerte erschweren ansonsten die reproduzierbare Wiederherstellung.

Alle Felder dieser Blöcke und ihre zulässigen Werte stehen zusätzlich in der vollständigen Parameterreferenz.

7. Mandanten

inv_tenants ist eine YAML-Liste. Jeder Eintrag legt die Identität und die gemeinsamen Werte eines technisch getrennten Mandanten fest. Die darunter folgenden Anwendungsblöcke werden anschließend auf der separaten Seite Mandanten konfigurieren ergänzt.

inv_tenants:
  - tenant_realm: "stadt-a"
    display_name: "Stadt A"
    tenant_domain: "a.platform.example.org"
    tenant_prefix: "stadta"

    mailserver:
      user: "{{ inv_email.user }}"
      password: "{{ inv_email.password }}"
      server: "{{ inv_email.server }}"
      port: "{{ inv_email.port }}"
      email_from: "{{ inv_email.email_from }}"

    # ... Komponenten von Stadt A ...

  - tenant_realm: "stadt-b"
    display_name: "Stadt B"
    tenant_domain: "b.platform.example.org"
    tenant_prefix: "stadtb"

    mailserver:
      user: "{{ inv_email.user }}"
      password: "{{ inv_email.password }}"
      server: "{{ inv_email.server }}"
      port: "{{ inv_email.port }}"
      email_from: "{{ inv_email.email_from }}"

    # ... Komponenten von Stadt B ...

Feld	Verwendung	Was Sie festlegen
tenant_prefix	Präfix für Kubernetes-Namespaces und technische Ressourcennamen	kurze, eindeutige und dauerhaft stabile Kennung des Mandanten
tenant_realm	Name des Keycloak-Realm und fachliche Mandantenidentität	eindeutigen Realm-Namen ohne URL verwenden
display_name	lesbarer Name in Oberflächen und mandantenbezogenen Konfigurationen	offizieller Anzeigename, beispielsweise Stadt Beispiel
tenant_domain	Basisdomain der öffentlich erreichbaren Mandantenendpunkte	vorhandenen DNS-Namen ohne https:// und ohne Pfad
mailserver.*	SMTP-Konfiguration dieses Mandanten	im Standard die zentralen Werte aus inv_email übernehmen; nur bei einem abweichenden Mandantenkonto ändern

Für jeden weiteren Mandanten wird ein vollständiger zusätzlicher Listeneintrag angelegt. tenant_realm, tenant_prefix und die vorgesehenen Domains müssen eindeutig sein. Vor dem Rollout müssen DNS, Mailkonfiguration, benötigte Kapazität und externe Zugänge auch für diesen Mandanten bereitstehen.

Ein Präfix wie stadta erzeugt zusammen mit ENVIRONMENT: prd beispielsweise Namespaces wie stadta-prd-ngsi-stack oder stadta-prd-data-management-stack. Ändern Sie den Präfix deshalb nach der Erstinstallation nicht ohne Migrationsplanung.

Welche Komponenten unter dem jeweiligen Listeneintrag ergänzt werden und was deren weitere Variablen bedeuten, beschreibt der nächste Schritt: Mandanten konfigurieren.

8. Secrets sicher behandeln

Das Inventory kann Passwörter, API-Schlüssel, Registry Tokens und S3-Credentials enthalten.

• Committen Sie produktive Inventories nicht unverschlüsselt.
• Verwenden Sie Ansible Vault oder geschützte CI/CD-Dateivariablen.
• Trennen Sie Inventories für Entwicklung, Staging und Produktion.
• Verwenden Sie Deploy Tokens mit minimal erforderlichen Rechten.
• Rotieren Sie Zugangsdaten, wenn ein Inventory ungeschützt weitergegeben wurde.
• Prüfen Sie Logs auf versehentlich ausgegebene Secrets; nicht alle älteren Tasks verwenden durchgehend no_log.

Beispiel mit Ansible Vault:

ansible-vault encrypt inventories/customer-prod.yml
ansible-playbook \
  -i inventories/customer-prod.yml \
  --ask-vault-pass \
  -l localhost \
  02_core_platform/full_install.yml

Inventory validieren

ansible-inventory \
  -i inventories/customer-prod.yml \
  --graph

ansible-playbook \
  -i inventories/customer-prod.yml \
  -l localhost \
  02_core_platform/full_install.yml \
  --syntax-check

Anschließend kann die im Playbook enthaltene Clusterprüfung separat ausgeführt werden:

ansible-playbook \
  -i inventories/customer-prod.yml \
  -l localhost \
  02_core_platform/full_install.yml \
  --tags validation

--syntax-check prüft Struktur und importierte Tasks, aber weder Erreichbarkeit noch fachliche Konsistenz. Die Validierung ersetzt deshalb keinen Staging-Rollout.

Vollständige Parameterreferenz

Releasegebundene Referenz

Alle Felder der Plattformbasis

Die Tabellen bilden die einstellbaren globalen Felder des Default-Inventory ab. Kommentierte optionale Felder und mitgeführte Kompatibilitätsblöcke sind ausdrücklich gekennzeichnet. Die Vorlage des tatsächlich verwendeten Releases bleibt strukturell maßgeblich.

Umgebung, Quellen und Proxy

Globale Werte unter all.vars. Sie gelten unabhängig vom einzelnen Mandanten.

Inventory-Pfad	Bedeutung	Erwarteter Wert
DOMAIN	Basisdomain der gemeinsamen Plattformdienste.	Hostname ohne Protokoll oder Pfad
ENVIRONMENT	Stabiler technischer Präfix der Umgebung.	dev, stg oder prd
kubeconfig_file	Kubeconfig-Datei unter $HOME/.kube/.	Dateiname, nicht der vollständige Pfad
HELM_REPOSITORY	Kompatibilitätsfeld für einen vorgeschalteten Helm-Proxy.	Leer lassen, solange der verwendete Release es nicht auswertet
OPERATOR_STACK	Gemeinsamer Namespace der Plattformoperatoren.	Üblicherweise {{ ENVIRONMENT }}-operator-stack
proxy_state	Kompatibilitätsfeld für die Proxyverwaltung älterer Bereitstellungspfade.	present oder absent; im aktuellen Plattform-Playbook ohne Wirkung
HTTP_PROXY / HTTPS_PROXY	Proxywerte für Komponenten und Tasks mit Großschreibung.	Vollständige Proxy-URL oder leer
http_proxy / https_proxy	Dieselben Proxywerte für Werkzeuge mit Kleinschreibung.	Vollständige Proxy-URL oder leer
NO_PROXY / no_proxy	Ziele, die den Proxy umgehen müssen.	Kommagetrennte Hosts, Domains, Service- und Clusternetze
enterprise_root_cert	Optionale Unternehmens-CA für Komponenten wie Grafana, Node-RED, CKAN, Superset und GeoServer.	PEM-kodiertes Zertifikat; Feld weglassen, wenn nicht benötigt

Mitgeführter Base-Cluster-Abschnitt

Der Block all.children.kubernetes stammt aus dem früher kombinierten Inventory. full_install.yml verwendet ihn nicht. Für ein separat aufgebautes Basiscluster ist heute das base-cluster-Repository maßgeblich.

Inventory-Pfad	Bedeutung	Erwarteter Wert
kubernetes.hosts.<host>.ansible_host	Adresse eines durch das alte Cluster-Playbook verwalteten Servers.	IP-Adresse oder DNS-Name
kubernetes.hosts.<host>.ansible_python_interpreter	Python-Interpreter auf diesem Server.	Üblicherweise /usr/bin/python3
kubernetes.hosts.<host>.ansible_ssh_private_key_file	SSH-Schlüssel für den alten Cluster-Aufbau.	Geschützter lokaler Dateipfad
kubernetes.hosts.localhost.ansible_connection	Lokale Verbindung für den Controller-Eintrag.	local
platform_default_user	SSH-Benutzer des alten MicroK8s-Bereitstellungspfads.	Vorhandener Benutzer mit den erforderlichen Rechten
microk8s_version	Zu installierender MicroK8s-Channel.	Beispielsweise 1.25/stable
microk8s_dns	Optionale Upstream-DNS-Server für MicroK8s.	Kommagetrennte IP-Adressen
microk8s_openebs_addon	Aktivierung des früher verwendeten OpenEBS-Add-ons.	enable oder disable
default_storage_class	Standard-StorageClass des alten Basisclusters.	Name einer vorhandenen StorageClass
k8s_ingress_class	IngressClass des alten Basisclusters.	Beispielsweise public
gitlab_domain	Domain einer optionalen GitLab-Installation im alten Clusterpfad.	Hostname
RUNNER_REGISTRATION_TOKEN	Registrierungstoken des früheren GitLab-Runner-Pfads.	Geschütztes Token

Deployment-Umgebung und Kubernetes

Der Controller-Block bestimmt, wo Ansible läuft und gegen welchen Cluster der Rollout ausgeführt wird.

Inventory-Pfad	Bedeutung	Erwarteter Wert
controller.hosts.localhost.ansible_host	Lokale Controller-Adresse.	127.0.0.1
controller.hosts.localhost.ansible_connection	Verbindungsart der offiziellen lokalen Bereitstellung.	local
controller.hosts.localhost.ansible_python_interpreter	Python-Interpreter der Ansible-Module.	{{ ansible_playbook_python }} bei einer virtuellen Umgebung
inv_k8s.config.context	Kubeconfig-Context des Zielclusters.	Exakt vorhandener Context
inv_k8s.ingress_class	IngressClass aller öffentlichen Plattformendpunkte.	Exakter Name im Zielcluster
inv_k8s.disable_ipv6	Deaktiviert IPv6 in dafür vorgesehenen Komponenteneinstellungen.	true oder false
inv_k8s.storage_class.rwo	StorageClass für reguläre ReadWriteOnce-Volumes.	Exakter StorageClass-Name
inv_k8s.storage_class.rwo_retain	StorageClass für besonders zu erhaltende Daten.	Exakter StorageClass-Name mit bewusst gewählter Reclaim Policy
inv_k8s.storage_class.provisioner	Dokumentierter CSI- beziehungsweise Storage-Provisioner.	Provisioner-Name der StorageClass
inv_k8s.gitlab_access.user_email	E-Mail des mitgeführten GitLab-Zugangs.	E-Mail-Adresse; aktueller Plattformpfad wertet das Feld nicht direkt aus
inv_k8s.gitlab_access.user	Benutzer des mitgeführten GitLab-Zugangs.	Benutzername; aktueller Plattformpfad wertet das Feld nicht direkt aus
inv_k8s.gitlab_access.token	Token des mitgeführten GitLab-Zugangs.	Geschütztes Token; aktueller Plattformpfad wertet das Feld nicht direkt aus
inv_k8s.cert_manager.le_email	Kontaktadresse des ACME-Kontos.	Gültige betriebliche E-Mail-Adresse
inv_k8s.cert_manager.staging_issuer_name	Name des Test-ClusterIssuers.	DNS-konformer Kubernetes-Name
inv_k8s.cert_manager.prod_issuer_name	Name des produktiven ClusterIssuers.	DNS-konformer Kubernetes-Name

Mail und Container-Registries

Zentrale Kommunikationswerte und Präfixe der vom Release verwendeten Imagequellen.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_email.server	Hostname des SMTP-Servers.	DNS-Name ohne Protokoll
inv_email.port	Port des SMTP-Dienstes.	Üblicherweise 587 für STARTTLS
inv_email.user	Technischer SMTP-Benutzer.	Vom Mailbetreiber bereitgestelltes Konto
inv_email.password	Passwort des SMTP-Benutzers.	Secret
inv_email.email_from	Erlaubte Absenderadresse.	Gültige E-Mail-Adresse
inv_registry.dockerio	Registry-Präfix für Images von Docker Hub.	docker.io oder internes Mirror-Präfix
inv_registry.quayio	Registry-Präfix für Images von Quay.io.	quay.io oder internes Mirror-Präfix
inv_registry.github	Registry-Präfix für GitHub Container Registry.	ghcr.io oder internes Mirror-Präfix

Operatoren und logische PostgreSQL-Backups

Operatoren werden einmal je Plattformumgebung installiert. Der PostgreSQL-Operator stellt zusätzlich ein gemeinsames S3-Ziel für aktivierte logische Datenbank-Backups bereit.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_op_stack.ns_name	Gemeinsamer Namespace der Operatoren.	DNS-konformer Namespace
inv_op_stack.cert_manager_operator.enable / ns_name	Aktiviert cert-manager und legt dessen Namespace fest.	true oder false; Namespace
inv_op_stack.postgres_operator.enable / ns_name	Aktiviert den PostgreSQL-Operator und legt dessen Namespace fest.	true oder false; Namespace
inv_op_stack.postgres_operator.logical_backup.enabled	Aktiviert die globale Unterstützung logischer PostgreSQL-Backups.	true oder false
inv_op_stack.postgres_operator.logical_backup.endpoint	S3-kompatibler Endpunkt des Backupziels.	Vom Anbieter erwartete URL
inv_op_stack.postgres_operator.logical_backup.bucket	Bucket für die logischen Datenbank-Backups.	Vorhandener Bucketname
inv_op_stack.postgres_operator.logical_backup.region	S3-Region des Buckets.	Exakter Anbieterwert
inv_op_stack.postgres_operator.logical_backup.access_key	Technischer Zugriffsschlüssel.	Secret mit minimalen Bucket-Rechten
inv_op_stack.postgres_operator.logical_backup.secret	Geheimer Schlüssel des technischen S3-Kontos.	Secret
inv_op_stack.postgres_operator.logical_backup.schedule	Standardzeitplan der logischen Backups.	Cron-Ausdruck
inv_op_stack.postgres_operator.logical_backup.retention_time	Aufbewahrung durch den PostgreSQL-Operator.	PostgreSQL-Dauer, z. B. 7 days oder 2 weeks
inv_op_stack.minio_operator.enable / ns_name	Aktiviert den MinIO-Operator und legt dessen Namespace fest.	true oder false; Namespace
inv_op_stack.minio_operator.enable_console_ingress	Veröffentlicht die Operator-Konsole über einen Ingress.	true oder false; nur nach bewusster Zugriffsbewertung aktivieren
inv_op_stack.keycloak_operator.enable / ns_name	Aktiviert den Keycloak-Operator und legt dessen Namespace fest.	true oder false; Namespace
inv_op_stack.keel_operator.enable / ns_name	Aktiviert Keel und legt dessen Namespace fest.	true oder false; Namespace
inv_op_stack.keel_operator.admin	Administrativer Keel-Benutzer.	E-Mail-Adresse
inv_op_stack.keel_operator.password	Passwort des Keel-Administrators.	Secret

Zentrale Identität mit Keycloak

inv_idm beschreibt die gemeinsame Keycloak-Instanz. Die Mandanten-Realms werden später unter inv_tenants ergänzt.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_idm.ns_name	Namespace der Keycloak-Anwendung.	Üblicherweise {{ ENVIRONMENT }}-idm-stack
inv_idm.db_ns_name	Namespace der Keycloak-Datenbank.	Üblicherweise {{ ENVIRONMENT }}-idm-db-stack
inv_idm.platform.admin_first_name	Vorname des initialen Plattformadministrators.	Freier Text
inv_idm.platform.admin_surname	Nachname des initialen Plattformadministrators.	Freier Text
inv_idm.platform.admin_email	Kontakt- und Benutzeradresse des Plattformadministrators.	Gültige E-Mail-Adresse
inv_idm.platform.master_username	Anmeldename des initialen Master-Administrators.	Im Standard dieselbe E-Mail-Adresse
inv_idm.platform.master_password	Initiales Master-Passwort.	Starkes Secret
inv_idm.keycloak.realm_name	Name des gemeinsamen Betriebs-Realm.	Stabiler Realm-Name, im Standard operations
inv_idm.keycloak.k8s_secret_name	Kubernetes-Secret mit dem administrativen Zugang.	DNS-konformer Secret-Name
inv_idm.keycloak.scope	Standard-OIDC-Scope.	Im Standard openid
inv_idm.keycloak.enable_events	Speichert Benutzerereignisse in Keycloak.	true oder false
inv_idm.keycloak.enable_adminEvents	Speichert administrative Ereignisse.	true oder false
inv_idm.keycloak.log_level	Log-Level der Keycloak-Laufzeit.	Unterstützter Keycloak-Level, z. B. INFO
inv_idm.keycloak.theme	Name des aktiven Keycloak-Themes.	Im Theme-Artefakt vorhandener Name
inv_idm.keycloak.theme_url	Bezugsadresse des Theme-Artefakts.	Erreichbare HTTPS-URL
inv_idm.keycloak.enable_logical_backup	Aktiviert das logische Backup der Keycloak-Datenbank.	true oder false; globales PostgreSQL-Backupziel erforderlich
inv_idm.group.default_tenant_name	Voreingestellte Datenraumgruppe neuer Plattformbenutzer.	Existierender Gruppenname

Gemeinsame Namespaces und Komponentenvorgaben

Diese Blöcke liefern Namespaces und gemeinsame Laufzeitwerte, die von den mandantenbezogenen Komponenten verwendet werden.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_am.apim.ns_name	Namespace des nur noch für Bestandsinstallationen vorgesehenen Gravitee-Pfads.	Namespace
inv_am.apim.management_log_level	Log-Level der Gravitee-Verwaltung.	Unterstützter Log-Level
inv_am.apim.gateway_log_level	Log-Level des Gravitee-Gateways.	Unterstützter Log-Level
inv_am.apim.default_basic_auth	Legacy-Basic-Auth-Wert für Gravitee.	Secret; nur für Bestandsinstallationen
inv_am.apim.portal_application	Anzeigename der Legacy-Portal-Anwendung.	Freier Text
inv_am.apisix.ns_name	Gemeinsamer APISIX-Namespace.	Üblicherweise {{ ENVIRONMENT }}-api-management-stack
inv_am.apisix.loki_namespace	Namespace des von APISIX verwendeten Loki-Ziels.	Namespace der internen oder externen Loki-Installation
inv_am.apisix.prometheus_namespace	Namespace des von APISIX verwendeten Prometheus-Ziels.	Namespace der internen oder externen Prometheus-Installation
inv_cm.fiware.ns_name	Namespace des Legacy-FIWARE-Pfads.	Namespace
inv_cm.frost.ns_name	Basisname des FROST-Namespace.	Namespace
inv_cm.stellio.ns_name	Basisname des Stellio-Namespace.	Namespace
inv_cm.stellio.set_tcp_keepalive	Optionaler TCP-Keepalive-Workaround für Stellio.	true oder false; Feld nur bei bekannten Idle-Verbindungsproblemen ergänzen
inv_dm.ns_name	Gemeinsamer Namespace der Datenmanagementdienste.	Namespace
inv_dm.grafana.rbac.create	Lässt das Grafana-Chart eigene RBAC-Ressourcen erzeugen.	true oder false
inv_dm.grafana.rbac.psp_enabled	Legacy-Schalter für PodSecurityPolicies.	Im Standard false
inv_dm.grafana.rbac.psp_use_app_armor	Legacy-AppArmor-Schalter des Grafana-Charts.	Im Standard false
inv_dm.grafana.service_account.create	Lässt das Grafana-Chart einen ServiceAccount erzeugen.	true oder false
inv_dm.grafana.datasources.timescale_name	Anzeigename der TimescaleDB-Datenquelle.	Freier, in Grafana eindeutiger Name
inv_dm.grafana.datasources.stellio_postgres_name	Anzeigename der Stellio-PostgreSQL-Datenquelle.	Freier, in Grafana eindeutiger Name
inv_kom.ns_name	Basisname des KomMonitor-Namespace.	Namespace
inv_gd.ns_name	Globaler Basisname des GeoStack-Namespace.	Namespace
inv_documentation.ns_name	Namespace einer gemeinsam genutzten Dokumentationsinstanz.	Namespace

Policy-Prüfung

Kyverno prüft Kubernetes-Ressourcen; Policy Reporter bereitet die Ergebnisse administrativ auf.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_security.ns_name	Gemeinsamer Namespace des Security-Stacks.	Namespace
inv_security.kyverno.enable	Installiert Kyverno und die mitgelieferten Regeln.	true oder false
inv_security.kyverno.enforce_policies	Wechselt unterstützte Regeln von Audit auf Enforce.	false für Beobachtung; true erst nach Prüfung in Staging
inv_security.policy_reporter.enable	Installiert Policy Reporter zusammen mit Kyverno.	true oder false
inv_security.policy_reporter.ui_enabled	Aktiviert die administrative Reporter-Weboberfläche.	true oder false
inv_security.policy_reporter.kyverno_plugin_enabled	Aktiviert die erweiterte Kyverno-Integration der Reporter-UI.	true oder false

Observability

inv_ml steuert Metriken, Dashboards, Alerting, Logs, Langzeitarchivierung und Datenbankexporter.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_ml.enable / ns_name	Aktiviert den Observability-Stack und legt dessen Namespace fest.	true oder false; Namespace
inv_ml.thanos.enable	Aktiviert die langfristige Prometheus-Ablage über Thanos.	true oder false
inv_ml.thanos.unique_labels[].key / value	Kennzeichnet Metriken dieser Plattforminstanz eindeutig.	Mindestens ein stabiles Schlüssel-Wert-Paar
inv_ml.thanos.s3_storage.bucket	Bucket der Thanos-Langzeitablage.	Vorhandener Bucketname
inv_ml.thanos.s3_storage.endpoint	S3-Endpunkt für Thanos.	Hostname ohne http:// oder https:// gemäß Inventory-Vorlage
inv_ml.thanos.s3_storage.region	S3-Region für Thanos.	Exakter Anbieterwert
inv_ml.thanos.s3_storage.access_key / secret_key	Zugang des technischen Thanos-Kontos.	Secrets mit minimalen Bucket-Rechten
inv_ml.prometheus.enable / replicas	Aktiviert Prometheus und legt dessen Instanzzahl fest.	true oder false; positive Ganzzahl
inv_ml.prometheus.storage_size	PVC-Größe je Prometheus-Instanz.	Kubernetes-Größe
inv_ml.prometheus.retention_days	Zeitliche Aufbewahrung der Metriken.	Prometheus-Dauer, z. B. 14d
inv_ml.grafana.enable	Aktiviert das Grafana des Observability-Stacks.	true oder false
inv_ml.grafana.deploy_default_dashboards	Installiert die mitgelieferten Plattformdashboards.	true oder false
inv_ml.grafana.storage_size	PVC-Größe von Grafana.	Kubernetes-Größe
inv_ml.grafana.deploy_dashboards.minio	Installiert die mitgelieferten MinIO-Dashboards.	true oder false
inv_ml.grafana.deploy_dashboards.apisix	Installiert die mitgelieferten APISIX-Dashboards.	true oder false
inv_ml.alertmanager.enable / replicas	Aktiviert Alertmanager und legt dessen Instanzzahl fest.	true oder false; positive Ganzzahl
inv_ml.alertmanager.storage_size	PVC-Größe je Alertmanager-Instanz.	Kubernetes-Größe
inv_ml.alertmanager.ingress.enable	Veröffentlicht Alertmanager über einen Ingress.	true oder false; Zugriffsschutz vorher bewerten
inv_ml.alertmanager.receivers.slack_webhook_backup	Slack-Ziel für Backup-Alarme.	Webhook-URL oder leer
inv_ml.alertmanager.receivers.slack_webhook_postgres	Slack-Ziel für PostgreSQL-Alarme.	Webhook-URL oder leer
inv_ml.alertmanager.receivers.slack_webhook_critical	Slack-Ziel für kritische Plattformalarme.	Webhook-URL oder leer
inv_ml.alertmanager.receivers.slack_webhook_warning	Slack-Ziel für Warnungen.	Webhook-URL oder leer
inv_ml.alertmanager.critical_alerts[]	Alarmnamen, die als kritisch weitergeleitet werden.	Liste vorhandener Prometheus-Alertnamen
inv_ml.alertmanager.warning_alerts[]	Alarmnamen, die als Warnung weitergeleitet werden.	Liste vorhandener Prometheus-Alertnamen
inv_ml.loki.enable / replicas	Aktiviert Loki und legt dessen Instanzzahl fest.	true oder false; positive Ganzzahl
inv_ml.loki.deploy_default_dashboards	Installiert die mitgelieferten Loki-Dashboards.	true oder false
inv_ml.loki.retention_period	Zeitliche Aufbewahrung der Logs.	Dauer, z. B. 168h
inv_ml.loki.storage_size	PVC-Größe je Loki-Instanz.	Kubernetes-Größe
inv_ml.loki.memory_limit	Memory-Limit der Loki-Container.	Kubernetes-Speicherwert
inv_ml.loki.gateway_replicas	Replikate des Loki-Gateways.	Positive Ganzzahl
inv_ml.promtail.enable	Aktiviert den älteren Promtail-Logsammler.	true oder false; im Standard durch Alloy ersetzt
inv_ml.alloy.enable / replicas	Aktiviert Grafana Alloy; der aktuelle Rollout betreibt es als DaemonSet.	true oder false; replicas ist im Inventory vorhanden, bestimmt aber nicht die Podzahl
inv_ml.exporters.postgres_exporter.enable	Exportiert PostgreSQL-Metriken nach Prometheus.	true oder false
inv_ml.exporters.patroni_exporter.enable	Exportiert Patroni-Metriken nach Prometheus.	true oder false

Velero

inv_velero installiert den Backupdienst und definiert globale Sicherungspläne sowie ein oder mehrere S3-Ziele.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_velero.enable / ns_name	Aktiviert Velero und legt dessen Namespace fest.	true oder false; Namespace
inv_velero.certificate	Optionale CA für ein S3-Ziel mit eigener PKI.	PEM-kodiertes Zertifikat
inv_velero.operations_backup.backup_storage_location	Logischer Name des primären S3-Ziels.	location_name eines Eintrags unter backup_storage_locations
inv_velero.operations_backup.schedule / ttl	Zeitplan und Aufbewahrung des primären Backups.	Cron-Ausdruck; Go-Dauer
inv_velero.operations_backup_2.enable	Aktiviert einen zweiten globalen Sicherungsplan.	true oder false
inv_velero.operations_backup_2.backup_storage_location	Logischer Name des zweiten S3-Ziels.	Vorhandener location_name
inv_velero.operations_backup_2.schedule / ttl	Zeitplan und Aufbewahrung des zweiten Backups.	Cron-Ausdruck; Go-Dauer
inv_velero.exclude_namespaces[]	Namespaces, die nicht gesichert werden.	Liste vorhandener Namespace-Namen
inv_velero.backup_storage_locations[].location_name	Interne Kennung eines S3-Ziels.	Eindeutiger Name ohne automatisch angehängtes -backup
inv_velero.backup_storage_locations[].endpoint	S3-kompatibler Endpunkt.	Vollständige URL
inv_velero.backup_storage_locations[].bucket	Bucket des Backupziels.	Vorhandener Bucketname
inv_velero.backup_storage_locations[].region	Region des S3-Ziels.	Exakter Anbieterwert
inv_velero.backup_storage_locations[].access_key / secret_key	Zugang des technischen Backupkontos.	Secrets mit minimalen Bucket-Rechten
inv_velero.backup_storage_locations[].s3ForcePathStyle	Erzwingt Pfadstil für kompatible S3-Dienste.	"true" oder "false" nach Anbietervorgabe

Replikate der Plattformkomponenten

inv_replicas übersetzt das gewählte Betriebsprofil in die tatsächliche Anzahl zustandsbehafteter und zustandsloser Instanzen.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_replicas.keycloak.db / keycloak.app	Instanzen der Keycloak-Datenbank und -Anwendung.	Positive Ganzzahlen
inv_replicas.gravitee.api_mgmt / gravitee.gateway	Replikate des Legacy-Gravitee-Pfads.	Positive Ganzzahlen
inv_replicas.api_mgmt.apisix / api_mgmt.etcd	Replikate von APISIX und dessen etcd.	Positive Ganzzahlen
inv_replicas.frost.db / frost.mqtt / frost.http	Datenbank-, MQTT- und HTTP-Instanzen von FROST.	Positive Ganzzahlen
inv_replicas.timescale.db	Instanzen der mandantenbezogenen TimescaleDB.	Positive Ganzzahl
inv_replicas.cm.api_gateway	Replikate des Stellio-API-Gateways.	Positive Ganzzahl
inv_replicas.cm.kafka	Replikate der internen Stellio-Kafka-Laufzeit.	Positive Ganzzahl passend zum Kafka-Quorum
inv_replicas.cm.postgresql	Instanzen der Stellio-Datenbank.	Positive Ganzzahl
inv_replicas.cm.search_service	Replikate des Stellio-Suchdienstes.	Positive Ganzzahl
inv_replicas.cm.subscription_service	Replikate des Stellio-Subscription-Dienstes.	Positive Ganzzahl

HYPERSENSUS

Die mandantenübergreifende Oberfläche wird nach den einzelnen Mandanten installiert und verwendet deren Identitäten und Datenbankverbindungen.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_hypersensus.enable	Aktiviert HYPERSENSUS.	true oder false
inv_hypersensus.version	Gemeinsamer Image-Tag von Frontend und Backend.	Freigegebener Versions-Tag
inv_hypersensus.backend_flask_secret	Optional vorgegebener stabiler Backend-Schlüssel.	Starkes Secret; wird sonst erzeugt
inv_hypersensus.frontend.common_url	Gemeinsamer öffentlicher Hostname.	Hostname ohne Protokoll; leer deaktiviert den gemeinsamen Einstieg
inv_hypersensus.frontend.nextauth_secret	Optional vorgegebener stabiler NextAuth-Session-Schlüssel.	Starkes Secret
inv_hypersensus.frontend.tenant_dropdown_enabled	Zeigt die Mandantenauswahl am gemeinsamen Einstieg.	true oder false
inv_hypersensus.registry.username / password	Zugang zu privaten HYPERSENSUS-Artefakten.	Deploy Token oder leer bei öffentlich erreichbaren Artefakten
inv_hypersensus.proxy.http / proxy.https / proxy.no_proxy	Optionaler komponentenspezifischer Proxy.	Proxy-URLs und kommagetrennte Ausnahmen

Optionaler GitLab Runner

Dieser globale Dienst ist kein notwendiger Bestandteil einer Standardinstallation und wird nur für bewusst integrierte CI/CD-Szenarien aktiviert.

Inventory-Pfad	Bedeutung	Erwarteter Wert
inv_gitlab_runner.enable	Installiert einen GitLab Runner im Cluster.	true oder false
inv_gitlab_runner.ns_name	Namespace des Runners.	DNS-konformer Namespace
inv_gitlab_runner.token	Runner-Token des vorgesehenen GitLab-Projekts oder der Gruppe.	Geschütztes Token
inv_gitlab_runner.url	Adresse der zugehörigen GitLab-Instanz.	Vollständige HTTPS-URL