Okay, machen wir weiter. Dann hier herzlich willkommen zur zweiten ADAP Woche und zum Vorlesungsteil. Heute besprechen wir Containerisierung und das Ganze mit Docker.

Um nochmal zu gucken, ja hier in ADAP, in der Vorlesung geht es ja eigentlich hier um so Entwurf und gute Software. Und ja, was hat das Ganze jetzt vielleicht nochmal mit Containern zu tun?

Wenn ihr mal daran denkt, an so einen kompletten Software-Lebenszyklus, da ist ja so Entwurf, Design ist ja ein Teil davon.

Dann gibt es hier den Implementierungsteil, wo man es dann umsetzt. Und es gibt auch Testen und ganz zum Schluss hat man auch sowas wie das Ausliefern der Software ist auch ein Teil.

Und dadurch, dass sich quasi in den letzten Jahren schon einiges hier geändert hat durch Containertechnologien und das quasi immer zu einem wichtigeren Werkzeug wurde für zur Softwareentwicklung, wollen wir das jetzt auch nochmal hier ansprechen.

Und diese Vorlesung dient hier quasi als Einleitung, hier wird nicht alles über Docker erklärt, aber so ein bisschen Einleitung, was es damit auf sich hat und grundlegende Konzepte und wie man es verwendet.

So, warum das Ganze jetzt mal? Wenn man mal sich guckt, man hat einerseits, vielleicht hat man hier so eine monolithische Anwendung.

Da kann es sein, ja es kann einfach sein, aber es könnte auch schon ein bisschen komplex sein, wenn man in anderen Technologien steckt mit Abhängigkeiten.

Aber was ja auch immer mehr verwendet wird, ist, wenn man so einen Architekturstil hat, der sich so an Microservices orientiert, wo man dann nicht nur einen Monolithen hat, sondern unterschiedliche Anwendungen, die unterschiedliche Funktionalitäten, Fachlichkeiten, ein bisschen so Kapseln.

Und da wird auch der Technologie-Stack heterogener. Hier haben wir mal so ein Beispiel gemacht, man hat hier zum Beispiel drei Services, hier ABC, dann hat man vielleicht noch ein Frontend, also hier nochmal eine zusätzliche Komponente.

Dann hat man andere Abhängigkeiten wie Datenbanken, hier könnte es sein eine PostgreSQL und eine MongoDB. Und wie ist denn das?

Jetzt habe ich hier ein Service, also zwei Services, hier ist ein Beispiel, sind mit Java implementiert, aber dann auch wieder die Sache, ja was für Java, welches JDK, welche Version, vielleicht ist das eine ein bisschen so ein Legacy System, ein bisschen gewachsen, habe ich was Neues.

Das habe ich mit dem allerneuesten JDK gebaut, um irgendwie spezielle Features zu nutzen, die mir das bereitstellt. Dann habe ich vielleicht nochmal so einen anderen Service in Node.js oder einer anderen Technologie gemacht, weil mir das vielleicht ein bisschen das bessere Werkzeug für den Ein-Anwendungsfall ist.

Oder könnte auch so etwas wie Python sein, wenn man dann speziell was hat. Und wenn man sich das mal so überlegt, da hat man ja schon so viele unterschiedliche Abhängigkeiten, einerseits zwischen den Entwicklern, ich habe jetzt mal auf meinem Notebook, habe ich die und die Version installiert, der Kollege, die Kollegin hat da vielleicht ein kleines bisschen eine andere Version installiert, da wird es schon kompliziert.

Aber dann haben wir ja noch gesagt, ja wir haben auch so etwas wie CI Server hier, QA Server, der nochmal was überprüft, der hat ja quasi auch nochmal die unterschiedlichen Versionen zu dem kompletten Technologie Stack installiert, da muss man aufpassen, da wird es auch nochmal ein bisschen komplizierter.

Und dann haben wir natürlich das Produktivsystem, hat das auch überall die gleichen Versionen wie alle anderen auch, ihr seht, das wird dann auf einmal nicht mehr so einfach, dass man nur sagt, ok ich brauche nur das eine JDK oder nur die eine Technologie und dann passt das.

Also hier haben wir aufgeschrieben, ok es kann hart sein so einen komplexen Technologie Stack zu managen und speziell wird es noch härter, wenn man das nochmal verteilt hat auf unterschiedliche Servern und unterschiedliche Systeme.

Da kommt natürlich immer solche Sachen zusammen wie ja bei mir läuft es ja hier und es wird dann ziemlich schwer und um das da zu vermeiden ist man dann halt, hat man ein bisschen so Container eingeführt.

Wenn man mal guckt, wo kommt denn das ganze her, es gibt ja schon unabhängig von jetzt hier von Informatik, es gibt ja mal dieses Transportation Problem, das hatte man, da war die Problematik, ok ich habe unterschiedliche Güter, die können unterschiedlich groß sein hier auf dem einen so ein Beispiel so etwas wie Schüttgut oder Gewürze, dann hat man aber auch irgendwelche größeren Pakete, hier ist mal so ein Auto mal als Übertreibung gemacht.

Es gibt ja auch unterschiedliche Waren, die haben wirklich unterschiedliche Größen, es ist schwer zu fassen plus die müssen auch auf unterschiedlichsten Wegen mal irgendwie ausgeliefert werden.

