Transkript: Ansible

Ja, hallo liebe Hörerinnen und Hörer.

Willkommen beim Python Podcast, Episode 44.

Heute soll es gehen um Ensible.

Hi Jochen.

Herzlich willkommen, Dominik.

Oh meine Güte, das geht ja schon häufig los.

Heute ist der Max.

Hallo, willkommen.

Hallo, heute bin ich dabei.

Ja, wir reden über Ensible, aber erstmal natürlich wieder wie immer die News.

Jochen, was hast du denn für News?

Ja, was hatte ich?

Es ist eine ganze Menge passiert.

Wurden ja auch schon auf Twitter.

Mitbekommen habt ihr ja, ja, und aber auch schon angehauen, dass wir doch mal wieder was machen sollen.

Und dann, genau, machen wir jetzt auch wieder was.

Insofern ist viel passiert, aber das meiste habe ich wieder vergessen, daher egal.

Eine wichtige Geschichte war das Release von Django 4.1, das ist auch noch gar nicht so lange her.

Das ist sehr nett.

Also sowieso in letzter Zeit die ganzen Django Releases finde ich sehr, also es ist, es wirkt nicht so bombastisch irgendwie, was da drin passiert, aber es sind halt solide Verbesserungen und eigentlich kommen jetzt so die ganzen netten Dinge, die halt irgendwie man machen kann, wenn man halt so ein stabiles Fundament hat und alles gut läuft.

Und das ist halt großartig.

Ja, also was diesmal dabei ist, also das, was, ja, das Ding ist auch auf Hacker News irgendwie direkt auf die Frontpage da gekommen und da haben alle irgendwie angefangen zu diskutieren über Async-Datenbank-Interface.

Ja, ich würde jetzt sagen, das ist halt so ein längerer Prozess.

Also von irgendwie, es gibt ASGI zu irgendwie, man kann Async-Views schreiben, zu irgendwann werden wir auch komplett irgendwie alles Async haben.

Das wird noch eine ganze Zeit lang dauern.

Also ich rechne da ehrlich gesagt nicht mit, dass das vor einem Jahr oder so möglich wird.

Aber ein Jahr ist ja auch.

Es gibt jetzt so immer ein.

Ein Jahr ist auch gar nicht so, ne?

Ja, stimmt, stimmt.

Letztes Jahr ist auch quasi gestern das stimmt schon.

Insofern, ja.

Aber wenn man jetzt überlegt, wann habe ich denn, wann haben wir den Artikel, wann haben wir den Artikel über.

Das war nicht letzten Sommer.

Doch, das war letzten Sommer.

Ne, nee, ich meine, das war 2020, oder?

Das war zwei Jahren schon.

Ich meine, das war zwei Jahre her.

Oh, ähm, äh, ja, okay.

Ups.

Ja.

Letzten Sommer war was anderes.

Wenn ich überlege, weil letzten Sommer war DjangoCon EU 2021, damit hatte ich da.

Also das muss zwei Jahre hier gewesen sein.

So, so sozusagen von da bis jetzt hat es halt zwei Jahre gedauert und also wir sind halt noch lange nicht da, daher es wird noch eine ganze Zeit dauern.

Aber jetzt ist zumindest halt das Interface irgendwie fix und das bedeutet, wenn man jetzt sowas sagt wie Wait, Query Side-Filter, irgendwas oder so, dann, wenn irgendwann die ganzen anderen Dinge, die auch alle dann async werden müssen und wo das dann funktionieren muss, alles funktioniert, dann kriegt man einfach so schnellere Datenbankergebnisse, ohne dass man was dafür tun muss.

Und das ist natürlich sehr praktisch.

Also insofern, jetzt kann man das halt schon so verwenden, als wäre es da, aber es ist halt noch nicht da, weil es, also es gibt noch keine Unterstützung für Psycho PG3 oder für Async PG oder sowas daher.

Man kann, glaube ich, irgendwie Dinge machen über irgendein Threadpool.

Also wenn man wirklich will, dann kann man auch so ein bisschen Async machen.

Aber das ist halt noch nicht so wirklich das richtige Ding.

Aber das war eine Geschichte.

Dann aber eigentlich die interessanteren Features, weil die kann man halt schon wirklich benutzen und die haben Bring einem was, sind sowas wie Model-Constraints.

Also wenn man in der Da, wenn man in einem Model festlegt, dass man irgendwie bestimmte Check-Constraints in der Datenbank haben will.

Also irgendwas darf nicht größer als so und sowas sein oder dann muss zwischen Wert zwischen dem und dem liegen oder darf nichts anderes als das oder so, irgendwas auch immer man für Constraints da festlegt, dann war es halt früher so, da musste man das halt in den Model-Formen nochmal mit, nochmal validieren, damit das wirklich funktioniert.

Ansonsten hat das Form gesagt, alles okay, und dann, wenn der View oder was auch immer, oder das Form versucht, das halt in die Datenbank zu schreiben, gibt es einen Integrity-Error.

Was natürlich ein bisschen kacke ist.

Und jetzt ist es halt so, dass man tatsächlich vom Form auch gesagt bekommt, nee, das geht so nicht, weil da ist ein Constraint auf dem Model.

Das ist ja letztlich super angenehm, weil vorher muss man selber checken und meistens.

Jetzt hat die Form da nicht schon angefangen.

Mit Statuskurs reicht sogar.

Ja, und dann eigentlich die, also ehrlich gesagt, aus meiner Perspektive, die coolste Neuerung, ich habe es mir jetzt noch nicht so richtig, aber es klang schon alles sehr vielsprechend.

Das, was ich gelesen habe, klang auch sehr, sehr gut.

Das kurze Feature ist halt, also es hat sich viel an den Forms getan, auch in Django 4.0 hat sich schon einiges an den Formularen getan, dass man halt zu an Formulare auch dran schreiben kann.

Also dieses Formular wird gerendert über irgendwie ein Template.

Und jetzt ist es halt komplett so, dass man auch global einstellen kann, quasi welches Template verwendet wird, um Forms zu rendern, sodass man es gar nicht mehr unbedingt in den Formen einstellen muss.

Und ja, da gibt es jede Menge, also man ist deutlich flexibler geworden, wie man Formulare rendern kann.

Und damit, also das habe ich noch nicht persönlich überprüft, aber ich fände es schön, wenn es so wäre, weil ich habe Anfang des Jahres so ein bisschen was mit Crispy-Forms gemacht und so.

Ja, das waren immer ein bisschen anstrengend

von alles.

Ja, ich habe es früher immer nur so ein bisschen verwendet und so und dann war es eigentlich okay.

Und dann habe ich da irgendwann mal so richtig tief reingeguckt, weil ich dachte so, okay, weil es darum ging, das mit Jumbo HTMX, also mit HTMX zusammen zu benutzen und dann hätte ich gern halt nur, ich ändere ein Feld, dann gehen die Formulardaten an ein View und dann möchte ich eigentlich quasi nur das Feld zurückbekommen und die Fehlermeldung, wenn da irgendwas nicht validiert zum Beispiel.

Aber das heißt, ich muss halt irgendwie ein Feld plus eine Fehlermeldung rendern nach

Nested Forms oder sowas.

In sehr komplizierten Formularen.

Ja.

Und allein nur das zurückgeben.

Und um das hinzukriegen, muss ich sehr, sehr tief in Crispy Forms reingucken, wie das denn eigentlich funktioniert und so und wie die ganzen Templates, Packs funktionieren.

Und ja, das war halt, da dachte ich mir, oh mein Gott, das muss weg, das kann nicht so bleiben, das ist alles schrecklich.

Formtweaks.

Ah, Django Form-Tweaks, ja.

Genau, das macht es ein bisschen schöner, aber nimmt das Problem auch nicht so ganz weg.

Letztlich habe ich dann auch, eigentlich habe ich auch so ein riesen Template, was alles durchrendert, also alles durchloopt und dann letztlich dann die EFABfragen macht, falls irgendwas irgendwo schiefläuft.

Aber das ist jetzt auch einfacher, dadurch, dass man angeben kann, okay, ich will jetzt dieses Template und man muss dann nicht mehr sagen, okay, ich include das Form.

Ja, aber wie löst du da das Problem, wenn du jetzt zum Beispiel quasi HTMX verwendest und sagst, okay, wenn da jemand draufklickt, dann wird das, eigentlich möchte ich nur einen kleinen Teil austauschen, aber es geht dann ja wahrscheinlich nicht so einfach, wenn du das Formular in einem großen Template renderst.

Ja, du sagst ja, wohin das soll letztlich.

Und da über den Response kannst du dann letztlich das ändern.

Also in den anderen direkt reingehen, in das dann dann nicht ab.

Tatsächlich muss ich sagen, wenn ich dann in so eine spezielleres Form gehe, was halt nicht so 0815 ist, dann schreibe ich die auch komplett von der Pike auf, weil ich dann die meiste Kontrolle habe, weil mir da Django einfach nicht so genug entgegenkommt.

Ja, ja, ja, ja.

Nee, ich verstehe das durchaus.

Aber zum Beispiel den Fall, den wir da hatten, der war halt, dass man ganz viele unterschiedliche Formulare gab, aber viele der Formularteile waren halt gleich.

So dass man das eigentlich so machen möchte, dass man sagen möchte, okay, dieser Teil des Formulars, das so immer gleich und die Logik, da ist eine Menge Logik hinter und

so, den

möchte ich jetzt in unterschiedlichen Formularen irgendwie verwenden können.

Und aber auch nur diesen Teil rendern und nicht das ganze Formular.

Und wenn da jemand was eingibt und so.

Also so quasi mehr in die Component-Ebene rein.

Ja, dann vielleicht ein eigenes Feld schreiben.

Und dann kann man sich das ja auch wieder.

Ja, das haben wir dann auch gemacht, ja, ja, klar.

Genau, das wäre dann auch mein Ansatz.

Ja, aber es war alles nicht so ganz, es war alles nicht so.

Also das wird jetzt auf jeden Fall schön mit Dango 4.

Genau, genau.

Also angeblich braucht man das nicht mehr.

Angeblich braucht man Crispy Forms unter Umständen nicht mehr und die ganzen Template-Packs nicht mehr und das kann man jetzt alles selber machen.

Und das klingt sehr gut, weil das ist echt so ein, ja, da kannst schon leicht schmerzhaft werden.

Ja, genau.

More News.

Ansonsten irgendwie, ja, Pydentic 2 kommt jetzt, also beziehungsweise SIS ist noch nicht released, aber das wird jetzt so allmählich Richtung Release geht das.

Und also du meintest das ja auch schon mal so, genau, Piedentic Core ist

halt in der Run-Epplementierung und Rust geschrieben, dass es schnell wird, ja.

Ja.

Ja, das ist ja, genau, also das ist halt halt das Problem, also Padentic hat halt auch so ein paar Probleme.

Die ganzen Internals sind halt eher so ein bisschen, ja, vielleicht nicht mehr dem Verbreitungsgrad, wie das halt verwendet wird und so angemessen.

Und es ist halt auch langsam, es ist sogar deutlich langsamer, als wenn man jetzt einfach nur Data-Classes nimmt.

Ja, oder halt am Data-Classes.

Data-Classes sind auch nochmal deutlich langsamer als ganz normale Klassen, ja.

Ja, okay, oder Atches oder so, glaube ich

das ganz schnell.

Und ja, das ist natürlich irgendwie ein bisschen doof.

Und genau.

Da, da, deswegen, das ist jetzt halt in Rust neu implementiert, da waren auch so ein paar Sachen dabei, habe ich jetzt letztens auch, glaube ich, einen Podcast gehört, Talk Python to me, letzte oder vorletzte Episode, weiß ich nicht genau, mit dem Autor von Pydentic, Samuel Cohn, hast du den, ja.

Und da sagte er so, da waren ein paar, weil ich normalerweise dann immer denke, so, das Erste, was man macht, wenn man es halt schon schnell haben will, warum nimmt man nicht einfach Seiten?

Und da hat er relativ ausführlich drüber gesprochen, warum das jetzt für ihn nicht so der gangbare Weg war.

Und das fand ich ganz interessant, weil er halt halt so, ja, also Zeiten und so, das ist zwar schön, das geht zwar auch, aber einmal ist es halt so C, es wird halt schon nach C kompiliert und dann führt das halt dazu, dass die Binaries riesig werden, weil da halt irgendwie doch jede Menge genauer 10 komplett ist.

Und das ist bei Rust wohl nicht, da gibt es irgendwie dieses Pio 3-Ding da, mit dem man Rust-Geschichten einbinden kann.

In beide Richtungen sogar.

Und die Binaries werden halt deutlich kleiner und das ist natürlich schön, weil dann, ja, ist man nicht so.

Und es ist halt genau.

Ja, dann alles wegputzen, was nicht gebraucht wird oder

so, glaube ich.

Ja, und die ganze Parsing-Logik ist jetzt bei Pan-Decor komplett in Rust.

Und es ist halt auch gar nicht so, dass, also bei Zeiten würde man halt sagen, okay, einige Teile macht man halt dann in C oder schreibt man in Zeiten, die dann nach C kompliert wird und dann wieder.

Und da ist es so, das passiert halt alles in Rust und am Schluss werden halt Python-Objekte erzeugt, aber man geht gar nicht den Umweg, sozusagen da doppelt irgendwie Sachen machen zu müssen.

Also ja, war auf jeden Fall sehr interessant und da bin ich mal gespannt, wie das so wird, weil ja, das ist auch immer so was, ja, wenn dann Leute dann aus der Google-Ecke sagen oder so, ja, mehrere viele Datenbankzeilen aus der Datenbank holt, dann ist er bei Python immer langsam.

Und ja, also wenn man Pythonic verwendet oder irgendwie sonst wie ein ORM und dann Objekte daraus erzeugt.

Also bei Python ist es noch schlimmer als bei anderen ORMs, aber dann kann das halt schon sehr langsam werden.

Aber ich meine, das ist halt die Frage.

Wenn man möchte, dass es schnell ist und eine Millionenzeilen aus der Datenbank holt, dann darf man halt nicht aus jeder Zahlen ein Objekt machen.

Das ist halt dann nicht gut, um sonst zu langsam, ja.

Ja.

Ja, hast du noch weitere News?

Nee.

Ich war auf der EuroPython.

Ja, das war natürlich ganz interessant.

Also total tolle Veranstaltung.

Da kann ich nur empfehlen, da teilzunehmen, wenn man da die Möglichkeit so hat.

Das war in Dublin.

Dublin ist natürlich auch sehenswert.

Es gibt leckere Getränke.

Aber aus der Python-Perspektive wäre das natürlich auch schön, mal so ein bisschen die Leute zu hören und verschiedene Sachen.

Vielleicht erzähle ich mal so ein bisschen, was ich ganz besonders interessant fand.

Und zwar hat der Patrick, Patrick Arminho, über Strawberry einen netten Workshop gemacht.

Also das war sehr schön und interessant zu hören.

Das ist eine GraphQL-Schnittstelle, die man einbauen kann.

Das gibt es auch Strawberry Django.

Da kann man das halt direkt als GraphQL-View quasi benutzen.

Sehr interessante Art und Weise mit der Datenbank unter Gene, da kann man relativ gut definieren, welche Queries möglich sind auf die Datenbank und hat dann einen Endpunkt, der das exposed, den man dann halt erfragen kann, um mal so ein bisschen den Nutzer diese API direkt entscheiden zu lassen, was er denn haben will und muss dann halt nicht die ganze Card-Interface irgendwie implementieren.

Bei GraphQL habe ich immer so die Frage, also ich muss ja das ganze Schema schreiben und irgendwie habe ich immer dann am Ende das Gefühl, ja, die Django OM gibt mir das aber eigentlich gratis, was ich dem rausgeben will.

Ja.

Ja, es ist so ein bisschen ein Missmatch zwischen, man hat halt eigentlich das nochmal, weil man irgendwie dem Frontend halt so eine Art Datenbankinterface zur Verfügung stellt.

Es ist schon so ein bisschen, ja, ich weiß auch nicht, also ich bin in letzter Zeit, also ich habe auch mal eine Zeit lang irgendwie intensiv GraphQL gemacht, meistens dann halt Django Graffinen, was dann halt, ja, das wird dann auch manchmal so unerklärlich langsam und manchmal halt mal so Probleme, das rauszukriegen dann, warum da, und ja, es glaube ich halt auch diverse Designprobleme, auch ich glaube, der Auto von Graphinen meinte dann irgendwann, ach, ihr müsst das nochmal alles komplett neu schreiben.

Keine Ahnung.

An den Punkt kommt man eigentlich immer.

Und ich weiß auch nicht, ich weiß ehrlich gesagt nicht, ob GraphQL überhaupt noch so eine, ich weiß es nicht, so eine super Idee.

Kritische Stimmen gehört in die Richtung.

Ja, Armin Ronach hat es vorstellt, jetzt letztens auf Twitter schrieb er dann so, irgendwie, also, ach, ne, das war, glaube ich, oder war das der HTMX-Typ?

Ich bin nicht, nicht mehr sicher.

Der dann schrieb, naja, bedenke, dass du, achso, genau, genau, ich glaube, Amin Runach hat man, also diese Graftical-Geschichte ist so unfassbar komplex und das wird alles so, oh, wie ist jemand nur auf diese, jemals auf diese Idee gekommen, das so zu machen?

Und darauf hat dann der HTMX-Autor irgendwie geantwortet und meinte so, ja, also bedenke immer, wenn du so einen generischen Datenbankendpunkt quasi deinem Frontend zur Verfügung stellst.

Du stellst dir nicht nur deinen Frontend zur Verfügung, sondern auch allen anderen inklusive Leuten, die dich angreifen wollen.

Ja, also du kannst auf jeden Fall schon tossen damit, wenn du sagst.

Das ist natürlich extrem schwierig zu verhindern, dass man, dass das nicht geht.

Ja, ja.

Also auf jeden Fall trotzdem, der Workshop ja, sehr interessant.

Ja, aber das

Story ist ein gutes

Buch und genau, dass das so ein bisschen ähnlich von Fast API, also um ungefähr, so vom Prinzip her viel mit modernen Type-Ins und so.

Ja, dann gab es noch einen schönen Talk, das war auch direkt am Anfang, über einen Blog-Eintrag von Peter Norwig und zwar hat das Luciano Ramalorders gemacht und zwar über Lisk Scheme Parser in Python relativ kurz.

Es gab so ein, weiß ich nicht, wie lang das ist, gelogen 70 Zeilen oder sowas in Python.

