WasmEdge CNCF 沙箱项目，为边缘优化的Wasm虚拟机
本文翻译自 Docker blog，作者为 TYLER CHARBONEAU，本文中的我们均指代 Docker。 原文链接： https://www.docker.com/blog/build-share-run-webassembly-apps-docker/
毫无疑问，WebAssembly（Wasm）最近在技术圈风头正劲。尽管在一些人看来这可能是一时热度，但我们相信 Wasm 在持续的容器化开发中发挥着关键作用。 Docker 和 Wasm 可以是互补的技术。
过去，我们探索了 Docker 如何成功运行 Wasm 模块以及 Linux 或 Windows 容器。近五个月后，我们通过 Docker+Wasm 技术预览 又向前迈出了一大步。开发者比以往任何时候都更需要卓越的性能、可移植性和运行时隔离。
Docker 工程总监 Chris Crone 和 Second State CEO、创始人 Michael Yuan 在 CNCF Cloud Native Wasm Day 2022 上解答了这些难题。这是大会演讲的完整视频，但请留意我们之后的详细拆解：
无需学习新流程，开发者即可使用 Docker 和 Wasm 顺利地开发。流行的 Docker CLI 命令可以解决这个问题。有了与 WasmEdge 的合作，Docker 甚至可以管理 WebAssembly 运行时。我们将深入探讨我们处理这个新项目的原因以及使之成为可能的技术机制。
https://github.com/WasmEdge/WasmEdgegithub.com/WasmEdge/WasmEdge
WebAssembly + Docker 为什么结合?
工作负载和代码的隔离方式对我们向用户交付软件的速度有重大影响。 Chris 通过解释开发者的价值来强调这一点：
- 跨项目轻松重复使用组件和定义的接口，有助于更快地创造价值
- 最大化共享计算资源，同时保持工作负载之间安全、牢固的边界——降低应用程序交付成本
- 通过容器镜像等便捷的打包机制，在几秒钟内将应用程序无缝交付给用户，让用户更快地看到价值
我们知道工作负载隔离在这些事情中发挥了作用，但是有很多方法可以实现它——比如隔离网闸（air gapping）、硬件虚拟化、堆栈虚拟化（Wasm 或 JVM）、容器化等等。由于每个都有独特的优点和缺点，因此选择最佳解决方案可能很棘手。
找到合适的工具也非常困难。仅 CNCF 工具全景图中就百花齐放不一而足，虽然我们很感激这些工具的存在，但对于许多开发者来说，种类繁多到让人眼花缭乱。
Chris 相信专用工具可以解决手头的任务。指导这些工具决策也是我们 Docker 的责任。这建立在我们持续的使命之上，即帮助开发者尽快构建、共享和运行他们的应用程序。
这就轮到 WasmEdge 和 Michael Yuan 大展身手啦。
Docker 和 WasmEdge 的机会激动人心
Michael 展示了容器和 WebAssembly 应用场景之间存在一些重叠。例如，两个阵营的开发者可能都想发布微服务应用程序。 Wasm 可以实现更快的启动时间和代码级安全性，这在许多场景下都很有优势。
然而，由于线程、垃圾收集和二进制打包的限制，WebAssembly 并不适合所有应用场景。目前，使用 Wasm 运行应用程序还需要额外的工具。
WasmEdge 实际操作：TensorFlow 接口
Michael 随后进行了一个 TensorFlow 机器学习应用的 demo，来展示 WasmEdge 可以做什么。此应用程序无法与其他兼容 WASI 的运行时一起使用：
下面几点确保了这个 demo 成为可能：
- Rust：一种安全快速的编程语言，对 Wasm 编译目标具有一等公民的支持。
- Tokio：一种流行的异步运行时，无需多线程即可处理多个并行 HTTP 请求。
- WasmEdge 的TensorFlow：与 WASI-NN 规范兼容的插件。除了 Tensorflow，WasmEdge 还支持 PyTorch 和 OpenVINO。
注意： Tokio 和 TensorFlow 支持是 WasmEdge 的特性，其他符合 WASI 的运行时目前还不支持。
使用 Rust 的 cargo build 命令，我们可以使用 wasm32-wasi 目标平台将程序编译成 Wasm 模块。 WasmEdge Runtime 可以执行生成的 .wasm 文件。应用程序运行后，我们可以执行 HTTP 查询来运行一些非常酷的图像识别任务。
此示例展示了 WasmEdge 为兼容 WASI 的运行时。 根据 WasmEdge 维护者的说法，“WasmEdge 是一个轻量级、高性能和可扩展的 WebAssembly 运行时，适用于云原生、边缘和去中心化应用程序。它为 Serverless 应用程序、嵌入式函数、微服务、智能合约和物联网设备提供支持。”
使 Wasm 可通过 Docker 使用
Docker 有两个神奇的特性。首先，Docker 和容器可以在生产环境在任何机器和任何地方上运行。其次，Docker 使构建、共享和重用来自任何项目的组件变得容易。容器镜像和其他 OCI 工件易于使用（和共享）。隔离是默认的。数以百万计的开发者也非常熟悉许多 Docker 工作流程，例如 docker compose up。
Chris 描述了标准化和开放生态系统如何使 Docker 和容器工具随处可用。 OCI 规范在这里至关重要，让我们形成适用于几乎任何人和任何受支持技术（如 Wasm）的新解决方案。
另一方面，设置跨平台 Wasm 开发者环境很棘手。你还必须学习新的工具和工作流程——让人抓狂的同时阻碍生产力。我们深信可以帮助开发者克服这些挑战，我们很高兴能够利用自己的平台让 Wasm 更易于使用。
演示 Docker+WasmEdge
Wasm 支持在实践中的表现如何？ Chris 使用 Docker Desktop 的预览启动了一个演示，并提供了 WASI 支持。他创建了一个包含三个服务的 Docker Compose 文件：
- 使用 NGINX Docker 官方镜像的前端静态 JavaScript 客户端
- 编译为
wasi/wasm32的 Rust 服务器 - MariaDB 数据库
该 Rust 服务器作为 Wasm 模块运行，而 NGINX 和 MariaDB 服务器在 Linux 容器中运行。 Chris 用一个 Dockerfile 构建了此 Rust 服务器，该 Dockerfile 是从他的本地平台编译成为了一个 wasm32-wasi 目标。他还运行 WasmEdge 专有的 AOT 编译器来优化内置的 Wasm 模块。但是，此步骤是可选的，优化的模块需要 WasmEdge Runtime。
这里暂时将细节留给 Chris（见视频 19:43 的演示）。但是，要知道你可以运行 Compose 构建并获得一个 wasi/wasm32 平台的镜像。运行 docker compose up 会启动你的应用程序，然后你可以通过 Web 浏览器与之交互。这是并行运行容器和 Wasm 的一种方式。
在 Docker CLI 中，你会看到 Wasm 微服务小于 2MB。它包含一个高性能 HTTP 服务器和一个 MySQL 数据库客户端。 NGINX 和 MariaDB 服务器分别为 10MB 和 120MB。或者也可以看看，你的 Rust 微服务在构建到 Linux 二进制文件并在 Linux 容器中运行后将达到数十 MB。这大大突出了 Wasm 镜像的轻量级优势。
由于输出是 OCI 镜像，因此你可以使用 Docker Hub 等符合 OCI 的 registry 存储或共享它，不必学习复杂的新工作流程。虽然 Chris 和 Michael 重点展示 WasmEdge ，但 Docker 应该能支持任何 WASI 运行时。
该方法可与容器互操作，并在 Docker Desktop 中得到早期支持。尽管 Wasm 可能最初看起来不熟悉，但与 Docker 生态系统的集成会大大缓和学习曲线。
Docker + Wasm 的未来
正如 Chris 所提到的，我们致力于让 Docker 和 Wasm 能够很好地协同工作。我们最近的 Docker+Wasm 技术预览是朝着提高互操作性迈出的重要一步。然而，我们也很乐意进一步探索 Docker 工具能够如何改善喜欢 Wasm 的开发者的体验——无论他们的目标是什么。
Docker 希望加入 Wasm 社区，从而更好地了解像你这样的开发者如何构建 WebAssembly 应用程序。我们非常重视你的应用场景和面临的挑战。通过与社区分享我们在容器生态系统方面的经验，我们希望加速 Wasm 的发展并帮助你攻克下一个大项目。
开始使用并了解更多信息
想要测试运行 Docker 和 Wasm 吗？查看 Chris 的 GitHub 主页 ，获取与 Wasm 兼容的特殊 Docker Desktop 构建、演示 repo 等。随着我们不断增加对 Docker+Wasm 的支持，我们也非常期待听到你的反馈！