To Docker or not to Docker: wie Container­techno­logien unser Leben verändern

Transkription

Konstantin Bauer: Hallo, herzlich willkommen zur neuen Folge von „Querverlinkt“! Meine Stimme ist neu, deswegen will ich mich kurz vorstellen. Mein Name ist Konstantin, ich bin Softwareentwickler bei consistec, arbeite da am Backend. Und zum Glück darf ich mir die heutige Podcast-Moderation teilen mit dem Dennis, groß geworden mit der Podcast- Folge 14 über das Thema Cloud. Hi, Dennis!

Dennis Groß: Hi! Ich stelle mich auch nochmal für alle vor. Ich bin der Dennis, ich bin auch in der Softwareentwicklung bei consistec tätig. Im Frontend und auch im Backend.

Konstantin Bauer: Schön, dass wir uns auch hier noch mal live in Farbe sehen. Die letzten Treffen, die wir hatten, waren immer über einen Bildschirm, per Kamera. Ich habe einen matrixhaften Einstieg vorbereitet. Ich habe keine Pillen mitgebracht, sondern Karten und du darfst dich entscheiden.

Dennis Groß: Okay! Also es gibt jetzt eine rote und noch eine grüne Karte?

Konstantin Bauer: Es gibt eine rote und eine blaue Karte. Genau! Es passiert in beiden Fällen nichts Schlimmes, das kann ich dir versprechen.

Dennis Groß: Ich bin mutig, ich nehme, glaube ich, die rote Karte.

Konstantin Bauer: Ich glaube, die gefällt dir. Du bist auch ein Musik-Fan. Die Frage lautet... ruf einfach rein: Kennst du folgenden Liedtext? Ich bin schweißgebadet aufgewacht nach einer Horrornacht. Sowas Blödes habe ich noch nie geträumt. Ich habe richtig Panik gehabt. Denn es war so, ich stand am Strand und vor mir lag ein Wal. Er lebte noch, ich war allein, es war so eine Qual. Ich bin nicht der Stärkste, das Tier war tonnenschwer, und die Wellen haben gerufen „Schieb den Wal zurück ins Meer“. Kennst du das?

Dennis Groß: Ich habe das mal gehört, aber ich weiß tatsächlich nicht, von wem das ist.

Konstantin Bauer: Macht auch nichts. Das war mal ein Hit von den Toten Hosen. Aber du kannst dir wahrscheinlich denken, warum ich den Text gewählt habe.

Dennis Groß: Weil bei uns heute geht’s um Container-Technologien. Im Konkreten geht’s um Docker und wie die Container-Technologien unser Leben als Softwareentwickler stark geprägt haben und immer noch prägen. Und da der Wal so ein bisschen das Maskottchen von Docker ist, passt das natürlich ganz gut in den Kontext.

Konstantin Bauer: Ja genau! Ich hatte auf jeden Fall, bei "Wal" kommt mir dann immer dieses Lied in den Sinn. Ich dachte, vielleicht kennst du das auch. Aber genau, das ist unser heutiges Thema, Docker und Container. Docker sind 2013 damals gestartet. Ist jetzt also schon ein paar Jährchen in der Welt draußen. Wie war das für dich damals? Wann bist du das erste Mal auf Docker gestoßen und wie war deine erste Begegnung damit?

Dennis Groß: Das erste Mal Docker gehört habe ich von Freunden von mir. Die haben an der Universität so ein Start-up gegründet und die haben mir dann irgendwas erzählt, dass die jetzt Docker verwenden und dass das alles total klasse ist, dass es alles viel einfacher gemacht hat mit dem Deployment. Ich kannte das tatsächlich vorher nicht, also bin ich direkt mal ins Internet und habe mal Docker eingegeben. Da habe ich auch relativ schnell eine Dokumentation dazu gefunden. Aber es war für mich am Anfang relativ schwer, mal wirklich durchzublicken, was das jetzt genau ist so ein Container, was bringt mir das, was macht das, wie arbeite ich damit? Das hat relativ lange gedauert, bis ich mal so dieses Konzept von den Containern wirklich verstanden habe, weil das auch schon ziemlich weitgehend ist und weil man viel damit machen kann. Und deshalb wollen wir heute auch mal das Ganze so ein bisschen durchleuchten, auch mal so ein bisschen drüber nachdenken: Wofür brauche ich es eigentlich? Was mache ich denn eigentlich damit?

