Herzlich willkommen hier im Hörsaal 3 am 2. Tag der FOSKIS 2023 aus Berlin-Atlas-Hof. Ich bitte ein bisschen mehr um Ruhe im Saal, danke. Den Geo-Server, den kennen wahrscheinlich alle.

Und die Frage ist, wie kann man die Vorteile des Geo-Servers mit modernen Techniken verknüpfen? Es gibt inzwischen die Geo-Server Cloud und zwar gibt es sie inzwischen auch im Produktiv-Einsatz. Und die Erfahrung mit dem Produktiv-Einsatz, die stellt uns jetzt André Borgi vor.

Ja, danke vielmal. Guten Tag, mein Name ist André Borgi, ich arbeite für Camp2Camp Geo Special Solutions. Heute wollte ich ein bisschen eine Einführung geben, für was Geo-Server Cloud ist. Aber zuerst, wer kennt schon Geo-Server, wer benutzt Geo-Server hier im Saal?

Okay, ziemlich viele Leute. Und wie viele von euch haben das wollen, vielleicht mehr als einen Instanz vom Geo-Server haben? Habt ihr Probleme damit gekriegt? Nicht mehr? Nein, jetzt haben wir...

Geo-Server Cloud ist ein Side-Projekt vom Geo-Server, der wir gestartet haben letztes Jahr. Und es ist eine geoserverbasierte Spring Boot Anwendung.

Das heißt, wir benutzen die Spring Boot Library, um das alles mit der Spring Cloud Framework als Distributed System zu machen. Das heißt, Geo-Server ist hier wie eine Library benutzt und es ist eine komplett neue Anwendung.

Ich beschreibe die Anwendung ein bisschen später besser. Das Vorteil ist, dass es ist nativ für Distributeden waren, mit horizontaler Skalierbarkeit gedacht. Es ist DevOps-friendly, wie ich es nenne. Wir haben auch einen Helmshot gemacht, den ich heute auch präsentiere.

Das Vorteil ist, dass die Config, die Datadare, für die, die das kennen, effizient geteilt wird. Jede Update vom Layer 3 ist synchron auf alle Instanz geschickt.

Das ist normalerweise ein Problem mit einem normalen Geo-Server, wo man einen Restart machen muss. Es ist ein bisschen cumbersome, wie sagt man auf Deutsch, mit Geo-Server viele Instanz von Geo-Server im Parallel zu haben.

Das war unser Problem und das, was wir hier vielleicht für euch auch gelöst haben. Es ist Geo-Server, es ist nicht die Funktionalität und das sind die für die von Geo-Server. Die Rest-API, die WebUI, alle die guten Sachen und die schlechten Sachen vom Geo-Server sind die gleichen.

Wir lösen nicht die Probleme vom Geo-Server, aber wir lösen ein Problem, das ist das Distributed-System. Wir haben eine Wahl gemacht, deswegen habe ich Opinionete geschrieben. Wir haben eine Wahl gemacht, für welche Extension bis jetzt supportiert sind.

Man muss ein bisschen aufmerksam sein, auf welche Integration von den gewissen Plugins wir schon gemacht haben. Verschiedene werden wir nicht nehmen, das ist ein bisschen eine Diskussion, aber wir bauen die Community.

Dieses Projekt ist sehr jung, wir nehmen auch viele Inputs an. Es ist gedacht für die Klaus, es kommt schon gepackt im Docker-Container mit seinem L-Chart, ein Docker-Komposer, es gibt alles um das zu installieren, wie es jetzt besser geht.

Wie gesagt, bei Design ist es skalierbar. Gerade jetzt haben wir schon verschiedene Projekte, die wir kennen, aber ich habe vorgestern einen Release von der Chart gemacht und ich habe direkt Issues gehabt auf GitHub 1, es funktioniert nicht mehr, das heißt andere Leute benutzen es schon auch, die ich nicht kenne.

Die ich kenne, die sind da. Das nächste ist der Input-Geben, das ist eine neue National-Alarm-Zentrale für Frankreich, die wir benutzen.

