Ja, hallo liebe Hörerinnen und Hörer, hier sind wir wieder, diesmal bei der zwölften Episode vom Python-Podcast.
Was machen wir heute? Heute machen wir ein bisschen Deployment für Anfänger.
Also so ein bisschen werde ich den Lochen löchern damit, wie man einfache Dinge auf irgendwelche Server bekommt.
Ja, ich bin der Dominik, hallo, Jochen ist wieder da, wir sind im Wintergarten, Sommergarten ist wieder viel zu heiß.
Wir hoffen, euch geht's gut.
Hört uns gerne zu.
Schreibt uns gerne alles, was ihr wollt, alles, was ihr
möchtet, an hallo.pysornpodcast.de
Ja,
schöne Grüße.
Ja, genau. Jetzt haben auch tatsächlich Leute
inzwischen so ein bisschen angefangen, die Kommentarfunktion
zu benutzen. Da war ich ja irgendwie...
Ja, unser Pocketcast-Chapter
mal funktioniert. Wirklich, wir wollen
irgendwann noch mal ein bisschen daran basteln, dass das dann mal geht.
Ja, und an den Kommentaren müssen wir wahrscheinlich auch noch
so ein bisschen was tun.
Da wäre es
vielleicht nicht so schlecht, wenn man E-Mail-Benachrichtigungen kriegen könnte
oder vielleicht zumindest
ein Kommentarfeed oder sowas. Muss ich
mal gucken. Geht bestimmt.
Habe ich mir schon mal auf die To-Do-Liste geschrieben,
aber es ist
nicht nur sehr warm, es ist auch irgendwie sehr
wenig Zeit momentan für alle möglichen Dinge.
Ja, ja. Alles auf einmal.
So ist das halt.
Aber genau, so ein bisschen
haben wir ja schon. Insofern brauchen wir uns nicht die ganze
Zeit nur zu beschweren, sondern können auch ein bisschen was erzählen.
Ja, diesmal durchherrsche ich
dich ja ganz viel mit lustigen Dingen, wie man
wieso man, warum man den ganzen Unsinn überhaupt
macht. Ja, ja,
ich finde es ein interessantes Thema und
naja, das ist, ehrlich gesagt,
ich meine, so Inspirationen aus
anderen Podcasts, die ich so höre, zu
nehmen, ist momentan auch so ziemlich das Einzige, wo ich Inspirationen
hernehmen kann. Daher dachte ich, nehme ich mal
irgendwie die Veröffentlichung von
Jungle for Professionals
von Will Vincent,
die jetzt gerade irgendwie dieses Wochenende
passiert ist, zum Anlass da auch so ein bisschen was
zuzusagen, weil ich hatte so beim, ich habe es
noch nicht komplett durchgelesen, aber ich habe so ein bisschen reingeguckt.
Also wie ihr merkt, wir sind direkt bei der nächsten
Chapter Mark-Szene.
Ja, Moment, genau.
News.
Ja, alles klar, habe ich gesetzt.
Ja,
so beim Durchblättern habe ich
schon gedacht, okay, das sind genau die Sachen, mit denen
ich auch schon irgendwie lange
rumgeplagt habe und
das ist wirklich sehr schön gemacht.
Und
ja, das ist eine Menge
Zeug, also wie betreibt man eigentlich überhaupt
irgendwie so eine Webseite da draußen im Netz und
was macht man da
alles und gerade jetzt
speziell irgendwie
was Django angeht, was
muss man da alles tun und
insofern, wenn einen das interessiert oder man das
Problem irgendwie hat, dann kann ich
dieses Buch auch durchaus empfehlen, das
ist eine sehr schöne Zusammenfassung
von all den Dingen, die man da so
beachten sollte.
Ja, aber eben, genau,
Also ich fand immer, das kam immer zu kurz.
Also auch wenn man sich so andere Bücher anguckt.
Dieser Teil, da wird dann immer gesagt, so naja, Händewedeln, das ist alles kompliziert.
Das ist nicht so einfach.
Fragt einfach euer Ops-Team.
Ja, und dann hat man das vielleicht gar nicht.
Das ist blöd.
Und genau, da kriegt man einen ganz guten Eindruck, was man da so tun kann.
Und irgendwie, ja, ich fand immer, das ist ein Thema, was zu kurz kommt,
aber was halt durchaus sehr wichtig ist, wenn man irgendwas auf die Straße kriegt.
Und darüber wollten wir so ein bisschen was reden.
Vor allen Dingen, weil wir müssen ja einfach mal
alle Synergien nutzen, die wir kriegen können.
Ich glaube, du wolltest ja auch irgendwie so eine Webseite
haben oder so, ne? Ja, ja, genau. Ich wollte
so einen Server mal selber auch irgendwie aufsetzen
und da brauche ich so ein bisschen Hilfe natürlich
bei und gucken, was man mit Python alles
machen kann und da lüge ich dich gleich ein bisschen mit.
Haben wir noch irgendwelche News aus der Szene,
die wir vielleicht dann noch hier reinbekommen?
Ja, ich würde einfach mal die Sachen,
die so passiert sind, einfach
nach und nach. Was haben wir denn da noch
so? Du hast noch so einen Postcast
gehört am Wochenende, Data Engineering.
Da hast du irgendwas
Spannendes zu erzählen. Ja, aber das weiß
ich gar nicht, ob das jetzt so super in
dieses Format passt.
Da ging es um
eine Firma, die halt so
Data Labeling macht. Also gut,
ich mache ja auch viel Machine Learning Zeugs,
Data Science und
also ich fand das deswegen gut,
also weil, also ich glaube,
wie hieß
die Firma nochmal?
Cloudworker oder so. Der Chef
von dem, einer der Gründer, hat er halt
irgendwie auf dem Detail-Engineering-Podcast da
was zu erzählen und
das, was er so beschrieben hat an,
das sind die Probleme, die man normalerweise kriegt, wenn man
irgendwie
Firmen dabei helfen will,
irgendwas in die Richtung zu machen, das kam
mir schon alles sehr bekannt vor, weil das sind halt auch die Dinge,
die ich immer beobachte, wenn ich da irgendwelche
Projekte zu mache und
ja, das sind halt so, eben,
wenn man, die meisten denken, das ist kein
Problem. Woher kriegt man eigentlich Daten? Dabei ist das ein Riesenproblem.
Also das ist oft
etwas, was nicht wirklich gelöst wird
oder wo viel größere Schwierigkeiten
dann tatsächlich lauern.
Also man kann jetzt nicht alle Maschinen lösen, aber die haben gar keine Daten, um das zu tun.
Genau. Oder denken sie, haben die Daten,
kommen aber irgendwie nicht ran oder brauchen die Daten
aber in einem anderen Format und dann gibt es
irgendwelche Abteilungen, die sich da querstellen.
Das ist immer furchtbar. Also das ist immer ganz schrecklich, an die Daten
ranzukommen. Das ist meistens ein großes
Problem. Und
der hatte auch so ein paar lustige Beispiele dafür,
wie momentan da
also auch wirklich
kuriose Ideen der Leute kommen, um Daten
zu bekommen, weil sie momentan zum Beispiel,
also wenn man irgendwas mit Bilderkennung machen möchte
oder so, braucht man halt auch oft viele, viele Daten
und in Las Vegas
scheint es wohl mittlerweile üblich zu sein, dass da
irgendwie die
irgendwie
Hotelzimmer werden gefilmt. Ja, Hotelzimmer
oder man mietet auf Airbnb
diverse Geschichten und
bezahlt mehr oder weniger oder gibt Leuten Goodies
dafür, dass sie sich da reinstellen und dann
darf man Fotos von ihnen machen oder so, weil man
unterschiedliche Leute in unterschiedlichen Situationen
haben muss. Nicht, dass irgendwie das Modell
dann nur lernt, irgendwie
den gleichen Raum wieder zu erkennen. Das wäre ja doof,
deswegen braucht man unterschiedliche. Und es ist nicht so einfach.
Und dann ist das natürlich
auch relativ schnell, relativ teuer, wenn man die Daten
versucht selber zu generieren. Oder man muss irgendwie mit Drohnen rumfliegen
und Sachen fotografieren und sowas.
Klingt ja nach großem Spaß.
Ja, es klingt nach großem Spaß, aber es ist auch
so ein bisschen, das ist alles so wilder Westen momentan so ein bisschen.
Was ja auch, ja,
je nachdem.
Das wäre durchaus Spaß.
Ja, ja, genau.
Brown Code Tonight.
Genau, genau.
Das habe ich gehört. Das fand ich ganz cool.
Kann man sich mal anhören.
Ich werde einfach den Link dazu in die Show Notes packen.
Das hat jetzt aber gar nicht so viel mit Python zu tun,
sondern es war eher so,
wie kriege ich das eigentlich hin, wenn ich viele Daten zu annotieren
habe und zu labeln?
Eher so Data Science Machine Learning-Geschichten.
Dann hat die S-Guys was getwittert
zum nächsten Chat, glaube ich, war das.
Ja, ah, okay.
Genau, da ging es um
Pre-Talks, glaube ich.
Ja.
Meine ich.
Das war der nächste Eintrag.
Doch, ja, genau.
Und zwar ist das so eine
Konferenz
Organisationssoftware,
die halt irgendwie viele Leute verwenden.
Ist auch so eigentlich ganz
cool, Django-basiert.
die wurde auch verwendet, um
zum Beispiel die Subscribe, diese Podcast-Konferenz
zu machen. Ja, da waren wir ja auch.
Deswegen kam mir das schon so bekannt vor.
Es wurde auch damit
organisiert und viele Events
im CCC-Umfeld, vor allen Dingen wohl auch das Camp,
wird halt damit
geplant. Und
denen fehlt irgendwie
ein ordentliches Ticketsystem.
Und
irgendwie, dass auch Pre-Talks
irgendwie mit E-Mails ordentlich umgehen kann und so.
Und deswegen hat auch Twitter mal gefragt,
Und ob es da nicht Leute gibt, die sehr Lust hätten, sich mit zu beschäftigen oder vielleicht im Rahmen von einem Sprint auf dem Camp irgendwie da was dran zu tun. Gerne auch Einsteiger, weil man kann da sicherlich auch viel lernen und auch für andere ist es vielleicht mal eine Gelegenheit, Leuten was zu zeigen, wie Django da so funktioniert, was man da so tun kann.
Also fand ich auf jeden Fall eine gute Idee und das Ding wollte ich mir auch immer schon mal näher angucken und finde ich eine gute Gelegenheit. Ich würde da auch hingehen, wenn ich auf dem Camp wäre. Ich weiß es aber nicht. Ich fürchte, ich werde nicht da sein. Ganz vielleicht doch, aber wahrscheinlich nicht. Daher wird das leider nicht funktionieren.
Wann ist das denn überhaupt vielleicht für irgendjemand geneigt?
Das Camp ist irgendwie Ende
August. Ich glaube, es ist alles ausverkauft.
Schon lange jetzt. Ja, schon lange, genau.
Moment, ich gucke mal gerade.
Das CCC-Camp, wann ist denn das?
Also irgendwie
20. bis 25.
8.
Irgendwo in der Nähe von Berlin.
Genau.
Ja,
also ist auf jeden Fall,
wenn da zufällig jemand hingeht oder so, dann ist das
sicher eine gute Gelegenheit, um sich mal intensiver
mit Django beschäftigen zu können
und auch was Sinnvolles damit zu tun, was ja auch
nicht so, dafür gibt es ja auch gar nicht so
wahnsinnig viele Gelegenheiten oft.
Ja.
Und, ach, da hat eine Überleitung,
die da vielleicht auch
direkt Sinn macht,
ist,
habe ich auch gehört
in einem Podcast,
ja, ich bin momentan viel auf Spielplätzen
unterwegs und höre da Podcasts.
Kinder toben,
Vor allem dann langweilig, wenn man in der Sonne rumsteht.
Und zwar ging es da um Tiger.io.
Halt nicht so wie das gefährliche Raubtier,
sondern mehr so wie diese öde, weite Ödnis im Norden.
Das Projektmanagement-Tool, das wollen wir doch später besprechen.
Nee, aber das passt jetzt super, das hier dran zu flanschen,
weil das ist nämlich, könnte man super auch mit dem P-Talks
eigentlich verbinden, weil, na ja,
da fehlt halt vielleicht so ein bisschen Ticketsystem.
und das Tiger hat das
auch schon eingebaut und das hat irgendwie
ein ziemlich cooles Ticketsystem eigentlich
und das ist halt auch Django und das ist vor allen Dingen
Django REST Framework und hat eine super
API, das heißt, man kann das alles
toll auch irgendwie
ansteuern. Jetzt müssen wir nochmal kurz erklären, was denn Tiger
jetzt überhaupt ist. Also Tiger ist ein Projektmanagement-Tool,
wo man Boards bauen kann, Kanbans bauen
kann, so ein bisschen wie Trello, wenn ihr das vielleicht
kennt oder so. Ja, wobei ich würde
sagen, also wenn man
irgendwie Jira
Herzliches Beileid, wer es kennt, aber
ich war
öfter mal
das Missvergnügen, irgendwie da
mich mit Beschäftigen zu wissen und das war
immer meistens eher schmerzhaft. Das kann aber auch sein,
das ist einfach, ich meine, es ist einfach viel Zeug und ich
habe jetzt auch meistens nicht so viel Lust, mich
mit Projektmanagement-Software zu beschäftigen, daher
vielleicht lag es auch einfach daran, dass ich da nie
so wirklich durchschaut habe, wie das
funktioniert und
dann schnell was machen wollte und das ging dann halt nicht, weil es
kompliziert ist und dann war ich irgendwie frustriert.
Mag sein.
Vielleicht ist es auch einfach ein furchtbares Tool, kann sein.
Finde ich auch.
Also ich konnte es auch nie leiden.
Ja, das haben wir so auf der komplexen
Enterprise-Seite irgendwie
möglicherweise und dann irgendwie sowas wie
Trello, also die Mutterfirma von
Jira ist Atlassian,
die auch mal so, wie hieß das,
Bitbucket gemacht haben und so,
die sich jetzt aber eher so in die Projektmanagement-
Software-Ecke begeben haben, was wahrscheinlich
ein schlauer Schlagzug war.
Und auf der anderen Seite
Trello, genau, das eigentlich von den
Leuten, die auch Stack-Overflow gemacht haben,
irgendwie mal gegründet worden, aber
verkauft worden an
Atlassian. Aber
das ist eher so eine leichtgewichtige Geschichte
und gefällt mir, der Ansatz gefällt mir irgendwie besser,
aber auch wie man das bedient, gefällt mir besser.
Kann natürlich nicht so viel
wie Jira. Und das
sind sozusagen vielleicht die beiden Pole,
die so von
super komplex Enterprise bis zu
naja, relativ einfach und
schlank und leicht zu bedienen.
auf der anderen Seite, dazwischen
gibt es aber von Atlassian jetzt nix.
Und da ist
glaube ich, oder da positioniert sich
Tiger selber als, ist ein bisschen,
hat ein bisschen mehr Features als Trello,
aber ist nicht ganz so,
nicht ganz so
kompliziert wie jetzt Jira.
Aber, und es hat halt
als Kernfeature halt eine
API, sodass man quasi alles, man kann sogar mit der API
mehr machen, als man jetzt mit dem Frontend machen könnte.
Daher,
ja, es gibt irgendwie mobile
Apps irgendwie, die man da verwenden
kann, die jemand anders gebaut hat, aber der gesehen
hat, dass man die API verwenden kann und dann hat er das einfach mal gebaut.
Ja, also wir werden auch später noch
erzählen, wie man sowas denn auf dem Server hostet.
Das ist ja das, was wir damit tun. Genau, wenn man
das installieren wollte, ist es auch komplett
freistoffbar. Das heißt, man kann das irgendwie
lokal sich installieren und da betreiben. Das ist ja auch
für viele Leute wahrscheinlich ganz wichtig, dass man das
tun kann. Und man kann halt auch reingucken
und schauen, wie die da so Sachen implementiert
haben. Ich habe so ein bisschen reingeguckt und war,
das ist eigentlich ganz gut. Ja, man kann seinen eigenen Board bauen,
seine eigenen Trelle-Boards organisieren, kann man Boards auf seinem eigenen
Server basteln. Und sowas habe ich auf jeden Fall
vor. Finde ich ziemlich cool und ich bin schon
ziemlich gespannt, wie das alles funktioniert.
Ja, genau. Also Scrum macht
das Ding oder man kann halt auch
damit machen.
Ja, und
kann man sich ja mal anschauen. Ist eigentlich ganz nett.
Genau.
Ja, was hatten wir noch?
Wir wollten eigentlich noch ganz kurz auf die Frage von
Arnim eingehen, der uns eine E-Mail geschickt hatte.
Oh, das haben wir auch verschludert irgendwie.
Ja, das war ein bisschen her tatsächlich, schon im Mai, glaube ich.
Und ja, er wollte mehr über Error-Driven-Development hören.
Und ja, wir wollten eigentlich mal eine Folge zu Tests machen.
Ja, das machen wir auf jeden Fall.
Aber das wird noch ein bisschen dauern.
Ja.
Und deswegen so viel, ja, was meinst du denn überhaupt damit an?
Alle vielleicht nochmal irgendwie fragen.
Es gibt irgendwie da nicht so ganz klar, welche Methode.
Ich dachte, ich wüsste, was gemeint wäre.
Aber dann habe ich nochmal gegoogelt und dachte so, oh nee, ich weiß doch nicht.
weil, also ich glaube, das kam
als Reaktion auf einen Pick
aus einer Folge von Anfang
Mai, wo wir erwähnt hatten, dass es
MatMat gibt.
Das Ding
macht, sozusagen guckt halt,
ob, es ist mehr so eine
Geschichte, um zu schauen, ob deine Tests
halbwegs abdecken, was dein Code so tut,
indem es einfach deinen Code zufällig verändert
und dann guckt, ob die Tests brechen oder nicht.
Und wenn dein Code zufällig
verändert werden kann, ohne dass deine Tests brechen,
dann weißt du halt, okay, das ist ein Problem.
Und sie nennen das Mutation-Testing.
Das ist eigentlich auch eine ganz nette Idee.
Aber das würde ich jetzt Error-Driven-Development,
weiß ich nicht.
Leute benutzen den Begriff gerne als Gegenbegriff
zu Test-Driven-Development.
Beziehungsweise schreiben dann halt,
dass wenn du kein Test-Driven-Development machst,
dann machst du halt Error-Driven-Development.
Was vielleicht, wenn man sich das mal klar macht,
also natürlich ist das irgendwie schon so.
Und wenn man sich das mal klar macht,
dann kann man sich auch vielleicht vorstellen, dass es nicht so eine
super schlaue Idee ist, sondern dass man das vielleicht
ja dann gleich richtig
machen kann. Wobei, naja, ich meine,
ich würde auch dieses Test Driven Development
Kool-Aid nicht irgendwie
nicht einfach so schlucken,
sondern da
also man sollte Sachen vielleicht
nicht so total übertreiben,
was die Reinheit angeht, der Gedanken.
Ich
probiere auch oft lieber Dinge erstmal
aus oder so, bevor ich dann Tests schreibe, weil
man legt sich halt auch, was die Implementation
angeht, ziemlich fest, wenn man Tests schreibt.
Damit sollte man
sich dann schon halbwegs sicher sein, was das Ding eigentlich machen soll,
bevor man das tut. Aber
ja, es ist auf jeden Fall, Testschreiben ist eine gute Idee
und
sozusagen
sich nicht von den Fehlern, die
User anreporten, quasi
die Tests
als Tests zu benutzen,
ist wahrscheinlich eine ganz schlaue Idee.
Aber wie gesagt, ich weiß nicht genau, was gemeint war.
Insofern nochmal nachfragen. Wir machen auf jeden Fall
eine Folge zu Testing
mindestens noch jemanden finden, der
irgendwie Lust hat, da mit uns drüber zu reden.
Test ist nämlich immer das spannendste Thema von allen.
Ja, was
noch mal, das ist ja auch schon fast ein Monat her jetzt,
wir haben ja schon Juli, ist gerade eine Folge
Visual Studio Code und da auch über Test,
da kam ich gerade drauf, glaube ich,
die man mit Visual Studio Code machen kann und
das Debugging-System auf
TalkPython2Me.
Ja, ja, ja, das war irgendwie der, glaube ich,
der Chef von den Produkt-Ownern
für Visual Studio Code irgendwie, der da
interviewt wurde. Der hat eine Menge
auch interessante Sachen erzählt.
Ja, vor allen Dingen, dass Visual Studio
Code halt auch irgendwie bei Python-Entwicklern
so super populär
ist irgendwie, womit sie gar nicht so
berechnet hätten am Anfang, aber das hat sich irgendwie so
rausgestellt. Offenbar gab es da irgendwie so
eine Marktlücke.
Ja, ich benutze ja jetzt auch schon eine Zeit lang
Visual Studio Code.
Hast mich angesteckt.
Ja, war eine gute Idee.
Es ist tatsächlich auch ein
Editorialisierer. Ich meine, es ist so eine,
viele Leute mögen ja dieses
Elektronen, es ist auch eine elektronenbasierter
Editorial insofern.
Ja, viele mögen das nicht so, aber
es funktioniert ziemlich. Also wenn ich das
zum Beispiel vergleiche mit PyCharm, PyCharm
habe ich ja auch irgendwie eine Zeit lang verwendet,
oder fand ich auch ab und zu immer noch, aber
tatsächlich fühlt sich das
irgendwie deutlich
softer an, so smoother. Ja, irgendwie
snappier, ich weiß nicht, was
kam da noch vor? Ja, es gibt da so ein paar Sachen, die funktionieren direkt,
also irgendwie, ne? Es ist einfach viel schneller.
es fühlt sich schneller an. Vielleicht ist es gar nicht schneller, aber es
fühlt sich schneller an. Die Sachen reagieren einfach
viel. Also die Latenz, wenn man auf irgendwas
drückt oder so oder irgendeine Tastenkombination eingibt,
die Latenz, bis dann was passiert, ist
deutlich schneller. Vielleicht hast du ja noch ein Rechner
gekauft inzwischen. Ne, ne.
Daran
liegt es nicht. Und ja,
das ist halt, also, ja, ich weiß nicht,
wie sie das, ich weiß auch nicht, vielleicht macht auch
PyCharm irgendwas falsch, keine Ahnung. Ja, das ist echt cool. Also
irgendwie, wenn man seinen Code damit verwalten will,
irgendwie auf Git oder sonst irgendwo,
das funktioniert super. Integration mit Azure ist
toll. Man kann direkt automatisch CI
irgendwie CD machen und
das alles pushen. Man kann Live-Sharing
machen und dann gemeinsam am Code arbeiten, was auch
ziemlich gut funktioniert.
Link und Multicursor und
Übertragung und
Terminal und mittlerweile, also in dem
Nightly-Bild war das drin, ich glaube, das müsste mittlerweile
sowas von im Stäbel sein, dass man jetzt auch über SSH
einfach sich irgendwo auf eine Maschine legen kann
und da im Verzeichnis entwickeln
kann, dass das auch ziemlich praktisch
kannst du auf deine VSL-Maschine gehen oder auf
in Respy oder auf einen anderen Server, wenn du
lustig bist und direkt da editieren.
Das ist ja auch oft ein Argument, was man hört, dass
Leute sagen, ja, ich nutze halt
VI oder Vim, weil da habe ich überall die gleiche
Entwicklungsumgebung und
ja, auch wenn ich mich auf irgendwelchen Produktionsmaschinen
einlogge, kann ich da auch mal
meine Umgebung
so wie ich da, aber genau,
ist natürlich in gewisser Weise ein Argument, aber geht mit
VS Code jetzt auch. Braucht man gar nicht mehr
unbedingt Vim für verwenden.
Also falls noch jemand herausbekommen hat, wie man
sowas wie Foxdot verwendet mit VS Code,
Das habe ich nämlich noch nicht hinbekommen.
Das ist Live-Evaluation von Python-Code.
Da hätte ich noch Lust drauf.
Das würde ich gerne noch rausfinden.
Das müsste irgendwie funktionieren.
Dass man irgendwie, weiß nicht, Alt-Enter drückt oder sowas.
Und dann spielt er direkt die eine Zeile.
Dann kann man Musik machen mit Foxhut für Python.
Das fände ich noch super.
Sonst muss ich mich irgendwie dran basteln.
Aber ja, so viel.
Wenig Zeit für so viele Projekte, ja.
Du hattest irgendwas noch reingeschrieben.
PySimple?
PySimple GUI.
Ja, da gibt es jetzt noch einigermaßen fünffige Versionen.
ist jetzt auch irgendwie vor, weiß nicht wann das
rausgekommen ist, vor ein, zwei Wochen oder so,
die man ganz gut nutzen kann. Das ist
ein Wrapper für
Tkinter, TK oder
PyQ5. Kann man beides benutzen
mit derselben Syntax. Man kann halt einfach angeben, welches
der dann visualisieren soll und
hat einen relativ einfachen GUI für die
ja, Python ist ja nicht so besonders stark
bei grafischer Programmierung und
das kann man damit aber ganz gut und
vor allen Dingen schnell und effektiv erledigen.
Das lohnt sich vielleicht da auch mal kurz
reinschauen. Wollen wir mal angucken.
Genau, jetzt hast du mir meine Woche schon fast geklaut.
Ach so, sorry.
Oh, ein Podcast, den ich auch noch gerne
erwähnen würde, ist auch einer
der letzten Django-Chat-Folgen
mit Simon Willison.
Also einer der Leute, die auch Django
quasi so mit aus der
Taufe gehoben haben.
Ziemlich,
ist also mit vielleicht, also Audioqualität
ist manchmal so ein bisschen, aber
ansonsten inhaltlich fand ich das
sehr, sehr gut. Das war sehr, sehr
spannend, was er da so alles erzählt hat,
also was die Geschichte von Django angeht, aber auch
was so die aktuellen Entwicklungen sind,
was er für spannend hält, ne, und das halt
gerade irgendwie,
ja,
so momentan spielt,
Async-Geschichten spielen da eine große Rolle, ne, die sind gerade
sehr spannend oder
sein Privat, oder sein
Pet-Project, was aber jetzt auch
mittlerweile so groß geworden ist, dass
Pet oder Pet?
Ja, ja, so ein Nebenprojekt halt, aber
es ist nicht mehr wirklich so neben, sondern er hat ja irgendwie auch
eine... Das Peißen-Halsband für die Katze, oder?
Nee, ja, also
er hat da irgendwie eine
Fellowship gekriegt, ich weiß es nicht genau, wo er dann von
irgendeiner Uni ein Jahr lang bezahlt wird, dafür
das jetzt zu entwickeln, das schon mal...
Also, daher geht auch die Entwicklung da
relativ schnell voran. Das Projekt heißt
Dataset. Ach so.
Genau, das ist mir auch
früher schon mal aufgefallen, hatte ich bestimmt auch schon mal ein paar Mal
erwähnt oder so. Ich glaube schon, hast du schon mal drüber gestolpert.
Ja, genau. Darüber
können wir bestimmt auch noch mal eine eigene
Sendung machen. Ich wollte mich
damit auch noch intensiver beschäftigen. Das ist
eigentlich eine sehr coole Idee,
wie man
mit einer SQLite-Datenbank
halt Datensätze
irgendwie verfügbar machen kann
öffentlich, und zwar
auf eine Art, wie man halt sehr, sehr gut das abfragen
kann, aber ohne, also man kann eine SQL-State
und es einfach verwenden und man kann auch so coole Sachen
machen wie JavaScript benutzen,
um SQL-Statements zu erzeugen, die man da verwenden kann,
um die Daten noch zu fragen, voll gut.
Und normalerweise ist das alles puri bär, weil
schrecklich, schrecklich SQL-Injection
droht und so, aber
man kann SQL
SQLite
so starten, dass man sagt,
das ist dein Datenbankens Read-Only
und dann ist das alles nicht mehr schlimm, weil es kann nichts
passieren. Und
da ist das, was man normalerweise nicht tun sollte,
dann plötzlich alles erlaubt und cool.
Das ist
einfach, es ist nett.
Es hat viele überraschende Wendungen, dieses Ding,
wo man sich denkt, ach cool, das geht und das kann man
so machen. Ja, die Datasette-Folge
müssen wir uns da nochmal aufschreiben, die steht nämlich gar nicht noch.
Ja, die muss da noch mit
drauf. Genau, das war
also diese Podcast-Episode kann ich
Leuten durchaus, die sich für Django und so interessieren
ins Herz legen, ist ja
sehr nett. Ja, ich würde sagen, jetzt
haben wir aber die News halt durch und machen den nächsten Chapter,
Marc, weil so langsam löchere ich dich jetzt
damit, wie das denn jetzt überhaupt funktioniert mit dem Server.
Und wir fangen wirklich von ganz
Basis-Bodensatz an, also so
gar keine Ahnung, wie macht ihr das und so und wo
und ja, ich möchte nämlich auch wissen,
wie man das am besten macht, so Best Practice,
was sagt denn Jochen dazu?
Und ja, ich würde sagen, können wir starten
jetzt mit unserem Hauptthema, Server. Dann starten wir da mal.
Server, die Plattform für Anfänger, ja.
Erstmal Server,
was ist denn das? Also irgendwo so
ein Rechner, der irgendwie bedienbar ist,
das sollte ja irgendwie so klar sein, aber
ja, wen nehme ich denn da?
Also, was mache ich denn da für einen Server?
Nämlich irgendeinen Hosting-Anbieter,
Cloud-dedizierten Server, virtuellen
Server, warum und so.
Boah, ich brauche ja noch irgendwie
jetzt eine Domain und so, ne?
Wie würdest du das irgendwie so...
Ja, also was man auf jeden Fall tun sollte,
ist halt irgendwie eine Domain selber registrieren
und was
nicht so... Also, man sollte
vielleicht... Da schreibst du einen Brief und schickst den an eine Stelle.
Ja, nee, da gibt es ganz viele Anbieter.
Ich weiß nicht, kann man... Ich bin das Universum, ich hätte gerne diese Domain.
Ja, es gibt ja diverse Anbieter,
da muss man halt ein bisschen Geld bezahlen,
das kostet gar nicht so viel pro Jahr
und dann hat man halt ein Domain.
Du hast gesagt, selber registrieren,
also es gibt ja verschiedenste Server,
Hoster, die das alles mit einbieten.
Ja, aber das ist vielleicht nicht so eine schlaue Idee,
das zu machen, sondern besser.
Aus welchem Grund?
Weil man das ja ändern können will.
Also bei vielen kann man das auch ändern,
das ist kein Problem,
aber ich kenne das auch,
dass viele, also so gerade, weiß ich nicht,
eben diese, ja,
Welt, Wald und Wiesen
Muster.
Da hat man dann oft irgendwie so ein Formular, wo man
irgendwie DNS-Geschichten eingeben kann,
aber dann halt die Sachen, die man braucht,
also weiß ich nicht, irgendwelche,
wie heißen diese Dinge,
Verified Domain,
SPF Records oder, also es gibt
diverse Records, die man unter Umständen einstellen
können möchte. Was ist ein Record?
Oh Gott, oh Gott, oh Gott.
Erklären, wie das Domain Name System funktioniert.
Also das ist im Grunde eine verteilte Datenbank,
die
Informationen darüber
enthält, wie
Namen auf
IP-Adressen aufgelöst
werden und umgekehrt.
Das heißt, da steht irgendwo, wenn man irgendwie den
Nameserver irgendwie fragt, keine Ahnung, der Einzige,
der wahrscheinlich bekannt ist, der von Google mit den
4.8 oder sowas oder 8.4.4
oder was und dann gibt es ja auch noch einige unabhängigere,
wenn man nicht alle seine Daten zu Google schicken möchte.
Aber die fragt man dann und die wissen
dann, wo, hinter welcher IP oder hinter
welchem Namen, welcher IP steht.
Ja, man kann auch einen eigenen Resolver betreiben. Also man kann das
durchaus von Hand auch machen. Das ist vielleicht mal eine ganz interessante
Geschichte, dass man halt irgendwie
das mal einfach von Hand mit
den S-Abfragen
irgendwas resolft.
Man resolft das halt so von hinten nach vorne. Also wenn man
jetzt irgendwie
pythonpodcast.de hätte, dann würde man
erstmal gucken, okay, also was man wissen muss
ist, man braucht
irgendwie so einen Root-Nameserver, aber wenn
man eine IP von dem hat,
dann kann man den halt fragen, okay, was ist denn der
Nameserver, der zuständig ist für die .de
Zone. Und der Root-Nameserver, das sind
die großen Knotenpunkte? Ja.
Kriege ich das irgendwie raus, wenn ich so ein Trace-Root mache,
wo die irgendwie hängen? Ja, die sind
weltweit verteilt. Da gibt es ein paar von
Rootservers.net, irgendwie
a.rootservers.net oder ein paar,
also ich weiß jetzt gar nicht mehr genau alles
schon, altes Wissen, vielleicht ist auch
mittlerweile alles anders, aber
auf der ganzen Welt sind da ein paar von denen verteilt
und
normalerweise, also einige von denen
sind halt einfach, die IP-Adressen sind halt eingebaut in
diverse
Resolver-Libraries daher.
Aber das muss man irgendwie wissen, sonst kommt man halt
auch nicht weiter. Und von denen
kann man sich dann halt durchhangeln bis zu der
Domain, die man eigentlich haben möchte. Und quasi
für jeden Teil der Domain
fragt man dann halt den entsprechenden Nameserver.
Also über
eben die Records, also NS-Records sind halt
die Records, die zuständig sind, einem
zu sagen, was denn der Nameserver
zuständig Nameserver ist. Also ich frage halt quasi den
NS-Record für .de
den Root-Server und dann kriege ich halt
irgendwie den Nameserver, der zuständig ist für die
.de-Zone
und das ist halt
na, wie heißen sie noch?
Hier
DENIC, da habt ihr irgendwo
Frankfurt steht, glaube ich
und die haben
dann das .de-Zone-File irgendwie
drin und da steht dann halt
drin, wer, also in dem File steht vor allen Dingen
stehen die NS-Records für alle
DE-Domains, sozusagen.
Wenn ich jetzt wissen will, wer ist, welcher Name-Server
ist dann zuständig für Python-Podcast.de,
dann hole ich mir den NS-Record
für Python-Podcast
in dem
Name-Server, der für .de zuständig ist
und dann, genau,
kriege ich das irgendwie zu.
Könnte ich das auch irgendwie selber machen, dass ich irgendwie sage, so, hey, hier,
ich heiße jetzt gerne
DominikMeinPython
kommen oder sowas, oder DE, wir wollen ja zu
DIN-NIC und dann sage ich der DIN-NIC so,
hey, wer scannet so, ist das noch frei
und schick das dann irgendwie da bei
DIN-NIC-Liste. Das geht nicht unbedingt so
einfach. Das heißt, ich muss da ein Registrier
Registrar für verwenden.
Ja, also früher ging das auch.
Ist man da vorbeigegangen beim DIN-NIC, hat er die Tür
geklopft und gesagt, hallo. Ich hätte
mal so gerne ein Domain.
Aber das geht schon lange nicht mehr.
Da kamen so viele Leute wahrscheinlich
auf diese Idee.
Ja, das
geht schon lange nicht mehr. Aber
genau, man braucht... Also bei Gandhi macht das dann zum Beispiel
wenn ich jetzt bei dem... Ja, es gibt ganz viele
unterschiedliche, also ich weiß gar nicht, ob es da
ich weiß nicht, ob das, was ich da finde, gut ist oder
nicht, keine Ahnung. Es spielt auch keine
große Rolle, weil es ist, die können alle irgendwie
mehr oder weniger das Gleiche.
Ja, aber was wichtig ist,
dass man selber das registriert hat und selber dann
sozusagen die
Sachen ändern kann und halt auch das umziehen kann,
wenn man mag und so. Und das ist halt
bei diesen, wenn man das beim Provider macht,
oft ist es auch so, dass das geht, aber
manchmal halt auch nicht und dann hat man ein Problem.
wenn man zum Beispiel den Hoster wechseln möchte.
Ja, und ja, genau.
Aber ja, das ist so das Erste, was man braucht.
Ja, okay.
Einen eigenen Domain.
Braucht man noch für viele andere Dinge.
Wenn man Indie-Web machen will, braucht man auch einen eigenen Domain.
Jetzt brauchen wir irgendwie so einen Computer, der irgendwie so läuft.
Also die Frage ist, muss der schnell sein, muss der langsam sein?
Was ist das denn?
Also haben wir da tatsächlich einen eigenen Computer,
der mit Kernfestlöse ...
Oh, sorry, stopp, stopp, stopp.
Ich war mit dem Auflösen noch nicht fertig.
Also wenn man jetzt den NS-Rekord von einem Domain hat,
das heißt noch nicht, dann muss man den nehmen.
aber noch fragen, was ist denn jetzt zum Beispiel der
A-Record? Das ist halt das, was halt die IP
einem gibt für
eine bestimmte Domain.
Es gibt auch noch andere. Es gibt MX-Records,
die halt einem sagen, wo die
wer zuständig ist für Mail.
Es gibt halt, ja, es gibt
eine ganze Menge Zeugs. Es gibt
doch Text-Records und weißer Teufel
und manche von denen werden auch missbraucht,
um andere Sachen zu signalisieren. Aber wenn man solche Sachen
machen möchte, wie
man möchte Mail irgendwie
von einem Drittanbieter machen
lassen, weil man keinen Bock hat, das irgendwie alles selber
aufzusetzen und zu
maintainen, dann muss man da
eine ganze Menge Records
setzen und so, oder auch für andere
Geschichten, Services, die man da benutzen kann,
damit halt sozusagen andere
unter, mehr oder weniger
unter der Domain auftreten können.
Ja, das würde ich auf jeden Fall auch machen.
Ich möchte ja gerne ganze Projekte unter unterschiedlichen
Domains, die ich mir dann irgendwie buche,
Vielleicht auf einen größeren Server legen
und die dann irgendwie da reinrouten?
Ja, das ist nochmal ein anderes Problem.
Das geht natürlich auch, aber allein
ist gut, DNS unter Kontrolle zu haben.
Jedenfalls, also man muss nicht unbedingt
einen eigenen Nameserver betreiben. Das mache ich
teilweise noch, aber das ist auch irgendwie
eher schmerzhaft.
Weil man hat auch direkt so mit Security
Geschichten oft, dann gibt es so diese
komischen DNS-Amplification-Angriffe
und blöde Geschichten
und so Zeugs, mit denen man zu tun kriegt.
Ja, aber
man will das eigentlich, glaube ich, nicht unbedingt selber
betreiben, wenn man da nicht Spaß dran hat, aber
trotzdem möchte man
die Rekords bestimmen können, weil das für
viele Services, die man sonst so benutzen möchte,
halt auch wichtig ist. Ich glaube, damit
sind wir aber mit DNS im Grunde durch.
Ja, jetzt kommen wir endlich auf den Server. Jetzt haben wir so einen Server, der hat dann
irgendwie nur so eine IP und dann
wissen wir noch gar nicht, ist das fest oder nicht, aber...
Nee, noch nicht. Wir haben nur das DNS
unter Kontrolle. Wir können das jetzt auf eine beliebige IP
zeigen lassen, sozusagen. Zum Beispiel einfach, dass wenn man
jetzt... Es gibt sowas wie DynDNS,
Das heißt, wir könnten sogar zu Hause einfach einen Rechner ans Netz hängen
oder so, wenn wir eine Dynamische haben.
Dann musst du dann Games aber selber
betreiben, irgendwie wahrscheinlich.
Ich glaube, es gibt so einen Service, da muss man immer nur
sagen, hey, ich bin jetzt hier, ich bin jetzt hier, ich bin jetzt hier.
Ja, klar. Es gibt auch in vielen Routern
ist das eingebaut, zum Beispiel eine Fritzbox
macht das. Da kann man einfach
sagen, das ist mein DNS-Anbieter
und dann
kriegt man halt immer eine entsprechende,
dann macht die das automatisch.
Wenn sich die IP-Adresse ändert, dann schickt die halt
irgendwie ein Request dahin und sagt, okay,
findest mich hier, hallo. Genau, und dann
kann man auch sein Kram zu Hause immer
erreichen, ja.
Wobei man da wahrscheinlich eigentlich eher sowas
wie ein VPN verwenden will, aber
DynDNS geht auch, aber ist eigentlich heutzutage
alles nicht mehr so richtig relevant, glaube ich.
Ja,
genau, also wenn man DynDNS unter Kontrolle hat,
dann kann man halt jetzt, wenn man
jetzt einen Server hätte,
irgendwo, der unter der IP
verfügbar ist, dann
kann man sozusagen
die Domänen darauf zeigen lassen.
So, und jetzt ist die Frage, was für einen Rechner will ich denn da haben? Will ich irgendwie vom großen Rechenzentrum haben? Will ich einen bei mir zu Hause in die Ecke stellen? Möchte ich irgendwie so einen Cloud-Server mir mieten? Möchte ich so einen dedizierten Server haben? Das kann man ja skalieren von 2 bis, weiß nicht, wahrscheinlich 200, 2000 Euro im Monat.
Ja, das kommt drauf an. Also was man damit vorhat, für die meisten Leute wird irgendwie da weniger, wahrscheinlich eher mehr sein. Also es wird wenig reichen, weil...
Es gibt ja auch so WordPress-Hosting-Anbieter
oder sowas, da kann man wahrscheinlich nichts anderes machen,
außer ein WordPress-Blog
drauf hosten, der auch schon
ziemlich viel kann, wenn man jetzt nicht so viele
Besucher hat.
Ist aber nicht das, was man wahrscheinlich
haben will, wenn man jetzt Python macht oder so.
Da möchte man das vielleicht schon
selber tun können. Also es gibt auch
eben für Python-Hosting
nicht so viele
Anbieter, die da...
Was ist denn jetzt Python-Hosting? Weil ich dachte, da läuft jetzt ein Computer.
Genau, ja.
Das ist halt, also bei WordPress ist halt klar,
das ist halt die Software. So was gibt es natürlich
für bestimmte
Python-Geschichten auch. Also es gibt
zum Beispiel, muss ich jetzt nochmal nachgucken,
habe ich letztens irgendwie gesehen, wenn man jetzt einfach nur ein CMS
haben will unter der Domain, da gibt es ja auch Anbieter,
Diego, Diego, Diego,
ich weiß es nicht mehr, muss ich mal nachgucken.
Die bieten an, dass man
irgendwie ein Wagtail CMS
oder halt ein
Django CMS
bekommt, da gehostet
und das ist dann so ähnlich wie WordPress-Hosting.
Okay, das läuft dann auch im virtuellen Container irgendwo.
Nee, das weiß ich nicht,
ob die da einen extra Container pro Seite hochfahren.
Ich denke nicht.
Also wenn man sich zum Beispiel anguckt,
was da die User sind,
die man teilweise, wenn man in manchen Feldern
versucht, irgendwas einzugeben,
dann kommt eine Liste der User hoch oder so.
Da kommt ziemlich wildes Zeug hoch.
Das heißt, ich gehe mal davon aus,
dass es nicht irgendwie pro Domain oder so gekapselt,
sondern das ist halt eine Datenbank, auf der alle sind
und dann gibt es halt unterschiedliche Sites
und das ist ja auch durchaus
vernünftig unter Umständen, also
du brauchst nicht unbedingt einen Container
für eine eigene Seite, da ist
es gar nicht
nötig, ist ja bei WordPress-Geschichten wahrscheinlich
auch nicht so
und
genau, das gibt durchaus da auch Anbieter,
aber das sind viel weniger als jetzt im PHP-Umfeld
oder WordPress oder so, wo das halt
eine große Geschichte ist,
was eher
eher eine Rolle spielt, wenn man
jetzt Python-Applikationen irgendwo hosten will,
ist halt sowas wie, also wenn man jetzt kommerzielle
Anbieter, wir gehen einfach mal von einfach
zu, es wird schwieriger oder komplizierter oder
man kann mehr selber kontrollieren
durch, wenn man
so, die heißen alle so Platform-as-a-Service
Anbieter
sich anguckt. Also ganz oben wäre sowas
wie eben, du kriegst halt
irgendwie dein Backtail-CMS und hast dann
halt ein fertiges CMS unter deiner Romain.
Das wäre halt sozusagen alles
Am besten
nur noch mit Admin-Interface. Genau, das wäre
dann auch irgendwie so quasi, ich weiß gar nicht, ob das das wäre,
wahrscheinlich Software-as-a-Service, mehr oder weniger
Modell. Dann Plattform-as-a-Service ist,
naja, du
sagst nicht, du kriegst
jetzt nicht eine fertige Webseite,
sozusagen, schlüsselfertig,
sondern du kannst... Schlüsselfertige Webseite,
ja. Sondern du kriegst halt
irgendwie, du hast
halt einen Account bei Heroku oder sowas,
Ampeter wären das sowas wie Heroku oder Python Anywhere oder so
und
da
Ich den Vergleich mit diesen Häusern
unheimlich toll. Mit den Hochhaus-Hindställen
und Gartenhütte.
Ja, also sag mal so, das ist halt
im Grunde, ja, da sind das
dann oft wahrscheinlich Container, die da hochgefahren
werden und du hast halt solche Dinge
wie Datenbank ist halt schon einfach
Du wohnst in einem Hotel und dann gehst du
in die Lobby. Es ist quasi so eine Art Hotel.
Ich weiß nicht, ob
diese Analogie trägt, also wenn
Software ist ein Service.
Lieber Concierge, ich hätte gerne einen Kaffee.
Ja, was wäre denn das fertige WordPress,
was man sich nur noch einloggen braucht?
Da ist der Pool schon vorgeheizt.
Ich würde sagen, das ist doch eigentlich eher das Hotel, oder?
Wo man sich um nichts kümmern muss.
Und Heroku ist die Ferienwohnung, wo du selber kochst.
Ja, und Heroku ist so ein bisschen die,
es ist eher so, nicht mal das,
ist es eher so der
die
Schuhkarton-Eigentumswohnung irgendwo
der Container halt. Oder es ist wie der Container auf dem Schiff,
ja, wo man irgendwie die ganze
Inneneinrichtung und so, das muss man halt selber machen, weil es ist halt
nicht drin. Und das kann man auch komplett austauschen.
Das ist natürlich auch irgendwie ein Vorteil.
Da kannst du halt sagen, okay, ich deploy da
halt irgendwie ein Flask-Ding
hin oder halt eben ein Django
hin oder so.
Aber du bist da halt nicht festgelegt, ja.
Also auch nicht auf, ja.
Und, ja, aber diverse andere Geschichten werden dann schon abgenommen.
Also man kümmert sich sozusagen nur noch um den Teil,
der halt, wenn man alles selber machen würde,
im Applikationsserver, jetzt nenne ich das mal so, laufen würde.
Um den Applikationsteil kümmert man sich.
Aber sowas wie Datenbank, das macht man nicht selbst.
Da gibt es dann halt, und es gibt auch endlos viele andere Plugins
und Dinge, die man dazuklicken kann, Suchmaschinen oder irgendwas.
irgendwelche anderen Sachen, die man halt auch
verwenden kann und das muss man alles dann nicht selber machen
bei Heroku jetzt beispielsweise, sondern das ist halt
dann einfach da.
Und man kümmert sich nur um die
Applikationen, die man dahin deployt und
natürlich definiert man irgendwie die Datenbank
dadurch, dass man jetzt in Django beispielsweise die ganzen
Modelle halt irgendwie
definiert und die werden dann halt auch
in der Postgres irgendwie
eingelegt, aber man betreibt die Postgres-Datenbank
nicht mehr selber, sondern das macht halt
entweder Heroku oder einer von den
Drittanbietern, die halt ein Postgres-Plugin
für Heroku anbieten. Für einen.
Was natürlich dazu führt, dass es
wesentlich weniger
aufwendig ist für einen Server.
Aber man ist halt auch so ein bisschen
eingeschränkt und
diese Geschichten führen halt oft dazu,
also ich habe das tatsächlich mal
versucht, weil ich habe versucht für
es ist ja auch sowas, wenn man
Das klingt nicht nach einem gelungenen Experiment.
Ja, für DjangoCast
wollte ich einfach mal so, wie ist das denn,
wenn man das jetzt auf Heroku mal deployen will zum Testen,
damit man es halt draußen irgendwo
laufen hat, aber
ja,
man möchte jetzt nicht vielleicht irgendwie so ein
Commitment eingehen, da jeden Monat Geld zu
bezahlen oder so, oder hat halt
dann auch keinen Root-Server irgendwo rumstehen, den man
benutzen könnte. Darauf kommen wir irgendwie später wieder.
Ja, dann wäre es
doch ganz praktisch, wenn man das einfach mal nach Heroku oder
so deployt und dann mal guckt, wie das so funktioniert.
Dachte ich, das wäre eigentlich ganz nett. Und
zumal halt all diese Anbieter alle so
freie Container anbieten,
die also für Hobby-Benutzung
oder so, die halt nichts kosten,
die dann auch bestimmte Anforderungen
nicht erfüllen, beziehungsweise keine garantierte,
die sind beim ersten Laden oft langsam,
weil das wahrscheinlich unten drunter irgendwie
Docker-Container oder vielleicht
benutzen die dann irgendwie Lambda-
Funktionen bei AWS oder so,
wer weiß. Genau, das ist das denn jetzt schon wieder?
Nein, nein, nein.
Ich bin mir noch auf.
Also da kann es sein, dass der Container erst gestartet
wird, wenn so ein Request reinkommt und dann ist
das halt ein bisschen langsam und doof und
aber es stört ja nicht, wenn man
das eh nur so
mal ausprobieren möchte
und
ja, und dann
habe ich mich da gemacht, da so ein bisschen eine Anleitung
für zu schreiben und dann ist mir relativ schnell
aufgefallen, es ist nicht so einfach
und ich war überrascht, wie knifflig
das ist und ich bin immer noch ein bisschen überrascht,
dass auch Heroku da keine gute Anleitung
für hat, wie macht man das eigentlich,
die machen auch Ruby on Rails und
auch Node.js und weiß der Teufel, aber
trotzdem, es ist schon
irgendwie, es war schwerer als ich dachte und ich dachte
mir so, ui, also
wenn jemand daran knabbert, dann
weiß ich jetzt nicht, ob ich jetzt anfänge, unbedingt
mich da so reinstürzen möchte.
Ich meine, auch dieses Jungle for Professionals
Buch kann man sich auch mal angucken. Auch der,
obwohl Vincent meinte es schon so, dass das alles
irgendwie immer, also die Sachen so hinzukriegen, dass sie dann
tatsächlich funktionieren, ist oft schwerer, als
man so denkt. Und es war echt nicht mal
ganz einfach. Das Containerschiff ist vielleicht überladen und
hat irgendwie halbe Schlagseite. Man weiß es nicht genau.
Ja, aber es ist halt, also ich fand
jetzt überraschend, wie viel wenig
einfacher das ist, als wenn man alles selber
macht. Also der Schritt von, also ehrlich
gesagt, ich finde es, das mag daran liegen,
dass ich das häufiger selber mache
irgendwie. Ich fand es einfacher, das selber
zu machen als bei Heroku.
Weil man stößt halt sofort auf so Probleme.
Gut, kann auch sein, dass mir das,
vielleicht ist das vielen Leuten egal, aber ich denke mir
halt so, naja, heutzutage Webseite ohne
SSL, das ist eigentlich eher kaputt. Also das
muss eigentlich, SSL muss irgendwie gehen
und eigentlich ist das ja auch kein Problem mehr mit Let's Encrypt
und so. Aber
für die Hobby-
Seite bei Heroku, bei denen
funktioniert das nicht.
Und es hat mir
nicht leicht gefallen, rauszukriegen,
dass es wirklich nicht funktioniert.
Und ich musste da tief graben.
Und ich bin in irgendwelchen Issues gelandet, wo dann
einer der Entwickler bei Heroku dann irgendwie
schrieb, das sollten wir vielleicht mal in die Dokumentation schreiben,
dass das wirklich nicht geht. Also auch mit diesem
Weg geht das nicht. Und da dachte ich
schon so, ja, solltet ihr vielleicht, weil
ich habe jetzt gerade da irgendwie ganz schön
Zeit reingesteckt, das rauszukriegen. Also weil
es sah so aus, als würde es vielleicht doch funktionieren, wenn man dann
irgendwie die Zertifikate von Hand hochlädt oder so.
Nee, tut's nicht. Und dann habe ich mir erst
lokal irgendwie Zartbord installiert
und da irgendwie auch rumgeeiert.
Aber es ging dann alles am Schluss nicht.
Also SSL, HTTPS, Heroku
nur, wenn man zahlt. Sonst geht's nicht.
ja, auch die,
wenn man jetzt irgendwie
ein CDN verwendet oder so.
Content Delivery Network, ja, da müssen wir auch nochmal
gleich noch klauen. Ja, da kommt alles noch dazu.
Ist alles... Anfängerfreundliche
Folge, Jochen. Ja, ist alles nicht so
einfach. Auf jeden Fall, also ich meine, man kann
sich das mal angucken, wenn man
jetzt auf HTTPS nicht so viel Wert liegt
oder dann kriegt man auch
mit Heroku wahrscheinlich schon halbwegs
schnell da irgendwie zum Ziel.
Es gibt glaube ich noch ein paar.
Und
das kann man auf jeden Fall auch verwenden.
Also man hat auf jeden Fall diesen ganzen
operativen Kram von der Backe, was natürlich auch
schon mal ein großer Vorteil ist. Also man muss sich nicht dafür
also man muss sich nicht
selber dafür interessieren,
wie das Zeug jetzt, ob das oben ist oder
nicht. Also das macht halt
jemand für einen und das
ist ja auch schon mal nicht so schlecht.
Ja,
das wäre sozusagen eine
Zwischenschicht zwischen irgendwie alles ist fertig
und... Hört sich nicht so an, als würde ich das
machen wollen, ehrlich gesagt. Doch, also ich kann mir
durchaus vorstellen, dass es gute Gründe gibt, das zu machen.
Nee, für mich nicht.
Ja, finde ich jetzt nicht,
aber... Nach der Dokumentation ausgeschlossen,
ja. Finde ich jetzt nicht, aber
ich denke schon, dass es für mich, aber
oder es gibt, was auch oft eine Falle ist,
wenn Startups irgendwie anfangen mit sowas,
dass sie dann irgendwann doch viele
Datenbank-Queries machen und da
sind auch, das ist eine ganze
Menge, ist irgendwie frei.
Aber wenn man dann aus diesem Bereich, wo
das frei ist, irgendwie rauskommt, dann wird es sehr, sehr schnell
brutal teuer.
Und das ist auch so etwas, was man vielleicht
nicht unbedingt haben will. Aber das Problem
ist, wenn man dann gerade wächst oder so, dann kann man nicht mehr so schnell
irgendwie. Die Infrastruktur komplett umfassen.
Ja, und dann gibt man halt ein
Vermögen. Dann gibt man Arm und Bein
an diese Anbieter.
Was ja irgendwie so dein Geschäftsmodell
ist. Ist auch nicht verwerflich, finde ich. Ist okay, aber
man sollte sich halt bewusst sein, dass man da eventuell ein Problem
bekommen kann.
Ja, also das ist eine Möglichkeit,
die man halt auch machen muss.
Jetzt müssen wir aber nochmal ganz kurz, bevor wir das alles wieder vergessen haben,
kurz eingehen auf Content-Division-Network.
Du musst auf Division-Ocean nochmal kurz erklären und
AWS-Lambda-Funktion.
Ja, also wenn wir jetzt bei
Software-as-a-Service,
Plattform-as-a-Service. So, jetzt werden
wäre quasi das Nächste, was nicht mehr
das, wo man ein bisschen mehr Freiheit hat, aber
sozusagen immer noch
nicht so viel selber machen muss, wäre dann
Infrastructure-as-a-Service, also das wäre dann
halt sowas wie
ja, Amazon
EC2,
Digital Ocean.
Also da
bekommt man im Grunde
ja, einen Container,
auf dem irgendein Linux oder so läuft, wo man
sich einloggen kann als Root per SSH.
und dann ist man auf sich alleine
gestellt. Den Rest macht man dann halt selber.
Das hört sich gar
nicht so schlecht an. Ja, das hört sich gar nicht so schlecht an.
Das ist auch, glaube ich, eine ganz
nette Geschichte. Welches Linux
nehme ich denn da? Fedora, Ubuntu,
Debian? Spielt im Grunde
keine große Rolle, würde ich jetzt mal so
sagen.
Vielleicht gibt es kein System,
das besonders gut Python unterstützt oder so?
Nee, das System Python kann man
in keinem von den Fällen verwenden.
Ist egal, muss man eh immer neu installieren.
oder selber installieren.
Hat Fedora jetzt nicht drei
standardmäßig alles schon drin? Ja, trotzdem
nee. Wie war das? Barry
Warsaw hat das mal auch auf Twitter geschrieben,
so, first rule of Python is you don't use
system, don't use system Python.
Du musst ja immer dein eigenes Python installieren,
das ist kein Spaß.
Ja,
also genau, also insofern
würde ich sagen, also der einzige Unterschied, den ich
noch sehen würde, der relevant ist, ist einmal
welches Paketmanagement-System einem
irgendwie besser oder schlechter gefällt
und ob man SystemD mag
oder nicht, weil
genau, wenn man das mag, dann kann man das ja benutzen
und da gibt es halt Unterschiede, je nachdem, welche
Distribution man verwendet.
SystemD nutzt dann sowas wie LoggingUp oder sowas, das mag man
vielleicht nicht, oder? Ja, aber auch vor allen Dingen
sowas wie, wie sorgt man eigentlich dafür, dass
der Kram, den man laufen haben möchte,
eigentlich läuft und am Laufen bleibt und so.
Das
kann man über SystemD auch machen.
Man kann auch irgendwas anderes nehmen.
Ich nehme öfter
Super-Vice-D,
aber es ist auch, im Grunde ist es
vorher Init-was?
F-Init-System-5?
Ich weiß nicht genau,
Init-Files, es gibt da auch
andere Konzepte, wie man, ja, also
System-D hat schon nette Konzepte,
aber es ist halt auch, es hat dann so manchmal so
Vielleicht hat da irgendwie eine ganz
spannende Folge dazu noch mal
gehört, irgendwann
die fahren irgendeinem Chaos-Radio-Express mit einem
von den Developern da, das war schon ein bisschen
ja, äh, na, wie heißt
er noch, äh
namensgerecht, keine Ahnung, ja, genau
äh, ja
okay, also völlig egal, welches System
also ich baue mir dann Fedora und Ubuntu drauf, zum Beispiel
weil ich das so ein bisschen schon kenne oder so
dann irgendwie, dann mit den Repos
schon ein bisschen weiß, wo ich meine Pakete finde und dann
ist der To oder warum sollte ich
das tun, warum nicht direkt einen eigenen Server
also, ja genau, weil halt auch da dir das
natürlich abgenommen wird, dass du dafür sorgen musst
äh, dass das Ding ordentlich läuft
oder so, ähm
Ja, du musst dich um viele Dinge nicht kümmern,
die du sonst tun müsstest.
Die da wären?
Ja, alles, was mit Netzwerk zu tun hat.
Stecker reinstecken, Strom.
Genau, dass das Ding immer oben bleibt.
Betriebssystem-Updates, weiß ich gar nicht,
das muss man wahrscheinlich selber machen.
Ja, das finde ich genau.
Managed-Server, glaube ich, heißt das oder so was.
Ja, das will man alles, wahrscheinlich eher nicht.
Aber genau.
Ja, aber man muss sich,
also schon um wesentliche Teile der Infrastruktur
jetzt bei so einer Geschichte nicht kümmern.
Also im Grunde ist halt der Container wie
der andere und das funktioniert einfach so.
Also das ist schon
auch nett, aber man zahlt natürlich auch
einen Preis, das ist halt schon teurer, als wenn man
jetzt, und es gibt noch mal so super
billige
Geschichten, auch
immer, also ich glaube die kleinsten
Container, wenn die durchlaufen sollen, die kosten
dann irgendwie
ein paar Zehn Euro im Monat oder so was,
ich weiß es nicht genau, aber
es gibt auch so Dinge wie bei Amazon Light Sale
heißt das glaube ich irgendwie, wo man dann für
wenige Euro im Monat so ein Ding
Container kriegt und bei
DigitalOcean gibt es das auch
und selbst bei sowas wie
Hustler wie Hetzner oder so kriegt man
irgendwie einen Container, der
durchläuft für
2,50 Euro oder 3 Euro oder so
wenig Geld im Monat und hat dann
ein richtiges Linux mit, wo man sich
als Root einloggen kann, ist schon natürlich ganz nett.
Und das will man wahrscheinlich sogar auch tun.
Ja, hängt dann davon ab, was man dann
Wenn man jetzt eine fette Datenbank braucht, dann geht das halt wahrscheinlich
nicht mehr, dann braucht man halt Hauptspeicher
und den hat man da nicht. Aber
ja, so eine Testinstallation...
Wann braucht man denn eine fette Datenbank?
Also so jetzt als Datenmensch
wirst du ja wissen, ab wie viel Traffic man da so irgendwie...
Nee, das hat mit dem Traffic gar nicht so viel zu tun, sondern
eher damit zu tun, wie viele Daten es sind.
Weil du willst, dass dein
Working Set im Hauptspeicher ist.
Und das heißt, wenn du halt irgendwie ein paar Gigabyte
Daten hast, dann willst du halt
ein paar Gigabyte Hauptspeicher haben, mindestens mal.
Wäre so viel zu viel oder so.
Also ungefähr doppelt so groß wie mein Dataset sollte
der Hauptspeicher dann sein. Ja, also
später geht das dann irgendwann nicht mehr, aber
ja, sollte schon
da reinpassen.
Und das,
die haben alle wenig Hauptspeicher natürlich, weil
die teilen sich, die sind halt auf großen Maschinen
meistens, aber es sind viele kleine Container und
dann muss es halt irgendwie, wenn die alle vier Hauptspeicher
verbrauchen, ist halt natürlich irgendwie der Hauptspeicher weg.
Wie kompliziert
wäre es denn jetzt da, weiß nicht, wenn man jetzt
mehrere kleine Services auf so einem Ding
laufen lässt, einen von denen umzuziehen?
auf eine größere Maschine.
Oh, das ist, ja, da bist du
dann schon, das ist alles nicht mehr so einfach.
Ich würde auch das nicht so machen, dass ich
die Sachen da direkt laufen lasse.
Kann man auch tun, aber
ich würde eher sowas wie Docker nehmen.
Tatsächlich.
Also das heißt, du würdest dann auf einen dieser
Cloud-Dinger einen Docker
bauen, installieren oder
Docker installieren, Docker-Demon starten
und dann halt
mit so einem Docker-Compose-File das
komplette System hochziehen.
sodass dann halt für jeden Service, den man
benutzen möchte im System,
das man da hochfährt, dass man
dafür einen Container hat, also einen Container für die Datenbank,
man hat einen Container für Redis.
Und man teilt sich dann genau die Dinge auf, also kann man
Docker so einstellen, dass er für alle verschiedenen
Systeme unterschiedliche Hardware nimmt?
Ja, das kannst du natürlich auch tun,
aber das würde ich
am Anfang auch nicht machen.
Und dann geht es eher so in den Bereich
von Kubernetes und diesen
Geschichten, das willst du nicht.
Also das ist auch gar kein
Problem, also
das musst du nicht machen.
Also Kubernetes ist eine Krake an Docker-Containern.
Ja, das ist so
ein bisschen, das Problem mit Docker ist halt,
dass das zu betreiben ist
halt fies, Netzwerk ist fies,
das ist alles, das entwickelt sich
auch alles noch, das ist alles nicht so richtig
gefestigt,
das ist nicht ganz so schlimm wie
jetzt bei den JavaScript-Frontends
bei React oder so,
aber es ist schon,
es ist nicht so, also man kann
sich da nicht so gut drauf verlassen und vor allen Dingen fehlt die Unterstützung
für viele Sachen und dann gibt es da eben
dann, wenn man
das im Großen, wenn man eine komplette Cloud irgendwo
betreiben möchte oder so, dann macht man da
andere Geschichten, Management-Geschichten für.
Da wäre jetzt Kubernetes ein Beispiel für. Aber
die Frage ist, ob man das braucht. Und wenn du das
selber irgendwie nur ein System, das brauchst du
nicht. Also würde ich jetzt mal einfach,
würde ich jetzt einfach mal so sagen, brauchst du nicht.
Ja, also ich habe eine bestimmte Voraussetzung tatsächlich,
also ich möchte so verschiedene Webseiten
betreiben irgendwie, ne, irgendwie private Sachen.
Dann hatten wir mal über Indie-Web besprochen,
dann irgendwie so die beiden Services da drauf
und dann vielleicht noch irgendwie eine Firmen-Webseite
mit einem kleinen Login und vielleicht noch für
IoT so ein bisschen, so ein Server,
der da irgendwie läuft und das irgendwie alles gerne parallel
und ja. Das ist ja kein Problem.
Wie baue ich das denn?
Also wo fange ich denn da an? Also ich habe jetzt so einen Server
dann Cloud am besten gemietet oder
vielleicht doch irgendwie so einen dedizierten irgendwo
hingestellt oder nur einen kleinen virtuellen
genommen. Das hängt halt wieder davon ab. Also ich würde
einfach mal, also nur um das
halt auszuprobieren, würde ich mit so einer kleinen
Geschichte anfangen.
Ja, aber das ist meine Frage nach dem Umzug. Also wenn ich dann merke,
oh, umziehen, muss ich alles normal machen?
Nee, musst du nicht.
Dafür hast du ja deine Domain registriert.
Ja, aber den Server muss ich ja umziehen.
Also die ganzen Sachen muss ich ja nochmal konfigurieren.
Ja, aber dann nee. Dann musst du gar nichts machen.
Wenn du Docker nimmst, hast du dieses
Problem gelöst.
Achso, ich baue den Container einfach neu auf
einem anderen System. Ja, genau.
Du sagst einfach auf dem anderen System
docker-compose dein docker-yaml-File
ab, fertig.
Nicht mal das. Also gut, man würde
das jetzt nicht von Hand ausführen, sondern man würde
dann halt irgendwie das in SystemD anhängen oder
in SuperViceD.
Normalerweise die Konfiguration dafür legst du
auch in dein Projektverzeichnis mit rein.
Linkst das nur noch
nach etc.superviceD.conf
oder weiß ich wo die Config-Files
dafür liegen. Startest das Ding einmal
neu und dann startet er deinen kompletten Kram,
ohne dass du noch irgendwas machst. Also wie gesagt, wenn ich
auf einem Server das deploye, da
muss ich einen Link ziehen.
Ich muss etwas
an der Caddy-Config
ändern, das machst du, dann schreib ich neu.
Caddy, es ist dieses Config,
also ich muss da irgendwas rein, ist die Reihenfolge entscheidend,
wie das da drin hängt, weil die dann nacheinander gelaufen,
wie verteilt er die Ressourcen,
also wie viele er hat.
Ja, also gut, das ist nochmal ein anderes Thema.
Caddy ist ein Loadbalancer, was?
Wir sind zu weit, wir müssen nochmal zurück.
Ja, okay. Ja, also es ging nur darum,
wie kriegst du das Zeugs irgendwie
auf einer Maschine zum Laufen
und da würde ich
empfehlen, heutzutage Docker zu nehmen. Man kann auch
andere Sachen benutzen, aber...
Vagrant. Ja, man könnte auch Vagrant
benutzen, aber das braucht auch mehr Ressourcen.
Also das würde ich jetzt zum Beispiel, wenn du
irgendwie so in dem Container, vor allen Dingen
Container ist ja, also es ist natürlich auch irgendwie
performancetechnisch sehr fies, also in dem Container
nochmal Container-Geschichte zu starten, ist vielleicht
auch nicht so die schlauste Idee
performancetechnisch, aber es ist halt zum Entwickeln.
Es ist halt so, würde ich
sagen, state of the art eigentlich.
Oder es ist halt am wenigsten
schmerzhaft von allem, was es so
momentan gibt. Vagrant kann man
lokal ganz gut verwenden oder halt, wenn man einen dicken
Server hat, aber du kannst
es nicht gut verwenden in einem kleinen Container.
Weil das
braucht halt, das fährt halt wirklich ein komplettes
Linux hoch pro.
Und du kannst natürlich da drin alles wieder
betreiben, du musst dann nicht das in einzelne
Container aufteilen.
Ja, aber das ist,
wenn du wenig Hauptspeicher hast, ist das vielleicht
einfach keine gute Idee.
Na, und Docker passt da eigentlich
ganz gut zu, da hast du dann zwar auch
Container in Container, aber es ist
nicht so, du fährst nicht jedes Mal ein komplettes
Betriebssystem hoch und so, eine komplette Maschine.
Ja,
du kannst natürlich das auch irgendwie
komplett einfach in diesem Container
alle deine Services, die du so haben willst,
starten, ja, du kannst halt zum Beispiel
kann man da irgendwie so, auch das benutzt man
eher für größere Infrastrukturen,
um da halt ein komplettes
System auszurollen, ja, das ist eigentlich so
Automatisierung
deiner
Automatisierung deiner
Infrastruktur hochziehend,
so was wie Ansible oder so,
es gibt auch noch diverse andere, es gibt Holstack, es gibt
irgendwie Puppet Chef,
aber Ansible wäre jetzt auch Python
und damit
verwaltest du
quasi ein ganzes Inventory an Rechnern
irgendwie und sagst dann,
roll mein System aus und dann, das Ding braucht auch nur
SSH, dann connectet es sich auf all die Systeme
per SSH und
macht dann magische Dinge, sodass dann da
wie die Services laufen, die da laufen sollen
und so. Irgendwie sowas braucht man auch,
wenn man einen Vagrant verwenden wollte, weil du musst ja die Services
dann irgendwie in deinem Vagrant, in deiner
virtuellen Maschine halt auch zum Laufen kriegen. Das heißt, du musst
da irgendwie die entsprechenden Pakete installieren,
musst du die Services hochfahren, du musst die Config-Files
irgendwie mit Templates so
irgendwie, also
du hast Templates für deine Config-Files, dann musst du die so mit den
echten IP-Adressen und so ersetzen, dass dann die
richtigen Config-Files da sind, dann muss das Ganze hochgefahren
werden und so weiter und so weiter.
Und für so ein komplettes System
irgendwie Ansible
Rollen, nennt man das, zu schreiben. Das geht
alles, habe ich auch schon gemacht und so.
Aber das ist eine Menge Arbeit.
Also das ist nicht so ohne. Und das dann
auszurollen dauert auch ziemlich lange.
Das ist halt auch
so ein Nachteil gegenüber Docker. Also das ist halt
irgendwie so ein komplettes
Ding mit Vagrant hochzuziehen. Kann sein,
dass das selbst, wenn du einen schnellen Rechner hast, lokal,
kann sein, dass das 20 Minuten dauert, wenn du so viele
Maschinen hochfährst oder so. Kannst natürlich
auch alles in einer Maschine haben, aber dann hast du wieder das Problem, du kannst
es nicht mehr aufteilen.
Wenn du es jetzt auf andere Maschinen aufteilen wolltest,
Und das ist halt einfach oft zu langsam.
Wenn du zum Beispiel irgendwas,
du versuchst, irgendeine Funktion hinzukriegen,
musst dafür irgendeine Bibliothek installieren,
die das halt kann,
ein Python-Wrapper drumherum,
der da irgendwas mitmacht.
Und du willst halt so schnell iterieren können.
Du willst halt schnell irgendwas ausprobieren.
Ah, geht nicht, nochmal.
Und bei Docker dauert so ein Build für,
weiß ich jetzt nicht,
je nachdem wie viel CPU-Power
und Platten und Netz man hat.
Aber so bei mir dauert das, ich habe so ein Standard-Django-Projekt, hat bei mir irgendwie die Datenbank, Redis, irgendwie Applikationszauber-Django, vielleicht noch Celery oder so, also fünf, sechs Container, irgendwie sowas, die alle neu zu bauen, wenn man jetzt zum Beispiel eine Abhängigkeit im Betriebssystem, also sagen wir mal, wenn man jetzt irgendwie auf Betriebssystem-Level irgendeine Bibliothek braucht oder so, die vorher nicht da war, dann muss man die Container neu bauen.
Und das dauert bei mir so
zwei bis drei Minuten
lokal.
Ja, je nach Größe der Anwendung natürlich.
Ja, je nach Größe der Anwendung, aber das ist
die Anwendung
selber, die Genre-Anwendung hat damit gar nichts mehr zu tun.
Der Hauptteil, der da dauert, ist halt
tatsächlich
die Installation
und das Bauen der Container.
Und dann halt hinterher müssen nochmal die ganzen
PIP-Abhängigkeiten per PIP
installiert werden. Das dauert auch.
Ja, aber das ist halt
viel, viel schneller, als wenn man
das jetzt bei Ansible und Vagrant machen
wollte. Und
das Problem ist halt, drei Minuten ist auch schon lang,
aber das macht
einem so gerade vielleicht den Flow noch
nicht kaputt. Aber wenn man jetzt irgendwie da
dann jedes Mal 20 Minuten warten muss, dann
geht man Kaffee trinken und macht irgendwas anderes.
Und man muss aber möglicherweise
zehnmal was anderes ausprobieren,
weil oft bleibt einem nichts übrig, als
Sachen auszuprobieren, ob es jetzt so geht.
Der Python-Rapper funktioniert nicht, muss einen anderen nehmen,
mit dir nochmal aus.
Wenn du da zehnmal irgendwas ausprobieren möchtest
und du hast immer eine
20 Minuten Latenz dazwischen ist,
das macht einen langsam.
Du hast gerade gesagt, von dir gehört
noch eine Redis, das ist ein Cache,
da man die Sachen von der Datenbank direkt verfügbar hat.
Ja, einfach nur
zum Cachen von beliebigen Dingen.
Nicht nur Datenbank, also es gibt ja auch vielleicht
andere Sachen, die länger laufen oder wo man halt
Statische Files oder sowas.
Nee, nee, nee, das machen wir nicht.
Nein, nein, okay.
Ne, also es gibt noch, wenn du jetzt
statische Files cachen möchtest, das würde man
auf der anderen Seite machen. Also Redis ist etwas,
die Applikation, also
wenn ich jetzt zum Beispiel in Django
eine Funktion habe, die irgendwas lange
berechnet
oder so, dann ist fertig ist, dann
schreibe ich darüber irgendwie
CacheProperty oder so zum Beispiel in Django
um Django zu sagen, cache das hier
mal bitte, weil ich will das nicht
jedes Mal, wenn dieses
Property
jemand, wenn jemand darauf zugreift,
möchte ich nicht, dass es jedes Mal neu berechnet wird.
Es soll nur einmal berechnet werden.
und dann im Cache landen. Und dann verwende ich diesen
Dekorator und dann landet
das im Redis. Also wenn ich jetzt Redis
konfiguriert habe, als das ist der Cache
für meine Django-Applikation.
Für sowas ist es gut. Man kann Redis auch noch
für diverse andere Geschichten verwenden.
Und
wenn ich jetzt sozusagen
die statischen Files cachen wollte
in Memory, das kann auch durchaus Sinn machen, aber das
würde ich an einer anderen Stelle machen. Und zwar
vorne dran, vor dem Django.
Vor dem Applikationsfang.
Da würde ich
einen Varnish nehmen oder so.
Das ist so ein In-Memory-Cache,
den man
davor hängt und
der würde halt
sozusagen alles, was so an statischen Files geht
oder so, die da durchgehen, halt
In-Memory-Cachen.
Oder überhaupt alles, was an statischen Assets drin ist
oder auch andere Sachen.
Überhaupt alle
Dinge, die identifizierbar
sind als cachebar über die Cache-Header.
Und das wäre dann
viel, viel schneller. Also das macht man
dann an der Stelle.
Ist jetzt aber in meinen Projekten meistens gar nicht mit drin,
weil
brauche ich eigentlich meistens nicht, weil ich
habe nicht so viel Traffic. Wenn ich jetzt irgendwo viel Traffic
hätte, ja, dann macht das
wahrscheinlich durchaus Sinn, sowas zu verwenden.
Aber
ansonsten werden die statischen Assets
halt ausgeliefert entweder von
in meinem Fall meistens
vom Caddy.
Das ist der, ja,
ich mache diesen Stack nochmal komplett durch.
Also das, was davor ist, und das ist auch etwas, was
leider nicht in dem
Docker-Geschichten selber
mit, also sagen wir mal so, wenn man jetzt Cookie-Cutter
verwendet, um ein Django-Projekt
zu erzeugen, dann ist der Caddy schon
mit drin, aber
man kann das oft nicht verwenden,
wenn man das jetzt auf irgendeine Maschine da draußen
deployt oder in einen Container,
auf den man sich per Route einloggt,
weil, wenn man da jetzt zum Beispiel mehrere Domains
hat,
die man
da ausliefern will,
dann muss der Caddy
halt unabhängig von den
einzelnen Systemen sein, sonst geht das halt nicht.
Und was macht der Caddy denn jetzt?
Im Celery hattest du noch eventuell, musst du auch noch mal kurz.
Ja, also Caddy ist
ein grob geschriebener
Web-Server,
der
besonders schön integriert ist mit halt
Let's Encrypt, sodass halt HTTPS,
also SLL, TLS kann
halt ohne, dass man da irgendwie viel konfigurieren muss,
ohne dass man irgendwie Startboard selber
irgendwie verändern muss.
es ist so,
ja, HTTPS
funktioniert einfach magisch und man muss sich nicht mehr
kümmern. Das ist halt so der Effekt.
Was ja ganz nett ist.
Und
der ist auch sonst relativ
schnell. Der ist nicht ganz so schnell wie Nginx oder so.
Aber ich meine, ob das Ding jetzt,
weiß ich nicht, 10.000 Requests pro Sekunde kann oder
nur 5.000, macht für die allermeisten Leute überhaupt keinen
Unterschied, weil sie haben nicht mal
ein Request pro Sekunde da. Ja, ist egal.
3, 3, 4, ja.
Ja, aber selbst bei 100 ist es völlig wurscht.
Und, ähm, ja,
und dass sein Google geschrieben ist, macht vielleicht das Ganze auch noch
ein bisschen vertrauenswürdiger, als wenn ich meine Nginx
C und so, hm,
wer weiß.
Aber, naja, eigentlich ist es wurscht.
Also was für mich den Ausschlag gibt, den zu verwenden, ist halt
die schöne Let's Encrypt-Integration.
Und, ähm,
ja, der ist sozusagen vor den,
vor Django davor, halt eben um
sowas wie Statisch Falls auszuliefern, weil das kann halt
Django nicht so gut selber. Wobei, muss man
auch einschränken, sagen, äh,
Mit White Noise ist das vielleicht nicht mehr so ganz aktuell, aber...
Was ist White Noise?
Oh Gott.
Das ist ein, ja, ich weiß nicht, innerhalb von Django kann man das als Party-App installieren
und das liefert dann Files, also wenn man normalerweise einfach so ein File ausliefern würde in Django,
dann zieht man das halt in den Hauptspeicher, also von der Platte in den Hauptspeicher
und dann von dem Hauptspeicher schickt man es
wieder durch
den Kernel-Space
irgendwie wieder raus über die Netzwerkkarte
und da wird
viele Daten werden da kopiert und
das ist alles scheußlich und man blockiert
einen
Worker-Prozess. Hängt auch wieder davon ab,
welchen Applikations-Server verwendet
Unicorn,
Micro-Whisky oder My-Whisky oder
WSGI oder so, also das ist alles
der gleiche, weil es nur nicht wieder ausgesprochen wird.
Man muss ja
irgendeinen Applikations-Server
verwenden, der sozusagen dieses
WSGI-Protokoll spricht
mit der Applikation.
Und
naja,
also wenn man
das File tatsächlich einfach so selbst ausliefert,
dann ist das extrem langsam
und dann ist halt bei wenigen Files
schon direkt Schluss.
Und das ist natürlich etwas, was man
nicht haben will.
Und wenn der Caddy
oder auch ein Nginx
kann halt problemlos viele
Files irgendwie ausliefern
und macht das halt nicht
so, dass er erst die Files in den Hauptspeicher kopiert,
dann durch den User, also vom
Kernel zu den User-Files und dann wieder zurück schiebt,
um das auszuliefern, sondern der
verwendet halt einen Kernel
und ein syscall
send-File, um die Files halt raus zu
sagt halt diesem Kernel
nur irgendwie hier, dieses File,
diese Verbindung bitte sehr, liefere aus.
Sodass das halt
ja, viel, viel schneller ist.
Also der Kernel liefert im Grunde mehr oder weniger die Files aus
und kann da
irgendwelche Tricks machen. Teilweise werden die
Sachen nicht mehr durch den Hauptspeicher, sondern
gehen direkt per Serial Copy TCP
irgendwie in den Netzwerkwaffer der
Karte oder so von den Platten aus und so.
Also da gibt es crazy
Shit-Optimierungskrams,
der da gemacht wird. Bin ich jetzt auch nicht mehr so auf der
Höhe der Zeit, was da momentan aktuell ist, aber es geht
irgendwie eine Menge.
Und White Noise verwendet
auch Sendfile. Insofern ist das da nicht mehr so
schlimm.
Aber eigentlich
will man jetzt auch nicht große Mengen darüber ausliefern,
weil der Request ja dann immer noch aufschlägt
im Django.
Oder jeder, der Request nach einem
File, und das kann halt viel sein. Also wenn man viele kleine
Bilder hat auf einer Webseite zum Beispiel,
wenn man eine Liste von irgendwelchen
Dingen, wo halt immer Bilder dabei sind, dann
ist halt jedes Bild, macht halt ein Request.
Und
in moderner Browser machen die ganzen Requests ja auch ein Parallel.
Das heißt, die prügeln halt dann auf
deine Applikations-Server ein und das ist halt
Und das finde ich nicht so gut.
Und da, ich mache es nicht so, aber was wohl gut ist,
ist halt, man verwendet White Noise und dann da vorne irgendwie Varnish oder sowas
oder halt ein CDN, sodass halt beim ersten Mal werden die Sachen dann tatsächlich von White Noise ausgeliefert
und danach sind sie halt gecached irgendwo im Content Delivery Network oder halt Varnish oder so.
Und dann ist es schnell.
Was ich mache,
ich verwende
meistens den Webserver
in Caddy oder Nginx vorne dran zum
Aussehen meiner statischen Assets.
Da gibt es halt einen Unterschied in Django.
Statische Geschichten, das ist sowas wie JavaScript,
CSS,
Fav-Icon,
dieser ganze Kram halt sozusagen, der
ja,
zum Projekt halt dazugehört, aber jetzt sich
im Grunde nicht ändert.
Das Firmenlogo, was du immer schon eingebaut hast.
Genau, also wenn man, die Sachen werden
dann auch generiert, diese High-Namen
und dann sobald man
da was
dran ändert und dann noch Collect Static aufruft,
um das halt alles in ein Verzeichnis zu kopieren, das dann halt
von einem Webserver ausgeliefert werden kann, dann kriegen die
halt unike Namen, sodass das halt
man auch sagen kann, die werden für immer gecached, weil
wenn es was Neues gibt, dann wird der eh einen anderen Namen verwenden.
Ja,
das ist halt, dieses
Headlink der Static-Files ist halt ein bisschen anders, als
wenn jetzt User Bilder hochladen oder so.
Dann ist das Media-Root in Django
und es wird halt so ein bisschen anders
gehandelt und statische Files
werden ausgeliefert vom
Caddy und
alles, was User
an Content hochladen, landet
in einem CDN, also landet in
S3, in einem Bucket
und der wiederum wird dann
ausgeliefert über, ich glaube, das ist
CloudFront, das ist
auch das CDN von
Amazon, sodass
ich halt auch damit keinen Stress mehr habe,
sondern das
ja, dann
das ist dann halt auch schnell.
Ist halt ein bisschen,
ja, muss man vielleicht gar nicht machen,
weiß ich jetzt gar nicht so genau.
Aber das ist halt auch eine Lösung.
Das ist natürlich auch eine, ja genau, das ist dann auch
quasi beliebig.
Ja, Traffic
wird halt irgendwann teuer.
Ja, da muss man sich...
Ja, aber man muss halt dann pro,
ja, weiß ich nicht,
weiß ich gar nicht, pro Gigabyte
oder weiß ich nicht, irgendwann bezahlt man halt pro
irgendwas. Man hat irgendwie 100 Gigabyte
frei oder so, dann fängt man irgendwann an zu bezahlen.
Zwei Euro pro Request.
Ist nicht ganz so schlimm, aber es ist
ja, und wenn man das selber macht
mit White Noise und so, kann man
wirklicherweise sich da auch den Traffic sparen, was
auch schnell ist.
Wenn man CDN vorne ran findet, auch nicht.
Wie auch immer, also genau.
Jetzt haben wir auf jeden Fall den Dango
Applikations-Server, da hast du gesagt, Junicorn, irgendwas laufen.
Junicorn, ja, also ich würde sagen, wenn man
eben nicht mehrere Seiten
hostet, dann
sondern, dass er so ein eigenes Projekt
hat, was irgendwie und der
Applikationsserver nur das für eine
Geschichte macht, für eine Domain oder so,
dann ist GeoNikon, denke ich, die bessere Wahl.
Ansonsten, wenn es
komplizierter ist, dann, gut, muss man
vielleicht dieses
WSGI-Ding nehmen,
das hat
einen Haufen
Einstellungen, die ja darauf optimiert sind, dass man,
wenn man HOSA ist selber,
kann man halt auch eine Menge andere Dinge
noch einstellen, ist aber komplizierter,
Daher würde ich das jetzt nicht direkt empfehlen.
Auch wenn man Cookie-Cutter nimmt, ist Unicorn dabei.
Ich würde sowieso empfehlen, das Cookie-Cutter-Django-Template
zu verwenden, weil das macht eigentlich an der Stelle
schon viel richtig.
Ja, da
muss man sich selber
um diese... Also Cookie-Cutter ist was, das deine
Projekte automatisch vorkonfiguriert,
deployed oder voranstellt.
Nee, das erzeugt das Projekt.
Es ist ein Projekt-Template
und es fragt einen, wenn man
es ausführt, am Anfang
so ein paar Sachen und da antwortet man
halt so zum Beispiel, wie das Projekt heißt oder
keine Ahnung, ob man jetzt Celery verwenden möchte oder nicht
oder so oder welche Datenbank. Celery hast du
jetzt auch noch nicht. Genau, das ist auch
Arbeiten, Bienen oder
Celery, genau, man hat oft
die Geschichte, dass man
nicht, dass man langlaufende
Jobs hat, die
ausgelöst werden von einem
Web-Request und man möchte jetzt den User am Ende
aber nicht warten lassen. Also sowas
wie, keine Ahnung,
ja,
User lädt ein Video hoch und man muss das jetzt in alle
Formate rendern,
die halt so gebraucht werden für unterschiedliche,
fürs iPhone, für Android.
Ja, da nimmt man dann
halt auch irgendwie anderen Codec oder so
und in unterschiedliche Auflösungen,
je nachdem, wo man das irgendwie anzeigen will.
Da möchte man nicht, und diese Renderjobs
dauern halt, je nachdem, wie lang das Video ist, sehr, sehr
lang. Jetzt lädt hier jemand ein Video,
das eine Stunde lang ist, hoch. Dann möchte
er nicht, dass der Request, wenn das im Request
selber lauft, dass es nochmal zwei Stunden dauert,
das wäre irgendwie komisch, sondern
dann nimmt man das Video her, sagt, okay, man macht
jetzt einen Task, man erzeugt einen Task,
der irgendwie
dann unabhängig vom Web-Server läuft
und der rendert dann halt
irgendwie das Video in die unterschiedlichen
Formate und so
und sagt dem User schon mal,
alles okay, dann
upload es durch. Für solche Sachen
braucht man das. Video ist ein
extremes Beispiel, es gibt sicherlich eine Menge
Beispiele, bei denen das nicht ganz so schlimm wäre,
aber auch schon so nervig, dass man das vielleicht nicht
haben will. Also es hätte doch nicht einfach
so Arbeitsbienen loszuschicken, die dann halt die einzelnen Tasks
abarbeiten. Ja, also die Tasks selber, genau,
da kann man sich auch suchen, welches Backend
man verwenden möchte und Redis ist halt auch ein Backend
sozusagen über das, damit
Redis als Queue verwendet. Also
es gibt, also Celery ist
im Grunde eine Task,
ja, es
besteht aus
einem Ding, was irgendwie die Worker koordiniert,
dann eine Menge von Workern
und halt einer Queue, in die die
Tasks halt reinlaufen, also
wenn man so einen Task erzeugt, dann landet
der halt in so einer Warteschlange
und die Worker greifen sich aus dieser Warteschlange halt
ihre Jobs raus, sozusagen, das sind Prozesse, die
laufen einfach irgendwie. Also wer am lautesten schreit, der wird dann
als erstes bedient oder was? Genau, ja, das erste
ja,
der erste Worker nimmt sich halt irgendwie den ersten Job
aus der Queue und rechnet dann halt,
bis er irgendwie fertig ist, der nächste Worker nimmt sich
den nächsten und so weiter, bis halt keine Worker mehr da sind,
die nichts zu tun haben und dann warten die Sachen
in der Queue halt einfach und die werden dann halt so
mit der Zeit abgearbeitet und
ja, dann hat das Ding auch noch so ein Webfrontend-Flower
heißt das irgendwie mit dabei, da kann man sich angucken,
was ist denn jetzt mal so ein Task geworden, haben die
irgendwelche Exceptions geworfen, gibt's da
Tracebacks, sind die alle gut durchgelaufen, wie lang
laufen die denn so, so Basis-Statistiken,
wie lang laufen die denn durchschnittlich,
ja, und all solche
Sachen, und
also, das, wenn's funktioniert,
ist es eigentlich ganz gut, ja, kann man
nix sagen, ist eigentlich solide Geschichte,
es ist aber so manchmal, also
im Salary ist es manchmal so ein bisschen scharfkantig,
muss man, ich hatte auch schon,
also wenn es nicht funktioniert, ist es nicht so geil,
muss man sagen.
Dann geht das nicht für fast alle Dinge bei der Software.
Ja, aber es gibt manche Sachen, bei denen passiert
einem das nicht, dass die dann nicht funktionieren.
Also zum Beispiel Redis ist dann so ein Stück von Software,
das funktioniert eigentlich fast immer super.
Es gibt selten den Fall,
oder habe ich noch nie erlebt,
habe ich noch nie erlebt, dass Redis irgendwie
etwas gemacht hat
und ich habe es nicht wieder hingekriegt.
Ich habe es noch nicht kaputt gekriegt,
sozusagen, oder auch Postgres ist so ein Ding,
das kriegst du nicht kaputt.
äh, Celery, äh,
hingegen, da installiert
man irgendwie, da wechselt man
irgendwie die Python-Miner-Version
und dann geht gar nichts mehr.
Und, äh, alles
kaputt, ja, also,
und das ist, äh,
ja, oder man wechselt die Django-Version und nichts
geht mehr, ne, also es ist halt, äh,
also es ist halt deutlich fragiler, es ist nicht so, dass
man da, das, also bei Celery
hab ich das schon häufig erlebt, dass es kaputt gegangen ist und zwar
auch dann so kaputt gegangen ist, dass man es im Grunde
nicht mehr fixen kann und das ist immer ärgerlich, wenn man
dann zum Beispiel eben Python nicht upgraden
kann oder halt auch Django nicht upgraden kann,
weil halt ein Celery daran hindert.
Das ist, und das ist schon öfter passiert.
Also, ähm,
ja.
Wenn man's,
man kann's halt oft nicht vermeiden,
dann braucht man's halt und dann,
es gibt noch diverse andere Task-Queue
Geschichten. Celery ist halt
die verbreitetste für Django.
Ähm, ja.
Äh, vielleicht lohnt es sich
auch, die sich die anzugucken.
Ich weiß es nicht genau, aber ja, also wenn man es nicht braucht, dann war es nicht unbedingt, also es ist nicht unbedingt eine Geschichte, die man aufgrund von reiner Freude, weil es so viel Spaß macht, das zu benutzen, verwenden sollte, weil das macht einfach nicht so wahnsinnig viel Freude.
Und wenn man die Abhängigkeit nicht braucht, sollte man sie weglassen.
Ja, aber oft braucht man sowas tatsächlich.
Ja, was haben wir noch?
Ja, ich würde jetzt nochmal so ein bisschen auf die ganz basic Sachen zurückkommen.
wie weiß ich denn jetzt, auf welche
Route ich jetzt meinen Nameserver zum Beispiel
schicke, auf welches Verzeichnis ich
den verweise oder
ich habe jetzt verschiedene Django-Apps
laufen oder du hast ja gesagt,
Junicorn ist nur eine, dann habe ich sonst ein Whiskey
und Whiskey weiß dann, wo was liegt.
Junicorn ist eine Applikations-Server, jetzt sagen wir mal,
wenn du jetzt Cookie-Cutter verwendet hast und so,
dann läuft
dein System, läuft halt
irgendwo intern in einen
Worker-Container und
sozusagen kann angesprochen werden,
aus dem Container heraus,
oder aus der Maschine heraus, auf der du dich angelockt hast,
auf irgendeinem Port 5000 oder sowas,
da läuft das Ding halt. Nimmt aber nur Requests an
von innen. Also sollte nicht von außen
erreichbar sein. Das heißt also, ich muss aber dann
den Port kämpfe ich natürlich an und dann, die Ports muss ich
irgendwie auf meiner Maschine routen dann?
Nee. Zu den Docker-Containern? Nee.
Nein? Wie? Wo funktioniert das denn? Die sind nur lokal.
Da.
Kannst du lokal drauf connecten, sonst nicht.
Und
wie dann die Requests sozusagen aus dem Web
da reinkommen ist, du hast halt den Caddy vorne
dran, da gehen die Sachen per
Report 443 kommen die rein.
Und den Caddy muss ich konfigurieren?
Den musst du konfigurieren, da brauchst du einen Config für,
die ist aber relativ einfach und da steht
mehr oder weniger nur drin,
irgendwie, wenn es an die Domain gehen soll,
dann alles an den Applikationsserver.
Okay, aber das heißt, der Caddy
ist derjenige, der ist alles verwaltet. Das heißt, in der Caddy-Konfiguration
stelle ich das ein, Name-Server, HTML-Routing.
Nein, nein, nein.
Nein, HTML-Routing im Dung?
Nein.
Nein, da steht nur drin, auf welche Domain
geht, also
je nachdem, auf welche
Domain der Request geht, auf welchen
Applikationsserver soll das gehen.
Insofern kann man auch sagen, das ist in gewisser Weise
Routing, aber es ist sehr, sehr
einig.
Und HTML-Routing ist das selbe,
aber das ist damit verknüpft, weil halt das
Name-Routing...
Es gibt noch das, es gibt etwas, was sich
URL-Routing nennt bei Django.
Ja, aber das ist aber innerhalb von Django.
Das ist innerhalb von Django. Aber ich kann ja verschiedene Projekte nehmen.
Ich könnte jetzt auch sagen, ich möchte jetzt einfach ein Verzeichnis
serven. Weiß nicht, war www irgendwas,
was da früher gab oder so?
Einfach ein Verzeichnis mit einer Index, irgendwas
noch bereitstellen.
Das kannst du mit dem Caddy auch machen, klar. Kann ich mit dem Caddy auch sagen,
das Verzeichnis kommt auch dann unter dem
Namen, wie so oft,
geroutet rein.
Okay, das ist
spannend. Also das sind halt verschiedene Optionen,
die kann ich alle gleichzeitig mit dem einen Caddy bauen.
Das heißt, das Einzige, um das zu machen, muss ich
meinen Caddy konfigurieren. Was ist mit E-Mail, wenn ich
jetzt irgendwie E-Mail schicken will über den Server? Auch Caddy?
Ne, das ist wirklich nur ein Webserver.
Das würdest du in einer Django-Applikation halt irgendwie machen
und da kannst du es entweder selber tun,
wenn du halt lokal einen Mail-Server laufen hast.
Oh, nein, ich meine, wenn ich jetzt meine Domain-E-Mail,
da gibt es sowas, wie nennt man das, C-Names oder sowas,
wo man dann die E-Mails direkt weggeroutet werden vom Server
auf, weiß nicht, Gmail oder sowas.
G-Name ist eine Art von Rekord
für DNS, wo
dran steht, also dieser Name ist eigentlich
nur ein Alias für den Namen.
Ja, aber die Alias muss ich
ja irgendwie auf meinem Server auch eintragen.
Wie passiert das denn? Also wenn ich
beispielsweise eine G-Suite habe, mit der
ich meine Firmen-E-Mail-Adressen
verwalten möchte, dann
trotzdem die Domain auf
meinen Server ankommt.
Wo muss ich dann einstellen, dass dann die
E-Mail-Adressen zur G-Suite weitergehen? Was ist das,
was da liegt? Im Name-Server.
Also da sagst du halt, der zuständige
MX, das ist wieder ein anderer Rekord, MX-Rekord,
der ist für Mail zuständig,
der Mail-Server für meine
Domain ist Google.
Aber das ist dann am Mail-Server, also an meinem
Provider, an meinem Name?
Nein, da, wo du
deine Domain registrierst. Ja, das mache ich an meinem Registrar, sage ich
dann. Registrar, der hat
eigentlich eine andere Aufgabe, das ist halt, der Name-Server
macht das. Aber der, wo du deine
Domain registriert hast, der betreibt wahrscheinlich den Name-Server,
wo dann deine Domain liegt. Ja, okay.
Ja, genau. Da machst du das.
Und genau, dann geht
halt alle Mail, die an deine Domain
geschickt wird, halt
dem Mail-Client
beziehungsweise Mail-Server, den halt irgendjemand
verwendet hat, macht dann
ein MX-Lookup
auf deine Domain, sieht halt, ah, die Mail soll
zu Google gehen und schickt dann die Mail direkt zu Google.
Und dann landet sie halt bei dir irgendwo
bei Gmail oder wo auch immer.
Und wenn ich jetzt einen File-Tab machen will,
dann muss ich das einfach wieder über den Kettich ruten, ob irgendein
Verzeichnis... Was ist ein File-Server?
Oder was meinst du damit?
Vielleicht einfach ein File, ein Verzeichnis, das ich freigebe,
wo ich dann hoch- und runterladen kann.
Einfach so schreibe
und lese Zugriff. Brauche ich dafür
sowas wie altes USFDP?
Nee, das hängt
halt sehr davon ab, was du da machen möchtest.
Ich würde sagen, ja, sowas gibt es
außerhalb der Windows-Welt eigentlich so nicht.
Also da ist es halt irgendwie Samba
oder ich weiß nicht, wie das Protokoll Microsoft
intern heißt.
Wahrscheinlich
heißt es irgendwie anders. Keine Ahnung. Ich kenne es nur, wie man es
jetzt Linux, wenn man Linux
als Server betreiben will, dann heißt das irgendwie Samba ist
dein Server. Aber das, was du betreibst, ist halt nicht am Internet.
Also, warum?
Viel zu gefährlich.
Das ist, äh,
ne. Und es macht auch so komische Sachen
mit irgendwie Broadcast-Geschichten
und so. Das geht alles im Internet nicht. Also,
äh. Also, zu gefährlich ist das.
Aber es würde gehen. Ne, geht auch nicht.
Ich glaube, es geht gar nicht.
Also, was war denn? FTP-Server, den hätte man
aber einfach. FTP-Server, ja, aber FTP ist
auch irgendwie, also. Out.
Ja, so die, wie würde man sagen,
die 70er haben angerufen und die 80er
haben dann
ihre
Wares zurück.
Also das ist... Das war ja damals ziemlich cool,
da konnte man irgendwie so einen FTP-Server connecten
und hat dann da alles rumgeschoben,
hinterhergeschoben, was man so brauchte.
Ja, da konnte man lustige
Dinge machen, also das ist uralt.
Da gab es ja irgendwann die File-Sharing-Plattform,
Hoster, was gibt es denn heute? Also einfach dann Cloud?
Ja, das macht man einfach
nicht mehr, würde ich sagen.
Es ist einfach komplett weg. Man hat das einfach sowieso
scheiße, da ist alles zur Verfügung.
Also, wenn du
Sachen hoch und runterladen, das ist heute alles HTTP.
Und auch da gab es
dann irgendwie früher so
Geschichten, vielleicht gibt es das auch immer noch,
ich weiß nicht so genau, WebDAV oder so,
wo man das dann auch
mounten kann, dass es dann halt aussieht, als hätte man
das lokal im Dateisystem oder so.
Aber es ist alles
heutzutage ist es eigentlich eher
Also wenn ich jetzt irgendwie nicht sowas machen will
für mich, irgendwie mit meinem kleinen Login oder sowas,
dass ich sage, hey, ich hätte gerne 10 Dateien, die ich immer runterziehe,
die nicht wichtig sind, wo man nicht besonders
viel kaputt machen kann, wenn da irgendwas auseinanderfließt.
Die Frage ist, was möchtest du machen? Was möchtest du eigentlich haben?
Nur einfach so eine Feilablage, so eine Teilablage
für, weiß ich nicht, 5 Fotos oder
irgendwas. Ich meine,
Fotos, weiß ich, gibt es ja auch andere Möglichkeiten, aber
nur so. Du willst
irgendwie verzeichnete Synchronen halten.
Ja, so ein kleines Dropbox. Ja, oder so ein kleines
Store für irgendwas, so mein virtueller USB-Stick.
Da gibt's, also würde ich
eher sagen, also da gibt's, als fertig
würde mir jetzt eigentlich nur einfallen, sowas wie
OnCloud oder UnCloud.
Aber intern,
was die wahrscheinlich alle machen, das machen wahrscheinlich solche
selbst wie, oder wenn man
jetzt Apple verwendet, würde ich sagen, dann nimmt man halt einfach iCloud.
Also UnCloud oder iDrive.
Wenn du selber hosten willst,
OnCloud wahrscheinlich, aber intern wird das auch
nichts anderes machen.
Ja, das wird nichts anderes machen, das machen auch Dropbox und die ganzen anderen wahrscheinlich, die sprechen alle HTTP oder HTTPS mit zu Hause sozusagen und dann haben sie irgendwie Client-Software, die halt auf deinem Rechner läuft, die halt sich per iNotify oder sonst irgendwie oder wie auch immer sich benachrichtigen lässt, wenn halt irgendwie sich was an ein Verzeichnis erinnert und dann synkt die das halt rüber und umgekehrt halt genauso.
deswegen brauchst du auch einen Client, weil
das ja dann sozusagen eine stehende
Verbindung irgendwie braucht und du halt
auch vom Server aus den Client
benachrichtigen können willst und
ja, ich weiß nicht, ob es
irgendeine gute, freie,
selbstgehostete Geschichte dafür gibt, aber
warum nicht irgendwie Dropbox oder sonst
irgendwie? Ja, ne, also ich meinte einfach nur jetzt so der private
USB-Stick, ne, wo man kurz was hinterschieben
kann, so von
Gerät zu Gerät
oder sowas, wo man einfach dann eine URL eingibt und dann
kurz seinen Login und dann hat man das
das wäre irgendwie schon nett
ja, ich weiß es nicht
ich glaube, also ich meine, was geräteübergreifend
funktioniert, ist wahrscheinlich dann Google
der Boot muss ja dann auch irgendwie auf die Telefone kommen
wäre ja dann praktisch
ja, und dann bist du eh
entweder bei Apple oder bei Google
da kommst du ja selber gar nicht mehr drauf
ja, dann fangen wir doch an
mit dem nächsten Thema an
ja, es ist ein bisschen
traurig alles, aber leider
ja, also
SSL-Zertifikate, hast du gesagt,
sind alles im Caddy mit drin. Das heißt, da funktioniert
das HTTPS mit, unterstützt
also, kannst du nochmal vielleicht einen Unterschied kurz, SSL,
HTTPS, ist das dasselbe?
Naja, SSL ist
eigentlich, glaube ich, veraltet. Das gibt es
eigentlich gar nicht mehr. Es ist immer nur so, dass man halt
davon redet, weil man das irgendwie gewohnt ist. Also mittlerweile
ist, was man eigentlich verwendet, TLS.
Und
naja, so genau weiß ich das
jetzt auch alles nicht.
Das zu konfigurieren ist ein Schmerz. Also ich
weiß, dass ich das, ich habe das mal ein paar Mal gemacht
für NGINX und das hat
das war auch, das hat länger gedauert, als ich
dachte. Es gibt da so ein
Test von
SSL Labs, wo man dann überprüfen kann, ob die
eigene Seite irgendwie den aktuellen
Sicherheitsanforderungen irgendwie genügt. Muss man da irgendwie ein Zertifikat
sich irgendwo generieren? Kann man das selber
erzeugen? Muss man das kaufen? Da gibt es ja irgendwie
so kostenlose Angebote.
Warum nimmt man die? Warum nimmt man freies?
Geht das auch frei?
Also ich würde da gar nicht so super in Detail drauf
eingehen. Also wenn man kann das kaufen, dann hat man
unter Umständen so Vorteile wie,
es wird in der Browser-Leiste grün angezeigt oder so,
weil es irgendwie so Spezial-Deals zwischen den Browser-Herstellern
gibt und
ich meine, das sieht auch komisch aus.
Ich weiß nicht mal, ob das jetzt vertrauenserweckender ist oder
nicht vielleicht, dass die Leute denken, das ist lieber seltsam.
Oh, Kapitalisten, weg da!
Nein, ich weiß nicht. Also, dann ist es so,
die ganzen
Certificate Authorities
sind halt dadurch
aufgefallen, also von denen
kaufst du sozusagen die Dienstleistung, dass sie
dein Key
unterschreiben und damit
der Browser halt, weil er die
Certification Authority kennt, halt sagen kann,
okay, ich glaube, dass das jetzt die Seite
ist, mit der ich tatsächlich rede.
Die haben, sind
halt schon ganz oft dadurch aufgefallen, dass
irgendwie, dass
sie Sachen unterschrieben haben, also das
eine Ding, was sie eigentlich nicht machen dürfen, Dinge
unterschreiben und damit authentifizieren, dass
jemand, der ist, der vorgibt zu sein,
der halt nicht, der ist,
der halt ein anderer war, so für Microsoft
das ist schon ein paar Mal passiert, dass jemand
sich dann als Microsoft ausgegeben konnte,
der es nicht war. Da kannst du natürlich den ganzen Leuten
halt per Windows Update
Sachen reinschieben.
Nicht so geil.
Und solche Sachen.
Das passiert halt dauernd. Daher ist diese
ganze Certificate Authority
Geschichte, das ist alles, das
funktioniert nicht so richtig gut. Und dann hast du
auch Probleme mit, was passiert, wenn du jetzt Sachen
revoken willst. Das geht alles nicht richtig.
Das ist schrecklich.
Also insofern würde ich sagen, man muss auch heutzutage eigentlich kein Geld mehr bezahlen. Es gibt eine freie CA, Let's Encrypt, die in allen Browsern die Keys drin hat, sodass man halt überprüfen kann, ob die korrekt signiert sind.
Das heißt, wo es früher gar nicht möglich war, wo man halt keine verschlüsselte Verbindung bekommen hat, ohne dass einer der Browser irgendwie schreckliche Warngeschichten angezeigt hat, ohne dass man bezahlt hat, das geht heute. Insofern, es ist, ja. Und ja, ich mache das so. Es gibt auch Gründe, das nicht so zu machen.
Oh, wir haben gerade eine Live, eine E-Mail
bekommen zu einem Podcast. Die ist aber leider so lange, dass ich
sie nicht lange vorlesen kann.
Von Topit.
Ja, bin gespannt. Ja, ich werde mir gleich mal
durchlesen. Ich freu mich schon.
Also, Thorsten. Ja. Hi, Thorsten.
Jetzt war eine Live-Interaktion.
Finde ich super.
Ja.
Engagement heute sehr hoch.
Also, wir möchten gerne tatsächlich
diesen Server, den wir jetzt ja irgendwie stehen haben,
mit dem ganzen SSL-Zertifikate und was.
Kann man denn irgendwie was, also wahrscheinlich
ich erzähle jetzt wieder irgendwelchen Unsinn, irgendwie mit
als Proxy benutzen, irgendwie über den
ins Netz connecten und Anfragen stellen auch,
dass ich irgendwie den anderen Weg gehen kann,
dass nicht jeder sieht, wovon ich komme, dass ich dann von meinem Server
ausgehe. Na, das willst du aber
nicht, weil dann weiß doch jeder, woher du
Ja, aber das ist doch okay, aber dann ist das
Das willst du ja gerade nicht.
Nein, aber vielleicht habe ich ja einen anderen Standort und ich connecte immer meinen
Server und dann wissen die vielleicht, dass ich immer mein Server bin
oder sowas, aber die wissen
meinen eigentlichen Standort jetzt nicht, weil ich nicht
immer über meinen Provider gehe. Ja, aber da sind die
Also mein Provider weiß zum Beispiel dann nicht mehr, wo ich hingehe, weil
ich über meinen Server gehe. Ja, okay, gut,
gut, aber der Nachteil ist,
dass jeder Web-Server-Betreiber
weiß, wer du bist.
Was vielleicht auch nicht so cool ist.
Das sind alles Dinge,
das will man wahrscheinlich nicht so machen.
Ja, aber vielleicht,
wenn die ganze Zeit mein Provider sonst immer
alles mitbekommt, vielleicht kann man...
Es ist halt die Frage, vor wem du Angst hast.
Vielleicht vor dem Provider.
Wenn du vor dem Provider Angst hast, ja.
Dann könnte man da raus und das könnte man als Tunnel benutzen.
Würde ich nicht so machen.
Dann nimm lieber was ordentliches, nimm lieber Tor.
Ja, okay.
Oder nimm halt einen von den VPN-Dienstleistern,
aber die sind auch, ich meine, da muss man sich auch bewusst sein,
dass die auch gecaptured werden.
Und vor allem, dass die möglicherweise zweimal verdienen.
Die verdienen halt einmal, weil sie Geld von dir bekommen
und dann verdienen sie halt nochmal,
weil sie Geld von Facebook oder sonst wem bekommen
für die Nutzungsdaten.
Also ich hatte mich jetzt gar nicht für anonyme Surfen interessiert,
sondern ich einfach nur, ob die technischen Möglichkeiten,
wie das funktioniert, wenn ich jetzt da meine Connection über
so einen Server schicken will, was ich da einrichten
würde. Das hat aber nichts
mit Web zu tun. Das ist dann, da würde
es dann irgendwie sowas wie OpenVPN nehmen oder so.
Das heißt, ich würde einen VPN-Server starten,
dahin connecten und dann von dem dann weiterlaufen.
Ja.
Okay. Das OpenVPN
Das ist tatsächlich
ein Anwendungsfall, für den ich das
tatsächlich auch benutze und auch
einen OpenVPN-Server laufen habe.
Bei iPhone geht das
sehr, sehr easy. Da kannst du halt
OpenVPN-Server auch einfach eintragen
als, das ist jetzt VPN. Du kannst ja dann
VPN irgendwie auswählen und kannst sagen, ich nehme jetzt einfach den.
Ist halt
für
Netflix und die ganzen
Streaming-Geschichten, Spotify-Sachen,
die funktionieren ja sonst im Urlaub halt nicht mehr.
die sind ja quasi, und wenn man dann
VPN anmacht, dann gehen die halt trotzdem.
Und dafür habe ich es halt benutzt
bisher.
Ja genau, den musst du dann
auch über den Caddy routen?
Nein, das ist kein HTTP.
Das läuft einfach
auf einem anderen Ort, als Service auf dem Rechner.
Das ist ein ganz anderes Protokoll.
OpenVPN, ein eigenes Protokoll,
läuft üblicherweise, du kannst auch
bei TCP, normalerweise bei UDP,
irgendwo auf einem Port, ich weiß nicht,
irgendwas. Das heißt, ich starte einfach dann auf dem
Rechner, dann die verschiedenen Services am Anfang,
die dann halt hochgefahren sind und die dann nebenbei als
Demons dann laufen. Dazu gehört dann der OpenVPN,
der auf einem anderen Port dann läuft, als der
Caddy, der auf dem 443er läuft.
Und dadurch kann ich dann, indem ich auf die verschiedenen Ports
zugreife, dann auf die verschiedenen einzelnen
Applikationen geroutet werden. Ja, so wie das im Internet halt so üblich ist.
Ja. Was halt quasi
die unterschiedlichen Services haben halt unterschiedliche Ports.
So, Dapp ist halt 80
und 443. Ja, Mail ist
25, DNS ist
53,
je nachdem.
ja, und so weiter. SSH ist 22?
Genau,
FTP 21, ja.
Ja, also SSH will ich wahrscheinlich auch
haben. Ja.
Weil ich halt da irgendwie connecten will. Der muss ja irgendwie auf die Maschine drauf, genau.
Aber dann ist halt auch die Frage, dann, also
als Route auf die Maschine draufgehen, ist das nicht ein bisschen riskant,
das irgendwie zu exponieren? Oder sage ich dem,
der darf sich gar nicht einloggen? Oder wie mache ich das? Mache ich das per
Passwort oder muss ich da irgendwie ein authorized key
irgendwie am besten hinterlegen in irgendeinem
SSH-Konto? Genau, also Authentifizierung
immer per Key und dann
sozusagen legst du den Public Key
in ein File namens
authorize-keys in dem
.ssh-Verzeichnis auf deinem Server
und dann kannst du dich da einloggen.
Und man kann, glaube ich, sogar dann Login
per Passwort abschalten oder sowas? Kann man machen, ja.
Sollte man vielleicht auch. Ja, aber dann kann man
tatsächlich nur noch mit seinem Private Key connecten.
Was macht man denn dann, wenn der kaputt geht?
Dann kann man sich nicht mehr connecten.
Dann ist er am Arsch.
Kannst aber mehrere zum Beispiel nehmen.
Ja, okay, aber dann ist man normalerweise am Arsch, dann muss man
den Server komplett abhauen, weil das alles dann
nicht mehr geht. Dann muss man den Server
hart, wie kommt man da wieder dran?
Also kann man nur die Presse...
Also das hängt halt davon ab,
was das ist.
Du kannst
auch zum Beispiel, wenn du jetzt einen eigenen Server hast,
den Fall hatten wir noch gar nicht, der ist aber auch vielleicht gar nicht so uninteressant,
jetzt bei Hetzner oder so,
wo du wirklich physikalisch eine Maschine gemietet hast,
die irgendwo im Rack steht,
da kriegst du auch eine Konsole drauf.
Ein paar serielle Konsole kannst du dich
auf das Ding, was halt auch interessant ist, wenn du
irgendwelche Dinge machen möchtest, während das Ding bootet oder so.
wo du halt per SSH nichts
machen kannst, weil es gibt keinen SSH, der da läuft,
weil der Kernel noch gar nicht hochgefahren ist.
Da willst du halt was anderes haben, mit dem
du drauf connectest und das geht da.
Oft. So, dass du halt wirklich das Ding
booten sehen kannst und halt kannst du auch Dinge tun
bei booten.
Genau, also das geht alles. Insofern
gibt es da noch andere Wege rein, aber
bei so einem Container, der halt
einfach da...
Da geht das natürlich so nicht, aber
das ist ja so Wegwerf-Kram.
Den schmeißt du halt einfach weg.
Wenn ich den Server irgendwie
abgeschossen habe oder so
und der bootet nicht mehr,
dann kann ich ja nicht anders.
Dann schmeißt du den Container weg und machst einen neuen.
Es dauert ja nicht lange, das dann wieder hochzuziehen.
Ja gut, aber wenn das im Container läuft, dann ist das kein Problem.
Also ich würde sagen, wenn das ordentlich
gemacht ist, dann dauert das von
irgendwie, du kopierst dein Projektverzeichnis dahin
oder checkst es halt aus,
was du auch machen kannst.
Wenn du SSH anhast mit irgendwie
Forward Agent, dann kannst du halt auch
private Repositories, beispielsweise GitHub
oder irgendwelchen Gridlab auschecken.
Du connectest die einfach hin, checkst es aus,
sagst Docker Compose
irgendwie Build und dann linkst du halt
das noch einmal in deinen Super-Wise-D-Config
Dings da nach etc.
Sagst Super-Wise-Control
Restart dein, was auch immer
wie das heißt. Und das
dauert dann drei, vier Minuten und dann ist das Ding
wieder oben.
Selbst das könntest du noch automatisieren.
Das kannst du per Script machen.
Kannst du auch per Python
SSH bedienen, per Paramiko
oder so.
Paramiko heißt das?
Das ist die Library, mit der man in SSA sprechen kann.
Ja, okay.
Ja, also Ports haben wir jetzt einmal so kurz
drauf eingegangen. Also ich könnte auch irgendwie
irgendwelche Ports hinten aufmachen oder irgendwas hinterstecken.
Macht man dann auch sowas wie
so einen Honigtopf auf, dass man einfach irgendwie so eine Reaktion
hat, falls die Leute irgendwie sagen, hey, klassischer
Angriff. Würde ich jetzt nicht machen.
Aber gut, kann man natürlich, wenn man Spaß daran hat.
Also, ja.
Fliegen fangen. Es gibt für
Danglund zum Beispiel auch so ein Honeypot-Modul
irgendwie, dass es so
ein Admin-Interface gäbe
und dann, wo sich Leute dann einloggen können mit
Standard-Passwörtern und dann können sie da irgendwie Dinge machen,
aber das ist alles nur Fake und dann kann man sich hinterher angucken, was sie gemacht haben.
Aber ja,
ich meine, wenn...
Ja, wenn man ein bisschen rumspielt in der Hobbygruppe und mal so guckt, was man so
alles rausfinden kann und wie man das alles so macht und so.
Aber ich würde sagen, ich würde es deswegen nicht machen,
weil das ist gefährlich.
Das ist halt viel Code, der mit außen redet.
Das ist viel Angriffsfläche.
Ja gut, ich sag mal, wenn man auf dem Server jetzt nichts zu verstecken hat,
sondern es eh nur so zum Rumspielen ist, dann ist das ja vielleicht gar nicht so schlimm.
Kannst du auch einfach offen lassen.
Dann gucken wir uns die Leute, vielleicht ist es hinterher besser.
Vielleicht ist das ja auch ein bisschen Honig ausliegen.
Schokolade.
Firewall?
Ist das auf Router-Ebene
dann im Serverzentrum?
Nein, also Firewall ist halt die Frage,
was die Leute darunter verstehen.
Das sind auch unterschiedliche Dinge.
Ich kenne es halt eher so aus der Internet-Admin-Welt.
Und da nennt man
ein Firewall ist ein System
zur Durchsetzung einer Policy
am Übergang zwischen Netzwerken.
Das ist eine Firewall.
Ich weiß, dass es so im Heimcomputer-Bereich
gibt es da irgendwie andere Definitionen von.
Da gibt es auch so Personal Firewalls oder sowas.
Aber das ist alles Quatsch.
Aus meiner Perspektive, weil die machen genau
das eben nicht.
Was heißt denn eine Policy-Restriktion? Also wann darf
denn welches Protokoll mit welchem ich reden? Oder darf ein bestimmtes
Protokoll nicht auf einem bestimmten Port?
Du guckst dir halt,
was ich normalerweise, also Firewall ist
ein Konzept, das ist nicht unbedingt eine
Implementation. Das, was die meisten Leute
vielleicht darunter verstehen, ist sowas wie ein Paketfilter.
Paketfilter, da guckt sich immer vier Sachen an.
Quell-IP,
Ziel-IP, Quellport, Zielport.
Du kannst jetzt natürlich auf beliebige
Kombinationen davon Policies definieren.
Kannst du sagen, okay, das lasse ich durch, das lasse ich nicht
durch. Und jetzt ein Paketfilter guckt
sich immer diese Quadruple an
und entscheidet dann, ob er das
Paket durchlässt oder nicht. Und sowas kann man dann
mit Paketeinlösung, mit
Pyshark machen und das dann selber bauen?
Da gibt es Software, die das
macht, aber das macht nur dann Sinn.
Also einmal willst du
solche Sachen niemals verwenden, um
dich
darauf zu verlassen, sondern das ist immer
nur ein zusätzliches Sicherheitsnetz.
Also die Sachen sollten sicher sein von sich aus.
Das kann ja auch sein, dass
Paketfilter ausfallen oder nicht ordentlich funktionieren
oder so. Das sollte deine Sicherheit nicht beeinträchtigen.
Sondern das ist einfach nur,
damit du sagen kannst, ich habe hier ein Stück Hardware,
das ist sonst mit nichts verbunden.
Ja, das ist nicht
irgendwie auf der gleichen Maschine, da kann ich
irgendwie, wenn jemand meine Maschine aufgemacht hat
oder eine Applikation aufgemacht hat, kann er
diese Policy nicht ändern. Das heißt,
dafür muss es dann halt
physikalisch getrennte Maschine im Grunde sein,
auf der nur der Paketfilter läuft, sonst nichts.
Sonst macht das keinen Sinn. So, und den hast du
halt am Übergang zwischen unterschiedlichen Netzen, weil
da kannst du halt genau auf
Basis dieser vier
Attribute irgendwie
dann deine Policy irgendwie durchsetzen.
Falls ich doch meinen offenen File-Dings da betreiben will,
dann sollte ich dann eine Firewall zwischen dem Netz und ...
Aber das kannst du überhaupt nicht.
Du hast ja nicht Kontrolle über das Netz.
Ich würde sagen, das macht ja nur dann Sinn,
wenn du auch das Netz da unter Kontrolle hast.
Dann muss ich das lokale Netz unter Kontrolle haben.
Du müsstest das Netz, in dem du diese Policy durchsetzen willst,
musst du unter Kontrolle haben.
Aber meine eigene Server-Farm zu Hause.
Du kannst es zu Hause machen, ja.
Für zwei verschiedene Router-Netze oder so was,
die ich voneinander trennen will.
Vielleicht habe ich irgendwie ein kleines offenes Netz da.
Da gibt es ja so ein paar Optionen, wo man frei sich
verbinden kann an einem Funk.
Und dann könnte man das mit seinem Heimnetzwerk machen und da sollte man
sowas dazwischen hängen, weil die Geräte zwar im gleichen
Laden... Das ist viel zu viel Aufwand.
Das ist viel zu viel Aufwand, um sowas selber zu machen.
Oder ich wüsste jetzt nicht, dass das irgendein...
Also ich
finde, diese Zeiten sind vorbei. Also das ist...
Das macht man nicht mehr.
Ja, also ich meine, eben diese
die Hoster und
vielleicht auch Amazon, die werden solche Sachen betreiben.
Die machen das so.
Aber
für zu Hause macht das doch kein...
Ich meine, du musst wirklich ein eigenes
Gerät dafür haben, dass das nur das tut.
Und dann brauchst du mehrere davon, weil
du willst ja
nicht nur einen, du brauchst ja dann irgendwie
unterschiedliche Zonen
und
da gibt es ja unterschiedliche Konzepte, wie du
das realisierst und du kommst ja
mit einem Ding auch gar nicht aus, da brauchst du mehrere davon.
Das heißt, du betreibst mehrere Rechner zu Hause nur, um
diese Policy da durchzusetzen.
Welchen Gewinn erzielst du dadurch?
Und vor allen Dingen im Verhältnis zu dem Aufwand.
Als Rechenzentrumsbetreiber kann man
das irgendwie rechtfertigen, dass man zu jedem Switch dann noch
irgendwie einen Paketfilter stellt.
Oder alle zwei, drei
Racks stellt man da halt irgendwie noch einen Paketfilter
dazu.
Aber zu Hause...
Da bin ich aber
ganz sicher, da bin ich nicht mehr so Glaskörper-mäßig.
Ja, aber das Ding
hilft dir ja für die meisten Sachen, die dich
sozusagen, wenn du...
Mist, nicht.
Genau, es hängt halt
davon ab, wovor du Angst hast.
Wenn du Angst davor hast, dass die
Applikationen, die bei dir laufen, was Böses tun, dann
schützt dich das alles überhaupt gar nicht.
Das schützt dich halt bloß davor, dass jemand
Verbindungen irgendwie, die du
laut Policy nicht zulässt,
macht. Aber das passiert heute eh fast
nicht mehr.
Oder das passiert ja auch nur dann, wenn
überhaupt eine Verbindung möglich wäre. Die meisten
sitzen hinter irgendeinem komischen, dynamischen
IP oder irgendeinem seltsamen NAT.
das ist mit den Verbindungen sowieso nicht so toll.
Und da müssen
sich, müssen ja diejenigen,
die das,
wenn du da irgendwie, wenn jemand
dich kompromittiert hat, dann muss er ja irgendwie nach Hause
telefonieren und dann muss er das eh auf eine relativ
schlaue Art tun, sonst kommt er ja gar nicht mehr durch.
Aber wenn er das auf eine relativ schlaue Art tut, dann nützt dir der ganze
Paketfilterkram nichts, weil
der sieht ja nichts Schlaues, der macht ja nichts Schlaues,
sondern der macht ja was sehr, sehr Einfaches eigentlich.
Also
schwer. Also Firewalls sind auch quasi
aus den Relikten, aus der Pakete.
Naja, also Firewall ist ja unter Umständen noch viel mehr.
Es ist ja nicht nur Paketfilter, sondern das ist halt,
man kann ja auch noch andere Dinge tun.
Man könnte auch solche Sachen machen wie,
na, du hast da einen Rechner,
auf dem läuft nur
ein,
wie heißt das, VLC oder so,
nee, dieses Ding ist VNC.
VNC ist das, ja.
Du connectest dich darauf, du hast selber,
bist du abgeschnitten von,
Du kannst halt bloß über so eine grafische Schnittstelle
irgendwie mit außen kommunizieren.
Das macht man auch manchmal. Das ist auch, würde ich sagen,
eine Firewall, um halt
zu verhindern, dass du
Netzwerke miteinander überhaupt verbinden musst. Dann kannst du halt da
sagen, okay, da ist
gar keine Verbindung in dem Sinne.
Es würde
für mich auch irgendwie unter Firewall fallen.
Oder es kann diverse
andere Geschichten geben, die
halt auch darunter fallen. Also ich würde eher sagen,
das ist eher ein Konzept,
ja, aber das ist alles
Sachen, das ist heute, ich würde
sagen, ich weiß es natürlich nicht so genau,
das ist heutzutage eher ein Ding für Experten.
Weil
wer hat...
Also ich meine,
wenn einem das Spaß macht, kann man sich ja damit beschäftigen, aber
so,
das,
ja,
die meisten Firmen
machen ja auch ihr Rechenzentrumskram nicht mehr selber.
Auch das macht natürlich Spaß, irgendwie selber Racks zu
bauen und Kabel zu ziehen und die zu labeln
und so, voll gut, aber das macht auch
heute kaum noch jemand, weil alle gehen halt
in die Cloud und
es ist halt so ein bisschen
das wird halt eher, das rutscht halt alles so
in die Richtung
Commodity, also früher hat es halt
vielleicht noch einen Unterschied gemacht, wenn man jetzt in einer Firma war
und hat halt irgendwie sein eigenes
Rechenzentrum im Keller betrieben, ob man
jetzt die Kabel ordentlich
gelabelt hat und irgendwie da
die Paketfelder ordentlich hingestellt hat und so
und heutzutage ist das halt so, darüber kann man
sich schwer differenzieren, weil
also außer man macht es halt scheiße,
aber ansonsten kann man es, wenn man es gut
macht, besser als Amazon wird man es nicht
machen können, daher, oder nur
mit einem Aufwand, der
das ist halt nicht mehr gerechtfertigt. Nicht mehr bezahlbar
natürlich. Nicht bezahlbar, ja, es lohnt sich einfach
nicht. Also Amazon ist
so gut, die anderen auch,
dass sich das nicht mehr lohnt,
das selber zu machen, um sich da noch irgendwie
was rauszuholen.
Das musst du mir nochmal genauer erklären.
Das ist so ein bisschen schade irgendwie, weil
natürlich viele coole Sachen, die früher irgendwie
interessant waren, heute halt nicht mehr so.
Aber
ich fürchte, das ist halt so der Gang der Dinge.
Zeiten sind vorbei.
Na gut.
Aber ja, ich meine, das ist natürlich schon alles interessant.
Also ich würde vielleicht gerne noch mal
kurz das mit dem Server abschließen.
So ein bisschen, was ich noch machen würde, also für mich
jetzt persönlich, ich würde gerne so ein paar IoT-Geräte
da ranschicken. Also ich habe jetzt irgendwo
ein paar Respi-Sensoren oder sowas,
die ich dann da
Broadcast oder sowas mit MQTT
habe ich gelernt, das würde ganz gut funktionieren.
Und dann lade ich irgendwie so ein REST
oder ein GraphQL am besten.
Was würdest du sagen, API
laufen über so ein Caddy
dann ein Django ansteuern?
Also in Django selber rein geht das
dann wahrscheinlich, wenn du es direkt in Django rein
schreiben willst, über wahrscheinlich
sowas wie Django REST Framework oder halt eben über
GraphQL oder so. Das sind halt so die typischen
Sachen, mit denen man halt APIs bereitstellt.
Aber
was du auch machen könntest,
das ist halt die Frage. Also MQTT ist halt
insofern schicker, als dass es halt genau für solche
Anwendungsfälle gedacht ist.
Und du dir halt
über viele Sachen nicht mehr selber Gedanken
machen musst, was du müsstest, wenn du es
halt, also wenn du
jetzt zum Beispiel irgendwie, keine Ahnung,
du hast einen Sensor,
ist halt die Frage, ob das jetzt wichtig ist, die Daten,
die dabei rausfallen, oder ob man die ignorieren kann. Also wenn
jetzt da ein wichtiger,
nehmen wir an, du hast einen Geigerzeller in deinen Raspberry Pi
eingeschlossen, ja, und irgendwie
die Fallout-Wolke ist überzieht
über dein Wohngebiet.
Aber dummerweise ist irgendwie
dein Server nicht erreichbar. Dann ist es natürlich blöd,
wenn jetzt diese Information,
dass dein Garten verseucht ist,
nicht bei dir ankommt,
weil der Raspberry Pi, der die Sensordaten
bekommen hat, versucht dir halt irgendwie
an deinen Server zu schicken und der ist halt gerade nicht da.
Und was macht...
Schmeißt dir einfach weg.
Schmeißt dir einfach weg und dann kriegst du die Daten
nicht. Hängt davon ab, hängt von
deine Anforderungen ab, ob das jetzt
schlimm ist oder nicht. Kann auch sein, dass es nicht schlimm ist.
Aber wenn du
möchtest, dass die dann halt
noch irgendwann dahin geschickt werden, wenn der Server wieder da ist,
dann brauchst du ja selber irgendwie eine Art von
Queue, dann brauchst du irgendwie eine Warteschlange,
wo halt die Sensordaten erstmal
auflaufen und dann halt irgendwie, dann wenn dein Server
wieder verfügbar ist, dahin geschickt werden.
Und ja,
dann kannst du noch Features dazu bauen und dann
implementierst du
MQTT oder halt beliebiges anderes
Queuing-System,
Message-Queue-System halt nach.
Und das muss man nicht tun, man kann einfach eins
nehmen, das schon fertig ist und das macht das dann
für einen. Dann schmeißt man halt
in die Queue halt irgendwie dieses Sensor
Datum halt rein.
Und der überlebt ja nicht so lange, bis er eine
201. Genau, man muss sich
nicht mehr selber kümmern, dass das irgendwie
zugestellt wird und so, das passiert dann automatisch.
Der macht dann einfach Post-Requests auf die API.
Nee, nee, nee, nee. Das Ding macht, nein, nein,
das hat ein eigenes Protokoll, das macht
auch kein HTTP.
Das ist ein eigenes Protokoll. Es gibt ein
MQTT-Broker, der irgendwie
weiß, welche
Ja. Dann spricht der dann REST.
Nein. Was bekommt der denn dann?
Kein HTTP. Aber wie bekomme ich denn
auf meinem Django
Backend, auf meinem Django-Server?
Du könntest natürlich, ja, du kannst halt intern
irgendwo bei dir zu Hause MQTT sprechen
und dann halt irgendwie den ganzen Kram halt periodisch
zu deinem Server schicken, aber du könntest
natürlich auch, und das ist fast wahrscheinlich dein geiler,
zum Beispiel
ein VPN aufmachen.
Ja. Und
hast halt auch
quasi ein
ja, Ding, was halt
an der Queue hängt, sozusagen
die konsumiert,
die Ereignisse,
die da rausfallen, die Events, die da rausfallen
und das dann halt irgendwo zum Beispiel in deine
Datenbank direkt reinschreiben.
Dann geh ich aber gar nicht mehr über die API.
Aber dann hab ich noch einen eigenen Service laufen, der
hängt aber nicht mehr am Caddy, sondern
der hängt als Daemon wieder auf einem eigenen Port.
genau. Aha, und dann muss ich dann einfach
dann, wie kann der denn dann mit
der, das ist mein Problem, mit der Datenbank,
die im Docker liegt, reden?
Ja, auf dem lokalen Host geht das
ja alles, da kannst du auch mit der
Datenbank reden, das geht.
Ah, das heißt, ich muss dann aber den
Container mit reinschreiben, den
MQTT
Broadcaster, damit er auf die
Datenbank zugreifen kann?
Nö, das musst du halt bloß irgendwie da
einkommen, das Ding kann in dem Container
irgendwie als Prozess laufen, es kann aber auch wieder in einem eigenen
Container laufen.
Ich bin jetzt gerade ein bisschen ausgestiegen an der Stelle
dieser Verzahnung. Also ich habe jetzt
meinen Dango in einem Docker-Container
laufen, der vom
Caddy angesteuert wird.
Das läuft
selber in einem eigenen Container.
Angesteuert, das gibt zu viel.
Also der Caddy, der schießt das doch zum
App-Server. Nein, wenn Requests
von außen kommen, die landen auf dem Caddy.
Und der schickt sie dann halt weiter an den Applikations-Server,
wenn sie bestimmte Container entsprechen.
Der läuft aber als Docker.
Ja, aber der Caddy kann auch als Docker-Ding
laufen. Das ist, bei der
Default-Installation mit Cookiecutter ist das auch
so. Da läuft auch der Caddy in einem eigenen
Container. Und dann ist das egal, dann kann der MQTT
Broadcaster auch in einem Container laufen, der kann
aber dann mit den anderen Postgres-Containern zum Beispiel
reden oder sowas. Ja. Ja, okay.
Dann kann er das dann reinschreiben und dann kann Django darauf zugreifen.
Ja. Der Zugriff, den mache ich jetzt, weiß ich
nicht, Django kann man Plotly,
Seaborn, Matplotlib oder halt tatsächlich so
ein bisschen Dash sogar, habe ich gesehen,
um das dann irgendwie für sich darzustellen.
Wie kommunizieren die denn dann mit der Datenbank,
damit das dann live abgerufen werden kann,
wenn ich die Daten jetzt live auslesen möchte?
Weiß ich, ehrlich gesagt.
Bin ich mir so ein bisschen überfragt, keine Ahnung.
Also man kann das halt so machen, dass man,
also du möchtest, dass sich live irgendwie dein Graph ändert.
Ja.
Wenn ich auf den Knopf drücke, dann soll das,
also auf dem Raspi, auf dem Knopf drücke,
dann soll das direkt sichtbar sein.
Ja, dann, also das Einfachste ist wahrscheinlich in JavaScript
einfach zu pollen, irgendwie alle paar hundert Millisekunden
oder so einfach nochmal die API zu fragen,
Da gibt es neue Daten.
Mit einem Get-Request und einfach.
Ja.
Oder, aber das ist halt die Frage,
ob man das machen möchte.
Du nimmst halt Web-Sockets
und dann sowas auf Django-Seite,
sowas wie Django-Channels oder so.
Aber dann musst du halt einen anderen,
musst du auch bestimmt einen anderen.
Was sind denn Web-Sockets jetzt schon wieder?
Ui, ja.
Das ist halt so eine Erweiterung.
Das ist halt dann auch schon nicht mehr HTTP.
Das ist halt was anderes.
Bei HTTP, da hast du das Problem,
du hast keine bidirektionale Verbindung,
sondern du hast halt immer nur Request-Response.
Und Request-Response
geht das nicht, weil du kannst halt
vom Server aus nichts zum Client schicken, weil du
weißt ja nicht mal, wer deine Clients sind. Du hast ja keine
Verbindung zu denen. Socket hört sich so an wie so ein Port
oder sowas, der irgendwie im Internet rumschwebt.
Socket. Ja, Socket ist
quasi sozusagen das eine
Ende der Hörer bei einem Telefon. Wenn du dir vorstellst,
das ist wie so eine Verbindung, so eine
Internet-TCP-Verbindung ist halt wie so
eine Telefonverbindung, dann wäre Socket
irgendwie der Hörer, wo man irgendwie was reinwerfen kann,
was dann auf der anderen Seite rauskommt. Und dann kannst du
in beide Richtungen auch was reinwerfen.
Bei HTTP ist halt nicht so, sondern
HTTP ist eher so wie
Rohrpost. Da wirfst du halt
was rein und das...
Quatsch, das ist auch Unsinn. Das wäre auch
bidirektional.
HTTP ist eher so wie...
Wie so ein Katapult.
Katapult in eine
Richtung, fliegt immer was vor die Stippmauer.
Du hast
eine Telefonverbindung, aber
auf der Serverseite hast du nur...
Oder du bist in so einem Bandiseil
und versuchst mit der Hand immer ins Wasser.
Ach, diese ganzen Vergleiche sind nicht gut.
Das stimmt alles nicht.
Ja, mir fällt jetzt kein guter Vergleich ein.
Das ist aber auf jeden Fall so.
Du hast halt eben keine Verbindung zu deinen Clients.
Du kannst die nicht benachrichtigen,
dass sich irgendwas geändert hat.
Du kannst immer nur darauf warten,
dass sie dich fragen.
Du kannst ein Fax hin und her schicken oder sowas.
Ja, du kannst halt nichts dahin schicken.
Du kannst halt nur darauf warten,
dass dich jemand fragt.
Und das ist halt,
du bist halt so wie
beim Bahnhof,
die Informationen.
Die Leute können zu dir kommen und dich irgendwas fragen,
aber wenn jetzt der Zug
ausfällt, die Wagenreihung
sich ändert oder Godzilla drüber gelaufen ist,
dann kannst du das
den ganzen Reisenden nicht
sagen, sondern die müssen kommen
und dich fragen, quasi.
Ja, man könnte ja so eine Durchsage haben,
aber so weit sind wir jetzt noch nicht, das ist viel zu modern.
Ja, genau, da geht es dann
natürlich schon wieder kaputt mit der Metapher.
ja, also
eben, wenn du dann
WebSockets hast, dann geht es halt doch. Dann hast du eben eine Verbindung
zu einem Client und den kannst du dann in Echtzeit direkt
sagen. Wie mache ich WebSockets an?
Also bei Django hast du gesagt Channels. Ja, Django
Channels ist eine, das Problem ist aber, du brauchst
halt einen anderen Server,
einen Applikationsserver, der das kann.
Und welcher Applikationsserver kann WebSockets?
Der kommt
dann da mit Django Channel Strike mit, der heißt irgendwie
Daphne.
Und ja,
es gibt auch, glaube ich, einen, der
so ähnlich ist wie Unicorn, der heißt bloß ein bisschen
anders, der das dann auch kann.
Aber
genau, also das ist alles
nicht mehr so einfach dann.
Ja, aber jetzt habe ich schon wieder eine Menge gelernt,
ich bin viel weiter gekommen. Was mir jetzt
das Einzige, was mir noch fehlt tatsächlich, wäre jetzt das
Indie-Web, was ich jetzt da irgendwie bauen wollte.
Achso, Indie-Web-Geschichten, genau, dafür brauchst
du, also wenn du eine eigene Domain hast, ist schon mal sehr gut,
dann kannst du schon mal eine Menge machen
und das auch
und vor allen Dingen kannst du eine Menge nachrüsten.
Ansonsten bei Django sieht es da momentan noch nicht so richtig
doll aus, also
da muss man noch ein bisschen was basteln.
Ja, ich habe jetzt tatsächlich
irgendwie geguckt, wir haben jetzt die ganze Zeit über Django geredet, aber du kannst
einfach auch irgendwie jetzt ein Flasho und Pyramid einfach
da nehmen, ist eigentlich relativ egal. Ja, da gibt es auch nichts.
Aber dann gibt es halt immer die
anderen Module, die man dann irgendwie sich herausfinden muss,
welche das dann sind und das funktioniert aber dann quasi
relativ ähnlich.
Genau. Also Indie-Web-Geschichten
ist momentan eher noch alles so in der PHP-Welt
zu Hause.
Ja, so ist es halt.
Das heißt, ich muss dann einfach den
Ketti auf ein PHP-Verzeichnis schicken?
Wenn du jetzt...
Nee,
du könntest... Also ich weiß nicht,
wie man das heutzutage so macht mit PHP.
Ich hoffe, dass auch mal da die Zeiten,
wo man da irgendwie so eine Web-Route
hatte und da irgendwie PHP-Dateien,
die dann irgendwie magisch ausgeführt werden über Mod.php
oder so. Und Apache, ich hoffe ja mal,
dass das nicht mehr so ist.
Sondern dass man da auch das inzwischen so macht,
dass man da halt irgendwie Caddy davor hat
oder irgendwie Nginx und dann hast du halt
Applikationsserver, die halt PHP...
Aber im Worst Case könntest du sagen, dass ich neben dem Caddy
dann einfach ein Apache mit einem Mod.php laufen
habe und der dann Ansprüche hat auf den nächsten Port.
Ja, könntest du ja natürlich auch machen.
Du kannst ja einfach ein Caddy sagen, so das bitte
diese Domain oder
diese Subdomain oder was auch immer an den Apache
weiterreichen geht natürlich auch und den in einen eigenen Container packen.
Klar. Und dann für das Indie-Werb,
was brauche ich denn da noch? Also eigentlich auch, sagen wir mal.
Ja, kommt halt darauf an, was du machen möchtest.
Aber da müssen wir noch mal, also weiß ich jetzt ehrlich gesagt,
aber das ist nicht so genau. Okay, das machen wir dann noch mal
von extern. Da haben wir ja schon mal ein bisschen kurz eingerichtet.
Aber das könnt ihr euch bestimmt auch einlegen, da gibt es ja Dokus zu.
Aber das geht alles mit dem selben Server.
Also ja, GitLab haben wir gesagt,
kannst du auch selber drauf bauen, wenn du deine eigene Versionskontrolle
bauen willst, dann ein GitLab-Server.
Das wird wahrscheinlich auch einfach ein
Dienst sein, oder? Demon?
Was ist das?
Ja, das ist einfach auch wieder eine Webgeschichte.
GitLab ist einfach auch nur so ein Webfrontend.
Ruby und Rails ist halt, ich weiß nicht genau,
wie aufwendig das zu hosten ist.
Also irgendwann wird es dann natürlich schwerer.
Also wenn du 10 Container hast oder 20,
irgendwann wird es dann mit dem Hauptspeicher ein bisschen eng.
Keine Ahnung.
Brauchen wir möglicherweise auch eine eigene Datenbank?
Ja.
Also Datenbanken sollte man nicht so viele nehmen.
Man sollte die meisten Sachen in dieselbe Datenbank packen,
weil Datenbanken viel Dinge brauchen.
Nein?
Ich würde das tatsächlich so machen.
Ganz viele kleine Container, ganz viele kleine Datenbanken.
Nee, ich würde das nach Systemen auftrennen.
Nach Projekten.
Und dann immer einen eigenen Container
für die Datenbanken machen und das nicht alles
auf eine Datenbank packen, weil
auch da wiederum, wenn du das halt irgendwie
updatest oder so, du möchtest ja eigentlich, oder du bist halt
dann, du begibst dich dann in das Gebiet.
Du musst die Datenbank löschen für ein Projekt und dann
sind alle Projekte blutsch.
Du upgradest die Datenbank und dann sind alle Projekte down.
Das willst du ja nicht eigentlich.
Sondern du willst halt auch vielleicht mit
einem Projekt auf einer bestimmten Datenbank-Version
bleiben können und so.
Und du willst halt die ganzen Systeme voneinander isolieren.
Es ist natürlich effizienter, wenn du irgendwo einen Datenbank-Server
hast, wo alle
deine Datenbanken liegen. Wäre viel effizienter,
aber ist halt viel schwerer,
was die,
was den Betrieb angeht.
Das heißt, ich muss dann von meinem Web-Server auf den Datenbank-Server
immer hin und her connecten oder sowas.
Naja, es ist halt einfach,
du musst dann
plötzlich Dinge tun. Du musst dann
irgendwie, da musst du Backups haben,
musst du auch so haben, aber das kriegst du alles
in deinem Projekt unter. Aber wenn du jetzt
einen eigenen Datenbank-Server hast, dann ist das
mit dem Backup immer alles nicht mehr so einfach.
Also wenn du das machst, dann bist du halt schon im Profibereich
irgendwie unterwegs, dann machst du sonst nichts mehr.
Dann machst du genau das nur noch. Und die Frage ist,
ja, für Hobbygeschichten lohnt sich das ja
überhaupt gar nicht.
Ja, dann sind wir wieder,
ich glaube, den Kreis können wir jetzt schließen. Wir sind ja
nämlich bei der Taiga angekommen, weil
die möchte ich jetzt vielleicht auch noch laufen lassen. Ich hätte gerne
ein paar Kanban-Boards irgendwie für mich persönlich, die ich dann
selber hoste. Genau dasselbe, ich muss da wieder
was hochfahren, was Routen über da in Keddy
und Abdeckung laufen und läuft.
Ja, super, also ja,
wenn ich das irgendwie, ich bin gespannt, wie lange ich dafür brauche,
bis das alles rennt. Ich gebe euch
die Zeit. Ja, wenn,
am Ball bleiben.
Das ist auch, aber ich meine, wenn du,
also ich höre, du willst eine ganze Menge Zeug betreiben,
da brauchst du wahrscheinlich dann schon
eher so eigene Hardware oder sagen wir so, dann wird es mit
eigener Hardware deutlich günstiger, als wenn du
jetzt da irgendwie
eine virtuelle
Container irgendwie dir mietest, der dick genug ist,
dass du das alles damit machen kannst, das wird dann relativ schnell teuer.
Ja, ja, also der RAM ist glaube ich das
größte Problem. Ja, RAM ist irgendwie das, ja, würde ich auch
sagen. Ja, ich habe noch so einen kleinen Eck,
aber mit dem ist es auch irgendwie doof und
ja, ich muss überlegen, was da irgendwie
am besten in Frage kommt. Aber damit
kannst du ja vielleicht starten, du kannst ja zu Hause anfangen.
Ja, ja, der ist schon, der läuft schon eine ganze Weile, aber das
macht keinen Spaß.
Ja, aber ich muss ja
immer so ein ganzes System bauen und so, aber ich möchte die ganze
nachher dann einfach wieder umbauen können, dass das
nicht jedes Mal dieser ganze Konfigurationsaufwand ist.
Ich habe jetzt irgendwie im Fedora-Server dann irgendwie
hingestellt, dass ich irgendwie einige Sachen auch konnte,
der auch in den Postgres auch lief und irgendwie
auch dann Dango konnte, aber dass das alles nicht so
gewesen ist wollte.
Aber wir haben jetzt auf jeden Fall, das finde ich total super,
ich habe da keinen Candy, kein Redux und nichts
da gebaut, das war mir bisher völlig unbekannt
und ja, finde ich super, dass man das
alles so machen kann. Also bis jetzt geht es ja immer nur
so, Docker-Containers bauen, dann läuft das
alles irgendwie magisch, aber wenn man nicht so wirklich versteht, was dann
dahinter steckt, ist das nochmal
mal eine ganz andere Hürde, glaube ich, auch zu verstehen, warum
was gerade nicht geht oder so.
Vielen Dank, dass du mir das alles wieder heute hier erklärt hast.
Ja, ich meine, jetzt weiß ich nicht,
ob das alles irgendwie klarer geworden ist oder nur noch
viel verwirrender. Nein, nein, nein, das war richtig, richtig,
richtig super. Eine große Erleuchtung
und man kann sich das ja alles auch mal
zurückspulen oder nochmal langsam abspulen.
Ja.
Ich fand's echt cool. Ja, also auf jeden Fall
eine tolle Folge für mich mal heute hier.
Ich mag die natürlich immer.
Das ist ganz persönlich auch gut.
Ja, und genau, also
ja, also
macht auch Spaß und
ich denke, dass man zumindest, also
wenn man so ein paar Anregungen
hat, wie man selber eine
Webseite irgendwie oder Django
Python-Kram im Web betreiben
kann und wenn man das eigentlich vielleicht
heutzutage so macht, dann ist das ja auch schon mal nicht so
schlecht, weil man muss eh viel recherchieren
und bei Django würde ich sagen, irgendwie
Buch kaufen, Cookie-Cutter-Template
verwenden.
Ja, also ich
Ich lese jetzt gleich erstmal die Mail von Thorsten durch
und freue mich, dass ihr heute alle wieder zugehört habt.
Fand ich richtig super.
Pics machen wir nicht.
Ich habe ja sowieso auch keine...
Ja, mit Pics der Woche habt ihr es ja heute Morgen.
Habe ich schon verbrannt, wie gesagt, am Anfang.
Machen wir dann diesmal nicht.
Ja, das machen wir nächstes Mal.
Gut.
Okay.
Ja, dann super, dass ihr wieder reingeschaltet habt.
Bleibt uns gewogen.
Immer dann, wann ihr auch hört,
ob gerade die Sterne scheinen oder die Sonne brüht.
Ja, wir hören uns.
Jo.
Bis später.
Jo, tschüss.
Tschüss.