Einerseits hier mit dem Schiff, mit der Bahn, vielleicht mit dem Flugzeug, mit dem LKW und die müssen ja, die müssen ausgeliefert werden und was hat man dann gemacht?

Dann hat man ja den Schiffscontainer eingeführt, der das ganze mal ein bisschen standardisiert hat, hier sieht man es ja, rechts unten der 40 Fuß Schiffscontainer, der ihn seit ein paar Jahrzehnten gibt und was der quasi gemacht hat, es gab auf einmal so eine standardisierte Form, wie man Sachen einpacken kann.

Der 40 Fuß Container hat immer seine feste Größe, man wusste, okay, ich kann meine Waren in den Container packen mit anderen Sachen und so wie der Container ist, kann er ausgeliefert werden, auch auf den unterschiedlichsten Wegen.

Einerseits auf dem Schiff, von da kann man auch wieder umlagern, auf die Bahn oder auf dem LKW, ist alles möglich, das heißt man hat das hier ein bisschen entkapselt, wie so eine Ware transportiert werden muss.

Und durch diese standardisierte Verpackung wurde das viel, viel einfacher. Und genau diese Analogie, so ist es auch mit den Containern, die wir verwenden wollen.

Wir wollen unsere Anwendungen, so unterschiedlich sie auch sind, mit den unterschiedlichen Theologien, wollen wir eine Möglichkeit finden, die standardisiert zu verpacken, damit wir eine Form haben, wie wir damit umgehen können.

Und genau das ist es, was wir mit Containern dann machen. Hier, das ist quasi wie Docker sich auf eigener Seite seiner Seite beschreibt.

Und dann mal hier diese, wenn man sich so die drei Schlagworte anguckt, das ist das, was man sich vielleicht merken sollte.

Wie man Bild, die Container, die Images bauen, share miteinander teilen oder sich welche holen und dann der letzte Teil run, das dann entsprechend auf eure Maschine, auf einem Produktivserver laufen lassen.

Ja, was sind denn jetzt hier die Vorteile? Also einerseits, wie gesagt, okay, das ist jetzt diese Form von diesem standardisierten Verpacken, meine Anwendung, mit deren Abhängigkeiten, die dazu noch notwendig sind.

Das hilft es mir dann einerseits, dass auch für die Anwendung immer eine konsistente Umgebung bereitstellt.

Also so, wie ich das gemacht habe, für meine Anwendung ist immer das korrekte Java JDK oder runtime environment oder eine andere Umgebung immer vorhanden mit entsprechenden Abhängigkeiten.

Und das kann dann so laufen gelassen werden auf den unterschiedlichen Systemen.

Dann, ich habe hier diesen Faktor der Isolation. Ich kann meine Anwendung in separate Container packen. Die sind voneinander isoliert.

Es gibt vielleicht keine komischen Seiteneffekte, dass sie sich gegenseitig irgendwie beeinflussen würden.

Das hat auch ein bisschen so einen Sandboxing Charakter. Aber hier kommt es immer ein bisschen darauf an, wie die Sicherheitseinstellungen sind, weil so wie das bei Docker gemacht ist,

man hat natürlich Einstellungen, die sind so ausgelegt, dass die meisten Entwickler und Entwicklerinnen das so nutzen können, ohne direkt Probleme zu haben.

Also es ist nicht zu restriktiv, dass es viel Arbeit ist, damit umgehen zu können, aber es ist auch nicht zu offen, um gleich so ein Scheuntor aufzumachen.

Dann natürlich hier dieses Versprechen, Bild once, run everywhere.

Wie ihr gesehen habt, ihr habt es ja schon gesagt, wenn man hier Windows verwendet, wird es ein bisschen komplizierter. Das ist hier beim Bildteil. Aber wenn man dann mal so ein Image zusammengebaut hat,

dann ist es eigentlich schon so, dass man das überall laufen lassen kann und dass man da eigentlich dann nicht so die Probleme hat.

Ein anderer Teil ist jetzt noch hier dieses Infrastructure aus code. Das ist natürlich auch sehr interessant, denn wo man vorher auf einem anderen System hat oder bei sich,

man musste ja quasi auch wissen, welche Abhängigkeiten zu Technologien habe ich, was muss der Surfer, der Rechner irgendwie installiert haben, damit es irgendwie lauffähig ist.

Und das sind ja so Sachen, die waren ja sonst separat von code gehalten und das musste irgendwie dokumentiert werden.

Wenn ich aber hingegen das in so einem Dockerfile, das schön definiert ist, dann ist es ja klar, was ich da für Abhängigkeiten habe, in welchen Versionen ich das habe.

Dann zudem, wenn ich das in meinem Versionsverwaltungssystem noch mit einchecke, ist das auch noch mal versioniert, was natürlich ein großer Vorteil ist.

Wenn wir sagen, Container, so eine Anwendung wird nochmal verpackt und ein bisschen isoliert, da gibt es ja auch hier virtuelle Maschinen.

Virtuelle Maschinen kennen wir ja auch. Und da nochmal, um das mal ein bisschen gegenüberzustellen, was jetzt so ein bisschen Unterschied ist zwischen Containern und virtuellen Maschinen.

Auf der linken Seite seht ihr ja bei so einer kompletten virtuellen Maschine, ihr habt hier ganz unten die Hardware, dann habt ihr dieses Hostbetriebssystem,

dann hier ein bisschen so ein Hypervisor, nochmal diese Virtualisierungsschicht, auf dem das stattfinden kann.