Docker

Simon Kölsch: Hallo Lucas.

Lucas Dohmen: Simon, erzähl uns doch mal kurz wer du bist und was du so bei innoQ machst.

Simon Kölsch: Ja, ich bin Consultant, wie man das heutzutage nennt, bei innoQ. Ich habe keinen festgelegten Hintergrund auf eine bestimmte Sprache, habe aber einen starken Java-Enterprise-Umfeld [als] Hintergrund an der Stelle. Im letzen Projekt hatten wir Docker im Einsatz und das wollten wir als Gelegenheit nehmen, einen Podcast darüber aufzunehmen.

Lucas Dohmen: Okay, und aus welchen Gründen braucht man Docker, also was sind die Probleme, die man versucht damit zu lösen?

Simon Kölsch: Das ist immer so die Frage, ob man da wirklich Probleme hat, die man lösen will. Docker ist so ein bisschen die eierlegende Wollmilchsau im Moment. Ist relativ stark gepuscht aus dieser DevOPs, Continuous Integration - Continuous Lifecycle Ecke. Da ist die Grundidee, dass ich ja einmal ein Artefakt baue, dass meine komplette Buildpipeline durchläuft, dann auf dem Testsystem deployed wird, später nicht nochmal neu gebaut wird für Produktion, sondern eben genau das gleiche Artefakt in Produktion wandert und ich ihm über die Umgebung die Konfiguration für das Artefakt zur Verfügung stelle. Und wenn ich so ein Artefakt durch die komplette Pipeline schieben will und idealerweise genau den gleichen Code beim Entwickler ausführen will in Produktion, brauche ich eine Möglichkeit, das zu verpacken. Und das bietet Docker mir als Container-Lösung an.

Lucas Dohmen: Aber was unterscheidet das jetzt beispielsweise von, wenn ich als JVM Entwickler, da einfach ein fertiges WAR-File oder sowas meinen OP-Leuten zur Verfügung stelle?

Simon Kölsch: Also, da ist die Frage wie man Docker voneinander abgrenzt. Auf der anderen Seite hätten wir nämlich das, was ich paketiert aus meiner Applikation, von meiner Sprache bekomme, also zum Besipiel ein WAR-File bei Java, um das auf einem Application Server laufen zu lassen und auf der anderen Seite könnte ich ja auch komplette virtuelle Maschinen ausliefern. Das sind so die beiden Enden von dem Spektrum. Der Unterschied liegt darin, dass man eigentlich erstmal verstehen muss, was gehört denn zu so einer Applikation oder zu so einem Artefakt was ich ausliefere. Es ist nicht mehr so, dass nur der Bytecode irgendwie auf einem Application Server geschoben wird, bei dem alle Libraries installiert sind, sondern ganz oft sind das kleine - ist ein Artefakt eigentlich ein kleines System, was ich direkt starten kann. Oft ist dann ein minimalistischer Web Server mit dabei, der das ganze bei 'nem Service entsprechend ausliefert. Eigentlich möchte ich ja als Entwickler des Webs entscheiden, welche Libraries da drin sind, um nicht irgendwie Probleme zu bekommen mit unterschiedlichen Versionen von meiner XML Library, die eben im Application Server schon irgendwo installiert ist und eine andere Version ist, wie ich lokal im Moment bei mir hab. Um das alles zusammen zu packen, da wäre die einfachste Lösung eigentlich, eine virtuelle Maschine zu erstellen, die Applikation dort zu installieren und das eben zu auszuliefern. Jetzt ist das Problem, dass so eine virtuelle Maschine relativ groß ist und so schwergewichtig. Und eigentlich will ich ja einen leichtgewichtigen Container nur für meine Applikation und das bietet mir an der Stelle eigentlich Docker.

Lucas Dohmen: Okay, das heisst also, Docker heisst nicht, dass es Virtualisierung ist, wie jetzt bei VM Ware oder sowas. Es ist was anderes und was genau bedeuet das?