Konstantin Bauer: Ja. Aus der Hinsicht wollen wir auf jeden Fall uns nähern. Bei mir war es auch ähnlich, ich hatte lange Zeit keine Vorstellung, wie ich es eigentlich verwende. Jetzt heute sind wir an dem Punkt, dass wir es sehr regelmäßig und gerne einsetzen. Und für all diejenigen, die bisher Docker auch immer nur begegnet sind, aber selbst noch nicht gearbeitet haben, wollen wir da mal einen kleinen Einstieg bieten. Und vielleicht diejenigen, die Docker schon kennen, können trotzdem das ein oder andere Neue mitnehmen.

Dennis Groß: Vielleicht fängst du mal an und erklärst den Leuten, was so ein Container überhaupt ist, wofür man das braucht.

Konstantin Bauer: Ja. Vielleicht fangen wir mal so an. Ein Container ist eine Einheit, in der ich meine Anwendungen, die ich entwickelt habe, verpacken kann mit all ihren Abhängigkeiten und diesen Container kann ich sozusagen als verschiffbare Einheit bei mir lokal laufen lassen oder auf irgendeiner anderen Maschine.

Dennis Groß: Und da so ein bisschen auf die technischen Hintergründe wollen wir auch heute eingehen. Konstantin, jetzt hast du mal erklärt, was so die grundlegende Idee ist von einem Container. Jetzt erkläre doch mal den Leuten, für was sollte man denn eigentlich so Container verwenden?

Konstantin Bauer: Ich verwende im Moment Container relativ viel in Integrationstests. Also ich verwende es, um Abhängigkeiten vor einem Test zu starten. Zum Beispiel eine Datenbank, ich habe eine saubere Umgebung dann in dem Container, kann den mit Daten füllen und am Ende des Tests wird der Container wieder entfernt. Da denke ich auch an meine Zeit als Werkstudent zurück. Da hatte ich nämlich eben soein Setup nicht verwendet, ich habe stattdessen mit einer Testumgebung getestet, habe da ein bisschen dran rumgespielt an meinen Tests, und auf einmal ist es passiert, dass alle Daten in der Datenbank weg waren. Also die Frage ist natürlich eh, war das sinnvoll, das so zu tun, ja oder nein. Aber alles zu spät, es ist passiert. Und mit Containern wäre das nicht passiert.

Dennis Groß: Also so diesen typischen Drop Table …

Konstantin Bauer: Ja, genau!

Dennis Groß: … Test geschrieben.

Konstantin Bauer: Nur leider habe ich damit alle betroffen und nicht nur mich. Wie war es dann bei dir? Hast du auch so eine Situation im Sinn?

Dennis Groß: Das letzte Mal, bei dem ich besser Docker verwendet hätte, das ist gar nicht mal so lange her. Und tatsächlich mal einen Software Release gemacht von einer Python Software, von einem Framework, was wir unseren Kunden anbieten. Und das hat gebaut, die Tests liefen bei mir, die liefen auch bei meinem Arbeitskollegen, die liefen auch auf unseren Jenkins, das ist so eine CI/DC Software, bei der man so Sachen automatisch testen kann. Da lief das in einer VM und da dachten wir „Gut! Läuft“. Haben wir released, hat nicht lange gedauert, da hat sich der Kunde wieder bei uns gemeldet, haben wir so gut die Hälfte der Dependencies in dieser Dependency Datei, in dieser Requirements Datei einfach vergessen. Und das ist einfach darauf zurückzuführen, dass bei uns in dem System auf dem Laptop schon alles installiert ist, und Jenkins war schon alles installiert. Da ist das einfach nicht aufgefallen, dass da etwas fehlt an den Dependencies. Und wenn die da jetzt einen Container verwendet hätten, wäre das immer wieder so eine ganz frische Umgebung gewesen, bei der man von null startet, und dann wäre das natürlich direkt aufgefallen. Da wäre die Software gar nicht gestartet, weil da Abhängigkeiten in der Requirements Datei jetzt gefehlt hätten. Da frage ich dich mal direkt. Ich weiß, dass du vor nicht allzu langer Zeit was mit Docker gemacht hast. Vielleicht kannst du da mal erklären, wo du da das letzte Mal als Softwareentwickler jetzt wirklich Docker verwendet hast, wofür.

Konstantin Bauer: So mein momentanes Go-To-Szenario für Docker ist im Bereich "Testing", also in Richtung Integrationstest. Wenn ich eine Komponente habe, die eine externe Abhängigkeit verwendet wie zum Beispiel eine Datenbank und ich möchte testen, funktioniert mein Code in der Hinsicht, dass der die Datenbank richtig abfragt, dass der die Daten, die von der Datenbank zurückgeliefert werden, auch richtig verarbeitet. Dass ich dann zum Testen mir so einen Docker Container starte, statt dass ich auf irgendeine vorhandene Testumgebung angewiesen bin. Das ist einfach ein super Einsatzszenario, weil ich wirklich konkret schon mit der Datenbank arbeiten kann, aber alles läuft nur lokal bei mir auf dem Rechner und ich bin nur bei mir unterwegs und laufe nicht irgendwie Gefahr, wir machen das da um irgendwem in die Daten zu pfuschen.