Das war das erste Input um GeoServer Cloud zu entwickeln. Das sind die ersten Sponsoren, würde ich sagen. Dann haben wir sehr viel mit einer großen schweizerischen Reinsurance-Kompanie gearbeitet, die ich nicht nennen darf.

Sie hatten eine große Instanz von 40 Instanzen von GeoServer im Parallel mit einer sehr komplizierten Umgebung und wir haben die Migration von GeoServer Cloud für euch gemacht. Das war auch ein sehr interessantes Projekt.

Das Deutsche Telekom gerade jetzt, Kanton Nargau in der Schweiz, die waren die erste in Produktion mit GeoServer Cloud. In der Kanton Nargau, das war sehr gut. Und wir haben in Veolia und Kachatoa immer mehr Leute gekommen, das ist gut.

Es ist ein Projekt, der auch auf GitHub im GeoServer-Organisation steht. Wir haben das dort doniert. GitHub GeoServer, das Hauptprojekt GeoServer und sein kleiner Bruder, GeoServer Cloud, steht auch dort. Und wir haben das doniert auf OSGeo.

Es ist auch die gleiche Lizenz, GPL3. Es ist komplett open source, frei. Und das ist vielleicht eine wichtige Slide. Das ist das Konzept jetzt. Es ist so geteilt, dass wir haben jedes Pod hier.

Jeder blaue Kreis hier ist ein verschiedener Pod oder Container. Und jeder von denen bedient nur eine API. Zum Beispiel, wir haben das Service für das WPS, das Service für das WMS, ein für die Rest-API und so weiter.

Und die Intelligenz, die alles da so orchestriert ist, basiert, wie gesagt, auf Spring Cloud Framework. Und wir haben diese Gateway, die ein intelligenter Proxy ist, die einfach das Http-Rooting macht auf alle die verschiedenen Pods.

Okay, das sollte auf den WMS Pod gehen, schickt das um WMS und so weiter. Können Sie das ein bisschen... Ist das besser so? Ja genau, das war ein bisschen eco. Sorry, danke vielmal.

Und das ist das für das Rest-Rooting. Und dann wir haben hier auf links das Discovery und Configuration, Caching, all diese Sachen. Und das ist, wissen wo die Magie steht, weil wir benutzen in diesem Fall RabbitMQ, aber wir könnten auch Kafka oder andere Engine benutzen,

um die interne Events vom Geo-Server zu teilen auf die anderen Pods. Das heißt, wenn ich eine neue Layer speichere, eine Web-UI oder ich schicke ein Rest-Request auf die Rest-API, ich habe ein neues Layer oder ein Delete, irgendetwas, irgendeine Interaktion, wird das Pod vom Rest-API diese Abfrage nehmen,

die Konfiguration ändern und das Div von der Konfiguration auf alle die anderen Instanz als Asynchron-Message schicken. Aber es ist normalerweise in einigen Millisekunden propagiert auf die ganze Sache.

Das heißt, wir haben viele Pods, die wie eine Anwendung arbeiten. Und es läuft wahnsinnig gut. Wir waren erstaunt, wie gut das geht. Ich zeige das ein bisschen.

Wie gesagt, wir brauchen keine Deintan zu haben, wenn wir eine Änderung machen, bis wann es zur Verfügung ist. Das heißt, wie man einen Instanz von einem monolithischen Geo-Server benutzt. Für den User ist es das gleiche. Es fühlt sich nicht an, ich muss das dort schicken und dann nach einer halben Stunde wird das Geo-Server neu gestartet und ich kann das haben.

Es gab einen Plugin, in dem ich nicht mehr weiß, wie das heißt, der das ein bisschen machte. Aber hier profitieren wir vom Spring-Boot-Framework. Das ist ein riesiges Framework. Es ist echt eine gute Gelegenheit, das zu benutzen.

Es ist sehr einfach, solche Sachen mit Spring-Boot zu schreiben. Ich war erstaunt, dass die Entwicklung schnell gegangen war. Es kommt in einen Container jede kleine Anwendung, also sein eigenes Container. Sein eigenes Code-Basis, sein eigenes Container. Es sind sehr viele kleine Microservices.

