oci images and ORAS support

[yunwei37]

如果我在 wasm 外面再包一层 oci 呢?

目前，有两种调配WebAssembly模块的办法– wasm-pack（应用NPM来存储模块）或WAPM（独立于编程语言和工具链，但仍是一个十分晚期的工具，尚未在其内部宽泛采纳）。然而，如果咱们认为WebAssembly是Linux容器的潜在跨平台替代品，那么咱们还须要一种独立于编程语言和工具链的散发形式。为何不齐全应用OCI注册核心散发容器镜像的办法呢？

此外，OCI最近发表了OCI Artifacts我的项目，该我的项目旨在扩大OCI注册管理机构标准并存储其余云原生工件（思考Helm图表或CNAB捆绑软件）。具备间接的长处–一种统一的形式来调配多个工件类型，应用曾经存在的注册表服务或重用和扩大以后的平安模型（例如TUF）。

ORAS（OCI注册表存储）是OCI Artifacts我的项目的拟议施行，可显著简化OCI注册表中任意内容的存储。因而，咱们能够应用ORAS客户端库来构建一个非常简单的工具，以将WebAssembly模块推入和推到OCI注册表中。

[yunwei37]

https://lequ7.com/guan-yu-webassembly-shi-yong-oci-zhu-ce-zhong-xin-fen-fa-webassembly-mo-kuai.html

envoy 的 wasm 插件好像已经有了比较完整的 oras 的实现:

https://www.alibabacloud.com/help/zh/alibaba-cloud-service-mesh/latest/use-oras-to-simplify-wasm-based-asm-instance-extension

https://cloud.tencent.com/developer/article/1801834

[zyy17]

支持使用 OCI Artifacts，因为这样能更好地兼容已有云原生 Artifact 相关的生态：比如类似于 Docker 的 Push/Pull 工作流；Artifact 加载时的签名以及验签流程（安全性）等等。如果我没有记错的话，solo.io 的 wasmhub 也是类似的思路。

我感觉 eunomia-bpf 是一个很有意思的项目 😊（引流自公众号），个人愚见，这个项目最核心的设计应该是将平时 bpf 中的用户态逻辑 wasm 插件化（wasm 的优势在于丰富的用户态生态，而 bpf 的优势在于日渐完善的 Linux 内核生态），并能够与 bpf 程序建立某种安全的通讯机制。这样一来，bpf 程序就能在某种程度从某一个固定的 host 程序上解耦，比如这时候端上只需要保留一个高权限的 agent 程序作为 loader，并集成一个高性能的 wasm runtime，这个 agent 可以加载不同的 bpf artifact 来实现内核的可编程，并有相应的机制将内核中的数据高效地透出到用户态。artifact 的分发和管理个人感觉难度不算太大，毕竟目前有不少很成熟的机制来辅助完成（可能这方面 C 系生态不算太好），而用户态逻辑 wasm 插件化感觉还是挺难的。

个人一点点肤浅的理解，希望能对作者构成一些参考。

[yunwei37]

非常感谢您的关注和提议!

支持使用 OCI Artifacts，因为这样能更好地兼容已有云原生 Artifact 相关的生态：比如类似于 Docker 的 Push/Pull 工作流；Artifact 加载时的签名以及验签流程（安全性）等等。如果我没有记错的话，solo.io 的 wasmhub 也是类似的思路。

是的，我们目前就是这么想的 (＾▽＾)
最近 wasmedge 也有和 docker 合作，以 docker 镜像的方式分发，我们也是受 wasm hub 和他们的影响打算这样做。目前这部分实际上已经基本做好了，还有一点收尾工作:

• https://github.com/eunomia-bpf/eunomia-bpf/tree/master/ecli%2Fecli-rs
• [FEATURE] Use the rust version ecli-rs to replace ecli #119

我感觉 eunomia-bpf 是一个很有意思的项目 😊（引流自公众号），个人愚见，这个项目最核心的设计应该是将平时 bpf 中的用户态逻辑 wasm 插件化（wasm 的优势在于丰富的用户态生态，而 bpf 的优势在于日渐完善的 Linux 内核生态），并能够与 bpf 程序建立某种安全的通讯机制。这样一来，bpf 程序就能在某种程度从某一个固定的 host 程序上解耦，比如这时候端上只需要保留一个高权限的 agent 程序作为 loader，并集成一个高性能的 wasm runtime，这个 agent 可以加载不同的 bpf artifact 来实现内核的可编程，并有相应的机制将内核中的数据高效地透出到用户态。artifact 的分发和管理个人感觉难度不算太大，毕竟目前有不少很成熟的机制来辅助完成（可能这方面 C 系生态不算太好），而用户态逻辑 wasm 插件化感觉还是挺难的。

个人一点点肤浅的理解，希望能对作者构成一些参考。

非常感谢您的总结! 您说的确实很正确，我们也是希望这样做😂其实使用 JSON 动态加载的部分也是类似的思路，不过那样对用户态的限制比较大，可以选择正确的挂载点和配置一点简单的参数，但没法做具体的计算逻辑

[zyy17]

很好的思路👍，我个人业余时间也在尝试类似的项目，只不过不是用 wasm 这种方式，而是会使用更保守的 agent 侧设计 framework 的方式来做一些扩展，且会重度围绕 K8s 生态来设计，不过最终目标也是想统一管理和分发 bpf 程序。不过业余时间有限，目前还只停留在脑子上一些粗糙的设计和之前一些偏 PoC 的验证。很感谢你们项目给我带来一些不一样的想法 💡😊