Wir starten mit dem Thema Geodateninfrastruktur und der Mark Jansen, der erste Meinung GDI, das geht auch mit Docker. Ist das wirklich so? Ja, eine sehr gute Frage. Genau darum soll es gehen in diesem Vortrag. Wir wollen uns damit beschäftigen

mit MobiDock. So heißt nämlich tatsächlich dieses Logo und dem Projekt, was dahinter steht, nämlich Docker. Und der Untertitel meines Talks ist Einführung, Überblick und Diskussion. Und es geht mir genau darum, nämlich um diesen letzten Teil, die Diskussion. Da würde ich einfach gerne eine Anregung zu geben und vielleicht auch im Nachgang dann nochmal weiter darüber sprechen wollen.

Gut, das ist die Gliederung, die ich mir überlegt habe, um diesen Talk zu führen. Zuerst gibt es ein bisschen Meta. Anschließend möchte ich die Motivation, die ja hinter diesem Talk steht, kurz beleuchten. Dann diese Frage stellen GDI mit Docker. Es ist ein Fragezeichen dahinter. Wie kann sowas aussehen, wie gut ist das, wie schwierig ist das?

Kann das jeder, kann das selbst der Mark Jansen? Dabei werden wir uns einen Überblick verschaffen, über was für Optionen eigentlich so auf dem Tisch sind, wenn wir GDIs mit Docker machen wollen und schließlich ein paar Punkte in die Diskussion bringen. Ja, mein Name ist Mark. Ich bin Geschäftsführer von der Firma Terrestris. Wir

haben den Stand hier noch wenige Stunden an diesem Freitag auf der Foskis. Und kommen Sie uns da gerne besuchen. Ich bin Kernentwickler von OpenLayers und habe auch mal ein Buch dazu geschrieben. Spreche oft auf so Veranstalten wie hier oder international und bin auch USGeo Foundation Charter Member. Die Firma Terrestris macht Open Source Kits aus Bonn. Kommen Sie wie gesagt vorbei.

Wir sprechen sehr gerne über das, was wir tun, weil wir die Software, die wir einsetzen, kennen, lieben, auch weiter verbessern. Wir finden bestimmt gemeinsam eine schöne Lösung für Ihre speziellen Fragestellungen. Zur Motivation hinter diesem Talk. Ich habe es gerade schon erwähnt, als ich die Firma vorgestellt habe, GDIs sind letztlich mein Tagesgeschäft. Oder das, was wir sehr häufig machen, was wir betreuen, was wir entwickeln, was wir konzeptionieren.

Das ist die eine Seite. Okay, GDI war schon mal irgendwie klar, kannst du vielleicht einen Vortrag so einreichen. Dockr ist nach wie vor heiß. Es ist nicht neu im engeren Sinne, sondern es existiert schon etwas länger. Das erkennt man unter anderem am Tagungsprogramm auch.

Es gab einen Workshop. Das war glaube ich auch der erste Workshop, der ausverkauft war. Sprich, da war eine entsprechende Nachfrage da. Es gibt mindestens vier Vorträge, die sich damit befassen, außer dem Vortrag, den Sie jetzt gerade hören. Ich konnte leider der ersten Vortragssession dem Blog nicht folgen, weil ich dann noch in einem anderen Gespräch war. Und ich wollte einfach quasi diese Sachen miteinander verbinden und über Pro

und Contra, denn vermutlich gibt es immer Pro und Contra, ins Gespräch kommen. Und um über Pro und Contra vernünftig diskutieren zu können, braucht man in irgendeiner Form eine Einführung. Das heißt, ich wollte gerne auch da mal Basics erklären. Sprich, das sind die Ziele, die ich verfolge, wenn ich diesen Talk hier halte.

Ich möchte eine Einführung in die Grundthematik geben. Ich möchte einige Beispiele geben, wie man Sachen angehen kann. Und das Ganze unter Betrachtung verschiedener Nutzungskontext. Und ich möchte einen Diskussionsgrundlage geben. Sorry.

