In Docker History: Four Major Initiatives with Far-Reaching Impact!, I mentioned how Docker started by leading container runtimes, then fell behind Kubernetes in the container orchestration dimension. To maintain its dominance in container runtimes, Docker Company proposed OCI and added support for more WebAssembly runtimes through containerd-wasm-shim.
To address Docker’s limitations in security, stability, performance, and portability, the Kubernetes community developed other container runtimes with different implementations and features, and established the Container Runtime Interface (CRI) specification for them. Currently, container runtimes implementing this specification include containerd and cri-o. There are also other container runtimes like katacontainers and gvisor that don’t implement 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. Docker donated its runtime runc as the first implementation of this standard. Recently, the WASM community has shown interest in the OCI toolchain, and Docker now supports WebAssembly modules as one of its artifacts. Docker Hub now supports common artifacts beyond images, such as Helm, Volume, and WebAssembly.
Using Docker to build images containing WebAssembly modules and save them in Docker Hub. Through containerd-wasm-shim, they can run in Kubernetes, as shown in the diagram below.
Containerd is a container runtime that complies with the CRI (Container Runtime Interface) specification, open-sourced by Docker Company and contributed to CNCF. Any runtime that supports the CRI specification can run in Kubernetes.
For an introduction to the relationships between containerd, CRI, OCI, and other terms mentioned above, see Docker, containerd, CRI, CRI-O, OCI, runc: Confused? This Article Is Enough
What Advantages Does Running WebAssembly Applications in Docker Have Over Linux Images?
Running WebAssembly applications with Docker has the following advantages over running Linux images.
Higher Performance
WebAssembly applications have shorter startup times because they don’t need to start an entire operating system, unlike Linux containers. The cold start time of WebAssembly modules is 100 times faster than Docker containers. WebAssembly modules have smaller memory footprints because they’re in a binary format that can efficiently compress code and dependencies, while Docker containers need to package the entire image. WebAssembly module sizes are generally within 1MB, while Docker images can reach 100 or 200 MB.
Higher Portability
WebAssembly applications are an architecture-neutral format. With the appropriate runtime, they can run on any underlying architecture without considering compatibility issues between different architectures. Docker containers need to build different images for different architectures, which may present potential security risks or vulnerabilities.
Better Security and Isolation
WebAssembly applications can provide code-level security, preventing malicious code from accessing system resources. Specifically:
- WebAssembly applications are binary bytecode running in a sandboxed environment. They don’t need to access host system resources and won’t be affected by the host system. Although Docker containers also run in an isolated environment, they still need to run on the host system and may be attacked or interfered with by the host system.
- WebAssembly applications interact with the outside world through the WebAssembly System Interface (WASI). WASI is a standardized set of APIs that can provide some basic system functions, such as file operations, network access, environment variables, etc. WASI can limit the permissions and capabilities of WebAssembly applications, preventing them from doing dangerous operations. Although Docker containers can also limit container permissions and capabilities by setting some security options, they still need to rely on functions and services provided by the host system.
- WebAssembly applications are an architecture-neutral format. With the appropriate runtime, they can run on any underlying architecture without considering compatibility issues between different architectures. Docker containers need to build different images for different architectures, which may present potential security risks or vulnerabilities.
Because of these advantages, WebAssembly has advantages over Docker containers in some scenarios, such as edge computing, cloud-native applications, and microservices. Of course, WebAssembly applications also have some limitations, such as lack of support for multithreading, garbage collection, and binary packaging. Therefore, not all scenarios are suitable for using WebAssembly applications. You can choose the appropriate technical solution based on your specific needs and preferences.
How to Run WebAssembly Applications in Docker?
Running WebAssembly applications in Docker is not much different from ordinary Linux images, except you need to specify the platform and runtime at runtime. The following example comes from Docker official documentation and runs a WebAssembly application in Docker Desktop:
docker run -dp 8080:8080 --name=wasm-example --runtime=io.containerd.wasmedge.v1 --platform=wasi/wasm32 michaelirwin244/wasm-example
Where:
--runtime=io.containerd.wasmedge.v1specifies using the WasmEdge runtime instead of the default Linux container runtime.--platform=wasi/wasm32specifies the image architecture. By leveraging the Wasm architecture, there’s 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.
Currently, Docker supports four WebAssembly runtimes:
| Runtime Name | API Name | Developer | Foundation Hosted |
|---|---|---|---|
| spin | io.containerd.spin.v1 | Fermyon | None |
| SpiderLightning | io.containerd.slight.v1 | DeisLabs | None |
| WasmEdge | io.containerd.wasmedge.v1 | SecondState | CNCF Sandbox Project |
| Wasmtime | io.containerd.wasmtime.v1 | Mozilla, Fastly, Intel, Red Hat, etc. | Bytecode Alliance Project |
Enter the following command in the terminal to check the running status of the WebAssembly application:
curl http://localhost:8080/
You will see the following output:
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:
curl localhost:8080/echo -d '{"message":"Hello"}' -H "Content-type: application/json"
You will see the following output:
{"message":"hello"}
Summary
This article introduced why Docker is adding 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, making them suitable for scenarios like edge computing, cloud-native applications, and microservices. Docker supports four WebAssembly runtimes: spin, spiderlightning, WasmEdge, and wasmtime. In upcoming articles, I will introduce how to develop a WebAssembly application. Stay tuned.
