Transkript: Deployment von Webapplikationen

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.pythonpodcast.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-Schepter-Marsch funktioniert nicht so wirklich.

Wir wollen irgendwann nochmal ein bisschen daran basteln, dass das dann mal geht.

Ja, unter den Kommentaren müssen wir wahrscheinlich auch noch so ein bisschen was tun.

Da wäre es vielleicht nicht so schlecht, wenn man eine E-Mail-Benachrichtigung kriegen könnte.

Oder vielleicht zumindest ein Kommentar-Feed oder sowas.

Muss ich mal gucken.

Geht bestimmt.

Habe ich mir schon mal auf die To-Do-Liste geschrieben, aber muss auch irgendwie, es ist nicht nur sehr warm, es ist auch irgendwie sehr wenig Zeit unterhand für alle möglichen Dinge.

Ja, ja, alles auf einmal.

So ist das halt.

Ja.

Aber genau, so ein bisschen haben wir ja schon.

Insofern brauchen wir uns nicht die ganze Zeit nur zu beschweren, sondern auch ein bisschen was erzählen.

Ja, die sind durchherrichtlich 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 nie 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 zu zu sagen, weil ich hatte so beim Durchschnitt, ich habe es noch nicht komplett durchgelesen, aber ich habe es so ein bisschen reingeguckt.

Also wie ihr merkt, wir sind direkt bei der nächsten Chaptermark.

News Szene.

Ja, Moment, genau, genau, Moment.

News.

Ja, alles klar, habe ich gesetzt.

Ja, so beim Durchblättern habe ich schon gedacht, so, 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, 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ände wedeln, das ist alles kompliziert, das ist nicht so einfach, fragt einfach euer Obs-Team.

Ja, und dann hat man das vielleicht gar nicht.

Das ist blöd.

Ja.

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.

Ja, ja, genau.

Ich würde 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 dadurch hätte ich 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 Podcast 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 dieses Format passt.

Da ging es um eine Firma, die halt so Label Data Labeling macht.

Also gut, ich mache ja auch viel Machine Learning Zeugs Data Science und da, also ich fand das deswegen gut, also weil, also da ging, ich glaube, wie hieß es die Firma normal?

Cloudworker oder so, der Chef von denen, einer von Gründer, hat er halt irgendwie auf dem Data Engineering Podcast da was zu erzählt und das, was er so beschrieben hat, 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 als sonst einfach.

Das sind nicht alle Machine Learning, 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, ist meistens ein großes Problem.

Und der hat ja auch so ein paar lustige Beispiele dafür, wie momentan da, also auch welche kuriose Ideen da Leute kommen, um Daten zu bekommen.

Also momentan ist es 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 irgendwie 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 ja irgendwie 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 unterschiedlich.

Und es ist nicht so einfach.

Und dann ist es natürlich auch relativ schnell, relativ teuer, um die Datenversucht selber zu generieren.

Oder muss irgendwie mit Drohnen rumfliegen und Sachen fotografieren und sowas.

Klingt ja mit 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, das wäre durchaus Spaß machen.

Ja, ja, genau.

Brown Cookie Nein.

Genau, genau, das habe ich gehört, das fand ich ganz cool.

Kann man sich mal anhören, ich werde das einfach den Link dazu in die Shownotes packen.

Das hat jetzt aber gar nicht so viel mit Python zu tun, sondern es war eher so, ja, 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-Kys was getwittert, zum nächsten Camp, glaube ich, war das.

Ja, ah, okay.

Genau, da ging es um Pre-Talks, glaube ich.

Ja.

Meine ich.

Nein, nein.

Doch?

Doch, ja, doch, genau, das ist es.

Zwar ist das so ein Konferenz, ähm, ja, 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.

Ah, ja, da waren wir auch, ja.

Auch waren.

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 das auch Pre-Talks irgendwie mit E-Mails ordentlich umgehen kann und so.

Und deswegen hat er auf Twitter mal gefragt, ob es da nicht Leute gibt, die ja 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 Tango 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 ja, finde ich eine gute Gelegenheit.

Ich würde da auch hingehen, wenn ich auf dem Camp wäre.

Ich weiß es aber.

Ich fürchte, ich werde nicht da sein.

Ganz vielleicht doch, aber ja, wahrscheinlich nicht.

Daher wird das leider nicht funktionieren, aber vielleicht kann ich nicht mehr.

Wann ist das denn überhaupt vielleicht für irgendjemanden geneigten?

Das Camp ist irgendwie Ende August.

Ich habe es schon ausverkauft, oder?

Schon lange jetzt.

Ja, ja, schon lange.

Moment, ich guck mal gerade das CCC-Camp, wann ist denn das?

Also irgendwie 20.

bis 25.8.

Irgendwo in der Nähe.

So einem Monat.

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.

Cool.

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 Podcast.

Kindertoben, ne?

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 öte Weite Ödnis im Norden.

Das Projektmanagement-Tool.

Ja, das werden wir doch später besprechen.

Nee, aber das passt jetzt super, das hier ran zu pflanschen, weil das ist nämlich, könnte man super auch mit den Peatalks eigentlich verbinden.

Weil, naja, da fehlt halt vielleicht so ein bisschen ein Ticketsystem und das Tiger hat das auch schon eingebaut.

Und das hat irgendwie ein ziemlich cooles Tickets-System eigentlich.

Und das ist halt auch Django und das ist vor allen Dingen ein 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 erkennen, was denn Tiger jetzt überhaupt ist.

Also Tiger ist halt ein Projektmanagement-Tool, wo man Boards bauen kann, Kanbuns bauen kann.

So ein bisschen wie Trello, wenn ihr das vielleicht kennt oder so.

Wobei, ich würde sagen, also wenn man irgendwie Jira hat sich das Beileid, wäre es kein Jahr.

Ja, tatsächlich.

Ich war öfter mal das Missvergnügen, irgendwie da mich mit beschäftigen zu wissen.

Und das war immer, es ist da immer meistens eher Schmerz.

Es kann aber auch sein, dass es einfach, ich meine, es ist einfach viel Zeug und ich habe jetzt auch meistens nicht so viel Lust, mich wie ordentlich haben, mit Projektmanagement Software zu beschäftigen.

Daher, vielleicht lag es auch einfach daran, dass ich da nie so wirklich durchgeschaut 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 es sein.

Vielleicht ist es auch einfach ein furchtbares Tool.

Kann sein.

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, ähm, wie hieß das, Bitwacket gemacht haben und so, die sich jetzt aber eher so in die Projektmanagement-Software begeben haben, was wahrscheinlich einen Schauerschacht super.

Und auf der anderen Seite Trello, genau.

Das eigentlich von den Leuten, die auch Stack Overflow gemacht haben, irgendwie mal gegründet worden, aber ja 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 komplexen Enterprise bis zu, naja, relativ einfach und schlank und leicht zu bedienen.

Auf der anderen Seite, dazwischen gibt es aber von Atlassian jetzt nichts.

Und da ist, glaube ich, oder da positioniert sich Taiga selber, als ist ein bisschen, hat ein bisschen mehr Features als Trello, aber ist 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, 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 freie Software.

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 eigentlich ganz gut.

Seine eigenen Boards bauen, seine eigenen Trelleboards 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, genau.

Also Scrum macht das Ding oder man macht halt, kann halt auch, irgendwie kann man damit machen.

Ja, und kann man sich ja mal anschauen, ist eigentlich ganz nett.

Ja, was hatten wir noch?

Ja, wir wollten eigentlich noch ganz kurz auf die Frage von Arnim eingehen, der hat uns eine E-Mail geschickt hatte.

Oh, das haben wir auch verschludert, irgendwie das Ding.

Ja, das ist 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.

Aber das wird noch ein bisschen dauern.

Und deswegen, Sophie, ja, was meinst du denn überhaupt damit Arnim?

Also vielleicht nochmal irgendwelche Fragen, es gibt irgendwie da nicht so ganz klar, welche Methode.

Ich dachte, ich wüsste, was das 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 matt-matt gibt.

Das Ding macht, sozusagen guckt halt, ob, das 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 guck, ob die Tests brechen oder nicht.

Und wenn dein Tod zufällig verändert werden kann, ohne dass dann Tests sprechen, dann weißt du halt, okay, hast du ein Problem.

Und ja, 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.

Also ich habe dann noch, also Leute benutzen den Begriff gerne als sozusagen Gegenbegriff zu Test-driven Development, ja, sozusagen, also 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 superschlaue Idee ist, sondern dass man das vielleicht dann gleich richtig machen kann.

Wobei, naja, ich meine, ich würde auch dieses Test-Driven Development Cool 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 halbwicher sein, was das Ding eigentlich machen soll, bevor man das tut.

Aber ja, es ist auf jeden Fall Tests schreiben ist eine gute Idee und sozusagen sich nicht von den Fehlern, die User an Reporten, die quasi die Tests als Tests zu benutzen, ist wahrscheinlich eine ganz, ganz schlaue Idee.

Aber wie gesagt, ich weiß nicht wieder, was gemeint war.

Insofern nochmal nachpacken.

Und wir machen auf jeden Fall nochmal eine Folge zu Testing.

Wir müssen uns nur noch jemanden finden, der irgendwie Lust hat, damit uns zu überzureden und so.

Test ist nämlich immer das spannendste Thema von allen.

Ja, was nochmal, es ist natürlich auch schon fast ein Monat her jetzt.

Wir haben ja schon Juli.

Es gab eine Folge über 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 TalkPython to me.

Ja, ja, ja.

Das war irgendwie der, glaube ich, der Chef von den Produktownern 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, was sie, wobei sie gar nicht so gerechnet 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 du mich angesteckt?

Ja.

War eine gute Idee.

Es ist tatsächlich auch ein Editoralisier.

Ich meine, es ist so eine.

Viele Leute mögen ja dieses Elektronen, diese, ist auch ein elektronbasierter Editor, insofern.

Ja, viele mögen das nicht so, aber es funktioniert ziemlich.

Also wenn ich das zum Beispiel vergleiche mit Pychar, Python verwende ich, habe ich 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 irgendwie.

Ja, irgendwie snappier.

Ich weiß nicht, was kommt man noch für andere.

Es gibt auch

ein paar Sachen, die funktionieren direkt.

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 angibt, die Latenz, bis dann was passiert, ist deutlich schneller als.

Vielleicht hast du ja noch ein Rechner gekauft inzwischen.

Nee, nee, daran liegt es nicht.

Und ja, das ist halt, also ja, ich weiß nicht, wie sie das, ich weiß auch nicht, vielleicht macht auch Python da irgendwas falsch, ich 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, weil es auch zum Beispiel funktioniert.

Mehr Link

und Multicursor und Übertragung und Gemeinden Terminal und mittlerweile, also in einem Nightly-Bild war das drin, ich glaube, das müsste mittlerweile so etwas von einem Stable sein, dass man jetzt auch über SSH einfach sich irgendwo auf eine Maschine legen kann und da im Verzeichnis entwickeln kann.

Das ist auch ziemlich praktisch.

Kannst du auf deine VSL-Maschine gehen oder auf den RESP-P oder auf eine anderen Serverfindung

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 Wim, 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 sage.

Aber genau, es ist natürlich ein gewisser Argument, aber geht mit VS-Code jetzt auch.

Braucht man gar nicht mehr unbedingt Wim verwenden.

Also falls noch jemand rausbekommen hat, wie man sowas wie Foxdot verwendet mit VS Code, das habe ich nämlich noch nicht hinbekommen, aber 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 ja direkt die eine Teile, dann kann man Musik machen mit Foxdot für Python.