Dennis Groß: Es geht quasi in diesem großen Use- Case, um irgendwelche Integrationstests die verschiedenen Komponenten miteinander testen und dieser so ein gewisses Test-Setup braucht, und in deinem Fall halt die Datenbank. Und das möchte ich auch irgendwie automatisieren, dass diese Datenbank in dem System, in dem ich teste, halt zur Verfügung stellt. Und dafür benutzt du letztendlich Docker.

Konstantin Bauer: Und in der Hinsicht bieten sich Container an, weil sie sehr kurzlebig sind. Ich kann den Container starten, ich kann was damit machen. Der Container wird beendet und fertig. Das ist auf jeden Fall ein Einsatzgebiet von Containern.

Dennis Groß: Was wir jetzt auch so in dem Bereich, wo ich jetzt momentan bei der consistec tätig bin, viel machen: Wir haben so ein Jenkins, das ist so ein CI/CD Server, da kann man dann quasi irgendwelche Tasks automatisieren, irgendwelche Tests laufen lassen, solche Sachen. Das sind wir jetzt momentan in dem Bereich, wo ich tätig bin, auch umgestiegen und benutzen da auch ganz viel Container. Wir haben da irgendwelche Tests, wo zuerst mal ein Stück von der Software gebaut wird und dann wird mal getestet, ob das alles funktioniert und dann wird es vielleicht auch noch deployt. Da haben wir einfach festgestellt, dass das mit Containern viel einfacher geht, als wenn man solche Jenkins Jobs, nennt sich das das, dann direkt auf einer VM laufen lässt, wo man dann bei den Containern immer so eine ganz frische Umgebung hat. Da merkt man dann auf einmal, ah okay, bei diesem Python Projekt, da fehlen dann doch noch ein paar Abhängigkeiten. Wenn du das dann so in der VM hast, hast du die Sachen vielleicht schon manuell installiert und merkst das dann einfach nicht, wenn mal was fehlt.

Konstantin Bauer: Man schüttet sich auch nicht direkt zu mit Abhängigkeiten, die man vielleicht nur mal kurz braucht.

Dennis Groß: Das sind so zwei große Use Cases, CI/CD, also Continuous Integration / Continuous Delivery, Testen natürlich auch. Ein weiterer großer Use Case ist die Entwicklung an sich und Produktivsysteme später. So ist es ganz gut, wenn man sein Produkt jetzt in einem Container quasi auf dem Zielsystem zur Verfügung stellt und den gleichen Container auch relativ unkompliziert auf seinem eigenen Entwickler-Laptop laufen lassen kann. Da hat man einfach letztendlich auch einen wirklich starken Bezug zwischen der Entwicklungsumgebung und der Produktivumgebung. Das heißt, wenn ich jetzt einen Fehler habe in der Produktivumgebung, dann ist es relativ wahrscheinlich, dass ich das auf meiner Entwicklungsumgebung so auch mit dem Container dann mal reproduzieren kann.

Konstantin Bauer: So dieser klassische Fehler, in den eigentlich wahrscheinlich jeder schon mal reingelaufen ist, „Runs on my Machine“ und ich gebe die Software weiter, aber auf einer anderen Maschine tut sie es auf einmal nicht mehr.

Dennis Groß: Die typischen Dinger, das läuft dann nachher auf irgendeiner produktiven VM und irgendjemand hat sich dann mal montagabends um acht Uhr da mit SSH eingewählt, hat mal noch ein paar Config-Dateien rumgeschoben, hat dann vielleicht noch was installiert und dann sind die Abhängigkeiten und die Konfiguration ist ein bisschen leicht anders auf dem produktiven System und dann wundert man sich, warum das jetzt bei dem Entwicklungssystem auf meinem Laptop jetzt nicht so läuft. Da hilft einem ein Container einfach weiter, weil das immer die gleiche Umgebung zur Verfügung stellt.

Konstantin Bauer: Ich denke, das waren schon mal klassische Einsatzszenarien. Und jetzt haben wir schon viel von Docker und Container gesprochen. Sollen wir damit weitermachen? Vielleicht ein bisschen nochmal aufzurollen, was ist das Ganze?

Dennis Groß: Genau!

Konstantin Bauer: Sollen wir vielleicht auch einmal kurz sagen, Docker und Container, wie ist da der Zusammenhang?

