容器化之路：谁偷走了我的构建时间

OverlayFS可以认为是AUFS的升级版本，容器运行时镜像层的文件是通过硬链接的方式组成一个下层目录，而容器层则是工作在上层目录，上层目录是可读写的，下层目录是只读的，由于大量的采用了硬链接的方式，导致OverlayFS会可能会出现inode耗尽的情况，后续Overlay2对这一问题进行了优化，且性能上得到了很大的提升，不过Overlay2也有和AUFS有同样的弊端——对大文件的操作速度比较慢。

DeviceMapper

DeviceMapper和前两种Storage-driver在实现上存在很大的差异。首先DeviceMapper的每一层保存的是上一层的快照，其次DeviceMapper对数据的操作不再是基于文件的而是基于数据块的。

下图是devicemapper在容器层读取文件的过程：

1. 首先在容器层的快照中找到该文件指向下层文件的指针。
2. 再从下层0xf33位置指针指向的数据块中读取的数据到容器的存储区
3. 最后将数据返回app。

在写入数据时还需要根据数据的大小先申请1~N个64K的容器快照，用于保存拷贝的块数据。

DeviceMapper的块操作看上去很美，实际上存在很多问题，比如频繁操作较小文件时需要不停地从资源池中分配数据库并映射到容器中，这样效率会变得很低，且DeviceMapper每次镜像运行时都需要拷贝所有的镜像层信息到内存中，当启动多个镜像时会占用很大的内存空间。

针对不同的storage-driver我们用上述etcd的dockerfile进行了一组构建测试

注：该数据因dockerfile以及操作系统、文件系统、网络环境的不同测试结果可能会存在较大差异

我们发现在该实验场景下DevivceMapper在时间上明显会逊于AUFS和Overlay2，而AUFS和Overlay2基本相当，当然该数据仅能作为一个参考，实际构建还受到具体的Dockerfile内容以及操作系统、文件系统、网络环境等多方面的影响，那要怎么样才能尽量让构建时间最短提升我们的工作效率呢?

且看下回分解!

【编辑推荐】

1. 盘点：十二“发行版Kubernetes”，引领容器革命！
2. 展望2019：容器云战升级，全栈云大势所趋
3. 部署容器时要考虑的6个关键因素
4. 数据中心容器网络技术
5. 容器赋能AI-人工智能在360私有云容器服务上的实践

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!