Zu jeder Software, die langfristig betrieben werden soll, gehören regelmäßige Updates. Diese liefern nicht nur neue Features und Bugfixes, sondern häufig auch wichtige Sicherheitsupdates. Gerade bei öffentlich erreichbaren Systemen sollte man Sicherheitswarnungen und bekannte Schwachstellen daher ernst nehmen und Updates nicht unnötig lange hinauszögern.
Auch Opencast entwickelt sich kontinuierlich weiter. Etwa alle sechs Monate erscheint ein neues Major-Release, das neue Funktionen, Änderungen an bestehenden Komponenten, und teilweise auch technische Umstellungen mit sich bringt. Wer Opencast produktiv betreibt, sollte sich daher frühzeitig Gedanken darüber machen, wie regelmäßige Updates gewährleistet werden können.
In diesem Beitrag soll es darum gehen, wie eine sinnvolle Update-Strategie aussehen kann, welche Schritte man bei Opencast-Updates unbedingt beachten sollte und welche typischen Stolperfallen es zu vermeiden gilt.
Zunächst sollte man sich darüber im Klaren sein, wie lange die aktuell eingesetzte Opencast-Version überhaupt noch unterstützt wird. Offiziell erhalten immer die zwei aktuellsten Major-Versionen weiterhin Bugfixes und Sicherheitsupdates. Durch den halbjährlichen Release-Zyklus bedeutet dies in der Praxis, dass eine Major-Version etwa ein Jahr aktiv gepflegt wird. Mit der Veröffentlichung von Opencast 20 endet damit beispielsweise zeitnah der aktive Support für Opencast 18.x. Spätestens zu diesem Zeitpunkt sollte man ein Update einplanen oder sich zumindest bewusst sein, dass keine weiteren Sicherheitsupdates mehr bereitgestellt werden.
Früher oder später kommt der Zeitpunkt, an dem ein Update durchgeführt werden muss. Doch wie geht man dabei sinnvoll vor? Was sollte man unbedingt beachten und wie stellt man sicher, dass das System nach dem Update weiterhin zuverlässig funktioniert?
Ein guter Ausgangspunkt ist die offizielle Opencast-Dokumentation. Dort finden sich bereits wichtige Hinweise zu notwendigen Migrationsschritten, geänderten Konfigurationen oder neuen Abhängigkeiten. Besonders wichtig ist dabei: Werden mehrere Major-Versionen übersprungen, sollte man unbedingt die Upgrade-Dokumentation aller Zwischenschritte lesen. Wer beispielsweise von Opencast 18.x direkt auf 20.x aktualisieren möchte, sollte sowohl die Hinweise für das Upgrade von 18.x auf 19.x als auch die Dokumentation für das Upgrade von 19.x auf 20.x beachten. Andernfalls besteht die Gefahr, dass wichtige Migrationsschritte übersprungen werden. Dies kann zu fehlerhaften Funktionen führen oder im schlimmsten Fall verhindern, dass Opencast nach dem Update überhaupt noch startet.
Regelmäßige kleinere Updates sind daher meist deutlich einfacher und risikoärmer als große Versionssprünge nach mehreren Jahren.
Bevor Änderungen am Produktivsystem vorgenommen werden, sollten zunächst alle wichtigen Komponenten gesichert werden. Dazu gehören insbesondere:
/etc/opencast/ auf allen Opencast-Servern,Nur so besteht im Fehlerfall die Möglichkeit, das System wieder in den ursprünglichen Zustand zurückzuversetzen und das Update später erneut durchzuführen.
Zusätzlich empfiehlt es sich dringend, Updates zunächst in einer Testumgebung durchzuführen. Gerade bei größeren Versionssprüngen lassen sich viele Probleme bereits im Vorfeld erkennen, ohne dass der Produktivbetrieb beeinträchtigt wird. Die Testumgebung sollte hierfür möglichst genau den Produktivbetrieb widerspiegeln. Genauer gesagt dürfen Spezifikationen wie RAM oder CPU natürlich herunterskaliert werden, aber wenn das Produktivsystem über mehrere Server verteilt ist, sollte die Testumgebung dies idealerweise replizieren.
Ebenso wichtig ist es sich mit Hilfe der Dokumentation zu informieren, ob sich die Versionsanforderungen bestimmter Komponenten geändert haben. Es kann beispielsweise der Fall sein, dass eine neuere Java oder MySQL/PostgreSQL Version gefordert wird. Die entsprechenden Updates können in den allermeisten Fällen ohne Probleme vor dem eigentlichen Opencast Update durchgeführt werden, sodass die potentiellen Fehlerquellen minimiert werden können.
Eine der häufigsten Fehlerquellen bei Opencast-Updates sind Änderungen an Konfigurationsdateien.
Über mehrere Versionen hinweg könnten sich z.B. folgende Dinge ändern:
Gerade bei Systemen mit vielen individuellen Anpassungen verliert man dabei schnell den Überblick. Besonders tückisch ist, dass Opencast häufig weiterhin startet, obwohl einzelne Konfigurationen fehlerhaft oder veraltet sind. Probleme fallen dadurch oft erst später im laufenden Betrieb auf. Es empfiehlt sich daher, die vorhandenen Konfigurationen sorgfältig mit den neuen Standardkonfigurationen der Zielversion zu vergleichen und Änderungen bewusst nachzuvollziehen.
Hilfreich kann es außerdem sein, sämtliche Konfigurationen über Git und beispielsweise Ansible zu versionieren. Dadurch lassen sich Änderungen zwischen verschiedenen Opencast-Versionen deutlich einfacher nachvollziehen, dokumentieren und bei Bedarf auch wieder rückgängig machen.
Bei verteilten Opencast-Installationen sollte zudem berücksichtigt werden, dass sich bestimmte Konfigurationen zwischen den einzelnen Knoten unterscheiden können. Dazu gehören beispielsweise die Server-URL oder Hostnamen In solchen Umgebungen reicht es daher nicht aus, lediglich die Konfiguration eines einzelnen Servers zu sichern oder zu überprüfen. Stattdessen sollten die Konfigurationen aller beteiligten Systeme in die Update-Planung und den Konfigurationsvergleich einbezogen werden.
Auch die Datenbank kann bei Opencast-Updates eine Fehlerquelle darstellen. Vor dem Update sollte geprüft werden, ob die eingesetzte Datenbankversion von der Zielversion von Opencast weiterhin unterstützt wird. Die entsprechenden Anforderungen ändern sich von Zeit zu Zeit und sind in den Release Notes bzw. der Upgrade-Dokumentation dokumentiert.
Bei einem Update sind gelegentlich Migrationsschritte erforderlich. Hierfür werden in der Regel Skripte bereitgestellt, die den Migrationsprozess automatisieren. Dabei ist darauf zu achten, die zum verwendeten Datenbanksystem passenden Skripte zu verwenden (MySQL oder PostgreSQL).
Selbstverständlich sollte außerdem vor jeder Datenbankmigration ein vollständiges Backup durchgeführt werden. Im Idealfall wird auch getestet, ob sich dieses Backup tatsächlich wiederherstellen lässt. Ein Backup, das sich im Ernstfall nicht zurückspielen lässt, ist natürlich wenig hilfreich.
Nach dem Update empfiehlt sich zudem ein Blick in die Opencast-Logs. Warnungen oder Fehlermeldungen im Zusammenhang mit Datenbankmigrationen sollten ernst genommen und zeitnah untersucht werden.
Jede Opencast-Installation verwendet zusätzlich Elasticsearch bzw. OpenSearch für die Suchfunktionen und allgemein Indizierung der Daten.
Bei Opencast-Updates kann es hier zu Problemen mit veränderten Index Schemata und nicht korrekt durchgeführte Migrationen kommen. Typische Symptome sind:
In den meisten Fällen werden für ein Major-Update Skripte zur Verfügung gestellt, die die nötigen Migrationsschritte des Index durchführen können. Hier gilt es zu beachten, dass vor Ausführung der Skripte ggf. noch Anpassungen wie die URL zu Elasticsearch/OpenSearch oder User/Passwort im Skript angegeben werden müssen. In manchen Fällen ist nach dem Update aber auch eine vollständige Neuindizierung notwendig. Diese kann, je nach Anzahl der vorhandenen Videos und verfügbarem Arbeitsspeicher, in Extremfällen durchaus bis zu mehreren Stunden in Anspruch nehmen. Im Zweifel ist auch hier wieder die entsprechende Dokumentation zu Rate zu ziehen.
Workflows gehören zu den zentralen Komponenten einer Opencast-Installation. Gleichzeitig sind sie häufig individuell angepasst und damit besonders anfällig für Probleme nach Opencast-Updates. Neue Operationen, geänderte Parameter oder veränderte Default-Werte können dazu führen, dass bestehende Workflows plötzlich fehlschlagen oder sich anders verhalten als zuvor.
Da viele dieser Probleme nicht unmittelbar sichtbar sind, empfiehlt es sich dringend, nach dem Update mehrere Testaufnahmen hochzuladen und zu überprüfen, ob sich die genutzten Workflows nach wie vor wie gewünscht verhalten.
Änderungen an API-Endpunkten, Authentifizierungsmethoden oder z.B. ein Wechsel zentraler Komponenten wie des Videoplayers, können selbstverständlich auch Auswirkungen auf jegliche angebundene Systeme z.B. Learning-Management-Systeme wie Moodle, Ilias oder StudIP haben.
Hierbei ist es wichtig, darauf zu achten, dass die jeweils installierten Opencast Plugins mit der neuen Opencast Version kompatibel sind. Die Plugins bieten teilweise eine Vielzahl an Konfigurationsmöglichkeiten, die unter Umständen nach einem Update aktualisiert werden müssen.
Typische Fehlerbilder, die vor allem nach Konfigurationsanpassungen auftreten können, sind zum Beispiel:
Neben den Opencast Logs, empfiehlt es sich bei Problemen ggf. auch die Entwicklertools des Browsers zu Rate zu ziehen und zu überprüfen, ob bereits aussagekräftige Fehlermeldungen im Browser angezeigt werden.
Je stärker eine Opencast-Installation in bestehende externe Systeme integriert ist, desto wichtiger wird es, diese Schnittstellen als festen Bestandteil der Update-Tests zu betrachten. Oft sind es nicht die eigentlichen Opencast-Komponenten, sondern genau diese Integrationen, die nach einem Update unerwartete Probleme verursachen können.
Ein erfolgreich abgeschlossenes Update bedeutet nicht automatisch, dass auch wirklich alle Funktionen weiterhin fehlerfrei arbeiten. Deshalb sollte nach jedem Update ein strukturierter Funktionstest durchgeführt werden.
Dazu gehören insbesondere:
Ebenso wichtig ist ein genauer Blick in die Logs. Fehlermeldungen sollten nicht ignoriert werden, selbst dann nicht, wenn das System auf den ersten Blick funktionsfähig erscheint.
Opencast-Updates sind ein wichtiger Bestandteil eines langfristig stabilen und sicheren Betriebs. Gleichzeitig bringen sie durch die Vielzahl an Komponenten und Konfigurationsmöglichkeiten auch einige Herausforderungen mit sich.
Wer Updates regelmäßig durchführt, die Dokumentation sorgfältig liest und Änderungen zunächst in einer Testumgebung überprüft, kann viele typische Probleme bereits im Vorfeld vermeiden.
Besonders wichtig sind dabei:
Regelmäßige kleinere Opencast-Updates sind dabei in der Regel deutlich einfacher zu bewältigen als große Versionssprünge nach mehreren Jahren.
Natürlich unterstützt der elan e.V. auch direkt bei der Planung und Durchführung von Opencast-Updates oder übernimmt diese vollständig.