Dennis Groß: Vielleicht erklärt man mal zunächst, was so der Unterschied zwischen einem Container und einer virtuellen Maschine ist. Virtuelle Maschinen, die meisten Leute kennen das schon, viele kennen jetzt vielleicht Container noch nicht so den Unterschied. Die Idee bei einer virtuellen Maschine ist im Prinzip, ich habe irgendwo in meinem Rechenzentrum konkrete Hardware zum Speichern von Daten für das Netzwerk rumliegen und ich versuche die ein bisschen abzugrenzen. Ich will nicht nur einen Supercomputer haben mit einer Hardware, sondern ich will mehrere kleine PCs im Prinzip haben. Und dann hat man ein Modul, das nennt sich Hypervisor, und der geht hin und unterteilt diese Hardware, die man rumliegen hat, in virtualisierte Hardware. Was da rauskommt, wenn ich diese virtualisierten Netzwerke, Speicher, Systemressourcen zusammenbündele, da habe ich nachher eine virtuelle Maschine. Da ist ein Betriebssystem drauf und dieses Betriebssystem hat so einen Betriebssystemkern. Dieser Kern weiß, wie man mit diesen virtuellen Ressourcen umgeht, zum Beispiel wie ich dann letztendlich etwas speichere. Das ist letztendlich die VM. Ich mache aus einer konkreten Hardware mir ganz viele kleine VMs, also viele kleine PCs sozusagen. Das hat Vorteile, das hat aber auch Nachteile. So eine VM ist schon relativ groß, meistens im Bereich von mehreren Gigabytes. Jetzt will man natürlich gerne Software in unterschiedlichen einfach Systemen deployen, damit sie voneinander abgegrenzt sind, also isoliert. Jetzt kann man natürlich klassischerweise hingehen und kann sich für jede Software, für jeden Service da eine eigene VM machen. Das ist aber immer relativ zeit- und ressourcenaufwändig, weil diese Virtualisierung sehr teuer ist. Also hat man jetzt diesen Container entwickelt, und der Container ist im Prinzip so ein Prozess, der läuft einfach auf der virtuellen Maschine und der virtualisiert sozusagen das Betriebssystem. Was das heißt, ist: Ich kann jetzt einen Docker Container haben, der hat ein Ubuntu Betriebssystem. Jedoch hat dieses Ubuntu Betriebssystem keinen eigenen Betriebssystemkern, sondern der benutzt einfach den Betriebssystemkern von dem Betriebssystem der virtuellen Maschine. Das heißt, der Container läuft auf der virtuellen Maschine als Prozess und für den Nutzer von diesem Container, innen drin sieht das so aus als hätte der hier ein vollwertiges Ubuntu Betriebssystem. Das ist im Prinzip die Idee, die Virtualisierung von einem Betriebssystem. Dadurch ist man natürlich dann auch deutlich ressourceneffizienter.

Konstantin Bauer: Ich habe meistens mehr die Entwicklerbrille auf, gar nicht die operative Brille. Aus eigener Erfahrung kenne ich es auch, wenn ich jetzt mir eine virtuelle Maschine aufgesetzt habe, das ist jetzt halt nicht automatisiert gewesen, aber per Hand starte ich mir irgendwie VirtualBox, installiere mir ein Image und muss dann erst mal noch, sobald das Image installiert ist, irgendwelche Konfigurationen vornehmen, bis ich mir dann mal Software installiere. Und dann ist auch schon viel Zeit vergangen. Und mit Docker ist das einfacher geworden. Wenn ich mal irgendwas laufen lassen will, finde ich da auch meistens eine Dokumentation schon in den Produkten, irgendwo steht schon der Docker Befehl „docker run“ und schon habe ich irgendwas mal supereinfach gestartet. Das ist auch meistens schneller passiert.

Dennis Groß: Das ist einer der Hauptgründe. Wenn man das jetzt mal so gegenüberstellt, sagt man so, eine VM, die ist mehrere Gigabyte groß, ein Container ist, wenn er gut geschrieben ist, mehrere Megabyte groß. Eine VM, um hochzufahren, also mit dem Hypervisor die Virtualisierung das alles zu machen, da ist man meistens bei mehreren Minuten, bei einem Container ist man da wirklich im Sekundenbereich. Das gibt einem einfach nochmal ganz andere Möglichkeiten und deshalb sind die Container so beliebt, weil die natürlich dadurch auch einfach sehr ressourcen- und zeiteffizient sind.

Konstantin Bauer: Vielleicht noch kurz eingeworfen, so die Beziehung Docker und Container ist ein bisschen so wie Tempo und Taschentuch.

Dennis Groß: Genau!

Konstantin Bauer: Also Docker ist ein Tool im Bereich der Container-Technik, also Container ist ein Konzept und Dockers ist das explizite Tool.