Kompletter List Scheme Parser, was halt irgendwie ganz cool ist, weil man da so ein bisschen versteht, wie so ein Parser funktioniert und was so ein Ast ist und weiß nicht, so ein List-Scheme ist ja relativ ähnlich zu JavaScript, glaube ich, oder so, wie man dann irgendwie Tokens baut und Funktionen baut irgendwie und fand ich ganz interessant, das mal so zu sehen.

Auch mit Typons und so versehen.

Ja, generell, wo Python halt dabei verwandt wird und verwendet wird.

Also James Webb Space Telescope von der NASA war auch jemand da, der dann sagte so, hey, wie denn die Bilder mit Python zur Erde geschickt werden und so, dass natürlich dann freut man sich immer, dass das so berühmte Anwendungsfälle gibt.

Die Lynn hat sehr schönen Talk gemacht über Everyday RPs von Spotify, ist das eine Entwicklerin, die da einfach so einen netten Talk gemacht hat, weil ich glaube, so wie wir das auch machen, aber sie hat sehr hübsche Folien.

Können wir auch mal verlinken.

Das haben wir nicht.

Genau.

Da kann man sich nochmal so angucken, so zusammen.

Also APIs Design, glaube ich, fand ich ganz interessant.

Ah, ja.

Auch super, das war einer der.

Für mich fand ich das so so didaktisch besten Talks von Niall O'Connor, irgendwie über Fibonacci Retrace Levels, Asset Price Prediction Reverse von der Bank of America.

Ja, der ist auch drumgespringen, hat die ganze Zeit über Resistances gesprochen und da ist eigentlich irgendwann immer die Folien gewechselt.

Irgendwie jetzt ein weiter, ein weiter.

And so long run we are all dead und er klick-klick-klick, eine Folie nach dem anderen.

Das war super, ich fand's toll.

Da muss man sich eigentlich wenigstens mal angucken.

Ich muss auch mal irgendwann so ein Tradingboard bauen, keine Ahnung.

Was ich auch ganz cool war, war das Typ, äh, das Team von Hugging Face war da.

Die haben ja dieses Dulli gemacht.

Das heißt, da kann man ja irgendwie durch Texteingaben Bilder generieren lassen von so einer KI.

Oh, da habe ich jetzt auch, da habe ich meine Verifikation bekommen.

Ich kann jetzt per Dolly Bilder generieren.

Ja, cool.

Genau.

Ja, und das Coole ist, es gibt da einen Python-Rapper drum um Hugging Face, der nennt sich Gradeo.

Den kann man einfach installieren und dann kann man gerade sagen, Gradio Use den Namen dieses Machine Learning-Modells und kann dann direkt diese vortrainierten Modelle nehmen und die auf seine eigenen Daten schmeißen und die auch annotieren und wie Features irgendwie anpassen.

Das fand ich sehr nice so zum Ausprobieren und so ganz schnell Machine Learning innerhalb von kurzen Teilen bauen.

Das war cool.

Ja, da gab es noch so ein paar politische Talks über AI, Dystopia und so, was man alles nicht mit Killer-Robotern machen kann und so.

Wenn man sich das nochmal angucken möchte, so die Argumentation, die dahinter stecken.

Dann darüber, wie man 30, 3.11 jetzt schneller gemacht hat, hat Mac Shannon gedacht.

Ja, das ist super.

Das war auch sehr schön, also so ein bisschen C Python wieder.

Und da in dem Fall auch Sam Gross von Facebook hat was dazu gesagt, wie er NoGil macht.

Und wie das aussieht, dass man halt in Python nicht immer eine Gil benutzen möchte.

Robin habe ich gesehen, das ist ein neues Framework.

Ein asynchrones Python Webframework, das mit einer Rust Run-Time läuft.

Dann kannst du halt sowas wie Juvicorn sparen vorneweg und hast halt direkt diese Rust-Run-Time und es ist relativ sags schnell, wenn du relativ gute Address.

Das ist auf jeden Fall eine interessante Idee.

Also ich meine, ich würde jetzt sagen, also ob einem das so wahnsinnig viel hilft, wenn man das jetzt in Raster.

Also das Einzige, also ich meine, Juvicorn finde ich ja eigentlich schon ganz gut, ist relativ schnell und so.

Aber also zum Beispiel wenn ich Files ausliefere, also meine Benchmarks sagen so, JuicyCorn ist deutlich schneller, äh, deutlich langsamer als sowas wie Nginx und so.

Ich weiß nicht warum.

Ich habe keine Ahnung.

Wahrscheinlich müsst ihr ja mal tiefer reingucken, was das eigentlich ist.

Also bei dem Probing gibt es auf jeden Fall auch diese so ein paar Benchmarks, ich weiß ja immer nicht, du bist ja immer bei Benchmarks wieder ein bisschen kritisch, wie gut die sind oder Radio.

Also, es ist einfach schwierig, Benchmarks so zu machen, dass sie halt etwas sagen, dir Informationen darüber geben, was du eigentlich wissen willst und nicht, dass du irgendwie dein Benchmark-Tool gemenmarkt hast oder deine CPU gemanchmarkt hast oder einen Speicherbus gebildet.

Das ist halt irgendwie, es kann vielfältig schief gehen.

Genau.

Ja, also jedenfalls, das war super interessant.

Achso, genau, ich hatte mich auch auf dieser Sam Gross Talk, der geht halt um Reference glaube ich auch, ne?

Mit einem Nogil, dass man halt irgendwie das ersetzen kann.

Ja, dann gab es noch einen Talk über Dot, fand ich ganz interessant.

Da wusste ich noch nicht alles drüber.

Dann hat die Jessica erzählt.

So ein bisschen nochmal so die Details darüber, was da für ein Payload drin ist und so weiter.

Das war interessant.

Und noch der Luciano Ramann hat noch einen über Typing, wie ich das.

Der hat ja jetzt, also überhaupt, ich weiß nicht, ob der so bekannt ist, der Name, wenn man den sagt, was der den Leuten trägt.

Das ist der Autor von Flu <unk> Python.

Ganz lange Zeit schon eine Community aktiv.

Und also ich finde Fluid Python ist halt auch so eines der besten Python-Bücher, die so draußen sind.

Und davon gab es jetzt auch im Frühjahr irgendwie eine zweite Ausgabe.

Und da ist eine der Neuerungen, ist ein Kapitel über Typing.

Und das ist halt super.

Also ja, kann man.

Genau, und das meint er so, wie du sich das vorgestellt hast, das war.

Und ich weiß nicht, weil der Talk war Type-Ins as Geo-Intendent.

Ah, okay.

Weil das würde mich jetzt mal interessieren, weil ich hab das, was ich, also ich habe da so ein bisschen reingelegt, ich hab's noch nicht komplett gelesen, aber so ein bisschen quer gelesen.

Und ich weiß auch sonst, was er darüber schon mal so geschrieben hat, und der war ja auch schon mal Gast in diversen Podcasts und so.

Und der ist ja auch eher so ein bisschen kritisch gegenüber dieser ganzen Type-Ind-Geschichte.

Und er sagt so, meine Güte, das ist halt irgendwie ein ganz schöner Aufwand, das zu lernen und teilweise ist es ganz schön schwer.

Also das Beispiel, was ich jetzt auch schon ein paar Mal gebracht habe mit Min- und Max-Funktionen und den Type-Annotationen, das kommt von ihm, ja.

Man hat, er hat ein Protokoll entwickelt, wie man das irgendwie machen kann.

Also Typing-Dot-Protocol macht ja irgendwie so solche Sachen zu lösen.

Das war ganz spannend.

Ja, ja.

Ja.

Ja, dann Super Search mit OpenSearch war noch ganz interessant.

Also OpenSearch als Elasticsearch Fork.

Irgendwie mit Python ging ein ganz schöner Talk dazu.

Ja.

Ja, Dublin war toll, man konnte auch an den Strand fahren, war super Wetter und nette Leute kennengelernt, groß an Marlene und ja.

Ja, sehr schön.

Also war eine super Veranstaltung.

Kann ich schon empfehlen, das nächste Mal gerne wieder.

Ja, nächstes Mal schaffe ich es gleich auch.

Gruß an Jan Hendrik auch.

War auch sehr schön.

Ja, habt ihr noch News?

Dann sind wir vielleicht endlich beim Thema.

Das Thema ist nämlich heute Ensible.

Und ich würde sagen, es ist auch der perfekte Zeitpunkt für Max, dass Max sich vorstellt und Hallo sagt.

Ja, hallo, ich bin Max.

Und programmiere viel in Python, mache viel mit Django, bin bei einer Compliance-Beratung, wir kümmern uns um Datenschutz, Qualitätsmanagement, Arbeitssicherheit.

Und eigentlich stelle ich so den Beratern die Tools zur Verfügung, damit die weniger arbeiten müssen und alles ein bisschen schöner am Ende aussieht.

Und da setzen wir hauptsächlich Python ein.

Und haben natürlich auch eine Ecke an Servern, die wir dann mit Ansible bespielen.

Das heißt, Ansible zur Servereinrichtung.

Genau, also so.

Ansible macht ja Konfigurationsmanagement.

Kennt ihr alle Ansible?

Ja, ich doch.

Was macht Ansible?

Ja, genau.

Konfigurationsmanagement heißt also, du rollst irgendwas auf einem Server aus und sagst dem, was das für ein Server sein soll und dann macht Ansible die ganzen Scripts und die Konfiguration und die Einstellungen von der Kiste.

Genau, also Ansible ist deklarativ.

Das heißt, ich sage dem Ansible nur, so soll das am Ende aussehen.

Und dann kümmert sich das um alles weitere.

Ja.

Und das ist bei Ansible, also es gibt dann natürlich viele verschiedene Tools, die das halt machen.

Da gibt es natürlich auch Chef und Puppet, die man zum Beispiel nutzen kann.

Salt gibt es natürlich auch.

Das sind so die großen, die man dann letztlich hat.

Und die Frage ist dann immer, okay, welches von diesen Tools nehme ich denn am Ende?

Und ich finde, ja, Ansible ist halt das Tool mit der niedrigsten Hürde, weil man am Ende halt YAML schreibt und dort halt relativ klar reinschreibt, was man denn am Ende haben möchte.

Und es funktioniert halt Agentless, das heißt, ich muss halt vorher keinen Kontakt zu dem Server gehabt haben, also kein Agent installieren.

Und dem werfe ich dann einfach Befehle zu und der führt die dann aus.

Ja, das ist so wie, also per SSH brauchst du natürlich Zugriff.

Genau, man braucht SSH-Zugriff und man braucht Python auf der Kiste.

Ja, okay.

Genau.

Und ab da läuft es dann sehr autonom.

Auf der anderen Seite gibt natürlich auch so ein paar Trade-offs in der Richtung.

Es ist nämlich dann, dass Ansible eigentlich so den State der Maschine nicht kennt.

Wenn man immer, also wenn man einen Agent drauf hat, der meldet dann regelmäßig zurück und sagt dann, ja, hör mal, hier ist übrigens gerade, ja, die Pakete sind ausgelaufen, könntest mal ein Update machen.

Davon weiß Ansible da nichts.

Es geht einfach kaputt oder aus, wenn irgendwas nicht stimmt.

Ja, also der

hält dein State nicht.

Also wenn du sagst, okay, ich möchte halt immer die aktuellste Version vom Apache drauf haben, dann ist das für den Moment, wo das ausgeführt wird, so.

Genau, und danach ist das

halt historisch, ja.

Genau, danach ist es dann gewesen.

Und die andere Annahme ist natürlich dann auch, dass halt niemand auf dem Server was macht, außer über Ansible.

Damit man halt den State hat, den man einmal.

Das ist so eine Konvention, die man dann haben muss.

Also das könnte ja auch anders sein.

Es könnte ja auch sein, dass irgendein Admin irgendein Login hat und dann einfach irgendwas macht.

Und das hat mit dem, was die Ensible-Wahrheit war, nichts zu tun.

Genau, und deswegen weiß ich am, also wenn ich das nächste Mal dann Ensible ausführe, halt nicht, wie sieht denn jetzt die Wirklichkeit auf der Maschine aus?

Okay.

Ja, also vielleicht wollen wir tatsächlich so ein bisschen reingehen, was der Ensible macht, wie das das so macht.

Ja, also ich würde sagen, generell der größte Unterschied eben zu den anderen ist halt, dass es Ancient Less ist.

Das ist halt ein Riesenunterschied.

Und das da kommt dann halt, also einmal ist es halt ein Riesenfolg, man braucht nur SSH, das ist alles.

Das hat man ja dann meistens.

Also ich würde sagen, es passt halt gut zu dieser Geschichte, was passiert eigentlich, wenn man jetzt halt eben so irgendwo sich einen Rechner klickt, dann kriegt man halt meistens einen Hut-Login da.

Das ist halt etwas.

Bis dahin ist es ja meistens schon automatisiert.

Und dann, ab dann ist halt die Frage, was macht man dann?

Aber dann braucht man halt auch nicht mehr.

Und dann kann man mit Ensimplation anfangen, während man bei anderen Sachen, da muss man halt dann irgendwie ein Agent installieren und keine Ahnung.

Ja, und ja, das ist halt der Vorteil, aber es ist halt natürlich in gewisser Weise auch Nachteil irgendwie, weil das macht dann halt dann bestimmte Sachen eben, wie er schon angesprochen hat.

Also eine Dinge, eine Geschichte ich noch hinzufügen würde, ist, macht es halt auch langsam.

Das ist halt dadurch, dass das alles durch S haben und durch muss.

Also wenn zum Beispiel Files kopieren, viele Files kopieren, ist halt mit Ensibles oder Templates, wie man da erzeugt, das ist halt schon relativ klar.

Ja, weiß ich nicht.

Das kommt wieder ein bisschen drauf an.

Okay, gut, interessant, ja.

Ja, also weil ich nehme das vielleicht jetzt vorweg.

Also was bei mir immer so ein bisschen bei dieser Infrastruktur as a Service-Geschichte dazukommt, ist halt dann Terraform.

Weil ein Terraform-Provider halt, die sind geschrieben für, weiß ich, AWS und Azure und Google Cloud und auch zum Beispiel Hetzner oder sowas.

Also jeder kann seinen eigenen Provider in Go irgendwie schreiben für Terraform, für diese Hashi-Corp-Language, in der man dann auch in YAML Infrastruktur definieren kann.

Also wie sieht die tatsächliche Hardware auf, welche, wie viel Kerne hat der Rechner, den du haben willst, wie groß ist die Platte und wie ist die Netzwerkkonfiguration von dem Ding.

Also das alles, was diese Cloud-Provider anbieten.

Und dann ist jetzt die Frage, wie man das mit Ensibel beispielsweise kombiniert.

Ja, man hat halt dann entweder macht man per Ensibel so Terraform, da musst du Max mir nochmal erklären, wie das funktioniert, das habe ich noch nicht ganz begriffen.

Und wie ich das mache, was ich ganz nett finde, ist tatsächlich Terraform anzufangen und bei dem Apply mit die Ensibel-Kommandos reinzugeben, die auf dem Server laufen sollen.

Und dann bedeutet das natürlich, das ist so ein bisschen von hinten die Musik-Ago, das muss dann so ein Cloud-Init-Skript zum Beispiel mit angeben, was dann auch quasi Ensibel selbst auf dem Rechner installiert und dann eins Local-Host-Inventory läuft.

Also eine Host läuft dann halt local.

Ja, kann man so machen.

Es ist so ein bisschen komplexer.

Aber sehr kompliziert, ja.

Ja, also du hast halt hinterher das Problem, dass du halt für Management die IPs wieder rausreichen musst und den SSH-Zugang brauchst, den Ensible nutzen kann, damit es halt dann sowas wie Upgrades oder sowas auf einen Kisten ausgerollt werden kann, wenn du da mehrere Farben mitrollen wirst.

Ich weiß nicht, ob ich das kompliziert finde, aber das ist halt so andersrum, weil du hast halt immer nur den Local-Host, den du dann provisionst, aber der sieht halt dann schon so aus, wie du willst.

Vielleicht erst jetzt mal mach mal kurz, wie es andersrum bei dir funktioniert.

Erst Ensible, dann Terraform.

Ja, also letztlich mache ich auch erst Terraform.

Achso, ja.

Und dann lasse ich mir das Inventory dynamisch erstellen.

Ah, genau, das hätte ich jetzt auch gedacht, das ist vielleicht ein guter Weg, dass das.

Genau.

Also so der andere Weg, Ensible und dann Terraform, heißt dann, okay, ich habe dann erstmal ein Ensible und lasse dann da soweit dann schon mal alle Templates und so weit ausfüllen, wie ich das letztlich haben möchte und starte von da aus dann den Terraform.

Kann man dann auch machen.

Aber ich finde der richtige Terraform.

Also erst Ensible lässt du dann die Terraform-Templates von Ensible befüllen, dass halt quasi Terraform dann weiß, welche, also die Frage ist halt, wo läuft dann diese Ass-In-Control-Node?

Läuft sie dann lokal und füllt dann quasi die Terraform-Templates mit den Dingen, du dir vorgestellt hast, über ein eigenes Ensible-Inventory oder irgendwelche Rollen, die du dir definiert hast, aus.

Und dann fängt es an, dann die Infrastruktur zu deployen.

Und die nächste Frage wird dann wieder, wie sieht denn denn dann die Kisten aus?

Dann muss Ensible ja quasi wieder hingehen, diese Nodes, die es erstellt hat, connecten und dann da seine Rollen auf.

Richtig.

Vielleicht noch ganz kurz eine Ensible Rolle ist quasi genau das, was man haben möchte.

Also eine Konfiguration für irgendwas, also Rolle, Datenbank-Server, Rolle, Web-App.

Genau, das ist also die Frage.

Wollen wir nochmal in die Definition gehen, damit wir so das Thema Playbooks, Place, Tasks und Rollen klar haben, weil das ist das, ich finde, das ist das Verwirrendste.

Also Inventory, damit kommt man ja irgendwie so klar.

So, okay, das sind meine.

Vielleicht auch nochmal erklären, für jemand noch gar nicht gut.

Also, Inventory, das sind so meine Kisten, das ist eigentlich eine YAML- oder Indie-Datei.

Und da kann ich dann die IPs oder die Server reinschreiben, die ich dann erreichen möchte.

Und die kann ich auch ein bisschen kopieren und sagen können, um dann zu sagen können, okay, das sind meine Datenbank-Server, das sind meine Web-Server.

Und die kann ich dann letztlich in einem Playbook halt ansprechen.

Also ein Playbook ist quasi eine Anleitung, welche Rollen ein Server haben soll, der die und die Bestimmungen erfüllt.

