#46 Welches Problem löst Docker?

Docker und Container: Buzzwords der letzten Dekade - Doch was ist Docker wirklich?

In dieser Episode versuchen wir genau diese Frage zu beantworten. Jeder redet davon, und wie in jedem Hype werden Wörter und Begriffe oft in einem falschen Kontext genutzt und das Ecosystem entwickelt sich unglaublich schnell. Deswegen ist es doch ganz gut, wenn man ein wenig hinter die Kulissen schaut: Warum wurde Docker erschaffen und welches ursprüngliche Problem sollte es lösen? Was ist das besondere an Docker, wenn es "diese Linux Container" bereits seit > 20 Jahren gibt? Was ist eigentlich ein Container im Kontext von Software und was hat "Change Root" (chroot) damit zu tun? Und welche Nachteile hat Docker?

Kurz um: 55 Minuten um das “Warum” hinter Docker.

Bonus: Warum Duisburg eine essentielle Rolle im Container-Ecosystem spielt, was Kaffe mit Software deployen zu tun hat und wie man das Endstück vom Brot nennt.

Sprungmarken

(00:00:00) Intro

(00:00:54) Wolfgangs Weltreise und Duisburg's Binnenhafen, der größte der Welt

(00:04:16) Das heutige Thema: Docker - Was ist das? Woher kommt es? Sind Docker und Container dasselbe? Und wie sieht das Container-Ecosystem eigentlich aus

(00:08:11) Wie lange gibt es Docker bereits? Und welches Problem löst Docker eigentlich?

(00:16:47) Was ist der Unterschied zwischen Virtual Machines (VMs) und Jar's zu Docker Containern?

(00:21:41) Wann und Wie entstand die Continuous Integration (CI) / Continuous Delivery (CD) / Continuous Deployment (CD) Bewegung?

(00:24:38) Was ist eigentlich ein Container im Sinne der Software?

(00:29:32) Change root (chroot)

(00:31:20) Was ist denn das Besondere an Docker, wenn es Linux Container bereits vorher gab?

(00:39:20) Welche Nachteile hat Docker oder ist Docker wie geschnitten Brot?

(00:47:37) Das Killer-Argument von Docker: Updaten von Applikationen

(00:51:06) Zukünftige Podcast-Episoden über Docker und das Container-Ecosystem

(00:52:25) Outro: Feedback und Shownote-Links

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:01:15)

Docker und Container, die Buzzwords der letzten Dekade. Und wo es um Buzzwords geht, geht es auch um ein sich schnell entwickelndes Ökosystem. Grund genug, mal zwei Schritte zurückzugehen und sich zu fragen, was ist eigentlich das Warum hinter Docker und wie lautet eigentlich das ursprüngliche Problemstatement von Solomon Hykes und seinem Team? Um diese zwei Fragen geht es in dieser Episode. Natürlich bleiben andere Buzzwords wie Immutability, idempotenz Copy-on-Write, LXC, LibContainer und Chainshoot nicht unerwähnt. Wenn du dir nun denkst, ich nutze Docker jeden Tag, ich weiß doch schon alles, gib uns mal ne Chance. Es wird kein So-nutzt-du-Docker-Audio-Tutorial, sondern eher um den Gedanken dahinter. Vielleicht nimmst du das ein oder andere Quäntchenwissen doch noch mit. Und somit viel Spaß. Wolfgang, soviel ich weiß, bist du ein sehr belesener Mann und hast auch schon die Welt bereist. Zumindest hattest du das mal vor, bis dieses Corona kam. Meines Wissens nach hast du deinen Vollzeitjob gekündigt und ich glaube offiziell nennt man das ein Cervetical. Und dann hast du begonnen, die Welt zu bereisen bzw. war das dein Ziel? Ist das korrekt?

Wolfi Gassler (00:01:15 - 00:01:19)

Das klingt alles sehr hochgestochen, aber ich lasse es mal so durchgehen.

Andy Grunwald (00:01:19 - 00:01:26)

Kannst du mal ganz kurz die Länder aufzählen, in die du es geschafft hast in dieser Zeit?

Wolfi Gassler (00:01:26 - 00:01:38)

Es waren gar nicht so viele, weil ich mir sehr Zeit gelassen habe, aber ich war zum Beispiel sechs Wochen in der Ukraine. War wirklich sehr spannend, super Land und jetzt im Nachhinein bin ich sehr froh, dass ich damals dort war und das Land gesehen habe.

Andy Grunwald (00:01:38 - 00:01:42)

Warst du auch in Deutschland unterwegs? Hast du dich auch mal ein bisschen tiefer mit Deutschland auseinandergesetzt?

Wolfi Gassler (00:01:42 - 00:01:49)

Ich war mal für unsere tolle Local Host Konferenz in Düsseldorf zwischendurch. Das muss reichen für Deutschland.

Andy Grunwald (00:01:49 - 00:01:52)

Und du warst ja auch schon ein paar Mal bei mir in Duisburg, richtig?

Wolfi Gassler (00:01:52 - 00:02:05)

Ja, wobei ich habe noch nie so dieses harte Duisburg im Kern kennengelernt. Du wohnst ja am Land, aber dieses Duisburg, von dem wir immer alle sprechen, das kenne ich nur vom Bahnhof, der mit irgendwelchen Tapes und Seilen geflickt ist seit 15 Jahren.

Andy Grunwald (00:02:05 - 00:02:12)

Wenn ich Duisburg sage, was ist das Erste, was dir in den Sinn kommt? Wofür Duisburg bekannt ist?

Wolfi Gassler (00:02:13 - 00:02:19)

Duisburg ist für irgendwas bekannt. Duisburger Landschaftspark vielleicht. Der Landschaftspark, der ist in Duisburg, oder?

Andy Grunwald (00:02:19 - 00:02:22)

Der Landschaftspark Duisburg Nord ist in Duisburg, richtig.

Wolfi Gassler (00:02:22 - 00:02:26)

Da war ich mal klettern. Da habe ich sogar den Gipfel bestiegen mit 30 Höhenmetern.

Andy Grunwald (00:02:27 - 00:02:30)

Hast du dich oben im Gipfelkreuz in das Buch eingetragen? Da gibt es doch immer so ein Buch, oder?

Wolfi Gassler (00:02:30 - 00:02:33)

Keine Ahnung, ob es da ein Buch gab. Ein Foto habe ich auf jeden Fall.

Andy Grunwald (00:02:33 - 00:02:37)

Wie sieht denn dein geografisches Wissen bezüglich Wasserstraßen und Duisburg aus?

Wolfi Gassler (00:02:37 - 00:02:39)

Wasserstraßen, meinst du jetzt in Rhein oder so?

Andy Grunwald (00:02:39 - 00:02:41)

Ist zum Beispiel eine Wasserstraße.

Wolfi Gassler (00:02:41 - 00:02:42)

Ah, da gibt es noch mehr.

Andy Grunwald (00:02:42 - 00:02:48)

Okay, ich beleuchte dich mal ein bisschen. Und zwar ist die Stadt Duisburg für einen Weltrekord bekannt.

Wolfi Gassler (00:02:48 - 00:02:51)

Es geht nicht um Umweltverschmutzung oder? Und höchste Werte oder so?

Andy Grunwald (00:02:52 - 00:03:13)

Es geht nicht um Umweltverschmutzung, es geht auch nicht um CO2-Werte. Es geht um den Binnenhafen. Und zwar besitzt Duisburg den größten Binnenhafen Europas. Und wenn man alle öffentlichen und privaten Hafenanlagen zusammenzählt, liefern wir, wir Duisburger, sogar den größten Binnenhafen der Welt.

Wolfi Gassler (00:03:13 - 00:03:15)

Ich bin beeindruckt.

Andy Grunwald (00:03:15 - 00:03:58)

Und bezüglich Wasserstraßen haben wir natürlich auch den Rhein, aber wir sind natürlich auch sehr an die Ruhr angedockt. Zugegeben, wenn du jetzt den Straßenverkehr auf dem Rhein mit der Ruhr vergleichst, ist es halt eher ein schlechter Vergleich. Aber warum erwähne ich das heute, dass wir den größten Binnenhafen der Welt liefern? Nicht nur, weil ich jede Nacht davon nicht geweckt werde. Ich hör das schon gar nicht mehr. Also, ich wohne relativ nah auch an Krefeld dran und relativ nah auch am Rhein. Und ich hab das Gefühl, Krefeld, speziell Krefeld-Ürdingen, hat auch einen kleinen Containerhafen. Und ich hab das Gefühl, nachts lassen die immer die Container extra fallen. Deswegen, wenn der Wind gut steht, hör ich das. Aber ich hab das Wort schon genannt, Container, darum geht's heute.

