Mail und Registries

Gemeinsamen Mailversand und die Bezugsquellen der Container-Images festlegen.

← Zur Übersicht der Plattformkonfiguration

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.

Konfigurationsfelder

Diese Felder gehören zu den globalen Blöcken außerhalb von inv_tenants. Verwenden Sie die vollständige Vorlage des ausgewählten Releases; optionale und mitgeführte Kompatibilitätsfelder sind in der Tabelle gekennzeichnet.

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