Zum Hauptinhalt springen

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 durch das Konfigurationsmodell und verlinkt die einzelnen Bereiche des Standardpfads. Alle globalen Felder werden direkt auf der jeweils zugehörigen Konfigurationsseite erläutert.

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.

Plattformdienste konfigurieren​

Bearbeiten Sie die folgenden Bereiche in der angegebenen Reihenfolge. Die Einstellungen gelten gemeinsam für alle Mandanten; verwenden Sie jeweils die vollständigen Blöcke aus der Vorlage des gewählten Releases.

Optionale Dienste und Bestandsinstallationen​

Der GitLab Runner wird nur bei einem vorgesehenen CI/CD-Szenario benötigt. Legacy-Felder dienen ausschließlich der Einordnung bestehender Inventories.

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 ...
FeldVerwendungWas Sie festlegen
tenant_prefixPräfix für Kubernetes-Namespaces und technische Ressourcennamenkurze, eindeutige und dauerhaft stabile Kennung des Mandanten
tenant_realmName des Keycloak-Realm und fachliche Mandantenidentitäteindeutigen Realm-Namen ohne URL verwenden
display_namelesbarer Name in Oberflächen und mandantenbezogenen Konfigurationenoffizieller Anzeigename, beispielsweise Stadt Beispiel
tenant_domainBasisdomain der öffentlich erreichbaren Mandantenendpunktevorhandenen DNS-Namen ohne https:// und ohne Pfad
mailserver.*SMTP-Konfiguration dieses Mandantenim 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.

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.