Wolfi Gassler (00:03:58 - 00:04:21)

Genau, und zwar haben wir irgendwie in letzter Zeit erstaunlich viele Anfragen zu Docker und zu Containern bekommen. Keine Ahnung, warum das gerade irgendwie so in aller Munde ist. Wir haben auch öfters darüber gesprochen. Andi hat mir mal erklärt, Docker ist sowieso tot und Docker gibt es auch fast gar nicht mehr und lauter so Schlagzeilen mir in den Kopf geworfen und darum haben wir mal gedacht, ich glaube, wir müssen über Docker sprechen.

Andy Grunwald (00:04:22 - 00:04:53)

Die Anfragen waren wirklich komplett durch die Bank. Von teilweise, was ist Docker? Oder könnt ihr mal eine Folge zu Docker machen? Oder ihr sagt öfters, dass Kubernetes viel zu groß und viel zu komplex ist. Was ist denn die Alternative? Bis über, was ist denn Nomad von HashiCorp? Oder welche Cloud-Provider gibt es? Oder wie kann ich datensensitiv Docker-Container in Deutschland hosten? Und so weiter und so fort. Eine eine frage hat uns in die aktuellste frage die wir bekommen haben ist auf welche art und weise würdet ihr den empfehlen docker container zu orchestrieren.

Wolfi Gassler (00:04:54 - 00:05:31)

Und das ist ja die frage schlechthin die sich aktuell immer stellt was soll man denn wirklich für dieses orchestrieren verwenden gibt es ja doch mittlerweile zahlreiche lösungen. Und darum haben wir uns gedacht, wir nehmen uns mal dem ganzen Docker-Thema an, in Ruhe. Wir sprechen dann auch natürlich die Orchestrierung, was es da so gibt. Aber dieses Thema ist so groß, dass wir das, glaube ich, in mehrere Episoden aufteilen müssen. Und wir starten heute einfach mal mit den, ich würde jetzt nicht sagen Basics, aber vor allem auch mit der Geschichte und probieren das auch ein bisschen aufzuarbeiten, wie das Ganze entstanden ist mit Docker, wo Docker aktuell steht, ob Docker wirklich tot ist und ob Docker und Container dasselbe sind.

Andy Grunwald (00:05:32 - 00:06:34)

Ich muss grad super grinsen, weil du sagtest schon, wir schauen uns das ganze Thema Docker mal an und da hast du ja schon die erste Verwirrung reingebracht, die wir auch in dieser Episode klären werden. Was Wolfgang sagen möchte ist, das komplette Container-Ekosystem ist sehr, sehr stark im Wandel, aber schon seit Jahren und es ist unglaublich schwierig, da mitzukommen. Und ja, vielleicht hat alles irgendwie mit Docker angefangen, obwohl die ganzen System-Investoren, System-Engineers und Co. jetzt sagen, wie, Docker hat doch Container gar nicht erschaffen. Ja, das ist jetzt richtig, weil die ganze Thematik gibt's halt schon alles ein bisschen länger mit Linux, LXC und Jails und was weiß der Geier nicht. Und um da mal so ein bisschen den ganzen Überblick über das ganze Container-System zu bringen, haben wir uns mal vorgenommen oder selbst den Anspruch auferlegt, okay, wir machen jetzt mal ein paar Episoden über Container. Wir werden Themen beleuchten wie Kubernetes, wir werden Themen beleuchten wie, wo ist eigentlich der Unterschied zwischen RunC, LibContainer, LXC, ChangeRoot und so weiter. Aber das Thema, was halt jeder kennt, ist halt mal das Wort Docker.

Wolfi Gassler (00:06:35 - 00:07:01)

Ich habe mir auch immer gedacht, dass ich mich bei Docker auskenne, bis du mir dann die ganzen anderen Schlagwörter so in den Kopf geworfen hast und dann habe ich mir gedacht, okay, vielleicht muss ich auch mal mehr nachlesen über das ganze Thema. Man verwendet zwar das Ganze und kennt sich, ich würde sagen, doch eigentlich ganz gut aus, es ist ein Werkzeug, was man tagtäglich verwendet, aber es gibt dann schon viele Kleinheiten, Feinheiten und es hat sich doch in den Jahren einiges getan. Und darum wollen wir da mal tiefer rein blicken in das Ganze.

Andy Grunwald (00:07:01 - 00:07:16)

Falls ihr Docker schon jeden Tag nutzt, schaltet nicht ab. Wir werden euch jetzt nicht Docker Run erklären. Wir werden euch jetzt nicht erklären, wo ist der Unterschied zwischen Docker Run und Docker Start und dass ein Docker-Container immer nur einen Prozess haben sollte. Sondern wir werden mal ein bisschen versuchen unter die Oberfläche zu gehen.

Wolfi Gassler (00:07:16 - 00:07:28)

Jetzt ist Docker für mich schon so ein Standard-Tool geworden, was ich wirklich tagtäglich verwende. Mir kommt vor eigentlich, dass das schon Jahrhunderte alt ist fast. ist ja eigentlich gar nicht mehr wegzudenken. Aber wie lange gibt es denn Docker eigentlich schon?

Andy Grunwald (00:07:28 - 00:07:42)

Docker, so wie wir es kennen, gibt es offiziell seit 2013. Und zwar hat der Gründer oder einer der Co-Entwickler Solomon Hikes die ganze Sache das erste Mal auf der Python-Konferenz PyCon im Jahre 2013 vorgestellt.

Wolfi Gassler (00:07:44 - 00:07:47)

Das heißt, Docker ist noch gar nicht zehn Jahre alt.

Andy Grunwald (00:07:47 - 00:07:51)

Also, Docker hat jetzt in sehr kurzer Zeit, in ein paar Monaten Geburtstag, genau.

Wolfi Gassler (00:07:52 - 00:07:55)

Ist eigentlich schon unglaublich, wenn man sich vorstellt, wie das die Welt verändert hat.

Andy Grunwald (00:07:56 - 00:09:02)

Also, es ist jetzt natürlich die Frage, was ist der reale Geburtstag, was ist der wirkliche Geburtstag von Docker? Es ist ja nicht so, als hatte der einen guten Morgen, hat einen guten Espresso getrunken, hat einen Wochenendprototyp gehackt und danach war das fertig. Solomon Hikes hat bei einer Firma gearbeitet, die DotCloud hieß. Und DotCloud hat seit circa drei Jahren an dem Problem, was Docker lösen sollte, gearbeitet, bis sie mal die richtige Lösung hatten, da wo die gesagt haben, hey, das hier hat einen roten Faden, das hier macht Sinn. Und diese Lösung haben sie halt in der Python-Konferenz PyCon 2013 vorgestellt. Und daraus ist dann Docker entstanden. Und das wurde dann ein paar Monate später nochmal bei der französischen Konferenz .scale nochmal vorgestellt. Aber nicht vorgestellt so, hey ich geh jetzt auf die Bühne und demo das jetzt. Sondern da hat Solomon Hayek mal einen richtig guten, schönen, recht kurzen 20-Minuten-Vortrag gehalten über das Warum. Denn ich denke, es wird viel zu wenig über das eigentliche Warum von Software gesprochen.

Wolfi Gassler (00:09:02 - 00:09:06)

Drum sprechen wir jetzt über das Warum. Schieß mal los. Warum?

Andy Grunwald (00:09:06 - 00:09:40)

Welches Problem löst Docker jetzt eigentlich? Immer wenn ich an Docker denke, denke ich an Container und blabliblub, ja? Aber der Gedankengang von Solomon Hikes und seinem Team ist unglaublich interessant. Und zwar haben die sich gedacht, das kann doch nicht so schwer sein, Software von A nach B zu schieben. Und dann fing der in dem Talk eigentlich relativ gut an darüber nachzudenken, okay, der war irgendwo in einem Projekt drin und dieses Projekt hatte eine Landingpage mit einem Static Site Generator, das Ding hatte ein Webfrontend, das Ding hatte eine Userdatenbank, sehr wahrscheinlich noch einen API Endpoint, hinten dran eine Queue mit Redis, dann Background Workers und eine Analytics DB.

Wolfi Gassler (00:09:40 - 00:09:43)

Im Moment hat es 2013 schon einen Static Site Generator gegeben.

Andy Grunwald (00:09:44 - 00:09:46)