Das finde ich noch super, sonst muss ich dann mich irgendwie dran basteln, aber ja, so viel.

Ja, wenig Zeit für so viele Projekte, ja.

Du hattest irgendwas noch reingeschrieben.

PySimple.

PySimple GUI, ja, da gibt es jetzt irgendwie eine einigermaßen vernünftige Version, die 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 T Kinta, 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 auch mal kurz rauszuschauen.

Genau, jetzt hast du mir meinen Woche schon fast geknaut.

Achso, sorry.

Ja, ja, ich will einfach dann nehmen.

Oh, ein Podcast, den ich da auch noch gerne noch erwähnen würde, ist auch eine der letzten Django-Chat-Folgen mit Simon Willison.

Also einem der Leute, die auch Django quasi so mit außer Taufe gehoben haben.

Ziemlich etwas ist also mit, vielleicht, das war Audioqualität manchmal so ein bisschen, aber ansonsten inhaltlich fand ich das sehr, sehr gut.

Das war 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, das halt gerade irgendwie, ja, so momentan spielt, Async-Geschichten spielen dann eine große Rolle.

Die sind gerade ja sehr spannend oder sein Privat- oder sein Pet-Projekt, was aber jetzt auch mittlerweile so groß geworden ist, dass

Pet oder Pad, was Tiere.

Ja, ja, so ein Nebenprojekt halt, aber es ist nicht mehr wirklich so neben, sondern er hat er irgendwie auch eine.

Das Python Halsband für die Katze, oder?

Nee, ja, also er hat da irgendwie eine, irgendeine 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 ist schon mal, also daher geht auch die Entwicklung damit halt relativ schnell voran.

Das Projekt heißt Dataset.

Ach so.

Genau, damit das ist mir auch früher schon mal aufgefallen, hatte ich bestimmt auch schon mal ein paar Mal erwähnt oder so.

Darf ich

schon mal drüber gestolpert, ja?

Ja, genau.

Werde ich mich, darüber können wir bestimmt auch nochmal eine eigene Sendung machen.

Ich wollte mich damit auch noch intensiver beschäftigen.

Das ist eigentlich eine sehr coole Idee, irgendwie, wie man mit einer SQL-Lite-Datenbank halt Data, also Datensätze irgendwie verfügbar machen kann, öffentlich, ohne, und zwar auf eine Art, wie man halt sehr, sehr gut das abfragen kann, aber ohne, also man kann ja SQL-Stations 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, aber einfach gut.

Und normalerweise ist alles Pui Bell, weil schrecklich, schrecklich SQL-Injection droht und so, aber mit, wenn man, man kann SQL SQLite so starten, dass man sagt, irgendwie, ja, das ist dann Datenbank-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.

Okay.

Das ist, ja, es ist einfach, es ist nett.

Es hat viele überraschende Wendungen, dieses Ding, wo man sich denkt, so, ach cool, das geht und das kann man so machen.

Ja, die Tastette-Folge müssen wir nochmal aufschreiben.

Die steht nämlich kann ich noch.

Ja, ja, die muss dann noch, die muss da mit drauf.

Genau.

Das war, also diese Podcast-Episode kann ich Leuten durchaus für Django zu interessieren, ins Herz legen, ist ja sehr nett.

Ja, ich würde sagen, jetzt haben wir aber die News-Sail durch und machen den nächsten Chaptermarkt, weil so langsam löchere ich dich jetzt damit, wie das denn jetzt überhaupt funktioniert mit dem Server.

Und wir fangen wirklich von ganz Basisbodensatz an.

Also so gar keine Ahnung, wie macht ihr das und so und wo.

Und ja, ich möchte mich auch wissen, wie man das am besten macht.

So Best Practice, was sagt denn Jochen dazu?

Und ja, würde ich sagen, können wir starten jetzt mit unserem Hauptthema, ne?

Server.

Dann starten wir da mal.

Server, die Plannung 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, wie nehme ich denn da?

Also für was mache ich denn da für einen Server?

Nämlich irgendeinen Hosting-Anbieter, Cloud, dedizierten Server, virtuellen Server, warum und so.

Ich mache ja noch irgendwie jetzt eine Domain und so, ne?

Wie wird es denn 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 dir in eine Stelle.

Ja, nee, da gibt es ganz viele Anbieter, ich weiß nicht ganz.

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, aber es gibt ja verschiedenste Server-Oster, 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 also ich kenne das auch, dass viele, also so gerade, weiß ich nicht, eben diese Welt, Wald und Wiesen.

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 es gibt diverse Records, die man unter Umständen einstellen können möchte.

Was ist ein Rekord?

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 zusammen, wenn man irgendwie den Name-Server irgendwie fragt, keine Ahnung, der einzige, der jetzt wahrscheinlich bekannt ist, ist irgendwie der von Google mit den vier Achten oder sowas.

Oder 844 oder was und dann gibt es ja aber 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.

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 Python-Podcast.de hätte, dann würde man erstmal gucken, okay, also was man wissen muss ist, man braucht irgendwie so einen Root-Names-Ever, aber wenn er eine IP von dem hat, dann kann man ihn halt fragen, okay, was ist denn der Name-Server, der zuständig ist für die .de-Zone.

Der Root-Names-Ever, das sind die großen Knotenpunkte.

Ja.

Kriege ich das irgendwie raus, wenn ich so einen Trace-Route mache, wo die irgendwie hängen?

Ja, die sind weltweit verteilt.

Da gibt es ein paar von.

Root-Servers.net, irgendwie A.rootServers.net und ein paar, also ich weiß es gar nicht mehr genau, alles schon altes Wissen, vielleicht ist es auch mittlerweile alles anders.

Aber es ist, also auf der ganzen Welt sind halt so 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 ja, 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 Name-Server, also über sogenannte eben die Records, also NS-Records sind halt die Records, die zuständig sind, einem zu sagen, was denn der Name-Server zuständige Name-Server ist.

Also ich frage halt quasi den NS-Record für Punkt D, den Root-Server, und dann kriege ich halt irgendwie den Names-Server, der zuständig ist für die DE-Zone.

Und das ist halt, na, wie heißen sie noch?

Hier, äh, äh, Denik.

Ah ja.

Betracht irgendwo Frankfurt steht, glaube ich.

Und die haben dann das DE-Sohn-File irgendwie drin und da steht dann halt drin, wer, also in dem File steht vor allen Dingen die NS-Rekords für alle DE-Domains.

Wenn ich jetzt wissen will, wer ist welcher Nameserver ist dann zuständig für Python-Podcast.de, dann hole ich mir eben den NS-Rekord für Python-Podcast in dem Names-Server, der für .de zuständig ist und dann kriege ich das irgendwie zurück.

Und ich dann auch irgendwie selber machen, dass ich sage so, hey, hier, ich heiße jetzt gerne Dominik meinPython.com oder sowas oder die, wir wollen jetzt nur Denik.

Und dann sage ich der Denik so, hey, hier, ich wäre es gerne so, ist das noch frei?

Und schicke das dann da irgendwie da bei den Liste.

Das geht nicht unbedingt so einfach.

Das heißt, ich musste ein Registrier, Registrar verwenden.

Ja, also früher ging das auch, da hat man einfach, ist man da vorbeigegangen beim DNI, hat er die Tür gekopf und gesagt, hallo.

Ich hatte mal sogar eine Domain.

Das ging, aber das ging nicht schon lange nicht mehr.

Kamen so viele Leute wahrscheinlich auf diese Idee, ja.

Ja, das geht schon lange nicht mehr.

Aber genau, man braucht.

Aber Gandhi macht das dann zum Beispiel, wenn ich jetzt bei den Karte mache.

Ja, aber es gibt ganz viele unterschiedliche.

Also ich weiß gar nicht, ob es da, ich weiß nicht, ob das, was ich da für eine 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 es 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.

Eigentlich braucht man noch für viele andere Dinge.

Wenn man in die Web machen will, braucht man auch einen eigenen Domain.

Das braucht man 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 jetzt tatsächlich einen Eigencomputer, der mit Kern festkommt.

Oh, oh, das ist mein Job schon vergessen.

Ich war mit dem Auflösung nicht fertig.

Also wenn man jetzt den NS-Rekord von einer Domain hat, das heißt noch nicht, dann muss man den Names aber noch fragen, was ist denn jetzt zum Beispiel der A-Rekord?

Das ist halt das, was halt die IP einem gibt für eine bestimmte Domain.

Ja, es gibt auch noch andere, es gibt MX-Rekords, die halt einem sagen, wo die wer zuständig ist für Mail, oder es gibt halt, ja, es gibt ja eine ganze Menge Zeugs, es gibt Text, es gibt doch Textrecords 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 maintain, 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 mehr oder weniger unter der Domain auftreten können.

Das würde ich auf jeden Fall auch machen.

Ich möchte ja keine ganzen Projekte unter unterschiedlichen Domains, die ich mir dann irgendwie buche, vielleicht auf einen größeren Server legen und die dann irgendwie da reinrouten oder.

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 und dann gibt es so diese komischen DNS-Amplification-Angriffe und blöde Geschichten und so Zeugs, mit denen man zu tun kriegt.

Ja, aber also 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.

So, ich glaube, damit sind wir aber mit DNS im Grunde durch.

Ja, das können wir ja endlich auf einen Server.

Jetzt haben wir so einen Server, der hat dann irgendwie so ein IP, ne?

Dann wissen noch gar nicht, was wir 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.

Es gibt sogar was für die Dünn-DNS, das heißt, wir könnten sogar zu Hause einfach einen Rechner ans Netz hängen oder so, wenn wir einen

Namen haben und dann.

Dann musst du dann den Name-Server selber betreiben, irgendwie wahrscheinlich.

Ich glaube, es gibt so einen Service, da muss man immer nur den mal sagen, hey, ich bin jetzt hier, ich bin jetzt hier, ich bin jetzt hier irgendwie so.

Ja, ja klar.

Es gibt auch in vielen Routern ist das eingebaut, zum Beispiel eine Fritzbox macht das.

Dem kann man einfach, da kann man einfach sagen, so, das ist mein Dünn DNS-Anbieter und dann kriegt man halt immer eine entsprechende, dann macht die das automatisch.

Dass sie halt immer, wenn man sich die IP-Adresse ändert, dann schickt die halt irgendwie einen Request dahin und sagt, okay, äh.

Findest du mich hier, hallo?

Genau, und dann kann man auch seinen Kram zu Hause immer erreichen.

Wobei man da wahrscheinlich eigentlich eher sowas wie ein VPN verwenden will, aber den DNS geht auch.

Aber ist eigentlich heutzutage alles nicht mehr so richtig relevant, glaube ich.

Ja, genau, also wenn man DNS unter Kontrolle hat, dann kann man halt jetzt, wenn man das.

Wenn man jetzt einen Server hätte irgendwo, der unter einer IP verfügbar ist, dann kann man sozusagen die Domain 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 200 bis, weiß ich nicht, wahrscheinlich 200, 2000 Euro im Jahr.

Ja, das kommt darauf an.

Also was man damit vorhat, für die meisten Leute wird irgendwie da weniger, wahrscheinlich eher mehr sein, also wird wenig reichen, weil.

Ja, es gibt ja auch so WordPress-Hosting-Anbieter oder sowas, da kann man wahrscheinlich nichts anderes machen aus dem WordPress-Blog drauf hosten, der auch schon ziemlich viel kann, wenn man jetzt nicht so viele Besucher hat, aber.

