Comprendre WAGI, l’interface de passerelle WebAssembly

Microsoft continue de résoudre des problèmes open source intrigants avec son équipe Deis Labs. Vous découvrirez ici des outils Kubernetes cruciaux comme Helm et CNAB, ainsi qu’un ensemble de tâches WebAssembly attrayantes. Avoir un groupe comme Deis est important pour Microsoft. Il permet à Azure d’expérimenter de nouvelles innovations cloud natives sans s’engager à les publier, tout en lui fournissant un point de contact utile avec les organismes de normalisation et les structures open source.

Le travail de Deis avec WebAssembly est particulièrement fascinant. Il est clair que Microsoft s’inquiète des limitations des conteneurs en tant que niveau le plus bas de développement d’applications cloud natives. Des frais généraux substantiels rendent les conteneurs imprudents pour de nombreuses applications périphériques, en particulier lorsque de petits appareils entrent en jeu. Ils sont une préoccupation dans les applications dispersées à plus grande échelle où vous voulez l’isolement des conteneurs mais n’avez pas besoin d’exécuter un système d’exploitation total, en utilisant des modèles sans serveur au-delà des infrastructures sans serveur traditionnelles.

Étendre l’informatique distribuée avec WebAssembly

Nous ne devrions pas être choqués de voir Deis explorer encore plus avec WebAssembly. Cette spécification pour l’exécution binaire hébergée par un navigateur Internet et un moteur JavaScript satisfait un certain nombre d’exigences pour une alternative aux conteneurs. C’est un environnement d’exécution de base pour plusieurs langues, utilisant une bonne isolation et un démarrage rapide. Il n’est pas nécessaire d’exécuter un système d’exploitation complet pour héberger WebAssembly ; tout ce dont vous avez besoin suffit pour exécuter un navigateur et héberger un environnement d’exécution JavaScript.

Avec WebAssembly hébergé par le navigateur, l’interface système WebAssembly (WASI) lui permet de fonctionner de manière autonome, prenant en charge des technologies comme les Krustlets de Deis, qui sont des applications WASI gérées par Kubernetes. WASI est également au cœur de l’une de ses expériences les plus récentes, l’interface d’entrée WebAssembly (WAGI).

WAGI peut apparaître comme un retour à une époque plus ancienne. Après tout, il utilise une grande partie des performances fournies à l’origine par l’interface d’entrée typique (CGI) de HTTP. Familier de tous ceux qui travaillaient dans les premiers jours du Web, CGI a permis aux développeurs d’étendre les fonctionnalités du navigateur Web avec du code enraciné appelé à partir de HTML. C’était le précurseur de PHP et de JavaScript, hébergeant l’interactivité Web précoce et fournissant les outils utilisés pour gérer et exécuter des sites et des services de commerce électronique.

En passant, j’ai investi une grande partie du milieu des années 90 dans la composition de CGI basé sur une application logicielle pour fonctionner parmi les tout premiers FAI axés sur le contenu avant de passer au développement de systèmes de commerce électronique plus complexes. Mon dernier grand projet CGI était un ensemble de scripts Perl qui exécutaient le système de carte Web d’AOL UK. Prévu pour ne durer qu’un jour férié, son code CGI modélisé a fonctionné pendant de nombreuses années et incluait de nombreux événements saisonniers dans sa bibliothèque. J’ai un intérêt personnel particulier à voir le retour du concept !

Présentation de WAGI

Deis a en fait repris l’idée des gestionnaires HTTP de CGI et les a utilisés pour WASI comme méthode de construction d’un serveur application au-dessus de WASI. Cela permet de contourner certaines restrictions architecturales essentielles dans WASI, en particulier son absence de couche réseau et sa nature sous-jacente à thread unique. Ceux-ci rendent difficile l’utilisation de WASI tel qu’il se présente actuellement en tant que plate-forme de microservices.

L’ancienne conception CGI a une réponse, fournissant un moyen de lier des scripts à un serveur et de les remplir comme demandé. Ils peuvent être composés dans n’importe quelle langue, en utilisant des variables d’environnement et des spécifications de questions pour gérer l’état. Le résultat a été un outil polyvalent qui a amené le Web au-delà de son modèle de livraison de matériel fondamental en une plate-forme d’applications à part entière. Vous vous souviendrez probablement des sites Web et des services que nous avons créés dans les années 1990 comme primitifs, mais ils ont devancé ce qui pouvait être fait à l’époque.

WAGI fait de même avec WASI, le poussant à fonctionner comme un plate-forme qui peut compresser dynamiquement le code WASM, offrant une structure pour appeler, compresser et exécuter des modules. Les en-têtes sont remplis au moyen de variables d’environnement, de spécifications d’enquête en tant que choix de ligne de commande pour les modules, avec des charges utiles HTTP remplies via stdin et une sortie provenant de stdout. L’utilisation de ces méthodes simples et bien comprises pour travailler avec WASM rationalise le style et l’avancement de l’interface, fournissant les outils nécessaires pour que WASM fonctionne comme un serveur léger.

Deis a en fait pris certaines décisions qui rendent WAGI différent de CGI , en mettant l’accent sur la sécurité et le contrôle des accès vers et depuis le système hôte. L’intention ici est d’éviter l’exécution de code malveillant, car les modules WAGI sont dispersés sous forme de binaires et peuvent provenir de tiers. Les modules n’obtiennent pas un accès complet au système de fichiers ; sans subventions spécifiques, ils ne peuvent pas établir de connexions réseau sortantes. Ils peuvent simplement accéder aux variables d’environnement passées dans l’environnement WASI, et ils ne sont pas en mesure d’appeler des exécutables supplémentaires.

