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 es 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. Es haben auch tatsächlich Leute inzwischen so ein bisschen angefangen, die Kommentarfunktion zu benutzen.
Da war ich ja irgendwie...
Ja, unser Pocket-Cast-Chapter-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.
Wäre es vielleicht nicht so schlecht, wenn man E-Mail-Benachrichtigungen 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 es ist nicht nur sehr warm, es ist auch irgendwie sehr wenig Zeit momentan für alle möglichen Dinge.
Ja, ja. Alles auf einmal.
So ist das halt. Ja. Aber genau. So ein bisschen haben wir ja schon.
Insofern brauchen wir uns nicht die ganze Zeit nur zu beschweren, sondern können auch ein bisschen was erzählen.
Ja, diesmal röchere ich dich ja ganz viel mit lustigen Dingen.
Wie man, wieso man, warum man den ganzen Unsinn überhaupt macht.
Ja, ja. Ich finde, das ist ein interessantes Thema.
Und naja, das ist ehrlich gesagt, ich meine, so Inspirationen aus anderen Podcasts, die ich so höre, zu nehmen, ist momentan auch so ziemlich das Einzige, wo ich Inspirationen hernehmen kann.
Daher dachte ich, nehme ich mal irgendwie die Veröffentlichung von Jungle for Professionals von Will Vincent, die jetzt gerade irgendwie dieses Wochenende passiert ist, zum Anlass, da auch so ein bisschen was zuzusagen.
Weil ich hatte so ein bisschen, ich habe es noch nicht komplett durchgelesen, aber ich habe so ein bisschen reingeschaut.
Also, wie ihr merkt, wir sind direkt bei der nächsten Chapter-Mark-Szene.
Ja, Moment, genau, Moment.
News. Ja, alles klar, habe ich gesetzt.
Ja, so beim Durchblättern habe ich schon gedacht, okay, das sind genau die Sachen, mit denen ich auch schon irgendwie lange rumgeplagt habe.
Und das ist wirklich sehr schön gemacht.
Und ja, das ist eine Menge Zeug.
Also, wie betreibt man eigentlich überhaupt irgendwie so eine Webseite da draußen?
Und was macht man da alles?
Und gerade jetzt speziell irgendwie, was Jungle 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.
Ja, äh, äh, äh.
Ähm, Hände wedeln.
Das ist alles kompliziert.
Das ist nicht so einfach.
Fragt einfach euer Ops-Team.
Ja, und dann hat man das vielleicht gar nicht.
Das ist blöd.
Ähm, ja.
Und, ähm, genau.
Das, äh, 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, damit man irgendwas auf die Straße kriegt.
Und darüber wollten wir so ein bisschen was reden.
Vor allen Dingen, weil, ja, wir müssen ja einfach mal alle Synergien nutzen, die wir kriegen können.
Ich glaube, du wolltest ja auch irgendwie so eine Webseite haben oder so, ne?
Ja, ja, genau.
Ich wollte so einen Server mal selber auch irgendwie aufsetzen.
Und, ähm, da brauche ich so ein bisschen Hilfe natürlich bei.
Und gucken, was man mit Python alles machen kann.
Und da löchere ich dich gleich ein bisschen mit.
Ja.
Ähm, haben wir noch irgendwelche News aus der Szene, die wir vielleicht dann noch hier reinbekommen?
Oder?
Ja, ich würde einfach mal die Sachen, die so, äh, passiert sind, einfach, äh, nach und nach.
Was haben, was haben wir denn da noch so, äh, äh.
Du hast noch so einen Postkast gehört am Wochenende.
Data Engineering.
Ähm.
Da hast du irgendwas Spannendes zu erzählen.
Da, ja, aber das weiß ich gar nicht, ob das jetzt so super in diese, dieses Format passt.
Da ging es um, äh, eine Firma, die halt so, äh, ja, Label, Data Labeling macht.
Also gut, ich mache ja auch viel Machine Learning Zeugs, äh, Data Science.
Und, ähm, da, also, ich fand, ich fand das deswegen gut.
Also, äh, weil, also, ich glaube, äh, wie hieß, ähm, wie hieß die Firma nochmal?
Cloudworker oder so.
Und der, äh, Chef von dem, äh, Gründer, hat da halt, äh, irgendwie auf dem Data Engineering Podcast da, äh,
äh, äh, was zu erzählt.
Und, ähm, äh, das, was er so beschrieben hat an, das sind die Probleme, die man normalerweise kriegt,
wenn man, äh, irgendwie, äh, Firmen dabei helfen will, äh, irgendwas in die Richtung zu machen.
Das kam mir schon alles sehr bekannt vor, weil das sind halt auch die Dinge, die, äh, ich immer beobachte,
wenn ich da irgendwelche Projekte zu mache.
Und, ähm, ja, das sind halt so, äh, eben.
Wenn man, die meisten denken, das ist kein Problem.
Woher kriegt man eigentlich die Daten?
Dabei ist das ein Riesenproblem.
Also, äh, das ist oft etwas, was nicht wirklich,
äh, gelöst wird, äh, oder wo viel größere Schwierigkeiten dann tatsächlich, äh, lauern.
Also, man soll was machen.
Die Leute kennen jetzt 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's 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, ähm, der war, der hatte auch so ein paar lustige Beispiele dafür, äh, wie momentan da, äh,
also, auch wenn ich, äh, kuriose Ideen der 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, äh, in, in Las Vegas scheint es wohl mittlerweile üblich zu sein, dass da, äh, wie die, äh, äh, wie, äh.
Hotelzimmer werden gefilmt.
Ja, ja, Hotelzimmer, oder man mietet auf Airbnb, äh, wie diverse, diverse Geschichten und bezahlt mehr oder weniger,
oder gibt Leuten Goodies dafür, dass sie sich da reinstellen.
Dann darf man Fotos von ihnen machen oder so, weil man ja irgendwie unterschiedliche Leute in unterschiedlichen Situationen haben muss, ne.
Nicht, dass, äh, irgendwie das Modell dann nur lernt.
Irgendwie den gleichen Raum wieder zu erkennen, das ist ja ja doof, deswegen braucht man unterschiedliche.
Und es ist, es ist nicht so einfach.
Und dann, äh, ist das natürlich auch relativ schnell, relativ teuer, wenn man die Daten versucht selber zu generieren.
Oder man muss irgendwie mit Drohnen rumfliegen und Sachen fotografieren und so.
Klingt ja nach großem Spaß.
Äh, ja, es, 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.
Hooray!
Das wäre durchaus Spaß.
Ja, ja, genau.
Ja.
Brown Coat Night.
Ja, ähm.
Äh.
Genau, genau, das habe ich gehört, das fand ich, das fand ich ganz cool.
Ähm, kann man sich mal anhören, ich werde das, einfach den Link dazu in die Show Notes packen.
Das hat jetzt aber gar nicht so viel mit Python zu tun, sondern es war eher so, ja, wie kriege ich das eigentlich hin, wenn ich viele Daten zu annotieren habe und zu labeln.
Äh, eher so Data Science Machine Learning Geschichten.
Dann hat dir erst gleich was getwittert, ähm, zum nächsten Chat, glaube ich, war das.
Äh, ja.
Ah, äh, okay.
Äh, genau, da ging es um, ähm.
Fix.
Äh, pre, äh.
Pre-Talks, glaube ich.
Ja.
Meine ich.
Ja, okay.
Das war der nächste Eintrag.
Ah, nein, doch.
Doch, ja, doch, genau, das ist es.
Äh, und zwar ist das so ein, äh, Kon, Konferenz, ähm, ja, Organisations, äh, äh, Organisationssoftware, die halt, äh, irgendwie viele Leute verwenden, ist auch so eigentlich ganz cool Django-basiert, ähm, äh, das, die wurde auch verwendet, um, äh, zum Beispiel die Subscribe, diese Podcast-Konferenz, äh, zu.
Ah, ja, da waren wir ja auch, ja.
Auch waren, ja.
Deswegen kam mir das schon so bekannt vor.
Es wurde auch damit, äh, äh, organisiert und viele, äh, ja, Events im CCC-Umfeld, vor allen Dingen wohl auch das Camp, wird halt damit, ähm, damit geplant.
Und, ähm, denen fehlt irgendwie, äh, ähm, ordentliches Ticketsystem.
Ähm, und irgendwie, dass auch Pre-Talks irgendwie mit E-Mails ordentlich umgehen kann und so.
Und deswegen hat auch Twitter mal gefragt, ob es da nicht Leute gibt, die sehr Lust hätten, sich mit, äh, zu beschäftigen oder vielleicht im Rahmen von einem Sprint auf dem Camp, äh.
Irgendwie da was dran zu tun.
Gerne auch, äh, Einsteiger, ne, weil man kann da sicherlich auch viel lernen und, äh, auch für andere ist es vielleicht mal eine Gelegenheit, Leuten was zu zeigen, wie Django da so funktioniert, was man da so tun kann.
Also fand ich auf jeden Fall eine, äh, gute Idee und, ähm, das Ding wollte ich mir auch immer schon mal näher angucken.
Äh, und, äh, ja, finde ich eine gute Gelegenheit.
Äh, ich würde da auch hingehen, wenn ich auf dem Camp wäre.
Ich weiß es aber nicht.
Ich fürchte, ich werde nicht da sein.
Ganz vielleicht doch, aber eher wahrscheinlich nicht.
Daher, äh, wird das leider nicht funktionieren.
Wann ist das denn überhaupt vielleicht für irgendjemand geneigt?
Äh, das Camp ist irgendwie Ende August, also.
Ich glaube, es ist alles ausverkauft worden, schon lange jetzt.
Ja, ja, schon lange, genau.
Ähm, äh, Moment, ich gucke mal gerade, das, äh, CC-Camp, wann ist denn das?
Also irgendwie, äh, 20. bis 25.8., ja.
Irgendwo in der Nähe von Berlin.
Genau.
Ja, ähm, also, äh, ist auf jeden Fall.
Wenn da zufällig jemand hingeht oder so, dann ist das.
Das ist sicher eine gute Gelegenheit, um sich mal intensiver mit Django, äh, 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.
Ähm, ja.
Und, ach, da hat eine Überleitung, äh, die da vielleicht auch, äh, direkt Sinn macht, ist, ähm, äh, habe ich auch gehört in einem Podcast.
Äh, ja, ich bin momentan viel auf Spielplätzen unterwegs und höre da Podcasten.
Ja, ja, ja.
Kinder toben.
Ja, ja, ja.
Vor allem dann langweilig, wenn man in der Sonne rumsteht.
Ähm, äh, und zwar ging es da um, äh, Tiger.io.
Äh, halt nicht so wie das, äh, wie das gefährlich raubt hier, sondern mehr so wie, äh, diese, äh, öde, äh, äh, weite Ödnis im Norden.
Das Projektmenschmentool.
Ja, das wollen wir doch später besprechen.
Nee, aber das passt jetzt super, das, äh, äh, hier ran zu, äh, äh, pflanschen, weil das ist nämlich, könnte man super auch mit dem P-Talks, äh, eigentlich verbinden.
Weil, äh, naja, da fehlt halt vielleicht so ein bisschen Ticketsystem.
Und das Tiger hat das auch schon eingebaut.
Und das hat irgendwie ein ziemlich cooles Ticketsystem eigentlich.
Und das ist halt auch Django und das ist vor allen Dingen ein Django REST-Framework, äh, und hat eine super API.
Das heißt, man kann das alles, äh, äh, toll auch, äh, irgendwie ansteuern ohne.
Jetzt müssen wir nochmal kurz erklären, was denn Tiger jetzt überhaupt ist.
Also Tiger ist ein Projektmenschmentool, wo man Boards bauen kann, Kanbans bauen kann.
So ein bisschen wie Trello, wenn ihr das vielleicht kennt oder so.
Wobei, ich würde sagen, also wenn, wenn man, äh, irgendwie, äh, Jira, äh, äh, herzliches Beileid.
Wer das kennt, aber, äh, ich hab, war öfter mal, äh, in der, also das Missvergnügen, irgendwie da, mich mit, äh, beschäftigen zu müssen.
Und das war immer, ist da immer meistens eher Schmerz.
Das kann aber auch sein, dass es einfach, ich meine, es ist einfach viel Zeug.
Und ich hab jetzt auch meistens nicht so viel Lust, mich wie ordentlich mit Projektmanagement-Software zu beschäftigen.
Daher, vielleicht lag's auch einfach daran, dass ich da nie so wirklich durchschaut hab, wie das funktioniert.
Und, äh, dann schnell was machen wollte.
Und das ging dann halt nicht, weil's kompliziert ist.
Und dann war ich irgendwie frustriert.
Mag sein.
Äh, vielleicht ist es auch einfach ein furchtbares Tool.
Kann sein.
Ähm.
Aber, ähm.
Also ich konnt's auch nie leiden.
Ja, auf der, das haben wir so auf der komplexen Enterprise-Seite irgendwie, ähm, möglicherweise.
Und dann irgendwie sowas wie Trello.
Ja, und also die Mutterfirma von, äh, Jira ist, äh, Atlassian.
Die auch mal so, ähm, na, wie hieß das, Bitbucket gemacht haben und so.
Die sich jetzt aber eher so in die Projektmanagement-Software-Ecke begeben haben.
Was wahrscheinlich ein schlauer Schlagzug war.
Und, ähm, auf der anderen Seite Trello.
Genau, äh, das eigentlich von den Leuten, die auch Stack Overflow gemacht haben.
Irgendwie mal gegründet worden, aber verkauft worden an, äh, an Atlassian.
Äh, 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, wie Jira.
Und, äh, das sind sozusagen vielleicht die beiden Pole, äh, die, äh, äh, so von super komplex Enterprise bis zu, äh, naja, relativ einfach und, äh, schlank und leicht zu bedienen.
Äh, auf der anderen Seite, äh, dazwischen gibt es aber von Atlassian jetzt nix.
Ähm, und, äh, da ist, glaub ich, oder da positioniert sich Taiga selber als, äh, ist ein bisschen, hat ein bisschen mehr Features als, als Trello.
Aber ist nicht ganz so, äh, nicht ganz so kompliziert wie jetzt, äh, wie jetzt Jira.
Aber, und es hat halt als, als Kernfeature halt ne, ne, ne API, sodass man quasi alles, man kann sogar mit der API mehr machen, als man jetzt mit dem Frontend machen könnte.
Daher, ähm, ja, es gibt, es gibt irgendwie mobile Apps irgendwie, die man da verwenden kann, die jemand anders gebaut hat.
Aber der gesehen hat, dass man die API verwenden kann, und dann hat er das einfach mal gebaut.
Ja, also wir werden auch, äh, 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, es ist auch, es ist komplett, äh, freies 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, und schauen, wie die da so Sachen implementiert haben.
Ich hab's ein bisschen reingeguckt und war, top, das ist eigentlich jetzt gut.
Ja, man kann seinen eigenen Board bauen, seinen eigenen Trello-Board organisieren, kann man Boards auf seinem eigenen Server basteln.
Und sowas hab ich auf jeden Fall vor.
Ich bin schon ziemlich gespannt, wie das alles funktioniert.
Ja, äh, genau, genau.
Also, Scrum macht das Ding, oder man macht halt, kann halt auch, äh, irgendwie kann man damit machen.
Äh, ja, und, ja, kann man sich ja mal anschauen, ist eigentlich ganz nett.
Ähm, äh, genau.
Ja, was hatten wir noch?
Ja, wir wollten eigentlich noch ganz kurz auf die Frage von Arnim eingehen, der uns eine E-Mail geschickt hatte.
Oh, das haben wir auch verschludert irgendwie.
Ja, das war ein bisschen her tatsächlich, schon, ähm, Mai, glaub ich.
Ähm, und, äh, ja, er wollte, äh,
mehr über Error-Driven-Development hören.
Und, ähm, ja, wir wollten eigentlich mal eine Folge zu Tests...
Ja, das machen wir auf jeden Fall.
...mal machen.
Ähm, aber das wird noch ein bisschen dauern.
Ja.
Und deswegen so viel, ja, äh, was meinst du denn überhaupt damit, Arnim?
Also, vielleicht nochmal irgendwie fragen.
Es gibt irgendwie da nicht so ganz klar, welche Methode...
Ich dachte, ich wüsste, was das, was gemeint wäre, aber dann hab ich nochmal gegoogelt und dann dachte ich so, oh nee, ich weiß doch nicht.
Weil, äh, also, ich glaub, das kam als Reaktion auf einen Pick aus einer Folge von Anfang Mai, wo wir erwähnt hatten, dass es MatMat oder, äh, gibt.
Und das Ding, ähm, macht, äh, äh, sozusagen guckt halt, ob...
Es war mehr so eine Geschichte, um zu schauen, ob deine Tests halbwegs abdecken, was dein Code so tut, indem es einfach deinen Code, äh, zufällig verändert.
Und dann guckt, ob die Tests brechen oder nicht.
Und wenn, äh, dein Code zufällig verändert werden kann, ohne dass deine Tests brechen, dann weißt du halt, mh, okay, ja, ist ein Problem.
Und, ähm, ja, sie nennen das Mutation Testing.
Äh, äh, das ist eigentlich, eigentlich auch eine ganz nette Idee.
Aber das würde ich jetzt Error-Driven...
Error-Driven-Development, weiß ich nicht.
Also, ich hab dann noch, also, äh, Leute benutzen den Begriff gerne als, äh, sozusagen Gegenbegriff zu Test-Driven-Development.
Ja, sozusagen, also, beziehungsweise, äh, schreiben dann halt, dass, wenn du kein Test-Driven-Development machst, dann machst du halt Error-Driven-Development.
Was, äh, vielleicht, wenn man sich das mal klar macht, also, natürlich ist das irgendwie schon so.
Und, äh, wenn man sich das mal klar macht, dann, dann kann man sich auch vielleicht vorstellen, dass es nicht so eine super schlaue Idee ist.
Sondern, dass man das vielleicht, äh, ja, dann gleich richtig machen kann.
Wobei, naja, ich mein, ich würd auch dieses...
Das Test-Driven-Development-Cool-Aid nicht, äh, irgendwie, äh, nicht einfach so schlucken, sondern da, äh...
Also, man, man sollte Sachen vielleicht nicht so total übertreiben, äh, was die, was die Reinheit angeht, der Gedanken.
Ähm, ich, ich probier auch oft lieber Dinge erstmal aus oder so, bevor ich dann Tests schreibe.
Weil man, ja, man legt sich halt auch, was die Implementation angeht, ziemlich fest, wenn man Tests schreibt.
Ähm, damit sollte man sich dann schon halbwegs sicher sein, was das Ding eigentlich machen soll, bevor man das tut.
Aber, ja.
Es ist auf jeden Fall, Testschreiben ist eine gute Idee und, ähm, äh, äh, sozusagen, ähm, sich nicht von den Fehlern, die User anreporten, äh, die quasi die Tests, äh, äh, äh, als Tests zu benutzen, ist wahrscheinlich eine ganz, ganz schlaue Idee.
Äh, aber wie gesagt, ich weiß nicht genau, was gemeint war.
Insofern nochmal nachfragen.
Ja, ja.
Wir machen auf jeden Fall noch eine, eine Folge zu, zu Testing.
Äh, wir müssen uns nur noch jemanden finden, der, äh, irgendwie Lust hat, da mit uns drüber zu reden und so.
Test ist nämlich immer das spannendste Thema von allen.
Ja.
Ja, ähm.
Was noch mal.
Ähm, es ist ja auch schon fast ein Monat her jetzt.
Wir haben ja schon, äh, Juli.
Ja, ja.
Ähm, es gab eine Folge über Visual Studio Code und da auch über Tests.
Da kam ich gerade drauf, glaube ich, ähm, die man mit Visual Studio Code machen kann und, ähm, das Debugging-System, äh, auf TalkPython2Me.
Ja, ja, ja.
Das, das war irgendwie der, glaube ich, der, der Produkt, Chef von den Produkt-Onern für Visual Studio Code irgendwie, der da interviewt wurde.
Oder der hat eine Menge auch interessante Sachen, äh, erzählt.
Ja, vor allen Dingen, dass Visual Studio Code halt auch irgendwie bei Python-Entwicklern so, äh, super populär ist.
Irgendwie, was sie, womit 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, äh, ich benutze ja jetzt auch schon eine Zeit lang Visual Studio Code.
Äh, äh.
Ja, ich kannte das noch.
Ich, äh, hab, hast mich angesteckt.
Ja.
War eine gute Idee.
Äh, ist tatsächlich auch ein Editorialisier.
Ich meine, es ist so eine, viele Leute mögen ja dieses Elektronen, dieser, ist auch ein elektronenbasierter Editorial insofern.
Ja, viele mögen das nicht so, aber es funktioniert ziemlich.
Also, wenn ich das zum Beispiel vergleiche mit PyCharm.
PyCharm verwende ich, habe ich auch irgendwie eine Zeit lang verwendet.
Oder fand ich auch ab und zu immer noch, aber, äh, tatsächlich fühlt sich das irgendwie deutlich, äh.
Softer an, ne?
So smoother.
Ja, irgendwie, äh, snappier.
Ich weiß nicht, was kam da noch vor?
Ja, es gibt da so ein paar Sachen, die funktionieren direkt, also irgendwie, ne?
Es ist einfach viel schneller.
Es fühlt sich schneller an.
Vielleicht ist es gar nicht schneller, aber es fühlt sich schneller an.
Die Sachen reagieren einfach viel.
Also die Latenz, wenn man auf irgendwas drückt oder so, oder irgendeine Tastenkombination angibt,
die Latenz, bis dann was passiert, ist deutlich schneller.
Vielleicht hast du ja noch ein Rechner gekauft inzwischen.
Ne, ne.
Ne, äh, das, daran, daran liegt es nicht.
Und, ähm, ja, das ist halt, äh, also, ja, weiß nicht, wie sie das, äh, ich weiß auch nicht,
vielleicht macht auch PyCharm irgendwas falsch, keine Ahnung.
Ja, das ist eigentlich cool.
Also irgendwie, wenn man seinen Code damit verwalten will, irgendwie auf Git oder sonst irgendwo,
das funktioniert super.
Integration mit Azure ist toll.
Man kann direkt automatisch CI, irgendwie CD machen und das alles pushen.
Man kann Live-Sharing machen und dann gemeinsam am Code arbeiten, was auch ziemlich gut funktioniert.
Ja, mit mehreren Cursor.
Und Link und Multicursor und Übertragung.
Ja.
Im Terminal und mittlerweile, also in einem Nightly-Build war das doch nicht top.
Das müsste mittlerweile sowieso schon im Stellbild sein,
dass man jetzt auch über SSA einfach sich irgendwo auf eine Maschine legen kann
und da im Verzeichnis entwickeln kann.
Das ist auch ziemlich praktisch.
Kannst du auch auf deine WSL-Maschine gehen oder auf den Raspberry
oder auf eine andere Server, wenn du lustig bist, und direkt da editieren.
Das ist ja auch oft ein Argument, was man hört, dass Leute sagen,
ja, ich nutze halt VI oder Vim, weil da habe ich überall die gleiche Entwicklungsumgebung.
Und, äh, ja, auch wenn ich mich auf irgendwelchen Produktionsmaschinen einlogge,
kann ich da auch mal...
Ähm, äh, meine Umgebung, so wie ich sie...
Aber, genau, ist natürlich in gewisser Weise ein Argument,
aber geht mit VS Code jetzt auch.
Da braucht man gar nicht mehr unbedingt Vim für verwenden.
Ja, ja.
Also, falls noch jemand rausbekommen hat, wie man sowas wie FoxDot verwendet mit VS Code,
das habe ich nämlich noch nicht hinbekommen,
also das ist Live-Evaluation von Python-Code,
da hätte ich noch Lust drauf.
Das würde ich gerne noch rausfinden.
Das müsste irgendwie funktionieren.
Dass man irgendwie, weiß nicht, Alt-Enter drückt oder sowas,
und dann spielt er direkt die eine Zeile,
dann kann man Musik machen mit FoxDot verpeisen.
Das fände ich noch super.
Sonst muss ich es nämlich...
Sonst muss ich es nämlich irgendwie dran basteln,
aber, ja, so viel...
Ja.
Und wenig Zeit für so viele Projekte, ja.
Du hattest irgendwas noch reingeschrieben,
PySimple...
PySimple GUI.
Ja, da gibt es jetzt irgendwie noch einigermaßen fünffige Versionen,
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 Tkinter, TK,
oder PyQ5.
Kann man beides benutzen mit derselben Syntax.
Man kann halt einfach angeben, welches der dann visualisieren soll
und...
Hat einen relativ einfachen GUI für die...
Ja, PySimple ist ja nicht so besonders stark
bei Nachverstandsprogrammierung
und das kann man damit aber ganz gut
und vor allen Dingen schnell und effektiv erledigen.
Das lohnt sich vielleicht da auch mal kurz rauszuschauen.
Wollen wir mal angucken.
Genau, jetzt hast du mir meine Woche schon fast geklaut.
Ach so, sorry.
Ja, ja, der kommt jetzt wieder.
Ja.
Oh, ein Podcast,
den ich auch noch gerne erwähnen würde,
ist auch einer der letzten Django-Chat-Folgen,
mit Simon Willison.
Also einer der Leute, die auch Django
quasi so mit aus der Taufe gehoben haben.
Ziemlich...
Ist alles so mit...
Audioqualität ist manchmal so ein bisschen...
Aber ansonsten inhaltlich
fand ich das sehr, sehr gut.
Das war sehr, sehr spannend, was er da so alles erzählt hat.
Also was die Geschichte von Django angeht,
aber auch, was so die aktuellen Entwicklungen
sind, was er für spannend hält.
Und das halt gerade irgendwie...
Ja, so momentan spielt...
Async-Geschichten spielen da eine große Rolle.
Die sind gerade sehr spannend.
Oder sein Privat...
Oder sein Pet-Projekt,
was aber jetzt auch mittlerweile so groß geworden ist,
dass...
Pet oder Pet?
Ja, ja, so ein Nebenprojekt halt.
Aber es ist nicht mehr wirklich so neben...
Das Peißen-Halsband für die Katze, oder?
Nee, ja, also...
Er hat da irgendwie
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...
Daher geht auch die Entwicklung da momentan relativ schnell voran.
Das Projekt heißt Dataset.
Ach so.
Genau, das ist mir auch früher schon mal aufgefallen.
Hätte ich bestimmt auch schon mal ein paar Mal erwähnt, oder so.
Da hast du schon mal drüber gestolpert, ja.
Ja, genau. 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
SQLite-Datenbank halt
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-Statements einfach verwenden,
und man kann auch so coole Sachen machen, wie
JavaScript benutzen, um SQL-Statements
zu erzeugen, die man da verwenden kann, um die Daten noch zu fragen.
Voll gut. Und normalerweise
ist das alles puri bär, weil
schrecklich, schrecklich SQL-Injection droht und so,
aber man kann
SQL
SQLite so starten,
dass man sagt, irgendwie, ja,
das ist dann Datenbank-Street-Only,
und dann ist das alles nicht mehr schlimm, weil es kann nichts passieren.
Und
da ist das, was man normalerweise nicht tun sollte, dann plötzlich
alles erlaubt und cool.
Das ist
einfach, es ist nett.
Es hat viele überraschende Wendungen,
dieses Ding, wo man sich denkt, ach, cool, das geht,
das kann man so machen.
Die Datasette-Folge müssen wir uns ja nochmal aufschreiben, die steht nämlich gar nicht noch.
Ja, die muss da noch
mit drauf. Genau.
Also diese Podcast-Improvisation
kann ich Leuten durchaus, die sich für Django und
so interessieren, uns herzlichen, ist ja
sehr nett.
Ja, ich würde sagen, jetzt haben wir aber die News halt durch und machen
den nächsten Chapter, Marc, weil solange
löchere ich dich jetzt damit, wie das denn jetzt überhaupt funktioniert
mit dem Server. Und wir fangen wirklich von ganz
Basis-Bodensatz an,
also so gar keine Ahnung, wie macht ihr das und so
und wo und, ja, ich möchte nämlich
auch wissen, wie man das am besten macht, so Best Practice,
was sagt denn Jochen dazu?
Und, ja, ich würde sagen, können wir
starten jetzt mit unserem Hauptthema, ne, Server?
Dann starten wir da mal. Server, die Plattform für Anfänger, ja.
Erstmal Server,
was ist denn das? Also irgendwo
so ein Rechner, der irgendwie bedienbar ist,
das sollte ja irgendwie so klar sein, aber
ja, wen nehme ich denn da?
Also, was mache ich denn da für einen Server?
Nämlich irgendeinen Hosting-Anbieter,
Cloud-dedizierten Server,
virtuellen Server, warum und so?
Boah, ich brauche ja noch irgendwie
jetzt eine Domain und so, ne?
Wie würdest du 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 den an eine Stelle.
Ja, ne, da gibt es ganz viele Anbieter.
Ich weiß nicht, kann man... Ich bin das Universum, ich hätte gerne diese
Domain. Ja.
Es gibt ja diverse Anbieter, da muss man halt
ein bisschen Geld bezahlen, das kostet gar nicht so viel pro Jahr
und dann hat man halt eine Domain.
Du hast gesagt, selber registrieren, also es gibt ja
verschiedenste Server, Poster, 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
ja,
Welt, Wald und Wiesen
da hat man dann oft irgendwie so ein
Formular, wo man irgendwie die NS-Geschichten eingeben
kann, aber dann halt die Sachen, die man
braucht, also weiß ich nicht,
irgendwelche, wie heißen
diese Dinger, Verified Domain
SPF Records oder
also es gibt diverse Records, die man unter Umständen
einstellen können möchte.
Was ist ein Record?
Oh Gott, oh Gott, oh Gott.
Wie ist das Domain Name System?
Also, das ist im Grunde eine verteilte
Datenbank, die
Informationen darüber
enthält, wie
Namen auf
IP-Adressen aufgelöst
werden und umgekehrt.
Das heißt, da steht irgendwo, wenn man irgendwie den
Nameserver irgendwie fragt, keine Ahnung, der einzige, der
wahrscheinlich bekannt ist, irgendwie der von Google mit den
4.8. oder sowas, oder 8.4.4
oder was, und dann gibt es ja auch noch einige unabhängigere,
wenn man nicht alle seine Daten zu Google schicken möchte.
Aber die fragt man dann und die wissen,
dann wo, hinter welcher IP oder hinter
welchem Namen, welcher IP steht.
Ja, man kann auch einen eigenen Resolver betreiben. Also man kann das
durchaus von Hand auch machen. Das ist vielleicht mal eine ganz interessante
Geschichte, dass man halt irgendwie
das mal einfach von Hand mit
den S-Abfragen
irgendwas resolft.
Man resolft das halt so von hinten nach vorne. Also wenn man
jetzt irgendwie
pythonpodcast.de hätte, dann würde man
erstmal gucken, okay, also was man wissen muss
ist, man braucht
irgendwie so einen Root-Nameserver, aber
wenn man eine IP von dem hat,
dann kann man den halt fragen, okay, was ist
in der Nameserver, der zuständig ist für die .de-Zone?
Der Root-Nameserver, das sind
die großen Knotenpunkte.
Kriege ich das irgendwie raus, wenn ich so einen Trace-Root
mache, wo die irgendwie hängen?
Ja, die sind weltweit verteilt. Da gibt es ein paar von
rootservers.net, irgendwie
a.rootservers.net oder ganz gerne ein paar.
Ich weiß jetzt gar nicht mehr genau,
alles schon altes Wissen, vielleicht ist es auch
mittlerweile alles anders, aber
auf der ganzen Welt sind da ein paar von denen verteilt
und
normalerweise
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 Nameserver,
also über
eben die Records, also NS-Records sind halt
die Records, die zuständig sind, einem
zu sagen, was denn der Nameserver
zuständig Nameserver ist, also ich frage halt quasi den
NS-Record
für .de, den Root-Server und dann
kriege ich halt irgendwie den Nameserver, der zuständig ist
für die .de-Zone
und das ist halt
na, wie heißen sie noch?
Hier
D-NIC,
irgendwo in Frankfurt stehen die, glaube ich
und
die haben dann das .de-Zone-File irgendwie
drin und da steht
dann halt drin, wer, also in dem File
steht vor allen Dingen, stehen die NS-Records
für alle .de-Domains,
also
wenn ich jetzt wissen will, wer ist,
welcher Nameserver ist dann zuständig für
pythonpodcast.de, dann hole ich mir
den NS-Record für pythonpodcast
in dem
Nameserver, der für .de
zuständig ist und dann
genau, kriege ich das irgendwie zu.
Und ich kann das auch irgendwie selber machen, dass ich
sage so, hey, hier, ich heiße jetzt gerne
Dominik
mein Python-Com oder sowas, oder
.de, wir wollen jetzt zu D-NIC und dann sage ich
der D-NIC so, hey, hier, ich wäre jetzt gerne so,
ist das noch frei und schicke das dann
da?
Ja, das geht nicht
unbedingt so einfach. Das heißt, ich muss da
einen Registrier, Registrar
verwenden. Ja, also früher ging das auch,
da ist man da vorbeigegangen beim D-NIC,
hat da die Tür geklopft und gesagt, hallo,
ich hätte da mal so gerne ein Domain.
Aber das geht schon lange nicht mehr.
Ja, da kamen so viele
Leute wahrscheinlich auf diese Idee, ja.
Ja, das
geht schon lange nicht mehr.
Aber Gandhi macht das
dann zum Beispiel, wenn ich jetzt bei dem Domain...
Es gibt ganz viele unterschiedliche, also ich weiß gar nicht, ob es da
ich weiß nicht, ob das, was ich da verwende, 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.
Einen eigenen Domain braucht man noch für viele andere Dinge.
Wenn man Indie-Web machen will, braucht man auch einen eigenen Domain.
Jetzt brauchen wir irgendwie so einen Computer, der irgendwie so läuft.
Also die Frage ist, muss der schnell sein, muss der langsam sein?
Was ist das denn? Also haben wir da tatsächlich
einen eigenen Computer, der mit
Kernfestweise...
Ich war mit dem Auflösen noch nicht fertig.
Also wenn man jetzt den NS-Rekord von
einem Domain hat, das heißt noch nicht, dann muss man den
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.
Es gibt dann auch andere. Es gibt MX-Rekords,
die halt einem sagen, wo die...
wer zuständig ist für Mail.
Es gibt halt...
Ja, es gibt ja eine ganze Menge Zeugs.
Es gibt doch Text-Rekords 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...
und man möchte Mail
irgendwie von einem
Drittanbieter machen lassen, weil man keinen Bock hat,
das irgendwie alles selber
aufzusetzen und zu maintainen, dann
muss man da eine ganze
Menge Records setzen und so.
Oder auch für andere Geschichten,
Services, die man da benutzen kann, damit halt sozusagen andere
unter
mehr oder weniger unter der Domain auftreten
können.
Das würde ich auf jeden Fall auch machen. Ich möchte ja gerne ganze
Projekte unter unterschiedlichen Domains, die ich mir
dann irgendwie buche, vielleicht auf einen größeren
Server legen und die dann irgendwie da reinrouten.
Ja, das ist immer ein anderes Problem,
das geht natürlich auch, aber allein
ist gut, DNS unter Kontrolle zu haben.
Jedenfalls, also man muss nicht
unbedingt einen eigenen Nameserver betreiben, das mache ich
teilweise noch, aber das ist auch irgendwie
eher schmerzhaft.
Weil man hat auch direkt so mit Security
Geschichten oft, dann gibt es
so diese komischen DNS Amplification
Angriffe und blöde
Geschichten und so Zeugs, mit denen man zu tun
kriegt.
Ja, aber
also
man will das eigentlich, glaube ich, nicht unbedingt
selber betreiben, wenn man da nicht Spaß dran hat.
Aber trotzdem möchte man
die Records bestimmen können, weil das
für viele Services, die man sonst so benutzen
möchte, halt auch wichtig ist.
Ich glaube, damit sind wir aber mit DNS im Grunde durch.
Ja, jetzt kommen wir endlich auf einen Server. Jetzt haben wir so einen Server, der hat
dann irgendwie nur so eine IP und dann
wissen wir noch gar nicht, dass 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.
Es gibt sogar so die DynDNS,
das heißt, wir könnten sogar zu Hause einfach einen Rechner ans Netz
hängen oder so.
Ja, aber dann musst du dann Games aber
selber betreiben, irgendwie, wahrscheinlich.
Ich glaube, es gibt so einen Service, da muss man immer nur
sagen, hey, ich bin jetzt hier, ich bin jetzt hier, ich bin jetzt hier.
Ja, ja, klar. Es gibt auch in vielen
Routern ist das eingebaut, zum Beispiel eine Fritzbox
macht das. Dem kann man einfach
sagen, so, das ist mein DynDNS-Anbieter
und dann
kriegt man halt immer eine entsprechende,
dann macht die das automatisch.
Wenn sich die IP-Adresse ändert, dann schickt die halt
irgendwie ein Request dahin und sagt, okay,
findest mich hier, hallo. Genau.
Und dann kann man auch sein Kram zu Hause
immer erreichen, ja.
Wobei man da wahrscheinlich eigentlich eher
sowas wie ein VPN verwenden will, aber
DynDNS geht auch. Aber ist eigentlich
heutzutage alles nicht mehr so richtig relevant, glaube ich.
Ja,
genau. Also wenn man DynDNS unter Kontrolle
hat, dann kann man halt jetzt, wenn man
jetzt einen Server hätte,
irgendwo, der unter der IP
verfügbar ist, dann
kann man sozusagen
die Domänen darauf zeigen lassen.
So, und jetzt ist die Frage, was für ein
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
zwei bis, weiß nicht, wahrscheinlich 200, 2000
Euro im Monat. Ja, das kommt auch an.
Also, was man damit vorhat, für die
meisten Leute wird
irgendwie da weniger, wahrscheinlich eher
mehr sein. Also, es wird wenig reichen, weil
Ja, es gibt ja auch so
WordPress-Hosting-Anbieter oder sowas.
Da kann man wahrscheinlich nichts anderes machen, außer ein WordPress-
Blog drauf.
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
schon selber tun
können. Also, es gibt auch eben
für Python-Hosting nicht
so viele Anbieter, die da
Was ist denn jetzt Python-Hosting?
Weil ich dachte, da läuft jetzt ein Computer.
Genau, ja. Das ist halt, also bei
WordPress ist halt klar, das ist halt die Software.
Sowas gibt es natürlich für bestimmte
Python-Geschichten
auch. Also, es gibt zum Beispiel, muss ich
jetzt nochmal nachgucken, habe ich letztens irgendwie gesehen, wenn man
jetzt einfach nur ein CMS haben will unter der
Domain, da gibt es da auch Anbieter.
Diego, Diego, Diego, ich weiß
es nicht mehr, muss ich mal nachgucken.
Die bieten an, dass man irgendwie ein
Wagtail-CMS oder halt
ein Django-CMS
bekommt, da
gehostet und das ist dann so ähnlich wie
WordPress-Hosting. Also, so. Okay, das läuft ja auch
im virtuellen Container irgendwo.
Nee, das, ja, das weiß ich
nicht, ob die da ein 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 in manchen
Feldern versucht, irgendwas einzugeben, dann kommt da eine
Liste der User hoch oder so. Da kommt
ziemlich wildes Zeug hoch. Das heißt, ich gehe mal davon
aus, dass es nicht irgendwie pro
Domain oder so gekapselt, sondern das
ist halt eine Datenbank, auf der alle sind. Und dann gibt es halt
unterschiedliche Sites. Und
das ist ja auch durchaus vernünftig unter Umständen.
Also, du brauchst
nicht unbedingt einen Container für
eine eigene Seite. Da ist es
gar nicht nötig. Ist ja bei
WordPress-Geschichten wahrscheinlich auch nicht so.
Und
genau, das
gibt durchaus da auch Anbieter, aber das sind viel weniger
als jetzt im PHP-Umfeld oder WordPress oder so,
wo 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, sie heißen alle so Platform-as-a-Service-Anbieter
sich anguckt.
Also ganz oben wäre sowas wie eben,
du kriegst halt irgendwie
dein Backtail-CMS und hast dann halt
ein fertiges CMS unter deiner 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, das wäre wahrscheinlich Software-as-a-Service
mehr oder weniger Modell. Dann
Platform-as-a-Service ist, naja, du
ähm
sagst nicht, du kriegst jetzt nicht eine fertige
Webseite sozusagen, schlüsselfertig
äh, sondern
du kannst eine fertige Webseite, ja,
sondern du kriegst halt irgendwie
äh, du hast halt einen Account bei Heroku
oder sowas, also Anbieter wären das sowas wie Heroku
oder Python Anywhere oder so.
Und ähm, da
äh
Ich vergleiche mich mit diesen Häusern unheimlich toll.
Mit den Hochhaus-Hinz-Stellen und Gartenhütte, ne?
Ja, also sag mal so,
das ist halt, äh
äh, im Grunde
ja, da, da sind das dann oft wahrscheinlich
Container, die da hochgefahren werden, äh, und
du hast halt solche Dinge wie Datenbank, ist halt
schon einfach irgendwie mal nicht da. Du wohnst in einem Hotel.
Du musst wohnen, dann gehst du unten in die Lobby.
Es ist quasi so eine Art Hotel, ja.
Ich weiß nicht, ob diese Analogie trägt, also
wenn, wenn Software-as-a-Service, also wenn
die, wenn diese... Ich war konziersch, ich hätte gerne einen
Kaffee. Ja,
was wäre denn dann, was wäre denn das fertige,
die fertige, das fertige WordPress, dass man
sich nur noch einloggen braucht?
Da ist der Pool schon vorgeheizt und
äh,
ich würde sagen, das ist doch eigentlich eher das Hotel, oder?
Wo man halt sich um nichts kümmern muss und das...
Und Heroku ist die Ferienwohnung, wo du selber kochst.
Ja, und Heroku ist so ein bisschen die,
es ist eher so, äh,
nicht mal das, es ist eher so
der, äh,
die, die, die Schuhkarton-
Eigentumswohnung irgendwo, das ist halt 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. Ja. Ähm,
da kannst du halt sagen, okay,
ich deploy da halt irgendwie
ein Flask, äh, ja,
Flask-Ding hin oder halt eben, äh,
ein Django, äh, hin oder so.
Ähm,
äh, aber du bist da halt nicht festgelegt, ja,
also auch nicht auf, äh, ja.
Und, ähm,
ja,
äh, äh, aber
diverse andere Geschichten werden dann schon abgenommen, ja,
also man kümmert sich sozusagen nur noch um
den Teil, der halt, wenn man alles selber machen würde,
äh, im Applikations-
Server, jetzt nenne ich das mal so, äh,
äh, laufen würde, äh,
um, um den Applikationsteil kümmert man sich, ja, aber
sowas wie Datenbank, das macht man nicht selbst, da gibt's dann halt
und es gibt auch endlos viele andere Plugins
und Dinge, die man dazuklicken kann, äh,
Suchmaschinen oder
irgendwelche, irgendwelche anderen, äh, Sachen, die man halt
auch verwenden kann und das muss man alles dann nicht selber machen
bei, bei Heroku jetzt beispielsweise, sondern das
ist halt dann einfach da. Ähm,
und man kümmert sich nur um die
Applikationen, die man dahin deployt und, äh,
natürlich definiert man irgendwie die Datenbank
dadurch, dass man jetzt in Django beispielsweise die ganzen
Modelle halt irgendwie, äh,
ja, definiert und, äh, die werden dann halt auch
in der, in der Postgres, äh, irgendwie
eingelegt, aber man betreibt die Postgres-Datenbank nicht
mehr selber, sondern das macht halt irgendwie, äh,
macht entweder Heroku oder einer von den Drittanbietern,
die halt ein Postgres-Plugin
für Heroku anbieten, für einen.
Was natürlich dazu führt, dass es
wesentlich weniger, äh,
aufwendig ist für einen Server.
Ähm, aber man ist halt auch so
ein bisschen eingeschränkt und, ähm,
diese Geschichten führen halt oft dazu,
also, äh, ich hab das tatsächlich mal
versucht, weil ich hab versucht für, äh,
äh, es ist ja auch sowas, ne, wenn man,
wenn man... Das klingt nicht nach einem gelungenen
Experiment. Ja, für Django, Django
Cast jetzt diese, wollte ich einfach mal so,
wie ist das denn, wenn man das jetzt auf Heroku mal deployen will,
zum Testen, damit man es halt draußen irgendwo, äh,
laufen hat, aber, äh,
ähm, ja,
man möchte jetzt nicht vielleicht irgendwie so ein Commitment,
äh, eingehen, da jeden Monat Geld zu bezahlen
oder so, das, oder hat halt dann auch keinen
Root-Server irgendwo rumstehen, den man benutzen könnte.
Darauf kommen wir irgendwie später wieder.
Ja, dann, dann wäre es doch ganz praktisch,
wenn man das einfach mal nach Heroku oder, oder so die
pläut und dann mal guckt, wie das so funktioniert.
Dachte ich, das wäre eigentlich ganz nett und zumal
halt all diese Anbieter alle so freie
Container anbieten, die also
für Hobby-Benutzung oder so,
die halt nichts kosten, äh, die dann auch
bestimmte Anforderungen nicht erfüllen,
beziehungsweise keine garantierte, äh, die sind beim ersten
Laden oft langsam, weil das ist wahrscheinlich
unten drunter irgendwie
Docker-Container oder vielleicht benutzen die dann irgendwie
Lambda-Funktionen
bei AWS oder so, wer weiß.
Ja, genau, das sagst du ja schon wieder.
Äh, nein, nein, ich bin mir noch mal auf...
Äh, äh, also
da kann es sein, dass der Container erst gestartet wird, wenn man,
wenn so ein Request reinkommt und dann ist das halt ein bisschen
langsam und doof und, äh, aber
es stört ja nicht, wenn man, äh,
wenn man das eh nur so
mal ausprobieren möchte, ne, und, ähm,
ja, äh,
und dann hab ich da, mich da gemacht,
da so ein bisschen eine Anleitung für zu schreiben und dann
ist mir relativ schnell aufgefallen, es ist,
ist es nicht so einfach, äh, und ich war
überrascht, wie, wie knifflig das ist und ich bin immer noch
ein bisschen überrascht, äh, dass auch Heroku
da, da keine gute Anleitung für hat, wie, wie macht
man das eigentlich, so machen die nicht nur Python, die machen auch
Ruby on Rails und, und, und auch
Node.js und weiß der Teufel, aber
trotzdem, es ist schon, äh, irgendwie, es war
schwerer, als ich dachte und ich dachte mir so, ui,
also, äh,
hm. Ja, wenn der Jungen daran knabbert, dann
weiß ich jetzt nicht, ob ich jetzt anfänge, unbedingt
mich da so reinstürzen
möchte. Also, ich meine, auch dieses Django for
Professionals Buch kann man sich auch mal angucken, auch der,
äh, obwohl Vincent meinte es schon so,
das ist alles irgendwie immer, also die Sachen so hinzukriegen,
dass sie dann tatsächlich funktionieren, so, ist oft
schwerer, als man so denkt und es war echt
nicht mal ganz einfach. Das Containerschiff ist vielleicht
überladen und hat irgendwie halbe Schlagzeit, 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 find's, das mag
daran liegen, dass ich das häufiger selber
mache, äh, irgendwie, ich fand es einfacher,
das selber zu machen, als bei Heroku
und das, weil man stößt halt sofort
auf so Probleme, gut, kann auch sein, dass mir das,
vielleicht ist das vielen Leuten egal,
aber ich denk mir halt so, naja, heutzutage, Webseite
ohne SSL, das ist eigentlich eher kaputt. Also,
es muss eigentlich, SSL muss irgendwie gehen
und eigentlich ist das ja auch kein Problem mehr mit
Let's Encrypt und so, aber
für die Hobby-Seite
bei Heroku, bei
denen, ähm, 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 tief graben
und ich bin in irgendwelchen Issues gelandet, wo dann
einer von den Entwicklern bei Heroku dann irgendwie
schon, puh, sollten wir vielleicht mal in die Dokumentation
schreiben, dass das wirklich nicht geht. Also, auch mit
diesem Weg geht das nicht und, äh,
da dachte ich schon so, ja, solltet ihr vielleicht, weil
irgendwie, ich hab jetzt grad da irgendwie ganz schön
Zeit reingesteckt, das rauszukriegen,
also, weil es sah so aus, als würde es vielleicht doch funktionieren, wenn man
dann irgendwie die Zertifikat von Hand hochlädt oder so,
nee, tut's nicht. Und dann hab ich mir erst
da lokal irgendwie Z-Bot installiert
und da irgendwie auch rumgeeiert und, ja,
aber es ging dann alles am Schluss nicht.
Also, SSL hatte TPS,
Heroku nur, wenn man zahlt, sonst geht's nicht.
Und, ähm,
ja, äh, auch die, ähm,
wenn man jetzt irgendwie
ein CDN verwendet oder so,
äh, Content Delivery Network, ja, da müssen wir auch noch mal
rechnen. Ja, da kommt alles noch dazu.
Ist alles... Anfängerfreundliche
Folge, Jochen. Ja, ist alles nicht so
einfach. Auf jeden Fall, man, also, ich meine, man
kann sich das ja mal angucken, wenn man
jetzt auf HTTPS nicht so viel Wert liegt
oder, äh, dann kriegt man auch
mit Heroku wahrscheinlich schon halbwegs
schnell da irgendwie zum Ziel, ob
ein anderes Alternativ ist, gibt, glaub ich, noch
ein paar. Ähm,
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,
äh, also, man muss sich nicht,
äh, ähm, selber dafür interessieren,
wie das Zeug jetzt, äh, ob das oben ist
oder nicht. Also, das macht halt,
äh, jemand für einen und
das ist ja auch schon mal nicht so schlecht.
Ähm, ja,
äh, das wäre sozusagen eine
Zwischenschicht zwischen irgendwie
alles ist fertig und... Hört sich nicht so an, als würde ich
das machen wollen, ehrlich gesagt. Doch, also, ich kann mir
durchaus vorstellen, dass es gute Gründe gibt, das zu
machen. Äh... Nee, für mich nicht.
Ja.
Nach der Geduld, wo wir sind ausgeschlossen, ja.
Für dich jetzt nicht, aber, äh, ich denke schon,
dass es für mich, aber, oder es gibt, was
auch oft eine Falle ist, dann, wenn, wenn, wenn
Startups irgendwie anfangen mit sowas, dass sie dann
irgendwann doch viele Datenbank, äh,
äh, Queries machen und da sind auch, äh,
das, 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, äh,
das ist auch so etwas, was man vielleicht nicht, nicht unbedingt
haben will. Aber das Problem ist, wenn man dann gerade wächst
oder so, dann kann man nicht mehr so schnell
irgendwie... Und die Infrastruktur komplett umfassen.
Ja, ja, und dann gibt man halt ein...
Vermögen. Dann gibt man Arm und 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.
Ähm,
ja, also das ist eine, eine Möglichkeit, die man halt
auch machen muss. Ja, jetzt müssen wir aber noch mal ganz
kurz, bevor wir das alles wieder vergessen haben, kurz eingehen
darauf. Quantitative Network, du musst auf dem
Geschirr auch schon noch mal kurz erklären. Und, äh, AWS
Lambda-Funktion. Ja, also, also wenn wir jetzt
bei, wir sind jetzt bei, also, so sagen
wir jetzt der Grund der Software-as-a-Service, Plattform-as-a-Service.
So, jetzt wären wir quasi das Nächste,
was nicht mehr, das, wo man ein bisschen mehr
Freiheit hat, aber, äh,
ähm, sozusagen immer noch,
äh, nicht so viel selber machen muss,
wäre dann Infrastructure-as-a-Service.
Also das wäre dann halt sowas wie,
ähm, ja,
Amazon EC2.
Ähm,
DigitalOcean.
Also da, äh, bekommt
man im Grunde, äh, ja,
einen Container, auf dem irgendein Linux
oder so läuft, wo man sich einloggen kann als, als
Root per SSH. Und dann
ist man auf sich alleine gestellt. Da muss man, man,
den Rest macht man dann halt selber. Ähm,
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,
äh, ganz nette
Geschichte. Welches Linux nimm ich denn da?
Fedora, Ubuntu, Debian?
Spielt im Grunde keine große Rolle,
würde ich jetzt mal so sagen. Also, äh,
äh, ich,
vielleicht. Gibt es kein System, das besonders gut Python
unterstützt oder so? Nee. Nee, das
System Python kann man in keinem von den Fällen verwenden.
Da, ja. Das ist egal.
Muss man eh immer neu installieren. Oder selber installieren.
Ähm.
Hat Fedora jetzt nicht drei standardmäßig alles schon
drin? Ja, trotzdem, nee.
Wie wäre das? Barry Warsaw hat
das mal auch auf Twitter geschrieben, so,
First rule of Python is you don't use system, don't use
system Python.
Du musst ja immer dein eigenes Python installieren.
Das ist kein Spaß. Ähm,
ja, also, äh,
genau, also insofern würde ich sagen,
also der einzige Unterschied, den ich noch sehen würde, der
relevant ist, ist einmal, welches Paket
Management System einem irgendwie besser oder
schlechter gefällt und, ähm,
ob man System D mag oder nicht.
Weil, äh, genau, wenn man das
mag, dann kann man das ja benutzen und da gibt's halt
Unterschiede, je nachdem, welche Distribution man verwendet.
Also System D, du brauchst dann sowas wie Logging
ab oder sowas, das mag man vielleicht nicht, oder?
Ja, aber auch vor allen Dingen sowas wie, wie, wie sorgt
man eigentlich dafür, dass der Kram, den man, äh,
laufen haben möchte, eigentlich läuft und
am Laufen bleibt und so. Das, ähm,
ja, äh, kann man über
System D auch machen. Ähm,
kann auch irgendwas anderes nehmen. Äh,
ich nehm öfter Super-Wise-D,
äh, aber es ist auch,
im Grunde ist das nicht alter.
Was war ja, äh, Init, äh, was, äh,
F, Init, System 5?
System 5, ich weiß nicht genau, Init-Files,
äh, es gibt da auch andere Konzepte,
wie man, ja, also System D hat schon
nette Konzepte, aber es ist halt auch,
es hat da so manchmal so...
Vielleicht hat da irgendwie eine ganz spannende, äh,
Folge dazu nochmal gehört, irgendwann, äh,
die fahren irgendeinem Chaos-Radio-Express
mit einem von den Developern da,
irgendwie, das war schon ein bisschen... Ja,
äh, na, wer ist da noch?
Äh, ja, Namensgerechtes,
keine Ahnung. Ja, genau.
Äh, ja.
Okay, also völlig egal, welches System, also ich hau mir dann
Fedora und Ubuntu drauf, zum Beispiel, weil ich
das so ein bisschen schon kenne oder so,
dann irgendwie, dann mit den Repos schon ein bisschen weiß,
wo ich meine Pakete finde und dann
ist der To oder warum sollte ich das tun?
Warum nicht direkt einen eigenen Server? Also...
Ja, genau, weil halt auch da dir das natürlich
abgenommen wird, dass du dafür sorgen musst,
äh, dass das Ding ordentlich läuft oder so.
Ähm,
du...
Ja, du musst dich um viele Dinge nicht kümmern,
die du sonst tun müsstest.
Ähm, und, ähm...
Ja, dieses ganze, also,
alles, was mit irgendwie Netzwerk zu tun hat...
Steckereien stecken, Strom... Genau, dass das Ding
immer oben bleibt, äh, irgendwie Betriebssystem-Updates,
weiß ich gar nicht, noch nicht stimmt, das muss man wahrscheinlich noch selber machen.
Ja, genau, ich meine, Managed Server, glaube ich,
heißt das oder sowas? Ja, das will man alles,
wahrscheinlich eher nicht, aber, äh, genau.
Ja,
aber man muss sich, also schon um
wesentliche Teile der Infrastruktur jetzt bei
so einer Geschichte nicht kümmern. Also, im Grunde ist
halt der Container wie der andere, und
das funktioniert einfach so, ne, und dann...
Also, das ist schon, das ist schon auch nett,
aber man zahlt natürlich auch einen Preis,
das ist halt schon teurer, als wenn man jetzt, äh...
Und dann, es gibt nochmal so superbillig, äh,
äh, superbillige, äh,
äh, Geschichten auch immer, also die,
ich glaube, die kleinsten Container,
wenn die durchlaufen sollen, die kosten dann irgendwie
ein paar
10 Euro im Monat oder sowas, ich weiß es nicht genau.
Äh, 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, äh,
DigitalOcean gibt es das auch, also,
und selbst bei sowas wie, äh,
so ein Husabee-Hetzner, also kriegt man irgendwie
einen Container, der, der durchläuft,
ähm, für
2,50 Euro oder 3 Euro oder so wenig
Geld im Monat, und hat dann ein richtiges
Linux mit, wo man sich als Root einloggen
kann, ist schon natürlich ganz nett.
Und das will man wahrscheinlich sogar auch tun.
Ja, äh, hängt dann davon ab, dass 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
leider nicht. Aber, äh,
ja, so, so eine feste Installation...
Aber wann braucht man denn eine fette Datenbank?
Also, so, jetzt als, äh, Datenmensch
muss ja wissen, ab wie viel Traffic man da so irgendwie...
Nee, das hat mit dem Traffic gar nicht so viel zu tun, sondern eher
viel damit zu tun, wie viel Daten es sind.
Weil du willst, dass dein, äh,
Working Set im Hauptspeicher ist. Und das heißt,
wenn du halt irgendwie ein paar Gigabyte, äh,
Daten hast, dann willst du halt ein paar Gigabyte
Hauptspeicher haben, mindestens mal. Ja, so oft wie zu viel.
Oder so. Also ungefähr doppelt so groß
wie mein Dataset sollte der Hauptspeicher dann sein.
Ja, also, später geht das dann irgendwann
nicht mehr, aber, äh, ja,
sollte schon da reinpassen.
Ähm,
und das, äh, die haben alle
wenig Hauptspeicher natürlich, weil die teilen sich, die sind halt
auf großen Maschinen meistens, aber es sind viele
kleine Container, und dann muss halt irgendwie,
wenn die alle vier Hauptspeicher verbrauchen, ist
halt natürlich irgendwie der Hauptspeicher weg.
Wie kompliziert wäre es denn jetzt da,
weiß nicht, wenn man jetzt mehrere kleine
Services auf so einem Ding laufen lässt,
einen von denen umzuziehen?
Auf eine größere Maschine.
Oh, das ist, ja, da
bist du dann schon, das ist alles nicht mehr so einfach.
Ich würde auch das nicht so machen,
dass ich die Sachen da direkt laufen lasse.
Kann man auch tun, aber
ich würde eher sowas wie Docker nehmen.
Tatsächlich.
Also das heißt, du würdest dann auf einem dieser
Cloud-Dinger einen Docker
bauen, installieren
oder... Docker installieren, Docker-Demon
starten und dann halt
mit so einem Docker-Compose-File
das komplette System hochziehen, sodass dann
halt für jeden Service, den man benutzen
möchte im System, das man
da hochfährt, dass man dafür einen Container
hat, also einen Container für die Datenbank,
man hat einen Container für Redis...
Und man teilt sich dann genau die Dinge auf, also kann man
Docker so einstellen, dass der für alle verschiedenen Systeme
unterschiedliche Hardware nimmt, weil...
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, du willst das...
Also das ist auch gar kein Problem, also
das musst du nicht
machen, also... Also Kubernetes ist eine
Krake an Docker-Containern.
Ja, das ist so ein bisschen, das
Problem mit Docker ist halt, dass
das zu betreiben ist halt
fies, Netzwerk ist fies, das ist alles...
Das entwickelt sich auch alles noch, das ist
alles nicht so richtig
gefestigt, das ist nicht ganz so
schlimm wie jetzt
bei den JavaScript-Frontends
bei React oder so, aber
es ist schon, es ist nicht
so, also man kann sich da nicht so gut drauf verlassen
und vor allen Dingen fehlt die Unterstützung für viele Sachen,
und dann gibt es da eben dann,
wenn man das im Großen, wenn man
eine komplette Cloud irgendwo betreiben möchte
oder so, dann nimmt man da andere Geschichten,
Management-Geschichten für, da wäre
jetzt Kubernetes ein Beispiel für, aber
die Frage ist, ob man das braucht, und wenn du das selber
irgendwie nur ein System, das brauchst du nicht,
also würde ich jetzt mal anfangen,
würde ich jetzt einfach so sagen, brauchst du nicht.
Ja, also ich habe da bestimmte Voraussetzungen tatsächlich, also ich möchte so
verschiedene Webseiten betreiben,
irgendwie, ne, irgendwie private Sachen, dann
hatten wir mal über Indie-Web besprochen, dann
irgendwie sind die beiden Services da drauf, und dann vielleicht noch
irgendwie eine Firmen-Webseite mit einem kleinen Login
und vielleicht noch für IoT so ein bisschen
so ein Server, der da irgendwie läuft
und das irgendwie alles gerne parallel, und
ja, das ist ja kein Problem.
Wie baue ich das denn? Also wo fange ich denn da an?
Also ich habe jetzt so einen Server dann Cloud
am besten gemietet, oder vielleicht doch irgendwie
so einen dedizierten irgendwo hingestellt, oder
nur einen kleinen virtuellen genommen, oder?
Das hängt halt wieder davon ab, also ich würde einfach mal,
also nur um das halt auszuprobieren,
würde ich mit so einer kleinen Geschichte anfangen.
Ja, aber das ist meine Frage nach dem Umzug,
also wenn ich dann merke, so, oh, um
zu ziehen, irgendwie alles normal machen, also das ist ja
Nee, musst du nicht, das ist ja, dafür hast du ja
deine Domain registriert.
Ja, aber den Server muss ich ja umziehen, also die ganzen Sachen muss ich ja
nochmal konfigurieren. Ja, aber dann nee, dann
musst du gar nichts machen. Wenn du Docker nimmst,
hast du dieses Problem gelöst.
Achso, also ich baue den Container einfach
neu auf einem anderen System.
Ja, genau, sagst du einfach auf dem anderen System
docker-compose, dann docker-yaml-file,
ab, fertig.
Nicht mal das, also gut,
man würde das jetzt nicht von Hand ausführen, sondern
man würde dann halt irgendwie das System, die an
hängen oder in Supervice-D,
normalerweise die Konfiguration dafür
legst du auch in dein Projektverzeichnis mit rein,
linkst das
nur noch nach etc.supervice-d.conf
oder weiß ich, wo die
Config-Files dafür liegen, startest das Ding
einmal neu und dann startet der deinen kompletten
Kram, ohne dass du noch irgendwas machst. Also wie gesagt,
wenn ich auf dem Server das deploye,
da muss ich einen Link
ziehen, ich muss
etwas an der Caddy-Config
ändern, das machst du, dann startest du neu, fertig.
Caddy ist jetzt dieses,
also ich muss da irgendwas rein, ist die Reihenfolge
entscheidend, wie das da drin hängt, weil die dann nacheinander
gelaufen, wie verteilt der die
Ressourcen verteilt, also wie viele er hat.
Ja, also gut, das ist nochmal
ein anderes Thema.
Wir sind zu weit, wir sind zu weit.
Ja, also es ging nur
darum, wie kriegst du das Zeugs
irgendwie auf einer Maschine zum Laufen
und da
würde ich empfehlen, heutzutage Docker zu nehmen.
Man kann auch andere Sachen benutzen, aber
background. Ja, man könnte auch
background, aber das ist auch, es 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 performantechnisch sehr fies, also
in einem Container nochmal Container-Geschichte
zu starten, ist vielleicht auch nicht so die
schlauste Idee performantechnisch, 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.
Und du kannst natürlich darin alles
wieder betreiben, du musst dann nicht das
in einzelne Container aufhalten, aber
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 diesen Container, alle deine Services, die du
so haben willst, starten.
Du kannst halt zum Beispiel,
auch das benutzt man eher für größere
Infrastrukturen, um da halt
komplette Systeme auszurollen.
Das ist eigentlich so Automatisierung
deiner
Automatisierung deiner
Infrastruktur hochziehens,
so nennt man sowas wie Ansible oder so,
es gibt auch noch diverse andere, es gibt Solstack, es gibt
irgendwie
Puppet Chef,
aber Ansible wäre jetzt auch Python
und damit
verwaltest du quasi
ein ganzes Inventory an Rechnern
irgendwie und sagst dann, roll mein
System aus und dann, das Ding braucht auch nur SSH,
dann connectet es sich auf all die Systeme per SSH
und
macht dann 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 deinem Vagrant, in deiner virtuellen Maschine
halt auch zum Laufen kriegen, das heißt, du musst da irgendwie die
entsprechenden Pakete installieren, musst du die Services
hochfahren, musst die Config-Files irgendwie
mit Templates so
irgendwie, also hast du 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, hab ich auch schon
gemacht und so,
aber das ist eine Menge Arbeit, also das ist nicht
so ohne und das dann auszurollen dauert
auch ziemlich lange.
Das ist halt auch so ein Nachteil
gegenüber Docker, also das ist halt
irgendwie so ein komplettes
Ding mit Vagrant hochzuziehen, kann sein, dass das
selbst wenn du einen schnellen Rechner hast, lokal, kann sein, dass
das 20 Minuten dauert, wenn du so viele
Maschinen hochfährst oder so. Kannst natürlich auch alles
in einer Maschine haben, aber dann hast du wieder das Problem, du kannst es nicht mehr
aufteilen, wenn du es jetzt
auf andere Maschinen aufteilen wolltest und 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
ein Python-Trepper drumherum, der da irgendwas mitmacht
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 Build
für, weiß ich jetzt
CPU-Power, je nachdem
CPU-Power und Platten und Netz man hat
aber so bei mir dauert das, ich hab
also Standard-Django-Projekt
hat bei mir irgendwie die Datenbank
Redis, irgendwie
Applikationszauber-Django, vielleicht noch
Celery oder so, also 5, 6 Container
irgendwie sowas, die alle
neu zu bauen, wenn man jetzt zum Beispiel
eine Abhängigkeit im Betriebssystem, also
sagen wir mal, jetzt irgendwie
auf Betriebssystem-Level 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
ja
zwei bis drei Minuten, lokal
je nach Größe der Anwendung natürlich
je nach Größe der Anwendung, aber das ist
ja, die Anwendung
selber, die Django-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 10 Mal
was anderes ausprobieren, weil
oft muss man, bleibt einem nichts übrig, als Sachen auszuprobieren
ob es jetzt so geht, ach scheiße
der Python-Wrapper funktioniert nicht, muss einen anderen nehmen
probier den nochmal aus
wenn du da 10 Mal irgendwas ausprobieren möchtest
und du hast immer eine
20 Minuten Latenz dazwischen ist, das
macht einen langsam
Du hast gerade gesagt, im Stack von dir gehört
noch eine Redis, das ist ein Cache, da hat man
irgendwie 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
Nee, also es gibt noch
wenn du jetzt statische Files cachen möchtest
das würde man auf einer anderen Seite machen
also Redis ist etwas, die
also wenn ich jetzt zum Beispiel
in Django eine Funktion habe, die
irgendwas lange
berechnet oder so, dann ist fertig
dann schreibe ich darüber
irgendwie Cache-Property oder so
zum Beispiel in Django, um zu sagen
in Django zu sagen, cache das hier mal bitte, weil
ich will das nicht jedes Mal, wenn dieses
diese Property
jemand, wenn jemand
darauf zugreift, möchte ich nicht, dass es jedes Mal neu berechnet wird
oder es soll nur einmal berechnet werden
und dann im Cache landen. Und dann verwende ich diesen
Dekorator und dann landet
das im Redis. Also wenn ich jetzt Redis
konfiguriert habe, als das ist der Cache
für meine Django-Applikation.
Für sowas ist es gut. Man kann Redis auch noch
für diverse andere Geschichten verwenden.
Und
wenn ich jetzt sozusagen
die statischen Files cachen wollte
in Memory, das kann auch durchaus Sinn machen, aber das
würde ich an einer anderen Stelle machen. Und zwar
vorne dran, vor dem Django.
Vor dem Applikationsfang.
Da würde ich
den Varnish nehmen oder so. Das ist so ein
In-Memory-Cache,
den man
davor hängt. Und
der würde halt
sozusagen alles, was an statischen Files geht,
die da durchgehen, halt
In-Memory-Cachen.
Oder überhaupt alles, was an statischen Assets drin ist.
Oder auf andere Sachen auch.
Überhaupt alle
Dinge, die identifizierbar
sind als cachebar über die Cache-Header.
Und das wäre
dann viel, viel schneller.
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
Stack nochmal komplett durch.
Also das, was davor ist. Und das ist auch etwas, was leider
nicht in dem
Docker-Geschichten selber mit, also
sagen wir mal so, wenn man jetzt Cookie-Cutter
verwendet, um ein Django-Projekt
zu erzeugen, dann ist der Caddy schon
mit drin. Aber man
kann das oft nicht verwenden, wenn
man das jetzt auf irgendeine Maschine da draußen
deployt oder in einen Container,
auf den man sich per Route einloggt.
Weil, wenn man da jetzt zum Beispiel mehrere Domains
hat,
die man
da ausliefern will,
dann muss der Caddy
halt unabhängig von den
einzelnen Systemen sein, sonst geht das halt nicht.
Und was macht der Caddy denn jetzt?
Und wie hat er noch, im Celery hattest du noch eventuell,
ich muss da auch nochmal kurz.
Ja, also Caddy ist ein grob geschriebener
Web-Server,
der
besonders schön integriert ist mit
halt Let's Encrypt, sodass halt HTTPS,
also SLL, TLS kann
halt ohne, dass man da irgendwie viel konfigurieren muss,
ohne dass man irgendwie Startboard selber
irgendwie verändern muss.
Und also
es ist so,
ja, HTTPS funktioniert einfach magisch
und man muss sich nicht mehr kümmern.
Das ist also der Effekt,
was ja ganz nett ist.
Und
der ist auch sonst relativ schnell, der ist nicht ganz so schnell
wie Nginx oder so, aber
ich meine, ob das Ding jetzt, weiß ich nicht, 10.000
Requests pro Sekunde kann oder nur 5.000,
macht für die allermeisten Leute überhaupt keinen Unterschied, weil
sie haben nicht mal ein Request pro Sekunde,
ja, ist egal.
2, 3, 4, ja.
Ja, aber selbst bei 100 ist es völlig wurscht.
Und, ähm, ja,
und das ist dann gut geschrieben, vielleicht ist das Ganze auch noch ein bisschen
vertrauenswürdiger als, wenn ich meine Nginx
C und so, hm, wer weiß.
Ähm, aber,
naja, eigentlich ist es wurscht. Also was für mich
den Ausschlag gibt, den zu verwenden, ist halt
die schöne Let's Encrypt-Integration.
Und, ähm,
ja, der ist sozusagen vor den,
vor Django davor, halt eben um sowas
wie Statisch-Falz ausliefern, weil das kann halt Django
nicht so gut selber. Wobei, muss man auch einschränken
und sagen, äh,
mit White Noise ist das vielleicht nicht mehr so gut,
ganz, äh, aktuell, ähm, aber,
äh, was ist White Noise?
Oh Gott.
Das ist, äh, ein,
hm, ja, äh,
äh, ich weiß nicht,
das gibt es nur für Django, es ist, auf jeden Fall,
innerhalb von Django kann man das als, kann man das, äh,
als, äh, 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,
ja, von der Platte in den Hauptspeicher und dann
von dem Hauptspeicher schickt man es wieder durch,
äh, äh, durch den
Kernel-Space irgendwie da raus über die
Netzwerkkarte und
da wird viel, viele Daten werden da kopiert
und, äh, das ist alles scheußlich und man blockiert
einen, ähm,
Worker-Prozess.
Hängt auch viel davon ab, welche, welchen Applikations-
Server verwendet, Junicorn,
Micro-Whiskey oder My-Whiskey
oder WSGI oder so, also,
das ist alles der gleiche, ich weiß nur nicht, wer ausgesprochen wird.
Ähm, äh,
man muss ja irgendeinen, irgendeinen
Applikations-Server verwenden, der sozusagen die
WSGI-Protokoll spricht,
äh, ähm, mit der Applikation
und, ähm,
naja,
äh, also, wenn man, wenn man, wenn man
das File tatsächlich einfach so selbst ausliefert,
äh, dann ist das extrem
langsam und dann ist halt bei wenigen Files
ist dann halt schon direkt Schluss.
Äh, und das ist natürlich etwas, was man,
was man nicht haben will, äh, und
wenn man, wenn der, der Caddy,
äh, oder auch, äh, ein Nginx
kann halt, äh, problemlos viele
Files, äh, irgendwie, äh, ausliefern,
äh, und macht das halt nicht so,
dass er erst die Files in den Hauptspeicher kopiert,
dann durch den User, äh, also vom
Kernel zu den User-Files und dann wieder zurück schiebt,
um das auszuliefern, sondern der
verwendet halt einen, einen Kernel, äh,
ähm, einen syscall, äh,
send-File, um die Files halt raus zu,
äh, sagt halt diesem Kernel
nur irgendwie hier, dieses File, äh,
diese Verbindung bitte sehr, liefer aus.
Sodass das halt, äh,
ja, viel, viel schneller ist, also
der Kernel liefert im Grunde mehr oder weniger die Files aus.
Mhm.
Äh, und, äh, kann ja irgendwelche
Tricks machen, teilweise werden die Sachen
nicht mehr durch den Hauptspeicher, äh, sondern gehen
direkt per Serial-Copy-TCP irgendwie
in den Netzwerkwaffer der Karte
oder so von den Platten aus und so, also
gibt's, äh, crazy, äh,
Shit-Optimierungskrams, der da
gemacht wird, bin ich jetzt auch nicht mehr so auf der Höhe
der Zeit, was halt 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.
Ähm, aber,
äh, eigentlich will
man jetzt auch nicht große Mengen darüber ausliefern,
weil der, der Request ja dann immer noch aufschlägt
im, im Django, ähm,
oder jeder, der Request nach einem File,
und das kann halt viel sein, ja, also wenn man viele kleine Bilder
hat auf einer Webseite zum Beispiel,
wenn man eine Liste mit, mit, äh, von irgendwelchen Dingen,
wo halt immer Bilder dabei sind, dann
ist halt jedes Bild, macht halt ein Request.
Und, ähm, im modernen
Browser machen die ganzen Requests ja auch ein Parallel,
das heißt, die prügeln halt dann auf deine
Applikations-Server ein, und das ist halt, äh,
das ist, äh, nicht so gut.
Und, äh,
ähm, da,
äh, äh,
was, was, ich mach's nicht so,
aber, was wohl gut ist, ist halt, man
verwendet White Noise, und dann da vorne
irgendwie Varnish oder sowas, oder halt
ein CDN, sodass halt beim ersten Mal
werden die Sachen dann tatsächlich von White Noise ausgeliefert,
und danach sind sie halt gecached irgendwo in
Content-Delivery-Network oder halt Varnish
oder so, und dann ist es schnell.
Ähm, was ich mache,
ich, äh, ich verwende
meistens den, den
Webserver eben Caddy oder Nginx vorne dran zum
Aufwählen meiner statischen Assets,
da gibt's halt einen Unterschied in Django,
also statische Geschichten, das ist sowas wie JavaScript,
CSS,
äh, Faf-Icon,
dieser ganze Kram halt sozusagen, der
äh, ja,
zum Projekt halt dazugehört, aber jetzt
sich im Grunde nicht ändert, also das,
das Firmen-Logo, was du immer schon eingebaut hast.
Ja, genau, also wenn man, die, die Sachen werden
dann auch generiert, diese High-Namen, äh,
und dann, sobald man,
äh, da was dran
ändert und dann noch Collect-Static aufruft,
um das halt alles in einen Verzeichnis zu kopieren, das dann halt
von einem Webserver ausgeliefert werden kann, dann kriegen die halt,
äh, unike Namen, sodass das halt, man auch
sagen kann, die werden für immer gecached, weil, wenn es
was Neues gibt, dann wird der eh einen anderen Namen verwendet.
Ja, ähm,
das ist halt, dieses Headlink-Design-Static-Files
ist halt ein bisschen anders, als wenn
jetzt User Bilder hochladen oder so, ne, dann ist
das, äh, Media-Root in Django und
es wird halt, also ein bisschen anders gehandelt und
statische Files sind bei mir, werden
ausgeliefert vom, vom, äh, Caddy
und, ähm, alles,
was User irgendwie an Content hochladen,
äh, landet in einem CDN, äh,
landet in, äh, S3.
In einem Bucket. In einem Bucket. Und
der wiederum wird dann ausgeliefert über,
äh, ich glaub, das ist CloudFront,
äh, das ist auch das, äh, CDN
von, von, von Amazon.
So, dass ich halt auch damit keinen
Stress mehr habe, äh, sondern das,
äh, ja, dann, äh,
das ist dann halt auch
schnell. Ist halt ein bisschen,
ja, muss man vielleicht gar nicht machen,
weiß ich jetzt gar nicht so genau, äh,
aber es ist halt auch eine Lösung.
Das ist natürlich auch eine, ja, genau, das ist dann auch
quasi beliebig. Ja.
Ähm,
ja, Traffic wird halt irgendwann teuer, da muss man
sich...
Ja, aber man muss halt dann
pro, äh, pro, ja, weiß ich nicht,
weiß ich gar nicht, pro Gigabyte oder, weiß ich nicht,
irgendwann bezahlt man halt pro irgendwas.
Man hat irgendwie 100 Gigabyte frei oder so, dann fängt man
irgendwann an zu bezahlen.
2 Euro pro Request.
Ist nicht ganz so schlimm, aber es ist, äh, hm.
Ja, und wenn man das selber macht mit, mit, mit
White Noise und so, kann man wirklicherweise sich da
auch den Traffic sparen, was auch schnell ist.
Ja. Gut, nee, wenn man CDN
drauf vorne ranfen will, auch nicht. Wie auch immer.
Also, genau, das...
Ja, das haben wir auf jeden Fall in den, in den Gango, äh, Applikations-
Server, da hast du gesagt, Gionicorn, irgendwas laufen.
Gionicorn, ja, also ich würde sagen, wenn man, äh, eben nicht,
äh, mehrere Seiten hostet,
äh, dann, äh, sondern
dass er so ein eigenes Projekt hat, was
irgendwie, und der Applikations-Server nur
das, äh, für eine Geschichte macht,
für einen Domain oder so, dann, dann ist
Gionicorn, denke ich, die bessere Wahl.
Ansonsten, wenn es komplizierter ist,
dann, gut, muss man vielleicht, äh,
dieses WSGI-Ding
nehmen, UWSGI.
Das hat, äh, einen Haufen,
äh, Einstellungen, die ja darauf
optimiert sind, dass man, äh, wenn man, äh, wenn man Hoster ist
selber, äh, und dann, ja,
kann man halt auch eine Menge andere Dinge noch einstellen.
Ist aber komplizierter, daher würde
ich das jetzt nicht, äh, nicht direkt empfehlen, auch wenn man
Cookiecutter nimmt, ist Gionicorn dabei.
Ich würde sowieso empfehlen, das Cookiecutter-Giango-Template
zu verwenden, weil das macht eigentlich an der Stelle schon
viel richtig, und, ähm,
ja, äh, da kriegt man
da kommt man da, da muss man sich selber um diese...
Also Cookiecutter ist was, was deine Projekte
automatisch vorkonfiguriert, deployed
oder, oder vorangestellt.
Nee, das erzeugt das Projekt, das erzeugt das Projekt, also es hat
halt, ähm, quasi, es ist ein Projekt-Template
und es fragt einen, wenn man
es ausführt, am Anfang, äh,
so ein paar Sachen, und da antwortet
man halt so, zum Beispiel, wie das Projekt heißt, oder
keine Ahnung, ob man jetzt Celery verwenden möchte oder
nicht, oder so, oder welche Daten man...
Celery hast du jetzt auch noch nicht gehabt, das ist dann wie
Arbeiten, Linen, oder...
Celery, äh, genau, man hat oft,
ähm,
äh, die Geschichte, dass man, äh,
nicht, dass man langlaufende, äh,
dass man langlaufende Jobs hat, die, ähm,
die ausgelöst werden von einem
Web-Request, und man möchte jetzt den User am Ende
aber nicht warten lassen. Also sowas
wie, äh, keine Ahnung,
hm,
ja, User lädt ein Video hoch, und man muss das jetzt in alle
Formate rendern, äh, dass, äh,
die halt so gebraucht werden für unterschiedliche,
fürs iPhone, für Android, äh,
ja, da oft nimmt man dann halt
auch irgendwie anderen Codec oder so,
äh, und in, in unterschiedliche
Auflösungen, je nachdem, wo man das irgendwie anzeigen will,
da möchte man nicht, und diese Render-Jobs
dauern halt, je nachdem, wie lang das Video ist,
sehr, sehr lang, ja, es lädt hier jemand ein Video, äh,
äh, 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, äh,
das ist sehr irgendwie komisch, sondern
dann nimmt man das Video her, sagt, okay, man macht
jetzt einen Task, äh, man erzeugt einen Task,
der, äh, irgendwie dann
unabhängig vom Web-Server läuft,
und der rendert dann halt irgendwie
das Video in die unterschiedlichen, äh,
Formate und so, und, äh,
sagt dem User schon mal, alles okay,
dann, dann upload es durch.
So, und für solche Sachen braucht man das.
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,
und dann... Also das hätte man gemacht, nicht einfach zur Arbeitsbienen
loszuschicken, die dann halt die einzelnen Tasks dann abarbeiten.
Ja, also die Tasks selber, äh, genau, da kann man sich auch
versuchen, welches Backend man verwenden
möchte, und Redis ist halt auch ein Backend,
sozusagen über das, damit Redis
als Queue verwendet, also diese, äh,
es gibt, also, Salary ist im Grunde
eine Task,
ja, es, äh, ähm,
besteht aus, äh, einem
Ding, was irgendwie die Worker koordiniert,
dann eine Menge von Workern,
und halt einer Queue, in die die Tasks
halt reinlaufen, also man, man
so einen Task erzeugt, dann, äh, landet der
halt in so einer Warteschlange, und
die Worker greifen sich aus dieser Warteschlange halt
ihre Jobs raus, ja, sozusagen, das sind Prozesse, die laufen
einfach irgendwie. Wenn wer am lautesten schreit, der wird dann als erstes
bedient, oder was? Genau, ja, das erste,
ja, äh,
der erste Worker nimmt sich halt irgendwie den ersten Job aus der
Queue und rechnet dann halt, bis er irgendwie
fertig ist, der nächste Worker nimmt sich den nächsten
und so weiter, bis halt keine Worker mehr da sind, die nichts
zu tun haben, und dann warten die Sachen in der Queue
halt einfach. Und die werden dann halt so mit der Zeit
abgearbeitet. Und, ähm, ja,
dann hat das Ding auch noch so ein Webfront in Flower, heißt das
irgendwie mit dabei, da kann man sich angucken, was ist denn
jetzt mal so ein Task geworden, haben die irgendwelche Exceptions
geworfen, gibt's da Tracebacks,
äh, sind die alle gut durchgelaufen, wie lang laufen die denn
so, so Basis-Statistiken,
wie lang laufen die denn durchschnittlich,
ja, äh, und all solche Sachen,
und, äh, also
das, wenn's funktioniert, ist es eigentlich
ganz, ganz gut, ja, kann man nix sagen,
ist eigentlich solide Geschichte, es ist
aber so manchmal, also, äh,
im Celery ist es manchmal so ein bisschen scharfkantig,
muss man, das hätte auch schon,
also wenn's nicht funktioniert, ist es nicht so geil,
muss man sagen. Also geht das nicht
für fast alle Dinge bei der Software? Ja,
es gibt manche Sachen, bei denen passiert einem das nicht,
dass die dann nicht funktionieren, also die,
zum Beispiel Redis ist dann so ein Stück von Software, das funktioniert
eigentlich fast immer super, ja,
es gibt selten den Fall, oder hab ich
noch nie erlebt, hab ich noch nie erlebt, dass Redis
irgendwie, äh,
etwas gemacht hat, und ich hab's nicht wieder
hingekriegt, also, ich hab's noch nicht
kaputtgekriegt, sozusagen, oder auch Postgres
ist so ein Ding, das kriegst du nicht kaputt.
Äh, Celery, äh,
hingegen, da installiert
man irgendwie, da wechselt man
irgendwie die Python meiner Version,
und dann geht gar nichts mehr.
Und, äh, alles
kaputt, ja, also,
und das ist, äh,
ja, oder man wechselt die Django-Version und nichts
geht mehr, ne, also es ist halt, äh,
also es ist halt deutlich fragiler, es ist nicht so, dass
man da, das, also bei, bei Celery
hab ich's schon häufig erlebt, dass es kaputtgegangen ist, und zwar
auch dann so kaputtgegangen ist, dass man's im Grunde
nicht mehr fixen kann, und das ist immer ärgerlich, wenn man
dann zum Beispiel eben nicht, Python nicht upgraden
kann, oder halt, äh, auch Django nicht upgraden kann,
weil halt ein Celery dran hindert,
das ist, und das ist schon öfters passiert,
also, ähm,
ja, muss
irgendwie so, also, wenn man's,
man, man kann's halt oft nicht vermeiden, dann
braucht man's halt, und dann, äh,
es gibt noch diverse andere Task-Queue-Geschichten,
Celery ist halt die verbreitetste
für Django, ähm,
ja,
äh, vielleicht lohnt es sich auch,
sich die anzugucken, ähm,
ich weiß es nicht genau, ähm,
aber, äh, ja, also wenn man's nicht braucht,
dann war's nicht unbedingt, äh, also es ist nicht,
es ist nicht unbedingt ne, äh,
ne Geschichte, die man aus der rein, aufgrund von
reiner Freude, weil's 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.
Ähm, ja, aber
oft braucht man sowas tatsächlich.
Äh, ja, was haben wir noch, ähm,
Ja, ich würde jetzt nochmal so ein bisschen auf die ganz
Basic-Sachen zurückkommen, also, äh, wie, ähm,
weiß ich denn jetzt, auf welche Route ich
jetzt meinen Name-Server zum Beispiel schicke,
auf welches Verzeichnis ich den, äh,
verweise, oder mach ich das überhaupt über Verzeichnis,
oder welche verschiedenen Django-Apps laufen,
oder, du hast ja gesagt, Junicorn ist nur eine,
dann hab ich sonst ein Whisky, und, ähm,
Whisky weiß dann, wo was liegt, oder,
Junicorn ist deine Applikations-Server, jetzt sagen wir mal, wenn du jetzt
Kugelkater verwendet hast, und so, dann,
äh, läuft dein
System, äh, läuft halt irgendwo
intern in einen Docker-Container,
und, äh, äh, 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, ja, nimmt aber nur Requests an von innen,
also sollte nicht von außen erreichbar sein.
Das heißt also, ich muss aber dann den Port
kämpfe ich natürlich an, und dann, die Ports muss ich ja irgendwie auf
meiner Maschine routen dann. Nee. Zu den Docker-Containern.
Nee. Nein? Wie?
Wo funktioniert das denn? Die sind nur lokal.
Äh, da.
Also kannst du lokal drauf connecten, sonst nicht.
Und, äh,
wie dann die Requests sozusagen aus dem Web da
reinkommen ist, du hast halt den Caddy vorne dran,
da gehen die Sachen per
Report 443, kommen die rein.
Und den Caddy muss ich konfigurieren?
Den musst du konfigurieren, du brauchst einen Config für,
die ist aber relativ einfach, und da steht
mehr oder weniger nur drin,
irgendwie, wenn's an die Domain gehen soll,
dann alles an den Applikations-Server.
Okay, aber das heißt, der Caddy ist derjenige,
der ist alles verwaltet. Das heißt, in der Caddy-Konfiguration
stelle ich das ein,
der Name-Server, HTML-Routing.
Nein, nein, nein, nein.
Nein, das steht nur drin,
auf welche Domain
geht, also,
je nachdem, auf welche
Domain der Request geht, auf welchen
Applikations-Server soll das gehen.
Insofern kann man auch sagen, das ist gewisserweise Routing,
aber es ist sehr, sehr einfach.
Es ist sehr, sehr einfach.
Und HTML-Routing ist das selbe, das ist damit verknüpft,
weil halt das Name-Routing...
Es gibt noch,
es gibt etwas,
was sich URL-Routing,
Routing nennt, bei Django.
Ja, aber das ist aber innerhalb von Django.
Aber ich kann ja verschiedene Projekte nehmen. Ich könnte jetzt auch sagen,
ich möchte jetzt einfach ein Verzeichnis-Server,
weiß nicht, war www irgendwas, was es da früher gab, oder so.
Einfach ein Verzeichnis mit einem Index,
irgendwas.
Das kannst du mit dem Caddy auch machen.
Kann ich mit dem Caddy auch sagen, das Verzeichnis kommt auch dann
unter dem Namen
resolved, geroutet, rein.
Okay.
Genau, das ist halt spannend.
Das sind halt verschiedene Optionen, die kann ich alle gleichzeitig
mit dem einen Caddy bauen. Das heißt, das Einzige, um das zu machen,
muss ich meinen Caddy konfigurieren.
Was mit E-Mail, wenn ich jetzt irgendwie E-Mail schicken will,
auch Caddy?
Ne, das ist natürlich nur ein Web-Server.
Das würdest du in der Django-Applikation
halt irgendwie machen und da
kannst du es entweder selber tun, wenn du halt lokal
eine Mail-Server laufen hast.
Oh, nein, nein.
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.
C-Name ist eine Art von
Rekord für DNS,
wo dran steht, also dieser Name ist
eigentlich nur ein Alias für den Namen.
Ja, also die Alias muss
ich ja irgendwie auf meinem Server auch eintragen.
Wie passiert das denn?
Also wenn ich jetzt beispielsweise eine G-Suite habe,
mit der ich meine Firmen-E-Mail-Adressen
verwalten möchte, dann
trotzdem die Domain auf
meinen Server ankommt.
Wo muss ich dann einstellen, dass dann die E-Mail-Adresse
in zur G-Suite weitergeht? Was ist das, was da liegt?
Im Name-Server.
Also da sagst du halt, der
zuständige MX, das ist wieder ein anderer Rekord,
MX-Rekord, der ist für Mail zuständig,
der Mail-Server für
meine Domain ist Google.
Aber das ist dann am Mail-Server, also an
meinem Provider, an meinem Name?
Nein, da, wo
du deine Domain registrierst.
Der hat
eigentlich eine andere Aufgabe, das ist halt, der Name-Server
macht das. Aber der, wo du
deine Domain registriert hast, der betreibt wahrscheinlich den Name-Server.
Wo dann deine Domain liegt.
Ja, genau, da machst
du das. Und
dann geht halt alle Mail,
die an deine Domain geschickt wird, halt
dem
Mail-Client, beziehungsweise Mail-Server,
den halt irgendjemand verwendet hat,
der macht dann
ein MX-Lookup auf deine Domain, sieht halt
die Mail zu Google gegeben und schickt dann die Mail
direkt zu Google. Und dann landet sie halt
bei dir irgendwo bei Gmail oder wo auch immer.
Und wenn ich jetzt einen
File-Server machen will, dann muss ich das einfach wieder über den Caddy-Root
finden, ob irgendein Verzeichnis...
Was ist ein File-Server?
Oder was meinst du damit?
Vielleicht einfach ein Verzeichnis, das ich freigebe, wo ich dann
hoch- und runterladen kann.
Einfach so schreibe und lese Zugriff.
Brauche ich dafür sowas wie alte
US-FDP?
Das hängt halt sehr davon ab, was du da
machen möchtest. Ich würde sagen, ja, sowas
gibt es außerhalb der Windows-Welt eigentlich
so nicht. Also da ist es halt irgendwie
Samba, oder ich weiß nicht, wie das Protokoll
Microsoft intern heißt.
Wahrscheinlich heißt es irgendwie anders. Keine Ahnung.
Ich kenne es nur, wenn man es jetzt Linux
als Server betreiben will, dann heißt es irgendwie
Samba als Server. Aber sowas betreibst du halt
nicht im Internet. Also... Warum?
Viel zu gefährlich.
Das ist...
Näh. Und es macht auch so
komische Sachen mit irgendwie Broadcast-
Geschichten und so. Das geht alles im Internet nicht.
Also... Also zu gefährlich
sagst du. Aber es würde gehen.
Näh, geht auch nicht. Ich glaube, es geht
gar nicht. Also was war denn ein FTP-Server?
Den hätte man aber einfach... FTP-Server, ja, aber
FTP-Server.
FTP ist auch irgendwie...
Ja, also die... Wie würde man
sagen, die 70er haben angerufen und die
80er haben angerufen.
Ihre
Wares zurück.
Also das ist... Das war ja damals
ziemlich cool. Da konnte man irgendwie so einen FTP-Server
connecten und hat dann da alles rumgeschoben,
hinterhergeschoben, was man so brauchte.
Ja, da konnte man
lustige Dinge machen. Also das ist uralt.
Ja...
Da gab es ja irgendwann die File-Sharing-Plattform
und man wusste, was gibt es denn heute? Also einfach dann
Cloud? Ja, das macht
man einfach nicht mehr, würde ich sagen. Also...
Es ist einfach komplett weg. Man hat das einfach
sowieso scheiße. Da ist alles zur Verfügung.
Näh, das war... Also...
Wenn du also Sachen hoch- und runterladen, das ist heute alles
HTTP. Und auch
da gab es dann irgendwie früher so
Geschichten. Vielleicht gibt es das auch immer noch.
Ich weiß nicht 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...
Also wenn ich jetzt irgendwie nicht sowas machen will
für mich, irgendwie mit meinem kleinen Login oder sowas,
dass ich sage, hey, ich hätte gerne 10 Dateien, die ich immer runterziehe,
die nicht wichtig sind, wo man nicht besonders
viel kaputt machen kann, wenn da irgendwas auseinanderfließt.
Die Frage ist, was möchtest du machen? Was möchtest du eigentlich haben?
Nur einfach so eine File-Ablage, so eine Teil-Ablage
für, weiß ich nicht, 5 Fotos oder
irgendwas. Ich meine,
Fotos, weiß ich, gibt es ja auch andere Möglichkeiten, aber
nur so. Du willst
irgendwie verzeichnete Synchronen halten.
Ja, so ein kleines Dropbox. Ja, oder so ein kleines Store
für irgendwas. So mein virtueller USB-Stick.
Da gibt es, also würde ich
eher sagen, also da gibt es als fertig,
würde mir jetzt eigentlich nur einfallen, sowas wie
On-Cloud oder Un-Cloud.
Aber intern,
was die wahrscheinlich alle machen, das machen wahrscheinlich solche
selbst wie, oder wenn man
jetzt Apple verwendet, würde ich sagen, dann nimmt man halt einfach iCloud.
Also Un-Cloud. Oder iDrive.
Wenn du selber hosten willst,
On-Cloud wahrscheinlich. Aber intern wird das auch
nichts anderes machen.
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 Rechner läuft. Die halt
sich per iNotify oder sonst irgendwie
oder wie auch immer
sich benachrichtigen lässt, wenn halt irgendwie sich was an
ein Verzeichnis erinnert. Und dann sinkt die das halt rüber.
Und umgekehrt halt genauso.
Deswegen brauchst du auch einen Client, weil
das ja dann sozusagen
eine stehende Verbindung irgendwie braucht.
Und du halt auch vom Server aus den
Client benachrichtigen können willst.
Und ja.
Ich weiß nicht, ob es irgendeine gute, freie,
selbst gehostete Geschichte dafür gibt.
Aber warum nicht irgendwie
Dropbox oder sonst irgendwas?
Ja, ich meinte einfach nur jetzt so der private USB-Stick.
Wo man kurz was hinterschieben kann.
Von Gerät zu Gerät
oder sowas. Wo man einfach dann URL eingibt
und dann kurz seinen Login. Und dann hat man das.
Das wäre irgendwie schon nett.
Ja. Ich weiß es nicht.
Ich glaube, also ich meine, das Geräteübergreifend
funktioniert das wahrscheinlich dann Google.
Du musst ja dann auch irgendwie auf die Telefone kommen.
Wäre ja dann praktisch.
Und dann bist du eh
entweder bei Apple oder bei Google.
Da kommst du ja selber gar nicht mehr drauf.
Ja, dann fallen wir doch
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 Keddy mit drin.
Das heißt, das HTTPS mit
Unterstützer. Also kannst du mal vielleicht
unterschiedlich kurz. HTTPS, ist das dasselbe?
Naja, SSL ist eigentlich, glaube ich,
veraltet.
Das ist gar nicht mehr so, dass man halt
davon redet, weil man das irgendwie gewohnt ist.
Also mittlerweile ist das, was man eigentlich verwendet,
TLS.
Und so genau
weiß ich das jetzt auch alles nicht.
Das zu konfigurieren ist ein Schmerz.
Also ich weiß, dass ich das, ich habe das mal ein paar
Mal gemacht für NGINX.
Und das hat, das war auch, das hat länger
gedauert, als ich dachte. Es gibt da so ein
Test
von SSL Labs, wo man dann überprüfen
kann.
Ob die eigene Seite irgendwie den aktuellen
Sicherheitsanforderungen irgendwie genügt.
Muss man da irgendwie ein Zertifikat sich irgendwo generieren?
Kann man das selber erzeugen? Muss man das kaufen?
Da gibt es ja irgendwie so kostenliche Angebote.
Warum nimmt man die? Warum nimmt man
freies? Geht das auch frei?
Also ich würde da gar nicht so super
detail drauf eingehen. Also wenn man kann das kaufen,
dann hat man unter Umständen so Vorteile
wie, es wird in der Browser weiß-grün angezeigt
oder so, weil es irgendwie so Spezial-Deals
zwischen den Browser-Herstellern gibt.
Und also, ich meine, das sieht auch komisch
aus. Ich weiß nicht mal, ob das jetzt vertrauenserweckende
ist oder nicht. Vielleicht denken die Leute, das ist
lieber seltsam. Oh, Kapitalisten, weg da!
Nein, ich weiß nicht. Also, dann
ist es so, die ganzen
Certificate Authorities
sind halt
dadurch aufgefallen, also von denen
kaufst du sozusagen die Dienstleistung, dass sie
deinen Key
unterschreiben und
damit der Browser halt, weil er die
Certification Authority kennt, halt sagen kann,
okay, ich glaube, dass das jetzt die Seite
ist, mit der ich tatsächlich rede.
Die haben, sind
halt schon ganz oft dadurch aufgefallen, dass
irgendwie
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
ist, das passiert halt dauernd. Daher ist diese
ganze Certification, äh,
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.
Ähm,
insofern würde ich sagen, tja, also,
äh,
dieses letzte, also,
man muss auch heutzutage eigentlich kein Geld mehr bezahlen.
Es gibt eine freie, äh,
CA, ne, Let's Encrypt,
die in allen Browsern, äh, die, äh,
äh, äh, äh, quasi Keys drin hat,
sodass man halt überprüfen kann, ob die korrekt
signiert sind. Äh, das heißt,
ja, wo es früher gar nicht möglich war,
wo man halt kein, äh, äh,
keine verschlüsselte Verbindung bekommen hat, ohne dass
einer der Browser irgendwie schreckliche
Warnungs-Warngeschichten angezeigt hat.
Äh, äh, ohne dass man bezahlt hat.
Das geht heute. Insofern,
es ist, äh,
ja.
Ähm, und, ja,
ich mach das so. Es gibt auch Gründe, das nicht
so zu machen, aber, äh,
oh, wir haben gerade eine Live, eine, eine
E-Mail bekommen zu einem Podcast. Die ist aber leider so lange,
dass ich sie nicht lange vorlesen kann. Ähm,
von Topit.
Ja, bin gespannt. Ja, ich werde mir gleich mal
durchlesen. Ich freu mich schon. Ja, ähm,
also, Thorsten. Ja. Hi, Thorsten.
Jetzt war eine Live-Inteilung.
Fand ich super. Okay.
Ja, äh,
Engagement, äh, heute sehr hoch.
Also, wir möchten gerne tatsächlich
diesen Server, den wir jetzt ja irgendwie stehen haben, ne,
mit dem ganzen SSL-Zertifikate und was. Kann man denn
irgendwie, was, also, wahrscheinlich erzähl ich jetzt wieder irgendwelchen
Unsinn, irgendwie mit, äh, als Proxy
benutzen, irgendwie über den ins Netz connecten
und Anfragen stellen auch, dass ich irgendwie
den anderen Weg gehen kann, dass nicht jeder sieht, wovon
ich komme, dass ich dann von meinem Server ausgehe?
Na, oh, das willst du aber nicht, weil dann weiß doch
jeder, woher, woher, woher. Ja, aber das ist doch okay,
aber dann, dann ist das... Das willst du,
das willst du ja gerade nicht. Nein, aber vielleicht hab ich ja einen
anderen Standort und ich connecte immer meinen Server und dann wissen die
vielleicht, dass ich immer mein Server bin, oder
sowas, aber die wissen meinen eigenen, eigentlichen
Standort jetzt nicht, weil ich nicht immer über meinen Provider gehe.
Ja, aber da sind... Also, mein Provider weiß zum
Beispiel dann nicht mehr, wo ich hingehe, weil ich über meinen Server gehe.
Ja, okay, gut, aber, äh,
gut, aber, also,
der, der Nachteil ist, dass halt jeder,
den du, dass du, dass jeder
Webserver-Betreiber weiß,
wer du bist, was
vielleicht auch nicht so cool ist, also,
äh, das ist alles, sind alles Dinge, das
will man wahrscheinlich nicht so machen. Ja, aber, also, vielleicht, also,
zumindest, wenn die ganze Zeit
mein Provider sonst immer alles mitbekommt,
vielleicht kann man... Ist halt die Frage, vor wem du
Angst hast, also... Vielleicht vor dem Provider.
Wenn du vor dem Provider Angst hast, ja, aber... Dann könnte
man da raus, das könnte man als Tunnel benutzen.
Würde ich nicht so machen, würde ich nicht so machen, dann
nimm lieber was ordentliches, nimm lieber Tor.
Ja, okay. Oder nimm halt
einen von den VPN-Dienstleistern, aber die sind
auch, ich meine, da muss man sich auch bewusst sein, dass die, ähm...
Auch gecaptured werden.
Und vor allem, dass sie zweimal verdienen,
ne, 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,
äh, für die, für die Nutzungsdaten, ne, also,
ähm... Also, ich hab 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, weil ich da einrichten würde.
Ja, das hat aber nichts mit, glaube ich,
zu tun, dass es dann, da würde es dann irgendwie
sowas wie OpenVPN nehmen oder so.
Das heißt, ich würde einen VPN-Server starten, dahin
connecten und dann von dem dann weiterlaufen.
Ja.
Okay.
und dann einfach einrichten auf dem...
Genau, also das ist tatsächlich ein Anwendungsfall,
für den ich das tatsächlich auch benutze
und auch einen OpenVPN-Server laufen
habe, ist, man kann
auch bei allen, also bei iPhone geht das sehr, sehr easy,
da kannst du halt OpenVPN-Server
auch einfach eintragen als, das ist jetzt
VPN, du kannst ja den VPN irgendwie auswählen und kannst
sagen, ich nehme jetzt einfach den.
Ist halt für
Netflix
und die ganzen Streaming-Geschichten,
Spotify-Sachen, die funktionieren ja sonst im Urlaub
halt nicht mehr.
Die sind ja quasi, und wenn man dann
VPN anmacht, dann gehen die halt trotzdem.
Und dafür habe ich es halt genutzt
bisher, aber...
Ja genau, den musst du dann
auch über den Kelly routen, oder wie ist das denn mit dem
Port? Das ist kein HTTP.
Das ist kein HTTP.
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... Also das heißt, ich starte einfach dann auf dem
Rechner, dann die verschiedenen Services am Anfang,
die dann halt hochgefahren sind und die dann nebenbei als
Demons dann laufen. Dazu gehört dann der OpenVPN,
der auf einem anderen Port dann läuft, als der
Kelly, der auf dem 443er läuft.
Und dadurch kann ich dann, indem ich auf die verschiedenen Ports
zugreife, dann auf die verschiedenen einzelnen
Applikationen geroutet werden. So wie das im Internet halt so üblich ist.
Was halt quasi
die unterschiedlichen Services haben halt unterschiedliche Ports.
DAP ist halt 80
und 443, Mail ist 25,
DNS ist
53,
je nachdem.
SSH ist 22.
Genau, FTP 21.
Ja.
Ja, also SSH will ich wahrscheinlich auch haben.
Ja.
Weil ich halt da irgendwie...
Aber dann ist halt auch die Frage,
als Root auf die Maschine draufgehen, ist das nicht ein bisschen riskant,
das irgendwie zu exponieren? Oder sage ich dem,
der 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 ein
File 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, ne? Was macht man denn dann,
wenn der kaputt geht?
Dann kann man sich nicht mehr connecten.
Dann ist er am 8, ja.
Kannst aber mehrere zum Beispiel nehmen. Ja, okay, aber dann ist man
normalerweise am 8, dann muss man den Server komplett abhauen dann.
Also weil das alles dann nicht mehr geht, dann muss man
den Server hart, wie
kommt man da wieder dran? Also kann man nur die Feste...
Naja, ne, 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 hatten wir noch gar nicht, der ist aber auch
vielleicht gar nicht so uninteressant, jetzt bei
Hetzner oder so, wo du wirklich physikalisch eine Maschine
gemietet hast, die irgendwo im Rack steht,
da kriegst du auch eine Konsole drauf.
Na, so ein paar serielle Konsole, kannst
du dich auf das Ding, was halt auch interessant ist,
wenn du irgendwelche Dinge machen möchtest, während das Ding bootet
oder so,
wo du halt
per SSH nichts machen kannst, weil es gibt keinen
SSH, die mit der läuft, weil der Körner noch gar nicht hochgefahren ist.
Da willst du halt
was anderes haben, mit dem du dich drauf connectest und das geht da.
Oft.
Sodass du halt wirklich das Ding booten sehen kannst und
kannst auch Dinge tun beim 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 ja so
Wegwerf-Kram, den schmeißt man halt einfach weg.
Wenn ich den Server irgendwie
abgeschmissen habe,
geschossen habe oder so,
und der bootet nicht mehr,
dann kann ich ja nicht anders machen.
Ja, dann schmeißt du den Container weg, machst einen neuen.
Es dauert ja nicht lang, das dann wieder hochzuziehen.
Ja gut, aber wenn das im Container läuft, dann ist das kein Problem.
Also ich würde sagen, wenn das ordentlich gemacht ist,
dann dauert das von irgendwie, du kopierst
dein Projektverzeichnis dahin
oder checkst es halt aus, was du auch machen kannst.
Wenn du SSH anhast mit
irgendwie Forward Agent,
dann kannst du halt auch private Repositories
beispielsweise GitHub oder irgendwelchen GitLab
auschecken. Das Connect ist ja
einfach hin, checkst es aus,
sagst Docker Compose, irgendwie Build
und dann linkst du halt das noch einmal
in deinen Supervise-Config-Dings
da nach ETC,
sagst Supervise-Control-Restart
dein, was auch immer, wie das heißt
und das dauert dann
drei, vier Minuten und dann ist das Ding wieder oben.
Also, ja.
Selbst das könntest du noch automatisieren.
Das kannst du per Script machen, kannst du auch
per Python SSH bedienen,
per Paramiko oder so.
Paramiko heißt das?
Mit der man SSH sprechen kann.
Ja, okay.
Ja, also Ports haben wir jetzt einmal so kurz drauf eingegangen.
Also ich könnte auch irgendwie irgendwelche Ports
aufmachen oder irgendwas hinterstecken.
Macht man dann auch sowas wie so einen Honigtopf
auf, dass man einfach irgendwie so eine Reaktion hat, falls die Leute
irgendwie sagen, hey, klassischer Angriff.
Würde ich jetzt nicht machen, aber gut.
Kann man natürlich, wenn man Spaß daran hat.
Also, ja.
Fliegenfang. Also es gibt für Dangler zum Beispiel
auch so ein Honeypot-Modul
irgendwie, das einen so vorgeholt,
dass es ein Admin-Interface gäbe.
Und dann, wo sich die Leute dann einloggen können mit
Standard-Passwörtern und dann können sie da irgendwie Dinge machen,
aber das ist alles nur Fake und dann kann man sich hinterher angucken, was sie gemacht haben.
Aber, ja, ich meine,
wenn ein, aber...
Ja, wenn man ein bisschen rumspielt in der Hobbygruppe und mal so guckt, was man so alles
rausfinden kann und wie man das alles so macht und so.
Aber ich würde sagen, ich würde es deswegen nicht machen,
weil das ist gefährlich.
Das ist halt viel Code, der mit außen redet.
Das ist viel Angriffsfläche.
Ja gut, ich sag mal, wenn man auf dem Server jetzt nichts zu verstecken hat,
sondern es eh nur so zum Rumspielen ist, dann ist das ja vielleicht gar nicht so schlimm.
Dann kannst du auch einfach offen lassen.
Dann gucken wir uns die Leute an. Vielleicht ist das ja besser.
Ja, vielleicht ist das ja auch ein bisschen Honig
ausliegen.
Schokolade.
Ja, also
Firewall?
Also Firewall...
Ist das auf Routerebene dann im Serverzentrum?
Nein, nein. Also Firewall
ist halt die Frage, was die Leute darunter verstehen. Das sind auch
unterschiedliche Dinge. Also ich kenne es halt eher so aus
der Internet-Admin-Welt.
Und da
nennt man Firewall
ein System zur
Durchsetzung einer Policy am Übergang
zwischen Netzwerken. So, das ist eine Firewall.
Ich weiß, dass es so im Heimcomputer-Bereich gibt es
da irgendwie andere Definitionen von. Da gibt es
auch so Personal Firewalls oder sowas.
Aber das ist alles Quatsch. Aus meiner Perspektive,
weil die machen genau das eben nicht.
Was heißt denn
Policy-Restriktion? Also wann darf denn welches
Protokoll mit welchem ich reden? Oder darf ein bestimmtes Protokoll nicht
auf einen bestimmten Port?
Genau. Du guckst dir halt...
Firewall ist ein
Konzept. Das ist nicht unbedingt eine
Implementation. Das, was die meisten Leute
vielleicht darunter verstehen, ist sowas wie ein Paketfilter.
Paketfilter, da guckt sich immer vier Sachen an.
Quell-IP,
Ziel-IP, Quellport, Zielport.
Du kannst jetzt natürlich auf beliebige
Kombinationen davon Policies definieren.
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 Paketeinlösung, mit, weiß ich nicht,
PyShark machen und das dann selber bauen auch?
Da gibt es Software, für die das
macht, aber das macht nur dann Sinn.
Also einmal willst du solche
Sachen niemals verwenden, um
dich
darauf zu verlassen, sondern das ist immer nur
ein zusätzliches Sicherheitsnetz. Also
die Sachen sollten sicher sein von sich aus.
Das kann ja auch sein, dass
Paketfilter ausfallen oder nicht ordentlich funktionieren oder so.
Das sollte deine Sicherheit nicht beeinträchtigen.
Sondern das ist einfach nur, damit
du sagen kannst, ich habe hier ein Stück Hardware, das ist
sonst mit nichts verbunden.
Das ist nicht
irgendwie auf der gleichen Maschine. Da kann ich irgendwie, wenn
jemand meine Maschine aufgemacht hat oder eine Applikation
aufgemacht hat, kann er diese Policy
nicht ändern. Das heißt, dafür
muss es dann halt physikalisch getrennte
Maschine im Grunde sein, auf der
nur der Paketfilter läuft, sonst nichts. Sonst macht
es keinen Sinn. 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...
Aber das kannst du überhaupt nicht. Du hast ja nicht
drüber das Netz. Also das kann... Ich würde sagen, das macht
ja nur dann Sinn, wenn du auch das Netz unter Kontrolle hast.
Aber dann muss ich das lokale Netz unter Kontrolle haben.
Du müsstest das Netz, in dem
du dir so Policy durchsetzen willst, musst du
unter Kontrolle haben. Also bei meiner eigenen Serverfarm zu Hause.
Wenn ich da... Du kannst es zu Hause machen, ja.
Für zwei verschiedene Routernetze oder sowas, die ich von einer
trennen will. Vielleicht habe ich
irgendwie ein kleines offenes
Netz da. Da gibt es ja so ein paar Optionen,
wo man frei sich verbinden kann
an einem Funk. Und dann könnte man das
mit seinem Heimnetzwerk machen. Und da sollte man dann sowas dazwischen hängen,
weil die Geräte zwar im gleichen LAN-Festival
zu viel Aufwand... Das ist viel zu viel Aufwand, um
sowas selber zu machen. Oder
ich wüsste jetzt nicht, dass das irgendein... Also
ich finde, seit diesen Zeiten
sind es vorbei. Also das ist...
Das meine ich nicht.
Ja, also ich meine, eben diese Infra... Also
die Hoster und vielleicht auch Amazon,
die werden solche Sachen betreiben.
Die machen das so.
Aber...
Für zu Hause macht das
doch kein... Ich meine, du musst wirklich
ein eigenes Gerät dafür haben, dass das nur das tut.
Und dann brauchst du mehrere davon.
Weil du willst ja
nicht nur einen... Du brauchst ja dann irgendwie
unterschiedliche Zonen
und...
Da gibt es ja unterschiedliche Konzepte,
wie du das realisierst.
Und du kommst ja mit einem Ding auch gar nicht aus. Da brauchst du mehrere
davon. Das heißt, du betreibst mehrere Rechner zu Hause
nur, um diese Policy da durchzusetzen.
Welchen Gewinn erzielst du dadurch?
Und vor allen Dingen im Verhältnis zu
dem Aufwand.
Als Rechenzentrumsbetreiber
kann man das irgendwie rechtfertigen, dass man zu jedem
Switch dann noch irgendwie einen Paketfilter stellt.
Oder so alle
zwei, drei Racks stellt man da halt
irgendwie noch einen Paketfilter dazu.
Aber zu Hause...
Da bin ich aber ganz sicher, da bin ich nicht mehr so
Glaskörper-mäßig.
Aber das Ding hilft dir ja für die meisten
Sachen, die dich sozusagen...
Nässt nicht.
Genau.
Es hängt halt davon ab, wovor du Angst hast.
Wenn du Angst davor hast, dass die
Applikationen, die bei dir laufen, was Böses tun, dann
schützt dich das alles überhaupt gar nicht.
Das schützt dich halt bloß davor, dass jemand
Verbindungen irgendwie, die du
laut Policy nicht zulässt, irgendwie
macht. Aber das passiert heute eh fast
nicht mehr.
Oder das passiert ja auch nur dann, wenn
eine Verbindung möglich wäre. Die meisten
sitzen hinter irgendeinem komischen, dynamischen
IP, irgendeinem seltsamen NAT.
Das ist mit den Verbindungen sowieso nicht so
toll. Und da müssen
ja diejenigen,
die dich...
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 der ja gar nicht mehr durch.
Wenn man das auf eine relativ schlaue Art tut, dann nützt dir der ganze
Paketfilter-Kram nichts. Weil
der sieht ja nichts Schlaues. Der macht ja nichts Schlaues.
Der macht ja was sehr, sehr Einfaches eigentlich.
Also
schwer. Also Firewalls sind auch quasi
aus den Relikte, aus der Paketfilter.
Naja, also Firewall ist ja unter Umständen noch viel mehr. Es ist ja nicht nur
Paketfilter, sondern das ist halt...
Man kann ja auch noch andere Dinge tun.
Man könnte auch solche Sachen machen, wie
ähm...
äh...
Na, du hast da einen Rechner,
auf dem läuft nur
äh...
wie heißt das? VLC oder so?
Nee, dieses Ding ist VNC.
Sozusagen, genau. Du connectst dich
darauf. Du hast selber... Bist du abgeschnitten
von... Du 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,
äh, die halt auch da drunter fallen.
Also ich würde eher sagen, das ist halt so...
Das ist eher ein Konzept. Und, äh...
Ja, aber das ist
alles Sachen, das ist heute...
Ich würde sagen, äh, ich weiß es natürlich
nicht genau, vielleicht, das ist heutzutage eher ein Ding
für Experten. Weil
wer hat...
Mist.
Also ich meine, wenn einem das Spaß macht, kann man sich ja damit beschäftigen,
aber, ähm...
So.
Das, ähm, ja.
Die meisten Firmen machen ja auch ihr Rechenzentrumskram
nicht mehr selber. Auch das macht natürlich Spaß,
irgendwie selber Racks zu bauen und Kabel zu ziehen
und die zu labeln und so. Voll gut.
Aber das macht auch heute kaum noch jemand, weil
alle gehen halt in die Cloud und...
Okay.
Es ist halt so ein bisschen, das wird halt eher, das rutscht
halt alles so in die Richtung, ähm...
Commodity. Also früher hat es halt
hat es vielleicht noch einen Unterschied gemacht, wenn man jetzt
in einer Firma war und hat halt irgendwie
sein eigenes Rechenzentrum im Keller betrieben, äh,
ob man jetzt die Kabel
ordentlich gelabelt hat, äh, und
irgendwie da die Paketfelder ordentlich hingestellt hat
und so. Und heutzutage ist das halt so,
darüber kann man sich schwer differenzieren, weil
also außer, man macht's halt
scheiße. Aber ansonsten kann man es,
wenn man's gut macht, besser als Amazon
wird man's nicht machen können. Daher, ähm,
oder nur, also, mit einem Aufwand, der
das ist halt nicht mehr gerechtfertigt, ja.
Nicht mehr bezahlbar, meinst du? Nicht bezahlbar, ja.
Das lohnt sich einfach nicht. Also, Amazon
ist so gut, äh, die anderen
auch, äh, dass sich das
nicht mehr lohnt, das selber zu machen, um sich da noch irgendwie
was rauszuholen.
Das musst du mir nochmal genauer erklären.
Das ist so ein bisschen schade irgendwie,
weil natürlich viele coole Sachen, die früher irgendwie
interessant waren, heute halt nicht mehr,
nicht mehr so, oder, ähm, ja.
Aber ich fürchte, das ist halt so der Gang
der Dinge. Zeiten sind vorbei.
Ja. Na gut.
Aber ja, also ich meine, das ist natürlich schon alles interessant.
Also, ja. Also ich würde vielleicht
gerne nochmal kurz das mit dem Server anschließen.
Ähm, 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 Raspberry-Sensoren oder sowas,
äh, die ich dann da, äh,
Broadcast oder sowas, mit MQTT
habe ich, äh, gelernt, das würde ganz gut funktionieren.
Und dann lade ich irgendwie so ein Rest, äh,
oder ein GraphQL, äh, am besten
was, was würdest du sagen, API
laufen über so ein Caddy
dann, ein Django ansteuern,
da lässt du dann... Also, in Django selber rein geht das
dann wahrscheinlich, wenn du es direkt in Django rein
schreiben willst, über wahrscheinlich
sowas wie Django REST-Framework oder halt eben über
GraphQL oder so, das sind halt so die typischen
Sachen, mit denen man halt APIs bereitstellt.
Ähm,
aber
was du dann
auch machen könntest, das ist halt die Frage. Also
MQTT ist halt insofern schicker,
als dass es halt genau für solche Anwendungsfälle gedacht ist.
Ähm,
und du dir halt über viele Sachen
nicht mehr selber Gedanken machen musst,
dass du müsstest, wenn du es halt, äh,
also wenn du jetzt zum Beispiel, äh,
irgendwie, äh, keine Ahnung, eben, äh,
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
ein wichtiger, äh, nehmen wir an, du hast
einen Geigerzeller in deinen Raspberry Pi eingeschlossen, ja,
und, äh, irgendwie der Fallout, die Fallout-Wolke
ist überzieht über dein Wohngebiet
und, ähm, aber dummerweise
ist irgendwie gerade dein Server nicht erreichbar.
Dann ist es natürlich blöd, wenn jetzt diese
Information, dass, äh, äh,
dass dein Garten verseucht ist, äh, äh,
nicht bei dir ankommt, weil der Raspberry Pi,
der die Sensordaten bekommen hat,
sucht dir halt, äh, irgendwie an deinen Server zu schicken
und der ist halt gerade nicht da. Und was macht,
was macht dann? Schmeißt dir einfach weg. Schmeißt dir einfach weg,
ja, was soll das? So, und schmeißt dir einfach
weg und dann kriegst du die Daten nicht. Hängt
davon ab, hängt von deinen, deiner, deinen Anforderungen
ab, ob das jetzt, äh, schlimm ist oder nicht. Kann auch sein,
dass es nicht schlimm ist. Aber wenn es,
wenn du möchtest, dass die, ähm,
dann halt noch irgendwann dahin geschickt werden,
wenn der Server wieder da ist, dann brauchst du ja selber
irgendwie eine Art von Queue, dann brauchst du irgendwie eine Warteschlange,
äh, äh, wo halt die
Sensordaten erstmal auflaufen und dann halt irgendwie,
dann, wenn dein Server wieder verfügbar ist, dahin geschickt werden.
Und,
ja, das kannst du, dann kannst du noch Features dazu
bauen und dann implementierst du, äh,
MQTT oder halt
beliebiges anderes, äh, Queuing-System,
Message-Queue-System halt nach.
Und das muss man nicht tun, man kann
einfach eins nehmen, das schon fertig ist und das macht das dann
ein Verein, ne? Okay. Dann sagt man, dann schmeißt man
halt in die Queue halt irgendwie dieses Sensordatum
halt rein.
Und der überlebt dich so lange bisher in
201. Genau, aber man muss sich,
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?
Ne, ne, ne, ne. Das Ding macht,
nein, nein, nein, das ist halt ein eigenes Protokoll. Das macht
kein, macht auch kein HTTP.
Das ist ein eigenes Protokoll. Es gibt einen
MQTT-Broker, der, äh, irgendwie
weiß, welche, äh,
ja. Was spricht der dann REST?
Nein. Was bekommt der denn dann? Kein HTTP.
Aber wie bekomme ich den denn auf
meinem Django
Backend, auf meinem Django-Server?
Du könntest natürlich, ja, du kannst halt intern
irgendwo bei dir zu Hause MQTT sprechen und dann halt
irgendwie den ganzen Kram halt periodisch
zu deinem Server schicken, aber du könntest natürlich auch,
und das ist fast wahrscheinlich dein geiler,
äh, zum Beispiel, äh,
ein VPN aufmachen.
Ja. Und, ähm,
hast halt auch, äh,
quasi einen,
ähm, ja,
Ding, was halt, äh,
äh, die, die
an der Queue hängt, sozusagen die, die
konsumiert,
die, äh, Ereignisse, die da rausfallen,
die Events, die da rausfallen, und das,
was dann halt irgendwo zum Beispiel in deine Datenbank direkt
reinschreibt. Ja, dann gehe ich aber gar nicht mehr über die API.
Dann gehst du gar nicht mehr über die API, genau. Aber dann habe ich
noch einen eigenen Service laufen, der, ähm,
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, bei, äh,
auf dem lokalen Host geht das ja alles, da kannst du auch
mit dem, mit der Datenbank reden, das geht.
Ah, das heißt, ich muss
dann aber den, den Container mit reinschreiben,
den
MQGT-Broadcaster, damit er
auf die Datenbank zugreifen kann?
Nö, das muss man halt bloß irgendwie auf
da ankommen. Das Ding kann in dem
Container irgendwie als Prozess laufen, es kann aber auch wieder
in einem eigenen Container laufen.
Aber das kann... Genau, ich bin jetzt gerade ein bisschen ausgestiegen
an der Stelle mit der Verzahnung. Also ich habe jetzt, ähm,
meinen Django in einem
Docker-Container laufen, der vom
Caddy angesteuert wird.
Mhm.
Das läuft selber in einem eigenen Container.
Angesteuert?
Also der Caddy, der schießt das doch zum
App-Server.
Nein, wenn Requests von außen kommen, die landen auf dem Caddy.
Und der schickt sie dann halt weiter an den Applikations-Server,
wenn sie bestimmte Container entsprechen.
Der läuft aber als Docker.
Ja, aber der Caddy kann auch als Docker-Ding
laufen. Das ist, bei der
Default-Installation mit Cookie-Cutter ist das auch so.
Da läuft auch der Caddy in einem eigenen
Container. Und dann ist das ja egal, dann kann der MQGT-
Broadcaster auch in einem Container laufen, der kann
aber dann mit den anderen Postgres-Containern zum Beispiel
reden oder sowas. Ja. Ja, okay.
Dann kann er das dann reinschreiben und kann dann darauf zugreifen.
Ja. Der Zugriff, den mache ich jetzt, weiß ich nicht,
Django kann man flott lieben,
Seaborn macht man flott lieben oder halt tatsächlich so
ein bisschen Dash sogar, habe ich gesehen, gibt Django
im Modul, um das dann irgendwie auf sich darzustellen.
Wie
kommunizieren die denn dann mit der Datenbank,
damit das dann live abgerufen werden kann, wenn ich die Daten
jetzt live auslesen möchte?
Weiß ich, ehrlich gesagt.
Bin ich mir so ein bisschen überfragt, keine Ahnung.
Also man kann das halt so machen, dass man,
also du möchtest, dass sich live irgendwie dein
Graph ändert. Ja.
Wenn ich auf den Knopf drücke, dann soll das, also auf
dem Raspberry, auf den Knopf drücke, dann soll das direkt
sichtbar sein. Ja, dann
das Einfachste ist wahrscheinlich in JavaScript
einfach zu pollen, irgendwie alle
paar hundert Millisekunden oder so einfach
nochmal die API zu fragen, gibt es neue Daten?
GetRequest und einfach. Ja.
Oder, aber das
ist halt die Frage, ob man das machen möchte.
Dann nimmst du halt WebSockets
und dann sowas auf Django-Seite, sowas wie Django-Channels
oder so, aber dann musst du halt, dann musst du
einen anderen, musst du auch bestimmt einen anderen...
Was sind denn WebSockets jetzt schon wieder? Ui, ja, das ist
halt so eine Erweiterung. Das ist halt dann auch schon
nicht mehr HTTP, das ist halt was anderes.
Bei HTTP, da hast du das
Problem, du hast keine bidirektionale Verbindung,
sondern du hast halt immer nur Request-Response.
Mhm. 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.
Ähm, Socket. Ja.
Socket ist quasi sozusagen der, das
eine Ende der Hörer bei dem Telefon. Wenn du dir vorstellst,
halt, das ist wie so eine Verbindung, so eine
Internet-TCP-Verbindung ist halt wie so
eine Telefon-Verbindung, dann wäre Socket
irgendwie der Hörer, wo man irgendwie was reinwerfen kann,
was halt auf der anderen Seite rauskommt.
Und du kannst in beide Richtungen auch was reinwerfen. Ja, genau.
So, aber HTTP ist halt nicht so, sondern
HTTP ist eher so wie, ähm,
Rohrpost. Ja, da wirfst du halt was rein
und das... Rohrpost.
Nee, Quatsch, ach, das ist auch Unsinn. Das wäre ja auch bidirektional.
Äh, äh, ähm,
HTTP ist eher so wie... Wie so ein Katapult.
Wie, wie, du hast, äh,
äh... Katapult in eine Richtung,
fliegst immer was durch die Stadtmauer, und dann wenn du was...
Du hast, du hast, du hast
eine Telefon-Verbindung, aber, äh,
auf der Server-Seite hast du nur...
Oder du bist dann in so einem Bandseil und
versuchst mit der Hand immer ins Wasser. Ach, diese ganzen Vergleiche
sind nicht gut. Das stimmt alles nicht.
Es, äh...
Ja...
Mir fällt jetzt kein guter, 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. Ja.
Du kannst immer nur darauf warten, dass sie dich fragen.
Du kannst ein Fax hin und her schicken, sowas.
Ja, du kannst halt nichts da hinschicken. Ja.
Du kannst halt nur darauf warten, dass dich jemand fragt.
Und das ist halt, äh,
also, jetzt halten wir einen Vergleich ein.
Du bist halt so wie die, äh,
wie die, äh, wie beim Bahnhof, die Information.
Ja? So, die Leute können zu dir
kommen und dich irgendwas fragen, aber wenn jetzt...
Wenn jetzt der Zug, äh, irgendwie, keine Ahnung, äh,
äh, ausfällt, äh, 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.
Ja. Quasi. Ja, ja.
Ja, meine Kunden haben ja so eine Durchsage, aber so weit sind wir jetzt noch nicht.
Das ist viel zu modern. Ja, ja, ja.
Das, das, äh, ja, genau. Da geht's dann natürlich schon wieder kaputt
mit der, mit der, mit der Metapher. Aber, ähm,
ähm,
ja, äh, also,
eben, äh,
wenn du dann WebSockets hast, dann geht's halt doch.
Dann hast du eben eine Verbindung zu einem Client,
den kannst du dann in Echtzeit direkt sagen, so.
Wie mach ich WebSockets an? Also, bei Django hast du gesagt
Channels. Ja, Django Channels ist ne,
das Problem ist aber, du brauchst halt einen anderen
Server dann, Applikationsserver,
weil der das kann. Und welcher Applikationsserver
kann WebSockets von Django?
Äh, das, äh, der kommt dann da mit
Django Channels, sagt mit. Der heißt irgendwie Daphne.
Und, ähm,
ja,
es gibt auch, glaube ich, einen, der,
äh,
so ähnlich ist wie Unicorn. Der heißt bloß ein bisschen anders.
Der das dann auch kann.
Äh, aber, äh,
genau. Also, das ist halt, das ist alles nicht mehr so
einfach dann. Und, ähm, ja.
Ja, aber
jetzt hab ich schon wieder jede Menge gelernt. Ich bin ja wieder
weitergekommen. Ähm, was mir jetzt das Einzige, was mir
noch so fehlt tatsächlich, wäre jetzt das Indie-Web,
was ich jetzt da irgendwie bauen wollte. Ach so, das
Indie-Web, Indie-Web-Geschichten, genau. Dafür brauchst du,
also, wenn du ein eigenes Domain hast, schon mal sehr gut,
dann, äh, kannst du schon mal ne Menge machen.
Ähm, und das auch,
vor allen Dingen kannst du ne Menge nachrüsten.
Ansonsten, bei Django sieht's da momentan noch nicht so richtig
doll aus. Also, äh,
da muss man noch ein bisschen was basteln.
Ja, ich hab jetzt tatsächlich irgendwie
geguckt, wir haben jetzt die ganze Zeit über Django geredet, aber du kannst
einfach auch irgendwie jetzt ein Flasho und Pyramid einfach
daneben, ist eigentlich relativ egal. Ja, da gibt's auch nix, aber
ja. Aber dann gibt's halt jeweils die anderen Module,
die man dann irgendwie sich herausfinden muss, welche das dann
sind, und das funktioniert aber dann quasi
relativ ähnlich.
Genau. Also, Indie-Web-Geschichten ist
momentan eher noch alles so in der PHP-Welt
zu Hause. Ja, okay.
Ja, so ist es halt, aber, ähm,
Das heißt, ich muss dann einfach den Ketti auf
ein PHP-Verzeichnis schicken, oder?
Wenn du jetzt,
nee,
den könntest du, also, ich weiß nicht, wie man
das heutzutage so macht mit PHP, also diese,
ich hoffe, dass auch mal da die Zeiten so, wo man
da irgendwie so eine Web-Route hatte
und da irgendwie PHP-Dateien, die dann irgendwie
magisch ausgeführt werden über Mod.php oder so,
und Apache, ich hoffe ja mal, dass das nicht
mehr so ist, äh, sondern
dass man da auch das inzwischen so macht, dass man da halt
irgendwie Ketti davor hat, oder irgendwie
NNX, und dann hast du halt Applikations-Server,
die halt PHP, äh...
Aber im Worst-Case könntest du sagen, dass ich neben dem Ketti dann einfach
ein Apache mit einem Mod.php laufen habe,
und der dann Ansprüche hat auf den nächsten Port.
Kannst du, ja, könntest du das natürlich auch machen. Du kannst ja einfach
im Ketti sagen, so, das, äh, bitte,
diese Domain oder diese Subdomain,
oder was auch immer, an den Apache weiterreichen geht
natürlich auch, und den in einen eigenen Container packen, klar.
Und dann fürs Indie-Web, was baue ich denn
da noch, also eigentlich auch, sagen wir mal?
Ja, kommt halt darauf an, was du machen möchtest, aber da müssen wir noch mal,
also weiß ich jetzt ehrlich gesagt auch nicht so genau.
Okay, das machen wir dann noch mal von extern,
da haben wir ja schon mal ein bisschen kurz eingerichtet, aber das könnt ihr euch da bestimmt auch einlegen,
da gibt's 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 ein GitLab-Server, das
wird wahrscheinlich auch einfach ein Dienst sein,
oder, Demon?
Was ist das?
Ja, ja, ja, ja,
ja, nee, das ist einfach auch wieder eine
Web-Geschichte, ne? Also GitLab ist einfach
auch nur so ein Web-Frontend.
Ruby und Rails ist halt, ich weiß nicht genau,
wie aufwendig das zu hosten ist, also irgendwann
wird's dann natürlich schwerer. Also wenn du einen
10-Container hast, oder 20, oder irgendwann wird's dann mit dem Hauptspeicher
ein bisschen eng. Keine Ahnung.
Brauchen wir möglicherweise auch eine eigene Datenbank?
Ja.
Also Datenbanken sollte man
nicht so viele nehmen, man sollte die meisten Sachen in dieselbe Datenbank
packen.
Weil Datenbanken viel
Dinge brauchen? Nein? Ich würde das tatsächlich
so machen. Ganz viele kleine Container, ganz viele
kleine Datenbanken. Nee, ich würde das nach Systemen
auftrennen. Nach Projekten.
Ja, okay. Und dann
immer einen eigenen Container für die Datenbanken machen.
Und das nicht alles auf eine Datenbank
packen, weil auch da wiederum, wenn du das halt
irgendwie updatest oder so, du möchtest ja eigentlich,
oder du bist halt dann, du begibst dich
dann in das Gebiet. Du musst die Datenbank
löschen für ein Projekt, und dann sind alle Projekte gut.
Du upgradest die Datenbank, und dann sind alle Projekte
down. Das ist ja nicht eigentlich.
Sondern du willst halt auch vielleicht mit einem Projekt
auf einer bestimmten Datenbank-Version bleiben
können und so. Und du willst halt
die ganzen Systeme voneinander isolieren. Es ist natürlich
effizienter, wenn du irgendwo einen Datenbank-Server hast,
wo alle deine Datenbanken
liegen. Ja, 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 sowas, ja.
Naja, es ist halt einfach, du musst
dann, du musst dann
plötzlich Dinge tun. Du musst dann
irgendwie, da musst du Backups haben,
musst du auch so haben, aber das kriegst du alles in deinem Projekt
unter. Aber wenn du jetzt einen eigenen
Datenbank-Server hast, dann ist das mit den Backups
immer alles nicht mehr so einfach.
Dann ist, dann, pff,
dann, das, also wenn du das machst,
dann bist du halt schon im Profibereich irgendwie
unterwegs, dann machst du sonst nichts mehr. Dann machst du genau das
nur noch. Und die Frage ist,
ja, für Hobbygeschichten lohnt sich das ja überhaupt gar nicht.
Also, äh,
ja. Ja, dann sind wir wieder, ich glaube,
den Kreis können wir jetzt schließen. Wir sind ja nämlich bei
der Taiga angekommen, weil
die möchte ich jetzt vielleicht auch noch laufen lassen. Ich hätte gerne ein paar
Kanban-Boards irgendwie für mich persönlich, die ich dann da selber hoste.
Genau dasselbe. Ich muss da wieder was hochfahren,
was, was Routen über da in Keddy und
auf der Aplikation 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 Zeit.
Ja, wenn, äh,
am Ball bleiben.
Das ist auch, aber ich meine, wenn du, also
ich höre, dass du wirst die ganze Menge Zeug betreiben.
Da brauchst du wahrscheinlich dann schon eher so
eigene Hardware oder sagen wir so, dann wird es mit eigener Hardware
deutlich günstiger, als wenn du jetzt
da irgendwie eine
virtuelle Container irgendwie
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 Dreck in der Ecke, aber dann
ist es auch irgendwie doof und ja.
Ja, ich muss überlegen, was da irgendwie am besten
in Frage kommt. Aber damit kannst du ja vielleicht starten.
Du kannst ja zu Hause anfangen. Ja, ja, der ist schon,
der läuft schon eine ganze Weile, aber das
macht keinen Spaß.
Ja, aber ich muss ja eh immer so ein ganzes Team bauen
und so. Aber ich möchte die ganze Nacht halt dann einfach
wieder umbauen können, dass das nicht jedes Mal
dieser ganze Konfigurationsaufwand ist.
Ich habe jetzt irgendwie einen Pedora-Server dann irgendwie hingestellt,
der so irgendwie einige Sachen auch konnte, der auch in den Postgres
auch lief und irgendwie auch dann
danken konnte, aber dass das alles nicht so
gewesen ist heute.
Aber wir haben jetzt auf jeden Fall, das finde ich total super.
Ich habe da kein Candy, kein Reels und nichts da gebaut.
Das war mir bisher völlig unbekannt und
ja, finde ich super, dass man das alles so machen
kann. Also bis jetzt geht es ja immer nur so
Docker-Containers bauen, dann läuft das alles irgendwie magisch.
Aber wenn man nicht so wirklich versteht, was dann dahinter steckt,
ist das nochmal eine ganz andere Hürde,
glaube ich, auch zu verstehen, warum was gerade nicht geht
oder so. Und ja, vielen Dank,
dass du mir das alles wieder heute hier erklärt hast.
Ich weiß nicht, ob das alles
irgendwie klar geworden ist oder nur noch viel verwirrender.
Nein, nein, das war richtig, richtig, richtig klar.
Also eine große Erleuchtung und
man kann sich das ja alles nochmal zurückspulen oder nochmal
langsam abspulen.
Ich fand es echt cool.
Ja, also auf jeden Fall.
Tolle Folge für mich mal heute hier.
Ich mag sie natürlich immer.
Ja, und
genau, also
ja, also macht
auch Spaß und ich denke,
dass man zumindest, also wenn man
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 ein Buch kaufen,
Cookie-Pattern-Template verwenden.
Ja, also ich gehe jetzt gleich
die Mail von Thorsten durch und freue mich, dass wir
heute alle wieder zugehört habt.
Fand ich richtig super.
Ich habe ja sowieso auch keine
Ja, mit Blick der Woche habt ihr das ja heute Morgen.
Habe ich schon verbrannt, so irgendwie gerade am Anfang.
Machen wir dann diesmal nicht.
Ja, das machen wir nächstes Mal.
Gut, okay.
Ja, dann super, dass ihr wieder reingeschaltet habt. Bleibt uns gewogen.
Immer dann, wann ihr auch hört, ob gerade die Sterne scheinen
oder die Sonne brüht.
Ja, wir hören uns.
Bis später. Tschüss.