Nachricht | 04. Juli 2022

Eine automatisierte Wikibase deployment pipeline für Forschungsdatenmanagement

Von Paul Duchesne

Motivation und Methoden für das Deployen von Wikibase Test- und Produktionsinstanzen am Open Science Lab, TIB – Leibniz Informationszentrum für Technik und Naturwissenschaften

Als Teil unserer Arbebit in NFDI4Culture, wurde im Open Science Lab der Aufbau eines verlässlichen und konfigurierbaren Deploymentprozess for Wikibase begonnen. Die Anroderungen sind basierend auf den Forschungsbedarfen im Kontext on Linked Open Data und Annotationen von komplexen Medienobjekten natürlich gewachsen und beinhalten signifikante Änderungen im Vergleich zu der Wikibase Installation, die von WMDE zur Verfügung gestellt wird. Unsere Deploymentmethode hat sich von einer Liste von Kommandozeilenbefehlen zu einem vollautomatisierten Ansible playbook weiterentwickelt.

 

Deployment

Unser gesamter Deploymentprozess läuft über Ansible. Dieses Tool ist dafür gedacht, dass Entwickler Systeme auf die immer gleiche Weise installieren können. Es ist deshalb so vorteilhaft, weil die Zielservern keine bestimmten Voraussetzungen erfüllen müssen. Außerdem skaliert , da die Playbooks beliebig oft auf beliebig vielen Servern ausgeführt werden können.

Ein weiterer Aspekt ist, dass auf diese Weise viel Zeit eingespart werden kann. In einem Deployment Playbook können zahlreiche Stadien abgedeckt werden; vom Installieren der benötigten Tools, über das Erstellen von eigenen Containern  bis hin zu Konfigurationen nach der Installation. Wir haben eine vollständige NGINX Konfiguration in das Playbook eingefügt. Dies beinhaltet das automatische Anfragen von SSL Zertifikaten. Dies wird zwar nicht länger in unserer eigenen Konfiguration genutzt, kann aber für andere nützlich sein, wenn ein komplettes HTTPS setup gewünscht ist.

Es folgt eine Übersicht der verschiedenen Rollen innerhalb des Playbooks:

• User
  Dieser Prozess beginnt damit, einen non-root User account anzulegen und die geforderten SSH Keys zu migrieren, um einen direkten Login für den neuen Account zu ermöglichen.

• Nginx
  NGINX wird installiert, Zertifikate und Konfigurationen generiert, und das System wird neu gestartet, sodass es sofort benutzt werden kann. Um Idempotency zu erreichen, werden Zertifikate nur generiert, wenn sie noch nicht exisitieren. Nutzende sollten sich beim Testen bewusst sein, dass LetsEncrypt rate limits vorgibt, die sehr schnell erreicht werden.

• Docker
  Diese Stufe installiert Docker und Docker Compose, die für die Containerkomponenten der Installation benötigt werden. Containerisation ist ein Prozess, der eine Anwendung mit einer generalisierten und vorhersehbaren Umgebung umgibt, wodurch vermieden wird, dass die Anwendung sich auf verschiedenen System unterschiedlich verhält.

• Custom Query UI
  Durch die Arbeiten von Rhizome inspiriert, die ihr eigenes Query Interface angepasst haben, haben wir ein Fork mit customising their own query interface,  weiteren Modifikationen erstellt. Dazu gehören stylistsche Elemente, sowie zusätzliche Custom Prefixes für das Query Building. Zur Zeit läuft das Deployment über Konfigurationsdateien mit Templates und das Erstellen eines Dockerimages als Teil des Playbooks. In Kürze werden wir dies auch als versionierten Container veröffentlichen, der nach dem Build konfiguiert werden kann.