Ja, ist aber nicht das, was man wahrscheinlich haben will.

Wenn man jetzt Python macht oder so, da möchte man das eigentlich schon selber tun können.

Also es gibt auch eben für Python-Hosting nicht so viele Anbieter, die da.

Macht das denn jetzt Python-Hosting, weil ich dachte, genau gibt es einen Computer.

Genau, ja.

Das ist halt, also bei WordPress ist ja klar, es 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 einen CMS haben will unter einer Domain, da gibt es da auch Anbieter.

Die Ego, Diego, Diego, ich weiß es nicht mehr, wir müssen nachgucken.

Die bieten an, dass man irgendwie einen Wagtail CMS oder halt einen Django CMS, CMS bekommt, da gehostet und das ist dann so ähnlich wie WordPress-Hosting.

Okay, das läuft dann auch einen virtuellen Container irgendwo.

Das, nee, das, ja, das weiß ich, das weiß ich nicht, ob die da extra Container pro Seite hochfahren.

Ich denke nicht.

Also wenn man sich zum Beispiel, also wenn man sich anguckt, was da die User sind, die man teilweise, wenn man manchen Feldern versucht, irgendwas einzugeben, dann kommt da eine Liste der User hoch oder so.

Da kommt ein ziemlich wildes Zeug hoch.

Das heißt, ich gehe mal davon aus, dass es nicht irgendwie pro Domain oder so gekapselt, sondern dass es 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.

Das ist 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 ein PHP-Umfeld oder WordPress oder so, das ist halt, wo es eine große Geschichte ist.

Was 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 so, die heißen alle so Platform as a Service-Anbieter sich anguckt.

Also ganz oben wäre sowas wie eben, du kriegst halt, du klickst halt irgendwie dein Wactail-CMS und hast dann halt ein fertiges CMS unter deiner Domain.

Das wäre halt sozusagen alles

am besten noch mit Admin-Interface und unten.

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 fertiges, äh fertige Webseite sozusagen, schlüsselfertig, sondern du kannst.

Das ist eine fertige Webseite, schön, ja.

Du kriegst halt irgendwie du hast halt einen Account bei Heroku oder sowas.

Anbieter werden das sowas wie Heroku oder Python Anywhere oder so.

Und da.

Ich finde den Vergleich mit diesen Häusern habe ich toll.

Wir müssen ein Hochhaus hinstellen und eine Gartenhütte.

Ja, also sagen wir 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 irgendwie mal einmal.

Du musst in das Lobby.

Es ist quasi so eine Art Hotel.

Obwohl ich weiß nicht, ob diese Analogie trägt.

Also wenn Software as a Service, also wenn du diesen.

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 und.

Ich würde sagen, das ist doch eigentlich eher das Hotel, oder?

Wo man halt sich um nichts kümmern muss.

Und Heroku ist die Ferienwohnung, wo du selber kostet.

Ja, und Heroku ist so ein bisschen die, es ist eher so nicht mal das, es ist eher so der Schuhkarton-Eigentumswohnung irgendwo, so ist ja der Container halt.

Oder es ist halt 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, ja, 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 dazu klicken kann, Suchmaschinen oder irgendwelche anderen Sachen, die man halt auch verwenden kann.

Und das muss man alles nicht selber machen, bei Heruku 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 Dumbo beispielsweise die ganzen Modelle halt irgendwie definiert und die werden dann halt auch in der Postgres irgendwie angelegt, aber man betreibt die Postgres-Datenbank nicht mehr selber, sondern das macht dann wieder 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 das ist ja auch sowas, ne?

Wenn man.

Das klingt nicht nach einem gelungenen Experiment.

Ja, für Django Cast jetzt diese, wollte ich einfach mal so, wie ist das denn, wenn man das jetzt auf Hiroku 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 Wohnat 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, ja?

Ja, dann wäre es doch ganz praktisch, wenn man das einfach nach Hiroku oder so deployt und dann mal guckt, wie das so funktioniert.

Da ist das eigentlich ganz nett.

Und zumal halt all diese Anbieter alle so freie Container anbieten, die so für Hobby-Benutzung oder so, die halt nichts kosten, die ja dann auch bestimmte Anforderungen nicht erfüllen, beziehungsweise sind 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 ABS oder so, wer weiß.

Ja, genau, aber das ist das dann ja schon wieder, aber bleiben wir weiter.

Gleich noch auf.

Also da kann es sein, dass der Container erst gestartet wird, wenn man, wenn 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 mich dran 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 Heruke da keine gute Anleitung für hat.

Wie macht man das eigentlich?

Nun machen die nicht nur Python, die machen auch Ruby und Rails und auch NoteJazz und weißer Teufel, aber trotzdem, es ist schon irgendwie, es war schwerer, als ich dachte.

Und ich dachte mir so, ui, also hm.

Wenn der Jemand nachhin knapp hat, dann weiß ich jetzt nicht, ob ich jetzt anfinge,

unbedingt mich da so reinstürzen müsste in diesem Weg.

Ich meine, auch dieses Django for Professionals Buch, kann man sich auch mal angucken, auch der, auch wohl Vincent meinte schon so, das ist alles irgendwie mal, 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 hatte irgendwie halbe Schlagzeite, man weiß es nicht genau.

Ja, also, 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, also es mag aber auch 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 keine Probleme mit Let's Encrypt und so.

Aber für die Hobby-Seite bei Heroku, bei denen, funktioniert das nicht.

Und das hat mich, es hat mir, es ist mir nicht leicht gefallen, rauszukriegen, dass es wirklich nicht funktioniert.

Und ich musste da tiefgraben und ich bin in irgendwelchen Issues gelandet, wo dann einer der Entwickler bei Heroku dann irgendwie schrieben, sollten wir vielleicht mal in die Dokumentation schreiben, dass das wirklich nicht geht.

Also auch mit diesem Weg geht es nicht.

Und da dachte ich schon so, ja, solltet ihr vielleicht, weil irgendwie, ich habe jetzt gerade da irgendwie ganz schön Zeit reingesteckt, das rauszukommen, 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 erstmal lokal irgendwie Satbot installiert oder irgendwie auch rumgeeiert und ja, aber es ging dann alles am Schluss nicht.

Also SSL HTTPS, Heroku nur, wenn man es hat, sonst geht's nicht.

Und ja, auch die, wenn man jetzt irgendwie einen CDN verwendet oder so, äh, Content

Elivery Network, ja, da müssen wir auch nochmal gleich noch Cloud bauen und ja, hat es und alles noch dazu.

Ist alles

anfängerfreundliche Folgejochen.

Ja, ist alles nicht so nicht so einfach.

Auf jeden Fall, man, 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, kommt man mit Heroku wahrscheinlich schon halbwegs schnell da irgendwie zum Ziel, ob Python Annivers eine andere Alternative, 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.

Oder 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 euch 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 Gedückung, wir sind ausgeschlossen, ja.

Für dich jetzt nicht, aber ich denke schon, dass es für viele, aber es gibt, was auch oft eine Falle ist, dann, wenn Startups irgendwie anfangen mit sowas, dass sie dann irgendwann doch viele Datenbank-Querys 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 um.

Die Infrastruktur komplett umfassen.

Ja, ja, und dann gibt man halt ein Vermögen.

Dann gibt man Arm und ein Bein an diese Anbieter.

Tja.

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.

Jetzt müssen wir aber nochmal ganz kurz, bevor wir das alles wieder vergessen haben, kurz eingehend auf Content TV Network, du musst auf Dividual Ocean nochmal kurz erklären und AWS Lambda-Funktion, wo hast du gesagt?

Also wenn wir jetzt bei S3, wir sind jetzt bei Stagunter Software as a Service, Platform as a Service.

So jetzt wären wir 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 Amazon Easy2, DigitalOcean.

Also da bekommt man im Grunde 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 halt 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.

Fedora, Ubuntu, Debian.

Spielt im Grunde keine große Rolle, würde ich jetzt mal so sagen.

Also ich.

Ne.

Nee, das System Python kann man in keinem von den Fällen verwenden.

Daher.

Ist egal.

Muss man eh immer neu installieren oder selber installieren.

Hat Fedora jetzt nicht drei standardmäßig alles schon drin

oder so.

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 Python.

Das ist keinen 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 System D mag oder nicht.

Weil, genau, wenn man das mag, dann kann man das ja benutzen und da gibt es halt Unterschiede, je nachdem, welche Disperson man verwendet.

System D nimmt aber auch dann sowas wie Logging ab oder sowas, das mag man vielleicht nicht.

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 System D auch machen.

Man kann auch irgendwas anderes nehmen.

Ich nehme Supervised D, aber im Grunde ist das so.

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 also manchmal so.

Ja, ich hatte da irgendwie eine ganz spannende Folge dazu nochmal gehört, irgendwann die war in irgendeinem Chaos Radio Express mit einem von den Developern da.

Das war schon ein bisschen hier.

Ja, äh, na, ja, ist er noch?

Namensgericht, keine Ahnung.

Ja, genau.

Ja.

Okay, also völlig egal, welches System, also ich haue mir da einen Fedora und Ubuntu drauf zum Beispiel, weil ich das so ein bisschen schon kenne oder so.

Dann irgendwie mit den Repos schon ein bisschen weiß, wo ich meine Pakete finde und dann ist er to oder warum sollte ich das tun?

Warum nicht direkt einen eigenen Server?

Ja, genau, weil halt auch da dir das natürlich abgenommen wird, dass du dafür sorgen musst, dass das Ding ordentlich läuft oder so.

Ja, du musst dich um viele Dinge nicht kümmern, die du sonst tun müsstest.

Titabieren?

Ja, dieses ganze, also was alles, was mit irgendwie Netzwerk zu tun hat.

Stecker reinstecken, Strom.

Genau, dass das Ding immer oben bleibt, irgendwie Betriebssystemupdates, weiß ich gar nicht noch nicht, stimmt.

Das muss man wahrscheinlich dann noch selber machen.

Ja, das war ich genau.

Die Frage.

Managed Server, glaube ich, heißt das

oder sowas.

Ja, das will man alles wahrscheinlich ehrlich, 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 jeder Container wie der andere und es funktioniert einfach so, ne?

Und dann, also das ist schon, das ist schon auch nett, aber man zahlt dafür natürlich auch einen Preis, es ist halt schon teurer, als wenn man jetzt und dann es gibt nochmal so super billige Geschichten auch immer, also die, ich glaube die kleinsten Container, wenn die durchlaufen sollen, die kosten dann irgendwie ein paar zehn Euro im Monat oder sowas, 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, einen Container kriegt und bei Digital Ocean gibt es das auch.

Und selbst bei sowas wie so einem Hostelby 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 Rout einloggen kann, ist schon natürlich ganz nett.

Das will man wahrscheinlich sogar auch cool.

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, also so eine Testinstallation.

Wann braucht man denn eine fette Datenbank?

Also so jetzt als Datenmensch müsst ihr ja wissen, ab wie viel Traffic man ja so irgendwie.

Nee, das hat mit dem Traffic gar nicht so viel zu tun, sondern eher viel 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.

So doppelt so viel oder so.

Also ungefähr doppelt so groß wie mein Data-Set, 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 da muss es halt irgendwie, wenn die alle vier Hauptspeicher verbrauchen, ist halt natürlich irgendwie der Hauptspeicher weg.

Und wie kompliziert wäre es denn jetzt da, weiß nicht, wenn man jetzt mehrere kleine Services auf so einem Ding laufen lässt, das 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 einem dieser Cloud-Dinger einen Docker bauen, installieren oder.

