Utiliser des conteneurs OCI pour exécuter des charges de travail WebAssembly

WebAssembly (également appelé Wasm) a gagné en popularité en tant que format d’instruction binaire portable avec un environnement d’exécution intégrable et isolé pour les applications client et serveur. Considérez WebAssembly comme une petite machine virtuelle basée sur une pile, rapide, efficace et très sécurisée, conçue pour exécuter un bytecode portable qui ne se soucie pas du processeur ou du système d’exploitation sur lequel il s’exécute. WebAssembly a été initialement conçu pour que les navigateurs Web soient un conteneur de fonctions léger, rapide, sûr et polyglotte, mais il n’est plus limité au Web.

Sur le Web, WebAssembly utilise les API existantes fournies par les navigateurs. L’interface système WebAssembly (WASI) a été créée pour combler le vide entre WebAssembly et les systèmes exécutés en dehors du navigateur. Cela permet aux systèmes sans navigateur de tirer parti de la portabilité de WebAssembly, faisant de WASI un bon choix pour la portabilité lors de la distribution et de l’isolation lors de l’exécution de la charge de travail.

WebAssembly offre plusieurs avantages. Parce qu’il est indépendant de la plate-forme, un seul binaire peut être compilé et exécuté simultanément sur une variété de systèmes d’exploitation et d’architectures, avec une empreinte disque et un temps de démarrage très faibles. Les fonctionnalités de sécurité utiles incluent la signature de module et les boutons de sécurité contrôlables au niveau de l’exécution plutôt que de dépendre des privilèges de l’utilisateur du système d’exploitation hôte. La mémoire en bac à sable peut toujours être gérée par l’infrastructure d’outils de conteneur existante.

Dans cet article, je vais parcourir un scénario de configuration des runtimes de conteneurs pour exécuter des charges de travail Wasm à partir d’images de conteneurs légers.

Adoption sur infrastructure cloud et bloqueurs

WebAssembly et WASI sont relativement nouveaux, de sorte que les normes d’exécution native des charges de travail Wasm sur les écosystèmes de conteneurs n’ont pas été définies. Cet article ne présente qu’une seule solution, mais il existe d’autres méthodes viables.

Certaines des solutions incluent la commutation des runtimes de conteneur Linux natifs avec des composants compatibles Wasm. Par exemple, Krustlet v1.0.0-alpha1 permet aux utilisateurs d’introduire des nœuds Kubernetes où Krustlet est utilisé en remplacement d’un kubelet standard. La limitation de cette approche est que les utilisateurs doivent choisir entre l’exécution du conteneur Linux et l’exécution Wasm.

Une autre solution consiste à utiliser une image de base avec le runtime Wasm et à appeler manuellement le binaire compilé. Cependant, cette méthode rend les images de conteneur gonflées par l’exécution, ce qui n’est pas nécessairement nécessaire si nous invoquons nativement l’exécution Wasm à un niveau inférieur à celui de l’exécution du conteneur.

Je décrirai comment vous pouvez éviter cela en créant une configuration hybride où les runtimes Open Containers Initiative (OCI) existants peuvent exécuter à la fois des conteneurs Linux natifs et des charges de travail compatibles WASI.

Utilisation de crun dans une configuration hybride de conteneurs Wasm et Linux

Certains des problèmes évoqués ci-dessus peuvent être facilement résolus en permettant à un environnement d’exécution OCI existant d’appeler à la fois des conteneurs Linux et des conteneurs Wasm à un niveau inférieur. Cela évite des problèmes tels que dépendre des images de conteneur pour transporter l’exécution Wasm ou introduire une nouvelle couche dans l’infrastructure qui ne prend en charge que les conteneurs Wasm.

Un environnement d’exécution de conteneur capable de gérer la tâche : crun.

Crun est rapide, a une faible empreinte mémoire et est un environnement d’exécution de conteneur entièrement conforme à l’OCI qui peut être utilisé en remplacement de votre environnement d’exécution de conteneur existant. Crun a été écrit à l’origine pour exécuter des conteneurs Linux, mais il propose également des gestionnaires capables d’exécuter des extensions arbitraires à l’intérieur du bac à sable du conteneur de manière native.

Il s’agit d’une manière informelle de remplacer le runtime existant par crun juste pour montrer que crun est un remplacement complet de votre runtime OCI existant.

$ mv /path/to/exisiting-runtime /path/to/existing-runtime.backup
$ cp /path/to/crun /path/to/existing-runtime

Un tel gestionnaire est crun-wasm-handlerqui délègue des images de conteneur spécialement configurées (un Image compatible Wasm) aux parties des runtimes Wasm existants dans une approche native à l’intérieur du bac à sable crun. De cette façon, les utilisateurs finaux n’ont pas besoin de gérer eux-mêmes les runtimes Wasm.

Crun a une intégration native avec wasmedge, wasmtimeet wasmer pour prendre en charge cette fonctionnalité prête à l’emploi. Il appelle dynamiquement des parties de ces runtimes lorsque crun détecte si l’image configurée contient une charge de travail Wasm/WASI, et il le fait tout en prenant en charge les conteneurs Linux natifs.