Simon Kölsch: Da ist auch wieder die Frage, wie man denn Virtualisierung abgrenzen möchte. Generell funktionieren virtuelle Maschinen entweder so, dass die komplette Maschine virtuell der Applikation zur Verfügung gestellt wird, das heisst, inklusive Hardware, Grafiknetzwerk. Das wird alles komplett virtualisiert. Die andere Variante, die ein bisschen leichtgewichtiger ist, da läuft dann Hypervisor und der Hypervisor mappt quasi meine reale Hardware in meine virtuelle Maschine. Das heisst, ich habe nich nochmal diesen Overhead mit einer virtuellen Netzwerkkarte. Das wird komplett entsprechend durchgereicht, das macht dann eben der Hypervisor. Trotzdem habe ich da ein komplettes Betriebssystem laufen. Da läuft ein eigener Kernel und die ganzen Systemprozesse.

Lucas Dohmen: Das heisst also, das macht Docker dann anders. Also bei Docker habe ich das nicht so.

Simon Kölsch: Genau. Eine bisschen flapsige, einfache Erklärung, was denn Docker eigentlich ist: das ist ein modernes „chroot“, so wie man das eben kennt. Ich kann natürlich in so einem Docker Container mehrere Prozesse laufen lassen. Die Idealvorstellung ist allerdings, dass pro Container genau ein Prozess läuft. Und was Docker dann macht, es nutzt Virtualsierungs Features, Security Features, zum Beispiel „CGroups“ vom Linux Kernel, um diese Separation der laufenden Prozesse zu erreichen. Das heisst, wenn ich Docker benutzen will, brauche ich, zumindest im Moment, noch irgendwo ein laufendes Linux mit einem Kernel, weil dagegen eben die Implementierung geht. Und dann läuft, getrennt vom restlichen System über die Linux Kernel Features, mein Prozess in dem Container.

Lucas Dohmen: Das bedeutet auch, dass das ein Linux spezifisches Ding ist. Also, ich kann das jetzt nicht auf meinem Windows-Rechner oder auf meinem Mac-Rechner dann laufen lassen, diese Container?

Simon Kölsch: Also, nativ nicht. Allerdings gibt’s dafür eine Lösung von Docker selbst wieder, das nennt sich „Docker Machine“. Früher hieß das „Boot2Docker“. Das hat sich jetzt in letzter Zeit geändert. Was Docker Machine macht, es stellt mir eben eine Maschine zur Verfügung, auf der ich dann meine Docker Applikation laufen lassen kann. Physisch sieht es so aus, dass ein Virtual Box installiert wird, in dem Linux installiert ist, was dann hochfährt und eben diesen Kernel zur Verfügung stellt. Auf dieser Docker Machine laufen alle meine Docker Container. Ich selbst bekomme davon auf der Kommandozeile beim Interagieren mit Docker erstmal nichts mit, weil wenn ich mit Docker Machine meine Maschine eben starte, wird die Umgebung so bereits vorbereitet, dass wenn ich den Docker Client benutze, um mit einem Docker-Host-Prozess zu kommunizieren, um die Container zu managen, dass direkt eine Umgebungsvariable gesetzt ist, wo denn dieser Host zu finden ist. Somit habe ich eben die Möglichkeit, unter 'nem Mac oder auf 'ner Windows-Maschine trotzdem mit Docker zu arbeiten. So native Unterstützung für Docker, das wird wohl noch 'ne Weile dauern.

Lucas Dohmen: Okay, verstehe ich. Wenn ich mir das jetzt so vorstelle, haben wir jetzt diese verschiedenen Prozesse, die da irgendwie virtuell sich diese Sachen teilen und abgegrenzt von einander sind, aber es gibt ja auch noch andere Ressourcen, auf die man zugreifen muss als Programm. Also beispielsweise möchte ich vielleicht Daten irgendwo hinschreiben. Wie funktioniert das in Docker, wie kann ich da mit Daten umgehen?

