基于Docker的持续集成方案(介绍) - Part.1

2018-6-3 分类: 系统架构

使用docker有很多的便利,这个就不再讲述了,在文章 《基于Docker的持续集成方案(安装docker) - Part.2》 已经对docker有所介绍。这篇文章将介绍如何将docker结合到持续集成(持续部署)中。

鸟瞰图

三个重要的概念

这三个概念可以和源码管理做类比。

下面是整体的一个结构:

基于docker的CI鸟瞰图

上图中每个步骤的流程如下:

  1. 本机开发环境,不需要安装docker,只需要根据选用的语言,安装顺手的开发工具就好了,例如Visual Studio等。开发者代码提交到位于本地局域网中的Git源码管理库,例如GitLab、Gogs等。此处我选择的源码管理库是Gogs。
  2. 使用源码库提供的Web钩子(Web hooks),将源码管理库和持续集成工具关联起来。当源码库更新时,发送通知给持续集成工具。
  3. 持续集成工具通过Web钩子获取到源码库更新的通知,然后从源码库拉取代码到本地。项目源码的根目录中应当包含两个文件,一个Dockerfile,一个docker-compose。其中Dockerfile用于制作镜像,docker-compose用于运行容器。
  4. 拉取到最新的源码后,代码持续集成工具负责生成本地镜像、运行容器(图中步骤3、步骤4)。
  5. 当开发者提交的是一个Tag标签时(此处可以自行定义规则,例如当Tag的前缀为release时),则持续集成工具则将本地镜像推送到远程的镜像仓库(Registry)。
  6. 当远程的镜像仓库获得更新后,将从镜像仓库中拉取镜像到本地镜像,然后运行容器,更新正式环境。

上图的步骤6、步骤7,也应当是需要采用第三方工具或者自行开发工具来实现的,但是我暂时还没有实现这一步骤。

需要部署和开发的部分

从上面的步骤中,可以看到,有若干需要部署的第三方工具。其中包括:

持续集成工具的功能

根据上面的分析,这个持续集成工具(我给它起名叫GOCI,因为打算用go语言来开发)需要实现的功能有下面这些:

  1. 接受源码库的提醒
  2. 判断是不是Commit提交
  3. 执行git pull,拉取源码
  4. 判断源码根目录是否有docker-compose文件
  5. 执行docker-compose,制作镜像(需要Dockerfile)、运行容器
  6. 根据规则和需要,执行docker push,将生成的镜像推送至远程镜像仓库

以上还在开发的过程当中 ...

感谢阅读,希望这篇文章能给你带来帮助!