Docker学习思考

Docker与CI持续集成/CD

• Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
• 持续集成(Continuous integration)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
• 持续部署（continuous deployment）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。

常见的利用Docker进行持续集成的流程如下：

• 开发者提交代码
• 触发镜像构建
• 构建镜像上传至私有仓库
• 镜像下载至执行机器
• 镜像运行
  

在上述的五步中，1和5的耗时较短，整个持续集成主要耗时集中在中间的3个步骤，也就是docker build、docker push、docekr pull这样还是无法达到顺滑的极致要求，下来我们来分析下build、push、pull的耗时和解决方法：

docker build

---

• 网络优化
  dockerhub的官方镜像在国外，由于众所周知的原因，在国内进行构建时网络会是很大的瓶颈，甚至某些公司的环境是无Internet连接的。
  在这种情况下，建议使用国内的镜像源，或者自己搭建私有仓库，保存项目需要的基础镜像，把构建过程中的网络传输都控制在国内或者内网，这样就不用再考虑网络方面的问题。
• 使用 .dockerignore文件
  dockerignore文件的设计是为了在docker build的过程中排除不需要用到的文件以及目录，目的是为了docker build这个过程可以尽可能地快速高效以及构建出来的image没有多余的“垃圾”。
• 最小化镜像层数（layers）
  把镜像层数减到最少，能加快容器的启动速度，但是这里也要权衡另一个问题：dockerfile的可读性。你可以把一个dockerfile写得很复杂以达到构建出最小层数的镜像，但同时你的dockerfile可读性也降低了。所以我们要在镜像层数和dockerfile可读性之间做出妥协。

docker push

---

docker registry升级到v2后加入了很多安全相关检查，在v2中的镜像的存储格式变成了gzip ，镜像在压缩过程中占用的时间也比较多。我们简单分解一下docker push的流程。

1. buffer to disk，将该层文件系统压缩成本地的一个临时文件
2. 上传文件至registry
3. 本地计算压缩包digest，删除临时文件，digest传给registry
4. registry计算上传压缩包digest并进行校验
5. registry将压缩包传输至后端存储文件系统
6. 重复1-5直至所有层传输完毕
7. 计算镜像的manifest并上传至registry,重复 3-5

这样的设计导致push会很慢，如果采用官方的dockerhub，需要考虑docker build一节中提及的网络方面影响，dockerhub公有镜像库还需考虑安全方面的因素。

同时docker和registry设置了过多的安全防范措施（如双向证书认证等），主要是为了防止在公有云的环境下镜像的伪造和越权获取。但是在一个可信的环境内，如果build和push过程都是自己掌控，很多措施都是多余的。

docker pull

---

docker pull 镜像的速度对服务启动速度至关重要，好在registry v2后可以并行pull了，速度有了很大改善。但是依然有一些小的问题影响了启动的速度：

• 下载镜像和解压镜像是串行的
• 串行解压，由于v2都是gzip要解压，尽管并行下载了还是串行解压，内网的话解压时间比网络传输都要长；
• 和registry通信， registry在pull的过程中并不提供下载内容只是提供下载url和鉴权，这一部分加长了网络传输，而且一些metadata还是要去后端存储获取，延时还是有一些的。

通过刚才的分析，大家可以看到，其实docker build、push、pull其实主要耗时是在网络传输（主要）及安全防范措施（轻微）上，整个传输过程甚至大大超过了其他所有步骤的时间；这样可以借助我们的AppHouse方便的搭建本地企业级镜像仓库，将网络传输转移至内网，同时完全掌控了 build、push和pull的过程，这样提高效率的同时也解决了安全问题，可谓一举两得。

经过Docker、AppHouse的帮助，我们距极致追求的如丝般顺滑的持续集成目标只有一步之遥，Docker解决了依赖和环境问题，AppHouse解决了镜像安全快速传输的问题，接下来就是容器的部署和管理问题。

Docker实现了底层技术的创新，它的出现将开发者从与系统的纠缠中释放了出来，但是阻碍企业使用Docker的问题是容器的大规模部署、管理问题和缺少企业级容器工具及系统。

镜像创建完成后，需要把它发布到测试和生产环境。因为Docker占用资源小，在单个服务器上部署成百上千个容器也不足为奇。这个阶段中如何更合理地使用Docker也是一个难点，开发团队需要考虑如何打造一个可伸缩扩展的分发环境。

AppSoar提供人性化的Web管理界面，丰富的Compose文件格式和功能完备的API接口，通过Compose实现以十分简单的文件描述复杂的应用结构，让部署变得更简单。并且，AppSoar还提供丰富的企业应用商店，让在一键创建服务成为可能。这样可以快速搭建应用场景，开发者只需要关注开发本身即可。