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

下图是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私有云容器服务上的实践

（编辑：晋中站长网）

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