WEBVTT
00:00:00.000 --> 00:00:18.041
Intro
00:00:18.041 --> 00:00:22.550
Herald: Ja, und dann freue ich mich euch
für den ersten Talk in diesem Block
00:00:22.550 --> 00:00:29.240
vorstellen zu dürfen: devnope. devnope ist
Operator im Bereich Linux und Unix und hat
00:00:29.240 --> 00:00:35.540
wie alle von uns das Gefühl gehabt, dass
man WorkAdventure-Entzugserscheinungen am
00:00:35.540 --> 00:00:39.830
besten entgegenwirkt, indem man selber
WorkAdventure aufsetzt und in diesem Talk
00:00:39.830 --> 00:00:45.950
wird er uns eine kleine Einführung geben,
wie man das so machen kann. devnope - dein
00:00:45.950 --> 00:00:48.203
Vortrag.
00:00:48.203 --> 00:00:55.290
devnope: Vielen Dank. [Willkommen] zu
[meinem] Vortrag. Nun, zum aktuellen
00:00:55.290 --> 00:01:00.660
Zeitpunkt ist die Dokumentation noch recht
dürftig in meinen Augen und ich hatte hier
00:01:00.660 --> 00:01:05.580
und da durchaus Probleme meine Instanz zum
laufen zu bekommen. Ich habe später
00:01:05.580 --> 00:01:11.070
erfahren, dass das nicht nur mir so ging
und ich dachte mir, das muss doch a -
00:01:11.070 --> 00:01:17.730
automatisierbar sein und b - angenehmer
gehen. Basierend darauf habe ich dann
00:01:17.730 --> 00:01:22.980
etwas gebaut und bin nun der Meinung dazu
lohnt es sich, einen kleinen Vortrag zu
00:01:22.980 --> 00:01:30.540
halten. Was braucht es für meine Lösung?
Eine VM oder ein VPS, ein Virtual Private
00:01:30.540 --> 00:01:36.480
Service, der eine Debian 10 VM hosted.
Natürlich kann man auch eine andere Linux-
00:01:36.480 --> 00:01:41.490
Distribution nehmen, aber das war das, womit
ich mich am wohlsten gefühlt habe. Außerdem
00:01:41.490 --> 00:01:46.950
braucht ihr eine Domain, bei der ihr eure
eigenen Subdomains einrichten könnt. Diese
00:01:46.950 --> 00:01:52.020
Domain ist dann dafür da, damit andere
Leute eure WorkAdventure-Instanz erreichen
00:01:52.020 --> 00:01:57.780
können. Außerdem hilft es, ein gewisses
Grundverständnis von Linux, Ansible und
00:01:57.780 --> 00:02:03.630
Docker zu haben. Nun, was ist zu tun? Ich
gehe davon aus, dass ihr erstmal eine
00:02:03.630 --> 00:02:08.970
blanke Debian-Maschine habt. Konfiguriert
am besten die Domains von vornherein.
00:02:08.970 --> 00:02:16.920
Welche Sub-Domains genau zu konfigurieren
sind, das findet ihr dann in der Readme
00:02:16.920 --> 00:02:23.220
des Repositories. Den Link seht ihr später
dann nochmal. Ladet euch am besten gleich
00:02:23.220 --> 00:02:29.910
das ganze Repository mit runter. Innerhalb
des Repositories gibt es Konfigurationen,
00:02:29.910 --> 00:02:36.030
die ihr noch treffen müsst, um den
Deployment-Prozess auf eure Umgebung
00:02:36.030 --> 00:02:43.140
anzupassen. Das umfasst die Domain, über
die ihr später laufen wollt, welchen Raum
00:02:43.140 --> 00:02:49.410
ihr standardmäßig öffnen lassen wollt und
mit welchem User ihr später per ssh auf
00:02:49.410 --> 00:02:56.730
den Host connecten können wollt. Wende
dann das Ansible Playbook an, wenn ihr
00:02:56.730 --> 00:03:02.580
fertig mit der Konfiguration seid. Hier
kurz der Befehl... Anschließend ist ein
00:03:02.580 --> 00:03:07.050
Reboot nötig. Es werden einige Pakete
installiert oder geupdatet, die dies notwendig
00:03:07.050 --> 00:03:12.750
notwendig machen. Wenn die Maschine wieder
da und verfügbar ist, könnt in den Ordner
00:03:12.750 --> 00:03:18.210
/opt/workadventure/contrib/docker wechseln
und mit docker compose up -d WorkAdventure
00:03:18.210 --> 00:03:25.260
starten. Was macht jetzt das Ansible
daran? Erstmal wird Debian 10 auf Testing
00:03:25.260 --> 00:03:30.000
geupdatet und das komplette System wird
auf einen aktuellen Stand gebracht.
00:03:30.000 --> 00:03:34.770
Außerdem werden einige Pakete installiert,
wie zum Beispiel htop, lynis, tmux und
00:03:34.770 --> 00:03:39.600
vieles weiteres. Es wird ein User
angelegt, wie gerade schon erwähnt, der es
00:03:39.600 --> 00:03:43.950
euch ermöglicht, euch später zu diesem
Host zu verbinden. Es werden viele
00:03:43.950 --> 00:03:48.690
Security Settings angezogen, wie zum
Beispiel Firewall-Regeln, configs für den
00:03:48.690 --> 00:03:54.150
ssh daemon, die zum Beispiel verbieten,
dass der root-User sich per ssh auf dem
00:03:54.150 --> 00:03:59.430
Host verbinden kann. All dies sind
Maßnahmen, um euch einen schmerzfreien
00:03:59.430 --> 00:04:03.150
Betrieb zu gewährleisten, wo ihr euch
nicht mehr so viel Sorgen machen müsst.
00:04:03.150 --> 00:04:07.920
Anschließend wird docker und docker-
compose installiert und eingerichtet,
00:04:07.920 --> 00:04:13.320
sodass ihr auch da keine weiteren Probleme
habt. Später wird ein WorkAdventure
00:04:13.320 --> 00:04:19.500
heruntergeladen und für euch
bereitgestellt. Anschließend werden noch
00:04:19.500 --> 00:04:24.390
ein paar config files ausgeliefert, sodass
ihr dann nichts weiter großartig herum
00:04:24.390 --> 00:04:30.810
ändern müsst, sondern gleich loslegen
könnt. Kurz: wie ist WorkAdventure
00:04:30.810 --> 00:04:36.150
überhaupt aufgebaut? Wir finden für die
einzelnen Funktionseinheiten einzelne
00:04:36.150 --> 00:04:42.600
Container. Das Kopfstück hierbei ist der
Reverse Proxy. Dieser wird mit traefik
00:04:42.600 --> 00:04:47.970
realisiert. traefik ist ein Reverse Proxy,
auch wie nginx. Jedoch läuft dieser
00:04:47.970 --> 00:04:53.700
innerhalb von docker und greift auf andere
Container in docker zu. Dies ermöglicht
00:04:53.700 --> 00:04:59.010
eine gewisse Menge an Automatisierung, die
andere Reverse Proxies nicht leisten
00:04:59.010 --> 00:05:06.820
können. Außerdem wird gleich von Haus aus
Let's Encrypt mit angewandt und ihr
00:05:06.820 --> 00:05:10.720
braucht euch keine Sorgen machen darüber,
woher ihr jetzt ein TLS-Zertifikat
00:05:10.720 --> 00:05:17.530
bekommt, damit ihr euren Dienst mit HTTPS
und eurer URL erreichen könnt. Start und
00:05:17.530 --> 00:05:22.870
Stopp der Anwendung wird auch über docker-
compose realisiert. Jetzt werden sich
00:05:22.870 --> 00:05:26.260
vielleicht ein paar Leute denken: "Ja ja
ich hab's eilig, das ist schon so weit da,
00:05:26.260 --> 00:05:31.510
aber irgendwie startet mein compose file
nicht." Das, was ich festgestellt habe,
00:05:31.510 --> 00:05:39.820
was am meisten nerven kann, ist die
Anbindung dieses acme.json Files, was die
00:05:39.820 --> 00:05:45.130
Informationen für das TLS-Zertifikat und
das Setup von Let's Encrypt ausmacht.
00:05:45.130 --> 00:05:49.990
Außerdem kann es durchaus zu Problemen
kommen, wenn der docker socket nicht
00:05:49.990 --> 00:05:54.910
ordentlich erreichbar ist. traefik möchte
mindestens lesend auf den Socket
00:05:54.910 --> 00:05:59.260
zugreifen. Ich bin davon jetzt kein Fan.
Deswegen schränke ich da auch ganz stark
00:05:59.260 --> 00:06:04.090
ein auf read only, lieber wär's mir
allerdings, wenn traefik das nicht tun
00:06:04.090 --> 00:06:09.490
müsste. Außerdem, noch mal: stellt sicher,
dass ihr alle Sub-Domains entsprechend
00:06:09.490 --> 00:06:13.390
konfiguriert habt. traefik wird nicht
ordentlich starten können, wenn nicht
00:06:13.390 --> 00:06:18.175
alle Sub-Domains ordentlich erreichbar
sind. Beim initialen Start vor allem gebt
00:06:18.175 --> 00:06:24.910
traefik ein bisschen Zeit, um alle anderen
Container und deren Schnittstellen zu
00:06:24.910 --> 00:06:30.940
erreichen. Das kann einen Moment dauern
und kann für Irritationen sorgen. Ja, auf
00:06:30.940 --> 00:06:35.590
die Karten bin ich jetzt noch nicht
eingegangen. Grundsätzlich könnt ihr jede
00:06:35.590 --> 00:06:42.730
Karte nehmen und besuchen, die ihr
öffentlich findet. Die genaue Position der
00:06:42.730 --> 00:06:47.980
Karte wird über die URL mit angegeben. Ihr
seht hier in dem Screenshot, in dem rot
00:06:47.980 --> 00:06:52.630
markierten Bereich die quasi URL zu der
Map. Wir sehen hier [die URL] vom
00:06:52.630 --> 00:07:03.590
Raumzeit-Labor, die uns zum Launch-Bereich
des rC3's quasi schickt. Alle Personen,
00:07:03.590 --> 00:07:09.560
die auf euren Host gehen und auf diese
Map, werden dann in der gleichen Instanz
00:07:09.560 --> 00:07:14.870
und in der gleichen Gegend landen. Ihr
seid dann in der Position, miteinander zu
00:07:14.870 --> 00:07:18.680
kommunizieren und zu interagieren. Ihr
könnt natürlich auch eure eigenen Karten
00:07:18.680 --> 00:07:23.330
bauen. Dazu findet ihr Infomaterial auf
der Seite von WorkAdventure, auf Youtube
00:07:23.330 --> 00:07:27.680
und auf anderen Quellen. Seid aber
gewarnt: hier gibt es noch einige Bugs,
00:07:27.680 --> 00:07:31.970
die zumindest mir aufgefallen sind, dass
bestimmte Positionsinformation nicht
00:07:31.970 --> 00:07:37.790
ordentlich interpretiert werden. Macht
euch bereit, dass es hier ab und zu zu
00:07:37.790 --> 00:07:45.170
Frust kommen kann. Noch ein Wort zu Jitsi.
Jitsi ist sehr mächtig. Ihr könnt
00:07:45.170 --> 00:07:49.970
grundsätzlich jeden beliebigen Jitsi-
Server nutzen, der für euch euch
00:07:49.970 --> 00:07:57.530
erreichbar ist. Ich schließe allerdings
den Betrieb eines eigenen Jitsi's im
00:07:57.530 --> 00:08:01.760
Rahmen dieses Deployments aus.
Grundsätzlich würde ich empfehlen, Jitsi
00:08:01.760 --> 00:08:08.150
komplett auf einer eigenen VM oder auf
einem eigenen Cluster zu betreiben. Jitsi
00:08:08.150 --> 00:08:16.640
ist sehr ressourcenhungrig. WorkAdventure
nicht. Einfach aufgrund einer ordentlichen
00:08:16.640 --> 00:08:23.330
Trennung würde ich davon abraten, das im
Mischbetrieb zu fahren. Jitsi kann auf
00:08:23.330 --> 00:08:28.192
sehr viele Arten und Weisen konfiguriert
werden und hat viele Parameter.
00:08:28.192 --> 00:08:31.760
Grundsätzlich wäre hier ein eigener
Vortrag angemessen, den werde ich aber
00:08:31.760 --> 00:08:38.150
nicht leisten. Wie geht es weiter mit
meinem Repository? Ich habe vor, noch mehr
00:08:38.150 --> 00:08:42.440
Energie und Zeit in das Thema Monitoring
zu investieren. Und in das Thema Logging.
00:08:42.440 --> 00:08:45.710
Ich möchte mich hier nicht unbedingt auf
irgendwelche Docker-Befehle verlassen,
00:08:45.710 --> 00:08:50.480
sondern möchte klassische Files. Weil, ich
bin ein klassischer Admin in dem Moment.
00:08:50.480 --> 00:08:55.520
Außerdem stört mich noch das Thema
traefik. Das heraus zu operieren scheint
00:08:55.520 --> 00:09:00.570
aber ein größeres Problem zu sein und
dafür habe ich aktuell noch keine Lösung.
00:09:00.570 --> 00:09:05.470
Ich danke euch für eure Aufmerksamkeit und
freue mich auf die Q&A-Session. Außerdem
00:09:05.470 --> 00:09:08.720
seid ihr eingeladen, mir natürlich auch
bidirektional Fragen zu stellen.
00:09:17.160 --> 00:09:22.750
Herald: Ja - devnope! Danke für den
Vortrag! Da steht ja immer ein bisschen
00:09:22.750 --> 00:09:30.610
Arbeit dahinter, die gar nicht so zwingend
in einem Einführungsvortrag erkennbar ist.
00:09:30.610 --> 00:09:37.480
Aber bis die Fragen eintrudeln - also
liebe Leute im Stream schreibt gerne ins
00:09:37.480 --> 00:09:45.610
Pad eure Fragen rein - vielleicht von mir
eine eine kleine Frage, wie viele Leute
00:09:45.610 --> 00:09:50.980
hast du denn schon so an die Hand genommen
bei einer WorkAdventure-Implementierung
00:09:50.980 --> 00:09:57.880
und Live-Schaltung?
devnope: Ich denke 4 oder sowas. Mit vier
00:09:57.880 --> 00:10:02.410
Leuten habe ich darüber etwas länger
diskutiert und hab denen geholfen, Dinge
00:10:02.410 --> 00:10:08.170
zu debuggen und Dinge zu tun. Ich bin
natürlich für Fragen und weiteres Feedback
00:10:08.170 --> 00:10:12.595
sehr dankbar, damit mehr Leute das nutzen
und nutzen können.
00:10:12.595 --> 00:10:16.120
Herald: Ja. Was was war da so die
häufigste Rückfrage, die du bekommen hast
00:10:16.120 --> 00:10:20.590
von den Leuten?
devnope: Warum startet der Container
00:10:20.590 --> 00:10:28.210
nicht? So grob zusammengefasst war so
meistens das Ding, das ist manchmal ein
00:10:28.210 --> 00:10:33.820
bisschen frustrierend, irgendwie
ordentliche Fehlermeldungen aus dem Docker
00:10:33.820 --> 00:10:39.040
Start rauszubekommen. Gerade so das
traefik und das Frontend, glaube ich, ja
00:10:39.040 --> 00:10:43.360
doch das Frontend, waren so meistens die
Container, die gern etwas zickig sein
00:10:43.360 --> 00:10:50.050
können. Ja, also vielleicht klappt es ja
irgendwann mal, dass man die Informationen
00:10:50.050 --> 00:10:53.590
noch ein bisschen besser aufbereitet
bekommt, damit die Fehlersuche so es
00:10:53.590 --> 00:10:59.350
denn Fehler gibt, leichter ist.
Herald: So, jetzt rollen hier langsam die
00:10:59.350 --> 00:11:04.210
Fragen aus dem Stream rein. Die erste
Frage: Welches Specs sollte der Server
00:11:04.210 --> 00:11:09.040
haben, bei ungefähr wie viel
gleichzeitigen Usern? Hast du da
00:11:09.040 --> 00:11:11.830
Erfahrungswerte?
devnope: Also, ich hab's zwischenzeitlich
00:11:11.830 --> 00:11:16.390
mal mit 20 Leuten probiert und hatte die
zweitkleinste Instanz von Hetzner, das
00:11:16.390 --> 00:11:24.060
sind zwei Standard-CPUs mit 2 GB RAM oder
sowas. Storage braucht das Ding fast kaum,
00:11:24.060 --> 00:11:31.590
also es hat, glaube ich, 10 oder 20 GB,
hat die Standard-VM, die Container-Images,
00:11:31.590 --> 00:11:36.930
die es runterlädt, die sind etwas größer,
wie diesen nodejs-Container. Da hat man,
00:11:36.930 --> 00:11:44.220
glaube ich, am Ende irgendwie 500 MB, 1GB
an dependencies, die da mit runterkommen,
00:11:44.220 --> 00:11:52.590
aber das sollte passen, so weit. So weit
ich das beobachten kann, ist die Nutzlast
00:11:52.590 --> 00:11:58.170
quasi auf dem Server gar nicht so
dramatisch groß wie das jetzt bei... wie
00:11:58.170 --> 00:12:02.940
das jetzt für 100-200 Leute skaliert, kann
ich jetzt nicht sagen in Ermangelung einer
00:12:02.940 --> 00:12:05.910
Testgruppe.
Herald: Schade, dass wäre etwas gewesen,
00:12:05.910 --> 00:12:09.690
das ich mal ausprobieren würde. Aber gut,
die Zukunft ist ja noch lang. Nächste
00:12:09.690 --> 00:12:13.200
Frage: das Ansible - wird das lokal oder
remote ausgeführt?
00:12:13.200 --> 00:12:19.290
devnope: Ich führ's aktuell lokal aus. Ich
hatte da im Hinterkopf, dass es durchaus
00:12:19.290 --> 00:12:23.880
auch Leute gibt, selbst im Admin-Umfeld,
die halt einfach einen Windows Desktop
00:12:23.880 --> 00:12:28.260
haben und Ansible unter Windows-Bedingung
irgendwie zum laufen zu kriegen ist halt
00:12:28.260 --> 00:12:34.860
ein schmerzhaft und da war es einfacher zu
sagen: okay Freunde, ich lad' dir das
00:12:34.860 --> 00:12:38.970
einfach auf die VM direkt runter und
führ's da aus. Da weiß ich, was da für ein
00:12:38.970 --> 00:12:41.910
Linux läuft und was da für ein Ansible
installiert ist. Das funktioniert
00:12:41.910 --> 00:12:48.030
weitestgehend.
Herald: Dann die nächsten brennenden
00:12:48.030 --> 00:12:53.640
Fragen rollen hier zu Jitsi rein. Ich
kombiniere mal die zwei fragen: Welchen
00:12:53.640 --> 00:12:57.900
Jitsi-Server würdest du empfehlen und gibt
es Dinge, auf die man oder mensch achten
00:12:57.900 --> 00:13:06.330
müsste, bei dem Jitsi-Server?
devnope: Ich persönlich nutze meinen
00:13:06.330 --> 00:13:14.160
eigenen Jitsi, den ich auf einer anderen
Instanz betreibe. Da läuft aber noch ein
00:13:14.160 --> 00:13:17.460
bisschen mehr drauf, deswegen - mit Specs
bin ich da ein bisschen vorsichtig.
00:13:17.460 --> 00:13:29.230
Ansonsten: es gibt auch Leute, die nutzen
den public Jitsi von Jitsi direkt. Der
00:13:29.230 --> 00:13:35.470
wird über eine Umgebungsvariable im .env-file
angegeben, ansonsten kann man, habe ich
00:13:35.470 --> 00:13:43.090
gesehen, kann mensch Jitsi-Server und
Jitsi-Räume in den Maps als Properties
00:13:43.090 --> 00:13:49.300
angeben. Und das geht tatsächlich wohl
auch pro Bereich den man halt angibt, also
00:13:49.300 --> 00:13:55.750
das funktioniert halt über Layer und ein
bestimmter Layer kann halt ein bestimmter
00:13:55.750 --> 00:13:59.980
Jitsi-Raum sein und da kann man halt
sagen: alles klar, wir haben jetzt hier
00:13:59.980 --> 00:14:04.180
einen großen Meeting-Saal, wir haben jetzt
hier ein dickes Jitsi, das ist halt nur
00:14:04.180 --> 00:14:10.990
dafür da, da kann ich halt sagen, okay,
extra Property für Jitsi-Server und so
00:14:10.990 --> 00:14:16.000
heißt der Jitsi-Room, und Feuer frei.
Ansonsten ist vielleicht noch drauf zu
00:14:16.000 --> 00:14:21.520
achten, ich hab immer wieder Probleme
gehabt bei Jitsi mit der Authentifikation,
00:14:21.520 --> 00:14:25.960
wenn man dort irgendwie Authentifikation
einbaut und User Management. Da gibt's
00:14:25.960 --> 00:14:30.970
bestimmt Leute, die haben da wesentlich
detailliertere Erfahrungen. Ich hab's bei
00:14:30.970 --> 00:14:33.460
meinen Jitsi-Servern dann einfach
irgendwann gesagt, es interessiert mich
00:14:33.460 --> 00:14:39.310
nicht. Ich mach' die Authentifikation an
der Stelle aus. Grundsätzlich gibt es wohl
00:14:39.310 --> 00:14:46.360
aber die Möglichkeit, auch mit JWT-Tokens
zu arbeiten und da ein bisschen den
00:14:46.360 --> 00:14:51.490
öffentlichen Gebrauch einzuschränken und
auf das WorkAdventure zu limitieren.
00:14:51.490 --> 00:14:58.480
Herald: Ja, das ist, so wie ich das Pad
beobachte, ein Hot Topic. Alle wollen
00:14:58.480 --> 00:15:03.580
WorkAdventure aufsetzen. Uns läuft leider
die Zeit davon. Der Slot ist nicht so
00:15:03.580 --> 00:15:07.750
lang. Sag' noch mal kurz, wie die Leute
dich erreichen können, um die Fragen
00:15:07.750 --> 00:15:12.010
weiter zu diskutieren.
devnope: Ihr könnt mich gerne über Twitter
00:15:12.010 --> 00:15:22.570
erreichen, unter @devnope. Ansonsten bin
ich auch hier im Matrix-Raum vom R2R zu
00:15:22.570 --> 00:15:28.380
erreichen. Genau. Also das sind so die
primären Ansprechmöglichkeiten. Ansonsten
00:15:28.380 --> 00:15:37.560
ist es bestimmt auch möglich, wenn ihr
über GitHub was zukommen lasst, und mich
00:15:37.560 --> 00:15:41.220
anschreit, dann werde ich darauf
entsprechend reagieren.
00:15:41.220 --> 00:15:44.610
Herald: Alles klar. devnope - ganz
herzlichen Dank für deinen Vortrag und das
00:15:44.610 --> 00:15:50.227
Q&A und dann, ja, wir sehen uns hier auf
der Veranstaltung.
00:15:50.227 --> 00:15:53.799
devnope: Vielen Dank und wir sehen uns!
00:15:53.799 --> 00:15:57.359
Outro
00:15:57.359 --> 00:16:06.000
Untertitel erstellt von c3subtitles.de
im Jahr 2021. Mach mit und hilf uns!