Anwendungsbereitstellung mit Turbo.net

Lesezeit
4 Minuten
Bis jetzt gelesen

Anwendungsbereitstellung mit Turbo.net

27.03.2020 - 10:21
Veröffentlicht in:
Das Bereitstellen von Anwendungen spielt gerade jetzt zu Home-Office-Zeiten eine entscheidende Rolle. Neben der herkömmlichen Installation von Anwendungen haben sich hier auch Technologien zur Virtualisierung von Anwendungen wie App-V von Microsoft durchgesetzt. Andere Produkte wie VMware ThinApp oder AppStreaming von Citrix sind wieder vom Markt verschwunden. In diesem Artikel stellen wir mit Turbo.net eine derzeit noch wenig bekannte Software vor.
Im Wesentlichen ist Turbo.net [1] ein Framework das es erlaubt, Windows-Anwendungen in einem Container zu installieren und somit schnell und vor allem portabel auf allen Desktops sowie in der Cloud bereitzustellen. Praktisch ein "virtueller Desktop ohne virtuellen Desktop", da Turbo Anwendungen ohne die ganze Virtualisierungsschicht und Betriebssystem auf den virtuellen Desktop bekommt. Im Gegensatz zu anderen Virtualisierungslösungen, die oft eine vollständige Kopie des Host-Betriebssystems erfordern, emuliert die Turbo-Container-Technologie nämlich nur die für die Ausführung der Anwendung erforderlichen Funktionen. Turbo-Container haben die gleichen Leistungsmerkmale wie native Anwendungen, jedoch ohne Änderungen an der Systeminfrastruktur.

Wer jetzt Container hört, wird zwangsläufig an Docker-Container denken. Abgesehen davon, dass Docker eine auf Linux (LXC) basierende Container-Umgebung ist, existieren diverse Gemeinsamkeiten. Turbo.net ist allerdings von Anfang an ausschließlich für Windows entworfen worden und unterstützt durch die Turbo Application Virtualization Engine sowohl Server- als auch Client-Applikationen ab Windows XP. Anders als bei Docker können Turbo-Container aus mehreren Containern dynamisch erstellt und verwendet werden.

Um beispielsweise einen Container für eine Java-Anwendung zu erstellen, die eine MongoDB-Datenbank verwendet, könnten Sie einen Container mit der Java-Laufzeitumgebung mit einem MongoDB-Datenbank Container kombinieren und den Anwendungscode in einer Anwendungsebene in einem weiteren Container stapeln. Dieses Layering von Containern macht die Wiederverwendung von gemeinsam genutzten Komponenten wie Laufzeitumgebungen, Datenbanken und Plug-ins sehr einfach.

Schlanker Kernel
Der Hauptkomponente der Turbo.net-Technologie ist der Turbo-VM-Kernel. Dieser Kernel ist eine minimale Implementierung von Kernbetriebssystem-APIs, einschließlich Dateisystem-, Registry-, Prozess- und Threading-Subsysteme. Vom Umfang belegt das weniger als ein MByte Speicher und hat somit fast keinen Performance-Overhead auf die Anwendung. Der Turbo-Kernel wird dabei vollständig im User-Space-Bereich implementiert, das bedeutet, Turbo-Anwendungen können ohne Treiberinstallation oder Administratorrechte laufen. Und das gilt selbst dann, wenn die Anwendung im Turbo-Container erweiterte Rechte benötigt.

Anwendungen in einem Turbo-Container interagieren mit einer virtualisierten Dateisystem-, Registry- und Prozessumgebung, die im Kernel enthalten ist. Anfragen werden intern innerhalb der virtualisierten Umgebung abgewickelt, können aber auch basierend auf Ihrer Konfiguration umgeleitet oder sogar überschrieben werden. Um mit Turbo.net zu beginnen, reicht uns bereits der kostenlose Account, den wir uns auf der Website von Turbo.net relativ einfach erstellen können.

Als kleinen zusätzlichen Vorteil lassen sich die Container persistent halten. Änderungen, die in dem lokalen Container vom Benutzer vorgenommen werden, werden als Delta auf dem Hub-Server gespeichert und stehen beim nächsten Start des Containers wieder zur Verfügung. Diese Synchronisierung ist benutzerbasiert, Sie haben also in jedem Container auch gleich die Anwendungsdaten enthalten und müssen sich im lokalen System oder über ein Profilmanagement nicht mehr darum kümmern.


Bild 1: Über Repositories stehen die Anwendungen zur Verfügung.

Applikationen aus dem Repository
In der kostenlosen Variante sind Sie an den Turbo.net-Hub als öffentliches Repository gebunden. Allerdings werden Änderungen immer nur in unseren eigenen Account synchronisiert und stehen nicht jedem Benutzer zur Verfügung. Mit einem kostenpflichtigen Account können Sie einen eigenen, privaten Hub-Server betreiben und diesen auch über die Turbo.net-Hub-Server synchronisieren.

Das ist dann sinnvoll, wenn Sie eigene Anwendungen bereitstellen möchten. Diese sind oft auch an eine eigene Lizensierung gebunden und sollten sicher nicht in einem öffentlichen Repository bereitstehen. Sie können jedoch trotzdem die Anwendungen nutzen, die bereits im öffentlichen Hub von Turbo.net bereitstehen und diese in unseren eigen Hub-Server importieren.

