p2d2 und CIVITAS/CORE

p2d2 läuft heute als Standalone-Anwendung auf eigener Proxmox-Infrastruktur. Parallel dazu wird geprüft, wie sich p2d2 als Plugin in CIVITAS/CORE integrieren lässt - die gemeinsame, Kubernetes-basierte Plattform des CIVITAS/CORE-Netzwerks. Die folgende Grafik stellt beide Betriebsarten gegenüber:

Architekturvergleich: p2d2 Standalone (Proxmox, Hetzner) versus p2d2 als CIVITAS/CORE-Plugin (Kubernetes-Cluster)

Die Komponenten im Einzelnen

Im Standalone-Betrieb besteht p2d2 aus sechs Komponenten, die als LXC-Container bzw. VMs auf dem Proxmox-Server laufen. Bei einer Integration in CIVITAS/CORE unterscheiden sich diese Komponenten grundlegend danach, ob sie sich unverändert als eigener Pod im Cluster abbilden lassen, oder ob sie durch bereits vorhandene CORE-Kernkomponenten ersetzt werden müssen.

Neu aufzubauen: 1:1 als eigener Pod

Diese Komponenten existieren im CIVITAS/CORE-Cluster noch nicht. Sie würden dieselbe Codebasis wie im Standalone-Betrieb behalten und lediglich als Kubernetes-Deployment statt als LXC laufen:

  • Frontend/Hub (AstroJS) - liefert die WebGIS-Oberfläche aus und steuert die Synchronisation zwischen Verwaltungsdaten und OpenStreetMap. Im Cluster: Deployment mit Ingress, gleiche Codebasis wie im Standalone-Betrieb. Da es keine Abhängigkeit zu einer CORE-Kernkomponente gibt, ist dies die Komponente mit dem geringsten Integrationsaufwand - im Wesentlichen Containerisierung und Anpassung der Umgebungsvariablen.
  • Mapproxy - cacht Kachel- und OGC-Dienste vor den eigentlichen GeoServer- und Tileserver-Backends und reduziert so Last und Latenz. Im Cluster: Deployment mit persistentem Volume (PVC) für den Tile-Cache. Ebenfalls unverändert übertragbar, da Mapproxy keine CORE-spezifische Gegenstelle hat.

Integration in bestehende Kernkomponenten

Diese Komponenten haben in CIVITAS/CORE ein Gegenstück, das bereits als gemeinsam genutzte Kernkomponente im Cluster läuft. Statt eine eigene Instanz mitzubringen, müsste p2d2 sich an die vorhandene Komponente anbinden:

  • Authentifizierung: Zitadel → Keycloak - im Standalone-Betrieb meldet sich p2d2 über Zitadel als eigenen Identity Provider an (OIDC Authorization Code Flow mit PKCE). In CIVITAS/CORE übernimmt Keycloak diese Rolle als zentrale CORE-Kernkomponente für alle Addons. Die Integration erfordert keinen neuen IAM-Betrieb, sondern eine OIDC-Anbindung an Keycloak: Client-Registrierung, Anpassung des Discovery-Endpunkts und Übertragung der p2d2-Rollen (editor, qs1_reviewer, qs2_reviewer, export_admin) in das Keycloak-Rollenmodell.
  • GeoServer - stellt die WMS-, WFS- und WFS-T-Schnittstellen bereit, über die die Editoren Geometrien lesen und transaktional schreiben. GeoServer ist ebenfalls eine CORE-Kernkomponente (Deployment mit PVC). Eine Integration bedeutet, dass p2d2 nicht mit einer eigenen GeoServer-Instanz arbeitet, sondern eigene Workspaces/Layer innerhalb des bestehenden CORE-GeoServers erhält - inklusive Klärung von Zugriffsrechten und Schema-Trennung gegenüber anderen Addons.
  • PostgreSQL/PostGIS - hält Stammdaten, Versionen und die Workflow-Tabellen des Session-Modells. In CIVITAS/CORE läuft die Datenbank über einen CloudNativePG-Operator als Kernkomponente. p2d2 müsste sein Schema in diese gemeinsam betriebene Instanz überführen, statt - wie im Standalone-Betrieb - ein eigenes LXC mit PostgreSQL/PostGIS zu betreiben.

Kein p2d2-Migrationsthema: der OSM-Tileserver

Der OSM-Tileserver, der die Kartenkacheln für die OpenStreetMap-Basiskarte liefert, ist im Standalone-Betrieb als eigene VM aufgebaut, aber noch nicht produktiv geschaltet - die Aufteilung des verfügbaren SSD-Speichers zwischen Mapproxy und Tileserver ist noch nicht final entschieden. Im CIVITAS/CORE-Szenario ist er als vereinsweiter, gemeinsam genutzter Dienst mit eigener PostgreSQL/PostGIS-Instanz außerhalb des Kubernetes-Clusters vorgesehen. Er ist damit kein Bestandteil der p2d2-Migration.

Offene Frage: Masterportal

CIVITAS/CORE sieht standardmäßig Masterportal als Geoportal-Komponente vor. Ob p2d2 dieses Masterportal nutzen muss oder mit seinem AstroJS-Frontend als eigenständige Präsentationsschicht betrieben werden kann, ist noch nicht abschließend mit den CIVITAS/CORE-Verantwortlichen geklärt.

Weiterführende Dokumentation

Eine ausführlichere Beschreibung der Server-Architektur findet sich im Administrationshandbuch. Diese Seite wird derzeit überarbeitet, um den aktuellen Stand (insbesondere Zitadel statt der dort früher beschriebenen Ory-Komponenten) sowie die CIVITAS/CORE-Perspektive abzubilden.