Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Paisen-Podcast, Episode 44.
Heute soll es gehen um Enzebel.
Hi Jochen.
Herzlich willkommen Dominik.
Oh meine Güte, das geht ja schon holprig los.
Heute ist der Max dabei.
Ein bisschen Pause gemacht und schon geht nichts mehr.
Und der Max, natürlich, hallo, willkommen.
Hallo, heute bin ich dabei.
Ja, wir reden über Enzebel, 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,
Jetzt war es ein bisschen Sommerloch.
Ja, und aber auch schon angehauen,
dass wir doch mal wieder was machen sollen.
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...
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.
Was diesmal dabei ist, also das was
ja, das Ding ist auch auf Erkan News
irgendwie auf die Start, 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 auch gar nicht so, ne?
Bitte? 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 haben wir
den Artikel über... Letzten Sommer.
Das war nicht letzten Sommer. Doch, das war
letzten Sommer. Ne, ne, ich meine, das war 2020,
oder? Das war zwei Jahre schon.
Ich meine, das ist zwei Jahre her.
Oh, ja, okay.
Ups. Ja.
Letzten Sommer war was anderes.
Wenn ich überlege, letzten Sommer war
DjangoCon EU 2021,
damit hatte ich da, also das muss
zwei Jahre her gewesen sein. 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 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 ein Threadpool oder so, 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 bringen einem was,
sind sowas wie Model Constraints.
Also 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 der Wert
muss zwischen dem und dem liegen oder darf nichts anderes
sein als das oder so. Irgendwas rauben wir mal
für Constraints da. Kleine Validierung, ja.
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 Formen gesagt,
alles okay und dann, wenn das
wenn der View oder was auch immer
oder das Formen versucht, das in den 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 Formen 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 hat die Datenbank dann angefangen.
Mit Status Quotes vielleicht sogar.
Ja, und dann eigentlich die, also
ehrlich gesagt, aus meiner Perspektive die coolste
Neuerung, ich hab's mir jetzt noch nicht so richtig,
aber es klang schon alles sehr viel, sprechen das, was ich
gelesen habe, klang auch sehr, sehr gut.
Das coolste 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 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 Formen zu rennern,
sodass man es gar nicht mehr unbedingt in jedem Formen einstellen
muss. Und ja, da gibt es
jede Menge, also es ist
deutlich flexibler geworden, wie man Formulare
rennern 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 war immer ein bisschen anstrengend.
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
Django HDMX, also mit HDMX
zusammen zu benutzen. Und dann hätte ich gern
halt nur, ich ändere ein
Feld, dann geht das,
gehen die Formulardaten an
einen 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.
In nested forms oder sowas.
in sehr komplizierten Formularen
und allein nur das zurückgeben
und um das hinzukriegen,
muss ich sehr, sehr tief in Crispy Forms reingucken,
wie das dann 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.
Wie heißt das? Form-Tweaks?
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 Riesentemplate,
was alles durchrendert,
also alles durchloopt
und dann letztlich
dann die EFAP-Fragen 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
HTMLX verwendest und sagst,
okay, wenn da jemand draufklickt,
dann wird das, eigentlich möchte ich nur
einen kleinen Teil austauschen, das geht dann ja wahrscheinlich nicht so einfach,
wenn du das Formular in einem großen
Template erinnerst?
Ja, du sagst ja, wohin das
soll, letztlich.
Und
da über den Response
kannst du dann letztlich
das ändern.
Also in den Dom dann direkt reingehen
und das dann an die Stelle packen.
Tatsächlich muss ich sagen, wenn ich dann
in so ein spezielleres Form gehe, was halt nicht so
0815 ist, dann
schreibe ich die auch komplett
von der Pike auf.
ich dann die meiste Kontrolle habe, weil mir da Django
einfach nicht so genug entgegenkommt.
Ja, ja, ja. Ich verstehe das durchaus.
Aber zum Beispiel den Fall, den wir
da hatten, der war halt,
dass es ganz viele unterschiedliche Formulare
gab, aber viele der Formularteile
waren halt gleich. Sodass man das eigentlich
so machen möchte, dass man sagen möchte, okay, dieser Teil
des Formulars, das ist 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
holen. 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...
Also das wird jetzt auf jeden Fall schön mit Dango 4.
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 kann es schon leicht
schmerzhaft werden.
Ja, genau. More News?
Ansonsten
irgendwie, ja,
Pydentic 2 kommt jetzt,
also, beziehungsweise ist es noch nicht
released, aber das wird jetzt so allmählich
Richtung Release
geht das. Und also
du meintest ja auch schon mal so, genau,
Pydentic Core. Genau, Pydentic Core.
Rust-Implementierung und Rust, dass das
schnell wird. Ja.
Ja, ich,
Das ist ja, genau, also das ist halt
halt das Problem, also Pandentica hat auch so ein paar Probleme,
die in 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 Data Classes
sind auch nochmal deutlich langsamer als
ganz normale Klassen, ja.
Ja, okay, oder Atis oder so, glaube ich, das kannst du
sagen. Ja.
und ja, das ist natürlich
irgendwie ein bisschen doof und
genau,
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, 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 Saiten?
und da hat er relativ ausführlich
darü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 halt so C
und es wird halt schon nach C kopiert
und dann
führt das halt dazu, dass die
Binarys riesig werden, weil da halt
irgendwie doch jede Menge
genau C hinterher kommt.
Und
das ist bei Rust wohl nicht,
da gibt es irgendwie dieses
Pyos3-Ding da, mit dem
man Rust-Geschichten
einbinden kann und das
macht halt...
Und die Binaries werden
halt deutlich kleiner und das ist natürlich schön,
weil dann, ja, das war nicht so...
Und es ist halt, genau...
Man kann halt alles wegputzen, was nicht gebraucht wird oder so,
glaube ich. Ja, und die
ganze Parsing-Logik ist jetzt bei
Paladin Decor komplett in Rust und
es ist halt auch gar nicht so, dass...
Bei Zeiten würde man halt sagen, okay, einige Teile
macht man halt dann einen C oder
schreibt man einen Zeiten, die dann nach C kompiliert 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 sowas,
ja, wenn dann
Leute dann aus der Google-Ecke sagen oder so,
ja, wenn man mehrere, viele Datenbankzeilen
aus der Datenbank holt, dann ist er bei Python immer langsam.
Und ja, also wenn man Pydentik verwendet oder
irgendwie sonst wie ein ORM
und dann Objekte daraus erzeugt,
also bei Pydentik 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 Millionen Zahlen aus der Datenbank
holt, dann darf man halt nicht aus jeder Zahl ein Objekt
machen. Das ist halt dann nicht gut.
Und sonst zu langsam.
Ja, hast du noch weitere News?
Nee. Ich war auf der Europython.
Ja. 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. Da gibt es leckere
Getränke.
Aber aus der Python-Bestseitigkeit 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 Arminio,
bei Strawberry einen netten Workshop gemacht.
Das war sehr schön und interessant zu hören.
Das war 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-Untrückgene kann man relativ
gut definieren, welche Queries möglich sind
auf die Datenbank und hat dann einen
Endpunkt, das Expose, den man dann halt
erfragen kann, um mal so ein bisschen
den Nutzer dieser API
direkt entscheiden zu lassen, was er denn haben will und muss dann halt nicht
die ganze Quad-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
mismatched 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 hab auch mal eine Zeit lang irgendwie intensiv
GraphQL gemacht, meistens
dann halt Django und Graphene,
was dann halt, ja, das wird dann auch
manchmal so unerklärlich langsam und manchmal hat man so
Probleme, das rauszukriegen
dann, warum da, und ja,
das ist, glaube ich, hat auch diverse Designprobleme,
auch, ich glaube, der Autor von Graphene meinte dann
irgendwann, ach, ihr müsst das nochmal alles komplett neu schreiben,
und keine Ahnung. An den Punkt kommt man eigentlich immer.
Ja, natürlich.
Und ich weiß auch nicht,
ich weiß ehrlich gesagt nicht, ob
GraphQL überhaupt noch so eine, ich weiß es nicht,
ich habe letztens auch
kritische Stimmen gehört, in die Richtung.
Ja, Armin
Runacher, jetzt letztens auf Twitter, schrieb er dann so,
irgendwie, also, ach,
das war, glaube ich, oder war das der HTMX-Typ?
Ich bin mir nicht mehr sicher.
Der dann schrieb, naja, bedenke,
dass du, ach so, genau,
ich glaube, Amin Omar, also diese
GraphQL-Geschichte ist so unfassbar komplex und das wird
alles so, oh, wie ist
jemand 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 Datenbank-Endpunkt
quasi deinem Frontend zur Verfügung
stellst. Du stellst den nicht nur deinem Freund
zur Verfügung, sondern auch allen anderen, inklusive
Leuten, die dich angreifen wollen. Ja, also du kannst
auf jeden Fall schon dusten damit. Das ist natürlich
extrem schwierig zu verhindern, dass
das nicht geht.
Also. Ja, ja.
Ja, also auf jeden Fall trotzdem
der Workshop war sehr interessant. Ja, aber es
sollte gut sein. Genau, das ist so ein bisschen
ähnlich von FastAPI, also ungefähr
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 Norweg
und zwar hat das Luciano Romano
das gemacht und so über Lisk-Screen-Parser
in Python, relativ kurz,
das gab so ein, weiß nicht wie lange das ist,
gelogen 70 Zeilen oder sowas
in Python, kompletter Lisk-Screen-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 Lisk-Screen-Parser ist ja relativ ähnlich
zu JavaScript, glaube ich, oder so, wie man dann Tugends
baut und Funktionen baut irgendwie und
fand ich ganz interessant, das mal so zu sehen,
auch mit Typefins und so versehen.
Ja, generell, wo
Python halt überall verwandt wird und verwendet wird.
Also James Webb Space Telescope
von der NASA, da war auch jemand da,
der dann sagte so, hey, wie denn die Bilder in Python
zur Erde geschickt werden und so. Das ist natürlich, dann
freut man sich immer, dass es so berühmte Anwendungsfälle gibt.
Die Lynn hat
einen sehr schönen Talk gemacht über Everyday RPs
von Spotify. Das ist eine
Entwicklerin, die da
einfach so einen netten Talk gemacht hat. Ich glaube,
so wie wir das auch machen, aber sie hat eine sehr hübsche Folie.
Können wir auch mal verlinken.
Genau. Da kann man sich
nochmal so angucken, wie man so APIs
designt, glaube ich, das fand ich ganz interessant.
Ah, ja.
Auch super, das war einer der,
für mich fand ich, das war so didaktisch besten Talks,
das war von Niall O'Connor, irgendwie über
Fibonacci-Retrace-Levels, Asset-Price-Prediction-Reverse
von der Bank of America.
Ja, der ist auch so rumgespringen,
hat die ganze Zeit über Resistances
gesprochen und da ist eigentlich immer
die Folie gewechselt, irgendwie jetzt
ein weiter, ein weiter, in so einem Run-We-Are-All-Dead
und dann klick, klick, klick, eine Folie nach dem anderen.
Das war super, ich fand es toll.
Muss man sich eigentlich wenigstens mal angucken.
Ich muss auch mal irgendwann so ein Trading-Bot bauen, keine Ahnung.
Was ich auch ganz cool war, war das Team von Huggingface war da.
Die haben ja dieses DALI 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 DALI Bilder generieren.
Ja, cool, genau.
Ja, und das Coole ist, es gibt da einen Python-Wrapper drum, um Huggingface, der nennt sich Gradio.
Den kann man einfach installieren und dann kann man gerade sagen
Gradual 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 die Features
irgendwie anpassen. Das fand ich sehr nice, so zum
ausprobieren und so ganz schnell
Machine Learning innerhalb von kurzen Teilen bauen.
Das war sehr cool, sehr nice.
Ja,
da gab es noch so ein paar politische Talks über AI,
Dystopia und sowas, was man alles nicht mit Killer-Robotern
machen kann und so, wenn man sich das nochmal
angucken möchte, so die Argumentationen, die dahinter stecken.
dann darüber, wie man 3.11
jetzt schneller gemacht hat, hat
Max Schendler gesagt.
Das war auch sehr schön, also 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 mehr Nogil benutzen möchte.
Robin
habe ich gesehen, das ist ein neues Framework.
Ein asynchrones Python-Web-Framework,
das mit einer Rust-Runtime läuft.
Dann kannst du halt sowas wie UV-Con sparen
vorneweg und hast halt direkt diese
Rust-One-Time und es ist relativ, sag ich schnell,
wenn du relativ gute
Anforderungen hast. Ja, 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 Rust, also das
Einzige, also ich meine, UV-Corn 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,
UV-Corn ist deutlich schneller, äh, deutlich langsamer
als sowas wie Nginx und so und ich weiß nicht, warum.
Ich habe keine Ahnung, wahrscheinlich müsst ihr ja mal tiefer reingucken,
was das eigentlich, warum das ist. Also bei dem Roboing
gibt es auf jeden Fall auch diese, so ein paar
Benchmarks. Ich weiß halt immer nicht, du bist ja immer bei Benchmarks immer ein bisschen
kritisch, wie gut die sind oder wie neutral die sind.
Ja, ja, es ist schwierig. Also, sagen wir mal so, 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 gebenchmarked hast oder deine
CPU gebenchmarked hast oder den Speicherbus
gebildet hast. Es ist halt irgendwie, es kann
vielfältig schief gehen. Genau.
Ja, also jedenfalls, das war super interessant.
Achso, genau, ich hatte mal auch schon dieses Tempolastalk, da geht es halt
um Reference-Crouching auch, mit dem Nogel, dass man halt
dass er irgendwie das ersetzen kann.
Ja, dann
gab es noch ein Talk
über Jot. Fand ich ganz interessant. Da wusste ich noch nicht
alles drüber. Da haben die Jessica erzählt.
So ein bisschen nochmal
so die Details darüber,
was da für ein Payout drin ist und so weiter. Das war interessant.
Und noch der Luciano Romano
hat noch einen über Typing.
Ja, der hat ja jetzt, also überhaupt,
ich weiß nicht, ob der so bekannt ist,
der Name, wenn man den sagt,
ob der den Leuten direkt...
Das ist der Autor von Fluent Python.
Ganz lange Zeit schon eine Community
aktiv und also ich finde
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
ein Kapitel über Typing und das ist halt
super. Also ja, kann man
Genau, das meint er so, wie du dich das vorgestellt hast.
Das war bei der Talk
bei Typings as Guido intended.
Ah, okay. Weil das würde mich
jetzt mal interessieren, weil ich habe das,
also ich habe da so ein bisschen reingelesen, ich habe es 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-In
Geschichte. 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, ich glaube, er hat gerade ein Protokoll
entwickelt, wie man das so machen kann. Also Type-In.protocol
macht er irgendwie, um solche Sachen zu lösen.
Das war ganz spannend.
Ja, super Search
mit OpenSearch, war noch ganz
interessant. Also OpenSearch als Elasticsearch
Fork, irgendwie mit Python
ein ganz schöner Talk dazu.
Dublin war toll, man konnte
auch an den Strand fahren, war super Wetter und
nette Leute kennengelernt, Gruß an Marlene.
Ja, sehr schön.
Das war eine super Veranstaltung. Kann ich empfehlen, das
nächstes Mal gerne wieder.
Nächstes Mal schaffe ich es vielleicht auch.
Gruß an Jan Hendrik auch, war auch sehr schön.
Ja.
Ja, habt ihr noch News?
Dann sind wir vielleicht endlich beim Thema.
Ja.
Das Thema ist nämlich heute Ansible.
Und ich würde sagen, jetzt ist auch der perfekte
Zeitpunkt für Max, dass Max sich vorstellt und
Hallo sagt. Ja, hallo.
Ich bin Max und
ja,
programmiere viel in
Python, mach 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 Server-Einrichtung.
Richtung. Genau, also
so, Ansible macht ja
Konfigurationsmanagement. Kennt ihr alle
Ansible? Ja, ich bin 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 Skripts und die
Konfigurationen 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 Anse,
also es gibt da 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,
Ansible ist halt das Tool mit der
niedrigsten Hürde, weil
man ja 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 keinen 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 es natürlich auch so ein paar Trade-offs in der Richtung.
Das 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ß Ansel Bilder nichts.
Es geht einfach kaputt oder aus, wenn irgendwas nicht stimmt.
Ja, also der hält da im 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 es 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...
Aber das ist so eine Konvention, die man dann haben muss.
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 Ansible-Wahrheit war, nichts zu tun.
Genau. Und deswegen weiß ich am...
Also, wenn ich das nächste Mal dann Ansible ausführe,
halt nicht, wie sieht denn jetzt die Wirklichkeit auf der Maschine aus.
Mhm, okay.
Ja, also vielleicht wollen wir
tatsächlich so ein bisschen reingehen, was Ensemble macht, wie 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 da kommen dann halt,
also einmal ist es halt ein Riesenfall. Man braucht nur SSH,
das ist alles. Das hat man ja 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
und kriegt man halt meistens
ein Root-Login da.
Das ist halt etwas,
bis dahin ist es ja meistens schon automatisiert.
so, 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 Ansible schon anfangen, während man
bei anderen Sachen, dann muss man halt dann irgendwie einen 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 halt dann
bestimmte Sachen eben, wie er schon angesprochen hat, also eine
Geschichte, die ich noch hinzufügen würde, ist,
macht das halt auch langsam. Das ist halt dadurch,
dass das alles durch S haben muss.
Also wenn zum Beispiel Files kopieren,
viele Files kopieren, ist halt mit Ansible
oder Templates, die dann
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
HashiCorp-Language, in der man dann
auch in YAML Infrastruktur definieren
kann. Also wie sieht die tatsächliche Hardware
auf? Wie viele 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 Ansible beispielsweise
kombiniert. Ja, man hat halt dann
entweder macht man
per Ansible so Terraform. Da musst du
manchmal 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 Ansible-Kommandos
reinzugeben, die auf dem Server laufen
sollen. Und dann bedeutet das natürlich,
das ist so ein bisschen von hinten in den Wurzels Augen,
das muss dann so ein Cloud-Init-Skript zum Beispiel mit angeben,
was dann auch quasi
Ansible selbst auf dem Rechner installiert und dann
als Local-Host-Inventory läuft.
Also, dass eine Host läuft, dann halt
local.
Ja, kann man so machen.
Es ist aber sehr kompliziert, ja.
Ja, also du hast halt hinterher das Problem,
dass du halt für Management die IPs wieder rausreichen musst
und einen SSH-Zugang brauchst, den Ensoble nutzen kann,
damit es halt dann sowas wie Upgrades oder sowas
auf einen Kisten ausgerollt werden kann, wenn du da
mehrere Farmen mitträumen wirst.
Ich weiß nicht, ob ich das kompliziert finde,
aber das ist halt so andersrum,
weil du hast halt immer nur so einen Localhost,
den du dann provisionst, aber der sieht dann
schon so aus, wie du willst. Vielleicht erklärst du
nochmal kurz, wie es andersrum bei dir funktioniert.
Erst Ensoble, dann Terraform.
Ja, also letztlich mache ich auch
also erst Terraform.
Ach so.
Und dann lasse ich mir das
Inventory dynamisch erstellen.
Ah genau, das hätte ich jetzt auch gedacht, dass das vielleicht ein guter Weg ist.
Und dann, genau, also
so der andere Weg, Ansible und dann Terraform
heißt dann, okay, ich habe dann erstmal
Ansible und lasse dann
ja,
da soweit dann schon mal alle Templates
und soweit 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, also
richtige TMWs.
Vielleicht müssen wir das nochmal kurz auseinander drusseln. Also erst
Ansible, lässt du dann die Terraform
Templates von Ansible befüllen,
dass halt quasi
Terraform dann weiß,
welche, also die Frage ist halt,
wo läuft dann diese ersten Control-Nodes? Läuft die dann
lokal und füllt dann quasi die
Terraform Templates mit den Dingen, die du dir vorgestellt hast,
über ein eigenes Ansible
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 sehen denn denn die Kisten aus?
Da muss Ansible ja quasi wieder hingehen,
diese Nodes, die es erstellt hat,
connecten und dann da seine Rollen aufbauen.
Vielleicht noch ganz kurz,
eine Ansible-Rolle ist quasi genau das,
was man hat.
Also eine Konfiguration für irgendwas.
Also Rolle, Datenbank-Server, Rolle, Web-Applikation, Rolle.
Genau, das ist also die Frage.
Wollen wir nochmal in die Definition gehen,
damit wir das Thema Playbooks, Plays, Tasks und Rollen klar haben,
weil ich finde, das ist das Verwirrendste.
Also Inventory, damit kommt man ja irgendwie so klar.
Vielleicht auch nochmal erklären für jemand,
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, 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 Bestimmung 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, 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 Föber ausgeführt werden sollen, damit das so ist, wie man sich das vorstellt.
Genau, aber Play ist halt, ein Playbook kann halt Rollen benutzen, aber Play, das ist keine Rolle selber, sondern Playbook ist halt, da kann ich halt, genau, Rollen drin benutzen, aber es gibt auch Leute, die das gar nicht machen, sondern die alles immer inkluden irgendwie, es 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.
Man kann auch alles, das geht sehr gut.
Ich mache tatsächlich ganz viele Rollen irgendwie.
Also ich weiß nicht,
also Ensemble Galaxy ist auch ganz schön,
das ist halt der Cloud, ist das Cloud-Dienst?
Also so ein...
Ja, die Sammlung von Rollen, die kann man hochstellen.
So wie PIP quasi, bloß für
Ensemble.
Also ich bin immer so ein bisschen picky, ich mache immer viele Sachen
selber, also notamentet hier und so.
Ja, genau. Also dann die Ansible Galaxy gucke ich mir dann auch zur Inspiration an.
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ß nicht, aus Gender-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 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-blah
oder so.
Ja. Postgres zum Beispiel
und Django auf einmal. Also dann wäre ja die
Rolle letztlich Postgres und dann kann man
sagen... Ja, dann wäre die 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
Ansible ja zum Beispiel auch ermöglicht, ist eine Unterscheidung
zwischen den Betriebssystemen, die benutzt
werden, also jetzt, ob ich jetzt einen
Red Hat Enterprise habe oder einen debilen oder so
und
das finde ich ja so 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. Ja, genau.
Ja. 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
anders als die anderen.
Ja, genau.
Ich meine,
ich verstehe schon, dass Leute diesen Fall haben.
Ich habe den selber auch nicht. Bei mir sind alle
Server, haben irgendwie das gleiche Betriebssystem.
Welches benutzt du? Ja, Debian
tatsächlich Bullseye zurzeit.
Das ist nicht ArchLinux.
Ja, es gibt da auch interessante Alternativen.
Also womit ich ab und zu mal geliebt georgelt habe,
ist halt nix.
Also ich habe nix auch benutzt,
aber nur als Desktop, also nicht als Server-Variante.
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 es ist halt nicht alles verfügbar
und es ist einfach sehr, sehr viel Maintenance-Arbeit,
wenn man da irgendwie Updates fahren will
und dann nicht, dass das 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, 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 es gibt keine Überraschungen
und die Frage ist, muss ich
halt die Schlachten aussuchen?
Dann würde ich sagen, na gut, dann nehme ich damit, dass es halt irgendwie
langweiliges Debian ist
und dann kann ich
die interessanten...
mein Innovation-Token irgendwo anders
ausgeben, wo es halt vielleicht irgendwie mehr bringt.
Aber es reizt mich schon, das muss ich
sagen, ja, das ist, ja.
Ja, also bei der Definition jetzt,
ich glaube, wo waren wir denn?
Infantiles, Playbooks, Hosts?
Genau. Haben wir das
klar genug definiert oder sind wir da auch wieder so
langsam? Ja,
genau. Ich wollte
irgendwas sagen, ich hab's wieder vergessen. Ich glaube, ja, ich hab
diesen Fall eben auch, das nervt mich auch in diesen
Rollen, die man halt von
der Galaxy bekommt.
eben sowas wie Postgres zum Beispiel.
Also, was ich dann, wenn ich diese
Rolle, ich weiß nicht, ob ihr die kennt,
die habe ich mal irgendwann benutzt, ich weiß nicht,
gibt es immer einen, der schreibt
die alle. Wie heißt der? Gerling?
Genau, der hat auch ein richtig
gutes Buch
über Ansible und noch ein paar gute
YouTube-Videos. Alle in die Shownotes?
Genau, 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.
Und wenn nicht, dann fragt man ihn an und wartet so lange,
bis die dann kommt.
Ja, genau. Aber das Problem bei denen
ist halt oft,
weil der hat dann eben für Postgres
zum Beispiel einen und die fand ich nicht, sondern ich habe seine geforkt
und dann
einfach
das ist zwar, also den Hauptteil
davon, der interessiert mich halt nicht, irgendwie die ganzen Installationen
für alle möglichen Plattformen und dann der Teil,
der mich interessiert für Debian,
da hätte ich keine andere Version.
Dann muss ich das aber irgendwie patchen, dass das dann doch geht.
Ja, gut, Ansible Galaxy,
das ist halt für alle
Anwendungsfälle und
gut.
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, okay, das ist so ein bisschen der Docker-Container
für den Server oder so. Also
so eine Rolle. Ich spawne jetzt meinen Server
in der und der Saison, ja.
Ja, in gewisser Weise, das finde ich
auch, das ist vielleicht ein guter Vergleich, das halt auch so,
aber ich meine, ist halt die Frage, ob man damit Rolle meint
oder ein Playbook, weil ich verwende eher Playbooks
tatsächlich so, wie vielleicht
ein Docker-Pile. Meistens braucht halt
irgendwie so ein Server mehrere Rollen, würde ich sagen, damit er das
macht, was man will. Ja, ja, aber
ich würde sagen, ich habe halt
für diese Geschichte zum Beispiel,
er soll irgendeine Funktion erfüllen,
habe ich halt ein Playbook bei mir
und nicht eine Rolle. Genau, ja, habe ich auch,
Ja, das kombiniert halt bei mir dann so
bestimmt. Genau, und
tatsächlich ist das, finde ich, auch
sehr ähnlich zu sowas wie Dockerfile
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 so hat.
Und auch
die ganzen Security-Sachen sind, finde ich, da
deutlich, wenn man das so macht, deutlich klarer als jetzt bei
Docker. Und, naja.
Ja, nochmal so zum
Abgrenzung Rolle und Playbook.
Ja, Rolle ist wirklich dafür
gedacht, alleine zu stehen.
Also bei dem Playbook, dann sage ich
okay, ich möchte halt
so einen bestimmten Server auf die
oder eine bestimmte Gruppe von
Servern, so konfiguriert haben und
eine Rolle wäre dann quasi so die
Unterfunktion davon, wenn ich sage, okay
Diese Konfiguration wird dann angewandt.
Genau. Und
ja, das Playbook,
wenn man sich dann so eine
größere, größeres Cluster
vorstellt, enthält dann es halt
mehrere Rollen. Also ein Loadbalancer,
einen Web-Server, eine Datenbank.
Was der Running-Back machen soll, was der Quarter-Back machen soll,
wie die Define stehen soll. Richtig, genau.
Ja, ja.
Okay, also ich glaube,
dann die grundsätzlichen Sachen haben wir definiert.
Haben wir noch was vergessen? Achso, vielleicht Facts.
Was ist ein Fact?
Ja, das ist halt das, was Ansible
irgendwie rausfindet.
Also am Anfang...
Ja, man macht das halt so ein Gathering-Facts.
Das kann man aber auch abschalten,
wenn man es nicht braucht. Dingen, wo dann halt
bestimmte Variablen belegt werden, mit
Informationen über das System, auf dem man grad irgendwie...
Kommt 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 reinpipet 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 drauf pipen, die halt
relativ nativ sich anfühlen,
wenn man das irgendwie bearbeiten möchte.
Achso, du meinst, um nochmal andere Dinge,
die da jetzt nicht drin waren,
man kann in einem Task sagen, Set Fact
und dann halt irgendwas.
Genau, dann kann man dann Pipe, Strip,
String, Station, was auch immer.
Die Playbooks, die sind ja letztlich,
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 es 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 noch ein Exkurs,
Ginger 2?
Ja, Ginger 2,
Templating Engine,
letztlich
so wie
alle Templating Engines, die man so
kennt. Django macht das ja auch.
Ist auch ähnlich.
Nicht genau so Ginger 2
ist wahrscheinlich sogar die bessere Template-Language.
Genau, es gibt auch Jinja 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.
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 dazwischen habe,
wenn man mit den ganzen Sachen umgeht.
Aber jetzt vielleicht noch mal, warum wir kurz das definieren wollten,
um diese Terraform-Ansible-Sache noch mal so ein bisschen zu verstehen.
Was spricht jetzt zum Beispiel dagegen,
sowas wie dieses lokale Ansible zu machen, deiner Meinung nach?
Wenn man sagt, okay, man lädt jetzt einen 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.
Nee, ich brauche die halt über Terraform,
muss ich die SSH-Verbindung bauen.
Genau, aber nicht mehr dann die auf dem,
also wenn du ja über die Local Connection gehst.
Genau, ich mache dann Fire and Forget.
Also ich sage dem halt quasi, renn los.
Und dann macht er halt sein Ensobe-Kram.
Ich habe da wenig Kontrolle drüber, ich muss halt dann auf den Server
in die Logs gucken oder was auch immer, um
festzustellen, wo sind die denn 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. Ja gut, man muss halt einmal ordentlich
E-Debuggen, damit er einmal sicherstellen kann, dass so ein Server
das macht, was er will, aber ja.
Ja.
Also es ist auf jeden Fall durchaus ein gangbarer Weg.
Ist dann die Frage,
ob man da ein bisschen so
die Idee hinter Ansible,
ja.
Also ich frage jetzt halt, was so ein Terraform ist, weil ich
frage mich halt, wie dann halt Terraform sonst aussehen soll,
weil ich weiß ja gar nicht, mit Ansible
anzufangen, welcher Server habe ich denn denn jetzt?
Ja, aber ich meine,
gut, vielleicht macht ihr das, aber
ich wundere mich mal, ich verwende gar keinen Terraform.
Ich meine, ich habe jetzt
auch nicht irgendwie
jobmäßig irgendwas, große Cluster zu konfigurieren
und so, wenn ich das hätte, hätte ich das vielleicht dann
doch, aber so für meinen
privaten oder so semi-privaten
Jörg hat gerade zugegeben, dass er sich die einzelnen
Cloud-Helfer einfach zusammenklickt.
Ja, ich benutze halt das Web-Advisor und ich rufe jemanden an,
der macht das dann.
Nee, aber ich kenne, es sind so
wenige, ja, so Privat-Helfer.
Handverlesene Server.
So viele habe ich dadurch, dass ich die nicht mehr kennen würde.
Da kenne ich jeden Einzelnen mit Namen
sozusagen. Und die kann ich dann auch
in den Ventury reinschreiben.
Ja, aber das ist ja eigentlich auch erst Terraform.
Also, weil das macht ja genau das, was du da klicken würdest.
Und dann Ensemble. 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
Endzippelweg ist, wie es vorgesehen ist.
Was ich halt bei mir machen würde, ist halt,
ich sage halt direkt
beim Deployment von Terraform, was
halt werden soll, und ich müsste mir
dann halt auch aus dem Output den
SSH, den ich mir dann selber, also ich
mache dann keinen SSH-Zuruf mehr, sondern halt
mit Keys, was ordentlich, dass es irgendwie einen User
gibt, der das dann darf und der
Nee, ja Moment, das wird
interessant. Du machst, du
connectest dich,
wenn du Ansible benutzt,
auf einen User? Nein.
Auf dem Rechner? Nein, Moment.
Ich gehe hin, ich baue
eine Kiste, beispielsweise bei Hetzner
oder bei Azure oder so was und
sag dem über so ein Cloud-Init-Skript
bitte installiere
Ansible 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 Extravariablen und das Playbook, das ausgeführt werden soll, kommt rein.
und ich klone quasi lokal
das Ansible-Server-Repo
und dann lasse ich da lokal
mit Localhost 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. Ja gut, 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
zum Beispiel meinen 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-Ansible
noch da reinschreiben.
Das sind aber dann trotzdem zwei Repos. Das eine
Repo ist das Terraform-Repo mit diesem Service-Ansible, wo
dann quasi ich mit Updates fahren kann oder
sowas oder ich überprüfe bitte den State für alle
Web-Applikationen, upgradee Django auf die
neueste Variante oder so.
Und auf der anderen Seite
das Enzibel-Setup läuft halt
über das Enzibel-Repo, wo halt dann
die ganzen Standard-Rollen
drin sind. Ah, okay.
Ja, interessant. Also
das ist irgendwie ganz anders, als ich das
erwähnt habe. Ja, nee,
witzig. Also ich muss sagen, es funktioniert
ganz gut. Es wütet sich auch so ein bisschen von hinten
durch die Brust. Ich habe mehrere Blog-Einträge
durchgelesen, mit so für und wieder.
Das war am Anfang so ein bisschen halt gefummelt,
das so hinzubekommen, dass das so funktioniert.
Aber das funktioniert halt gut.
Ja, also
mein einziger Einwand wäre dann
zu sagen, okay, hast du
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 für Rollen das haben soll.
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.
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 ist ein Terraform-Ordner
ein Tango-Server, ein Terraform-Ordner ein Bucket,
ein Terraform-Ordner ein Datenbank-Server, irgendwie so.
Und da werden die Sachen halt dann,
kann man die auch so schnell skalieren, weil die Variablen
stehen halt dann direkt mit drin und das war halt okay,
Datenbank-Server ist ein bisschen schneller oder so
und hat ein bisschen andere Netzwerkkonfigurationen oder sowas.
Ja, gut.
Das klingt irgendwie, ja.
Genau, also erinnert mich auch so ein bisschen an Vagrant.
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.
Ich erinnere mich da auch noch dran.
Wann war das? 2012?
2013 habe ich das mal gemacht.
Das war ziemlich schrecklich, ehrlich gesagt.
Ja, aber da gab es noch kein Docker.
Da gab es noch kein Docker, genau.
Deswegen muss man da ein bisschen...
Ja, ja, ja.
Anderer Punkt.
Entschuldigung, ich wollte dich nicht unterbrechen, aber...
Ich zum Beispiel, ich mag es auch meinen
debilen Desktop
per Ansible auszurollen.
Ja. Okay.
Also kann ich absolut verstehen,
nur 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 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
Ansible zu machen. Ja, also die Alternative wäre nichts
gewesen.
Aber da
mich nichts genervt hat an so ein paar Punkten,
dann habe ich dann gesagt, okay, dann mache ich es mit Ansible, weil
ich möchte auf jeden Fall eine reproduzierbare Maschine
haben, weil mich nervt das 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 bei Ansible steuern. Da muss man halt dann immer
fliegen, muss halt immer dann ein Repo haben, was
halt für seinen Desktop ist, muss der halt da immer dran
rumpummeln. 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
sonstige Sachen irgendwie in der 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, wir können ja auch grafische Anwendungen in Docker
laufen lassen.
Ja.
Ja, ja, kann man auch.
Doch, es hat so einen Zwischenlayer irgendwie noch.
Ich weiß nicht, ob es so ein Personalismus-Rename 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
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 schwer zu installieren ist.
Und da gibt es ja durchaus Software.
Dann sagt man sich, okay, nimm doch hier einfach diesen Docker-Code
und 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.
Ja, also genau. Ich glaube, das Kompilieren ist das, was lange
dauert und Updates sind halt immer ein bisschen nervig.
Wenn man halt irgendwie so Breaking Changes irgendwo hat,
dann muss man alles wieder umbauen.
Naja.
Früher hat man auch
dann mehr Ansible-Playbooks
gesehen, wenn es dann um schwierige Installationen
ging.
Leider ist es so ein bisschen auf dem
absteigenden Ast.
Was nimmt man denn jetzt? Nur Docker dann?
Ja, oft findet man halt die Docker-Container
und dann sagt man hier, also wenn du das einfach
dem Run sagst, dann läuft der
und dann kannst du
mitnehmen.
Ja, das finde ich auch faszinierend, weil, also 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, es wird eher immer
schlimmer, hätte ich gesagt, aus meiner Perspektive.
Ich habe es auch zwischendurch ganz gerne genutzt, aber
ich weiß nicht, irgendwas finde ich nervig.
ja. Das ist immer so gekapselt
auch irgendwie. Also ich habe nicht so den direkten
Zugriff. Also sag mal so,
es nimmt einem schon irgendwie Probleme ab,
aber es hat halt nicht,
auch nicht so ganz die Flexibilität, wie jetzt
die man mit Ansible hat.
Also gerade, was man bei Docker dann doch irgendwie
öfter mal, was einem dann passiert, so zum Beispiel
irgendwie so, irgendwie das Filesystem ist halt
voll. So, man weiß halt nicht genau, warum.
Und dann guckt man halt und denkt, ach ja, deswegen,
ach, und dann, uh, was liegt denn
hier noch alles rum? Ich habe jetzt
diesen Container 30 Mal hier.
Genau, solche Sachen. Oh, Docker-Compost-Down
vergessen, ups. An der Stelle ist die Abstraktion
halt schon sehr leaky. Oder man muss halt
sich gut mit Docker auskennen. Oder was ich
dann halt oft sehe, wie Leute dann so
wirklich 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 und dann so
ah ja, okay, ich muss hier ein neues Paket
für das Docker-Image. Und dann warten die
halt da irgendwie stoisch eine halbe Stunde,
bis das irgendwie alles kopiert 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,
das ist doch normal, das ist doch immer so.
Guck mal rein und so, dann nehmen sie dann halt
Alpine irgendwie,
Linux, ja, und dann
installieren sie aber NumPy, ja, und dann
zieht das erstmal in GCC nach und dann wird erstmal
die komplette Compiler-Toolchain
irgendwie kompiliert 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, und dann nehmen sie Alpine, damit die klein werden,
und dann werden die irgendwie anderthalb Gigabyte groß.
Und, ja, und dann denke ich so,
also irgendwie,
ihr haltet das falsch rum.
Das ist, ja, genau.
Das ist irgendwie, das, ja.
Und, aber,
ich habe das Gefühl,
es hindert die Leute, also, wenn ich denke,
das ist eigentlich ein ziemliches Katastrophenszenario,
ja, und eigentlich müsste man sagen, also, wenn
die, 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, es verbreitet sich trotzdem.
Und das finde ich immer faszinierend.
Sind wir noch bei Docker oder schon bei JavaScript?
Ja, bei JavaScript und
irgendwie, ja, NPM und
diesen ganzen, ja, das ist teilweise so ähnlich, ja.
Es gibt doch jetzt bei
SAPN ganz viele andere Sachen, Dino und Ban.
Ja, aber das ist auch alles ziemlich furchtbar.
Ich meine, gut, vielleicht
liegt es irgendwann so, ja,
wird das da auch mal wieder.
Man überlebt 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 das halt ziemlich angenehmer.
Job Security ist auch ganz wichtig.
Aber ja, und
ich weiß nicht, also ich finde,
so im direkten Vergleich, wenn ich jetzt
irgendwie, das habe ich früher gemacht, zum Beispiel
pythonpodcast.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 da ist 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
Jochen mir gesagt, das ist so, wie man das macht und dann stand
ich erstmal für diese Komplexität. Ja, sorry, ich kam ja von
Vagrant und da sah das aus, als wäre
das Fortschritt. Also ich musste erstmal ein paar Mal
gegenhauen und hab mich erstmal gefragt, was ist das denn jetzt?
wie geht denn das jetzt? Muss ich jetzt eingeben?
Muss ich mir irgendwie tausendlange Kommandozeilen,
Listen schreiben, um zu verstehen, was machen?
Und dann überhaupt ein Introspekt.
Das war schon echt
ein Komplexitätsmonster, muss ich sagen.
Ja, also es tut mir leid.
Aber so ist es halt.
Ja, aber das läuft noch alles
auf Docker und so.
Es ist aber nicht, 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,
oh je, habe ich eigentlich ein Backup, habe ich wirklich
ein Backup, hoffentlich
mache ich jetzt nichts kaputt
und ich vergleiche das jetzt so
mit dem, was ich jetzt mache und das ist halt
irgendwie die Dinge einfach direkt via Ansible
zu installieren und ich habe halt für jeden Service
halt einen eigenen User und
der hat halt ein eigenes Virtual-End 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 ordentlich.
Aber man kann auch überall reingucken,
man kann da einfach als Root mal so
über alle 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-Stop-Zeugs, das man
da sonst so hat. Ja, vor allem, wenn die einmal gut sind, dann
ist das eigentlich angemacht. 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.
In einem user space
oder so. Ja, weil die sowieso
alle uniform sind und man
halt nicht, sagen wir
jetzt mal, 10 Container braucht, um
jede App zu kapseln. Ja, also
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,
oder wie 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 hinweilt und sagt so,
aber auf meiner Maschine läuft es, und jemand
klopft ihm auf die Schulter und sagt, okay, dann
shippen wir eben deine Maschine.
Das ist natürlich so, ja, wenn du
sonst einfach nicht deployed kriegst, außer du shippst
das, was der Entwickler da hat, dann ist locker
möglicherweise sehr gut. Und wenn du dann viele von solchen
Sachen auf einer Maschine laufen lassen willst, dann
führt vielleicht um den Docker auch kein Weg drumherum.
Aber das ist ja letztlich auch
der Kritikpunkt an Python, dass man quasi
immer die Entwicklermaschine shippen muss, damit
es überhaupt läuft. Ja, das ist
natürlich auch bei Python so ein Problem.
Wobei...
Also ich finde Poetry löst das, wenn Poetry läuft.
Ja. 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 Cash reparieren,
neue Versionen irgendwie installieren,
Pre. Fällt jetzt alles auseinander,
genau. Ja, ich stelle momentan
auch alle Sachen, wenn ich alte
Projekte habe und ich sehe dann, ah, dafür bin ich noch poachy,
ich stelle es meistens nochmal auf PIP-Tools. Aber PIP-Tools
ist furchtbar.
Wird auch verfügbar von PIP-Tools,
weil letztlich ist es nur PIP.
Ja, genau. Und wenn jemand PIP brechen
sollte, dann fällt es auf und dann machen andere
Ärger dafür, dass so viel Ärger, dass das dann
wieder funktioniert schnell. Also
genau, es ist letztlich nur PIP
Und man kann sich da ja Tools drumherum schreiben,
die das halt angenehm zu benutzen machen.
Ja, ja.
Oh, ich hab jetzt, das hab ich dann nochmal
versucht, weil du meintest, das kann auch
Pipetools können, das ist dann nicht so richtig.
Nein. Ja, genau.
Ja, das ist so. Und ich brauch Pipetools.
Also ich find die super, das ist eine gute Idee.
Ja.
Weil diese ganzen
TXT-Files mit irgendwie, ah ne, bäh.
Ja. Ich will die ganze Konfiguration
in Pipetools 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 einer
Pip-Projektion. Ja, aber 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 hakelig. Ja, aber das habe ich jetzt gelöst.
Tatsächlich. Ja, wie installierst du denn Poetry?
Also ich installiere
PyEnv, das Python,
was ich muss sagen. Okay. Dann
PipX. Aha, oh, oh, oh,
okay. Ja, und PipX
und Portree, das funktioniert gut. Und dann habe ich das Portree
drauf, was funktioniert. Ach, du installierst dann Portree per
PipX. Genau. Das ist aber nicht die empfohlene
Art, glaube ich. Ja, das ist egal, das ist furchtbar. Die empfohlene
Art ist furchtbar, das zu tun. Ja, das ist nämlich ein
Shell-Skript runterladen und ausführen. Ja, genau, das ist komisch.
Und deswegen per PipX, aber das funktioniert
dann super. Und dann habe ich dann per PipX, kann ich dann
Portree benutzen, um halt meine
Environments zu installieren und ein Kurz-Config-Setting
für Poetry und dann... Aber das ist schon
ein ganz schöner auch irgendwie...
Es ist ein Playbook.
Ja, das ist... Aber ja, das ist
funktioniert gut. Und wie kommst du an den...
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 General-Kontext? Du kannst den 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
reproduzierbar. Ich habe mir eine Funktion getrieben, die mit den Namen
von den Wänden kommt. 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 Envs in Project Paths dann machen.
Das mache ich bei Deployments dann, weil dann ist
das Problem erledigt. Weil dann hast du es halt einfach
lokal drin liegen. Und dann kannst du halt den Pfad
kannst du ja auch angeben, dann macht der halt nicht irgendwo
unter Envs mit einem Hash, sondern dann
Lässt das rein und das würde ich empfehlen.
Aber das ist auch genau der Punkt. Also benutzen
wir Docker, weil wir eben daherkamen,
auf Produktionsmaschinen? Ich würde fast sagen, nein,
weil das hat auch zu viel Hardwarefrist und man möchte
ja relativ viel...
Netzwerkprobleme hat man oft, wenn man das
in Docker macht. Das ist auch sehr nervig.
Und deswegen würde ich die Sachen in 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. Und da... Es gibt ja auch Entwickler, die
Windows benutzen. Ja, oder müssen. Und da
kommt man dann mit Docker schon mal ein bisschen
weiter. Also ich muss das auch
auf der Arbeit viel. Und da ist halt,
habe ich halt auch entforst, dass wir Docker-Container
nehmen, weil halt viele Sachen dann auf Linux nur
kompilieren richtig. Und auf Windows,
dass immer von hinten durch die Brust ins Auge ist oder dann 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 fährt man immer gegen irgendwann. Und deswegen
entwickeln im Docker, befreit
einen einfach von diesem Schmerz,
weil das ist relativ klar, was da passieren wird.
Wobei ich ja, also wie gesagt, mit diesem
Windows-Subsystem von Linux und dann einfach
da ein Debian draufhaben oder so, damit kommen
wir ja auch schon relativ weit. Nur was ich jetzt letztens
immer wieder doch häufiger gesehen habe, ist, dass
halt, wenn dann Leute dann eine IDE
verwenden, die dann wieder unter Windows läuft,
dass dann irgendwie in dem Filesystem manchmal Probleme gibt
oder jedenfalls Leute mal so, hä, und dann kommen hier
komische Fehler. Oh, irgendwie ist das, was
da in dem Linux-Filesystem ist, nicht das
gleiche. Das muss man halt konfigurieren. Genau, und die
Pfade werden halt gemountet, also zum Beispiel in
Windows-Gestalt so ein Pfad wie C, Doppelpunkt, Backslash,
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 ein Vinyl-Variable 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.
VSL 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 man zwei VSL drauf,
aber ohne Updates oder so, da kann man es halt nicht
richtig benutzen. Und die Frage ist, warum man
Windows benutzen will, wenn man WSL benutzt.
Also aus der, ich sag mal,
Maschinendeployment-Methode. Also der Grund, warum ich
das in letzter Zeit immer gesehen habe, ist halt,
weil Leute sagen, ja, ja, weil halt
der Rest der Firma quasi in der Windows-Welt
hängt und man mit dem kooperieren können möchte.
Genau, aber so mache ich das bei mir privat auch,
wenn ich Windows benutze, 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 ausräumen will, da macht es
relativ wenig Sinn, wenn ich den Leuten dann WSL freischalte,
weil dann von hinten die nämlich
wieder rauskommen. Und das will ich ja eigentlich gar nicht.
Ja. 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 ist 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 wäre die Frage,
vielleicht ist es dann besser, wenn die nicht auf der lokalen Maschine
arbeiten.
Sondern mit einer IDE
dann irgendwo hinkonnekten
und darauf arbeiten.
Ja, also letztlich...
Und dann fehlt das WLAN aus.
Da kann man nichts mehr machen.
Da weiß man gar nicht mehr, wo die Dokumentation ist.
Irgendwo muss man halt schärmen.
Das fand ich sehr witzig.
Da habe ich letztens einen Podcast
gehört mit einer
der Engineering-Chefin
und ich glaube es ist nicht das CTO,
sondern irgendwas darunter, aber auch
Chefin von 500 Entwicklern bei GitHub.
die meinte, GitHub ist
intern
auf Codespaces umgezogen.
Also quasi komplett
in der Cloud.
Also wie ist Code und Codespace?
Also sozusagen
deren komplette Entwicklungsumgebung sind halt immer
auf irgendeiner Maschine
bei Azure.
Machen sie halt deswegen, weil sie bei Azure nicht zahlen müssen,
weil sie gehören zu Microsoft.
Ja, ist natürlich praktisch.
Es könnte
natürlich ihren Move
dahin ein wenig
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,
ups.
Ja, ich weiß auch nicht, ob das so,
also ich wäre da nicht so
early dabei, das zu adopten,
quasi so rein in der Cloud zu kommen, aber ich kann es,
Also ich kann es in gewisser Weise verstehen, weil man löst damit halt auch dieses Problem, was Docker ansonsten vielleicht dann lösen würde und halt unterschmerzen, weil ehrlich gesagt, Docker Desktop, also gut, ich kann jetzt nur von Mac sprechen, kann sein, dass es unter Windows besser ist, aber auf Mac ist Docker Desktop klein, dieses Docker Desktop ist halt so ein unfassbarer Schrott.
Ja, da wird das auch, ja.
Also wie oft mir das gestorben ist und zwar auf eine Art, dass ich das nicht mehr reparieren konnte.
Ja, der Updates gehen nicht oder so.
Ja, Updates gehen nicht oder, also ich hatte das
mehrfach, dass mir doch jemand gesagt hat,
The Spinery ist kaputt.
So nach dem Update-Versuch.
Ich musste ganz hart einfach das wegschmeißen
und dann nochmal wegschmeißen, aus der
Windows-Registry rauslöschen, also quasi
die ganzen Profiles irgendwo aufsammeln und rausfinden,
wo die sind, wegschmeißen, neu machen,
damit es funktioniert. Furchtbar.
Ja, und langsam und komisch
und ich verstehe nicht so richtig,
warum dieses Ding so...
Und wenn man davon wegkommt,
dadurch, dass man das in der Cloud macht, ja, das könnte man
mir vorstellen, dass es für viele Leute vielleicht durchaus...
Ja, okay. Ja, wahrscheinlich.
Gute Idee.
Da zwingt man die Leute dazu, VS Code zu benutzen.
Ja, also PyCharm bietet das jetzt auch.
Ja.
Dass man in der Cloud arbeiten kann.
In derselben oder sind das dann zwei 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 da so Dev Spaces zusammen hat.
Bist du PyCharm oder VS Code?
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, ja, viele Sachen damit machen.
Okay, ich muss auch so, also ich mag es ja gerne.
Ja, aber also letztlich so dieses vollintegrierte IDE, da ist man ja bei PyCharm einfach, ja, 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, also ich habe jetzt, also Kollege,
wir haben ja mit diesem 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 ausgiebig
verwendet, 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 mir, ah,
vielleicht habe ich was, ob du das
mit VSCode hingekriegt hat, weil ich habe es bisher noch nicht
hingekriegt, bei
auf PyTest Fixtures klicken und dann im Code
der Fixture landen. Das macht PyCharm
einfach so.
Auf die Fixtures? Ja, weil
das ist tatsächlich ein Use Case, den ich häufig habe,
weil VSCode dann so klingelt und ich denke,
klickt das denn jetzt nicht richtig?
Das funktioniert irgendwie nicht. Und dann so, ach nee, VSCode 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 Ganze, also VSCode, Fixtures, 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-Standard auf der Europe-Python, wo die halt meinten so,
oh ja, voll gut und sagt mal, was uns noch fehlt, wir bauen das halt
einfach so einfach ein.
Ja, da ist viel Druck hinterkommt, ja.
Also zum Beispiel auch Azure war halt irgendwie,
Python 3.8 noch, da habe ich auch gedacht, hey Leute, geht noch gar nicht.
Aber da arbeiten sie wohl dran, da ist wohl...
Ja, ja. Aber
Editor Wars.
Ja, wir haben es eigentlich, wir haben irgendwie so was.
Also Wim ist eigentlich auch ganz
gut.
Gut, dass hier niemand E-Mails nimmt.
Hallo, Johann.
Ja, oh,
das ist auch ganz, 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 musste ich das anhören.
Lex Friedman Podcast,
eine der letzten Episoden
ist mit
John Carmack.
Genau.
John Comet, der John Comet, der
von Quake. Ja. Ja, okay.
Genau. Hätte ich so, ah, okay.
Das ist fast fünfeinhalb Stunden
lang, aber
ich hab in letzter Zeit
länger Autofahren.
Ja, und genau, ich dachte so.
Ein Docker-Bild.
Genau.
Das war sehr kurzweilig.
Also seit Quake 1 brauche ich immer die Konsole
auf Tilde.
Ah, ja, ja.
Das war mein Bein.
Ja, und das war
ganz interessant, weil da redete
er auch so ein bisschen über, beteiligte sich an diesem
Editor war so ein bisschen und
der hat dann auch
irgendwann mal versucht Vim zu verwenden, also ich meine
eine Woche irgendwo eingeschlossen versucht
das zu lernen und dann rauszukriegen, 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 meinte, er macht das nicht
so extrem wie andere, andere machen das so was wie
eine uralte, nicht
wie es Code, sondern tatsächlich wie 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 irgendwie C-artiges
C++ oder sowas und macht
halt viel im Debugger und das fand ich, aber ich fand es
interessant, also einfach mal so zu
hören, wie er da so Sachen macht und so
Und der Name ist natürlich ein Guru, ne?
Doom, Quake. Ja, ja, ja, tatsächlich, also ich
genau, die auch, ich, damals
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.
Ich habe es vielleicht mal gespielt, aber ich habe nie Ehrgeiz entwickelt oder mich da lange miteinander...
Oh, kurze Anekdote, ich war damals quasi Clan-Based in der Liga und da waren wir relativ weit oben, also ich glaube European Top 3.
Wow, okay.
Das war ganz gut.
Ja gut, zwei TTF. Ja, TTF hieß damals noch was anderes.
Ja, und genau. Aber was da so im Grafikbereich zum Beispiel bei Qualcomm passiert ist, das war gerade zu der Zeit, wo ich da auch irgendwie so mit Informatik und Grafik, da waren schon einige abgefahrene Sachen dabei.
Da dachte ich so, wow, krass, also das ist ja so irgendwie
so Spieleentwickler, die machen da irgendwie so ein bisschen,
das war schon so echt,
okay, das sind,
die haben da, die machen da echt, also die implementieren
da wirklich so ganz, ganz aktuelle
Forschungsgeschichten direkt
und machen das halt besser als
alle anderen und so. Wahnsinn.
Insofern, ja, also
hat mich schon interessiert, was der, 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, finde ich auch dafür.
Ja, aber das ist halt so, einer meinte so, ja, das ist
halt einer, der hat einfach wahnsinnig viel
gearbeitet. Es gibt auch Leute, die können einfach schnell ertippen, die haben
dann sowas wie 500 oder 600 Anschläge, die Mut.
Ja, ja.
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-Machine-Interface.
Er meinte das auch so, er redet dann so ganz locker
flockig, meinte so, ja, also er hat ja 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 nicht am nächsten Tag
dann irgendwie sich, also
bei mir ist das so, am nächsten Tag reduziert sich dann meine Produktivität
auch deutlich. Also bei mir ist das anders.
Ja, ja, ja. Und er meinte auch, er ist ein bisschen
neidisch auf Leute, die dann halt nur vier Stunden
schlafen müssen und am nächsten Tag wieder topfit sind und das lange durchhalten
können. Und das kann er auch nicht. Sondern er meinte, so nach
zwölf Stunden Programmieren ist halt bei ihm auch irgendwie
Ende. Aber das kann er tatsächlich
sustainable durchhalten. Dann meinte er so, zwölf Stunden am Tag
programmieren kann ich sustainable machen.
Habe ich seit ein paar Jahrzehnten gemacht.
Das geht. Ich kriege dann auch keinen Burnout
oder so. Das geht einfach immer so weiter.
Okay.
Das ist mir ein bisschen zu hart, ehrlich gesagt.
Aber gut. Also schon nachvollziehbar
so, wenn man so richtig Bock hat, dann hört
man auch nicht mehr auf. Ja, aber das kann es ja nicht
länger als zwei, drei Monate durchziehen.
Denn irgendwann brauchst du halt wieder ein bisschen
Luft und...
Ich höre...
Ja,
seine Einstellung war dazu, dass ich diesen ganzen
Quatsch brauche ich nicht. Ich brauche nur Diet Coke und Pizza
und dann reicht es. Genau,
das Sozialleben leidet dann zwar, aber
ich weiß nicht, wenn man sich so richtig
dann zurückzieht und dann... Die adlige Vampirblässe.
Ja.
Erinnert mich so ein bisschen an die Anfangszeiten,
wo ich dann programmiert habe und rausgefunden
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.
Long time ago, Galaxy Far Far Away.
Ja. 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.
Pubertätsende oder sowas.
Auch danach noch.
Bis wann geht das?
Das ist so eine Feedback-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 Beispiel.
Ich hoffe mal, irgendjemand kommt da mal und sagt so, ich mache 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 echt, ich wünsche mir das.
Ich habe am Anfang auch bei den Peißen-Zillern
auch 70 Stunden investiert.
Ja, ja, eben.
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 Zeit,
in der man da ist irgendwie.
Und wenn man irgendwie jetzt 5 Stunden die Woche was macht
oder 70 Stunden die Woche
und dann macht man das 2 Jahre lang
und man ist genauso gut,
dann ist derjenige im Verhältnis zu demjenigen,
der es 5 Stunden die Woche macht,
einfach um 28 Jahre weiter.
Ja, ich glaube, man kann es nicht so naiv rechnen.
Ja, also, natürlich,
aber der Punkt ist ja, glaube ich,
relativ klar. Also, man kann das im Leben
nicht aufholen, wenn man das
versucht,
so nebenbei.
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 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 wir hatten 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 gegenzuhauen, bis es kaputt geht.
Ja, genau.
Wo du sagst, das ist Quatsch.
Also lieber weggehen und unter der Dusche fährt es 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 es 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 dahin kommt, wo man gegenhauen muss zum Beispiel.
Und wenn man das halt dann nur
die Einflusslösung hat, dann hat man diese ganzen Schläge von der
Seite oder sowas verpasst.
Also ich fand das schon immer super. Ja, kann sein. Vielleicht sind auch
unterschiedliche Leute einfach unterschiedlicher.
Oder es sind unterschiedliche Themen oder sowas, wo das halt hilft oder nicht hilft.
Ich weiß nicht. 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 es irgendwo nicht weitergeht,
dann mache ich halt was anderes und
dann bis da dann nichts mehr weitergeht
und dann wieder was anderes und
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ß es eigentlich keine Ahnung.
Ja, seltsam. Ja, irgendwie
der heilige Gral an der Stelle noch nicht gefunden.
Schade, schade.
Wir sind übrigens in der Ente-Befolge.
Ja, genau, genau, Ansible.
Ja.
Also ich habe hier noch so ein paar Sachen stehen, und zwar,
also einmal, was macht man mit den Outputs, wo bekommt man die her,
wie sammelt man die ein, das ist so ein bisschen technisch schlecht,
testen, würde ich gerne noch mal drüber sprechen,
wie macht man das, braucht man das?
Ja, vielleicht die ganzen Commandos, Buildings,
was gibt es denn überhaupt so, was kann man denn damit machen,
dass man so ein bisschen mal vielleicht weiß, was ist denn schon drin,
wofür muss man denn so Community-Module nehmen oder so.
Und
wie machen wir das mit so Secrets oder so,
wo staut man die, wie staut 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 der nächsten Chapter-Mark.
Hint, hint.
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, ja man hat jetzt
keine Ahnung, seine Datenbank
exposed und wusste vorher noch nicht, welche Server-IP
gab es denn da und die muss dann
der Server drückschicken 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 dann irgendwo hinschicken.
Man kann die natürlich dann auch in eine Datei schreiben
oder so. Ja, die Frage ist genau das.
Man muss die vielleicht auf der Control-Note irgendwo ablegen,
weil vielleicht braucht man die beim nächsten Run
beispielsweise zu
ähm
wie klicke ich das? Also man möchte jetzt
sowas machen wie Updates
und man hat jetzt nicht den Luxus,
dass man einfach sagen kann, okay, ich reiße den jetzt ab und baue
den 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,
wenn man einen Test fahren muss, weil 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.
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.
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 ABT und da kann ich dann halt sagen, welchen State soll das Paket haben.
Nein, beispielsweise ich habe eine Software, die ich selber geschrieben habe, dann muss ich mir die Version zu mal merken, weil jetzt nicht über App kommt, sondern beispielsweise über ein GitHub-Report oder ein GitHub-Tag oder sowas.
Ja, da kann ich natürlich dann
sagen, okay, welches Tag möchte ich denn überhaupt
auschecken? Oder möchte ich einfach die
Latest auschecken? Dann habe ich halt immer die Latest,
egal. 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 sicher
zu stellen, dass ich das testen kann, um dann die Latest
auf Produktion auszurollen. Dann 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 kompliziert, also
ich weiß nicht, ob es das Problem löst, aber
willst du wirklich
deine Ansible-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
Applikationen 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.
Da wäre letztlich so die Frage,
wie funktioniert
mein Update-Mechanismus?
Also warum willst du
das auf Produktion testen und nicht lokal?
Ja, weil
vielleicht die Infrastruktur kaputt geht beim
Bauen oder sowas. Wenn ich Änderungen 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,
wenn da irgendwie bei der Netzwerkkonfiguration
irgendwas kaputt geht. Also quasi, ja,
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 eine 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 welche 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 genau, aber diese Facts muss ich ja irgendwie dann zwischenspeichern, weil das ist ja ein alter Fact quasi gewesen.
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 das 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,
dann müsste ich wirklich mein Playbook ändern.
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 der, ah, gibt's
was Neues? Okay, ich soll
Latest nehmen, also update ich die Version.
Und ob dann was kaputt geht,
ist dem Ansible erstmal egal.
Genau, und das ist das, was ich meine.
Dafür müsste man
dich diese Facts, was war denn jetzt
Latest, irgendwie rausschreiben, also diesen State.
Muss man sich irgendwie merken, um den
reproduzierbar zu haben, also nach dem Motto,
baue 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,
wofür du das machen willst
und dass man das, aber
ich habe auch schon gehört, dass Leute eben,
wenn man, das ist ja alles irgendwie auch
so Infrastructure-as-a-Code
ja, Infrastructure-as-a-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?
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
Script oder mein Ansible Playbook
bearbeiten, dann wüsste ich das und dann würde ich
halt,
wahrscheinlich ist ja im Git eingecheckt und dann sagen,
okay, 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, so und so viel
von meinem Projekt installiert und ich
möchte es auf meinem Staging-System testen können
oder das muss ja gar nicht das Staging-System sein,
sondern ich ziehe automatisch mit
Terraform irgendwie mir 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. Genau. Das ist aber im Grunde
ein Test deines
Systems. Genau, das würde man
ja dann einfach machen und gucken, ob es geht.
Ja.
Das Problem ist halt, wenn du das Update halt auf dem Produktionssystem
fährst und es funktioniert nicht, dann ist es halt blöd. Genau,
deswegen Staging.
Ja, oder. Genau, und die muss halt dann
so gerade. 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 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. Also mir fällt vielleicht, weißt du, wie es geht?
Ich würde versuchen, das zu vermeiden, weil...
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 deine
Serverinfrastruktur funktioniert. Ja, wenn meine Serverinfrastruktur
kaputt geht, dann weiß ich, habe ich einen neuen Test
für meine Applikation. Aber ist das nicht genau der Sinn der
Staging-Umgebung, um dann einmal das zu machen?
Aber die ist ja in einem anderen Zustand.
Genau, das ist, was ich meine.
Die Frage ist halt, du musst halt diese Staging-Umgebung
auf diesen zwei Ebenen bauen,
damit du quasi dieses Update simulieren kannst.
Weil wenn du 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, wie gesagt, was ich gehört habe,
ist halt, dass Leute halt auch Tests eben gegen so,
die ziehen dann sogar temporär Infrastruktur 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
Ansible ist halt schon, also bei mir,
vielleicht mache ich irgendwas ganz falsch, langsam.
Also das dauert Minuten. Also die ICD macht es langsam,
also es dauert eher länger als, eher Stunden.
Ja, das ist ja schrecklich, also wenn du
halt sozusagen so einen 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
einen deutlich langsamer macht, ja. Und wenn da Stunden
dazwischen liegen, dann wird es ruhig. Aber genau, also so ein
Deployment auf Azure, also ich weiß nicht, da kommen irgendwelche
Ameisen und hängen Redis irgendwie
allein selbstständig manuell ans
Rack und musst 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 Asia
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ß
ich weiß natürlich nicht, ob das immer geht, aber ich würde
sagen, man schiebt die Tests in die
Applikationen. 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, oh mein Gott, das ist einer
der Gründe, warum ich ganz viel zu diesem
Fileswerving auch gemacht habe.
Also das ist auch bei dem jetzigen
Python-Podcast ist es so, die Files kommen von
S3 und
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.
Oder Django.
Ja, das Problem, Django kann sich ja nicht darum 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,
Wenn es über S3 geht,
da ist ja kein...
Das ist sogar so, es ist S3, aber das S3
ist sozusagen nur das Backend für
CloudFront, für so ein CDN.
Und
jetzt ist halt die Frage, okay,
wenn das über ein CDN geht, das geht ja nicht über
dein Nginx, sondern das geht ja außenrum.
So, jetzt kannst du...
Du kannst die URLs so
generieren, dass die halt signiert sind, zum Beispiel.
Und dann kannst du dem S3
beziehungsweise CloudFront oder wie auch immer sagen,
ah, die URL muss aber signiert sein.
die Signaturen sind nur für so und so lange gültig.
Oder du musst halt irgendwie Cookies setzen. Es gibt ja diverse
Möglichkeiten, wie man sich authentifizieren kann. Genau.
Aber das Problem ist jetzt natürlich, wenn du darauf angewiesen bist,
dass das wirklich funktioniert, musst du das ja
eigentlich testen. Musst du ja sagen, okay, wenn
jetzt jemand hier im Django-Admin
gesagt hat, da darf keiner, da dürfen
nur Authentifizierte drauf zugreifen, dann muss man
diese Logik irgendwie testen können. Aber wenn
die tatsächliche Überprüfung irgendwie
in Cloud
Front stattfindet, dann
kannst du das nicht mehr gut testen, ohne
dass du tatsächlich irgendwie das nach Cloud
schon hochschiebst, irgendwie deine Einstellung machst
und dann musst du... Du musst jetzt natürlich dann einen Mock
dafür machen. Ja, aber das ist ja
verkehrt, dann erbst du die Fehler ja
damit. Jetzt kommt der Punkt, warum dann Leute
einfach... Also genau
das gleiche Szenario quasi, wenn Leute
sagen 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
Byte-Range-Requests
irgendwie erlaubt. Das muss man irgendwie bei AWS
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 so,
was ist das denn? Das habe ich ja noch nie gehört.
Was sind denn Byte-Range-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
Byte-Range-Requests nicht mehr gehen und
ja, also wie zum Beispiel bei Podcasts
oder Podcast-Player holen sich immer nur Teile,
wenn das Teil-Format
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, also
der Features deiner Applikation
sozusagen darin bestehen, dass du
dein
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 im CDN liegen, halt testen
und dann kannst du erst sagen, wenn das alles funktioniert,
okay, es funktioniert. Das war gerade ein Plädoyer für das,
was ich gerade eben gesagt habe.
Für mich hört sich das an, oh mein Gott, das will man auf gar
keinen Fall machen. Für mich klingt das nach
ein Plädoyer, ich surfe meine
Files selber, ich mache das nicht bei dem CDR.
Aber erst als Beispiel.
Dann kann ich es in der Applikation testen.
Aber du müsstest deine Byte-Requests jetzt tatsächlich testen mit AWS.
Nee, muss ich nicht.
Du hast jetzt bei AWS, also 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 mit meinem Update vielleicht.
Naja, du musst dann halt
dann, es ist halt furchtbar.
Okay, wie würdest du es denn machen?
Also 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 surf 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 service halt direkt.
Okay, aber das ist dann eine Entscheidung, die an deine Stelle
kommen muss. Das macht dich
an mehreren Stellen vielleicht unbeweglich.
Ja, also
solange das funktioniert, bin ich damit deutlich flexibel.
Ja, 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 Tests 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.
Also ich sag mal, bei Kundendaten, die du nicht einfach
mal so neu reinbauen kannst, dann sollte man
das vielleicht in Erwärmung ziehen.
Genau, und dann muss man halt
gucken, was ist das
Richtige.
Und vielleicht
kann man dann auch überlegen, okay, ich habe jetzt
in dem Bereich nichts gemacht, da reicht so die
normale, die normalen Tests.
Ja.
Ja, ja, also
Ja, okay.
Testing haben wir ja.
Okay, aber jetzt vielleicht nochmal.
Molekül gibt es bei Enzebel
oder Assertions?
Achso, ich meinte nur, ich schreibe keine Tests
für die Enzebel-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 Enzebel-Sachen ist, ich mache Assertions
am Anfang, so ein paar.
Einfach die dann halt mir um die Ohren fliegen, dann weiß ich relativ schnell,
funktioniert das 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, also
geht ja ganz am Anfang los mit einer Debug-Flag
und sich da einfach mal 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
die am Ende
die Konfiguration hat, die ich haben möchte.
Interessant. Okay, mit Vagrant testen?
Okay, was ist mit Molecule?
Kennt ihr das?
Ist auch so Endable-Molecule-Testing
da kann man sowieso Testmodule schreiben, die man dann irgendwie
reinsetzt in seinen
ja, wenn man das so selber
Endable-Module schreibt, dann kann man das irgendwie machen
müssen wir vielleicht nochmal nachgucken
Genau, so 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
Ansible. Also Ansible Build-in 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 Befehlszahlen
ausgibt. Da könnte man ja selber
sich ein Ansible-Modul für schreiben, in Python,
was dann quasi ein Abstraktionslayer
drüber schreibt, wo man dann ein
eigenes Ansible-Modul,
ob man das in Galaxy hochlegt, wie auch immer,
benutzt, um dann zu sagen,
hey, wir hatten 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 hat tatsächlich dann direkt
das, was man ausführen kann. Genau.
Und ja, dann wird 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 noch ein bisschen
das Assoziationsniveau, kann man halt manchmal, wenn
wirklich mal ein komplexes Sachmal, 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 weg abstrahiert vielleicht.
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. Vielleicht hätten wir es mit der
Teamgröße zu tun, also wie viele Anwender von deinem
Endebim-Modul gibt es zum Beispiel intern,
um was zu machen, und wie viele Leuten kannst du da
Arbeit erleichtern oder sowas.
Ja, dann
Und 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 sich authentifiziert? Wie macht man das? Schreibt man Secrets mit in irgendwelche Repos rein? In Source Control? Ist das eine schlechte Idee? Also man kann 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 Unsable World 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, dann kann ich das 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üsselt 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, unter welchen Umständen sollte ich Geheimnisse in meine Repos einchecken?
Genau, das ist ja spannend. Also 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-Info 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 rein schieben. Dann muss man halt aufpassen, dass es irgendwo
wo nicht in irgendwelchen Logs 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.
Die Vermittlung zwischendrin muss halt auch stabil sein und so.
Ja gut, die sind ja da
SSR relativ abgehangen.
Das ist wahrscheinlich nicht
das Problem, aber ja, also
ich meine, die Secrets sind halt auf der Maschine
unter der... Ich meine, das Schlimmste...
Es gibt ja diese 12-Factor-App
Geschichte, wie man halt, also das
ist halt eigentlich die Art, wie
Heroku irgendwie Dinge deployed hat
irgendwie mal und die haben das halt so aufgeschrieben und das dann so genannt
und da ist ja eine
der Geschichten so für Secrets oder so
Umgebungsvariablen zu verwenden.
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 da mit Angreifern aber auch extrem
einfach, ja, 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 AWS-Keys und so
irgendwo hingeschickt und das ist halt schon, das ist halt das Erste,
was ein Eingreifer macht. Ja, wenn man bei GitHub danach sucht,
da gibt es dann einige,
die, ja,
gesquattete Vapors,
die genau das machen, also die quasi
den Quellcode nehmen und halt
wenn man sich vertippt hat,
dann 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
und nicht, aber
in Projekten, wo ich Pydentic habe,
mache ich das meistens mit Base-Settings oder so, wo es
dann halt aus einem File gelesen wird und man das halt
wissen muss und man importieren muss und das ist halt schon mal
so ein automatisierter Angriff, ein Angriff
funktioniert da schon. Und dann diese Base-Settings werden in
Environment-Variablen geschrieben.
Nee, eben, genau.
Ist es bei der IT-Security immer das
Thema, was ist denn mein Angriffsszenario,
wenn ich jetzt
sage, okay, ich bin eh in einem privaten
Repo und
wenn jemand dann Zugriff auf
mein privates Report, was auf mein CI läuft
und alles, also sagen wir, ich habe ein privates
GitLab und da ist jemand drin,
ja, dann ist es egal.
Oder
wenn ich sage, okay, aber
es ist ja dann im Rahmen.
Wenn jemand jetzt meine Umgebungsvariablen auslesen kann,
dann auch schon wieder
ein Problem.
Das ist, 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 klappen kann.
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
in so eine Terraform irgendwie rein,
da kommen das halt aus Secrets und das ist halt irgendwie gekapselt,
sondern ich musste es nochmal über einen Umweg
in einen 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 Invasion 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.
Ja, ist natürlich dann die Frage, was hat man
damit gewonnen? Also nix. Okay,
vielleicht kann ich noch in der Vault dann steuern,
wer Zugriff drauf hat, dass dann
alle sagen, okay, jetzt hat niemand mehr Zugriff drauf
und dann... Ja, das war der Plan, aber das Problem
ist halt, wenn die Sachen dann sowieso wieder auf dieser Web
erplanten, dann ist halt... Dann haben alle Zugriff drauf.
Ja, Zugriff haben, ja. Dann hat das
so wenig Sinn gemacht, weil dann quasi noch mehr
Angriffsszenarien dann irgendwo dazwischen liegen konnten.
Genau, also man muss halt vorher überlegen,
wogegen möchte ich mich denn wappnen?
Oder vielleicht nicht verstanden haben, was man überhaupt tut,
bevor man irgendwie die Regeln entforstet, die statisch
irgendwie in den Passring. Ja, aber das
steht so in der Policy, das machen wir so.
Ja, genau, das ist ETIL. Irgendwer hat
einen ETIL-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 auch da verbessern könnte, weil Mutant ist halt
das Problem, okay, wie verhält man denn die,
das Passwort oder
das Brotpasswort, das man dafür braucht halt
und ja gut.
Ja, man braucht halt irgendeinen vertrauenswürdigen
Kanal, über den man das übermitteln kann.
Ich glaube, man kann auch irgendwie Dinge mit GPG machen.
Also ich würde sowas versuchen, wie
YubiKeys zu verschicken.
Also wo dann halt die Keys drauf sind,
die das funktionieren und dann vielleicht geht das.
Die sind halt auch nicht kopiersicher oder sowas.
Ja, die YubiKeys, ja genau, die könnte man
natürlich dann über den SSH-Agent
und dann könnte man
GPG machen und dann könnte
man das wieder entschlüsseln.
Ja, aber
also mein idealer
Workflow sozusagen, ich kann es momentan nur so
beschreiben, wie ich es gerne hätte, aber ich weiß noch nicht genau, wie man
es implementiert, ist halt sozusagen, dass ich sage, wenn ich
jetzt halt irgendwas deployen will oder möchte an die Secrets,
dass mich das
Ansible halt dann, dass ich mich irgendwie bei Ansible
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 Kombination cool. Auf dem Telefon geht auch
halt mal bitte an das Telefon in YubiKey.
Ja, irgendwie sowas. Irgendwie so, ne? Weil der hat ja dann irgendwie
NFC oder Bluetooth oder irgendwas.
Ja, da könnte man dann auch gleich überlegen, ja,
mache ich das vielleicht auf der Ebene von
SSH, dass ich den 2-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 ein Artikel in seinen Weak News.
Ja, ja.
Ja, aber genau,
aber das ist halt die Frage, wem musst du vertrauen?
an 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 du jedes Mal irgendwie
einen Antrag stellen musst und in drei Tagen warten musst,
das ist natürlich totaler Quatsch.
Ja, oder?
Ja, an irgendeiner Stelle muss ich halt
Leuten vertrauen und ich muss halt dann die
Abwägung treffen, 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 da sowas gibt.
Ja, also die YubiKeys,
ja, die soll, also
an sich, diese ganzen Hardware-Schlüssel
sind kopiergeschützt.
Ja, also, ne, dann könnte man
Wenn halt einer rausfindet, wie es geht.
Ja, ja.
Wenn ich halt jemanden dann sage, okay, wir treffen uns, oder ich schicke
ihn per Post, dann kann er auch kompromittieren, aber
man gibt den,
der fängt dann an, ne, wer hat da den physischen Zugriff auf,
diese ganzen Sachen. Aber dann, wenn man den halt dann
abgeben kann, dann ist das schon relativ
sicher, okay, dass sich jetzt in meiner Chain dann
nur die Leute auch dann beziehen 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
Root Authority, die ist dann
die gehört einem dann.
Ja, genau. Also geht ja auch
relativ fix, so eine CA aufzustellen.
Die sicher zu halten, ist wieder schwierig.
Ja, das ist auch so super. Wir haben auch so eine Root CA, die
sich selbst definiert hat und die dann die ganzen
Zertifikate mit raus hat. Ich dachte, warum macht der denn
den Scheiß drauf?
Ja.
Ja, ja, das ist Security auch sehr, sehr, sehr schwieriges Thema.
Ja, man kriegt es nicht absolut sicher hin und man, also es ist wirklich, man muss sich die Risiken vor Augen führen und sagen, dieses Risiko gehe ich jetzt ein.
Ja, man braucht halt irgendwie eine unabhängige Autorität, der man vertrauen kann.
TÜV geprüft, ne?
Ja.
Man müsste irgendwo so ein Denkmal machen, in dem Denkmal steht dieser ursprüngliche Schlüssel drin und der ist dann noch, ne?
Ja, es ist schwierig.
Einen spannenden Aspekt, den wir noch nicht so beleuchtet haben,
also wir haben ja auch viel über Docker gesprochen
und dass es vielleicht auch Ansible verdrängt,
aber was Ansible jetzt viel macht,
ist in die Network Automation reinzugehen.
Das heißt, 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, UniPi, Nokia, die lassen sich jetzt über Ansible ansprechen. Und ja, wer schon mal so eine Cisco-Konsole bedient hat.
Ja, das will man automatisiert wegschieben über seine eigene Shell, wo man sagt, ich habe hier ein Skript, wir rennen mal.
Genau, so Ansible definiert mir hier jetzt mal, welche IP-Adressen wohin und welche VLAN es gibt.
Ja, das ist super.
Das ist schöner, als das alles mit der Hand einmal einzupippen.
Das kann man dann auch wieder schön testen eigentlich.
Dann weiß man halt, okay, stabil. Dann kann man auf jeden Fall Use Cases finden, wenn es nicht stabil ist, okay, dann mach es mal anders.
Also dieses Ganze, ich muss jetzt immer manuell
dran rumfummeln bis es stimmt und mach am hundertsten
Mal. Das sollte man nicht machen.
Ja, also klar, das ist
das ist natürlich,
davon muss man irgendwie weg.
Also ich finde, also prinzipiell,
dass das halt alles in einem 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.
Aber gut,
bei Testen wäre ich mir jetzt, also 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 gleiche
Ziel zu erreichen. Ja, du musst halt wie bei Ronny
machen, sobald die Coverage bei deinem
Commit runtergeht oder bei deinem Pull-Request
wird er direkt mal denied.
Ja, genau.
Ja.
Ja, ja.
Ich weiß nicht. Ach so, genau.
Ich wollte irgendwas sagen.
Ja genau, Dinge, die mir noch so, die ich noch gerne loswerden würde, 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 finde ich manchmal ganz praktisch.
Also auf einer Maschine oder auf den anderen?
Für Tasks zum Beispiel.
Aber die Tasks laufen dann auf einer Maschine parallel in verschiedenen Prozessen?
Ja, ja, du kannst, ja, oder auf einer Maschine.
Die müssen ja voneinander abhängig sein.
Ja genau, das wollte ich gerade fragen.
Ja, klar. Also du hast eine Parallelität über
unterschiedliche Maschinen, nicht nur auf einer.
Ja, genau.
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 Waitpoints 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 Info-Schoko hat ja so hässliche
sequenzielle Probleme, wo manche Sachen vorher fertig sein müssen,
dann die und die. Ja, aber
das geht alles. Also du kannst ja auch so Rolling-Updates
machen, wo du Sachen aus dem Notbalance rausnimmst
und dann irgendwie reinnimmst oder
ganz aufhörst, wenn mehr als 10%
deiner
Geschichten nicht funktioniert haben und
das geht ja alles. Also das kannst du ja
schon. Das sind Sachen, die sind so nervig, manchmal
gerade Infrastruktur, erste Service aufbauen
und dann zwischendurch hast du so Fehler, die
unvorhersehbar sind, weil irgendwelche Netzwerkprobleme
sind oder irgendein Nameserver gerade nicht reagiert hat
oder sowas und 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, da kannst du auch
so ein Retrys mitgeben. Ja.
Aber, ja,
man läuft halt dann halt
wirklich in diese unschönen Probleme rein
und es wird auch nicht schöner.
Ach so,
jetzt richtig, jetzt weiß ich wieder, was ich sagen wollte.
Genau, also einer
der Gründe, warum ich meine ganzen Incivil
Geschichten, die meisten davon nicht eingecheckt
habe, also manche davon schon, aber die
meisten nicht, ist halt, dass ich, also
man kann bei Ansible auch sagen,
das habe ich halt noch nicht gemacht, aber
solche vielleicht, die Inventories
kann man halt auch auf Server legen oder so, dass es
halt nicht aus dem Textfile kommt, sondern irgendwo
und momentan bei mir kommen sie meistens aus dem Textfile
und das heißt, wenn ich mein Inventory wieder einchecke, dann
checke ich meine gesamte Infrastruktur mit ein und das will ich
echt 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. Dynamisches Anbauen, ne?
Ja, du musst halt dazwischen, wie nennen wir das, Jump-Hose
bauen, die dann irgendwie bestimmte Sachen vorbereiten
und ausführen und dann da
so eine Art Statebarheit haben.
Ich kann einfach gegen den Hetzner DNS zum Beispiel
fragen, so, wie sieht's hier aus?
Und dann gibt er mir das als
Inventory.
Ja, okay.
Also, da gibt's verschiedene
Plugins, AWS, Docker, Kubernetes,
Proxmox
und noch viele mehr.
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 wäre. Nur halt
so ein bisschen als Community-Projekt.
Okay, vielleicht
auch mal reinhören.
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
Ansible so auf der Kommandozelle ausführt.
Aber man kann halt
Ansible auch sagen, hier ist
dein Callback-Command
irgendwie. Und dann
kann man selber zum Beispiel eine Funktion schreiben,
in die die Ausgaben von Ansible 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 es läuft,
irgendwie direkt auf einer Webseite
anzeigen, was man sieht. Okay, dann weißt du halt,
wie der State gerade ist und wo ist denn das gerade und
wie klein ist denn das und ja, okay.
Und vor allen Dingen habe ich an der
Stelle auch eine sehr schöne
Abstraktion, wo ich das auftrennen kann,
weil ich verwende jetzt meistens zwar
Ansible, aber es könnte auch Situationen
geben, wo ich nicht Ansible verwenden will, sondern
wo ich direkt SSH
verwenden will oder ein Skript
einfach nur, oder ein Python-Skript oder
was ganz anderes. Ich will Ansible
durch was anderes ersetzen. Es gibt ja auch so, ich meine,
bei den
Boxcene, die verwenden ja, die hatten
Ansible lange Zeit,
sind dann auf was anderes umgestiegen.
Weißt du was?
Weißt du auf was? Ne, ich hab's wieder vergessen.
Ich wusste es mal. Okay, der Jens hat
irgendwas eigenes gebaut. Ne, ne, aber
ja, oder er hat was eigenes, ich weiß es nicht mehr genau.
Jedenfalls,
genau, also vielleicht will ich ja auf irgendwas
anderes umsteigen, aber ich kann ja diesen
Jason-Layer halt
sozusagen erhalten.
Dann muss ich an meinem quasi
Deployment-Überwachungstool
muss ich überhaupt nichts mehr ändern,
das läuft einfach so weiter und ich habe unten drunter
kann ich das Ansible austauschen und
das finde ich ganz nett, dass man das weiß, dass das geht,
dass man nicht irgendwie Ansible Tower oder so
verwenden muss, weil das ist ja auch sowas.
Was ist Ansible Tower?
Ah ja, gut, stimmt, das müssen wir noch mal.
Das wäre ich auch noch zugekommen.
Ja, also
diese ganzen Probleme, die Ansible 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, man müsste quasi irgendwas online halten die ganze Zeit,
was dann Sachen... Genau, und das wäre
genau Ansible 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 jetzt
mit der Enterprise-Variante. Ja, ja. Genau.
Und die Enterprise-Preise
werden auch nicht angezeigt auf der Webseite.
Das heißt, es ist auch...
Oder theoretisch könnte man sich auch eigentlich
so einen eigenen Server per Enzel konfigurieren,
der dann Cronjobs laufen lässt.
Genau, also Enzible Tower an sich,
wenn es gehostet laufen lässt, ist auch teuer.
Es gibt, kann es auch selber aufsetzen.
Aber ja, habe ich bisher noch nie geschafft.
Komischerweise ist es auch ein Docker-Container
und kein Enzible-Playbook.
Hätte ich jetzt eher erwartet, so Dogfood.
Aber warum macht man dann nicht so was wie einfach Cronjobs
auf einem Dask-Gear-Metal?
Genau.
Ja, kannst du machen, aber es ist natürlich auch...
Der Ansible Tower gibt dir natürlich noch eine schöne
Web-Oberfläche, die dann dir die Logs einfängt
und alles sagt.
Kann man ja auch alles selber bauen, irgendwie so ein Grafana-Promis.
Ja, alles selber
bauen ist natürlich auch immer eine gute
Zeitsenke. Ja, ich hab's
getan und ja, es war dann sehr...
Ich konnte da quasi beliebig viel Zeit
drin versenken, das war gar kein Problem.
Ja, das war 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 kommt mir irgendwie bekannt vor.
Ja, genau das mache ich halt auch.
Genau, und wir können mal gucken, ob ich das
hier, ist das gerade,
das ist natürlich das Sobe im
Ja, aber ich habe auch, bei mir heißt das
Steward. Ich habe mir überlegt, ich muss die ganze Nacht
eher nach Schiffen nennen. Die Server heißen alle nach
Planeten und die Dinge ein Steward
Lieutenant oder so, je nachdem.
Ja, genau.
Also es gibt auch die Möglichkeit,
die Server einfach nach dem zu benennen, was sie tun,
dann ist es für alle sofort klar.
Ja, also was heißt denn für alle?
Das muss ja hinreichend
geheim und...
Ja, aber ich habe im Grunde so was wie
ein Tower. Das macht nicht das, was Tower macht,
sondern noch ein bisschen mehr und andere Dinge, aber
es ist halt tatsächlich sehr ähnlich.
Jochen kann richtig gut User-Interfaces.
Nee, gar nicht. Das sieht man hier auch.
Aber das macht halt genau so was.
Also das kann halt eben
diese Dinge, das dann halt direkt live
einzeigen, was da halt passiert. Und was ich halt
damit auch machen kann, ich kann halt
sozusagen, ich habe Playbooks, die deployen halt,
also wenn ich jetzt zum Beispiel Hosting machen will
für andere Leute, dann kann ich
denen sagen, okay, nimm halt dieses Playbook und
setz halt die Domain auf das und
die Datenbank auf das.
Man könnte natürlich auch Variablen dann
mitgeben, die abgefragt werden.
Ja, genau.
Das ist schön, ja.
Ja, und da es ja alles Python ist,
integriert sich das ja auch alles sehr schön
dann wieder mit Django und man kann quasi aus dem Django
raus direkt dann das Ansible aufrufen.
Ja, das habe ich jetzt nicht
gemacht, sondern ich habe hier,
weil ich dachte, für diese Geschichte habe ich nicht Django
verwendet, sondern irgendwie Fast
API, weil
damit halt
alles schön async ist, weil das Problem ist, dass ich jetzt
viele Deployments laufen habe, die laufen alle
async, aber die laufen lange und
da kommen immer mal wieder so Events und
dann habe ich halt Clients, die drauf sind und dann, ich habe das,
das würde ich heute nicht mehr machen, ich habe das
jetzt, hier habe ich das mit WebSockets gemacht und
mit Vue. Ich würde dafür
heutzutage, jetzt inzwischen würde ich dafür
tatsächlich HTMX nehmen, aber
ja,
ja genau,
ich habe ganz viele langlaufende Sachen,
die parallel, wo Dinge so, dann nehme ich
doch irgendwie nativ Async alles.
Ja, hat
viel mehr Zeit gekostet, als ich jetzt
gedacht hätte.
Kurzer Exkurs, ja, also
da geht das ja alles schon bei
bei SQL Alchemy
jetzt in der aktuellsten Version Async,
ich habe Async PG verwendet und
SQL Alchemy und Django ist an der
Stelle deutlich bequemer, also da funktioniert
einfach alles so. Bei SQL Alchemy
ist es mächtiger, es
macht die ganzen Sachen in Anführungsstrichen
richtig, aber es ist halt auch echt
ziemlich, also ich finde es ziemlich scharfkantig
das zu verwenden und ich bin da in
viele üble Sachen reingelaufen, also auch
so richtig fiese, also ich meine, gut,
es ist halt ganz neu, ja, also ich kann das noch
nicht so lange, aber ich habe da schon
sehr üble Tracebacks
irgendwie aus den Internas von SQL Alchemy gesehen,
wo ich mir dachte, so häufig
solche Sachen wie
an diese Stelle solltest du niemals kommen,
irgendwie hier versuchen gerade zwei,
eine Connection wird von zwei unterschiedlichen
Routinen irgendwie benutzt oder so,
dass hier ist irgendwas furchtbar schiefgelaufen,
tschüss.
Und das ist irgendwie häufig passiert, ja,
und überhaupt dieser ganze Tanz,
also man hat ja bei SQL Alchemy hat man eine Engine
und dann hat man, auf der Engine hat man eine Connection.
Und diese Connection braucht man halt,
die ist in einem Connection-Pool. Und dann gibt es halt
eine Session, die hat den Connection-Pool. Ah, die Session muss man
auch aufmachen. Und dann auf dieser Session hat man halt
irgendwie noch Transaktionen. Also diese Transaktionen können dann
natürlich nochmal genestet sein. Und all diese Dinge, die man da
aufgemacht hat, die muss man ja auch irgendwie wieder zumachen.
Und wenn man irgendwo was vergisst, also manche
von den Funktionen, mit denen man die auf- oder zumacht,
sind halt synchron. Manche sind asynchron.
Das ist natürlich ganz schlecht, wenn man jetzt
irgendwie ein Ding, was man eigentlich asynchron
erwarten sollte, halt einfach so zumacht.
Dann passiert auch ganz, dann bleibt plötzlich
so, es funktioniert alles und irgendwann bleiben plötzlich
Dinge hängen oder werden langsam und irgendwas
wird komisch, irgendwas funktioniert nicht mehr so richtig
und dann kann man halt irgendwie so wirklich
viel Zeit damit verbringen, rauszukriegen, was läuft denn da
eigentlich schief und das ist echt, also
das ist einfach ätzend
und was mich auch irgendwie
so ein bisschen geärgert hat schon,
ist halt, dass das alles inkonsistent ist,
also einmal ist Sync also inkonsistent
und dann Engine aufmachen,
Engine zumachen ist dann halt Engine Dispose,
Connection ist aber Connection
Close, Session ist wieder auch
Session Close, glaube ich, und dann, aber es
ist halt immer unterschiedlich, ja.
Man muss halt so einen kompletten Tanz da irgendwie
machen, wie das war, wenn man das aufmacht und
wieder zumacht und
an welcher Stelle macht man jetzt was und was ist
irgendwie, darf global im Prozess leben und
was muss man aber irgendwie für jeden
Request da reinkommen, neu machen, das ist kein Spaß.
Also ich hab, manchmal dachte
ich mir so, ich probiere jetzt einfach alle Möglichkeiten, wie man
Dinge auf und zu machen kann, irgendwie durch
und versuche irgendwie zu testen, ob das dann noch funktioniert
oder nicht.
Kurzes Plädoyer für Django.
Ja gut, bei Django geht das halt noch gar nicht,
was ich da jetzt gemacht habe.
kann man nicht sagen, nimmt einfach Django,
dann habt ihr das Problem nicht, sondern dann habt ihr auch die Lösung nicht.
Insofern, aber es war
schon, also das war, also es hat mich schon
so ein bisschen, also es war, ich fand es
schwierig. Ja, es funktioniert
jetzt halbwegs häufig, aber
Ich mach jetzt einfach
tatsächlich alles pro Request.
Wie dann einfach die Konfidenz abnimmt.
Ich muss mich länger mal drüber nachdenken.
Ja.
Ja, ja, ja, aber ja.
Also ich würde fast sagen, das war das Schlusswort zu der
Ansible-Folge, es sei denn, du hast noch was, Max,
was wir vergessen haben.
Nur so noch ein paar allgemeine
Sachen. Also sich den ersten Commit von Ansible
anzusehen, ist auch sehr schön.
Weil da ist es noch
sehr einfach und man sieht, okay,
Ansible macht halt wirklich
nur eine SSH auf
und gibt den Command weiter.
Und da versteht man noch wirklich viel,
was dann später
nicht mehr der Fall ist.
Also wenn man
sich so grundsätzlich interessiert, okay,
Wie funktioniert das?
Dann ist das ein wirklich schöner Commit, der erste.
Okay, cool.
Danke für den Tipp, muss ich unbedingt mal machen.
Wenn wir auch in den Show-Notes direkt linken, würde ich sagen.
Ja, genau.
Ja, gab es noch was zu Ansible?
Ansonsten können wir auch Pics machen.
Ich würde mit den Pics gerne anfangen.
Okay.
Und zwar habe ich auch eben was vergessen bei den Europython,
was ich noch mitnehmen wollte.
Und zwar das Ibis-Project.
Kennt das von euch jemand?
Oh ja, das habe ich.
Das ist sehr hübsch.
das ist geschrieben von West McKinney
auch, die neue
Company. Das ist
so ein Abstraktionsinterface auf, ich würde sagen,
also Art von SQL, in dem man halt so Datenmager
Fragen machen kann, auf
Pandas funktioniert das, das funktioniert
auf Apache Impala, auf
PySpark und anderen großen Sachen und das ist
so ein bisschen fast wie so ein
ORM oder so fast, könnte man so ähnlich
sehen, auf Datenstrukturen.
Also ich würde sagen,
es macht halt so etwas möglich
auf Pandas, dass
man halt Lazy Evaluation
hat und es
macht halt SQL-like Geschichten.
Weil
normalerweise sind alle Sachen, die man auf DataFrames macht,
irgendwie so eager. Also Pandas
ist sowieso, das muss man auch verlinken,
es gab da so einen schönen Talk von
Matthew Rocklin, der Maintainer von Pandas,
der sagte, Pandas ist gerade Crossroads,
wir haben jetzt ein paar Optionen, was wir machen
können. Also Pandas,
da gab es auch schon vor Jahren einen Vortrag
von Weißwein Pini, dem Ursprünglichen Autor
von Pandas, für kleine
Datenmengen funktioniert es, aber wenn es jetzt mehrere
10 GB groß wird, dann wird es halt schlecht und es
gibt halt diverse Probleme. Die Pandas hat halt einfach
aufgrund von der ganzen Geschichte
und dass man irgendwie der
Blockmanager und NumPy unten drunter
ganz viel und
der hat dann Pandas 2.0
quasi angeschartet und das ist
aber nie zu irgendwas geworden.
Und ja, aber das eigentlich
Pandas-Projekt steht jetzt wieder an der gleichen Stelle sozusagen
und man muss sich halt überlegen, was man macht und das ist ein
großer Unterschied zu anderen Geschichten ist halt,
dass es sowas wie, dass man nicht sagt,
okay, ich compile mir jetzt
meinen Filter und sonst wie, keine Ahnung, was ich auf dem
Dataframe machen möchte und dann sage ich irgendwann execute,
sondern es ist halt eager,
was halt bedeutet, ich kann es eigentlich nicht auf viele Maschinen
verteilen und dann irgendwie ein Ergebnis
zurückholen. Was halt die Skalierungsprobleme bei Riesengroten
Genau, und mit Spark und so, da kann man
das alles machen oder mit DARS geht
das natürlich auch, aber kann das selber halt nicht.
Und IBIS-Project ist genau das, der
Reparator von Python, das war mit DARS und die ganzen Sachen,
da einfach alles drauf zugreifen kannst und es benutzen kannst.
Superschönes Python-High-Level-Interface.
sehr, es kommt als natürlich bekannt vor,
also für eine Funktion.
Ja, genau, da gibt es
diese Firma hinter
ist das Cloudera? Ich glaube,
West McKinney war da mal eine Zeit lang und da hat er dieses Projekt
auch gestartet, weil die ganz, also
ich habe sich das zum ersten Mal verwendet, das war
auch Ende 2016,
glaube ich, da habe ich Ibis zum ersten
Mal verwendet, Anfang 2017,
weil
die ganzen Geschichten,
die oft in so Business Intelligence Abteilungen
sind, die arbeiten alle mit
mit riesigen SQL-Statements.
Und wenn du jetzt eigentlich aber das
in Python machen möchtest, also ich kam da halt
so als Python-Entwickler und die
machten alle irgendwie SQL vor allen Dingen für ihre
um Sachen aus, sie hatten einen riesigen
Hadoop-Cluster und
dann SQL-Abfragen
und die gehen dann per Hive, irgendwie
werden die halt verteilt über MapReduce
oder halt das neue heiße Ding da
war halt Impala, wo das dann halt in Memory
und irgendwie schneller geht.
Impala ist auch unterstützt von
Evis, ja. Genau, und dann
ist aber das Problem, okay,
und dann dachte ich, okay, wie komme ich denn jetzt
an meine Daten, wie kriege ich das denn jetzt in DataFrames,
weil ich würde ja gerne mit DataFrames-Dingen drauf tun
und nicht das in CSVs
rausschreiben, was die oft dann gemacht haben und dann
in R irgendwie einlesen, das ist ja alles ganz schrecklich
und die saßen, das war auch so eine Situation,
also, wo
ich mir denke, so, wie könnt ihr
ja, das ist ja irgendwie,
wie könnt ihr so leben, ja, das geht doch nicht,
okay, jetzt schieße ich diesen Hive-Job ab,
dann gehe ich erstmal Mittag essen, weil das dauert jetzt erstmal anderthalb Stunden
oder so, keine Ahnung, ja, aber das geht doch
nicht. Und ja, für die ging
das irgendwie.
Was soll man den ganzen Tag machen?
Also man muss halt nicht so viel arbeiten, wenn dann ein Python ist,
der superproduktiv ist. Ja, oder dann halt eben
dann auch diese komischen
Zwischenschritte und Dinge und dass man halt
irgendwie so komisch stand und dann auch überhaupt
diese riesigen SQL-Statements, der auch so denkt,
okay, wenn das 100 Zeilen
werden und man nachdenken muss, was macht denn dieses SQL-Statement
eigentlich? Ui, ich muss da wirklich mal drüber nachdenken.
Ui, ich habe immer noch nicht verstanden, was
es wirklich tut. Dann ist das schon schlimm. Aber wenn man dann
so Dinge hat, mehrere hundert Zeilen und dann
macht das so Core-Funktionalität, wo man sich denkt so,
wenn da irgendwo ein Fehler drin ist
und das ist so kompliziert, dass
also wenn das Code wäre, das
muss ausgiebig getestet werden, ja.
Und ja, bei SQL-Statements
testen ist halt auch so ein Ding, das passiert nicht so
richtig. Naja, jedenfalls
genau, da bin ich dann auf Ibis auch gekommen,
weil man damit halt schön
quasi irgendwie Impala,
ich weiß nicht, ob es damals schon Impala war, irgendwas
direkt abfragen konnte und dann kommt man direkt in DataFriends
rein, ja.
Ja, das war
mein Pick der Woche.
Ja, sehr schön.
Hast du auch einen, Max?
Ich habe tatsächlich zwei.
Einmal den
Django Context Decorator von Rix.
Das ist
ein sehr schöner, kleiner Helfer.
Man sagt
einfach, man macht halt den Decorator
drum, sagt dann
okay, gib mir das
raus und dann habe ich das halt im Kontext.
Sonst muss ich mir natürlich immer die Context-Variable holen,
das da reinschreiben und dann rausschicken.
So Mixed-in-Bound für sowas oder so.
Genau, erspart ungefähr so drei Zeilen Code.
Ja, aber das summiert sich natürlich irgendwie.
Aber Software-Ergonomie ist halt dann schön.
Ja, und das andere Thema ist Xonj.
Das ist eine Python-Shell.
Also da schreibt man halt nicht Bash,
da schreibt man dann Python.
Und das kann man gut und schlecht finden,
aber ich finde es eigentlich sehr schön,
denn da kann ich dann auch wie
gewohnt in Python halt drüber loopen.
Ist das dein Default-Tel? Ja.
Meine Default. Genau, ich kann da
letztlich alle
Commands, die ich in der Shell
hab, letztlich ausführen und die laufen
dann halt in den Python-Interpreter rein
und dann kann ich schlimme Dinge damit tun.
Okay, das muss ich unbedingt mal
angucken. Das klingt sehr gut. Ja, ich muss das irgendwie
kombinieren. Es gibt übrigens auch ein
Terminal, jedenfalls auf dem Mac.
Das nennt sich
Kitty. Das ist auch in Python
geschrieben. Genau, das funktioniert
super gut mit Xonj zusammen.
Okay, alles klar. Ja, gibt's auch
dann den Starship
Prompt für drin.
Nett, das klingt doch gut.
Hier, der hat mir auch schon mal eben drüber gesagt.
Cool.
Ja, macht's nur nicht als Root-Prompt,
wenn die dann kaputt geht.
Da kommt man nicht mehr weiter.
Ja gut, ne?
Ändert man die Shadow-File.
Ja.
Genau, was hatte ich?
Ja, genau. Mein Pick wäre PyTestMock.
Das habe ich letztens in den WeakNotes von Simon
Willison zufällig... Nee, er hat das
irgendwie auf Twitter gepostet. Simon Willison hat
einen ganz tollen WeakNotes, haben wir nochmal veröffentlicht.
Ja, den muss man auch mal verlinken.
Ja, also, wenn ihr denkt,
oh, da sind
ja immer interessante Links in den WeakNotes von Johannes
und von mir, dann lest
doch lieber die, die sind noch viel interessanter.
Da lese ich mal die WeakNotes.
Ja,
und der hatte auf Twitter, nee, das war auf Twitter,
der irgendwie geschrieben so, ah ja, er hat irgendwie
einen Weg gefunden, irgendwas mit S3 zu machen oder so
und dann hab ich da reingeguckt in den Kunden und dachte so, hä?
Also ich hab ja in Tests
oft das Problem, also ich benutze
Paltests zum Testen meistens
und so manchmal, also ich versuche ja immer
ohne Mocks auszukommen oder wenn dann
selber da, aber manchmal geht's
halt nicht, sondern da muss man halt irgendwie viel
mocken und dann hat man das Problem, also entweder
stapelt sich dann so eine Kaskade von
Patch-Dekoratoren über so einen Test
oder man hat halt irgendwie so eine tief
geschachtelte Geschichte mit so Wist
Context-Managern, also geht jetzt
mit einer neuen Python-Version, kann man da auch dann
klammern und so, aber
das sieht dann manchmal schon sehr wild aus
und ich denke mir so, ach, so ein bisschen hässlich ist das ja schon
und eigentlich, ja, also
gibt es da nicht irgendwie einen eleganterer Weg
und PyTest-Mock ist ein eleganterer Weg,
weil da sagt man einfach, schreibt man
halt in die
Signatur Mocker rein und dann kriegt man halt
irgendwie quasi
Ding übergeben, dem kann man
dann sagen, Punkt Patch
und dann braucht man aber keinen Kontextmanager
und man braucht auch nicht einen Dekorator,
sondern das passiert dann im Kontext
von dem Test. Und wenn der Test
vorbei ist, dann wird es halt wieder
geunpatcht, sozusagen automatisch.
Weil das ist ja irgendwie über diese PyTest-Magie da drin.
Das heißt, man kann das halt alles schön
linear verwenden und
ist halt diese Hässlichkeiten los.
Also ich mach dann auch noch einen zweiten
Pick, weil wenn Tests nicht laufen, dann macht man
einfach Pip install Fuckit, Fuckit-Dekorator
drüber, dann macht der 2XL-Pass
und dann läuft alles wunderschön.
Sehr schön.
Ja, also das als Abschluss.
Ja, also vielen Dank, dass ihr da wart.
Danke, Max, das war eine schöne Folge.
Bleibt uns gewogen, schaltet uns wieder ein,
hört uns und schreibt uns E-Mails an
hallo.peisenpodcast.de
Ja, danke Jochen, danke Max.
Auf Wiederhören.
Bis zum nächsten Mal.
Tschüss.