Ja, ich begrüße alle zum letzten Vortrag des heutigen Tages auf Bühne 3. Und zwar wird Postkits ziemlich sicher wieder vorkommen, wir werden sehen, es geht um eine GDI im Container.

Vortragend ist David Arndt, er arbeitet bei der Generalverwaltung Ruhr in Essen. Ich wünsche viel Vergnügen. Herzlich willkommen zum Vortrag Geodateninfrastruktur im Container. Mein Name ist David Arndt, ich bin seit 2014 am Regionalverband Ruhr tätig.

Seit Mitte 2017 bin ich Teamleiter des Teams Geodatentechnik im Referat Geoinformation und Raumbeobachtung. Dort sind wir zuständig für die Planung, den Aufbau und den Betrieb der zentralen Geodateninfrastruktur für den Regionalverband Ruhr. Zu den weiteren Aufgaben gehören die Netzwerktätigkeit mit den Verbandskommunen im Rahmen des Geonetzwerks Metropole Ruhr.

Der Regionalverband Ruhr umfasst die dichteste Städtelandschaft Deutschlands mit rund 5,1 Millionen Einwohnern. Er besteht aus elf kreisfreien Städten und vier Kreisen mit insgesamt 53 Kommunen.

Als regionale Klammer sind wir seit 1920 in der Region tätig. Ich möchte Ihnen heute folgende Inhalte näherbringen. Als erstes werde ich Ihnen erzählen, wie die Geodatendienste bisher bereitgestellt wurden. Im zweiten Schritt erzähle ich Ihnen etwas über die Containertechnologie.

Im dritten Schritt werde ich Ihnen die Umsetzung der Containertechnologie in der GDI des Verbandes erläutern. Die Bereitstellung der Geodienste war bisher klassisch.

Für jeden Dienst ein Hardware-Server. Im Frontend-Bereich setzten wir dabei auf zwei Reverse-Proxy, die im Load Balancing und Failover miteinander arbeiteten. Im Backend liefen ein Maps-Server und ein Applications-Server, beide repliziert auf zwei Hardware-Server.

Und dann lief im Backend noch ein Datenbank-Server, der die Daten bereitgestellt hat. Der Maps-Server war mit dem UMM Maps-Server und den QGIS-Servern ausgestattet. Im Applications-Server liefen zum Beispiel so Anwendungen wie unser Wiki, unser Projektmanagement,

unser WebGIS und unsere Datenkataloge für die Bereitstellung der Metadaten. Das Problem dabei war, dass bei neuer Software-Konfiguration immer die Abhängigkeiten zu den anderen Software-Komponenten berücksichtigt werden mussten.

Und das war unter Umständen sehr komplex, dass hier Inkompatibilitäten zwischen unterschiedlichen Bibliotheken kommen kann. Ich möchte Ihnen jetzt etwas über Microservices erklären. Was sind überhaupt Microservices? Im Grunde sind das eine Kapselung von Anwendungen in einem Image.

Dabei sollten die Anwendungen so klein wie möglich gehalten werden, um sie möglichst einfach zu halten. Diese Images können in einer kompatiblen Laufzeitumgebung ausgeführt werden, unabhängig von der zugrunde liegenden Hardware. Eine Laufzeitumgebung, die sehr populär ist, ist zum Beispiel Docker.

Aber es gibt auch noch weitere andere Laufzeitumgebungen für Microservices. Der Vorteil ist, dass solche kleinen Services relativ einfach ersetzt werden können und durch neue Software-Komponenten somit ersetzt werden.

Sie sind isoliert gegenüber anderen Services und beeinflussen diese Services nicht. Das heißt, Bibliotheksinkompatibilitäten kann es zwischen verschiedenen Services hier nicht geben, weil jeder Service einen kompletten Stack mit sich bringt.

Die Schnittstellen sind das A und O eines Services. Über diese Schnittstellen, die standardisiert sind, werden die Informationen ausgetauscht. Und diese müssen auch stabil bleiben, damit die Infrastruktur läuft. Im besten Fall sind Microservices dezentralisiert und horizontal skalierbar.

Dies ermöglicht dann eine möglichst einfache Hochskalierung in einer Infrastruktur unter Last. Zur Umsetzung der GDI des Verbandes. Wir haben in den letzten Jahren stetige ansteigende Anforderungen hinsichtlich Verfügbarkeit, Geschwindigkeit und Datenmenge bekommen.