Ja, es ist so ein bisschen die Metapher aus dem Football.

Du hast dann als Coach von deinen Servern sagst, okay, wir spielen jetzt diesen Spielzug und alle Server, die Datenbank sind, gehen jetzt alle nach links.

Und da ist dann das Play drin, wo dann drin steht, okay, das sind die welche einzelnen Anweisungen da erledigt

werden müssen.

Okay, dann in einem Play, also dann, wenn eine Rolle ausgeführt wird, in jeder Rolle stehen dann Aufgaben drin, also Tasks drin, welche alle aus diesem Server ausgeführt werden sollen, damit das so ist, wie man sich das vorstellt.

Genau, aber a Play ist halt, ähm, Playbook kann halt Rollen benutzen, aber Play, das ist keine Rolle selber, sondern Playbook ist halt, da kann ich halt, genau, ja, ja, Rollen drin benutzen.

Also es gibt auch Leute, die das gar nicht machen, sondern die alles immer includen irgendwie.

Ist halt, ja.

Ja, letztlich ist es eine Hilfe, dann seinen Code zu organisieren.

Ja, man kann natürlich auch alles in eine große Datei schreiben.

Es geht weg.

Also ganz viele Rollen irgendwie, ne, an diesen Moment.

Also ich weiß nicht, also Ensible Galaxy ist auch ganz schön, dass das halt der Cloud, ist das Cloud-Dienst?

Also so ein

Sammlung von Rollen, die kann man da hochstellen.

Das ist so wie Pip quasi, bloß für Ensible-Rollen.

Also ich bin immer so ein bisschen picky, ich mache immer viele Sachen selber, also Not Invaded hier und so.

Also die Ensible Galaxy gucke ich mir dann auch zur Inspiration an.

Genau.

Ja, und jedenfalls, da könnte man sich halt auch solche Rollen einfach inkluden von dort.

Und dann baut man halt seine Rollen und da legt man dann halt fest, welche Konfigurationsaufgaben ausgeführt werden müssen.

Da kann man dann, weiß ich nicht, aus Ginder, Templates, Konfigurationsdateien sich belegen und befüllen lassen mit Variablen, die man reinreicht von außen und so weiter.

Das ist ja genau die Besonderheit bei Rollen.

Da sind ja dann Variablen mit drin, Plugins mit drin, Templates mit drin, Dateien mit drin.

Und das ist quasi so der Gegensatz dann zum Playbook, was das dann nicht unbedingt mit drin hat.

Okay, also weil ich definiere mir halt immer so Playbooks, wo dann halt dann diese Rollenliste drin ist.

Die benenne ich dann irgendwie immer so Setup Web-Server with Bla oder so.

Ja.

Postgres zum Beispiel und Django auf einmal.

Also dann wäre ja die Rolle letztlich Postgres und dann kann man.

Ja, wenn eine Rolle Postgres und Django beispielsweise.

Genau.

Ja, und vielleicht haben die noch Dependencies, keine Ahnung.

Also bei mir ist zum Beispiel dann so ein Minimum-Server-Setup oder so mit drauf oder so.

Genau.

Und letztlich die Rollen, die soll man quasi so schreiben, dass man die wiederverwenden kann.

Modular austauschbar, egal.

Genau.

Also Postgres ist halt überall der Postgres und der.

Also ich finde das zum Beispiel schwierig, weil was Enzabell ja zum Beispiel auch ermöglicht, ist eine Unterscheidung zwischen den Betriebssystemen, die benutzt werden.

Also jetzt, ob ich jetzt ein Red Hat Enterprise habe oder ein Debian oder so.

Und das finde ich also ein bisschen blöd, weil also ich habe keine Lust, immer meine Rollen für alle Systeme zu schreiben, die ich nicht benutze.

Ja.

Also so.

Genau.

Also deswegen ist es eigentlich ganz gut, die Themen so homogen zu halten, damit man nicht so viele unterstützen muss.

Aber da kann man natürlich auch nochmal mit dem Inventory arbeiten und dann beim Inventory den einzelnen Servern nochmal Variablen mitgeben und sagen, okay, der ist halt, der ist halt anders als die anderen.

Ja, ja.

Ja, genau, also das, ja, also ich meine, ich verstehe schon, dass Leute diesen Fall haben.

Ich habe den selber auch nicht, bei mir sind alle, alle Server haben irgendwie gleiche Betriebssystem.

Welche benutzt du?

Ja, Debian tatsächlich Pulse Eye zurzeit.

Nicht Arch Linux.

Naja, ja, nee.

By the way, eigentlich.

Also ja, es gibt da, also es gibt da auch interessante Alternativen, also womit ich ab und zu mal geliebt oder, ist halt nix.

Aber ich habe nix auch benutzt, aber nur als Desktop, also jetzt nicht als Servervariante.

Also gerade Python ist da sehr, sehr nervig mit, weil man halt gar nicht so wie Paketmanagement über seine Projekte verwalten kann, sondern muss halt jedes Mal seine eigenen Environments irgendwie zusammenfummeln und ist halt alles nicht alles verfügbar und das ist einfach sehr, sehr viel Maintenance-Arbeit, wenn man da irgendwie Updates fahren will und dann nicht, dass es irgendwie.

Man hat halt sehr viel Kontrolle, die man auch ausüben muss.

Das ist

schon irgendwie sexy, aber.

Genau, das würde mich eigentlich reizen, also weil mir das Konzept natürlich schon irgendwie ganz gut gefällt und so.

Aber auf der anderen Seite irgendwie Debian benutze ich halt schon so lange und kenne ich halt gut und da es gibt keine Überraschungen und die Frage ist immer, muss ich halt die Schlachten aussuchen, die man gegen das?

Und dann würde ich sagen, da gucken nehme ich damit, dass es halt

irgendwie ein langweiliges Debian ist.

Und dann kann ich mich, kann ich die interessanten, man nimmt mein Innovation-Token irgendwo anders ausgeben, wo es halt vielleicht irgendwie mehr bringt.

Aber es reizt mich schon, das muss ich sagen.

Ja, also bei der Definition jetzt, ich glaube, wo waren wir denn?

Inventories, Playbooks, Hosts, genau so.

Haben wir das klar genug definiert oder sind wir da auch so lange doch?

Ja, genau.

Ich wollte irgendwas sagen, ich habe es wieder vergessen.

Ich glaube, ja, ich habe diesen Fall eben auch nicht, das nervt mich auch in diesen Rollen, die man halt von der Galaxy bekommt.

Galaxy bekommt, ja, eben sowas wie Postgres zum Beispiel.

Also, was ich dann, wenn ich diese Rolle, wenn ich, ich weiß nicht, ob ihr die kennt, die habe ich mal irgendwann benutzt, ich weiß nicht, ob die ja noch aktuell sind.

Da gibt es immer einen, der schreibt die alle.

Wie heißt der?

Gerling Guy.

Der hat auch ein richtig, richtig gutes Buch über Ansible und noch ein paar gute YouTube-Videos.

Alle in die Shownotes.

Genau.

Und der hat auch einen Vortrag, wie man rausfindet, welche Rollen gut sind in der Ansible Galaxy.

Hat dann ein Schaubild gesagt, mit so ein bisschen Augenzwinkern.

Also man guckt dann, ob er der Autor ist.

Ja, tatsächlich.

Wenn nicht, dann fragt man ihn an und wartet so lange, bis die dann kommt.

Ja, ja, genau.

Aber das Problem bei denen ist halt oft, weil der hat dann eben für Postgres zum Beispiel einer und die fand ich nicht, sondern ich habe seine geforgt und dann.

Einfach, das ist total.

Also den Hauptteil davon, der interessiert mich halt nicht, irgendwie die ganzen Installation für alle möglichen Plattformen, ja, und dann der Teil, der mich interessiert für Debian, da ist bestimmt dann die Version, da hätte ich gerne eine andere Version.

Und dann muss ich das aber irgendwie patchen, dass das dann doch geht.

Ja, na gut, ne, Ansible Galaxy, das ist halt für alle Anwendungsfälle.

Ja.

Und gut.

Ja, also

wie gesagt, eher so die Inspirationsquelle.

Oder wenn man es halt wirklich mal schnell hochziehen will, um zu gucken, okay, wie sieht das so aus?

Ja.

Ja, okay, das ist so ein bisschen der Docker-Container für den Server oder so.

Also so eine Rolle.

Ich spawne jetzt mal den Server in der und her.

Ja, in gewisser Weise, das finde ich auch, das ist vielleicht ein guter Vergleich.

Das ist halt auch so ein, aber ich meine, es ist halt die Frage, ob man eine mit Rolle meint oder ein Playbook, weil ich verwende eher Playbooks tatsächlich so wie ein Docker.

Meistens braucht halt irgendwie so ein Server mehrere Rollen, würde ich sagen, damit er das macht, was man will.

Ja, ja, aber ich, ich, äh, also ich würde sagen, ich habe halt für diese Geschichte, ähm, zum Beispiel, er soll irgendeine Funktion erfüllen, habe ich halt ein Playbook bei mir und nicht eine Rolle.

Genau, ja, habe ich auch.

Das kombiniert halt bei mir dann so bestimmt.

Genau, und tatsächlich ist das, finde ich, auch sehr ähnlich zu sowas wie Docker-Pfeil oder oder weiß ich nicht, Docker-Compose oder sowas.

Nur, dass es halt irgendwie, dass man die ganzen Einschränkungen nicht hat, die man bei Docker sagt.

Und auch die ganzen Security-Sachen sind, finde ich, da, wenn man das so macht, deutlich klarer als jetzt bei Docker.

Und naja.

Ja, nochmal so zur Abgrenzung Rolle und Playbook.

Ja, Rolle ist wirklich dafür gedacht, alleine zu stehen.

Also bei dem Playbook, dann sage ich, okay, ne, ich möchte halt so einen bestimmten Server auf die

Gruppe von Servern

so konfiguriert haben.

Und eine Rolle wäre dann quasi so die Unterfunktion davon, wenn ich sage, okay, na, wenn.

Diese Konfiguration wird dann angewandt.

Genau.

Und ja, der Playbook, das Playbook, also wenn man sich dann so ein größeres Cluster vorstellt, enthält dann es halt mehrere Rollen.

Also ein Loadbalancer, ein Webserver, eine Datenbank.

Was der Running Back machen soll, was der Quarterback machen soll, wie die Defense entstehen soll.

Richtig, genau.

Ja, ja.

Okay, also ich glaube dann die grundsätzlichen Sachen haben wir definiert.

Haben wir noch was vergessen?

Achso, vielleicht Effects, was ist ein Fact?

Ja, das ist halt das, was Ansible irgendwie rausfindet.

Damit in die Variablen schreibt, vielleicht um das.

Ja, man macht das halt so ein Gathering Facts, das kann man aber auch abschalten, was ich braucht.

Dinge, wo dann halt bestimmte Variablen belegt werden, mit Informationen über das System, auf den man gerade geht.

Kommen natürlich daher, dass Ansible das erstmal nicht weiß.

Ja, ja.

So, wo bin ich denn?

Und da kriegt man natürlich dann auch ein schönes Python-Directory zurück, was halt alles Erdenkliche auf diesem System herausgefunden hat.

Da kann man auch mal schön reingucken.

Ja, da ist ja viel interessantes Zeug drin.

Genau.

Auch noch genau die Sachen vielleicht, also die ganzen Variablen, die man irgendwie reinpipt oder irgendwie, die man dann behandelt als Facts oder sowas, die halt da schon drin sind.

Da kann man ja ganz viele Python-Funktionen auch draufpipen, die halt relativ nativ sich anfühlen, wenn man das irgendwie arbeiten möchte.

Du meinst, um nochmal andere Dinge, die da jetzt nicht drin waren, brauchst du sagen, ja, genau.

Man kann in einem Task sagen Set-Fact und dann halt irgendwas an

einem anderen Pipe verwenden.

Als String, als JSON, als was auch immer.

Genau, die

Playbooks, die sind ja letztlich, äh, läuft da halt auch ein Ginger 2-Support hinter.

Und das heißt, ich kann alles letztlich machen, was ich in Ginger 2 machen kann.

Mit den Facts, die vorher Ansible gesammelt hat.

Und ich kann die letztlich wie ein Directory accessen oder beziehungsweise ist sie ja eins.

Und dann kann ich da alles machen, was Ginger 2 mir letztlich erlaubt.

Und das ist ja echt eine ganze Menge.

Da, vielleicht, vielleicht noch ein kleiner Exkurs, Ginger 2.

Ja, Ginger 2 Templating Engine.

Letztlich so wie alle Templating Engines, die man so kennt.

Django macht das ja auch, ja.

Genau, Django ist.

Das hört auch ähnlich.

Also nicht, dass das genauso

Ginger 2 ist wahrscheinlich sogar die bessere Template Language umgedreht, so ein bisschen.

Genau, es gibt

Ginger 2 Support für Django, wenn man das dann machen möchte.

Und bietet eigentlich auch die Möglichkeit, direkt Python in das Template zu schreiben.

Oder halt in das Playbook dann und auch Funktionen zu definieren, die man dann später haben möchte.

Ja, wäre dann halt am Ende die Frage, ob man dann nicht lieber ein Modul schreibt, wo man dann direkt in Python arbeitet.

Ja, okay.

Interessant.

Ich glaube, jetzt haben wir so ein bisschen definiert.

Ich habe noch so jede Menge Fragen, die ich dann irgendwie dazwischen habe, wie man irgendwie die ganzen Sache umgeht.

Aber jetzt vielleicht nochmal, warum wir kurz das definieren wollten, um diese Terraform-Ensible-Sache nochmal so ein bisschen zu verstehen.

Was spricht jetzt zum Beispiel dagegen, sowas wie dieses lokale Ensible zu machen, deiner Meinung nach, wenn man sagt, okay, man lädt jetzt ein Local-Host einfach und sagt ihm, welche Rollen er hat.

Ja, also wirklich viel dagegen spricht nicht.

Also es ist halt anders gedacht.

Und dann bin ich immer doch eher dafür, die Werkzeuge so zu benutzen, wie die letztlich gedacht sind.

Klar, du würdest dir halt die SSH-Verbindung dann sparen.

Ne, ich brauch die halt über Terraform, muss ich SSH-Verbindung bauen.

Genau, aber nicht mehr dann die auf dem, also weil wenn du ja über die Local Connection gehst.

Genau, ich mach dann Fire und Forget.

Also ich sage dem halt quasi, renn los und dann macht er halt sein Enselbekram.

Ich habe da halt wenig Kontrolle drüber, ich muss halt dann auf den Servern dann in die Logs gucken oder was auch immer, um festzustellen, wo sind die ihn gerade.

Genau, also da gibt es ja dann auch nicht mehr diese Rückmeldung zurück.

Brauche ich vielleicht am Ende auch nicht, wenn ich dann in die Logs gucke oder.

Ja, gut, man muss halt einmal ordentlich Idee buggen, damit er einmal sicherstellen kann, dass ein Server das macht, was er will, aber ja.

Ja.

Also ist auf jeden Fall durchaus ein gangbarer Weg.

Ist dann die Frage, ob man da ein bisschen so die Idee hinter Ensible, ja.

Nee, also ich frage es halt, was sonst Terraform ist, weil ich frage mich halt, wie dann halt Terraform sonst aussehen soll, weil ich weiß ja gar nicht, mit Ensibel anzufangen, welche Server habe ich denn denn jetzt?

Ja, aber ich meine, gut, vielleicht macht ihr das, aber ich wundere mich mal, ich verwende gar keine Terraform.

Ich meine, ich habe jetzt auch nicht irgendwie jobmäßig irgendwas, große Cluster zu konfigurieren.

Wenn ich das hätte, dann hatte ich das vielleicht dann doch, aber so für meinen privaten oder so semi-privaten reicht.

Locken hat gerade zugegeben, dass er sich die einzelnen Cloud-Server einfach zusammenklickt.

Ja, ich benutze da selber Interface und ich rufe jemanden an, der macht das dann.

Aber ich kenne, es sind so wenige, ja, so privat habe ich

jetzt nicht so gewesen, Server.

So viel habe ich da

nicht, dass ich da nicht mehr kann, dass ich die nicht mehr kennen würde.

Da kenne ich jeden einzeln mit Namen sozusagen.

Und die kann ich ja dann auch in den Inventory reinschreiben.

Ja, weil da ist ja eigentlich auch erst Terraform, also weil das macht ja genau das, was du da klicken würdest und dann Ensible.

Also nur mit dem Unterschied, dass ich jetzt halt einmal hingehe und sonst in Terraform beispielsweise einmal eine generelle SSH-Verbindung vorkonfiguriere und dann den Output sammle und die IPs dann ins Inventory reinschreibe,

um die

dann mit den Rollen zu versehen.

Was halt dann so der direkte Ensible-Weg ist, wie es vorgesehen ist.

Was ich halt bei mir machen würde, ist halt, ich sage halt direkt beim Deployment von Terraform, das, was er halt werden soll, der Server.

Und ich müsste mir dann halt auch aus dem Output den SSH, den ich mir dann selber, also ich mache dann keinen SSH-Zugriff mehr, sondern halt mit Keys für das ordentlich, dass es irgendwie einen User gibt, der das dann darf.

Und der.

Nee, äh, ne, Moment, das wird interessant.

Du machst du connectest dich, wenn du Ensible benutzt, auf einen User.

Nein.

Auf dem Rechner?

Nein, Moment.

Ich gehe hin, ich baue eine Kiste, beispielsweise bei Headsha oder beim MAH oder sowas, und sag dem über so ein Cloud-Init-Skript, bitte installiere Ensible lokal.

Aber dann kannst du auch alles über das Cloud-Init-Skript machen.

Ja, also mache ich im Prinzip schon.

Aber ich möchte ja gerne diese Flexibilität der Rollen haben, die ich dann über das Terraform-Skript reingebe.

Das heißt, ich gebe quasi eigentlich nur den Pfad zum Playbook mit den Variablen, das kommt über Terraform.

Also die extra Variablen, die in das Playbook, das ausgeführt werden soll, kommt rein.

Und ich klone quasi lokal das Ensibel-Server-Repo und dann lasse ich da lokal mit Local Host das Playbook laufen.

Mit den entsprechenden Variablen.

Was aber auch das Geschwindigkeitsproblem, was Jochen hatte, löst, weil das halt alles lokal auf der

Maschine läuft.

Es kann gut sein, dass das dann schneller ist, ja.

Genau, das läuft halt dann schnell einfach durch und konfiguriert die Maschine lokal halt einfach so, wie sie sein soll.

