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

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

鸟瞰图

三个重要的概念

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

• 镜像仓库：github是最大的源码库，hub.docker.com则是最大的镜像仓库（官方）。github上面包含了很多公司和个人项目的源码，hub.docker.com上则包含了很多公司和个人的docker镜像。docker镜像仓库就相当于github源码仓库。它除了可以搭建在互联网上，也可以搭建在局域网上。
• Docker镜像：github上有成千上万的源码库，但在我们本地，通常只通过git clone命令来获取几个源码库到本地进行开发。一个镜像就相当于一个项目的源码库，是一个静态的概念。只不过源码库中包含的只是源码，而镜像则既包含源码也包含源码的运行环境（各种依赖）。
• Docker容器：源码编译成可执行程序后，可以同时运行在多个进程中。比如用asp.net core开发一个站点后，可以同时启动多个站点（使用不同端口号），运行在不同的进程当中。Docker容器就是一个运行中的镜像。如果说：源码-->可执行程序-->进程；那么对于docker来说，则是：镜像-->容器。

下面是整体的一个结构：

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

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，也应当是需要采用第三方工具或者自行开发工具来实现的，但是我暂时还没有实现这一步骤。

需要部署和开发的部分

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

• 代码库：通常有GitLab、Gogs等，这里我开始选择的是GitLab，但是试用之后，以及参考其他人的使用评价，感觉都是笨重、卡顿，比方说在我2GB内存的Linux上运行GitLab时明显感觉很不流畅。因此我选用了一个go语言开发的，Gogs源码管理库，也是基于Git的。github地址是：github.com/gogs/gogs。如何配置Gogs，参考《安装和配置Gogs源码仓库》。
• 持续集成工具：业界的工具也很多，有Jenkins、CircleCI等。这里我了解得不算太深入，但就了解到的情况来看，都存在下面这几个问题的某几项：配置复杂、入门学习曲线陡峭；收费；文档不健全；不是基于docker。本来我选择的也是go语言开发的Drone，但是它的文档比较简单，版本还没有到1.0，遇到两个问题，全网都找不到解决方案，最后放弃了。现在打算自己来写一个工具实现这部分，比起成熟的工具肯定不够灵活，但是满足我们的特定需求应当是足够了。
• 远程镜像仓库：这个可以使用Docker官方提供的Registry镜像来制作，但需要配置访问权限等。可以参考《安装和配置Docker镜像仓库》。

持续集成工具的功能

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

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

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

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