In 2020, pandemiebedingt, hat sich die Zugriffe auf unsere Dienste verdoppelt. Von zwei Millionen Zugriffen täglich auf vier Millionen Zugriffe täglich. Im ersten Quartal 2021 sind diese Zugriffe nochmal auf fünf Millionen Zugriffe täglich auf unsere Dienste gestiegen.

Dabei sind unser Stadtplan und unsere Ortofüll-Dienste die Favoriten, die am meisten abgerufen werden und 95 Prozent des Volumens ausmachen. Begonnen mit der Migration hin zum Microservice haben wir 2019.

Wir haben das dort für unseren Metadatenkatalog getestet. Hier war die Anforderung von unseren Verbandskommunen im Rahmen des Geonetzwerks Metrobole Ruhr, ein mandantenfähiges System zu schaffen. Über die Microservices können wir diese Kataloge, Klonen und jeder Kommune

einen eigenen Katalog bereitstellen, der vollumfänglich von den Kommunen gewartet werden kann. Der technische Betrieb läuft bei uns und wir können im Backend sicherstellen, dass der Service sicher und stabil und mit den aktuellen Sicherheitsupdates läuft. Dadurch haben wir langsam das nötige Know-how erlernt, um Microservices bereitzustellen.

Anfang 2020 haben wir uns durch den Erfolg, den wir in dem Bereich hatten, mit der Migration aller Services zu Docker hin beschäftigt. Dies hat so ausgesehen, dass wir alle unsere Services angeschaut haben

und versucht haben, diese optimal in eine Microservice-Infrastruktur zu integrieren. Bis Ende 2020 hatten wir dann den Großteil unserer Services auf Microservices umgestellt. Mittlerweile läuft unsere komplette GDI in Microservices.

Als Cluster Manager setzen wir Docker Swarm ein. Der Cluster Manager ist nötig, wenn wir eine Docker-Laufzeitumgebung in einer Multi-host-Installation haben wollen. Das heißt, wir haben beliebig viele Hardware-Server, die eine Laufzeitumgebung bereitstellen.

In dem Fall kümmert sich der Docker Swarm darum, dass die Ressourcen gleichmäßig auf die host verteilt werden und alle Services von außen erreichbar sind. Docker Swarms zeichnet sich durch eine gute Integration in Docker an,

weil es von der gleichen Firma entwickelt wurde, und eine einfache Administration. Im Gegensatz zu Kubernetes, was eine sehr hohe Einstiegshürde hat. Wie sieht das bei Docker Swarm aus? Welche Begriffe muss ich kennen? Dort gibt es Stack, Service, Container und Image. Aber was ist das genau?

Ein Image ist ein lauffähiger Service, den wir bereitgestellt haben. Zum Beispiel in unserem Fall ein Geo-Server. Diese Services lassen wir in Stacks laufen. Ein Stack beinhaltet 1 bis n Services.

Diese Services sind wieder unterteilt. In einem Service können beliebige Container laufen, um die Anwendung zu skalieren. Am Beispiel unseres Geo-Servers wäre das zum Beispiel, wir haben einen Geo-Server. Wir lassen ihn als Service 1 in einer laufenden Instanz Geo-Server laufen und skalieren ihn auf drei Container hoch.

Somit haben wir eine Replizierung von drei laufenden Geo-Server-Instanzen. Im Backend läuft dann eine Datenbank, die sozusagen die Dienste, die Daten bereitstellt. Wie man sieht, ist der Stack somit eine geschlossene Umgebung.

Wenn alle Services laufen, läuft der komplette Stack und der Geo-Server kann Daten ausliefern. Zur Administration unserer Docker-Umgebung nutzen wir unter anderem das WebAdmin GUI Portainer. Portainer zeichnet sich dadurch aus, dass ich ein weit ausgefeiltes rechte

Management habe und Zugriffe auf Stacks einzelnen Mitarbeitern oder Teams geben kann. Somit kann jedes Team auf seine Stacks zugreifen und diese administrieren, ohne in Konflikte mit anderen Services und Stacks zu kommen.

Ich habe jederzeit einen Überblick über alle laufenden Container, Stacks und Services. Schauen wir uns das am Mapserver-Stack an. Die Stacks werden in einer Jaml-Notation definiert.