Simon Kölsch: Genau, die Grundidee bei Docker ist die, dass erstmal die Daten, die im Container anfallen, auch in diesem Container liegen. Wenn dieser Container beendet wird, irgendwie gelöscht wird, dann sind diese Daten auch weg und ich habe erstmal keine Möglichkeit, da direkt zu interagieren. Als nächstes gibt’s seit Docker 1.8 die Möglichkeit, Daten in einen laufenden Container zu kopieren. In Versionen voher konnte ich auch schon beliebig Daten aus dem Container rauskopieren. Alles, was ich irgendwie behalten will, und über einen Container-Neustart retten will, wird über ein Volume zur Verfügung gestellt. Das heisst, beim Erzeugen vom Container, oder eben schon vorher, beim Erstellen des Container Images, markiere ich Teile vom Dateisystem, die ich eben extern zur Verfügung stellen will. Das funktioniert eigentlich wie so ein Linux Mount. Ich habe dann die Möglichkeit, Verzeichnisse aus meinem Host direkt in den Container zu mounten. Zum Beipiel, Konfigurationsdateien für diesen Container oder ein Verzeichnis, in dem ich gerne [auf] Logdateien später zugreifen möchte und die Daten bleiben so quasi über Conatiner-Neustarts und so weiter persistent erstmal zur Verfügung.

Lucas Dohmen: Okay. Wie ist es dann beispielsweise mit Netzwerk? Also, meine Applikation möchte jetzt mit einer anderen Applikation oder auch von außen erreichbar sein, weil irgendwie ein HTTP Server zur Verfügung steht.

Simon Kölsch: Also, bei Docker funktioniert es so, dass es ein virtuelles Netzwerk-Interface, das „Docker 0“ gibt. Das hat eine IP-Adresse und jeder Docker-Container, der hochgefahren wird, bekommt dynamisch eine IP in diesem Host Netzwerk. Wenn ich jetzt hingehen möchte und zum Beispiel meine Applikation ganz viele Ports öffnet, die ich aber eigentlich nicht von außen verfügbar machen will, sondern eben nur den Port 80, dann würde ich beim Erzeugen des Containers, also wenn der gestartet wird, würde ich ein Port Mapping mit angeben. In diesem Port Mapping mappe ich dann eben diese Container Ports auf die Ports von meinem Hostsystem. Das heisst, ich könnte den Port 80 aus dem Container auf den Port 8080 in meinem Docker Host zur Verfügung stellen. Was da eigentlich passiert, sind simple IP-Tables-Einträge, die dann von Docker automatisch angeleget werden. Da gibts 'ne IP Tables Chain, die heißt Docker, und der Docker Host kümmert sich aber eigentlich um das Managen von diesen Regeln. Also faktisch habe ich einen Parameter -p und da gebe ich an: 80:80. Und damit haben wir den Port 80 gemappt auf dem Docker Host. Wenn ich an der Stelle diese Komplexität gar nicht haben will und auch keine Separierung, habe ich auch die Möglichkeit, den Stack direkt vom Host im Container zur Verfügung zu stellen. Das heisst, jeder Port, der im Container geöffnet wird, das ist genau der gleiche Stack wie auf dem Host.

Lucas Dohmen: Aber das hat dann sicher Nachteile, wenn ich irgendwie mehrere Container habe, die ich gleichzeitig auf einem Host laufen lassen möchte.

Simon Kölsch: Genau, ich muss halt irgendwo meine Ports managen. Das nimmt mir Docker auch nicht ab, aber ich kann zum Beispiel so klassische HTTP Alternative Port 8080, ich kann irgendwie jede Applikation auf dem Port 8080 laufen lassen und dann zur Laufzeit beim Starten entscheiden, wie das Binding ist. Wenn ich das eben nicht mache und den IP Stack vom Docker Host benutze, hätte ich an der Stelle halt Port-Kollision und müsste die Konfiguration schon beim Entwickeln festlegen.

Lucas Dohmen: Du hast jetzt eben gesagt, dass man das beim Erzeugen des Docker Containers machen kann. Wie erzeuge ich denn so einen Docker Container? Also gibt’s da irgendwie ein Tool für oder schreibe ich da irgendeine Datei? Oder wie funktioniert das?

