 Der Vortrag geht heute über Docker, den Container Service. Er ist ziemlich basic, also er geht noch ein paar Sachen weiter als basic, aber ansonsten, wenn ihr schon mal Docker selber rumgeworfen habt und wenn ihr schon mal Docker gebaut habt und mit Docker schon mal was deployed habt und so weiter, kann der Vortrag teilweise langweilig für euch sein, erst zum Schluss hin mit der Interessant. Also vielleicht drückt euch noch eine Mate und kommt dann später nach oder so, ja. Also erst mal zu mir, wenn es geht, erst mal zu mir, ich habe ein paar Interessenfelder, die mich besondere Netzwerke zu tun haben, mit Hardware, Cocktails trinken, also wenn ihr mir nachher ein Bier ausgeben wollt, bitte nicht, eher ein Schunk. Hacking natürlich, weswegen wäre ich sonst hier, und Musik und Lichttechnik, also auf Bühnen rumrobben, irgendwelche Lichttechniken ansteuern mit Arten und Programmieren und so weiter. Ich komme aus Karlsruhe, Kontaktdaten findet ihr hier, die Folien kriegt ihr später auch online, wenn euch die interessieren, wenn ihr die Kreise rund sehen wollt und so. Wie kommt es dazu, dass ich Docker einen Vortrag halte? Ich mache beruflich seit 2014 ziemlich so fulltimemäßig Docker. Das liegt daran, dass ich in der Firma hier in Karlsruhe arbeite, die einen SDN macht, ein Software Distributed Networking Produkt und wir benutzen Docker in der Cloud. Und dort deployen wir halt alle unsere Container als Services dort mit Docker. Dann zum Inhalt der Präsentation. Also erstens möchte ich mit euch über das Software-Deployment im Allgemeinen reden, mal eine Einführung bereihen, wie Software-Deployment normalerweise heute aussieht und wie sich es gerade verändert. Dann über VMs versus Container reden. Dann die Basics von Docker erklären. Dann über das Container-Format in Docker reden, dass es ein Layered-Underts hat, dass es kein Binary-Block ist. Dann über die Tools von Docker reden, das ist vielleicht eher so ein Advanced-Ding, was nicht hier oben zu tun hat, wenn er mit Docker mal rum experimentiert hat. Dann über die Sicherheit von Docker reden, was muss man da beachten, wenn man Docker-Deployt irgendwo, welche Angriffe gibt es da, welche Angriffektoren speziellen. Und dann über die Zukunft von Docker reden, weil Docker ist nicht alles. Und am Ende gibt es natürlich eine Fragenrunde und ich hoffe, ich habe das irgendwie so getimt, dass wir am Ende noch 15 Minuten haben, wo wir Fragen stellen könnten. Ich beantworte dir auch gerne und ich bin auch später noch da. Also lass uns erst mal über das Software-Deployment reden. In der Vergangenheit, wie es wahrscheinlich meistens passiert. Das Problem. Wir haben eine Applikation, die hat mein Entwickler geschrieben. Und diese Applikation wurde dann an das Operations-Department weitergegeben oder meistens den Admin. Und der Admin muss jetzt diese Applikation irgendwo installieren, weil dieser Server da gegebenenfalls dieser Entwickler keinen Zugriff drauf hoffentlich. Oder vielleicht darf der Entwickler es auch selber installieren. Und der Admin gibt ihn den Zugriff. Aber auf jeden Fall ist das meistens so, dass dann der Situation eintritt, dass man feststellt, dass das auf dem Server nicht mehr so funktioniert, wie das auf der Entwicklermaschine funktioniert hat. Ich glaube, ein Problem, was am meisten die mal irgendwie Code geschrieben haben, bekannt ist, wenn sie mal irgendwo andershin gebracht haben. Also, man muss einfach mal sagen, dass dieser Prozess eine Applikation, die man geschrieben hat, dann auch in den Live-Betrieb zu schalten, meistens noch mal ziemlich viel Zeit kostet. Also er könnte sagen, dass eigentlich noch mal wahrscheinlich 30 bis 40 Prozent der Zeit drauf gehen, um diese Applikation irgendwie nachher dorthin zu kriegen und dann auch noch zu maintainen, dass sie dort funktioniert und so weiter. Also das eigentliche Programmcode schreiben ist gar nicht so der große Aufwand in der Gesamtzeit, die die Lebensdauer diese Applikation hat. Und es scheint sich immer gleich zu Verhalten am Anfang gegebenenfalls. Also wenn man findet vielleicht solche Probleme wie, da ist irgendeine Dependency nicht richtig, dann korrigiert man die mal schnell, dann findet man raus, oh, da bricht was anderes, dann korrigier ich das auch mal schnell. Also diese iterative Ansatz mit Try and Error immer wieder ausprobieren. Und die Iteration geht zu weit bis zum Kunden, dass er da iterativ durchprobiert, oh, das geht mal nicht, ich klick mal woanders hin oder ich drück mal Reload in Browser oder so. Und das heißt also kurz um, es gibt viele Fehlerfälle, die entstehen können dadurch, dass die Applikationen ursprünglich von dem Entwickler-System rübergenommen worden ist auf ein anderes System. In den klassischen Deployment-Szenario, wenn man so eine Applikation irgendwo hinbringt, bringt man sie meistens monolithisch irgendwo hin. Das heißt, man hat eine Applikation, die man geschrieben hat, die ein Programmierer geschrieben hat. Und so diese Applikationen gehören natürlich auch Libraries Abhängigkeiten. Und diese Abhängigkeiten installiert man dann entweder diese Applikation mit, indem sie irgendein Bootstrap hat, irgendein Setup, File oder sowas. Oder sie werden einfach als gegeben angenommen und dann muss der admin sich natürlich nachinstallieren. Ich hoffe, dass dann dementsprechend der Programmierer vorher definiert hat, was die Abhängigkeiten sind und nicht der admin es feststellt beim Deployment, während er die Applikation installiert. Meistens ist leider die Realität, dass das dann erst festgestellt wird, was genau gebraucht wird. Und wir haben natürlich unten drunter ein Betriebssystem und ein Server, der benutzt wird. Und da ist normalerweise die Verwaltung vom admin passiert, also nicht vom Entwickler. Der Entwickler kümmert sich dann nicht wirklich darum, die Betriebssystem Updates und so weiter, installiert der admin und auch den Server-Wartung, die Hardware fasst der admin an, da hat der Entwickler eigentlich relativ wenig mit zu tun. Ja, aber jetzt gehen wir mal in das Szenario, wo diese eine Applikation gegebenenfalls nicht die einzige ist, die auf diesem Server läuft, sondern es gibt noch eine zweite Applikation, die auf dem Server laufen möchte. Und jetzt habe ich Glück, dass es die gleiche Applikation gegebenenfalls, dann gibt es vielleicht gar nicht so große Probleme, die noch mal darauf laufen lassen auf dem Server, außer sie werden dieselben Ports benutzt. Aber ich habe vielleicht auch eine Applikation, die ähnlich ist. Dann kann ich vielleicht noch ein paar Sachen nachinstallieren, die ich benötige, in den Libraries, die die Applikation benötigt und kann die Applikation tatsächlich starten, als derjenige, der sie dort installiert. Aber das sieht natürlich auch, kann natürlich auch durchaus anders aussehen. Ich habe die zwei Applikationen und die bringen alle ihre eigenen Abhängigkeiten mit. Das funktioniert auch noch relativ gut, sagen diese Abhängigkeiten sich eben nicht überschneiden, sagen diese Abhängigkeiten für sich alleine stehen und die einzelnen Abhängigkeiten, die alles sozusagen gemeinsam nutzen, sind das Betriebssystem und natürlich der Server, die Hardware, auf dem es Ganze läuft. Also wahrscheinlich ist die auch noch alles relativ super. Jetzt gibt es aber Situationen, da ist es nicht mehr super. Nämlich, der Entwickler sagt zu einem, meine Applikation, die braucht unbedingt PHP 4.0. Und der andere Entwickler sagt, meine Applikation, die braucht unbedingt PHP 4.3. Ja, dann steht man im Punkt und denkt sich, hm, jetzt versuche ich mal, beides parallel zu installieren. Ja, das ist meistens sehr viel Spaß, erfordert sehr viele Nachtstunden, das irgendwie hinzukriegen. Auch wenn es ein Betriebssystem ist, wo das Ganze drauf passieren soll oder sowas. Also meistens endet man dabei, dass man einfach noch verzweifelt ist und dass man unendlich viele Stunden probiert hat, das Ganze zum Fliegen zu kriegen. Und immer wieder festgestellt hat, oh, es bricht auf der einen Seite das, dann bricht auf der anderen Seite das, dann bricht auf dieser Seite das und so weiter und drum und dran. Nicht schön. Ja, dann kommen wir jetzt zur Abhängigkeitshöhle, die halt dadurch entsteht, die da meistens in Applikationen forciert wird, dass sie auf bestimmte Versionen zwanghaft laufen müssen. Besonders mit älterer Software, das ist meist ein Problem mit eurer Software, gucken die meisten, dass sie irgendwie ihre Abhängigkeiten sauber hinkriegen oder gemeint von den neuen Sachen abhängen und damit keine Komplikationen entstehen. Aber gerade wenn man eine alte Applikation hat und eine neue Applikation drauf installieren will, hat man diese lustigen Unterschiede. Okay. Was macht der Atmen, wenn er keine Zeit hat, aber irgendwie Geld? Er kauft einen neuen Server. So, er hat einen neuen Server, er installiert ein neues Betriebssystem drauf, er installiert die zweite Applikation auf dem anderen Server, das hat seine eigenen Abhängigkeiten, seine eigene Libraries, das ist alles super. Da kann man jetzt schön die Applikationen voneinander getrennt halten und man hat keinen Konflikt an der Stelle. Natürlich ist das in erster Linie teuer. Das ist einfach mal die Verdopplung der Ressourcen, der Hartle-Ressourcen, die man in der Stelle hat und nicht sehr effektiv. Also ist es einfach verschwenderisch, was man da macht. Aber es passiert sich immer allzu oft, dass die Applikationen auf unterschiedlichen Servern landen. Ja, das Ganze ist natürlich auch schwer zu managen, weil jetzt habe ich zwei Servern, das heißt, ich muss mir die Sicherheits-Updates von zwei Servern kümmern, ich muss mich nicht nur mit Sicherheits-Updates von einem einen Servern kümmern und ich muss auch zur Administration auf beiden Servern gleichzeitig irgendwie unterwegs sein, ich muss die Logs dort lesen und so weiter. Also der Aufwand ist nicht wenig. Okay. Wie man natürlich auch feststellen kann, in so einem Szenario, was wahrscheinlich auch der Fall ist, ist, man hat nicht eine Applikation, die 100 Prozent vor diesem Server beansprucht. Also die Applikationen, meistens sind sie nicht so wirklich rechenintensiv. Ja, so Speicher hungrig und Festplatten hungrig. Und egal, wie rum es ist, auch wenn es eine Applikation ist, die durchaus CPU-intensiv ist, hat man meistens dann die anderen Ressourcen, die da einfach rumliegen und nur Geld kosten und in Zweifeln in alle drei Jahre ausgetauscht werden müssen. Also auch keine zufriedenstellende Lösung an der Stelle. Was gibt es da jetzt anderes? Naja, es gibt sowas wie virtuelle Maschinen, VMs. Und es gibt sowas wie Container seit neun oder seit längerem vielleicht sogar schon. Wir haben es noch nicht Container, es kannte nur noch fast keiner als Container. Okay. Wir gucken uns das mal den Fall an, von, wir nutzen die Virtualisierung. Also wir dachten wie vor, wir haben diese zwei getrennten Applikationen, die in den Mitteln dann kollidieren würden, im Normalfall. Und dann ziehen wir einfach da so eine Virtualisierungsebene rein. Also jetzt besorgen wir uns irgendwie Software, die das für uns tut, die auf dem Server eine Virtualisierung schafft. Es kann entweder für teuer Geld sein, also Dollar-Commerz irgendeine Firma, oder es kann natürlich auch günstig sein oder Open Source sein, den wir KVM einsetzen. Aber auf jeden Fall, was wir damit tun, ist, wir erhöhen die Komplexität in dem System. Zwischen Layer, der auch nochmal seine speziellen Anforderungen hat, der auch nochmal seine speziellen Bedürfnisse hat, auch was die Wartung angeht und so weiter. Also wir sind zwei jetzt schön getrennt voneinander, und wir nutzen vielleicht auch die Hardware jetzt effektiv an der Stelle. Aber wir haben uns in erster Linie auch mal Overhead besorgt, an der Stelle. Und die Virtualisierung wird immer besser, es wird immer optimierter an der Stelle, d.h. der Overhead wird vergleichsweise immer geringer, aber die Komplexität natürlich nimmt natürlich auch zu. Also es wird nicht so, dass es dann für die Abendsrate deutlich einfacher wird an der Stelle. Er hat zwar keine Nachtstunden mehr, indem er Abhängigkeiten versucht aufzulösen, aber er hat dann Nachtstunden, in denen er versucht, Rates von VM-Versor1 zu fixen, was vielleicht auch nicht so cool ist. Ja. Kommen wir zum Container. Der Container an sich ist auch nach wie vor so eine politische Geschichte. Wenn man so mal diesen Stack anguckt, den ich hier aufgemalt habe, man hat eine Applikation, man hat Abhängigkeiten, nach wie vor dasselbe. Man hat allerdings die Digitalisierung Ebenen jetzt wieder rausgenommen. Und man hat jetzt Containerseparierung auf Betriebssystemebene. Also ein Container führt ein, dass ich jetzt nicht mehr unter dem Betriebssystem virtualisiere, sondern ich tue es an der Zeit, dass wir diese Versorgung schaffen auf den Betriebssystem. Also man spricht eigentlich nicht von Virtualisierung an der Stelle mehr, sondern man spricht eher an Separierung von unterschiedlichen Sachen. Und die Separierung findet hier im Körner statt auf Linux-Betriebssysteme. Interessant an dem Beispiel ist, auch ein Windows, ein Microsoft versucht das gerade irgendwie hinzukriegen. Die wollen das auch haben. Und da findet es natürlich nicht unter Linux statt, sondern eher wie anders. Das kann ja auch nicht sein, dass irgendwie lösen und das Problem und so. Viele lustige Zeiten, die auf einen zu kommen. Wer die Linux kennt, kennt vielleicht schon so etwas ähnliches wie so Container, das heißt Chainshrude. Und man könnte eigentlich sagen, dass Docker ein Chainshrude auf Drogen ist. Also es ist ein Chainshrude aufgebohrt, mit dem, was man eigentlich immer mal haben wollte. Und es nutzt verschiedene Features aus der Linux-Körne, die da sind, die ein Chainshrude nicht nutzt. Dazu zählen wir erst einmal die Network-Namespaces, die ermöglichen, dass man Netzwerksachen voneinander trennen kann, dass auch wirklich Container ihre eigenen Netzwerkschnittstellen haben und nichts in andere Systeme reinschauen können auf Netzwerkebene. Es gibt Sea Groups, die es im Gelenius-Körner ermöglichen ganz klar Prozessstrukturen voneinander zu trennen. Also auch da keine Überschneidungen zu schaffen. Und jetzt gibt es das eigentliche Thema, auf das ich mit euch ja den Dorfvortrag halten wollte, ist Docker. Dass so ein High-Level-Tool oben drauf darstellt, mit dem man das Ganze einfach managen kann. Also ihr müsst euch nicht in Detail auskennen mit LXC, was die Linux-Container sind, was Docker unter der Haube alles benutzt. Und eben ihr müsst euch nicht wissen, was Network-Namespaces sind und Sea Groups und so weiter. Das macht Docker vor euch. Also, Docker. Docker ist, prinzlicherweise beachtet erst mal die Applikation als solche. Eine Applikation könnt man so als einfacher Kasten jetzt so darstellen. Das ist meistens aber ziemlich komplexer als ein einfacher Kasten. Meistens ist so eine Applikation aus mehreren Gliedern zusammengebaut. Und erst zusammen, diese Glieder allein sind zusammen, ergeben die eigentliche Struktur der Applikation und die eigentliche Applikation. Also im konkreten, hat man jetzt zum Beispiel ein Webshop, der besteht aus Code. Und man hat ein Webserver, ein Datenbank-Server, der sich irgendwie darum kümmert, dass die Bestellungen nicht verloren gehen, die jemand mal getätigt hat. Und man hat ein Mail-Server, der versorgt die Leuten mit Bestell-E-Mails. Das ist jetzt alles die Applikation. Also aus entwickelter Sicht ist es sozusagen die Applikation. Für dich als Administrator oder für dich diejenigen, der es deployt, ist es halt mehr als das. Es ist diese ganzen Abhängigkeiten, die da geschaffen werden müssen, auch an Prozessen und an Subsystemen. Damit können wir sagen, jedes diese einzelnen Glieder ist eigentlich auch eine Applikation an sich. Sie löst ein Teilproblem. Der Webshop-Code löst die eigentliche Logik an der Stelle. Der Webserver kümmert sich eben und es ausliefern. Der Datenbank-Server hält die Datenpersistent. Und der Mail-Server kümmert sich darum, dass die Kommunikation nach außen, wie er E-Mail auch stattfindet. Also geht Docker von dem Ansatz her, eigentlich könnten wir das jetzt alles viel als einzelne Applikation betrachten. Und das teilen Sie auch auf. Wenn man bei den Docker-Paradigmen folgt, sagt man normalerweise, dass man einen Prozess pro Container hat. Und in dem Fall ist wirklich der Webserver ein Prozess, der Webshop-Code ist ein Prozess, der Datenbank-Server ist ein Prozess und der Mail-Server ist ein Prozess. Alles läuft auf denselben Server, läuft auf denselben Betriebssystem und man hat die schöne Separierung erreicht. Aber es ist immer noch eine Applikation. Nun, wenn man jetzt so ein komplexeres Setup anguckt, wo es auf den Server mehrere Sachen sich tummeln, als nur diese eine Applikation, sondern drei Applikation, dann stellt man sich schnell die Frage, hm, jetzt habe ich mehrere Container da liegen, aber irgendwie müssen die Container ja auch miteinander reden. Und irgendwie müssen ja irgendwie der Webserver auch Wissenwasser ausliefert und der Mail-Server muss irgendwie Wissenwasser verschickt und so weiter. Und genau bei dieser Sache, wie man im Container miteinander kommunizieren, hilft einem Docker. Also das, was wir bis jetzt gesehen haben, diese reine Container-Separierung der Prozesse, das könnt ihr auch mit dem Basistools in der Linux machen. Also eine ADX-C und so weiter kann das auch. Wenn ihr jetzt ein bisschen weitergehen wollt und eben die Kommunikation herstellen wollt zwischen den einzelnen Systemen, dann hilft euch Docker hier an der Stelle und baut Brücken zwischendrin. Und die Brücken können ganz unterschiedlich aussehen. Auf der einen Seite gibt es Brücken, die Docker zur Verfügung stellt, die Netzwerkverkehr ermöglichen zwischen zwei Containern. Also ihr könnt euch dann, wenn beide Containern irgendein IP-Dienst anbieten, können die mitten da reden. Oder ihr könnt Volumes, sozusagen sogenannte Volumes mounten. Das heißt, ihr könnt von einem Container in den anderen Containern Daten auslagern und die Daten euch dann auch holen von dort. Dadurch gibt man einfach Pfade an wo man Daten gerne hätte. Es fühlt sich so ein bisschen an, wie als würde man einen USB Stick mounten und so. Aber Docker hat eigene Kommando dazu. Und dann gibt es natürlich auch Systeme, es ist hier nicht eingezeichnet, aber wo man gegebenenfalls auf Daten zugreifen will, die auf dem Betriebssystem Level liegen. Auch dazu stellt Docker Tools zur Verfügung und dadurch kann man dann effektiv auch auf das Heißystem Sachen zugreifen, die nicht in Containern liegen. In diesem Fall möchte man wahrscheinlich die Applikation meistens, wenn es eine Online-Applikation ist, auch noch von außen erreichbar machen und dafür stellt auch Docker Tools zur Verfügung, dass ihr vom Betriebssystem Level aus Ports freigeben könnt, die dann in Container reingemapped werden. Also auch das gibt es. Also jetzt kommen wir mal zu den Basics, die Docker ausmacht. In erster Linie ist Docker eine offene Plattform. Also das Begriff Docker wird offene Niveum benutzt zu den eigentlichen Tools, die zu Docker gehören, aber an sich beschreibt an sich Docker die Plattform. Das ist nämlich eine Unmengen an Tools, es werden jeden Tag mehr gefühlt an der Stelle. Die Plattform richtet sich in erster Linie an Entwickler und an die Admins, die es deployen müssen. Die haben die beiden, die sind die Hauptzielgruppe von Docker. Docker sagt dazu, deploy everything nearly everywhere, reliably everywhere. Also sie versprechen einem, also sie geben ein Halsversprechen ab, dass man mit Docker so ziemlich alle Probleme löst, die es in den Weg gibt. Fraglich, ob das so ist. Aber was sie auf jeden Fall gut können, ist this deploy everything. Docker kann relativ gut mit Web-Applikationen, mit Backend-Applikationen, zu diesen Web-Applikationen auch, mit Datenbanken, mit Message Queues, and you name it. Also so alle Applikationen, die irgendwie auf Kommunikation mit Außendiensten-Sachen beruhen, damit spielt Docker ganz gut. This deploy everywhere, man muss es ein bisschen einschrecken. In erster Linie läuft Docker auf Linux. Es braucht ein Linux-Colonel, der unten drunter ist. Es läuft aber auch mit Linux-Betriebssystemen effektiv in virtuellen Maschinen, wo ein Linux installiert ist. Und es läuft auch auf einem Linux-Betriebssystem, natürlich dann auch auf direkt dem Nacktien-Metall. Also direkt auf dem Server, ohne Probleme. Es unterstützt fast die jegliche Distribution heute, Docker. Also wenn ihr irgendwie ein aktuelles Ubuntu, ein aktuelles Fedora, ein aktuelles Ganttu nehmt oder sonst was, ist eigentlich ziemlich egal. Hauptsache eine Linux-Distribution und ihr habt eine Möglichkeit, Docker laufen zu lassen. Voraussetzungen sind natürlich moderne Kernel und wenn ihr ein Betriebssystem habt, was auch einen alten Kernel hat, dann kann das teilweise auch noch funktionieren. Für 3.2 gibt es noch Portierungen. Aber so alles mit 2.6 irgendwie solltet ihr besser vielleicht nicht Docker benutzen. Das Problem ist einfach hier fehlen die Bausteine, die Docker benutzt, nämlich Elix-C-Linux-Container-Format und so weiter, um die richtige nutzen zu können. Und ihr seid ein Stück weit angewiesen darauf, dass es X8664-Plattformen sind. Was ich sehr faszinierend finde, von Docker für ARM. Also wenn euch immer ARM sagt, so ein Embedded-Bereich besonders stark, da wollen die irgendwie auch was mit Containern machen. Ich weiß nicht, wie performant das Ganze ist an deiner Stelle, aber ja, ihr habt auf jeden Fall auch starkes Interesse daran, die Industrie, und die Portierung da findet, fand eben schon statt und wird gerade weiterentwickelt. Was ist ein Dockerfall? Das ist jetzt mal so die Basiskomponente, die ihr braucht, nämlich die Bauanleitung. Wenn ihr so ein Dockercontainer baut, dann müsst ihr ihm ein Dockerfall präsentieren. Das heißt tatsächlich Dockerfall. Und darin beschreibt ihr in Schritt-verschritt-Anleitungen, was ihr haben wollt. In dem Beispiel, was ich jetzt hier oben zeige, wenn man seht ihr oben, das Fedora 20, was hier als Dependency required wird, das ist dieses From. Also, wir holen es ein Basisystem rein in den Dockercontainer, der erstmal aussieht wie ein Fedora. Dann setzen wir noch ein Maintainer, der dieses Paket, der irgendwie dieses Dockerfall mal geschrieben hat, aber es ist nur Meta-Information. Und dann führen wir Befehle aus, mit sogenannten Run-Kommandos. Und dies fühlt sich genauso an von den alten Administratoren, als würde er ja auf der Bash nacheinander die Befehle reinhacken, was er installieren möchte. Also, er ruft sein Paketmanager der Wahl auf, installiert erstmal das Paket, was er haben möchte, in dem Fall MongoDB. Und am Ende ruft, räumt er auch noch ein bisschen auf, was er gerade installiert hat mit seinem Zeug, damit nicht irgendwie das Zeug rumgammelt, was da nicht hingehört. Und dann installiert er ein Directory, also habe ich installiert, sondern legt ein Directory an, touched ein paar Files, alles was halt MongoDB braucht, um nachher zu funktionieren. Und dann legt er noch mit diesem Add-Befil, den ihr hier sehen könnt, ein Fall rein in diesen Dockercontainer, was vorher an sich so nicht erreichbar war, nämlich es kommt aus dem eigentlichen Dateisystem, wo Docker gerade aufgerufen worden ist. Also liegt zum Beispiel in eurem Home Directory drin, da liegt eine Constatei von MongoDB und die bindet jetzt einfach in diesen Container mit ein. Aber in dieses Image. Ja, und dann gibt es noch ein Volumes Definition. Die Volumes Definition hilft euch zu sagen, ich biete übrigens ein Verzeichnis an, das heißt, war mit MongoDB und da kann ein anderer Container gerne sich Daten auch abholen, wenn er das machen möchte. Zum Beispiel, weil es ein zweiter MongoDB Container ist, der auf denselben Daten arbeitet, was tatsächlich mit MongoDB funktioniert, dann kann er diesen Datenbereich auch lesen, also denselben Datenbereich, den der erste Container auch liest. Und das ist nur die Hilfe dazu, dem anderen Container zu sagen, übrigens, hier gibt es ein Verzeichnis, das kannst du lesen. Dann gibt es Expose. Expose hilft zu deklarieren, welche Ports nach außen hin dein Container zur Verfügung stellt. Das ist Ports 80 und Ports 443. Bei MongoDB ist es irgendeine grüptische Portnummer, ich weiß nicht mehr, ob die offizielle ist, keine Ahnung. Aber auf jeden Fall sind das die Deklarationen, die man benutzt, um nachher die Ports bekannt zu geben an die Außenwelt, aber das hat effektiv auch nur einen Dokumentationseffekt. Also diese Portnummer sind nicht zwanghaft, wenn ihr da ein Portnummer vergessen habt, die eure Service eigentlich zur Verfügung stellt, dann passiert da gar nichts, ihr könnt trotzdem einfach unser dieser Portnummer. Es ist nur so, dass diese Portnummer hier helfen, den anderen, wenn man eine Übersicht macht über alle Container zu sehen, okay, welche Ports bietet eigentlich, sollte eigentlich dieser Container anbieten. Okay, dann gibt es ein User. Ein User, der hilft, einfach im Container zu bestimmen, welcher unter welchem Benutzer rechten sollte das Ganze laufen. Weil man möchte ungern Sachen immer als gut laufen lassen, auch in Containern. Dazu komme ich auch später mehr in die Security-Geschichten. Und ein Work Directory, das ist so was wie ein Home Directory von dem Prozess. Und ein Entry Point und Command. Ein Entry Point und Command, das sind zwei voneinander ein bisschen unabhängige Dinge. Das Entry Point bezeichnet einfach ein Programm, was gestartet hat, wenn der Container hochgefahren wird. Und der Command bezeichnet sozusagen die Parameter, die dem Kommando übergeben werden. Dann kann man nachher später auch noch mit den Docker Tools ein bisschen dran rumspielen, auch wenn dieses Dockerfals schon definiert worden ist, kann man später trotzdem die Parameter aufrufen. Jetzt kommen wir zur eigentlichen Command-Line von Docker. Kann man das lesen? Okay, sehr gut. Command-Line von Docker ist meistens, was die ersten machen, werden mit Docker wahrscheinlich ist. Sie installieren sich Docker über ihre Distributionen, die sie installiert haben. Und rufen dann normalerweise ein Pull-Befil auf, der ihnen erstmal ein Image besorgt, was schon existiert. Hier hat schon jemand mal ein Dockerfals geschrieben. Und das Image kann man sich einfach runterladen, kann man starten und dann hat man ein Container. Dazu benutzt man Docker Pull. In dem Fall wird ein Ubuntu Image runtergeladen. Dann kann man jetzt mit diesem Image, was man runtergeladen hat, kann man erstmal vorerst noch gar nichts machen. Das ist einfach mal so ein Blob. Um damit etwas zu tun, muss man Docker Run aufrufen. Hier ist ein bisschen ein komplexeres Beispiel von Docker Run, was hier benutzt wird. Hier gibt es einen Hello World ausgibt in diesem Container. Aber an sich sind die Docker Run befehle relativ kurz gehalten. Außer, sie haben relativ viele Parameter, es kommt drauf an. Ich dachte, dem, wie ihr es zusammenpackt, braucht ihr manchmal mehr, manchmal weniger. Und dann gibt es noch ein paar Hilfskommandos, dass sie mal so ein Container laufen lassen. Nämlich, man kann mit Docker Logs dann in diesen Container reingucken und kann gucken, was hat er auf Standard Out rausgeschrieben. Also dadurch habt ihr sozusagen ein bisschen so etwas wie die Prozessverwaltung an der Stelle, mit der ihr eben die Docker Container befähigen könnt. Ja, es gibt noch mehr. Viel, viel, viel mehr an der Stelle. Ich möchte gar nicht alle Befehle erklären, die an der Stelle da sind, weil Docker irgendwie gefühlt jede Stunde kommt ein neues Kommando raus, was unterstützt wird in der Stelle. Es gibt eben noch Stop-Starten, Exec, alles Mögliche, mit dem man halt die Docker Container verwalten kann. Weil es gibt immer mehr Wünsche von Benutzern mit diesen Docker Containern noch mehr machen zu können, als man schon kann. Also außer Starten stoppen möchte man sich jedenfalls auch mal einfrieren können. Man möchte gegebenenfalls auch mal eine Schelle drin spawnen können. Auch so ein ganz komischer Wunsch. Und man möchte gegebenenfalls auch mal unterschiedliche Logs daraus lesen können und so weiter. Das dafür gibt es dann alles getrennte Kommandos, die dieses Docker Tool zur Verfügung stellt. Das kennen die meisten unter Docker, diese CLI, also dieses Command Line Interface, das kennen die meisten als Docker. Aber an sich ist eigentlich die wahre Macht dahinten dran, der Docker Diemen, der diese ganzen Funktionalitäten macht. Die CLI sendet nur ein AP Befehl an den Docker Diemen im Hintergrund und der übernimmt für einen die ganzen Aufgaben an der Stelle. Es gibt ein paar Kommandos, da muss der Kleint auch noch selber Sachen machen, aber der Docker Diemen hat schon sehr viel Magie an der Stelle. Dann zu den Basiskomponenten. Wie ich schon erwähnt habe, es gibt diesen Docker Diemen. Der ist, am Anfang war der relativ schmal, ziemlich klein, ziemlich einfach. Zwischenseitig ist es schon ziemlich komplex geworden dieser Docker Diemen. Und man muss sagen, er läuft als Ruht. Also wenn er mir Docker irgendwas macht an der Stelle, er braucht die Ruhtrechte. Und dann hat auch dieser Prozess Ruhtrechte und führt er auch als Ruht aus. Er tropft keine Privileges oder so was, sondern er füllt es als Ruht aus. Und dieser Docker Diemen stellt diese Docker AP zur Verfügung, auf die ihr euch connecten könnt, individual über die CLI oder tatsächlich über einen HDTP Rest-Interface. Die zwei Möglichkeiten habt ihr. Und es gibt noch eine wichtige Komponente, die man am Anfang gesehen hat, indirekt, das ist der Docker Hub. Ihr habt das Docker Pull am Anfang gesehen, um den Image sich runter zu laden. Dieses Image kommt von einer offiziellen Webseite, die Docker Hub sich nennt. Und dort werden alle diese Images gespeichert. Also jemand hat mal ein Docker Fall geschrieben, hat mal ein Image erstellt daraus und hat dann dieses Image hochgeladen auf die Docker Registry. Und jetzt gibt es so ein Namensding. Manchmal wird es Registry genannt, manchmal wird es Repository genannt, Docker ist da ziemlich uneins, was so die Namensgebung an der Stelle angeht. Oder manchmal nennt man es eben den Docker Hub, wenn man den mit den offiziellen meint. Aber es gibt solche Hubs auch privat, die heißen dann normalerweise Private Registry. Also wenn ihr einen Betrieb habt, ein Unternehmen habt, in dem ihr eure Images nicht gerne an die ganze Welt verteilen wollt, dann legt ihr euch so eine Private Registry an. Die könnt ihr bei euch selber betreiben. Und ihr fällt sich genau gleich und ihr könnt auch ein Docker Pull machen und eure Images runterladen. So, dann gibt es aber noch einen wichtigen Unterschied, nämlich ich nutze es schon die ganze Zeit zwischen Image und Container. Ein Image hat ein Name und der Step ausgeführt. Und am Ende entsteht ein Applikationsabbild von dem, was ihr im Dockerfalt definiert habt. Das darf man allerdings nicht verwechseln, mit dem, was ein Container ist. Ein Container hat auch ein Name, den können wir auch in Namen geben, aber der benutzt das Image als Basis. Und wenn das Image ausgeführt wird, dann wird daraus sozusagen eine Runtime. Also dort drin wird dann eigentlich Leben eingehaucht, diesem Image. Und dann spricht man effektiv von einem Container. Oft so, wenn man Docker anfängt, zu wechseln an die beiden Sachen, was ein Image und was ein Container ist. Images könnt ihr irgendwo hinschieben, rumpurschen, runterladen, in Targetets zusammenparken und so weiter. Container lasst ihr laufen, stoppt ihr, löscht ihr und so weiter. Ja, der ganze Prozess an der Stelle dann, mal kurz visualisiert, sieht dann so aus, dass sich hier unten das Dockerfile als Ausgangsbasis habe, was wiederum in einem Verzeihensnick, nämlich ein Docker-Dier, also überall da, wo ich ein Dockerfile reinlege, ist es automatisch auch ein Docker-Dier. Und dann kann ich ein Kommando aufrufen, das heißt Docker-Bild. Und mit dem Docker-Bild-Kommando füge ich dann sozusagen aus diesen einzelnen Schritten, die ich definiert habe in diesem Dockerfile, führ ich dann ein Image zusammen. Und dieses Image kann ich dann jederzeit, wenn ich es einmal gebaut habe, dann habe ich ein Container. Und wenn ich diesen Container laufen habe und der Container hat irgendwelche Änderungen gemacht, die ich gerne wieder hätte im laufenden Betrieb, dann kann ich das tatsächlich mit Docker-Commit wieder zu einem Image zurückbringen. Aber es ist nicht dasselbe. Oder ich kann natürlich mit dem Image hingehen und ich kann einen Docker-Push ausführen und kann eben auf diesen Docker-Harp oder Docker-Repositories oder Registries, wenn man sie nennen möchte, Daten pushen und jetzt kommt das Interessante dieser Loop zurück, der hier entsteht. Zurück auf ein Dockerfile von einer Docker-Repository. Der schafft die Möglichkeit, dass ich, wenn ich Software entwickle, nicht jedes Mal das Rad neu erfinden muss. Also es heißt, wenn ich mir jetzt eine Python-Applikation schreiben möchte, dann muss ich mir nicht in eigenen Python-Container bauen auf Basis von Ubuntu und erstmal so die Python-Abhängigkeiten installieren, was ich da brauche, die Libraries und so weiter, und ich drücke im Zweifel auf den Docker-Harp und da gibt es schon ein Python-Image. Und diese Python-Images, die es auf dem Docker-Harp gibt, sind schon so generisch gehalten, dass die mir ermöglichen, meine eigenen Abhängigkeiten als ein Requirements-TXT mit in dieses Docker-Dir zu legen. Und dann kann ich das Docker-Bild aufrufen und schreibt mein Docker-File, was ganz kurz ist, was nur noch mal eine Applikation enthält und es gibt aber in der Formzeile Python an was basiert auf dem alten Image, was auf der Repository hier oben kam. Also es heißt, ich kann einen Ansatz machen, dass ich mir eine Basis suche irgendwo, Python, Perl, sonst was, ein Docker-Container, ein Docker-Image, und dann dieses Image nehme, in meinem Docker-File als From-Angebe und damit sozusagen meine Applikation on top draufbauen. Wieso geht das? Ja, Docker hat da Intelligenz eingebaut in der Stelle. Docker ermöglicht seine Daten, seine einzelnen Schritte, die es ausführt, seine Sachen, die den Bildprozess durchmacht, als Layer zu speichern. Und von Layern kann man im Kompetent davon reden, dass auf Körne-Ebene ein Dateisystem benutzt wird, was Layer unterstützt. Es gab, war mal zu einer Zeit lang, OFS unter Docker, jetzt zwischenseitig ist es schon wieder eine andere, Device-Mapper, heißt das System, was Sie jetzt nutzen und das System ist unterschiedlich, es interessiert aber meistens die Leute nicht, weil sie damit gar nicht in Berührung kommen. Das einzige Wichtige ist, es muss einen System geben, was Layer unterstützt. Und was man jetzt hier tut, zum Beispiel, und das sieht man in diesem Beispiel ist, man hat ein Debian-Basis-Container und darauf führt man aus, dass man Emails haben möchte. Das ist dann ein zusätzlicher Layer auf diesem Debian-Basis-Container. Dieser Basis-Container von Debian bleibt unangefast. Der liegt nach wie vor, so wie am Anfang ihr eure Änderungen wird nur on top gemacht auf einem neuen Layer. Und dann wird noch ein Apache hinzugefügt auf diesen Emacs und es erzeugt wiederum ein neues Image, was allerdings eine Abhängigkeit natürlich hat von dem unten drunter. Also es gibt noch eine Abhängigkeit, eine Referenzabhängigkeit nach unten hin und damit ist ganz klar, was ihr am Ende kriegt. Und jetzt kommt noch ein wichtiger Schritt, ganz oben, was passiert in ganz oben. Ganz oben gibt es ein Union-Mount-Layer, der ganz oben drauf sitzt und dieser Union-Mount ermöglicht euch, dass wenn ihr Dateien verändert, die eigentlich in den unterliegenden Layern drin sind, dass er zum Zeitpunkt, wenn er sie verändert, ein Copy-on-Write macht, also er kopiert den Datenblopp, woanders denn, in seinem Speicher, gibt euch den als Schreib zum Schreiben frei und dann könnt ihr darauf Sachen verändern. Aber so lange die Dateien nicht anfassen, und passiert da gar nichts. Ihr verändert nichts an dieser Total. Das heißt, er greift weiterhin auf diese Layer zu, die er vorher schon sich irgendwo mal runtergeladen hat. Was heißt das? Wie können die sie wieder benutzt werden? Und was Vorteile schaffen sich daraus? Als Beispiel hier in Ubuntu, aktuelle Longtime Support Release, Ubuntu hat man sich hier runtergeladen, hat darauf ein Apache Layer sich mal gebaut. Den hat man Apache genannt, das Image. Und jetzt unterscheidet sich es aber in zwei Richtungen. Man hat nämlich einmal ModPerl benötigt für Apache, um eine Perl-Applikation, ein Monitoring-System eSyncer zu installieren. Und einmal hat man aber Apache gebraucht, um PHP 5 zu installieren. Und darauf ein WordPress laufen zu lassen. Und an der Stelle hilft einem Docker und erkennt, dass eben Apache das gemeinsame Teil ist und benutzt das wieder. Und erst ab der Unterscheidung ModPerl und PHP 5 ist eine fremde Wege. Und diese Layer müssen gebaut werden. Aber vorher wird unten drunter die Basis dasselbe benutzt. Hat auch den Vorteil, wenn ihr jetzt wirklich Security-Updates einspielen müsst für dieses unterliegende Ubuntu, müsst ihr das einmal nur für dieses Ubuntu tun und dann vererbt sich das hoffentlich weiter in alle weiteren Container. Bei den Security-Sachen rede ich immer noch darüber, das kann auch schiefgehen. Ja. Also, man kann das sogar noch weitertreiben dass man eine Applikation hat, die auch auf WordPress basiert. Aber man will diese Applikation zweimal starten. Also man will zwei WordPress-Blocks haben. Da kann man das auch mit Docker einfach zweimal Docker Run aufrufen für WordPress. Und man hat am Ende zwei Container, die WordPress darstellen, genau gleich. Vielleicht auf unterschiedlichen URLs heran dann später, wenn man sie durchkonfiguriert hat. Aber somit hat man halt zwei Applikationen, die aus denselben Layern stammen, nur wenn man sich unterscheiden an dem Union-Mount-Layer, der ganz oben drauf liegt. Das ist der einzige Unterschied. Also die Laufzeitdaten sind der einzige Unterschied. Das ist einfach sehr speichereffizient, muss man sagen. Also, für mir aus der Firma raus kann ich euch sagen, dass es so ist, dass wir eine Applikation haben, die müssen wir ca. 100 Mal parallel deployen auf einem Server. Und wir speichern die Daten für diese Applikation, für diese spezifische Version genau einmal. Und dann starten wir diesen Container 100 Mal. Im Normalfall, wenn wir mit einem virtualisierten System an diesen Ansatz rangehen würden, müssten wir diese Daten 100-fach duplicieren. Wir müssten in jedem virtuellen System diese Daten bereithalten. In dem Fall, wo wir ein Basis-System nutzen und darauf 100 Container starten, haben wir die Daten genau nur einmal. Und das Einzige, was sich unterscheidet, sind die Laufzeitdaten. Und das ist interessant auch bei uns in der Applikation, zum Beispiel gar nicht viel. Also so ein Image unserer Applikation, müsste wir duplicieren 100 Mal, also 100 Gigabyte. Die Laufzeitdaten wiederum sind aber gerade mal 500 Megabyte. Also da kann man einfach deutlich erkennen, dass da das Container-basierte System deutlich überlegen ist in einem virtualisierten Ansatz. So, dann gibt es noch weitere Tools, die doch gerade zur Verfügung stellt. Das war das erstmal die Basics, die doch gerade da hat. Jetzt kommen noch weitere Tools ins Spiel. In erster Linie gibt es dazu Compose, was Anfang des Jahres sich groß aufkam, nachdem man ein anderes Projekt übernommen hatte. Das macht Docker auch gerne, so andere kleine Projekte, die sich interessant anhören, einfach mal schlucken. Die haben nämlich ziemlich viel Risikokapital bekommen, nachdem es so ein gehyptes Projekt war. Und Compose macht für einen Container-Management. Also man hat eine Applikation oder viele Applikation und die, wie ich sie vorhin gezeigt habe, besteht normalerweise aus mehreren Containern, wenn man den Docker-Ansatz verfolgt. Also ein Prozess pro Container, der Datenbank-Container, der Webserver-Container und so weiter. Also man hat Abhängigkeiten zwischen drinnen auch noch, die dann entstehen, wenn man multiple Container hat. Man hat die Netzwerkzugriffe, die gegenseitig realisiert werden müssen, die Volumezugriffe, die gegenseitig realisiert werden müssen und so weiter. Und da kommen jetzt Composensspielen. Compose ist das Verwaltungswerkzeug, was es euch ermöglicht, dass ihr diese Sachen miteinander verbinden könnt. Und das effizient für euch, wie der Nachher der Eindruck entsteht, ist es eine Applikation oder für den Entwickler. Und dazu benutzt Docker-Compose ein Jammel-Pfeil, wo man deklariert sozusagen, welche Images man alle haben möchte und wie die Images zueinander in Abhängigkeit stehen. Und dann bietet Docker-Compose auch noch Kommandos on top an, um diesen ganzen Verbunden zu starten, zu stoppen, neu zu bauen. Also man kann damit auch Docker-Bild aufrufen für alle diese Images und so weiter. Dann kommen wir zu Swarm. Swarm ist ein Docker-Projekt auch relativ neu, auch circa ein halbes Jahr alt. Wo es darum geht, wenn man so ein Docker betreibt, z.B. was es in größeren Clustern betreiben möchte. Und man hat ein Docker-Demon auf einem Server, man hat ein Docker-Demon auf dem zweiten Server, auf dem dritten Server, auf dem vierten Server. Überall sehen die Server normalerweise gleich aus. Also bietet sich eigentlich so ein Clustert-Antatz ziemlich gut an. Oder man hat Server, die sind zwar hier, aber man hat auch irgendwelche Server, wird normalisiert irgendwo in der Cloud. Und die möchte man jetzt auch in den Clustern damit verbinden. Das kann alles Swarm lösen. Swarm spawnt einfach multiple Docker-Demons überall. Und kann diese wiederum verwalten. Und am Ende ist es interessanter noch dabei, es gibt eine Apik-Kompatibilität zum normalen Docker. Das heißt, der Entwickler oder der Admin, der dann darauf eine App laufen lässt oder Container laufen lässt, für den fühlt sich das immer noch so an, dass man das nicht schützen kann. Also das, was der Admin gewohnt ist. Aber im Hintergrund startet er das irgendwo im Cluster. Oder, wie man so schön sagt, irgendwo in der Cloud. Genau. So, das letzte Tool, was ich euch noch vorstellen möchte heute ist Kite-Matic oder Kite-Matic. Und das Tool dient dann dafür, um es einfacher zu machen, Convenien zu machen, Leute, die unter Mac und Windows arbeiten, haben gerne Guys, sagt man. Also es fällt euch vor euch diese klicky-bunty-Geschichte zur Verfügung. Weil das Problem, was ihr tatsächlich habt, unter Mac und Windows, ist, dass ihr kein Linux-System habt. Ihr habt zwar unter Mac ein BSD-Klon im entferntesten Art und Weise, aber unter Windows habt ihr gar keine Chance. Und trotzdem möchtet ihr jedenfalls Docker nutzen. Und dafür bietet euch die Kite-Matic einen Installer an, mit dem ihr einfach unter Windows eine Excel, unter Mac eine dmg-Datei, mit dem ihr mit einem Klick euch eine Comments-Docker-Environment herzaubern könnt mit einer GUI. Und realisieren drinnen ist das Ganze mit VirtualBox im Hintergrund. Also da kommen wir einfach wieder zur Realität zurück. Was muss man tun auf einem System, was man hat? Ja, man muss ihn virtualisieren. Man hat keine Chance, das anders hinzukriegen. Aber sie machen das halt sehr konvinient. VirtualBox installiert sich im Hintergrund, startet diese VM, huckt sich überall da rein, wo es sein muss. Man kann sogar von der Shell aus unter den Mac, dann auf diesen Docker dementsich connecten. Das fühlt sich alles ganz nativ an. Aber in Wirklichkeit geht das halt immer noch einmal den Umweg in diese VM rein. Und was in dieser VM steckt, ist ein minimales Docker-Betriebssystem. Also früher war es mal so ein ganz abgespecktes Debian. Ich weiß nicht, was ich sage, benutzen die irgendetwas anderes. Ich weiß nicht mehr. Es scheint so den Trend zu geben, das irgendwie zu minimieren, dann wieder zu vergrößern, wieder zu minimieren, zu vergrößern, je nachdem, wie viele Features Sie gerade reinpacken in Docker. Also da gibt es immer jeden wie jedes Update, gibt es ein neues Betriebssystem, was Sie da benutzen. Und was Sie da natürlich ein sehr cooles Feature mit dieser GUI realisieren können, ist, Sie bieten eine Möglichkeit an, in dieser GUI, das sieht man auch hier, also Sie wissen ja, Webseiten besuchen und sowas, total out. Das macht man nicht mehr mal genügend. Das ist wieder die Applikation klassischerweise und sucht eine Applikation durch eine Webseite und tut dann von dort aus die Container starten. Also man klickt dann sozusagen auf Start und dann tut der im Hintergrund das runterladen, Docker pull machen, Docker run aufrufen und die Applikation läuft. Wenn man Zweifel kriegt, man dann hier auch noch Locks angezeigt auf im GUI. Oder für Leute, die sich Docker mal angucken wollten, nichts für den Proletivbetrieb überhaupt nicht. Das ist ein ziemlicher Verschlag, der da benutzt wird, um das irgendwie lauffähig zu kriegen. Okay. Gut, jetzt möchte ich mit euch noch über Sicherheit reden bei Docker. Weil ich denke, bei dem ganzen Hype ist dieses Thema irgendwie untergegangen. Was für Angriffsvektoren gibt es da? Naja, es gibt diesen Docker Diemen, den ich jetzt schon mehrfach angesprochen habe. Viele Applikation heutzutage auf Linux-Systemen laufen nicht unbedingt mehr mit Rootrechten, jedenfalls nur kurz am Anfang. Dann tropfen sie ihre Privilegien und es gehen weiter als User-Prozess. Aber der Docker Diemen arbeitet prinzipiell immer auf Root. Warum tut er das? Naja, da gibt es viele Probleme, die sie lösen müssen über die Zeit, was wahrscheinlich auch gelöst wird. Hoffentlich, dass sie eben auf Volumes zugreifen vom System, dass sie dem Linux-Curtle NW mit teilen möchten, dass er bestimmte C Groups anlegt, dass er NetNamespaces anlegt und diese ganzen Sachen kann man halt als User nicht tun. Oder jedenfalls nicht mit Docker tun. Ja, dann gibt es das Thema Docker API. Wie jede neue Applikation heutzutage kommt es mit einer API um die Ecke und man kann per R2-TP alle ziemlich alles machen, was natürlich auch nicht gut ist. Weil alles machen heißt tatsächlich auch, ich kann damit ein System own. Also ich kann tatsächlich über die Docker API mir einen arbitrieren Container starten, der mir in den Remote Shell von diesem Systemsporn nach extern. Also so wie der feuchte Traum von jedem um irgendwie in den Remote Code Execution hinzukriegen, wenn die Docker API offen ist, wunderbar, geht sofort. Gerade mal so Fortgutrechte, kann man alles machen. Sie haben diese Probleme ein bisschen adressiert, indem sie gesagt haben, okay, wir bieten die Docker API zur Version 0.6 oder sowas, vorher war die anders geregelt, bieten wir die mal nur per lokalen Socket an. Also vorher war die immer offen per TCP. Und da hat man die mal nur noch per lokalen Socket angeboten, so als Security Feature. Und hat dann gesagt, okay, jetzt hier nur ein lokaler Socket, der ab und weiß schon, was er tut. Ja, der lokalen Socket so von Haus aus in bestimmten Systemen ist auch von jedem schreibbar. Also jeder, der mal eine Shell hat, man muss mal gucken, ob der Docker installiert, ob da jemand Docker installiert hat und man kann mal gucken, ob der Socket da schreibbar ist. Wenn ja, dann viel Spaß mit dem Server. Also Ubuntu und sowas haben das Problem angelöst, indem sie hingegangen sind und gesagt haben, okay, von Haus aus hat dieser Socket nur Schreibrechte für eine Group namens Docker. Und daran ist normalerweise nur Hut vorerst mal drin. Und das muss man dann dementsprechend erweitern. Aber ja, es gibt viel interessantes Angriffspotenzial an der Stelle. Und interessanterweise ist es so, man kann eben noch RATTP zusätzlich einschalten. Also man kann neben den Ports und von Haus aus, wenn man RATTP einfach einschaltet, ist keine Verschüßelung angebaut und keine Authentifizierung. Also man ist wieder bei einem Fild, wie man vorher war, man hat einen TCP-Port nach außen aufgemacht und darüber kann man die Docker API erreichen. Und das Interessante ist auch noch, wenn man die URL einfach mal queried mit dem Port, dann kriegt man auch einfach mal gesagt, hallo, ich bin Docker mit der Aktion, so und so und so und so und so und so und so. Also das ist auch noch sehr geschwetzig und dann haben sie aber gesagt, oh ja, wir bauen das mal durch die Sicherheit ein, wir gehen mal hin und machen mal HTCPS. Ja, im kleinen Server-Modell. Also hat Docker API unterstützt, kleinen Server-Zertifikate. Jeder weiß, was für ein unheimlicher Krampf das ist, das Ganze auszurollen und gemanagt zu kriegen, für jeden Docker-Demen. Also was normalerweise passiert ist, es gibt irgendwie so einen kleinen Zertifikat, was sich alle teilen und irgendwie einen Server-Zertifikat, was sich alle teilen. Wie eine globale CA, teilweise auch noch, was sich alle teilen. Also das ist irgendwie ziemlich oft kaputt an der Stelle, dass man sieht, die Deployments, die haben HTCPS eingeschalten, aber dieses Zertifikat zu bekommen, ist meistens gar nicht so schwer. Und es ist halt nach wie vor optional. Also ich bin stark verfechtert davon, dass man HTCPS-Managerie heutzutage macht, wenn man neues Produkt auf den Markt bringt. Und ich denke, die Community, die hier im Raum ist, denkt genauso. Aber es ist bei Docker so, erst Inversion 7 oder sowas erschienen, dass man sowas mal einbaut. Und das ist natürlich auch gleichzeitig der Authentifizierungsschutz des Zertifikat. So, dann kommen wir ein bisschen mal runter von Docker an sich, aber am Ende nutzt Docker ganz viele Kernel Features. Und diese ganz vielen Kernel Features, die Docker nutzt, die werden halt durch diese API exposed, irgendwie. Also dieser Docker Run Befehl ruft halt im Hintergrund, legt Spaces an, lädt Images irgendwo runter, geht in den Kernel, schreibt irgendwie Zugriffsrechte, damit Volume Mounds und sowas funktionieren können und so weiter. Ja, dieses Docker Projekt hat ständigen Fortschritt in Entwicklung. So täglich kommen da ganz viele Commits rein und diese unterschiedlicher Qualität. Und manchmal ist es tatsächlich so, dass über welche bestimmten Funktionalitäten in der Docker API Kernel Sachen exposed werden, die so direkt hard level Kernel-Zugriff sind. Also LXC-Konfigurationsparameter sind teilweise so Spezialfälle. Und das ist ein unheimliches Sicherheitsproblem an der Stelle. Und wird manchmal auch nicht wirklich sauber abgefangen von der Docker API, dass da Sachen verändert werden können in den Stellen. Und da kommen halt wieder zum Schritt zurück Docker hat Routerechte, also das darf alles. Ihr könnt das mitigieren natürlich, indem ihr sowas wie Selinux und AppArmor benutzt. Kann man, sollte man auch ein Produkt betrieb tun, hat dann aber auch das Problem mit jedem Docker Update, rennt ihr erst bei hinterher und tut irgendwelche Selinux-Profile anpassen, damit dieses neue Features endlich immer unterstützt wird. So, dann kommen wir noch zum wichtigsten Punkt, das sind die Userfehler. Die Userfehler im Hauptbereich spielen sie sich ab mit den Containercapabilities. Also ich kann einem Container erlauben, dass er auch als gut läuft. Und das ist wirklich tatsächlich nicht cool. So, einem Container, der einen Subprozess hat, der normalerweise nach außen exposed wird, Routerechte zu geben, ist nicht gut aufs Basisystem. Sondern er sieht auch noch alle anderen Container natürlich, weil er ist ja Rout. Also man denkt man ist ein Container, aber in Wirklichkeit ist man es nicht. Und das heißt, wenn jemand Minus Minus Privileged bei Docker Run macht, tut er genau das, er gibt den System Routerechte, dem Container. Und dann gibt es das nächste, das ist das Material-Mounts, mit dem ich schon mehrfach geredet habe. Da kann ich hingehen und kann tatsächlich slashetc in einen Container rein mounten. Ja, und der ist dann redridable von dem User im Container. Also etcshadow ein bisschen rumspielen und so was, wenn ihr mal ein Docker-Container erlauben habt, könnt ihr mal gucken, ob das geht. Das sind halt solche Probleme, die entstehen können, und das gibt der Docker-Dimen, in die ihr reinlaufen könnt. Oder in die Adments reinlaufen, die es für euch, dieses Service anbieten, dass ihr Docker-Container erlaufen lassen könnt. Okay. Das war es so weit zum Security bei Docker. Die Zukunft von Docker. Ich denke Docker ist nicht das High-Mittel. Also der Hype, der in den letzten 2 Jahren darum entstanden ist, sondern im letzten Jahr war so massiv, dass sich natürlich auch andere gedacht haben, dass wir Docker-Jungs da machen, das können wir irgendwie auch. Also Docker ist nicht die Lösung, die alle Probleme lösten an vielen Stellen, löste die auch nicht. Aber es ist mal der erste Schritt gewesen. Das war das erste Projekt, was man große Aufmerksamkeit bekommen hat. Weil Linux-Containers LXC existiert schon seit 2007. Also das Projekt ist echt ziemlich alt und ist auch ziemlich erwachsen, was das angeht. Aber der richtigen Schub jetzt hat es erst durch Docker bekommen. Also was gibt es da mehr am Horizont? Es gibt Rocket. Coole Namen für Projekte. Rocket ist eine Ausgründung von CoreOS. Ein Betriebssystem, was speziell eigentlich nur auf Docker gerichtet war, jetzt zwischendurch aber auch mehr macht. Darum geht es ein alternatives Container-Format zu schaffen. Ein Format neben Docker. Also dieses Docker-File und diese Docker-Images usw. zu ersetzen durch was Eigenes. Und was Sie, die Idee, die Sie haben ist, damit schneller Einfahrer-Systeme aufsetzen und man hat eine schmaleren Footprint von dem Gesamtsystem, wo Docker unheimlich gigantisch geworden ist zwischenzeitlich. Und Security ist da auch im Fokus. Es gibt signierte Images zum Beispiel. Dann gibt es noch ClearLinux. ClearLinux ist ein Intel-Projekt. Das zieht darauf ab, Containervirtualisierung zu verheiraten mit Virtualisierung. Also mit der klassischen Virtualisierung. Ich bring KVM zusammen mit Linux-Containern und starte pro Linux-Container eine Kubette KVM-Umgebung und habe die Sicherheit von KVM als Virtualisierer plus dem Imagesaustauschbarkeit von Containern. Und trotzdem der Convenience von Containern. Wie Sie das erzielen wollen, ist dadurch, dass Sie hingehen und hardwareseitig mit Ihren Intel-Features das Problem optimieren werden, dass KVM ein Overhead schafft. Dadurch hat man aber wirklich tatsächlich das Security technisch eine komplette Isolation wie in der VM. Und dann gibt es Robuntu, die was Eigenes an der Stelle machen. Canonical hat LXD ausgerufen, der Linux-Container-Diemen, den Sie selber positionieren wollen gegenüber Docker und Rockcap und so weiter, wo Sie sagen, wir schiften weg von dem Paradigma ein Prozess pro Container. Also Sie erlauben durchaus in Docker-Containern multiple Prozesse und machen auch Prozessmanagement in einem Docker-Container, sondern in einem Container. Und dadurch ermöglichen Sie halt in einem Container zu starten. Und Sie denken natürlich auch, dass Sie das schmaler hinkriegen als Docker und besser sicher hinkriegen und das Ganze auch noch viel cooler integriert bekommen mit ein anderes System. So, das war's. Ich danke euch erstmal für die Aufmerksamkeit und wenn ihr Fragen habt, könnt ihr gerne jetzt fragen. Ich glaube, es gibt hier kein Mikrofon. Und ansonsten, ich bin auch nach dem Vortag noch da, ich warte hier draußen, da könnt ihr auch gerne noch fragen stellen. Ja, das spricht sich nicht unbedingt. Kommt auf an, wie du deinen Prozess strukturiert hast in der Stelle. Wenn der Entwickler zuständig ist für diesen Container und du ein Bild-Server zum Beispiel hast, eine Bildpipeline irgendwie, wo diese Container gebaut werden, dann kümmert sich normalerweise der Entwickler darum, dass auch wenn es Security-Updates gibt, die seinem Produkt betreffen, dass ergegebenfalls auch darauf hinwirkt, dass er einfließt, indem er diesen Bildprozess neu anstößt, dieser Ubuntu, den er neu gebaut wird, daraufhin sein Applikationscode darauf neu gebaut wird, weil im Zweifelfall muss er das noch mal kontrollieren, ob seine Applikation immer noch genauso funktioniert wie vorher, weil vielleicht waren da nicht nur Security-Updates drin oder vielleicht haben die Security-Updates auch Verhalten geändert. Also an der Stelle ist es tatsächlich organisatorisch eine Geschichte, die gelöst werden muss, wenn man über diesen multiplen Image-Ansatz geht, wenn man auf eine Image sagt, ich gebe dir recht, wenn man das so tut, dass der Atmen dieses Ubuntu Image verwaltet und der Entwickler oben nur dieses eine Image verwaltet, dann hat man auch lustige Phänomene, die eben dazu führen, dass sich das nicht genau gleich verhält. Außer der Entwickler benutzt nur dieses Image, was der Atmen immer zur Verfügung stellt. Dann hat er eigentlich auch immer dasselbe Verhalten. Also die Frage ist, wenn man so multiple Abhängigkeiten hat und jetzt unten in diesem unteren Verhalten was verändert hat, zum Beispiel war G-Lib-C Sicherheitspatch, der rein musste, wie man sicherstellt, dass die Applikation die ganz oben ist und das läuft, dass die dieses Update auch bekommt, also dass die gepatchede G-Lib-C auch benutzt. Genau. Also jetzt kommt man einfach zu dem Fall, man muss unterscheiden zwischen dem Image und zwischen dem Container. Die Applikation die oben läuft, ist der Container. Das, was die G-Lib-C verändert, ist das Image. Das Image wird durch die G-Lib-C verändert. Also um diese Image-Änderungen in dem Container richtig reinzubekommen, muss der Container effektiv neu gestartet werden. Ja. Also ich kann mit dem Docker Command Line Clients, kann ich, also die Frage nochmal wiederholen, ob es eine Möglichkeit gibt, das automatisiert irgendwie zu tun, dass man mit einem Client sagen kann, starten alle Container neu, die auf diesem Image basieren. Ja, das gibt es, ist allerdings meistens so ein bisschen selbst gestrickt. Also man muss wirklich sagen, Docker von Haus aus bietet nicht, die optimalen Tools, das zu tun. Man muss ein bisschen Bash Glue Code zwischen reinschreiben. Dann kann man das auch machen. Und sollte man auch dringend tun, dass wenn man diese Security Patches hat, dass man die auch schlechtzeitig ausrollt und allgemein in die Richtung geht das ganze versions, also paketiertes Systeme und die Versionsverwaltung und sowas mit Docker, ist nicht immer einfach zu lösen, die Probleme in der Stelle. Man muss dann auch Abhängigkeiten hat von außen über ein Paket mehr Raw und sowas, wie man den dann richtig rein pflegt und sich jetzt zu stellen, dass die auch wirklich in allen Docker Containern drinnen ist und sowas, das ist manchmal eine ziemliche Aufgabe. So, die letzte Frage, dann muss ich leider sagen, dann ist auch Schluss, da muss ich da nämlich leider vorgehen, ja. Also, Entschuldigung, ich glaube, hier hinten war der länger. Also, so best practice zum Datenhaltung in Containern, weil das ist das, zum Datenhaltung in Containern war die Frage. Schwierig, ist sehr applikationsabhängig. Ist sehr applikationsabhängig. Im Normalfall der erste Schritt, den die meisten machen, ist, dass sie den Totalsystem vom Host legen. Das ist der erste Schritt. Was ihr sagen kannst, was wir, was ich beruflich tue an der Stelle, ist die Sache, dass ich diese Container, die Daten da drinnen reinlege, zum Zeitpunkt, wenn der Container startet, er sich selbst mit diesen Daten professioniert aus einer externen Quelle und zum Zeitpunkt des Beendens, diese Daten wieder rausschreibt. Damit liegen die Daten rein im Container, liegen nichts im Hostsystem und sind verfügbar dort. Es gibt unterschiedliche Ansätze, das ist total abhängig von der Applikation, die man hat, sondern man hat Applikationen, und wenn man ein State hat, dann muss man sich das überlegen, wie man den am besten strukturiert und wo man den ablegt. Okay, dann vielen Dank.