当谈到 GitLab CI 的时候,我们都该聊些什么(下篇)

百家 作者:又拍云 2017-10-17 10:39:06


 又拍云 Open Talk 

No.37 (上海)  No.38 (北京)

报名从速!


——BEGIN——

本文根据莫红波(又拍云系统开发高级工程师)在又拍云 Open Talk No. 36  “看微服务如何漫步云中化繁为简”中的分享整理而成,此次分享的主题是“CI/CD 的又拍云实践”。

上篇主要介绍 GitLab WorkFlow 以及 CI/CD 做的事情,详细分析 GitLab CI 跟 Runner 信息交互是如何进行的。接下来将为大家讲解 Executor 的实现,再通过两个例子具体展示 GitLab CI 的使用。


Executor

本章主要讲了在 Runner 在接收到任务之后,会调用 Executor,Executor 是怎么实现的,重点介绍 Docker Executor 的实现细节

其实 Runner 会去调用对应的 executor,由 executor 来完成接下去的工作。

图 12

图 12 是从 GitLabMutliRunner 项目中截取的一部分代码,基本可以说明 executor 的流程。

第一步Prepair,做准备工作;

第二步:拉取代码,根据 Job 里的 git_info 字段,Runner 去 GitLab 仓库拉取代码;

第三步:还原缓存,这些缓存是上一次构建留下的;

第四步:下载 artifacts,这是前一个阶段的产生的中间结果;

第五步:执行用户定义的脚本,这里指的是 before_scripts 跟 scripts 两部分;

第六步:执行 after_scripts;

第七步:保存缓存打包 artifacts 等;

第八步:上传 artifacts 供下一阶段使用。

基于这样一个流程,官方提供了 ssh、shell、docker、docker-ssh、virtualbox、kubernates 等执行器,来应对实际使用中的不同场景,本次分享主要也是从 Docker 跟 Docker-ssh 进行展开的。由于 Docker 的隔离性强、秒级别启动容器、轻量、回收方便这些特点非常符合集成测试的要求。

首先,如果要使用 Docker executor,CI 配置文件需要做如下调整:


图 13

1.定义 image 字段,该字段指定了本次测试环境使用的 Docker 镜像;

2. services,这个字段定义了本次测试依赖的服务,这里依赖的是 redis 跟 mysql。

Docker executor 的实现

第一步:Prepare,Runner 会先去下载 redis、mysql 等项目依赖的服务,启动映射了目录代码的容器,启动映射了缓存目录的容器。

图 14

第二步:GetSource,Runner 会在启动一个 predefine 的容器,通过 volume from 的方式挂载项目代码路径,再通过 predefine 这个容器去拉取代码。由于目录共享,所以 volumes 里的这个容器数据内容也发生了改变。

图 15

第三步:执行脚本,runner 会启动一个 build 容器,通过 docker link 的方式把依赖的服务连接起来,通过 docker volume from 的方式加载项目代码以及缓存,然后执行 job 中定义的脚本。

图 16


Artifacts

当图片处理项目 Nami 刚接入到 CI 时,是分成 Test 跟 Build 两个阶段处理,Test 阶段需要先编译 Nami,然后启动测试。等测试通过后,执行第二阶段,进行 Docker Build,这时又需要重新再编译依次 Nami,这个过程很费时。后来了解到了 Artifacts 这个功能,可以把这个阶段中产生的文件上传到 GitLab 供下一个阶段来使用,这样以来就不需要二次编译了。

图 17

完成优化后,将整个过程拆成了 3 个阶段,第一个阶段进行编译,第二个阶段使用上一个阶段编译好的结果进行测试,第三个阶段使用第一个阶段编译好的二进制做 Docker Build。这样一来,整个过程中只需要做一次编译,大大缩短了构建耗费的时间。

图 18

另外上传 GitLab 还有一个好处,安装包可以直接通过网页下载回来。


关于 GitLab CI 的实践经验

C/C++ 编译优化

CDN 项目依赖 Nginx,并且增加了公司定制的逻辑,所以每次测试都需要重新编译 Nginx,但是众所周知编译是十分耗时的。为了解决这个问题,我们引入了 CCACHE。CCACHE 是一个编辑器驱动器,第一次编译时 CCACHE 会缓冲 GCC 的 -E 输出,编译选项以及 O 文件到 $HOME/.ccache 下,第二次编译时尽量利用缓冲,必须时更新缓冲。但是这里会有一个问题,测试跑完之后容器立刻就被回收了,怎么把编译缓存保留到下一次测试呢?

这里就需要用到前面提交的 cache 选项了,cache 选项可以把上一次的缓存目录保留到下一次测试中,供下一次测试使用。但是我们需要对 ccache 做一下配置,修改缓存的路径,指定到 /cache 目录下。


$ ccache —set-config=cache_dir=/cache/.ccache
$ ccache -F 0 && ccache -M 0


Localhost 问题

图 19

如果测试中依赖第三方服务的话,docker executor 是通过 docker link 的方式,但是采用这种方式的话,Build 这个容器就无法通过 127.0.0.1 来访问 Redis、Mysql 了。但是研发同学常会把测试环境的配置写成 127.0.0.1,方便本地开发测试。这样一来,接入到 CI 之后就会有不少困扰。针对这个问题,我们给出了两种解决方案。

第一种解决方案是使用别名:在定义 services 的时候,可以定义 alias,来指定该服务的别名,指定好别名之后,Build 容器内就会多一条该别名的解析记录,解析到指定的容器 IP。这种方式下,研发同学只要修改下测试配置就可以把服务跟测试跑起来,不过本地开发的时候,需要增加一条解析记录,把别名解析到 127.0.0.1。

图 20

第二种解决方案是端口转发,这种方式更加简单灵活些。拿 redis 举个例子,如果测试中以来了 redis,需要在 build 容器中安装 3proxy 做端口转发,并且把对 6379 端口的请求,都转发到 redis 对应容器的 6379 上去,通过这种方式来解决访问 127.0.0.1:6379。这种方式更加方便,研发同学不需要去修改测试的配置,但是需要在执行测试之前,去启动 3proxy 并配置端口转发规则。

——END——

Open Talk 是由又拍云发起的系列主题分享沙龙,秉承又拍云回馈技术、加速在线业务的初衷,从 2015 年开启以来,Open Talk 至今已成功举办 36 期,辐射线上线下近 50,000 技术人群。不管是从某个“主题”出发,横向拓展技术干货分享,还是以一家“企业”为主,纵向深挖企业的开发、产品、运维体系,Open Talk 秉承“干货不注水”的理念,场场爆满。

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接