WebAssembly：無需容器的 Docker （上）

語言: CN / TW / HK

時間 2022-12-28 14:01:31 WasmEdge

主題: php linux github mac os x webassembly risc-v vmware android opencv javascript

本文翻譯自 Wasm Labs @ VMware OCTO 的 blog： WebAssembly: Docker without container，已獲得授權這是 Wasm Labs 在 2022 年 12 月 15 日在冬季Docker Community All Hands 7 的關於 Docker+WebAssembly 的演講的文字版。

作者：Asen Alexandrov，Wasm Labs 工程師

文中的我們均指作者或 Wasm Labs。由於文章內容翔實、篇幅較長我們將分成上下兩篇分享，上篇將注重在概念闡釋，如 Wasm 是什麼，Wasm 與 Docker 的關係是什麼。下篇文章將更具實踐性，將以 PHP 為例帶領大家實踐 Docker + Wasm。

最近，Docker 宣佈與 WasmEdge 合作支援 WebAssembly。

本文將解釋什麼是 WebAssembly（Wasm），為什麼它與 Docker 生態相關，並提供一些實踐示例供大家嘗試。我們假設你已經熟悉 Docker 工具。我們將使用我們在 PHP 的 WebAssembly 埠上做的工作來演示如何構建 PHP 直譯器，將其打包為 OCI 映象的一部分，並使用 Docker 執行它。

請注意，本文專注動手經驗，而不是討論技術細節。

WebAssembly 是什麼？為什麼選它？

本節是對 WebAssembly 的基本介紹。已經熟悉 Wasm 的小夥伴，可以快速重溫一下，明天的文章將介紹更多實踐。

什麼是 WebAssembly?

WebAssembly 是一種定義二進位制指令格式的開放標準，它支援從不同的源語言建立可移植的二進位制可執行檔案。這些二進位制檔案可以在各種環境中執行。它起源於 Web，並得到各大主流瀏覽器的支援。

Wasm 如何在瀏覽器中工作？

瀏覽器引擎集成了一個 Wasm 虛擬機器，通常稱為 Wasm 執行時，可以執行 Wasm 二進位制指令。編譯器工具鏈（如 Emscripten）可以將原始碼編譯為 Wasm 目標。這允許將現有的應用程式移植到瀏覽器，並直接與在客戶端 Web 應用程式中執行的 JS 程式碼通訊。

這些技術能讓傳統的桌面應用程式在瀏覽器中執行。現在它們可以在任何裝了瀏覽器的裝置上執行。一些著名的例子包括 Google Earth 和用於計算機視覺的 Open CV庫。

Wasm 如何在伺服器上執行？

除了瀏覽器，也有可以在瀏覽器之外執行的 Wasm 執行時，包括 Linux、Windows 和 macOS 等傳統作業系統。因為無法依賴可用的 JavaScript 引擎，所以他們使用不同的介面與外界通訊，例如 WASI（WebAssembly 系統介面）。這些執行時允許 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的創始人之一)這句話：

如果在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 的 Wasm 執行時來執行 Wasm 應用程式。這意味著，現在可以在 WasmEdge 執行時（模擬容器）中執行 Wasm 應用程式，而不是用典型的 Windows 或 Linux 容器執行容器映象中二進位制檔案的單獨程序。

因此，容器映象不需要包含正在執行的應用程式的作業系統或執行時上下文——單個 Wasm 二進位制檔案就足夠了。

這在 Docker 的 Wasm 技術預覽文章中有詳細解釋。

WasmEdge 是什麼?

WasmEdge 是一個高效能的 WebAssembly 執行時：

是開源的，屬於 CNCF。
支援所有主要的 CPU 架構（x86、ARM、RISC-V）。
支援所有主要作業系統（Linux、Windows、macOS）以及其他作業系統，例如 seL4 RTOS、Android。
針對雲原生和邊緣應用程式進行了優化。
可擴充套件並支援標準和新興技術
- 使用 Tensorflow、OpenVINO、PyTorch 進行人工智慧推理
- Tokio 的非同步網路。支援微服務、資料庫客戶端、訊息佇列等。
- 與容器生態、Docker 和 Kubernetes 無縫整合（如本文所示！）

解釋型語言呢？

到目前為止，我們只提到了 C 和 Rust 等編譯語言可以編譯為 WebAssembly。對於 Python、Ruby 和 PHP 等解釋型語言，方法有所不同：它們的直譯器是用 C 語言編寫的，可以編譯為 WebAssembly。然後這個直譯器編譯成的 Wasm 可以用來執行原始碼檔案，通常以 .py、.rb、.php 等結尾。一旦編譯為 Wasm，任何帶有 Wasm 執行時的平臺都將能夠執行這些解釋型語言，即使實際的直譯器從未為該平臺原生編譯過。