Comment by haspok | Hacker News Reader

Comment by haspok | Hacker News Reader

So it's kind of like GraalVM with cgroups?

How about Kubernetes, in other words, how does this scale (I understand the single process proposition, but can't see how it replaces multiple containers, which might be deployed on multiple VMs / hardware)? In other words, what is the WASM runtime running on? In the article they show a WASI layer, but that does not replace a VM / container (AFAIK), so you still need an OS to run on. I'm a bit puzzled.

EDIT: let me rephrase my question. In a docker container you can have your libraries and dependencies independent of the host system (eg. in your container you need libc 1.0, whereas your host system has libc 2.0). This is possible because the docker container does actually contain a copy of libc 1.0 if you set it up so. But in the case of WebAssembly this is no longer the case (this is what makes it possible to have smaller images).

But then you need not only the kernel from the host, but everything else around it. Unless your code does not depend or anything, or you compile ALL your dependencies to webassembly, which sounds interesting - I'm not saying it is not possible, but is this how it should work?

WebAssembly is a binary format executed in a virtual machine. By default, the execution is isolated from the host OS, so that there is no concept of syscall to the OS directly from your WebAssembly module. The WASM module calls to certain exports (the WASI layer) whose endpoints are implemented by the runtime. However, the runtime in this case has the ability to decide whether and how this call that would correspond to a syscall directly had it been run on the OS directly will be mapped to the OS in reality. You might want to map that to a syscall on a real OS, or the Wasmtime runtime could be running in an embedded environment where there is no OS as we might otherwise assume.

WebAssembly also allows for powerful constructs like the component model, where components written in even different languages can interact between them.

Can you address the question about needing to compile all dependencies….

Sure, after you name an example of a programming language where neither you nor someone else has to compile the dependencies for a given program.

Yea, unsure how this replaces compose or how it would work in pods. Is there some kind of runtime planned to replace container.io so that you still get all the k8s orchestration (live/readiness, anti affininity, cgroups limits etc).

The way this works is it uses a containerd shim. In containerd-land, shims are responsible for all the platform dependent setup/management of a container.

The "normal" shim on Linux is the runc shim (io.containerd.runc.v2). On Windows the shim is called runhcs (io.containerd.runhcs.v1).

The docker solution mentioned in the article modifies the "wasmtime" shim from https://github.com/containerd/runwasi so that it uses "wasmedge" instead. It also happens to be using an unreleased version of dockerd.

So how does this work with compose? Currently you need to specify the runtime for the container, there should be an option in the compose yaml for this.

How does it work with pods? You need to configure containerd's cri config with a runtime handler that specifies the wasmedge shim. Then you add a RuntimeClass to k8s and add that to your pod spec.

Reply on news.ycombinator.com