Alina: Erzähl uns doch erst einmal ein wenig über dich.

Bastian: Ja, gerne. Ich arbeite im Team von Nico Roeser an der Universität Regensburg. Ursprünglich wurde ich eingestellt, um eine Migration von ILIAS auf Moodle umzusetzen. Das änderte sich dann aber doch recht schnell, als klar wurde, dass EDUTIEK (derzeit) nur für ILIAS verfügbar ist. Unsere e-Prüfungsplattform muss also weiterhin auf ILIAS laufen und möglichst up to date sein.

Und hier kommen wir auch schon zum eigentlichen Problem. Zuletzt lief die nämlich mit der Version 5.4. Die IT-Security hatte entsprechend oft gemeckert, denn regelmäßig fiel dieses Thema bei Reports auf. Nico hat zwar über die Zeit alle relevanten Security-Patches nachgezogen, aber dennoch war das so nicht mehr tragbar.

Ihr musstet also updaten.

Genau. Ich kam Mitte/Ende Juli aus meinem Urlaub zurück. Nico sagte mir, wir müssen bis zum 15. August dieses Update durchhaben. „Willkommen zurück“. So ungefähr.

Das klingt stressig. War das denn überhaupt machbar?

Naja, es waren etwa zwei Wochen. Und in dieser Zeit sollten wir unser ILIAS auf 11 updaten und auf einem Kubernetes-Cluster zum Laufen kriegen. Es gab aber so viele Dinge, die vorab geklärt werden mussten. Wir haben uns deshalb dazu entschieden, erst mal „nur“ das Update zu machen und dann nachträglich eine Migration auf Kubernetes anzustoßen. Denn der Zeitdruck war noch größer: Die Prüfungsphase endete am 11. August und bis zum 15. August sollte alles stehen… Den 12. musste ich aus persönlichen Gründen frei nehmen, deswegen verlief das Upgrade bei uns am 13. und 14. August. Wie gesagt, erst mal ohne den Kubernetes-Cluster.

Was ist ein Kubernetes-Cluster genau?

Gehen wir dafür am besten ein paar Schritte zurück zu einem Docker-Container. Docker ist eine freie Software, mit der sich Anwendungen in Containern isoliert ausführen lassen. Die Anwendung läuft dabei in einem Docker-Container – entweder lokal auf deinem Rechner oder auf einem Server. Diese Funktion haben wir uns für unser eigentliches Update auch zunutze gemacht. Dazu aber gleich mehr.

Legt man mehrere Server mit Docker-Containern zusammen, spricht man von einem Cluster. Und um das zu managen, gibt es Kubernetes.

Mit Kubernetes kann man beispielsweise mehrere Instanzen eines Containers gleichzeitig laufen lassen. Fällt eine davon aus, kann Kubernetes automatisch eine neue starten. So lässt sich eine Anwendung auch bei Ausfällen verfügbar halten. Das nennt man High Availability. Außerdem kann man festlegen, wie viele Instanzen einer Anwendung parallel laufen sollen und diese Anzahl bei Bedarf erhöhen oder verringern. Das ermöglicht eine flexible Skalierung, also Scalability.

Das sind echte Vorteile von Kubernetes. Genau dahin soll unsere Reise gehen. Testweise haben wir das schon umgesetzt – nur eben derzeit noch nicht produktiv.

Erzähl uns von dem Update. Man darf bei ILIAS ja keine Major-Version überspringen. Wie habt ihr das gemacht?

Ja, genau. Wir haben mehrere Docker-Images gebaut. Für jede ILIAS-Version eins (außer ILIAS 6 – die konnte man als einzige überspringen). Zur Erläuterung: Bei Docker kannst du eine Datei erstellen, die beschreibt, wie deine Maschine aussehen soll. Das sind sogenannte Docker-Files, die dann Docker-Images erzeugen. Diese kannst du dann so oft du willst reproduzieren. In diesen Files gibst du bspw. auch die PHP-Version an, welche Dependencies benötigt werden und welcher ILIAS-Datenstand genutzt werden soll. Und am Ende läuft dein ILIAS in der entsprechenden Version auf dem Docker.

Und dann ging‘s los. Und das dann relativ elegant.

Wir haben uns zunächst einmal alle Daten vom alten Produktivsystem gezogen. Diese wurden dann in den Docker-Container kopiert. Da macht man dann das Update und damit wird auch der Datenbestand geupdatet. Dann gehen die Daten auf den nächsten Docker-Container, den vorherigen fährt man runter, fährt den anderen hoch, zieht das Update und wiederholt das Ganze bis ILIAS 11.

Das klingt trotzdem ganz schön aufwendig.

Dank der Vorarbeit war das relativ entspannt und man musste sich im Hintergrund nicht um irgendwelche Dependencies kümmern. Man musste sich nicht um PHP kümmern. Man musste nicht schauen, dass im Hintergrund alles läuft, weil das alles schon durch die Docker-Images geregelt war.

Bei uns hat das insgesamt 2 Tage gedauert. Ein Tag war das Upgrade selbst, am zweiten Tag haben wir Bugfixing betrieben und die Firewall wieder runtergefahren. Diese hatten wir zuvor aktiviert, damit alles „gelockt“ ist und niemand daran arbeiten kann, während wir da rumbasteln und Updates machen.

Und so sind wir dann circa innerhalb von 48h von ILIAS 5.4 auf ILIAS 11 gegangen. Mit Testsystem und so weiter haben wir für alles insgesamt 4 Tage gebraucht.

