Transcript: Ansible

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Paisen-Podcast, Episode 44.

Heute soll es gehen um Enzebel.

Hi Jochen.

Herzlich willkommen Dominik.

Oh meine Güte, das geht ja schon holprig los.

Heute ist der Max dabei.

Ein bisschen Pause gemacht und schon geht nichts mehr.

Und der Max, natürlich, hallo, willkommen.

Hallo, heute bin ich dabei.

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

Jochen, was hast du denn für News?

Ja, was hatte ich, es ist eine ganze Menge passiert, wurden ja auch schon auf Twitter,

Jetzt war es ein bisschen Sommerloch.

Ja, und aber auch schon angehauen,

dass wir doch mal wieder was machen sollen.

Genau, machen wir jetzt auch wieder was.

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

Daher egal.

Eine wichtige Geschichte war das Release von Django 4.1.

Das ist auch noch gar nicht so lange her.

Das ist sehr nett.

Also sowieso in letzter Zeit die ganzen Django-Releases

finde ich sehr...

Es wirkt nicht so

bombastisch irgendwie,

was da drin passiert, aber es sind halt

solide Verbesserungen und eigentlich

kommen jetzt so die ganzen netten Dinge, die halt

irgendwie man machen kann, wenn man halt so ein stabiles

Fundament hat und alles gut läuft und das

ist halt großartig.

Was diesmal dabei ist, also das was

ja, das Ding ist auch auf Erkan News

irgendwie auf die Start, direkt

auf die Frontpage da gekommen und

da haben alle irgendwie angefangen zu diskutieren über

Async-Datenbank-Interface.

Ja, ich

würde jetzt sagen, das ist halt so ein längerer Prozess, also

von irgendwie, es gibt

ASGI zu

irgendwie, man kann Async-Views schreiben,

zu irgendwann werden wir auch komplett

irgendwie alles Async haben.

Das wird noch eine ganze Zeit lang dauern, also ich rechne

da ehrlich gesagt nicht mit, dass das vor

einem Jahr oder so möglich wird.

Aber ein Jahr ist auch gar nicht so, ne?

Bitte? Ein Jahr ist auch gar nicht so, ne? Ja, stimmt, stimmt.

Letztes Jahr ist auch quasi gestern, das stimmt schon.

Insofern, ja.

Aber wenn man jetzt überlegt, wann haben wir

den Artikel über... Letzten Sommer.

Das war nicht letzten Sommer. Doch, das war

letzten Sommer. Ne, ne, ich meine, das war 2020,

oder? Das war zwei Jahre schon.

Ich meine, das ist zwei Jahre her.

Oh, ja, okay.

Ups. Ja.

Letzten Sommer war was anderes.

Wenn ich überlege, letzten Sommer war

DjangoCon EU 2021,

damit hatte ich da, also das muss

zwei Jahre her gewesen sein. Sozusagen von da

bis jetzt hat es halt zwei Jahre gedauert

und also wir sind halt noch lange nicht da.

Daher, es wird noch eine ganze Zeit dauern.

Aber jetzt ist zumindest halt

das Interface irgendwie fix und das

bedeutet, wenn man jetzt sowas sagt wie

Wait-Query-Side-Filter irgendwas

oder so. Dann, wenn irgendwann

die ganzen anderen Dinge, die auch alle dann async werden müssen

und wo das dann funktionieren muss, alles

funktioniert, dann kriegt man einfach so

schnellere

Datenbankergebnisse, ohne dass man

was dafür tun muss. Und das ist natürlich sehr praktisch. Also insofern

jetzt kann man das halt schon so verwenden,

als wäre es da, aber es ist halt noch nicht da, weil

es gibt noch keine Unterstützung

für Psycho-PG3 oder

für Async-PG oder sowas daher.

Man kann, glaube ich, irgendwie Dinge machen

über ein Threadpool oder so, wenn man wirklich

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

Aber das ist halt noch nicht so wirklich

das richtige Ding.

Aber das war eine Geschichte.

Dann aber eigentlich die

interessanteren Features, weil die kann man halt schon wirklich benutzen

und die bringen einem was,

sind sowas wie Model Constraints.

Also wenn man

in einem Model festlegt, dass man irgendwie

bestimmte Check Constraints in der Datenbank

haben will. Also irgendwas darf nicht größer als so

und sowas sein oder der Wert

muss zwischen dem und dem liegen oder darf nichts anderes

sein als das oder so. Irgendwas rauben wir mal

für Constraints da. Kleine Validierung, ja.

Dann war es halt früher so, da musste man

das halt in den Model-Formen nochmal mit

nochmal validieren,

damit das wirklich funktioniert.

Ansonsten hat das Formen gesagt,

alles okay und dann, wenn das

wenn der View oder was auch immer

oder das Formen versucht, das in den Datenbank zu schreiben,

gibt es einen Integrity-Error.

Was natürlich ein bisschen kacke ist. Und jetzt ist es halt

so, dass man tatsächlich vom Formen auch

gesagt bekommt, nee, das geht so nicht, weil da ist

ein Constraint auf dem Model.

Das ist ja letztlich super angenehm,

weil vorher muss man selber checken

und meistens hat die Datenbank dann angefangen.

Mit Status Quotes vielleicht sogar.

Ja, und dann eigentlich die, also

ehrlich gesagt, aus meiner Perspektive die coolste

Neuerung, ich hab's mir jetzt noch nicht so richtig,

aber es klang schon alles sehr viel, sprechen das, was ich

gelesen habe, klang auch sehr, sehr gut.

Das coolste Feature ist halt,

also es hat sich viel an den Forms getan, auch in Django 4.0

hat sich schon einiges an den Formularen getan,

dass man halt an Formulare auch

dran schreiben kann. Also dieses Formular

wird gerendert über irgendwie

ein Template.

Und jetzt ist es halt komplett so, dass man auch

global einstellen kann,

quasi, welches

Template verwendet wird, um Formen zu rennern,

sodass man es gar nicht mehr unbedingt in jedem Formen einstellen

muss. Und ja, da gibt es

jede Menge, also es ist

deutlich flexibler geworden, wie man Formulare

rennern kann. Und damit, also das habe ich

noch nicht persönlich überprüft, aber ich fände es schön, wenn es so wäre,

weil ich habe Anfang des Jahres so ein bisschen was

mit Crispy Forms gemacht und so.

Ja, das war immer ein bisschen anstrengend.

Ja, ich habe es früher

immer nur so ein bisschen verwendet und so, und dann war es eigentlich

okay. Und dann habe ich da irgendwann mal so richtig

tief reingeguckt, weil ich dachte so, okay.

Weil es darum ging, das mit

Django HDMX, also mit HDMX

zusammen zu benutzen. Und dann hätte ich gern

halt nur, ich ändere ein

Feld, dann geht das,

gehen die Formulardaten an

einen View. Und dann möchte ich

eigentlich quasi nur das Feld zurückbekommen

und die Fehlermeldung, wenn da irgendwas

nicht validiert zum Beispiel. Aber das

heißt, ich muss halt irgendwie ein Feld

plus eine Fehlermeldung rendern.

In nested forms oder sowas.

in sehr komplizierten Formularen

und allein nur das zurückgeben

und um das hinzukriegen,

muss ich sehr, sehr tief in Crispy Forms reingucken,

wie das dann eigentlich funktioniert und so

und wie die ganzen Templates-Packs funktionieren

und ja, das war halt, da dachte ich mir,

oh mein Gott, das muss weg, das kann nicht so bleiben,

das ist alles schrecklich.

Wie heißt das? Form-Tweaks?

Ah, Django Form-Tweaks, ja.

Genau, das macht es ein bisschen schöner,

aber nimmt das Problem auch nicht so ganz weg.

Letztlich habe ich dann auch,

eigentlich habe ich auch so ein Riesentemplate,

was alles durchrendert,

also alles durchloopt

und dann letztlich

dann die EFAP-Fragen macht,

falls irgendwas irgendwo

schiefläuft. Aber das ist jetzt auch

einfacher, dadurch, dass man angeben kann, okay, ich will

jetzt dieses Template und man muss dann nicht mehr

sagen, okay, ich include

das Form. Ja, aber wie löst du da

das Problem, wenn du jetzt zum Beispiel quasi

HTMLX verwendest und sagst,

okay, wenn da jemand draufklickt,

dann wird das, eigentlich möchte ich nur

einen kleinen Teil austauschen, das geht dann ja wahrscheinlich nicht so einfach,

wenn du das Formular in einem großen

Template erinnerst?

Ja, du sagst ja, wohin das

soll, letztlich.

Und

da über den Response

kannst du dann letztlich

das ändern.

Also in den Dom dann direkt reingehen

und das dann an die Stelle packen.

Tatsächlich muss ich sagen, wenn ich dann

in so ein spezielleres Form gehe, was halt nicht so

0815 ist, dann

schreibe ich die auch komplett

von der Pike auf.

ich dann die meiste Kontrolle habe, weil mir da Django

einfach nicht so genug entgegenkommt.

Ja, ja, ja. Ich verstehe das durchaus.

