¶ Intro Docker, Containerisierung und Microservices
Herzlich willkommen zu Folge 68 von einfach komplex. Hier ist Gerrit und Bockert ist auch da. Hallo Burkhard. Und ihr lieben Hallo. Unser Thema ist heute dokka und nicht einfach nur mal erklären. Ja, was Docca ist. So ein bisschen haben wir das schon mal gemacht in einer in einer älteren Folge vielleicht. Bock hat gleich ein kleines Re Cup, aber Burkhard will uns heute mal erklären, wie man locker tatsächlich einsetzen
kann. Ja es ist trotzdem nicht nur für Entwickler glaube ich es ist glaube ich für alle ganz spannend mal zu. Wissen, was es so für Herausforderungen da gibt, was es eigentlich bedeutet, wenn jemand sagt, Ich nutze mal eben Docker so, aber ich glaube, es ist sogar auch ein bisschen was für Leute dabei, die das dann wirklich mal machen wollen. So habe ich verstanden,
Burkhard, ist das richtig. Ja genau richtig, Gerrit, weil ja, also es gibt so viel Docker hier, dokada, Microservices und so weiter es gibt viele Artikel und so und viel bleibt halt irgendwie an der Oberfläche und ich hatte irgendwie das Gefühl, dass wir versuchen, wirklich mal ein Stück tiefer zu gehen dann. Wird es auch gleich schon harter Tobak, sage ich mal. Und heute wird auch die Folge vielleicht ein bisschen härterer Tobak als so manch andere Folge. Aber macht ja nichts.
Aber ich will halt mal versuchen durchzukommen. Ja, durch diese wichtigen, ja durch diese sehr wichtigen Konzepte, und das hat mich auch, ich will auch n bisschen aus der aus dem Nähkästchen plaudern, weil ich auch sehr lange gebraucht hab, um um mir das Docker so zu biegen und so zu verstehen. Bies gut einsetzen kann.
Ja, es ist weil Doccar ist halt n Fundament der modernen Software Architektur, aber es ist gar nicht so glasklar wie man es einsetzt, gibt also nicht so richtig krasse Best Practices. Weil aber auch die ganzen Anwendungen sehr unterschiedlich sind, man kann es sehr, sehr unterschiedlich in verschiedene Arten einsetzen, ne und heute gucken wir das mal so n bisschen an, wie wir es benutzen, weil wie gesagt, es ist so unterschiedlich, dass ich gar
nicht über alle, erstens nicht über alle Kombinatoriken des Einsetzens sprechen kann. Und zweitens von da auch nicht in der Tiefe, die Ahnung hab ja deswegen n kleiner Disclaimer, bisschen Nähkästchen geplaudern so n bisschen so wie wir es machen oder wie ich es quasi machen würde bei anderen Projekten auch. Oh da versuchen wir mal durchzukommen, ne? Ne gute Grundlage könnte wahrscheinlich auch noch Folge 2 sein oder ne Anschlussfolge, die
man sich noch mal anhört, ne? Genau in Folge 2 schon ein bisschen her. Haben wir tatsächlich einmal über Microservices im Großen und Ganzen geredet, die würde ich jetzt für alle, die jetzt irgendwie Docker das erste Mal hören, würde ich sagen, auf jeden Fall mal kurz folge 2. Vielleicht auch auf 1,5, Speed oder Irgendsowas hören. Und dann diese Folge, die baut schon jetzt noch drauf auf.
Ja also ich mach ein kleines Recape gleich, aber wir wollen ein bisschen tiefer gehen als wir in Folge 2 waren. Ja, dann möchtest du damit starten mit diesem RE Cup und nochmal kurz ausholen oder uns erläutern was so Microservices eigentlich sind und wie Docker damit zusammenhängen.
Machen wir also einmal vorweg, gesagt, Docker, das ist halt die Containerierungstechnologie, das haben wahrscheinlich schon viele gehört, wenn man Docker sagt, dann spricht man eigentlich nur vom Viertel der Aufgabe. Vielleicht noch weniger.
Es ist zwar das das erste Fundament, was ich brauche, ich muss erstmal Container erschaffen, was die gleich sind sag ich noch, aber viel wichtiger ist das gleich vorweg ist später das Nutzen der Container, ich hab es nie mit einem Container zu tun ne das ist das wäre paradox ja das ist drauf angelegt, dass ich mit vielen Containern gleichzeitig arbeite, wenn ich eine größere Anwendung habe, vor allen Dingen Webanwendungen, dann habe ich halt das nicht in einem
Container, sondern typischerweise in vielen. Und hier ist, wo der Hase im Pfeffer liegt, ist nämlich die Orchestrierung dieser Container. Weil. Im Prinzip, Jeder Container Kapselt quasi eine Anwendung. Wenn du möchtest. Einen logischen Aspekt einer Gesamtanwendung. Die hat aus vielen kleinen Anwendungen besteht Microservices.
Genau so ist der Fachbegriff richtig und dadurch entsteht halt schon was sehr komplexes, weil das gleich ein wichtiger Punkt am Anfang diese diese Anwendung, diese Microservices die ergeben, wenn du mehrere hast sofort einen verteiltes System wieder Informatiker sagt ja, ein verteiltes System ist halt ein System was Komponenten in einem Netzwerk zur Verfügung
stellt. Wo ich ständig netzwerkaufrufe brauche, um Logiken oder Teile von Logiken zu benutzen, in meiner Gesamtanwendung ja, dadurch wird das sofort auf ne ganz andere Komplexitätsebene gehoben, als wenn ich jetzt zum Beispiel so altertümlich irgendwie so ne.
Ja, so n Monolithen monolithische Anwendung, hab ja das hab ich in Folge 2 auch gesagt, dann hab ich quasi vom Programmieren her n ganz anderen Stil, dann hab ich quasi Bibliotheken und Abhängigkeiten direkt um mich rum und ich brauch keine remote Calls machen, ich brauch keine rest Apis ansprechen, ich muss nicht über RPC Protokolle oder Irgendsowas nachdenken weil es nicht Netzwerk ist.
Was dazwischen ist. Aber immer wenn wir Docker sprechen, dann haben wir das Problem der Orchestrierung ja
das ist wichtig, ja also. Wie spiele ich mit der Gesamtheit dieser Container später rum und alles was dieses Docker dann auch ausmacht, diese ganze Sachen mit Skalierung, pro Verfügbarkeit und so weiter das hat alles was damit zu tun, dass ich auch noch dynamisch quasi diese Container vermehre, verkleinere und so weiter und dadurch wird das wird diese Orchestrierungsaufgabe eines der wichtigsten Aufgaben, sag ich mal und jetzt vorweg, um uns um uns festzulegen, es gibt
Orchestratoren. Für diese Container, was die sind, sage ich gleich noch mal schnell, aber ich sag mal kurz die Orchestratoren vorneweg. Docker kommt mit dem sogenannten Docker Compose. Und das ist das, wo wir heute drüber sprechen wollen. Das ist so das erste, was man nehmen kann, weil es halt auch quasi irgendwie zu zu Docker, zur Dockertechnologie gehört und eingebaut ist.
Dann gibt es noch das Swarm und dann gibt es noch so Sachen wie Portainer und und vor allen Dingen das Kybernetik, das hat dann vielleicht schon viele Leute gehört, Kybernetik ist quasi so die dickste Kanone der Orchestrierung, die man benutzen kann, aber das lassen wir heute alles mal weg und sprechen nur über Compose als. Orchestrator. Magst du noch kurz sagen, woher Docker eigentlich kommt?
Also war das einfach, da gibt es auch wieder ein Open Source Projekt oder steht da eine Firma hinter? Es gibt eine Community Edition von Docers, also Open Source
Benutzer muss nichts zahlen. Ich weiß jetzt nicht die Historie gerade nicht, vielleicht weißt du es, ich weiß nur, dass es quasi eine Weiterentwicklung oder einen Überbau von von etwas, was schon immer da war, nämlich vom Linux Kernel, der hat sogenannte Features, das sind die Namespaces und die Control Groups für die Techies jetzt und. Aus diesen Möglichkeiten des Kernels hat man quasi diese Kontinuisierung gebaut.
Und was ist Kontinuierierung? Es ist Prinzip nichts anderes als ne Gekapselte, sehr leicht gewichtige virtuelle Umgebung, also man kann es sich vorstellen wie ne wie n virtuelles Betriebssystem, nur viel leichter als sowas wie Virtual Box oder sowas. Du kennst das ne, also wenn du so ein ganzes System nimmst, es startet unglaublich schnell und du kannst es stoppen und durch diese kontinuierisierung kannst du quasi kleine Linux Systeme im Prinzip jeglicher Distribution.
In so einem Container. Quasi vorhalten und auch dir die so hin installieren oder erweitern. Also das Betriebssystem quasi was wieso ein kleines Mini Betriebssystem Linux pro Container und das ist völlig unabhängig von deinem Wirtssystem und von den anderen Containern. Ja es läuft also es ist wie eine kleine virtuelle Umgebung, kann aber so klein sein wie nur 3040 Megabyte wenn es ausführt, also ist nicht irgendwie so hier wenn
du Windows 11 hast. Ich weiß nicht, was das im Moment braucht an der Platte. Also da hast du 2 Gigabyte. Schon im Arbeitsspeicher stehen und Festplatte wollen wir gar nicht von reden, aber das ist halt halt vielleicht wichtiger. Ja und dadurch bekommst du Sicherheit und Unabhängigkeit diese Komponenten rein ne. Pass auf, dann sag ich dir das noch kurz, wo es herkommt und zwar oder wann.
Wann ist den ersten Commit im entsprechenden Repository gab, das war 2013 von der Dot Cloud Ink, also eine amerikanische Firma, die sich dann im gleichen Jahr noch auch in die Docker Ink umgetauft hat. Ja und? Wie du schon sagst, es gibt dann diese Community Edition und du kannst natürlich aber auch die Docker Ink bezahlen für entsprechende Services rundherum. Genau wie es oft so ist, macht ja auch Sinn.
Und dann war es zuerst zum Einsatz bei Redhead Red hat Linux, was ja quasi in ein bezahltes professionelles Linux ist, wenn man so will und Enterprise Linux und dann weiter brauche ich jetzt nicht gehen. Ich zitiere jetzt auch noch Wikipedia, aber dann haben wir das noch mal kurz geklärt. Ja, danke, Gerhard, Das ist nochmal auf dem Zettel hattest. Ich habe mich heute für die für die technische Roni Methoden entschieden. Das vorzubereiten, das war jetzt auch mein Beitrag. Quasi.
¶ Docker Features & Konzepte
Alles klar, pass auf, dann erzähl ich noch mal kurz die wichtigsten, die wichtigsten Features, quasi um Docker jetzt selber mal rum, da gibt es das sogenannte Konzept eines Images und eines Containers, ich wiederhole ich noch mal. Schnell haben wir in Folge 2 auch aufgearbeitet, das Image ist im Prinzip so eine Art Blaupause oder ein Template für ein bestimmt aussehendes virtuelles System.
Ich könnte zum Beispiel sagen, ich habe ein Image von einem von einem Debian Linux System, worauf ich dann irgendwie noch spezieller Abhängigkeiten installiert habe, zum Beispiel Tensor Flow von Google oder irgend sowas. Und bereite mir das System vor und kann da quasi Sachen reinkopieren. Auch meine zum Beispiel meine Anwendung oder bestimmte Skripte oder Irgendsowas und dann ist so n Image quasi fertig und dann kann ich, wenn ich das Image quasi ausführe, dann wird sofort n Container.
Ja das Image ist immer nur ne statisches abgeschlossenes festes Ding, ein Template und wenn ich es anfange auszuführen wird das quasi ein Container und mit Leben erweckt, so als würde ich den Computer anschalten, der auf der dieses Betriebssystem quasi vorinstalliert hat mit. Den ganzen Sachen, die ich im Image festgehalten habe, quasi vorbereitet. Und den mache ich dann quasi einfach an und ich könnte aber
ganz viele Rechner anmachen. Also ich kann dieses Image mehrfach instanzieren sage ich mal. Also mehrfache Container machen, die sehen dann innen drinne alle exakt gleich aus und hab halt aber immer genau das gleiche Setting drumherum, das nennt sich dann der Container ich für Leute, die Objektorientiertes programmieren kennen, dann mache ich immer gerne diese Analogie, Image und Container verhält sich so wie Klasse und Instanz oder Klasse und Objekte.
In der Klasse definiere ich alles hin. Was passiert beim beim Errichten der Klasse? Welche Methoden hab ich und so weiter was soll ich zur Verfügung? Das ist quasi das Image und ne Instanz quasi, die ist quasi ein lebendes Abbild dieser dieses Templates und kann sich dann auch verändern über die Zeit.
Ja das ist so auch beim Container, ich kann mit dem Container richtig arbeiten, die Anwendung, ich kann, da können Daten geschrieben werden, es kann ne Datenbank da drin sein, die kann sich füllen und so weiter wenn ich aber nichts mache, dann ist alles was du getan hast bleibt im Container sage ich mal. Ja so ein bisschen wie auf der Party sagt alles was irgendwie was da passiert.
Ist bleibt da irgendwie. Das wird alles wieder mit abgeräumt so ja, also da bleibt nichts übrig, ja keiner weiß mehr was da passiert ist. Also was blöd ist ja normal. Also im Produktivbetrieb ist das nicht was du möchtest.
Wenn du in der Datenbank was reinschreibst und Leute irgendwie was mit deinem Webservice interagiert haben und du machst das quasi aus den Container, was eine normale Sache ist, weil wenn du ein Upgrade haben willst, dann lass dir quasi eine neue Version von deinem Quellcode da drinne. Ja und wenn du dann nichts machst, dann wäre alles weg und dann fängst du wieder bei 0 an. Das ist nicht, was man will und das führt mich zum zweiten Konzept.
Das zweite wichtige Konzept. Nicht neben Image und Container ist das sogenannte Volume. Ja, und hier ist das erste Mal, wo wir quasi die Grenze zwischen ich hab ja gesagt, ist alles gekapselt ne und Unabhängigkeit haben wir da, aber das Volume führt dazu, dass ich quasi Daten.
Es gibt 2 Arten von Volumes. Ich nenn das gleich, aber erstmal ist es so, dass ich quasi Daten persistieren kann, also speichere außerhalb des Containers und zwar auf dem Host. US sagt man immer, also auf dem außenliegenden Betriebssystem was drumherum ist. Was dir quasi das Dockersystem laufen lässt. Darauf wird dann quasi werden dann Daten gespeichert und in den Container gemountet sag ich mal, der Container kann quasi über diese Containergrenze hinaus.
Live lesend und schreibend, je nachdem, man kann es aufzwingen, dass es nur lesen kann oder irgend sowas, aber typischerweise kann es einfach lesend und schreibend auf das außenliegende System zugreifen, um Daten zu sichern.
Damit kann ich erreichen, dass ich den Container ausschalten kann und wieder anschalten kann und dann guckt er quasi auf diese vorher gesicherten Daten und kann zum Beispiel seine Datenbank wiederherstellen, damit kann ich quasi dafür sorgen, dass ich bestimmte Daten nicht verlieren will oder verliere, die ich nicht verlieren möchte.
Das heißt aber quasi, wenn man den aufstellt, wäre so eine Datenbank auch wieder leer und der kann sich nur die kann sich nur wieder füllen, in dem man nach dem Neustart. Das Volume guckt und sich die Daten wiederholt. Ne, das passiert dann automatisch ist wieso n Mount? Du kannst dir das vorstellen, du manchmal kennt man das im im im im Windows ne wenn du im Explorer quasi so ne Art ja es gibt zusammenbauen oder irgendsowas ne, da sagst du quasi ich hab n netzwerklaufwerk ja.
Und das ist sofort immer da. Ja, und das ist genauso funktioniert es n Docker, du sagst halt bestimmte tatsächlich, also wenn du so n so n bind Mount jetzt fühlt mich das dazu, du kannst halt sagen ich beziehe mich auf n ganz bestimmten Ordner, zum Beispiel in dem außenliegenden File System. Ja und wenn ich den Docker Container anmache, dann ist sofort das da drinne was außen anliegt ja und es ist tatsächlich sogar wenn du so ein
Pfeil im Mount nennt sich das also ein File Volume quasi hast, dann ist es sogar so, dass wenn du außen manipulierst innen sofort auch geändert ist ist war Spiegel ja, also der Container guckt quasi auf einen auf eine bestimmte Datei oder einen Ordner. Ja wo Dateien drin sind, in deinem Fall System des Außenlicht, ja ist nachher noch ganz wichtig oder aber du hast quasi einfach nur wirklich nen nen nen Datenhalde das sind die named Volumes, da willst du
nicht sagen das liegt in einem bestimmten Ordner, in meinem Fall System sondern du willst einfach nur sagen hier liegt quasi ein benahmtes Volume, auf meinem Fall System wo ich nie reingucke eigentlich und das ist einfach ein Datenspeicher typischer Anwendungsfall deine Daten.
Also wenn wir ne Postgres haben, dann guckt man typischerweise in der Post Quest wo speichert die Post Quest tatsächlich ihre Daten und dann würde man quasi sagen, OK, diesen Speicherort der Daten daraus machst du n benahm des Volume zum Beispiel Database, kannst du es einfach nennen. Ja das ist n Volume im sagst du dann im Container und wenn dann die Datenbank agiert und schreibt dann tut sie das eigentlich in dieses Benahmte Volume rein, was außerhalb des
Containers liegt. Wenn du den Container neu startest, dann ist quasi die Datenbank da musst du eine Abfragelogik haben, das kann ja sein, denn der Container ganz am Anfang. Nicht also musst du irgendwie diesen if haben, wenn ich noch nie ne Datenbank hatte, dann setzt die auf und Fang an das in dieses Volume zu speichern oder aber wenn ich halt jetzt irgendwie die Datenbank schon hatte was man sieht wenn man auf dieses Volume guckt ja sieht man
ja OK ich hab schon hier n Datenbanken Tabellen dann ist es halt einfach da ja Punkt so das ist wichtig also datenpersistenz erreiche ich über Volumes und dann haben wir noch eine wichtige und es gibt noch viel mehr Konzepte ich hab nur die wichtigsten rausgepickt das Netzwerk. Ich hatte ja gesagt, wenn wir, wenn wir so eine Horde von Microservices haben, dann ist es wie ein verteiltes System.
Das ist auch wirklich, und es heißt, wirkliche Netzwerkarchitekturen greifen in der Welt über Microservices hinweg. Wir hatten zum Beispiel auch schon eine Folge, wo ging es um Netzwerksegmentierung als Sicherheit, zum Beispiel, wenn du, wenn du ein shopfloor Netzwerk in einer Firma hast, dann kannst du in verschiedene Unternetze verteilen und so weiter das kannst du alles mit Microservices auch machen. Du kannst quasi also den einzelnen Containern, wenn sie dann ausführen, ein Netzwerk
zuweisen, in dem sie ausführen. Und damit kannst du es bestimmt Container. Ausschließen oder Einschließen in einer Kommunikation mit anderen Containern in diesem microservice Netzwerk, das hat viel mit Sicherheit zu tun, weil oft hast du was weiß ich 4567 10 Container und es müssen nicht alle miteinander sprechen, ja zum Beispiel. Die Datenbank nur mit einem All Service sprechen oder irgendwas Database hast. Dann packst du nur die in n Netzwerk und die anderen kommen n anderes Netzwerk.
Ja so machst du n Netzwerksegmentierung ne das kannst du aber alles ist alles virtuell quasi über diese Orchestratoren dann geregelt weil ich schon vorher gesprochen hab. So, und das ist als Recap, würde ich sagen, reicht es erstmal und dann gucken wir uns gleich n bisschen tiefer an was los ist. Hab ich das? Richtig verstanden, dass man auf jeden Fall einen Orchestrator benötigt. Du kannst nicht ohne orchestrator Docker benutzen oder es macht dann zumindest wenig Sinn. Ich würde das so.
Ich würde das bejahen. Ja, also kannst du wahrscheinlich mit mit Docker run also aber das macht keiner. Ja also also du kannst also zum Spaß wenn du es anguckst. Es gibt diesen Dockerbefehl, das muss man mal sagen, es gibt da so ne Kommandozeile, gibt es quasi den den Docker. Ne, nur Docker eingibst und hast ne ganze Sorte von Befehlen.
Die sind aber meistens nur dafür da Container, also Images zum Beispiel zu erstellen, ja oder in einen einzelnen Container reinzuschauen und so weiter und sofort ja. Wenn du ne Anwendung hast, bist du immer im Augustator unterwegs. Ja, und das ist zum Beispiel Docker Composer genau. Ja, den nehmen wir auch, oder? Wir nehmen Docker compose ja genau, es gibt viele, die die bei uns vielleicht schon dann in einer Richtung Kybernetik greifen würden. Ich sag ja immer, gibt es think
simple as you can, es dauert. Vielleicht auch einen Moment, bis man mit einem Docker compose sich das so zurechtgelegt hat, bis man alles so hat, wie man es braucht.
Vielleicht einen Schluck manueller, also kymanitis macht ein paar Sachen mehr automatisch als Docker compose, aber meiner Meinung nach kommt man mit Docker compose genauso weit wie Kybernetisch bis zum gewissen Maß so ja, aber für unseren Anwendungsfall reicht Docker Compose völlig aus und ich glaube für viele, auch für viele andere auch und ich finde es spricht überhaupt nichts dagegen Docker compose zu nehmen als Orchestrator. Vorteile sehen wir gleich noch.
Also jetzt haben wir Konzeptuell kurz gesprochen, was Stocker ist und welches die wichtigsten. Wichtigsten Konzepte sind genau jetzt gucken wir mal, wie arbeitet Stocker, wie funktioniert das eigentlich, was ist das? Es gibt quasi also auf jedem Computer, der mit Docker Containern umgehen können soll, muss der sogenannte Docker demon
¶ Docker Funktionsweise & Komponenten
laufen. Ne? Was ist der Docardime ne? Klingt so, klingt so geheimnisvoll, deamon ist ja eigentlich nur, das ist ja eigentlich nur das Team mit klingt überwiesen, ich hab immer an Drachen gedacht oder irgendwas früher so, aber es ist eigentlich in Deanman heißt eigentlich nichts anderes als n Dienst. Ja.
Der halt irgendwie 24 7 irgendwie da ist, sobald das Betriebssystem startet sag ich mal ja und und und ansprechbar ist und der Dockertypen ist nichts anderes als n ganzen stinknormaler Rest full Server ja also Rest API Invest hatten wir auch schon in der Folge. Wer da jetzt gerade nicht Bescheid falls er da wieder rein aber es ist ein Rest Server ja am Ende des Tages. Der gestartet wird und sich einhängt als demon ins System wenn du halt docker installierst
und docker kannst du installieren auf dem Linux auf dem Windows mittlerweile auf Mac OS und auch auf Edge Devices und so weiter das hat extrem krasse Verbreitung gefunden weil es halt so praktisch ist halt in Containern Software zu machen so haben wir den docker demon und dann haben wir den docker Client also wenn du einen Server hast dann brauchst du noch typischerweise auch einen Client den sieht man immer gar nicht so als Rest API Client da haben viele Leute jetzt hier irgendwie
curl im Kopf oder postman und ich musste irgendwelche gats.
Durch die Gegend schicken? Ja, muss ich eigentlich, aber gekapselt, denn der Dockerbefehls, was ich gerade gesagt hab, wenn du sagst, Docker Run oder Docker Build oder Docker Exec oder Irgendsowas diese ganzen Befehle, das nennt sich ja ne Seal Eyes, ein Command Line Interface sogenanntes und das so hat er auf dem Terminal, das ist quasi so ne Art Überbau unten drunter wenn du sagst Docker run ist, dann gehen tatsächlich Post Requests ab.
Wenn du sagst zeig mir mal alle Container an, dann macht der irgendwo drunter nen Get Call gegen diesen Restfulserver sehen wir nun nicht weil es gekapselt ist. Ne Seal Eye. Das ist quasi das zweite Ding, wie du dann. Das ist quasi wie kannst du Docker benutzen und kurzer Seiten reinstich da gehen wir heute nicht tief rein, aber weil es so ist, das ist einfach Client Server, Architektur ist nach Rest Best Practice und sogar Jason. Als Message und so weiter also
alles ganz klassisch. Kannst du auch aus deiner Anwendung heraus diesen Docker demon steuern und du kannst so wilde Sachen machen wie innerhalb eines Docker Containers dafür sorgen, dass andere Docker Container gestartet werden, da gestoppt werden und so weiter weil du einfach quasi. Dieser Rest Verbindung aufbauen kannst gegen den den Server und dann kannst du mit dem ganzen Infrastruktur von Docker auch spielen.
Ne, du kannst dir quasi deine eigenen Orchestrator programmieren, selber ja machen wir auch zum Teil ja das braucht man immer dann wenn man quasi. Wenn man in der Runtime quasi neue Container haben will, ja und so weiter für für n Kundenaccount oder irgend sowas ja als kleiner Seitennotiz das geht halt auch wegen dieser Architektur ja. Das heißt, wenn wenn du sagst für n Kundenaccount das heißt, wenn sich bei uns jemand bei der heißen wär n Account anlegt. 9
dann werden Container gestartet. Ja oder oder erstellt. Speziell für diesen Kunden. Ja genau so, das passiert auch irgendwo anders im Container, der schon da ist.
Es gibt nämlich einen Container, der ist tatsächlich bei uns Docker, also ist n Docker Container, den wir Docker genannt haben und dieser Docker Container hat die Möglichkeit tatsächlich andere Docker Container ins Leben zu rufen und das ist genau das was du sagst passiert, wenn jemand bei uns einen Account registriert, dann passieren viele viele Dinge im Hintergrund das bei anderen Anwendungen aber auch so und bei uns entstehen halt ein ganzer Satz neue Container für diesen
Account. Trainer entstehen basierend auf Images, die Vorliegen. Richtig, genau. Die Images müssen vorher da sein. Genau das ist so ja immer genau richtig, genau und dann gibt es ne dritte Komponente in diesem in diesem Docker technischen System, das ist die Registry, die muss man auch mal wissen.
So funktioniert das, wenn ich wenn der Docker Klienten zum Beispiel sagt, Bring mir hoch den Container, Hello World oder sowas, den gibt es, den gibt es glaube ich direkt auch von Docker, dann funktioniert das einfach, dann startet halt so n Docker, obwohl der nie vielleicht vorher noch nie auf
deinem Betriebssystem war. Ja der kommt tatsächlich aus dem Internet, das funktioniert so ein bisschen wie github, also es gibt quasi eine Registry, die liegt, es gibt so eine Offizielle die Docker Hub Registry, das ist. Einfach eine Riesen, ein riesen Repository an images, da liegen halt diese ganzen Images mit Namen und ein Tag, so
funktioniert das immer. Der Image hat immer einen Namen, typischerweise hast du die Firma vorne dran, dann hast du irgendwie einen Slash, also bei uns zum Beispiel heißen Wir slash Bilderfrontend, so könnte ein Name sein, ja und dann kommt noch ein Doppelpunkt und ein Tag dann im Tag steht meistens die Version dran, weil du hast die die Images sind ja quasi wie kleine Softwareprodukte und die werden durch Versioniert wenn du was Neues gemacht hast oder ein Backe fix hast dann.
Wird es eine neue Version von deinem Image machen? Das steht unter dem Doppelpunkt und die kannst du in sogenannte Regeln. Ablegen und wenn die, wenn jemand das Recht hat, die Registry zu lesen mit deinem Docker Client, ja dann kann der quasi dieses Image aus der Registry holen, die irgendwo im Internet liegt. Ja und diesen Container dann starten, das passiert also das Image wird quasi runtergeladen, lokal auf dein, auf dein Host da gecached und dann wird der Container gestartet, das
passiert immer nur einmal. Ja die Images die einmal aufgerufen wurden, die bleiben quasi gecached in deinem Host System, damit der nächste Start schneller geht und nichts aus dem Internet runtergeladen werden müssen.
So eine Registry, da gibt es halt 2 Teile, da gibt es halt einen Public Part, das kannst du sagen okay mein Image hier, das darf jeder benutzen auf der ganzen Welt so und dann kannst du halt einfach, wenn du den Namen nimmst und es nicht weiter geschützt, dann kann das halt jeder ausführen oder du sagst ich habe eine private Registry, da musst du dann halt irgendwie username Passwort vorher musste ich anmelden und dann geht es erster wie das Halt so ist in der Web Welt okay also dann
haben wir diese 3 Dinge haben wir auch verstanden und jetzt ist die Frage und das ist jetzt eigentlich jetzt können wir eigentlich mal zu dem richtigen Inhalt auch schon ein bisschen gequatscht. Aber das macht ja nichts.
Ich wollt jetzt mal irgendwie kurz darstellen, wenn ich das jetzt alles so hab mit diesem ganzen Dockergedöns und so weiter was heißt denn das jetzt wirklich wirklich, wenn ich jetzt irgendwie so n kleinen webservice mal machen möchte, ja. Und jetzt machen wir heute so n bisschen Architektur, Software, Architektur für so n Webservice. Ja lasst uns mal kurz was annehmen, dass dieser Webservice 4 Komponenten bräuchte. Ja ich nenne sie mal kurz ja.
Wir sagen mal, wir brauchen nen Reverse Proxy. N Reverse Proxy ist hatten wir auch schon, ne Folge ist quasi unser Heim daal ja der ist also der verbindet quasi das die
¶ Webservice Design mit Docker
Außenwelt mit unserer Innenwelt. Also wenn ich irgendwelche URLS hab mit Slashes und Passes und so weiter oder irgendwelche Subdomains, ja der verteilt das dann quasi weiter an die richtigen internen Komponenten. So ein Reverse Proxy wird immer ist immer interessant zu haben wenn man Microservices hat, ja. Weil irgendwer muss mich ja quasi aufteilen auf die richtigen, auf den richtigen Microservice.
Eine Anfrage von außen kommt also, wenn man in der Webwelt sind, kommt er immer über eine URL rein, die URL hat irgendwie eine bestimmte Struktur, der Reverse Proxy guckt sich diese URL an und leitet nach innen, das zieht der Nutzer nicht mehr der URL leitet nach innen auf einen bestimmten Microservice weiter, der jetzt dafür verantwortlich zeichnet.
Ja zum Anfrage dieser Anfrage ja so also haben wir den Reverse Proxy und dann sagen, wir, haben wir als zweite Komponente nen Frontend, also eine UI und heute mal react. Merkt es ja was, was man überall braucht.
Wir wollen es jetzt mal genau anschauen, was muss man mit React machen, um um das cool hinzukriegen in Sachen Docker und dann sagen wir, wir haben nen No JS backend ja also das React Front entspricht ja irgendwie wenn es Daten braucht dann mit dem No JS Backend und das Backend um seine Daten zu halten hat ne postrace Datenbank ja also haben wir dann den No just js macht eigentlich SQL Anfragen gehen Post Datenbank jetzt haben wir schon das habe ich jetzt mal architektonisch
einfach so auseinander genommen, das sind jetzt auch schon 4 Komponenten 4. Komponenten, die verschiedene Sachen machen und man würde diese 4 jetzt, wenn man wenn ich finde euch ordentliche Architektur macht, auch in 4 Microservices packen. Das heißt ich brauche hier 4 Images und im kleinsten Falle wenn das System halt jeweils eine Instanz dieses Images hat, habe ich später 4 Container die laufen und damit kann ich dann meinen Webservice dann irgendwie
haben. Ja jetzt muss ich noch einen, jetzt muss ich noch eine Sache sagen, jetzt ist ja heute, das ist schon eine krasse architektonische Entscheidung, ja, dass ich sage, ich habe meinen eigenen Reverse Proxy, ja und meine eigene Datenbank. Ich selber mir einen Docker Container und orchestrier das selbst. Weil was für die Alternative das? Genau. Die Alternative ist, ich gehe halt hinzu ABS oder zu Google Cloud oder zu Azure Cloud und die haben Garrett ja diese ganzen.
Man muss sich ja vorstellen diese Cloud Provider, die haben ja, die ist ja nicht nur ein Server den ihr zur Verfügung stellen, wo also quasi einen Bret Rechner der im Internet eine IP Adresse hat so ja das ist ja das Minimum was ich brauche, aber die haben ja viel mehr, die haben ja diese ganzen Services, dass die auch was ich teuer bezahle. Ich könnte jetzt also auch sagen, und das gibt es alles. Bei ABS, ich brauch halt so ne Art Reverse Proxy.
Ja das haben die, das kannst du einfach daneben. Ja klickst du an quasi ja brauch ich ja und dann brauch ich noch ne Datenbank postg Rest ja klickst du auch an ne das wird alles für dich gemacht ja weil das sind ja standardkomponenten, da hast du jetzt noch nicht mal Business Logik verbaut.
Ja das ist einfach, das ist eine konfiguriert werden, das kannst du halt machen und dann hast du schon einfach das ist ein Problem schon irgendwie um 2 Container oder 2 images kleiner geworden weil du die da als Service nimmst.
Ja und dann kannst du dann quasi selber noch sagen okay hier ist mein Backend. Da ist das Image, das Schlag ich auch noch da. Rein ans ABS und dann Verwurste das irgendwie und dann fängst du da an im und das ist aber jetzt sehr spezifisch im Google Business oder im AWS Sprech oder im Azure Sprech quasi deine microservice Anwendung aufzubauen ja und bist aber auch dann schon eingehängt in die jeweilige Technologie, ja weil garantiert die Post Press
Datenbank anders zu integrieren ist bei Azure als bei AWS. Also das ist die erste Entscheidung, die ich machen will. Ja, wenn du jetzt eine Webanwendung größer machen willst und langfristiger haben möchtest und du nimmst halt diese Services von einem Cloud Dienstleister, da hängst du da erstmal drin. Das ist erstmal so schnell kannst du dann nicht zum nächsten umziehen, weil die halt ihre eigenen Ideen haben und
sowas konfiguriert. Im Prinzip wird der Orchestra dann nicht mehr Compose was ein unabhängiges Produkt ist, sondern der Orchestrator wird quasi dieser Cloud Provider zum Teil. Also ist das hier die erste krasse Entscheidung, die man führt, ob man, ob man sich jetzt ob man sowas halt mit einkauft, was total praktisch sein kann und so. Deswegen gibt's das. Oder ob es man es halt selber macht. Ja, was auch total praktisch sein kann und auf einmal unabhängig bist von dem ganzen Krempel.
Du brauchst einfach nur ne virtuelle Maschine mit ner IP Adresse in der Cloud. Ja wir nehmen jetzt mal zweiteres an ja und haben wir auch so entschieden erstmal bei unseren Lösungen ja die ist halt komplett. Cloud Anbieter unabhängig ja, wir können halt hingehen zu wem wir wollen, weil wir halt nicht deren interne Services nutzen ne, sondern die quasi in Container gekapselt haben. Ja. Kannst du schätzen wieviel mehr oder weniger Aufwand das ist? Weil 2 * 3 * 4 oder schwer zu
sagen. Kann man das nur, kommt auf die Anwendung drauf an und so weiter und kommt ich würde mal so sagen, also wenn man wenn man so ein bisschen mehr vorhat, was wie soll ich sagen also. Was Best Practice mäßiges zu machen Standardmäßiges, wo jetzt quasi sag ich mal die die Technologie die darunter liegt nicht der entscheidende Neuerungspunkt ist, sondern vielleicht der Inhalt.
Ja weil ich zum Beispiel irgendwie eine Plattform mache, die bestimmte Suchanfragen macht, die es halt vorher noch nicht gegeben hat, ja, weil ich quasi weil die Daten, die ich halte, irgendwie den Wert bringen und nicht die Technologie, da kann ich halt auch zu diesen ganzen standardmäßigen Dingern greifen, dann ist es schneller da, dann reicht es ja aber, also bei uns ist es quasi so, dass wir bei uns halt die Technologie, quasi das was wir verkaufen.
Mit diesen, mit diesen ganzen FC, Wir bauen und so weiter, dass wir managen müssen. Insofern liegt da n anderer, ja liegt dann anderer Schwerpunkt, sag ich mal.
Deswegen haben wir uns jetzt für diese Variante entschieden, ne genau, aber ich würde mich immer erstmal dafür entscheiden, wenn man weiß was man tut, dann ist es auch schnell, ja dann dann verliert man da nicht viel Zeit ehrlich gesagt okay also nehmen wir mal an wir wollen das so machen, dann muss man und jetzt muss man doch noch eine Sache beachten und und die ist wahr für beide Szenarien, ob ich jetzt da irgendwie Google
mitnehme oder. Oder das alles selber baue, was man immer nicht vergessen darf und was nie irgendwo steht, ist ja, dass das echte Leben ja nicht nur aus der finalen Anwendung besteht, das ist ja schön, wenn ich die da mal habe.
Ja, für die Nutzer der Weg dahin oder ich würde mal sagen die finale Anwendung, die wird ja zu 99,9% genutzt von den Entwicklern, die müssen das den ganzen Tag benutzen das Ding, weil die das ja entwickeln und dann in 0,1% der Fälle benutzt das Halt mal ein echter Nutzer später ja das. Ist schon so. Ja, auch bei großen Produkten. Ja guck mal, die haben Hunderte von Entwickler, die machen jeden Tag 8 Stunden nichts anderes als mit diesem Ding da zu arbeiten.
Zu debuggen, das Weiterzubauen und so weiter ja, das ist wahrscheinlich immer. Also wenn du nicht gerade youtube bist oder Spotify oder Irgendsowas ist glaub ich der Entwickler die die die wichtigsten Nutzer für dein Produkt sind, die Entwickler ja weil sie es entwickeln müssen so, und das darf man nicht vergessen, wie wichtig das ist, ja. Und die müssen das gut können.
Ja, und wenn die das gut können, müssen und gut und und gut sehen wollen, ob das wirklich cool funktioniert, dann muss die Entwicklungsumgebung sehr, sehr ähnlich sein zu der Produktionsumgebung, das muss sich genauso anfühlen, und das ist das mach ich mal den Punkt, mach ich mal ganz klar, das ist total wichtig, dass man das hinkriegt, und es ist überhaupt nicht einfach, es hinzubekommen. Weil wenn ich entwickel, dann hab ich dann hab ich irgendwie code den ich schreibe.
Ich bin in der IDE, ich schreib zeilencode und ich zurück, will das speichern und im nächsten Moment muss die Anwendung auf den neu gespeicherten Code reagieren und das haben ja in einem System was hoch verteilt ist im Web ja was auch diese Skalierungseigenschaften haben soll weil ich will das ja alles mit testen und die Produktionsvariante ist so viel anders ja da habe ich vor hochoptimierten durchkompilierten Webcode der dann auf irgendwelche statischen
Server geladen wird und so weiter und das kann man nicht vergleichen. Das ist eine ganz andere Technologie. Ja, und doch kriege ich es halt hin mit Docker auch dieses alles gleichzeitig abbilden zu können.
Fein haben wir das. Jetzt habe ich was habe ich denn jetzt gesagt, jetzt habe ich gesagt, wir haben diese 4 Komponenten entdeckt, wir wollen die in Container stecken jetzt, wie sieht denn das aus in der Technik, dann habe ich im Prinzip, ich sage jetzt mal ein paar, Ich mache Mono repo auf, schreibe jetzt also Code Web Service Projekt blub blub und mache erstmal 4 Ordner ja reverse proxy react from end no js backend und Postgase Datenbank.
Zack gebum ja, alle 4 Ordner entsprechen quasi diesen, werden quasi diese 4 Microservices. Ja, da steckt der Code drin, der da irgendwie rein muss, da steckt die ganze Krams drin. Ja wie ich das jetzt ordentlich machen will, dann brauchen alle 4 Ordner nen Dockerfile jetzt kommt das nächste Konzept ja. Dann ja, ich hab ja gesagt, es muss n Image geben. Ja das kommt ja nicht irgendwoher geflogen.
Ja ich muss ja definieren, irgendwo muss ja mal definiert werden, was ist das Image, ja was steckt da drinne. Ja und das macht das Dockerfile ja. Das heißt Anleitung oder wie? Ist die Bauanleitung? Ja ist das Rezept nen Image zu bauen? Genau und das schreibt man, das Dockerfile, das heißt auch so muss so heißen Docker File schreibt man typischerweise so hin, das Projekt ist muss nicht so heißen Best Practice und das Dockerfile ist quasi einen Satz von Instruktionen die man von
oben bis runter schreibt. Ja da gibt es.
¶ Images & Dockerfile erstellen
Erstes typischerweise das from statement ich jetzt geh jetzt mal kurz durch wie baue ich mit so einem Docker fallenden Image?
Ja und das from Statement, das legt erstmal fest von welchem Startpunkt fang ich an und typischerweise ist das n Betriebssystem ja irgendso n Linux Ding ja also zum Beispiel könnte ich sagen from Debian Slim oder irgend sowas ja in Version irgendwas dann habe ich quasi erstmal im Betrieb ein Linux Betriebssystem quasi definiert auf dem ich aufbaue, ja dann gibt's aber noch viel bessere Froms und es gibt da sogenannte Official Images, die haben schon ein bisschen mehr
drin. Wir nutzen zum Beispiel weil wir no js benutzen. Quasi javascript dann auch haben wollen und so weiter haben wir haben wir oft nen nen Image, das heißt Node. Ja das heißt das ist quasi dann nimmst du quasi bestimmte Versionen von der Node JS sprachen, das ist dann alles prima installiert und hast alles da. Ja also das liegt erstmal fest auf auf wo fange ich an ja und dann kannst du in so einem in so einem Imagefile das ist auch wichtig, dann gibt es quasi
Spezial optimierte. Betriebssysteme, also Bunte, was du dir auf dem Desktop installierst relativ fett.
Ja, das soll ja auch was anderes lösen, das soll Grafik machen, so alles Mögliche haben ja so ein Container soll ja relativ dünn und schnell starten, da gibt es dann die sogenannten Slims und alpine und so weiter kann man sich mal angucken, die sind halt hoch optimierte und runter gedampfte Betriebssysteme die nur noch das Nötigste haben im nächsten Schritt in so einem Dockerpfeil wenn ich jetzt mal festlege zum Beispiel ein Betriebssystem vielleicht mit einer Programmiersprache.
Installiere ich mir die Abhängigkeiten, die ich brauche? Warum zum Beispiel? Ich mache zum Beispiel Image Processing oder sowas und brauche halt eine krasse, die gibt es ja oft im. Gibt n Linux gibt es ja 1000 Pakete. Ja installier ich mir halt open CV libreader irgend sowas. Ja und das mach ich indem ich das Run Word Run ist ein Befehl im dockert Image und das tut so als würde ich einfach auf der Command Teile von diesem. Betriebssystem was ich in der Form Zeile ausgedrückt hab
Sachen machen. Ich kann wirklich machen was ich möchte, ja ich hab das gesamte ich hab so als hätte ich n Linux System ich schreib es quasi nur Teile für Zeile hin ne also kann ich sagen so du get install irgendwas also ich brauch und so weiter ja. Hier sollte man auch nur das machen, was man wirklich braucht. Ja, weil alles das was ich installiere und nicht brauche macht halt das System unnötig fett.
Wir wollen ja schlank bleiben ja, also installiere ich hier und referenziere Krams so ja und dann dann brauch ich zum Ende des Tages ja auch meinen eigenen Code, ja der soll ja irgendwie ausgeführt werden, das heißt den muss ich da auch irgendwie reinkopieren. Und das kann ich doch alles
machen. Und dann hab ich nen sogenannten Entry Point. Also das File hört typischerweise raus mit dem Entry Point heißt das Wort, das ist n Keyword oder Command und das führt dann das führt zum Starten eines Programms typischerweise.
Führt das dann zu, also bei Nord JS kann man mal sagen, das ruft dann quasi zum Beispiel aus noteindex Punkt JS ja Index Punkt JS ist das Eingangspfeil zu deinem zu deinem Noteprogramm hast du selber geschrieben was Index JS hast du selber geschrieben ist n Teil in diesem Ordner ja von der von dem Frontend steht irgendwo in der Index JS file hast du da rein kopiert und dann sagst du irgendwie im Container Note Index js und dann startet quasi die Anwendung die du da gecodet
hast im Container hocher und tut was sie soll ja oft wird der Webservice Hochgejagt. Jetzt wollen wir, wenn wir das verstanden haben, wollen wir mal gucken. Es gibt nämlich 2 Arten, wie du jetzt deinen Sourcecode da reinklatschen kannst und das führt mich noch mal zu Death und Pott. Hier ist es wichtig, ja. Es ist total sinnvoll, wenn du jetzt nen produktionsimage vorbereitest. Es gibt quasi einen einen, ich würde sagen ein Development Image und ein Produktionsimage.
Keiner sagte ja keiner zwingt dich ja irgendwie nur wenige Images zu bauen. Du kannst ja images bauen wie du lustig bist und nennen auch wie du lustig bist. Im Produktionsimage würdest du quasi deinen Sourcecode da rein kopieren und Reinkompilieren und hochoptimieren, dass da irgendwie gut läuft im Development Image. Wenn du entwickeln willst, da willst du nichts reinkopieren, denn in dem Moment wo du den Code rein kopiert hast und du auf der Idee tippst bist du entkoppelt.
Ja weil es ist in den Container kopiert ja und du bist losgelöst von dem was du in der Idee tippst. Hier erinnern wir uns an das ist Volume. Ja hier würdest du sogenannte Volume Mount machen und sagst halt du kopierst überhaupt nichts in den Container rein, du. Ist jetzt aber quasi du lässt den Container auf den Sourcecode gucken, der auf deinem Betriebssystem liegt, den du mit deiner IDE zum Beispiel Visio
Code bearbeitest. Ja, das heißt, der wird da nicht reinkopiert, sondern nur rein gelingt, wenn du möchtest, ja. Das führt dazu, wenn du den Container ausführst, dass wenn du den Code änderst, sofort diese Änderung trotzdem im Container übernommen wird. Das ist unglaublich wichtig, wenn du jetzt zum Beispiel React. Ich hatte gesagt, wir gucken uns Reaction noch ein bisschen genauer an, ne, wenn man React entwickelt.
Dann hast du diesen ganzen UI, diesen Java Script, CSS Code und so weiter da bist du die ganze Zeit am ändern und du guckst dir andauernd live das Ergebnis an. Ja so arbeitet man halt ja, du hast quasi die UI vor dir an der Nase, die führt aus Du änderst den Code, drückst auf Return und dann siehst du ja schon was du geändert hast da. Was blau gemacht war, was vorher gelb war oder irgendwie was. Ja, und dieses Gefühl, dieses dieses developer Feeling, das brauchst du halt auch.
Ja, und wenn du jetzt aber wenn du jetzt aber nicht willst, dass du jetzt komplett das ganze System ohne die ganzen Dockercontainer aufziehst. Weil dann behält es dann würde sich quasi dann developmentsystem schon sehr sehr anders verhalten als das Product System, was ja in diesen Containern laufen soll. Ja dann müsstest du ja auch wenn du es machst, dein ganzes Host Betriebssystem mit allen diesen was ich gerade gesagt hab und dependencies und so weiter
verschmutzen. Das willst du also nicht. Ja, das heißt du bist irgendwie gezwungen diese React Anwendung auch selbst wenn du entwickelst trotzdem in dem Containerauslauf laufen zu lassen. Ja und am besten ist dieser Container auch Teil dieser Orchestrierung, die du später hast, die sehr ähnlich aussieht wie die Produktionsorchestrierung. Und hier wird es halt kniffelig.
Ja, hier muss man halt gucken, dass man die richtigen Waffen in die Hand nimmt, man kann das machen und ich kann euch sagen, es dauert ne Sekunde, vielleicht schreib ich mal n Blog Artikel dazu oder n Tiefen, das geht ja und ein Trick zum Beispiel ist halt zum Beispiel den Code da nicht rein zu kopieren sondern halt rein zu Mountain ne. Und schon läuft das trotzdem im Container und ich hab kann aber trotzdem quasi meinen Code
editieren, drück auf Return und und seh es trotzdem live, obwohl das quasi ne ne Microservice basierte Architektur ist, die es ausführt, ja. Ja ist krass. Ich, ich kann es mir vorstellen, was da passiert irgendwie. Ich kann dir folgen, aber man muss es wahrscheinlich mal gesehen haben ne ja man. Muss es vielleicht mal gesehen haben. Ja, also. Ich bin gespannt auf den Block. Ja, das muss ich mal machen.
Man würde quasi auch für jetzt n so n reacting brauchst du eigentlich im Prinzip gar keinen Docker File schreiben? Ja, du kannst quasi im Orchestra einfach sagen, ich nehme mir einfach nen Image, was halt alles hat und das gibt's ja was ich brauche, zum Beispiel für React und dann klemme ich da einfach mal nen Code über so ein Volume Mount rein quasi und dann
läuft das schon. Wohingegen, wenn ich das jetzt quasi in Production mache, das will ich einmal sagen, ja, und da gibt's nämlich auch noch was cooles, da wird so was ganz anderes machen. Da würdest du nämlich quasi auch, da fängst du auch erstmal an, mit so einem Standard Image und jetzt baust du quasi jetzt kopierst du den Code rein, dein React Code und du installierst ihn auch, also du installierst diese ganzen Abhängigkeiten fest.
In diesem Container, kopierst diesen Code rein und sagst dann auch sowas wie npm install run Build npm RUN build sagt und dann dann wird geht diese React Maschine an und ein Web Hack und so weiter und. Richtig krasse Sachen gebaut und so weiter dafür brauchst du auch viel Umgebung.
Ja und dann hast du ein sogenanntes Artefakt, was übrig bleibt von wenn du so ne wenn du so ne UI Anwendung brauchst in nem kleines javascript Paket ja. Und dann brauchst du eigentlich nur noch n statischen Server nen Webserver, sowas wie n enginex oder irgend sowas. Ja der dieses Paket lädt, das ist das was du also mehr brauchst du nicht, ja und wenn du jetzt aber quasi in diesem Image was du hast für dieses produktiv, für diese produktiv Reader Anwendung.
Wenn du da alles drin machst, also das Bauen und so weiter, dann wird das relativ großer Container, weil du brauchst diese ganzen Abhängigkeiten um es überbauen zu können.
Ja, und hier gibt es so nen, das muss man auch hier ist ein Trick, den will ich auch sagen, es gibt die sogenannten Multi Stage Builds, wer das noch nicht gehört hat, muss ich das unbedingt angucken ja also wenn ich nen Image baue kann ich quasi sagen ich fang mal an mit einem schmutzigen Container und Bau da allen möglichen Kram drin und dann im gleichen Dockerpfeil sage ich und so und jetzt ziehe ich ihn noch mache ich noch ein From und Fang Vanille an auf einem ganz kleinen.
Ein oder irgend so was. Und da packe ich jetzt nur den kleinen Webserver rein, den ich brauche und kopiere mir von dem anderen Container der Schmutzcontainer das gebaut hat ja das die kleinen Artefakte rein die ich brauche. Ja das heißt ich trenne den das den den den den Bauschritt, den Buildingschritt. Dann Sperrmüllcontainer den schmeiß wieder raus und kopiere sauber nur die kleinen Elemente rein in den Ausflug in den Produktivcontainer, den ich
eigentlich dann brauche. Ja, das nennt sich Multi Stage Bild. Ja und dann entstehen super Kleine, extrem hoch optimierte. Images also Docker images, die zu hoch optimierten Containern führen, die dann die so ne reactanwendung mit 15 Megabyte Speicher oder irgendwas ausführen. Ja ist voll cool, ja. Man muss halt wissen, dass man das machen muss. So, das steht nicht überall. Ja, also das, das sind so, die diese, diese kleinen Tricks, die ich heute auch schon mal sagen
wollte. Das heißt, du findest es raus, indem du einfach extrem viel Recherchierst liest? Das ich auch total viel Erfahrung einfach genau oder irgendwie genau er muss lesen. Recherche.
Und vielleicht am besten, Ich glaube, am meisten hilft sich mal so ne Docker, also n gutes System was so ne microserviceinfrastruktur mal programmiert hat wirklich zu verstehen den Code zu lesen, aber es ist halt nicht einfach weil überall hast du diese Files verteilt und so weiter nicht so einfach da n roten Faden zu kriegen. Ich hab Jahre gebraucht bis ich das so verstanden hatte wie man
es so braucht. Weil das alles Ball dadurch, dass du das entkapselierst, musst du halt wirklich viel nachdenken, wie du das alles reinkriegst und so okay. Aber dann haben wir das und im Prinzip habe ich dann meine Bauanleitung für das Image in jedem, in jedem von diesem Ordner, was später dann quasi der Container wird.
Was ich jetzt als nächstes brauche ist quasi den Orchestrator. Jetzt habe ich also quasi Gerrit, das haben wir vorher gesagt, jetzt habe ich also quasi alles vorbereitet und sagen wir mal, wir sind fertig und haben diese ganzen Images. Gebaut. Jetzt müssen sie irgendwie ins Leben gerufen werden. Images sind ja nur. Tote Templates, sag ich mal.
Ja, irgendwer muss jetzt ja die Container machen und sagen, welche Netzwerke habt ihr und wie seid ihr gestartet werden und dann, wie sollt ihr konfiguriert werden.
¶ Container orchestrieren & Docker Compose File
Das lass ich heute weg, weil es relativ bekannt ist. Aber alle Konfigurations, also alle Einstellungen und so weiter werden immer über Environment Variablen gelöst. Das ist so n Konzept, das kennt jeder Linuxer. Auch gibt es natürlich auch im Windows, das sind quasi systemweite Konfigurationen. Ja so n so zum Beispiel Path kennt ich weiß nicht ob du mal die Pass Environment Variable gehört hast. Da steht immer drin, welche Programme direkt laufen dürfen und so weiter zum Beispiel.
Ja hab ich zur Pars hinzugefügt zur und Environment Variablen sind aber das Mittel der Wahl um um Microservices zu konfigurieren, weil wir hier immer die denke ist quasi. Fast auf ner Betriebssystemebene.
Ja und wenn ich n Betriebssystem konfigurieren will, dann tu ich das über Environment Variablen ja auf dem Level spiele ich halt, deswegen ist das das Mittel der Wahl um Konfigurationen vorzunehmen, das mach ich immer über Environment Variablen, da gibt es halt auch viel Tooling drumherum. Das muss man auch gut im Griff haben.
Ne so mit Sicherheit zu tun ne OK, aber jetzt nehmen wir mal den den Orchestrator und jetzt hab ich also quasi meine 4 Ordner da stehen meine 4 Docker Files drinne und jetzt brauch ich quasi auf der auf der höchsten Ebene, also quasi außerhalb dieser 4 Ordner. Meine Anweisung für den Orchestrator. Es macht Sinn, weil der soll
quasi alle 4 sehen können. Und der Orchestrator mit Docker compose Name ist auch wieder nen Pfeil nen Jamel Pfeil in diesem Fall. Typischerweise kannst du auch in Jase wahrscheinlich hinschreiben, aber es hat immer Yammel genommen und das Standard File heißt auch Docker minus
compose Punkt YML also. Und in diesem Jammelfall, man kann es sich wirklich vorstellen, steht, das heißt, Services ist quasi die erste Überschrift, Services, Doppelpunkt und dann stehen erstmal alle Services aller Microservices. Für jedes Microservice sind Päckchen, wie es konfiguriert zu werden hat. Ja, also würden wir in unserem Beispiel hier in dem Docker minus compose dot Jammel 4 Services sehen, ne?
Weil wir hier 4 Microservices hochreißen wollen, ne und das schicke ist was du was du im Docker compose Yaml machst ist das ganze Gespiele mit den wie baue ich also wer also selbst der Orchestrator kümmert sich sogar um das Bauen, tatsächlich der der Image ist. Das Dockerfile macht nichts ist nur die Bauanleitung angestoßen, das Bauen und wie es gemacht werden soll und wie das Image danach heißt, da steht alles im
Docker Compose Jamel File drin. Und ja, jetzt habe ich hier sehr viel sehr viel technisches Zeugs aufgeschrieben. Ich glaube also, ich merke gerade, das ist zu Hardcore wird, aber ich will, ich will ein paar Sachen zu diesem Docker Composer sagen, die man auch nicht so weiß, die sich mir auch erst durch längeres Nutzen erschlossen haben.
Ich muss jetzt hier, was ich jetzt hier hinbekommen muss ist mit diesem Docker Composer Files quasi 2 Sorten von Umgebungen zu erstellen, nämlich diese Development Umgebung. Und die Produktionsumgebung. Und das bekomme ich hin, nicht in einem Fall, das macht man nicht so. Es gibt ein spezielles Fall, das heißt, das ist sogar besser Praxis und es ist nicht nur jetzt, einen Namen, den ich mir ausgedacht habe, nicht das File Docker Composer compose Punkt
Override Yaml nenne. Dann passiert n Magic, die ist im Docker Compose mit eingebracht. Ja, also ist jetzt nichts was ich mir ausgedacht hab, es ist so, ja dann überschreibt quasi dann überschreiben die Anweisungen im Docker compose Override heißt das schon so? Also sie überschreibt es nicht, das Mercht es quasi, es ergänzt das und wenn ich gleiche Sachen hab überschreibt es das ja es ist ne Art mergent Replays wenn du willst, ja.
Die Sachen vom Docker compose Jamel ja, das kann ich dann zum Beispiel nutzen und jetzt bin ich wieder bei React. Ja, jetzt muss ich nämlich was ganz anderes machen im React, ich muss quasi, wenn ich React im im Development Stil benutzen will, dann muss ich sehen, dass der Development Server von React läuft. Dass diese, dass dieses Volume mounting passiert und so weiter und sofort, das schreibe ich
alles in dieses Override rein. Ich kann quasi eben Docker compose ja mal ausdrücken, welche Volumes klemm ich an diesen Service ran. Ja also ich kann dann quasi sagen, du guckst jetzt im React. Im React Anwendung im React Frontend in der Konfiguration von meinem Docker Compose.
Hier haben wir sagst du du guckst jetzt als Source Files direkt da auf die Source auf den Source Ordner den ich da in meiner IDE hier liegen hab ja. Live so, und das drück ich alles quasi aus dem Docker compose Override. Das will ich aber natürlich nicht, wenn ich in Produktion bin, dann soll da keiner irgendwo was hingucken. Ja dann muss der Code ja da reingenommen werden, kompiliert werden, dann muss dieses Staging kommen und so weiter und das
kann ich. Das kann ich dann alles ausdrücken in einem Docker compose. Wenn ich dann noch n prott jammel, so mach ich das immer. Ich hab dann production yammel. Da steck ich quasi. Das ist quasi das Gegenteil zu dem Override. Das Override macht quasi die Entwicklungsumgebung und das Prod macht quasi dann die Container fertig zur Produktionsumgebung. Ja, da liegt dann zum Beispiel fest, wie die Images heißen, da steht dann drin heißen wärst.
Hisenway, Slash, React heißen Wir Slash, Ingrid und so weiter und sofort. Ja, und dann kann ich das jetzt noch n bisschen Technologie dazu, dann kann ich quasi diese Images erstellen. Ja, indem ich sogar Docker
compose. Das Docker Compost ist nicht nur zum Ausführen, ne, man kennt immer nur Docker Compose ab d. Das was heißt das das heißt Bring hoch alle Microservices die drin definiert sind, ja lass die starten, das mache ich ganz zum Schluss wenn ich es hab ja man kann aber es gibt noch Bild und config will das mal erzählen also Docker compose Bild. Und Docker compose config. Und wenn ich zum Beispiel Bild sage, dann werden tatsächlich die die Images gebaut.
Ja, das heißt dann guckt und es gibt auch dieses Bild Keyword, dann guckt quasi der Orchestrator rein in die ganzen Dockerfiles und erstellt diese Images das erste Mal gibt denen einen Namen und tagt die auch hier mache ich das Ganze dieses wenn das so Magic ist. Wenn ich eine neue Version mache, neues Release ja dann habe ich. Ein Environment Variable, der heißt Version, die ist eingebaut mit in den Tag, dann sage ich baue das alles und dann werden die Image gebaut für das Release.
Und dann hab ich die alle lokal bei mir auf dem Rechner liegen und dann kann ich noch sagen, pusht die alle in die Registry.
Ja und dann werden die in die Registry gepusht und dann kann ich n mit config kann ich n Docker file erstellen, das listet quasi alle diese Produktionscontainer die bezieht sich quasi auf die Produktionscontainer die in die Registry gepusht habt, dann habe ich nur noch ein großes Docker compose file, das lege ich dann auf den ausführenden Server raus, das kann dann irgendwas sein in irgendeiner Cloud dann.
Habe ich ein einziges Docker compose File und das zieht sich dann die die Images raus bringt die hoch die Docker Container und führt die aus in Produktion während ich lokal das Docker compose abnutze weil das das override File gleich mit reinzieht. Ja und dann entstehen gar nicht erst diese Images die ich in die Registry geladen habe und so weiter dann entsteht quasi die Development.
Umgebung ja, mit zwar den gleichen Microservices, die später haben werde, aber die sehen von innen ganz anders aus, weil die weil die zum Beispiel halt die Quellcode nicht da reinkompiliert haben, nicht reingeguckt haben, sondern nur rein Referenzen. Und dann kann ich, dann kann ich das aber trotzdem auf dem Server ausführen und könnte das, und das ist jetzt noch der Schickste und der letzte Tipp den ich noch hab für diesen komplexen Dings, wenn ich jetzt meine Development
Umgebung Auslage und gar nicht mehr lokal auf dem Laptop. Sondern direkt tatsächlich auf dem Server, in der Cloud, in der IP Adresse hat, die von außen kommt. Wenn ich jetzt Docker compose so einsetze, dass ich quasi, dass ich das so hab, wie ich das gesagt hab, dass ich quasi in der IDE, die ich dann benutze auf dem Server, das geht nämlich auch heute mit Visual Studio Code, kannst du quasi per SSH Remote editieren und der Code liegt quasi schon auf dem
Server, der im Internet ist. Dann habe ich das Beste von allen Welten, weil dann habe ich ein unglaublich nahes Abbild meiner Produktionsumgebung, bin aber trotzdem.
Modus Aha kann dann Visual Studio Code die Zeilen Code ändern und ich sehe die neue React Anwendung und die läuft aber schon als Teil dieser gleichen microservice Architektur, die später in der Produktion hab ja nur, dass ich in der Produktion quasi den Code, den Code den ich dann fertig editiert hab, nehme, packe und installiere quasi in diese gleichen Images, aber dann läuft es quasi trotzdem weiter.
Ihr merkt schon ich hab jetzt Gerrit Gerrit hat ein großes Fragezeichen, man konnte nämlich voll abgehängt, ich hab wahrscheinlich auch alle abgehängt.
Quasi das Ziel der Folge zuzusehen, dass es halt, dass man da noch nicht so viel geschenkt kriegt und es also es lohnt sich wirklich, in der Tiefe diese Dockersachen zu verstehen, weil es ist so unglaublich wichtig, wenn wenn man, wenn man performantisch schnelle Anwendung macht, ja, also es hilft nichts und nicht das nur halb verstanden habe und den von Google oder von Abs diese diese Services, dann zahle ich im Notfall viel Geld, das wird dann gehen, aber weil ich
einfach mit Hardware Ressourcen auf nicht optimierte Soft. Ware raufhaue so ja, also wenn man Docker nimmt, muss man sich diese Sachen genauer angucken und verstehen, was da los ist. Glaube ich. Ja, das ist Qi, wenn nicht große
Webanwendung bauen will ja ich. Glaube das ist ein guter Hinweis. Ja, mein Fragezeichen wurde jetzt am Ende ein bisschen größer, ich würde sagen, das höre ich mir danach noch mal in halber Geschwindigkeit oder so an und ja, es ist natürlich auch für die jetzt gewesen, die es benutzen wollen letzten Endes und auch nicht nur für die, die es benutzen wollen, sondern auch für die, die vielleicht irgendwie mit allen Leuten arbeiten, die es benutzen, ja,
und da kann man ja mal die richtigen Fragen stellen, welche da da so ist ja ein bisschen die Idee. Ja, ich wollte. Paar Punkte machen. Ich glaub die sind durchgekommen, also dass man, dass man Development gleich mitdenkt, wenn man production macht, dass man bei Development diese File Mounts nimmt und so weiter einen Tipp hab ich noch für alle die React mal im Container ausführen wollen, das ist tatsächlich muss man sich echt die Handschuhe an die Ärmel hochkrempeln.
Einen Tipp habe ich noch, den habe ich noch nicht genannt. Das ist ein Insider. Wenn ich environment Variablen die ich brauche oft auch im React einsetzen will im Container, dann muss ich sie in der Bauzeit reingeben.
Ja, weil React ist ja ne ne ne Spa, also eine Single Page Application, die zieht sich ja nicht irgendwo her da noch irgendwelche Environment Variablen, das heißt ich muss zur Bauzeit die drinne haben, das ist aber nicht so einfach beim Container hier muss ich mit den Arguments spielen. Es gibt sogenannte Arguments im Dockerfile und die Arguments beschicke ich quasi vom Docker compose.
Da setze ich dann die Environment in die Arguments und die in den Docker file werden die Arguments im Environment Variablen umgedichtet, die müssen alle mit React unterstrich App anfangen, damit das funktioniert und dann kann ich quasi auch sogar ziemlich nice irgendwie über diese Docker compost als zentrale Konfigurationsschnittstelle auch die Environment Variablen in mein Frontend bringen jetzt, das war jetzt mit 3 Fragezeichen. Aber alle, die es schon mal
versucht haben, haben vielleicht jetzt eine Idee. Ja, genau, und ich glaube also Podcasts, ich weiß nicht, ist ein bisschen schwierig. Auszudrücken ich werd, ich werd mal versuchen wird es nicht versprechen. Ich werd mal versuchen noch mal n Artikel zu schreiben mit den mit den Key Learnings quasi die ich hatte um sowas zu realisieren ne also ich. Find es ziemlich beeindruckend, wie das alles runterbeten kannst. Die ganze Geschichte also. Ich muss das ja jeden Tag
machen. My daily Brad and Butter. Das Stocker Compose Yammel das wird auch immer wieder angefasst. Oder ist es irgendwann mal fertig? Auch wenn du ne Anwendung weiterentwickelst? Nee, das ist eigentlich dann mal
fertig. Ja, das fasst man dann nicht mehr so oft an. Ja, also es sei denn, du machst einen komplett neuen Microservice dazu, eigentlich ist das dann mal fertig, aber man muss erstmal das initial alles ein bisschen aufsetzen und so weiter ich fasse das nicht so oft an, ich habe es das letzte Mal angefasst, als wir quasi auch noch mal unsere Cloud Strategie. Verändert haben und so weiter aber genau und dann kann man auch das Ganze, was ich jetzt alles weggelassen habe, diesen
ganzen dev ops. Also Leute wir machen auch Deap Ops so, man muss das nicht alles per Hand antippen und so weiter dann kann man das natürlich noch in diese Cicd, das greift dann da rein, wenn ich das jetzt sage, also dieses Docker compose jammel ja und das Verarbeiten dieses Docker compose Yamml und was ich gesagt habe, da kannst du mal, dann musst du halt quasi aufrufen Docker compose Build und so weiter.
Nur um das aber auch noch mal zu sagen, das sind die typischen Schritte, die ich in sowas wie ICD Pipeline mache. Das passiert dann automatisch. Ja, also ich habe gerade.
Code gemacht. Ich hab rum editiert, hab das getestet, die Developer dann sagen die OK fein cool getestet ich will das Releasen, dann gibt es n im Repository Tag und dann kommt so ne CICD Event angelatscht und dann macht das das quasi alles so ja aber wenn ich mit Docker compose arbeite dann wird genau das passieren was ich heute so zum Teil irgendwie erzählt hab, dann wird das ausgerollt und das schicke ist, dass tatsächlich und das ist wirklich schick ja also wenn
du jetzt nen Server mit reinnehmen willst, neue Hardware, dann brauchst du echt nur nen Vanilla Server holen, der muss nichts anderes können als Docker und das können die fast alle Easy Docker hast du schnell installiert und dann klatscht du einfach dein fertiges Production Docker compose drauf, da ist alles drin was du brauchst.
Dann sagst du nur noch da Docker compose ab und dann ist ja dann ist der Lack fertig so dann kommt das hoch und dann ist die Installation fertig und das funktioniert halt überall ob das ein Webserver ist oder ob sie dann sogar Orden Brand gehst das ist das coole das sag ich jetzt auch noch mal. Diese Architektur Entscheidung, dass wir quasi auch nicht Services nehmen aus der Cloud. Die führt dazu, dass unser Server quasi egal ist, ob der in der Cloud ist oder nicht.
Ja, es kann halt auch n Server beim Kunden sein und premist funktioniert es halt auch, ja. Da hast du vielleicht am Anfang gefragt, da ist das viel mehr Aufwand. Ja, ist gar nicht so viel mehr Aufwand. Du musst n paar Sachen mehr mitdenken, aber das kaufst du dir natürlich dann ein, ne, dass du bist du on premise unterwegs ja ansonsten wenn du das wenn du das willst musst du da quasi schwer schuften, dass du dich dann rauslöst aus diesen. Und du hast ja keine Google Database on premise.
Du bist auch deutlich günstiger unterwegs mit deinen Cost of Revenuews würde man sagen. Also jeder hat zusätzliche Account, ist günstiger bei uns als wenn wir jetzt alles bei Amazon hätten oder bei bei Google oder oder Microsoft entsprechen. Das ist richtig, weil wir im Prinzip nur einen Server brauchen, und den gibt es virtualisiert mit in allen möglichen Fassungen.
Aber. Bei uns reicht so ein Standard 8 Gigabyte RAM was weiß ich 2 Kerne oder 4 Kerne Intel und da zahlst du unter 10€ für einen Server pro Monat, das ist echt günstig, so kannst du schon richtig was mit abfrühstücken, wenn du dann wenn du dann halt wirklich die Container schmal machst, dann muss man halt darauf achten, dass du schon optimieren, dass die nicht so viel Memory nehmen und nicht so viel CPU, da kommt es ja lange hin mit so einem Server, der
macht ja sonst nichts außer den Container zu laufen, die sind ja auch wieder hoch optimiert das. Ist wirklich. Tatsächlich sparst du da auch einen Euro? Das ist so, also hat also Cloud Infrastruktur auch direkt was mit deinem Revenue zu tun. Zumindest mit der Marge. Ja, ja. Genau das stimmt. Alles klar? OK, dann fällt dir gerade noch n Tipp ein. Nee, ich glaub ich hab auch schon n schlechtes Gewissen mit. Läuft, dann hört man schon auf
vor dem Neuen einfällt mal. Gucken, wer noch so jetzt noch so zuhört, so aber das ja, ich hab es, ich hoffe es hat euch trotzdem n bisschen weitergeholfen, mal n bisschen bisschen deeper inside so, ja vielleicht ein bisschen mehr für die Developers heute, aber genau das. Sind schon ein paar Leute dabei, bin ich sicher alles klar. Burkhardt, ich danke dir und ich danke euch fürs Zuhören und wir hören uns dann in 2 Wochen bis dann. Alles klar, hat die, die noch dabei sind.
Tschüss aus Hamburg. Einfach komplex wird präsentiert und produziert von Highsomware. Wir freuen uns auf deine Fragen und deinfeedbackanpodcast@heiseweb.com vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.