Also GDI mit Dockr ist schon der dritte Punkt quasi meines Vortrags. Zuerst Geodateninfrastrukturen, GDIs. Was sind das denn? Was ist das denn? Es gibt vermutlich auch eine offizielle Definition. Ich habe die jetzt nicht rausgesucht. Ich habe so ein paar Eigenschaften aufgezählt von Geodateninfrastrukturen, die häufig eigentlich zum Tragen kommen.

Häufig genug sind sie zentral und sie sind nutzbar vor allem für andere Nutzer dieser Infrastrukturen. Sie bestehen häufig aus verschiedenen Komponenten, die einzelne Aufgaben übernehmen und miteinander interagieren. Eine extrem zentrale Aufgabe von Geodateninfrastrukturen ist natürlich die Datenhaltung. Also auf Datalsystemsebene, aber auch auf Datenbank-Ebene beispielsweise.

Sehr häufig sind GDIs Dienst basiert, konzipiert und es gibt dann in der Regel auch eine anzeigende Komponente und natürlich noch weitere. Häufig sind sie nach diesem kleinen Server-Modell aufgebaut, sprich irgendeine zentrale Komponente. Liefert beispielsweise einen WMS-Dienst aus, dieser wiederum greift auf eine Datenbank zu.

Dann wird das zur Anzeige gebracht in einem Leaflet-Client, sage ich jetzt mal. Muss nicht immer oben leer sein. Und eine Sache hat sich jetzt geändert hier, das haben wir natürlich alle wieder vergessen. Neben der Datenhaltung zählt natürlich auch die Metadatenhaltung, damit man in einer GDI auch einfach weiß, was für Elemente sind denn überhaupt einfach da, welche Dienste gibt es, in welcher Aktualität, welche räumlichen Bereiche decken die ab.

Metadaten gehören ganz sicher auch noch dazu. Das ist sicherlich auch nicht vollständig, also ich denke, dass GDI jeder noch ein bisschen anders definieren würde. Jetzt Docker. Docker ist eine Software, die letztlich Kontainerisierung, Virtualisierung auf Betriebssysteme eben anbietet. Das führt dazu, dass man quasi isolierte Standalone und relativ portable Maschinen hat oder Container hat, die Funktionalität zusammenpacken.

Und ja, die kann man relativ schnell als Container laufen lassen und auch genauso schnell wieder entfernen. Und man hat quasi eine Applikation und alle Dependenzen, die diese Applikation hat, also beispielsweise eine Java-Applikation, die auf Java 9 nur läuft, kann ich in einer Docker, in einem Docker Image bzw. dem daraus resultierenden Docker-Container so aufbauen, dass die Applikation dort ist,

das Java 9 in der richtigen Version, wie ich es brauche und noch von mir aus irgendwas anderes, irgendein spezieller Treiber oder was auch immer dort ist und das alles betrifft eigentlich nicht das Host-System, auf dem Docker läuft, sondern ist alles abgeschlossen.

Drei zentrale Begriffe habe ich aufgeschrieben. Wie gesagt, das ist ein Einführungsvortrag, die auch mir nochmal klar geworden sind in der Vorbereitung. Ich hoffe, Ihnen geht es vielleicht ähnlich dann. Also Images sind letztlich ein Kochrezept, quasi wie so ein Container aufgebaut wird. Und der Container selber ist das Gericht, was aus diesem Kochrezept quasi entsteht.

Das eine ist also die Konkretisierung des etwas abstrakteren anderen. Eine andere Analogie, um dieses Container-Image-Build ein bisschen einfacher Verständnis zu machen, ist vielleicht, wenn Sie Programmierer sind, das eine ist eine Java-Klasse, also das Image ist eine Java-Klasse, hat gewisse Eigenschaften und Methoden. Und ein Container ist eine Java-Instanz, also wenn ich denn wirklich diese Klasse instanziert habe.

Davon macht man ganz viele, von Containern, von Images macht man üblicherweise nicht so mega viele. Zentral auch für Images sind sogenannte Docker-Files. Das ist letztlich eine Textdatei, in der ich in einer gewissen Syntax schreibe. Das Beispiel, was ich gerade eben genannt habe, ich brauche Java 9. Außerdem brauche ich ein gewisses Datei von meinem Dateisystem in diesem Container und dann lass mir bitte meine Applikation laufen.

