WebAssembly dans Docker : vers une cohabitation pacifique ?

WebAssembly (Wasm) signera-t-il la fin des conteneurs ? Pas plus que ces derniers n’ont signé la fin des VM, veut-on croire chez Docker.

L’entreprise exprime ce point de vue de longue date. Elle a toutefois accentué, ces derniers mois, sa communication à ce sujet. En toile de fond, l’intégration de WebAssembly dans sa boîte à outils.
Le chantier vient de se concrétiser. On peut en avoir un premier aperçu – instable – dans la preview de Docker Desktop.

L’intégration de Wasm repose sur un shim pour containerd. Et sur une fonctionnalité actuellement expérimentale dans Docker : la gestion des images par containerd. Une fois l’image récupérée, le runtime extrait et charge le module Wasm, puis le réseau est configuré.

Quels avantages pour WebAssembly par rapport aux conteneurs Linux ? Des applications encore plus légères, multiarchitectures*, qui démarrent et se ferment plus rapidement, tout en pouvant fonctionner en sandbox.

Avec ces attributs, WebAssembly visait initialement les navigateurs web. Mais il a fini par susciter de l’intérêt dans le contexte des applications cloud. Wasm étant alors amené à interagir non pas avec un DOM, mais avec des systèmes de fichiers, des variables d’environnement, des horloges système, etc.
En la matière, Docker a choisi son exemple – en vidéo ci-dessous. Et pour cause : il associe conteneurs et Wasm.

L’application (un jeu de rapidité qui consiste à cliquer sur des aliments pour nourrir un animal) repose sur un front-end statique, huit modules WebAssembly, et un magasin clé-valeur Redis conteneurisé avec mécanisme pub/sub. Chaque appui sur un bouton « aliment » lance une instance Wasm qui gère la requête.

En parallèle, Docker rejoint la Bytecode Alliance. Il s’agit de l’organisation référente de l’écosystème WebAssembly. Fastly, Intel, Microsoft et Mozilla en sont les fondateurs.

* Ce que Docker permet aussi avec les commandes docker manifest et docker buildx

Illustration principale © Rawpixel.com – Adobe Stock