Ja, das nannte man gegebenenfalls einfach HTML-Seiten.

Wolfi Gassler (00:09:47 - 00:09:48)

Okay, eine Webseite.

Andy Grunwald (00:09:48 - 00:10:34)

Das ist so die Applikation. Und dann hat man natürlich auch noch die Infrastruktur. Man hat den Laptop von dem Contributor, man hat eine Development Virtual Machine, man hat sehr wahrscheinlich einen QA-Server, dann hat man irgendwie ein paar Produktionsserver und dann hat man natürlich auch noch irgendwas im Thema Disaster Recovery. Und da rennt man natürlich in so ganz klassische Probleme, wie die Development VMs laufen auf Debian, aber Production ist irgendwie auf Red Hat, weil man irgendwie offiziell Support braucht und der, der Engineer, den entwickelt auf Python 3 und Production läuft auf Python 2.7 und so weiter und so fort. Auf jeden Fall haben sie sich halt fast drei Jahre damit beschäftigt, wie kann ich denn jetzt reliable Software von A nach B schieben, ohne in Seiteneffekte zu laufen.

Wolfi Gassler (00:10:34 - 00:10:40)

Und da kommt jetzt dein Bremerhaven, Duisburger Hafen ins Spiel.

Andy Grunwald (00:10:40 - 00:10:53)

Und da kommt mein Duisburger Hafen ins Spiel, weil die haben sich halt nachgeguckt, okay, wie machen das denn andere Industrien? Und da war, ist der Vergleich super. Und zwar haben die sich gedacht, okay, was brauche ich denn, um einen Sack Kaffee von Chile nach Duisburg zu kaufen?

Wolfi Gassler (00:10:53 - 00:10:57)

Kaffee und Chile, genau. Kaffee, Chile, nicht Kiel.

Andy Grunwald (00:10:58 - 00:11:04)

Chile, China, Chemie, Kaffee. Kaffee ist ja keine Bohne, ist eine Lebenseinstellung, Lebenskultur oder wie war das, ne?

Wolfi Gassler (00:11:04 - 00:11:06)

Genau, Kaffee ist eine Lebenseinstellung.

Andy Grunwald (00:11:06 - 00:13:14)

Okay, ich rede jetzt einfach von Kaffeebohnen, ja? Was passiert eigentlich, wenn ich einen Sack Kaffeebohnen aus Chile und ein Klavier, also zum Beispiel ein Piano, transportieren möchte? Dann muss ich jemanden haben, der das genau weiß. Okay, ich darf das Piano nicht auf die Kaffeebohnen stellen, weil dann gehen die Kaffeebohnen kaputt. Was passiert denn, wenn ich die Säcke Kaffeebohnen auf das Klavier stelle? Ja, das funktioniert sehr wahrscheinlich auch nicht, weil dann sind Tasten sehr wahrscheinlich durchgerückt oder vielleicht ist der... ist das Gewicht der Kaffeebohnen zu schwer, was das Piano beschädigt. Also... Dann habe ich jemanden, der weiß, wie ich dann das Kaffeebohnen von Pianos auf dem Schiff trenne. Aber dann muss ich noch jemanden in dem Hafen haben, der auch weiß, wie ich ordentlich einen Sack Kaffeebohnen lager und transportiere und dann auch wirklich zum Endkunden bringe, weil gegebenenfalls dürfen die nicht nass sein oder nicht frieren oder sowas. Und dasselbe mit Piano. Piano darf keinen Kratzer haben, sonst bleibt der Wertverlust. Und dann hat er sich halt sich damit mal ein bisschen beschäftigt und zwar gab es 1950 haben sich ganz viele intelligente Leute zusammengesetzt und sind zu einem shipping container agreement gekommen. Also was sie eigentlich gemacht haben ist jeder hatte dieses Problem auf der Welt und die haben sich darauf geeinigt auf also die Infrastruktur provider in diesem Sinne das bedeutet die die Leute die, Häfen haben, die Häfen bauen, die Schiffe bauen und so weiter und so fort. Die haben sich gedacht, irgendwie müssen wir dieses Problem lösen, weil ich kann jetzt hier nicht kontinuierlich Leute einstellen, die wissen, wie man Kaffee transportiert oder Klaviere transportiert. Und dann haben die sich halt hingesetzt und haben halt gesagt, okay, wir einigen uns auf ein Format und das war der Schiffscontainer. Ja, also die haben sich dann auf die Masse geeinigt, aufs Gewicht, wie die Türen aufgehen, wie man die Türen abschließt, wie die Kanten sind und so weiter und so fort. Und das ist das, was wir heute so kennen als klassischer Schiffscontainer. Und was die, was das eigentlich aus Softwareperspektive bedeutet, ist, dass ein Schiffscontainer selbst eigentlich die Natur von Separations of Concern ist. Weil eigentlich sagt man jetzt, egal was im Container ist, es kann transportiert werden. Also man muss gar nicht mehr die Details kennen von, wie man Kaffee transportiert und wie man ein Piano transportiert, sondern man transportiert einfach nur diese Box, diesen Shipping-Container aus Stahl, diesen Schiffscontainer. Der, der bei mir in Krefeld-Urding immer nachts fallen gelassen wird.

Wolfi Gassler (00:13:15 - 00:13:23)

Und man kann theoretisch auch eine Kühlung einbauen, wenn man will. Also dann hat man intern die Kühlung eingebaut, wenn man irgendeine spezielle Temperatur halten will oder so. Also das ist ja alles möglich.

Andy Grunwald (00:13:24 - 00:13:44)

Und weil man jetzt ein standardisiertes Format hat, nämlich diesen Schiffscontainer, ermöglicht das nämlich dann so eine Art Automatisierung. Das bedeutet, die Infrastrukturprovider waren jetzt frei zu wählen, welchen Kran sie bauen wollen. Weil es ist ja völlig egal, weil der Kran muss ja nur dieses Interface, diese Maße von dem Schiffscontainer handhaben können und dieses Gewicht von diesem Schiffscontainer.

Wolfi Gassler (00:13:45 - 00:13:47)

Also die API von dem Container sozusagen.

Andy Grunwald (00:13:47 - 00:13:48)

Kann man so sagen.

Wolfi Gassler (00:13:48 - 00:13:49)

Die Schnittstelle.

Andy Grunwald (00:13:49 - 00:14:13)

Und was nach 1950 dann passiert ist, die Logistikindustrie, die Schiffindustrie ist explodiert. Weil natürlich durch diese Separation of Concerns wurde Automation enabled und jeder hat einen Hafen gebaut, jeder hat einen Kran gebaut und natürlich sind dann die Geschwindigkeiten nach oben gegangen. Man kann also eigentlich sagen, wie man Kaffee um die Welt verschifft ist besser organisiert als wie wir alles Software deployen.

Wolfi Gassler (00:14:14 - 00:14:14)

Oder deployed haben.

Andy Grunwald (00:14:14 - 00:14:38)

Ja, da muss ich dich mal ganz kurz rausholen. Ich denke, du bist immer noch in deiner Cloud- und Container-Bubble. Ich denke, dass es immer noch sehr, sehr viele Firmen draußen gibt, die noch nicht auf Container umgestiegen sind. Was völlig okay ist, weil es gibt auch Use Cases gegen Container. Doch ich will nur sagen, es gibt sehr viele Leute immer noch da draußen, die per FTP deployen oder die vielleicht sogar manuell auf irgendwelchen Server gehen und Files modifizieren, sofern das denn keine kompilierte Sprache ist.

Wolfi Gassler (00:14:38 - 00:14:46)

Ja, aber es gibt auch sicher Transportunternehmen, die nicht Container verschiffen. Wenn du ein Windrad liefern musst, kannst du auch keine Container verwenden.

Andy Grunwald (00:14:47 - 00:14:53)

Das ist richtig. Auf jeden Fall ist das so das ursprüngliche Problem, und dann haben die sich natürlich gedacht, okay, was ist denn ein Container in der Softwarewelt?

Wolfi Gassler (00:14:53 - 00:15:23)

Aber man könnte jetzt ja auch sagen, okay, 2013, das ist noch nicht mal zehn Jahre her, da war die Softwareentwicklung ja doch schon relativ weit. Man hatte da seine schönen Packages, man hatte JAR-File, das man ausliefern konnte, man hatte schon Virtualisierung, ich hab da wahrscheinlich auch schon meinen Server virtualisiert damals. Das war ja schon alles schön abstrahiert. Also ich hab da mein JAR-Package ausliefern können auf meine VM und hab das dort laufen lassen können. Also wofür ich dann noch Docker irgendwie gebrauche.