Aber zum Beispiel den Fall, den wir

da hatten, der war halt,

dass es ganz viele unterschiedliche Formulare

gab, aber viele der Formularteile

waren halt gleich. Sodass man das eigentlich

so machen möchte, dass man sagen möchte, okay, dieser Teil

des Formulars, das ist so immer gleich

und die Logik, da ist eine Menge Logik hinter und so, den möchte

ich jetzt in unterschiedlichen Formularen irgendwie verwenden

können. Und aber auch nur diesen

Teil rendern und nicht das ganze Formular.

Und wenn da jemand was eingibt

und so. Also so quasi mehr in die

Component-Ebene rein. Ja.

Dann vielleicht ein eigenes Feld schreiben.

Und dann kann man sich das ja auch wieder

holen. Ja, das haben wir dann auch

gemacht. Ja, ja, klar. Genau, das wäre

dann auch mein Ansatz.

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

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

Genau, also angeblich braucht man das nicht mehr.

Angeblich braucht man Crispy Forms unter Umständen nicht mehr

und die ganzen Template-Packs nicht mehr. Und das kann man

jetzt alles selber machen. Und das klingt sehr gut,

weil das ist echt so ein...

Ja, da kann es schon leicht

schmerzhaft werden.

Ja, genau. More News?

Ansonsten

irgendwie, ja,

Pydentic 2 kommt jetzt,

also, beziehungsweise ist es noch nicht

released, aber das wird jetzt so allmählich

Richtung Release

geht das. Und also

du meintest ja auch schon mal so, genau,

Pydentic Core. Genau, Pydentic Core.

Rust-Implementierung und Rust, dass das

schnell wird. Ja.

Ja, ich,

Das ist ja, genau, also das ist halt

halt das Problem, also Pandentica hat auch so ein paar Probleme,

die in ganzen

Internals sind halt eher so ein bisschen

ja,

vielleicht nicht mehr dem

Verbreitungsgrad, wie das halt verwendet wird und so

angemessen und es ist halt auch

langsam, es ist sogar deutlich langsamer, als wenn man jetzt einfach

nur... Data Classes nimmt. Ja,

oder halt Data Classes

sind auch nochmal deutlich langsamer als

ganz normale Klassen, ja.

Ja, okay, oder Atis oder so, glaube ich, das kannst du

sagen. Ja.

und ja, das ist natürlich

irgendwie ein bisschen doof und

genau,

deswegen, das ist jetzt halt

in Rust neu implementiert, da waren auch so ein paar Sachen

dabei, habe ich jetzt letztens auch glaube ich einen Podcast

gehört, Talk Python to Me, letzte oder

vorletzte Episode, weiß ich nicht genau,

mit dem Autor von

Pydentic, Samuel Cohn,

hast du, ja,

und da sagte er so,

da waren ein paar, weil ich normalerweise

dann immer denke, so das erste, was man macht, wenn man es halt schon schnell

haben will, warum nimmt man nicht einfach Saiten?

und da hat er relativ ausführlich

darüber gesprochen, warum das jetzt für ihn nicht so

der gangbare Weg war und das fand ich ganz interessant,

weil er halt halt so, ja, also Zeiten

und so, das ist zwar schön, das geht zwar auch,

aber einmal ist halt so C

und es wird halt schon nach C kopiert

und dann

führt das halt dazu, dass die

Binarys riesig werden, weil da halt

irgendwie doch jede Menge

genau C hinterher kommt.

Und

das ist bei Rust wohl nicht,

da gibt es irgendwie dieses

Pyos3-Ding da, mit dem

man Rust-Geschichten

einbinden kann und das

macht halt...

Und die Binaries werden

halt deutlich kleiner und das ist natürlich schön,

weil dann, ja, das war nicht so...

Und es ist halt, genau...

Man kann halt alles wegputzen, was nicht gebraucht wird oder so,

glaube ich. Ja, und die

ganze Parsing-Logik ist jetzt bei

Paladin Decor komplett in Rust und

es ist halt auch gar nicht so, dass...

Bei Zeiten würde man halt sagen, okay, einige Teile

macht man halt dann einen C oder

schreibt man einen Zeiten, die dann nach C kompiliert wird und dann wieder

und da ist es so, das passiert halt alles

in Rust und am Schluss

werden halt Python-Objekte erzeugt, aber

man geht gar nicht den Umweg

sozusagen, da doppelt irgendwie

Sachen machen zu müssen.

Also ja, war auf jeden Fall sehr interessant und

da bin ich mal gespannt, wie das so wird, weil

ja, das ist auch immer sowas,

ja, wenn dann

Leute dann aus der Google-Ecke sagen oder so,

ja, wenn man mehrere, viele Datenbankzeilen

aus der Datenbank holt, dann ist er bei Python immer langsam.

Und ja, also wenn man Pydentik verwendet oder

irgendwie sonst wie ein ORM

und dann Objekte daraus erzeugt,

also bei Pydentik ist es noch schlimmer als bei

anderen ORMs, aber dann kann das

halt schon sehr langsam werden. Aber ich meine,

das ist halt die Frage. Wenn man

möchte, dass es schnell ist und Millionen Zahlen aus der Datenbank

holt, dann darf man halt nicht aus jeder Zahl ein Objekt

machen. Das ist halt dann nicht gut.

Und sonst zu langsam.

Ja, hast du noch weitere News?

Nee. Ich war auf der Europython.

Ja. Ja, das war natürlich ganz interessant.

Also total tolle Veranstaltung.

Da kann ich nur empfehlen, da teilzunehmen,

wenn man da die Möglichkeit so hat.

Das war in Dublin. Dublin ist natürlich auch

sehenswert. Da gibt es leckere

Getränke.

Aber aus der Python-Bestseitigkeit wäre das natürlich auch schön,

mal so ein bisschen die Leute zu hören

und verschiedene Sachen.

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

Und zwar hat der Patrick,

Patrick Arminio,

bei Strawberry einen netten Workshop gemacht.

Das war sehr schön und interessant zu hören.

Das war eine GraphQL-Schnittstelle,

die man einbauen kann. Das gibt es auch Strawberry

Django. Da kann man das halt direkt

als GraphQL-View quasi

benutzen. Sehr interessante Art

und Weise mit der Datenbank-Untrückgene kann man relativ

gut definieren, welche Queries möglich sind

auf die Datenbank und hat dann einen

Endpunkt, das Expose, den man dann halt

erfragen kann, um mal so ein bisschen

den Nutzer dieser API

direkt entscheiden zu lassen, was er denn haben will und muss dann halt nicht

die ganze Quad-Interface irgendwie implementieren.

Bei GraphQL habe ich immer so die Frage,

also ich muss ja das ganze Schema

schreiben und irgendwie habe

ich immer dann am Ende das Gefühl, ja, die

Django OM gibt mir das

aber eigentlich gratis, was ich dem rausgeben will.

Ja.

Ja, es ist so ein bisschen

mismatched zwischen,

man hat halt eigentlich das nochmal,

weil man irgendwie dem

Frontend halt so eine Art Datenbankinterface

zur Verfügung stellt. Es ist schon

so ein bisschen, ja, ich weiß auch nicht, also ich bin in letzter Zeit,

also ich hab auch mal eine Zeit lang irgendwie intensiv

GraphQL gemacht, meistens

dann halt Django und Graphene,

was dann halt, ja, das wird dann auch

manchmal so unerklärlich langsam und manchmal hat man so

Probleme, das rauszukriegen

dann, warum da, und ja,

das ist, glaube ich, hat auch diverse Designprobleme,

auch, ich glaube, der Autor von Graphene meinte dann

irgendwann, ach, ihr müsst das nochmal alles komplett neu schreiben,

und keine Ahnung. An den Punkt kommt man eigentlich immer.

Ja, natürlich.

Und ich weiß auch nicht,

ich weiß ehrlich gesagt nicht, ob

GraphQL überhaupt noch so eine, ich weiß es nicht,

ich habe letztens auch

kritische Stimmen gehört, in die Richtung.

Ja, Armin

Runacher, jetzt letztens auf Twitter, schrieb er dann so,

irgendwie, also, ach,

das war, glaube ich, oder war das der HTMX-Typ?

Ich bin mir nicht mehr sicher.

Der dann schrieb, naja, bedenke,

dass du, ach so, genau,

ich glaube, Amin Omar, also diese

GraphQL-Geschichte ist so unfassbar komplex und das wird

alles so, oh, wie ist

jemand jemals auf diese Idee gekommen,

das so zu machen? Und

darauf hat dann der

HTMX-Autor irgendwie geantwortet und meinte so, ja,

also bedenke immer, wenn du

so einen generischen Datenbank-Endpunkt

quasi deinem Frontend zur Verfügung

stellst. Du stellst den nicht nur deinem Freund

zur Verfügung, sondern auch allen anderen, inklusive

Leuten, die dich angreifen wollen. Ja, also du kannst

auf jeden Fall schon dusten damit. Das ist natürlich

extrem schwierig zu verhindern, dass

das nicht geht.

Also. Ja, ja.

Ja, also auf jeden Fall trotzdem

