WASM能否取代Docker?

云计算、微服务计算、无服务器计算、可扩展计算、可负担计算等等,这一切主要靠一项杰出的技术——Linux容器(LXC)来实现。

云计算、微服务计算、无服务器计算、可扩展计算、可负担计算等等,这一切主要靠一项杰出的技术——Linux容器(LXC)来实现。

Linux容器(LXC)提供了操作系统级的虚拟化沙箱。简而言之,容器允许在一台主机上运行多个隔离的Linux系统。利用Linux内核的某些特征,将共享资源(内存、CPU、文件系统)划分为称为“命名空间”的隔离级别。容器直接在物理硬件上运行,没有仿真,并且资源消耗低(除了设置命名空间的一点初始化之外)。目前使用Linux容器最流行的工具是Docker。Linux容器与虚拟机不同,在虚拟机中,虚拟机管理软件(VirtualBox、VMware ESXi等)模拟物理硬件,虚拟机在该模拟环境中运行。

WASM能否取代Docker?

LXC一直是云计算开发的关键,但是一个新的玩家(我之前在本周刊谈到过)已经进入这个游戏。是的,我指的就是WebAssembly(WASM)。我想我已经多次复制粘贴过WASM的定义,但为了清楚起见,我觉得值得再次阐述一下:“WebAssembly是一种新的二进制格式的开放标准。从设计上看,它是内存安全的、可移植的,并以接近原生的性能运行。其他语言的代码可以交叉编译成WebAssembly。目前,对Rust、C/C++和AssemblyScript(一种为WebAssembly构建的新语言,针对TypeScript的子集进行编译)提供了一流的支持。许多其他编译器已经在开发中。”

众所周知,WASM最初是为浏览器设计的,它是一种在浏览器中取代Javascript来进行计算密集型应用的方式,但是想象一下,有一种交叉编译的二进制格式,其可以提供一种快速、可扩展且安全的方式在所有机器上运行相同的代码,这个想法是相当吸引人的。这就是WASI(WebAssembly系统接口)诞生的原因(可参见2019年的公告)。WASI是一项新的标准,它将WebAssembly的执行扩展到操作系统。它引入了新的抽象层次,使WASM二进制文件可以“编译一次,就能在任何地方运行”,而与底层平台无关。这就是去年让我对WASM感到兴奋的原因,也是引发我在本周刊中发表这篇文章的原因。

开端

然而,前几天我在开发一个小型的Rust微服务,在部署的那一刻,我开始怀疑:“等一下,在这里用WASM也许会很方便”。具体来说,我正在开发的是一个简单的服务器,该服务器可以监听一组webhooks,并根据所触发的webhook及其具体内容触发数据库和其他服务中的动作。它是一个无状态的微服务,我希望它尽可能的轻量级(因此,选用了Rust)。当我在对服务进行Docker化时,我意识到:“为什么不能将我的Rust微服务编译成WASM,并像无服务器功能一样在我的基础架构上按原样运行它?”就在那时,我开始研究WASM在无服务器环境中的使用。显然,很多人之前已经尝试过使用AWS Lambdas和Azure Functions,但我讨厌供应商锁定。我已经使用Kubernetes来管理我的部署(因此,对微服务进行Docker化),为什么我不能在没有附加虚拟化的情况下运行原始WASM二进制文件,就像在Kubernetes上运行Docker容器一样。这将允许LXC和WASM负载共存于我的Kubernetes集群中,使我能够在Kubernetes上部署轻量级WASM(由于WASM二进制文件小,唤醒速度快)功能和应用,并在我的基础架构中融合容器化和无服务器的方法。

在云中使用WASM不仅意味着频繁睡眠和唤醒的轻量级进程的快速启动时间、接近原生代码的性能以及更轻量的二进制文件(这也是其开发的一些初衷),而且还意味着通过设计具有一种沙箱式运行环境。WASM安全模型具有两个重要目标:“(1)、保护用户免受错误或恶意模块的影响;(2)、在(1)的约束下,为开发者提供开发安全应用的有用原语和缓解措施。”这是云安全工程师多年来一直试图在Docker中实现的目标。

Docker与WASM的比较

深入研究后,我发现并不是只有我一个人看到了WASM在云计算中的潜力,就连Docker的创始人所罗门·海克斯(Solomon Hykes)也已经意识到WASM和WASI的结合对云环境的影响:

WASM能否取代Docker?

(tweet)“如果在2008年已经有了 WASM + WASI,我们根本不需要创建 Docker。WASM 就是这么重要。服务器端的 Webassembly 是计算的未来。标准化的系统接口是缺失的环节。让我们希望WASI能够胜任这项任务!”

我强烈推荐大家关注上述推特的回复,可以找到亮点,比如:

WASM能否取代Docker?

(tweet)“那么WASM会取代Docker吗?不会,但是可以想象一下未来Docker并排运行linux容器、windows容器和WASM容器的情景。随着时间的推移,WASM可能会成为最流行的容器类型。Docker会对它们一视同仁,能够全部运行。”

然后我看到了Microsoft的这篇博文和Krustelet的公告,对我的答复的进一步回答。

“重要的是,WASM在很高的层面上具备两个主要特征,Kubernetes生态系统或许能够利用它的优势:

  • 与容器相比,WASM及其运行时可以快速执行并且体积非常小
  • WASM在默认情况下不能做任何事情;只有在明确的权限下才能执行。

上述两个特征恰好是我们需要的,这暗示了我们或许可以在受限且对安全性要求很高的环境中(在这些环境中,对于容器而言比较困难)有利地结合使用WASM与Kubernetes。”

仅通过LXC,容器的执行还是会受限于底层的体系结构,比如,你试过在Windows在运行Docker嘛?我懂你的困难。但是通过WASM我们有了一个全新的通路,使得我们可以在任何体系上运行虚拟的WASM环境,甚至在虚拟化或容器技术都不支持的架构上(其实浏览器就是这种体系)。我不知道你如何看待这个问题,但是随着我越来越深入的阅读和学习WASM,我就愈发对这个技术感到兴奋。当然我可能也有自己的偏见,无所谓啦。

咱们下周再继续聊!

本文来自腾讯云计算社区,转载请注明出处:https://computeinit.com/archives/3393

发表评论

登录后才能评论
交流群