Das schreibe ich da in einer gewissen Art und Weise rein und dann gibt es Docker-Befehle, die dafür sorgen, dass dieses Rezept ausgeführt wird in dem Image und mir ein Container erzeugt wird. Ganz wichtig ist dabei, dass es halt verschiedene Registries gibt, wo man solche Images quasi finden und dann auch wiederum verwenden kann. Das heißt, es gibt stand jetzt einfach schon eine ganze Menge Images für viele von den Standardkomponenten,

die Ihnen auch im Kopf voranzubringen existieren, bereits mehrfache Images, wo jemand diese Rezepte quasi aufgekocht hat, aber es ist genau so wie bei den Rezepten, der eine mag es halt lieber etwas schärfer, der nächste mag es, weiß ich nicht, mit ein bisschen mehr Zucker. So ist das mit Kochrezepten. Es gibt durchaus für die verschiedenen Komponenten auch verschiedene Rezepte,

die sich dann alle von mir aus Biergulasch nennen, aber der eine macht es linksrum, der andere macht es rechtsrum. Ja und diese ganzen Images, die man auch zentral nehmen kann, kann man auch verwenden, um eigene, sehr einfache Images zu bauen, die dann eigentlich noch kleinere Abweichungen davon enthalten können.

Das sind die Nutzungskontexte, unter denen ich das betrachten möchte. Einmal die Entwicklung einer GDI und zur Entwicklung einer GDI gehört auch meiner Meinung nach, dass man bestehende Komponenten, die vielleicht nicht dockerisiert sind, ja vielleicht noch dockerisieren möchte. Also ich nehme, also häufig genug fängt man nicht auf der grünen Wiese an, sondern viele haben bereits irgendwas

und dann möchte man vielleicht eher von einer Migration reden, als wie eine Neuentwicklung. Ich möchte auch über Schulung sprechen, das gehört zu GDIs sicherlich auch dazu. Wenn die nämlich einfach nur da sind, die niemand benutzen kann, dann ist es auch nur halb so gut, denn man muss auch schon wissen, wie man das macht. Aber auch wie man eine solche GDI, die ich beispielsweise entwickelt habe, wie ich die dann in produktiven Kontexten überführe.

Also sprich von meinem Testserver auf die wirkliche, meine superwichtige domain.com Adresse, wo ich einfach eine GDI betreiben möchte und schließlich auch Wartung und Support von sowas. Denn das ist keine One-Man, keine One-Time-Solution, wo ich die mache und dann ist die da und dann wird die auf alle Ewigkeiten fertig sein, sondern sowas muss gewartet und auch gesupportet werden, so eine GDI.

Zum Überblick. Docker, Docker Run Hello World, das ist so ein Befehl. Docker ist die executable sozusagen, run ist ein Kommando, was halt dazu führt, dass jetzt hier das Hello World Image quasi in einen Container überfüllt werden soll und dann auch ausgefüllt werden soll. Und wenn man sowas dann ausführt, sieht das ungefähr so aus.

Hängt ein bisschen davon ab, ob sie das schon mehrmals gemacht haben oder nicht. Und wenn man das hier durchgeht, erklärt es eigentlich ganz schön, was passiert. Er kennt dieses Image nicht, Hello World, wenn man das zum ersten Mal aufruft. Also das Kochrezept kennt er nicht. Ich habe ihm gesagt, ja, mach mir mal bitte Biergulasch. Ich habe gesagt, ich weiß nicht, wie ich Biergulasch machen soll. Also muss ich rauskriegen, wo ich denn dieses Rezept dafür her bekomme.

Dann fragt er halt eine Registry und fragt, kannst du mir mal bitte das Hello World Rezept geben? Image. Dann befolgt er die Anweisungen Schritt für Schritt und in dem Fall führt das halt dazu, dass dann tatsächlich wenige Sekunden später Docker mir sagt, guten Tag, deine Installation mit Docker scheint geklappt zu haben.