Dadurch, dass wir ILIAS nur als e-Prüfungssystem nutzen, war unser Datenbestand aber auch relativ klein. Ich habe von anderen gehört, dass da eine Migration schon mal mehrere Tage dauern kann, weil bspw. 3 Terabyte an Daten vorhanden sind. Bei uns waren das, glaube ich, 240-260 GB an Datensätzen und circa 13-17 GB MariaDB-Dump. Das ist sehr überschaubar.
Ich kann also mit meinem Erfahrungsbericht nicht garantieren, dass so ein Update bei anderen ebenfalls so schnell geht.

Und hattet ihr Schwierigkeiten?

Tatsächlich ging das alles relativ reibungslos. Wir hatten nur einmal – ich glaube von 9 auf 10 - komische Einträge in der Datenbank. Beim Update hatten wir dann plötzlich 23 Testabgaben, bei denen in zwei Tabellenfeldern jeweils null stand.

Es gab also ein Problem mit den vorhandenen Daten. Wir konnten die Testabgaben allerdings auch niemandem mehr zuordnen. Also weder zu einem Test noch zu einem Testteilnehmer. Am Ende haben wir uns daher dazu entschieden, diese 23 Daten zu löschen. Unser e-Prüfungssystem läuft bei uns jetzt seit 10 Jahren. Da sind 23 einzelne Testdaten nicht die Welt. Vor allem dann, wenn wir sie gar nicht mehr zuordnen können.

Gab es technische Probleme oder Bugs nach dem Update? Wird schon auf eurem System gearbeitet?

Ja, es arbeiten schon Leute am System und bereiten Prüfungen vor. Wir haben selber intern nach dem Update getestet und konnten das ein oder andere patchen. Es scheint aber erst mal so zu laufen, wie es soll.
Wie sich das System final schlägt und ob es weitere Probleme gibt, zeigt sich aber erst in der nächsten Prüfungsphase.

Hattest du zuvor schon viel mit ILIAS gearbeitet? Wie war das für dich aus Sicht eines Systemadministrators?

Eigentlich war ich ja für die Migration zuständig und nicht für den Betrieb von ILIAS. Die Berührungspunkte mit ILIAS an sich waren da also recht überschaubar. Ich hab bisher eher mit ILIAS 11 und 12.alpha gearbeitet. Das liegt daran, dass die Jura-Fakultät auf uns zukam, weil sie gerne EDUTIEK nutzen wollte. EDUTIEK gibt es aber erst mit ILIAS 9. Da unser Update zu dem Zeitpunkt noch nicht abzusehen war, habe ich für die Juristen ein ILIAS 9 aufgesetzt. Das war meine Aufgabe. Und so kam ich also mit ILIAS erstmals intensiver in Kontakt.

Als Systemadministrator finde ich ILIAS relativ entspannt. Ich kann mich eigentlich nicht beschweren. Die Doku war relativ gut. Was mir zum Beispiel gefehlt hat – und ohne Nico wäre ich da nie drauf gekommen – war die Info zum Initialpasswort. Das habe ich selber irgendwie nicht gefunden. Also ich weiß, in ein paar Kommentaren und wohl auch in der Doku ist es vermerkt, aber irgendwie konnte ich es nicht finden.

Beim Aufsetzen hatte ich aber keine Schwierigkeiten.

Meine Irrungen und Wirrungen hatte ich jedoch beim Erstellen eines Features. Ich entwickle keinen ILIAS-Kern, aber ich habe einen Feature Request umgesetzt. Das Feature habe ich in ILIAS 12.alpha komplett durchentwickelt.
Bis man sich da richtig eingefuchst hat, dauert es mitunter. Da ist die Doku dann doch stellenweise noch ausbaufähig oder schwierig zu finden. Ich fühlte mich zu Beginn, als würde ich wie vor einer riesigen Mauer stehen. ILIAS ist ziemlich verschachtelt. Da muss man erst reinkommen. Ist die Mauer aber einmal bezwungen, kommt man klar.

Aber dein Feature ist noch nicht im Kern?

Nein. Die Daten liegen vor und es wäre meiner Meinung nach ready. Es müsste nur noch durch den Review gehen. Aber die Bürokratie im Hintergrund ist für uns gerade der hindernde Faktor. Denn das Feature sehen wir mittlerweile eher als Komponente. Und Komponenten brauchen Authorities. Aber die Universität Regensburg hat nicht die Ressourcen, um Authorities zu stellen. Daher müssen wir mal schauen, wie es damit weitergeht.

Worum geht es denn in eurem Feature?

Man kann aktuell ja schon den Zugriff auf Tests IP-adressbasiert einschränken. Wir wollen aber gerne noch weitere Arten der Beschränkung unterstützen. Außerdem wollen wir sogenannte "IP-Adressdefinitionen" einführen. ILIAS-Admins können dann festlegen, welche IP-Adressen zu welchem Prüfungsraum gehören.

Bei Interesse kann alles Weitere im Feature Wiki nachgelesen werden:
hier https://docu.ilias.de/go/wiki/wpage_8863_1357 und
hier https://docu.ilias.de/go/wiki/wpage_8827_1357.

Abschließend möchte ich noch einen großen Dank an mein Team richten. An Nico und an Mark. Ohne die beiden hätte ich das nämlich nicht geschafft.

Vielen Dank Bastian, für deine Zeit und deinen Einblick in euer wirklich spannendes Update. Ich habe durch unser Interview tatsächlich noch das ein oder andere gelernt. Und wer weiß, vielleicht kann auch ein Systemadministrator von euren Ideen profitieren.