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