• Wikibase
  Als nächstes wird Wikibase installiert. Dies wird dadurch erreicht, dass die nötigen Templates und Skripte auf den Zielserver geschrieben werden und und alle Docker Container mit einer einzigen Docker Compose configuration file gestartet werden. Der Großteil dieser Docker Konfiguration unterscheidet sich nicht von der Standardeinstellung, mit einigen wenigen Änderungen, um HTTPS support zu ermöglichen. Die Wikibase configuration file wurde modifiziert, um Erweiterungen zu integrieren, wie zum Beispiel Das Hosten von lokalen Mediendateien, das Erzwingen von Login und Accountbestätigung um Edits vornehmen zu dürfen, Email Server Konfiguration um Wikibase zu erlauben, Benachrichtigungen zu verschicken, und ein Custom Namespace für "Description" pages. Letzteres erfüllt das im Forschungsdatenmanagement häufige Bedürfnis, auch längere Texte darzustellen, wofür diese separat von den strukturierten Statements gespeichert werden müssen. Außerdem gibt es typische Styleupdates: Logo, Icon und Wikibase Name.

• ConfirmAccount
  Obwohl ConfirmAccount durch die Wikibase Konfiguration angefragt wird, muss die Erweiterung selbst installiert werden. Hier wird der aktuelle Release heruntergeladen, entpackt und an den richtigen Ort verschoben. Außerdem läuft das nötige maintenance PHP script um die Wikibase SQL Database upzudaten.

• Prefixes
  Einige Prefix Updates müssden der Query Konfiguration hinzugefügt werden, damit die Customization als Teil des Query Interfaces deployed werden kann.

• Reconcile
  Der letzte Schritt beim Deployment ist das Aktivieren eines Reconciliation Endpoints, sodass Daten über OpenRefine in die Wikibaseinstanz geschrieben werden können. Bevor die Anwendung installiert werden kann, müssen Edit Tags für verschiedene OpenRefine Versionen erstellt werden. Dies wird durch ein kurzes Python script erreicht. Danach wird die Servicekonfiguration mit spezifischen Informationen über die Wikibase Instanz erstellt und der Service wird gelauncht.

Produktion und Testarchitektur

Wie bei anderen Projekten der TIB wird jedes Wikibase Deployment mit jeweils einer Instanz für Produktion, Tests und Entwicklung aufgesetzt, jede auf einem eigenen Debian Server. Der Vorteil daran, auf jedem dieser Server das gleiche Ansible playbook für die Installation zu nutzen ist, dass Tests und Entwicklung in einer identischen Umgebung zur Produktionsinstanz vorgenommen werden. Die Datensynchronisation wird über eine SQL Datenbank mit Snapshort gemacht und wird regelmäßig von der Produktions- auf die Testinstanz überspielt.

Maintenance

Die Pflege der Wikibaseinstanz wird einem separaten Playbook kontrolliert, das den automatiscen Snapshotprozess managed und sicherstellt, dass die Daten im Fall eines Serverfehlers erhalten bleiben, sowie regelmäßige Datenbanküberschreibungsoperationen erleichtert. Eine geplante Erweiterung dieses Playbooks wird die Integration von System Monitoring Taks sein, die sicherstellen, dass der Service so wie erwartet reagiert. Das Playbook wird außerdem an ein Schedulingsystem wie Apache Airflow übergeben, sodass die normalen Operationen ohne menschliche Interaktionen durchgeführt werden können.

Die Benutzung von Ansible ist über das Deployment hinaus nützlich, da Systemupgrades für Mediawiki, Wikibase und andere containerisierte Komponten automatisch über die jeweiligen Server abgefragt werden können. So bleibt die Maintenance des Systems möglich, auch wenn die Zahl der verwalteten Instanzen steigt.

Zukünftige Arbeiten

Der oben beschriebene Prozess hat es möglich gemacht, Wikibaseinstanzen zu deployen, die maßgeschneidert die Bedürfnisse von unterschiedlichen Forschungsdatenmanagement Use Cases erfüllen. Dies geschieht mit wenig Aufwand und der Sicherheit, dass der resultierende Service stabil und anwendungsbereit ist. Weitere Arbeiten werden sich auf zusätzliche Strategien fokussieren, mehrere Deployments zu verwalten, verbessertes Monitoring der System hinzuzufügen und weitere Tools und Konfigurationsmöglichkeiten je nach Bedarf zu integrieren.

 

Autor: Paul Duchesne, Open Science Lab, TIB

Erstveröffentlichung: 6. Juli 2022