Andy Grunwald (00:15:23 - 00:16:09)

Ja, das Problem ist das, was du jetzt angesprochen hast, das geht so in zwei Richtungen. Auf der einen Seite hast du gesagt, okay, wir haben irgendwie Isolation von Sprachen mit Java, du hast ein Java, was du drauf packst, und auf der anderen Seite haben wir diese Virtual-Maschinen. Lass das mal ganz kurz trennen. Bei den Sprachen hast du völlig recht, also wir haben ja Möglichkeiten, irgendwie Sprachen in ein Paket zu packen. Wie zum Beispiel JAR in Java, VirtualEnv für Python und RVM bei Ruby zum Beispiel. Das Problem ist hier, man kann da nicht wirklich alles reinpacken. In JAR kann man ja wirklich nur Java- und JVM-Geschichten reinpacken und in VirtualEnv halt wirklich nur irgendwie Python-Dependencies. Aber was ist denn mit allem, was da drunter liegt? Also, das bedeutet die OpenSSL-Library, libcurl, von mir aus auch FFmpeg. Also all das, was irgendwie halt nicht Python ist oder was halt nicht Java ist.

Wolfi Gassler (00:16:09 - 00:16:12)

Ja, die liegen ja eh in meinem VM-Image.

Andy Grunwald (00:16:12 - 00:17:27)

Ja, ja, das ist richtig. Das bedeutet, die ganzen Libraries, die ich grad gesagt hab, ja, die sind auf deiner VM, das stimmt schon. Aber jetzt gehst du ja grad davon aus, dass in dieser komplexen Welt, von der ich grad erzählt hab, dass du den Contributors-Laptop hast, dass du die Development-VM hast, den QA-Servers, Production und so weiter und so fort, dass das alles auf demselben VM-Image läuft. Und wenn du jetzt nur die Software daraus auftauschst, tauschst du ja nicht die unterliegenden Dependencies aus. Einer der Probleme. In der Regel versucht man natürlich, dass das Staging-System gleich dem Produktionssystem ist, gleich dem Entwickler-Laptop. Sind wir mal ehrlich, das funktioniert einfach nicht. Da ist die Realität einfach off. Das bedeutet, die heftigsten Fehler und die, die am meisten zum Debuggen brauchen, sind halt oft diese Fehler. wo du irgendwie eine meiner Version Unterschied hast, wo irgendeine API gechanged ist, wo dann gegebenenfalls kein Semantic Versioning funktioniert hat. Das bedeutet, die Dependencies, von denen du ansprichst, ist ja alles in meinem VM-Image. Das ist schön, wenn das so wäre, aber es ist halt einfach nicht so. Ja, also die Setups sind nicht gleich. Und wenn man jetzt sogar noch On-Premise-Setups hat, also man schreibt eine Software, die dann bei Kunden wirklich On-Premise gehostet wird, wo dann zum Beispiel der Server, also diese virtuelle Maschine, gar nicht unter deiner Kontrolle ist, ist es ja noch schlimmer. Nicht schlimmer, beziehungsweise komplexer.

Wolfi Gassler (00:17:27 - 00:17:37)

Und warum kann ich jetzt nicht einfach die vm verwenden dass ich die die vm durchziehe durch meinen ganzen stack für entwickler für staging für production.

Andy Grunwald (00:17:37 - 00:19:00)

Kannst du und das wurde ja auch jahrelang gemacht und ich meine so technologien wie wie mw und so weiter und so fort sind ja immer noch sehr populär und es ist auch immer noch super. Es gibt verschiedene Herausforderungen bei Virtual Machines und mir fallen jetzt gerade recht schnell zwei Stück ein. Auf der einen Seite, bei einer Virtual Maschine selbst, hast du halt sehr viele Maschinendetails. Das bedeutet, du bundlest halt schon, okay, wieviel Harddrive hat die, dein Netzwerkinterface und so weiter und so fort. Also du shippst ja wirklich eine komplette Virtual Maschine. Und bundles halt so viel, was die Applikation gegebenenfalls gar nicht so im Detail abstrahiert. Also du sagst halt, okay, diese virtuelle Maschine muss 100% 100 Gigabyte haben und diesen Netzwerkthroughput und so weiter und so fort. Das ist die eine Geschichte. Die andere Geschichte ist natürlich die Geschwindigkeit. Eine virtuelle Maschine ist halt eine virtuelle Maschine mit einem Betriebssystem, mit allem drum und dran. Und wenn das natürlich in ein Paket packe, irgendwo hinschippe und starte, Systeme brauchen halt Zeit zum Booten und Systeme brauchen halt Zeit zum Operieren, deswegen ist es halt nicht innerhalb von ein paar Sekunden getan, wie der in die Kiste oben ist oder ähnliches. Also jeder, der zum Beispiel schon mal Virtual-Maschinen von A nach B geschoben hat, weiß, dass das je nach Größe ein andauernder Prozess sein könnte.

Wolfi Gassler (00:19:00 - 00:19:10)

Wie hat eigentlich die ganze CICD Bewegung da mit reingespielt? War die eigentlich vor Docker? Ist die mit Docker entstanden? Ist die erst nach Docker gekommen?

Andy Grunwald (00:19:10 - 00:19:39)

Meines Wissens nach war das alles vor Docker, weil diese ganze Continuous Integration, Continuous Deploy, Continuous Delivery Thematik hat ja meines Erachtens nach den richtigen Hype und erst den richtigen Kickoff, Mit der Präsentation von John Oldsport und Paul Hammond von Flickr auf der Velocity-Konferenz 2009 gekriegt, da wo die gesagt haben, hey, pass mal auf, wir zeigen euch mal, wie unsere Entwicklungsabteilung und unsere Operationsabteilung auf Flickr kooperieren. Flickr kennst du noch, dieses Foto-Teil-Plattform-Ding?

Wolfi Gassler (00:19:39 - 00:19:41)

Natürlich, gibt's auch noch.

Andy Grunwald (00:19:41 - 00:19:42)

Ist glaube ich aber nicht mehr so populär, oder?

Wolfi Gassler (00:19:42 - 00:19:45)

Ja, Instagram hat alles gekillt.

Andy Grunwald (00:19:45 - 00:20:45)

Naja, auf jeden Fall so im Juno 2009 haben sich halt John Oldspore und Paul Hammond da hingestellt auf der Velocity-Konferenz und haben gesagt, hör mal auf, auf Flickr deployen wir 10 Mal pro Tag. Und das war für 2009... Brainfuck, ja? Also das war wow, wie macht ihr das denn? Wo heutzutage in einer guten Organisation, die sehr gut aufgestellt ist, die auch stabiles Testing hat und so weiter, wo man sagen kann, okay, zehn Deploys am Tag sollten der Standard sein, wenn es nicht der Standard ist, sollten das Ziel sein, aber für 2009, also ich meine, das war 13 Jahre her, war das schon massiv und Da wir gerade gesagt haben, Docker wurde das erste Mal public announced auf der PyCon 2013, wird für mich bedeuten, also für mich ist der Start diese Präsentation mit CI, CD. Das bedeutet, auch wenn wir sagen, .cloud hat schon drei Jahre an Docker gearbeitet, dann wären wir bei 2010. Das bedeutet für mich, der richtige Ursprung von CI, CD und Co. war mit dieser Präsentation somit vor Docker.

Wolfi Gassler (00:20:45 - 00:20:52)

Aber das hat dann durchaus vielleicht die Docker-Bewegung angeschoben, weil das natürlich in dem in dem Ecosystem dann auch viel, viel vereinfacht.

Andy Grunwald (00:20:52 - 00:21:21)

Wir reden hier über zwei Dinge. Ich glaube, wir reden hier über auf der einen Seite die Kultur und das Mindset, dass wir zehnmal am Tag deployen, dass wir unsere Changes sofort in Produktion packen oder mit einem sehr geringen Delay. Also, dass wir wollen das und das What and Why. Und Docker hat dazu beigetragen und hat die technische Hürde gesenkt und somit eher das How beantwortet. Also, wie machen wir das?

Wolfi Gassler (00:21:22 - 00:21:30)

Also das habe ich gemeint, dass die CI-CD Bewegung Docker angeschoben hat, weil das natürlich ein cooles Tool war für die, um den Prozess zu vereinfachen.

Andy Grunwald (00:21:30 - 00:21:33)

Ja, auf dem generellen Aspekt hast du halt schon recht.

Wolfi Gassler (00:21:33 - 00:22:01)