Was ich dann natürlich machen muss, ist, also was ich auch mache, ist, ich konfiguriere jetzt beispielsweise mein Admin-User, ja, mit den entsprechenden Keys und tralala.

Den könnte ich ja dann wieder rausgeben, ja.

Ich brauche halt den Key, der Zugriff darauf hat, ich brauche den Nutzer-Account, der das darf und ich brauche die IP vom Server.

Die kann ich mir aus den Terraform-Outputs hier wieder einsammeln und mir dann quasi so ein Service-Ensibel noch da reinschreiben.

Das sind aber dann trotzdem zwei Repos.

Das eine Repot, das Terraform-Repo mit diesem Service-Ensible, wo dann quasi ich mit Updates fahren kann oder sowas.

Oder ich überprüfe bitte den State für alle Web-Applikationen und Upgrade Django auf die neueste Variante oder so.

Und auf der anderen Seite des Ensibel des Setup läuft halt über das Ensible-Repo, wo halt dann die ganzen Standardrollen drin sind.

Ah, okay.

Ja, interessant.

Also das ist irgendwie ganz anders, als ich das geht.

Ja, ne, witzig.

Also ich muss sagen, es funktioniert

ganz gut.

Es fühlte sich auch so ein bisschen an von hinten, wie ich Broth sagt, aber ich hatte mehrere Blogeinträge durchgelesen, nur mit so führen wieder.

Und das war am Anfang so ein bisschen halt gefummelt, das so hinzubekommen, dass das funktioniert.

Aber das funktioniert halt gut.

Ja, also mein einziger Einwand wäre dann zu sagen, okay, du hast sie halt dann sehr stark verknüpft.

Ja, habe ich das.

Ja, also schon.

Also ich meine, das will ich ja auch.

Also ich will ja quasi schon sagen, was wir rollen, das haben sollen.

Nicht nur die Hardware festlegen.

Ja.

Weil das ist ja auch genau das.

Also ich will ja nicht nur irgendeine Hardware haben und dann sagen, okay, vielleicht das mal, das mal, das mal das, sondern ich habe eigentlich, wenn ich eine Hardware habe, hat die auf jeden Fall schon direkt einen Zweck.

Ah ja, okay.

Und das läuft halt dann so, dass ich quasi Terraform-Ordner habe für jedes einzelne Projekt, also auch für so bestimmte Rollen.

Das ist ein Terraform-Ordner Django-Server, ein Terraform-Ordner Bucket, ein Terraform-Ordner Datenbank-Server irgendwie so.

Und da werden die Sachen halt dann, kann man die auch so schnell eskalieren, weil die Variablen stehen halt dann direkt mit drin und dann weiß ich halt, okay, Datenbank-Server ist ein bisschen schneller oder so und hat ein bisschen andere Netzwerkkonfiguration oder sowas.

Ja, gut.

Okay, ja auch.

Das klingt irgendwie.

Genau, also erinnert mich auch so ein bisschen an Vagrant jetzt, was man vor Docker gemacht hat.

Da konnte man ja auch die Ansible Playbooks reingeben.

Und dann hat er einem dann den Vagrant so hochgezogen, wie man das letztlich im Playbook stand.

Ja, ja.

Also ich erinnere mich da auch noch dran, dass man das habe ich 2000, wann war das?

2012, 13 habe ich das mal gemacht.

Das war ziemlich schrecklich, ehrlich gesagt.

Ja, aber da gab es noch keinen Docker.

Da gab es noch keinen Docker, genau.

Deswegen muss man da ein bisschen.

Ja, ja, ja.

Anderer Punkt.

Ich wollte dich nicht unterbrechen, aber.

Ja, also ne, sag ruhig denn.

Ich mag es auch meinen Debian Desktop per Ansible ausrollen.

Ja.

Okay.

Also kann ich absolut verstehen, weil ich hatte auch so eine Diskussion online.

Für Linux gibt es kein Endpoint Management.

Und da muss man sich einfach mal überlegen, ja, was ist denn der Endpunkt?

Also was ist der Unterschied zwischen Server und einem Laptop bei Linux?

Dass ein X11 läuft oder Valent und den Rest kann man ja genauso benutzen am Ende.

Also von daher eine wunderschöne Sache, das mit Ensibel zu machen.

Ja, also die Alternative wäre nix gewesen.

Ja.

Aber da mich nichts genervt hat an so ein paar Punkten, weil dann habe ich dann gesagt, okay, dann mache ich es mit Ensible, weil ich möchte auf jeden Fall eine reproduzierbare Maschine haben, weil ich mich nervt, dass jedes Mal selber rumkonfigurieren zu müssen und so.

Und das ist halt nicht nur irgendwie dort falsch, sondern das ist halt noch mehr.

Und deswegen wollte ich das halt über Ensible steuern.

Da muss man halt dann immer fliegen, muss halt immer dann ein Repo haben, was halt für sein Desktop ist, muss er halt da immer dran rumfummeln, wenn man die Konfiguration hat, die updaten, aber dann kann man halt, egal wo man ist, einfach seine Sachen reproduzieren.

Und wenn man auch irgendwie seine irgendwie sonstige Sachen irgendwie eine Cloud hat, dann kann man, egal wo man ist, einfach mit seinem System, wie man es gewohnt ist, genauso arbeiten.

Das finde ich irgendwie schon nett.

Ja.

Aber das gibt es ja auch so die Bewegung, das dann letztlich wieder über Docker zu machen.

Dann auch zu sagen, okay, ne, wir können ja auch grafische Anwendungen in Docker laufen lassen.

Ja.

Ja, ja, kann man auch das.

Docker hat so einen Zwischenlayer irgendwie noch, ne?

So ein bisschen, ich weiß nicht, ob es einen Performance-Mustrenneh gibt.

Also ich meine, die Rechner, die wir nutzen, sind ja meistens relativ strong, aber ja.

Ja, es gibt schon irgendwie so ein bisschen Einschränkungen, aber es gibt es inzwischen sehr, sehr häufig, dass man halt auch auf vielen Projektseiten sieht.

Also ich meine gerade, ich kann es auch verstehen, wenn es halt irgendwas ist, was man einfach, was schwer zu installieren ist.

Und da gibt es ja durchaus Software, dass man sagt, yo, okay, nimm doch hier einfach diesen Docker-Container, dann geht's.

Bevor du jetzt irgendwie sowas wie zum Beispiel, es gibt halt manche Software so mit Abhängigkeiten zu Qt und so, wo man dann halt erstmal anderthalb Stunden kompilieren muss und das dann.

Ja, also genau, also ich glaube, das Kompilieren ist das, was lange dauert und Updates sind halt immer ein bisschen nervig, ne?

Wenn man halt irgendwie so Breaking-Changes irgendwo hat und dann muss man alles wieder umbauen.

Ja.

Ja.

Ja, also früher hat man auch dann mehr Ansible-Playbooks gesehen, wenn es dann um schwierige Installationen ging.

Ja, leider ist es so ein bisschen auf dem absteigenden Ast.

Was will man denn jetzt?

Nur Docker dann?

Ja, also oft findet man halt die Docker-Container erstmal hier, ne?

Also wenn du das einfach dem Run sagst, dann läuft der und dann kannst du.

Ja, das finde ich auch faszinierend, weil, also ich sehe das, ich sehe diesen Trend durchaus auch, aber ich finde ehrlich gesagt, so von dem, wie fühlt es sich von der Benutzung her an?

Docker wird eher immer schlimmer.

Also ich fand auf.

Ehrlich gesagt, aus meiner Perspektive.

Ich habe das zwischendurch ganz gerne genutzt, aber irgendwie weiß nicht, irgendwas finde ich nervig.

Ja.

Das ist immer so gekapselt auch.

Also ich habe es nicht für den direkten Zugriff.

Also sag mal so, es nimmt einem schon irgendwie Probleme ab, aber es hat halt auch nicht so ganz die Flexibilität, die man mit Ansible hat.

Also gerade was man bei Docker dann doch irgendwie öfter mal was anderes passiert, so zum Beispiel irgendwie so, irgendwie das Pfeilsystem ist halt voll.

Man weiß halt nicht genau, warum.

Und dann guckt man halt und dann sagt, ach ja, deswegen, ach, und dann, uh, oi, was liegt denn hier noch alles rum?

Ich habe jetzt

diesen Container 30 Mal hier.

Ja, genau, genau.

Solche Sachen.

Oh, Docker-Kompos down vergessen.

Ups.

An der Stelle ist die Abstraktion halt schon sehr leaky.

Oder man muss halt sich gut mit Docker auskennen, ja.

Oder was ich dann halt oft sehe, wie Leute dann so, so wirklich, also in größeren, großen Firmen, wo dann Leute da sitzen und irgendwie, wo dann das halt alles vereinheitlicht ist, wo alle Entwickler irgendwie Docker verwenden, ja.

Und dann so, ah ja, okay, ich muss hier ein neues Paket für das Docker-Image, ja, und dann warten die halt da irgendwie stoß eine halbe Stunde, bis das irgendwie alles korreliert ist und die Dinger sind halt die Images.

Dann denken sie so, hä, das dauert eine halbe Stunde, bis die Images da?

Hä?

Was macht ihr denn da?

Und dann so, ja, nö, das ist doch normal, das ist doch immer so.

Dann guckt man rein und so, dann nehmen sie dann halt ein Alpine irgendwie Linux, ja, und dann installieren sie aber NumPy, ja.

Und dann zieht das erstmal in ein GCC nach und dann wird erstmal die komplette Compiler-Tool-Chain irgendwie kopiliert.

Und dann, ja, und dann ist kein Wunder, warum das so lange dauert.

Aber es ist halt irgendwie so, ja, und die Images werden riesig, ja.

Dann nehmen sie Alpine, damit die klein werden und dann werden die irgendwie anderthalb Gigabyte groß.

Und ja, und dann denke ich so, oh.

Also irgendwie, ihr haltet das falsch rum.

Das ist irgendwie, das, ja.

Und aber ich habe das Gefühl, es hindert die Leute.

Also ich denke, das ist eigentlich ein ziemliches Katastrophenszenario, ja, und eigentlich müsste man sagen, also wenn, also es müsste den Leuten doch irgendwie auffallen, dass das jetzt alles furchtbar ist, oder?

Aber das ist nicht so.

Die Leute halten das für normal und das ist dann jetzt halt so und dann verbreitet sich trotzdem.

Und das finde ich immer faszinierend.

Sweden wir noch bei Docker oder schon bei JavaScript?

Ja, bei JavaScript und irgendwie in Terme und diesen ganzen, ja, das ist teilweise so ähnlich, ja.

Also es gibt doch jetzt bei Stat-APN ganz viele andere Sachen, die nur und bannen

oder irgendwie.

Ja, aber das ist auch alles ziemlich furchtbar.

Also ich meine, gut, vielleicht liegt es irgendwann so, ja, wird das da auch mal.

Ja, egal, Entschuldigung.

Wir wollten nicht über da mehr.

Man verliebt sich halt irgendwann in die Komplexität und dann macht das auch Spaß und keiner weiß mehr, wie es geht.

Und dann hat man auch mal so eine Expertenrolle.

Das ist auch schön.

Genau, also wenn keiner mehr weiß, wie es geht, dann ist es halt ziemlich anziehen.

Job Security ist auch ganz wichtig, oft, ja.

Die hätten wir ja eigentlich eh, ne?

Aber ja, und ja, ich weiß nicht, also ich finde, also ich so im direkten Vergleich, ja, wenn ich jetzt irgendwie, das habe ich früher gemacht, zum Beispiel Python-Podcast.de, wenn man sich das anguckt, das ist tatsächlich, das ist ein Cookie Cutter-Template für Django und dann ist da auch ein Docker-Container oder mehrere Docker-Container, weil das halt auch Datenbank und so und das läuft alles auf Docker-Container und ist halt irgendwie deployed.

Als ich angefangen habe, Sachen zu lernen, hat Joch mir gesagt, das ist so, wie man das macht.

Und dann stand ich erstmal von dieser Komplexität.

Ich kam ja von Vagrant und da sah das aus, als wäre das fortschreitet.

Also ich musste erstmal ein paar Mal gegenhauen und dann habe ich jetzt gedacht, was ist das denn jetzt?

Wie geht denn das jetzt?

Was muss ich denn jetzt eingeben?

Tausendlange Kommando, Zeilen, Listen schreiben, umständlich was machen.

Und dann überhaupt das Introspectrum, das war schon echt ein Komplexitätsmonster, muss ich sagen.

Ja, also es tut mir leid, aber so ist es halt.

Und ja, aber das läuft noch alles auf Docker und so.

Und es ist aber nicht, es ist, also wenn ich das jetzt vergleiche, auch den Betrieb davon mit irgendwie, ich mache jetzt schon seit einiger Zeit, ich habe es noch nicht geschafft, das eine auf das andere umzuziehen.

Also sozusagen die alte Infrastruktur läuft immer noch und ich habe den direkten Vergleich noch und letztens hatte ich da das Problem, dass da irgendwas, es ging nicht mehr und irgendwas war vollgelaufen und ich wusste, oh mein Gott, ich muss in diese Docker-Container reingucken, oje, habe ich eigentlich ein Backup?

Hab ich wirklich keinen Deck, wo liegt denn das?

Hoffentlich mache ich jetzt nichts kaputt.

Und ich vergleiche das jetzt so mit dem, was ich jetzt mache und das ist halt irgendwie die Dinger einfach direkt via Ensible zu installieren.

Und ich habe halt für jeden Service halt einen eigenen User und der hat halt ein eigenes Virtual Enter da nochmal drin und das wird einfach alles so hochgezogen und hat dann auch ein schreibbares Dateisystem und so.

Man kann auch so eine Backup-Holle installieren, dann überläuft das Vernünftiges, man weiß dann auch, wo die sind, das ist alles so ordentlich.

Ja, so aber man kann auch überall reingucken, ja, man kann da einfach als gut mal so irgendwie über alle irgendwie drüber gucken und gucken, was da so los ist.

Das ist deutlich angenehmer und so viel länger sind die Playbooks nicht als die Docker-Files mit dem ganzen drumherum Start-Stopzeugs, das man da sonst so hat.

Ja, vor allem wenn die einmal gut sind, dann

eigentlich angemeldet.

Und das ist halt viel transparenter als.

Ja, man muss halt gucken, welche Vorteile bietet einem letztlich der Docker-Container und nutze ich die überhaupt?

Oder manchmal ist es auch ganz schön, einfach nur einen richtig großen Server zu haben und da laufen halt die Sachen dann alle sehr lokal drauf.

Ja, weil die sowieso alle uniform sind und man halt nicht, sagen wir jetzt mal, zehn Container braucht, um jede App zu kapseln.

Ja, ich meine, ich kann es natürlich in gewisser Weise verstehen, auch da wieder, wenn man halt irgendwas hat, was sehr schwer zu kompilieren ist, ja.

Oder gibt es da, ich weiß nicht, ob das bei XKCD oder sonst wie irgendwo ein Comic war, wo ein Entwickler irgendwie da sitzt und so leise vor sich hin, weil dann sagt so, aber auf meiner Maschine läuft es.

Und jemand klopft ihm auf die Schulter und sagt, okay, dann schippen wir eben deine Maschine.

Das ist natürlich so, ja, wenn du sonst einfach nicht deployed kriegst, außer du schippst das, was der Entwickler da hat, dann ist Docker möglicherweise sehr gut.

Und wenn du dann viele von solchen Sachen auf einer Maschine laufen lassen willst, dann führt vielleicht um Docker auch kein Weg drumherum.

Aber das ist ja letztlich auch der Kritikpunkt an Python, dass man quasi immer die Entwicklermaschine schippen muss, damit sie überhaupt läuft.

Ja, das ist natürlich auch bei Python so ein Problem.

Wobei.

Also ich

finde, Poetry löst das, also wenn Poetry läuft.

Ja, Poetry läuft so.

Also da war meine Erfahrung, das läuft so drei Monate, vier Monate.

Auf einmal wird irgendwas irgendwo kaputt und dann.

Cache reparieren, Neuversionen irgendwie installieren, pre.

Fällt das alles auseinander, genau.

Ja, ich stelle momentan auch Sachen.

Wenn ich alte Projekte habe und ich sehe dann, ah, dafür bin ich noch Poetry, ich stelle es meistens nochmal auf Piptools, weil.

Aber Piptools ist furchtbar.

Wird auch Verführter von Pip Tools, weil letztlich ist es nur Pip.

Ja.

Genau.

Und wenn jemand Pip brechen sollte, dann fällt auf.

Und dann machen andere Ärger dafür.

Das ist so viel Ärger, dass das dann wieder funktioniert schnell.

Also, genau.

Es ist letztlich nur Pip und man kann sich da ja Tools zum Rumschreiben, die das halt angenehm zu benutzen machen.

Ja, zum, ja.

Oh, ich habe jetzt, das habe ich dann nochmal versucht, weil du meintest, es kann auch PiProject Hommel können, äh, Pip-Tools können das nicht so richtig sein.

Ja, genau.

Nee, das so.

Ich brauche Pipe Project Hommel.

Also ich finde die super.

Das ist eine gute Idee.

Ja.

Weil diese ganzen ganzen TXT-Files mit irgendwie.

Ah, ne, bäh.

Ja.

Ich will die ganze Konfiguration im Pi-Project Hommel haben, ich will die Pakete da drin haben.

Und also ja.

Was man auch machen könnte, man kann ja einfach einen Tommelparser nehmen und dann die Dinger automatisch generieren aus seiner Popular-Party.

Ja, das ist auch wieder sehr eklig.

Ja, gut, naja.

Ehrlich gesagt, ja.

Ja, okay.

Aber ja, ich stelle das jetzt alles um und ich finde auch vom Deployment-Aspekt her ist Pip Tools deutlich angenehmer als Poetry, weil Poetry ist auch beim Deployment ganz schön hackelig.

Na, aber das habe ich jetzt gelöst tatsächlich.

Ja, wie installierst du denn Poetry?

Also ich installiere Pyen, dann das Python, was ich

mal finde.

Okay.

Dann Pipx.

Aha, O, oh, oh, okay.

Und Pipx und Poetry, das funktioniert gut.

Und dann habe ich das Poetry drauf, was gemacht hat.

Ach, du installierst dann Poetry per Pipx.

Genau.

Das ist aber nicht die empfohlene Art.

Es ist furchtbar.

Die Empfohlenart ist furchtbar, das zu tun.

Ja, da ist nämlich ein Shell Script runterladen oder auch nicht.

Ja, genau, das ist komisch.

