電子發燒友App
作者：Asen Alexandrov，Wasm Labs 工程師
文中的我們均指作者或 Wasm Labs。由于文章內容翔實、篇幅較長我們將分成上下兩篇分享，上篇將注重在概念闡釋，如 Wasm 是什么，Wasm 與 Docker 的關系是什么。下篇文章將更具實踐性，將以 PHP 為例帶領大家實踐 Docker + Wasm。
最近，Docker 宣布與 WasmEdge[3] 合作支持 WebAssembly[4]。
本文將解釋什么是 WebAssembly（Wasm），為什么它與 Docker 生態相關，并提供一些實踐示例供大家嘗試。我們假設你已經熟悉 Docker 工具。我們將使用我們在 PHP 的 WebAssembly 端口[5]上做的工作來演示如何構建 PHP 解釋器，將其打包為 OCI 鏡像的一部分，并使用 Docker 運行它。
請注意，本文專注動手經驗，而不是討論技術細節。
WebAssembly ?是什么？為什么選它？
本節是對 WebAssembly 的基本介紹。已經熟悉 Wasm 的小伙伴，可以快速重溫一下，下篇文章將介紹更多實踐。
什么是 WebAssembly?
WebAssembly 是一種定義二進制指令格式的開放標準，它支持從不同的源語言創建可移植的二進制可執行文件。這些二進制文件可以在各種環境中運行。它起源于 Web，并得到各大主流瀏覽器的支持。
Wasm 如何在瀏覽器中工作？
瀏覽器引擎集成了一個 Wasm 虛擬機，通常稱為 Wasm 運行時，可以運行 Wasm 二進制指令。編譯器工具鏈（如 Emscripten）可以將源代碼編譯為 Wasm 目標。這允許將現有的應用程序移植到瀏覽器，并直接與在客戶端 Web 應用程序中運行的 JS 代碼通信。
這些技術能讓傳統的桌面應用程序在瀏覽器中運行?，F在它們可以在任何裝了瀏覽器的設備上運行。一些著名的例子包括 Google Earth[6] 和用于計算機視覺的 Open CV[7]庫。
Wasm 如何在服務器上運行？
除了瀏覽器，也有可以在瀏覽器之外運行的 Wasm 運行時，包括 Linux、Windows 和 macOS 等傳統操作系統。因為無法依賴可用的 JavaScript 引擎，所以他們使用不同的接口與外界通信，例如 WASI（WebAssembly 系統接口[8]）。這些運行時允許 Wasm 應用程序以與 POSIX 類似（但不完全相同）的方式與其 host 系統交互。WASI SDK 和 wasi-libc 等項目幫助人們將現有的兼容 POSIX 的應用程序編譯為 WebAssembly。
你只需將應用程序編譯成 Wasm 模塊一次，然后這個同樣的二進制文件就可以在任何地方運行。
Wasm 有什么了不起的地方？
下面這些特性讓 Wasm 在瀏覽器大放異彩，也使得它用在服務端開發頗具優勢：
開放——它是業界廣泛采用的標準。與過去的瀏覽器爭奪戰相反，各大公司正積極合作，實現 WASI 和 WebAssembly 應用程序的標準化。
快速——它可以通過大多數運行時的 JIT/AOT 能力提供類似原生的速度。與啟動 VM 或啟動容器不同的是，它沒有冷啟動。
安全——默認情況下，Wasm 運行時是沙箱化的，允許安全訪問內存?；谀芰Φ哪Ｐ痛_保 Wasm 應用程序只能訪問得到明確允許的內容。軟件供應鏈更加安全。
可移植——幾個主要的 Wasm 運行時支持大多數 CPU（x86、ARM、RISC-V）和大多數操作系統，包括 Linux、Windows、macOS、Android、ESXi，甚至非 Posix 操作系統。
高效——最小的內存占用和最低的 CPU 門檻就能運行 Wasm 應用程序。
支持多語言——40 多種編程語言可以編譯成 Wasm，有現代的、不斷改進的工具鏈。
服務器平臺發展的下一步是什么？
也許你已經看過 Solomon Hykes (Docker的創始人之一)這句話[9]：
如果在2008年已經有了 WASM + WASI，我們根本不需要創建 Docker。Wasm 就有這么重要。服務端的 WebAssembly 是計算的未來。
事實上，WASM+WASI 似乎的確是服務端軟件基礎設施發展的下一步。
最早，我們有物理硬件可以使用。我們會給機房里每個服務器精心安裝操作系統和應用程序，并一一維護。
然后隨著 VMware 開創的 VM 的采用，一切變得更容易了。人們可以跨硬件機器復制、克隆和移動虛擬機。但這仍然需要在 VM 中安裝操作系統和應用程序。
隨后出現了由 Docker 推廣的容器，這使得在最小打包的上下文下運行應用程序配置變得更加容易，而不會影響主機操作系統上的任何其他應用程序。但是，仍然需要分發與其運行時和必要的庫捆綁在一起的應用程序。安全邊界由 Linux 內核提供。
現在有了 WebAssembly。它的技術特性和可移植性使得分發應用程序成為可能，無需 ship 操作系統級別的依賴項，并且可以在嚴格的安全約束下運行。
鑒于所有這些，開發者通常將 WebAssembly 視為容器的“繼承者”，以及基礎設施部署的自然而然的下一步。
然而，另一種看待 WebAssembly 的方式是將其作為 Docker 工具的另一個“后端”選擇?？梢允褂孟嗤拿钚泄ぞ吆凸ぷ髁鳎娲?Linux 容器，使用基于 WebAssembly 的容器等同等的東西來實現。本文的其余部分探討了這個概念，這就是標題所說的“沒有容器的 Docker”。
Wasm 如何結合 Docker 運行？
Docker Desktop 現在加入了對 WebAssembly 的支持。它是通過 containerd shim 實現的，該 shim 可以使用名為 WasmEdge[10] ?的 Wasm 運行時來運行 Wasm 應用程序。這意味著，現在可以在 WasmEdge 運行時（模擬容器）中運行 Wasm 應用程序，而不是用典型的 Windows 或 Linux 容器運行容器鏡像中二進制文件的單獨進程。
因此，容器鏡像不需要包含正在運行的應用程序的操作系統或運行時上下文——單個 Wasm 二進制文件就足夠了。
這在 Docker 的 Wasm 技術預覽文章[11]中有詳細解釋。
WasmEdge 是什么?
WasmEdge[12] 是一個高性能的 WebAssembly 運行時：
是開源的，屬于 CNCF[13]。
支持所有主要的 CPU 架構（x86、ARM、RISC-V）。
支持所有主要操作系統（Linux、Windows、macOS）以及其他操作系統，例如 seL4 RTOS、Android。
針對云原生和邊緣應用程序進行了優化。
可擴展并支持標準和新興技術
使用 Tensorflow、OpenVINO、PyTorch 進行人工智能推理
Tokio 的異步網絡。支持微服務、數據庫客戶端、消息隊列等。
與容器生態、Docker 和 Kubernetes 無縫集成（如本文所示?。?/p>
解釋型語言呢？
到目前為止，我們只提到了 C 和 Rust 等編譯語言可以編譯為 WebAssembly。對于 Python、Ruby 和 PHP 等解釋型語言，方法有所不同：它們的解釋器是用 C 語言編寫的，可以編譯為 WebAssembly。然后這個解釋器編譯成的 Wasm 可以用來執行源代碼文件，通常以 .py、.rb、.php 等結尾。一旦編譯為 Wasm，任何帶有 Wasm 運行時的平臺都將能夠運行這些解釋型語言，即使實際的解釋器從未為該平臺原生編譯過。
明天我們將介紹，如何將 PHP 解釋器編譯 Wasm ，并打包成 OCI 鏡像，并使用內置了 WasmEdge 的 Docker Desktop 運行這個 OCI 鏡像，我們也將介紹傳統容器與 Wasm 容器的不同之處。
[1]
Wasm Labs @ VMware OCTO: https://wasmlabs.dev/
[2]
Docker+WebAssembly 的演講: https://youtu.be/yo30oF1Gflo?t=7361
[3]
WasmEdge: https://wasmedge.org/
[4]
WebAssembly: https://docs.docker.com/desktop/wasm/
[5]
WebAssembly 端口: https://wasmlabs.dev/articles/php-wasm32-wasi-port/
[6]
Google Earth: https://earth.google.com/
[7]
Open CV: https://opencv.org/
[8]
WebAssembly 系統接口: https://wasi.dev/
[9]
這句話: https://twitter.com/solomonstre/status/1111004913222324225
[10]
WasmEdge: https://github.com/WasmEdge/Wasmedge
[11]
Wasm 技術預覽文章: https://www.docker.com/blog/docker-wasm-technical-preview/
[12]
WasmEdge: https://github.com/WasmEdge/Wasmedge
[13]
CNCF: https://cncf.io/
編輯：黃飛
?
工商網監
評論