Ihr könnt alles herunterladen auf Docker Hub. Wir machen verschiedene Security-Scans auf GitHub, auf Docker Hub und so weiter. Wir probieren das so gut wie möglich auf Sicherheitsgründen zu haben, zu pflicken.

Es ist auch so skalierbar, das ist logisch, ich habe das schon erklärt. Die Idee ist, dass man für jeden Service auch wählen kann. Für die WMS brauche ich ein bisschen mehr Rahmen. Ich kann einfach nur die Post vom WMS ein bisschen größer haben in meiner Komposition.

Oder viel mehr von diesem Service haben. Das kann man komplett unabhängig zwischen den verschiedenen Services machen. Das ist gut, denn normalerweise hat man nicht genau die gleiche Traffic, je nach Bedarf, für die verschiedenen Kunden.

Das kannst du sehr einfach konfigurieren beim Deployment. Das ist vielleicht ein kleiner Überblick von einer normalen Spring Cloud-Anwendung.

Das ist ein Beispiel vom Spring, aber wir benutzen genau das Beispiel. Die Struktur ist genau die gleiche. Wir haben die Kunden links für euch.

Dann haben wir das API Gateway, dieses intelligente Router. Das ist einfach ein Reverse-Proxy. Das schickt alle die Abfragen auf die verschiedenen anderen Services. Wo die Magie steht, ist, dass wir ein Service Registry haben.

Wir benutzen Autodiscovery. Das heißt, wenn ein neues Pod kommt, registriert sich selbst auf die Registry. Es sagt, ich bin dieses Pod mit IP.

Es fügt sich ein in die Service Registry. Dann weiß die Gateway durch diese Service Registry, welche Backends sie benutzen kann für dieses Service. Wenn wir nicht Kubernetes benutzen, benutzen wir Eureka Service Registry.

Auf Kubernetes benutzen wir das Kubernetes Discovery Service. Wir brauchen dieses Service nicht. Aber man kann das auch auf verschiedene Server mit Docker Compose installieren. Da braucht man eine Service Registry. In diesem Fall benutzen wir Eureka.

Alles, was beim Spring Cloud supportiert ist, kann man benutzen. Das ist sehr frei, sehr reich. Das ist die Basis des Spring Cloud. Für den Geo-Server-Teil haben wir eine Selektion gemacht.

Wir haben eine Auswahl gemacht, für welche Services und Plugins wir haben. Aber für die Services... Ich denke, das ist ziemlich gut, was wir hier in der Liste haben. Die Hauptsachen sind da.

Das zeigt, was wir in die verschiedenen Container gepackt haben. Das WMS hat Vector Raster Rendering. Das WMC hat Mapbox Render Style. Die WebUI hat alle solche Funktionalitäten. Geo Web Cache haben wir integriert.

Das ist die gleiche Version von Geo Web Cache. Wenn man Geo-Server mit schon geteilten Layer als Geo-Server-Option hat. Diese integrierte Web Cache und so weiter. In der Konfiguration ist das normal aktiviert.

Man kann das Disable, wenn man etwas nicht will. Ich sehe keinen Vorteil. Wenn man etwas nicht will, kann man das hier in der Konfiguration schreiben. Es wird nicht mehr im Service sein.

Das ist ein klassischer Spring Boot Jammerl-File. Ihr schreibt keinen Code mehr, ihr schreibt Jammerl mit Spring Boot. Aber ja, das ist so. Sie ist ready for the cloud.

Ich arbeite als DevOps-Ingenieur. Ich hatte sehr viel Mühe, verschiedene Lösungen auf Kubernetes zu installieren. Ich bin sehr faul. Ich will etwas leichtes und einfaches haben. Ich habe ziemlich viel Zeit investiert, um diese einfache Lösung zu haben.

Wir haben einen Helm-Chart für das gebaut. Ich denke, dass Kubernetes aus meiner Sicht die beste Lösung ist, um Geo-Server-Cloud zu benutzen. Wenn ihr einen Kubernetes-Kloster schon habt, give it a try. Es ist ziemlich leicht.

