HN Explorer

Show HN: Run WASM in Containerd (github.com)

77 points by cpuguy83 ↗ HN
I've been working with a partner team to integrate wasm workloads with existing container toolchains with the goal of enabling wasm workloads anywhere, be it on the edge, in kubernetes, or wherever.

To that end, this project implements a containerd shim which runs those wasm workloads. It is designed as a library to bring your own host implementation, but also includes an implementation for WASI. Right now the library assumes you are using wasmtime, which is embedded in.

It works either standalone (run with containerd directly) or in kubernetes. Kubernetes networking and storage are wired into the wasm host and the wasm can run side by side with native workloads on the same machine. Wasm pods can be exposed as a service like any other pod.

11 comments

[ 2.8 ms ] story [ 35.1 ms ] thread
metadat
What could this be used for in reality? It sounds cool but I don't get it.

I'm certainly excited about the Rust aspect.

Tangentially relevant shameless plug:

https://news.ycombinator.com/item?id=31242735

algorithmmonkey
One of the things we are using it for is for running wasm workloads with cluster networking on K8s. A shim like this makes it simple to construct a small OCI image since all that needs to be included is the wasm module, rather than needing the wasm module and the runtime (500k vs 20MB). Basically, you can define a service and a deployment much the same way as a normal container image and it just works.
mikewarot
It's not obvious to me how you make capabilities available to the code running inside the WASM virtual environment.

The core security advantage of WASM is the fact that no file capabilities are provided to the workload by default.

cpuguy83
It gets setup fairly similarly to how you would run a "normal" runc container. containerd passes along a path to the rootfs of the container (for wasi I'd expect to be just the wasm module) which is built from the OCI image along with a set of mounts the be mounted to the rootfs. The project here goes ahead and performs those mounts to the rootfs path and then maps that rootfs path into wasmtime's WASI config as "/".

If you have something like a Kubernetes volume, config map, secret, etc. this is all prepared by Kubelet and winds up as mounts we need to perform as mentioned above.

voigt
> Included in the repository is a PoC for running a plain wasi host (ie. no extra host functions except to support wasi system calls).

Looks like that’s not decided yet.

In theory you could use pod.spec.volumes to hand it over to the shim for the wasi preopens.[1]

Whether that’s a good idea is the other side of the story…

[1] https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

voigt
Great work! Nice to see some progress in this direction.

The WasmEdge team also tamed their crun OCI runtime to run containers as well as wasm modules. [1]

So running wasm along with your pods is not exactly new.

Though it yet needs to be proven what’s the better approach: a shim on CRI level or integration in OCI level…

[1] https://wasmedge.org/book/en/kubernetes.html

cpuguy83
The main advantage to doing it at the shim level is I can run multiple wasm containers from a single wasm runtime more easily.

I did look at implementing this at the OCI layer (also really cool that crun does this!) but decided to go another way.

sitkack
WasmEdge is unfortunate in that it is >20kloc of C/C++, obviating many of the security properties of Wasm itself. Many folks would have liked to see something like safe Rust. Of course there will always be issues with codegen, but at least that has had research around the application of formal methods.

Is there a WasmEdge replacement shim using Wasmtime?

rad_gruchalski
Hah. Looks great. This is fourth or fifth Rust WASM entry making the main page in the last 2 days. Is it time to rename Rust to Wust?
laerus
or WASM to RASM.

Jokes aside, it's mainly cause Rust has first class support for wasm. Soon the rest will catch up.