Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast, Episode 44.
Heute soll es gehen um Ansible.
Hi Jochen.
Herzlich willkommen Dominik.
Oh meine Güte, das geht ja schon holprig los.
Heute ist der Max dabei.
Wir haben 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 Ansible, aber erstmal natürlich wieder wie immer die News.
Jochen, was hast du denn für News?
Ja, was hatte ich, es ist eine ganze Menge passiert.
wurden ja auch schon auf Twitter
mitbekommen habt.
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,
und Jochen unterhalten sich über die Programmiersprache Python
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?
Letzten Sommer. Das war nicht letzten Sommer.
Doch, das war letzten Sommer.
und Jochen unterhalten sich über die Programmiersprache Python
jetzt sowas sagt wie await
Query-Side-Shelter 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 Datenbank-Ergebnisse,
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 PsychoPG3
oder für AsyncPG oder sowas
daher. Man kann, glaube ich,
Dinge machen, über ein Threadpool.
Also wenn man wirklich will, dann kann man auch so ein bisschen
Async machen, aber das ist
halt noch nicht so wirklich das richtige Ding.
Aber das war
eine Geschichte. Dann
aber eigentlich die interessanteren Features, weil die kann man
halt schon wirklich benutzen und die 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
Wert muss zwischen dem und dem liegen
oder darf nichts anderes sein als das oder so.
Irgendwas auch immer man für Constraints da festlegt.
Dann war es halt früher so,
da musste man das halt in den
Modelformen nochmal mit 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
wird die Datenbank dann angefangen.
Ja, und dann
eigentlich, also meiner Perspektive
die coolste Neuerung,
ich habe es mir jetzt noch nicht so richtig, aber es klang schon
alles sehr viel sprechend, das was ich gelesen habe, klang auch 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,
welches Template verwendet
wird, um Formen zu rendern, sodass man es gar nicht mehr unbedingt
in jedem Formen einstellen muss.
Und ja, da gibt es jede Menge.
Es ist deutlich flexibler geworden,
wie man Formulare rendern kann.
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.
und ich habe es
früher immer nur so ein bisschen verwendet und so,
so 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
JumboHTML, also mit
HTML 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
ändern.
In sehr komplizierten Formularen.
Und allein
nur das zurückgeben.
Um das hinzukriegen, muss ich sehr tief in CrispyForms
reingucken, wie das eigentlich funktioniert und so.
Und wie die ganzen Tablet-Packs funktionieren.
Und ja, da dachte ich mir, oh mein Gott,
das muss weg. Das kann nicht so bleiben. Das ist alles schrecklich.
Was heißt das?
Formtweaks?
Ah, Django Formtweaks.
Das macht es ein bisschen schöner, aber nimmt das Problem
auch nicht so ganz weg.
und 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 rennerst
Ja, du
sagst ja, wohin das
soll, letztlich.
Und
da über den Response kannst du dann
letztlich
das ändern.
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
Control ab, weil mir da Django einfach nicht so
genug entgegenkommt.
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 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 quasi mehr in die Component-Ebene rein.
Ja.
Dann vielleicht ein eigenes Feld schreiben.
Und dann kann man sich das ja auch wieder holen.
Das haben wir dann auch gemacht.
Ja, klar.
Genau, das wäre dann auch mein Ersatz.
Ja, aber es war alles nicht so ganz...
Also das wird jetzt mit Python und 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, das ist ja genau,
also das ist halt halt das Problem,
also Pathentic 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, okay, oder Etis oder so, glaube ich, das kann ich stellen.
Ja.
Und ja, das ist natürlich irgendwie ein bisschen
doof.
Deswegen,
das ist jetzt halt in Rust neu
implementiert. Da waren auch so ein paar Sachen dabei.
Ich habe letztens auch einen Podcast gehört,
Talk Python to Me, letzte oder vorletzte Episode,
weiß ich nicht genau, mit dem
Autor von Pydentic,
Samuel Cohn.
Und
da sagte er so,
da waren ein paar, weil ich normalerweise
dann immer denke, 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
und Jochen unterhalten sich über die Programmiersprache Python
Rust-Geschichten einbinden kann.
Und das macht halt...
In beide Richtungen sogar.
Und die Binaries werden halt
deutlich kleiner und das ist natürlich schön, weil
das war nicht so...
Und es ist halt genau...
Man kann halt alles wegputzen, was man nicht gebraucht hat oder so, glaube ich.
Ja, und die ganze Parsing-Logik
ist jetzt bei Python-Decor komplett
in Rust und es ist halt auch gar nicht so,
dass... Also bei Zeiten würde man halt
sagen, okay, einige Teile macht man halt in C
oder schreibt man in 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,
wenn dann Leute dann aus der
Google-Ecke sagen oder so, ja, wenn man
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.
Ja.
Ja, hast du noch weitere News?
Nee. Ich auch, der EU-Python.
Ja, das war natürlich ganz interessant.
Also total tolle Veranstaltung,
kann ich nur empfehlen, da teilzunehmen,
wenn man da die Möglichkeit so hat.
Das war in Dublin. Dublin ist natürlich auch
sehenswert. Es gibt da leckere
Getränke.
Aber aus der Python-Bestseller-Diktatur 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 Raminio,
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.
Dann kann man das halt direkt als GraphQL
View quasi benutzen.
Sehr interessante Art und Weise mit der Datenbank
untergehen. Da kann man relativ gut definieren,
welche Queries möglich sind auf die
Datenbank und hat dann einen Endpunkt, das Exposed,
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
implementieren. Bei GraphQL
habe ich immer so die Frage, also ich
muss ja das ganze Schema schreiben
und irgendwie habe ich immer am Ende
das Gefühl, ja die
Django OM gibt mir das aber eigentlich gratis, was ich dem rausgeben will.
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 habe auch mal eine Zeit lang irgendwie intensiv GraphQL gemacht, meistens dann halt Django Graphene.
Ja, das wird dann auch manchmal so unerklärlich langsam und ich mache halt mal so Probleme, das rauszukriegen dann, warum da und ja, ich glaube ich hatte 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 Idee ist.
Ich habe letztens auch kritische Stimmen gehört, in die Richtung.
Ja, Armin Runacher
hat es vielleicht jetzt letztens auf Twitter, da 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,
Armin Runacher hat immer gesagt, also diese GraphQL-Geschichte
ist so unfassbar komplex und das wird alles so
wie ist jemand
jemals auf diese Idee gekommen, das so zu machen?
darauf hat dann der
HTMX-Autor irgendwie geantwortet und meinte so, ja, also
bedenke immer, wenn du so einen
generischen Datenbankendpunkt
quasi deinem Frontend zur Verfügung
stellst, du stellst dir nicht nur deinem Frontend
zur Verfügung, sondern auch allen anderen, inklusive
Leuten, die dich angreifen wollen.
Ja, also du kannst auf jeden Fall schon tossen damit.
Das ist natürlich extrem schwierig zu verhindern,
dass das nicht geht.
Also
ja, ja.
Also auf jeden Fall trotzdem, der Workshop war sehr interessant.
Ja, aber es ist gut sein.
So ein bisschen ähnlich von FastAPI,
also ungefähr, also vom Prinzip her viel
mit modernen Typings 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
über Lisk-Screen-Parser in Python
relativ kurz, das gab so ein,
weiß nicht wie lang das ist,
gelogen 70 Teilen 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
so ein Lisk-Screen ist ja relativ ähnlich zu JavaScript, glaube ich,
oder so, wie man dann Tugends baut und Funktionen
und fand es ganz interessant, das mal so zu sehen, auch mit
Python und so versehen.
Generell, wo Python überall verwendet wird,
also James Webb Space Telescope
von der NASA war auch jemand da, der dann sagte, hey, wie denn die Bilder
in Python zur Erde geschickt werden und so, das freut man sich
immer, dass es so berühmte Anwendungsfelder gibt.
Die Lynn hat einen sehr schönen Talk
gemacht über Everyday-RPs von Spotify.
ist das eine Entwicklerin, die da
einfach so einen netten Talk gemacht hat,
so wie wir das auch machen, aber sie hat eine sehr hübsche
Folien, die können wir auch mal verlinken.
Das haben wir nicht. Genau.
Da kann man sich nochmal so angucken.
Abis Design, glaube ich, das war irgendwie, dann fand ich ganz
interessant.
Auch super, das war einer der,
für mich fand ich, das war so die didaktisch besten Talks,
das war von Niall O'Connor, irgendwie über
Fibonacci Retrace Levels, Asset Price
Prediction Reverse von der Bank of
America, der ist auch so rumgespringen,
hat die ganze Zeit über
Resistances gesprochen und da ist
immer die Folie gewechselt.
Ein weiter, ein weiter, in the long run we are all dead
und dann klick, klick, klick, eine Folie nach dem
anderen Team. Das war super, ich fand's 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 fand, 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 Dolly Bilder generieren
Ja, cool, genau, ja und das Coole ist
es gibt da einen Python-Wrapper drum, um HGFace
der nennt sich Gradio, den kann man einfach
installieren und dann kann man gerade sagen Gradio Use
den Namen dieses
Machine Learning Modells und kann dann direkt diese
vortrainierten Modelle nehmen und die auf seine eigenen Daten schmeißen
und die auch annotieren und 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
Ja, sehr cool, very nice
Ja, da gab es noch so ein paar politische Talks
über AI, Dystopia und so, was man alles nicht
mit Killer-Robotern machen kann und so
wenn man sich das nochmal angucken möchte, so die Argumentationen
dahinter stecken
Dann
darüber, wie man 3.11 jetzt schneller
gemacht hat, hat Mike Shannon gesagt
Ja, das ist super
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
No-Gill macht und wie das aussieht
dass man halt in Python nicht mehr No-Gill 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 Ubicon
sparen vorneweg und hast halt
direkt diese Rust-Runtime und das ist relativ
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, Ubicon finde ich ja eigentlich schon ganz
gut, ist relativ schnell und so,
aber also zum Beispiel
in, wenn ich Files ausliefere, also meine Benchmarks sagen, so Ubiquon ist deutlich schneller, äh, deutlich langsamer als sowas wie Nginx und so, ich weiß nicht warum. Ich hab keine Ahnung, wahrscheinlich müsst ihr mal tiefer reingucken, was das eigentlich, also bei den Roboing ist auf jeden Fall auch diese, ähm, so ein paar Benchmarks, ich weiß halt immer nicht, du bist ja immer bei Benchmarks, bist du da ein bisschen kritisch, wie gut die sind oder wie weit gerade die sind? Ja, ja, schwierig, also sag mal so, es ist einfach schwierig, Benchmarks so zu machen, dass sie halt etwas sagen, die 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,
kann vielfältig schief gehen.
Ja, also jedenfalls, das war super interessant.
Achso, genau, ich hatte auch noch dieses
Tim-Gross-Talk, da geht es halt um Reference-Counting auch,
mit dem Nogel, dass man halt irgendwie das ersetzen kann.
Ja, dann
gab es noch
einen 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 Payload drin ist und so weiter,
das war interessant. Und noch
der Luciano Roman 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, dass der den Leuten interessiert.
Das ist der Autor von Fluid Python.
Ganz lange Zeit schon Community aktiv.
Und 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.
Genau, das meint ja so, wie du dich das vorgestellt hast.
Das war.
Ich höre dich bei der Talk bei
Pythons as Guido in Tende.
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 ein Protokoll
entwickelt, wie man das machen kann. Also typing.protocol
macht er irgendwie, um solche Sachen zu lösen.
Das war ganz spannend.
Ja, dann Supersearch
mit OpenSearch, war noch ganz interessant.
Also OpenSearch als Elasticsearch
Fork, irgendwie mit Python.
Ganz schöner Talk dazu.
Ja,
Dublin war toll, man konnte auch
an den Strand fahren, war super Wetter und
nette Leute kennengelernt, großer Marlene.
Und ja.
Ja, sehr schön.
Das war eine super Veranstaltung. Kann ich empfehlen, das nächste Mal gerne wieder.
Ja, nächstes Mal schaffe ich es gleich auch.
Ein Gruß an Jörn 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 Ensebel.
Und ich würde sagen, jetzt ist auch der perfekte
Teilpunkt für Max, dass Max sich vorstellt und
Hallo sagt.
Ja, hallo, ich bin Max.
und
ja, programmiere
viel in Python,
mache viel mit Django,
bin bei einer
Compliance-Beratung, wir kümmern uns um
Datenschutz, Qualitätsmanagement,
Arbeitssicherheit und eigentlich
stelle ich so den Beratern die Tools
zur Verfügung, damit die
weniger arbeiten müssen
und alles ein bisschen schöner
am Ende aussieht.
Und da setzen wir hauptsächlich Python
ein und haben natürlich auch eine
Ecke an Servern, die wir dann
mit Ansible bespielen.
Das heißt Ansible zur Servereinrichtung.
Genau, also so.
Ansible macht ja Konfigurationsmanagement.
Kennt ihr alle Ansible?
Ja, ich doch.
Was macht Ansible? Ja genau, Konfigurationsmanagement
heißt also, du rollst
irgendwas auf dem 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.
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,
ja, Ansible ist halt
das Tool mit der niedrigsten Hürde,
weil man
am Ende halt
YAML schreibt
und dort halt relativ klar reinschreibt,
was man denn am Ende haben möchte.
Und es funktioniert halt
agentless, das heißt, ich muss halt
vorher keinen Kontakt zu dem
Server gehabt haben, also
kein Agent installieren
und dem werfe
ich dann einfach Befehle zu und der führt die dann
aus.
Ja, das ist
so wie, also per SSH brauchst du natürlich Zugriff.
Genau, man braucht SSH-Zugriff
und man braucht Python auf der Kiste.
Ja, okay.
Genau, und
ab da läuft es dann
sehr autonom.
Auf der anderen Seite gibt es natürlich auch
so ein paar Trade-offs in der Richtung.
ist nämlich dann, dass Ansible
eigentlich so den State der Maschine
nicht kennt.
Wenn man Agent drauf hat, der meldet dann
regelmäßig zurück und sagt dann,
ja hör mal, hier ist übrigens gerade
die Pakete sind ausgelaufen, kannst mal ein Update
machen, davon weiß
Ansible dann nichts.
Es geht einfach kaputt oder aus, wenn irgendwas nicht stimmt.
Ja, also der hält dann
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. Also es 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
und weiß ich, also wenn ich das nächste Mal
dann Ansible ausführe,
halt nicht, wie sieht denn jetzt die Wirklichkeit
auf der Maschine aus.
Ja, also vielleicht wollen wir tatsächlich so ein bisschen reingehen,
was Ansible 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 Riesenvolk,
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 ein Rechner klickt, dann kriegt man halt meistens ein
Root-Login da. Bis dahin ist es ja meistens schon automatisiert. Ab dann ist halt die
Frage, was macht man dann? Aber dann braucht man halt auch nicht mehr. Dann kann man mit
Enzimid schon anfangen, während man bei anderen Sachen, da muss man halt dann irgendwie einen
Agent installieren und keine Ahnung. Ja, das ist halt der Vorteil, aber es ist halt
natürlich in gewisser Weise auch ein Nachteil irgendwie, weil das macht dann 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.
Dadurch, dass das alles sich erst haben muss.
Also wenn zum Beispiel Files kopieren,
viele Files kopieren, ist halt mit
templates, die dann,
wie man da abzahlt, 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 erst 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
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, 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
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 die Musse des Auges,
man muss dann so ein Cloud-Init-Skript zum Beispiel mit angeben, was dann
auch quasi Ansible
selbst auf dem Rechner installiert und dann
ein Local Host Inventory läuft.
Also das Host läuft dann halt
local.
Ja, kann man so machen.
Ist aber sehr kompliziert, ja.
Ja, du hast halt hinterher das Problem,
dass du halt für Management die IPs wieder rausreichen
musst und einen SSH-Zugang brauchst, den Enso benutzen
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 Local
Host, die du dann provisionst.
Aber der sieht dann schon so aus, wie du willst.
Vielleicht erklärst du noch mal kurz, wie es andersrum bei dir funktioniert.
Erst Ansible, dann Terraform.
Ja, also letztlich mache ich
auch erst
Terraform. Achso.
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 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
richtige TMW wäre...
Vielleicht müssen wir das nochmal kurz auseinander druseln.
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
Ascent-Control-Node? 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
die Kisten aus? Also dann muss Ansible ja quasi wieder hingehen,
diese Nodes, die es erstellt hat,
connecten und dann da seine
Rollen aufbauen.
Eine Ansible-Rolle ist quasi genau das,
was man hat. Also eine Konfiguration für irgendwas.
Also Rolle, Datenbank-Server, Rolle,
Web-Applikation, Rolle.
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 doch nochmal erklären, für jemand, der es noch gar nicht gehört hat.
Also Inventory, das sind so meine Kisten, das ist eigentlich eine YAML oder INI-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, das sind die einzelnen Anweisungen, die 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,
ist halt, ja.
Ja, letztlich ist es eine Hilfe, dann
seinen Code zu organisieren.
Man kann natürlich auch
alles in eine große Datei schreiben.
Ich mache tatsächlich
ganz viele Rollen irgendwie.
Ich weiß nicht,
aber der Ensemble Galaxy ist auch ganz sch das ist halt der Cloud Die Sammlung von Rollen die Sammlung von Rollen die kann man hochstellen Wie Pip quasi blo f Ensebel
Also ich bin immer so ein bisschen picky,
ich mache immer viele Sachen selber, also
Notimated hier und so.
Ja.
Die Ensebel Galaxy
gucke ich mir dann auch zur Inspiration an.
Genau.
Ja, und
jedenfalls, da könnte man sich halt auch
solche Rollen einfach inkluden von dort.
und dann baut man halt seine Rollen und da
legt man dann halt fest,
welche Konfigurationsaufgaben
ausgeführt werden müssen.
Da kann man dann, weiß nicht, aus
Tinder-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
also okay, also weil ich
definiere mir halt immer so Playbooks
wo dann halt diese Rollenliste drin ist
die benenne ich dann irgendwie immer so
Setup Web Server with
bla oder so
ja
Postgres zum Beispiel und Django auf einmal
also dann wäre ja die Rolle letztlich Postgres
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
und letztlich die Rollen, die
soll man quasi so schreiben, dass man die
wiederverwenden kann.
Modular, austauschbar, egal.
Postgres ist halt überall, der Postgres
und der... Also ich finde das zum Beispiel
schwierig, weil
was Ensemble ja zum Beispiel auch ermöglicht ist,
eine Unterscheidung zwischen den Betriebssystemen,
die benutzt werden, also ob ich jetzt
ein Meta-Enterprise habe oder ein
Debian oder so und
das finde ich ein bisschen blöd, weil
ich habe keine Lust, immer meine Rollen
für alle Systeme zu schreiben, die ich nicht benutze.
Ja. Also so.
Genau.
Also deswegen ist es eigentlich ganz gut,
die Themen so homogen zu halten,
damit man nicht so viele
unterstützen muss. Aber da kann man
natürlich auch nochmal mit dem Inventory arbeiten
und dann beim Inventory
den einzelnen Servern nochmal Variablen
mitgeben und sagen, okay, der ist halt
anders als die anderen.
Ja.
Genau. Also das, ja.
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 Pulse I zur Zeit.
Das ist nicht Arch Linux.
Naja, nee.
By the way.
Es gibt da auch interessante
Alternativen. Also womit ich ab und zu mal
geliebt und ordnet habe, ist halt nix.
Aber ja.
Ich habe nix auch benutzt, aber nur als
Server-Variante.
Gerade Python ist da sehr, sehr nervig
mit, weil man halt gar nicht so
wie Paketmanagement, wo er seine Projekte
verwalten kann, sondern muss halt jedes Mal seine eigenen
Environments irgendwie zusammenfummeln und ist
nicht alles verfügbar und das ist einfach
sehr, sehr viel Maintenance-Arbeit,
wenn man da irgendwie Updates fahren will.
Man hat halt sehr viel Kontrolle,
die man auch ausüben muss.
Ja, genau.
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,
dann überlebe ich damit, dass es halt irgendwie ein langweiliges
Debian ist.
Und dann kann ich die interessanten...
meinen Innovation-Token
irgendwo anders ausgeben, wo es halt vielleicht
irgendwie mehr bringt. Aber es reizt mich schon,
das muss ich sagen.
Ja, also bei der Definition
jetzt, ich glaube, wo waren wir denn?
Inventories, Playbooks, Hosts?
Haben wir das klar genug definiert?
Oder sind wir da auf der Suche?
Ja, genau.
Ich wollte irgendwas sagen, ich habe es wieder vergessen.
Ich glaube, ich habe diesen Fall eben auch,
das nervt mich auch in diesen Rollen, die man halt von
Galaxy
bekommt, ja eben sowas wie Postgres
zum Beispiel. Also
was ich dann, wenn ich diese Rolle, wenn ich, ich weiß nicht,
ob ihr die kennt, die habe ich mal
irgendwann benutzt, ich weiß nicht, ob es ja noch aktuell ist.
Da 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 Show Notes? Genau.
und der hat auch einen Vortrag,
wie man rausfindet,
welche Rollen
gut sind in der Ansible Galaxy.
Hat dann ein Schaubild gesagt
mit so ein bisschen Augenzwinkern.
Also man guckt dann, ob er der Autor ist.
Ja, tatsächlich.
Und wenn nicht, dann fragt man ihn an und wartet so lange,
bis die da kommt.
Ja, genau. Aber das Problem bei denen
ist halt oft,
weil der hat dann eben für Postgres zum Beispiel
eine und die fand ich nicht, sondern ich habe seine gefragt
und dann
und einfach, das ist zwar, also den Hauptteil davon, der interessiert mich halt nicht, irgendwie die ganzen Installationen von allen möglichen Plattformen, ja, und dann der Teil, der mich interessiert für Debian, da hätte ich keine andere Version und 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
und so 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 meine Server in der und der
Ja, in gewisser Weise, das ist vielleicht ein guter Vergleich
und so weiter.
oder 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.
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.
Diese Konfiguration wird dann angewandt.
Genau.
Und das Playbook,
wenn man sich dann
so ein größeres Cluster
vorstellt, enthält dann es halt
mehrere Rollen. Also ein Loadbalancer,
ein Webserver, eine Datenbank.
Was der Running Back machen soll, was der Quarterback machen soll,
wie die Defense stehen soll.
Richtig, genau.
Ja, ja.
Okay, also ich glaube dann die grundsätzlichen
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...
Die Variablen schreibt vielleicht? Ja, man macht das
halt so ein Gathering Facts.
Das kann man aber auch abschalten, wenn man es nicht braucht.
Dinge, wo dann halt bestimmte Variablen belegt werden
mit Informationen über das System
auf dem man gerade irgendwie... Kommt natürlich daher,
dass Ansible das erstmal nicht weiß.
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 auch viel interessantes Zeug drin.
Genau. Auch noch genau die Sachen vielleicht,
also die ganzen Variablen, die man irgendwie reinpiped
oder 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
verarbeiten möchte. Achso, du meinst,
um nochmal andere Dinge, die da jetzt nicht drin waren,
rauszusein.
Man kann in einem Task sagen, Set Fact und dann
halt irgendwas.
Dann kann man dann Pipe, Strip,
String, Station, was auch immer.
Die Playbooks, die sind ja letztlich,
läuft da halt auch ein Ginger2-Support hinter
und das heißt, ich kann alles
letztlich machen, was ich in Ginger2 machen kann
mit den Facts, die
vorher Ansible gesammelt hat und ich
kann die letztlich wie ein Directory
accessen, beziehungsweise ist sie ja eins
und dann kann ich da alles
machen, was
Ginger 2 mir letztlich erlaubt.
Das ist ja echt eine ganze Menge.
Da vielleicht
ein Exkurs. Ginger 2?
Ja, Ginger 2.
Templating Engine.
Letztlich
so wie
alle Templating Engines,
die man so kennt.
Ist auch ähnlich.
Nicht genau so.
Ginger 2 ist wahrscheinlich sogar die bessere
Template Language.
schon ein bisschen. Genau, es gibt auch
Ginger2-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 da irgendwie dazwischen
habe, wenn man irgendwie mit dieser Sache umgeht.
Aber jetzt vielleicht nochmal, warum wir kurz das definieren
wollten, um diese Terraform-Enzibel-Sache
nochmal so ein bisschen zu verstehen.
Was
spricht jetzt zum Beispiel dagegen,
sowas wie dieses lokale
Enzibel zu machen, deiner Meinung nach, wenn man sagt,
okay, man lädt jetzt
einen Localhost einfach und sagt
dem, 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 Endebekram.
Ich habe da wenig Kontrolle
drüber, ich muss halt dann auf den Servern dann in die Logs gucken
oder was auch immer, um festzustellen, wo sind die 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 IDE backen, damit
er einmal sicherstellen kann, dass ein Server das macht, was er will.
Aber 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
und ja.
Also ich frage mich halt, was sonst Terraform ist, weil ich
frage mich halt, wie dann halt Terraform sonst aussehen soll,
weil ich weiß ja gar nicht, mit
Ansible anzufangen, welches 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
Bereich. Jochen hat gerade zugegeben, dass er sich
die einzelnen Klausel einfach zusammen klickt.
Ja, das hat er selbst.
Und ich rufe jemanden an, der macht das dann.
Aber ich kenne,
es sind so wenige, ja, so Privat-
Handverlesene, Server,
so viele habe ich da nicht, dass ich die nicht mehr kennen würde.
Da kenne ich jeden Einzelnen
mit Namen sozusagen.
Und die kann ich dann auch in 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 Enzable.
Also nur mit dem Unterschied, dass ich jetzt halt einmal hingehe
und sonst in Terraform beispielsweise
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 Hether oder bei
Azure oder so, und sage 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.
also, aber ich möchte
halt gerne diese Flexibilität der Rollen haben,
die ich dann über das Terraform-Skript
reingebe, ja, 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 ist 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.
Es kann gut sein, dass das dann schneller ist.
Genau, das läuft halt dann schnell einfach durch und
konfiguriert die Maschinenlokal halt einfach so, wie sie
sein soll.
Was ich dann natürlich machen muss, ist, also was ich
auch mache, ist, ich konfiguriere jetzt meistens
meinen Admin-User mit den entsprechenden Keys und tralala.
Den könnte ich ja dann wieder rausgeben.
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
und upgradee Django auf die neueste Variante
oder so.
Und auf der anderen Seite des Ansibles-Setup
läuft halt über das Ansible-Repo,
wo halt dann die ganzen Standard-Rollen
drin sind.
Ah, okay.
Ja, interessant. Also das ist irgendwie ganz anders,
als ich das mal gesagt habe.
Ja, ne, witzig.
Also ich muss sagen, es funktioniert ganz gut.
Es witzigt sich auch so ein bisschen von hinten, wie ich Brustsatz
habe, ich habe mehrere Blog-Einträge durchgelesen
mit so für und wieder und ich,
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, du hast die 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.
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 Dango-Server, ein Terraform-Ordner Bucket, ein Terraform-Ordner Datenbank-Server, irgendwie so.
und da werden die Sachen halt dann, kann man die auch so schnell skalieren, weil die Variablen stehen halt dann direkt mit drin und dann sagt man halt, okay, Tatmark-Server ist ein bisschen schneller oder so und hat ein bisschen andere Netzwerkkonfigurationen oder sowas.
Ja, gut.
Okay, ja auch.
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 der einen dann den Vagrant so hochgezogen, wie man das letztlich im Playbook stand.
Ja, ja, ja.
Also.
Ja, ja, ja.
Ich erinnere mich da auch noch dran, das habe ich 2000, wann war das?
2012, 13
habe ich das mal gemacht. Das war ziemlich schrecklich,
ehrlich gesagt.
Ja, aber da gab es noch 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,
den BN Desktop
per Ansible auszurollen.
Ja, also kann ich
absolut verstehen, nur weil
und 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 nix gewesen.
Aber dass da in mich nix genervt hat an so ein paar Punkten,
weil dann habe ich dann gesagt, okay, dann mache ich es mit Enzabel, 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 dotfiles, sondern
das ist halt noch mehr
und deswegen wollte ich das halt bei Enzabel steuern. Da muss man halt
dann immer fliegen, muss halt immer dann ein Repo
haben, was halt für seinen Desktop ist, muss da halt da immer
dran rumfummeln, wenn man die Konfiguration hat
die updaten, aber dann kann man halt egal wo man ist einfach
seine Sachen reproduzieren
und wenn man auch irgendwie sein
ja seine irgendwie 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.
Aber Docker ist halt so ein Tischenlayer irgendwie noch.
Das ist so ein bisschen, ich weiß nicht,
ob es ein Personennummer gibt. Also ich meine, die Rechner, die wir nutzen,
sind ja meistens relativ strong, aber
ja.
Ja, es gibt schon irgendwie so ein bisschen
Einsprünge, 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 man einfach
schwer zu installieren ist. Und da gibt es ja durchaus Software.
Also man sagt, jo, okay, nimm doch
hier einfach diesen Docker-Code, 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 erst mal
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?
Ja, also
früher hat man auch dann
mehr Ansible-Playbooks gesehen,
wenn es dann um schwierige Installationen ging.
Ja, leider
ist es so ein bisschen auf dem
absteigenden Ast.
Was macht man denn jetzt? Nur Docker dann?
Oft findet man halt die Docker-Container
und das hier. Also wenn du das einfach
dem Run sagst, dann läuft der
und dann kannst du
leben.
Ja, das finde ich auch faszinierend, weil
Ich sehe diesen Trend durchaus auch,
aber ich finde ehrlich gesagt,
wie fühlt es sich von der Benutzung her an?
Docker wird
eher immer schlimmer.
Ich habe noch zwischen euch ganz gerne genutzt,
aber ich weiß nicht, irgendwas finde ich nervig.
Das ist immer so gekapselt auch.
Ich habe nicht so den direkten Zugriff.
Es nimmt
einem schon irgendwie Probleme ab, aber
es hat halt auch nicht so ganz
die Flexibilität, wie es Demon & 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 den container
30 mal hier
solche Sachen, oh Docker kommt bloß dauernd 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, 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
kumuliert ist und die Dinger sind halt, die
Images, dann denken sie, 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 und dann installieren sie
aber NumPy und dann zieht das erstmal
in GCC nach und dann wird erstmal die komplette
Compiler-Toolchain irgendwie
kopiliert und dann
ist kein Wunder, warum das so lange dauert.
Aber es ist halt irgendwie so
und die Images werden riesig.
Dann nehmen sie Alpine, damit die klein werden und dann werden die
irgendwie anderthalb Gigabyte groß.
Und dann denke ich so,
also irgendwie,
ihr haltet das falsch rum.
Ja, genau.
Das ist irgendwie das, ja.
Aber
ich habe das Gefühl, es
hindert die Leute. Also ich denke, das ist
eigentlich ein ziemliches Katastrophenszenario.
Und eigentlich müsste man sagen,
es müsste den Leuten doch irgendwie auffallen,
dass das jetzt alles furchtbar ist, oder?
Aber das ist nicht so. Die Leute
halten das für normal und das ist dann jetzt halt so.
Und dann verbreitet es 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 LPN ganz viele andere Sachen,
Dino und Bun, oder wie? Ja, aber das ist auch alles
ziemlich furchtbar. Also, ich meine, gut,
vielleicht liegt es irgendwann so,
ja, wird das da auch mal wieder.
Egal, Entschuldigung. Wir wollten nicht über
da machen. 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 es ziemlich
an. Job Security
ist auch ganz wichtig.
Ja.
Aber ja.
Und
ich weiß nicht.
So im direkten Vergleich.
Das habe ich früher gemacht.
Zum Beispiel PythonPodcast.de.
Wenn man sich das anguckt, das ist tatsächlich
ein Cookie-Cutter-Template für Django.
Und dann ist da auch
ein Docker-Container oder mehrere Docker-Container,
weil da ist halt auch ein Datenbank und so.
Und es ist halt
und irgendwie Report.
Als ich angefangen habe, Sachen zu lernen,
hat Jochen mir gesagt, das ist so, wie man das macht.
Und dann stand ich erst mal auf dieser komplexen Ziele.
Ich kam ja von Vagrant und da war das
aus, als wäre das Fortschritt.
Also ich musste erst mal ein paar Mal gegenhauen und habe mich jetzt mal gefragt,
was ist das denn jetzt? Wie geht denn das jetzt?
Muss ich mich jetzt eingeben? Muss ich mir irgendwie tausendlange
Kommandozeilen, Listen schreiben?
Und dann überhaupt
die Introspection. Das war schon echt
ein Komplexitätsmonster, muss ich sagen.
Ja, also
es tut mir leid, aber so ist es.
und ja, aber das läuft noch
alles auf Docker und so
und
es ist aber nicht, es ist, also wenn ich
das jetzt vergleiche, ist ja auch der 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 Dinger 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-Enterter nochmal drin
und das wird einfach alles so hochgezogen und
hat dann auch ein schreibbares Dateisystem und so. Man kann auch so eine Backup-Rolle installieren,
dann überläuft das vernünftig, jetzt weiß man auch, wo die sind, das ist alles ordentlich.
Ja, aber man kann auch überall reingucken, man kann da einfach als Root mal
so irgendwie ü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-Stopp-Zeugs,
das man da sonst so hat.
Ja, vor allem, wenn die einmal gut sind, dann ist das eigentlich
gut. Und es ist halt viel transparenter.
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
einen richtig großen Server zu haben
und da laufen halt die
und Jochen unterhalten sich über die Programmiersprache Python
vor sich hin, weil dann sagt er, 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, dass das der
Entwickler, dann ist Docker möglicherweise sehr gut
und wenn du dann viele von solchen Sachen auf einer
Maschine laufen lassen willst, dann führt vielleicht um
Docker auch kein Weg drumherum.
Aber das ist ja letztlich auch der Kritikpunkt
an Python, dass man quasi immer die
Entwicklermaschine shippen muss, damit sie überhaupt läuft.
Ja, das ist natürlich auch bei
so ein Problem.
Ich finde Poetry löst das,
wenn Poetry läuft.
Ja, Poetry läuft so.
Das war meine Erfahrung. Das läuft so drei Monate,
vier Monate und auf einmal
ist irgendwas irgendwo kaputt und dann
Cache reparieren, neue Versionen
installieren, pre.
Fällt jetzt alles auseinander, genau.
Ich stelle momentan auch
Sachen, wenn ich alte Projekte habe und ich sehe,
dafür bin ich noch Poetry, ich stelle es mal auf
PipTools. Aber PipTools ist furchtbar.
Aber PIP wird auch
verfürchtert von PIP-Tools, weil letztlich ist es nur PIP.
Ja, genau.
Und wenn jemand PIP brechen sollte, dann
fällt auf und dann machen andere Ärger.
Es ist 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, wie PUT.
Oh, ich habe jetzt,
das habe ich dann nochmal versucht, weil du meintest,
es kann auch PIP-Tools können,
also nicht so richtig, nein.
Ja, genau.
Und ich brauche PyProject Hummel. Also ich finde
die super. Das ist eine gute Idee.
Ja.
Weil diese ganzen
TXT-Files mit irgendwie...
Ich will die ganze Konfiguration
in PyProject Hummel haben. Ich will die Pakete
da drin haben.
Was man auch machen könnte,
man kann ja einfach einen Tummel-Parser nehmen
und dann die Dinger automatisch generieren
aus seiner Puppe.
Das ist auch wieder sehr eklig.
Ja, gut.
Ja, okay.
Ich stelle das jetzt alles um und ich finde auch vom Deployment-Aspekt her ist PipTools deutlich angenehmer als Poetry, weil Poetry ist auch beim Deployment ganz schön hakelig.
Naja, aber das habe ich jetzt gelöst.
Wie installierst du denn Poetry?
Also ich installiere Python, dann PipX, dann Poetry, das funktioniert gut.
Ach, du installierst dann Poetry per PipX?
Genau.
Das ist aber nicht die empfohlene Art.
Es 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 Potree benutzen, um
halt meine Environments installieren und
ein Konfig-Setting für Potree
Aber das ist schon ein ganz schöner
auch irgendwie... Es ist ein Playbook.
Ja, ja, das ist
aber ja, das funktioniert gut.
Und wie kommst du an den, erzeugst du deine
Virtual-Infs auch über Potree? Ja.
Wie kommst du an deinen Interpreter,
wenn du jetzt mal sowas wie manage migrate
ausführen willst oder so im General Context?
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.
Das ist nicht immer anders. Das ist reproduzierbar.
Ich habe mir eine Foto geschrieben, die mit den Namen von Event.
Ja, das habe ich nämlich auch gemacht. Genau.
Ich sehe dann ein Muster.
Genau das habe ich nämlich auch gemacht.
Da gucke ich dann jetzt immer so drauf und denke mir so,
warum nehme ich da an der Stelle nicht einfach ein Virtual End
und dann weiß ich vorher, wo der Pfad ist.
Ja, was halt geht ist, du kannst halt die Virtual Env in Project
Path 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 den Pfad, kannst du ja auch angeben,
dann macht der halt nicht irgendwo unter Envs mit
Hash, sondern dann setzt 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
Kraft und auch Netzwerkprobleme hat man
auch, wenn man das mit 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.
Es gibt ja auch Entwickler, die Windows benutzen.
Da kommt man dann mit Docker schon mal
ein bisschen weiter.
Ich musste 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 er mal von hinten durch die Brust ins Auge ist
oder irgendwelche C-Libraries nachinstallieren muss,
was man auch manchmal meistens hinkriegt,
bis auf ein paar Ausnahmen, aber das ist manchmal sehr,
sehr, sehr nervig und wenn man das mit Leuten macht, die sich
da nicht gut mit auskennen, dann hat man immer
Gegenüberwand und deswegen entwickeln im Docker
befreit einen einfach von diesem Schmerz,
weil das ist relativ klar.
Wobei ich ja, also wie gesagt,
mit diesem Windows-Subsystem für Linux
und dann einfach da ein Debian draufhaben oder so,
dann 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
ein Fallsystem manchmal Probleme gibt oder jedenfalls
Leute machen so, hä, und dann kommen hier komische Fehler.
Oh, irgendwie ist das, was da in dem Linux-Fallsystem
ist, nicht das gleiche.
Genau, und die Pfade werden halt gemountet,
also zum Beispiel in Windows-Gipfelstatt so ein
fag.wc, 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 Weibchenvergabe 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 wie jetzt Code
dann das Verzeichnis machen und so.
WSL hat noch ein paar andere Probleme Zum Beispiel ist es dann oft wenn man Windows hat weil dann irgendwelche Leute mit Active Directory Zugriff das einfach sperren k hat man zwei WSL drauf aber ohne Update also das kann man
halt nicht richtig benutzen und die Frage ist,
warum man Windows benutzen will, wenn man WSL benutzt, weil
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 und dann mache ich das auch mit
WSL2 oder so, das ist super, aber
jetzt in der Firma beispielsweise, wenn ich jetzt
ein Windows-Management-System habe oder
ein Team habe, was halt über Active Directory
die Zugriffe kontrolliert und ausrollen will,
dann macht es relativ wenig Sinn, wenn ich den Leuten dann
WSL freischalte, weil dann
die nämlich wieder rauskommen und das will ich ja eigentlich
gar nicht.
Das ist so ein bisschen blöd.
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
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 fällt 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
habe ich jetzt letztens einen Podcast
gehört mit der
mit einer der
Engineering-Chefin und ich glaube es ist nicht CTO, sondern
irgendwas drunter, 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ört zu Microsoft.
Komisch, komisch, komisch.
Ja, ist natürlich praktisch.
Es könnte natürlich
ihren Move dahin
ein wenig irgendwie
genatscht haben, sozusagen,
dass das passiert.
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 auch gefallen,
als ich irgendwelche Tracebacks bekommen habe, wo ich dachte, also 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 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,
also gut, ich kann jetzt nur von Mac sprechen,
kann sein, dass es unter Windows besser ist, aber
auf Mac ist Docker Desktop
halt ein unfassbarer
Schrott.
echt. Also wie oft mir das
gestorben ist und zwar auf eine Art, dass ich das nicht mehr
reparieren konnte.
Ja, da Updates gehen nicht oder so.
Ja, Updates gehen nicht.
Ich hatte es mehrfach, dass mir doch jemand gesagt hat,
das Spinery ist kaputt.
So nach einem Update-Versuch.
Kaputt.
Ganz hart einfach das wegschmeißen und dann
nochmal wegschmeißen, aus der Registry,
aus der Windows-Registry rauslöschen, also quasi die ganzen
Pfeils irgendwo aufsammeln und rausfinden, wo die
sind, wegschmeißen, neu machen, damit
es funktioniert. Furchtbar.
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.
Wir entwickeln die Leute dazu, wie es gut ist.
Ja, also PyCharm bietet das jetzt auch,
dass man in der Cloud arbeiten kann.
In derselben? Oder ist das dann um zwei unterschiedliche?
Also muss man sich entscheiden? Oder kann man die
parallel benutzen?
Ich glaube, das sind unterschiedliche.
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.
Also PyCharm für Python
und VS Code ist eigentlich ein schöner
Texteditor, also wenn man das
Microsoft Zeug wegnimmt und VS Codium nimmt,
dann ist das ein schöner Editor und
dann kann man halt
viele Sachen damit machen.
Ich mag es sehr gerne.
Ja, aber letztlich so dieses
vollintegrierte IDE, da ist man ja bei PyCharm einfach
komplett
ohne irgendwas konfigurieren zu müssen.
Man macht es an und dann ist man drin.
Würde ich auch sagen, ja, vielleicht mit Konfiguration,
aber wir haben ja mit diesem Battle
noch nichts gefunden, was ich nicht andersrum so oder so lösen könnte.
Das ist ein Muster.
Ja, also
Man kann das durchaus, also ich habe beides jetzt auch schon
ausgebildet, man kann durchaus beides verwenden, denke ich.
Aber ich finde auch PyCharm ist halt, wenn man Python
macht, ist schon, es hat auch noch so ein paar
nette Funktionen. Also zum Beispiel ein Ding, das mich mir
vielleicht habe ich was,
ob du das mit VSCode hingekriegt hast,
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 tatsächlich ein Use Case, den ich häufig
habe, wo ich dann bei VSCode dann so klicke und denke,
äh, klingt das denn jetzt nicht richtig?
Das funktioniert irgendwie nicht.
Ach nee, wie ist gut, kann das nicht.
Das fand ich auch immer sehr angenehm bei PyCharm.
Dass man halt so schnell springen kann.
Ja gut, das Ganze, also wie es so
entwickelt ist, 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.
Es gab auch einen Microsoft-Standard auf der Europe-Python,
wo die meinten so, oh ja, voll gut, und sagt mal, was uns noch fehlt.
Wir bauen das halt einfach so einfach ein.
Ja, ja, da ist viel Druck hintergrat.
Ja, ja.
Zum Beispiel auch Azure war halt irgendwie erst auf Python 3.8 noch, da habe ich mir auch gedacht, hey Leute, geht doch gar nicht.
Aber da arbeiten sie wohl dran, da ist wohl...
Aber Editor Wars.
Ja, wir haben es eigentlich...
Also Wim ist eigentlich auch ganz gut.
Ja, genau.
Gut, dass hier niemand E-Mails hat.
Hallo, Johann.
Ja, ja, ja.
Ja, oh, das ist auch ganz...
Da muss man ein bisschen Zeit mitbringen, aber vielleicht...
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.
Der John Carmack, der von
Quake.
Ja, genau.
Es ist fast
fünfeinhalb Stunden lang, aber
für die jüngere Generation.
Ein Docker-Bild.
Genau.
Das war sehr kurzweilig.
Für der SecCode 1 brauche ich immer die Konsole auf Tilde.
Ah, ja, ja.
Das war mein Bein.
Ja, und das war ganz interessant,
weil da beteiligte sich
sich an diesem Editor Wars ein bisschen
und der
hat dann auch irgendwann mal versucht, Wim zu verwenden.
Also ich meine, eine Woche angeschlossen
versucht er es zu lernen und dann rauszukriegen,
warum Leute das gut finden, aber es hat
ihn nicht überzeugen können. Er ist
auch so eher auf der IDE-Seite und
viele Debugger verwenden.
Und ja,
er macht das nicht so extrem wie andere. Andere machen
sowas wie eine uralte,
nicht wie das Code, sondern tatsächlich
Visual Studio-Version 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
da und ja,
dann schreibt er halt meistens irgendwie
C-artiges C++ oder sowas
und macht halt viel im Debugger.
Aber ich fand es interessant, also einfach
mal so zu hören, wie er da so
Sachen macht und so.
Das ist natürlich ein Guru, ne?
Ja, tatsächlich.
Damals
habe ich so ein bisschen,
ich meine, ich habe es nie gespielt, aber ich habe ein bisschen geguckt,
und was sie so im Grafikbereich machen.
Er hat es nie gespielt.
Ich habe es vielleicht mal gespielt, aber ich habe nie
Ehrgeiz entwickelt oder mich da lange
miteinander...
Kurze Anekdote, ich war damals
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, 2 TTF.
Ja, ja, dann TTF hieß damals noch was anderes.
Ja, und
genau, also
aber was da so im Grafikbereich zum Beispiel
über Quaken oder so passiert das. Das war gerade zu der Zeit,
wo ich da auch irgendwie
so mit Informatik und Grafik da
das war, da waren
schon einige abgefahrene Sachen dabei.
Wow, krass, das ist ja so irgendwie
Spieleentwickler, die machen da irgendwie so ein bisschen
das war schon so echt
okay, das sind, die
implementieren da wirklich
so ganz, ganz aktuelle
Forschungsgeschichten direkt
und machen das halt besser als alle anderen
und so. Wahnsinn.
Insofern, ja, also
und hat mich schon interessiert, wie der dann so arbeitet und so.
Ehrlich gesagt, was ich so ein bisschen frustrierend fand,
ist, dass eines der Geheimnisse hinter seiner Produktivität wohl einfach ist,
wahnsinnig viel arbeiten.
Verdammt.
Hätte mir eine andere Antwort gewünscht, eine andere Lösung für dieses Problem.
Ich wäre gerne 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 er meinte so, ja, das ist halt eines seiner,
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 Mutti, wie war das?
Meistens ist es ja nicht, wie schnell ich den Code
in die Datei bekomme, sondern
wie schnell ich darüber nachdenke.
Ja, genau.
Oder im Machine Interface.
Er redet dann sogar locker flockig.
Er hat ja immer Stress im Internet,
wenn dann Leute meinen, naja, bei mehr als 8 Stunden
dann ist man ja nicht mehr so produktiv.
Ja, das ist schon so. Man ist dann nach 8 Stunden nicht mehr so produktiv.
Aber man ist halt noch so ein bisschen produktiv.
Also nicht mehr so produktiv wie in den ersten 8 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 kann,
bei mir ist das so, am nächsten Tag
reduziert sich dann meine Produktivität auch deutlich.
Bei mir ist das anders.
Er meint 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 nach zwölf Stunden Programmieren ist halt bei ihm auch
irgendwie Ende, aber das kann er
tatsächlich sustainable durchhalten.
Er meint so, zwölf Stunden am Tag programmieren kann ich
sustainable machen, habe ich seit ein paar
Jahrzehnten gemacht, das geht.
Ich krieg dann auch keinen Burnout oder so
Das geht einfach immer so weiter
Okay
Das ist mir ein bisschen zu hart, ehrlich gesagt
Also schon nachvollziehbar, wenn man so richtig
Bock hat, dann hört man auch nicht mehr auf
Ja, aber das kann tatsächlich länger als 2-3 Monate
durchziehen, denn irgendwann
brauchst du halt wieder ein bisschen Luft
und
Ja
Seine Einstellung war dazu
Diese ganzen Quatsch brauch ich nicht, ich brauch nur
Diet Coke und Pizza und dann
Das Sozialleben leidet dann zwar,
aber wenn man sich
so richtig dann zurückzieht und dann...
Die artige Vampirblässe.
Erinnert mich so ein bisschen an die
Anfangszeiten, wo ich dann programmiert habe
und herausgefunden habe, wie alles funktioniert, auch mit Django.
Und
ja, da habe ich eigentlich
jede freie Minute
an Django geschrieben und das
gemacht. Das waren coole Zeiten,
aber mittlerweile geht das auch nicht mehr.
Long Time No See 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 ich habe auch eine Phase,
so phasenweise irgendwie Dinge sehr
intensiv gemacht und ich weiß nicht, ob vielleicht das
notwendig ist.
Bei T's Ende oder sowas.
Auch danach.
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, ob das weitergeht. 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, ich wünsche mir das
irgendwann mal so.
Am Anfang auch, also in Python zu lernen, auch 70 Stunden
investiert war. Ja, ja, eben.
Ich höre das von vielen. Ja, also diese Rechnung
ist halt tatsächlich irgendwie, wenn man
betonen wir es mal so, schaffen maximal
Produktivität in der Sendung, wenn man da ist.
und wenn man 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 das 5 Stunden die Woche macht, einfach um 28 Jahre weiter.
Ja, ich glaube, man kann es nicht so naiv rechnen.
Ja, 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, 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 gegenteil, bis es kaputt geht.
Ja, genau.
Also lieber weggehen und unter der Dusche fährt man dann ein,
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
dann halt nur die Einfalllösung hat,
dann hat man diese ganzen Schläge von der Seite oder sowas verpasst.
Also ich fand das schon immer gut.
Ja, kann sein. Vielleicht sind auch unterschiedliche Leute einfach unterschiedlich.
Oder unterschiedliche Themen oder sowas, wo das halt hilft oder nicht hilft.
Ich weiß nicht.
So ein bisschen Guru-Meditation.
Ja, ja.
Ja, ich habe auch das Gefühl,
dass ich das früher tatsächlich nicht konnte,
irgendwie mehrere Projekte gleichzeitig.
Das mache ich jetzt halt gern.
Wenn es irgendwo nicht weitergeht, dann mache ich halt was anderes.
Und dann bis da nichts mehr weitergeht
und dann wieder was anderes.
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 ändere ich 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 Ensebel-Folge.
Ja, genau, genau, Ensebel.
Ja.
Also, ich habe hier noch so ein paar Sachen gestehen 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 zu erklären.
Testen würde ich gerne nochmal drüber sprechen.
Wie geht das, macht man das, braucht man das?
Ja, vielleicht die ganzen Commandos, Bildschirms, was gibt es denn überhaupt?
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?
Wie startet man die, kann man die auch
irgendwie committen, macht man das Nutzerskontroll?
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 vorne nicht, welche Server-IP gab's
denn da und die muss dann der Server
drücken 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 halt irgendwo
hinschicken. Man kann die natürlich
dann auch eine Datei schreiben?
Ja, die Frage ist genau das. Man muss die vielleicht auf der
Control-Node irgendwo ablegen, weil vielleicht braucht man
die beim nächsten Run
beispielsweise zu
ähm, wie klingt das?
Also man möchte jetzt sowas machen wie
Updates. Und man hat
jetzt nicht das Denux, 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,
wenn das eine kritische Infrastruktur ist, dann muss man
vielleicht auf der alten Version aufbauen
und dann updaten.
Weil sonst das
nicht dasselbe ist wie das Produktionssystem,
was man ja nur updaten muss.
Du meinst, du willst das Update testen?
Genau.
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, yum oder apt
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 zum Beispiel merken, weil jetzt nicht über App kommt,
zum Beispiel über den GitHub-Revo oder den GitHub-Tag oder sowas.
Ja, da kann ich natürlich dann sagen,
okay, welches Tag möchte ich denn überhaupt auschecken?
Ja. Oder möchte ich einfach die Latest
auschecken? Dann habe ich halt immer die Latest, egal
welche. Genau, aber wenn ich jetzt genau dieses Update-Fall
habe, dann muss ich ja mir merken, welche Version
in Produktion läuft, beispielsweise.
Damit ich
erstmal das auschecken kann, um dann das Update auf die Latest
zu fahren, um dann sicherzustellen,
dass ich das testen kann, um dann die Latest auf
Produktion 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.
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 der neuen Version funktioniert oder nicht,
das kann ich auch lokal testen.
Da wäre letztlich so die Frage, wie funktioniert mein Update-Mechanismus?
Ja, also warum willst du das auf Produktion testen und nicht lokal?
Ja, weil dich ja 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 als quasi Integrationstest?
Ungefähr, ja.
und das kann ja sein, dass beim Staging-System, 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.
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, diese Facts muss ich ja irgendwie dann zwischenspeichern, weil das ist ja ein Alter-Fact 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 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.
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
ein Playbook ändern.
Das ist genau was, was wir am Anfang hatten. Du sagst halt,
wenn ich jetzt Latest eingebe, dann ist Latest
in zwei Monaten nicht mehr Latest.
Genau, also wenn ich dann über das Playbook nochmal
laufen lasse, dann guckt er, gibt es 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 sich diese Facts, was war denn jetzt Latest, irgendwie rausschreiben, also diesen State.
Muss man sich irgendwie merken, um den Reproduzierwert 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.
Ich verstehe,
wofür du das machen willst.
Aber ich
habe auch schon gehört, dass Leute eben,
das ist ja alles irgendwie auch
Infrastructure as a Code
Geschichte, dass man halt auch
diese komplette Infrastruktur irgendwie testbar machen
können will.
Aber ich weiß nicht, will man das wirklich?
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, Version
so und so viel von meinem Projekt installiert.
und ich möchte jetzt auf meinem Staging-System
testen können, oder das muss ja gar nicht das Staging-System
sein, 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. Das ist aber im Grunde
ein Test
deines Systems. Genau, das würde
man ja dann einfach machen und gucken, ob es geht.
Das Problem ist halt,
wenn du das Update 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 dann
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 weiß nicht, ob es anders geht
Ich würde versuchen, das zu vermeiden
Aber wie vermeidest du das?
Nämlich die Tests halt in der Applikation
laufen lassen. Ja gut, aber dann weißt du, ob deine Applikation
funktioniert und nicht, ob deine Serverinfrastruktur funktioniert
Ja, wenn man jetzt ins Fast-Fact-Rabot geht, dann
weiß ich, habe ich einen neuen Test für meine Applikation
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, also die Frage ist halt
Du musst halt diese Staging-Umgebung, 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, dass Leute halt auch Tests eben
gegen, sie 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 seine Entwicklung total langsam, weil
allein das Hochziehen von dem Kram und auch
ehrlich gesagt, ich finde Ansible ist halt schon, also
bei mir, ich glaube vielleicht mache ich irgendwas ganz falsch,
langsam. Also das dauert Minuten.
Die ICT macht es langsam, also es dauert eher länger als
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
und Jochen unterhalten sich über die Programmiersprache Python
eine Sache, warum Azure nervig ist.
Ja, überhaupt nicht.
Aber die Frage ist, was würdest du denn sagen, was wäre denn die Lösung
von diesem Problem? Also für mich,
ich weiß natürlich nicht, ob das immer geht, aber ich würde
sagen, man schiebt die Tests in die
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 diesen
Fileswerving auch gemacht habe,
Also, das ist auch bei dem jetzigen
Python-Podcast ist es so, die Files kommen von
S3.
Aber das Problem ist jetzt natürlich,
wenn ich jetzt Files
gerne hätte, wo Leute sich authentifizieren müssen,
um sie 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 Engine X zum Beispiel
da mitgibt
Wenn es über S3 geht, ist es S3, aber das S3 ist sozusagen nur das
Backend für CloudFront, für so ein CDN
Jetzt ist halt die Frage, okay, wenn es über ein CDN geht, das geht ja nicht über dein Engine X
sondern das geht ja außenrum
So, jetzt kannst du, gibt's ja natürlich schon gewisse, du kannst die URLs so generieren, dass die halt signiert sind zum Beispiel. Und dann kannst du dem S3 bzw. CloudFront oder wie auch immer sagen, ah, die URL muss aber signiert sein und die Signaturen sind nur für so und so lange gültig oder du musst halt irgendwie Cookies setzen. Es gibt ja diverse Möglichkeiten, wie man sich authentifizieren kann.
Aber das Problem ist jetzt natürlich, wenn du
darauf angewiesen bist, dass das wirklich funktioniert,
musst du das ja eigentlich testen.
Du musst ja sagen, okay, wenn jetzt jemand hier
im Django-Admin gesagt hat,
da darf keiner, da darf nur ein Autorifizierter
darauf zugreifen, dann muss man diese Logik irgendwie
testen können. Aber wenn die
tatsächliche Überprüfung irgendwie
in CloudFront stattfindet,
dann kannst du das nicht mehr gut
testen, ohne dass du
tatsächlich irgendwie das nach CloudFront hochschiebst,
irgendwie deine Einstellungen machst.
Du musst jetzt natürlich dann einen Mock dafür machen.
Ja, aber das ist ja
das ist genau
Jetzt kommt der Punkt, warum dann Leute
genau das gleiche
Szenario quasi, wenn Leute
sagen so, ja und wir ziehen unsere Infrastruktur
ja per Terraform hoch und das ist ja
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, muss man das irgendwie
so und so konfigurieren, dass das geht oder eben
Authentifizierung und jetzt schieben wir das Ganze nach Azure
und jetzt
hat irgendjemand in der Terraform-Config
irgendwie diese komische Konfiguration
für AWS oder so gesehen, wie man das macht,
hat sich gedacht 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.
Und jetzt müssen alle Clients plötzlich irgendwie alle Files
immer komplett holen, weil ByteRange
wird jetzt nicht mehr gehen und
wie zum Beispiel bei Podcast oder PodcastPlayer
holen sich immer nur Teile,
wenn das Teilformat das unterstützt.
Und ja,
das ist in der Produktion dann unterbestimmt eine riesen
Katastrophe, wenn das halt abgeschaltet ist und nicht mehr geht.
Das heißt eigentlich, wenn du solche Sachen
da drin hast, dass halt
Teile der
Features deiner Applikation sozusagen
darin bestehen, dass du dein
ObjectStore
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 würde man auf gar keinen Fall
machen. Für mich klingt das nach einem Plädoyer,
ich software meine Files selber,
ich mache das nicht bei einem CDN.
Aber erst mal als Beispiel.
Dann kann ich so eine Applikation testen.
Aber du müsstest deine Byte-Request-Tests tatsächlich testen mit AWS?
Nein, muss ich nicht.
Du hast jetzt bei AWS.
Okay, aber dann wäre der Test, wenn du den hättest, würdest du halt merken, wenn jemand ein Update fährt und das geht dann nicht mehr.
Aber das würdest du nur mit meinem Update vielleicht.
Naja, es ist halt furchtbar.
Wie würdest du es denn machen?
Also ich würde sagen, 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 serve die
Requests halt selber und teste
das halt auch, dass die Byte-Range-Requests halt gehen
und dass Authentifizierung geht, lokal, ohne
irgendein CDN. Und ich benutze
dann halt eben kein CDN für diese Art von,
also vielleicht benutze ich ein CDN für Sachen, wo es egal ist,
wo ich keine Konfiguration brauche, aber für die Sachen,
wo ich halt irgendwie Spezialkonfigurationen brauche,
nehme ich halt kein CDN, sondern
serve es halt direkt.
Okay, aber das ist eine Entscheidung, die an deine Stelle
kommen muss. Das macht mich
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
ist halt die Frage.
Ich weiß nicht, ob es auch
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.
3,5 Stunden.
Aber letztlich muss man dann auch überlegen,
sind diese Dateien so wichtig, dass ich mir 3,5 Stunden
Zeit nehme, damit ich
halt absolut sicher bin?
Ja.
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.
Ja, natürlich.
Und vielleicht kann man dann auch überlegen, okay, ich habe jetzt in dem Bereich nichts gemacht, da reicht so die normalen Tests.
Ja.
Ja, ja, also.
Ja, okay.
Testing haben wir ja. Okay, aber
vielleicht nochmal Man kann Molek gibt es bei Enzebel oder Assertions Achso ich meine ich schreibe keine Tests f die Enzebel 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, bei Enzebel-Sachen ist, ich mache Assertions
am Anfang, so ein paar,
die dann halt mir um die Ohren fliegen, weil es sich relativ schnell
funktioniert, also nicht ein wahrteiliges 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, um 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.
Okay, interessant.
Mit Vagrant testen?
Was ist mit Molecule? Kennt ihr das?
Ist auch so
Endable-Molecule-Testing, da kann man
Testmodule schreiben, die man dann irgendwie reinsetzt
in seinen,
ja, wenn man jetzt so selber Ensemble-Module
schreibt, dann kann man das irgendwie machen.
Müssen wir vielleicht nochmal nachgucken. Genau, also in die
Verlegenheit bin ich bisher noch nicht gekommen, weil es gibt
echt viel, was man letztlich,
was es schon gibt.
Und wenn es das nicht
gibt, am Ende setze ich dann einfach ein Command
ab. Ja, okay, das ist halt
tatsächlich die Frage, weil es gibt halt viele,
viele Buildings von Ensemble, also Ensemble-Building
irgendwas, ermöglicht einem relativ viel,
Kommandos auch dann.
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
Befehlszeilen ausgibt. Da könnte
man ja selber sich ein Enable-Modul verschreiben
in Python, was dann quasi ein
Abstraktionslayer drüber schreibt, wo man dann
ein eigenes Enable-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 Shell-Kommandos,
die man halt ausführen kann. Genau.
Und ja, dann hat man sich überlegt, okay,
am Ende
wird eine SSH-Verbindung aufgemacht
und ein Shell-Kommando abgesetzt.
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
man komplex sagt, 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 wegabstrichelt 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.
Also, 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 das mit der Teamgröße zu tun. Also wie viele Anwender von deinem Ende-Bim-Modul gibt es zum Beispiel intern, in dem du was machen willst und wie viele Leuten kannst du da Arbeit erleichtern oder sowas.
Ja, dann
ich glaube, was noch fehlt,
jetzt nur noch nach meiner Liste,
sind die Secrets und wie man mit Secrets umgeht
und wo man die 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 Ansible Vault
und da kann ich dann letztlich
einen beliebigen String
verschlüsseln gegen ein Passwort
und bekomme dann halt
das Secret rausgeworfen,
das kann ich dann in meinen Playbook reinpacken,
dann kann ich das
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
auch wieder ins Inventory schreiben
zum Entschlüsseln, aber dann
bin ich wieder bei dieser Debatte.
Sollte ich
unter welchen Umständen sollte ich Geheimnisse
in meine Repos einchecken?
Das ist ja spannend. 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
.env oder was auch immer und da muss man halt wenigstens hingehen
und das für den Zeitraum, wo man die Befehle ausführt,
dann entschlüsseln, aufmachen und
dann da reinschieben. Dann muss man halt auch fassen, dass es irgendwo
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, also da gibt es...
Also jede Maschine, die es ausführt, weiß es.
Genau.
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...
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,
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 damit Angreifern aber auch extrem
einfach, weil
eigentlich muss ein Angreifer, wenn er weiß, dass du das so machst
oder ich meine eigentlich, das ist halt das erste, was man dann tut
als Angreifer, einfach mal das Environment
nehmen, weil das ist ja super einfach zu lesen
wenn du halt das Gehaft 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 das erste, was ein Angreifer macht
Ja, wenn man bei GitHub danach sucht, da gibt es dann
einige
gesquattete
Raypos, 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 aber
in Projekten, wo ich Pydentic habe,
mache ich es meistens mit Base-Settings oder so, wo es
dann halt aus einem File gelesen wird und man das halt
wissen muss und importieren muss und das ist halt schon mal
so ein automatisierter Angriff funktioniert.
Und dann diese Base-Settings werden dann in
Environment-Variablen geschrieben.
Am Ende 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
und 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
geändert habe.
Ich wurde gezwungen von der Konzern-Security,
für den Konzern, für den ich was gemacht habe,
eben nicht direkt Environment Variables
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 von mir war aber, es wurde dann doch wieder
da als Environment Variable in diese Container
reingeschrieben. Das heißt,
das Ergebnis war dasselbe, nur dass ich zwischendurch
noch ein paar extra Schritte gehen musste, wo
und Jochen unterhalten sich über die Programmiersprache Python
haben, was man überhaupt tut, bevor man irgendwie die Regeln in FOS statisch irgendwie...
Ja, aber das steht so in der Policy,
das machen wir so. Ja, genau, das ist ITIL.
Irgendwer hat einen ITIL-Prozess definiert, wo das drinsteht,
wie man das macht.
Also ich kann ja einfach sagen, wie ist das? Also ich check
tatsächlich die Secrets
irgendwie mit ein, auch in
öffentlichen Repos und da
braucht man halt dann eben eine entsprechende Passphrase.
Also was ich mir vorstelle, was man noch da verbessern
könnte, weil momentan ist halt das Problem, okay, wie schnell
verhält man denn das
Passwort oder das Wohlpasswort, das man
dafür braucht halt.
Ja gut.
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 die Yubi-Keys zu verschicken.
Ja.
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 Yubi-Keys, 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.
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
das angucken
kannst und dann geht es halt auf
so zum Beispiel
oder YubiKey oder so.
Also ich finde die Kombination cool. Auf dem Telefon geht auch
halt mal bitte an das Telefon in YubiKey.
Ja, irgendwie sowas.
Ja, da könnte man dann auch gleich überlegen,
mache ich das vielleicht auf der Ebene von SSH,
dass ich den Zwei-Faktor-SSH mache?
Gibt es auch eine Lösung?
Da geht es auch mit YubiKey übrigens.
Da habe ich letztens irgendwie, der Johannes hat das so gelinkt,
so einen Artikel in seinen Weak News.
Ja, ja.
Ja, genau.
Wem musst du vertrauen?
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 zugefahren.
Das macht halt sonst keinen Sinn, wenn du jedes Mal irgendwie
einen Antrag stellen musst und in drei Tagen warten musst.
Für mich wäre das 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 so etwas gibt.
Ja, also die YubiKeys,
ja, die soll
also an sich, diese ganzen
Hardware-Schlüssel sind kopiergeschützt.
Ja, also
wenn einer rausfindet, wie es geht.
Wenn ich halt jemanden dann sage, okay, wir treffen uns,
oder ich schicke ihn per Postakku,
da fängst du dann an,
wer hat dann den Zugriff auf diese ganzen Sachen.
Aber wenn man den halt dann
abgeben kann, dann ist das schon
relativ sicher, okay, dass ich jetzt in meiner Chain
dann nur die Leute anwenden, die diesen
Schlüssel auch von mir bekommen haben.
Das ist ja schon mal ein Vorteil.
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...
Ja, genau.
Geht ja auch relativ fix, so eine CA
aufzustellen. Die sicher zu halten, ist
wieder schwierig. Ja, das ist absolut super. Wir haben auch so eine
Root CA, die sich selbst definiert hat und
die dann die ganzen Zertifikate mit raus...
Warum macht ihr denn den Scheiß drauf?
Ja.
Ja, ja.
Das ist Security auch. 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.
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,
da steht dieser ursprüngliche Schlüssel drin und der ist dann
noch, ne?
Ja.
Och, ja, ja.
Es ist schwierig.
Ja, das
einen spannenden Aspekt, den wir
noch nicht so beleuchtet haben. Also wir haben ja
auch viel über Docker gesprochen
und dass das so, ja, vielleicht
auch Ansible verdrängt. Aber
was Ansible jetzt viel macht, ist
in die Network Automation
reinzugehen. Das heißt,
ja, alle großen Anbieter, die bieten
jetzt auch Ansible-Module an. Das heißt,
ich kann letztlich Cisco
Switch mit Ansible konfigurieren.
Das sind interessante Sachen.
und alles, was relativ groß ist, Palo Alto, Unipy, Nokia,
die lassen sich jetzt über Ansible ansprechen.
Und 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 für Rennmal.
Genau, Ansible definiert mir hier jetzt mal, welche IP-Adressen wohin und welche VLAN es gibt.
und das ist schöner,
als das alles mit der Hand einmal einzupicken.
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.
Das sollte man nicht machen.
Klar, das ist natürlich,
davon muss man irgendwie weg.
Also ich finde,
also prinzipiell, dass das halt alles
in Repositories drin ist und die
Änderungen getrackt werden und man
auch den Stand wieder reproduzieren kann.
Das sind alles super Sachen.
Das will man eigentlich schon haben.
Aber
gut, bei Testen wäre ich mir jetzt...
Ich kann mir auch vorstellen, dass es Situationen gibt, wo man das
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.
Du musst es halt wie bei Ronny machen. Sobald
die Coverage bei deinem Commit runtergeht
oder bei deinem Pull-Request, wird er direkt
by the Night.
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 ist manchmal ganz praktisch.
Also auf einer Maschine oder auf
an den anderen Posts.
Für den Task zum Beispiel.
Aber die Task auf einer Maschine parallel, in verschiedenen Prozessen?
Ja, du kannst, ja, oder
auf einer Maschine.
Ja, genau, das wollte ich gerade fragen.
Ja, klar, also du hast die Parallelität über
unterschiedliche Maschinen, nicht 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.
Ja, kann man auch so Waitpoints machen?
Keine Ahnung, du musst jetzt aber warten, bis das und das
und das fertig ist.
und
Geschichten nicht funktioniert haben
und das geht ja alles.
Also das kannst du ja nicht schaffen.
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 Name Server 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.
Aber ja,
man läuft halt dann halt
wirklich diese unschönen Probleme rein
und es wird auch nicht schöner.
Achso, jetzt richtig, jetzt weiß ich wieder, was ich sagen wollte.
Genau, also
einer der Gründe, warum ich 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 Incivil auch sagen,
das habe ich halt noch nicht gemacht, aber
sollte 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 nennt man das, Jump-Hose
bauen, die dann irgendwie bestimmte Sachen vorbereiten
und ausführen und dann da
so eine Art Date-Warein haben.
Ich kann einfach gegen den Hetzener DNS zum Beispiel
fragen, so, wie sieht's
hier aus und dann gibt er mir das als
Inventory.
Also
da gibt es verschiedene Plugins
AWS, Docker, Kubernetes,
Proxmox
und noch viele mehr.
Was ist Proxmox?
Das ist auch eine
Virtualisierungsumgebung, also eher wie
ein
Hardwarehost,
der einem halt dann
verschiedene
so wie früher
vor MWR.
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 eine Textausgabe, wenn man einfach
Ansible so auf der Kommando-Zelle 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. Okay, dann weißt du halt, in welcher State
gerade ist und wo ist denn das gerade und wie weit ist denn das?
Und vor allen Dingen habe ich an der Stelle auch eine sehr schöne Abstraktion,
wo ich das ja 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 Boxinen,
die verwenden ja, die hatten Ansible
lange Zeit verwendet und sind
dann auf was anderes umgestiegen.
Weißt du was?
Ich habe es wieder vergessen. Ich wusste es mal.
Okay, der Jens hat irgendwas Eigenes gebaut.
Nee, nee, aber ja, oder er hat
irgendwas Eigenes, ich weiß es nicht mehr genau.
Jedenfalls,
genau, also vielleicht will ich ja auf irgendwas anderes umsteigen,
aber ich kann ja diesen
JSON-Layer halt sozusagen
erhalten, dann muss ich an meinem
quasi Deployment-Überwachungstool
muss ich überhaupt nichts mehr ändern,
muss ich überhaupt nichts ändern, das läuft einfach so weiter
und ich habe unten drunter kann ich das Ansible austauschen
und also das finde ich ganz nett,
dass man das weiß, dass das geht, dass man nicht
irgendwie Ansible Tower oder so verwenden muss,
weil das war auch sowas, nicht?
Was ist Ansible Tower?
Ah ja, gut, stimmt, das müssen wir noch machen.
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
und 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 zu der Enterprise-Variante.
Genau, und die Enterprise-Preise werden auch nicht angezeigt auf der Webseite.
Gut, aber theoretisch könnte man sich auch eigentlich so einen eigenen Server per Enzel konfigurieren,
der dann Kontos laufen lässt.
Genau, also Enzible Tower an sich, wenn man es gehostet laufen lässt, ist auch teuer.
kann es auch selber aufsetzen
aber
habe ich bisher noch nie geschafft
komischerweise ist es auch ein Docker-Container
und kein Ansible-Playbook
hätte ich jetzt eher erwartet
Dogfood
aber warum macht man dann nicht so etwas wie einfach Conjobs auf einem
Bare Metal
der Ansible-Tower
gibt ja natürlich noch eine schöne Web-Oberfläche
die dann die Logs einfängt
und alles sagt
kann man ja auch alles selber bauen
und wie so ein Grafana-Problem ist.
Ja, alles selber bauen ist natürlich
auch immer eine gute Zeitsenkung.
Ja, ich habe es getan und
ja, es war dann sehr, ich konnte
quasi beliebig viel Zeit dran senken, 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, wir können mal gucken, ob ich das hier...
Das ist natürlich so im...
Ja, aber ich hatte auch...
Bei mir heißt das Steward. Ich habe mir überlegt,
ich muss die ganze Nacht nach Schiffen nennen.
Die Server heißen alle nach Planeten und die Dinge
Steward, Lieutenant, also ich gehe nach denen.
Ja, genau.
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?
Es muss ja hinreichend
geheim und...
Wer muss das nennen?
Ja, aber ich habe im Grunde sowas wie ein Tower, das macht nicht, dass das Tower macht, sondern noch ein bisschen mehr und andere Dinge, aber es ist halt tatsächlich sehr ähnlich.
Ich kann richtig gut User Interfaces.
Nee, gar nicht. Das sieht man hier auch.
Aber das macht halt genau sowas.
Das kann halt eben
diese Dinge, das kann er direkt live einzeigen,
was da halt passiert. Und was ich halt damit auch
machen kann, ich kann halt
Playbooks, die deployen halt,
also wenn ich jetzt zum Beispiel Hosting machen will
für andere Leute, dann kann ich dem 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 FastAPI,
weil...
Ja, wird ja auch gehen.
Ja, weil damit halt alles schön async ist, weil das Problem ist,
wenn 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 HTMLX nehmen, aber
ja,
ja genau,
ich habe ganz viele langlaufende Sachen,
die parallel, wo Dinge so, dann nehme ich
doch irgendwie native async alles.
Ja, hat
viel mehr Zeit gekostet, als ich jetzt
gedacht hätte. Oh,
kurzer Exkurs, ja, also
und
noch nicht so lange, aber ich habe da schon
sehr üble Tracebacks
aus den Internas von SQL Alchemy gesehen,
wo ich mir dachte, so häufig
solche Sachen wie
an diese Stelle solltest du niemals kommen,
hier versuchen gerade zwei,
eine Connection wird von zwei unterschiedlichen
Routinen benutzt oder so,
hier ist irgendwas furchtbar schiefgelaufen,
tschüss.
Und das ist irgendwie häufig passiert,
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,
die Session muss man auch aufmachen und dann auf dieser Session
hat man halt irgendwie noch Transaktionen.
Diese Transaktionen können dann natürlich noch mal genestet sein und all diese
Dinge, die man 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 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 inkonsistent und dann Engine aufmachen
Engine zumachen ist dann halt Engine Dispose, Connection
ist aber Connection Closed. Session
ist wieder auch Session Closed, glaube ich.
Aber es ist halt immer unterschiedlich.
Man muss halt so einen kompletten Tanz
da irgendwie machen.
Wenn man das aufmacht und wieder zumacht und
an welcher Stelle macht man jetzt was
und was darf global im Prozess
leben und was muss man aber für jeden
Request da reinkommen, neu machen.
Das ist kein Spaß.
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.
Also, ja.
Kurze Plädoyer für Django.
Ja gut, bei Django geht das halt noch gar nicht, was ich da jetzt gemacht habe.
Insofern kann man nicht sagen,
nehmt einfach Django, dann habt ihr das Problem nicht,
sondern dann habt ihr auch die Lösung nicht.
Aber es war schon, also das war,
es hat mich schon so ein bisschen,
also ich fand es schwierig.
Ja, es funktioniert jetzt, halbwegs hoffe ich.
Das hat ja auch doch irgendwo Gegengarum mitgebracht.
Ich mache jetzt einfach tatsächlich alles
pro Request.
Wie man einfach die Konfidenz abnimmt.
Die länger man drüber nachdenkt.
Ja, ja, ja.
Aber ja.
Also ich würde fast sagen, das war das Schlusswort zu der Ensebel-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 Ensebel anzusehen,
ist auch sehr schön.
Weil da ist es noch sehr einfach
und man sieht, okay,
Ensebel 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, den muss ich unbedingt mal machen.
Wenn ja auch in der Show-Note direkt linken, würde ich sagen.
Ja, genau.
Ja, gab es noch was zu Ensebel?
Ansonsten können wir auch Pics machen.
Ich würde mit dem Pix-Scan anfangen.
Okay.
Und zwar habe ich auch eben was vergessen bei Europython, was ich noch
mitnehmen wollte, und zwar das
Evis Project. Kennt das von euch jemand?
Oh ja, das habe ich.
Das ist sehr hübsch. Das ist geschrieben
von Wes McKinney, auch
die neue Company.
Das ist so ein Absalationsinterface
auf, ich würde sagen, also Art von SQL,
in dem man halt so Datenmagerfragen machen kann
auf Postgres, 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,
und 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 Data Frames macht, irgendwie so eager.
Also Pandas ist sowieso, das muss man auch verdenken, es gab da so einen schönen Talk von Matthew Rocklin,
der Maintainer von Pandas, der sagt, 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 Wes Van Pini, dem ursprünglichen Autor von Pandas
für kleine Datenmengen funktioniert es, aber wenn es jetzt mehrere Zehn Gigabyte
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 Nampai und ganz viel und
der hat dann Pandas 2.0 quasi angeschartet und das ist aber nie zu
irgendwas geworden.
Aber das eigentliche Pandas-Projekt steht
jetzt wieder an der gleichen Stelle sozusagen und man muss sich halt
überlegen, was man macht. Und ein großer Unterschied zu
anderen Geschichten ist halt, dass es so etwas 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 Riesengruten.
Genau, mit Spark und so, da kann man das alles machen.
Oder mit Das geht das natürlich auch.
aber fangen das selber halt nicht.
Und Ibis ist genau das, der Rappertra von Python,
dass du halt mit das und die ganzen Sachen da einfach
alles drauf zugreifen kannst und es benutzen kannst.
Superschönes Python High-Level-Interface.
Es kommt natürlich bekannt vor,
also für eine Funktion.
Ja, genau, da gibt es
diese Firma hinter
ist das Cloudera?
Ich glaube, das war da mal eine Zeit lang.
Da hat er dieses Projekt auch gestartet, weil
ich habe sich das zum ersten Mal vernetzt,
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 die
mit riesigen SQL-Statements.
Wenn du jetzt eigentlich aber das
in Python machen möchtest, also ich kam da halt
als Python-Entwickler und die
machten alle irgendwie SQL vor allen Dingen
um Sachen aus
riesigen Hadoop-Cluster und
dann SQL-Abfragen
und die gehen dann per Hive,
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 den 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 wäre alles ganz schrecklich und die saßen
das war auch so eine Situation, also
wo ich mir denke,
wie könnt ihr ja, das ist ja
irgendwie, wie könnt ihr so leben?
Das geht doch nicht, dass wir so, okay,
jetzt schieße ich diesen Hype-Job ab, dann gehe ich erst mal Mittagessen,
weil das dauert jetzt erst mal anderthalb Stunden oder so, keine Ahnung.
Ja, aber das geht doch nicht.
und ja, für die ging das irgendwie.
Ich hab gedacht, was soll man den ganzen Tag machen?
Ja, gut.
Also man muss halt nicht so viel
arbeiten, wenn dann Python ist ja superproduktiv.
Ja, oder dann halt eben dann auch
diese komischen Zwischenschritte
und Dinge und dass man halt irgendwie so
komisch kommt 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.
Ich hab immer noch nicht verstanden was das wirklich tut Dann ist das schon schlimm aber man hat so Dinge hat mehrere hundert Zeilen und dann macht das so Core wo man sich denkt wenn da irgendwo ein Fehler drin ist Und das ist so kompliziert
also wenn das Code wäre,
das muss ausgiebig getestet werden.
Und 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 von Impala
war, irgendwas direkt abfragen konnte und dann
und Data Friends freimachen.
Ja.
Ja, das war mein Pick der Woche.
Ja, sehr schön.
Hast du noch 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 Kontextvariable holen,
das da reinschreiben und dann rausschicken.
So Mixed-Sense-Bound für sowas oder so.
Genau, erspart. Ungefähr so drei
Zellen Code.
Aber Software-Ergonomie ist halt
dann schön.
Das andere Thema ist
Xonj. Das ist eine
Python-Shell.
Da schreibt man halt nicht Bash, da schreibt
man dann Python.
Das kann man gut und schlecht finden,
aber ich finde es eigentlich sehr
sch denn da kann ich dann auch wie gewohnt in Python dr loopen Ist das dein Default Ja meine Default Genau ich kann da letztlich alle Commands die ich in der
Shell habe, 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 mal angucken. Das klingt sehr gut.
Ja, ich muss das irgendwie kombinieren.
Es gibt übrigens auch ein Terminal, jedenfalls auf dem Mac.
Es 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.
Ja, super, super.
Cool.
Macht es nur nicht als Root-Prompt,
wenn die dann kaputt geht.
Da kommt man nicht mehr weiter.
Ja gut, ne?
Ändert man die Shadowfile.
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 WeakNote, haben wir nochmal verlegt.
Ja, er hat einen ganz tollen WeakNote, das 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,
hat er irgendwie geschrieben, so, ah ja, er hat irgendwie
einen Weg gefunden, irgendwas mit S3 zu machen
und dann habe ich da reingeguckt in den Kunden und dachte so, hä?
Also ich habe 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 es halt nicht sondern
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 WIS-Kontextmanagern,
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 PyTestMock 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 Context Manager
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 geunpatched
sozusagen automatisch, weil es ist ja
irgendwie über die 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 mache dann auch noch einen zweiten Blick, weil
wenn Tests nicht laufen, dann macht man einfach
Pip in zwei Fuckit-Dekorator drüber.
Dann macht der zwei Exemplars und läuft alles
wunderschön. Sehr schön.
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
und schreibt uns E-Mails an
helloatpythonpodcast.de
Danke Jochen, danke Max
auf Wiederhören