Hier unten steht auch nochmal genau erklärt, was passiert ist. Im konkreten Fall ist das übrigens eine C-Applikation, aber es ist mir ehrlich gesagt egal, weil ich einfach nur das Rezept genommen habe, nur Hello World, und jetzt kriege ich eine Ausgabe, das ist gut. Das hätte auch irgendjemand anders in, weiß ich nicht, Java, Python, Haskell schreiben können. Es ist mir eigentlich egal. So läuft das häufig genug.

Das war Hello World. Jetzt müssen wir uns Gedanken machen zu den Komponenten einer GDI. Ich nehme jetzt mal vier auf. Wir brauchen eine Datenbank, wir brauchen OGC-Dienste, wir brauchen Metadaten und wir brauchen eine kleine, kleine Applikation. Und ich habe mich entschieden dafür, einen relativ klassischen Stack aufzubauen, PostgreSQL PostGIS.

Als Datenbank Komponente, Geo-Server, als Kartenlieferant sozusagen, GeoNetwork Open Source für die Metadatenverwaltung und eine Open-Layers-Applikation, die kann ich einfach am besten. Leaflet könnten Sie genauso nehmen, auch irgendwelche anderen. Dann stellt sich mir schon die Frage, okay, ich habe es ja eben schon gesagt, jetzt gibt es ja viele verschiedene Arten und Weisen, Biergulasch zu kochen.

Genauso gibt es viele verschiedene Arten und Weisen, Geo-Server beispielsweise bereitzustellen. Und genauso ist es auch, wenn Sie diese Registry, da ist oben so ein Link quasi drin, durchsuchen, nach beispielsweise PostGIS oder Geo-Server, besten Dank fürs Muten.

Wenn Sie das machen, werden Sie viele verschiedene Rezepte finden für PostGIS, für Geo-Server, für Geo-Network und so fort. Ich habe jetzt eine Auswahl hier getroffen. Es gibt kein richtig und kein falsch an dieser Stelle vorerst, sondern wir haben einfach eine Auswahl getroffen. Und eine eigene Applikation habe ich geschrieben, denn das ist ja genau das, was ich sage. Ich entwickle mir eine GDI, also schreibe ich mir eine Open-Layers-Applikation, eine sehr einfache.

Okay, meine Open-Layers-Applikation, die ich selber schreibe, die sieht ungefähr so aus, also das Docker-Fall dazu. Ich habe mir halt eine JavaScript-Datei geschrieben und wenn sie im Open-Layers-Vortrag waren, habe ich die auch genau so geschrieben, dass sie halt nur das Notwendigste nimmt. Also es sind ein paar Schritte, die notwendig sind. Ich brauche dafür Node, da steht hier dieses From-Node-10.

Ich habe gewisse NPM-Befehle, das soll uns jetzt nicht zu sehr interessieren. Ich baue mir quasi meine eigene Applikation, die am Ende einen Punkt auf eine Karte bringt. Also eine funktional, sicherlich nicht beeindruckende Applikation, aber eben in dem Sinne eine, die alle Komponenten zusammenbringt.

Wenn ich jetzt diese ganzen einzelnen Komponenten habe, ich habe sie hier aufgenannt, die kann ich einzeln laufen lassen. Ich kann also sagen, bitte, liebes Docker, Docker Run, haben wir ja eben schon gelernt, Docker Run Hello World, ich kann sagen, lass mal den Terrestres-Geo-Server laufen. Dann macht der das, dann existiert der irgendwo. Ich kann das genauso machen für Geo-Network in einem anderen Tab von meinem oder in einem anderen Terminal.

Aber letztlich habe ich eben auch das erwähnt bei der Definition von einer GDI, diese Komponenten müssen noch miteinander sprechen. Sprich, es ist schon besser, wenn sie quasi alle gemeinsam hochfahren, und vielleicht hängt auch der Geo-Server davon ab, dass beispielsweise die Datenbank zuerst da ist, denn sonst macht es keinen Sinn, den Geo-Server schon bereitzustellen. Das heißt, während ich mit einem Befehl eigentlich möchte, dass alle diese Komponenten hochgefahren werden,

