Neu in UCS 4.1: Docker Apps für das Univention App Center

Mit Version 4.1 von Univention Corporate Server unterstützt das App Center Docker Apps. Ich möchte an dieser Stelle einen kleinen Rückblick darauf werfen, wie sich das App Center in den letzten Jahren entwickelt hat, über die Gründe sprechen, warum wir auf die Docker-Technologie setzen, einen kurzen Einblick in die technische Umsetzung geben und anreißen, welche Vorteile die Technologie für Apphersteller und Anwender mit sich bringt. Und zum Schluss werde ich auch schon einmal einen kleinen Ausblick darauf geben wie es weitergehen wird.

Das App Center bis UCS 4.0

Das Univention App Center wurde vor drei Jahren eingeführt und hat sich seitdem zu einer zentralen Komponente für UCS entwickelt, weil es die Installation und Wartung von geschäftskritischer Software mit wenigen Klicks ermöglicht. Wir haben großen Zuspruch von Anwendern und Software-Herstellern bekommen und das Angebot ist seitdem stetig gewachsen. 

Das App Center umfasst verschiedene Groupware-Lösungen, Content Management-Systeme, ERP-Software, Tools zur Administration von IT-Infrastruktur, Sicherheits- und Backup-Lösungen. Zudem gibt es noch eine Reihe kleiner, aber wichtiger Spezialsoftware. Kurzum: Mit dem App Center kann man seine UCS-Domäne einfach um die Komponenten erweitern, die man für den produktiven Betrieb benötigt.

Aus Sicht eines Software-Herstellers gestaltete sich die Paketierung seiner Applikation für das App Center unkompliziert: Er musste nur Pakete für das Betriebssystem bereitstellen, ein paar beschreibende Informationen mitliefern und unser App Center-Server lieferte diese Software auf Knopfdruck beim Anwender aus und installierte sie direkt in der Domäne. Allerdings waren die Hersteller immer an die stabile Basis von UCS gebunden. Die App musste auf die Systembibliotheken und Programmiersprachen zurückgreifen, die UCS anbot. Neuere Versionen waren in der Regel nicht möglich; zu groß war die Gefahr, dass das Einspielen einer neuen Version eines Paketes zu Kompatibilitätsproblemen führen könnte.

Auf Univention Seite haben wir die Testabdeckung von UCS ständig erweitert und fahren vor jeder Freigabe einer App automatische Tests nach Installation der App. So stellen wir sicher, dass eine App nicht den Betrieb der gesamten Domäne gefährdet.

Diese Tests wurden aber mit der wachsenden Anzahl von Apps zunehmend schwieriger, da diese sich durchaus auch gegenseitig beeinflussen können. Auch deshalb, weil das App Center die einfache Deinstallation von Software ermöglichen muss, sodass auch dieser Fall gut getestet werden musste. Wir stießen zunehmend an die Grenzen dieser herkömmlichen Apps.

Docker Apps in UCS 4.1

Deshalb begannen wir, nach Alternativen zu dieser Art der Installation – nämlich direkt ins Dateisystem des jeweiligen Servers – zu suchen und beschäftigten uns früh mit Docker. Diese Containertechnologie verspricht, eine dünne, aber sichere Kapselung der Prozesse zu erlauben, sodass jede App ihr eigenes Dateisystem hat, in dem sie tun und lassen kann, was sie will, ohne die Integrität des Servers zu gefährden.

 

Man startet sogenannte Container, die ein vom Rest abgeschottetes System erzeugen, auf das man von außen aber immer noch sehr einfach zugreifen kann. In diesen Containern ist die App installiert. Wichtiges Merkmal ist auch, dass vergleichsweise wenig zusätzliche „Kosten“ auf das zentrale System zukommen, so wird z.B. derselbe Linux-Kernel verwendet.

Echte Virtualisierungslösungen hätten einen ganz anderen Grad an Komplexität mit sich gebracht, wenn man von außen das System hätte anpassen wollen (und das App Center bietet solche Möglichkeiten). Auch wären virtuelle Maschinen bedeutend „teurer“. Und virtuelle Maschinen in ohnehin schon virtuellen Maschinen zu starten bringt noch einmal ganz eigene Herausforderungen mit sich – wenn es denn überhaupt funktioniert – und viele UCS-Systeme laufen heute schon virtualisiert auf Großrechnern in Unternehmen oder in der Cloud.

Docker-Konventionen missachtet!

