Letztes Jahr habe ich mal die Idee vorgestellt, dass man WebAssembly als eine Technologie wahrnehmen kann, welche durch den Einsatz eines OS-fernen Maschinencodes und die Bereitstellung einer quasi allgegenwärtigen Runtime die Möglichkeit schafft, Containerisierung auf einem hohen Abstraktionslevel anzubieten. Selbstverständlich war ursprünglich gedacht, WebAssembly im Browser laufen zu lassen, um so den Web-Standard weiter auszubauen. Die Idee war, dass nicht die ganze Client-seitige Logik zwingend in einer JavaScript-Engine wie der V8 ausgeführt werden muss, sondern eine weitere, WebAssembly-fähige Runtime zur Verfügung steht, worin Applikationscode in einer galvanisch isolierten Sandbox läuft.
Das ist natürlich eine interessante Entwicklung, in der heutigen Zeit. Dieser Weg wurde schon von anderen Pionieren eingeschlagen. Nicht zuletzt die Entwicklung der Java Virtual Machine, bekannter unter deren Akronym JVM, war der Versuch, programmatischen Code in einen OS-fernen Maschinencode zu übersetzen und dieses Substrat, den Bytecode, in einer gekapselten, isolierten Runtime ausführen zu lassen. Trotz des massiven Erfolgs von Java als Sprache über Jahrzehnte hinweg, hat die JVM es dennoch nicht geschafft, einen Standard für eine Sandbox zu festigen, in der Code frei nach Lust und Laune interpretiert werden kann. Dem Gedanken der Verwendung einer lupenreinen Sandbox kam aber spätestens Docker auf die Schliche und hat es geschafft, dem Sandboxing neuen Schwung zu verleihen. Heute bekommt man in der Tech-Welt das Wort Containerisierung kaum aus jedermanns Munde.
Jetzt ein wenig vorweg gegriffen; wenn man diesen Containerisierungs-Gedanken weiterspinnt, so kann man sich gut eine Zukunft ausmalen, in der sich der Fokus von der Containerisierung mit Docker eher in Richtung WebAssembly bewegen könnte.
Die Idee, alles ausserhalb der eigentlichen Applikationslogik zu abstrahieren, sodass der Entwickler seinen gesamten Fokus auf die Entwicklung, treu dem Developer-Experience-Aspekt, legen kann, ist ja nicht neu. Es gibt mit Serverless-Plattformen bereits den Ansatz FaaS so auszubauen, dass der Entwickler so wenig wie möglich mit der Infrastruktur und dem CI/CD-Prozess in Berührung kommt. Nennenswert an dieser Stelle ist sicher Serverless, Serverless-Stack, oder auch Architect. Das Innovative an der Umsetzung einer Serverless-Architektur mit WebAssembly-Runtimes ist die Tatsache, dass die Logikbausteine mit einem transparenten Standard kompiliert und in einer standardisierten Sandbox zum Laufen gebracht werden. Wenn auch die Firecracker-MicroVM von AWS sicherlich eine robuste und effiziente Grundlage für AWS Lamdba oder AWS Fargate bietet (es ist nämlich in Rust geschrieben), so ermöglicht ein WebAssembly-Modul dessen Ausführung auch auf unterschiedlichsten Umgebungen, sprich, die Portabilität eines WebAssembly-Moduls lässt es zu, die Workload auch auf Geräten an der Edge (oder sonstwo) auszuspielen.
Bevor wir mit der eigentlichen Einführung in die Kunst von WebAssembly in der Cloud mithilfe von wasmCloud einsteigen, wäre es sicherlich angebracht, ein gewisses Vorwissen in verschiedenen Technologien mitzubringen. Glücklicherweise kannst du mit etwas Zeit alle relevanten Technologien in unseren TechUp’s nachlesen. Da wären folgende TechUp’s, die an das heutige Thema anknüpfen:
- Einstieg WebAssembly
- Containerisierung mit WebAssembly
- Einstieg in Rust
- Workload-Orchestrierung mit HashiCorp Nomad
- Einstieg und Verständnis über Elixir und OTP
Cloud-to-Edge WebAssembly-fähige Host-Runtime mit wasmCloud
Wenn wir uns richtig erinnern, beschrieb ich im Containerless mit WebAssembly Runtimes-TechUp, wie eine WebAssembly-Runtime wie Wasmer genutzt werden kann, mit der WebAssembly-Module auf allen möglichen Rechnereinheiten ausgeführt werden können.
Liam Randall und Stuart Harris haben im November 2021 ein aufschlussreiches Interview gegeben, worin die zwei Founder von Cosmonic prägnant wasmCloud zusammenfassen und auch einen Ausblick in die Zukunft geben. Dort kontextualisieren sie wasmCloud als nächste Abstraktionsstufe in einem jahrzehntelangen Trend weg von der Maschine hin zur Applikationsdomäne (in der Referenz unten “Business-Logik” genannt).
Wasmcloud is a higher level abstraction for the cloud that uses WebAssembly to run everywhere securely. Virtual machines abstract away from specific hardware, containers abstract away from a Linux environment, and wasmCloud abstracts away from the specific capabilities you use to build an application. wasmCloud continues the trend of increasing abstractions for building and deploying software in the cloud. Kubernetes lets an organization run their containers in any cloud environment, and wasmCloud lets a developer run their business logic on any capabilities, in any cloud or edge environment.
— Liam Randall und Stuart Harris, Quelle: jaxenter.com (04/04/2022)
Falls man schon mit Applikations-Containerisierung und -Sandboxing in Berührung gekommen ist weiss man, dass die Containerisierungslandschaft sehr breit aufgestellt ist und mittlerweile der Containerisierungsgedanke nicht mehr mit Docker gleichzusetzen ist. Auf den Punkt gebracht abstrahiert eine klassische Container-Runtime wie containerd oder cri-o den Betriebssystem-Kernel. Aus diesem Grund nennt man dies auch OS-Level Virtualisierung, welche im Gegensatz zur Hardware-Virtualisierung wie XEN oder VMWare vSphere nicht ein ganzes Betriebssystem auf das Host-Betriebssystem stülpt, sondern nur den User-Space (welcher über dem Kernel-Land liegt) abstrahiert.
Ähnlich wie die Java Virtual Machine, stellt eine WASM-Runtime eine Laufzeitumgebung bereit, welche nur den Applikationscode ausführt und über die Virtual Machine/Runtime andere Komponenten des Betriebssystems anspricht, falls notwendig. Somit ist alles in einer isolierten Sandbox gekapselt. Es geht bei der Virtualisierung immer darum, eine Domäne in einem im Voraus klar abgegrenzten Sandkasten zu isolieren. Es gibt mittlerweile zwar auch den Trend zurück zur OS-nahen Containerisierung wie das Firecracker, Kata oder auch gVisor (diese kann man grob unter den Micro-VMs zusammenfassen) machen.
WasmCloud geht hier noch einen Schritt weiter als eine JVM, indem auch die ganzen Anbindungen an die Laufzeitumgebung mittels sogenannter Capability Provider abstrahiert werden sollen. Somit werden I/O-Bedürfnisse in standardisierte Schnittstellen einmalig programmiert und über das WASM-Modul, sofern ausgerollt und lauffähig, angesprochen. Dies vermindert die Side-Effects eines gegeben WASM-Modul und macht dieses auch noch einfacher testbar.
WasmCloud ist in erster Linie eine Host-Runtime
Vielleicht ist Host-Runtime schon ein zu spezifischer Begriff. Man kann wasmCloud griffiger als eine Distributed Application Framework für Microservices verstehen.
WasmCloud kommt mit einem gewissen Tech-Stack daher und verbaut gewisse “Best-of-Breeds” (jeweils das beste Tool), um seine angestrebte Zielsetzung in ein technisch funktionales und stabiles Produkt zu packen. Im vorhin genannten Interview werden auch die Vorteile der verbauten Technologien umschrieben.
The entire wasmCloud team and project is built with best-of-breed open source projects, including Nats, Elixir/OTP and the Smithy project from AWS. Nats, from Synadia, has emerged as the internet’s dialtone – and in wasmCloud we use this to seamlessly connect wasmCloud hosts at the application layer. Elixir/OTP has over the last 20 years become the default way to scale to millions of processes and we adopted it on our backend in order to offer that incredible approach to our community. And while Smithy is a new project, it has been used successfully within AWS to model and design hundreds of APIs.
— Liam Randall und Stuart Harris, Quelle: jaxenter.com (04/04/2022)
Die Best-of-Breed Software-Technologien, die wasmCloud nutzt sind unter anderem folgende Produkte:
- WASM und eine eigene WASM-Runtime als Container und Container-Runtime.
- Elixir/OTP als eine Art WASM-Modul-Orchestrierungsmechanismus. Die OTP-basierte Orchestrierung ist als eine Host-Runtime zu verstehen und bildet das Herzstück des wasmCloud-Projekts. Es gab in der ursprünglichen Fassung eine eigens geschriebene, Rust-basierte Host-Umgebung, welche aber durch OTP gänzlich abgelöst wurde.
- NATS als API und Service Mesh zwischen den einzelnen Applikationsdomänen. WasmCloud nutzt hier eine eigens konzipierte Lattice, um eine flache Topologie des Service Meshs zu erreichen.
- Smithy als deklarative API für die WASM-basierten Services.
WasmCloud verwendet eine spezifischen Nomenklatur, mit der alle Teilkomponenten in einem wasmCloud-Host-basierten Cluster bezeichnet werden. Diese Teilkomponenten unterliegen somit einer gewissen Definition, welche wir hier kurz uns zu Gemüte führen:
- Host-Runtime: Das, was auf den OTP-Nodes ausgerollt wird. Ursprünglich in Rust, jetzt in Erlang/OTP.
- Capability Provider: Domainübergreifende Funktionalitäten, die ein gegebener Actor aufrufen kann.
- Interfaces: Die Funktionalitäten und Operationen, die ein Capability Provider unterstützt, werden in einem Interface definiert. Dafür wird Smithy verwendet.
- Actor: Instanz eines WebAssembly-Moduls, welches die Business-Logik beinhaltet. Actors werden über eine Replikation horizontal skaliert. WasmCloud-Actors sind zeitgleich auch OTP-Actors, da OTP die Instanziierung des WebAssembly-Moduls als Prozess wahrnimmt und somit selber schon entsprechend “scheduled”.
- Application: Eine Vielzahl von Actors bilden in der Summe eine Anwendung. Siehe https://github.com/wasmcloud/examples/tree/main/petclinic.
Die Gesamtarchitektur einer klassischen Cluster-Instanziierung könnte wie hier unten abgebildet aussehen. Da der OTP-Host auf mehreren Maschinen erst richtig in die Gänge kommt und erst mit verteilter Architektur als highly-available bezeichnet werden kann, gibt es offizielle HashiCorpNomad-Playbooks, mit denen man schnell und unkompliziert die wasmCloud-OTP-Hosts ausrollen kann.
Neben den eigentlichen Business-Logik-Einheiten, den Actors, gibt es noch sogenannte Capability Providers, welche Applikationsübergreifende Grundfunktionalitäten bereitstellen. Um eine Idee zu bekommen, was ein solcher Capability Provider typischerweise als Applikationsübergreifende Funktionalität übernehmen könnte, habe ich hier eine kleine Auflistung aller offiziell gewarteten Providern zusammengestellt:
- httpserver: HTTP web server built with Rust and warp/hyper.
- httpclient: HTTP client built in Rust.
- redis: Redis-backed key-value implementation.
- nats: NATS-based message broker.
- lattice-controller: Lattice Controller interface.
- postgres: Postgres-based SQL database capability provider.
- numbergen (built-in): Number generator, including random numbers and GUID strings.
- logging (built-in): Basic level categorized text logging capability.
So, soviel zur Theorie. Jetzt springen wir in den praktischen Teil und schauen uns einen wasmCloud-Cluster an und wie man ein solchen auf deinem lokalen Rechner zum laufen bringt. 🤠
Hands-On mit einer lokalen Host-Runtime
Das anstehende Hands-On entspricht bis auf einige Kleinigkeiten der gleichen Zielsetzung, nämlich dem Aufbau einer wasmCloud-basierten Host-Umgebung, und hat denselben Ablauf, wie es der offizielle Getting Started-Guide vorsieht.
Da sich wasmCloud noch in einer sehr frühen, man kann schon von einer Prä-Alpha-Phase sprechen, Entwicklungsphase befindet, kann es gut sein, dass zum Zeitpunkt von deinem Aufruf des Getting Started-Guides sich dessen Inhalt und Beschreibung bereits geändert oder zumindest leicht angepasst hat. Aus diesem Grund liefere ich hier alle nötigen Manifeste, Kommandos und Snippets mit, sodass man den Guide auch noch in seiner ursprünglichen Fassung durchmachen kann. Die verwendeten Docker-Images sind versioniert und somit ist das Szenario auch später noch 1:1 nachstellbar.
Wie bereits kurz erwähnt ist die Ausgangslage die, dass wir zusammen eine Host-Umgebung auf deiner lokalen Maschine aufsetzen, worauf wir im Anschluss eine kleine Funktion (einen wasmCloud Actor) ausrollen und aufrufen werden.
Vorbereitungen
Für das Aufsetzen der Host-Umgebung nutzen wir jetzt kein Nomad, um unsere Zielmaschinen zu bedienen, da wir sowieso nur eine Maschine, nämlich deinen lokalen Rechner, zur Verfügung haben. Aus diesem Grund nutzen wir containerisierte Docker-Images für die Teilkomponenten. Dazu kommt noch die wasmCloud-hauseigene wash, die wasmCloud-Shell.
Wie immer ist es bei solchen technischen Schritt-für-Schritt-Guides von Vorteil, gewisse UNIX- und Shell-Grundlagen mitzubringen. Es macht das Verständnis der einzelnen Schritten viel einfacher, obwohl in diesem Hands-On wenig “Magie” zum Einsatz kommen sollte. Zusammengefasst sind folgende 3 Punkte als Vorbereitung wahrzunehmen:
- Docker
- Wash
- UNIX- und Shell-Kenntnisse
Die Installation von wash ist auf GNU/Linux und Mac OS sehr einfach. Für Mac OS kann man wie gewohnt per brew tap die Third-Party-Repository von wasmCloud wasmcloud/wasmcloud dem Package Manager brew hinzufügen. Danach installieren wir wash mit brew install.
|
|
Wenn man GNU/Linux, eine BSD-Variante oder Windows nutzt, kann man sich einfach über die Rust-Umgebung und dessen Package-Manager Cargo per cargo install die CLI installieren lassen.
|
|
Bevor wir loslegen; Lass mich noch ein kurzes Wort zu WASM, Container Registry und OCI verlieren. OCI ist ein Container-Standard und ein Akronym für die Open Container Initiave. Dieser Container-Standard garantiert, dass wir auch nicht LXC-fähige Images containerisieren und auf einer Container-Registry ablegen können. Somit ermöglicht OCI die Containerisierung von WASM-Modulen.
Um fertige WASM-Module als Image zu verpacken und anschliessend auf einer Container Registry der Wahl hochzuladen, gibt es eine Software-Lösung namens wasm-to-oci, welche genau diesen Standard umsetzt.
Die WASM-Images, die von wasmCloud bereitgestellt werden und hier im Hands-On zur Verwendung kommen sind auf der Azure Container Registry gehosted. So, jetzt sind wir aber ready für unser Setup. 😁
Setup mit Docker Swarm
Der Plan sieht aus wie folgt. Es gibt nur einen Node, nämlich den lokalen Rechner. Darauf werden wir mit docker compose drei Docker-Images instanziieren, welche als Teilkomponente der Gesamtplattform nötig sind.
Das wären dann folgende drei Komponenten:
- Redis als KeyValue-Store
- NATS als asynchrone Streaming-API
- Und nicht zuletzt der OTP-basierte wasmCloud-Host
Für dieses Hands-On werden wir keine eigene Actors oder Capacity Provider schreiben, sondern ziehen uns WASM-Images von der Azure Container Registry, auf denen die Crew hinter wasmCloud bereits Beispielsmodule hinterlegt hat. Der wasmCloud-Host stellt uns noch ein Phoenix-basiertes Dashboard bereit, auf den wir den Host abgebildet bekommen. Zudem haben wir, genau wie bei Kubernetes, mit kubectl oder bei OpenShift mit oc und mit wash die Möglichkeit, den Zustand auch per CLI abzufragen und zu provisionieren.
First things first, lass uns gleich reinspringen und diesen gewünschten Zielzustand in die Tat umzusetzen. Im Anschluss siehst du eine (relativ einfache) docker-compose.yml-Datei wie man sie zu genüge kennt.
Darin finden wir unsere 3 Teilkomponenten als services eingetragen.
nats:2.3redis:6.2wasmcloud:latest
|
|
So weit, so gut. Jetzt starten wir per docker compose up den Cluster.
|
|
Man kann den obigen Docker Swarm auch mit einem -d als Daemon, als Hintergrundprozess, laufen lassen. Falls man dann doch die Logs anschauen möchte, kann man ganz einfach mit docker logs -f plus Service-Namen die gewünschten Logs ausgeben lassen.
|
|
Sobald die 3 Sercives Running sind kann man als ersten Test und auch als ersten Einstiegspunkt das wasmCloud-Dashboard unter localhost:4000 direkt im Browser aufrufen.
Wie man sieht ist das Dashboard noch sehr rudimentär und bietet nur wenig Klickfläche für sinnvolle Interaktion. Aber ja, das sei wegen des frühen Projektstatus verziehen.
Wichtig bei der Bedienung der CLI ist die sogenannte Host-ID . Diese müssen wir zur Hand haben, um Ressourcen des Zielhosts anzuzeigen oder zu verändern. Diese Host-ID findet man glücklicherweise einfach heraus:
|
|
In unserem Fall ist es der Wert NAJKNTL43I5EQ7JU22HJ7EVPTCXF3CDMGG7UPSE7D7IJEMS26QUWOMKX, dieser wird aber bei dir sicher ein anderer sein. Kopier diesen Mal in dein Clipboard. Beim Aufruf vom Status unseres Inventory per wash ctl get inventory geben mir den Host-ID-Wert als letzter Parameter mit. Und siehe da. Das Host Inventory scheint da zu sein. wasmCloud erkennt meinen Mac OS als linux (siehe Zeile mit hostcore.os), und es gibt (noch) keine Actors oder Providers.
|
|
Den fehlenden Actors und Providers möchten wir natürlich Abhilfe verschaffen, da genau damit überhaupt für uns interessante Business-Logik auf unsere neue Plattform eingeschleust wird.
Diese Actor-, oder auch die Capability Provider-Ressource kann man wahlweise per Web-UI oder per CLI mit wash managen. Wir tun dies mal versuchsweise mit der Web-Oberfläche. Den ganz mutigen gebe ich noch wash-Befehle mit auf den Weg. 🤓
So, lass uns man eine neue Actor-Ressource erstellen. Es gibt auf der wasmCloud-eigenen GitHub-Repository eine Vielzahl von Beispiel-Actors unter /examples/actors. Da wären zum Beispiel ein Todo-Actor oder ein Keyvalue-counter-Actor, aber wird werden mit einem simplen Echo-Actor starten. Jetzt müssen aber zum Glück nicht die Repo auschecken und das Rust-Projekt mit WASM als Target kompilieren lassen, sondern können ein vorgefertiges WASM-Image aus der Azure Container Registry refernzieren. Die Referenz dazu ist wasmcloud.azurecr.io/echo:0.3.4 . Trage diesen Wert im “Start Actor from OCI Registry”-Fenster unter OCI reference ein.
Aha. Da ist was passiert! Im Dashboard sieht man jetzt den Actor mit dem Namen “Echo”. Wir können die Anzahl der Instanzen hier genau wie bei Kubernetes oder anderen Container-Orchestrierungslösungen, auch Replicas genannt, verändern. Sehr schön. Das sollte den Kubernetes-affinen schon sehr bekannt vorkommen…
Damit ist es aber noch nicht getan. Obwohl auf einem produktiven wasmCloud-Host nicht oft Capability Provider angelegt werden müssen, so müssen wir das hier initial doch trotzdem mal tun. Genau wie beim Actor vorhin, geben wir eine Referenz zu unserem Wunsch-Provider an. Diese Referenz, die wir hier nutzen wasmcloud.azurecr.io/httpserver:0.14.10 stellt uns einen Provider hin, welcher die HTTP-Server-Funktionalität mit sich bringt. “Link Name” einfach default belassen.
Jetzt kann unser wasmCloud-Host HTTP-Server-Funktionalität ausführen. Jetzt müssen wir unserem Echo-Actor noch sagen, dass es einen solchen Funktionalitätsdienstleister gibt. Diese Durchsage nennt sich eine Link Definition und ist im Dashboard genau wie der Actor oder der Capability Provider erstellbar. Die Felder sollen so aussehen:
- Actor:
Echo (#ID) - Provider:
HTTP Server (#ID) - Link Name:
default - Contract ID:
wasmcloud:httpserver - Value:
address=0.0.0.0:8080
Falls man nicht sicher ist, hier noch ein Screenshot des “Define Link Definition”-Fensters.
Das finale Dashboard sollte so aussehen. Es gibt einen Actor “Echo”, es gibt einen Provider “HTTP Server” und eine Link Definition “default”, welche den Actor mit dem Provider verknüpft.
Wenn alles richtig konfiguriert ist, kann man jetzt einen HTTP-Request an unseren Cluster absetzen. Der Kontextpfad hierbei ist /echo. Wir machen das einfach mal im Terminal mit curl. Die Response siehst du hier unten:
|
|
Herzlichen Glückwunsch! 🎉
Du bist in der Zukunft angekommen. Zumindest eine mögliche Zukunftszeitschiene, in der WebAssembly-Module den klassischen Container in der Container-Orchestrierung ersetzt haben.
Aussichten
Das ganze ist wirklich noch sehr Early Alpha. Wir bleiben also gespannt, wie sich wasmCloud weiterentwickelt! Es gibt aber bereits eine Plattform, welche auf wasmCloud aufbaut. Diese heisst vino.
Weiterführende Links und Ressourcen
CNCF Welcomes WebAssembly-Based wasmCloud as a Sandbox Project | The New Stack
Brian Sletten (2021) WebAssembly: The Definitive Guide – Safe, Fast, and Portable Code | O’Reilly