Docker 持续集成过程中的性能问题及解决方法
Docker 持续集成过程中的性能问题及解决方法
2016-01-05 16:18:06 来源：oilbeater的博客 
抢沙发
2016-01-05 16:18:06 来源：oilbeater的博客
摘要：本文通过对目前常见的利用docker做持续部署的流程中的时间消耗分析，剖析在使用docker 搭建流水线之后没有直接本地开发测试效率高的原因、在此过程中出现的问题及解决办法。
关键词：
Docker
Docker push
docker registry 在升级到 v2 后加入了很多安全相关检查，使得原来很多在 v1 already exist 的层依然要 push 到 registry,并且由于 v2 中的存储格式变成了 gzip，在镜像压缩过程中占用的时间很有可能比网络传输还要多。我们简单分解一下 docker push 的流程。
buffer to diske 将该层文件系统压缩成本地的一个临时文件
上传文件至 registry
本地计算压缩包 digest，删除临时文件，digest 传给 registry
registry 计算上传压缩包 digest 并进行校验
registry 将压缩包传输至后端存储文件系统
重复 1-5 直至所有层传输完毕
计算镜像的 manifest 并上传至 registry 重复 3-5
此外判断 already exist skip pushing 的条件变严格了，必须是本地计算过digest 且 该 digest 对应的文件属在对应 repo 存在才可以。
换句话说就是如果这个镜像层是 pull 下来的，那么是没有digest的还是要把整个压缩包传输并计算 digest，如果这个镜像你之前并没有比如 ubuntu 的 base image 你的 repo 第一次创建之前没传输过，那么第一次也要你传输一次确认你真的有 ubuntu。
这里面的改进点就是在太多了，先列举 Docker 官方已经做得和正在做的。
1.9.1 后 push 是 streaming 式的，也就是把 1 和 2 合并去掉临时文件，直接一边压缩一边传输。
pull 镜像后 digest 保存，大概是 1.8.3 之后添加的省去了重复计算。
registry 可以直接 mount 别人 repo 中的一层到自己的 repo,只要有pull权限即可，这个工作还在进行中。
但是这只解决了一小部分问题，push 依然会很慢，docker 和 registry 的设计更多的考虑了公有云的环境设置了过多的安全防范为了防止镜像的伪造和越权获取，但是在一个可信的环境内如果 build 和 push 过程都是自己掌控的，那么很多措施都是多余的，我们可以设计一个自己的 smart pusher 挖掘性能的最大潜力：
压缩传输 streaming 化和 docker 1.9.1 实现的类似
越过 registry 直接和存储系统通信，直接拿掉上面 5 的传输时间
如果 digest 在 存储系统中存在则不再重复传输，在 manifest 中写好层次关系就好
将多层的传输并行化，多个层一块传，这样才能充分发挥多核的优势，docker 自带的串行push效率实在是太低了
另外针对 build 结果进行 push 的 smart pusher 可以将流水线发挥到极致，build 每构建出一层就进行传输，将 build 和 push 的时间重叠利用
有了 smart pusher，push 时间的绝大多数都被隐藏到了 build 的时间中，我们把并发和流水线的技术都用上，充分发挥了多核的优势。
Docker pull
docker pull 镜像的速度对服务的启动速度至关重要，好在 registry v2 后可以并行 pull 了，速度有了很大的改善。但是依然有一些小的问题影响了启动的速度：
下载镜像和解压镜像是串行的
串行解压，由于 v2 都是 gzip 要解压，尽管并行下载了还是串行解压，内网的话解压时间比网络传输都要长
和 registry 通信，registry 在 pull 的过程中并不提供下载内容只是提供下载 url 和鉴权，这一部分加长了网络传输而且一些 metadata 还是要去后端存储获取，延时还是有一些的
docker pull 某些情况会卡死，不 docker restart 很难解决，而 restart 又会停止所有服务，严重影响服务稳定性。
为此我们还需要一个独特设计的 smart puller 帮助我们解决最后的问题： 1. streaming downloading and extracting 和在 smarter pusher 做的类似将这两步合为一步 2. 并行解压，也和 smarter pusher 并行压缩类似 3. 越过 registry 直接和后端存储通信 4. redis 缓存 metadata
有了 smart puller 我们自然的将 docker pull 的工作和 docker daemon 解耦了，这样再不会发生 pull 导致的 docker hang,服务稳定性也得到了增强，解绑后其实 docker 只是做一个 runtime 这一部分也可考虑改成 runc 去除掉 daemon 这个单点，不过这个工作量就比较大了。此外 smart puller 也可以帮助我们实现在 smart cache 中的精确 pull 以及 pull cache 的加速，可谓一举多得。
总结
将 push 和 pull 的工作和 daemon 解绑，把 smart cache，smart puller 和 smart pusher 用上后，持续集成如丝般润滑。
原文链接：http://oilbeater.com/docker/2016/01/02/use-docker-performance-issue-and-solution.html
第四十一届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：pingxiaoli
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