Und deswegen per Pipx, aber weil dann, das funktioniert dann super und dann habe ich dann per Pipix, kann ich dann Poetry benutzen, um halt meine Environments zu installieren und ein kurz-config-Setting für Poetry und dann.

Aber das ist das ist schon ein ganz schöner, auch irgendwie.

Es ist Playbook.

Ja, ja, das ist aber gut.

Und wie kommst du an den, und erzeugst du deine Virtual Infs auch über Poetry?

Ja.

Wie kommst du an deinen Interpreter, wenn du jetzt mal sowas wie Manage Migrate ausführen willst oder so im Django-Kontext?

Du kannst ihn ja einfach dann lokal zum Beispiel nehmen.

Ja, aber Poetry macht halt so komische Verzeichnisse mit einem Hash drin, die irgendwie immer anders sind.

Das ist egal.

Nee, das ist nicht immer anders, das ist reproduzierbar.

Ich habe mir eine Funktion getrieben, die mit den Namen von Event.

Ja, das habe ich nämlich auch gemacht, genau.

Ich sehe dann ein Muster.

Genau, das habe ich nämlich auch gemacht, aber das ist halt dann so, da gucke ich dann jetzt immer so drauf und denke mir so, warum nehme ich da an der Stelle nicht einfach einen Virtual Env so und dann weiß ich vorher, wo der Pfad ist.

Ja, was halt geht, ist, du kannst halt die Virtual Ents in Project Pass dann machen.

Das mache ich bei Deployments dann, weil dann ist das Problem erledigt.

Weil dann hast du es halt einfach lokal drinnen liegen.

Und dann kannst du halt den Pfad, kannst du ja auch angeben, dann macht der halt nicht irgendwo unter Ems mit einem Hash, sondern dann lädt das rein und das würde ich empfehlen.

Aber das ist auch genau der Punkt.

Also benutzen wir Docker, weil wir eben daherkamen, auf Produktionsmaschine.

Ich würde fast sagen, nein, also weil das halt auch zu viel Hardware frisst und man möchte ja relativ viel kaputt sein.

Außerdem Netzwerkprobleme hat man auch, wenn man

das von Docker macht.

Das ist auch sehr nervig.

Und deswegen würde ich die Sachen Produktion direkt auf die Maschinen deployen.

Aber in Dev würde ich sagen, will man vielleicht Docker-Container benutzen zum Entwickeln, weil man halt oft Entwickler hat, die auf unterschiedlichen Maschinen arbeiten, um die Konsistenz zu sichern.

Also das wäre der einfachste Grund, weil die Leute halt keine Lust haben, irgendwie gleiche Sachen zu benutzen.

Es gibt ja

auch Entwickler, die Windows benutzen.

Ja, aber kommt man dann mit Docker schon mal ein bisschen weiter?

Also ich hab mich muss das auch auf der Arbeit fielen und da ist halt, habe ich halt auch entforckt, dass wir Docker-Container nehmen, weil halt viele Sachen dann auf Linux nur kompilieren, richtig und auf Windows das immer von hinten durch die Brust ins Auge ist oder irgendwelche C-Libraries nachinstallieren muss, was man auch manchmal meistens hinkriegt, bis auf ein paar Ausnahmen, aber das ist manchmal sehr, sehr, sehr nervig.

Und wenn man das mit Leuten macht, die sich da nicht gut mit auskennen, dann wird man immer gegen irgendwann deswegen entwickeln.

Im Docker befreit einen einfach von diesem Schmerz, weil das

relativ klar, was dann macht.

Wobei ich ja, also wie gesagt, mit diesem Windows-Subsystem von Linux und dann einfach da ein Debion drauf haben oder so, das kommt man ja auch schon relativ weit.

Nur was ich jetzt letztens immer irgendwie dann doch häufiger gesehen habe, ist, dass halt, wenn dann Leute eine Idee verwenden, die dann wieder unter Windows läuft, dass dann irgendwie in dem Fallsystem manchmal Probleme gibt und jedenfalls Leute mal so, hä, und dann kommen die politische Schüler.

Oh, irgendwie ist das, was dann in Linux nicht das gleiche konfigurieren?

Genau, und die Pfade werden halt gemountet, also zum Beispiel in Windows-Crips halt so ein FPC-Doppelpunktback slash bla bla bla.

Das wird halt unter Mount C irgendwie abgelegt.

Und dann muss man halt die Pfade tatsächlich gucken.

Das muss man eigentlich über Environment-Variablen machen.

Die werden zum Beispiel von VS Code nicht immer direkt unterstützt, sondern nur in bestimmten Fällen.

Und dann muss man eigentlich relativ laden und muss halt dann zum Beispiel VS Code dann das Verzeichnis mounten und so.

WSL hat noch ein paar andere Probleme.

Zum Beispiel ist es dann oft, wenn man Windows hat, weil dann irgendwelche Leute mit Active Directory Zugriff das einfach sperren.

Da hat zwei WSL drauf, aber ohne Updates oder so.

Das kann man es halt nicht richtig benutzen.

Und die Frage ist, warum man Windows benutzen will, wenn man VSL benutzt, weil, also aus der, ich sag mal, Maschinen-Deployment-Methode.

Also der Grund, warum ich das in letzter Zeit immer gesehen habe, ist halt, weil Leute sagen, ja, ja, weil halt allen der Rest der Firma quasi in der Windows-Welt hängt und mit dem kooperieren.

Genau, aber so mache ich das bei mir privat auch, wenn ich Windows benutze und dann mache ich das auch mit WSL2 oder so, das ist super.

Aber jetzt in der Firma beispielsweise, wenn ich jetzt ein Windows-Management-System habe oder ein Team habe, was halt über Active Directory die Zugriffe kontrolliert und ausrollen will, dann macht es relativ wenig Sinn, wenn ich den Leuten an WSL freischalte, weil dann halt von hinten die nämlich wieder rauskommen.

Und das will ich ja eigentlich gar nicht.

Das ist so ein bisschen blöd.

Und da gibt es noch nicht so die gute Lösung für oder wenig gut konfigurierte Teams, würde ich jetzt sagen, oder dass das gar nicht so einfach, das ordentlich zu konfigurieren.

Dass das halt genau diese ganzen Scherze dann nicht ermöglicht oder halt ein bisschen besser macht, das so ein bisschen.

Ja, dann werde ich fragen, ob vielleicht ist es dann besser, wenn die nicht auf der lokalen Maschine arbeiten, sondern mit einer IDE dann irgendwo hin connecten und darauf arbeiten.

Ja, also letztlich.

Und dann fällt das WLAN aus.

Da kann man eh

nichts mehr machen.

Also weiß man gar nicht mehr, wo die Dokumentation

läuft, tatsächlich.

Aber das fand ich.

Das fand ich sehr witzig.

Ich habe jetzt letztens einen Podcast gehört, mit der mit einer der Engineering-Chefinnen, ich glaube, es ist nicht CTO, sondern irgendwas drunter, aber auch Chefin von irgendwie 500 Entwicklern bei GitHub, die meinte, GitHub ist intern auf Codespaces umgezogen.

Also quasi komplett in der Cloud, ja.

Also wie es Code und Codespace, also sozusagen, deren komplette Entwicklungsumgebung sind halt immer auf irgendeiner Maschine bei Azure.

Auch Azure.

Machen sie halt deswegen, weil sie bei Azure nicht zahlen müssen, weil du gehört zu Microsoft.

Aber steht komisch durch.

Ja, das ist natürlich praktisch.

Es könnte natürlich ihren Move dahin ein wenig irgendwie genatscht haben, sozusagen, dass das passiert.

Einmal noch eine kurze Warnung an der Stelle.

Die Azure Linux Web-Apps laufen auf einem Windows.

Unten runter, das ist so ein bisschen blöd.

Das ist mir noch ein paar Mal aufgefallen, als ich irgendwelche Tracebacks bekommen habe, wo ich dachte so, ups.

Ja, ich weiß auch nicht, ob man es so, also ich wäre da nicht so early dabei, das zu adopten, quasi so rein in der Cloud zu sein.

Aber ich kann es in gewisser Weise verstehen, weil man löst damit halt auch dieses Problem, was Docker-N sonst vielleicht dann lösen würde und halt unter Schmerzen, weil ehrlich gesagt, Docker Desktop, also gut, ich kann jetzt nur von Mac sprechen, ich habe keinen, kann sein, dass es unter Windows besser ist, aber auf Mac ist Docker Desktop dieses Docker-Desktop ist halt so ein unfassbarer Schrott, echt.

Also, wie oft mir das gestorben ist und zwar auf eine Art, dass ich das nicht mehr reparieren konnte, ja.

Ja, da Updates gehen nicht oder so.

Ja, Updates gehen nicht.

Ich hatte so mehrfach, dass mir Docker-Desktop gesagt hat, das Binary ist kaputt.

So nach einem Update-Versuch.

Ich musste ganz hart einfach das wegschmeißen und dann nicht mal wegschmeißen aus der Registry, aus der Windows-Registry rauslöschen, also quasi die ganzen Upfiles irgendwo aufsammeln und rausfinden, wo die sind.

Wegschmeißen, neu machen, damit es funktioniert.

Furchtbar.

Ja, und langsam und komisch und ja, ich verstehe nicht so richtig, warum dieses Ding so, also es ist.

Und wenn man davon wegkommt, dadurch, dass man das in der Cloud macht, ja, das könnte man mir vorstellen, dass das für viele Leute vielleicht durchaus

interessant wird.

Ja, wahrscheinlich.

Ja, gute Idee.

Ja, also PyCharm bietet das jetzt auch.

Ja.

Dass man in der Cloud arbeiten kann.

In derselben?

Oder ist denn das dann unterschiedliche?

Also muss man sich entscheiden oder kann man die parallel benutzen?

Ich glaube, das sind unterschiedliche.

PyCharm bietet nämlich da, glaube ich.

Also es gibt dann wieder so ein Angebot, dass man dann so Dev Spaces zusammen hat.

Bist du Pycharm oder VS Code, oder?

PyCharm, okay.

Also PyCharm für Python und VS Code ist eigentlich ein schöner Texteditor.

Also wenn man das Microsoft-Zeug wegnimmt und VS Codium nimmt, dann ist das ein schöner Editor.

Und dann kann man halt viele Sachen damit machen.

Okay, ich mache es auch so, also ich mag es ja gerne.

Ja, aber also letztlich so dieses vollintegrierte IDE, da ist man ja bei PyCharm einfach komplett.

Komplett ohne irgendwas konfigurieren zu müssen.

Man macht es an und dann ist man drin.

Würde ich auch sagen, ja, okay, vielleicht mit Konfiguration, aber ich habe jetzt, also Kollege, wir haben immer diesen Battle noch nichts gefunden, was ich nicht andersrum so oder so lösen könnte.

Ja, das ist ein Muster, ne?

Das ist dann.

Ja, ja.

Ja, also man kann das durchaus, also ich habe beides jetzt auch schon ausgewürfen, man kann durchaus beides verwenden, denke ich.

Aber ich finde auch PyCharm ist halt, wenn man Python macht, ist es schon, es hat auch noch so ein paar nette Funktionen.

Also zum Beispiel ein Ding, das mich mit der, ah, vielleicht habe ich was.

Ob du das mit V-Scode hingekriegt hast, weil ich habe es bisher noch nicht hingekriegt.

Auf Pytest Fixtures klicken und dann im Code der Fixture landen.

Das macht PyCharm einfach so.

Auf die Fixes.

Ja, weil das ist tatsächlich ein Use Case, den ich häufig habe, wo sich dann bei VS Code dann so kreiert und kriegt das denn jetzt nicht richtig?

Das funktioniert irgendwie nicht und dann so, ach nee, VS Code kann das nicht.

Fand ich auch immer, das fand ich auch immer sehr angenehm bei PyCharm, dass man halt so schnell springen kann.

Ja, gut,

das kannst du, also VS Code, äh, Fictions muss ich gerade überlegen.

Muss ich mal ausprobieren.

Also vielleicht gibt es irgendein Plugin, das das kann, aber so einfach so und mit dem Microsoft Language Server und so, das geht nicht.

Aber ich finde, die entwickeln relativ schnell.

Also es gab auch einen Microsoft-Stand auf der EuroPython, wo die alten meinten so, oh ja, voll gut, und sagt mal, was uns noch fehlt, wir bauen das halt alles einfach ein.

Ja, ja.

Da ist viel Druck hintergrund.

Also Twitter Asia war halt irgendwie, als auch Python 3.8 noch, da habe ich auch gedacht, ey Leute, geht noch gar nicht.

Aber da arbeiten sie wohl dran, da ist wohl.

Aber Editor Wars.

Ja, das alten Logi-Kies oder haben wir irgendwie sowas.

Also Wim

ist eigentlich auch ganz gut.

Gut, dass hier niemand E-Mails nutzt.

Hallo Johann.

Ja, ja, ja.

Ja.

Oh, das ist auch ganz, äh, habe ich letztens, also da muss man ein bisschen Zeit mitbringen, aber vielleicht, also mich hat das, ich hatte dann so ein nostalgisches Gefühl und dann muss ich das anhören.

Lex Friedman Podcast an der letzten Episoden ist mit John Carme.

Don Carmet, der, Don Carmet, der von Quake.

Ja.

Ja, okay.

Genau.

Da hatte ich da so, ah, okay.

Es ist so fünf, äh, fast fünfeinhalb Stunden lang, aber die länger Generation.

Ja, und genau, ich dachte so.

Und ein Docker-Bild.

Genau.

Das war sehr kurzweilig, dann denke ich, genau.

Der Sehr Quake 1 brauche ich immer die Konsole auf Tilde.

Ah, ja, ja.

Das ist auch mein Bein, ja.

Nimm als Control-Tilde aber.

Ja, und das war ganz interessant, weil da der redete dann auch so ein bisschen über die, beteiligte sich an diesem Editor War so ein bisschen.

Und der hat dann auch irgendwann mal versucht, Wim zu verwenden, sich mal eine Woche irgendwie eingeschlossen versucht, das zu lernen und dann drauszukriegen, warum Leute das gut finden, aber es hat ihn nicht überzeugen können.

Er ist bei so auch so eher auf der IDE-Seite und viel Debugger verwenden.

Und ja, er meine er macht das nicht so extrem wie andere, machen das sowas wie eine uralte, nicht wie es Code, sondern tatsächlich Visual Studio Versionen verwenden, so Visual Studio 6 oder sowas, was dann halt auf den Rechnern damals gerade so ging.

Und dann auf den heutigen Rechnern ist es halt einfach sackschnell und alles ist instant sofort sofort da.

Und ja, dann genau schreibt er halt meistens so irgendwie C-artiges C<unk> oder sowas und macht halt viel im Debugger.

Und das fand ich, aber ich fand es gerade interessant, also einfach mal so zu hören, wie er da so Sachen macht und so.

Also Charmex ist natürlich ein Guru, ne?

Dugendquake.

Naja, ja, tatsächlich.

Also ich genau, die auch ich damals habe ich so ein bisschen, ich meine, ich habe es nie gespielt, aber ich habe ein bisschen geguckt, was sie so im Grafikbereich machen und fand das.

Er hat es nie gespielt.

Oder nie wirklich, ich hab's vielleicht mal gespielt, aber ich habe es nie Ehrgeiz entwickelt oder mich da lange mit anderen da top.

Kurze Anekdote, ich war damals gerade irgendwie Clan-Base, irgendwie Liga und da waren wir relativ weit oben, also ich glaube European Top 3.

Wow, okay.

Das war ganz gut.

Ja, Q2 TTF.

Ja, ja, dann TTF hieß damals noch was anderes.

Ja, und genau, also aber was da so im Grafikbereich zum Beispiel bei Quack und so passiert ist, das war gerade zu dem Zeit, zu der Zeit, wo ich da auch irgendwie so mit Informatik und Grafik da, das war, da waren schon einige abgefahrene Sachen dabei und da dachte ich so, wow, krass, also das ist ja so irgendwie, so Spieleentwickler, die machen da irgendwie so ein bisschen, das war halt schon so echt, da so, okay, das sind, die haben, die machen ja echt, also die implementieren da wirklich so ganz, ganz aktuelle Forschungsgeschichten direkt und machen das h

alt besser als alle anderen und so.

Wahnsinn.

Insofern, ja, also mich hat mich schon interessiert, wie der dann so arbeitet und so.

Ehrlich gesagt, was ich so ein bisschen frustrierend fand, ist, dass eines der Geheimnisse hinter seiner Produktivität wohl einfach ist, wahnsinnig viel arbeiten.

Hätte mir eine andere Antwort gewünscht, eine andere Lösung für dieses Problem.

Ich wäre gern auch sehr produktiv, aber das mit dem Arbeiten, das gefällt mir nicht.

Das muss irgendwie anders auch gehen.

Ja, aber das ist einer, er meinte so, ja, das ist halt eines seiner, der hat einfach wahnsinnig viel gearbeitet.

Es gibt auch Leute, die können einfach schneller tippen, die haben ja sowas wie 500 oder 600 Anschläge, die Mutti waren.

Meistens ist es ja nicht, wie schnell ich den Code da in die Datei bekomme, sondern wie schnell ich darüber nachdenke.

Ja, ja, genau.

Und das, ja.

Brain-Manchine-Interface.

Er meinte, dass er redet dann sogar als locker Flock, ich meinte so, ja, also er hat ja dann immer Stress im Internet, wenn dann Leute meinen, so na, aber mehr als acht Stunden, dann ist man ja nicht mehr so produktiv und er meinte, ja, das ist schon so, man ist dann nach acht Stunden nicht mehr so produktiv.

Aber man ist halt noch so ein bisschen produktiv.

Also nicht mehr so produktiv wie in den ersten acht Stunden, aber man kann ja noch ein paar Stunden weiterarbeiten und ist dann halt nicht mehr so produktiv, aber das ist ja dann immer noch mehr als voll.

Ja, das ist richtig.

Wenn es sich am nächsten Tag kann irgendwie sich auch, also dann dass man nicht mehr, also bei mir ist das auch am nächsten Tag reduziert sich dann meine Produktivität auch deutlich.

Also bei mir ist das anders.

Ja, ja, ja.

Er ist ein bisschen neidisch auf Leute, die dann halt nur vier Stunden schlafen müssen, am nächsten Tag wieder top-fit sind und das lange durchhalten können.

Und das kann er auch nicht, sondern so nach zwölf Stunden programmieren ist halt bei ihm auch irgendwie Ende.

Aber das kann er tatsächlich sustainable durchhalten.

Er meinte so, zwölf Stunden am Tag programmieren, kann ich sustainable machen, habe ich es seit ein paar Jahrzehnten gemacht, das geht.