Für diese Präsentation habe ich letzte Woche ein paar Beispiele in unserem Chart hinzugefügt. Wir können das selbst ausprobieren. Wir haben das schon auf Amazon, auf Azure, auf Google und auch auf OpenShift deployiert. Und auch auf dem lokalen Kubernetes mit Minikube oder so.

Es geht ein bisschen überall. Wir sind fast auf Version 1. Wir sind auf Release Candidate 30. Wir wollten Release 1 für heute haben, aber wir haben noch einen gefunden. Ja, schade.

Aber es ist Release Candidate 30 und es gibt heute schon eine Produktion. Es ist eine Minor Bug. Und ich werde jetzt ein bisschen auf dem Helm-Chart reden. Es ist auch open source. Es ist in unserer Camp2Camp-Organisation zur Verfügung. Und es ist gedacht als eine Abhängigkeit für einen Chart.

Wenn ihr eine Geoportal habt mit seinem Chart, das ist nur ein Backend. Und die Logik ist, dass es als Abhängigkeit installiert sein sollte. Was heißt das? Ich zeige das hier so konkret.

Kennt ihr ein bisschen Kubernetes oder ist das ein Helm-Chart? Wer kann bitte eine Hand heben? Okay, es spricht für etwa 15 Leute. Ich erkläre das einen Moment.

Ja, ihr müsst einfach im YAML-Chart von eurer Anwendung eine Abhängigkeit auf GeoServer Cloud hinzufügen. Und dann könnt ihr die Abhängigkeit einfach konfigurieren. Mit den Values, die im Config-File sind. Dann ist es ein normales Chart.

Es kann nicht so installiert sein. Es muss als Abhängigkeit installiert sein. Weil man muss wahlen. Will ich eine Datadire mit einem NFS oder etwas? Will ich die JDBC-Config für die Konfiguration? Man muss ein paar Wahlen explizit machen. Und deswegen muss das von meinem anderen Chart zugefügt werden.

Aber ich kann eine Demo machen, wenn Sie wollen, bei unserem Stand. Wir können einfach kommen und trinken einen Kaffee und machen eine kleine Demo. Ich bin fast fertig. Ich denke, ich gehe schnell dabei.

Nur zu sagen, mit Spring Boot kommen alle die Actuator-Funktionalitäten. Das heißt, Monitoring ist sehr einfach zu tun und sehr standardisiert. Wir müssen noch die Probe für Promisios hinzufügen. Aber wir haben schon Erfahrungen mit Azure Application Insight gemacht.

Das läuft ziemlich gut. Wir haben auch Custom Metrics hinzugefügt. Für die Leute, die ein bisschen Ops machen, gibt es ein bisschen mehr Out-of-the-Box-Monitoring mit diesen Tools. Und ich denke, ich bin noch zwei Minuten.

Wo sind wir? Das ist etwas, was wir letztes Jahr gemacht haben. Wir haben Webcache integriert. Wir haben verschiedene Extensions integriert. Das ist nicht eine exhaustive Liste, das ist einfach die wichtigste, auf meine Sicht, die wir integriert haben.

Wir haben verschiedene Variability gepackt. Es ist falsch. Jetzt ist das eine neue Version von Spring Cloud. Ich habe meine Slides nicht gut abgedatet. Und was wir jetzt machen, gerade jetzt sind wir auf Punkt 2 beim Arbeiten.

Wir haben einen Sponsor für das Geofence als Microservice. Und wir machen ein totales Rewrite vom Geofence. Es ist fast fertig. Es ist noch nicht akzeptiert als Version 4 bei der Community.

Vielleicht wird das als ein anderes Projekt kommen. Wir haben ein paar Schritte mit der Community, weil es ist ein komplettes Rewrite im Spring Boot. Dieses Geofence wird sicher im Spring Cloud sein. Es wird kompatibel mit dem Geofence-API sein.

Es wird vielleicht nicht Geofence genannt am Ende. Es ist die Diskussion von den letzten drei Tagen. Ich weiß es nicht. Und Webcache wollen wir auch mit diesem Queuing-System verteilen. Im Moment wir können das noch nicht für die Generation. Und wir wollen ein neues Backend für die Konfiguration.

