Zielbild und Abgrenzung

Diese Seite beschreibt das Zielbild der statischen, versionierten und imagebasierten Masterportal-Konfiguration für CIVITAS/CORE V1 sowie die Abgrenzung zu anderen Vorhaben.

Ausgangslage

Die Masterportal-Konfiguration wird derzeit über eine RustFS-/S3-basierte Ablage bereitgestellt. Betroffen sind die drei Masterportal-Dateien:

• config.json
• services.json
• rest-services.json

Die lokale RustFS-LXC ist damit aktuell eine zwingende Voraussetzung für die Auslieferung dieser Konfiguration.

Ziel

Die fachlichen Portal-Konfigurationen sollen unabhängig von der lokalen RustFS-/S3-Ablage ausgeliefert werden können. Ziel ist eine statische, versionierte und imagebasierte Masterportal-Konfiguration, die sich reproduzierbar bereitstellen und überprüfen lässt.

Architekturprinzipien

Die Zielvariante folgt diesen Prinzipien:

• reproduzierbar – identische Konfiguration führt zu identischem Ergebnis,
• versioniert – jede Änderung ist einer Version und deren Historie zuordenbar,
• reviewbar – Änderungen sind vor der Auslieferung prüfbar,
• überprüfbar – der ausgelieferte Zustand ist verifizierbar,
• rückbaubar – ein vorheriger Zustand ist wiederherstellbar,
• keine verdeckten manuellen Infrastrukturzustände – die Bereitstellung ist nachvollziehbar und nicht von nicht dokumentierten Handgriffen abhängig.

Klarstellung zu S3

S3 wird durch diese Spezifikation nicht als generelle Technologie ausgeschlossen. Die lokale RustFS-LXC darf jedoch keine zwingende Voraussetzung für die Zielvariante sein. Für V1s ist diese Entscheidung inzwischen getroffen: RustFS/S3 wird nicht mehr verwendet; Grund ist, der p2d2-AddOn-Zielgruppe keine zusätzliche, dauerhaft zu betreibende RustFS-Instanz aufzubürden.

Dabei sind zwei Ziele zu unterscheiden, die im ursprünglichen Text vermischt waren:

• (a) reproduzierbare, versionierte Konfiguration — grundsätzlich auch mit S3 plus Git-Sync lösbar gewesen,
• (b) die RustFS-LXC als Infrastruktur-Abhängigkeit eliminieren — der maßgebliche Grund für den imagebasierten Weg.

(b) ist der maßgebliche Treiber der V1s-Entscheidung.

Nichtziele

Ausdrücklich nicht Bestandteil dieses Vorhabens:

• keine p2d2-AddOn-Implementierung – das AddOn wird in einer eigenen Spezifikation beschrieben,
• keine Änderung der V2-Architektur – CIVITAS/CORE V2 ist ein eigenständiges, späteres Vorhaben,
• keine pauschale Migration bestehender kommunaler Plattformen – eine Migration erfolgt nur im Rahmen eines definierten, kompatibilitätsgeprüften Verfahrens.

Offene Entscheidungen

Die folgenden Punkte sind noch nicht entschieden und werden als offene Fragen geführt:

• kontrollierter Geoportal-Components-Fork beziehungsweise dessen Nachfolgeartefakt (beantwortet: Soft-Fork nach Upstream-README-Verfahren, kein Vollfork mit eigener CI nötig),
• genaue Image-Build- und Release-Verantwortung (beantwortet für den Testfall: lokaler Build + lokaler containerd-Import, kein Registry-Betrieb bei Single-Node-k3s),
• genaue Inventory-Felder (beantwortet: inv_gd.portal_backend.image_repository/image_tag, s3_backend.enable: false),
• Anzahl und Zuordnung von portal-backend-Deployments zu Masterportal-Instanzen,
• mögliche Koexistenz bestehender S3- und neuer statischer Konfigurationen (entschieden: S3/RustFS wird für V1s nicht mehr genutzt, siehe ai-runs/2026-08-26-civitas-v1s-s3-entfernen),
• Konfigurations-Lifecycle einer späteren p2d2-Masterportal-Instanz: Abgrenzung zwischen Build-Time-Artefakten, Deployment-Time-Konfiguration, schnell aktualisierbarer Instanzkonfiguration und sensiblen Werten. Insbesondere müssen config.js, config.json, services.json und rest-services.json in diesem Lifecycle fachlich und technisch eingeordnet werden. Die konkrete Bereitstellung dieser Dateien (etwa über Images, ConfigMaps, Volumes oder Object-Storage) ist noch nicht entschieden.