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