Latest / Coding Buddies | Tech & Dev-Mindset / #153 Mit GitOps auf das nächste Level als Entwickler:in

Transcript

#153 Mit GitOps auf das nächste Level als Entwickler:in · Coding Buddies | Tech & Dev-Mindset

0:00
Heute reden wir darüber, warum dein Deployment Prozess dein
0:02
größtes Risiko ist und wie Git Ups das ändert.
0:06
Coding Buddies, Dein Podcast rund um Softwareentwicklung und
0:09
aktueller Tech News. Herzlich Willkommen.
0:23
Halli Hallo und herzlich Willkommen hier zum Coding
0:26
Buddies Podcast, Deinem Softwareentwicklungspodcast.
0:30
Und zwar mit mir, dem Fabi und dem Tino.
0:33
Der darf nicht fehlen, der sitzt mir gegenüber.
0:35
Er hat Bock, glaube ich jedenfalls.
0:37
Sieht so aus. Auf jeden Fall.
0:39
Wie geht's der Tino Fabi, Was geht ab?
0:42
Ja, mir geht's gut, mir geht's gut, ich hab Bock, ich hab
0:45
richtig Bock. Das ist schön.
0:47
Ich weiß nicht übers Wetter, ich, ich hab mir heute
0:49
vorgenommen, nicht mit dir übers Wetter zu reden, also hast du
0:51
vielleicht irgendwie so n anderes Einstiegsthema liegt dir
0:54
was auf dem Herzen, mir liegt nichts auf dem Herzen, ich hatte
0:58
letztens ne ganz coole ne ganz coole Sache die mir passiert
1:01
ist. Ich hab ne Pizza einfach so
1:02
umsonst bekommen war geil OK das war.
1:05
Valentinstag von meinem heimlichen Verehrer oder meiner
1:10
heimlichen Verehrerin? Ich weiß es nicht genau, ja.
1:13
Also das ist schon, das ist schon wieso n Hollywood Film als
1:15
du mir das erzählt hast, ne, dass du einfach so auf die
1:17
Straße gehst, dir denkst, oh ich hab super Hunger, ich muss mal
1:21
was einkaufen und dann so n Lieferando liefer Dude vorfährt
1:26
und sagt hast du Bock auf ne Pizza also sorry wann passiert
1:30
sowas feiges war bezahlt ja und das krasse war dabei, das ist
1:34
auch noch er sagt. Ne Mexican mit extra Käse und
1:40
ich dacht mir so. OK, cool, geil, das ist mein
1:45
Tag. Mehr Frau zu sagen, also es ist
1:48
ja nicht so, als wär das irgendwie vielleicht auch nicht,
1:51
also als hätte es nicht gepasst. Weißt du, dass ich mir sage, so
1:53
i Brokkoli oder so, ich mag Brokkoli, aber ich mein so als
1:56
Beispiel, also so Hawaii, weißt du wo dann Ananas drauf ist?
2:00
So ja mag man ja vielleicht nicht, ja, sowas war es ja
2:03
nicht, sondern einfach was geiles ja und scharfmarkig ja
2:06
und extra Käse gut braucht man nicht drüber zu reden hat.
2:09
Heute Tag extra Käse mag ja jeder, oder?
2:11
Ja. Und ich denke.
2:13
Jeder, vielleicht nicht jeder ich.
2:15
Wollte. Eigentlich wollte ich einkaufen
2:16
fahren ne und hatte übelst Hunger und dachte noch so hey
2:19
kannst nicht machen ja ohne also mit Hunger einkaufen fahren ja
2:23
nee aber hat sich ja ganz gut gefügt mit einer Pizza.
2:29
Weißt du was richtig witzig wär, wenn unter unseren Zuhörerinnen
2:32
und Zuhörern jetzt derjenige oder diejenige ist, die, die
2:35
eigentlich bestellt hat und noch wartet, dann melde dich, fabi,
2:39
schuldet dir ne Pizza. Ey, der Typ.
2:42
Von die Frau hat gesagt, Falls die falls, die noch mal anruft,
2:47
die Person ja, dann schick dir eine neue.
2:50
Also das ist fair, das ist fair, das ist fair.
2:53
Dann hätte er 2 Personen glücklich gemacht an dem Tag,
2:56
weil du warst definitiv glücklich, du hast mir ja direkt
2:58
geschrieben, was für ein freudiges Ereignis das gerade
3:01
war und ich habe mich auch wirklich richtig für dich
3:03
mitgefreut, muss ich sagen, ich hatte zwar selbst Hunger in dem
3:05
Moment, ich war so so ein bisschen neidisch, ja.
3:08
Ich bin erst mal vor die Tür gegangen, hab geguckt, da kam
3:10
aber niemand. Schade, aber ich gönn dir das
3:15
auf jeden Fall und ich wünsche es und ja, ich glaube aber sowas
3:21
wird so schnell nicht wieder passieren, wenn doch dann krass.
3:24
Also das ist doch so n Once and a lifetime oder?
3:28
Ja das auf jeden Fall Ah herrlich herrlich ja.
3:35
Ich hab n ganz cooles Thema mitgebracht heute Fabi, deswegen
3:38
möchte ich auch mit dir reinstarten, weil ich glaube es
3:40
wird n bisschen dauern. Es ist n umfangreiches Thema und
3:44
ich sag mal nicht so trivial und auch n bisschen technischer
3:50
heißt ich möchte mit dir heute mal wieder in Richtung Def Ops
3:54
gehen, wir haben ja ne def Ops einsteigerreihe gemacht.
3:59
Ja so mit den Grundlagen. Mit ja eigentlich mal so ne
4:03
klassische CICD Pipeline besprochen wie die aussehen
4:07
kann, wie man sie umsetzen kann. Liebe Zuhörer, lieber Zuhörer,
4:11
falls du dich fragst, diese folgen sind aber glaub ich an
4:13
mir vorbei gegangen, dann schau noch mal.
4:15
Es ist schon ne Weile her zurück, ansonsten findest du
4:18
auch ne Playlist von uns auf Spotify zum Beispiel mit allen
4:23
Folgen die wir zu Def Ops gemacht haben, also hör da auch
4:26
gerne mal rein, wenn dich das Thema interessiert und du sagst
4:29
Ey mit def Ops hab ich mich noch nicht so beschäftigt.
4:31
Das wird heute in der Folge nicht wichtig sein, um es
4:35
grundlegend zu verstehen, was wir heute erzählen, sage ich
4:39
mal. Aber um das ganze besser in
4:40
Kontext zu passen, Aufzupacken auf jeden Fall, denn ich würde
4:45
sagen, es ist schon wieder eine Einstiegsfolge in ein neues oder
4:49
erweiterndes Thema, ne? Aber halt nicht ganz so Basic
4:55
wie jetzt CICD an sich. Ich hoffe ich hab es gut gut
4:58
eingeordnet für dich und für die Zuhörer.
5:00
Fabi Wir wollen heute über Gate Ops reden.
5:04
Genau, also ich sag mal so, ja wenn jetzt die Junioren, wenn
5:08
man das so nennen mag, dabei sind ja die Folge ist trotzdem
5:12
dafür, dass man quasi Verständnis schafft, wenn man
5:16
jetzt so auf dem Mitlevel ist, dann hat man einfach noch mal
5:20
so. Tipps für vielleicht stabileres
5:23
Deployment? Ja, und für Senior oder Leads
5:26
sag ich jetzt mal, das ist einfach noch mal so n kleiner
5:28
Reminder. Ja ey gibt es ja, bestell es
5:32
doch um. Ja, wenn du es ist.
5:34
Ich find reminder ist auch n gutes Stichwort, weil in dem
5:37
Zuge wo ich jetzt mir überlegt hab oder wir uns überlegt haben,
5:39
ey lass doch über Git Ops reden, war das auch noch mal so ganz
5:43
interessant noch mal wirklich zu durchdenken warum?
5:46
Gibt es das? Warum fahren viele darauf ab,
5:49
warum setzen wir auch selbst auf dieses Modell?
5:53
Ja, das kann man ja schon mal vorwegnehmen, was wir heute
5:56
erzählen, nutzen wir selbst für unsere Coding Buddies,
6:00
Infrastruktur und Systeme und es war halt cool noch mal zu sehen,
6:04
ja ach ja, genau deswegen ja richtig und ja genau.
6:10
Aber lass uns doch noch mal ganz kurz zusammenfassen.
6:16
Eine klassische CICD Pipeline. Sie wird gerade in der
6:21
Gegenüberstellung mit Git Ops auch oft CI Ops genannt, da
6:26
jetzt nicht verwirren lassen an der Stelle, wir reden in dem
6:29
Zuge dann nicht nur von dem Continuous Integration teil,
6:34
sondern von so einer klassischen.
6:37
CICD Pipeline, ein CI Server, der aber irgendwie ja doch mehr
6:42
macht als nur Integration und Artefakte bauen, sondern
6:45
irgendwie auch Deployment beinhaltet.
6:47
Jeder kennt das, der vielleicht mal so ganz einfache Pipelines
6:50
gebaut hat. Und im Endeffekt steckt dahinter
6:54
das schon mal vorweg, eine Strategie, ein Modell, das Push
6:58
Modell und das wollen wir heute mal mit Git ops.
7:02
Spoilerwarnung ist halt kein Push.
7:04
Modell, das heute mal gegenüberstellen.
7:07
Ja genau, ich würde dazu noch sagen, dass zum Beispiel weil du
7:10
auch Def Ops erwähnt hattest, wenn man jetzt von def ops
7:13
redet, finde ich, sollte man es so einordnen oder ist es halt
7:16
so, dass Def Ops. Ich sag mal nen ne Art Mindset
7:20
ist oder ne Art Kultur mit einer bestimmten ich sag mal Palette
7:25
von Prozessen die man nutzen kann, wo es viel um
7:27
Automatisierung geht ne und wenn man jetzt sagt OK wir wollen
7:30
jetzt aber def Ops nehmen, ja und jetzt nicht sagen OK git Ops
7:35
ist aber sozusagen def Ops plus in dem Sinne sondern Git Ops ist
7:40
genauso wie CI ops so wie du es gerade beschrieben hast.
7:44
Es sind ja ich sag mal konkrete Betriebsmodelle von defops ne,
7:50
also defops sagt Denk dran, dass du Dinge automatisieren sollst.
7:54
Ne, also ob es jetzt Fehlermeldungen sind die du
7:56
siehst, die du schnell erkennst, die automatisiert dir gemeldet
7:59
werden oder vielleicht auch, dass du n irgendein Deployment
8:01
machst, was schief geht und es automatisiert wieder gerade
8:05
gebogen werden soll, solche Dinge, das sind ja Konzepte und
8:10
die konkret umzusetzen, das ist dann am Ende natürlich die
8:13
Frage, wie man es macht, ne und genauso wie CI OPS.
8:17
Es. Git Ops sozusagen auch eine
8:19
Möglichkeit dazu? Ne ja, absolut und ja, git ops
8:25
ist quasi so über die Jahre so diese Weiterentwicklung, aber
8:28
lass uns mal drüber sprechen warum es überhaupt notwendig war
8:31
oder warum es es hat ja immer Gründe warum Entwicklerinnen und
8:36
Entwickler sich denken. Wir müssen uns irgendwie noch
8:39
was überlegen. Wir müssen vielleicht noch das
8:41
Modell erweitern, ja, oder auch wie du meinst im Death Ops
8:44
Gedanken das ganze noch weiter tragen als wir es bisher tun und
8:49
da möchte ich mal so auf ne klassische Pipeline gehen, so
8:52
wie wir sie ja auch anfangs wieder betrieben haben, nenne
8:57
ich es mal. Also alles was wir heute
8:59
erzählen ist ja nicht so, dass man sich denkt, jetzt weiß ich
9:02
was git ops ist nur noch git ops, so weißt du.
9:05
Sondern es ist ja auch immer nen nen Prozess sag ich mal ne
9:09
Entwicklung ne Einschätzung zu dem Projekt was wofür möchte ich
9:14
das gerade verwenden? Ist es notwendig, brauche ich
9:16
das wirklich, ist es n bisschen over the top?
9:19
Ja das ich mein das sagen wir bei vielen Themen, aber es ist
9:21
leider halt auch immer so, dass man das natürlich projektbezogen
9:24
entscheiden muss. Für unsere Systeme hatte ich ja
9:28
schon gesagt, haben wir uns wieder dafür entschieden, aber
9:32
wir sind von diesem klassischen. Hinzu git Ops gegangen.
9:37
Wir haben ja auch ganz am Anfang gesagt, Hey, wir brauchen ne
9:40
Website, lass mal ne einfache Pipeline aufbauen und das
9:44
entsprach eher einer CI Ops Pipeline.
9:48
Ja so wie wir sie jetzt heute definieren als Modell und nicht
9:52
einer Git ops Pipeline nenn ich es mal.
9:55
Ja ja. Und deswegen finde ich das Thema
9:58
halt auch so cool, weil es zeigt halt auch einfach, dass es auch
10:01
n Entwicklungsprozess ist. Und genau dafür steht ja def
10:04
Ops. Ne, dass man sich dahingehend
10:06
auch weiterentwickelt. Auf jeden Fall.
10:10
Also ich kann ja mal n bisschen noch mal das ganze kurz
10:15
beschreiben, dass man sagt, OK, was ist denn jetzt so CI ops ne,
10:19
also du meintest ja auch schon, das ist so n push Modell ja also
10:22
das heißt. Wenn wir jetzt am Beispiel
10:24
unserer zum Beispiel unserer Website von der Coding Bodies
10:27
Website sind, dann haben wir gesagt, OK, wir haben halt
10:30
irgendwo unser Repository, wir machen Changes am Repository, es
10:34
laufen zum Beispiel Tests, ne um zu gucken, ob neue Änderungen
10:38
neue Changes integriert werden können in die Codebase und wenn
10:41
das der Fall war, dann deployen wir die neue Version, sodass es
10:45
halt eben. Auch ne die aktualisierte
10:48
Version verfügbar gemacht wird. Das heißt du hast irgendwie NCI
10:51
System was am Ende noch sagt OK ich pushe jetzt das Artefakt was
10:56
ich zum Beispiel erzeugt habe oder ne was was da ist push ich
10:59
jetzt in die in in auf Port sozusagen dass du es halt
11:03
einfach verfügbar machst. Das heißt du hast ja ne dieses
11:07
dieses Push Prinzip etwas erstellt das und du schiebst es
11:10
dahin wo es hin soll ne also das ist ja so als würde.
11:14
Weiß ich nicht. Ich jetzt zum Beispiel, oder
11:18
sagen wir mal Postbote. Ne Postbote ist auch n Push
11:21
Prinzip ja also der kommt zu dir und sagt OK es gibt irgendwie n
11:23
Brief hier bitteschön komm zu dir und gib dir das als Beispiel
11:26
ne so und so. Full er wirklich zum
11:27
Briefkasten? So genau so und so funktioniert
11:30
das halt ne und das kann man ja auf jeden Fall so machen.
11:33
Und wie du meintest, wir hatten das ja so gemacht und sind dann
11:36
irgendwann wieder auf Git Ops gegangen.
11:37
Bisher ist ja irgendwann wieder, also wir sind dann auf Git Ops
11:40
gewechselt. Ich finde, es hat aber auch ein
11:42
paar Gründe gehabt, ne und es hat aber auch Gründe gehabt zu
11:44
sagen, wir haben es erstmal so gemacht, wie wir es gemacht
11:48
haben mit diesem push Prinzip ne weil es halt eben auch nur diese
11:53
eine Website gab. Es war nicht vieles war nur
11:55
dieses kleine und dafür hat es erstmal völlig ausgereicht.
11:59
Genau da steckten ja nicht mehrere Systeme denn dahinter,
12:02
sondern es war ja anfangs wirklich eine reine
12:03
Informationsseite, die sich ja auch nicht oft geändert hat,
12:07
oder irgendwas. Wir haben da jetzt nicht täglich
12:10
dran entwickelt, sage ich mal. Also es war auch sehr statisch,
12:13
das ganz der ganze Projektkontext, sage ich mal.
12:16
Und da war das auch genau richtig, weil es sich ja auch
12:18
schnell umsetzen lässt. Ja, aber was da natürlich Fakt
12:23
ist, um das pushen zu können, und da kommen wir mal auf einen
12:26
Punkt, der auch sehr entscheidend heute sein wird.
12:28
Ist, dass ich natürlich Zugriff brauche aus meiner CI heraus sag
12:34
ich mal ne, also aus meinem sei es der CI Server.
12:38
Wie auch immer, ich hab aber in dem Schritt wo ich diese
12:41
Continuous Integration mache und quasi Änderung integriere,
12:46
Artefakte erzeuge und jetzt sage ich push sie gleich aktiv ja auf
12:51
Prot beispielsweise setzt das natürlich voraus, dass ich auch
12:55
Zugriffe darauf brauche. Ja, das heißt, ich muss ja
12:58
Zugriff auf mein Prot System haben.
12:59
Ich muss secrets haben. Ja, also in dieser ganzen
13:03
Umgebung, in der ich mich gerade befinde, müssen ja auch gewisse
13:06
Secrets vorhanden sein, sonst funktioniert das ja am Ende
13:09
nicht, weil ich einfach keinen Zugriff hab.
13:10
Also ich sollte keinen Zugriff haben, wenn ich die Secrets
13:13
nicht habe. Ja und oder auch so im
13:16
kubanettes Kontext. Ich muss natürlich dann Zugriff
13:19
aufs Cluster haben und so weiter das heißt man merkt da sind so n
13:23
paar Sicherheitsaspekte die man berücksichtigen muss an der
13:26
Stelle. Und Fakt ist auch, dass ich an
13:29
der Stelle die komplette Deployment Logik brauche.
13:33
Ja, wenn diese natürlich sehr simpel ist, wie wir es gerade
13:36
gesagt haben, anfangs ist es einfach nur kommt Sheeps auf
13:39
prot und fertig, ja dann ist die die Logik dahinter nicht sehr
13:43
umfangreich und komplex, dann kann man sagen ja OK dann.
13:46
Machen wir das da halt mit rein. Es ist irgendwo Continuous
13:49
Integration und Continuous Deployment, aber es passiert
13:53
alles in einem Kontext, sozusagen auf dem gleichen
13:56
System. Ja, und das bringt natürlich
14:00
Probleme mit sich, ne, also wo ist jetzt zum Beispiel so ne
14:04
richtige Single Source of Truth? Ja oder dieses typische Ach
14:10
komm, wir ändern mal schnell was, hau mal rein.
14:13
Dann wird das gleich gepusht. Das geht gleich auf Prot.
14:16
Wenn dann irgendwas passiert huiuiui, dann machst du noch
14:20
schnell n paar Hotfixes, schiebst das direkt hinterher.
14:24
Worst Case gerade, aber das kann ja passieren, dass du auch bei
14:27
einer einfachen Website sagst, komm ich mach mal was neues
14:30
rein, oh warte, warte, warte, warte, hier geht gar nichts mehr
14:33
gerade oh oh gleich mal n Hotfix hinterher geschoben, weil du
14:37
auch gar nichts anderes machen kannst.
14:38
Dann an der Stelle außer. Erneut zu Deployen ja, also
14:43
wieder was rauf zu pushen und das sind so worst case Szenarien
14:46
wo man sich denkt Oh das so n bisschen separieren voneinander
14:51
wär schon nicht schlecht. Aber du kannst ja auch, du
14:55
kannst ja auch soweit gehen und sagen, du hast, sagen wir mal,
14:58
wenn du jetzt so größere Cloud Services ne bist ne, da kannst
15:02
du ja auch so NCI Ops umsetzen, kannst aber gleichzeitig dann
15:06
auch. Wie willst, wie will ich das
15:09
jetzt am besten beschreiben? Du hast deine deine Umgebung,
15:11
die etwas irgendwo hin pusht, ne auf die entsprechende prot
15:14
Instanz und die prot Instanz, die hat halt bestimmt auch ich
15:17
sag mal konfigurationsparameter und so weiter das kannst du
15:20
natürlich alles irgendwo in deiner, also in deinen deinen so
15:25
infrastructures Codemäßig abbilden in so einer
15:27
Konfiguration die du dann sozusagen auch über diese diese
15:32
ganz also dass dass du das alles aufsetzt, ne darüber, aber du
15:36
hast immer noch die Möglichkeit, zum Beispiel dann auch bestimmte
15:39
Dinge selbst zu verändern. Also du kannst ja zum Beispiel
15:42
dann reingehen und manuell Veränderungen machen, was aber
15:47
dann zum Beispiel auch wiederum dazu führen kann, wenn du nicht
15:49
aufpasst, dass du halt so ne Art Drift hast zwischen deinem
15:52
System, ja, was du eigentlich im Code hast, was wo du eigentlich
15:56
davon ausgehst, das ist jetzt gerade irgendwie diploid,
15:59
genauso wie es ist. Und auf der anderen Seite hast
16:02
du aber irgendwo einen manuellen Step gemacht, weil du vielleicht
16:05
genau dieses Verhalten gerade hattest.
16:09
Was du angesprochen hast. Irgendwas funktioniert nicht.
16:11
Ich mach mal ganz kurz was um zu gucken ob es geht.
16:14
Du vergisst irgendwas wie auch immer, am Ende kannst du halt
16:17
einen einen Drift erzeugen zwischen dem was du eigentlich
16:20
in deiner Source truth hast und was dann tatsächlich aber
16:23
wirklich produktiv läuft und das ist halt auch so ein kleines
16:28
Problem. Ja, und genau das ist sogar der
16:31
das Kernproblem, weswegen man ja gesagt hat okay, lass uns mal
16:35
das Ganze weiterentwickeln, weil man quasi die Aussage getroffen
16:39
hat, wenn dein Live System, wie du es ja gerade besprochen hast,
16:43
nicht vollständig reproduzierbar ist.
16:45
Aus Git zum Beispiel aus deiner Versionierung, dann hast du halt
16:49
ein strukturelles Problem, ein Risiko, vor allem was dir früher
16:53
oder später in die Suppe spucken kann und.
16:57
Ja, das ist nämlich auch n gutes Stichwort.
17:00
Wenn wir nämlich über reproduzierbare Infrastruktur
17:02
sprechen, dann braucht man natürlich auch eine saubere
17:05
Basis. Da fängt es ja schon beim Server
17:07
an. Ne, man braucht ne Basis auf die
17:09
man sich verlassen kann und an der Stelle muss ich mal ganz
17:12
kurz Werbung machen. Denn für unsere codingbuddies
17:15
Systeme nutzen wir unter anderem auch.
17:17
V Server und da können wir wärmstens die Server von unserem
17:21
heutigen Werbepartner Strato empfehlen, denn Strato hat
17:24
aktuell wieder absolute No brainer Angebote.
17:27
Ja Tino, ich find es auch krass, weil es ist einfach.
17:29
Du bezahlst einen schmalen Taler und kriegst einfach für ein paar
17:33
Monate so diese Server zum Testen.
17:36
Und das ist absolut geil, um das einfach mal auszutesten und
17:40
genau das, was wir in dieser Folge besprechen, auch wirklich
17:42
mal umzusetzen. Selbst wenn man nur keine
17:45
Ahnung. Eine Testumgebung für kleine
17:46
Mini Projekte aufsetzt. Ja also gar nicht mal das Ziel
17:49
hat groß Webseiten zu betreiben, Backends zu betreiben aber
17:53
einfach mal in die Welt einzutauchen und es mal für sich
17:56
produktiv umzusetzen, auch zum Beispiel Git Ops ist.
17:59
Das natürlich absolut Gold wert und man muss natürlich sagen,
18:03
Strato bringt auch richtig coole Eigenschaften mit ihren Servern
18:06
mit sich. Also allein schon der
18:08
Datenschutz. Ne es ist auf jeden Fall DSGVO
18:10
konform, die Rechenzentren sind in Deutschland.
18:13
Das sind einfach Dinge, die sind heutzutage, glaube ich,
18:15
wichtiger als den je. Und was natürlich auch ein
18:17
richtig cooler Punkt ist und auch wichtiger denn je ist
18:20
natürlich ihr Green Hosting Ansatz.
18:22
Also wenn du Bock hast auf einen neuen Server oder vielleicht
18:25
deinen allerersten Server, dann schau gerne bei uns in die Show
18:28
Notes, da findest du den Link zu den Strato angeboten mit diesem
18:32
Link unterstützt du uns und das Projekt Coding Buddies auch
18:34
zusätzlich dann vielen Dank dafür und jetzt geht es weiter
18:38
mit der Folge Werbung Ende. Und ich finde es halt auch
18:43
spannend, dass du ja vorhin gesagt hast, das ist so Mindset
18:46
und Modell. Also du hast ja Def Ops als
18:48
Mindset auch bezeichnet, da gehe ich auch ganz mit und ich finde
18:52
spannend hierbei ist, wenn wir jetzt, ich nenne es jetzt noch
18:54
mal ci ops und git Ops vergleichen, dann stellen wir
18:58
auch 2 verschiedene Ansätze, auch Denkansätze gegenüber, die
19:03
da verfolgt werden, das. Dein Punkt war ja klassisch
19:07
Infrastructure is CODE. Wie sieht das oft aus?
19:11
Infrastructure is Code sieht ja oft so aus im ganz einfachen
19:15
Kontext gesprochen, dass es immer so Befehle sind, ne mach
19:19
das. Mach das und jetzt machst du das
19:22
Beispiel. Teste ob die Änderung richtig
19:26
ist. Bau das ganze und jetzt pushe es
19:29
hoch und lass es produktiv laufen.
19:31
Ganz ganz simpel ausgedrückt, aber das könnte ja so die
19:34
Reihenfolge sein. Ne ich teste noch mal ob die
19:36
Änderung in Ordnung ist. Ich integriere sie, baue dir
19:38
meine Software und schiebe sie hoch.
19:40
So, das Ganze ist ja sehr imperativ gedacht, ne?
19:44
Also so befehlsform ne, also mach das, mach das und jetzt
19:48
machst du das, jetzt machst du das und jetzt bist du fertig und
19:51
die von diesem Ansatz ja oder auch sowas wie Installier die
19:56
Abhängigkeiten vorweg ja auch ganz gefühlt immer drin.
19:59
Ne für deine Software, die Abhängigkeiten müssen ja erstmal
20:01
irgendwie gegeben sein, aber das ist alles so stepweise Befehle
20:06
die ausgeführt werden sollen. Und bei Git Ops geht man jetzt
20:09
aber so einen deklarativen Ansatz und sagt nicht mehr macht
20:13
das Macht das Macht, das Macht das, sondern beschreibt was
20:17
möchte ich, wie soll das Aussehen am Ende, wie soll mein
20:20
System aussehen, das heißt, ich konzentriere mich auf eine
20:24
Zustandsbeschreibung am Ende ja, also wie stelle ich mir den
20:30
Zustand vor, wie er am Ende aussehen soll und nicht mehr als
20:33
Schritt für Schritt befehlsanleitung Abfolge.
20:37
Befehlskette wie das, dann weißt du was ich meine und das hat bei
20:44
mir jetzt, wo wir auch die Systeme quasi umgestellt haben
20:48
beziehungsweise den ganzen Ansatz unseres unserer Pipeline
20:53
sag ich mal ne umgestellt haben war das für mich erstmal wieder
20:56
n Step dieses Umdenken gar nicht so einfach, weil du fängst
21:02
wieder an im Kopf zu sagen OK was müssen wir machen.
21:05
OK, erstmal die Abhängigkeiten auflösen, sehen, dass alles da
21:10
ist. Die Tests auf jeden Fall müssen
21:12
die Tests erstmal laufen und so weiter ne und davon gehst du weg
21:17
mit dem Ansatz um einfach Komplexität da auch rauszunehmen
21:20
dir nicht halt gleich direkt zu überlegen welche Steps müssen da
21:23
alle rein, vor allem um Reihenfolgefehler zu vermeiden,
21:27
weil bei umso komplexer. Es wird also jetzt von der von
21:31
der Abfolge der Befehle her, umso mehr musst du drauf achten
21:34
Boah hab ich hier irgendwelche Abhängigkeiten?
21:35
Abhängigkeiten? Kann ich das überhaupt vor dem
21:37
machen oder sollte ich vielleicht doch noch Schritt c
21:40
erstmal machen? Ei und außerdem diese Abfolge
21:46
wie du ja meintest, menschliches Eingreifen hier mal was ändern,
21:49
da mal was ändern. Ist das überhaupt alles so noch
21:52
auf Prot wie ich das gerade hier vor mir sehe?
21:54
Das ist schwierig und davon will man halt weggehen mit einem
21:58
deklarativen Ansatz. Ja.
22:02
Also im Endeffekt ist es ja dann so, dass du quasi deine
22:06
Deployment Umgebung hast, die nicht mehr darauf wartet, dass
22:11
etwas, dass sie etwas bekommt, sondern diese Umgebung zieht
22:15
sich aktiv, dann sozusagen das was es braucht von dort, wo es
22:21
weiß wo es das gibt was es braucht, ne was ja nicht mehr
22:26
heißt, dass du sagst, OK, man muss irgendwie, man braucht sich
22:29
jetzt nicht mehr darum kümmern, dass man sagt, OK, die Tests
22:31
müssen nicht laufen. Würde ich jetzt ne.
22:33
Also das das ist ja trotzdem. Also du hast ja so als Beispiel,
22:37
du hast dein Repository in in github zum Beispiel und Du nutzt
22:41
vielleicht github actions um mal so ein konkretes Beispiel zu
22:44
nehmen, dann hast du ja trotzdem auf einem auf einem Push ne der
22:48
irgendwie stattfindet auf dein Repository irgendeine Action die
22:51
Losläuft, also zum Beispiel sowas wie natürlich muss erstmal
22:54
gecheckt werden, dass die Tests laufen, damit die Tests laufen,
22:57
muss man vielleicht auch noch irgendwelche Abhängigkeiten
22:59
installieren, so. Und wenn das aber in Ordnung
23:03
ist, dann wird mehr oder weniger.
23:04
Ich nenn es jetzt mal dieses Artefakt bereitgestellt und
23:06
gesagt, OK, wir sind jetzt erst mal soweit fertig und wären
23:10
bereit ne etwas, also wir können etwas anbieten, aber wir pushen
23:16
es nicht auf die auf die Deployment Umgebung, das ist
23:20
nicht mehr sozusagen der Sinn, sondern es kommt ja dieser Pull,
23:25
also dieses die Deployment Umgebung checkt dann warte da
23:29
ist was Neues. Das hole ich mir mal selber.
23:33
Genau. Und das ganze ja, weil ich, und
23:36
das finde ich halt so cool, an dem Ansatz jetzt sage Git meine
23:42
Versionierung ist die absolute Single Source of Truth, was in
23:47
Git steht in den Comits das zählt, und du hast ja jetzt
23:52
schon quasi angefangen, so n bisschen zu beschreiben, wie das
23:55
Ganze unter githops githops aussieht ja nicht mehr.
24:01
Ich mach ne Continuous Integration und ja ist fertig.
24:04
Na gut, dann ich will das jetzt auch verwenden, also Push ist
24:07
hoch ne dass ich so aktiv treibe, sondern es ist jetzt
24:11
wirklich ne Integration, das heißt wenn wir jetzt zum
24:14
Beispiel über Github sind und github actions nutzen, ich lass
24:17
meine Tests laufen, alles ist grün, alles ist super, die
24:21
Codeänderung beispielsweise auf dem Pull Request sehen gut aus,
24:24
es läuft alles grün, ja dann integriere ich das, das heißt.
24:28
Ich integriere es in meine codebasis, ich baue meine
24:32
Software, zum Beispiel unsere Website.
24:34
Ja, baue ich neu, das läuft auch durch und dann habe ich mein
24:39
Artefakt erzeugt, dass ich sage, es gibt eine neue Version meiner
24:43
Website beispielsweise, und das ist ja Continuous Integration,
24:49
so wie man sich das vorstellt, ja, aber an der Stelle ist das
24:53
von der Seite aus beendet. Ja, also ich habe n Artefakt
24:57
erzeugt und ich kann eine neue Auslieferung bereitstellen, aber
25:01
ich drück sie nicht gleich irgendwo hin und weiß nicht mehr
25:04
wo überhaupt noch irgendwo was liegt, sondern jetzt kommt
25:07
nämlich der Unterschied warum man sagt Git ist jetzt die
25:10
Single Source of Truth. Bei Git Ops habe ich noch eine
25:16
weitere Instanz, beispielsweise ein Infrastructure Repository.
25:22
Was macht das Ganze? Das Ganze sorgt dafür, dass ich
25:28
diese Deployment Strategie ja, also im Prinzip die
25:34
Konfiguration meines Deployments ebenfalls versioniere.
25:39
Das heißt, ich hab jetzt beispielsweise n ein n einzelnes
25:42
Repository, wo jetzt drin steht, da gibt es ja verschiedene
25:46
Möglichkeiten und Tools, die das unterstützen.
25:48
Wir sind jetzt wirklich nur auf der Theorie modellebene ne, also
25:51
es gibt ja unterschiedliche Tools das umzusetzen.
25:55
Aber da definiere ich jetzt zum Beispiel Deklarativ.
26:01
Ja, es gibt eine Website und ich wünsche mir, dass sie so und so
26:07
deployed wird, dass sie darunter erreichbar ist, dass sie das und
26:12
das Macht. Alles, was ich mir so vorstelle
26:14
und mir von meiner Website wünsche, und ich wünsche mir,
26:17
dass es in der Version xy ist so.
26:22
Und das ist nämlich der entscheidende Punkt.
26:25
Darüber wird definiert, welche Version erwarte ich denn
26:29
überhaupt in zum Beispiel productive wie du meintest das
26:34
überhaupt erstmalig versioniert ist?
26:37
Was soll denn überhaupt live laufen, weil bei dem anderen sag
26:42
ich mal feiern forget ich push, das wird klappen, ja hat
26:45
geklappt, gut, da läuft jetzt ne Version.
26:48
Aber ich kann das nicht reproduzieren, und das ist genau
26:50
der entscheidende Step, in dem ich jetzt sage, wir packen das
26:53
in ein Repository, ich kann es reproduzieren, ich kann
26:56
jederzeit sämtliche Konfigurationen davon ja auch
27:00
wiederherstellen und zeigen, dann lief die Version hier und
27:03
so weiter und das sind halt noch, das wird noch sehr wichtig
27:06
für die guten Eigenschaften, die Git, ob es dadurch ja mit sich
27:09
bringt, ja, also. Ich habe jetzt ein Repository,
27:13
was mir den deklarativen Zustand beschreibt, wie es ist.
27:17
Das heißt, ich muss ja jetzt nur noch nachschauen, welcher
27:20
Zustand ist gewünscht und ziehe mir sozusagen die Version, die
27:25
ich ja mit Continuous Integration immer bereitstelle.
27:28
Mhm. Die gewünschte Version und lass
27:31
die in Prot. Laufen beispielsweise.
27:34
Ja, also ich find es erstmal ganz gut, weil ich.
27:37
Als ich das erst mal git ops gehört hab, ne, da denkst du
27:39
erst mal OK was das ist wieder für n Quatsch ne also irgendwie
27:42
git ops klingt wie def ops was wieso git ops ne und ich finde
27:46
es ist ja auf jeden Fall gut um das noch mal konkret also
27:50
wirklich auf den Punkt zu bringen, du hattest es auch
27:52
schon gesagt, Git Ops ist nicht def Ops mit git so nach dem
27:56
Motto Ja wir machen jetzt def Ops und nutzen dafür git sondern
27:58
es geht ja darum, dass du wirklich diese Single Source of
28:01
Truth wie du meintest in Git hast.
28:04
Und das was du meinst, es ist halt mit dieser Versionierung
28:08
zum Beispiel, es ist ja n totaler Vorteil, weil du genau
28:11
diese Versionierung auch wirklich mehr oder weniger als
28:14
commit irgendwo in deinem Infrastructure repo dann hast.
28:18
Du weißt ja genau, diese Version wurde erzeugt und du kannst
28:21
nachverfolgen aus welchem Commit diese Version kommt.
28:25
Ne, also du kannst mehr oder weniger sagen, diese Änderungen
28:28
sorgen für diese Version und Sorgen für dieses Deployment.
28:32
Und das ist ja totaler Vorteil, den du unter Umständen in diesem
28:38
ne CI, ob sie das genannt haben ja nicht unbedingt hast.
28:40
Also du weißt nicht, OK, du musst ja immer gucken welcher
28:44
Pipeline run ist das, welche Änderungen wurden da gemacht, in
28:47
welchem Environment und so weiter also da es kann da auf
28:50
jeden Fall zu n bisschen kuddelmuddel kommen und das ist
28:52
natürlich absolut klar definiert dabei.
28:55
Und weil du ja gemeint hast so das die guten Eigenschaften ja
28:59
ich find wir können ja gleich, wir können ja direkt mal n
29:01
bisschen diese guten Eigenschaften mal so auf so
29:03
präsentieren, weil und ich finde das ist NN unglaublich
29:08
spannender Punkt, auch diese der der Sicherheitsfaktor ne wenn du
29:13
zum Beispiel sagst du hast irgendwie in der CI Pipeline,
29:18
die braucht die. Also deine sagen wir mal.
29:21
Nennen wir es mal CI Umgebung ne deine CI Umgebung braucht alle.
29:24
Credentials ne um halt eben n Deployment zu machen und
29:30
angenommen ja, wir würden jetzt mal das Gedankenexperiment
29:34
durchspielen und sagen, irgendein Angreifer schafft es
29:38
deine CI Umgebung zu kompromittieren, dann hat er die
29:42
komplette Kontrolle darüber neue Dinge zu deployen, auch Mhm.
29:48
Was, wohlgemerkt. Wir hatten ne Big Fails Folge
29:50
dazu ja auch schon passiert. Ist sowas ne, dass Angreifer
29:54
genau das geschafft haben, wirklich in die Def Ops Welt
29:59
einzudringen und so Schadsoftware zu verbreiten?
30:01
Also deswegen ist das n riesen Punkt den du da nennst ne genau
30:05
und das ist. Ja, zum Beispiel tatsächlich
30:07
nicht unbedingt der Fall, wenn du nach diesem Git Ops Prinzip
30:11
arbeitest, weil selbst wenn du die CI.
30:15
Kompromittieren kannst, heißt das ja noch lange nicht, dass du
30:18
sozusagen die auch wirklich die Deployment Umgebung
30:22
kompromittieren kannst beziehungsweise richtig, die
30:25
sind ja getrennt und solange das Deployment, solange man das
30:29
Deployment da, also die Deployment Umgebung getrennt
30:32
hat, davon die sich ja selbst die sehr selbst entscheidet nach
30:36
gewissen regeln, OK was hole ich mir hier eigentlich ne?
30:42
Dann hast du sozusagen. 2 Systeme und wenn du das eine
30:45
hast, hast du das andere nicht zwangsläufig.
30:48
Ne, das heißt du kannst nicht einfach irgendwas direkt
30:51
deployen, ja. Also.
30:55
Das ist halt wirklich n riesen riesen Punkt ne, dass ich halt
30:58
in der Lage bin dadurch dass ich den.
31:02
Das Deployment quasi extrahiert habe und eigenständig verwalte,
31:08
kann ich natürlich jederzeit auch sagen.
31:10
Ich gehe auf einen alten Zustand zurück, der absolut definiert
31:14
ist und reproduzierbar ist an der Stelle, weil es halt auch in
31:18
Git versioniert ist. Das heißt wie du meintest, die
31:22
können ja gerne den CI Server, sage ich mal ganz simpel
31:26
ausgedrückt hacken und irgendwie Versionen erstellen, die.
31:30
Die Schadsoftware beinhalten, aber dann sind das nur
31:33
Artefakte, die abholbereit sind, aber niemand muss sie abholen,
31:38
weil sie sich nicht selbst ausliefern sozusagen.
31:41
Das ist der Unterschied, ob der Postbote dir den Brief unter der
31:44
Haustür durchschiebt oder im Briefkasten legt und ich selbst
31:48
noch entscheide, ob ich den aus dem Briefkasten rausnehme, ja.
31:51
Also und ich finde, dass das ist halt wirklich n riesen Punkt
31:54
auch aus Security Sicht. Wenn du mal keine
31:57
Rechnungssätze. Hattest und das ansprichst super
31:59
Möglichkeit ne einfach nicht den Brief aufmachen, ja.
32:04
Ja oder so genau, weil es gibt. Natürlich dann unterschiedliche
32:11
Strategien, beispielsweise ich hab n Pull recurse ne neue
32:15
Änderung kommt rein, ne neue Version wird gebaut, dann kann
32:17
ich natürlich auch sagen. Das automatisiert, und das sind
32:22
so typische Kontrollmechanismen, die so Tools mit sich bringen,
32:27
die dann halt quasi so n Operator haben, der ständig auf
32:29
Changes guckt. Ja der dann mitkriegt ey es gibt
32:33
ne neue Version. Ja also.
32:35
CI ist gelaufen, Änderungen wurden integriert, alles Grün
32:40
gebaut, Artefakt abgelegt und ich krieg das mit, weil ich halt
32:43
n kontrollmechanismus hab, der quasi ständig den ist und den
32:48
soll Zustand vergleicht. Ja also an der Stelle soll
32:51
Zustand ist das was in meinem Repository steht ja also es gibt
32:55
jetzt zum Beispiel auf meinem Infrastruktur Infrastructure
32:59
Repository 9 commit ja. Das erkenne ich.
33:04
Das heißt, es gibt neuen soll Zustand an der Stelle, den ich
33:08
analysiere was? Ist mein ist Zustand.
33:11
Ist der Zustand in meinem Cluster?
33:12
Was läuft prod? Was läuft auf der Teststage?
33:15
Wie auch immer das aussieht, aber ich habe ja quasi immer den
33:18
Abgleich zwischen mein Repository und dem was ich
33:21
gerade aktiv laufen habe und verwalte und da dieser
33:26
Kontrollmechanismus gleicht, das dann zum Beispiel ständig ab und
33:29
dann kannst du natürlich sagen, ja, zieh dir das automatisch,
33:32
lass es laufen. Aber dann kommt der nächste
33:34
super wichtige Punkt an der Stelle.
33:37
Ich hab n has check, ich kann einfach prüfen, ist zum Beispiel
33:42
der Container den ich hochfahr für unsere Website jetzt
33:45
beispielsweise wie wir es hatten, ist der überhaupt
33:47
gesund, läuft der, hat der irgendwelche Fehler?
33:51
Ja, bei dem alten pushst du das hoch das Ding schmiert ab zack
33:55
seid ihr nicht erreichbar. Kriegst du mit oder kriegst du
33:58
nicht mit? Das ist denn dein Problem, mehr
34:00
passiert da erstmal nicht. Jetzt haben wir den Zustand
34:04
Monitoring ey warte mal das das läuft nicht, ich kann das nicht
34:07
hochfahren das Ding hier und der die der alte Container die alte
34:11
Version ist ja noch da, ist ja nicht so dass die Weg ist ja,
34:14
sondern es wird halt aktiv gemonitort ey das läuft nicht ja
34:17
gut dann machen wir n royback oder oder selbst wenn es
34:20
hochfährt und wir sehen ey nee warte mal die Änderung war
34:22
richtig Käse jetzt haben wir richtig bugs drin da was haben
34:24
wir da nur gemacht. Ist ja auch die Realität, dass
34:26
sowas passiert. Rollback.
34:28
Ich kann ja dadurch, dass es versioniert ist, immer wieder
34:31
auf nen definierten Zustand zurückgehen.
34:34
Ja das sind Riesen Vorteile die an der Stelle sich da ergeben.
34:37
Ja das auf jeden Fall das ohne dass ich jetzt in meiner
34:40
Codebase irgendwie zurückspringen muss, das darf
34:42
man ja nicht vergessen dabei ja meine Entwicklung, meine
34:45
Codebase von meiner Software hat damit ja gar nichts zu tun, ich
34:49
sag ja. Einfach nur ich.
34:51
Guck auf mein Infrastruktur repository.
34:55
Und. Sag im Endeffekt nee.
34:56
Das hier ist gerade nicht so gut.
34:57
Was war denn übrigens die Vorgängerversion nachher die und
35:00
die? Ja gut hier komm hab ich,
35:01
kriegst du ne wissen mal dass die läuft wenn du von einer
35:05
klassischen. Von von diesem klassischen CI
35:07
Ops oder einer ganz klassischen CICD Pipeline ausgehst.
35:11
Dann ne vielleicht. Noch mal so n bisschen.
35:15
Noch n Beispiel oder das noch mal so darzustellen, wir hatten
35:18
das ja auch schon mal, dass wir gesagt haben, wir.
35:21
Pushen etwas also auch in der unserer alten cicd Pipeline.
35:26
Da haben wir etwas gepusht und am Ende war es einfach, hatten
35:30
wir die Situation, dass die Website halt nicht mehr
35:32
verfügbar war, ne, weil es halt irgendwie einen Fehler gab so,
35:36
das heißt die Tests sind zwar durchgelaufen, ne wie gesagt,
35:40
zwar ist es auch sehr viel statischer Content, weshalb auch
35:43
quasi gar nicht so viele Tests dann funktional drin sind
35:48
demzufolge. War es quasi OK so n Check ne
35:52
und es wurde deployed, heißt aber noch nicht, dass unbedingt
35:56
auch wirklich immer alles abgefangen wird.
35:59
Dadurch so ne kann man natürlich auch verbessern, ist ja klar ne,
36:04
aber du hast halt die Situation, dass du in der Lage bist
36:06
bestimmt etwas zu deployen, was irgendwie nicht ganz hinhaut und
36:10
um das zu fixen, wenn wir jetzt einmal mal die Situation
36:13
annehmen, dann sagst du, OK, ich muss mal kurz im Code was
36:16
ändern. Pusht das wieder neu?
36:19
Die Pipeline läuft durch, ist die Ploid und es funktioniert
36:22
wieder ne, das wäre ja so der klassische Weg, so dieser
36:26
typische dieses typische ich fixe das ne ein Hotfix was auch
36:29
immer einspielen Zack funktioniert wieder geht wieder
36:32
alles gut ne oder wie du auch meintest ja du merkst ey diese
36:35
diese das irgendwie haben wir was eingebaut was echt blöd ist
36:38
ne. Neues Deployment anstatt einfach
36:42
nur zu sagen ich habe meine CI, also meine Deployment Umgebung
36:45
so nicht CI deployment Umgebung und kann einfach n rollback
36:49
machen ganz entspannt ne und das genau das hatten wir ja auch
36:53
erlebt, auch mit unserer neuen Infrastruktur wo wir gesagt
36:57
haben OK Moment warte mal das war n anderes Problem Probleme
37:00
kannst du immer irgendwie erzeugen das war glaube ich ne
37:02
falsche Docker Version das heißt am Ende.
37:06
Konnte man sozusagen konnte dieser Container nicht
37:09
hochgefahren werden. Das heißt, wir haben aber
37:10
gemerkt, OK, irgendwie, der Container ist nicht healthy,
37:14
also konnten wir einfach n rollback machen und demzufolge
37:16
mussten wir nichts am Code ändern, aber konnten uns in Ruhe
37:19
angucken, was eigentlich genau das Problem ist und konnten also
37:22
im Lokal nachstellen und konnten in Ruhe aber erstmal sagen wir
37:25
gehen noch mal auf die alte Version zurück, völliger Vorteil
37:29
ja. Und was dabei?
37:31
Auch ersichtlich wird ist, dass man auch so ein man spricht da
37:34
oft so von so einem vollständigen Audit Trail, weil
37:39
das Ganze ist vollständig nachvollziehbar am Ende, wenn
37:43
ich nämlich anfange, gerade in der alten Welt mit Hotfixes zu
37:46
arbeiten, und ich verfalle im Panikmodus, je nachdem, was für
37:49
ein Projekt das ist, so mal Hand aufs Herz, wenn unsere Website
37:52
mal eine Stunde nicht erreichbar ist, dann geht die Welt nicht
37:54
unter, ja, aber es gibt Projekte, wo das das Ende
37:58
bedeuten kann. Oder auf jeden Fall n großen
38:01
großen Schaden. Ja, und dann verfällst du in so
38:04
n Panic Mode, weil es ist passiert, wir müssen sofort
38:07
wieder live gehen, irgendwas muss passieren und in der alten
38:10
Welt sah das halt auch oft so aus wie du ja meintest.
38:14
OK warte mal, warte mal, warte mal commit noch mal raus,
38:16
zurück, noch mal pushen, los, noch mal hochschieben, das Ding
38:19
muss wieder laufen so ne und wo ist da die Nachvollziehbarkeit
38:24
hin? Wenn du sag ich mal Monate
38:26
später drauf guckst und also warte mal ihr habt etwas
38:29
committed. Dann habt ihr es.
38:31
So gesehen reverted. Habt den Stand davor wieder
38:33
committed, dann habt ihr fix committed, dann noch n fix, also
38:38
weißt du, also da, da ist ja die sämtliche, warum passiert etwas
38:43
wenn du das auch ständig in deiner Codebase wieder
38:45
zurücksetzt? Und so hast du die Möglichkeit,
38:48
dass ja geradliniger, sauberer. Zu entwickeln wie du meinst.
38:52
Du kannst es dir in Ruhe angucken.
38:54
Du kannst sagen, OK, dieser fix ist jetzt drin und der ist
38:56
passiert, sozusagen ne und darauf aufbauen, ohne dass du
39:00
irgendwelche Sachen wieder wegschmeißt oder so, weil du ja
39:03
diesen Prozess voneinander trennst.
39:05
Genauso kannst du auf der anderen Seite genauso sehen, ey,
39:08
warum geht diese Version nicht? Ja, die war halt nicht healthy
39:11
wie du meintest, wir haben es zurückgesetzt.
39:13
Ja, hier siehst du der. Container kriegt den und.
39:15
Den Fehler wir können diese Version nicht hochfahren, fix 1
39:18
fix 2 fix final. Ja, kann.
39:21
Man dann. Vermeiden.
39:23
Und das das sind halt auch. Wirklich wichtige Sachen?
39:26
Ja, die du denn dadurch gewinnst?
39:28
Ja, definitiv man. Muss ja auch dazu sagen ne
39:34
prinzipiell ne, also auch bestimmte Fehler die auftreten,
39:38
die kann man ja auch abfangen, ne also zum Beispiel.
39:41
Wie ich meinte, wenn du jetzt zum Beispiel sagst, du möchtest
39:43
eine Angular Version deployen, ne oder ein eine Angular
39:47
Anwendung ein Angular Frontend in einer Version, die dann aber
39:50
zum Beispiel vielleicht weil du deine Angular Version updatest
39:53
nicht mehr zu der Note Version passt, die du in deinem
39:56
Dockercontainer hast. Es ist möglich, es gibt auch,
39:59
ich sag mal Möglichkeiten diese Fehler im Vorfeld abzufangen,
40:03
ohne dass es dazu kommt, dass du sagst ey OK.
40:06
Irgendwie ist mein Container nicht healthy.
40:08
Das ist mal eine andere Geschichte.
40:10
Das ist natürlich Learning, was man daraus ziehen kann, um zu
40:13
sagen okay. Man kann das immer noch.
40:17
Verbessern, das finde ich, ist auch immer ein wichtiger Punkt,
40:19
dass man sich sagt, du setzt ja ein System auf, merkst okay es
40:23
gibt vielleicht Schwachstellen, die zu einem möglichen Verhalten
40:28
führen, was irgendwie. Ich sag mal unschön ist ne und
40:32
wenn du jetzt genau diese Reihenfolge gehst und sagst du
40:35
hast ne klassische cicd Pipeline wie wir sie besprochen haben und
40:39
merkst ey irgendwie ist das blöd weil ich muss jetzt wirklich
40:42
noch mal n fix machen damit das erstmal wieder quasi läuft und
40:45
dann kann ich mir das in Ruhe angucken.
40:47
Vielleicht passieren aber zwischendrin noch andere Dinge,
40:50
weil vielleicht noch jemand anders committed hat.
40:52
Ah es wird schwieriger, es wird schnell schwieriger ne so also.
40:56
Sagst du, ey, wir stellen um von einer klassischen CICD Pipeline
40:59
nutzen wir jetzt git Ops, dann merkst du zum Beispiel sowas was
41:02
ich meinte ne, dass vielleicht die Version nicht passen
41:04
Containers anhält, sie die Seite ist kurzzeitig auch nicht
41:07
erreichbar, also überlegst du dir wieder zum Beispiel n
41:09
automatisches Rollback oder ne das sind ja die Dinge, weil man
41:13
ja sich immer hinstellen kann sagen kann ja, aber man kann ja
41:15
auch ne klar kann man und es kann auch immer wieder
41:18
schiefgehen, aber es ist natürlich ne noch mal um den so
41:21
n bisschen. Sag ich mal den größeren Bogen
41:24
zu spannen. Es ist ne schrittweise
41:27
Verbesserung und es ist natürlich auch immer die Frage,
41:30
wie du ja auch eingehend meintest.
41:31
Passt es denn überhaupt oder ist es notwendig für das was was wir
41:35
bauen? Ja, also für für die
41:37
Infrastruktur, die man im Endeffekt hat, bei uns war es ja
41:40
am Anfang auch so, wir hatten eine Website, ja es ist nicht so
41:44
schlimm wenn sie mal bisschen down ist an sich kein Problem,
41:48
also konnten wir das machen. Wir sind ja hauptsächlich auf
41:51
Git Ops umgestiegen oder auf dieses Prinzip dieses Betriebs,
41:56
diese Betriebsart, weil wir gesagt haben, ey, wir, wir haben
41:59
noch mehrere Services, also wir haben jetzt nicht nur einfach ne
42:02
Website, sondern wir haben zum Beispiel noch ne n Backend dazu
42:04
oder was auch immer ne und es ist ja nicht nur ein Service,
42:08
nicht nur 2 Services, es sind sagen und schreibe 3, Nein.
42:14
Weißt du? Du hast mehrere Services, die du
42:16
halt im Endeffekt die auch zusammenlaufen.
42:18
Du brauchst vielleicht n Cluster und demzufolge hat es sich ja,
42:22
also das war ja der eigentliche Gedanke, ne da überhaupt in die
42:26
Richtung zu gehen das umzustellen, weil unsere
42:29
Infrastruktur generell oder unsere Anforderungen komplexer
42:32
geworden sind, ne genau. Noch mal der Punkt nimm.
42:35
Das was du brauchst für das was Sinnvolles.
42:38
Ja, ja, und wenn? Du halt auch zu dem Punkt
42:40
kommst, dass du sagst was ist. Wenn das hier alles mal
42:42
zusammenbricht, wie schnell können wir das Eis wieder
42:44
aufbauen und da bist du halt mit dem Git Ops Ansatz dadurch dass
42:48
ja alles versioniert ist auch sehr schnell, dabei halt ne
42:52
definitiv ja, aber wenn wir schon bei der Umsetzung sind,
42:56
ich würd das gern noch mit aufnehmen, die heutige Folge
42:58
lass uns auch mal n bisschen praxisnah werden.
43:03
Soll jetzt keine Einleitung in das Tool selbst werden, aber
43:07
Vollständigkeit halber würde ich gerne kurz drüber sprechen.
43:10
Und zwar haben wir uns ja für ago CD entschieden, auch
43:15
hinsichtlich so Absprachen in der Community.
43:19
Ja kennt ihr das ja, aber noch nicht verwendet, ja guckt euch
43:22
das mal an, das ist wirklich cool, haben wir gemacht uns und
43:26
sag ich mal auch dafür entschieden das zu verwenden,
43:28
weil es auch wirklich ein cooles Tool ist was im Prinzip.
43:34
Hilft Git Ops umzusetzen? Ne, weil es halt auch diesen
43:37
deklarativen, deklarativen Ansatz schwieriges Wort verfolgt
43:42
und das ganze Halt mit beispielsweise kybernet es dann
43:45
halt sich geil alles verbinden lässt, um diese ganze
43:48
Infrastruktur aufzubauen. Ne es ist so gesehen eine Git
43:52
Ops Engine ja also es ermöglicht dir halt diese Prinzipien
43:56
umzusetzen. Das heißt, es kann sich mit Git
43:59
verbinden, es kann deine Konfigurationsänderungen
44:02
überwachen, es macht halt diesen soll ist Zustandsvergleich
44:06
diesen Kontrollmechanismus, den wir angesprochen hatten, es
44:09
synchronisiert auch automatisch, wenn du es möchtest.
44:12
Und was ich halt auch richtig cool finde ist, dass du
44:15
natürlich auch einfach eine UI hast, auf die du dich einloggen
44:18
kannst, wenn du quasi agocity eingerichtet hast, dann.
44:21
Um einfach auch zu sehen, wie sieht denn mein Cluster aus,
44:24
laufen die Container, wie lange laufen sie, sind sie überhaupt
44:27
gesund? Ja, also healthy oder seh ich
44:30
zum Beispiel, dass irgendwas abgeschmiert ist und kann
44:32
einfach noch mal royback triggern sozusagen, und das ist
44:36
halt das coole, wenn irgendwas passiert und ausfällt wie bei
44:41
uns, dann geh ich darauf royback fertig und dann ist erstmal Ruhe
44:45
wieder so ne dann bin ich erstmal wieder an einem Punkt wo
44:47
ich mal durchatmen kann und sagen kann.
44:51
OK, was haben wir hier gerade verkackt, oder?
44:54
Das muss ich sagen. Mag ich sehr und es war auch
44:57
sehr cool, das Ganze damit umzusetzen.
45:00
Es war auch sehr lehrreich, wie gesagt, es war n umdenken, aber
45:04
ich will es auch nicht mehr missen und an der Stelle, liebe
45:07
Zuhörerinnen, liebe Zuhörer, wenn du sagst so Boah klingt
45:09
geil mit Argo CD könnt ihr nicht mal mehr dazu machen ne Folge
45:13
oder auch anderen Content, dann meld dich gerne bei uns, lass es
45:16
uns gerne wissen dann. Machen wir das natürlich sehr
45:20
gerne und teilen da noch mehr unsere Erfahrung zu.
45:22
Auf jeden Fall da bleibt. Mir nicht viel zu sagen, Tino,
45:27
sehr gut. Genau also welche Vorteile?
45:32
Also ich würd gern, lass uns mal abschließend noch mal vor und
45:37
Nachteile so als Take Home Message zusammenfassen, weil
45:41
viel gesagt viele Punkte genannt ist aber auch kein.
45:47
Einfaches. Thema sag.
45:48
Ich mal ne, was würdest du sagen aus unserer Erfahrung und auch
45:54
aus der Theorie heraus? Das sind natürlich immer so 2
45:57
Paar Schuhe, ne in auf der Theorie klingt vieles gut, aber
46:00
wie sieht es dann in der Praxis am Ende aus?
46:03
Kannst. Du so vor.
46:04
Und Nachteile nennen bei. Git Ops bei dieser.
46:09
Bei diesem Modell, bei dieser Strategie dahinter.
46:12
Also Vorteil. Ja, du hast auf jeden Fall wie
46:15
gesagt diese diese Entkopplung, diesen, diesen Sicherheitsaspekt
46:19
auf jeden Fall. Auch diese Entkopplung von, ich
46:22
sag mal CI und CD möchte ich es jetzt mal so n bisschen nennen,
46:26
einfach aus dem Grund, dass du zum Beispiel halt eben nicht
46:29
mehr aus deiner CI Umgebung sagst.
46:32
OK, ich pushe jetzt zum Beispiel weiß nicht, also du, du kannst
46:39
ja zum Beispiel wenn du kybernetes hast oder so.
46:41
Als Umgebung, dass du dann nicht sagst, OK, applye mir jetzt
46:44
meine neue Protjammel oder so nach dem Motto ne, dass du das
46:48
halt nicht machen kannst. Es ist n Sicherheitsaspekt auf
46:51
der einen Seite und auf der anderen Seite hatten wir auch
46:55
gesagt, dass das natürlich ne deutlich bessere
46:57
Nachvollziehbarkeit mit sich bringt.
46:59
Ne, dass du proco mit auch genau weißt was da los ist und sich
47:02
dann am Ende die Deployment Umgebung sozusagen das holt.
47:07
Also du hast sozusagen diesen Pull und nicht diesen Push, ne?
47:11
Wie gesagt, Nachvollziehbarkeit, Sicherheitsaspekt, aber auch die
47:17
Möglichkeit, dass du zum Beispiel eine bessere Kontrolle
47:21
über dein Cluster hast. Im Normalfall diese Single
47:25
Source of Truth in Git drin hast und nicht die Möglichkeit oder
47:30
weniger die Möglichkeit hast, irgendwelche manuellen
47:32
Änderungen zu machen, die dann irgendeinen Drift erzeugen, weil
47:36
selbst wenn du das machen würdest.
47:38
Wäre es ja so, dass sich trotzdem dann als Nächstes in
47:42
beim bei der nächsten Änderung einfach die Deployment Umgebung
47:45
sich wieder das Holt was da ist. So, das heißt du Überbügelst den
47:50
Drift am Ende wenn du ihn nicht sogar einfach konfigurierst,
47:52
dass gemeldet wird, dass irgendwas passiert ist oder so
47:54
ne, aber das sind auf jeden Fall definitiv Vorteile, die wir auch
47:59
genannt haben. Aber noch mal kurz
48:01
zusammenzufassen, auch die Rollbacks, wie gesagt es ist
48:03
einfach viel viel einfacher und wie gesagt, die
48:05
Reproduzierbarkeit ist für mich halt ein Riesenvorteil, gerade
48:08
wenn man so in der Klasse. Clusterwelt unterwegs ist und
48:10
sagt, Ich möchte mehrere Cluster haben, dann kann ich halt mit
48:13
dieser Strategie einfach mehrere Cluster hochfahren.
48:17
Nachteile ist natürlich wie gesagt die Komplexität, du
48:22
brauchst. Halt einfach.
48:23
Einen schon einen Repo für die Infrastruktur, also da, wo
48:28
sozusagen alles drin steht, wo die Versionen sozusagen auch
48:31
hochgezählt werden für einen Commit und so weiter
48:34
beziehungsweise für Changes. Dieses diesen Ovide hast du halt
48:38
einfach, der ist mit dabei, ne und da das muss man sich halt
48:42
auch vor Augen halten und es ist natürlich auch irgendwo n
48:45
weiteres Repository was man irgendwie pflegen muss und das
48:50
Bedarf halt eben auch irgendwie ne gewisse Art von Lernkurve, ne
48:53
um das zu handeln ja absolut absolut.
48:56
Allein das Umdenken ne. Also diesen Change in der
49:01
Denkweise im Ansatz. War auf jeden Fall, das kann man
49:04
auch jeweils Lernkurve bezeichnen.
49:06
Ne, du hast ja auch einfach so n Multi Environment Ansatz der
49:10
auch unübersichtlich werden kann.
49:12
Ne das finde ich es halt auch n Nachteil du brauchst halt ne
49:14
gute repostruktur du musst n Gutes Secret Management haben
49:18
weil du das ja voneinander trennst.
49:20
Jetzt können ja manche sagen ja gut, aber ich muss mich nur an
49:22
einer Stelle wie beim klassischen CI Server um die
49:25
Secrets kümmern so ne und das stelle ich sicher, dass das
49:28
passt und gut, dann muss ich nur darauf gucken, jetzt muss ich
49:30
ja. Einmal für den Continuous
49:33
Integration Anteil ne und die Artefakte zu erzeugen was auch
49:36
immer muss ich gucken was ich da brauche und für die Deployment
49:39
Strategie werde ich ja auch Secrets brauchen, spätestens vom
49:42
Cluster halt ne und jetzt hab ich 2 stellen die ich überwachen
49:46
muss. Ja gut das kann man natürlich
49:48
als Nachteil auslegen oder muss man einfach nennen, dass man
49:51
natürlich n gutes Konzept braucht um das Ganze.
49:54
Auch übersichtlich zu gestalten. Am Ende ne, aber da gibt es ja
49:57
wie gesagt dann auch Tools die einen das gut abnehmen am Ende,
50:00
dafür sind sie ja da definitiv. Ja, was?
50:05
Würdest du sagen, ist git Ops n Allheilmittel?
50:08
Ist es jetzt so n Ding def Ops nur mit git ops?
50:14
Na ja, also wir hatten das ja schon.
50:16
Gesagt, dass es im Endeffekt darauf ankommt, ne wie du.
50:21
Was du eigentlich benötigst, ne? Also wenn es wenn, wenn alles
50:25
schon anfängt langsam sehr komplex zu werden, dann brauchst
50:31
du halt auch ne komplexere Infrastruktur, wenn es zum
50:35
Beispiel auch wichtig ist, dass du sagst, OK, es ist mir
50:38
wirklich sehr sehr wichtig oder es gibt vielleicht auch
50:40
Anforderungen, dass bestimmte Dinge ne auch wirklich sehr,
50:44
sehr nachvollziehbar sind, dass du so n Audit Trail hast, um
50:46
wirklich zu sagen, Ey, was passiert hier eigentlich, dass
50:49
vielleicht auch. Für für Audits, die ja auch
50:52
manchmal gemacht werden, in für bestimmte Produkte, das dafür
50:58
hilft es halt einfach ne. Also da kannst du ja auf jeden
51:00
Fall sagen, wenn du sowas hast, dann brauchst du das auf jeden
51:03
Fall, aber natürlich ist es nicht unbedingt n Allheilmittel,
51:07
du kannst dich natürlich auch verlieren da drin oder
51:10
vielleicht auch ich sag mal das ganze auch over Engineeren an
51:13
der Stelle ist natürlich möglich ne ja ja.
51:17
Fakt ist natürlich, dass trotzdem git UPS so in den
51:20
letzten Jahren sich absolut etabliert hat.
51:23
Also so gerade kybernet ist Git ups, dass sich das auch so Cloud
51:27
native Umgebung ganz klar ne, also es ist halt so irgendwie
51:30
der Standard geworden ne und viele bauen da drauf und
51:33
deswegen sind wir beide ja auch der Meinung, dass man
51:36
zumindestens ob man das jetzt selbst umsetzt oder nur
51:39
verwendet, also nur so n User ist am Ende.
51:42
Das Konzept dahinter zu verstehen, ist auf jeden Fall
51:44
Gold wert und es lohnt sich auch, das noch mal so als
51:48
abschließende Motivation. Ja, weil ich kann, oder ich
51:53
denke mal, wir können so aus Erfahrung sagen, wenn man diese
51:57
ganze Infrastruktur auch wirklich wie Code behandelt,
52:00
weil mir hilft es zum Beispiel zu sagen, OK, warte mal, das ist
52:03
jetzt n Repository, also da sind auch nur config Dateien drinne.
52:07
Ja, es ist versioniert. Ich kann da was ändern, ich kann
52:10
das zurücksetzen, das ist alles kein Thema mehr, so ne verliert
52:13
man auch die Angst davor, dass irgendwas Schlimmes im
52:16
Deployment passieren kann, weil du halt diese Sicherheiten auch
52:20
gewinnst. Ganz klar.
52:21
Also das heißt nicht, dass man. Fahrlässig.
52:24
Wird das meine ich nicht. Aber dieses ungute Gefühl von
52:27
eigentlich habe ich an alles gedacht, aber oh bitte lass das
52:30
Deployment gut gehen, so, das ist ja so absolut worst case,
52:33
das willst du ja nicht, ne und dann hast du zum Beispiel
52:35
Schutzmechanismen wie. Ja OK, wenn das hier nicht
52:38
gesund ist, das Ding oder nicht richtig hochfertig, ja dann
52:41
machen wir royback und fertig und dann gucken mal was los ist.
52:43
Ne du hast n log dann alles auch Stichwort Audit wieder der alte
52:48
Container läuft alles cool so ne und das muss ich sagen, das hat
52:52
dieses Prinzip hat da auf jeden Fall geholfen da entspannter zu
52:56
werden und zuversichtlicher, ja und?
52:58
Gerade wenn du sagst, klar, man sollte auf jeden Fall dadurch,
53:01
dass es halt etabliert ist, mit diesem Konzept vertraut sein und
53:04
natürlich noch besser ist es. Es auch einfach mal
53:07
durchzuspielen, also wirklich mal zu sagen, ich probiere das
53:11
mal wirklich, aussagen wir bei vielen Dingen, auch wenn es nur
53:14
ums um Design Pattern geht, auch wenn man es nicht akut braucht,
53:17
es ist nicht verkehrt es einmal auszutesten und auszuprobieren
53:20
und dafür kann man ja zum Beispiel auch einfach mal Agus
53:23
City ausprobieren, wie wir es auch haben und wenn du es
53:25
richtig machen willst, nimmst du halt einen Server dafür, dass du
53:28
irgendein Server hast, mit dem du arbeitest und dann quasi das
53:31
Ganze einfach mal ausprobierst. Genau.
53:34
Und wenn du noch einen Server sucht, wie gesagt, können wir
53:36
dir die Strato v Server wärmstens empfehlen und dann
53:39
schaue gerne noch mal die Show Notes, da findest du einen Link
53:42
dazu. Kannst du uns auch mit
53:43
unterstützen, vielen Dank. Ja, ansonsten gibt es auch
53:48
nichts mehr dazu würde ich sagen, haben wir die Folge
53:50
durchgebracht super geiles Thema, war vielleicht an der
53:52
einen oder anderen Stelle ein bisschen theoretisch, aber
53:54
bleibt nicht aus, weil es halt auch wirklich sage ich mal geht
53:57
ob es ein Modell ist, ein Arbeitsmodell, eine Strategie,
54:01
ja. Aber uns interessiert natürlich
54:03
noch, liebe Zuhörer, liebe Zuhörer, bist du in der Def Ops
54:06
Welt unterwegs, wie deployst du aktuell, nutzt du vielleicht
54:10
schon die git ops Prinzipien? Lass es uns gerne wissen, hast
54:13
du Anmerkung Ergänzung Verbesserungsvorschläge?
54:17
Schreib uns gerne alle Links in den shownotes e mail Adresse in
54:20
den shownotes such dir was aus wir werden auf allen Plattformen
54:23
antworten. Und wenn dir der Podcast
54:27
gefällt, empfehlen gerne weiter. Lass ne Bewertung da, das
54:30
unterstützt uns ungemein. Du findest auch in den Shownotes
54:34
n kleinen Spendling wenn du sagst ey Leute wieder mal ne
54:36
geile Folge vielen Dank, ich möchte euch n bisschen
54:39
unterstützen, dann würde uns das auch mega freuen.
54:42
Vielen vielen Dank dafür. Ansonsten bleibt mir eigentlich
54:44
nur noch zu sagen Fabi, wir hören uns alle beim nächsten Mal
54:47
wieder wenn es weitergeht mit dem Coding Buddies Podcast bis
54:50
dahin habt ne schöne Zeit ciao ciao Deine Coding Buddies
54:53
gemeinsam besser. Weißt du, was ich auch immer
54:57
ganz cool. Finde, dass so Tools wie auch
54:59
beispielsweise Agus sind, die eigentlich immer so ganz witzige
55:02
Maskottchen haben. Ja, und da bin ich richtig froh,
55:04
dass wir Kobi haben. Ja, Kobi ist ja besser.