Jeder Service in einem Stack hat einen Namen, der eindeutig innerhalb des Stacks sein muss. Jeder Service beruht auf einem Image, das gestartet wird, wenn der Service gestartet wird. Zudem geben wir an, wo und wie der Service laufen soll. Dieser Service soll zum Beispiel auf allen Nodes laufen, die von Type-Mapserver sind und skaliert somit hoch.

Wenn ich einen neuen Hardware-Knoten hinzuschalte und diesen den Node-Label Type -Mapserver gebe, wird der Mapserver auf diesem Service auch ausgeführt und wird sozusagen hochskaliert.

Des Weiteren muss ein Netzwerk verbunden sein, damit dieser Service mit der Außenwelt kommunizieren kann. Als Weiteres brauche ich noch 1 bis N Volumes, wo die persistenten Daten sind. Ein Docker-Container enthält nämlich keine persistenten Daten. Wenn ich diesen Service oder Container beende, dann sind alle Daten, die innerhalb

dieses Containers generiert wurden und nicht auf einem persistenten Volumen gespeichert werden, verloren. Deshalb binden wir eigentlich in allen Services Volumes ein, in denen die persistenten Daten liegen. Im Fall des Mapservers sind das zum Beispiel unsere Rastadaten bzw. unsere Map-Files.

Als Weiteres definieren wir ein Lockbackend. Hier lockt der komplette Service all seinen Output. Das heißt, die Zugriffe werden an einer zentralen Stelle gelockt und können dort von dort untersucht werden. Dazu aber später noch mehr.

Im Container kann ich jeden Service dann überwachen. In diesem Fall habe ich hier den Mapserver-Service neu gestartet. Auf dem Mapserver 1 wird der Start vorbereitet. Im nächsten Schritt wird der Mapserver auf dem Mapserver 1 gestartet.

Und im dritten Schritt habe ich wieder auf beiden unserer Mapservern einen laufenden Mapserver-Container. Diesen kann ich nun weiter untersuchen, indem ich dieses Eigen anklicke.

Ich bekomme dann Informationen zur Speicherauslastung, zur CPU-Auslastung, zur Netzwerknutzung und auch zu allen laufenden Prozessen innerhalb dieses Containers. Zum Logging nutzen wir Kibana mit Elasticsearch. Dieser bietet uns einen zentralen Log-Server an.

Alle unsere Requests landen sozusagen im Backend von Kibana und können dort durchsucht werden. Das hat folgenden Vorteil. Ich werde Ihnen das mal erläutern anhand eines Mapservers-Requests.

Der Mapserver-Request kommt am Reverse-Proxy an, wird vom Reverse-Proxy dann weitergeleitet. Der Reverse-Proxy lockt zentral in unserer Kibana. Der weitergeleitete Request landet in unserem Mapserver. Vom Mapserver aus wird wieder ein Log-Request an den zentralen Log-Server Kibana geschickt.

Gegebenenfalls schickt der Mapserver dann ein Request an unsere Datenbank. Auch hier lockt die Datenbank wieder direkt in Kibana. Ich kann über Suchfilter jetzt mir den kompletten Request vom Anfang des Reverse-Proxys bis zur Datenbank in Kibana anzeigen

und gegebenenfalls die Fehlerquelle sehr schnell identifizieren. Ich möchte Ihnen nun noch erklären, wie eigene Images erstellt werden.

Wir nutzen zum größten Teil in unserer Infrastruktur eigene Images aus im Rahmen der Sicherheit. Wir wollen keine Fremdanbieter dort drin haben, da man sich gegebenenfalls Schad-Software einlädt. Alle unsere Images beruhen zum größten Teil auf Debian Unstable oder Stable Images.

Wir installieren dann die Kommandanten, die wir brauchen. In dem Fall ist es ein einfaches GDAL, was als Kommand ein GDAL-Infra-Version ausgibt. Wir bauen dieses Image mit dem Kommand Docker Build.

Im nächsten Schritt laden wir dieses Image in unsere zentrale Registry. Und im dritten Schritt starten wir dieses Image mit einem Docker Run. Es gibt jetzt hier die GDAL-Version aus als Output.

Die zentrale Registry nutzen wir, damit wir all unsere Images auf all unseren Hosts zur Verfügung stellen können. Im anderen Fall müssten wir alle unsere Images manuell auf alle verfügbaren Hosts kopieren, um diese auch überall zur Verfügung zu stellen. Die zentrale Registry bietet uns aber auch den Vorteil, dass wir jedes Image, was wir einladen und jeden Stand des Images uns anschauen können