so möchte ich schon kommunizieren, okay, der Geo-Server macht erst dann Sinn, wenn die Datenbank beispielsweise da ist. Und das alles kann ich tun, indem ich das manuell mache und was weiß ich genau, auf die Ausgabe achte und so weiter und so fort. Ich kann es aber auch machen, indem ich halt ein sogenanntes Docker Compose-File schreibe.

Das dient letztlich dazu, die verschiedenen Images zu kombinieren, da hat man so Möglichkeiten wie Depends-On, das ist auch eine einfache Textdatei, hier sieht man so dieses Depends-On, und es ist genauso wie ich sage, der Geo-Server wird hier definiert in diesem Bereich, da sind dann eine ganze Menge Informationen, die im Detail vielleicht schon etwas zu weit führen,

aber hier ist zum Beispiel dieses Depends-On, das heißt, bevor dieser Geo-Server gestartet wird, muss die Datenbank da sein. Und hier oben kann ich halt auch, das sind ja diese Standard-Images sage ich mal, der Rest des Geo-Servers wird mir, wenn es ausgeführt wird, mit dem Geo-Server in einer gewissen Version geben, das ist ein Standard-Image, also da habe ich erst gar nichts dann geändert im Grunde.

Aber das hier oben ist nochmal was Eigenes, das ist so ein sogenannter Bild-Kontext, das heißt, ich sage jetzt hier, außerdem gibt es hier noch ein paar Input-Dateien und ein sogenanntes Docker-File, haben wir ja bereits eben gehört, und bitte führ das auch aus und fahr das auch mit hoch, das heißt, ich habe, wenn das alles so durchläuft, habe ich eine komplette GDI.

Und das habe ich tatsächlich auch mal gemacht, also das ist die Ausgabe, wenn ich das entsprechend mache, das sieht jetzt sehr bunt hier aus, man sieht hier, das ist der Aufruf Docker-Compose-UP, in dem Fall ist das der konkrete Befehl, den ich ausführen muss, dann wird der Inhalt dieses Docker-Files ausgewertet und die entsprechenden Schritte ausgeführt. Jetzt sieht man hier dann die Log-Files entsprechend, also das sind Ausgaben vom Geo-Server,

wenn ich hier ein bisschen hochscrolle, der Geo-Server ist sehr log-freudig, aber irgendwann anders für den einer anderen Farbe, ja, wir warten ein bisschen, doch mal die Maus nehmen, naja, man könnte ja jetzt glauben, aha, so, hier ist nochmal irgendwas in Lila,

das ist jetzt eine Ausgabe von Geo-Network, sprich, die teilen sich in dem Moment quasi die Log-Ausgabe, wird in verschiedenen Farben gesagt, was die einzelnen Komponenten dort denn dazu vermelden haben, und auch hier, das ist ein weiterer Befehl, den ich machen kann, das ist das gleiche Verzeichnis, docker.ps sagt mir quasi auch die einzelnen Images, die halt dort sind,

also einmal talks-foskis-ul, das ist meine eigene Applikation, der Geo-Server läuft, Geo-Network läuft und das Postkiss läuft auch, alle so seit circa 38 Minuten, da hinten steht auch noch irgendwas zu verschiedenen Ports, weil das ist ja wichtig für die Kommunikation, das heißt, ich hab einen Befehl gemacht,

der Befehl hieß docker.compose, ich schreib ihn nur hier hin, ich führ ihn nicht aus, docker.compose, ab, und wie magisch werden diese vier Containern inklusive meiner eigenen Applikation gebaut, gestartet, und das alles ist in meinem lokalen Netzwerk verfügbar, und die alle können miteinander kommunizieren, und wenn die miteinander kommunizieren, sieht das ungefähr so aus, hier ist die entsprechende, das wollte ich als letztes zeigen,

also hier ist der Geo-Server, der läuft jetzt auf Port 88, das kennen Sie bereits, also Geo-Server haben Sie vielleicht schon mal gehört, ist halt eine Java-Applikation, läuft jetzt hier lokal bei mir auf Port 88, und dieser Port 88 kommt aus genau dieser