Dennis Groß: Es gibt da in dieser Container-Welt verschiedene Abstraktionsschichten und Standards. Da wollen wir jetzt nicht im Detail genau drauf eingehen, weil es ein bisschen zu weit geht. Aber die Idee ist, Docker, die sind relativ bekannt, weil die den Container auch ein bisschen populär gemacht haben, sage ich jetzt mal. Aber das Docker bietet im Prinzip einmal so ein Tool-Set an, um Container zu entwickeln und zu deployen. Aber da gibt’s dann auch ganz viele verschiedene. Und dann gibt’s unter diesen Docker Tools dann auch sogenannte Docker Runtime, das sind Container Images. Also da gibt’s relativ viele Abstraktionsschichten. Und letztendlich ist das ein ziemlich modulares System und Docker ist einfach so eine Firma, die so ein Tool-Set quasi für ihre Container-Technologie zur Verfügung stellt.

Konstantin Bauer: Du hast recht, sie haben es auf jeden Fall geschafft, das ganze Thema stark zu pushen und da auch irgendwie ein Ökosystem zu schaffen, was einfach diese ganze Container-Technik jetzt mittlerweile sehr etabliert hat.

Dennis Groß: Ich glaube, sie waren noch nicht mal die ersten, die den Container …

Konstantin Bauer: Ja genau!

Dennis Groß: … erfunden haben, der ist schon ein bisschen älter. Aber sie waren, glaube ich, definitiv maßgeblich an dem Erfolg beteiligt, dass das so ein großes Thema geworden ist. Heutzutage ist das schon der neue Standard im Prinzip, dass man seine Software auf einem Container deployt und nicht mehr direkt auf der VM. Das kommt auch immer mehr, also der Trend geht einfach dahin. Deshalb ist es für jeden, der jetzt da zuhört beim Podcast, der sich da vielleicht jetzt noch nicht auskennt, aber wirklich mal interessant die Zeit zu investieren und sich da mal einfach zu informieren, weil man auch als Softwareentwickler durch Container-Technologien aber auch viel mehr Möglichkeiten hat seine Software zu deployen. Und heutzutage sagt man, diese DevOps Culture, wir sind alle nicht nur da, um Code zu schreiben, sondern auch ein bisschen dafür da, den Code zu deployen. Dann macht das auf jeden Fall mal Sinn sich auch mit Container-Technologien als Entwickler zu beschäftigen.

Konstantin Bauer: Ja. Da fällt mir auch gerade ein bei der Gelegenheit, in unserer Vorbereitung sind wir auch auf Katacoda, ist von O’Reilly, so eine E-Learning-Plattform gestoßen. Die bieten auch Lektionen zu Docker an. Das können wir auch in die Shownotes packen. Da gibt’s auch eine Umgebung, da ist Docker schon vorinstalliert. Also wenn man das einfach gar nicht bei sich auf dem Rechner haben möchte, aber man möchte es mal verwenden, dann ist das sehr empfohlen, da mal sich rein zu klicken und einfach mal ein paar Befehle abzusetzen. Macht vielleicht auch die ganzen Konzepte dann ein bisschen greifbarer, weil man einfach mal per Hand Befehle eingetippt und abgesetzt hat und sieht, was passiert. Und man kann auch absolut nichts kaputtmachen. Das beruhigt dann vielleicht auch.

Dennis Groß: Das ist immer wichtig, das ist immer beruhigend. Ich denke auch, das ist ganz sinnvoll, das so zu lernen. Ich habe damals, also ich es das erst Mal gehört habe, Docker, habe ich so High Level versucht zu verstehen, was das überhaupt ist. Da sind relativ viele abstrakte Konzepte, die da dazukommen. Wir gehen gleich noch auf einige davon ein und auf das ganze Docker Ökosystem. Aber in der Praxis ist es glaube ich am besten, wenn man einfach mal Hands on was probiert. Und mit diesem Katacoda, da hat man auf der Webseite dann so einen Terminal und dann kann man die Sachen einfach mal ausprobieren, so einen ganzen Workflow von, ich schreibe das Image bis, ich lasse den Container laufen. Dann versteht man, glaube ich, ganz gut, wie die einzelnen Konzepte so miteinander vernetzt sind.

Konstantin Bauer: Das sollte im besten Fall die letzte Scheu nehmen, wirklich mal selbst einen Docker Befehl auszuführen.

Dennis Groß: Dann wollte ich dich noch eine andere Sache fragen. Ich glaube, viele Leute haben im Zusammenhang von Docker schon mal gehört, dass das wie eine Zwiebel ist. Das wird immer so als Sprachbild verwendet. Ist ja immer interessant, auch mal wirklich zu erklären: Was ist denn damit genau gemeint? So ein Docker Container, was hat denn der für eine Ähnlichkeit mit einer Zwiebel? Was haben die Sachen jetzt miteinander zu tun?