und auch jederzeit zu einem bestimmten Stand eines Images wieder zurückgehen können, wenn es beim Update zum Beispiel zu Problemen gekommen ist.

So sieht die Bereitstellung der Dienste heutzutage so aus. Wir haben im Frontend nicht mehr zwei Hardware-Notes, sondern zwei Container, die als Service-Reverse-Proxy laufen. Diese können auf irgendeinem Host in unserer GDI laufen. Mapserver laufen auch in zwei Containern, die wiederum auf irgendwelchen Host bei uns in der GDI laufen können.

Und im Backend läuft ein Datenband-Container, der die Daten für die Mapserver bereitstellt. Der Vorteil dieser Umgebung liegt auf der Hand.

Docker Swarm eignet sich als einfacher Einstieg in eine Multi-Host-Docker-Umgebung. Wir haben die Möglichkeit, flexibel neue Konfiguration und Software auszuprobieren, ohne Auswirkungen auf das Produktivsystem. Updates können nun durch die Kapselung der einzelnen Images einfach angewendet werden.

Dadurch, dass die Images relativ klein sind und einzelne Funktionalitäten bereitstellen, können wir per Image Updates einspielen, testen und nach und nach unseren Software Stack aktualisieren. Allerdings wird auch die Komplexität des Gesamtsystems erhöht.

Es ist ein sehr gutes Know-how im Bereich von Linux-Administration und Netzwerk-Administration notwendig, da hier vor allem die Neuerungen drinstecken, wenn man von einem normalen Linux-System auf eine Microservice-Infrastruktur wechselt.

Für Fragen stehe ich Ihnen jetzt gerne zur Verfügung, beziehungsweise Sie können mich auch im Nachgang gerne per Telefon oder E-Mail kontaktieren. Vielen Dank für Ihr Interesse.

Vielen Dank, David Arndt, für den interessanten Vortrag. Es sind einige Fragen reingekommen. Wir schauen, was wir noch zeitlich reinkriegen. Sehr früh kam die Frage, habt Ihr alle Services im Container verschoben, auch Datenbanken? Was kannst Du dazu sagen? Ja, wir haben mittlerweile wirklich alles in die Container verschoben, weil uns das eine gewisse Flexibilität gibt

und es läuft eigentlich auch ganz stabil. Mit den Datenbanken haben wir auch relativ früh angefangen, allerdings sind die derzeit noch auf einen speziellen Host festgenagelt,

wo wir auch eine schnelle SSD drunter haben, um da einfach die Performance auch in der Datenbank zu haben. Da passt gerade die nächste Frage dazu, wo befindet sich der aktuell größte Flaschenhals? Der größte Flaschenhals befindet sich in den Containern, die schlecht zu verdoppeln sind.

Wir haben das zum Beispiel bei den Datenbanken, die wir derzeit auch nur einfach haben, wo wir derzeit auch am Replizierungsverfahren arbeiten, wie wir das am besten machen können, wobei das natürlich relativ komplex ist, mit Postgres eine Master-Master-Replikation aufzubauen.

Dementsprechend ist das denke ich mal noch das größte Problem, was wir haben. Ansonsten haben wir alle Dienste eigentlich mindestens doppelt vorhanden, dementsprechend auch kaum ein Flaschenhals.

Ich sehe mein Bild ist weg, aber ich glaube, mein Ton ist noch da. Offenbar sind wir nicht so gut ans deutsche Internet angebunden. Aber ich frage mal weiter, die oberste Frage, würde man sich Stand heute wieder für Docker Swarm Mode entscheiden? Gibt es noch andere Möglichkeiten? Was meinst du dazu?

Im Grunde ist Docker Swarm der Vorteil, dass es relativ einfach zu konfigurieren ist. Es hängt natürlich immer ganz von den Anforderungen ab, die man an so eine Infrastruktur hat. Wir brauchten was, wo wir ein einfaches Netzwerk aufbauen können, wo wir unterschiedliche Hardware-Nodes zusammenschalten können.

Und das bietet Docker Swarm out of the box relativ einfach, wohingegen andere Orchestrierungstools wie Kubernetes zum Beispiel schon eine relativ hohe Einstiegshürde brauchen, wenn wir uns entsprechendes Know-how länger hätten aufbauen müssen. Es gab mal zwischenzeitlich so ein kleines, wo wir tief durchatmen mussten.