der Workshop war sehr interessant. Ja, aber es

sollte gut sein. Genau, das ist so ein bisschen

ähnlich von FastAPI, also ungefähr

vom Prinzip her viel mit modernen

Type-Ins und so.

Ja, dann gab es noch einen schönen Talk, das war auch

direkt am Anfang über

einen Blog-Eintrag von Peter Norweg

und zwar hat das Luciano Romano

das gemacht und so über Lisk-Screen-Parser

in Python, relativ kurz,

das gab so ein, weiß nicht wie lange das ist,

gelogen 70 Zeilen oder sowas

in Python, kompletter Lisk-Screen-Parser, was halt

irgendwie ganz cool ist, weil man da so ein bisschen versteht, wie so ein

Parser funktioniert und was so ein Ast ist

und weiß nicht, so ein Lisk-Screen-Parser ist ja relativ ähnlich

zu JavaScript, glaube ich, oder so, wie man dann Tugends

baut und Funktionen baut irgendwie und

fand ich ganz interessant, das mal so zu sehen,

auch mit Typefins und so versehen.

Ja, generell, wo

Python halt überall verwandt wird und verwendet wird.

Also James Webb Space Telescope

von der NASA, da war auch jemand da,

der dann sagte so, hey, wie denn die Bilder in Python

zur Erde geschickt werden und so. Das ist natürlich, dann

freut man sich immer, dass es so berühmte Anwendungsfälle gibt.

Die Lynn hat

einen sehr schönen Talk gemacht über Everyday RPs

von Spotify. Das ist eine

Entwicklerin, die da

einfach so einen netten Talk gemacht hat. Ich glaube,

so wie wir das auch machen, aber sie hat eine sehr hübsche Folie.

Können wir auch mal verlinken.

Genau. Da kann man sich

nochmal so angucken, wie man so APIs

designt, glaube ich, das fand ich ganz interessant.

Ah, ja.

Auch super, das war einer der,

für mich fand ich, das war so didaktisch besten Talks,

das war von Niall O'Connor, irgendwie über

Fibonacci-Retrace-Levels, Asset-Price-Prediction-Reverse

von der Bank of America.

Ja, der ist auch so rumgespringen,

hat die ganze Zeit über Resistances

gesprochen und da ist eigentlich immer

die Folie gewechselt, irgendwie jetzt

ein weiter, ein weiter, in so einem Run-We-Are-All-Dead

und dann klick, klick, klick, eine Folie nach dem anderen.

Das war super, ich fand es toll.

Muss man sich eigentlich wenigstens mal angucken.

Ich muss auch mal irgendwann so ein Trading-Bot bauen, keine Ahnung.

Was ich auch ganz cool war, war das Team von Huggingface war da.

Die haben ja dieses DALI gemacht.

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

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

Ich kann jetzt per DALI Bilder generieren.

Ja, cool, genau.

Ja, und das Coole ist, es gibt da einen Python-Wrapper drum, um Huggingface, der nennt sich Gradio.

Den kann man einfach installieren und dann kann man gerade sagen

Gradual Use, den Namen

dieses Machine Learning Modells und kann dann

direkt diese vortrainierten Modelle nehmen und die auf seine eigenen Daten

schmeißen und die auch annotieren und die Features

irgendwie anpassen. Das fand ich sehr nice, so zum

ausprobieren und so ganz schnell

Machine Learning innerhalb von kurzen Teilen bauen.

Das war sehr cool, sehr nice.

Ja,

da gab es noch so ein paar politische Talks über AI,

Dystopia und sowas, was man alles nicht mit Killer-Robotern

machen kann und so, wenn man sich das nochmal

angucken möchte, so die Argumentationen, die dahinter stecken.

dann darüber, wie man 3.11

jetzt schneller gemacht hat, hat

Max Schendler gesagt.

Das war auch sehr schön, also ein bisschen

C-Python wieder. Und da in dem Fall auch

Sam Gross von Facebook hat

was dazu gesagt, wie er Nogil macht.

Und wie das aussieht, dass man halt

in Python nicht mehr Nogil benutzen möchte.

Robin

habe ich gesehen, das ist ein neues Framework.

Ein asynchrones Python-Web-Framework,

das mit einer Rust-Runtime läuft.

Dann kannst du halt sowas wie UV-Con sparen

vorneweg und hast halt direkt diese

Rust-One-Time und es ist relativ, sag ich schnell,

wenn du relativ gute

Anforderungen hast. Ja, das ist auf jeden Fall eine interessante Idee.

Also ich meine, ich würde jetzt sagen,

also ob einem das so wahnsinnig viel hilft,

wenn man das jetzt in Rust, also das

Einzige, also ich meine, UV-Corn finde ich ja eigentlich schon ganz gut,

ist relativ schnell und so,

aber also zum Beispiel, wenn ich

Files ausliefere, also meine Benchmarks sagen so,

UV-Corn ist deutlich schneller, äh, deutlich langsamer

als sowas wie Nginx und so und ich weiß nicht, warum.

Ich habe keine Ahnung, wahrscheinlich müsst ihr ja mal tiefer reingucken,

was das eigentlich, warum das ist. Also bei dem Roboing

gibt es auf jeden Fall auch diese, so ein paar

Benchmarks. Ich weiß halt immer nicht, du bist ja immer bei Benchmarks immer ein bisschen

kritisch, wie gut die sind oder wie neutral die sind.

Ja, ja, es ist schwierig. Also, sagen wir mal so, es ist einfach schwierig, Benchmarks

so zu machen, dass sie halt etwas sagen,

dir Informationen darüber geben, was du

eigentlich wissen willst und nicht, dass du irgendwie

dein Benchmark-Tool gebenchmarked hast oder deine

CPU gebenchmarked hast oder den Speicherbus

gebildet hast. Es ist halt irgendwie, es kann

vielfältig schief gehen. Genau.

Ja, also jedenfalls, das war super interessant.

Achso, genau, ich hatte mal auch schon dieses Tempolastalk, da geht es halt

um Reference-Crouching auch, mit dem Nogel, dass man halt

dass er irgendwie das ersetzen kann.

Ja, dann

gab es noch ein Talk

über Jot. Fand ich ganz interessant. Da wusste ich noch nicht

alles drüber. Da haben die Jessica erzählt.

So ein bisschen nochmal

so die Details darüber,

was da für ein Payout drin ist und so weiter. Das war interessant.

Und noch der Luciano Romano

hat noch einen über Typing.

Ja, der hat ja jetzt, also überhaupt,

ich weiß nicht, ob der so bekannt ist,

der Name, wenn man den sagt,

ob der den Leuten direkt...

Das ist der Autor von Fluent Python.

Ganz lange Zeit schon eine Community

aktiv und also ich finde

Python ist halt auch so eines der besten

Python-Bücher, die so draußen sind.

Und davon gab es jetzt auch im Frühjahr irgendwie

eine zweite Ausgabe.

Und da ist eine der Neuerungen

ein Kapitel über Typing und das ist halt

super. Also ja, kann man

Genau, das meint er so, wie du dich das vorgestellt hast.

Das war bei der Talk

bei Typings as Guido intended.

Ah, okay. Weil das würde mich

jetzt mal interessieren, weil ich habe das,

also ich habe da so ein bisschen reingelesen, ich habe es noch nicht komplett gelesen,

aber so ein bisschen quer gelesen und ich

weiß auch sonst, was er darüber schon mal so geschrieben hat

und der war ja auch schon mal Gast in diversen Podcasts

und so und der ist ja auch eher

so ein bisschen kritisch gegenüber dieser ganzen Type-In

Geschichte. Er sagt so, meine Güte, das ist

halt irgendwie ein ganz schöner Aufwand, das zu lernen

und teilweise ist es ganz schön schwer.

Also das Beispiel, was ich jetzt auch schon ein paar

Mal gebracht habe mit Min und Max-Funktionen

und den Type-Annotationen, das kommt von

ihm. Ja, ich glaube, er hat gerade ein Protokoll

entwickelt, wie man das so machen kann. Also Type-In.protocol

macht er irgendwie, um solche Sachen zu lösen.

Das war ganz spannend.

Ja, super Search

mit OpenSearch, war noch ganz

interessant. Also OpenSearch als Elasticsearch

Fork, irgendwie mit Python

ein ganz schöner Talk dazu.

Dublin war toll, man konnte

auch an den Strand fahren, war super Wetter und

nette Leute kennengelernt, Gruß an Marlene.

Ja, sehr schön.

Das war eine super Veranstaltung. Kann ich empfehlen, das

nächstes Mal gerne wieder.

Nächstes Mal schaffe ich es vielleicht auch.

Gruß an Jan Hendrik auch, war auch sehr schön.

Ja.

Ja, habt ihr noch News?

Dann sind wir vielleicht endlich beim Thema.

Ja.

Das Thema ist nämlich heute Ansible.

Und ich würde sagen, jetzt ist auch der perfekte

Zeitpunkt für Max, dass Max sich vorstellt und

Hallo sagt. Ja, hallo.

Ich bin Max und

ja,

programmiere viel in

Python, mach viel mit Django,

