Why should Docker add the WebAssembly runtime?

Docker started out leading the container runtime and then fell behind Kubernetes in the container orchestration dimension. in order to retain the container runtime dominance, Docker has introduced OCI and supports more WebAssembly runtimes with containerd-wasm-shim.

To address the limitations of Docker in terms of security, stability, performance, and portability, the Kubernetes community has developed other container runtimes with different implementations and features, and has developed the Container Runtime Interface (CRI) specification for them. The current container runtimes that implement this specification are containerd, cri-o, and other container runtimes such as katacontainers and gvisor that do not implement the CRI but can run on Kubernetes by adding a virtualization layer.

The Open Container Initiative (OCI) aims to define industry standards for container image formats and runtimes, and Docker has donated its runtime runc as the first implementation of the standard. Recently, the WASM community has shown interest in the OCI toolchain, and Docker now supports the WebAssembly module as one of its artifacts. Docker Hub now supports common artifacts such as Helm, Volume, and WebAssembly in addition to images.

Use Docker to build images containing WebAssembly modules and save them in Docker Hub. With containerd-wasm-shim, you can make them run in Kubernetes as shown in the following image.

Containerd is a container runtime that conforms to the CRI (Container Runtime Interface) specification, which was open sourced by Docker and contributed to CNCF. Any runtime that supports the CRI specification can be run in Kubernetes.

What are the advantages of running a WebAssembly application in Docker versus a Linux image?

Running a WebAssembly application with Docker has the following advantages over running a Linux image.

Higher performance

WebAssembly applications take less time to start because it does not require booting the entire operating system, which Linux containers do. the cold start time for WebAssembly modules is 100x faster than Docker containers. the memory footprint for WebAssembly modules is smaller because it is a binary format that compresses code and dependencies efficiently, whereas WebAssembly modules are typically under 1MB in size, while Docker images can be 100 or 200 MB in size.

Higher portability

WebAssembly applications are an architecture-neutral format that can run on any underlying architecture as long as the appropriate runtime is available, without the need to consider compatibility issues between different architectures. docker containers require different images to be built for different architectures, which may have some potential security risks or vulnerabilities.

Better security and isolation

WebAssembly applications provide code-level security against malicious code accessing system resources, specifically:

• WebAssembly applications are binary bytecode running in a sandbox environment that does not require access to host system resources and is not affected by the host system. docker containers, while also running in an isolated environment, still need to run on the host system and can be attacked or interfered with by the host system.

• WebAssembly applications interact with the outside world through the WebAssembly System Interface (WASI), a standardized collection of APIs that provide basic system functionality such as file manipulation, network access, environment variables, etc. The WASI can limit the permissions and capabilities of WebAssembly applications to prevent them from doing something dangerous. The Docker container can also set some security options to limit the container’s permissions and capabilities, but it still needs to rely on the features and services provided by the host system.

Because of these advantages, WebAssembly has an advantage over Docker containers in some scenarios, such as edge computing, cloud-native applications, and microservices. Of course, WebAssembly applications have some limitations, such as no support for multithreading, garbage collection, and binary packaging. As a result, not all scenarios are suitable for using WebAssembly applications. You can choose the right technology solution based on your specific needs and preferences.

How do I run a WebAssembly application in Docker?

Running a WebAssembly application in Docker is not much different from a normal Linux image, except that you need to specify the platform and runtime at runtime. The following example from the official Docker documentation runs a WebAssembly application in Docker Desktop as an example:

1

docker run -dp 8080:8080 --name=wasm-example --runtime=io.containerd.wasmedge.v1 --platform=wasi/wasm32 michaelirwin244/wasm-example

where:

• --runtime=io.containerd.wasmedge.v1 Specifies that the WasmEdge runtime is used, replacing the default Linux container runtime.
• --platform=wasi/wasm32 specifies the architecture of the image. By leveraging the Wasm architecture, there is no need to build separate images for different machine architectures. The Wasm runtime is responsible for the final step of converting Wasm binaries to machine instructions.

Docker currently supports four WebAssembly runtimes, as follows:

You can view the WebAssembly application in action by entering the following command in the command line terminal

1

curl http://localhost:8080/

You will see the following output:

1

Hello world from Rust running with Wasm! Send POST data to /echo to have it echoed back to you

You can also send a POST test request to the /echo endpoint:

1

curl localhost:8080/echo -d '{"message":"Hello"}' -H "Content-type: application/json"

You will see the following output:

1

{"message":"hello"}

Summary

This article describes why Docker added support for WebAssembly, and the advantages and methods of running WebAssembly applications in Docker. webAssembly applications have higher performance, portability and security compared to Linux images, and are suitable for edge computing, cloud-native applications and microservices scenarios. Docker supports four WebAssembly runtimes, spin, spiderlightning, WasmEdge, and wasmtime, and in the next article I will describe how to develop a WebAssembly application, so stay tuned.

Ref

• https://jimmysong.io/blog/why-docker-support-wasm/