什么是Gitlab CI
Gitlab CI是一个持续集成的工具,目前已经与Gitlab完美整合在一起。它提供一个虚拟的代码测试、打包的环境,这个环境与Gitlab Repo勾连在一起,让每一次的push或者merge request触发这个虚拟环境的创建,自动运行测试与打包的脚本,得出脚本的运行结果呈现在Gitlab 的web页面上,然后再销毁这个虚拟的环境。并且,它能与我们的真正的产品部署环境连接起来,让我们能在Gitlab的web页面上看到部署环境的一些结果,让整个代码的生产线变得完整。通过Gitlab CI与Gitlab的整合,源代码开发、自动测试、自动打包、自动部署成为一条流水线,能极大地加快产品的迭代速度。
Gitlab Runner 与 Docker
Gitlab Runner是一个为我们创建上述Gitlab CI虚拟环境的一个程序,我们选择把这个程序所需的环境用Docker来安装,作为一个Docker Daemon Container来配置好Gitlab Runner运行的环境。每一个Gitlab project都可以注册一个或多个runner,这些runner就是负责跑我们上述的虚拟环境的,它们的注册,创建以及运行都是由Gitlab Runner这个程序来控制的。这些runner实际上都是docker container,由Gitlab Runner这个程序自动创建,它们与Gitlab Runner所处的container是同等关系而不是从属关系。使用docker来建立runner,使得每一个虚拟环境都干净、轻量,相互隔离,互不影响。
下面我主要讲一下在服务器上安装docker,通过docker安装Gitlab Runner,以及通过Gitlab Runner注册runner的步骤。
安装与配置
Docker
第一步先要在服务器上把Docker装起来,服务器环境是Centos,安装流程非常简单,完全参照Docker官网即可:https://docs.docker.com/engine/installation/linux/centos/#/install-docker-engine
这样安装好以后,每次运行docker指令都要加sudo,十分不方便,可以把用户加到docker group里面,便可以省去sudo了,参考:https://docs.docker.com/engine/installation/linux/centos/#/create-a-docker-group
Gitlab Runner的安装与注册
安装
我们用docker来配置一个container给Gitlab Runner程序运行。安装指令如下:
|
|
上述指令主要是根据gitlab/gitlab-runner这个docker镜像运行一个docker container,这个镜像里安装好了gitlab-runner这个程序来为我们创建测试用的虚拟环境。我们把这个container用–name参数命名为gitlab-runner。-v指令代表挂载,我们将host服务器主机的/var/run/docker.sock和/srv/gitlab-runner/config这两个文件或文件夹与gitlab-runner这个container内部的/var/run/docker.sock和/etc/gitlab-runner这两个文件或文件夹挂载在一起。/var/run/docker.sock是用来创建docker container的,都过挂载host的/var/run/docker.sock,使得gitlab-runner container可以利用host服务器的docker来创建container,而不需要使用docker-in-docker。/etc/gitlab-runner/里面则有一个config.toml文件,我们通过这个文件来设置一些runner的参数,挂载在host的/srv/gitlab-runner/config里使得我们可以通过修改host主机的这个文件来设置runner的参数。
还有一个比较重要的参数是–add-host。这个参数在Gitlab CI官网上是找不到的,但对于我们是必须的。因为gitlab.local是一个内网的gitlab服务器,不能通过公共的DNS来查找到,这个参数会把gitlab.local加到gitlab-runner container的host文件里。这个是docker提供的一个参数,当然我想如果host服务器的host文件里如果有gitlab.local的信息,通过上面说的挂载host主机上的/etc/hosts的方法也可以实现我们的需求。所以,如果gitlab服务器建在内网(我觉得是大多数情况),都需要通过这种方法解决。
注册
下面是为我们需要测试的Gitlab项目注册runner:
|
|
其中url填写gitlab服务器的域名,gitlab-ci token是每个project特有的,填写你需要测试的project的token即可。关于runner的更详尽的信息可以参照:https://docs.gitlab.com/ce/ci/runners/README.html
注册成功以后,我们还需要修改一个配置。因为我们执行测试的runner本身是一个docker container,执行测试时候runner需要从gitlab服务器里fetch gitlab repo,所以我们也需要确保它们也可以对gitlab.local这个域名进行解析。它们的配置信息通过挂载可以在host服务器主机的/srv/gitlab-runner/config/config.toml里查看和修改,下面是一个runner的配置例子:
|
|
这段配置信息除了extra_hosts这一项,其他都是注册成功后自动生成的。我们需要加上extra_hosts来确保gitlab.local可以得到正确的解析。
简述.gitlab-ci.yml
最后简述一下.gitlab-ci.yml这个文件。
当我们把代码push到gitlab上,或者提交了merge request,会自动触发gitlab ci进行测试。gitlab ci控制测试是通过project repo里面根目录的.gitlab-ci.yml这个文件来进行的,开发者在开发的同时也需要撰写这个文件并放到到repo的根目录下,才能触发自动测试。
下面以一个我自己开发的仿微博的java web项目的.gitlab-ci.yml为例,简单说明一下整个结构,可以对照这个文件来看。下面附上代码:
|
|
主要参数
image代表虚拟环境的基础镜像,这个镜像是docker镜像,我们可以根据项目需求在docker hub里挑选想要的镜像,作为基础的环境。因为weibo项目是用java开发的,因此这里选了java:8这个镜像。
services也是一些镜像,它们和我们主要的这个虚拟测试环境是同等的,都运行在一个独立的docker container中。这些service其实主要是用来运行数据库的,它们与主测试环境,即这里的java:8镜像建立的container,是通过docker link建立通信的。
variables是一些gitlab ci的变量,通过它们可以配置一些测试需要用到的参数,相当于是docker内的环境变量,并且可以给services共享。这里主要是配置postgres的用户,密码以及数据库,根据我们项目需求配置即可。后面我们就可以用这些参数来连接service了。这些参数的名字一般docker hub的image介绍里都会提及,我们可以根据具体的应用去查阅,看看我们需要用到哪些参数,极大地方便了我们的配置。
stage是测试的阶段,是人为划分的,只有在上一个stage正确通过以后才会运行后面的测试。
compile,connect,package,deploy都是job的名字,每个job都是独立运行在一个干净的docker container里面的,在运行结束时候自动销毁环境。其中同一个stage的job可以并行运行。每个job必须含有script,里面写我们执行测试的脚本即可。
artifacts保存我们需要在job和stage间共享的文件,如果测试成功,这些文件同时可以在gitlab的web页面上下载。
测试流程
- compile这个job主要用javac这个指令来把.java源文件编译成.class文件,这些.class文件放在artifacts里给下一个stage使用。
- connect这个job是进行单元测试的,我们要先下一个postgres的客户端去连接postgres这个service,进行一些数据库的初始化工作,再用junit这个库运行单元测试文件。
- package这个job是把weibo这个工程打成war包,放在artifacts里给后面测试部署环境使用。
- deploy这个job是基于tomcat:7这个基础镜像的,我们把上面的war包部署在tomcat里,把tomcat启动起来,然后下载安装jmeter来进行压力测试,并在屏幕上打印测试结果。
其实.gitlab-ci.yml还有很多配置的知识,上面所述只不过冰山一角,要针对自己的项目编写这个文件,必须阅读gitlab ci的文档。