Wer macht sich eigentlich die ganze Arbeit?

Mein ursprünglicher Ansatz für dieses Projekt war ziemlich einfach:
Ich wollte lediglich meine Erfahrungen teilen.

Deshalb habe ich bewusst auf ausführliche Anleitungen oder Codebeispiele verzichtet. Der Grund dafür ist simpel: Ich sehe mich selbst nicht als Experten und wollte vermeiden, falsche Empfehlungen zu geben.

Während der Tests und der Konfiguration wurde mir jedoch etwas klar:
Kaum jemand wird den kompletten Aufwand betreiben, nur um am Ende ein paar potenziell hilfreiche Tools zu haben – die für sich genommen noch nicht einmal eine vollständige Lösung darstellen.

Also musste ein neuer Ansatz her.

Ein neuer Ansatz

Das Projekt basiert bereits auf Docker-Compose-Dateien. Diese lassen sich relativ einfach anpassen und auch direkt mit entsprechenden Befehlen starten. In der Praxis gibt es jedoch ein Problem: Einige Container benötigen zusätzliche Dateien oder Ordnerstrukturen, damit sie korrekt funktionieren.

Um den Einstieg deutlich einfacher zu machen, werde ich deshalb künftig alle benötigten Dateien bündeln:

• Docker-Compose-Dateien
• notwendige Konfigurationsdateien
• erforderliche Ordnerstrukturen

Alles wird gemeinsam in einem ZIP-Archiv bereitgestellt.

Das bedeutet für euch:

1. ZIP-Datei herunterladen
2. lokal entpacken
3. mit docker compose den Server starten

Damit sollte es deutlich einfacher werden, das Setup auszuprobieren oder weiter anzupassen.

Änderungen beim Reverse Proxy

Im Zuge dieser Umstrukturierung habe ich auch den Reverse Proxy gewechselt.

Ursprünglich lief das Setup über Nginx Proxy Manager. In einer klassischen Serverumgebung funktioniert das auch gut. Innerhalb eines Docker-Compose-Setups stößt man jedoch relativ schnell an Grenzen, wenn neue Dienste oder Domains dynamisch hinzukommen.

Der Hauptgrund:
Nginx lässt sich in diesem Szenario nicht besonders komfortabel mit zukünftigen Domains oder Weiterleitungen konfigurieren, ohne die Konfiguration ständig manuell anzupassen.

Deshalb wird Nginx Proxy Manager komplett durch Traefik ersetzt.

Traefik ist deutlich stärker auf Container-Umgebungen ausgelegt. Die Konfiguration erfolgt direkt über Labels in den Docker-Containern. Dadurch können Domains, Weiterleitungen und Routing-Regeln unmittelbar im Compose-Setup definiert werden.

Das hat mehrere Vorteile:

• neue Dienste können direkt im Compose-File konfiguriert werden
• keine separate Proxy-Konfiguration notwendig
• automatische Erkennung von Containern
• deutlich besser geeignet für dynamische Setups

Gerade für ein Projekt, das möglichst einfach reproduzierbar sein soll, ist das deutlich praktischer.

Änderungen bei den Komponenten

Im Zuge dieser Umstrukturierung habe ich mich außerdem entschieden, zunächst auf Budibase zu verzichten.

Auch wenn Budibase später wahrscheinlich wieder integriert wird, liegt der Fokus im Moment darauf, die grundlegenden Funktionen stabil zum Laufen zu bringen.

Für die Datenhaltung setze ich aktuell stattdessen auf PostGIS.

PostGIS ist praktisch der Standard für georeferenzierte Datenbanken. Dadurch ergeben sich mehrere Vorteile:

• Daten können direkt mit Leaflet in Webanwendungen genutzt werden
• dieselben Daten lassen sich problemlos in QGIS analysieren und bearbeiten
• räumliche Abfragen und Geodaten-Operationen sind direkt in der Datenbank möglich

Damit bleibt das System flexibel und sowohl für Web-Anwendungen als auch für klassische GIS-Tools nutzbar.

Fazit

Der ursprüngliche Plan war, einfach ein paar Erfahrungen zu dokumentieren.
Inzwischen entwickelt sich daraus eher ein reproduzierbares Setup, das sich relativ einfach starten und testen lässt.

Ob daraus am Ende ein wirklich nützliches System wird, wird sich zeigen.
Aber zumindest soll der Einstieg künftig deutlich weniger Arbeit machen als bisher.