Da gab es mal in der Presse, ich weiß nicht, ob Sie das alle mitbekommen haben, dass Docker Swarm eingestellt werden soll. Aber das ist jetzt zum Glück erst mal vom Tisch. Das heißt, es wird auch weiterentwickelt. Dementsprechend sind wir auch sehr zufrieden heute noch damit und würden das wahrscheinlich gleich aufbauen,

wenn wir heute nochmal neu anfangen würden. Wir haben noch Zeit für weitere Fragen. Dann gibt es die Frage, gab es Änderungen bei den Hardware-Requirements? Wurden neue Nodes angeschafft oder bestehen die erleitert? Also ist die Anforderung an die Hardware größer oder kleiner? Könnte man vielleicht auch so fragen.

Im Grunde sind die Anforderungen an die Hardware eigentlich gleich geblieben bei uns. Wir hatten vorher schon relativ starke Hardware-Ausstattungen eigentlich bei unserem Dienstleister. Womit wir jetzt Probleme bekommen haben, ist im letzten Jahr eher die Corona-Pandemie, wo sich wirklich die Zugriffszahlen eigentlich verdoppelt haben. Und wir sind derzeit dabei, die Hardware auszubauen.

Allerdings haben wir gerade das Problem, dass der Dienstleister auch Lieferprobleme mit der Hardware hat. Das heißt, wir warten gerade auf die neue Hardware und bräuchten die eigentlich gerade regeln. Eine weitere Frage vom Publikum.

Geo-Server, wie stellen Sie sicher, dass Änderungen in der Konfiguration zwischen verschiedenen Instanzen propagiert werden und keine Inkonsistenzen aufdrehen sind? Wir haben Geo-Server derzeit wirklich nur einmal aufgesetzt. Also wir haben nur eine Instanz an Geo-Server. Das heißt, die haben wir nicht doppelt aufgesetzt. Dementsprechend entstehen da derzeit keine Inkonsistenzen.

Aber genau daran arbeiten wir auch. Da ist allerdings mein Kollege für zuständig. Wenn es da noch weiteres Austauschbedarf gibt, würde ich da einfach nochmal den Kontakt dann herstellen, weil da kann ich gar nicht so viel zu sagen. Aber derzeit ist er einfach nur einfach da, der Geo-Server. Weil das auch nicht unser Standard-Map-Server ist.

Unser Standard-Map-Server ist der UMN-Map-Server. Okay. Dann noch eine Frage. Ist das ein großer Aufwand, Container auf einen anderen Server umzuziehen? Nein, das geht entweder über die grafische Oberfläche, Pro-Tainer, wie ich es vorgestellt habe, eigentlich auf Klick. Beziehungsweise ich kann das auch relativ einfach über die Kommandozeile machen,

da die ganzen Images ja in einer zentralen Registry liegen, kann ich die eigentlich daraus laden und auf jedem beliebigen Server starten, den wir haben. Es gab ja auch noch kritische Tweets heute über Docker-Container. Ich kann sie nicht mehr ganz zitieren.

Sie rotten vor sich hin. Ich glaube, Arnof hat das gesagt. Ich weiß nicht genau, auf was er angespielt hat. Kannst du dazu was sagen? Ja, ich vermute mal, dass er so ein bisschen darauf einspielen wollte, dass natürlich so ein Container sehr schnell gemacht ist, aber wir es ja gerade im Backstage-Bereich auch schon hatten,

dass eben Software-Aktualisierungen oder sowas dann in den Images nicht mehr durchgezogen werden. Dem beugen wir eigentlich vor, dass wir einen automatischen Prozess haben, wo wir eigentlich von all unseren Images einmal in der Woche Software-Updates einspielen. Das heißt, Distribution-Updates werden einmal in der Woche neu eingespielt

und dadurch gehen wir eigentlich darauf, dass wir dann immer aktuelle Images haben, wo auch die Sicherheitslücken dann auch geschlossen sind. Das ist natürlich die große Gefahr bei Docker, dass man Image startet und das für immer laufen lässt und sich Sicherheitslücken einhandelt. Gut, ja. Ich glaube, da konnten wir alle Fragen beantworten.

Vielen Dank, David.