*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!