Okay, jetzt haben wir also VMs, die sind zu schwergewichtig. Wir haben diese Jars, die Packages für Software, für eine Sprache. Da hat zu wenig Platz, weil man da zu wenig Abhängigkeit noch mit reinpacken kann. Docker ist dazwischen, beziehungsweise Container sind dazwischen. Aber was sind jetzt diese Container überhaupt oder Docker? Was ist denn so ein Container-System? Oder wie ist denn dieser Container überhaupt spezifiziert mit seinen Türen und Maßen und so weiter? Was ist das technisch eigentlich?

Andy Grunwald (00:22:01 - 00:22:34)

Einen Container kann man als gesunden Mittelweg zwischen diesen beiden zwei Welten, Packaging in einer spezifischen Sprache und einer virtuellen Maschine sehen. Und zwar, wenn wir jetzt einfach nur mal uns auf Linux fokussieren, erfindet Docker jetzt nicht das Rad neu. Das bedeutet, dieses Wort Linux-Container, die gibt es schon seit Ewigkeiten. Und was es unten drunter ist, ist eigentlich eine Prozessisolation. Man isoliert eigentlich Prozesse voneinander. Diese Prozesse teilen zwar dann noch den Linux-Körner, also das unten drunter, das Basis-System.

Wolfi Gassler (00:22:34 - 00:22:36)

Das heißt, ihr könnt kein Windows in Docker laufen lassen.

Andy Grunwald (00:22:36 - 00:23:01)

Ich kann jetzt keinen Windows-Docker-Container auf einem Linux-Host-System laufen lassen, weil ich ja gesagt habe, die sharen den Kernel und es ist eine Prozessisolation. Das bedeutet, ich kann jetzt kein anderes, kein grundlegendes andere Betriebssystem-Architektur laufen lassen. Was ich aber tun kann, es gibt inzwischen Windows-Docker-Container und die kann ich auf einem Windows-Host-System laufen lassen, weil Docker mehr und mehr in die Richtung geht, auch Windows zu supporten.

Wolfi Gassler (00:23:01 - 00:23:21)

Und da hat man schon ein Problem gesehen mit dem ganzen, wie die neue Mac-Architektur rausgekommen ist, auf ARM, dass die halben Images nicht funktioniert haben und dass das extremes Problem war, die Images auf Mac zum Laufen zu bekommen, weil halt das eben eine andere Architektur ist und daher das Host-System nicht matcht mit dem Container-System.

Andy Grunwald (00:23:21 - 00:25:48)

Ja gut, aber mit ARM würde ich fast so weit gehen, dass das jetzt kein Docker-Problem war, weil auch Photoshop auch Probleme hat. Und da geht's einfach nur um andere CPU-Instructions und Co. Da geht's dann wirklich... Also das ist kein Problem, was Docker hat, meines Erachtens nach. Das ist ein Problem der Software-Industrie, dass wir einfach die CPU-Architektur ändern und somit andere Instructions haben. Also was Docker dann jetzt wirklich macht, ist Prozessisolation. Und das ermöglicht dir natürlich unter anderem auch, andere Python-Versionen zu installieren, weil du kannst ja den Python-Prozess von anderen Python-Prozessen isolieren. Was aber unten drunter geteilt wird, ist halt schon die gemeinsamen Ressourcen. Zumindest im Anfang von Docker gab es nur die Prozessisolation, weil am Anfang Docker ganz stark auf LXC gesetzt hat. LXC ist die Abkürzung für Linux Containers und ist eine Art und Weise, wie man Linux Containers auf einem Linux Host startet. Inzwischen nutzt Docker kein LXC mehr, inzwischen nutzt Docker Lib Container, was eine eigene Entwicklung ist, um die Dependency zu LXC loszuwerden und um mehr Möglichkeiten vom Linux Kernel zu nutzen. Auf LXC gehen wir später mal ein in einer weiteren Folge. Der Punkt ist jedoch, neben der Prozessisolation geht es natürlich im Containerwesen auch um Ressource-Isolation. Das bedeutet wie viel RAM, wie viel CPU, wie viel Harddisk darf so ein Container benutzen und das kam erst später beziehungsweise das war noch nicht im initialen Release von Docker vorhanden. Man kann also sagen, Linux und Container und Linux Namespacing isoliert eigentlich unter anderem auch, es schafft ja einfach ein neues Filesystem. Und das ist unter anderem der Grund, warum man zum Beispiel nicht in jedem Docker-Container eine Bash-Shell starten kann, weil die Bash-Shell auch in dem isolierten Filesystem mit dabei sein muss. Und was halt nicht immer der Fall ist, wie zum Beispiel bei einem Docker-Stretch-Container oder ähnliches. Und das ist der Grund, warum ziemlich viele Leute aus Convenience-Reason ein Alpine, Debian oder Fedora-Base-Image nehmen, weil man dann schon ziemlich viel mitgeliefert hat, was man dann vom klassischen Betriebssystem kennt, was man aber nicht muss. Das bedeutet, es wird das Filesystem isoliert, es wird die Prozesse isoliert, der Kernel wird geteilt und das hat zur Folge, alles was man haben möchte, muss man in den Container packen, weil sonst hat man noch nicht mal das bare Minimum wie eine Shell.

Wolfi Gassler (00:25:48 - 00:26:26)

Wer Interesse hat, ist besser zu verstehen. Wir können da einen Artikel verlinken, der ist wirklich gut, der erklärt eigentlich, wie man mit ChangeRoot so ein Mini-Container-System bauen kann, mit wirklich drei Kommandos. Ist natürlich jetzt nicht gleichwertig mit einem Full-Fledged-Container-System, aber wie einfach das ist eigentlich mit ChangeRoot, in Linux so einen Container zu machen und zu bauen und wie der wirklich funktioniert. Weil dadurch bei Linux ja alles über das File-System bzw. über die Pfade geregelt ist, kann man über Change Root, wo einfach das Root-Verzeichnis geendet wird, eigentlich alles kontrollieren, weil man dann eben keinen Zugriff mehr hat auf andere Prozesse zum Beispiel.

Andy Grunwald (00:26:26 - 00:26:28)

Wolfgang, hilf mir doch mal eben ganz kurz, was ist ChangeRoot?

Wolfi Gassler (00:26:28 - 00:27:23)

ChangeRoot macht nichts anderes, als dass dein Slash, den du sonst kennst, als dein Root-Verzeichnis auf Linux umzusetzen auf irgendein anderes Verzeichnis. Und damit kannst du nicht mehr auf //proc//etc//home zugreifen, weil dein Slash ist eben irgendein Unterverzeichnis. Und dort musst du dann, wie du jetzt erklärt hast, Dein eigenes Umfeld mit reinpacken, deine eigene Bash. Alles was du so brauchst, musst du dort reinpacken und das lebt dann dort in diesem neuen Root. Also aufgerufen wird es dann oder executed wird es dann natürlich im Kernel, aber das ganze Filesystem musst du einfach mitliefern. Die Dateien, die du brauchst, die executables, die du brauchst, wie Bash zum Beispiel. Und das zeigt eigentlich, wie einfach das funktioniert. Also kann ich wirklich jedem ans Herz legen, den Artikel mal durchzulesen oder vielleicht mit den Kommandos rumspielen. zeigt eigentlich, dass das alles keine Blackmagic ist, die dahinter steckt, sondern wirklich Linux-Grundlagen.

Andy Grunwald (00:27:24 - 00:29:51)