bin bei

einer Compliance-Beratung. Wir kümmern uns

um Datenschutz, Qualitätsmanagement,

Arbeitssicherheit und

eigentlich stelle ich so den Beratern

die Tools zur Verfügung, damit die

weniger arbeiten müssen

und alles ein bisschen schöner

am Ende aussieht.

Und da setzen wir hauptsächlich

Python ein und haben natürlich auch

eine Ecke an Servern, die wir

dann mit Ansible bespielen.

Das heißt Ansible zur Server-Einrichtung.

Richtung. Genau, also

so, Ansible macht ja

Konfigurationsmanagement. Kennt ihr alle

Ansible? Ja, ich bin doch.

Was macht Ansible? Ja genau, Konfigurationsmanagement

heißt also, du rollst

irgendwas auf einem Server aus und sagst

dem, was das für ein Server sein soll und dann

macht Ansible die ganzen Skripts und die

Konfigurationen und die Einstellungen von der Kiste.

Genau, also Ansible

ist

deklarativ, das heißt, ich sage dem

Ansible nur, so soll das am Ende

aussehen und dann kümmert sich

das um

alles Weitere.

Ja.

Und das ist bei Anse,

also es gibt da natürlich viele verschiedene Tools,

die das halt machen. Da gibt es natürlich auch Chef und

Puppet, die man

zum Beispiel nutzen kann. Salt gibt es natürlich auch.

Das sind so die großen, die man dann

letztlich hat.

Und die Frage

ist dann immer, okay, welches von diesen

Tools nehme ich denn am Ende?

Und ich finde,

Ansible ist halt das Tool mit der

niedrigsten Hürde, weil

man ja am Ende halt

YAML schreibt

und dort halt relativ

klar reinschreibt, was man denn am Ende

haben möchte. Und es

funktioniert halt agentless, das heißt

ich muss halt vorher keinen Kontakt

zu dem Server

gehabt haben, also keinen Agent installieren

und

dem werfe ich dann einfach Befehle zu

und der führt die dann aus.

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

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

Ja, okay.

Genau, und ab da läuft es dann sehr autonom.

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

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

Wenn man immer, also wenn man einen Agent drauf hat, der meldet dann regelmäßig zurück und sagt dann,

Ja, hör mal, hier ist übrigens gerade, ja, die Pakete sind ausgelaufen,

könntest mal ein Update machen.

Davon weiß Ansel Bilder nichts.

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

Ja, also der hält da im State nicht.

Also wenn du sagst, okay, ich möchte halt immer die aktuellste Version

vom Apache drauf haben, dann ist das für den Moment,

wo das ausgeführt wird, so.

Genau, und danach ist es halt historisch, ja.

Genau, danach ist es dann gewesen.

Und die andere Annahme ist natürlich dann auch,

dass halt niemand auf dem Server was macht,

außer über Ansible.

Damit man halt den State hat, den man einmal...

Aber das ist so eine Konvention, die man dann haben muss.

Das könnte ja auch anders sein.

Es könnte ja auch sein, dass irgendein Admin irgendein Login hat

und dann einfach irgendwas macht.

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

Genau. Und deswegen weiß ich am...

Also, wenn ich das nächste Mal dann Ansible ausführe,

halt nicht, wie sieht denn jetzt die Wirklichkeit auf der Maschine aus.

Mhm, okay.

Ja, also vielleicht wollen wir

tatsächlich so ein bisschen reingehen, was Ensemble macht, wie das

so macht. Ja, also ich würde sagen,

generell der größte Unterschied eben zu den

anderen ist halt, dass es Ancient-less ist. Das ist halt

ein Riesenunterschied. Und da kommen dann halt,

also einmal ist es halt ein Riesenfall. Man braucht nur SSH,

das ist alles. Das hat man ja meistens. Also ich würde sagen,

es passt halt gut zu dieser Geschichte.

Was passiert eigentlich, wenn man jetzt halt eben

so irgendwo sich einen Rechner klickt

und kriegt man halt meistens

ein Root-Login da.

Das ist halt etwas,

bis dahin ist es ja meistens schon automatisiert.

so, und dann, ab dann ist halt

die Frage, was macht man dann? Aber dann braucht man halt auch nicht mehr

und dann kann man mit Ansible schon anfangen, während man

bei anderen Sachen, dann muss man halt dann irgendwie einen Agent installieren

und keine Ahnung.

Ja, und ja,

das ist halt der Vorteil, aber es ist halt natürlich in gewisser

Weise auch Nachteil irgendwie, weil das macht halt dann

bestimmte Sachen eben, wie er schon angesprochen hat, also eine

Geschichte, die ich noch hinzufügen würde, ist,

macht das halt auch langsam. Das ist halt dadurch,

dass das alles durch S haben muss.

Also wenn zum Beispiel Files kopieren,

viele Files kopieren, ist halt mit Ansible

oder Templates, die dann

wie man da erzeugt, das ist halt schon relativ klar.

Ja, weiß ich nicht. Das kommt wieder ein bisschen

drauf an. Okay, gut. Interessant, ja.

Ja, also weil

ich nehme das vielleicht jetzt vorweg, also was

bei mir immer so ein bisschen

bei dieser Infrastruktur-as-a-Service-Geschichte

dazukommt, ist halt dann Terraform,

weil ein Terraform-Provider halt,

die sind geschrieben für, weiß ich,

AWS und Azure und

Google Cloud und auch zum Beispiel Hetzner oder sowas.

Also jeder kann seinen eigenen Provider in Go irgendwie schreiben

für Terraform, für diese

HashiCorp-Language, in der man dann

auch in YAML Infrastruktur definieren

kann. Also wie sieht die tatsächliche Hardware

auf? Wie viele Kerne hat der Rechner, den du

haben willst? Wie groß ist die Platte? Und

wie ist die Netzwerkkonfiguration von dem Ding?

Also das alles, was diese Cloud-Provider

anbieten. Und dann ist jetzt die

Frage, wie man das mit Ansible beispielsweise

kombiniert. Ja, man hat halt dann

entweder macht man

per Ansible so Terraform. Da musst du

manchmal nochmal erklären, wie das funktioniert. Das habe ich noch nicht ganz

begriffen. Und wie ich das mache, was

ich ganz nett finde, ist tatsächlich Terraform

anzufangen und bei dem Apply

mit die Ansible-Kommandos

reinzugeben, die auf dem Server laufen

sollen. Und dann bedeutet das natürlich,

das ist so ein bisschen von hinten in den Wurzels Augen,

das muss dann so ein Cloud-Init-Skript zum Beispiel mit angeben,

was dann auch quasi

Ansible selbst auf dem Rechner installiert und dann

als Local-Host-Inventory läuft.

Also, dass eine Host läuft, dann halt

local.

Ja, kann man so machen.

Es ist aber sehr kompliziert, ja.

Ja, also du hast halt hinterher das Problem,

dass du halt für Management die IPs wieder rausreichen musst

und einen SSH-Zugang brauchst, den Ensoble nutzen kann,

damit es halt dann sowas wie Upgrades oder sowas

auf einen Kisten ausgerollt werden kann, wenn du da

mehrere Farmen mitträumen wirst.

Ich weiß nicht, ob ich das kompliziert finde,

aber das ist halt so andersrum,

weil du hast halt immer nur so einen Localhost,

den du dann provisionst, aber der sieht dann

schon so aus, wie du willst. Vielleicht erklärst du

nochmal kurz, wie es andersrum bei dir funktioniert.

Erst Ensoble, dann Terraform.

Ja, also letztlich mache ich auch

also erst Terraform.

Ach so.

Und dann lasse ich mir das

Inventory dynamisch erstellen.

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

Und dann, genau, also

so der andere Weg, Ansible und dann Terraform

heißt dann, okay, ich habe dann erstmal

Ansible und lasse dann

ja,

da soweit dann schon mal alle Templates

und soweit ausfüllen, wie ich das letztlich haben möchte

und starte von da aus dann den Terraform.

Kann man dann auch machen,

aber ich finde

der, also

richtige TMWs.

Vielleicht müssen wir das nochmal kurz auseinander drusseln. Also erst

Ansible, lässt du dann die Terraform

Templates von Ansible befüllen,

dass halt quasi

Terraform dann weiß,

welche, also die Frage ist halt,

wo läuft dann diese ersten Control-Nodes? Läuft die dann

lokal und füllt dann quasi die

Terraform Templates mit den Dingen, die du dir vorgestellt hast,

über ein eigenes Ansible

Inventory oder irgendwelche Rollen, die du dir

definiert hast, aus. Und dann fängt es an,

dann die Infrastruktur zu deployen und

die nächste Frage wird dann wieder,

wie sehen denn denn die Kisten aus?

Da muss Ansible ja quasi wieder hingehen,

diese Nodes, die es erstellt hat,

connecten und dann da seine Rollen aufbauen.

Vielleicht noch ganz kurz,

eine Ansible-Rolle ist quasi genau das,

was man hat.

Also eine Konfiguration für irgendwas.

Also Rolle, Datenbank-Server, Rolle, Web-Applikation, Rolle.