Ich krieg dann auch keinen Burnout oder so.

Das geht einfach immer so weiter.

Okay, oh oh.

Das ist mir ein bisschen zu hart, ehrlich gesagt.

Also schon nachvollziehbar, so wenn man so richtig Bock hat, dann hört man auch nicht mehr auf.

Ja, aber das kannst du ja nicht länger als zwei, drei Monate durchziehen.

Denn irgendwann brauchst du da wieder ein bisschen Luft und.

Ja, seine Einstellung war dazu, diesen ganzen Quatsch brauche ich nicht, ich brauche nur Dietcok und Pizza und dann, das war reicht.

Genau, also das Sozialleben leidet dann zwar, aber wenn man sich so richtig dann zurückzieht und dann.

Die artige Vampirblässe.

Ja.

Erinnert mich so ein bisschen an die Anfangszeiten, wo ich dann programmiert habe und herausgefunden habe, wie alles funktioniert, auch mit Django.

Und ja, da habe ich eigentlich jede freie Minute an Django geschrieben und das gemacht.

Das waren coole Zeiten, aber mittlerweile geht das auch nicht mehr.

Longe, Alex, ich war

far away.

Aber ich frage mich, ob das bei, also das ist auch etwas, was ich von vielen Leuten höre, dass sie halt eine Phase hatten, wo sie das sehr intensiv, also das muss ich, also ich habe auch eine Phase, so phasenweise irgendwie Dinge sehr intensiv gemacht und ich weiß nicht, ob vielleicht das notwendig ist.

Also bei T jetzt Ende oder sowas.

Auch danach noch.

Bis wann geht das?

Das ist so eine Fleetback-Loop.

Je länger du das machst, desto länger machst du das, desto länger machst du das.

Und wenn du da aus dieser Loop nicht rauskommst, dann wo ist das Limit?

Ja, keine Ahnung.

Ich warte noch auf das Fall.

Ich hoffe mal, irgendjemand kommt da mal an und sagt so, ich mach das immer so zwei Stunden am Tag und ist trotzdem irgendwie sehr produktiv dabei geworden und kriegt irgendwie Dinge hin.

Das wäre nett, weil das wäre, das wäre, ich wünsche mir das nicht.

Ja, ich habe am Anfang auch, also in Python zu denen auch 70 Stunden investiert waren.

Ja, ja, eben, ja.

Also irgendwie, ich höre das von vielen.

Ja, also diese Rechnung halt ist halt tatsächlich irgendwie, wenn man, wir tun jetzt mal so, als schaffen maximal Produktivität, in der ist halt immer da ist irgendwie, ne?

Und wenn man irgendwie jetzt fünf Stunden die Woche was macht oder 70 Stunden die Woche und dann macht man das zwei Jahre lang und man ist genauso gut, dann ist derjenige im Verhältnis zu demjenigen, der es fünf Stunden die Woche macht, einfach um 28 Jahre weiter.

Ja, ich glaube, man kann es nicht so naiv rechnen.

Ja, also naiv

rechnen, natürlich, Zeiteffekt, lalala, aber der Punkt ist ja, glaube ich, relativ klar.

Also man kann das im Leben nicht aufholen, wenn man das versucht, so nebenbei.

Ja, ja, ja.

Ja, also der eine Effekt ist halt, dass man natürlich irgendwie nicht die ganze Zeit so gut dazulernen kann, wenn man das so lange macht, sondern dann halt irgendwann weniger lernt und auch nicht so produktiv ist.

Auf der anderen Seite ist es so, wenn man, wenn man sehr langsam lernt, dann ist zwar die Zeit, die man investiert, besser investiert, aber das Problem ist, man vergisst dann ja auch wieder Sachen.

Ja, also ich weiß nicht.

Wir hatten bei uns schon mal dagegen drum gestritten, um so eine Sache, die ich persönlich sehr effektiv finde.

Und zwar ist das, wenn irgendwas nicht funktioniert, da so lange gegenhauen, bis es

kaputt geht.

Ja, ja, genau.

Wo du sagtest, das ist Quatsch, also lieber weggehen und unter der Dusche fährt man dann ein.

Also was natürlich auch stimmt bei bestimmten Sachen.

Aber ich finde halt auch durch dieses Gegenhauen von allen Seiten und das irgendwann kaputt machen, lernt man halt intensiver und man merkt sich die Sachen mehr, weil man so lange gegengehauen hat, bis kaputt gegangen ist, dass man gemerkt hat, wo man halt gegenhauen kann, es passiert nichts und wo man halt vielleicht doch was umfällt, dass man beim nächsten Mal auf jeden Fall schneller da hinkommt, wo man gegenhauen muss, zum Beispiel.

Und wenn man dann halt dann nur die Einfahrtlösung hat, dann hat man diese ganzen Schläge von der Seite oder sowas verpasst.

Also ich fand das schon einmal.

Ja, kann sein, vielleicht sind auch Unterschiedleute einfach unterschiedlich.

Ja, oder ist das

unterschiedliche Themen oder sowas, wo das halt hilft, wenn hilft?

Ich weiß nicht, ja.

Also ein bisschen Guru-Meditation.

Ja.

Ja, ja.

Ja, ist aber auch, ich habe auch das Gefühl, dass ich das früher tatsächlich nicht konnte, irgendwie mehrere Projekte gleichzeitig.

Also das mache ich jetzt halt gern.

Ich mache irgendwie, wenn das irgendwo nicht weitergeht, dann mache ich halt was anderes.

Und bis da dann nichts mehr weitergeht und dann wieder was anderes.

Und das habe ich, ich habe das Gefühl, das geht jetzt eigentlich ganz gut.

Und früher hätte ich das überhaupt nicht machen können.

Früher hätte mich das total rausgebracht.

Also, ich weiß auch nicht.

Ja, vielleicht ändert man sich halt über die Zeit auch.

Ich weiß nicht, keine Ahnung.

Ja, seltsam.

Ja, irgendwie.

Der Heilige gerade an der Stelle noch nicht gefunden.

Schade, schade.

Wir sind übrigens in der Ensible-Folge.

Ja, genau, genau.

Ensible.

Ja.

Also ich habe hier noch so ein paar Sachen gestehen.

Und zwar, also einmal, was macht man mit den Outputs?

Wo kommt man die her?

Wie sammelt man die ein?

Das ist so ein bisschen technisch, ich kann mir erklären.

Testen würde ich gerne nochmal drüber sprechen.

Macht man das?

Braucht man das?

Ja, vielleicht die ganzen Commandos, Bild-S, was gibt es denn überhaupt so?

Was kann man denn damit machen?

Irgendwie, dass man so ein bisschen mal vielleicht weiß, was sind schon drin, wofür muss man denn so Community-Module nehmen oder so.

Und wie machen wir das mit so Secrets oder so?

Wo stort man die?

Wie stort man die?

Kann man die auch irgendwie committen?

Machen wir das mit Source Control?

Irgendwie so.

Vielleicht nochmal so als kleine Mini-Struktur vorweg für den nächsten Teil des nächsten Chaptermark.

Genau, wo sollen wir einsteigen?

Fangen wir oben an, also vielleicht nochmal mit dem Output.

Man hat jetzt Zeugs und man braucht den Output davon, weil man irgendwie seine Datenbank expost und wusste vorne nicht, welche Server-Hyp gab es denn da und die muss dann der Server drückt oder so.

Genau, da kann ich dann in der Task selbst eine Variable registrieren mit dem Output.

Und die kann ich dann halt über das ganze Play letztlich benutzen.

Okay, ansonsten muss man die irgendwo hinschicken.

Man kann die natürlich dann auch in der Datei schreiben oder so.

Ja, also die Frage ist genau das.

Also man muss die vielleicht auf der Control-Node irgendwo ablegen, weil vielleicht braucht man die beim nächsten Run.

Beispielsweise zu.

Also man möchte jetzt sowas machen wie Updates.

Und man hat jetzt nicht das Luxus-System einfach sagen kann, okay, ich reiße den jetzt ab und baue dann mit der neuesten Version neu auf, sondern man möchte vielleicht den updaten.

Und das Problem ist ja, wenn man irgendwie was, so ein Staging-System vielleicht daneben haben will, um zu gucken, ob das läuft beim Test fahren muss, wenn das eine kritische Infrastruktur ist, dann muss man vielleicht auf der alten Version aufbauen und dann updaten.

Weil sonst das nicht dasselbe ist wie das Produktionssystem, was man ja nur updaten muss.

Du meinst, du willst das Update-testen, sozusagen.

Genau.

Achso, mhm.

Ja, also da würde ich letztlich dann sagen, okay, ich habe dann mein Inventory und dann habe ich da definiert, welche Server da in der Staging-Umgebung sind.

Und dann lasse ich das Playbook da hinten.

Genau, aber du musst ja erst auf die historische Version laufen und dann das Update fahren.

Und dafür muss ich mir wahrscheinlich die letzte Version irgendwo merken oder sowas.

Ja, das ist natürlich auch nochmal so die Geschichte deklarativ.

Wenn ich jetzt sage, ganz einfach im Package Manager, Yam oder Apt, und da kann ich dann halt sagen, welchen State soll das Paket haben.

Nein, beispielsweise, ich habe eine Software, die ich deploy, die ich selber geschrieben habe, dann muss ich mir ja die Version zu mal merken, weil jetzt nicht über App kommt, sondern beispielsweise über einen GitHub-Brief oder ein GitHub Tag oder sowas.

Ja, da kann ich natürlich dann sagen, okay, welches Tag möchte ich denn überhaupt auschecken?

Ja.

Oder möchte ich einfach die Latest auschecken, dann habe ich halt immer die Latest, egal welche.

Genau, aber wenn ich jetzt genau dieses Update-File habe, dann muss ich ja mir merken, welche Version in Produktion läuft, beispielsweise.

Damit ich erstmal das auschecken kann, um dann das Update auf die Latest zu fahren, um dann sicherzustellen, dass ich das testen kann, um dann die Latest auf Produktion auszulälen.

Da muss ich mir wieder merken, was war denn jetzt Latest, was läuft denn jetzt da?

Und das muss ich irgendwo hinschreiben.

Und dafür brauche ich irgendwie so eine.

Also das klingt mir ehrlich gesagt so ein bisschen komplex.

Also ich weiß nicht, ob es das Problem löst, aber ich habe so, willst du wirklich deine Ensible-Geschichten testen?

Weil ich würde jetzt sagen, es geht nicht so gut.

Also man kann das natürlich machen, aber ich weiß nicht, ist das eine schlaue Idee?

Also wäre es nicht besser?

Also ich würde eher dazu tendieren, die ganzen Tests in die Applikation zu verlagern und zu sagen, wenn die Tests in meiner Applikation grün sind, dann gehe ich davon aus, dass die funktioniert.

Und ob das mit einer neuen Version funktioniert oder nicht, das kann ich auch lokal testen.

Dafür ist es ja.

Da wäre ja letztlich so die Frage, wie funktioniert mein Update-Mechanismus.

Ja.

Also warum willst du das auf Produktion testen und nicht lokal?

Ja, weil ich ja vielleicht die Infrastruktur kaputt geht beim Bauen oder sowas.

Wenn ich Änderung an der Infrastruktur habe, keine Ahnung, es kommt ein neues Netzwerk dazu oder so, dann hilft es mir jetzt nicht, wenn die Anwendung selber irgendwie grün ist und läuft und da irgendwie bei der Netzwerkkonfiguration irgendwas kaputt ist.

Integrationstest so ungefähr, ja.

Und das kann ja sein, dass halt beim Staging-System da, wenn ich das einfach vom Scratch baue, dann funktioniert diese Netzwerkkonfiguration, aber beim Update, weil da irgendwelche Versionen inkompatibel sind, muss ich irgendwie in einer Migrationsfahrt wählen, damit das funktioniert.

Ja, damit ich halt von der alten auf die neue Infrastruktur umwechseln kann.

Und deswegen muss ich ja irgendwie wissen, auf welcher alten Variante ich das bauen muss oder so.

Ja, gut, das wäre dann so das Thema, das hole ich mir dann aus den Facts.

Ja, aber diese Facts muss ich irgendwie dann zwischenspeichern, weil das ist ja ein alter Fact quasi gewinnen.

Das ist ja automatisch.

Genau, also bevor irgendwas gemacht wird, werden ja die Facts geholt.

Und anhand der Facts kann ich ja letztlich dann auch wieder entscheiden, was ich mache.

Okay, das heißt, du musst halt dann tatsächlich sehen, okay, dein Repo ist ausgecheckt auf Tag und dann nicht auf Main oder Master oder Trunk oder was oder auf Production, wie auch immer man den Branch jetzt nennen will, in der jeweiligen Version.

Genau.

Also ist vielleicht auch so eine andere Denkweise.

Also durch dieses Deklarative.

Also dass man halt nur sagen möchte, ich möchte immer die neueste Version haben oder ich möchte immer diese Version haben, dann wäre das letztlich schon im Play oder im Playbook definiert.

Und dann würde ich halt nicht mehr so gut.

Das ist genau diese Ensible State, genau, weil du das ist genau was, was wir am Anfang hatten.

Du sagst halt, okay, wenn ich jetzt Latest eingebe, dann ist Latest in zwei Monaten nicht mehr Latest, vielleicht.

Genau, also wenn ich dann über das Playbook halt nochmal laufen lasse, dann guckt ihr, ah, gibt es was Neues?

Okay, ich soll Latest nehmen, also update ich die Version.

Und ob dann was kaputt geht, ist dem Ensible erstmal egal.

Genau, und das ist das, was ich meine.

Das kann man halt so nicht.

Dafür müsste man dich diese Effects, was war denn jetzt Latest, irgendwie rausschreiben, also diesen State.

Muss man sich irgendwie merken, um den reproduzierbar zu haben.

Also nach dem Motto, ähm, bau mir jetzt das Latest von vor zwei Monaten und dann check, ob das Update funktioniert, was ich mir überlegt habe.

Ja, aber das klingt mir doch sehr stark.

Also ich meine, ich verstehe, ich verstehe, was das, äh, wofür du das machen willst und dass man das, aber ich, also ich habe auch schon gehört, dass Leute eben, wenn man, es ist ja alles irgendwie auch so in Infrastructure as a Code Infrastructure as Code Geschichte, dass man halt auch diese komplette Infrastruktur irgendwie testbar machen können will.

Und das, aber ich weiß nicht, will man das wirklich?

Also man.

Ja, am Ende ist es halt auch so, dann müsste ich halt immer meine Version pinnen.

Vielleicht ist das auch eine gute Idee zu sagen, ich pinne sowieso immer und nehme Latest nicht.

Dann würde ich halt dann mein Ansible-Skript oder mein Ansible Playbook bearbeiten.

Dann wüsste ich das und dann würde ich halt neu, ähm, wahrscheinlich ist ja im Git eingecheckt und dann sagen, okay, ein neuer Commit und dann das testen.

Aber also so wie ich dich verstanden habe, ist es so, du möchtest im Grunde sagen können, also auf meinem Produktionssystem ist jetzt gerade, keine Ahnung, Version so und so viel von meinem Projekt installiert.

Und ich möchte jetzt auf meinem Staging-System testen können, oder das muss ja gar nicht das Staging-System sein, ja.

Sondern ich ziehe automatisch mit Terraform irgendwie mehr Infrastruktur hoch und zwar in Versionen, so wie ich sie auf dem Produktionssystem habe.

Und dann will ich testen, dass wenn ich das jetzt update, dass dann alles noch funktioniert.

Das ist aber im Grunde ist das ja ein Test deines Systems.

Genau, das würde man ja dann einfach machen und gucken, ob es geht.

Das Problem ist halt, wenn du das Update halt auf dem Produktionssystem, fährst, und es funktioniert nicht, ist halt blöd.

Genau, deswegen Staging.

Ja, oder.

Und die muss halt dann so gerade, also.

Aber du musst halt das Update reproduzieren.

Du kannst halt nicht einfach dann vom Sketch eine neue Version bauen, weil sonst wirst du das Produktionssystem abreißen und neu bauen.

Aber also da würde ich sagen, will man wirklich in eine Situation kommen, in der man sowas machen muss.

Ich glaube, ich weiß nicht, ob es anders geht.

Ich würde versuchen, das zu vermeiden.

Aber wie vermeidest du das?

Nämlich die Tests halt in der Applikation laufen lassen.

Ja gut, aber dann weißt du, ob deine Applikation funktioniert und nicht, ob dein Serverinfrastruktur funktioniert.

Ja, wenn meine Serverinfrastruktur kaputt geht, dann weiß ich, habe ich einen neuen Test für meine Applikation.

Der Sinn der Staging-Umgebung, um dann einmal das zu machen und zu.

Aber die ist ja in einem anderen Zustand.

Genau, das ist, was ich meine.

Also der andere, die Frage ist halt, was, du musst halt diese Staging-Umgebung diesen zwei Ebenen bauen, damit du quasi dieses Update simulieren kannst.

Weil wenn du dir nur die neue Version baust im Staging System, kann es sein, dass das aus irgendwelchen Gründen funktioniert, aber das Update halt nicht.

Also, ja, also wie gesagt, was ich gehört habe, ist dann, dass Leute halt auch Tests eben gegen so, sie ziehen dann sogar temporärinfrastruktur hoch, ein System und machen dann ihre Tests dagegen.

Das hört sich für mich ganz schrecklich an, weil das Problem ist, das macht ja dann auch dann eine Entwicklung total langsam, weil allein das Hochziehen von dem Kram und auch ehrlich gesagt, ich finde Ensible ist halt schon, also bei mir, ich mache irgendwas ganz falsch, langsam.

Also das dauert man.

Die ICD macht es langsamer, also es dauert eher länger als eher Stunden.

Das ist ja schrecklich.

Also wenn du halt sozusagen so ein Feedback-Loop haben willst, irgendwie du änderst was, guckst, ob es funktioniert.

Wenn es nicht funktioniert, wieder was ändern.

Also für mich ist das schon, wenn da Minuten dazwischen liegen, ist das halt so, dass es halt deutlich langsamer macht.

Und wenn da Stunden zwischenliegen, dann.

Aber genau, also so ein Deployment auf Asia dauert, also ich weiß nicht, da kommen irgendwelche Ameisen und hängen Redis irgendwie allein selbstständig manuell ans Rack und mussten 20 Minuten warten, bis das irgendwie angeschlossen ist.

Solche Sachen, das ist halt ewig.

Das dauert halt einfach lange.

Und wenn man das halt dann in mehreren Stufen machen muss, dann schenkst du halt stundenlang da.