Und wenn man uns jetzt so zuhört, kann man sich denken, okay, ja, Moment mal. Also, wir haben jetzt zwei Problemfelder. Einmal die Programmiersprachenpackaging, einmal die VMs. Okay, haben wir. Jetzt haben wir Container, das ist so ein Mittelding dazwischen. Und jetzt erzählt ihr die ganze Zeit, hey, das gibt's doch schon. Mit Changeroot und so weiter. Also Linux kann das schon. Was ist denn jetzt das Ding an Docker? Jetzt kann man böse sein und sagen, Docker ist Changeroot mit dem Marketingbudget. Oder man kann wirklich mal gucken, was Docker ist. Weil Docker, das, ich sag mal in Anführungszeichen, Revolutionäre an Docker ist Folgendes. Und zwar genau drei Dinge. Die erste Baustelle. Docker definiert ein einheitliches Format zur Definition von Containern. Wie man Container baut. Und wie Container paketisiert werden und allem drum und dran. Die haben halt ein einheitliches Format geschaffen. Also sozusagen wir haben 50 Standards. Wir machen den 51. Standard. Dieser Standard hat sich aber durchgesetzt. Und ich bin mir nicht sicher, ob wenn die nur den Standard gemacht hätten, ob die erfolgreich gewesen sind, weil ich denke, die nächsten beiden Punkte sind genauso wichtig. Und zwar haben sie Entwicklern ein Tool an die Hand gegeben, um Container sehr einfach zu bauen. Sie müssen sich nicht mit Chainshoot auseinandersetzen, sie müssen sich nicht mit Machine Types auseinandersetzen, sie müssen sich nicht mit LXC auseinandersetzen und SystemDN spawnen und was es nicht noch alles da unten drunter gibt oder Jails. Sie haben einfach ein Docker-Build-Command gekriegt, womit Sie das einheitliche Format, zum Beispiel die Definition durch ein Docker-File, simpel bauen können. Und das dritte im Bunde, Sie haben der Operations-Abteilung, den Systemadministratoren, den Cloud-Providern, den Systems-Engineers einfache Tools an die Hand gegeben, um einen Container zu starten und ihn laufen zu lassen. Und meines Erachtens nach kann man den Erfolg von Docker auf diese drei Dinge zurückzuführen, dass sie einfach das ganze Paket mitgebracht haben. Der Grund für den Erfolg ist also eigentlich, dass Docker die Problematiken des Linux-Container-Systems sehr vereinfacht hat und für das komplette Container-Ökosystem eine Managementlösung geschaffen hat. Ich bin immer sehr böse und sage immer, Docker ist einfach nur richtig, richtig einfach zu benutzende UI, User Interface für Container. Und meines Erachtens nach ist das der Erfolg von Docker, dass sie einfach diese komplexe Thematik von Linux Containern zugänglicher gemacht haben. Ich sage nicht, dass es immer noch einfach ist, das sage ich nicht, weil unten drunter wird es immer schwierig, wenn man sich mit den Details auseinandersetzt. Doch der Zugang, die Einstiegsbarriere wird deutlich heruntergehoben.

Wolfi Gassler (00:29:51 - 00:32:22)

Man muss sich ja nur überlegen, wie einfach das jetzt ist als Developer oder wenn man irgendein Tool ausprobieren will. Docker ist fast standardmäßig schon installiert, sonst installiert man sich das halt einmal schnell über das Betriebssystem und dann sagst du docker run von irgendeinem Image Von irgendeiner Software, die du ausprobieren willst, kann was komplexes sein. Irgendwie, Metabase haben wir zum Beispiel besprochen. Da gibt es ein Command, das führst du auf deiner Command-Line aus. Du musst nichts runterladen, das passiert alles automatisch. Ein Docker-Run-Befehl und du hast eine Metabase laufen, lokal. Und ich glaube, das ist eben genau wie du sagst, das ist die Stärke von Docker, dass das so einfach gemacht wurde. Wo ich das erste Mal Docker verwendet habe, hatte null Ahnung, was das eigentlich macht. Du führst einen Befehl aus und wie ein Wunder hast du plötzlich irgendwas am Laufen lokal bei dir. Und das ohne Probleme, ohne irgendwie viele Einstellungen zu machen. Wenn man das früher mit der VM probiert hatte, klar, die Anbieter hatten auch so VM-Images. Aber da hast du das richtige VM-Image gebraucht, da hast du die richtige Umgebung gebraucht, es hat alles passen müssen, es war langsam. Es hat alles gebraucht, bis das Online war. Und dann hat es meistens aus irgendeinem Grund doch nicht funktioniert. Und mit Docker, die Erfahrung, die User Experience, die Dev Experience war einfach super, super gut. Und das ist dann eher die Endanwender Sicht. Aber es gibt natürlich auch die Developer Sicht. Wenn man jetzt irgendetwas entwickelt, vor allem im Team gemeinsam, das war plötzlich so einfach, wenn man mit Docker gearbeitet hat, wenn man sich geeinigt hat auf die Container, weil vermutlich können das alle Devs, wie das früher war, man hat zuerst 100.000 Dependencies installieren müssen, irgendwas hat nie funktioniert lokal, dann hat man wieder was anderes ausgecheckt, dann hat es wieder einen Versionskonflikt gegeben. Also es war alles nicht sauber getrennt, Auch wenn man jetzt irgendwelche Chars oder solche Dinge hat, irgendwo hat es immer irgendwelche Probleme gegeben. Und das fällt mit Docker eigentlich komplett weg, weil einfach immer die gesamte Umgebung mitgeliefert wird, so wie wir entwickeln für dieses Projekt. Und damit habe ich immer up-to-date die Environment zur Verfügung, die dann auch produktiv eingesetzt wird, im Idealfall. Und das hat natürlich das Developerleben stark vereinfacht. Am Anfang hat man meistens so gesagt, Docker ist eher nichts für produktiven Einsatz. Da hat man das langsam so im Development-Prozess eingesetzt. Aber auch da hat es schon so viele Sachen vereinfacht. Und ich glaube, das war eigentlich so das Erfolgsrezept, die Einfachheit und die vielen Schmerzen, die dann auf der Dev-Seite eben nicht mehr da waren. Das war, glaube ich, der große Erfolg von Doc.

Andy Grunwald (00:32:23 - 00:32:59)

Prinzipiell würde ich dir zustimmen, aber da sage ich auch wieder, der Teufel liegt im Detail. Also ich habe schon sehr, sehr viele Docker-Container gesehen, wo einfach während des Docker-Build-Commands, also wenn der Container gebaut wird, ein Update und ein Upgrade gemacht wird. Und das heißt natürlich, man hat bei jedem Build gegebenenfalls eine neue Version von irgendeiner unterliegenden Software. Wenn man halt nicht wirkliches Version Pinning betreibt, dann holt man sich gegebenenfalls neue Dependencies, geupdated Dependencies, die dann auch wieder Bugs und Regressions haben könnten, holt man sich dann rein und somit wird dieser Vorteil, den du gerade genannt hast, relativiert, aber man kann ihn immer noch erreichen.

Wolfi Gassler (00:32:59 - 00:33:36)

Das ist vielleicht ein wichtiger Punkt, weil das ist ja einer der großen Vorteile von Containern, dass du diese Wiederholbarkeit hast. Wenn du auf Maschine A irgendwas machst, dann kommt da dasselbe Resultat raus wie auf Maschine C. Das stimmt natürlich nur bedingt, genau wie du sagst, wenn du natürlich die Docker Images bildest. dann hast du dasselbe Problem, dass du dann auch externe Abhängigkeiten und wenn du da auf irgendeine Lip verweist, die es nicht mehr gibt, dann hast du natürlich auch ein Problem. Aber solange du mit Images arbeitest, also mit den fertig gebauten Images, kannst du das natürlich verhindern. Also diese Idempotenz, also dass immer dasselbe rauskommt, wenn man was ausführt, das hat man natürlich nur bedingt.

Andy Grunwald (00:33:36 - 00:34:37)

Natürlich kann man auch sowas bauen, wie ich habe ein fertiges Docker-Image und mache dann beim Docker-Run, also wenn ich den Container, die Containerinstanz hochfahre, also eine neue Instanz aus dem fertigen Image, wenn ich da natürlich auch irgendwas mit Upgrade, Update, Upgrade, Upgrade mache, dann kann sogar jede Containerinstanz natürlich unterschiedlich sein. Also falls ihr sowas mal seht, hebt mal bitte die Hand und sagt, gegebenenfalls sollten wir uns hier über die Idempotenz dieser Container und Containerinstanzen mal unterhalten, weil dadurch könnt ihr euch natürlich eine ganze Menge Probleme ins Haus holen. Auf der anderen Seite macht das natürlich auch das Upgrade ein bisschen aufwendiger, weil man dann explizite Package-Upgrades haben muss. Meines Erachtens nach überwiegen da die Benefits den Nachteilen. Thema Nachteile. Ich bin immer so ein Fan davon, okay, lass mal bitte eine Lösung kritisch betrachten, weil es klingt nämlich so ein bisschen wie, ist Docker jetzt das neue geschnitten Brot? Also ist Docker jetzt die Allerweltslösung und heilen wir damit Krebs? Nein, tun wir nicht. Docker hat auch Nachteile. Und Docker ist gegebenenfalls nicht für alles.

Wolfi Gassler (00:34:37 - 00:34:42)

Naja, Freunde von mir arbeiten in der Krebsforschung, die verwenden Docker, also... Ich hoffe.

Andy Grunwald (00:34:42 - 00:35:42)