Konfiguration, da steht ja Port 88 zu 8080, das heißt, dieses Geo-Server-Image, was standardmäßig dabei ist, dieses startet halt den Geo-Server üblicherweise intern auf

Port 8080, ich möchte ihn aber in meinem Kontext gerne auf Port 8888 laufen lassen, das ist diese Konfiguration, und das führt dazu, dass der Geo-Server hier ist, da ist alles genauso, wie wir das immer schon kennen, hier läuft ein Geo-Network, die Datenbank zeige ich jetzt nicht, sie läuft aber, und das ist dann meine Open Layers-Applikation, eine wunderschöne Applikation, einfach eine Open Layers-Applikation,

der ich zoomen kann, und Sie sehen schon, da ist so eine rote Kiste, und die rote Kiste ist tatsächlich ein Punkt, höchstwahrscheinlich werde ich Dresden gewählt haben, irgendein Punkt in Dresden, und der zeigt jetzt den kompletten Durchstoß, nämlich, dass in der Datenbank ein Point mit irgendeiner Koordinat angegeben ist, und diese wird vom Geo-Server

ausgeliefert an meine Open Layers-Applikation, und ist letztlich, das ist meine GDI. Sie alle wissen, dass es noch krassere GDIs gibt, mit wesentlich mehr Funktionalitäten, ist mir völlig klar, aber es ist der technologische Durchstoß letztlich, und es war jetzt nicht übermäßig aufwendig, das so zusammenzusticken. Das heißt, wir haben eine GDI mit einer

Datei, die ist der Docker Compose Yumble letztlich, und einen Befehl erzeugt, und haben damit implizit dieses Dev Setup beispielsweise gezeigt, was man wunderbar benutzen kann. Das kann man so mehr oder weniger auch auf andere Applikationen übertragen. Da waren hier noch so ein paar Punkte, aber, jetzt kommen wir zu einem Punkt, der mir wichtig ist, dafür habe ich noch zwei Minuten, das reicht auch völlig aus. Die Diskussion. Es gibt Unterschiede je Environment, also wenn ich im Dev Setup

irgendwas laufen lasse, auf diesem Laptop hier ist ein großer Unterschied zu dem, wie wenn ich es produktiv laufen lasse. Die muss man bitte bedenken dabei, man möchte vielleicht auch eine Datenbank Service nehmen aus der Cloud oder so weiter. Die Umgebungen, die ich verwende, die sind vielleicht selber auch gehadend, also sprich, da sind doch ein paar andere System Umgebungen einfach voraussitzen. Und man muss auch schauen,

ob man irgendwie ein 0815 Image genommen hat, also zum Beispiel ist das Terrestris Geo Server Image vielleicht wirklich besser oder schlechter, weil es anders konzipiert wurde als Rezept, wie irgendeins von wem anders. Das muss ich mir schon anschauen, um da nicht irgendwas zu picken und damit letztlich eine zentrale Komponente zu haben. Wie ist es mit

existierenden GDIs? Ist das nur ein To-do, also wenn Sie jetzt, ich sage jetzt mal eine andere Komponente, die häufig, wenn Sie jetzt ein Map in der Installation haben, ist das nur noch ein To-do für die Menschen, die dahinterstehen, dass sie das migrieren oder sollte man das überhaupt machen? Also das muss man schon mal hinterfragen. Partizipiert man überhaupt davon, hat man alle Vorteile dann automatisch. Und dann ist noch was Schönes,

die Top 10 Most Popular Docker Images, die enthalten jeweils, ist eine Nachricht aus diesem Februar, 30 Vulnerabilities und wenn man mal genau guckt, war das nämlich so, wir haben eben meine eigene Applikation, ist eine Node Applikation, das sind die Top 10 Docker Images und da sind 580 Operating System Vulnerabilities drin, die habe ich