Genau, das ist also die Frage.

Wollen wir nochmal in die Definition gehen,

damit wir das Thema Playbooks, Plays, Tasks und Rollen klar haben,

weil ich finde, das ist das Verwirrendste.

Also Inventory, damit kommt man ja irgendwie so klar.

Vielleicht auch nochmal erklären für jemand,

Also Inventory, das sind so meine Kisten, das ist eigentlich eine YAML oder Indie-Datei und da kann ich dann die IPs oder die Server reinschreiben, die ich dann erreichen möchte und die kann ich auch ein bisschen kopieren, um dann zu sagen können, okay, das sind meine Datenbank-Server, das sind meine Web-Server und die kann ich dann letztlich in einem Playbook halt ansprechen.

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

Ja, es ist so ein bisschen die Metapher aus dem Football. Du hast dann als Coach von deinen Servern sagst, okay, wir spielen jetzt diesen Spielzug und alle Server, die Datenbank sind, gehen jetzt alle nach links. Und da ist dann das Play drin, wo dann drin steht, okay, welche einzelnen Anweisungen da erledigt werden müssen.

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

Genau, aber Play ist halt, ein Playbook kann halt Rollen benutzen, aber Play, das ist keine Rolle selber, sondern Playbook ist halt, da kann ich halt, genau, Rollen drin benutzen, aber es gibt auch Leute, die das gar nicht machen, sondern die alles immer inkluden irgendwie, es ist halt, ja.

Ja, letztlich ist es eine Hilfe,

dann seinen Code zu organisieren.

Ja, man kann natürlich

auch alles in eine große Datei schreiben.

Man kann auch alles, das geht sehr gut.

Ich mache tatsächlich ganz viele Rollen irgendwie.

Also ich weiß nicht,

also Ensemble Galaxy ist auch ganz schön,

das ist halt der Cloud, ist das Cloud-Dienst?

Also so ein...

Ja, die Sammlung von Rollen, die kann man hochstellen.

So wie PIP quasi, bloß für

Ensemble.

Also ich bin immer so ein bisschen picky, ich mache immer viele Sachen

selber, also notamentet hier und so.

Ja, genau. Also dann die Ansible Galaxy gucke ich mir dann auch zur Inspiration an.

Ja, und jedenfalls, da könnte man sich halt auch solche Rollen einfach inkluden von dort. Und dann baut man halt seine Rollen und da legt man dann halt fest, welche Konfigurationsaufgaben ausgeführt werden müssen.

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

Das ist ja genau die Besonderheit bei Rollen.

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

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

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

die benenne ich dann irgendwie immer so

Setup-Web-Server-with-blah

oder so.

Ja. Postgres zum Beispiel

und Django auf einmal. Also dann wäre ja die

Rolle letztlich Postgres und dann kann man

sagen... Ja, dann wäre die Rolle Postgres und Django beispielsweise.

Genau. Ja, und vielleicht haben die noch Dependencies,

keine Ahnung, also bei mir ist zum Beispiel dann so ein

Minimum-Server-Setup oder so mit drauf

oder so. Genau. Und

letztlich die Rollen, die

soll man quasi so schreiben, dass man die

wiederverwenden kann. Modular,

austauschbar, egal. Genau, also Postgres ist

halt überall, der Postgres und der

Also ich finde das zum Beispiel schwierig,

weil, was

Ansible ja zum Beispiel auch ermöglicht, ist eine Unterscheidung

zwischen den Betriebssystemen, die benutzt

werden, also jetzt, ob ich jetzt einen

Red Hat Enterprise habe oder einen debilen oder so

und

das finde ich ja so ein bisschen blöd, weil also ich

habe keine Lust, immer meine Rollen für

alle Systeme zu schreiben, die ich nicht benutze.

Ja. Also so. Ja, genau.

Ja. Also

deswegen ist es eigentlich ganz gut,

die Themen so homogen zu halten, damit man

nicht so viele

unterstützen muss. Aber da kann man natürlich

auch nochmal mit dem Inventory arbeiten und dann

beim Inventory den einzelnen

Servern nochmal Variablen mitgeben

und sagen, okay, der ist halt

anders als die anderen.

Ja, genau.

Ich meine,

ich verstehe schon, dass Leute diesen Fall haben.

Ich habe den selber auch nicht. Bei mir sind alle

Server, haben irgendwie das gleiche Betriebssystem.

Welches benutzt du? Ja, Debian

tatsächlich Bullseye zurzeit.

Das ist nicht ArchLinux.

Ja, es gibt da auch interessante Alternativen.

Also womit ich ab und zu mal geliebt georgelt habe,

ist halt nix.

Also ich habe nix auch benutzt,

aber nur als Desktop, also nicht als Server-Variante.

Also gerade Python ist da sehr, sehr nervig mit,

weil man halt gar nicht so wie Paketmanagement

über seine Projekte verwalten kann,

sondern muss halt jedes Mal seine eigenen Environments

irgendwie zusammenfummeln.

Und es ist halt nicht alles verfügbar

und es ist einfach sehr, sehr viel Maintenance-Arbeit,

wenn man da irgendwie Updates fahren will

und dann nicht, dass das irgendwie...

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

muss.

Das ist schon irgendwie sexy, aber...

Genau, das würde

mich eigentlich reizen, weil mir das Konzept natürlich schon

irgendwie ganz gut gefällt und so, aber auf der

anderen Seite, irgendwie Debian benutze ich halt schon so lange

und kenne ich halt gut und es gibt keine Überraschungen

und die Frage ist, muss ich

halt die Schlachten aussuchen?

Dann würde ich sagen, na gut, dann nehme ich damit, dass es halt irgendwie

langweiliges Debian ist

und dann kann ich

die interessanten...

mein Innovation-Token irgendwo anders

ausgeben, wo es halt vielleicht irgendwie mehr bringt.

Aber es reizt mich schon, das muss ich

sagen, ja, das ist, ja.

Ja, also bei der Definition jetzt,

ich glaube, wo waren wir denn?

Infantiles, Playbooks, Hosts?

Genau. Haben wir das

klar genug definiert oder sind wir da auch wieder so

langsam? Ja,

genau. Ich wollte

irgendwas sagen, ich hab's wieder vergessen. Ich glaube, ja, ich hab

diesen Fall eben auch, das nervt mich auch in diesen

Rollen, die man halt von

der Galaxy bekommt.

eben sowas wie Postgres zum Beispiel.

Also, was ich dann, wenn ich diese

Rolle, ich weiß nicht, ob ihr die kennt,

die habe ich mal irgendwann benutzt, ich weiß nicht,

gibt es immer einen, der schreibt

die alle. Wie heißt der? Gerling?

Genau, der hat auch ein richtig

gutes Buch

über Ansible und noch ein paar gute

YouTube-Videos. Alle in die Shownotes?

Genau, der hat auch einen Vortrag,

wie man rausfindet,

welche Rollen

gut sind in der Ansible-Galaxy.

Hat dann ein Schaubild

gesagt, mit so ein bisschen Augenzwinkern.

Also man guckt dann, ob er der Autor ist.

Ja, tatsächlich.

Und wenn nicht, dann fragt man ihn an und wartet so lange,

bis die dann kommt.

Ja, genau. Aber das Problem bei denen

ist halt oft,

weil der hat dann eben für Postgres

zum Beispiel einen und die fand ich nicht, sondern ich habe seine geforkt

und dann

einfach

das ist zwar, also den Hauptteil

davon, der interessiert mich halt nicht, irgendwie die ganzen Installationen

für alle möglichen Plattformen und dann der Teil,

der mich interessiert für Debian,

da hätte ich keine andere Version.

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

Ja, gut, Ansible Galaxy,

das ist halt für alle

Anwendungsfälle und

gut.

Also wie gesagt, eher so die Inspirationsquelle

oder wenn man es halt wirklich mal

schnell hochziehen will, um zu gucken,

okay, wie sieht das so aus?

Ja, okay, das ist so ein bisschen der Docker-Container

für den Server oder so. Also

so eine Rolle. Ich spawne jetzt meinen Server

in der und der Saison, ja.

Ja, in gewisser Weise, das finde ich

auch, das ist vielleicht ein guter Vergleich, das halt auch so,

aber ich meine, ist halt die Frage, ob man damit Rolle meint

oder ein Playbook, weil ich verwende eher Playbooks

tatsächlich so, wie vielleicht

ein Docker-Pile. Meistens braucht halt

irgendwie so ein Server mehrere Rollen, würde ich sagen, damit er das

macht, was man will. Ja, ja, aber

ich würde sagen, ich habe halt

für diese Geschichte zum Beispiel,

er soll irgendeine Funktion erfüllen,

habe ich halt ein Playbook bei mir

und nicht eine Rolle. Genau, ja, habe ich auch,

Ja, das kombiniert halt bei mir dann so

bestimmt. Genau, und

tatsächlich ist das, finde ich, auch

sehr ähnlich zu sowas wie Dockerfile

oder, weiß ich nicht, Docker Compose

oder sowas. Nur, dass es halt

irgendwie, dass man die ganzen

