This article is translated from Wasm Labs @ VMware OCTO’s blog: WebAssembly: Docker without container, authorized. This is the text version of Wasm Labs’ speech on Docker+WebAssembly at Winter Docker Community All Hands 7 on December 15, 2022.

By Asen Alexandrov, Engineer, Wasm Labs

We in this article refer to the authors or Wasm Labs. Due to the detailed content and length of the article, we will divide it into two parts to share. The first part will focus on conceptual explanations, such as what is Wasm, and what is the relationship between Wasm and Docker. The next article will be more practical, taking PHP as an example to lead you to practice Docker + Wasm.

Recently, Docker announced a partnership with WasmEdge to support WebAssembly.

This article will explain what WebAssembly (Wasm) is, why it is relevant to the Docker ecosystem, and provide some practical examples for you to try. We assume you are already familiar with Docker tools. We’ll use our work on PHP’s WebAssembly port to demonstrate how to build a PHP interpreter, package it as part of an OCI image, and run it with Docker.

Note that this article focuses on hands-on experience rather than discussing technical details.

What is WebAssembly? Why choose it?

This section is a basic introduction to WebAssembly. Friends who are already familiar with Wasm can quickly review it. Tomorrow’s article will introduce more practices.

What is WebAssembly?

WebAssembly is an open standard that defines a binary instruction format that enables the creation of portable binary executables from different source languages. These binaries can be run in various environments. It originated from the Web and is supported by major major browsers.

How does Wasm work in the browser?

Browser engines integrate a Wasm virtual machine, often called the Wasm runtime, that can run Wasm binary instructions. Compiler toolchains such as Emscripten can compile source code into Wasm targets. This allows existing applications to be ported to the browser and communicate directly with the JS code running in the client web application.

These technologies allow traditional desktop applications to run in the browser. Now they can run on any device with a browser. Some notable examples include Google Earth and the Open CV library for computer vision.

How does Wasm work on the server?

In addition to browsers, there are also Wasm runtimes that can run outside of browsers, including traditional operating systems such as Linux, Windows, and macOS. Since they cannot rely on the available JavaScript engine, they use a different interface to communicate with the outside world, such as WASI (WebAssembly System Interface). These runtimes allow Wasm applications to interact with their host system in a manner similar to (but not identical to) POSIX. Projects such as the WASI SDK and wasi-libc help people compile existing POSIX-compliant applications to WebAssembly.

You only need to compile your application once into a Wasm module, and then this same binary can be run anywhere.

What’s so great about Wasm?

The following features make Wasm shine in the browser and also make it advantageous for server-side development:

🌐 Open – it is a widely adopted standard in the industry. In contrast to past browser battles, companies are actively collaborating to standardize on WASI and WebAssembly applications.

🚀 Fast – It can provide native-like speed through JIT/AOT capabilities of most runtimes. Unlike starting a VM or starting a container, there is no cold start.

🔒 Security – By default, the Wasm runtime is sandboxed, allowing safe access to memory. A capabilities-based model ensures that Wasm applications can only access what is explicitly allowed. The software supply chain is more secure.

💼 Portable – Several major Wasm runtimes support most CPUs (x86, ARM, RISC-V) and most operating systems, including Linux, Windows, macOS, Android, ESXi, and even non-Posix operating systems.

🔋 Efficient – Wasm applications can run with the smallest memory footprint and the lowest CPU threshold.

🗣️ Multilingual support – 40+ programming languages ​​can compile to Wasm, with a modern, ever-improving toolchain.

What’s next in the evolution of server platforms?

Maybe you’ve seen Solomon Hykes (one of the creators of Docker)This sentence:

If there was already WASM+WASI in 2008, we would not have needed to create Docker at all. Wasm is just that important. WebAssembly on the server side is the future of computing.

In fact, WASM+WASI does seem to be the next step in the evolution of server-side software infrastructure.

• Early on, we had physical hardware to work with. We will carefully install the operating system and applications for each server in the computer room, and maintain them one by one.
• Then it got easier with the adoption of VMs pioneered by VMware. One can copy, clone and move virtual machines across hardware machines. But this still requires the OS and applications to be installed in the VM.
• Then came containers popularized by Docker, which made it easier to run application configurations in a minimally packaged context without affecting any other applications on the host operating system. However, there is still a need to distribute the application bundled with its runtime and necessary libraries. Security boundaries are provided by the Linux kernel.
• Now with WebAssembly. Its technical characteristics and portability make it possible to distribute applications without ship OS-level dependencies and to run under strict security constraints.

Given all of this, developers often see WebAssembly as the “successor” to containers, and the natural next step for infrastructure deployment.

However, another way of looking at WebAssembly is as another “backend” option for the Docker tooling. The same command-line tools and workflow can be used to replace Linux containers with the equivalent of WebAssembly-based containers. The rest of this article explores this concept, which is what the title calls “Docker without containers”.

How does Wasm work with Docker?

Docker Desktop now includes support for WebAssembly. It is implemented through a containerd shim that can run Wasm applications using a Wasm runtime called WasmEdge. This means that it is now possible to run Wasm applications within the WasmEdge runtime (which emulates a container), rather than a typical Windows or Linux container running a separate process of the binary in the container image.

Therefore, a container image does not need to contain the operating system or runtime context of a running application – a single Wasm binary is sufficient.

This is explained in detail in the Docker’s Wasm Technology Preview article.

What is WasmEdge?

WasmEdge is a high-performance WebAssembly runtime:

• It is open source and belongs to CNCF.
• All major CPU architectures are supported (x86, ARM, RISC-V).
• All major operating systems (Linux, Windows, macOS) as well as others such as seL4 RTOS, Android are supported.
• Optimized for cloud-native and edge applications.
• Scalable and supports standards and emerging technologies
  • AI Inference Using Tensorflow, OpenVINO, PyTorch
  • Tokio’s asynchronous network. Supports microservices, database clients, message queues, and more.
  • Integrate seamlessly with the container ecosystem, Docker and Kubernetes (as shown in this article!)

What about interpreted languages?

So far we’ve only mentioned that compiled languages ​​like C and Rust can compile to WebAssembly. For interpreted languages ​​like Python, Ruby, and PHP, the approach is different: their interpreters are written in C and compile to WebAssembly. The Wasm compiled into this interpreter can then be used to execute source code files, usually ending in .py, .rb, .php, etc. Once compiled to Wasm, any platform with a Wasm runtime will be able to run these interpreted languages, even if the actual interpreter was never compiled natively for that platform.

In the next article, we will introduce how to compile Wasm with the PHP interpreter, package it into an OCI image, and run the OCI image using Docker Desktop with WasmEdge built in. We will also introduce the differences between traditional containers and Wasm containers.

About WasmEdge

WasmEdge is a lightweight, secure, high-performance, scalable, OCI-compatible software container and runtime environment. Currently a CNCF sandbox project. WasmEdge is used in SaaS, cloud native, service mesh, edge computing, edge cloud, microservices, stream data processing and other fields.

GitHub: https://github.com/WasmEdge/WasmEdge

Official website: https://wasmedge.org/

Discord group: https://discord.gg/U4B5sFTkFc

Documentation: https://wasmedge.org/book/en