 Und dann freue ich mich, euch für den ersten Talk in diesem Blog vorstellen zu dürfen. DevNope ist Operator im Bereich Linux und Linux und hat, wie alle von uns, das Gefühl gehabt, dass man WorkAdventure Entzugs Erscheinung am besten gegenwirkt, indem man selber WorkAdventure aufsetzt und in diesem Talk wird er uns eine kleine Einführung geben, wie man das so machen kann. DevNope, dein Vortrag. Vielen Dank. Nun, zum aktuellen Zeitpunkt ist die Dokumentation noch recht dürftig in meinen Augen und ich hatte hier und da durchaus Probleme, meine Instanz zum Laufen zu bekommen. Ich habe später erfahren, dass es nicht nur mir so gehen, und ich dachte mir, das muss doch automatisierbar sein und beeingeniemer gehen. Passieren darauf habe ich dann etwas gebaut und bin nun der Meinung, dazu lohnt es sich, einen kleinen Vortrag zu erhalten. Was braucht es für meine Lösung? Eine Vm oder ein VPS, ein Virtual Private Service, der eine Debian 10 Vm haustet. Natürlich kann man auch eine andere Linux-Distribution nehmen, aber das war das, womit ich mich am wohlsten gefühlt habe. Außerdem braucht ihr eine Domain, bei der ihr eure eigenen Subdomains einrichten könnt. Diese Domain ist dann dafür da, damit andere Leute eure WorkAdventure Instanz erreichen können. Außerdem hilft es, ein gewisses Grundverständnis von Linux, Ansible und Docker zu haben. Nun, was ist zu tun? Ich dir davon aus, dass ihr erstmal eine blanke Debian Maschine habt. Konfiguriert am besten die Domains von vornherein. Welche Subdomains genau zu konfigurieren sind, das findet ihr mit in der Readme des Repositories. Den Link seht ihr dann später nochmal. Ladet euch am besten gleich das ganze Repository mit runter. Innerhalb des Repositories gibt es Konfigurationen, die ihr noch treffen müsst, um den Deployment-Prozess auf eure Umgebung anzupassen. Das umfasst die Domain, über die ihr später laufen wollt, welchen Raum ihr standardmäßig öffnen lassen wollt und mit welchem User ihr später per SSH auf den Host-Connecten können wollt. Wenn ihr dann das Ansible-Playbook an, wenn ihr fertig mit der Konfiguration seid, ihr kurze Befehl. Anschließend ist ein Reboot nötig. Es werden einige Pakete installiert und geupdatet, die dies notwendig machen. Wenn die Maschine wieder da und verfügbar ist, könnt ihr in den Ordner Opt WorkAdventure Contract Docker wechseln und mit Docker-Compose ab-d WorkAdventure starten. Was macht jetzt das Ansible daran? Erstmal wird von DBN-10 auf Testing geupdatet und das komplette System wird auf einen aktuellen Stand gebracht. Außerdem werden einige Pakete installiert, wie z.B. Hardtop, Lünos, T-Mux und vieles weiteres. Es wird ein User angelegt, wie gerade schon erwähnt, der es euch ermöglicht euch später zu diesem Host zu verbinden. Es werden viele Security-Settings angezogen, wie z.B. Firewall-Regeln, Konfigs für den SSH-Diemen, die z.B. verbieten, dass der Route User sich per SSH auf den Host verbinden kann. All these sind Maßnahmen, um euch einen schmerzfreien Betrieb zu gewährleisten, wo ihr euch nicht mehr so viel Sorg machen müsst. Anschließend wird Docker und Docker-Compose installiert und eingerichtet, sodass ihr auch da keiner weiteren Probleme habt. Später wird ein WorkAdventure runtergeladen und bereitgestellt. Anschließend werden noch ein paar Konfig-Files ausgeliefert, sodass ihr dann nichts weiter großartig herum ändern müsst, sondern gleich loslegen könnt. Kurz, wie ist WorkAdventure überhaupt aufgebaut? Wir finden für die einzelnen Funktionenzeiten einzelne Container. Das Kopfstück hierbei ist der Reverse Proxy. Dieser wird mit Traffic realisiert. Traffic ist eine Reverse Proxy, auch wie EngineX. Jedoch läuft dieser innerhalb von Docker und greift auf andere Container in Docker zu. Dies ermöglicht eine gewisse Menge an Automatisierung, die andere Reverse Proxys nicht leisten können. Außerdem wird gleich von Haus aus Let's Encrypt mit angewandt und ihr braucht euch keine Sorgen machen und darüber, woher ihr jetzt ein TLS-Zertifikat bekommt, damit ihr euren Dienst mit HTTPS und eurer URL erreichen könnt. Start und Stop der Anwendung wird auch über Docker-Compose realisiert. Jetzt werden sich vielleicht ein paar Leute denken, ja, ja, ich hab's eilig, das ist schon soweit da, aber irgendwie startet mein Compose-File nicht. Das, was ich festgestellt habe, was am meisten nerven kann, ist die Anbindung dieses Acme.json Files, was die Information für das TLS-Zertifikat und den Setup von Let's Encrypt ausmacht. Außerdem kann es durchaus zu Problemen kommen, wenn der Docker Socket nicht ordentlich erreichbar ist. Traffic möchte mindestens lesend auf den Socket zugreifen. Ich bin davon jetzt kein Fan, deswegen schränke ich da auch ganz stark ein auf Read Only. Lieber wär's mir allerdings, wenn Traffic das nicht tun müsste. Außerdem nochmal stellt sicher, dass ihr alle Subdomains entsprechend konfiguriert habt. Traffic wird nicht ordentlich starten können, wenn nicht alle Subdomains ordentlich erreichbar sind. Beim initialen Start vor allem gibt Traffic ein bisschen Zeit, um alle anderen Container und deren Schnittstellen zu erreichen. Das kann einen Moment dauern und kann für Irritationen sorgen. Ja, auf die Karten bin ich jetzt noch nicht eingegangen. Grundsätzlich könnt ihr jede Karte nehmen und besuchen, die ihr öffentlich findet. Die genaue Position der Karte wird über die URL mitangegeben. Ihr seht hier in dem Screenshot, in dem rot markierten Bereich, die quasi URL zu der Map. Wir sehen hier vom Raumzeitlabor, die uns zum Launchbereich des RC3s quasi schickt. Alle Personen, die auf euren Host gehen und auf diese Map werden dann in der gleichen Instanz und in der gleichen Gegend landen. Ihr seid dann in der Position, miteinander zu kommunizieren und zu interagieren. Ihr könnt natürlich auch eure eigenen Karten bauen. Dazu findet ihr Infomaterial auf der Seite von WorkAdventure, auf YouTube und auf anderen Quellen. Seid aber gewarnt, hier gibt es noch einige Packs, die zumindest mehr aufgefallen sind, dass bestimmte Positionsinformationen nicht ordentlich interpretiert werden. Macht euch bereit, dass das hier ab und zu zu Frust kommen kann. Noch ein Wort zu Jitzy. Jitzy ist sehr mächtig. Ihr könnt grundsätzlich jeden beliebigen Jitzy-Sauer nutzen, der für euch erreichbar ist. Ich beschließe allerdings den Betrieb eines eigenen Jitzy im Rahmen dieses Diploments aus. Grundsätzlich würde ich empfehlen, Jitzy komplett auf einer eigenen VM oder auf einem eigenen Cluster zu betreiben. Jitzy ist sehr ressourcenhungrig. WorkAdventure nicht. Einfach aufgrund einer ordentlichen Trennung würde ich davon abraten, das im Mischbetrieb zu fahren. Jitzy kann auf sehr viele Artenweisen konfiguriert werden und hat viele Parameter. Grundsätzlich wäre ihr ein eigener Vortrag angemessen, den werde ich aber nicht leisten. Wie geht es weiter mit meinem Repository? Ich habe vor, noch mehr Energie und Zeit in das Thema Monitoring zu investieren und in das Thema Logging. Ich möchte mich hier nicht unbedingt auf irgendwelche Docker Befehle verlassen, sondern möchte klassische Files, weil ich bin ein klassischer Atmen in dem Moment. Außerdem stört mich noch das Thema Traffic. Das Rauszuoperieren scheint aber ein größeres Problem zu sein und dafür habe ich aktuell noch keine Lösung. Ich danke euch für eure Aufmerksamkeit und freue mich auf die Q&A Session. Außerdem seid ihr eingeladen, mir natürlich auch bidirektionale Fragen zu stellen. Ja, DefNo, danke für den Vortrag. Da steht ja immer ein bisschen Arbeit dahinter, die gar nicht so zwingend in so einem Einführungsvortrag erkennbar ist. Aber bis die Fragen eintrudeln, also liebe Leute im Stream, schreibt gerne ins Pad eure Fragen rein. Vielleicht von mir eine kleine Frage. Wie viele Leute hast du denn schon so an die Hand genommen bei einer Workadventure Implementierung und Livestaltung? Ich denke vier oder sowas. Mit vier Leuten habe ich darüber etwas länger diskutiert und habe denn geholfen, Dinge zu debaggen und Dinge zu tun. Ich bin natürlich für Befragen und weiteres Feedback sehr dankbar, damit mehr Leute das nutzen und nutzen können. Ja, was war da so die häufigste Rückfrage, die du bekommen hast von den Leuten? Warum startet der Container nicht? So grob zusammengefasst war meistens das Ding. Das ist manchmal ein bisschen frustrierend, irgendwie ordentliche Fehlermeldungen aus dem Dockerstart rauszubekommen, gerade so das Traffic und das Frontend, glaube ich. Nee, doch das Frontend waren so meistens die Container, die gern etwas zickig sein können. Ja, also vielleicht klappt es ja irgendwann mal, dass man die Informationen noch ein bisschen besser aufbereitet bekommt, damit die Fehlersuche, so ist den Fehler gibt, leichter ist. So, jetzt rollen hier langsam die Fragen aus dem Stream rein. Die erste Frage, welche Specs sollte das Server haben bei ungefähr wieviel gleichzeitig Usern? Was sind der Erfahrungswerte? Also ich habe zwischenzeitlich, glaube ich, mal mit 20 Leuten probiert und hatte die zweitkleinste Instanz von Hetzner. Das sind zwei Standard-CPUs mit 2 GHz oder sowas. Storage braucht das Ding fast kaum, also es hat, glaube ich, 10 oder 20 Gigabyte, hat die Standard-VM, die Container, die Images, die es runterlädt, die sind etwas größer, sehr diese Node.js Container. Da hat man, glaube ich, am Ende irgendwie 500 MB in Gigabyte an Dependencies, die damit runterkommen. Aber das sollte passen soweit. Soweit ich das beobachten kann, ist die Nutzlast quasi auf dem Server gar nicht so dramatisch groß. Wie das jetzt bei, wie das jetzt für 102 einer Leute skaliert, kann ich jetzt nicht sagen, in der Mangelung einer Testgruppe. Schade, es wäre das gewesen, was ich mal ausprobieren würde. Aber gut, die Zukunft ist ja noch lang. Nächste Frage, das Ansible, wird das lokal oder remote ausgeführt? Ich führe es aktuell lokal aus. Ich hatte da im Hinterkopf, dass es durchaus auch Leute gibt, selbst im Atmenumfeld, die einfach ein Windows-Tasthop haben und Ansible unter Windows-Bedingungen irgendwie zum Laufen zu kriegen, ist halt einfach schmerzhaft. Und daraus einfacher zu sagen, okay, Freunde, ich lade dir das einfach auf die vor allem direkt runter und für Star aus. Da weiß ich, was da für ein Linux läuft und was da für eine Ansible installiert ist. Das funktioniert weitestgehend. Dann die nächsten brennenden Fragen rollen hier zu JITZY rein. Ich kombinier mal die zwei Fragen. Welchen JITZY Server würdest du empfehlen und gibt es Dinge, auf die man man oder Mensch achten müsste, wenn man bei den JITZY Server? Ich persönlich nutze meinen eigenen JITZY, den ich auf einer anderen Instanz betreibe. Der läuft aber noch ein bisschen mehr drauf. Deswegen mit Specs bin ich da ein bisschen vorsichtig. Ansonsten, es gibt auch Leute, die nutzen den PublicJITZY von JITZY direkt. Der wird halt über eine Umgebungsvariable im .nv-File angegeben. Ansonsten kann man, habe ich gesehen, kein Mensch JITZY Server und JITZY Räume in den Maps als Properties angeben. Das geht tatsächlich wohl auch pro Bereich, den man angebt. Das funktioniert über Layer. Ein bestimmter Layer kann ein bestimmter JITZY Raum sein. Da kann man sagen, wir haben jetzt hier einen großen Meetingsaal und ein dickes JITZY. Das ist nur dafür da. Dann kann ich sagen, extra property für JITZY Server und so heißt der JITZY Room und Feuer frei. Ansonsten ist es vielleicht noch darauf zu achten, ich habe immer wieder Probleme gehabt bei JITZY mit der Authentifikation, wenn man dort irgendwie Authentifikation einbaut und User Management. Da gibt es bestimmt Leute, die haben da wesentlich detaillierter Erfahrung. Ich habe es bei meinen JITZY Server dann einfach irgendwann gesagt, es interessiert mich nicht. Ich mache die Authentifikation an der Stelle aus. Grundsätzlich gibt es wohl aber die Möglichkeit, auch mit JWT Tokens zu arbeiten, um da ein bisschen den öffentlichen Gebrauch einzuschränken und auf das Workadventure zu limitieren. Ja, das ist so, wie ich das Pad beobachte, ein Hot Topic. Alle wollen Workadventure aufsetzen. Uns läuft leider die Zeit davon. Der Slot ist nicht so lang. Sag nochmal kurz, wie die Leute erreichen können, um die Fragen weiter zu diskutieren. Ja, könnt mich gerne über Twitter erreichen, unter der Elbdeffnung. Ansonsten bin ich auch hier im Matrixraum vom R2R zu erreichen. Genau, also das sind so die primären Ansprechmöglichkeiten. Ansonsten ist es bestimmt auch möglich, wenn ihr über GitHub mir da irgendwie nochmal was zu kommen lasst und mich anschreit, dann werde ich darauf entsprechend reagieren. Alles klar. Defnaub, ganz herzlichen Dank für deinen Vortrag und das Q&A. Und dann, ja, wir sehen uns hier auf der Veranstaltung. Vielen Dank und wir sehen uns.