Einschränkungen nicht hat, die man bei Docker so hat.

Und auch

die ganzen Security-Sachen sind, finde ich, da

deutlich, wenn man das so macht, deutlich klarer als jetzt bei

Docker. Und, naja.

Ja, nochmal so zum

Abgrenzung Rolle und Playbook.

Ja, Rolle ist wirklich dafür

gedacht, alleine zu stehen.

Also bei dem Playbook, dann sage ich

okay, ich möchte halt

so einen bestimmten Server auf die

oder eine bestimmte Gruppe von

Servern, so konfiguriert haben und

eine Rolle wäre dann quasi so die

Unterfunktion davon, wenn ich sage, okay

Diese Konfiguration wird dann angewandt.

Genau. Und

ja, das Playbook,

wenn man sich dann so eine

größere, größeres Cluster

vorstellt, enthält dann es halt

mehrere Rollen. Also ein Loadbalancer,

einen Web-Server, eine Datenbank.

Was der Running-Back machen soll, was der Quarter-Back machen soll,

wie die Define stehen soll. Richtig, genau.

Ja, ja.

Okay, also ich glaube,

dann die grundsätzlichen Sachen haben wir definiert.

Haben wir noch was vergessen? Achso, vielleicht Facts.

Was ist ein Fact?

Ja, das ist halt das, was Ansible

irgendwie rausfindet.

Also am Anfang...

Ja, man macht das halt so ein Gathering-Facts.

Das kann man aber auch abschalten,

wenn man es nicht braucht. Dingen, wo dann halt

bestimmte Variablen belegt werden, mit

Informationen über das System, auf dem man grad irgendwie...

Kommt natürlich daher, dass Ansible das

erstmal nicht weiß. Ja, ja. So, wo

bin ich denn? Und da kriegt man natürlich dann

auch ein schönes Python-Directory zurück,

was halt alles

Erdenkliche auf diesem System

herausgefunden hat. Da kann man auch mal

schön reingucken. Ja.

Da ist ja viel interessantes Zeug drin. Genau.

Auch noch genau die Sachen vielleicht, also die ganzen Variablen, die man

irgendwie reinpipet oder irgendwie, die man dann behandelt

als Facts oder sowas, die halt da schon drin sind.

Da kann man ja ganz viele

Python-Funktionen auch drauf pipen, die halt

relativ nativ sich anfühlen,

wenn man das irgendwie bearbeiten möchte.

Achso, du meinst, um nochmal andere Dinge,

die da jetzt nicht drin waren,

man kann in einem Task sagen, Set Fact

und dann halt irgendwas.

Genau, dann kann man dann Pipe, Strip,

String, Station, was auch immer.

Die Playbooks, die sind ja letztlich,

läuft da halt auch ein Ginger 2 Support hinter

und das heißt, ich kann alles letztlich

machen, was ich in Ginger 2 machen kann

mit den Facts, die vorher

Ansible gesammelt hat und ich

kann die letztlich wie ein Directory accessen

oder beziehungsweise ist es ja eins

und dann kann ich da alles

machen, was Ginger 2

mir letztlich erlaubt und das ist ja echt

eine ganze Menge.

Da vielleicht noch ein Exkurs,

Ginger 2?

Ja, Ginger 2,

Templating Engine,

letztlich

so wie

alle Templating Engines, die man so

kennt. Django macht das ja auch.

Ist auch ähnlich.

Nicht genau so Ginger 2

ist wahrscheinlich sogar die bessere Template-Language.

Genau, es gibt auch Jinja 2 Support

für Django, wenn man

das dann machen möchte und

bietet eigentlich auch die Möglichkeit,

direkt Python in das Template

zu schreiben oder halt in das Playbook dann

und auch Funktionen zu definieren,

die man dann später haben möchte.

Wäre dann halt am Ende die Frage,

ob man dann nicht lieber ein Modul schreibt,

wo man dann direkt in Python arbeitet.

Ja, okay.

Interessant.

Ich glaube, jetzt haben wir so ein bisschen definiert.

Ich habe noch so jede Menge Fragen, die ich dazwischen habe,

wenn man mit den ganzen Sachen umgeht.

Aber jetzt vielleicht noch mal, warum wir kurz das definieren wollten,

um diese Terraform-Ansible-Sache noch mal so ein bisschen zu verstehen.

Was spricht jetzt zum Beispiel dagegen,

sowas wie dieses lokale Ansible zu machen, deiner Meinung nach?

Wenn man sagt, okay, man lädt jetzt einen Local-Host einfach

und sagt ihm, welche Rollen er hat.

Ja, also wirklich viel dagegen spricht nicht.

Also es ist halt anders gedacht.

Und dann bin ich immer doch eher dafür,

die Werkzeuge so zu benutzen, wie die letztlich gedacht sind.

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

Nee, ich brauche die halt über Terraform,

muss ich die SSH-Verbindung bauen.

Genau, aber nicht mehr dann die auf dem,

also wenn du ja über die Local Connection gehst.

Genau, ich mache dann Fire and Forget.

Also ich sage dem halt quasi, renn los.

Und dann macht er halt sein Ensobe-Kram.

Ich habe da wenig Kontrolle drüber, ich muss halt dann auf den Server

in die Logs gucken oder was auch immer, um

festzustellen, wo sind die denn gerade.

Genau, also

da gibt es ja dann auch nicht mehr diese

Rückmeldung zurück.

Brauche ich vielleicht am Ende auch nicht, wenn ich dann

in die Logs gucke. Ja gut, man muss halt einmal ordentlich

E-Debuggen, damit er einmal sicherstellen kann, dass so ein Server

das macht, was er will, aber ja.

Ja.

Also es ist auf jeden Fall durchaus ein gangbarer Weg.

Ist dann die Frage,

ob man da ein bisschen so

die Idee hinter Ansible,

ja.

Also ich frage jetzt halt, was so ein Terraform ist, weil ich

frage mich halt, wie dann halt Terraform sonst aussehen soll,

weil ich weiß ja gar nicht, mit Ansible

anzufangen, welcher Server habe ich denn denn jetzt?

Ja, aber ich meine,

gut, vielleicht macht ihr das, aber

ich wundere mich mal, ich verwende gar keinen Terraform.

Ich meine, ich habe jetzt

auch nicht irgendwie

jobmäßig irgendwas, große Cluster zu konfigurieren

und so, wenn ich das hätte, hätte ich das vielleicht dann

doch, aber so für meinen

privaten oder so semi-privaten

Jörg hat gerade zugegeben, dass er sich die einzelnen

Cloud-Helfer einfach zusammenklickt.

Ja, ich benutze halt das Web-Advisor und ich rufe jemanden an,

der macht das dann.

Nee, aber ich kenne, es sind so

wenige, ja, so Privat-Helfer.

Handverlesene Server.

So viele habe ich dadurch, dass ich die nicht mehr kennen würde.

Da kenne ich jeden Einzelnen mit Namen

sozusagen. Und die kann ich dann auch

in den Ventury reinschreiben.

Ja, aber das ist ja eigentlich auch erst Terraform.

Also, weil das macht ja genau das, was du da klicken würdest.

Und dann Ensemble. Also nur mit dem Unterschied,

dass ich jetzt halt einmal hingehe und

sonst in Terraform beispielsweise einmal eine generelle

SSH-Verbindung vorkonfiguriere

und dann den Output sammle und die

IPs dann ins Inventory reinschreibe,

um die dann mit den Rollen zu versehen.

Was halt dann so der direkte

Endzippelweg ist, wie es vorgesehen ist.

Was ich halt bei mir machen würde, ist halt,

ich sage halt direkt

beim Deployment von Terraform, was

halt werden soll, und ich müsste mir

dann halt auch aus dem Output den

SSH, den ich mir dann selber, also ich

mache dann keinen SSH-Zuruf mehr, sondern halt

mit Keys, was ordentlich, dass es irgendwie einen User

gibt, der das dann darf und der

Nee, ja Moment, das wird

interessant. Du machst, du

connectest dich,

wenn du Ansible benutzt,

auf einen User? Nein.

Auf dem Rechner? Nein, Moment.

Ich gehe hin, ich baue

eine Kiste, beispielsweise bei Hetzner

oder bei Azure oder so was und

sag dem über so ein Cloud-Init-Skript

bitte installiere

Ansible lokal.

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

Ja, also mache ich im Prinzip schon. Aber ich möchte ja gerne diese Flexibilität der Rollen haben, die ich dann über das Terraform-Skript reingebe. Das heißt, ich gebe quasi eigentlich nur den Pfad zum Playbook mit den Variablen, das kommt über Terraform, also die Extravariablen und das Playbook, das ausgeführt werden soll, kommt rein.

und ich klone quasi lokal

das Ansible-Server-Repo

und dann lasse ich da lokal

mit Localhost das

Playbook laufen mit den entsprechenden Variablen.

Was aber auch das Geschwindigkeitsproblem,

was Jochen hatte, löst, weil das halt alles lokal

auf der Maschine läuft. Ja gut, es kann gut sein, dass

