Serveraufbau V1s

Dieser Bereich spezifiziert den Serveraufbau für die V1s-Buildvariante: CIVITAS/CORE V1 mit statischer statt S3-basierter Masterportal-Konfiguration. Die Masterportal-Konfiguration wird dabei nicht mehr zur Laufzeit aus RustFS/S3 geladen, sondern als versioniertes Artefakt direkt in das Portal-Backend-Image gebaut.

Grundlage ist das Vorhaben CIVITAS/CORE V1: Statische Masterportal-Konfiguration. Die vorliegende Spezifikation leitet sich weitgehend aus dem bestehenden Serveraufbau V1 ab und beschreibt ausschließlich die Abweichungen.

Unverändert gegenüber V1

Die folgenden Bereiche des V1-Serveraufbaus gelten für V1s unverändert:

Bereich	Verweis	Hinweis
VM-Sizing und Host-Ressourcen	VM-Sizing und Host-Ressourcen	keine Änderung für V1s
Netzwerk, DNS und TLS	Netzwerk, DNS und TLS	keine Änderung für V1s
Kubernetes-Laufzeit (k3s)	Kubernetes-Laufzeit	keine Änderung für V1s
IDM-Provisionierung und Login	IDM-Provisionierung und Login	keine Änderung für V1s
E2E-Testumgebung	E2E-Testumgebung	keine Änderung für V1s

Geändert gegenüber V1

Gegenüber dem V1-Serveraufbau ändern sich zwei Aspekte, die in eigenen Unterseiten spezifiziert sind:

• Portal-Backend-Image-Build — lokaler Soft-Fork-Build des geoportal_backend-Images mit statisch eingebauter Masterportal-Konfiguration
• Inventory-Delta — die gegenüber dem V1-Inventory geänderten Felder

Weitere Abweichungen gegenüber V1

Über die beiden oben genannten Aspekte hinaus unterscheidet sich V1s in drei Punkten, die im erfolgreichen Testlauf vom 2026-08-31 sichtbar wurden:

• Monitoring: Monitoring ist in beiden Varianten aktiv. In V1s installiert 05_addons.sh zusätzlich die Prometheus-Operator-CRDs vorab (install_prometheus_operator_crds(), Version v0.89.0). Grund: Das Live-Playbook führt das Monitoring-Play nicht zuverlässig vor der APISIX-Installation aus. APISIX rendert metrics.serviceMonitor.enabled: true bedingungslos und benötigt daher die ServiceMonitor-CRD bereits vor dem APISIX-Helm-Install.
• inv_access.apis.import: V1s setzt den Wert explizit auf true. Das ist nötig für die Apisix-Routen der Geodata-Kernkomponenten, insbesondere portalBackend. Die cc_cli validate-Regel „Prometheus und Loki aktivieren, wenn APIs importiert werden“ wird über den zweiten ODER-Zweig erfüllt, weil das Monitoring aktiv ist.
• Containerd-Namespace: Der lokale Image-Import nutzt k3s ctr -n k8s.io images import -. Ohne -n k8s.io läge das Image im Containerd-Namespace default und wäre für kubelet unsichtbar. Der Punkt ist V1s-spezifisch, weil V1 keinen lokalen Image-Build kennt.

Der lokale Image-Build selbst ist in Portal-Backend-Image-Build beschrieben und hier nicht erneut ausgeführt.

Explizit nicht Gegenstand

• Frontend-Image-Rebuild: Das Masterportal-Frontend bleibt das unveränderte Original-Upstream-Image (geoportal). Seine Konfiguration wird weiterhin zur Laufzeit über Umgebungsvariablen parametrisiert; ein Rebuild ist für V1s nicht erforderlich.
• RustFS-Deinstallation: RustFS/S3 bleibt als Dienst der Plattform bestehen. Für die V1s-Instanz wird die S3-Anbindung lediglich deaktiviert; eine Deinstallation des Dienstes ist ausdrücklich nicht Gegenstand dieser Spezifikation.