mal eben einfach so in meine GDI reingenommen und ich habe mir überhaupt keine Gedanken darüber gemacht. Das heißt, es ist kein 0850, also es ist vielleicht vorteilhaft an einer Stelle, dass ich das innerhalb von Stunden so aufgesetzt habe vielleicht, aber es hat auch einfach Konsequenzen, über die wir nachdenken müssen. Es ist nicht per se eine Lösung, ein Passpartout, die für alles einfach genommen wird und

dann ist alles gut. Security Concerns sollte man da insgesamt einfach machen. Es gibt Empfehlungen von Docker, wie man gewisse Sachen besser macht. Prüfen Sie, welches das Base Image ist, ob Sie ein aktuelles Base Image haben, prüfen Sie auch, ob Updates installiert wurden werden und wenn man einen Docker Fall macht, wie zum Beispiel

nimm dir Ubuntu und dann machst du erst mal die Installation der Updates, dann führt das übrigens dazu, dass das Image, was Sie dort gestern gemacht haben daraus, also das Container, den Sie daraus erzeugt haben und der Container, den Sie daraus erzeugt haben, letztlich doch verschiedene Instanzen sind, was doch wieder irgendwie ein bisschen diesem Grundkonzept irgendwie widerspricht.

Das ist die letzte Folie wirklich, das war durch der Schulungskonzern auch das, so eine GDI will geschult werden. Das, was ich jetzt hier gezeigt habe, ist auf einem Linux Setup. Unter Windows in einem Corporate Setup mit Proxies und so weiter und so fort kann das wirklich schlimm sein und schwierig sein, das alles so zum Laufen zu bringen. Es geht, da habe ich auch ein gutes Beispiel, aber es ist kein Passpartout. Und Summa summarum, es ist echt

interessant und sehr einfach, so eine GDI zu kompositionieren, aber es braucht anschließend noch Aufwand und Liebe, um da wirklich eine stabile und sichere GDI zu haben. Und damit danke ich für die Aufmerksamkeit und hoffe, Sie haben noch ein paar Anmerkungen. Ja, vielen Dank, Mark, für diesen schönen Vortrag.

Ja, wir haben gesehen, es gibt Vorteile, es gibt vielleicht auch Nachteile. Ein großer Vorteil ist sicherlich die Modularität. Gibt es da zu sagen?

Susanne, kurze Frage. Habt ihr Erfahrungen mit Engines, die Docker administrieren und verwalten können? Also mir ganz viele Docker-Container auf viele Rechner verteilen. Sowas wie Kubernetes und was auch immer und OpenShift, so diese ganzen

etwas größeren Sachen. Ja, haben wir Erfahrungen mit, haben wir in einem Projekt eingesetzt. Die Erfahrungen sind auch wirklich gut, aber auch da, es ist nochmal eine Komplexitätsebene, die eingezogen wird. So gut das auch ist, es ist wiederum ein Aufwand, der den dann ja DevOps-Engineer, jetzt in unserem Falle so zum Beispiel, da ist schon auch eine Menge noch an

Know-how, was man sich erstmal aufladen muss. Es ist ja dann wirklich, es ergibt sich ja klar, wenn man diese Schnittmenge abbilden will, muss man auch irgendwie ein bisschen was von dieser klassischen Ops-Knowhow, also Admin-Knowhow einfach mitbringen, sonst kann man diese Aufgaben auch nicht jemandem übertragen. Wir haben gute Erfahrungen gemacht, aber letztlich gilt da leider auch das gleiche. Es ist eine extrem schnelllebige Landschaft.

Wir haben auch mehrmals den Kontext gewechselt, die Software, die Technologien, die wir da verwendet wollen, um eine Orchestrierung von vielen Images zu machen. Das war ja hier so die Kindergartenvariante vielleicht, aber es gibt da durchaus noch größere Tools, wie du sie auch gerade angesprochen hast. Gute Erfahrungen gemacht, aber es ist auch ein relativer Invest, muss ich dazu sagen. Es lohnt sich glaube ich im

Ende wirklich für so Sachen wie Infrastructure as Code, also wirklich ein Commit auf meiner Open-Layers-Applikation. Ich möchte jetzt noch eine weitere Funktion, die wir da drin haben, führt dazu, dass ich auf irgendeinem Cloud-Service die komplette Infrastruktur hochfahre. Das ist super natürlich, also das hat auch extreme Vorteile, aber es ist auch wie immer leider kein Passpartout und man muss es einfach so nehmen.

