Dragonfly Nydus——下一代容器格式的一种实现

2021-10-07 05:40:17

最近在学习造核弹，刚好碰到 Dragonfly 群里，来自蚂蚁金服的巴德大佬在直播分享另外一个子项目Nydus。

按照我的理解，Nydus是下一代容器格式的一种实现。其存在主要是为了解决旧的容器格式（container format）存在的问题。

那么问题来了，什么是 Nydus？什么是 container format？ Nydus 具体解决了什么问题。这里先来一波名词扫盲。

名词扫盲

实际上，容器技术从1979年发展至今已经超过40年，docker 只能说是目前为止，其中一种比较著名而流行的实现。可以说，docker 解决了应用分发的难题，为日后 kubernetes 的流行奠定了基础。

但是，俗话说得好，勇士战胜恶龙之日，自身亦化作恶龙。不管是 Docker 公司后来各种神操作（把项目改名 Moby ，docker swarm 的弱鸡编排）也好，CoreOS 的崛起也罢，开源世界的战争，是一种技术标准的全球话语权争夺，这种争夺远比你想象的要残酷。

OCI

OCI全称 Open Container Initiative ，隶属于Linux基金会，是Docker, CoreOS联合其他容器厂商，于 2015-6-22 建立的一个开源组织。其目的主要是为了制定容器技术的通用技术标准。

OCI旗下主要有2个项目：

OCIv1

OCIv1) 就是目前的容器格式。

OCIv2

OCIv2 就是为了解决 OCIv1 的历史技术债务。

Dragonfly Nydus

2020年4 月 10 日，由云原生计算基金会（CNCF）技术监督委员会投票决议，来自中国的开源项目 Dragonfly 正式晋升为 CNCF 孵化级别的托管项目，成为继 Harbor、TiKV 之后，第三个进入 CNCF 孵化阶段的中国项目。

Dragonfly 的架构主要是为了解决了大规模镜像下载、远距离传输、带宽成本控制、安全传输这四大难题。

Nydus 是OCIv2的一种实现，计划捐给 Dragonfly ，作为其旗下一个子项目运作。

当前容器格式的问题

在直播分享中，巴德大佬提到了OCIv1的几个问题:

分层效率很低
数据没有校验
可重建性问题

分层效率很低

分层效率低主要是指冗余性。如果把 docker image 比喻作汉堡包，镜像A是吉士汉堡包。

FROM centos

镜像B是双层吉士汉堡包。

FROM centos
RUN yum update -y

# 拉取吉士汉堡包
docker pull h1
# 拉取双层吉士汉堡包
docker pull h2

那么按照目前的设计，镜像之间是独立的，也就是说，拉取h1之后，虽然磁盘里面已经缓存了 centos 的底层镜像，但是拉取h2的时候，还是重新拉取整个镜像，并没有复用 centos 那个底层镜像。最终导致了磁盘的冗余和网络流量的浪费。

数据没有校验(Verifiability)

这里稍加引述巴德大佬的话：

只读层被修改了，容器应用是不知道的。现在的OCI镜像格式下就有可能发生这种事情，镜像在构建和传输过程中是可校验的，但是镜像下载到本地后会被解压，解压后的文件的修改是无法探知的。

镜像需要下载，解压到本地文件系统，然后再交给容器去使用。这个流程中，解压到本地文件系统这一步是丢失可信的关键。

workspace 可重建性问题(repairability)

可重建性可以从某种程度上解决 docker build 慢的问题。

以轻量级 kubernetes event导出组件 kube-eventer为例，

FROM golang:1.14 AS build-env
ADD . /src/github.com/AliyunContainerService/kube-eventer
ENV GOPATH /:/src/github.com/AliyunContainerService/kube-eventer/vendor
ENV GO111MODULE on
WORKDIR /src/github.com/AliyunContainerService/kube-eventer
RUN apt-get update -y && apt-get install gcc ca-certificates
RUN make


FROM alpine:3.10

COPY --from=build-env /src/github.com/AliyunContainerService/kube-eventer/kube-eventer /
COPY --from=build-env /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

ENV TZ "Asia/Shanghai"
RUN apk add --no-cache tzdata
COPY deploy/entrypoint.sh /

ENTRYPOINT ["/kube-eventer"]

我们在机器A上反复执行docker build，每次的构建都是原子的，也就是说，每一次都是从上到下重新跑一遍。但实际上我们知道，很多指令都是重复的，没有必要重复执行。

可重建性还有另外一层意思，从机器A拷贝到机器B之后，继续构建docker image。

我的吐槽

在我看来，目前的 OCIv1 借鉴了 git 的设计，但本质是一个很难吃的汉堡包。只有最上面一层可以吃（读写）。

云原生应用的交付周期，一般是

git Ops --> CI --> docker image --> waiting container/pod（docker pull，sandbox etc） --> running container/pod --> terminated container/pod

云原生应用的安全性由运行时环境和 docker container 组成，一个安全的 docker container ，应当尽量让它在各个环节里面，都没有可乘之机。

比如，从代码到CI的过程中，应当有静态代码分析 + 人工 code review 的机制，确保代码无安全性上的问题；从CI到 docker image 的构建过程中，应当让CI运行在一个可信的环境。这个可信的环境包括了可信的权威DNS，可控的安全防火墙，受限的网络连接以及安全扫描套件（杀毒软件）。

从这个层面上讲，Nydus 计算每一层哈希，不仅不是很专业，而且很慢。这一块内容交给更高效的安全引擎，Nydus 做个异步事件回调/消息发布订阅，也许更好。

综上所述，结合短桶原理，可以得出这样的结论：容器的安全性需要各方协调，云原生应用不存在绝对意义上的安全。

最后，欢迎大家加入Dragonfly项目，项目钉群群主是《Docker源码分析》的作者孙宏亮。在国内《21天学会XX》垃圾技术书风行的大背景下，这本书是一股清流。

同时也欢迎大家参与OCIv2标准的共建。

结论

PPT first，bug secondly.

~~我想暗中买一批孙宏亮大佬写的第一版《Docker源码分析》，之后再潜入阿里云，要到他的亲笔签名，最后再转卖出去????~~

参考链接

[1]
docker、oci、runc以及kubernetes梳理
https://xuxinkun.github.io/2017/12/12/docker-oci-runc-and-kubernetes/

[2]
About the Open Container Initiative
https://opencontainers.org/about/overview/

[3]
The Road to OCIv2 Images: What's Wrong with Tar?
https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar

[4]
重磅 | Dragonfly 晋升成为 CNCF 孵化项目
https://developer.aliyun.com/article/754452

码农公寓