Configurer un serveur WAGI

La mise en route de WAGI est assez simple. Vous pouvez télécharger un binaire du serveur à partir de sa page de versions GitHub ou créer le vôtre en assemblant WebAssembly à l’aide de Rust. Actuellement, WAGI fonctionne mieux sous Linux, bien que des versions de Windows soient proposées et évaluées par Deis. Comme WAGI est une application Rust, vous avez le choix de l’exécuter à partir des sources plutôt que de construire un binaire.

Une fois développé et installé, vous pouvez commencer à explorer WAGI. C’est un outil en ligne de commande, vous devez donc apprendre ses indicateurs. Une fonctionnalité utile est l’assistance pour un autre projet Deis, Bindle. Il s’agit d’une méthode d’agrégation de tous les objets nécessaires à l’exécution d’une application, en option dans le fichier de configuration de ses modules. Bindle est un outil polyvalent et puissant, mais comme WAGI, il est en cours de développement et vous préférerez peut-être configurer WAGI avec un fichier de configuration plus standard.

Vous devrez configurer le nom d’hôte et le port utilisé , en plus de l’adresse IP utilisée pour écouter les demandes. D’autres aspects de la configuration incluent le site de répertoire utilisé pour mettre en cache les modules WASM binaires et toutes les variables d’environnement typiques : par exemple, les secrets requis pour accéder aux services distants.

La majorité de votre configuration reste dans le fichier modules.toml de WAGI. Cela spécifie les chemins utilisés pour accéder aux modules, qui fournissent aux utilisateurs des URL pour accéder à votre code. Vous fournissez ensuite une référence de système de fichiers local à un module, afin que WAGI puisse le remplir lorsqu’il est appelé. En même temps, le fichier d’installation peut spécifier le point d’entrée d’un module, vous permettant d’appeler une fonction particulière. Cela permet à un module d’inclure de nombreuses fonctionnalités, chacune étant spécifiée dans une fonction distincte. Deis autorise l’expansion ici, car il existe une entrée réservée pour les référentiels, ce qui recommande qu’à l’avenir vous puissiez avoir la possibilité de charger dynamiquement les modules lors de leur mise à niveau vers les référentiels principaux. Il existe déjà une prise en charge de l’utilisation des registres PC OCI pour charger des modules, si vous souhaitez faire de WAGI le point de terminaison d’un pipeline d’intégration et d’expédition constantes (CI/CD).

Les modules peuvent même être configurés pour obtenir des informations spécifiques. accès à des répertoires spécifiques, leur permettant de travailler directement avec les ressources du serveur. Cela peut être utilisé pour donner accès aux ressources utilisées pour créer du matériel, telles que des images. Toutes les variables d’environnement nécessaires sont transmises via la ligne de commande dans le cadre de l’appel WAGI. Les variables d’environnement qui doivent être partagées entre les modules peuvent être conservées dans un fichier de configuration supplémentaire et compressées au moment de l’exécution.

Composer votre tout premier module WAGI

Composer des modules est aussi simple que de configurer eux. Vous n’êtes limité à aucune langue. Tant qu’il s’assemble sur wasm32-wasi, il peut être utilisé avec WAGI. Il y a très peu de complexité et aucun besoin de bibliothèques spécialisées car tout ce qui est géré au moyen d’opérations d’E/S standard. Tout ce que vous avez à faire est de lire stdin et d’imprimer la sortie sur stdout. Si vous gardez à l’esprit comment composer des applications CGI, vous pouvez composer des modules WAGI. La seule vraie contrainte est de s’assurer que vous formatez les sorties afin qu’elles puissent être livrées sous forme d’actions HTTP. Cela indique de fournir un en-tête de type de contenu et une ligne vide avant d’ajouter votre contenu.

Le résultat est une méthode familière et utile pour étendre les serveurs Web, en ajoutant du matériel dynamique si nécessaire et en offrant un moyen pour les gadgets de pointe de livrer matériel formaté. Ce dernier point est peut-être le plus essentiel. WAGI est une méthode légère de fourniture de contenu Web, et le HTML formaté est une méthode efficace pour gérer les sorties d’une manière qui peut être analysée par n’importe quel client. Il est possible d’imaginer un point de terminaison WAGI sur un périphérique périphérique qui fournit des informations formatées en réponse à une requête d’une application de gestion ou d’une application hautement distribuée basée sur WAGI qui utilise le moins de ressources cloud possible, réduisant ainsi les dépenses au minimum.

Il est très important de disposer d’un moyen relativement simple de créer et de diffuser du code sur des appareils périphériques. Tout ce dont le firmware de votre gadget a besoin pour implémenter est un serveur WAGI et un runtime WASI ; Les modules peuvent être compressés sur n’importe quelle connexion IP à partir d’un registre de système informatique Open Container et mis en cache sur votre appareil, mis à niveau au fur et à mesure que de nouvelles versions sont fournies. La prise en charge future des technologies de description de packages telles que Bindle doit simplifier encore plus le processus, avec une description commune des ressources et du contenu pouvant être chargée au démarrage.