Konstantin Bauer: Ich denke, das ist auch so dieser Vorteil, ich muss nicht bei null anfangen, sondern es gibt sogenannte Images, die basieren dann auf einem Betriebssystem, sagen wir Ubuntu, und auf dieser Basis können dann Pakete vorinstalliert werden wie zum Beispiel ein NPM, besser gesagt Node, also NPM als Paketmanager mit Node Runtime mitgeliefert. Wenn ich jetzt irgendein Projekt mit Node entwickele, dann kann ich mir diesen Schritt schon sparen und suche stattdessen nach einem Image von Node. Also die meisten Umgebungen gibt’s auch als offizielle Images, also danach sollte man dann Ausschau halten. Also sei es jetzt irgendwie Node, .NET, irgendwas mit Java, Python. Das heißt, auf dieser Schicht eines Basis-Betriebssystems wird mir schon mal eine Schicht mit einer weiteren Umgebung angeboten, wo ich dann wieder drauf aufbauen kann. Und so entstehen diese Schichten. Was auch dann letztlich den, also wir hatten die Begriffe Image und Container genannt. Also ein Image sind diese einzelnen Schichten, die sind schreibgeschützt, und ein Container unterscheidet ein Image so, dass er dann eine beschreibbare Schicht oben draufsetzt, mit der der Container arbeiten kann.

Dennis Groß: Letztendlich ist das Image im Prinzip eine spezielle Docker oder Container Syntax, mit der ich sagen kann, wie jetzt eine bestimmte Schicht von dieser Container Zwiebel aussieht. Die Idee ist: ich muss nicht immer anfangen mit einem Ubuntu Betriebssystem, sondern ich kann einfach schon eine weitere Schicht dazu holen. Zum Beispiel kann ich mir ein Docker Image als Basis verwenden, was schon  node.js installiert hat. Und dieses node.js Docker Image basiert vielleicht auf einem Ubuntu Docker Image. Das macht es natürlich relativ einfach. Man kann dann natürlich in dem Level einsteigen, wo man möchte oder wo man jetzt einfach einsteigen muss. Wenn man das jetzt mal mit einer VM vergleicht, da ist eher so der Workflow, ich habe jetzt so eine VM über den Hypervisor zur Verfügung gestellt und jetzt muss ich mit SSH da rein und dann muss ich zum nächsten Mal alles installieren. Wenn ich jetzt node.js will, muss ich das installieren, dann muss ich NPM installieren und so weiter und so fort. Und bei Docker da läuft das Ganze über Images. Das heißt, das ist auch automatisiert, über die Images beschreibe ich dem Docker quasi, wie der Container hochfährt und was da drauf installiert wird. Und das Schöne daran ist, ich habe also diesen Zwiebelgedanken, ich kann Sachen wiederverwenden und kann da einsteigen, wo ich mich wohlfühle letztendlich. Das spart mir dann in der Praxis auch einfach viel Zeit bei der Entwicklung.

Konstantin Bauer: Total! Genau! Ich suche quasi, man fängt eigentlich nie vom Scratch an, sondern man sucht schon mal nach vorgefertigten Images und erst da knüpft man dann an.

Dennis Groß: Und das Schöne ist wirklich, dass viele Open Source Communities, bieten natürlich dann auch solche offiziellen Docker Images an. Da gibt’s dann unheimlich viel Sachen, die man dann einstellen kann. Und die Arbeit spart man sich. Da hat man wirklich etwas aus erster Hand schon. Was man sich da nicht erst mal mühselig selber zusammen konfigurieren muss. Jetzt haben wir schon relativ viel über Docker geredet, jetzt wäre es vielleicht auch mal interessant, so ein bisschen auf das Docker Ökosystem einzugehen. Da gibt es so viele verschiedene Sachen. Wir haben jetzt mal über das das Container Image gesprochen, was so ein bisschen beschreibt, wie der Container letztendlich aussehen soll. Wir haben über den Container gesprochen. Das ist letztendlich dieser Prozess, der nachher läuft. Jetzt ist so die Frage, dazwischen ist auch etwas, und Konstantin, was ist denn da dazwischen?

Konstantin Bauer: Wenn ich mir jetzt mein eigenes Image bauen möchte, dann verwende ich bei Docker ein sogenanntes Docker File, also sprachlich mit einer gewissen Syntax wird da drin beschrieben, wie mein Image aussieht. Also das startet meistens mit einem From Befehl, also wo drauf man das Ganze basieren lässt. Also wie wir es gerade schon gesagt hatten, es kann entweder Ubuntu sein oder auch schon Node. Ich kann dann Befehle hinzufügen, dass bestimmte Dateien aus meinem Projekt rüber kopiert werden. Ich kann zusätzlich noch eigene Pakete installieren. Ich kann Befehle ausführen, wie zum Beispiel NPM Pakete, wenn wir jetzt bei dem Beispiel bleiben, installiert werden. Und in aller Regel dann der letzte Befehl ist, dass meine Anwendung ausgeführt wird.