Ein großer Vorteil dieses Ansatzes ist, dass Sie nicht nur Windows-Endgeräte verwenden können. Alle Container lassen sich auch über einen Anwendungsserver ausführen. Das funktioniert bei Endgeräten ohne einen Turbo-Client im Browser über HTML 5 und mit installiertem Turbo-Client auch als eigenes Fenster. Diese Anwendungsserver lassen sich getrennt vom Hub installieren und, je nach Anzahl der Benutzer, beliebig auch in die Cloud, etwa in Microsoft Azure, skalieren. Die Technologie dahinter verhält sich ähnlich wie beim bekannten Citrix XenApp. Der Turbo-Client ist derzeit auch für macOS, iOS und Android verfügbar.

Turbo.net in Betrieb nehmen
Für erste Versuche mit der Turbo.net-Technologie benötigen Sie neben dem kostenlosen Account natürlich den installierten Turbo.net-Client, der die komplette Umgebung inklusive des Turbo-VM-Kernels bereitstellt. Diesen können Sie im Downloadbereich herunterladen und installieren.

Prinzipiell ist der Client eine reine Konsolenanwendung, die lediglich die Laufzeitumgebung für die Anwendungs-Container bereitstellt. Der Zugriff auf die Anwendungen erfolgt über einen Hub-Server, der uns die Anwendungen in einem Browser anzeigt. Hier lässt sich in der kostenlosen Variante der Hub-Server von Turbo.net verwenden. Mit einer entsprechenden Lizenz sind aber auch Hub Server im eigenen Netzwerk als auch in der Cloud möglich.

Auf einem Windows-System starten Sie die Anwendung aus dem Hub Server einfach mit einem Klick auf das entsprechende Icon. Der Start der Anwendung verläuft relativ unspektakulär: Der Container wird beim Ausführen vom entsprechenden Hub-Server heruntergeladen und über den Client gestartet. Je nach verfügbarer Bandbreite und Größe des Containers dauert das erste Starten einen kleinen Augenblick, da der Container erst auf das lokale System heruntergeladen werden muss. Jeder weitere Start der Anwendung verhält sich dann wie bei einer lokal installierten Anwendung. Im Taskmanager sehen wir die gestarteten Container als Subprozess des Turbo-VM-Kernels. In unserem Beispiel haben wir Chrome und Firefox gestartet.

Container beziehungsweise die Anwendungen darin müssen aber nicht zwangsweise über die Weboberfläche des Hub-Servers gestartet werden. Als Option lassen sich die Verknüpfungen zu diesen Containern auch im lokalen Startmenü oder auf dem Desktop bereitstellen. Für den Benutzer erscheinen diese Anwendungen dann wie lokal installierte Applikationen.

Anwendungen gezielt isolieren
Interessanterweise können Sie auf dem Hub-Server auch noch weitere Optionen setzen. Der Container mit dem Chrome-Browser hätte normal gestartet keinen Zugriff auf die lokalen Dateien und würde vollständig isoliert laufen. Für einen Browser ergibt das vielleicht Sinn, für einen Texteditor vielleicht eher nicht. Mit Turbo-Anwendungen können Sie beispielsweise den Zugriff auf lokale Daten verhindern oder nur den Zugriff auf das lokale Benutzerverzeichnis erlauben.

Ein weiteres Szenario, gerade für einen Browser, ist die Einschränkung der Netzwerkkommunikation. So könnten Sie etwa einen älteren Browser zusammen mit unsicheren Plug-ins in einen Container installieren und hier die Netzwerkkommunikation zum Beispiel nur auf eine spezielle Webanwendung beschränken. Benutzer könnten diesen Browser dann lediglich nur für diese Anwendung benutzen, surfen im Web wäre damit ausgeschlossen.

Seite 1: Funktionen und Einrichtung
Seite 2: Administration per Kommandozeile


Seite 1 von 2 Nächste Seite >>


Thomas Krampe/dr

[1] https://turbo.net

Ähnliche Beiträge

Seite 2 - New Work – und jetzt?

Technologien zum Remote-Onboarding
Gerade das Onboarding neuer Kollegen hat sich in Zeiten von New Work und mobilem Arbeiten verändert. Vor allem in den letzten zwei Jahren hat der erste Arbeitstag häufig nicht im Büro, sondern aus dem Remote-Office stattgefunden. Auch dann wird eine einfache Inbetriebnahme der Arbeitsgeräte erwartet – ohne den persönlichen Kontakt mit den IT-Teams.

New Work – und jetzt?

Flexible Arbeitsmodelle sind für viele Unternehmen zum Standard geworden. Das bringt viele Vorteile für die Mitarbeiter – aber auch immer größere Herausforderungen für IT-Administratoren. Denn sie sollen flexibles, sicheres Arbeiten mit hohem Nutzungskomfort ermöglichen, sind dabei aber mit verschiedensten, komplexen Systemumgebungen und einer kritischen Sicherheitslage konfrontiert. Lesen Sie, welche Strategien und Technologien bei der praktischen Umsetzung helfen.

Schatten-IT im Home Office verhindern

Seit Beginn der Pandemie boomt das Home Office. Mehr Flexibilität, ein geringeres Infektionsrisiko und hohe Produktivität sind die Folgen. Doch wie immer gibt es auch eine Kehrseite: Gefahren aufgrund von Schatten-IT. Mitarbeiter nutzen unautorisierte Soft- und Hardware, um ihren Aufgaben nachzugehen und öffnen Hackern damit oft unbewusst Tür und Tor. Der Online-Artikel zeigt die Risiken auf und beleuchtet, was IT-Verantwortliche tun können, um die eigene Infrastruktur wirkungsvoll zu sichern.