Simon Kölsch: Genau, vielleicht zum Anfang einfach mal die Begrifflichkeiten. Also Docker Container ist quasi immer ein laufender Prozess und ich starte natürlich nicht einfach so einen Prozess, sondern ich habe irgendwann vorher mein Image gebaut. Und dann möchte ich aus diesem Docker Image einen Docker Container erzeugen und das Docker Image könnte zum Beispiel eine Redis Instanz sein. Von diesem Redis möchte ich dann 5,6,7,8 Instanzen hochfahren, das heisst, ich habe ein Image und habe 5,6,7,8 Container. Dieses Image kann ich entweder [als] vorgefertigtes benutzten, da gibts im Moment ein relativ großes Ökosystem von Docker selbst, oder ich erzeuge das eben selbst. Es funktioniert dann so, dass ich ein Docker File habe, das ist eine Art Make File für meine Images, habe ein Verzeichnis, in dem das Docker File liegt und alle Daten, die ich irgendwie später in diesem Image benutzen möchte und würde dann mit 'nem Docker Built Command in diesem Verzeichnis die einzelnen Schritte vom Docker File abarbeiten.

Lucas Dohmen: Wie ist das jetzt, wenn ich bei diesen Docker Files merke, irgendwie benutze ich bei allen die selben Grundeinstellungen. Kann ich da irgendwelche Sachen teilen zwischen diesen Docker Files, gibt’s da irgendwelche Import Statements oder sowas ähnliches?

Simon Kölsch: Das funktioniert so, dass Docker eigentlich oder ein Docker Image, wie bei Git, über Deltas aufgebaut ist. Das heisst, ich habe für jeden Layer von diesem Image einen Hash Wert und die nachfolgenden Layer bauen auf dem vorherigen auf. In meinem Docker File stehen verschiedene Befehle, zum Beispiel, „erzeuge ein Verzeichnis“, „kopiere jetzt mein Binary File in diesen Container“, „beim Ausführen von diesem Container führe folgenden Befehl aus“ … und jeder Befehl in diesem Docker File erzeugt einen neuen Layer in diesem Image File System. Die Idee dahinter ist die, dass ich eine einfache Vererbungshierarchie darüber habe. Ich kann [in] dem Docker File das Schlüsselwort „FROM“ benutzen, ganz am Anfang und dann könnte ich eben sagen, „erbe doch bitte von diesem Image, was ich hier vorher gebaut habe und füge noch folgende fünf Befehle hinzu“.

Lucas Dohmen: Du sprachst da eben dann von einem Ökosystem, da gibt’s dann schon fertige Images - wie kann ich mir das vorstellen? Also, wenn ich jetzt irgendwie eine Ruby Applikation laufen lassen kann, kann ich da irgendwie sagen „ich möchte hier ein Ruby haben“ oder so?

Simon Kölsch: Also, meine Images verwalte ich in Docker über eine Registry. Das ist teilweise noch recht rudimentär, wie sich diese Registry managen lässt. Aber wenn ich diese Registry benutzen will, würde ich das mit – wie man das auch von Git her kennt – mit 'nem Git push - Git pull. Das wäre bei Docker ein „docker push“ und ein „docker pull“ benutzen, um darüber meine Images auszutauschen. Was Docker zur Verfügung stellt, ist der DockerHub. Das ist ein öffentliches Docker Images Repository, ähnlich wie man das von GitHub eben kennt, soweit in der Basis-Variante kostenlos. Inzwischen findet man eigentlich fast jedes Projekt bei DockerHub in dieser offiziellen Registry und kann da teilweise offizielle, teilweise inoffizielle Images mit, zum Beispiel 'nem fertigen Node, mit 'nem fertigen Debian als Basis Image oder direkt 'n CAdvisor ziehen. Man muss natürlich ein stückweit darüber nachdenken, bevor man das irgendwie produktiv benutzt, einfach aus Security-Sicht. Ich hab da einfach sehr schnell sehr viele Layer, an denen sehr viele Autoren beteiligt sind. Das sollte mir zumindest bewusst sein, wenn ich so ein Feature nutze. Also, das Problem ist ja auch nicht von Docker allein, das findet man auch im Umfeld von anderen. Also, wenn man Node anguckt, so ein „npm install“ zieht auch ganz schön viele Pakete aus’m Netz. Bei Java, so ein Maven Built zieht auch relativ viele Abhängigkeiten in mein Projekt rein, über die ich keine Kontrolle habe. Aber damit habe ich eigentlich ein recht komfortables Interface, um irgendwie meine Images abzulegen und auf Maschinen zu verteilen.