Docker installieren, Docker-Niemen starten und dann halt mit so einem Docker-Compose-File das komplette System hochziehen.

So dass dann halt für jeden Service, den man benutzen möchte im System, dass man da hochfährt, dass man dafür einen Container hat.

Also man hat einen Container für die Datenbank, man hat einen Container in den Redersystem.

Man hört sich dann genau die Dinger auf.

Also kann man Docker so einstellen, dass der für alle verschiedene Systeme unterschiedliche Hardware nimmt?

Ja, das kannst du natürlich auch tun, aber das würde ich am Anfang auch nicht machen.

Nee, 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.

Aber Kubernetes ist eine Krake an Docker-Containern.

Ja, da das ist so ein bisschen das Problem mit Docker ist halt, dass der, 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.

Das, also würde ich jetzt mal einfach so sagen, brauchst du nicht.

Ja, also ich habe da bestimmte Voraussetzung tatsächlich, also ich möchte so verschiedene Webseiten betreiben, irgendwie, ne, irgendwie private Sachen.

Dann hatten wir mal über Iniveb besprochen, dann irgendwie sind die beiden Service da drauf und dann vielleicht noch irgendwie eine Firmenwebseite mit einem Login und vielleicht noch für IoT so ein bisschen, so ein Server, der da irgendwie läuft und das da irgendwie alles gerne parallel und

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 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 ja mehr so umziehen, alles normal machen?

Nee, musst du nicht.

Das ist ja da, dafür hast du ja eine Domain-registriert.

Ja, aber den Server muss ich ja umziehen, also die ganzen Sachen muss ich ja nochmal konfigurieren.

Ja, aber dann nee, da 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.

Sagst du einfach auf dem anderen System, Docker Compose, deinen Docker-Yammel-File, ab, fertig.

Nicht mal das, du, 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 Supervise-D.

Normalerweise die Konfiguration dafür legst du auch in dein Projektverzeichnis mit rein.

Linkst das nur noch nach etc supervised.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 machen.

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 war's.

Stop shop.

Ist es in dieses Config?

Also ich muss da irgendwas rein, ist die Reihenfolge entscheidend, wie das da drin hängen, weil die dann nacheinander gelaufen?

Wie verteilt er die Ressourcen und verteilt er einfach so wie viele er hat?

Ja, also gut, das ist nochmal ein anderes Thema.

Ist ein Loadbalancer, was?

Wir sind zu weit, wir sind zu weit.

Okay.

Wir müssen nochmal zurück.

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.

Wagrant.

Ja, man könnte auf Wagrand benutzen, aber das ist auch, 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 performance-technisch sehr fies.

Also in einem Container nochmal Containergeschichte zu starten, ist vielleicht auch nicht so die schlauste Idee performance-technisch, 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 aufbauen.

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.

Du kannst halt zum Beispiel so, auch das benutzt man eher für größere Infrastrukturen, um da halt ein komplettes System auszurollen.

Das ist eigentlich so Automatisierung deiner Automatisierung deiner Infrastruktur hochziehens, so damit sowas wie Ensible oder so.

Oder es gibt auch noch diverse andere, es gibt Solstack, es gibt irgendwie Puppet-Chef.

Aber Ensibel 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 connectest du sich auf all die Systeme per SSH und mach dann magisch Dinge, sodass dann da die Services laufen, die da laufen sollen und so.

Irgendwie sowas braucht man auch, wenn man Vagrant verwenden wollte, weil du musst ja die Services dann irgendwie in deiner Vagrant, in deiner virtuellen Maschine halt auch zum Laufen kriegen.

Das heißt, du musst da irgendwie die entsprechenden Pakete installieren, du musst ja 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 Wagrand hochzuziehen, kann sein, dass das, selbst wenn du einen schnellen Rechner hast, lokal, kann sein, dass das 20 Minuten dauert.

Wenn du viele Maschinen hochfallen hast oder so.

Kannst du 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 so und ach, ja.

Also, und das ist halt einfach oft zu langsam.

Wenn jetzt, wenn du zum Beispiel irgendwas, du versuchst, irgendeine Funktion hinzukriegen, musst dafür irgendeine Bibliothek installieren, die das halt kann, einen Python-Dreiber drumherum, der da irgendwas mit macht.

Und du willst halt so schnell iterieren können.

Du willst halt schnell irgendwas ausprobieren, geht nicht nochmal.

So, und bei Docker dauert so ein Bild für, weiß ich jetzt ein.

CPU-Power.

Je nachdem, wie viel CPU-Power und Platten und Lets man hat, aber so bei mir dauert das, ich habe, also Standard-Django-Projekt hat bei mir irgendwie die Datenbank, Redis, irgendwie Applikations-Server-Django, vielleicht noch Salary 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 sozusagen, wenn man jetzt irgendwie auf Betriebssystemlevel irgendeine Bibliothek braucht oder so, die vorher nicht da war, dann muss man die Docker-File, muss man die Container neu bauen.

Und das dauert bei mir so zwei bis drei Minuten.

Lokal.

Ja, in der größer der Anwendung natürlich.

Ja, in der größer der Anwendung, aber das ist die Anwendung selber, die Jungle-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 per 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 man macht da irgendwas anderes.

Und man muss aber möglicherweise zehnmal was anderes ausprobieren, weil oft muss man, bleibt einem nichts übrig, als Sachen auszuprobieren, ob es jetzt so geht und dann, ach scheiße, der Python-Rapper funktioniert nicht, muss einen anderen nehmen, guck mir den nochmal aus.

So, und dann, wenn du da zehnmal irgendwas ausprobieren möchtest und du hast immer eine 20 Minuten Latenz dazwischen ist, das macht allen langsam.

Du hast gerade gesagt, zu dem Stack von dir gehört noch eine Read, ist das ein Cache, ja, damit man irgendwie 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, nein.

Nein, nein, nein.

Nein.

Okay.

Nee.

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, die irgendwas lange berechnet oder so, dann ist es fertig ist, dann schreibe ich darüber irgendwie Cache-Property oder so zum Beispiel in Django, um zu sagen, um Django zu sagen, cache das hier mal bitte, weil das, ich will das nicht jedes Mal, wenn diese Property jemand, wenn jemand darauf zugreift, möchte ich nicht, dass es jedes Mal neu berechnet wird, weil 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 der Cache von meiner 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 Applikationswagen.

Da würde ich einen Barnisch 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 gehen oder so, die da durchgehen, halt in-Memory cachen.

Oder überhaupt alles, was an statischen Assets drin ist, oder auch andere Sachen auch überhaupt alle Dinge, die identifizierbar sind als cachbar über die Cacheheader.

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, da muss man diesen Stack nochmal komplett durch.

Also das, was davor ist, und das ist auch etwas, was leider nicht in den Docker-Geschichten selber mit.

Also sagen wir so, wenn man jetzt Cookie Cutter verwendet, um ein Django-Projekt zu erzeugen, dann ist der Caddy schon mit drin, als 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 Root einloggt.

Weil, wenn man da jetzt zum Beispiel mehrere Domains hat, die man beliefern will.

Ja, die man da ausliefern will, dann muss der Caddy halt unabhängig von den einzelnen Systemen sein, sonst geht das halt nicht.

Was macht der Caddy denn jetzt?

Und wir hatten noch, im Salary hast du noch erwähnt, die musst du auch nochmal kurz.

Ja, also Caddy ist ein Go-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 Sartboard selber irgendwie verwenden muss.

Und also es ist so, ja, HTTPS funktioniert einfach magisch und 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 5000, macht für die allermeisten Leute überhaupt keinen Unterschied, weil sie haben nicht mal einen Request pro Sekunde da, ja, ist egal.

Drei, drei, vier.

Ja, aber selbst vor 100 ist es völlig wurscht.

Und ja, und das sein Google geschrieben ist, macht vielleicht das Ganze auch noch ein bisschen vertrauenswürdiger, als wenn ich meine Nginx C und so.

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 ja, der ist sozusagen vor den, vor Django davor.

Halt eben um sowas wie Statisch Files auszuliefern, weil das kann halt Django nicht so gut selber.

Wobei muss man auch einschränken und sagen, ah, mit White Noise ist das vielleicht nicht mehr so ganz aktuell, aber.

Was ist White Noise?

Oh Gott.

Das ist ein Django.

Auf jeden Fall innerhalb von Django kann man das als Third-Party-App installieren.

Und das liefert dann Files, also wenn man normalerweise einfach so einen 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 Applikationsserver verwendet.

Unicorn, Micro-Whisky oder Mi-Wisky oder U-WSGI oder so, also das ist alles dergleiche, ich weiß nur nicht, wie er ausgesprochen wird.

Man muss ja irgendeinen Applikationsserver 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, was man nicht haben will.

Und wenn man, 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 Hauptspeicher kopiert, dann durch den User, also vom Kernel-Space in den User-Space dann wieder zurückgeschiebt, um das auszuliefern, sondern der verwendet halt einen Kernel, einen syscall-Send-File, um die Files halt rauszu, sagt halt dem Kernel nur irgendwie hier, dieses File, diese Verbindung bitte sehr, liefere

aus.

So dass 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 Hautspeicher, sondern gehen direkt per Zero-Copy TCP irgendwie in den Netzwerkwaffer der Karte oder so von den Platten aus und so.

Also gibt es crazy Shit-Optimierungskrams, der da gemacht wird.

Bin ich jetzt auch nicht mehr so auf der Höhe, der ist halt wasser als momentan aktuell ist, aber es geht irgendwie eine Menge.

Und White Noise macht das, macht auch, verwendet auch Send-File.

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.

Wenn man viele kleine Bilder hat auf einer Webseite zum Beispiel, in einer Liste von irgendwelchen Dingen, wo halt immer Bilder dabei sind, dann ist halt jedes Bild macht halt einen Request.

Und im moderner Browser machen die ganzen Requests ja auch in parallel.

Das heißt, die prügeln halt dann auf deine Applikationsserver ein und das ist halt nicht so gut.

Und da was, was, ich mache es nicht so, aber was wohl gut ist, ist halt, man verwendet White Noise und dann da vorne irgendwie Warnish 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 Contentable Delivery Network oder halt Varnish oder so und dann ist es schnell.

Was ich mache, ich verwende meistens den Web-Server eben Caddy oder Nginx vorne dran zum Ausleben der statischen Assets.

Da gibt es halt einen Unterschied in Django, sondern so statische Geschichten, das ist sowas wie JavaScript, CSS.

Wir faffen dieser ganze Kram halt sozusagen, der zum Projekt halt dazugehört, aber jetzt sich im Grunde nicht ändert.

Das für ein Logo, was du immer schon eingebaut hast.

Ja, genau.

Also wenn man, die Sachen werden dann auch generiert, die Dateinamen, 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 unique Namen, sodass es halt man auch sagen kann, die werden für immer gecached, weil wenn es was Neues gibt, dann wird er eh ein anderer Name verwendet.

Ja, das ist halt, dieses Settling dieser 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 also ein bisschen anders gehandelt und statische Files sind bei mir, werden ausgeliefert vom Caddy.

Und alles, was User irgendwie an Content hochladen, landet in einem CDN, also landet in S3, in einem Bucket.

Und der wiederum wird dann ausgeliefert über, ich glaube, es ist CloudFront, das ist auch das CDN von Amazon.

So dass ich halt auch damit keinen Stress mehr habe, sondern 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 mit.

Das ist natürlich auch eine, ja genau, das skaliert dann auch quasi beliebig.