Ja, klingt für mich nach keinem sehr angenehmen Workflow.

Stimmt, das macht's nervig.

Also das ist auch eine Sache, warum ATO nervig ist.

Ja, überhaupt nicht.

Aber die Frage ist, was würdest du denn sagen, was wäre denn die Lösung von diesem Problem?

Also für mich, ich weiß natürlich nicht, ob das immer geht, aber ich würde sagen, man schiebt die Tests in die Applikation zum Beispiel, also ein Beispiel jetzt, wo ich das auch gehört habe, wo Leute sowas testen, wo die sagen, ja, also wenn ich jetzt zum Beispiel irgendwie nach AWS deploye und dann weiß ich zum Beispiel, die haben genau dieses Ding, wo ich auch denke, so, oh mein Gott, das ist einer der Gründe, warum ich ganz viel zu diesem File-Serving auch gemacht habe.

Also, das auch bei dem jetzigen Python-Podcast ist es so, die Files kommen von S3.

Aber das Problem ist jetzt natürlich, wenn ich jetzt Files gerne hätte, wo Leute sich authentifizieren müssen, um die sehen zu können, dann muss ich ja dann S3 darum kümmern, dass das so ist.

Ja, das Problem, Django kann sich ja nicht drum kümmern, so in gewisser Weise, weil da ist ja sozusagen dann nur, also auf der Webseite ist ja nur ein Link auf S3.

Ja.

Das heißt, man kann natürlich dafür sorgen, dass der Link nicht sichtbar ist, wenn es nicht authentifiziert ist.

Also verschiedene Möglichkeiten, dass man dem quasi dem Nginx zum Beispiel da mitgibt.

Ja, wenn es über S3 geht, da ist ja kein NG, oder sagen wir so, das ist sogar so, ist es S3, aber das S3 ist sozusagen nur das Backend für Cloudfront, für so ein CDN.

Und ja, jetzt ist halt die Frage, okay, wenn das über ein CDN geht, dann kannst du, das geht ja nicht über deinen Nginx, sondern das geht ja außenrum.

So, jetzt kannst du, gibt es ja natürlich schon gewisse, du kannst die Urholze so generieren, dass die halt signiert sind zum Beispiel.

Und dann kannst du dem S3 bzw.

dem Cloudfront oder wie auch immer sagen, ah, die URL muss aber signiert sein.

Und die Signaturen sind nur für so und so lange gültig.

Oder du musst halt irgendwie Cookies setzen.

Aber es gibt ja diverse Möglichkeiten, wie man sich authentifizieren kann.

Aber das Problem ist jetzt natürlich, wenn du darauf angewiesen bist, dass das wirklich funktioniert, musst du das ja eigentlich testen.

Du musst du ja sagen, okay, wenn jetzt jemand hier im Django Admin gesagt hat, da darf keiner, da dürfen Authentifizierte drauf zugreifen, dann muss man ja diese Logik irgendwie testen können.

Aber wenn deine, wenn die tatsächliche Überprüfung irgendwie in Cloudfront stattfindet, dann kannst du das nicht mehr gut testen, ohne dass du das, dass du tatsächlich irgendwie das nach Cloudfront hochschiebst, irgendwie dann in den Einstellungen machst und dann.

Du musst das natürlich dann einen Mock dafür machen.

Ja, aber das kannst du.

Aber da geht das.

Genau, jetzt hast du die Fehlerjahme mit.

Jetzt kommt der Punkt, warum dann Leute dieses genau das gleiche Szenario quasi, wenn dann Leute sagten, so, ja, und wir ziehen unsere Infrastruktur ja per Terraform hoch und das ist ja dann der Vorteil, dass wir das auf unterschiedliche Cloud-Anbieter hochschieben können.

Und jetzt haben wir zum Beispiel eben genau dieses Problem.

Wir haben zum Beispiel da irgendwie Byterange-Requests irgendwie erlaubt.

Das muss man irgendwie bei AWS muss man das irgendwie so und so konfigurieren, dass das geht oder eben Authentifizierung.

Und jetzt schieben wir das Ganze nach Azure.

Und jetzt hat irgendjemand in der Terraform-Config irgendwie diese komische Konfiguration für AWS oder so gesehen, wie man das macht.

Hat sich gedacht, was ist das denn?

Das habe ich ja noch nie gehört.

Was sind denn Byterange-Requests?

Ach, das ist bestimmt ein Artefakt von irgendeiner uralten Geschichte.

Ich nehme das mal raus und gucke, ob es geht.

Man nimmt das raus, guckt, ob es geht.

Und dann geht es auch.

Aber man hat damit halt einen ganz wichtigen Teil der Funktionalität kaputt gemacht.

Ja, und jetzt müssen alle Clients plötzlich irgendwie alle Files immer komplett holen, weil Byterange-Requests nicht mehr gehen.

Und ja, also wie zum Beispiel bei Podcasts oder Podcast-Player holen sich immer nur Teile der, wenn, wenn das Teil-Teilformat das unterstützt.

Und ja, das ist halt in der Produktion dann unterbestimmt eine Riesenkatastrophe, wenn das halt abgeschaltet ist und nicht mehr geht.

Das heißt eigentlich, wenn du solche Sachen da drin hast, dass halt Teile der Features deiner Applikation sozusagen darin bestehen, dass du deinen Object Store oder CDN richtig konfigurierst, dann musst du das eigentlich testen.

Dann musst du das auf einer Test irgendwie testmäßig hochziehen, dann deine Features, die halt in der CDN liegen, halt testen.

Und dann kannst du erst sagen, wenn das alles funktioniert, okay, das funktioniert.

Das war gerade ein Plädoyer für das, was ich gerade eben gesagt habe, weil.

Also für mich hört sich das an, oh mein Gott, das würde man auf gar keinen Fall machen.

Für mich klingt das nach einem Plädoyer, ich surf meine File selber.

Ich mach das nicht, weil es nicht macht.

Okay, gut, das ist dann.

Aber jetzt als Beispiel.

Dann kann ich es deine Applikation testen.

Aber du müsstest deine Byte-Requests jetzt tatsächlich testen mit AWS.

Nee, nicht, nee, muss ich nicht.

Du hast jetzt bei AWS.

Okay.

Aber dann wäre der Test, wenn du den hättest, würdest du halt merken, wenn jemand ein Update fährt und das geht dann nicht mehr.

Aber das würdest du nur mehr mit meinem Update vielleicht.

Nee, du musst dann halt dann.

Es ist halt furchtbar.

Okay, wie würdest du es denn machen?

Also ich würde, ich würde sagen, also es geht wahrscheinlich nicht immer.

Also manchmal muss man dann vielleicht sowas Furchtbares tun, wie irgendwie dann solche Tests gegen eine Testinstallation fahren.

Ich würde es so machen, ich würde sagen, ich survefe die Requests halt selber und teste das halt auch, dass die Byte-Range-Requests halt gehen und dass Authentifizierung geht, lokal, ohne irgendein CDN.

Und ich benutze dann halt eben kein CDN.

Für diese Art von, also vielleicht benutze ich ein CDN für Sachen, wo es egal ist, wo ich keine Konfiguration brauche, aber für die Sachen, wo ich halt irgendwie Spezialkonfigurationen brauche, nehme ich halt kein CDN, sondern Serve es halt direkt.

Okay, aber das ist dann entscheidend, hier an deiner Stelle kommen muss.

Macht dich an mehreren Stellen vielleicht unbeweglich.

Ja, also solange das funktioniert, bin ich damit deutlich flexibel.

Also solange du den Hut auf hast, schon.

Ja, also ja gut, also ist halt die Frage, ich weiß nicht, ob es auch da eine.

Aber diese Geschichte, ich ziehe mir eine Testinfrastruktur hoch und mache dann Test dagegen und das dauert alles irgendwie 30 Minuten, das klingt ziemlich schrecklich, ehrlich gesagt.

Dreieinhalb Stunden.

Aber letztlich muss man dann auch überlegen, okay, also sind diese Dateien so wichtig, dass ich mir dreieinhalb Stunden Zeit nehme, damit ich halt absolut sicher bin.

Ja.

Also ich sag mal, bei Kundendaten, die du nicht einfach mal so neu reinbahnen kannst, dann sollte man das vielleicht in Erwägung ziehen.

Ja, natürlich.

Und vielleicht kann man dann auch überlegen, okay, ich habe jetzt in dem Bereich nichts gemacht, da reicht so die normalen Tests.

Ja.

Ja, ja.

Also, okay, das kann man probieren.

Testing haben wir, also okay, aber jetzt vielleicht nochmal Ensible.

Molecule gibt es bei Ensible, ne?

Oder Assertions.

Du wolltest noch.

Achso, nee, ich meinte nur, also ich schreibe keine Tests für die Ensible-Geschichten, sondern ich probiere es halt aus und wenn es geht, dann sage ich mir, okay, das ist gut genug.

Alles, was ich wirklich testen möchte, teste ich in der Applikation.

Also was ich mache, also bei Ensible Sachen ist, ich mache Assertions am Anfang.

So ein paar.

Einfach, die dann halt mir um die Unfliegen, da weiß ich relativ schnell, funktioniert das ja nicht und warte halt nicht, dass das ganze Playbook da läuft, sondern einfach direkt, okay, irgendwas geht hier nicht, danke, mach nochmal.

Aber das sind so einfache Sachen eigentlich nur.

Ja, ne, also geht ja ganz am Anfang los mit einer Debug-Flag, ne?

Und sich dann einfach einmal alles so anzeigen zu lassen und zu sehen, okay, passieren auch die Dinge, wo ich vermute, die passieren.

Tatsächlich teste ich die letztlich auch gegen Vagrant und gucke dann, ob der VM am Ende die Konfiguration hat, die ich haben möchte.

Okay, interessant.

Okay, mit Vagant testen.

Okay.

Was ist mit Molecule?

Kennt ihr das?

Ist auch so Ensible Molecule Testing.

Da kann man sowieso Testmodule schreiben, die man dann irgendwie reinsetzt in seinen Ja, wenn man das so selber Ensible Module schreibt, dann kann man das irgendwie machen.

Müssen wir vielleicht nochmal nachgucken.

Genau, also in die Verlegenheit bin ich bisher noch nicht gekommen, weil es gibt echt viel, was man letztlich, was es schon gibt.

Und wenn es das nicht gibt, am Ende setze ich dann einfach ein Command ab.

Ja, okay, das ist halt tatsächlich die Frage, weil es gibt halt viele, viele Build-Ins von Ensible.

Also Ensible-Bildern irgendwas ermöglicht einem relativ viel.

Kommandos auch dann.

Es gibt auch

Community, ist meistens schon vorinstalliert mit, wenn man das, die meisten Community-Sachen sind mit drin.

Für schöne Sachen.

Die Frage ist, gibt es so Dinge, die man dann selber bauen will?

Beispielsweise, man hat irgendein Command-Line-Interface, das man ständig benutzt, was dann immer sehr hässliche, ellenlange Befehlzeilen ausgibt.

Da könnte man ja selber sich ein Ensible-Modul für schreiben in Python, was dann quasi ein Abstraktionslayer drüber schreibt, wo man dann ein quasi ein eigenes Ensible-Modul, ob man das in Galaxy hochlegt, wo auch immer, benutzt, um dann zu sagen, hey, hat ein einfacheres, schöneres Interface, um so Befehle zu bieten.

Ja, also tatsächlich so, bisher habe ich noch alles gefunden in Ansible, was man so braucht.

Ja, oder man halt tatsächlich dann direkt Shellkommando, das Thema halt ausführen kann, ne?

Genau.

Und ja, wenn man sich überlegt, okay, am Ende wird eine SSH-Verbindung aufgemacht und ein Shell-Kommando abgesetzt.

Ja, und dann kann man natürlich gucken, okay, wenn ich ein Modul entwickle, dann gucke ich, dass halt das Richtige am Ende rauskommt.

Ja, ich würde auch sagen, das ist ein bisschen das Astrationsniveau, kann man halt manchmal, wenn wirklich mal komplexe Sachen macht, kann man es so ein bisschen vereinfachen, vielleicht für Leute, mit denen man arbeitet oder die es benutzen, indem man das so ein bisschen wegaufsicht, vielleicht dann.

Aber beim Thema Modul schreiben sind wir wieder so, dann schreibe ich natürlich auch wieder ganz viele Sachen für ganz viele Betriebssysteme, die ich vielleicht dann doch nicht brauche.

Ja, das ist halt immer so die Abwägung, wann macht es Sinn, in die höhere Abstraktion zu gehen, um einfach zu sagen, okay, das bringt mir jetzt so viel, dass du.

Vielleicht hätten das mir jetzt mit der Teamgröße tun.

Also wie viele Anwender von deinem Ende-Modul gibt es zum Beispiel intern, in dem du was du machen willst.

Und wie viele Leuten kannst du da Arbeit erleichtern oder sowas, ja?

Ja, dann.

Ich glaube, was noch fehlt, jetzt nur noch nach meiner Liste, sind die Secrets und wie man mit Secrets umgeht und wo man herbekommt.

Gibt es irgendwelche Vaults, aus denen man jetzt authentifiziert?

Wie macht man das?

Schreibt man Secrets mit in irgendwelche Repos rein, in Source Control.

Ist das eine schlechte Idee?

Also man kann die jetzt zum Beispiel verschlüsselt reinschreiben und dann irgendwie aufschlüsseln und dann einen Schlüssel nur mitgeben oder so.

Und was würdet ihr sagen?

Genau, also es gibt Ansible Vault.

Und da kann ich dann letztlich einen beliebigen String verschlüsseln gegen ein Passwort und bekomme dann halt das Secret rausgeworfen.

Das kann ich dann in meinen Playbook reinpacken.

Da kann ich halt letztlich auch einchecken, weil es verschlüsselt ist.

Und muss dann beim Ausführen des Playbooks einfach sagen, okay, frag mich nach dem Geheimnis oder nach dem Schlüssel für das Geheimnis und dann entschlüssel er das Ganze.

Ich kann es natürlich letztlich dann auch wieder ins Inventory schreiben zum Entschlüsseln, aber dann bin ich wieder bei dieser Debatte, sollte ich, unter welchen Umständen sollte ich Geheimnisse in meine Repos einchecken?

Genau, ja, das ist ja spannend.

Also weil beispielsweise, wenn das gerade bei dem ganzen Infrastrukturprozess, muss das ja irgendwo rein und irgendwo entschlüsselt sein.

Also irgendeine Maschine kennt dann das Secret, entweder als lokale Dot-End oder was auch immer.

Und da muss man halt wenigstens hingehen und das für den Zeitraum, wo man die Befehle ausführt, dann entschlüsseln, aufmachen und dann da reinschieben.

Dann muss man halt aufpassen, dass es irgendwo nicht in irgendwelchen Loks oder irgendwo im Speicher zwischendurch weggeschrieben wird.

Genau, also letztlich die Maschine, die es ausführt, die weiß es.

Ja.

Ja, ja, also da gibt es.

Also jede

Maschine, die es ausführt, weiß es.

Und genau, die Verbindung zwischendrin muss halt auch stabil sein und so.

Ja gut, sind ja da SSA relativ abgehangen.

Das ist wahrscheinlich nicht das Problem, aber ja, also ich meine, die Secrets sind halt auf der Maschine unter.

Ich meine, das Schlimmste, also es gibt ja diese Twill-Factor-Up-App-Geschichte, wie man halt, also das ist halt eigentlich die Art, wie Roku irgendwie Dinge deployed hat, irgendwie mal, und die haben das halt so aufgeschrieben, das haben sie genannt.

Und da ist ja eine der Geschichten, so für Secrets oder so Umgebungsvariablen zu verwenden.

Es ist halt auch so eine.

Also ich mach's häufig auch so, aber auf der anderen Seite so ein simpler Einwand dagegen ist halt, dass Leute sagen, ja, du machst es damit angreifern, aber auch extrem einfach.

Weil du eigentlich musst ein Angreifer, wenn er weiß, dass du das so machst, oder ich meine, eigentlich, das ist halt das Erste, was man dann tut als Eingreifer, einfach mal das Environment nehmen, weil das ist ja super einfach zu lesen, wenn du halt es geschafft hast, irgendwie Code im Kontext von irgendeinem Prozess auszuführen, nimmst du das Environment und schickst es irgendwo hin.

Und dann hast du halt schon viele Secrets, möglicherweise alle möglichen ABS-Keys und so, irgendwo hingeschickt und das ist halt schon das ist halt das Erste, was ein Angreifer macht.

Ja, wenn man bei GitHub danach sucht, da gibt es dann einige die gesquattete Repos, die genau das machen, also die quasi den Quercode nehmen und halt, wenn man sich vertippt hat, einfach mal die Environment woanders hinschicken.

Genau, und das ist natürlich so ein bisschen, und wenn man das irgendwie anders machen würde, also zum Beispiel über, also was ich auch gern mache, jetzt nicht bei Django mache ich es tatsächlich meistens über Environment, weil es halt irgendwie so praktisch ist.

Aber in Projekten, wo ich Pidentec habe, mache ich das meistens mit Base-Settings oder so, wo es dann halt aus einem Pfeil gelesen wird und man das halt wissen muss und importieren muss und das ist halt schon mal so ein automatisierter Angriff funktioniert da schon.

Und dann diese Base-Settings werden dann in Environment-Variablen geschrieben, nein, nein.

Nee, eben, genau.

Es ist bei der IT-Security immer das Thema, was ist denn mein Angriffsszenario?

Ja.

Wenn ich jetzt sage, okay, ich bin eh in einem privaten Repo und wenn jemand dann Zugriff auf mein privates Report hat, was auf mein CI läuft und alles, ne, also sagen wir, ich habe ein privates GitLab und da ist jemand drin, ja, dann ist halt egal.

Oder wenn ich sage, okay, aber es ist ja dann im RAM, ne?

Wenn jemand jetzt meine Umgebungsvariable auslesen kann, dann auch schon wieder Probleme.

Das heißt,

wenn ich meinem Provider oder meinem Hoster nicht traue, dann habe ich auch ein Problem.

Irgendwo muss man dann sagen, okay, diese Risiken gehe ich ein.

Oder das sind die Maßnahmen, die ich habe.

Ja, ich musste, ich wurde gezwungen von der Konzern-Security, für den Konzern, wenn ich was gemacht habe, eben nicht direkt Environment-Variablen zu setzen, was ich gewollt hätte.

Also aus in so eine über Terraform irgendwie rein, da kommt das halt aus Secrets und das ist halt irgendwie gekapselt, sondern ich musste es nochmal über einen Umweg in ein extra Vault reinschreiben, der dann irgendwie extra verschlüsselt wird, wo dann keiner mehr dran Zugriff drauf haben sollte, angeblich.