Für deine Freunde, dass sie bald Erfolg haben, damit Docker dann auch Krebs heilen kann. Schauen wir uns mal ein bisschen so die Nachteile an. Und zwar, jetzt reden wir hier gerade, Docker-Container sind super, Prozessisolation, blabliblub. Wir sagen aber auch, Container teilen gewisse Ressourcen. Und das ist nämlich genau der Punkt. Docker-Container sind nicht virtuelle Maschinen. Das bedeutet, die Elemente innerhalb eines Containers sind nicht strikt isoliert. wie in Virtual-Maschinen. Das bedeutet auch, wird auf eine erhöhte Security Wert gelegt, kann man deutlich bessere Isolation mit ganz klassischen Virtual-Maschinen an den Tag legen, als mit Docker-Containern. Weil die Popularität von Docker und von Containern, beziehungsweise von Linux-Containern, hat natürlich auch sehr viele Security-Researcher und Hacker auf den Plan gerufen, die natürlich in irgendeiner Art und Weise jetzt versuchen, okay, aus Containern auszubrechen, um Zugang aufs Host-System zu kriegen. All diese Versuche gibt's natürlich auch bei klassischen Virtual-Maschinen, um auf den Hypervisor zu bekommen, gar keine Frage. Doch von Haus aus hat man natürlich bei Virtual-Maschinen ein erhöhtes Isolationslevel.

Wolfi Gassler (00:35:42 - 00:36:29)

Vor allem, weil man da halt dann wirklich auch die Hardware simulieren kann, unter Umständen in VMs, und dann kann die natürlich eigentlich alles machen. Dann kann die genau den Speicherplatz begrenzen, dann kann die Art, die Geschwindigkeit sogar begrenzen, wie auf die ... Hardware zugegriffen wird auf ein virtuelles Filesystem zum Beispiel. Das kann ich natürlich bei Docker alles nicht machen, weil das nativ zugreift. Das kann ein großer Vorteil sein, was natürlich viel viel schneller ist, aber wenn ich da natürlich irgendwas begrenzen will, limitieren will, einstellen will, filtern will, dann habe ich dann natürlich keine Möglichkeiten bei Docker oder nur sehr sehr begrenzt. Memory geht ja mittlerweile, aber es sind doch sehr rudimentäre Einstellungen, die da getroffen werden können. Im Vergleich zu einem KEMU, keine Ahnung, ich weiß bis heute nicht, wie man es genau ausspricht, diese Virtualisierung, die sogar einen ARM-Prozessor virtualisieren kann, zum Beispiel, oder simulieren kann.

Andy Grunwald (00:36:29 - 00:36:41)

Man kann schon sagen, dass Docker-Container halt kein Bare-Metal-Speed leisten, weil man hat natürlich ein paar Layer dazwischen. Virtuelle Maschinen sind halt schon näher dran an der richtigen Hardware.

Wolfi Gassler (00:36:41 - 00:36:45)

Da erinnere ich mich immer gern zurück an die Diskussion, man kann Datenbanken nicht in Docker betreiben.

Andy Grunwald (00:36:45 - 00:37:09)

Ja, aber davon rede ich nicht. Also Datenbanken ist meines Erachtens nach eine andere Liga. Nicht wegen dem klassischen Per Metal Speed, sondern einfach nur wegen dem Write-Throughput. Es geht hier einfach nur darum, je nachdem, dass der Zugang zur Hardware, dass da ein paar Layer dazwischen sind und das automatischen Performance-Impact hat. Ich sage nicht, dass dieser automatische Performance-Impact relevant für jede Anwendung ist.

Wolfi Gassler (00:37:09 - 00:37:30)

Nein, nein, aber lass mich fertig reden. Das war eben lange die Diskussion und ich kann mich erinnern, wie dann Percona endlich so einen Test rausgebracht hat zum MySQL zumindest. Wie performt MySQL auf Docker? Und im Prinzip haben die gemeint, klar siehst du einen minimalen Unterschied bei manchen Dingen, aber im Prinzip ist es komplett zu vernachlässigen. Also bei MySQL. Es ist ja zum MySQL gegangen.

Andy Grunwald (00:37:31 - 00:39:50)

Aber Datenbanken und Container ist ja ein super Thema. Und zwar sagt jeder, du darfst keine Datenbanken und Container betreiben und so weiter, weil das hat ja einen Performance Impact und ist langsam. Ja, das stimmt halb. Was man sich bewusst werden muss, ist, dass Container von Haus aus erstmal stateless und immutable sind. Das bedeutet, wenn ich einen Container starte und da werden Daten innerhalb des Containers geschrieben und ich stoppe den Container, Dann werden die Daten nicht auf dem Host-System persistiert. Wenn ich dann die Container insgesamt sogar lösche, dann sind die Daten erstmal weg. Datenschreiben innerhalb eines Containers hat auch eine gewisse Art von Performance-Impact. Und ich sag gewisse Art, weil Container von Haus aus erstmal mit der Copy-on-Write-Methode arbeiten. Was bedeutet das? Container sind optimiert auf Lesezugriffe. Mehrere Prozesse greifen auf eine Datei zu. Jeder dieser Prozesse bekommt eine eigene inode für diese Datei. Die Zeigerinformationen in dieser inode greifen aber alle auf dieselbe Stelle auf der Harddisk zu. Das bedeutet, super viele Prozesse können auf dieselbe Datei zu greifen, ohne irgendwie richtige Kopien zu erstellen, ohne irgendeinen Performance-Impact. Kommt jetzt ein Prozess um die Ecke und schreibt diese Datei, just in diesem Moment wird eine Kopie von dieser Datei, eine reale Kopie von dieser Datei erstellt. Das hat auch zur Folge, dass wenn du eine write-heavy-Applikation hast, wie zum Beispiel eine Datenbank, dann wird natürlich bei jedem Schreibvorgang erstmal eine neue Datei erstellt. Das kann dazu führen, dass schreiblastige Applikationen, wie zum Beispiel Datenbanken, die ihren Schreibfahrt innerhalb des Containers haben, einen gewissen Performance Impact erleiden. Im Detail ist das aber jetzt auch nur so halbwahr, weil da muss man jetzt unterscheiden, welchen Storage Driver hat man denn konfiguriert für Docker und der Standard Storage Driver ist mit Copy-on-Write oder nutze ich ein Docker-Volume. Und ein Docker-Volume bedeutet, ganz generell gesprochen, man mountet ein Folder vom Host-System in den Container und somit hat man dieses Copy-on-Write partiell umgangen. Das hat natürlich dann andere Eigenschaften, wie zum Beispiel, dass innerhalb eines Containers direkt einen Weg aufs Host-System geht. Das bedeutet Security und Co. Stellen wir jetzt einfach mal zur Seite. Aber das ist immer der Punkt, wo die Leute sagen, uuh, uuh, uuh, Docker-Kartiner sind langsam. Ja, weil sie in der Regel auf dieses Copy-on-Write hinaus wollen, weil sie in der Regel auf den konfigurierten Storage-Driver hinaus wollen, weil sie sehr wahrscheinlich dann auch auf den Unterschied zwischen Storage-Driver und Docker-Volumes hinaus wollen.

Wolfi Gassler (00:39:50 - 00:39:59)

Und wenn man Volume eingebunden hat, bekommt man eigentlich nativen Speed. Da gibt es eigentlich keine Nachteile, weil da dann kein Virtualisierungslayer mehr dazwischen ist.

Andy Grunwald (00:40:00 - 00:41:21)

Da hat man dann andere Herausforderungen, zum Beispiel wenn man jetzt an PHP-Dateien oder Node.js oder JavaScript-Dateien denkt, wo man halt mit unglaublich vielen Dateien über ein Docker-Volume arbeitet, da hat man eine andere Herausforderung. Aber das liegt dann primär an der schieren Menge an Dateien, wenn ich so an Open-File-Limits denke und Co. Ein dritter Nachteil ist, und da muss ich zugeben, da weiß ich gar nicht, wie relevant dieser Nachteil wirklich in der Industrie ist, Docker selbst wurde für Server-Applikationen designt und nicht für grafische User-Interfaces. Das bedeutet irgendwie, wenn du Applikationen hast, die wirklich eine UI haben, und davon rede ich jetzt nicht von einer Web-UI, ich rede wirklich von einer Desktop-Applikation oder ähnliches, dann ist das immer so eine Thematik. Und natürlich, da gibt's irgendwie Workarounds mit X11 Video, mit der Weiterleitung von einem Videostream mit X11 und solche Geschichten. Aber die fühlen sich alle eher so wie ein dreckiger Workaround, wie ein dreckiger Hack an. Also, auch heutzutage, Docker ist halt noch nicht wirklich geil für grafische Applikationen. Man kriegt's ans Fliegen, aber die Frage ist, nutzt man da nicht das falsche Tool für ein Problem? Weil es wurde halt einfach designt. für Serveranwendung. Allem in allem denke ich, die Nachteile sind überschaubar und ich plädiere wirklich dafür, sich das auch mal anzusehen. Ich bin schon ein Fan von Containern.

