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.
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
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
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.
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.
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.