 Hallo zusammen, ich möchte euch heute ein bisschen was über schlanke OCI Container reden und erzählen und was sind eigentlich diese OCI Container? Kurz als Vorwarnung, wie in der Ankündigung gesagt, wenn ihr den ganzen Tag eure Kubernetes-Cluster baut und euch mit eurer Rüberskullieren und ihr habt auch ganz ein paar Pläns im Griff, werdet ihr nichts Neues erfahren. Wir gucken uns hier mal so ein bisschen die Basics an, die Hintersohne im lustigen Container leben. Zuerst mal kurz zu mir, habt euch mal Mathe studiert, habt euch so eine kleine Vorliebe für krafttheorische Probleme. Manchmal entwickle ich Software, aber was ich viel öfter mache ist, ich deploy integriere Zeug. Was haben die andere Leute gebaut haben und was die ja so gebaut haben. Alle machen mit best Erfolg, ich mache Fehler, alle machen Fehler und es gibt so ein paar Dinge, wo ich sage, da bin ich jetzt so oft drüber gestobert, vielleicht können wir das ja in Zukunft mal ein bisschen eleganter lösen. Kurz die Agenda, wo spielen wir heute durch? Was ist eigentlich so ein OCI Container? Und danach spielen wir einmal durch. Was ist eigentlich dieses komische Dockerfile? Wann ist mein Image fertig und wie sieht das mit den Updates aus? Dann werde ich noch einen kleinen Ausblick geben, was kann man eigentlich alles Cooles mit Bildpipelern zu machen. Und auch wenn es nur ein inhaltlich kurzes Zeitpunkt annimmt, aber weil es so wichtig ist, Leute, man kann das in der Pipeline scanen, über die Vulnerability-Scanner reden wir am Ende nochmal kurz. Auf geht's. OCI Container sagt wahrscheinlich keinem was. Unter dem Begriff Open Container Initiative gehört zu Linux Foundation. Dahinter sind tatsächlich diese ganzen Namen Docker, Portman, Container, der ist von Kubernetes, ganz viele andere, ganz viele Unternehmen, bla bla bla. Wo ist das relevant an der Stelle? Naja, das Problem war okay, die Idee mit so hellgepackten Dingen und Container und Betreiben, die ist cool. Aber wenn ihr zählt, alles ein bisschen anders machen, ist nix kompaktibel. Deshalb OCI ist eine wunderbar schöne Standardisierung. Sie haben jetzt vor zwei Wochen eine neue Iteration rausgebracht, wo im Open Container Standard zum Beispiel so etwas beigebracht wurde wie. Man kann als Artefakte nicht nur Images, zu denen kommen wir gleich ganz viel, sondern plötzlich kann man auch andere Datentypen nehmen, man kann Dinge verlinken und andere Attributionen dran schreiben. Ziemlich cool, aber ansonsten ist es eigentlich ein relativ gesetztes Format, da passiert nicht mehr so viel momentan. Immer noch genug spannendes Zeug. Aber wir gucken uns jetzt mal, die Docker-Doku finde ich immer noch toll für solche Sachen, auch wenn Docker mittlerweile ein bisschen von Portman bzw. Container, die verdrängt wurde aus diversen Gründen. Architektur-Dinge, die man damals so gemacht hat. Und damals war das das Beste, was man hatte. Und mittlerweile hat man daraus ein bisschen gelernt und macht anderen Aufbau. Was aber geblieben ist? Was ist eigentlich so ein Container? So ein Container besteht im Kern, da gehen wir gleich ganz roll drauf ein. Oh, nicht die Lichtreste kaputt treten. Hier haben wir ganz viele, irgendwie unsere Image, das irgendwie aus Layern besteht. Und das Ganze teilt sich irgendwie den Kernel, der teilt sich aber irgendwie vom restlichen System und wir können nur rennen komplett, weil der Star läuft schon. Und dann, irgendwann macht dieser Container jetzt nicht nur so ein Statisch aufs Blob, sondern der tut ja auch irgendwas. Und da haben wir hier diesem wunderbar schönen interaktiven Layer, das ist so, hey, das ist wohl meine eigentliche Arbeit drin passiert. Also, keine Ahnung, ich habe da vielleicht eine kleine Applikation drin, die mir eine West-AP anbietet. Und wenn ich sage, hey, was ist das fünffache von 25, dann gibt es mir dann halt irgendwelche lustigen Zahlen zurück. So, und das Spannende, was für uns jetzt im weiteren Verlauf ist, ist dieses schöne, was da als Image-Layers läuft. Und Idee ist so ein Image, das ist so unsere Hauptzutat für unsere ganze Container. Und wo gibt es ein Base-Image, das ist Layer. Und dann fügt die nächste Person oder nächste Eterrationsschritt ein Layer dazu, beispielsweise werden Dateien hinzugefügt. Das ist so die Standard-Juice-Case. Es gibt noch ein paar andere Sachen, die man in so einem Layer machen kann, wie man kann Label dran schreiben, man kann Umgebungsvariablen an das Ding dran hängen und, und, und, aber das Standard-Juice-Case ist tatsächlich, hey, wir packen Dateien hin oder auch wir plänten Dateien aus, weil das am Endeffekt ein Geschichte des Betriebssystems ist, das ist das nächste, das nächste, das nächste. Soweit so schick, so alles bequem. Und das hat natürlich diesen tollen Vorteil, hey, ich, ich baue, ich entwickel etwas, ja, ich muss nicht immer vom Urschlag am Anfang, sondern, keine Ahnung, ich brauche NGNX, cool. Hier, nimm mal bitte ein NGNX-Image, da haben ordentliche Leute vor mir schon was gebaut, und dann pack ich übrigens, ich will folgende NGNX-Config haben, lade die rein, ach, und folgende Umgebungsparameter setzt du bitte noch, okay, cool, mach ich. Ich sag zwei Ebenen mehr in meinem Image, und dann habe ich plötzlich ein Image, und das kann ich dann wieder in irgendeine Container-Engine reinwerfen, zum Beispiel Docker, Portman, was auch immer. Und dann bekommt das ganze Leben und Arbeitsspeicher CPU, bla bla, cool. Und ja, wo kommt dieses komische Leiter her? Dockerfile haben wahrscheinlich fast alle schon mal gesehen, ist für, glaube ich, kaum wen was Neues. Ich habe hier jetzt mal genau das Demo-Beispiel auch wieder aus einem Docker-Dokument herausgepickt, weil es einfach ein paar schöne Sachen nimmt. Es gibt dieses eine Schlüsselwort immer drin, Form, das ist, von welchem Image fange ich an. Es kann auch ein empty Image sein, alles cool. Ich setze Label rein, standardmäßig ist meistens alles drin, muss ich mich gar nicht selber darum kümmern. Copy, das ist dieser Sprung, wo jetzt irgendwo mal Dateien ranwandern, in dem Fall von meinem auswählenden Verzeichnis, also wo auch immer dieses Docker-Bild gerade passiert, und seinen Bildverzeichnis hat. Da liegen ordentlich Dateien drin, und schmeißen wir mal bitte nach App. Ah, okay, dann bauen wir anscheinend. Also es ist scheinbar, gehen wir mal von aus, dass da irgendwie ein Make-File mit dabei war, cool, dann bauen wir. Ja, gut, und jetzt haben wir gebaut, und die ganzen Cash-Starten brauchen wir jetzt unbedingt nicht. Ja, dann löschen wir sie nochmal. Und dann zum Ende, ja, was passiert, wenn jetzt wer den Container startet, hat das ordentlich ein Standard-Befil. Ja, hat's, bitte mit Pfeifen, man kann es sich auch, und da kommen wir auch schon gleich auf unsere Stolperfallen. Nämlich, hier sind ein paar Dinge an diesem Beispiel, ich zermache das ganz gerne, ein paar Dinge sind echt schön, und ein paar Dinge, da könnte man besser machen. Aber gehen wir mal positiv ran. Was, gucken wir alle kurz drauf, was fällt uns auf? Ja, okay, irgendwie wird hier an einem Layer irgendwas angelegt, und dem anderen Layer gelöscht. Wir hatten ja gerade gesehen so, wir bauen aufeinander auf. Hm, was passiert denn dann? Ja, genau, dann haben wir natürlich plötzlich da zwei Layer, und natürlich, wenn ich hier bin, kann was da irgendwie in diesem Cash-Otner war, kann ich aus dieser Betriebs-Ebene nicht mehr aufrufen, also wenn meine Applikation kommt nicht mehr in diese Daten, weil die sind ja gelöscht. Aber irgendwie sind sie trotzdem noch im Image drin. Unpraktisch. Aber man konnte es viel, viel schlimmer machen. Was könnte man alles noch schlimmer machen, wenn man irgendwie alle leider doch zu häufig gesehen habe. Man kann Umgebungsvariablen setzen. Ist das mal persönlich Schlimmes. Kritisch wird es aber, wenn diese Umgebungsvariablen zum Beispiel Daten enthalten, die eigentlich nicht so ein Image sind. Während uns so ein Image, ist eigentlich so ein Start-up-Lob. Und den fügen wir dann irgendwann zur Laufzeit, Arbeitsspeicher- und Umgebungsparameter dazu. Und natürlich können wir die auch irgendwie alle mit in das Image reinpacken, aber dann wird das schnell mit der Universität schwierig. Wo es noch mehr will, tut es. Ich eventuell schreibe es nicht als Ent-Umgebungsvariable, sondern als ARC. Das heißt am Ende nur mit, ich gebe das zur Bauzeit rein. Ja, aber was sind Daten, die ich in so ein Image zur Bauzeit reingebe, so als Trink kodiert? Erstaunlich häufig habe ich da ordentliche Konfigurationen gefunden, die man eigentlich nicht im Image haben möchte, weil, vielleicht will das nochmal im Image oder vielleicht will man es auch mit der Welt teilen und vielleicht teilt man es auch immer umbeabsichtigt mit der Welt und da hat man diese ganzen Baustellen, die man will man dann nicht sehen. Und one hard coded swing, damit meint ich so dieses Problem. Ja, es werden auch gerne Credentials Dinge mit in Image rein gepackt. Es gibt so Dinge, wo man sagt, okay, kann man drüber reden, wie, hey, übrigens, wenn du in diesem Image, du willst übrigens folgender CA vertrauen, weil, keine Ahnung, da kommt, das ist deine interne Quelle, dann willst du das vielleicht drin haben und nicht zur Laufzeit, gerade wenn das irgendwelche Konfigurationen macht, aber in meisten Fällen möchtest du das eigentlich nicht drin haben. Es sind so Paarbaustellen, so alles so oft gesehen, bitte nicht machen. Was könnten wir ja schöner machen? Gehen wir mal durch. Wir könnten zum Beispiel, wo wir unsere Make-App haben und dann nach den Cash-Loschen, wir müssten das nicht in zwei Layer reinpacken. Das kann in einem Layer passieren, das ist ein Schritt und dann landen die Daten gar nicht aus meinem Image und machen sie nebenbei auch nicht gar nicht dicker. Weil, da ist ja das Problem, jedes Mal, wenn ich anfange und auf mein, das Ding ausführe, muss ich jedes Mal, auch wenn es relativ schnell geht, ich muss jedes Mal durch alle Layer durchgreifen. Ich kann als Containerbetriebssystem in diesem Demo ein Beispiel. Wir hatten kein User deklariert, je nachdem, unter welcher Container-Engine wir unterwegs sind, bei Docker ist das startmäßig ruht. Ich weiß nicht ob, ja, man könnte natürlich sagen, es ist alles im Container drin, aber eigentlich möchte man doch den User ein bisschen gerne etwas enger fassen. Die andere Frage ist dann so, wie sich eigentlich meine Credentials in diesen ganzen Spaß hinein. Und da gibt es nun eine Laufzeit reinwerfen, aber wie ich zum Beispiel um, wenn ich so ein Volt habe. Der Trick ist tatsächlich da, man mountet das Zeug. Man mountet es als Typ-Secret, dann kann man das zur Laufzeit wunderbar schon reinhängen. Und damit einfach an dem Beispiel so, wie macht man es nicht, viel schneller lernt. Ovas kennt ihr wahrscheinlich, sind ganz gut hinterher so ein bisschen mehr sicher als Praxis in Dinge reinzukriegen, haben wir ein wunderbar Funktion. Was von Secrets findet ihr wunderbar schön gefunden. Und da haben sie einfach mal ... da hat einfach mal ein Dockerfile geschrieben und entsprechend Image gebaut, aus dem man ein Container machen kann. Und da macht man einfach nur so alles falsch, was man mit so Secrets da falsch machen kann. Warum nervt der hier vorne im Endeffekt, ja, die haben, die coole Berechnung, wie ihr besonders elegant eure Fibonacci-Zahlen rechnet, eure tolle Web-Applikation, weißt der Geier, aber im Endeffekt läuft das irgendwo und irgendwo, haben Leute damit in Daktion. Und die wenigsten Anwendungen sind rein so, hey, ich bekomme ein Daten und ich gebe sie raus. In den meisten Fällen, ich habe eine Datenbank im Hintergrund, ich verschlüssel meine Kommunikation vielleicht, auch wenn ich das habe, dann haben wir so eine Späße wie, ja, vielleicht nutze ich ja selber meine Applikation, irgendwelche APIs für die ich mich selber wieder autentifizieren muss. Das will ich, das sind alles Informationen, die will ich eigentlich nicht im Image haben und die will ich auch nicht raus haben. Und last but not least, wenn ich jedes Layer mache, ich füge hier eine große Teil hinzu, ich lösche sie wieder und das ganze pack ich als mein Image und schiebe es raus. Das ist cool, das läuft auf meinem Entwicklungslaptop, der ist schnell, der kann das. Alles cool. Und jetzt, wenn ich das zum Beispiel so einem Kubernetes zum Beispiel laufen habe und dann bekomme mein Load Blender mit, oh, wir haben unsere CPU Auslastung getocht und oh, wir kriegen gerade richtig 12GB rein. Machen wir schnell noch ein paar Pots mehr hoch, ja, dann will es sich sein Images und will da raus Container bauen. Und je nachdem wie ich meine Caching-Struktur gebaut habe und ich habe meine Images zu dick gebaut, dann laden die einfach langsamer und dann braucht es auch die da sind und das kostet mich in der Skalierung. Das ist jetzt bei 2, 3, tut das noch nicht so weh, wenn ich aber plötzlich in der Situation bin, eben waren es hier noch so 5 mal, dass da aus meinem Image ein Container gebaut hat und jetzt soll das plötzlich 50 werden, ja, dann ist es, das tut noch nicht so weh, machen wir noch nur 0 dran, dann tut es langsam weh, wenn wir dazu dicke Images haben. Und damit haben wir nämlich auch gleich den nächsten Punkt. In diesem Image wird gebaut und dann das gleiche Ding geschippt und dann wird es wieder gebaut, vermutlich, weil der CMD-Befilm war relativ eindurch in die Richtung. Ich frage es jetzt aber, meine Entwicklungsumgebung, die brauche ich doch gar nicht komplett da, wo ich die pleue und es gibt eine schöne Standard-Lösung, die nennt sich Multi-Stage-Bild, machen wir auch gleich noch mal ein bisschen Hands-On und was ist der ganze Idee dahinter? Ich brauche meine ganze Entwicklungstools, mein ganzes Compiler, den brauche ich nicht da, wo das Ding am Ende läuft. Da brauche ich nur mein Verbindung, aber ich brauche mein Quellcode doch nicht am Ende da oben Deployed, außer aus meine Webseite dann vielleicht, aber selbst da wird ja ganz viel mit anderen Fernwirks rumgearbeitet. Und deshalb gucken wir jetzt einfach mal an, was das jetzt in der Praxis ist. Genau, was haben wir hier gemacht? Ich spiele jetzt hier mal gerade ein bisschen mit Portman, weil da gehen ein paar Dinge schön. Und weil ich natürlich total vergesslich bin, gebe ich mal kurz mal ein Specker aus. Wenn ihr hier alles wisst und das gesehen habt und sagt so, ja okay, ist nicht weiter spannend für euch, cool, könnt ihr jetzt abschalten, ansonsten ist da auch nicht viel Magie dahinter. Vielleicht erzähle ich noch ganz kurz, was sich da eigentlich hinter diesen Images passiert. Es gibt einmal dieses Do Nothing Image, das führt halt irgendwie einfach nur dieses wunderbar schöne Do Nothing Skript aus. Ich habe zum Beispiel in diesem Video als Base Image Ubuntu genommen, weil ganz viele Dinge da drin sind. Unter anderem es ist komplett ein Overkill für mein Newscales, aber skaliert nicht gut. Wir wollen ja Dinge machen, damit niemand besser machen könnte. Also genau, das gibt einfach nur unsere Umgebungswaben aus. Random Junk ist dann schon etwas spannender. Wir fangen wieder bei dem Ubuntu Image an. Okay, das Ubuntu Image da stand ein bisschen, ist tatsächlich auch gar nicht so gruselig. Also alles gut. Dann habe ich da irgendwie mal so ein Datei einfach zufallsgeneriert, just random, ja, der kopiert hier rein, löscht die, kopiert die, löscht die, kopiert die, löscht die. Ihr seht das Muster und am Endeffekt, damit ich auch irgendein Palo drin habe, damit das auch was zu tun hat, kopiert er, dann macht er den gleichen Spaß nochmal mit dem Copy, mit dem eigentlichen Tunics Skript und ja, danach führt das bitte einmal aus. Also wir sehen, hier machen wir ja ganz ganz viel eigentlich nichts. Was ist los? Wenn wir uns dann, müssen wir mal kurz gucken, ob ich sie jetzt alle schon gebaut habe. Genau. Sehr gut, ich habe ein nicht getaktes gebaut, aber dann bauen wir doch einfach mal den Random Junk. Random Junk. Genau. Bauen wir einmal das Random Junk. Und wir können jetzt bereits im Bauprozess sehen, wir legen jedes Mal ein, legen jetzt mal ein Cash an, der wird auch jedes Mal auf eine Leer gemapped und haben dann den ganzen Spaß durch. Und wenn wir uns jetzt angucken, was ist jetzt eigentlich in diesem ganzen Image, wo jetzt so richtig viel Output gekommen ist, den zu Beginn einer Masse, lauter komischen Nummern kurz, kann so kein Mensch verstehen, vielleicht ein paar Scholen, aber schwierig. Man, was war's? Ja, okay. Das coole Tool, Portman Diff, sagt mir gleich einmal so, Docker hat sowas auch in die anderen. Es gibt ja ganz viele, die entsprechende Tooling haben, ich nehme jetzt gerade noch mal Portman, weil irgendwie muss man nehmen. Am Endeffekt wird nur diese eine der Teil Do Nothing hinzugefügt, aber wenn ich jetzt auf das Image, ach ja, ich kann natürlich noch ausführen. Nein, das ist nicht mein Do Nothing, sondern mein Random Junk. Genau, wenn wir gucken, der tut nicht viel. Gucken wir hier, ja genau, wir haben jetzt gerade noch den, haben den gerade gestartet, alles coole, der tut nix, alles, alles so wie erwartet. So, sehr coole habe ich den, den kenn ich natürlich jetzt gerade noch nicht, weil tut mir jetzt auch nicht weh, genau. Das Problem ist natürlich jetzt, wir haben den, der laufen, der tut jetzt nicht viel, aber wenn wir jetzt uns angucken, was er da eigentlich tut, dann haben wir den, und da sehen wir jetzt irgendwie auch schon mehr von unserem ganzen Spaß, den wir da getan haben. Wir haben dieses ganze schöne Image, so hier sind wir, hier fangen wir an, das hat irgendwo eine Idee, und das fängt irgendwo an. Wir hatten ein paar lustige Umgebungsvariabeln, halt irgendwie Architektur, Version, Plan, alles so standard, und dann haben wir unser Datei-System. Und da ist jeder dieser schöne, ist einer dieser LAM Datei-System. Das, und das kostet mich einfach mal jedes Mal, wenn ich da gucke, ist da ein Fahrt da, muss ich jedes Mal durch alle Leute durchspringen. Und dann haben wir entsprechend hier die ganzen Label, und der gucken wir nochmal kurz in die Historie an, was ist da eigentlich passiert. Da steht, das gibt es das schöne Ding, created by, und dann gucken wir da durch und fest, ja, hier passiert sehr viel, genau das, wo eigentlich nichts passiert. Und könnte man das nicht irgendwie auch noch eleganter lösen? Ja, klar, wir können jetzt, wir, sehr schön, Historie ist gut. Eben haben wir es einfach so gebaut, haben nur das Portman-Bild getagt und haben gesagt, welchen Orte, und jetzt nehmen wir das Squash. Wir sehen einfach mal kurz den Vergleich. Wir sehen schon, ah, unser Bildprozess ist mal deutlich übersichtlicher. Wir kriegen nicht halb so viel Output. Warum? Wir bauen ganz, ganz, ganz viele Layern, gar nicht erst auf. Also, wir nehmen die und das passiert alles in einem Layer. Das coole ist, mein Dockerfall muss sich dafür überhaupt nicht anfassen. Und ich möchte ja nicht jedes Mal, wenn ich irgendwie das Software von wem bekomme und daraus mal schnell ein Image bauere. Und das sind vielleicht Dinge nicht ganz optimal gelaufen. Aber wenn ich das Dockerfall umschreibe, ist der Fehler jetzt bei mir entstanden, weil ich irgendwie zu dumm war, das Dockerfall umzuschreibe, habe ich mich vertippt. Nee, einfach Squash und bitte einmal alles flach machen. Das tut am Ende genau das, was man erwartet. Das drückt einmal die ganzen Layern ein Layer zusammen. Und hat natürlich jetzt auch, wenn ich das Ding dann deploye, diesen wunderbar schönen Netenreiz, es muss deutlich weniger tief durchgreifen. Und wenn man nämlich jetzt mal den Inspekt Inspekt ist, dann kann man da mal ein Lack gehen. Passiert jetzt war eine ganze Menge, aber wir haben jetzt immer diese nette Information. Auch übrigens ist es ein empty Layer, also da ist nichts passiert. Cool. Ja, damit haben wir eigentlich schon mal eine ganze Menge durch. Ja, dann können wir den gleichen Spaß nochmal im Multi-Statch bauen. Im Wesentlichen hier mit meinem, ich lege, ich füge Random Dateien hinzu, ich lösche sie wieder, füge sie hinzu, lösche sie wieder. Ist am Endeffekt das Ding, was so ziemlich wie der Bitprozess macht, da fallen irgendwelche Object-Dateien an, die werden dann später gelingt. Und am Ende fällt da vielleicht irgendwie ein feindliches binary in den Lipp oder was auch immer bei raus. Und vielleicht auch mehrere. Und dabei fällt ganz viel Zeug nebenbei raus. Oder ich nehme Pan-Doc und habe ein Lathech-Dokument. Da fallen ganz, ganz viele lustige Dateien bei raus, die ich am Ende gar nicht haben will. Aber ordentlich fallen sie halt mit raus. Jetzt habe ich das alles durch und sage dann, okay cool, dann nehme ich hier mein eines als Base-Image, ich habe jetzt beide mal Ubuntu genommen, weil das einfach total nichts tut, habe dann irgendwie aus meiner Entwicklungsumgebung, also diese Datei hier, kopiere ich mir dann hier einmal mein Image und hier ist dann der nächste Punkt so, ich kann das ja durchaus mit mehreren Bildimages bauen, ziehe es mir dann einmal raus und sage so, ach ja, von diesem Image, was wir hier oben als Base-Gelablet haben, kopiere mir mal bitte die Datei Do Nothing und leg sie mir mal bitte da ab und dann genau, sehr gut da hab, und genau, dann führen wir bitte einmal genau den Spast aus. So, gucken wir mal, ob wir das jetzt auch gebaut kriegen. Specker, den Multi-Stage, genau, unseren wunderbar ungeschickten Multi-Stage-Bild. Ach ja, eine Initiative wäre, die auch mit Tweet-Aus geht, wir können ihn ja erst mal bauen lassen im Hintergrund, wir sehen, er baut jedes Mal super Fett, und das ist das Problem, wenn ihr jetzt ja mal das Dockerfall schreibt, ihr wisst nicht, mit welchen Parameter Leute euch später aufrufen, aber auf diese Art und Weise könnt ihr dann sich ausstellen, dass, wenn man jetzt nochmal unser es anschaut, dass es wieder wunderbar sehr viel nichts passiert, also genau das, was ihr wollt. Ihr könnt natürlich auch nochmal mit Tweet drauf gucken, also Baller Ah, Image vergessen. Dann gehen wir das Spiel nochmal so umdurch. Baller, gehen wir einfach mal so um rein. Also ja, wir sehen, wir gehen jetzt einfach nur mal kurz durch den ganzen Befehl durch. Das ist nämlich nochmal ein Tick, wie von der Visualität finde ich sogar netter, ich ah, ok, wir haben irgendwie, das ist. Da haben wir jetzt nichts gesquorst und gar nichts. Wir können's auch nochmal gleich mit Squash machen, dann sehen wir, okay, wir kriegen da jetzt nämlich das Layer noch weg und haben dann das ganze, aber dann unser ganzes Spaß, den wir danach gemacht haben, einfach nur in einem Layer rübergezogen. Cool. Es ist ja so gesehen auch nicht so. Also, alles kein Hexenwerk, alles steht alles in der Doku, wenn man aber die Repositories sich anguckt, die einem so insoweit über den Weg laufen, dachte ich, es tut mir nicht weh, das auch nochmal mal gesehen zu haben. Und natürlich können wir auch dieses wunderbar Schöne noch auch mit beliebigen vielen bauen. Man kann aus mehreren bauen. Können wir jetzt durchspielen, aber ich glaube das Konzept bleibt verstanden. Zieht euch die Dinger zusammen, setzt sie rein. Okay, anscheinend keine Zeit. Und damit ist die Frage so, okay, jetzt haben wir da irgendwie unser lustiger Stockerfall gebaut und haben jetzt teilweise noch gesquorst und was sind jetzt unsere Gewinne, die wir haben? Ja, unsere paar Ressourcen, die wir haben, wenn wir so ein Ding betreiben, es spart uns CPU. Ja, jedes Mal ist es nicht die Welt, aber in der Summe kommt ein bisschen was zusammen. Wir sparen uns CPU, weil du musst nicht einmal durch alle, ich glaube ich bin gerade erstaunt. Wir sparen uns einmal den CPU, wir sparen uns die Logups durch den Speicher, unser ganzes Image wird schmaler, wenn wir irgendwo eine Container Registry haben, müssen wir die irgendwie auch hinpacken. Und Startup Time, das ist die Ressource, die uns in der Praxis, da ist es meistens, oh warum starten meine Images so langsam. Da kann ganz, ganz viele Dinge sein, man kann vielleicht irgendwelche komischen Initialisierungen zur Startup-Zeit machen, die man vielleicht schon vorher in auch eine Bildstage-Kette gemacht haben können und das dann einfach so als fertiges Artifakt nehmen. Aber die Tatsache, dass man ein sehr, sehr dickes Image hat, was einfach sehr lange braucht von der einen, da wo ich meine Images gelagert habe, zu da wo ich sie betreibe und dieser Transfer braucht lange oder zu lange, ist eigentlich ein Problem. Und das kriegen wir so alles nebenbei raus. Und natürlich sparen sie nebenbei auch noch ein bisschen Arbeitsspeicher. Was haben wir nicht gelöst? Wie sieht man das mit den Updates aus? Ich habe da basiert auf einem Ubuntu 15 noch was, wir sind momentan glaube ich bei 22 noch was. Ja, wie kriegen wir jetzt damit, wie kriegen wir das eigentlich mit den Updates rein? Trauerinfos? Ne, unser Dockerfile allein wird uns hier nicht retten. Denn da kommen wir jetzt ein bisschen in die Ecke der Automatisierung davon. Ist da wirklich nur das drin, was reingehört? Viel zu häufig findet man in irgendeinem Docker-Image Daten, die eigentlich nicht, also in diesem OCI-Container-Image findet man dann Daten, die da eigentlich nichts drin verloren haben. Warum? Ja, weil da wurde einmal Copy, Sternchen und einmal rein das Ding. Ja, man hat alle relative Daten drin, aber gerne auch mal Dinge, die man nicht braucht. Mein Jackpot war ich, meine persönliche History von wem gefunden habe in so einem Image. Ja, passiert immer keinem, außer wenn es dann doch mal passiert ist, ein Dockerfile zu pflegen ist mal ganz freundlich. Lifecycle Management, ja, ist schmerzhaft, ist nervig, ist nicht bequem, geht nicht schnell, aber ist ein Problem. Ja, und dann noch so die beiden Dinge, die am häufigsten über die Füße rennen, Caches und Pipeline. Zu den beiden kommen wir jetzt auch nochmal ein bisschen. Caches, haben zwei Fälle von Caches. Zunächst einmal die, den Art von Cache. Cool, ihr habt jetzt alles in eurer Pipeline, sagen wir einen Jenkins, einen Dirtlab Jobs, was auch immer, und baut da jetzt ganz in eure Artifakte und ladet die dann rein in eure Layer. Vielleicht habt ihr aber noch das Problem, irgendwie gibt es ja ja noch so Repository Checkout, was da alles so passiert und so eine Bilder zu bauen, das kostet Ressourcen. Also überlegen sich Leute, wie machen sie das effizient? Ah, man können ja diese Runner, die da irgendwie mein Repository auschecken und sich, vielleicht sind das die Repository ja auch nicht Publix, sondern Private, also muss man es gehen, die non-authentifizieren und automatisieren das ein bisschen und man kann hier ein bisschen recyceln. Ja, ist eine gute Idee. Es fängt an, wir zu tun, wenn hier ist mein lustiger Bild-Server und dieser Bild-Server hat seine Worker und die stehen hier alle hier und die laufen los und die cashen sich mal, was sie vom Vorliegen laufen. Und er hat eine Antwort und eine andere Applikation gebaut. Ja, und diese Teile werden dann irgendwie, weil die Worker schlecht passen und weiß der Geier was, laufen die plötzlich mit auf diesem Image drauf und dann habe ich plötzlich den Effekt, ich habe mein Runner, der hier ist, der noch zu meinem Projekt überhaupt nicht zugehörige Sachen hat und die liegen dann dummerweise auf irgendwelchen Obskullen umwegen mit in meinem Image. Jetzt ist mein Image vielleicht irgendwelche Dinge, das vielleicht Dinge ins Netz boostet, Daten bereitstellt weiß der Geier und plötzlich haben wir von einem komplett anderen Projekt irgendwelche Artefakte mit ausgeliefert. Hat mit meinem Projekt aber nichts zu tun, jetzt bin ich zu oft drüber gestolpert, guckt mal was eure Worker da tun und wenn nicht putzt mal bevor ihr anfängt zu bauen. So im Image, im Image wir haben so eine Dinge wie Hey, Pippen, Store, so ein, oh das ist ein Ubuntu-basierendes Package. Lass uns mal kurz noch eine ordentliche Software drin installieren. Warum das so rum? Warum? Und dabei entstehen dann lustige Caches und seht mal zu, dass ihr die Caches wegkriegt, dass ihr die Caches putzt und dass ihr das dann vielleicht auch Mux in einem Step macht, weil so eine klassische Paketverwaltung, ganz ganz ganz viele Cache-Stänge nebenbei tut, die einfach wieder eure Image aufbläht und das hat für die Anwendung, die ihr machen wollt, genau gar nichts zu tun und diese Caches sind wichtig, wenn ihr das öfters ausführt, aber in eurem Image wird das bitte nie wieder ausgeführt. Also, der geht einig ist ein bisschen schlanker. Ja, genau. Den Squash hatten wir jetzt gerade schon mal und der Docker ist dann mit Experimentale gelabelt. Portman hat auch noch dieses wunderbare, schöne Squash All Feature. Ja gut, aber jetzt nehme ich ja nicht Portman und so jedes Mal und möchte es ja irgendwie auch ein bisschen automatisieren und will ja auch gerne so ein automatisiertes Feedback bekommen, wenn ich so, hey übrigens, da laufen Dinge nicht ganz so cool. Und hey, du hast einen Dockerfile und dir ist klar, dass du das gerade als Routener zustande misst laufen lässt. Die Demo-Beispiele eben, wir haben alle aufgepasst. Es gab niemals ein User, das lief immer mit den Rechten, die mir die Container Engine gerade eingeräumt hat, war Portman also mit meinen lokalen Nutzerrechten. Ja, wir können zum Einmal mit dem Slim Toolkit, ich mache es ganz gerne, können wir einmal den gelinden und das Schöne ist natürlich, wir können das Ding einmal statisch machen, da fallen uns dann so eine Sache raus und das andere ist aber auch, das kann auch dynamisch und jetzt haben sie das eine wunderbar schöne Seite gebaut, wo sie zeigen, wie das jetzt eigentlich da tut und genau, darüber wollte ich auch einmal durchsetzen. Im Wesentlichen, ich habe gerade Portman Bild genommen, du nimmst den Slim als Bild, du setzt ein Target, also nimmst die gleiche Konzentration wie sonst auch, nimmst irgendwie mein Frontofeld da, mein Image rein, dann setzt es eine ganze Menge Telemetrie hintran, viel Observabilityzeug und fängt dann mit dem Sache an zu sagen, okay cool, jetzt kriegt der Container, also just a coffee, in dem Fall halt Arbeitsspeicher RAM und ein bisschen Umgebungsvariablen und jetzt bewerfen wir das Ding einfach mal, kann man noch ein bisschen fine tune, ist noch ein bisschen was möglich und dabei fallen dann so eine Dinge bei raus, wie ja übrigens, du hattest da irgendwie ein Zertifikat drin gehabt und warum hast du das Zertifikat eigentlich in das Image gepackt, aber vor allen Dingen dein Zertifikat ist abgelaufen oder dein Zertifikat hat irgendwie noch so ein Standard, den du eigentlich nicht mehr haben willst oder warum zur Hölle hast du eigentlich auf deinem Image eine vollwertige Shell laufen, weil du willst eigentlich nur dieses eine Binary da laufen lassen, brauchst du keine volle Shell, macht dabei eine ganze Menge Dinge, die man so da gerne mag, so es guckt mal so, auf welche Teilen wurden eigentlich zugegriffen, habe ich vielleicht da Teilen reinkupiert, die ich gar nicht brauche, Klassiker, ich habe dazu viel reinkupiert in mein Image, dann kann ich überlegen so, ah ok, der Test hat es einfach nicht abgedeckt, alles cool oder oh nee Misty, da wollte ich ja wirklich nicht da drin haben, ja meine Docuik nur kann mir dann Update bekommen. Dann so eine Frage, was für eine Syscoids macht das Ding und natürlich, was da dann noch so unten rum dran hängt, genau und dann bietet es mir auch gleich an, hey, baum ich daraus doch gleich ein angepasstes Image und wofür ich es gerne mag, wer hat schon mal versucht einen App Amore Profil zu schreiben, wer ist daran gescheitert, weil so ein App Amore Profil ist cool, ist der richtige Weg, Leute macht das, aber es ist super nervig und man tut sich so toll wie dabei, ja die Docu ist gar nicht mal so schlecht, aber es ist halt am Endeffekt, es hat eine Komplexität und alle Tools, die mir da helfen, Dinge vor zu generieren, habe ich gerne, Slimtut bietet mir genau das an, funktioniert tatsächlich ganz gut und damit haben wir nämlich, sind wir nämlich auch schon so ganz diskret reingeswitched in dem Bereich, ja wir haben ja Scanner und Slim ist jetzt mehr so wie mache ich meinen Image, das klein, ja gut, dann haben wir aber noch das andere Problem mit, ich bau da was rein, ich lade vielleicht auch mein Image vielleicht bau ich basierend auf Images, die andere Leute gebaut haben und da haben wir einfach immer mal relativ schnell irgendwelche lustigen, sehr halt Spezialitäten, die wir vielleicht nicht unbedingt haben wollen, wir haben so eine Dinge wie, hey unser Betriebssystem oder unser Engine X hat eine bekannte Macke, es gibt dafür CVS, wir haben da irgendwelche Secrets reingeworfen oder was vielleicht auch manchmal relevant ist, wir nutzen dabei ordentliche Lizenzschlüssel gerade, wenn wir was von dem Anderes nehmen, Exposen wir die ein bisschen weiter, als wir eigentlich wollen, Pressmarclaw gibt ganz ganz viele, 12 von Aqua Security hat einfach den Vorteil, das Repository ist public, man kann, du kannst das Ding selbst bauen, es ist glaube ich auf dem Docker Hub, es ist glaube ich auch mit drauf und das ist im Wesentlichen einfach so ein kleiner Baustein meiner Pipeline, der mir natürlich spart er mir nicht, ich muss immer weiter noch mitdenken, aber es fängt mir so ein paar Standardfehler ab, die gerne mal passieren oder auch, damit sind wir wieder beim Thema Pipeline, cool, letzte Woche war mein Image alles cool, jetzt kommt aber leider, ja ob es da gibt es einen neuen CVE, da es eine gibt es eine Schwachstelle oder gibt es eine neue Version, ich sollte vielleicht auf die Updaten, wer guckt jedes Mal in seine ganzen Abhängigkeiten, nicht viele, in Bildumgebungen gibt es das tatsächlich ganz viel, das ist so klein, nicht uns, meine Makeumgebung, im Java-Umfeld ist das sehr gängig, die dann gucken, oh mein Dependency Checker, und wovon hängt das ab, habe ich beim Node.js, habe ich beim Java, habe ich beim Go und ja das ganze kann ich natürlich auch mal spielen und das Tooling dafür lohnt sich dadurch aus dem Anzug gucken, wenn ich mein Pipeline habe und dann läuft die vielleicht automatisch alle einmal am Tag durch und dann bekomme ich zumindest am nächsten Tag, hey übrigens du willst dir dein altes Package, ja du arbeitest da gerade nicht dran, aber das hat da eine CVE Potenzial, guck mal drauf, schauen wir, ob es für dich relevant ist, vielleicht willst du dir gerade mal updaten, ist eine nette Erinnerung, weil wenn ich an einem Projekt bin, das habe ich im Blick, ich habe aber nicht mehr im Blick, was ich vor einem Voteljahr gemacht habe, das ist sehr nett, wenn dann so eine Pipeline plötzlich rot wird und sagt so, hey du mach mal Update, ich habe da so eine komische Verhaltedabhängigkeit, was ich denn damit mache ist meine Verantwortung, aber zumindest ist mitbekommen für mich schon ganz nett, ja boah es ist aber eine ganze Menge hier, ich wollte doch nur mal schnell einfach schnell das bauen und in den Container mit dir jetzt da drüben auch betreiben könnt, ja es war so, Infrastruktur geht nicht ohne und wenn man sagt so ja gut, okay schon, aber auch nicht zu viel Aufwand, vielleicht habe ich hier auch irgendwie ein Unternehmen, die auch so die Dinge tun und dann gibt es ja irgendwie so eine Priorisierung und so, was soll schon schief gehen, nutze auch eh keiner. Auf der Easterhack haben Menschen einen sehr, sehr tollen Vortrag Dokabugbau und die Erlebnisse gebracht, wo sie im Wesentlichen eins gemacht haben, sie haben die Public Repositories genommen, als ich glaube sie sind nur auf Docker Hub, sind sie glaube ich sogar nur durchgegangen und haben einfach mal die Images sich gezogen und einfach mal noch so Sachen geguckt wie hey was ist eigentlich, liegen da irgendwelche Credentials für auch zum Cloud Provider drin, liegen auch irgendwie Passwort Dateien drin, SSH Keys und dann haben die es eigentlich gar nicht so lange laufen lassen und haben damit eine sehr lustige Anzahl an Backbounties mit einsammeln können und zu den Backbounties kommt entsprechend großer Teil, wo es keine Backbounties gab, sondern ja Videos verlinkt, Folien landen auch gleich noch online, könnt ihr also dann selber angucken oder guckt einfach Easterhack unter dem Titel habt ihr es auch, also ja es tut weh wenn man es nicht macht, ja es ist nicht schön, aber putzt eure Pipeline und damit würde ich sagen, danke für die Aufmerksamkeit und Fragen, Fehler, Korrekturen, her damit.