Lucas Dohmen: Okay, ich kann dann also quasi entscheiden, ob ich von meinen eigenen Images erbe oder von Images, die irgend jemand anders mir bereit gestellt hat?

Simon Kölsch: Genau.

Lucas Dohmen: Aber das ist 'ne einfach Vererbung, ich kann jetzt nicht irgendiwe zwei Quellen angeben?

Simon Kölsch: Richtig, das sind immer nur Deltas zum vorherigen Layer.

Lucas Dohmen: Okay, das kann ich mir gut vorstellen, aber du hast am Anfang gesagt, dass da eigentlich immer nur ein Prozess drin ist. Jezt brauche ich vielleicht für meine Anwendung einen Container, in dem Ruby läuft, weil da meine Rails-Anwendung drin läuft, und einen Container, da läuft dann meine Postgres Datenbank zum Beispiel drin. Wenn ich das laufen lassen will, muss ich dann beide separat starten oder kann mir da Docker auch bei Dependencies zwischen verschiedenen Maschinen helfen?

Simon Kölsch: Da gibt’s natürlich auch 'ne Lösung von Docker zu, die sich in den letzten Monaten entwickelt hat, und zwar nennt die sich „Docker Compose“, und ich kann natürlich einfach 'nen Weg wählen an der Stelle und eben einen Container bauen, und da ist dann alles drin. Aber genau wie du das jetzt in dem Beispiel genannt hast, es fühlt sich erstmal falsch an, seine Applikation mit der Datenbank zusammen in einem Container laufen zu lassen. Das ist am Ende nicht mehr leichtgewichtig, das ist schwierig zu administrieren. Das Schöne bei Docker ist ja, ich kann so einen Container ohne Probleme stoppen, auf 'ne andere Maschine schieben und da wieder hochfahren. Wenn ich dann noch die Datenbank mit drin habe, ist das eigentlich 'ne blöde Idee. Deswegen besteht meine Applikation in der Regel aus mehreren Containern. Und Docker Compose funkioniert so: ich habe ein YAML Config File. In diesem Config File beschreibe ich alle Container Images, von denen ich gerne eine Instanz haben möchte, die Konfigurationsparamter, zum Beispiel die Volumes und das Port Mapping, und dann rufe ich eigentlich nur Docker Compose und mein YAML File auf und dann sorgt Docker Compose dafür, dass diese Images gezogen werden, die Container gestartet werden und dann meine Applikation läuft.

Lucas Dohmen: Das heißt also, dieses Docker Compose ist für die Entwicklungsumgebung gedacht, nicht dann für die Produktion?

Simon Kölsch: Docker Compose lässt sich so eigentlich auch auf der Produktion benutzen. Dann hätte ich zum Beispiel unterschiedliche Docker Compose Files, wenn ich irgendwie Environment ändern will, das könnte man darüber ablegen, zum Beispiel.

Lucas Dohmen: Okay, aber wenn ich jetzt in der Produktion bin, ich meine, wenn man mal so eine klassische Webapplikation hat, dann hat man vielleicht einen Datenbank-Server und irgendwie vier Applikations-Server. Wie mach' ich das denn dann, dass ich da mehr hochfahre, als in meinem Development Environment? Kann ich da irgendwie magisch skalieren, wie man das in der Cloud heutzutage machen kann?

