持续集成的概念

持续集成，Continuous integration ，简称CI。

首先，解释下集成：所有的项目代码都是托管在SVN或者GIT服务器上（以下简称代码服务器）。每个项目都有若干个单元测试和集成测试。集成测试是单元测试的逻辑扩展：在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来（关于单元测试及集成测试的详述，读者可以查阅相关文档）。

简单来说，集成测试就是把所有的单元测试跑一遍，以及其它一些能自动完成的测试。只有通过了集成测试的代码才能上传到代码服务器上，确保上传的代码没有问题。集成一般指集成测试。

持续，显而易见就是长期对代码进行的集成测试。既然是长期进行，那么最好是自动执行，否则人工执行既没保证，而且耗人力。

基于此种目的，我们需要有一台服务器，它将定期从代码服务器中拉取代码，并进行编译，然后自动运行集成测试；并且每次集成测试的结果都会记录在案。

持续集成的特点

• 它是一个自动化的周期性的集成测试过程，从拉取代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的，无需人工干预；
• 需要有专门的集成服务器来执行集成构建；
• 需要有代码托管工具支持；

持续集成的作用

• 保证团队开发人员提交代码的质量，减轻了软件发布时的压力；
• 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；

首先，Docker可以让你非常容易和方便地以“容器化”的方式去部署应用。 它就像集装箱一样，打包了所有依赖，再在其他服务器上部署很容易，不至于换服务器后发现各种配置文件散落一地，这样就解决了编译时依赖和运行时依赖的问题；

其次，Docker的隔离性使得应用在运行是就像处于沙箱中一样，每个应用都认为自己是在系统中唯一运行的程序，就像刚才例子中，A依赖于Python 2.7，同时A还依赖于B，但B却依赖于Python3， 这样我们可以在系统中部署一个基于python2.7的容器和一个基于python3的容器，这样就可以很方便的在系统中部署多种不同的环境来解决依赖复杂度的问题。这里有些朋友可能会说，虚拟机也可以解决这样的问题！诚然，虚拟化确实可以做到这一点，但是这样需要硬件支持虚拟化及开启BIOS中虚拟化相关的功能，同时还需要在系统中安装2套操作系统，虚拟机的出现是解决了操作系统和物理机的强耦合问题。但是Docker就轻量化很多，只需内核支持，无需硬件和BIOS的强制要求，可以很轻松迅速的在系统上部署多套不同的容器环境，容器的出现解决了应用和操作系统的强耦合问题。

正以为Docker是以应用为中心，镜像中打包了应用及应用所需的环境，一次构建，处处运行。这种特性完美的解决了传统模式下应用迁移后面临的环境不一致问题。

同时，Docker 压根不管内部应用怎么启动，你自己爱咋来咋来，我们用 docker start 或 run 作为统一标准。这样我们应用启动就标准化了， 不需要再根据不同应用而记忆一大串不同的启动命令。

基于Docker的特征，现在常见的利用 Docker 进行持续集成的流程如下：

1. 开发者提交代码
2. 触发镜像构建
3. 构建镜像上传至私有仓库
4. 镜像下载至执行机器
5. 镜像运行

其基本拓扑结构如下所示：

熟悉Docker的都知道，Docker以的启动是非常快的，可以说是秒启。在上述的五步中，1 和 5 的耗时是比较短的，整个持续集成主要耗时集中在中间的3个步骤，也就是 Docker build，Docker push ，Docekr pull 的时间消耗.

Docker Registry升级到 v2 后加入了很多安全相关检查，在v2中的镜像的存储格式变成了gzip ，镜像在压缩过程中占用的时间也是比较多的。

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

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

整个持续集成平台架构演进到如下图所示：