Dennis Groß: Wenn ich jetzt Nutzer bin und ich möchte von Start to Finish im Prinzip jetzt so einen Container deployen, was muss ich machen? Also der erste Schritt: Ich muss so ein Dockerfile schreiben.

Konstantin Bauer: Genau! Du kannst auch, wenn du jetzt eine eigene Anwendung entwickelst für deine Anwendung, schreibst du ein Dockerfile.

Dennis Groß: Da schreibe ich so in dieser Docker Syntax im Prinzip wie mein Image aussieht. Und dann mache ich so ein Doktor Bild und gebe dem Image dann noch einen Namen, einen sogenannten Stack. Dann habe ich dieses Image und dieses Image kann ich ausführen. Ich kann Docker Run verwenden mit dem Image-Namen und dann weiß Docker, wie aus diesem Image so ein Rechen-Container startet. Das ist jetzt so der Use Case, ich will jetzt den Container bei mir …

Konstantin Bauer: Bisher sind wir da nur lokal unterwegs.

Dennis Groß: Aber was ist jetzt, wenn dein Container nicht auf deinem PC, wo du das Dockerfile geschrieben hast und gebaut hast, starten möchtest, sondern du möchtest das jetzt auf deinem produktiven System starten? Dann müsst das Image irgendwie …

Konstantin Bauer: … verteilt werden.

Dennis Groß: … publizieren.

Konstantin Bauer: Genau! Da kommen die Container Registries ins Spiel. Man würde bei Docker einen Push-Befehl absetzen und dann wird das Image in die Registry geschoben und ist über die Registry dann für alle anderen zugreifbar. Im Beispiel von Docker die bekannteste Registry ist Docker Hub, aber mittlerweile auch GitLab, GitHub bieten da schon Möglichkeiten, sich in seinem Repository direkt seine Images auch mit zu hosten. Jemand anderes, der dieses erstellte Image verwenden möchte, kann jetzt über diese Registry da drauf zugreifen.

Dennis Groß: So im Prinzip, wenn man so sagt, ist die Registry die Datenbank für Container Images, die schon gebaut sind. Und wenn jetzt jemand mal einen Docker Pull, zum Beispiel einen node.js Container "pullt", das ist in der Regel tatsächlich ein Container Image, das von Docker Hub kommt. Wenn man da mal genau nachguckt, dann wird man auch in der Konsolen-Ausgabe sehen, das nennt man dann Pullen, von Docker Hub runterlädt. Und dann startet der das. Gut! Dann haben wir schon relativ viel über Docker erklärt. Sollen wir jetzt so ein bisschen das Thema bewerten? Was ist denn jetzt so dein Eindruck abschließend von Docker und von Container Technologien?

Konstantin Bauer: Vielleicht, es ist auch ein Wissen durchgeklungen, wir sind auf jeden Fall kleine Docker Fanboys, wir verwenden es in unserem Alltag sehr, sehr gerne. Und wenn jetzt da draußen jemand ruft, ich kann aber Docker nicht verwenden, weil … dann wird das bestimmt auch seine Gründe haben. Was könnte für dich ein bestimmter Grund sein, in dem man Docker dann nicht verwendet?