das dann schneller ist, ja. Genau, das läuft halt dann schnell einfach durch

und konfiguriert die Maschine lokal halt einfach

so, wie sie sein soll.

Was ich dann natürlich machen muss,

ist, also was ich auch mache, ist, ich konfiguriere

zum Beispiel meinen Admin-User, ja, mit den

entsprechenden Keys und tralala. Den könnte

ich ja dann wieder rausgeben, ja?

Ich brauche halt den Key, der Zugriff darauf hat, ich brauche

den Nutzer-Account, der

das darf und ich brauche die IP vom Server.

Die kann ich mir aus den Terraform-Outputs hier wieder

einsammeln und mir dann quasi so

ein Service-Ansible

noch da reinschreiben.

Das sind aber dann trotzdem zwei Repos. Das eine

Repo ist das Terraform-Repo mit diesem Service-Ansible, wo

dann quasi ich mit Updates fahren kann oder

sowas oder ich überprüfe bitte den State für alle

Web-Applikationen, upgradee Django auf die

neueste Variante oder so.

Und auf der anderen Seite

das Enzibel-Setup läuft halt

über das Enzibel-Repo, wo halt dann

die ganzen Standard-Rollen

drin sind. Ah, okay.

Ja, interessant. Also

das ist irgendwie ganz anders, als ich das

erwähnt habe. Ja, nee,

witzig. Also ich muss sagen, es funktioniert

ganz gut. Es wütet sich auch so ein bisschen von hinten

durch die Brust. Ich habe mehrere Blog-Einträge

durchgelesen, mit so für und wieder.

Das war am Anfang so ein bisschen halt gefummelt,

das so hinzubekommen, dass das so funktioniert.

Aber das funktioniert halt gut.

Ja, also

mein einziger Einwand wäre dann

zu sagen, okay, hast du

halt dann sehr stark verknüpft?

Ja, habe ich das?

Ja, also schon. Also ich meine,

das will ich ja auch. Also ich will

ja quasi schon sagen, was für Rollen das haben soll.

Nicht nur die Hardware festlegen.

Ja.

Weil das ist ja auch genau das. Also ich will ja nicht nur irgendeine

Hardware haben und dann sagen, okay, vielleicht das mal, das mal,

das mal, das. Sondern ich habe eigentlich, wenn ich eine Hardware habe,

hat die auf jeden Fall schon direkt einen Zweck.

Und das läuft halt dann so, dass ich quasi

Terraform-Ordner

habe für jedes einzelne Projekt.

Also auch für so bestimmte Rollen ist ein Terraform-Ordner

ein Tango-Server, ein Terraform-Ordner ein Bucket,

ein Terraform-Ordner ein Datenbank-Server, irgendwie so.

Und da werden die Sachen halt dann,

kann man die auch so schnell skalieren, weil die Variablen

stehen halt dann direkt mit drin und das war halt okay,

Datenbank-Server ist ein bisschen schneller oder so

und hat ein bisschen andere Netzwerkkonfigurationen oder sowas.

Ja, gut.

Das klingt irgendwie, ja.

Genau, also erinnert mich auch so ein bisschen an Vagrant.

was man vor Docker gemacht hat.

Da konnte man ja auch die Ansible-Playbooks reingeben

und dann hat er einem dann den Vagrant so hochgezogen,

wie man das letztlich im Playbook stand.

Ja, ja.

Ich erinnere mich da auch noch dran.

Wann war das? 2012?

2013 habe ich das mal gemacht.

Das war ziemlich schrecklich, ehrlich gesagt.

Ja, aber da gab es noch kein Docker.

Da gab es noch kein Docker, genau.

Deswegen muss man da ein bisschen...

Ja, ja, ja.

Anderer Punkt.

Entschuldigung, ich wollte dich nicht unterbrechen, aber...

Ich zum Beispiel, ich mag es auch meinen

debilen Desktop

per Ansible auszurollen.

Ja. Okay.

Also kann ich absolut verstehen,

nur weil ich hatte auch so eine Diskussion

online. Für Linux gibt es kein

Endpoint-Management.

Und da muss man sich einfach mal überlegen,

ja, was ist denn der Endpunkt?

Also was ist der Unterschied zwischen

Server und Laptop bei Linux?

Dass ein X11 läuft

oder Valent und den Rest kann man ja

genauso benutzen am Ende.

Also von daher eine wunderschöne Sache, das mit

Ansible zu machen. Ja, also die Alternative wäre nichts

gewesen.

Aber da

mich nichts genervt hat an so ein paar Punkten,

dann habe ich dann gesagt, okay, dann mache ich es mit Ansible, weil

ich möchte auf jeden Fall eine reproduzierbare Maschine

haben, weil mich nervt das jedes Mal selber

rumkonfigurieren zu müssen und so.

Und das ist halt nicht nur irgendwie dort falsch, sondern das

ist halt noch mehr. Und deswegen

wollte ich das halt bei Ansible steuern. Da muss man halt dann immer

fliegen, muss halt immer dann ein Repo haben, was

halt für seinen Desktop ist, muss der halt da immer dran

rumpummeln. Wenn man die Konfiguration hat, die updaten,

aber dann kann man halt, egal wo man ist, einfach seine Sachen

reproduzieren.

Und wenn man auch irgendwie seine

sonstige Sachen irgendwie in der Cloud hat,

dann kann man, egal wo man ist, einfach mit seinem System, wie man es

gewohnt ist, genauso arbeiten. Das finde ich irgendwie schon nett.

Ja, aber das

gibt es ja auch so die Bewegung, das dann

letztlich wieder über Docker zu machen. Dann auch zu

sagen, okay, wir können ja auch grafische Anwendungen in Docker

laufen lassen.

Ja.

Ja, ja, kann man auch.

Doch, es hat so einen Zwischenlayer irgendwie noch.

Ich weiß nicht, ob es so ein Personalismus-Rename gibt.

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

strong, aber

ja.

Ja, es gibt schon irgendwie so ein bisschen Einschränkungen, aber es gibt

inzwischen sehr, sehr häufig, dass man halt auch

auf vielen Projektseiten sieht. Also ich meine gerade,

ich kann es auch verstehen, wenn es halt irgendwas ist,

was schwer zu installieren ist.

Und da gibt es ja durchaus Software.

Dann sagt man sich, okay, nimm doch hier einfach diesen Docker-Code

und dann geht's.

Bevor du jetzt irgendwie sowas wie zum Beispiel

es gibt halt manche Software

so mit Abhängigkeiten zu

Qt und so, wo man

dann halt erstmal anderthalb Stunden kompilieren muss.

Ja, also genau. Ich glaube, das Kompilieren ist das, was lange

dauert und Updates sind halt immer ein bisschen nervig.

Wenn man halt irgendwie so Breaking Changes irgendwo hat,

dann muss man alles wieder umbauen.

Naja.

Früher hat man auch

dann mehr Ansible-Playbooks

gesehen, wenn es dann um schwierige Installationen

ging.

Leider ist es so ein bisschen auf dem

absteigenden Ast.

Was nimmt man denn jetzt? Nur Docker dann?

Ja, oft findet man halt die Docker-Container

und dann sagt man hier, also wenn du das einfach

dem Run sagst, dann läuft der

und dann kannst du

mitnehmen.

Ja, das finde ich auch faszinierend, weil, also ich sehe

diesen Trend durchaus auch, aber

ich finde ehrlich gesagt so von dem,

wie fühlt es sich von der Benutzung her an?

Docker, es wird eher immer

schlimmer, hätte ich gesagt, aus meiner Perspektive.

Ich habe es auch zwischendurch ganz gerne genutzt, aber

ich weiß nicht, irgendwas finde ich nervig.

ja. Das ist immer so gekapselt

auch irgendwie. Also ich habe nicht so den direkten

Zugriff. Also sag mal so,

es nimmt einem schon irgendwie Probleme ab,

aber es hat halt nicht,

auch nicht so ganz die Flexibilität, wie jetzt

die man mit Ansible hat.

Also gerade, was man bei Docker dann doch irgendwie

öfter mal, was einem dann passiert, so zum Beispiel

irgendwie so, irgendwie das Filesystem ist halt

voll. So, man weiß halt nicht genau, warum.

Und dann guckt man halt und denkt, ach ja, deswegen,

ach, und dann, uh, was liegt denn

hier noch alles rum? Ich habe jetzt

diesen Container 30 Mal hier.

Genau, solche Sachen. Oh, Docker-Compost-Down

vergessen, ups. An der Stelle ist die Abstraktion

halt schon sehr leaky. Oder man muss halt

sich gut mit Docker auskennen. Oder was ich

dann halt oft sehe, wie Leute dann so

wirklich in größeren, großen Firmen,

wo dann Leute da sitzen

und irgendwie, wo dann

das halt alles vereinheitlicht ist, wo alle

Entwickler irgendwie Docker verwenden und dann so

ah ja, okay, ich muss hier ein neues Paket

für das Docker-Image. Und dann warten die

halt da irgendwie stoisch eine halbe Stunde,

bis das irgendwie alles kopiert ist

und die Dinger sind halt, die Images, dann denken sie so,