Docker wird häufig als Lösung für sogenannte „Microservices“ angepriesen. Dabei startet jeder Container genau einen Prozess, der genau eine Aufgabe hat. So benötigt man unter Umständen für eigentlich eine (größere) Aufgabe („Ich will eine Groupware betreiben“) viele einzelne Container. Zum Beispiel einen für das Annehmen von Mails, einen für das Speichern von Postfächern, einen für die Anbindung an das Netzwerk, einen nur für das Logging und so weiter – das ist nur ein Bruchteil dessen, was Groupware heute bietet. Daten werden in der Regel nicht im Container gespeichert, sondern über viele sogenannte Volumes zugänglich gemacht – dem Wirtsystem, aber auch anderen Containern.

 

 

Wir sind bei der Integrationsmöglichkeit von Docker Apps einen anderen Weg gegangen. Wir starten nicht nur einen Prozess – also den einen, der die App ausmacht -, sondern wir starten sozusagen ein gesamtes Betriebssystem. Die Docker Container, die alle Docker Apps benutzen, sind voll funktionsfähige (auf das Nötigste reduzierte) UCS-Systeme. Beim Start des Containers werden sie ordentlich hoch- und beim Stoppen heruntergefahren. Dazwischen starten sie ganz normal die App, die sich in diesen Container installiert.

Damit unterscheidet sich in vielerlei Hinsicht eine Docker App nicht von einer herkömmlichen. Auch die Software-Hersteller müssen für die Integration ihrer Applikation in das App Center weiterhin nur Pakete liefern (nicht etwa eigene Docker-Container). Und Anwender können, wenn nötig, auf ein funktionierendes UCS zugreifen, das dann letztlich doch nur eine Aufgabe hat: Plattform der App zu sein.

Vorteile der Docker Apps

Docker Apps kapseln das Dateisystem rund um die eigentliche App. Für Anwender bedeutet das die erhöhte Sicherheit, dass die App nicht ungewollt anderen Diensten in die Quere kommt. Docker Apps sind einfach zu sichern und bei Problemen ist es deshalb sehr viel einfacher, eine alte Version wieder zurückzuspielen.

Für Hersteller von Apps ändert sich wenig. Sie können weiterhin Apps auf dem bekannten Weg zur Verfügung stellen. Nur werden die Softwarepakete nun nicht mehr auf dem Server selbst, sondern in einem Container installiert. Da sich dieser Container aber in den wichtigsten Punkten nicht vom Wirtsystem unterscheidet, muss sich der Hersteller auch kaum Gedanken über Docker selbst machen.

Großer Pluspunkt für den Hersteller ist, dass er nun frei über das System verfügen kann. Er darf neue Versionen von Paketen installieren, Konfigurationsdateien anpassen, und vieles mehr. Auf Kompatibilität muss er bei Weitem nicht mehr so sehr achten. Tatsächlich kann der Container nun auch das (Container-)Betriebssystem unabhängig vom Wirt aktualisieren. So kann der Container schneller auf eine neue UCS-Version umsteigen als der Anwender für den Rest der Umgebung. Oder er bleibt umgekehrt länger auf der alten Basis.

Wir haben auch viel Arbeit in Schnittstellen zwischen dem Wirtsystem und den Containern gesteckt. Im besten Fall kann der Software-Hersteller nun eine unangepasste Version seiner App bereitstellen („Vanilla“). Die Integration in UCS erfolgt dann über diese Schnittstellen, die außerhalb der Pakete auf dem App Center-Server liegen.

 

 

Für Univention vereinfacht es den Freigabeprozess enorm. Wir müssen keine Lösungen mehr für Apps finden, die sich gegenseitig eigentlich ausschließen. Stattdessen können wir uns auf die Schnittstellen und die Kernkomponenten konzentrieren, während die App-Hersteller UCS um weitere geschäftskritische Lösungen erweitern.

Alles in allem sind wir überzeugt, dass die neuen Docker Apps ein wichtiger Schritt für die technologische Zukunftsfähigkeit des Univention App Center darstellen und für eine spürbare Vereinfachung der Entwicklungsarbeit für Hersteller und einen Gewinn an Komfort und Sicherheit für unsere Anwender sorgen werden.

Wir sind gespannt, wie unsere Docker Apps angenommen werden.

Epilog: Die Zukunft des Univention App Center

UCS 4.1 bringt eine erste Version der Docker Apps mit. Wir haben darauf geachtet, dass die Schnittstellen den Wünschen der Software-Hersteller entsprechen. Für die Zukunft wird die Anzahl dieser Schnittstellen mit Sicherheit weiter wachsen. Hier werden wir mit den Herstellern eng zusammen arbeiten.

Darüber hinaus haben wir bereits den Grundstein dafür gelegt, dass auch „fremde“ Container betrieben werden können. Zunächst haben wir uns auf UCS-Container fokussiert. Aber in Zukunft wollen wir auch andere Betriebssysteme (etwa Ubuntu oder Fedora) unterstützen. Auch denken wir über vom Hersteller selbst gebaute Container nach, die dann doch eher Richtung Microservices gehen.