Traffic wird halt irgendwann teuer, da muss man nicht sagen.

Nee, das ist komische Behörde, die man ja auch versucht.

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 und dann fängt man irgendwann an zu bezahlen.

2 Euro pro Request.

Das ist nicht ganz so schlimm, aber es ist ja und wenn man das selber macht mit White Noise und so, kann man sich wirklicherweise sich da auch den Traffic sparen, das auch schnell ist.

Ja, gut, nee, wenn man CDN vorne ranfindet, auch nicht.

Wie auch immer.

Also genau, das ist ja.

Ja, das haben wir auf jeden Fall den Dango-Applikationsserver, der hast du gesagt, Unicorn, irgendwas laufen.

Geunicorn, ja, also ich würde sagen, wenn man eben nicht mehrere Seiten hostet, sondern dass eher 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 Geunicorn, denke ich, die bessere Wahl.

Ansonsten, wenn es komplizierter ist, dann gut, muss man vielleicht dieses Mi-WSGI-Ding nehmen.

UWSGI.

Das hat einen Haufen Einstellungen, die ja darauf optimiert sind, dass man, wenn man Hoser ist, selber und dann, ja, 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 ein Cookie-Cutter nimmt, ist JuniCorn dabei.

Ich würde sowieso empfehlen, das Cookie-Cutter Django Template zu verwenden, weil das macht eigentlich an der Stelle schon viel richtig.

Und ja, da kriegt man, da kommt man da, da muss man sich selber um diese.

Also Cookie Cutter ist sowas, das seine Projekte automatisch vorkonfiguriert deployt oder so.

Ne, das erzeugt das Projekt.

Das erzeugt das Projekt.

Also es hat halt quasi 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 Salary verwenden möchte oder nicht oder so oder welche Datenbank.

Salary hast du jetzt auch noch nicht, aber

arbeitende Bienen oder so.

Man hat oft die Geschichte, dass man nicht, dass man langlaufende Request, 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, oft nimmt man dann halt auch irgendwie anderen Codec oder so und in unterschiedliche Auflösungen, je nachdem, wo man das irgendwie anzeigen will.

Dann möchte man nicht, und diese Render-Jobs dauern halt, je nachdem, wie lang das Video ist, sehr, sehr lang.

Es lädt jemand ein Video, das eine Stunde lang ist, hoch, dann möchte er nicht, dass der Request, wenn das im Request selber läuft, 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 Webserver 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 jetzt.

Jetzt 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 Cedoc macht es einfach zu Arbeitsbienen loszuschicken, die dann halt die anderen Tasks an 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 diese, es gibt, also Salary ist im Grunde eine Task, ja, besteht aus einem Ding, was irgendwie die Worker koordiniert, dann eine Menge von Workern und halt einer Que, 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.

Das sind Prozesse, die laufen einfach irgendwie.

Wer am lautesten schreit, der wird dann halt als erstes bedient

oder was?

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 die nächsten und so weiter, bis halt keine Worker mehr da sind, die nichts zu tun haben.

Und dann warten die Sachen in der Que halt einfach.

Und die werden dann halt so in Mitterzeit abgearbeitet.

Und ja, dann hat das Ding auch noch so ein Webfront <unk> Flower, heißt das irgendwie mit dabei.

Da kann man sich angucken, was ist denn jetzt aus meinen Tasks geworden?

Haben die irgendwie Exceptions geworfen?

Gibt es da Tracebacks?

Sind die alle gut durchgelaufen?

Wie lange laufen die denn so zur Basisstatistiken?

Wie lange laufen die denn durchschnittlich?

Ja, und all solche Sachen.

Und also das, wenn es funktioniert, ist es eigentlich ganz gut.

Ja, kann man nichts sagen.

Es ist eigentlich eine solide Geschichte, es ist aber so manchmal, also Settery ist manchmal so ein bisschen scharfkantig, muss man.

Ich hatte auch schon, also wenn es nicht funktioniert, ist es nicht so geil, muss man sagen.

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 die, also zum Beispiel Redis ist dann so ein Stück 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 hab's noch nicht kaputt gekriegt, sozusagen.

Oder auch Postgres ist so ein Ding, das kriegst du nicht kaputt.

Salary hingegen, da installiert man irgendwie, da wechselt man irgendwie die Python Miner Version und dann geht gar nichts mehr.

Und alles kaputt.

Und das ist ja, oder man wechselt die Django-Version und nichts geht mehr.

Also es ist halt deutlich fragiler.

Es ist nicht so, dass man da, dass, also bei Salary habe 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 Salary daran hindert, das ist und das ist schon öfter passiert.

Also ja.

Man kann es halt oft nicht vermeiden, dann braucht man es halt und dann es gibt noch diverse andere Task-Queue-Geschichten.

Salary ist halt die verbreitetste für Django.

Vielleicht lohnt es sich auch die CD anzugucken.

Ich weiß es nicht genau.

Aber ja, also wenn man es nicht braucht, soll man es nicht unbedingt, also es ist nicht unbedingt eine Geschichte, die man aufgrund von reiner Freude, weil 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 tatsächlich jetzt nochmal so ein bisschen auf die ganz Basic-Sachen zurückkommen.

Also wie weiß ich denn jetzt, auf welche Route ich jetzt meinen Nebenserver zum Beispiel schicke, auf welches Verzeichnis ich denen verweise oder mache ich das überhaupt über Verzeichnis oder ich habe jetzt verschiedene Django-Apps laufen oder du hast ja gesagt, Unicorn ist nur eine, dann habe ich sonst ein Whisky und Whisky weiß dann, wo was liegt.

Junicon ist ein Applikationsserver, jetzt sagen wir mal, wenn du jetzt Cookie-Cutter verwendet hast und so, dann läuft dein System, läuft halt irgendwo intern in einem Docker-Container und sozusagen kann angesprochen werden aus dem Container heraus, den du da oder aus der Maschine heraus, auf der du dich angelockt hast, auf irgendeinem Port 5000 oder sowas, da läuft das Ding halt.

Nimm aber nur Requests an von innen.

Also sollte nicht von außen erreichbar sein.

Das heißt also, ich muss aber dann den Portcamp natürlich an und dann die Ports muss ich ja irgendwie auf meiner Maschine routen dann.

Nee.

Zu den Docker-Containern.

Nee.

Nein?

Wie?

Wo funktioniert

das denn?

Die sind nur lokal da.

Also 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, über Port 443 kommen die rein.

Und den Caddy muss ich konfigurieren.

Den musst du konfigurieren, du brauchst einen Config für, die ist aber relativ einfach.

Und da steht mehr oder weniger drin.

Irgendwie, wenn es an die Domain gehen soll, dann alles an den Applikations-Server.

Okay, aber dann.

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.

Nein, HTML-Routing im Tanken, nein?

Nein.

Nein.

Nein, da steht nur drin, auf welche Domain geht, also wahrscheinlich wieder vor.

Je nachdem, auf welche Domain der Request geht, auf welchen Applikations-Server soll das gehen.

Okay, also.

Insofern kann man auch sagen, das ist gewisserweise Routing, aber es ist Name-Routing.

Es ist sehr, sehr an.

Und HTML-Routing ist dasselbe verknüpft, weil halt das Name-Router ist.

Also es gibt, es gibt noch etwas, was sich URL-Routing nennt bei Django.

Ja, aber das ist aber innerhalb von Django da.

Aber ich kann ja verschiedene Projekte nehmen.

Ich könnte jetzt auch sagen, ich möchte jetzt einfach ein Verzeichnis serven, weiß ich nicht, war, www, irgendwas, was da früher gab oder so.

Einfach ein Verzeichnis mit einer Index, irgendwas noch bereits.

Das kannst du mit dem Caddy auch machen, klar.

Kann ich mit dem Caddy auch sagen, das Verzeichnis kommt auch dann unter dem Namen resolved, geroutet, rein.

Okay, das ist, also genau, das ist halt 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 mein Caddy konfigurieren.

Was mit E-Mail, wenn ich jetzt irgendwie E-Mail schicken will, auch Caddy?

Nee.

Da, äh.

Nee, nee, das ist wirklich nur ein Webserver.

Das würdest du in der Django-Applikation halt irgendwie machen und da kannst du es entweder selber tun, wenn du halt lokal einen Mail-Server laufen hast.

Nein, nein, was ich jetzt zum Beispiel 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?

Das ist eine Art von Rekord für DNS.

Ja.

Woran steht also, 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 jetzt beispielsweise eine G-Suite habe, ja, 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 Provider, bei meinem Name.

Nein, dann da, wo du deine Domain registrierst.

Ne, das mache ich.

An meinem Registrar sage ich dann.

Registrar ist, der hat eigentlich eine andere Aufgabe, es ist halt, der Name-Server macht das.

Aber der, wo du deine Domain registriert hast, der betreibt wahrscheinlich den Name-Server, wo dann dein 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 bzw.

Mail-Server, den halt irgendjemand verwendet halt, um Mail hinzusetzen.

Der macht dann ein MX-Lookup auf deine Domain, sieht halt A, die Mail so 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.

Okay.

Und wenn ich jetzt einen File-Server machen will, dann muss ich jetzt einfach wieder bei den Caddy routen, ob irgendein Verzeichnis ist.

Was ist ein File-Server?

Oder was meinst

du damit?

Vielleicht einfach ein File, ein Verzeichnis, das ich freigebe, wo ich dann herunterladen kann.

Einfach so Schreibe und Lese Zugriff.

Brauche ich dafür sowas wie altes FDP.

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 kenn es nur, wie man es jetzt Linux, wenn man Linux als Server betreiben will, dann heißt es irgendwie Samba ist seiner Server.

Aber sowas betreibst du halt nicht im Internet.

Warum?

Viel zu gefährlich.

Das ist und es macht auch so komische Sachen mit irgendwie Broadcast-Geschichten und so, das geht alles im Internet nicht.

Also zu gefährlichst du, aber es würde gehen.

Nee, geht auch nicht.

Ich glaube, das geht, ich glaube, es geht gar nicht.

Also was war denn ein FTP-Server, den hätte man aber einfach gemacht?

FTP-Server ja, aber FTP ist auch irgendwie.

Ja, also die, wie würde man sagen, die 70er haben angerufen und die 80er haben ihre Ware 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, hin- und hergeschoben, was man so brauchte.

Ja, da konnte man lustige Dinge machen.

Also das ist uralt.

Da gab es ja irgendwann die File-Shaming-Plattformen, Hoster, was gibt es denn heute?

Also einfach dann Cloud.

Ja, das macht man einfach nicht mehr, würde ich sagen.

Also es ist komplett weg, hat das einfach sowieso schon alles verfügbar.

Nee, das war, also wenn du Sachen hoch 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, irgendwie so, dass es dann halt aussieht, als hätte man das lokal im Dateisystem oder so.

Aber es ist alles heutzutage ist es eigentlich eher benutzt.

Aber 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 zehn Dateien, die ich immer runterziehe, die nicht wichtig sind, wo man nicht besonders viel kaputt machen kann, wenn da irgendwas auseinanderflächt.

Die Frage ist, was möchtest du machen?

Was möchtest du eigentlich haben?

Nur einfach so eine Pfeilablage, so eine Teilablage für, weiß ich nicht, fünf Fotos oder irgendwas.

Ich meine, Fotos weiß ich, gibt es auch andere Möglichkeiten, aber nur so.

Du willst irgendwie Verzeichnisse synchronen halt

eine Dropbox.