Simon Kölsch: Das hängt natürlich immer von den Gegebenheiten, von der Applikation, ab und so weiter. Es gibt „Docker Swarm“. Das ist ein Scheduler für ein Cluster. Da ist die Idee, dass ich eben nicht nur einen Docker Host habe, sondern eben, wie das eben in der Cloud ist, wenn ich denn möchte, 20, 30 oder 40. Da kann ich natürlich, zum Beispiel, Amazon-Instanzen drunter liegen haben, die dann plötzlich meine Docker Hosts sind. Was Swarm an der Stelle für mich tun kann, ist nämlich den Container nehmen und auf 'ne Maschine, die ich vorher unter Umständen über Metadaten enstprechend defniert habe, in dieser Cloud verteilt und sich dann eben darum kümmert, dass die Container auch laufen. Wenn ein Container durch einen Fehler auf ein Exit läuft und der Prozess terminiert, könnte Swarm dafür sorgen, dass der Container wieder auf einem anderen Host neu gestartet wird - das wären die Features, die ich darüber irgendwie abbilden kann.

Lucas Dohmen: Also der sorgt dafür, dass die Sachen gut verteilt werden auf den Maschinen und kann dann auch dafür sorgen, dass wenn was abstürzt, wird’s neu gestartet?

Simon Kölsch: Genau.

Lucas Dohmen: Gibt’s da auch andere Lösungen für, außer das Docker Swarm, oder ist das so das Einzige was es da auf dem Markt gibt?

Simon Kölsch: Also es gibt ja im Moment relativ viele Lösungen. Gefühlt erscheint da jede Woche eine neue Cluster-Cloud-Lösung. Es gibt „Kubernetes“, es gibt „Mesos“ und es gibt „CoreOS“. Die bringen alle Cluster Scheduler mit, der sich eben um solche Dinge kümmert. Bei CoreOS ist es zum Beispiel „Fleet“, von HashiCorp ist vor wenigen Monaten „Nomad“ erschienen - also, Lösungen gibt’s da eigentlich mehrere. Swarm ist auch noch nicht so alt, ich weiss jetzt nicht ganz genau, wie die Versionierung war, aber das ist im Laufe des Jahres auch erst aus der Beta raus gelaufen - ich glaube im August. Da sind natürlich auch ein Stückweit irgendwie konkurrierende Lösungen mit der Zeit entstanden und das ganze Ökosystem muss sich - würde ich jetzt vom Bauchgefühl her sagen – so über die nächste Zeit mal so ein bisschen normalisieren.

Lucas Dohmen: Wie siehst du das mit der Praxistauglichkeit? Kann man das schon einsetzten oder ist das noch ein bisschen früh und vielleicht erstmal nur in der Testumgebung und noch nicht in Produktion nehmen. Wie siehst du das?

Simon Kölsch: Also Docker selbst ist natürlich praxistauglich. Allerdings funktioniert halt da diese Vorstellung mit, „ich installiere da einmal mein Docker Ökosystem und das nutze ich dann das nächste halbe Jahr, da entstehen nur so ein bisschen Betriebsaufwände“, das ist halt ein Fehlschluss eigentlich. Also, Docker wird selbst noch aktiv entwickelt und in dem letzten Projekt hatten wir zum Beispiel mit Docker 1.6 angefangen und sind jetzt bei Docker 1.9 und haben das kontinuierlich geupdated. Einfach weil so einfache Features, zum Beispiel bei 'nem Docker Built Parameter mitgeben, die ich dann, zum Beispiel die Version von meinem Artefakt verpacken will, ist jetzt erst seit Docker 1.9 verfügbar. Oder, wie gesagt, das Kopieren von Dateien in eine laufenden Container gibt’s erst seit Docker 1.8, und vorher musste man halt einfach den Container wegwerfen und neu starten. Von daher ist das Docker-Ökosystem eher als so ein lebendes Ökosystem zu sehen, und das zieht sich natürlich bis in den Betrieb durch. Natürlich will man als Entwickler auch aktuelle Versionen benutzen, und am liebsten Bleeding Edge, das ist natürlich auch bei Docker so, aber da entwickeln sich einfach rudimentäre Features, die man auf jeden Fall auch benutzen möchte. Ein anderes Beispiel ist die Möglichkeit, der Standard Outstream von Docker selbst. Der wurde bisher immer in einer Datei geschrieben, als Logging. Es gibt jetzt Log Treiber, um sowas direkt nach SysLog zu schieben oder in CrayLog oder in XStack – je nachdem, was ich da aufgebaut habe. Das ist so die Sorte Features, die man eigentlich erwarten würde, die aber jetzt Schritt für Schritt dazu kommt und da muss ich mich drum kümmern.

