#DiVOC R2R - Workadventure selbst betreiben: Ein Serviervorschlag

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!