Ja, oder so einen kleinen Store für irgendwas, so mein virtueller USB-Stick.

Da gibt es, also würde ich eher sagen, also da gibt es, als fertig würde mir jetzt eigentlich nur einfallen, sowas wie OwnCloud oder OnCloud, oder ich weiß nicht.

Aber intern, was die wahrscheinlich alle machen, das machen wahrscheinlich solche, selbst wie, äh, oder wenn man jetzt Apple verwendet, würde ich sagen, ja, nimm halt einfach iCloud.

Also OwnCloud, was wir tun.

Oder iDrive.

Wenn du selber hosten willst, OnCloud wahrscheinlich.

Aber intern wird das auch nichts anderes machen.

Was macht das?

Es 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 Rechter läuft, die halt sich per iNotify oder sonst irgendwie oder die Notify, wie auch immer, sich benachrichtigen lässt, wenn halt irgendwie sich was an Verzeichnis ändert und dann synkt die das halt rüber.

Und umgekehrt halt genauso.

Deswegen brauchst du auch ein 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, selbst gehostete Geschichte dafür gibt.

Aber warum nicht irgendwie Dropbox oder sonst irgendwie?

Ja, nee, also ich weiter einfach nur jetzt so der private USB-Stick, den man kurz was hinterschieben kann, so von Gerät zu Gerät oder sowas, wo man einfach dann eine URL eingibt und dann kurz deinen Login und dann hat man das.

Das wäre irgendwie schon nett.

Ja.

Ich weiß es nicht.

Ich glaube, also ich meine, das Geräteübergreifend funktioniert, ist wahrscheinlich dann Google.

Du musst ja dann auch irgendwie auf die Telefone kommen, ne?

Wäre ja dann praktisch.

Und dann bist du eh entweder bei Apple oder bei Google.

Da kommst du ja selber gar nicht mit rauf.

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, das funktioniert als HTTPS mit Unterstützer, also kannst du nochmal vielleicht Unterschied kurz SSL, HTTPS, ist das dasselbe?

Naja, SSL ist eigentlich, glaube ich, veraltet.

Das eigentlich gar nicht mehr.

Es ist nur nur so, dass man halt davon redet, weil sonst irgendwie gewohnt ist.

Also mittlerweile ist, was man eigentlich verwendet, TLS.

Und ja, 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 einen Test von SSL-Labs, wo man dann überprüfen kann, ob die eigene Seite irgendwie den aktuellen Sicherheitsanforderungen irgendwie...

Muss man sich irgendwie ein Zertifikat sich irgendwo generieren?

Kann man das selber erzeugen?

Muss man das kaufen?

Da gibt es ja irgendwie so diverse Angebote.

Warum nimmt man die?

Warum nimmt man freies?

Geht das auch frei?

Also ich würde da gar nicht so super en detail drauf eingehen.

Also wenn man kann das kaufen, dann hat man unter Umständen so Vorteile wie, es wird in der Browserleiste grün angezeigt oder so, weil es irgendwie so ein Spezialdeal zwischen den Browserherstellern gibt.

Ich meine, das sieht auch komisch aus.

Ich weiß nicht mal, ob das jetzt vertrautenserweckender ist oder nicht, vielleicht der Leute denken, das ist übersaltsam aus.

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 sind halt schon ganz oft dadurch aufgefallen.

Dass es 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 ist das schon ein paar Mal passiert, dass jemand sich dann als Microsoft ausgeben konnte, der es nicht war.

Dann kannst du natürlich den ganzen Leuten halt per Windows-Update Sachen reinschieben.

Ja, nicht so geil.

Und solche Sachen.

Also das passiert halt dauernd daher.

Es ist diese ganze Certificate Authority Geschichte, das ist alles, das funktioniert nicht so richtig gut.

Und dann hast du auch Probleme mit, wie was passiert, wenn du jetzt Sachen revoken willst, das geht alles nicht richtig.

Und das ist schrecklich.

Insofern würde ich sagen, tja.

Also dieses Let's also man muss auch heutzutage eigentlich kein Geld mehr bezahlen.

Es gibt eine freie CA, Let's Encrypt, die in allen Browsern die quasi 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 eine Browser irgendwie schreckliche Warnungswarnunggeschichten angezeigt hat, ohne dass man bezahlt hat.

Das geht heute.

Insofern.

Es ist ja.

Und ja, ich mach das so.

Es gibt auch Gründe, das nicht so zu machen, aber.

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 durchstehen.

Ich freue mich schon.

Thorsten.

Hi, Thorsten.

Zwar eine Live-Interaktion, finde ich super.

Okay.

Ja, also Engagement heute sehr hoch.

Also wir möchten gerne tatsächlich diesen Server, den wir jetzt ja irgendwie stehen haben, mit dem ganzen SSL, Zertifikat oder Quatsch.

Kann man denn irgendwie was?

Also wahrscheinlich erzähle ich jetzt wieder irgendwelchen Unsinn, irgendwie 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, sondern dass ich dann von meinem Server ausgehe.

Nein, das willst du aber nicht, aber dann weiß doch jeder, woher, woher du woher du bist.

Ja, aber das ist doch okay, aber dann ist das.

Das willst du

gerade nicht.

Nein, aber vielleicht habe ich einen anderen Standort und ich connecte bei 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 gehen will.

Also mein Provider weiß zum Beispiel dann nicht mehr, wo ich hingehe, weil ich ja bei meinen Server gehe.

Ja, okay, gut, aber gut, aber der Nachteil ist, dass halt jeder, den du konnten, dass du, dass jeder Webserverbetreiber weiß, wer du bist.

Was vielleicht auch nicht so cool ist.

Also, das ist alles sind alles Dinge, das will man wahrscheinlich nicht so machen.

Ja, aber vielleicht, also dann zumindest, wenn die ganze Zeit mein Provider sonst immer alles mitbekommt,

vielleicht kann man das machen.

Ist halt die Frage, vor wem du Angst hast.

Vielleicht vom Provider.

Wenn du vor dem Provider Angst hast, ja.

Dann könnte man da raus, das könnte man als Tunnel benutzen.

Das würde ich nicht so machen.

Würde ich nicht so machen.

Dann nimm lieber was ordentlich, ne?

Lieber Tor.

Ja, okay.

Oder nimm halt so einen von den VPN-Dienstleistern, aber die sind auch, ich meine, da muss man sich auch bewusst sein, dass die auch

gecaptured werden.

Nein, weil das so unabhängig.

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 habe mich jetzt gar nicht für anonyme Surfen interessiert, sondern ich einfach nur, ob die technischen Möglichkeiten irgendwie, wie das funktioniert, wenn ich jetzt da meine Connection über so einen Server schicken will, wenn ich da das einrichten würde.

Das hat aber nichts mit Web zu tun, dass es dann, da würdest du 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 und dann einfach einrichten auf dem Sinn.

Genau, also das ist tatsächlich ein Anwendungsfall, für den ich das tatsächlich auch benutze und auch einen OpenVPN-Server laufen habe.

Man kann auch bei allen, also bei iPhone geht das sehr, sehr easy, da kannst du halt Open VPN-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 dann, wenn man dann VPN anmacht, dann gehen die halt trotzdem.

Und dafür habe ich es halt benutzt bisher.

Aber ja.

Ja genau, aber das war von.

Also OpenVPN, den musst du dann auch über den Caddy routen oder weil wie ist das dann mit dem Fall?

Nein, nein, nein, nein, nein, dann können wir hier Ports dann.

Das läuft einfach auf einem Service auf dem Rechner.

Das ist ein ganz anderes Protokoll.

Das ist OpenVPN ein eigenes Protokoll, läuft üblicherweise, du kannst auch bei TCP und 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.

Und dazu gehört dann der OpenVPN, der auf einem anderen Port dann läuft als der Caddy, der auf dem 443 läuft.

Und dadurch kann ich dann, indem ich auf die verschiedenen Ports zugreife, dann auf die verschiedenen einzelnen Applikationen.

So wie das im Internet halt so üblich ist.

Die unterschiedlichen Services haben halt unterschiedliche Ports.

DAP ist halt 80 und 443.

Mail ist 25, DNS ist 53, je nachdem.

SSH 22?

Genau, FTP 21.

Ja, also SSH will ich wahrscheinlich auch haben.

Ja.

Weil ich halt da irgendwie das Connector habe.

Ich muss irgendwie auf die Maschine drauf, genau.

Aber dann ist halt auch die Frage, dann, also hat Rude auf die Maschine draufgehen, ist das nicht ein bisschen riskant, das irgendwie zu exponieren?

Oder sage ich dem, da darf sich gar nicht einloggen und 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 einen Pfeil namens Authorized 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?

Da kann man sich nicht mehr connecten.

Dann ist er am Arsch.

Du kannst ja aber mehrere zum Beispiel nehmen.

Ja, okay, aber dann ist man normalerweise am 8, dann muss man den Server komplett aufbauen dann.

Also weil das alles dann nicht mehr geht.

Dann muss man den Server hart, äh, wie kommt man dann wieder dran?

Also kann man nur die Fest.

Nee, also das hängt halt davon ab, mit welchem, was das ist.

Also du kannst, also du kannst auch zum Beispiel, weil wenn du jetzt einen eigenen Server hast, den Fall hat man 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.

Also einfach per serieller 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, die mit der läuft, weil der Kernel noch gar nicht hochgefahren ist.

Da willst du halt was anderes haben, mit dem du dich drauf connectest und das geht da.

Oft.

So dass du halt wirklich das Ding booten sehen kannst und halt kannst da Dinge tun bei Booten.

Genau, also das geht alles.

Insofern gibt es da noch andere Wege rein, aber ja, bei so einem Container, der halt einfach da.

Da geht das natürlich so nicht.

Aber das ist der so Wegwerfkram, ne?

Den schmeißen wir halt einfach weg.

Wenn ich den Server irgendwie abgeschossen habe oder so und der bootet nicht mehr, dann kann ich ja nicht anders machen.

Ja, du schmeißt den Container weg, machst du neuen.

Es dauert ja nicht lange, das dann wieder hochzufüllen.

Ja gut, aber wenn es im Container läuft, dann ist 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 an hast mit irgendwie Forward-Agent, dann kannst du halt auch private Repositories, beispielsweise GitHub oder irgendwelchen GitLab auschecken.

Das heißt, du connectest sie einfach hin, checkst es aus, sagst Locker Compose irgendwie Bild und dann links du halt das noch einmal in dein Supervice D-Config-Dings da nach ETC, sagst Supervice Control, Restart, dein was auch immer wie das heißt.

Und das dauert dann drei, vier Minuten und das Ding wieder oben.

Also, ja.

Selbst das könntest du noch automatisieren, ja.

Das kannst du per Script machen.

Hast du auch per Python SSH bedienen, ne?

Per Paramico oder so.

Paramico heißt das.

Library, mit der man SSH sprechen kann.

Ja, okay.

Ja, also Ports haben wir jetzt einmal so kurz drauf eingegangen.

Also ich könnte auch irgendwelche Ports da hinten aufmachen und da irgendwas hinterstecken.

Macht man dann auch sowas wie so ein Honitopf auf, dass man einfach irgendwie so eine Reaktion hat, falls die Leute irgendwie sagen, hey, klassischer Angriff und dann.

Würde ich jetzt nicht machen, aber gut.

Kann man natürlich, wenn man Spaß daran hat.

Also Fliegen fangen und dann.

