Wasm+Docker Run

在學會怎麼撰寫 Wasm 應用程式與如何做出 Wasm Container Image 之後，我們的下一步就是來看看當 docker run --rm wasm-container-image 的時候，到底發生了什麼事。

傳統的 Container 工作流程

當 docker run --rm -it A 被呼叫之後，會是以下的流程：

docker -> containerd -> containerd-shim -> runc -> 設定 A 的 container

當然，由於過程的每個階段都有對應的標準，你隨時可以把 runc 換成 crun 或者其他不同的 OCI Runtime 都是一樣的流程。

Wasm Container 工作流程

正如我們之前所言，Wasm Container 是來輔助傳統的 Container 的，在這個前提下，會以不破壞流程為主。
然而以上面的派生流程來說，動到哪個環節是影響最小的呢？

1. 換掉 Docker: 直接 fork docker 做出一個 docker-wasm 指令？別傻了，使用者第一個反對。
2. 換掉 Containerd: 必須 fork containerd，所以中間有任何 upstream 的更新，維護 containerd-wasm fork 的人就得跟上，維護者會先累死。
3. 換掉 Containerd-shim: containerd-shim 本來的設計就是 plugin 了，開發者可以做一個 shim 來替換現在 runc 的位置，相比 1&2 是可以接受的方案。
4. 當然 3 已經夠好了，但在我們最最最初的設計其實是 fork crun 並弄了一個與 crun 相容的工具，叫做 crunw = crun+runwasm，我們後續會在其他的工具鏈裡（podman+crun+wasmedge handler）看到，不過在 docker desktop 中，是選擇 3 的解決方案。

根據上面的結論，現在的流程就會變成是以下的樣子：

docker -> containerd -> containerd-shim -> runc -> 設定 A 的 container
                                      |--> runwasi -> 設定不同的 Wasm runtime

至於這個 runwasi 的細節，就讓我們明天再繼續展開吧！