Intro Herald: Ja, und dann freue ich mich euch für den ersten Talk in diesem Block vorstellen zu dürfen: devnope. devnope ist Operator im Bereich Linux und Unix und hat wie alle von uns das Gefühl gehabt, dass man WorkAdventure-Entzugserscheinungen am besten entgegenwirkt, 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. devnope: Vielen Dank. [Willkommen] zu [meinem] Vortrag. 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 das nicht nur mir so ging und ich dachte mir, das muss doch a - automatisierbar sein und b - angenehmer gehen. Basierend darauf habe ich dann etwas gebaut und bin nun der Meinung dazu lohnt es sich, einen kleinen Vortrag zu halten. Was braucht es für meine Lösung? Eine VM oder ein VPS, ein Virtual Private Service, der eine Debian 10 VM hosted. 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 gehe davon aus, dass ihr erstmal eine blanke Debian-Maschine habt. Konfiguriert am besten die Domains von vornherein. Welche Sub-Domains genau zu konfigurieren sind, das findet ihr dann in der Readme des Repositories. Den Link seht ihr später dann 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. Wende dann das Ansible Playbook an, wenn ihr fertig mit der Konfiguration seid. Hier kurz der Befehl... Anschließend ist ein Reboot nötig. Es werden einige Pakete installiert oder geupdatet, die dies notwendig notwendig machen. Wenn die Maschine wieder da und verfügbar ist, könnt in den Ordner /opt/workadventure/contrib/docker wechseln und mit docker compose up -d WorkAdventure starten. Was macht jetzt das Ansible daran? Erstmal wird Debian 10 auf Testing geupdatet und das komplette System wird auf einen aktuellen Stand gebracht. Außerdem werden einige Pakete installiert, wie zum Beispiel htop, lynis, tmux 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 zum Beispiel Firewall-Regeln, configs für den ssh daemon, die zum Beispiel verbieten, dass der root-User sich per ssh auf dem Host verbinden kann. All dies sind Maßnahmen, um euch einen schmerzfreien Betrieb zu gewährleisten, wo ihr euch nicht mehr so viel Sorgen machen müsst. Anschließend wird docker und docker- compose installiert und eingerichtet, sodass ihr auch da keine weiteren Probleme habt. Später wird ein WorkAdventure heruntergeladen und für euch bereitgestellt. Anschließend werden noch ein paar config 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 Funktionseinheiten einzelne Container. Das Kopfstück hierbei ist der Reverse Proxy. Dieser wird mit traefik realisiert. traefik ist ein Reverse Proxy, auch wie nginx. 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 Proxies nicht leisten können. Außerdem wird gleich von Haus aus Let's Encrypt mit angewandt und ihr braucht euch keine Sorgen machen darüber, woher ihr jetzt ein TLS-Zertifikat bekommt, damit ihr euren Dienst mit HTTPS und eurer URL erreichen könnt. Start und Stopp 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 so weit 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 Informationen für das TLS-Zertifikat und das Setup von Let's Encrypt ausmacht. Außerdem kann es durchaus zu Problemen kommen, wenn der docker socket nicht ordentlich erreichbar ist. traefik 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 traefik das nicht tun müsste. Außerdem, noch mal: stellt sicher, dass ihr alle Sub-Domains entsprechend konfiguriert habt. traefik wird nicht ordentlich starten können, wenn nicht alle Sub-Domains ordentlich erreichbar sind. Beim initialen Start vor allem gebt traefik 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 mit angegeben. Ihr seht hier in dem Screenshot, in dem rot markierten Bereich die quasi URL zu der Map. Wir sehen hier [die URL] vom Raumzeit-Labor, die uns zum Launch-Bereich des rC3's 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 Bugs, die zumindest mir aufgefallen sind, dass bestimmte Positionsinformation nicht ordentlich interpretiert werden. Macht euch bereit, dass es hier ab und zu zu Frust kommen kann. Noch ein Wort zu Jitsi. Jitsi ist sehr mächtig. Ihr könnt grundsätzlich jeden beliebigen Jitsi- Server nutzen, der für euch euch erreichbar ist. Ich schließe allerdings den Betrieb eines eigenen Jitsi's im Rahmen dieses Deployments aus. Grundsätzlich würde ich empfehlen, Jitsi komplett auf einer eigenen VM oder auf einem eigenen Cluster zu betreiben. Jitsi ist sehr ressourcenhungrig. WorkAdventure nicht. Einfach aufgrund einer ordentlichen Trennung würde ich davon abraten, das im Mischbetrieb zu fahren. Jitsi kann auf sehr viele Arten und Weisen konfiguriert werden und hat viele Parameter. Grundsätzlich wäre hier 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 Admin in dem Moment. Außerdem stört mich noch das Thema traefik. Das heraus zu operieren 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 bidirektional Fragen zu stellen. Herald: Ja - devnope! Danke für den Vortrag! Da steht ja immer ein bisschen Arbeit dahinter, die gar nicht so zwingend in 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 eine kleine Frage, wie viele Leute hast du denn schon so an die Hand genommen bei einer WorkAdventure-Implementierung und Live-Schaltung? devnope: Ich denke 4 oder sowas. Mit vier Leuten habe ich darüber etwas länger diskutiert und hab denen geholfen, Dinge zu debuggen und Dinge zu tun. Ich bin natürlich für Fragen und weiteres Feedback sehr dankbar, damit mehr Leute das nutzen und nutzen können. Herald: Ja. Was was war da so die häufigste Rückfrage, die du bekommen hast von den Leuten? devnope: Warum startet der Container nicht? So grob zusammengefasst war so meistens das Ding, das ist manchmal ein bisschen frustrierend, irgendwie ordentliche Fehlermeldungen aus dem Docker Start rauszubekommen. Gerade so das traefik und das Frontend, glaube ich, ja 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 es denn Fehler gibt, leichter ist. Herald: So, jetzt rollen hier langsam die Fragen aus dem Stream rein. Die erste Frage: Welches Specs sollte der Server haben, bei ungefähr wie viel gleichzeitigen Usern? Hast du da Erfahrungswerte? devnope: Also, ich hab's zwischenzeitlich mal mit 20 Leuten probiert und hatte die zweitkleinste Instanz von Hetzner, das sind zwei Standard-CPUs mit 2 GB RAM oder sowas. Storage braucht das Ding fast kaum, also es hat, glaube ich, 10 oder 20 GB, hat die Standard-VM, die Container-Images, die es runterlädt, die sind etwas größer, wie diesen nodejs-Container. Da hat man, glaube ich, am Ende irgendwie 500 MB, 1GB an dependencies, die da mit runterkommen, aber das sollte passen, so weit. So weit 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 100-200 Leute skaliert, kann ich jetzt nicht sagen in Ermangelung einer Testgruppe. Herald: Schade, dass wäre etwas gewesen, das 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? devnope: Ich führ's aktuell lokal aus. Ich hatte da im Hinterkopf, dass es durchaus auch Leute gibt, selbst im Admin-Umfeld, die halt einfach einen Windows Desktop haben und Ansible unter Windows-Bedingung irgendwie zum laufen zu kriegen ist halt ein schmerzhaft und da war es einfacher zu sagen: okay Freunde, ich lad' dir das einfach auf die VM direkt runter und führ's da aus. Da weiß ich, was da für ein Linux läuft und was da für ein Ansible installiert ist. Das funktioniert weitestgehend. Herald: Dann die nächsten brennenden Fragen rollen hier zu Jitsi rein. Ich kombiniere mal die zwei fragen: Welchen Jitsi-Server würdest du empfehlen und gibt es Dinge, auf die man oder mensch achten müsste, bei dem Jitsi-Server? devnope: Ich persönlich nutze meinen eigenen Jitsi, den ich auf einer anderen Instanz betreibe. Da 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 public Jitsi von Jitsi direkt. Der wird über eine Umgebungsvariable im .env-file angegeben, ansonsten kann man, habe ich gesehen, kann mensch Jitsi-Server und Jitsi-Räume in den Maps als Properties angeben. Und das geht tatsächlich wohl auch pro Bereich den man halt angibt, also das funktioniert halt über Layer und ein bestimmter Layer kann halt ein bestimmter Jitsi-Raum sein und da kann man halt sagen: alles klar, wir haben jetzt hier einen großen Meeting-Saal, wir haben jetzt hier ein dickes Jitsi, das ist halt nur dafür da, da kann ich halt sagen, okay, extra Property für Jitsi-Server und so heißt der Jitsi-Room, und Feuer frei. Ansonsten ist vielleicht noch drauf zu achten, ich hab immer wieder Probleme gehabt bei Jitsi mit der Authentifikation, wenn man dort irgendwie Authentifikation einbaut und User Management. Da gibt's bestimmt Leute, die haben da wesentlich detailliertere Erfahrungen. Ich hab's bei meinen Jitsi-Servern dann einfach irgendwann gesagt, es interessiert mich nicht. Ich mach' die Authentifikation an der Stelle aus. Grundsätzlich gibt es wohl aber die Möglichkeit, auch mit JWT-Tokens zu arbeiten und da ein bisschen den öffentlichen Gebrauch einzuschränken und auf das WorkAdventure zu limitieren. Herald: 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' noch mal kurz, wie die Leute dich erreichen können, um die Fragen weiter zu diskutieren. devnope: Ihr könnt mich gerne über Twitter erreichen, unter @devnope. Ansonsten bin ich auch hier im Matrix-Raum 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 was zukommen lasst, und mich anschreit, dann werde ich darauf entsprechend reagieren. Herald: Alles klar. devnope - ganz herzlichen Dank für deinen Vortrag und das Q&A und dann, ja, wir sehen uns hier auf der Veranstaltung. devnope: Vielen Dank und wir sehen uns! Outro Untertitel erstellt von c3subtitles.de im Jahr 2021. Mach mit und hilf uns!