Wolfi Gassler (00:41:21 - 00:41:36)

Ich würde fast sagen, das sind teilweise keine Nachteile, sondern sind halt einfach Eigenheiten von der Technologie, mit denen man sich auseinandersetzen muss, um die man auch rumarbeiten kann. Und so wie halt jedes Tool muss man das halt gut kennen und wissen, für welchen Einsatzzweck es gedacht ist.

Andy Grunwald (00:41:37 - 00:41:40)

Was würdest du denn sagen ist dein geschnitten Brot Vorteil?

Wolfi Gassler (00:41:40 - 00:41:42)

Wo sagst du... Men, men, was?

Andy Grunwald (00:41:42 - 00:41:54)

Geschnitten Brot. Kennst du nicht? Das verkauft sich wie geschnitten Brot. Also geschnitten Brot war ja eine Erfindung, die ist ja durch die Decke gegangen. Und meines Erachtens nach frage ich dich jetzt, was ist denn dein Hauptvorteil? Weswegen sagst du, wow, das ist der Killer?

Wolfi Gassler (00:41:54 - 00:42:11)

Also geschnitten Brot Vorteile gibt es bei mir nicht, weil geschnittenes Brot hat nur Nachteile. Ich bin ja auch jemand der gerne selber Brot backt und geschnittenes Brot trocknet nur viel schneller aus. Aber warum schneidet man Brot? Man macht weniger Sauerei oder?

Andy Grunwald (00:42:11 - 00:42:15)

Kurze Frage, wo wir bei Brot sind. Wie nennt ihr das Endstück von einem Brot?

Wolfi Gassler (00:42:15 - 00:42:16)

Scherzl.

Andy Grunwald (00:42:16 - 00:42:18)

Scherzl? Das ist doch kein Witz.

Wolfi Gassler (00:42:18 - 00:42:21)

Ja, ich glaub Scherzl, wenn man jetzt nicht alles täuscht.

Andy Grunwald (00:42:21 - 00:42:23)

Ihr?

Wolfi Gassler (00:42:23 - 00:42:24)

Ist das schon wieder so eine Stulle oder sowas?

Andy Grunwald (00:42:25 - 00:42:29)

Knäppchen kenn ich, Knistchen kenn ich auch, Ende ab und zu ganz einfach.

Wolfi Gassler (00:42:29 - 00:42:32)

Okay, wir werden den Sprachatlas zu Scherzl verlinken.

Andy Grunwald (00:42:33 - 00:42:49)

Ich hab hier gerade mal geguckt und zwar heißt hier ein Artikel die 100 häufigsten Wörter für das Brotende. Geiles Ding, werden wir natürlich in den Shownotes verlinken. Aber was ist denn jetzt hier dein Verkaufsargument? Du bist jetzt hier Vertriebler, so warum muss ich jetzt Docker einsetzen und was sagst du? Hör mal, das ist das Killer-Argument.

Wolfi Gassler (00:42:50 - 00:44:03)

Ja, es gibt schon viele Argumente, die wir hier auch besprochen haben. Mein persönlicher Favorit ist einfach, auch wenn ich jetzt sehe, wie das mit VMs ist, dass der Updateaufwand viel geringer ist von Docker. Weil eine VM muss ich immer updaten, muss ich das ganze Betriebssystem up-to-date halten, das muss ich in verschiedenen Environments machen. Und mit Docker habe ich ein sehr abgespecktes System, das heißt, ich muss nur, unter Anführungszeichen, nur diese Umgebung up-to-date halten von meinem System. Und wenn ich da auf andere Docker-Container vertraue, wenn ich da jetzt für PHP und PHP-Docker-Container verwende, dann ist der eigentlich up-to-date gehalten und jedes Mal, wenn ich das Docker-Image neu baue oder halt Ich muss die Versionen natürlich anpassen, kann das schnell lokal testen. Das heißt, das ist auch super im Vergleich zu VMs, weil da muss ich mich irgendwo einloggen, muss updaten, muss hoffen, dass da irgendwie nichts kaputt geht oder muss eine eigene Staging-Environment haben, die genau gleich ist. Das ist mit Docker viel einfacher. Das mache ich lokal, updaten, schauen, ob alles funktioniert, Tests laufen durch, kann ich deployen, fertig. Also dieser Cycle ist auf jeden Fall viel viel einfacher und da spare ich glaube ich persönlich schon sehr viel Zeit. Das ist mein persönlicher Favourite. Hast du ein Favourite?

Andy Grunwald (00:44:03 - 00:45:16)

Spezifisch einen anderen Favourite hätte ich jetzt nicht, aber da würde ich schon mitgehen. Also es ist schon sehr einfach. Natürlich ist da auch der Teufel immer im Detail und ich möchte da nicht negativ drüber kommen, aber wenn die Applikation intern das Dateiformat ändert, welches du nach außen mit einem Docker-Volume aufs Host-System gemontet hast, dann kann es natürlich auch zu sehr vielen Problemen geben. Aber stimmt schon, du kannst halt schon da die Reifen von einem Formel-1-Wagen während des Rennens tauschen, meines Erachtens nach, wenn du ebenfalls noch eine Komponente davor hast mit Blue-Green-Deployments und solche Geschichten. Das geht halt schon. Und Zero-Downtime-Deployments, ich glaube schon, da hast du schon einen sehr, sehr guten Grund. Das ist es von uns soweit. Also das ganze Thema Docker und Container ist natürlich riesig. Und wir werden uns bemühen, in zukünftigen Episoden da ein bisschen tiefer einzusteigen. Wir haben das ganze Thema Docker jetzt noch gar nicht komplett beleuchtet. Also Themen, die wir in Zukunft auch anreißen werden, ist, wie überladen ist das Wort Docker eigentlich und was schließt das eigentlich ein? Reden wir hier von der Firma? Reden wir hier von einer Containerinstanz? Reden wir hier von einer Image? Oder wie sieht es eigentlich aus mit Docker Images? Was ist eigentlich die OCI, die Open Container Initiative? Kann ich Docker Images eigentlich auch mit anderen Applikationen wie zum Beispiel Podman laufen lassen? Ja, nein. Und wieso geht das überhaupt?

Wolfi Gassler (00:45:16 - 00:45:18)

Oder warum Kubernetes nicht Docker verwendet?

Andy Grunwald (00:45:19 - 00:45:39)

Genau, was war da los mit dem Shitstorm, ne? Woraus besteht Docker eigentlich? Also die Docker-Komponenten. Was ist denn die Docker-CLI? Was ist Container-D? Was ist Run-C? Und so weiter. All das werden wir versuchen so ein bisschen in den nächsten Episoden zu beleuchten und vielleicht ein bisschen Zugänge euch dazu machen. Heute ging es nur um Docker. Was war das originale Problem von Docker?

Wolfi Gassler (00:45:39 - 00:45:42)

Also nicht von Docker, sondern was Docker lösen wollte.

Andy Grunwald (00:45:43 - 00:45:48)

Und warum Duisburg eine essentielle Rolle im Container-Ökosystem spielt.

Wolfi Gassler (00:45:48 - 00:46:15)

Genau, und wenn ihr Feedback habt oder Vorschläge, was wir auch allgemein machen könnten oder im Docker-Umfeld oder wenn wir weniger über Duisburg sprechen sollen oder über mehr über Bremen zum Beispiel, weil die den besseren Hafen haben, dann bitte alles an stetisch.engineeringkiosk.de oder unter Twitter ENG Kiosk, solange es Twitter noch gibt. Und dann hören wir uns hoffentlich in alter Frische und hoffentlich endlich bei mir auch mit besserer Stimme in einer Woche.

Andy Grunwald (00:46:15 - 00:46:24)

Und schaut wirklich mal in die Show nachts, da sind ein, zwei interessante Artikel, die das ganze Thema auf sehr einfache Art und Weise echt zugänglich machen. Also ich war auch sehr überrascht. Bis dahin, happy learning, bis bald. Ciao.