Lucas Dohmen: Okay, also es ist ein sehr lebendiges Ökosystem, in dem momentan viel passiert, und wo man nicht einfach abwarten kann, sondern man muss schon auf dem Laufenden bleiben um da mitzukommen.

Simon Kölsch: Richtig.

Lucas Dohmen: Und wenn das bei Technlogien so ist, gibt’s da auch schon Best Practises oder Patterns, die sich da bilden? Oder muss man das selber rausfinden, wie man das alles am besten macht?

Simon Kölsch: So die absolute Wahrheit gibt’s, was das angeht, sowieso nicht. So ein bisschen Best Practises ist eben, wie gesagt, keine großen Container zu bauen. So ein Riesenvorteil von Docker ist eben, dass ich so in Sekundenbruchteilen meine Instanz auf eine Maschine bringen kann, und dann den Container starten, und dann ist der da. Wenn ich natürlich jetzt anfange, einen großen Container zu bauen, verliere ich eben diesen eigentlichen Vorteil von Docker. Das nächste ist von der Idee her so ein bisschen … ich habe, zum Beispiel, in meinem Container die Möglichkeit 'ne Art Log-Vorwort zur Verfügung zu stellen. Das heißt, dass man Applikation nur nach Standard Out loggt, wie das ja so 12-Factor-App mäßig, so als Best Practise auch genannt ist. Und wenn ich mir jetzt vorstelle, ich habe einen Host, auf diesem Host laufen 30 Docker Container, dann möchte ich vielleicht nicht 30 mal 'nen Prozess im Container noch zusätzlich laufen haben, der sich nur darum kümmert, die Logdaten weiter zu schieben. Deswegen gibt’s ein Pattern, das nennt sich Sidekick. Sidekick Pattern könnte man eigentlich sagen. Da ist die Idee, dass ich eben solche Dienste in einen eigenen Container packe. Dieser Container hat erweiterte Rechte um, zum Beispiel, die Logs aller anderen Container lesen zu können – Docker hat da auch eine sehr lebendige API, die ich da nutzen kann. Und das hat eben den Vorteil, dass eben nur ein Container läuft und eben nicht 30 Prozesse davon. Das nächste ist, wenn ich Monitoring habe, möchte ich ja eigentlich nicht – zum Beispiel, man würde Prometheus nutzen – möchte ich ja eigentlich nicht irgendwelche Exporte in diesen 20, 30 Containern laufen haben, sondern da würde mir eigentlich einer reichen. Dann würde man eben als Sidekick Container, zum Beispiel CAdvisor um die Metriken zu exportieren, hochfahren und hat eben nur einen Prozess am laufen.

Lucas Dohmen: Okay, also das klingt so, als würde da viel passieren, man hat da viel Auswahl, was man da so machen kann. Ja, dann bietet sich da an, über andere Themen auch noch in einer weiteren Folge zu sprechen, aber ich denke mal an der Stelle haben wir eine gute Übersicht über Docker oder fehlt dir jezt noch was, worüber wir noch sprechen sollten?

Simon Kölsch: Also grundsätzlich ist das Thema Docker eben sehr lebendig und eigentlich müsste man da, wie in anderen Podcasts, drei, vier Stunden drüber reden, aber ich denke für so eine halbe Stunde haben wir soweit alles Wichtige erstmal zusammengefasst.

Lucas Dohmen: Gut, dann vielen Dank und den Hörern bis zum nächsten Mal.