Transcript: Ansible

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.