Dennis Groß: Genau wie du gesagt hast, Docker ist jetzt auch kein goldener Hammer. Es gibt die wenigen Use Cases, wo man es nicht verwenden sollte. Was mir da einfällt, sind Legacy Anwendungen, das heißt, relativ alte Software, die relativ viel Abhängigkeiten hat, die zum Beispiel mit mehreren Datenbanken kommuniziert, die die Datenbanken sehr direkt anspricht, also nicht Protokolle wie http zum Beispiel verwendet und bei denen einfach sehr konkrete Gegebenheiten in einer virtuellen Maschine notwendig sind. Da hat man oft einfach Probleme diese Sache zu containerisieren, also da Docker Images für zu schreiben. Und oft ist es praktisch auch nicht so sinnvoll, weil das oft dann Systeme sind, die noch mal neuentwickelt werden. Also diese "grüne Wiese" nennt man das dann. Wo man wahrscheinlich auch eher mit einem Container-Ansatz startet und sich das nicht mehr rentiert das zu portieren. Vielleicht noch so ein letzter Aspekt, der mir jetzt auch gerade einfällt, ist, dass Container Technologien es auch ein Stück weit wirklich einfacher gemacht haben Software laufen zu lassen. Also zum Beispiel, hole ich jetzt mal eine Postgres Datenbank. Früher musste ich das dann installieren, das kommt dann darauf an, was für ein Betriebssystem ich habe, Windows, Mac oder Linux. Da muss ich das konfigurieren und starten. Und ich kann dann auch nur eine Datenbank haben, ich kann jetzt nicht zwei Postgres auf meinem System so einfach installieren. Gibt’s sicherlich auch, aber das ist dann schon kompliziert. Und heutzutage reicht es, ich mache einfach ein Docker Run, lade mir dieses Postgres Image von Docker Hub und das läuft. Das ist nicht nur mit so Sachen wie Postgres Datenbanken, sondern das ist auch mit proprietärer Software. Wenn wir jetzt zum Beispiel einen Backend Service in Scala entwickeln, das nennt man dann "containerisieren", das heißt, wir machen da jetzt ein Docker Image, das beschreibt wie diese Software im Container laufen kann. Dann kann jeder ganz einfach die Software deployen. Das ist letztendlich nur noch ein Thema, ich muss das Docker Bild machen, um das Image zu bauen, und dann Docker Run. Der Rest da drum ist einfach automatisiert. Das heißt, ich muss da gar nicht mehr so im Detail drin sein in der Software.

Konstantin Bauer: Ich muss gar nicht in dieses Tooling einsteigen, also was brauche ich für Scala im Speziellen, was für ein Bild-Tool brauche ich da?

Dennis Groß: Das macht das auch ein bisschen leichter, das zu trennen. So diese Trennung zwischen, das ist der, der es jetzt entwickelt und der, der es deployt, klar, heutzutage verschwimmen da so ein bisschen die Grenzen. Aber in der Praxis gibt’s immer schon so eine leichte Trennung. Es gibt immer schon eher Leute, die mehr für das Operations, also für das Deployment, Maintenance verantwortlich sind, und Leute, die für die Entwicklung verantwortlich sind. Und für diese Trennung ist es einfacher, wenn man einen Container hat. Weil der, der das deployt, weiß ganz einfach wie man es deployt, weil es diese Standard-Tools gibt, von Docker zum Beispiel. Jetzt haben wir natürlich viel über Docker geredet, jetzt sind wir auch schon langsam zum Ende gekommen. Ich will jetzt noch einmal für den Zuhörer ein bisschen durchgehen, über was wir jetzt alles geredet haben. Wir haben so ein bisschen angefangen, haben erklärt, was ist genau ein Container, was ist konkret der Unterschied zwischen einem Container und einer virtuellen Maschine. So ein bisschen den Zusammenhang erklärt, dass der Container im Prinzip auf der virtuellen Maschine läuft. Wir sind dann ein bisschen drauf eingegangen, woher dieser Zwiebelgedanke oder diese Metapher kommt, was eine Zwiebel mit dem Container zu tun hat, dass es da einfach verschiedene Image-Schichten gibt, Container-Image-Schichten, auf die man aufsetzt. Dass da einfach eine große Wiederverwertbarkeit in diesem Container Ökosystem ist. Und das Stichwort Ökosystem kannst du vielleicht ein bisschen erklären, was wir da drüber gesagt haben.

Konstantin Bauer: Wir haben vorhin gehört, dass es auch sowas wie eine Registry gibt, über die Images verteilt werden können. Wir haben knapp den Unterschied gehört zwischen Image und Container. Und vor allem habt ihr so ein bisschen unsere Use Cases gehört, also dass sich Container vor allem anbieten im Bereich CI/CD, beim Testing und auch Container viele Dinge im Bereich Cloud Computing erst möglich gemacht haben.

Dennis Groß: Das war es dann schon wieder heute mit der Episode von unserem Docker Podcast. Wir bedanken uns, dass ihr wieder eingeschaltet habt, und hoffen, dass ihr beim nächsten Thema auch wieder dabei seid.

Konstantin Bauer: Hat mir auch sehr viel Spaß gemacht, Dennis.

Dennis Groß: Bis dahin!

Konstantin Bauer: Tschüss! Ciao!

So! Das war‘s für heute. Wir hoffen, die heutige Folge hat euch gefallen und dass wir euch das Thema Docker und Container Technologien ein bisschen näherbringen konnten. Weiterführende Links zur aktuellen Folge findet ihr in den Shownotes. Und wenn ihr euch für die wunderbare Welt der Softwareentwicklung interessiert, freuen wir uns natürlich, wenn ihr uns abonniert. Für unsere Folge am 3. März haben wir Thomas und einen ganz besonderen Gast für euch im Gepäck. Bis dahin eine gute Zeit! Bleibt gesund!