Danke. Hallo, Sie haben ja jetzt Standard-Images benutzt, die im Standard auch erstmal leer sind, aber auch für Entwicklung oder lokale

Rechner möchte ich ja vielleicht schon mal einen Datensatz haben, der ganz hilfreich ist, vielleicht auch mit eigenen Daten, nicht unbedingt was Öffentliches. Wie verteilen Sie Daten oder haben Sie da eine Lösung für? Also wir haben Probleme schon gehabt mit großen Datensätzen, dann Docker-Images zu bauen. Ja, glaube ich sofort. Also für die

Development-Umgebung ist beispielsweise beim Geo-Server ist es der Fall, da kann man externes Data Directory ein- mounten, quasi innerhalb dieses Containers kann ich sagen, quasi das Verzeichnis XY ist in wirklich das Verzeichnis, was sich wirklich physisch auf diesem Rechner hier befindet und da kann man natürlich dann entsprechend drauf zugreifen und das könnten dann zum Beispiel eine Menge an Geo-Packages

sein, die man im Geo-Server zum Beispiel drin hat. Das geht genauso wie jetzt auch hier in dem Fall, dass die Datenbank, die hat auch ein externes Verzeichnis, in das sie ihre Daten Directory ablegt, also quasi eine Änderung, die ich dort vornehme in der Datenbank, wird ja persistiert, am Ende sind es doch irgendwie Dateien und auch das liegt

auf meinem lokalen Rechner. Das heißt auch das könnte ich zum Beispiel versionieren oder mir woanders her beziehen und überschreiben. Großes Vorsicht, dann kommen sie relativ zügig in diese Probleme mit Dateisystems rechten, also quasi muss das der Root-User vielleicht machen, damit es überhaupt lesbar ist. Das wird auch durchaus hakelig. Also das war die lange Antwort, die kurze Antwort ist, es gibt Wege und

Möglichkeiten drumherum, wenn es große Daten werden, wird es eine Herausforderung sicherlich und es gibt auch da leider noch nicht, also was mir bekannt ist, auch dafür gerne aus dem Auditorium noch jemand was zu sagen, das sind so Dinge, die wir tatsächlich einsetzen, ein externes Data Directory, wo dann Daten mit drin sind und die sind dann verfügbar im Container, weil es reingemontet wurde. Das reicht

für Dev-Zecke höchstwahrscheinlich aus, für so Produktivumgebungen sicherlich eher nicht. Man könnte genauso gut, fällt mir gerade ein, man könnte genauso gut auch einen Skript machen, was halt einfach gewisse Schritte noch macht, nachdem gewisse Sachen passiert sind. Also wenn die hochgefahren sind, mache ich noch so ein Image, das dependiert, also ich mache eins, was vom Geo-Server abhängt, depends on Geo-Server und sag dann, wenn du hochfährst, beziehst du

mir die Daten von dort und führst gegen, in diesem Netzwerk bitte folgende Insatztatements aus oder WFST-Transaktionen oder kopierst irgendwas hin und her. Das wäre eine andere, dann hätte man das auch versioniert, wäre eine andere Alternative, die mir jetzt spontan einfallen würde, für größere Sachen. Eine letzte Frage noch und ich bitte Mark um eine kurze Antwort.

Habt ihr Erfahrung damit, automatisch herauszufinden, ob es neue Versionen von Images gibt, um genau diesem Sicherheitsproblem aus dem Weg zu gehen? Ja, in der Form, in der wir pollen, also das ist halt die billige Variante von, wir haben einen Cronjob, die für verschiedene Dinge einfach immer weiter ganz stumpf neu baut und entweder kriegen wir neue Dinge oder eben nicht. Also es ist nicht

wirklich mitbekommen, sondern es ist ein Polling, der ungedrehte Fall. Kurz genug. Super, alles klar. Vielen Dank Mark Jansen für diesen schönen Vortrag.