Es gibt für Danger zum Beispiel auch so ein Honeypot-Modul irgendwie, das einen, wenn das dann so vorgeholt, dass es ein Admin-Interface gäbe und dann, wo sich Leute dann einloggen können mit irgendwelchen Standardpasswörtern und dann können sie da irgendwie Dinge machen, aber das ist alles eine Fake und dann kann sich hinterher angucken, was sie gemacht haben.

Aber ja, ich meine, wenn ein, wenn, aber.

Ja, wenn man so

ein bisschen rumspielt in der Hobbygruppe und man 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 nicht zu verstecken hat, sondern es eh noch so zum Rumspielen ist, dann ist das ja vielleicht gar nicht so schlimm.

Du kannst ja auch einfach offen lassen.

Vielleicht ist er hinterher besser.

Vielleicht ist das ja auch ein bisschen Honig ausliegen.

Schokolade.

Okay, ja.

Ja, also Firewall?

Ist das doch das?

Braucht man sowas was?

Nee, also Firewall.

Ist das auf Router-Ebene dann im Serverzentrum?

Nein, nein.

Also Firewall ist halt die Frage, was die Leute drunter verstehen.

Das sind auch unterschiedliche Dinge.

Also ich kenne es halt eher so aus der Internet-Admin-Welt.

Und da ist, nennt man Firewall, ist ein System zur Durchsetzung einer Policy am Übergang zwischen Netzwerken.

So, das ist eine Firewall.

Ich weiß, dass es so im Heimcomputerbereich gibt es da irgendwie andere Definitionen von.

Da gibt es halt so auch so Personal Firewalls oder sowas, ne?

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 mich reden oder darf ein bestimmtes Protokoll nicht auf einem bestimmten Port?

Genau, du setzt, du guckst dir halt, also was ich normalerweise, also Firewall ist ein Konzept, ja.

Das ist nicht unbedingt eine Implementation.

Das, was die meisten Leute vielleicht darunter verstehen, ist sowas wie ein Paketfilter.

Paketfilter guckt sich immer vier Sachen an.

Quell-IP, Ziel-IP, Quellport, Zielport.

Du kannst jetzt natürlich auf beliebige Kombinationen davon Policies definieren.

Also sagen, okay, das lasse ich durch, das lasse ich nicht durch.

Und jetzt ein Paketfilter guckt sich immer diese Quadruppel an und entscheidet dann, ob er das Paket durchlässt oder nicht.

Und sowas kann man dann mit Paketanalyse, mit weiß ich, Py-Shark machen und das dann selber bauen auch.

Da gibt es Software für dir, die das macht, aber das macht nur dann Sinn.

Also einmal willst du das nicht, willst du solche Sachen niemals verwenden, um dich drauf zu verlassen, sondern das ist immer nur ein zusätzliches Sicherheitsnetz.

Also die Sachen sollten sicher sein von sich aus.

Sodass halt auch wenn deine, das kann ja auch sein, dass deine 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, aber dafür muss es dann halt eine physikalisch getrennte Maschine im Grunde sein, auf der nur der Paketfilter läuft, sonst nichts.

Sonst macht es 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.

Also, falls ich doch meinen offenen File-Dings da betreiben will, dann sollte ich dann eine Firewall zwischen dem Netz und dem Netz.

Aber das kannst du überhaupt nicht, du hast ja nicht Kontrolle über das Netz.

Also das kann, ich würde sagen, das macht ja nur dann Sinn, wenn du auch das Netz unter Kontrolle hast.

Und dann müsste 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 eigenen Server zu Hause, wenn ich da für zwei verschiedene Routernetze oder sowas sich voneinander trennen will.

Vielleicht habe ich irgendwie ein kleines offenes Netz da.

Da gibt es ja so ein paar Optionen, wo man sich frei sich verbinden kann an einem Funk.

Und dann könnte man das mit seinem Heimnetzwerk machen und da sollte man dann sowas dazwischen hängen, weil die Geräte zwar im gleichen Laden sind.

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, äh, also ich, seit diesen Zeiten sind es vorbei.

Also das ist nicht.

Ja, also ich meine, eben diese Infra, also die Hoster und vielleicht auch Amazon und die werden solche Sachen betreiben, ja, 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, das nur das tut.

Und dann brauchst du mehrere davon.

Weil du willst den ja, 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, aber brauchst du mehrere davon.

Das heißt, du betreibst mehrere Rechner zu Hause nur, um diese Policy da durchzusetzen.

Welchen Gewinn erzielst du dadurch?

Also, und vor allen Dingen im Verhältnis zu dem Aufwand.

Also als Rechenzentrumsbetreiber kann man das irgendwie rechtfertigen, dass man zu jedem Switch dann noch irgendwie einen Paketfilter stellt.

Oder so alle zwei, drei Racks stellt man da halt irgendwie noch einen Paketfilter dazu.

Aber zu Hause.

Und damit mich aber ganz sicher, damit nicht mehr so glaskörpermäßig.

Ja, aber das Ding hilft dir ja für die meisten Sachen, die dich sozusagen, wenn du.

Mäst nicht.

Ja, das, das, genau, wenn du, wenn du, 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 kann, 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, irgendwie macht.

Aber das passiert heute eh fast nicht mehr.

Weil, äh, oder das passiert ja auch nur dann, wenn es überhaupt eine Verbindung möglich wäre.

Die meisten haben ja, sind ja, da sitzen hinter irgendeinem komischen, dynamischen IP oder irgendeinem seltsamen Natt.

Ja, da ist es mit den Verbindungen sowieso nicht so toll.

Und da müssen sich, müssen ja diejenigen, die das, die dich, also 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.

Und wenn er das auf eine relativ schlaue Art tut, dann nützt der ganze Paketfilter kam nichts.

Weil der sieht ja nichts schlau aus, der macht ja nichts Schlaues, sondern der macht ja was sehr, sehr Einfaches eigentlich.

Okay.

Also schade.

Also Firewalls sind auch quasi aus den Relikte aus

der Faktorfelder.

Naja, also Firewall ist ja unter Umständen noch viel mehr.

Also es ist ja nicht nur Paketfilter, sondern das ist ja halt, man kann ja auch noch andere Dinge tun.

Man könnte auch solche Sachen machen wie du hast einen Rechner, auf dem läuft nur ein VLC oder sowas?

Dieses Ding ist VNC.

VNCC.

Sozusagen, genau, du konntest dich darauf.

Du hast selber, bist du abgeschnitten von und kannst halt bloß über so eine grafische Schnittstelle irgendwie mit außen kommunizieren.

Also das macht man auch manchmal.

Das ist auch, würde ich sagen, ja, eine Firewall, um halt zu verhindern, dass du Netzwerke miteinander überhaupt verbinden musst.

Dann kannst du halt da sagen, okay, da ist eine, da ist gar keine Verbindung in dem Sinne.

Ja.

Okay.

Es würde für mich auch irgendwie unter Firewall fallen.

Oder es kann diverse andere Geschichten geben, die halt auch da drunter fallen.

Also ich würde eher sagen, das ist halt eher ein Konzept.

Und ja, aber das ist alles Sachen, das ist heute, ich würde sagen, ich weiß es natürlich nicht so genau, vielleicht, das ist heutzutage eher ein Ding für Experten.

Weil wer hat.

Mist.

Also ich meine, wenn man einem Spaß macht, man sich ja damit beschäftigen, aber so.

Das, ja, die meisten Firmen machen ja auch ihre Rechenzentrumskram nicht mehr selber.

Auch das macht natürlich Spaß, irgendwie selber Rex 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 pfff.

Okay.

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, man hat es vielleicht noch einen Unterschied gemacht, wenn man jetzt eine 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ßerhalb 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, also mit einem Aufwand, der das ist halt nicht mehr gerechtfertigt.

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 sowas rauszuholen.

Das ist ein PC, das mussten wir nochmal irgendwann genauer erkennen.

Das ist so ein bisschen schade irgendwie, weil natürlich viele coole Sachen, die wir früher irgendwie interessant waren, heute halt nicht mehr nicht mehr so.

Ja, 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 nochmal kurz das mit dem Server abschließen.

Ja.

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 daran schicken.

Also ich habe jetzt irgendwo ein paar RESPI-Sensoren oder sowas, die ich dann da broadcasten oder sowas mit MQTT habe ich gelernt, das würde ganz gut funktionieren.

Und dann darf 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, da das dann.

In Django selber rein geht das dann wahrscheinlich, wenn du es direkt in Django reinschreiben 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, ist es 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 wir jetzt zum Beispiel irgendwie, keine Ahnung, eben, du hast einen Sensor, es ist halt die Frage, ob es jetzt wichtig ist, die Daten, die dabei rausfallen oder ob man die ignorieren kann.

Also wenn jetzt da eine wichtige, nehme an, du hast einen Geigerzeller in einen Raspberry Pi eingeschlossen, ja, und irgendwie der Fallout, die Fallout-Wolke ist überzieht über dein Wohngebiet.

Und aber dummerweise ist irgendwie gerade 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 sie halt irgendwie an deinen Server zu schicken und der ist halt gerade nicht da.

Und was macht dein Dann.

Dann schmeißt sie einfach weg.

Schmeißt sie einfach weg, ja.

So, dann schmeißt sie einfach weg und dann kriegst du die Daten nicht.

Hängt davon ab, hängt von deinen Anforderungen ab, ob das jetzt schlimm ist oder nicht.

Kann auch sein, dass es nicht schlimm ist.

Aber wenn es, wenn du möchtest, dass die dann halt noch irgendwann dahingeschickt 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, da hingeschickt werden.

Und ja, das kannst du dann, kannst du noch Features dazu bauen und dann implementierst du MQTD oder halt beliebiges anderes Queuing-Systemen, 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.

Eben sagt man, dann schmeißt man halt in die Queue halt irgendwie dieses Sensordatum halt rein.

Und der überlegt die so lange bisher eine 2001.

Genau, aber

man muss sich nicht mehr selber kümmern, dass das irgendwie zugestellt wird und so, das passiert dann automatisch.

Also der macht dann einfach Post-Requests auf die API.

Nee, nee, nee, nee.

Das Ding macht.

Nein, nein, nein.

Das war ein eigenes Protokoll.

Das macht auch kein HTTP.

Das ist ein eigenes Protokoll.

Es gibt einen MQTT-Broker, der irgendwie weiß, welche.

Wie spricht der dann REST?

Was bekommt der denn da?

Kein HTTP.

Aber was bekomme ich denn auf meinem Django-Backend, auf meinem Dango-Server?

Du könntest natürlich, ja, wenn 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 dann geiler, zum Beispiel ein VPN aufmachen.

Ja.

Und hast halt auch quasi ein Ding, was halt die an der Que hängt, sozusagen die, die konsumiert, die Ereignisse, die da rausfallen, die Events, die herausfallen, und das dann halt irgendwo zum Beispiel in deine Datenbank direkt reinschreibst.

Oder gehe ich aber gar nicht mehr über die API?

Dann gehst du gar nicht über die API, genau.

Aber dann habe ich noch einen eigenen Service laufen, der hängt aber nicht mehr im Caddy, sondern der hängt als Demon wieder auf einem eigenen Port.

Ja, genau.

Aha, und dann muss ich dann einfach dann, der.

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 in den Container mit reinschreiben.

Den im QGT-Broadcaster, damit er auf die Datenbank zugreifen kann.

Nö, das musst du halt bloß irgendwie auf da reinkommen.

Das Ding kann in dem Container irgendwie als Prozess laufen, das kann aber auch wieder in einem eigenen Container laufen.

Aber das

kann halt, ich bin jetzt gerade ein bisschen ausgestiegen an der Stelle dieser Verzahnung.

