使用Docker构建、共享和运行WebAssembly应用程序

毫无疑问，WebAssembly（AKA Wasm）正处于开发阶段。虽然对一些人来说这可能只是昙花一现，但我们相信，Wasm在集装箱化的持续发展中发挥着关键作用。Docker和Wasm可以是互补的技术。
在过去，我们探讨了Docker如何成功地在Linux或Windows容器中运行Wasm模块。近五个月后，我们在Docker+Wasm技术预览版上又迈出了一大步。开发人员比以往任何时候都更需要卓越的性能、可移植性和运行时隔离。
Docker工程总监Chris Crone和Second State首席执行官、创始人Michael Yuan在2022年CNCF Wasm Day上解决了这些难题。以下是他们的完整课程，但请随时关注我们的简明分解：

您不需要学习新的流程就可以成功地使用Docker和Wasm进行开发。流行的Docker CLI命令可以为您解决此问题。多亏我们与WasmEdge的合作，Docker甚至可以管理WebAssembly运行时。我们将深入探讨我们为什么要处理这个新项目以及使其成为可能的技术机制。
为什么选择WebAssembly和Docker？
工作负载和代码的隔离方式对我们向用户交付软件的速度有重大影响。Chris强调了这一点，解释了开发人员如何重视：
跨项目轻松重用组件和定义的接口，有助于更快地构建价值
最大化共享计算资源，同时保持工作负载之间的安全、稳固边界-降低应用程序交付成本
通过容器图像等方便的打包机制，在几秒钟内将应用程序无缝交付给用户，让用户更快地看到价值
我们知道，工作负载隔离在这些事情中起着重要作用，但有许多方法可以实现它-如空气间隙、硬件虚拟化、堆栈虚拟化（Wasm或JVM）、容器化等等。由于每种方法都有独特的优点和缺点，因此选择最佳解决方案可能很棘手。
找到合适的工具也非常困难。仅CNCF工具就已经饱和了，尽管我们很庆幸这些工具的存在，但对于许多开发人员来说，种类繁多。
克里斯相信，专业化的工具可以解决手头的任务。我们在Docker也有责任指导这些工具决策。这建立在我们帮助开发人员尽快构建、共享和运行应用程序的持续使命之上。
这就是WasmEdge和Michael Yuan的用武之地。
Docker和WasmEdge带来令人兴奋的机会
Michael展示了容器和WebAssembly用例之间的一些重叠。例如，两个阵营的开发人员可能都希望发布微服务应用程序。Wasm可以实现更快的启动时间和代码级别的安全性，这在许多情况下都是有益的。
然而，由于线程、垃圾收集和二进制打包的限制，WebAssembly并不适合每个用例。目前，使用Wasm运行应用程序还需要额外的工具。
WasmEdge正在运行：TensorFlow接口
Michael随后启动了TensorFlow ML应用程序演示，展示了WasmEdge的功能。此应用程序无法与其他WASI兼容的运行时一起工作：

有几件事使这个演示成为可能：
Rust：一种安全快速的编程语言，对Wasm编译目标具有一流的支持。
Tokio：一个流行的异步运行时，可以处理多个并行HTTP请求，而无需多线程。
WasmEdge的TensorFlow：一个与WASI-NN规范兼容的插件。除了TensorFlow，WasmEdge中还支持PyTorch和OpenVINO。
注意：Tokio和TensorFlow支持是WasmEdge功能，在其他符合WASI的运行时中不可用。
使用Rust的cargo build命令，我们可以使用wasm32wasi目标平台将程序编译成Wasm模块。WasmEdge运行时可以执行生成的.wasm文件。一旦应用程序运行，我们就可以执行HTTP查询来运行一些非常酷的图像识别任务。
这个例子举例说明了WasmEdge作为WASI兼容运行时的绘制。根据其维护人员的说法，“WasmEdge是一个轻量级、高性能和可扩展的WebAssembly运行时，适用于云原生、边缘和去中心化应用程序。它支持无服务器应用程序、嵌入式功能、微服务、智能合约和物联网设备。”
使用Docker访问Wasm
Docker有两个神奇的特性。首先，Docker和容器可以在生产中的任何机器和任何地方工作。其次，Docker使构建、共享和重用任何项目中的组件变得容易。容器图像和其他OCI工件易于使用（和共享）。隔离是烘烤出来的。数以百万计的开发人员也非常熟悉许多Docker工作流，如Docker合成。
克里斯描述了标准化和开放生态系统如何使Docker和容器工具随处可用。OCI规范在这里至关重要，让我们形成新的解决方案，几乎适用于任何人和任何受支持的技术（如Wasm）。
另一方面，设置跨平台的Wasm开发环境很棘手。你还必须学习新的工具和工作流程，这会阻碍工作效率，同时也会产生挫折感。我们相信我们可以帮助开发人员克服这些挑战，我们很高兴能够利用我们自己的平台使Wasm更容易访问。
演示Docker+WasmEdge
Wasm支持在实践中看起来如何？Chris使用Docker Desktop的预览启动了一个演示，并提供了WASI支持。他用三个服务创建了一个Docker Compose文件：
使用NGINX Docker官方图像的前端静态JavaScript客户端
Rust服务器编译为wasi/wasm32
MariaDB数据库

 Rust服务器作为Wasm模块运行，而NGINX和MariaDB服务器在Linux容器中运行。Chris使用一个Dockerfile构建了这个Rust服务器，该Dockerfle从他的本地平台编译为wasm32 wasi目标。他还运行了WasmEdge的专有AOT编译器来优化构建的Wasm模块。然而，此步骤是可选的，优化的模块需要WasmEdge运行时。
现在我们将把细节留给克里斯（演示见19:43）。但是，要知道，您可以运行Compose构建，并获得wasi/wasm32平台映像。运行docker compose启动您的应用程序，然后您可以通过Web浏览器与之交互。这是一种无缝并排运行容器和Wasm的方法。
从Docker CLI中，您将看到Wasm微服务小于2MB。它包含一个高性能HTTP服务器和一个MySQL数据库客户端。NGINX和MariaDB服务器分别为10MB和120MB。或者，在将Rust微服务构建为Linux二进制文件并在Linux容器中运行之后，它将是几十兆字节。这突显了Wasm图像的轻量级。
由于输出是一个OCI映像，您可以使用与OCI兼容的注册表（如Docker Hub）来存储或共享它。您不必学习复杂的新工作流。尽管Chris和Michael专注于WasmEdge，Docker应该支持任何WASI运行时。
该方法可与容器互操作，并在Docker Desktop中得到早期支持。尽管Wasm最初可能看起来很陌生，但与Docker生态系统的集成会立即提升学习曲线。
Docker和Wasm的未来
正如克里斯所提到的，我们致力于让Docker和Wasm一起工作。我们最近的Docker+Wasm技术预览是提高互操作性的重要一步。然而，我们也很高兴能够探索Docker工具如何改善渴望Wasm的开发人员的生活——无论他们的目标是什么。
Docker希望参与Wasm社区，以更好地了解像您这样的开发人员如何构建WebAssembly应用程序。你的用例和障碍很重要。通过与社区分享我们在集装箱生态系统方面的经验，我们希望加快Wasm的发展，并帮助您解决下一个大项目。
开始并了解更多
想试运行Docker和Wasm吗？查看Chris的GitHub页面，获取与Wasm兼容的Docker Desktop构建、演示repo等的链接。在我们继续支持Docker+Wasm的同时，我们也希望听到您的反馈！
最后，不要错过在即将举行的会议上与专家和开发人员一起了解更多关于WebAssembly和微服务的机会。