Nicht mehr Datadir oder GDBC-Konfig. Das wäre unser Traum. Und auch ich erwarte gerade jetzt auf die OAuth 2-Authentifikation mit Spring Cloud zu hinzufügen. Ja, und fertig.

Ja, vielen Dank, Andrea. Auch ihr wart sehr fleißig, wie man sieht. Gibt es Fragen?

Ist es geplant, dass auch Services vom Geo-Server wie WMS standalone deployed werden können? Zum Beispiel, dass man dann eine Konfig einfach in den Docker-File hinzupackt,

der beschreibt, wie ein Layer auszusehen hat und dass die Administrierung mit dem Load Balancer und allem Drum und Dran nicht mehr vom Geo-Server gemacht werden muss? Das ist eine komplexe Frage. Ist das möglich mit Geo-Server? Also aktuell ist es nicht möglich.

Deswegen ist es geplant. Ja, also wie gesagt, wir lösen die Probleme vom Geo-Server hier nicht. Wir werden vielleicht ein paar Sachen haben, die nicht im normalen Geo-Server sind, weil Spring Cloud das macht. Und zum Beispiel die Integration von der OAuth-Authentifizierung,

das werden wir nicht mit den Plugins existieren vom Geo-Server machen, aber mit den echten Spring Cloud Sachen. Und wenn man andere Services braucht, also aus meiner Sicht ist es denkbar, dass das als Erweiterung im Geo-Server Cloud hinzufügen ist.

Vielleicht nicht im Geo-Server Cloud, aber es sollte möglich sein, das zu konfigurieren, dass diese anderen Services mit ihm kommunizieren. Vielleicht braucht das ein bisschen Entwicklung. Ich würde so viel wie möglich als eine Microservice-Architektur das haben.

In diesem Fall ist es einfacher, solche anderen Teile hinzufügen. Aber gerade jetzt nicht. Vielen Dank. Aber wenn Sie ein Projekt haben, das ist sehr interessant. Nein, ich finde einfach das Potenzial da sehr groß. Und gerade im Bezug zur Vector gibt es ja dieartige Services schon,

aber im Bereich Raster leider noch nicht. Und da würde der Geo-Server einen ganz guten Teil beitragen. Ja, sehr interessant. Danke. Eine kleine Frage würde ich noch zulassen. Ja, total cooles Projekt, voll spannend, gucke ich mir auf jeden Fall noch an.

Du hast erzählt, dass ihr so eine Auswahl getroffen habt bezüglich der Plugins, die er so unterstützt. Du hast aber für dieses Geo-Fans-Plugin gesagt, dass es ein ganzer viel Aufwand war, oder noch ist, das zu unterstützen. Ist das generell für alle Plugins oder ist das speziell nur für dieses Geo-Fans-Plugins?

Die Frage ist je nach Plugin. Das Problem ist, die Plugins für Geo-Server haben eine sehr breite Qualität.

Es gibt Plugins, die einfacher oder nützlicher sind. Diese haben wir als Prio 1 hinzugefügt. Verschiedene werden wir nicht nehmen, wie zum Beispiel die LED für die Authentifizierung. Wir werden das auf Spring Cloud basieren,

mit Spring Security und den Filter von Spring Security direkt, aber mit Spring Cloud Framework. Und für Geo-Fans, wir wollen nicht das Plugin Geo-Fans von Geo-Server integrieren. Das verlassen wir und wir wollen das Microservice Geo-Fans benutzen als Rest-API.

Das Problem ist, dass das Geo-Fans von Geo-Server 3, der aktuelle Geo-Fans, ziemlich alt ist und verschiedene Probleme hat. Wir wollten das ein bisschen freshen und einen kleinen Clean-Up machen.

Das ist ein komplettes Rewrite. Und jetzt haben wir ein paar Schreiten mit der Community. Das ist das Problem von dieser Woche. Vielleicht in zwei Wochen haben wir dieses Problem nicht mehr. Vielen Dank nochmal an Andrea Boggi.