Ende vom Lied war aber, es wurde dann doch wieder da als Environment-Variable in diese Container reingeschrieben.

Das heißt, das Ergebnis war dasselbe, nur dass ich zwischendurch noch ein paar extra Schritte gehen musste, wo halt ein Risiko eigentlich dann halt ist für Exposure.

Es ist natürlich dann die Frage, was hat man damit gewonnen?

Wenn man sagt, okay, vielleicht kann ich noch in der Vault dann steuern, wer Zugriff drauf hat, weil das dann alles sagen, okay, jetzt hat niemand mehr Zugriff drauf.

Ja, das war der Plan, aber das Problem ist halt, wenn die Sachen sowieso wieder auf dieser Web-App landen, dann ist halt Frage der Status drauf.

Dann hat das so wenig Sinn gemacht, weil dann quasi noch mehr so mehr Angriffsszenario dann irgendwo dazwischen liegen konnten.

Genau, also man muss halt vorher überlegen, wogegen möchte ich mich denn wappnen.

Oder vielleicht verstanden haben, was man da überhaupt tut, bevor man irgendwie Regeln enforce, die

statisch irgendwie nachbringt.

Ja, aber das steht so in der Policy, das machen wir so.

Ja, genau, das ist E-TIP.

Irgendwie hat einen ET-Prozess definiert, wo das drin steht, wie man das macht.

Ja, also ich kann ja mal einfach sagen, wie ich das, also ich check den, ich check tatsächlich die Secrets irgendwie mit ein, auch in öffentlichen Repos.

Und da braucht man halt dann eben eine entsprechende Passphrase.

Also was ich mir vorstelle, was man noch da verbessern könnte, weil momentan ist halt das Problem, okay, wie verhält man denn das

Passwort oder das

Volt-Passwort, das man dafür braucht halt.

Und ja gut, ja, man braucht halt irgendeinen vertrauenswürdigen Kanal, über das man das übermitteln kann.

Ich glaube, man kann auch irgendwie Dinge mit GPG machen.

Also ich

würde sowas versuchen, wie Yubi-Keys zu verschicken.

Ja, ja.

Also, wo dann halt die Keys drauf sind, die funktionieren und dann vielleicht geht das.

Also die sind halt auch nicht kopiersicher oder sowas, ja?

Ja, die Yubi-Keys, ja genau, die könnte man natürlich dann über den SSH-Agent dann und dann könnte man GPG machen und dann könnte man das wieder entschlüsseln.

Aber mein idealer Workflow, sozusagen, ich kann es momentan nur so beschreiben, wie ich es gerne hätte, aber ich weiß noch nicht genau, wie es man, wie man es implementiert, ist halt sozusagen, dass ich sage, wenn ich jetzt halt irgendwas deployen will oder möchte dann die Secrets, dass mich das Ensible halt dann, dass ich mich irgendwie bei Ensible einhake oder so und dann, dass dann, keine Ahnung, auf meinem Telefon halt dann irgendwie Two-Factor-mäßig irgendwas aufgeht und sagt halt, hier bestätige mal, dass ich irgendwie, dass du dir das angucken kannst und dann geht es halt auf so zum Beispiel.

Oder YubiKey oder so.

Ja, also ich finde die kommt mir jetzt uncool für.

Auf dem Telefon geht auch halt mal bitte an das Telefon in Yubi-Key.

Ja, irgendwie sowas.

Irgendwie so, ne?

Weil der hat ja dann irgendwie NFT oder Buntu und irgendwas.

Ja, ne, da könnte man dann auch gleich überlegen, ja, mache ich das vielleicht auf der Ebene von SSH, dass ich den Zwei-Faktor SSH mache, gibt es auch eine Lösung?

Da geht es auch mit YubiKey übrigens, habe ich letztens irgendwie, der Johannes hat das irgendwie gelinkt, so einen Artikel in seinen Week News.

Ja, ja.

Ja, aber genau, aber das ist also die Frage, wem musst du vertrauen?

Dann deinen Mitarbeitern vertrauen.

Ist auch vielleicht nicht immer so einfach für was und so, aber klar, also wenn du jetzt irgendwie einen Admin hast, der Sachen entwickeln soll, der muss natürlich schon Zugriff haben.

Das macht halt sonst keinen Sinn, wenn jedes Mal irgendwie einen Antrag stellen musst und in drei Tage warten musst.

Degen nämlich wird das natürlich totaler Quatsch.

Ja, oder?

Ja, ja, an irgendeiner Stelle muss ich halt Leuten vertrauen und ich muss halt dann die Abwägung treffen.

Also ich finde das mit.

Wem möchte ich denn vertrauen?

Ich finde das mit physisch, glaube ich, ganz gut.

Also wenn man den Leuten einen physischen Schlüssel in die Hand geben kann, den die vielleicht sogar kopiergeschützt.

Ich weiß nicht, ob es sowas gibt.

Ja, also die Yubi-Keys, die soll also an sich, diese ganzen Hardware-Schlüssel sind kopiergeschützt.

Ja, also, dann könnte man den.

Ja, ja.

Aber wenn ich halt jemanden dann sage, okay, wir treffen uns oder ich schicke ihn per Porsche, gut, können auch kompromittiert sein, aber man gibt den.

Der fängt schon an, ne?

Wer hat halt einen Zugriff auf diese ganzen Sachen.

Aber dann, wenn man den halt dann abgeben kann, dann ist er schon relativ sicher, okay, dass sich jetzt in meiner Chain dann nur die Leute identifizieren können, die diesen Schlüssel auch von mir bekommen haben.

Das ist ja schon mal ein Vorteil.

Ja, oder Zertifikate, auch schön.

Die kann man ja auch sagen, die laufen ab, relativ schnell.

Und dann ist die Route Authority, die ist dann hört einem dann oder so.

Ja, genau, also geht ja auch relativ fix, so eine CA aufzustellen.

Die sicher zu halten, ist wieder schwierig.

Ja, das ist absolut super.

Also wir haben auch so eine Route CA, die sich selbst definiert hat und die dann die ganzen Zertifikate mit raus hat.

Ich habe gesagt, warum macht der denn den Scheißhau?

Ja.

Ja, ja, es ist Security auch sehr, sehr schwieriges Thema.

Man kriegt es nicht absolut sicher hin.

Man muss sich die Risiken vor Augen führen und sagen, dieses Risiko gehe ich jetzt an.

Man braucht halt irgendwie den ankommen Autorität, den man vertrauen kann.

TÜV geprüft, ne?

Ja, man

müsste irgendwo

so einmal machen.

Da steht dieser ursprüngliche Schlüssel drin und der ist dann noch, ne?

Ja, ja, ja.

Es ist schwierig.

Ja, das ist ein bisschen.

Ein spannender Aspekt, den wir noch nicht so beleuchtet haben, also wir haben ja auch viel über Docker gesprochen.

Und das ist so, ja, vielleicht auch Ansible verdrängt.

Aber was Ansible jetzt viel macht, ist in die Network Automation reinzugehen.

Das heißt, ja, alle großen Anbieter, die bieten jetzt auch Ansible-Module an.

Das heißt, ich kann letztlich einen Cisco-Switch mit Ansible konfigurieren.

Das sind interessante Sachen.

Alles, was relativ groß ist, Palo Alto, Unipy, Nokia, die lassen sich jetzt über Ansible ansprechen.

Und ja, wer schon mal so eine Cisco-Konsole bedient hat.

Ja.

Ja, das will man nicht.

Das will man automatisiert wegschieben über seine eigene Shell, wo man sagt, ich habe hier ein Skript für Rennen mal.

Genau, ne?

Also Ansible definiert mir hier jetzt mal, welche IP-Adressen wohin und welche Foulern es gibt.

Und schöner, als das alles per Hand einmal einzupippen.

Auch das kann man dann auch wieder schön testen eigentlich, ne?

Ja.

Und weiß man halt, okay, stabil.

Dann kann man auf jeden Fall Use Case finden, wenn es nicht stabil ist, okay, dann mach's mal anders.

Also dieses Ganze, ich muss jetzt immer manuell dran rumfummeln, bis es irgendwie im letzten Mal gibt.

Das sollte man nicht machen, ja.

Also klar, das ist natürlich, davon muss man irgendwie weg.

Also ich finde, also prinzipiell, dass das halt alles in Repository drin ist und die Änderungen getrackt werden und man auch den Stand wieder reproduzieren kann.

Also das sind alles super Sachen.

Also das ist,

das will man eigentlich schon haben.

Ja, aber gut, bei Testen wäre ich mir jetzt, also ich meine, ich kann mir auch vorstellen, dass es Situationen gibt, wo man das dann halt auch dann testen können will.

Ich wäre mir jetzt nur nicht so sicher, ob der Aufwand sich immer lohnt oder ob es nicht andere Wege gibt, das zu gleiche Ziel zu erreichen.

Da muss man wie bei Ronny machen, sobald die Coverage bei deinem Commit runtergeht oder beim Pull-Request, wird er direkt mal denied.

Ja, genau.

Ja, ja.

Ich weiß nicht, achso, genau.

Ich wollte irgendwas sagen.

Ja, genau.

Dinge, die mir noch so, die ich noch gerne loswerden würde, ist, man kann auch noch so Dinge tun wie, wenn Sachen lange laufen, kann man irgendwie Async mitgeben und dann wird halt immer nur ab und zu mal geguckt und andere Sachen können halt parallel weiterlaufen.

Das ist, finde ich, manchmal ganz praktisch.

Also auf einer Maschine oder auf anderen Taskskurs?

Aber die Tasks laufen auf einer Maschine parallel in verschiedenen Prozessen?

Nein, du kannst ja oder über.

Nein, nein, auf einer Kinder.

Die müssen ja voneinander abhängig sein.

Ja, genau, das wollte ich gerade frühen.

Ja, ja, klar.

Also du hast eine Parallelität über unterschiedliche Maschinen, nicht über einer.

Und du kannst natürlich auch angeben, wie viele Prozesse das sein sollen.

Wenn du viele Maschinen hast und viele Prozesse, dann wird es natürlich irgendwann doof auf dem Host, auf dem du das ausführst.

Kann man auch so Weightpoints machen?

Keine Ahnung, du musst jetzt aber warten, bis das und das und das fertig ist.

Geht bestimmt irgendwie, keine Ahnung.

Den Use Case hatte ich noch nicht, aber weiß ich nicht.

Ja.

Also Infrastruktur hat ja so hässliche sequentielle Probleme, wo manche Sachen vorher fertig sein müssen, dann die und die nur.

Ja, aber das geht alles.

Also du kannst ja auch so Rolling-Updates machen, wo du Sachen aus dem Load Balance rausnimmst und dann irgendwie reinnimmst oder ganz aufhörst, wenn mehr als 10% deiner Geschichten nicht funktioniert haben.

Das geht ja alles.

Also das kannst du halt.

Da sind Sachen, die sind so nervig, manchmal gerade Infrastruktur erst a Service aufbauen und dann zwischendurch hast du so Fehler, die unvorherbesehbar sind, weil irgendwelche Netzwerkprobleme sind oder irgendein Name-Server gerade nicht reagiert hat oder sowas und die irgendeine IP noch nicht kennt oder so.

Und dann macht es Bumm und du fragst dich, warum und dann lässt es nochmal laufen und es funktioniert wieder.

Das ist eine

furchtbare Hölle.

Genau, du kannst auch so einen Retrice mitgeben.

Ja.

Aber ja, man läuft halt dann halt wirklich in diese unschönen Probleme rein.

Und es wird auch nicht schöner.

Achso, jetzt richtig, jetzt weiß ich wieder, was ich sagen wollte.

Genau.

Also einer der Gründe, warum ich manche meine ganzen Ensible-Geschichten, die die meisten davon nicht eingecheckt habe, also manche davon schon, aber die meisten nicht, ist halt, dass ich, also man kann bei Ensible auch sagen, das habe ich halt noch nicht gemacht, aber sollte vielleicht, die Inventaries kann man halt auch auf Server legen oder so, dass es halt nicht aus dem Textfile kommt, sondern irgendwo, und momentan kommt bei mir kommen sie meistens aus dem Textfile und das heißt, wenn ich meine Inventory mit einchecke, dann checke ich meine gesamte Infrastruktur mit ein und das will ich jetzt nicht.

Das Inventory kann halt auch ein Skript sein, das kann ein Ordner sein, das kann wieder ein Ansible-Modul sein, wo sich das halt dann die Punkte wieder herholt.

Dynamisch zusammenbauen, ne?

Ja, du musst halt dazwischen wieder Jump-Hosts bauen, die dann irgendwie bestimmte Sachen vorbereiten und ausführen und dann da so eine Art Staged haben.

Ich kann einfach gegen den Hetzer DNS zum Beispiel fragen, so wie sieht es hier aus?

Und dann gibt er mir das als Inventory.

Okay.

Also da gibt es verschiedene Plugins, AWS, Docker, Kubernetes, Proxmox und noch viele mehr.

Nochmal ganz kurz, was ist Proxmox?

Das ist auch eine Virtualisierungsumgebung, also eher wie ein Hardware-Host, der einem halt dann verschiedene, also ja wie früher VM-Ware.

Nur halt so ein bisschen als Community-Projekt.

Okay, vielleicht gucken wir auch mal rein an.

Habt ihr noch Punkte auf eurer Liste?

Ja, genau.

Einen Punkt habe ich noch, was man auch machen kann.

Man kriegt ja Textausgabe, wenn man einfach Ensible so auf der Kommandozeile ausführt.

Aber man kann halt Ensible auch sagen, hier ist dein Callback-Command irgendwie.

Und dann kann man selber zum Beispiel eine Funktion schreiben, in die die Ausgaben von Ensible reingehen, beziehungsweise nicht nur die Ausgaben, sondern man kriegt halt wirklich.

Man kann das loggen, wenn man will.

Man könnte es loggen, also

wozu ich das benutze, ist, ich gebe halt JSON aus.

Also ich passe das dann halt auf und dann packe ich das in mein eigenes JSON-Format und gebe dann halt JSON aus.

Weil dann kann ich das halt, während das läuft, irgendwie direkt auf einer Webseite anzeigen.

Okay, dann weißt du halt, wer das State gerade ist und wo ist denn das gerade und wie weit ist denn das und ja, okay.

Und vor allen Dingen habe ich an der Stelle auch eine sehr schöne Abstraktion, wo ich das ja auftrennen kann, weil irgendwie ich verwende jetzt meistens zwar Ensible, aber es könnte auch Situationen geben, wo ich nicht Ensible verwenden will, sondern wo ich direkt SSH verwenden will oder ein Skript, einfach nur ein, oder ein Python-Skript oder was ganz anderes.

Ich will Ensible durch was anderes ersetzen.

Es gibt ja ja auch so, ich finde, wie bei den Boxinen, die verwenden ja, die hatten Ensible lange Zeit verwendet, sind dann auf was anderes umgestiegen.

Weißt du was?

Weißt du auf was?

Ich habe es wieder vergessen, ich wusste es mal.

Der Jens hat irgendwas Eigens gebaut.

Nee, nee, aber ja, oder er hat was eigentlich, ich weiß es nicht mehr genau.

Jedenfalls, genau, also vielleicht will ich ja auf irgendwas anderes umsteigen, aber ich kann ja diesen JSON-Layer halt sozusagen halten.

Dann muss ich an meinem quasi Deployment-Überwachungstool muss ich überhaupt nichts mehr ändern, muss ich überhaupt nichts ändern, das läuft einfach so weiter und ich habe unten drunter kann ich das Ensible austauschen und also das finde ich ganz nett, dass man das weiß, dass es geht, dass man nicht irgendwie Ensible Tower oder so verwenden muss.

Weil das ist ja auch sowas, nicht meine

Ensible Tower ist das ja nochmal so.

Ah ja, gut, stimmt, das müssen wir noch.

Das würde ich nämlich, wäre ich auch noch zugekommen.

Ja, also diese ganzen Probleme, die Ensible ja hat, zum Beispiel, manchmal hat man ja Tasks, die sollen so wie ein Cronjob laufen, aber dann sollen die nicht auf der lokalen Maschine laufen.

Und dann hat man erstmal ein Problem.

Ja, aber man müsste ja quasi irgendwas online halten die ganze Zeit, was dann Sachen.

Genau, und das wäre genau Ensible Tower.

Der kann dann halt, da kann man halt Playbooks reintun und die laufen dann.

Und wo steht denn der?

Also, den kann man sich von Red Hat mieten.

Ah, deswegen rum wir jetzt in der Enterprise-Variante.

Genau, und die Enterprise-Preise werden auch nicht angezeigt auf der Webseite.

Das heißt, es ist auch ein bisschen.

Oder theoretisch könnte man sich auch eigentlich so einen eigenen Server per Ansible konfigurieren, der dann Crondrops laufen lässt?

Genau, also Ensible Tower an sich, wenn es gehostet laufen lässt, ist es auch teuer.

Es gibt es auch selber aufsetzen.

Aber ja, habe ich bisher noch nie geschafft.

Komischerweise ist es auch ein Docker-Container und kein Ensibel Playbook.

Hätte ich jetzt eher erwartet, so DockFood.

Aber warum macht man da nicht sowas wie einfach Crondrops auf einem

Black Metal?

Genau.

Ja, kannst du machen, aber es ist natürlich auch.

Der Ensible Tower gibt ja natürlich eine schöne Web-Oberfläche, die dann die Loks einfängt und alles sagt.

Kann man ja auch

alles selber bauen, irgendwie so ein Grafana-Prämie.

Ja, alles selber bauen ist natürlich auch immer eine gute Zeit senke.

Ja, ich hab's getan und ja, es war sehr, ich konnte da quasi beliebig viel Zeit drin versenken, das war gar kein Problem.

Ja, das war, ich hab so eine der ersten Django-Apps, die ich hatte, oder hat dann, also die zweite App, die hat nämlich dann die erste App, die ich hatte, deployed per Ansible Playbooks.

Ach, sehr gut.

Jetzt kommen irgendwie bekannt vor.

Ja, genau das, genau das mache ich halt auch.

Und mal gucken, ob ich das hier.

Das ist gerade.

Das ist natürlich das so im Planet.

Ja, aber das ist ja auch so.

Bei mir heißt das Stuart.

Ich habe mir ja überlegt, ich muss die ganze Nacht nach Schiffen nennen.

Die Server heißen alle nach Planeten und dann die Dinge, ein Steward, Lieutenant oder so, je nachdem.