hä, das dauert eine halbe Stunde,

bis die Images da, hä,

was macht ihr denn da? Und dann so, ja,

das ist doch normal, das ist doch immer so.

Guck mal rein und so, dann nehmen sie dann halt

Alpine irgendwie,

Linux, ja, und dann

installieren sie aber NumPy, ja, und dann

zieht das erstmal in GCC nach und dann wird erstmal

die komplette Compiler-Toolchain

irgendwie kompiliert und dann, ja,

und dann ist kein Wunder, warum das so lange dauert,

aber es ist halt irgendwie

so, ja, und die Images werden riesig,

ja, und dann nehmen sie Alpine, damit die klein werden,

und dann werden die irgendwie anderthalb Gigabyte groß.

Und, ja, und dann denke ich so,

also irgendwie,

ihr haltet das falsch rum.

Das ist, ja, genau.

Das ist irgendwie, das, ja.

Und, aber,

ich habe das Gefühl,

es hindert die Leute, also, wenn ich denke,

das ist eigentlich ein ziemliches Katastrophenszenario,

ja, und eigentlich müsste man sagen, also, wenn

die, also, es müsste den Leuten doch irgendwie

auffallen, dass das jetzt alles furchtbar ist, oder?

Aber das ist nicht so. Die Leute

halten das für normal und das ist dann jetzt halt so

und dann, es verbreitet sich trotzdem.

Und das finde ich immer faszinierend.

Sind wir noch bei Docker oder schon bei JavaScript?

Ja, bei JavaScript und

irgendwie, ja, NPM und

diesen ganzen, ja, das ist teilweise so ähnlich, ja.

Es gibt doch jetzt bei

SAPN ganz viele andere Sachen, Dino und Ban.

Ja, aber das ist auch alles ziemlich furchtbar.

Ich meine, gut, vielleicht

liegt es irgendwann so, ja,

wird das da auch mal wieder.

Man überlebt sich halt irgendwann in die

Komplexität und

dann macht das auch Spaß und keiner weiß

mehr, wie es geht und dann hat man auch mal so

eine Expertenrolle. Das ist auch schön.

Genau, also wenn keiner mehr weiß, wie es geht,

dann ist das halt ziemlich angenehmer.

Job Security ist auch ganz wichtig.

Aber ja, und

ich weiß nicht, also ich finde,

so im direkten Vergleich, wenn ich jetzt

irgendwie, das habe ich früher gemacht, zum Beispiel

pythonpodcast.de, wenn man sich das

anguckt, das ist tatsächlich, das ist ein

Cookie-Cutter-Template für Django

und dann ist da auch ein

Docker-Container oder mehrere Docker-Container, weil da ist halt auch

Datenbank und so und das läuft alles auf Docker-Container

und ist halt irgendwie

deployed.

Als ich angefangen habe, Sachen zu lernen, hat

Jochen mir gesagt, das ist so, wie man das macht und dann stand

ich erstmal für diese Komplexität. Ja, sorry, ich kam ja von

Vagrant und da sah das aus, als wäre

das Fortschritt. Also ich musste erstmal ein paar Mal

gegenhauen und hab mich erstmal gefragt, was ist das denn jetzt?

wie geht denn das jetzt? Muss ich jetzt eingeben?

Muss ich mir irgendwie tausendlange Kommandozeilen,

Listen schreiben, um zu verstehen, was machen?

Und dann überhaupt ein Introspekt.

Das war schon echt

ein Komplexitätsmonster, muss ich sagen.

Ja, also es tut mir leid.

Aber so ist es halt.

Ja, aber das läuft noch alles

auf Docker und so.

Es ist aber nicht, also wenn ich das jetzt

vergleiche, auch den Betrieb davon mit

irgendwie, ich mache jetzt schon seit einiger Zeit,

ich habe es noch nicht geschafft, das eine auf das andere umzuziehen,

also sozusagen die alte Infrastruktur läuft immer noch

und ich habe den direkten Vergleich noch und letztens hatte ich da

das Problem, dass da irgendwas, es ging nicht mehr

und irgendwas war vollgelaufen und ich wusste,

oh mein Gott, ich muss in diese Docker-Container reingucken,

oh je, habe ich eigentlich ein Backup, habe ich wirklich

ein Backup, hoffentlich

mache ich jetzt nichts kaputt

und ich vergleiche das jetzt so

mit dem, was ich jetzt mache und das ist halt

irgendwie die Dinge einfach direkt via Ansible

zu installieren und ich habe halt für jeden Service

halt einen eigenen User und

der hat halt ein eigenes Virtual-End da nochmal

drin und

das wird einfach alles so hochgezogen

und hat dann auch ein schreibbares Dateisystem

und so. Man kann auch so eine Backup-Holle installieren,

dann überläuft das Vernünftiges, man weiß

dann auch, wo die sind, das ist alles ordentlich.

Aber man kann auch überall reingucken,

man kann da einfach als Root mal so

über alle drüber gucken und gucken, was da so

los ist. Das ist deutlich

angenehmer und so viel länger sind die Playbooks

nicht als die Docker-Files mit dem ganzen

drumherum Start-Stop-Zeugs, das man

da sonst so hat. Ja, vor allem, wenn die einmal gut sind, dann

ist das eigentlich angemacht. Und das ist halt viel transparenter

als... Ja, man muss halt

gucken, welche Vorteile

bietet einem letztlich der Docker-Container und

nutze ich die überhaupt?

Oder manchmal ist es auch

ganz schön, einfach nur einen richtig großen

Server zu haben und da

laufen halt die Sachen dann alle

sehr lokal drauf.

In einem user space

oder so. Ja, weil die sowieso

alle uniform sind und man

halt nicht, sagen wir

jetzt mal, 10 Container braucht, um

jede App zu kapseln. Ja, also

Ich meine, ich kann es natürlich in gewisser Weise verstehen, auch da wieder,

wenn man halt irgendwas hat, was sehr schwer zu kompilieren ist,

oder wie gibt es da,

ich weiß nicht, ob das bei XKCD

oder sonst wie irgendwo

ein Comic war, wo ein Entwickler

irgendwie da sitzt

und so leise vor sich hinweilt und sagt so,

aber auf meiner Maschine läuft es, und jemand

klopft ihm auf die Schulter und sagt, okay, dann

shippen wir eben deine Maschine.

Das ist natürlich so, ja, wenn du

sonst einfach nicht deployed kriegst, außer du shippst

das, was der Entwickler da hat, dann ist locker

möglicherweise sehr gut. Und wenn du dann viele von solchen

Sachen auf einer Maschine laufen lassen willst, dann

führt vielleicht um den Docker auch kein Weg drumherum.

Aber das ist ja letztlich auch

der Kritikpunkt an Python, dass man quasi

immer die Entwicklermaschine shippen muss, damit

es überhaupt läuft. Ja, das ist

natürlich auch bei Python so ein Problem.

Wobei...

Also ich finde Poetry löst das, wenn Poetry läuft.

Ja. Ja, Poetry läuft

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

so drei Monate, vier Monate.

Auf einmal wird irgendwas irgendwo kaputt

und dann Cash reparieren,

neue Versionen irgendwie installieren,

Pre. Fällt jetzt alles auseinander,

genau. Ja, ich stelle momentan

auch alle Sachen, wenn ich alte

Projekte habe und ich sehe dann, ah, dafür bin ich noch poachy,

ich stelle es meistens nochmal auf PIP-Tools. Aber PIP-Tools

ist furchtbar.

Wird auch verfügbar von PIP-Tools,

weil letztlich ist es nur PIP.

Ja, genau. Und wenn jemand PIP brechen

sollte, dann fällt es auf und dann machen andere

Ärger dafür, dass so viel Ärger, dass das dann

wieder funktioniert schnell. Also

genau, es ist letztlich nur PIP

Und man kann sich da ja Tools drumherum schreiben,

die das halt angenehm zu benutzen machen.

Ja, ja.

Oh, ich hab jetzt, das hab ich dann nochmal

versucht, weil du meintest, das kann auch

Pipetools können, das ist dann nicht so richtig.

Nein. Ja, genau.

Ja, das ist so. Und ich brauch Pipetools.

Also ich find die super, das ist eine gute Idee.

Ja.

Weil diese ganzen

TXT-Files mit irgendwie, ah ne, bäh.

Ja. Ich will die ganze Konfiguration

in Pipetools haben, ich will die

Pakete da drin haben.

Und also, ja.

Was man auch machen könnte, man kann ja einfach

einen Tommelparser nehmen und dann

die Dinger automatisch generieren aus einer

Pip-Projektion. Ja, aber das ist auch wieder sehr eklig.

Ja, gut, naja. Ehrlich gesagt, ja.

Ja, okay.

Aber ja, ich stelle das jetzt alles um und ich finde

auch vom Deployment-Aspekt her ist

Pip-Tools deutlich angenehmer als Poetry, weil

Poetry ist auch beim Deployment

ganz schön hakelig. Ja, aber das habe ich jetzt gelöst.

Tatsächlich. Ja, wie installierst du denn Poetry?

Also ich installiere