Pour plus de détails sur la création de crun avec le support Wasm/WASI, consultez le dépôt crun sur GitHub.

Construire et exécuter des images Wasm à l’aide de Buildah sur Podman et Kubernetes

Les utilisateurs peuvent créer et exécuter des images Wasm indépendantes de la plate-forme sur Podman et Kubernetes utilisant crun comme runtime OCI sous le capot. Voici un tutoriel :

Création d’images compatibles Wasm à l’aide de Buildah

Les images compatibles Wasm/WASI sont spéciales. Ils contiennent une annotation magique qui aide un environnement d’exécution OCI comme crun à classer s’il s’agit d’une image Linux native ou d’une image avec une charge de travail Wasm/WASI. Ensuite, il peut invoquer des gestionnaires si nécessaire.

La création de ces images compatibles Wasm est extrêmement facile avec n’importe quel outil de création d’image de conteneur, mais pour cet article, je vais démontrer l’utilisation de Buildah.

1. Compilez votre .wasm module.

2. Préparez un Containerfile avec votre .wasm module.

FROM scratch
COPY hello.wasm /
CMD ["/hello.wasm"]

3. Construire une image Wasm en utilisant Buildah avec annotation module.wasm.image/variant=compat

$ buildah build --annotation "module.wasm.image/variant=compat" -t mywasm-image

Une fois l’image construite et le moteur de conteneur configuré pour utiliser crun, crun fera automatiquement le nécessaire et exécutera la charge de travail fournie par le gestionnaire Wasm configuré.

Exécuter une charge de travail WASM avec Podman

Crun est le runtime OCI par défaut pour Podman. Podman contient des boutons et des poignées pour utiliser la plupart des fonctionnalités de crun, y compris le gestionnaire de crun Wasm. Une fois qu’une image compatible Wasm est construite, elle peut être utilisée par Podman comme n’importe quelle autre image de conteneur :

$ podman run mywasm-image:latest

Podman exécute l’image de compatibilité Wasm demandée mywasm-image:latest en utilisant le gestionnaire Wasm de crun et renvoie une sortie confirmant que notre charge de travail a été exécutée.

$ hello world from the webassembly module !!!!

Implémentations d’interface d’exécution de conteneur (CRI) prises en charge et testées par Kubernetes

Voici comment configurer deux environnements d’exécution de conteneur courants :

CRI-O

• Configurez CRI-O pour utiliser crun au lieu de runc en modifiant la configuration à /etc/crio/crio.conf. La documentation de Red Hat OpenShift contient plus de détails sur configuration du CRI-O.
• Redémarrez CRI-O avec sudo systemctl restart crio.
• CRI-O propage automatiquement les annotations de pod à la spécification de conteneur.

Conteneur

• Containerd prend en charge la commutation de l’exécution du conteneur via une configuration personnalisée définie à /etc/containerd/config.toml.
• Configurez containerd pour utiliser crun en vous assurant que le binaire d’exécution pointe vers crun. Plus de détails sont disponibles dans le documentation en conteneur.
• Configurez containerd pour autoriser les annotations Wasm afin qu’elles puissent être propagées à la spécification OCI en définissant pod_annotations dans la configuration : pod_annotations = ["module.wasm.image/variant.*"].
• Redémarrez le conteneur avec sudo systemctl start containerd.
• Maintenant, containerd devrait propager les annotations de pod Wasm aux conteneurs.

Voici un exemple de spécification de pod Kubernetes qui fonctionne à la fois avec CRI-O et containerd :

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-wasm-workload
  namespace: mynamespace
  annotations:
    module.wasm.image/variant: compat
spec:
  containers:
  - name: wasm-container
    image: myrepo/mywasmimage:latest

Problèmes connus et solutions de contournement

L’infrastructure Kubernetes complexe contient des pods et, dans de nombreux cas, des pods avec side-cars. Cela signifie que l’intégration Wasm de crun n’est pas utile lorsqu’un déploiement contient des side-cars et que les conteneurs side-car ne contiennent pas de point d’entrée Wasm, comme les configurations d’infrastructure avec un maillage de services comme Linkerd, Gloo et Istio ou un proxy comme Envoy.

Vous pouvez résoudre ce problème en ajoutant deux annotations intelligentes pour les gestionnaires Wasm : compat-smart et wasm-smart. Ces annotations servent de commutateur intelligent qui bascule uniquement l’exécution Wasm si cela est nécessaire pour un conteneur. Par conséquent, lors de l’exécution de déploiements avec des side-cars, seuls les conteneurs contenant des charges de travail Wasm valides sont exécutés par les gestionnaires Wasm. Les conteneurs réguliers sont traités comme d’habitude et délégués à l’environnement d’exécution du conteneur Linux natif.

Ainsi, lors de la création d’images pour un tel cas d’utilisation, utilisez l’annotation module.wasm.image/variant=compat-smart à la place de module.wasm.image/variant=compat.

Vous pouvez trouver d’autres problèmes connus dans documentation crun sur GitHub.