Also ich habe jetzt meinen Django in einem Docker-Container laufen, der vom Caddy angesteuert wird.

Den läuft selber in einem eigenen Container.

Angesteuert ist.

Also der Caddy, der schießt das doch zum App-Server.

Der App, der hat.

Nein, wenn Requests von außen kommen, die landen auf dem Caddy und der schickt sie dann halt weiter an den Applikationsserver, wenn sie bestimmt entsprechen.

Der läuft aber als Docker.

Ja, aber der Caddy kann auch als Docker-Ding laufen.

Bei der Default-Installation mit Cookie Cutter ist das auch so.

Da läuft auch der Caddy in einem eigenen Container.

Und dann ist das egal, dann kann der MQTT-Bloadcaster auch im Container laufen.

Der kann aber dann mit den anderen Ausglash-Containern zum Beispiel reden oder sowas.

Ja.

Ja, okay.

Dann kann er das dann reinschreiben und kann da gut drauf zugreifen.

Der Zugriff, den mache ich jetzt, weiß ich nicht, Django kann man Plotly, C-Born, Matwot Blip oder halt tatsächlich so ein bisschen Dash sogar, habe ich gesehen, Dumbo-Modul, um das dann irgendwie vernünftig 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 den Knopf drücke, dann soll das direkt umpassen.

Sichtbar sein, ja.

Das Einfachste ist wahrscheinlich in JavaScript einfach zu pollen, irgendwie alle ein paar hundert Millisekunden oder so einfach nochmal die API zu fragen, gibt es neue Daten.

Get Request und einfach.

Oder aber das ist halt die Frage, ob man das machen möchte, du machst halt Websockets und dann sowas auf Django-Seite, was wie Django Channels oder so, aber dann musst du halt einen, da musst du einen anderen, musst du noch ein bisschen anderer.

Was sind denn Websockets jetzt schon wieder?

Oh je, ja, das ist halt so eine Erweiterung.

Das ist halt dann auch schon nicht mehr HTTP, dann ist dann halt was anderes.

Weil HTTP ja, da hast du das Problem, du hast keine bidirektionale Verbindung, sondern du hast halt immer nur Request-Response.

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.

Ja, Socket ist quasi sozusagen das eine Ende der Hörer bei dem Telefon.

Wenn sich vorstellt, 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 halt auf der anderen Seite rauskommt.

Der kannst in beide Richtungen, aber was reinwerft, das hat er nicht so ein bisschen.

Ja, genau, es hat in beiden Sachen.

So, aber HTTP ist halt nicht so, sondern HTTP ist eher so wie hoher Post.

Da wirfst du halt was rein und das.

Ruhe Post.

Ne, Quatsch, ach, das ist auch Unsinn.

Das wäre ja auch bidirektional.

HTTP ist eher so wie.

Wie so ein Katapult.

Katapult in eine Richtung fliegt immer was für die Stadtmauer und dann, wenn du was.

Du hast eine Telefonverbindung, aber auf der Serverseite hast du nur.

Oder du bist dann in so einem Bunge-Seil und versuchst mit der Hand immer ins Wasser.

Ach, diese ganzen Vergleiche sind nicht gut.

Das stimmt alles nicht.

Ja.

Mir fällt 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 einen Fax hin und her schicken, sowas.

Ja, du kannst halt nichts dahin schicken.

Du kannst halt nur darauf warten, dass dich jemand fragt.

Und das ist halt, also jetzt halt mein Vergleich ein.

Du bist halt so wie die, äh, wie die, äh, wie beim Bahnhof die Information.

So, die Leute können zu dir kommen und dich irgendwas fragen, aber wenn jetzt der Zug irgendwie, keine Ahnung, 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, ja.

Ja, also man könnte ja so durchsagen, aber so weit sind wir jetzt noch nicht, das ist viel zu modern.

Da geht es dann natürlich schon wieder kaputt mit der Metapher.

Aber ja, also eben, wenn du dann Websockets hast, dann geht es halt doch.

Dann hast du eben eine Verbindung zu allen Clients und denen kannst du dann echtzeit direkt sagen.

Wie mache ich Websockets an?

Also über Django hast du gesagt Channels.

Ja, Django Channels ist eine.

Das Problem ist aber, du brauchst halt einen anderen Server, dann Applikationsserver, der das kann.

Und welcher Applikationsserver kann Selbstsockets von Duncan?

Der kommt dann da mit Django Channels 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 halt alles nicht mehr so einfach dann.

Und ja.

Ja, aber jetzt habe ich schon wieder jede Menge gelernt und ich bin viel weitergekommen.

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, in die Web-Geschichten, genau, dafür brauchst du, also wenn du eine eigenen Domain hast, ist schon mal sehr gut, dann kannst du schon mal eine Menge machen.

Und das auch vor allen Dingen kannst du eine Menge nachrüsten.

Ansonsten bei Django sieht es da momentan noch nicht so richtig doll aus.

Also muss man noch ein bisschen was basteln.

Ja, ich habe jetzt tatsächlich irgendwie geguckt, wir haben jetzt die ganze Überschreit, aber du kannst halt einfach auch irgendwie jetzt ein Flashroom Pyramid einfach da nehmen, ist eigentlich relativ egal.

Ja, da gibt es auch nichts.

Aber dann gibt es halt jeweils die andere Module, die man dann irgendwie sich herausfinden muss, welche das dann sind und das funktioniert aber dann quasi relativ ähnlich.

Genau.

Also in die Webgeschichten ist momentan eher noch alles so in der PHP-Welt zu Hause.

Ja, okay.

Ja, so ist es halt.

Das heißt, ich muss dann einfach so ein Caddy auf ein PHP-Verzeichnis schicken, oder?

Wenn du jetzt nee, du könntest, also ich weiß nicht, wie man das heutzutage so macht mit PHP.

Also diese, ich hoffe, dass auch mal da die Zeiten, wo man da irgendwie so eine Webroute hatte und da irgendwie PHP-Dateien, die dann irgendwie magisch ausgeführt werden über Modelbot 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 sein, dass ich neben dem Caddy dann einfach ein Apache mit einem Mod PHP laufen habe und der dann Anspreche aus auf dem nächsten Port.

Kannst du, ja, könntest du ja natürlich auch machen.

Du kannst ja einfach einen Caddy sagen, so das bitte an diese Domain oder diese Subdomain oder was auch immer, an den Apache weiterreichen, geht natürlich auch und den eigenen Container packen, klar.

Und dann fürs Indie-Web, was baue ich denn da noch?

Also eigentlich auch sagen wir.

Da kommt mal drauf an, was du machen möchtest, aber da müssen wir nochmal, also weiß ich jetzt ehrlich gesagt, das ist nicht so genau.

Okay, das machen wir dann nochmal an externe, haben wir jetzt 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 demselben Server.

Also ja, GitLab haben wir gesagt, kannst du auch selber drauf bauen, wenn du deine eigene Versionskontrolle bauen willst, dann halt einen GitLab-Server.

Das würdest wahrscheinlich auch einfach ein Dienst sein, oder?

Daemon?

Was ist das?

Ja, ja, ja, ja, ja.

Das ist einfach auch wieder eine Webgeschichte, ne?

Also GitLab ist einfach auch nur so ein Webfrontend.

Auch nicht.

Ruby und Rails ist halt, ich weiß nicht genau, wie aufwendig das ist, das zu hosten.

Also irgendwann wird es dann natürlich schwerer.

Also wenn du einen 10-Container hast oder 20 oder irgendwann wird es dann mit dem Hauptspeicher ein bisschen eng.

Keine Ahnung.

Braucht man möglicherweise auch eine eigene Datenbank?

Ja.

Also Datenbanken sollte man nicht so viele nehmen.

Man sollte die meisten nach 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.

Also und dann immer eine 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 einen Projekt und dann sind alle Projekte rutscht.

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 Datenbankversion 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 du, wo alle deine Datenbanken liegen.

Wäre viel effizienter, aber ist halt viel schwerer, was die, 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 irgendwas, ja.

Naja, das ist halt einfach, du musst dann, du musst dann plötzlich Dinge tun.

Du musst dann, wie da musst du Backups haben, du musst auch so haben, aber das kriegst du alles in einem Projekt unter.

Aber wenn du jetzt einen eigenen Datenbank-Server hast, dann ist das mit den Backuppen alles nicht mehr so einfach.

Dann ist 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 nutzt sich das ja überhaupt nicht.

Ja, dann sind wir wieder, ich glaube, den Kreis können wir jetzt schließen.

Wir sind ja nämlich bei der Tiger 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 da selber hoste.

Genau dasselbe, ich muss da wieder was hochfahren, was routen über dein Keddy und ab der Applikation laufen und läuft.

Ja, super.

Also ja, wenn ich das irgendwie mache, ich bin gespannt, wie lange ich dafür brauche, bis das alles rennt.

Ich gebe

euch die Feucht.

Das ist auch, aber ich meine, wenn du, also ich höre, dass du wirst 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 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 Technik gesehen, aber dann mit Dünden ist auch irgendwie doof und ja.

Ja, ich muss überlegen, was da irgendwie am besten in Frage findet.

Aber damit kannst du ja vielleicht starten.

Du kannst ja zu Hause anfangen.

Ja, ja, der ist schon in der Luft schon eine ganze Weile, aber der macht keinen Spaß.

Ja, aber ich muss ja eh immer so ein ganzes System bauen und so.

Aber ich möchte die ganze Nacht halt dann einfach wieder umbauen können, dass das nicht irgendwie das mal dieser ganze Konfigurationsaufwand ist.

Ich habe jetzt irgendwie im Fedora-Server dann irgendwie hingestellt, dass es irgendwie einige Sachen auch konnte, der auf den Postgres auch lief und irgendwie auch dann Dankbo konnte, aber das ist alles nicht so gewesen wollte.

Aber wir haben jetzt auf jeden Fall, das finde ich total super.

Ich habe da kein Candy, kein Rius und Nix 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 brauchen doch das alles irgendwie magisch, aber wenn man nicht so wirklich versteht, was dann dahinter steckt, ist das nochmal eine ganz andere Hürde, glaube ich.

Auch zu verstehen, warum was gerade nicht geht oder so.

Und ja.

Ja, vielen Dank, dass du mir das alles wieder heute hier erklärt hast.

Jetzt weiß ich nicht, ob das alles irgendwie klarer geworden ist, sondern nur noch viel verwirrender.

Nein, nein, nein, das war richtig wahr.

Also eine große Erleuchtung.

Man kann sich das alles auch mal zurückspulen oder nochmal langsam abspulen.

Ich fand es echt cool.

Ja, also auf jeden Fall.

Eine tolle

Folge für mich mal heute hier.

Okay, ja.

Mag sie natürlich immer an.

Ja, und genau, also ja, also es 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 Putter Template verwenden.

Ja, also ich schließe jetzt gleich erstmal die Mail von Thorsten durch und freue mich, dass ihr heute alle wieder zugehört habt.

Fand ich richtig super.

Ich habe ja sowieso auch keine.

Ja, Pick der Woche habt ihr heute Morgen.

Habe ich schon verbannt.

Machen wir dann diesmal nicht.

Machen wir diesmal wieder.

Ja, dann gut, dass ihr wieder eingeschaltet habt.

Bleibt uns gewogen.

Immer dann, wann wie ihr hört, irgendwie, ob gerade die Sterne scheinen oder die Sonne brüht.

Ja, wir hören uns.

Bis wieder.

Jo, tschüss.