Aufbau eines Unikernels, der WebAssembly ausführt – Teil 1

• Ein Artikel aus der Hackweek 22 von SUSE über das Projekt des Autors, einen Unikernel zu bauen, der WebAssembly ausführt.
• Der Autor wählte dieses Projekt aus mehreren Gründen, unter anderem wegen der potenziellen Vorteile der Kombination von Unikernels und WebAssembly.
• Aus Sicht von Anwendungsentwicklern kann es schwierig sein, Anwendungen auf einen Unikernel zu portieren oder dafür zu schreiben, da die Anwendung und ihre Abhängigkeiten den jeweiligen Ziel-Unikernel unterstützen müssen.
• Auch Unikernel-Betreuer haben Schwierigkeiten sicherzustellen, dass beliebige Anwendungen auf ihrer Plattform reibungslos laufen, weil es unbekannte Systemprimitiven geben kann, die von Benutzeranwendungen genutzt werden.
• Wenn jedoch die WebAssembly-Plattform das Ziel ist, verfügen Anwendungen über einen klar definierten Funktionsumfang, der von der WebAssembly-Laufzeit bereitgestellt werden muss.
• Der Autor nutzte das RustyHermit-Projekt, einen in Rust geschriebenen Unikernel, als Grundlage für die Unikernel-Anwendung.
• Der Autor stieß auch auf Schwierigkeiten im Zusammenhang mit der WebAssembly-Laufzeit, da Wasmtime, seine bevorzugte Laufzeit, nicht auf RustyHermit aufgebaut werden konnte. Schließlich fand und nutzte er wasmi, eine reine Rust-WebAssembly-Laufzeit.
• Der Autor diskutiert außerdem die Nutzung des Vorschlags zum WebAssembly Component Model in Spiderlightning, das es ermöglicht, WebAssembly-Gästen Funktionen bereitzustellen und dem Host zu erlauben, von WebAssembly-Gästen bereitgestellte Funktionen zu verwenden.
• Der Autor musste außerdem wit-bindgen, ein CLI-Tool zur Erzeugung von Host-/Gast-Code aus .wit-Dateien, erweitern, damit es die wasmi-WebAssembly-Laufzeit unterstützt.
• Der Beitrag endet mit einer Aufzeichnung der Unikernel-Anwendung, die die Spiderlightning-http-server-Demo ausführt, und mit dem Versprechen, im nächsten Teil der Reise auf Rust async, Redis und einige Fehler einzugehen.

[GN⁺]

Hacker-News-Kommentare

• Nutzer stellen einen Bezug zum Vortrag "Die Geburt und der Tod von JavaScript" her
• Diskussion darüber, was für Nicht-OS-Hacker der beste Weg zu einem Unikernel ist; vorgeschlagen werden unter anderem das Bauen einer Anwendung als Linux-Kernel-Modul, das Hacken von Linux und Einschleusen von Code oder die Nutzung von Unikernel-Projekten auf GitHub
• Die Idee einer x64-Maschine, die ein an eine Netzwerkkarte gebundenes VM als allgemeine Computing-Ressource ausführt, wird vorgeschlagen und diskutiert
• Begeisterung für WebAssembly (WASM); Nutzer loben dessen Sandboxing und Portabilität, und einige wünschen sich, es wäre in den 90ern anstelle von JavaScript erfunden worden
• Nutzer hoffen auf die langfristige Beständigkeit von WASM, sehen es als Problem an, dass viele alte Programme nicht ausgeführt werden können, und hoffen, dass WASM dies lösen kann
• Fragen zum Potenzial spezialisierter WASM-Hardware, was Interesse an der künftigen Weiterentwicklung der Technologie zeigt
• Neugier der Nutzer auf Anwendungsfälle für Unikernel und WASM, was den Wunsch nach praktischen Anwendungen der Technologie zeigt
• Diskussion über die Idee eines Unikernels, der eine sichere GC-Runtime im Kernel-Space ausführt; dies könnte die Unterstützung für Virtual-Memory-Mapping auf der CPU überflüssig machen und sie dadurch schneller machen
• Ein markierter Kommentar mit dem Text "Molto interessante, complimenti" bedeutet auf Italienisch "Sehr interessant, Glückwunsch"