Zum Hauptinhalt springen

Mandanten konfigurieren

Auf der Seite Plattformbasis konfigurieren wurden Identität, Domain, Präfix und Mailserver jedes Mandanten angelegt. In diesem Schritt werden unter dem jeweiligen Eintrag die benötigten Datenpfade und Anwendungen ergänzt und konfiguriert.

Verwenden Sie dafür immer die vollständigen Komponentenblöcke aus dem default_inventory.yml des ausgewählten Releases. Die Beispiele auf dieser Seite erklären die entscheidenden Felder, ersetzen aber nicht die versionsgebundene Vorlage.

Die globalen Werte des Inventory werden auf den Fachseiten unter Plattformbasis konfigurieren beschrieben. Auf dieser Seite stehen ausschließlich die mandantenbezogenen Komponenten und ihre Konfiguration im Mittelpunkt.

Grundprinzip​

Ein Komponentenblock liegt immer innerhalb des betreffenden Listeneintrags:

inv_tenants:
  - tenant_realm: "stadt"
    display_name: "Stadt Beispiel"
    tenant_domain: "platform.example.org"
    tenant_prefix: "stadt"
    hypersensus_domain: "portal.platform.example.org"

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

    idm:
      enable: true

    timescale:
      enable: true
      # ... Komponentenkonfiguration ...

    stellio:
      enable: true
      # ... Komponentenkonfiguration ...
FeldBedeutungErwarteter Wert
tenant_realmstabiler Name des Keycloak-Realm und fachliche Mandantenkennungeindeutiger Realm-Name ohne URL
display_namelesbarer Anzeigename in gemeinsamen Oberflächenoffizieller Name des Mandanten
tenant_domainBasisdomain der mandantenbezogenen EndpunkteHostname ohne https:// und Pfad
tenant_prefixPräfix der Kubernetes-Namespaces und technischen Ressourcenkurze, eindeutige und dauerhaft stabile Kennung
hypersensus_domainoptional abweichender HYPERSENSUS-Hostname dieses MandantenHostname ohne Protokoll; Feld weglassen oder leer lassen, um tenant_domain zu verwenden
mailserver.*Mailkonto dieses Mandantenim Standard die fünf Werte aus inv_email; nur bei einem eigenen Mandantenkonto abweichend setzen

Ein direkt unter einer Komponente stehendes enable nimmt diese Komponente in den Rollout auf oder überspringt sie. Das spätere Umschalten auf false deinstalliert keine bereits vorhandenen Ressourcen.

enable_logical_backup wirkt dagegen immer auf den Datenbank-Cluster der jeweiligen Komponente. Alle so aktivierten logischen Backups verwenden gemeinsam das unter inv_op_stack.postgres_operator.logical_backup konfigurierte globale S3-Ziel des PostgreSQL-Operators. Richten Sie dieses Ziel vollständig ein, bevor Sie den Schalter bei PostgreSQL, Stellio, FROST, Superset, CKAN oder der Geo-Datenbank aktivieren.

Komponenten konfigurieren​

Wählen Sie zunächst den Aufgabenbereich, den der Mandant tatsächlich benötigt. Die Kategorie-Seiten zeigen nur die dazugehörigen Komponenten mit ihren Inventory-Ausschnitten, Parametern und direkten Voraussetzungen. Dadurch bleibt die Auswahl getrennt von der globalen Plattformbasis und von nicht benötigten Komponenten.

4 Komponenten

Kontext und IoT

Kontextdaten, Sensorwerte und ihre Historisierung bereitstellen.

Stellio · QuantumLeap · Context Hoster · FROST-Server

Inventory-Konfiguration öffnen
5 Komponenten

Geodaten

Geoportale, Karten, Geodienste und Druckausgaben konfigurieren.

GeoStack · Masterportal · Geoportal-Backend · GeoServer · MapFish Print

Inventory-Konfiguration öffnen

Nicht für Neuinstallationen verwenden​

Das Repository enthält weiterhin Legacy-Pfade für:

  • Orion Context Broker unter fiware.enable
  • Gravitee API Management unter apim.enable

Diese Pfade dienen bestehenden Installationen und Migrationen. Für neue Plattformen sind Stellio und APISIX vorgesehen. Aktivieren Sie Legacy- und Zielpfad nicht parallel, sofern dies nicht ausdrücklich in einem Migrationskonzept vorgesehen ist.

Damit auch diese im Default-Inventory enthaltenen Felder vollständig nachvollziehbar bleiben, zeigt die folgende Referenz ihren Aufbau:

fiware:
  enable: false
  mongo:
    initdb_database: "orion"
    initdb_root_username: "<secret>"
    initdb_root_password: "<secret>"
  orion:
    mongodb_user: "<secret>"
    mongodb_password: "<secret>"

apim:
  enable: false
FeldBedeutungVerwendung
fiware.enableaktiviert den bestehenden Orion-/MongoDB-Pfadnur für Bestandsinstallationen und geplante Migrationen
fiware.mongo.initdb_databaseinitiale MongoDB-Datenbank von Orionstabiler Datenbankname
fiware.mongo.initdb_root_username / initdb_root_passwordinitialer administrativer MongoDB-ZugangSecrets
fiware.orion.mongodb_user / mongodb_passwordAnwendungszugang von Orion zur MongoDBgetrennte Secrets
apim.enableaktiviert den bestehenden Gravitee-Pfadnur für Bestandsinstallationen und geplante Migrationen

Vor dem Rollout prüfen​

  • Jeder aktivierte Komponentenblock stammt aus dem default_inventory.yml des verwendeten Releases.
  • Secrets, Imagezugänge, Domains und Storagewerte sind vollständig gepflegt.
  • Benötigte Operatoren und globale Plattformdienste sind aktiviert.
  • Nicht benötigte Standardkomponenten wurden bewusst deaktiviert.
  • Das Inventory wurde wie unter Inventory validieren beschrieben geprüft.

Der vollständige Erst-Rollout und die Ansible-Tags für spätere selektive Runs werden im nächsten Schritt unter Plattform ausrollen beschrieben.