Gitlab-CI使用及.gitlab-ci.yml配置入门

一、 Gitlab-CI/CD使用场景

首先，公司使用Gitlab作为工作仓库进行代码发布及版本控制，Gitlab内置了CI/CD的工具，这些工具可以用于代码提交的同时完成镜像构建、自动化测试、自动化部署等连续的工作：

• CI: Continuous Integration（持续集成）
• CD: Continuous Delivery（连续交付）
• CD: Continuous Deployment（持续部署）
  这里暂时只讨论CI持续集成部分的工作，我们常用CI来做一些自动化工作，这种自动化工作会运行在一台集中的机器上，比如程序镜像的打包，单元测试，部署等，它可以节省项目开发迭代过程中维护正确的代码所耗费的时间。

例比如CI中自动测试，在多人协同开发的过程中，可能会有频繁的不同分支的代码推送更新，使用CI管道，可在代码发布的同时触发CI中定义的单元测试操作，以便于在开发早期发现错误，从而确保所有新代码的提交都不影响项目功能。

二、 了解Gitlab-CI/CD工作流

参考下图先了解CI/CD的具体工作流和概念，黄色部分为主要涉及的概念，将在后文重点说明：

1. 你当前的代码库托管在Gitlab上， 且已经为代码仓库配置了gitlab-runner服务, 它是用来实际执行CI任务的服务器；
2. 提交代码，且根目录中包含一个名为.gitlab-ci.yml文件，该文件是用来指定构建、测试和部署流程、以及CI触发条件的脚本，其概念类似于docker-compose.yml文件；
3. Gitlab检测到.gitlab-ci.yml文件，若当前提交符合文件中指定的触发条件，则会使用配置的gitlab-runner服务运行该脚本进行测试等工作；
4. 若.gitlab-ci.yml中定义的某个自动化脚本运行失败，将判定为此次CI不通过，则需要提交者修复问题代码后重复提交，直至自动化CI通过。
5. 没有问题的提交才能被项目负责人merge到主分支，进行后续的部署工作（此文暂不涉及CD自动化部署）

三、 如何编写.gitlab-ci.yml文件

.gitlab-ci.yml文件中指定了CI的触发条件、工作内容、工作流程，编写和理解此文件是CI实战中最重要的一步，该文件指定的任务内容总体构成了1个pipeline、1个pipeline包含不同的stage执行阶段、每个stage包含不同的具体job脚本任务。

.gitlab-ci.yml示例文件及常用说明

 

 

Pipeline说明

一个.gitlab-ci.yml文件触发后会形成一个pipeline任务流由gitlab-runner来运行处理，pipeline中stage、job概念如下，需要按照项目实际情况定义不同stage和job， 自己绘制了一个流程示意图帮助理解:

 

 

示例 .gitlab-ci.yml文件运行顺序及逻辑说明

按1.所示在项目根目录中编写好yml文件，

1. 首先绿色方框中定义了stage的阶段顺序，总共定义了3个阶段，按顺序依次命名为build、test、deploy；

2. 第一个蓝色方框定义了build阶段的一个job，该job仅在tags阶段的分支提交时触发，执行script中的脚本，按照DockerfileCI文件将项目打包为成名为img的镜像，并推送到仓库中，然后移除本地镜像；

3. 第二个蓝色方框定义了test阶段的一个job，该job没有限制触发条件，将在每次提交时执行。

   • Image指定了该阶段使用的基础镜像，该镜像为本地手动提前创建并推送;
   • services指定了该阶段依赖使用的服务，mongo和redis，该job运行时会初始化指定服务版本的容器，并分别暴露域名为mongo:27017、redis:6379，需要在配置文件中提前配置好CI专用的配置文件;
   • befor_script指定了在执行正式脚本之前预先执行的命令，打印python版本信息、将CI专用测试配置文件置为项目读取的配置文件、运行测试数据初始化脚本、npm构建前端部分;
   • script指定了正式脚本执行命令，开始执行django的单元测试。

4. 其他gitlab-ci.yml文件参考

   • CI/CD Example: https://docs.gitlab.com/ee/ci/examples/
   • Job Keyword: https://docs.gitlab.com/ee/ci/yaml/#job-keywords

四、 Gitlab-Runner介绍和使用

上面讲了.gitlab.yml文件如何编写以及其中的job执行顺序逻辑，那各个job实际的执行者是谁呢，答案就是gitlab-runner，一般来说gitlab-runner会和gitlab所在的服务器进行隔离，因为一个任务的构建、往往会执行编译、测试、发布的过程，这个过程会消耗大量的系统资源。gitlab-runner几乎可以安装在任何的机器上，只要能和gitlab所在服务器及docker仓库服务器进行通信即可。

一般来说，gitlab上已由负责人配置好了gitlab-runner，我们只需要编写好.gitlab.yml文件提交代码即可触发runner进行工作。但对于初学者来说，你可能想能不能在提交代码前在本地先执行.gitlab.yml文件的job，本地调试成功检查没有问题后再进行最终代码的提交，触发服务端的CI流程。答案当然也是可以的。之前已经说了，.gitlab.yml文件中定义的job其实是某个服务器中的gitlab-runner在运行，那我们也可以在本地安装好gitlab-runner手动的来执行本地.gitlab.yml中的job。

Gitlab-runner的安装

你几乎可以在任何机器上安装gitlab-runner，这里讲一下mac上的安装方式:

• mac安装： brew install gitlab-runner

• 其他安装参考：https://docs.gitlab.com/runner/install/

• gitlab-runner-helper安装：docker pull gitlab-runner-helper

注：gitlab-runner需要依赖gitlab-runner-helper本地镜像，最好提前pull到本地仓库或者私有仓库中。

使用gitlab-runner运行本地.gitlab.yml中定义的job

目前本地的gitlab-runner貌似只能一次执行一个指定的job，而不能自动完成yml文件包含的pipeline的总流程，但作为本地测试也是足够了。当然，本地必须启动有docker服务，并且提前准备好了需要的基础镜像, job会基于基础镜像，将本地代码置于一个新目录中执行，本地runner时一般为生成容器中的/builds/projects0目录。

1. 进入本地项目根目录，即包含了.gitlab.yml的目录
2. 执行gitlab-runner命令：
   gitlab-runner exec docker test_job --docker-pull-policy=never

 

3. 参数释义
   • gitlab-runner exec docker 为固定命令写法;
   • test_job为.gitlab.yml中定义的一个job;
   • --docker-pull-policy=never表示使用本地的docker镜像而非网络仓库

这样很简单的安装和命令便能在本地运行一个gitlab-runner的测试了。

推送代码到gitlab分支

本地测试没问题后便可放心的将代码推送至远程分支了，如果当前是fork仓库，则需要同时将代码推送至upstream触发主仓库的CI流程，CI通过后，后续才可将分支代码合并至master。

五、字段详解

关键字	是否必须	描述
script	必须	定义Runner需要执行的脚本或命令
image	非必须	需要使用的docker镜像，请查阅该文档
services	非必须	定义了所需的docker服务，请查阅该文档
stage	非必须	定义了工作的场景阶段,默认是test
type	非必须	stage的别名，不赞成使用
variables	非必须	在job级别上定义的变量
only	非必须	定义哪些git引用（分支）适用该job
except	非必须	定义了哪些git引用(分支)不适用该job
tags	非必须	定义了哪些runner适用该job（runner在创建时会要求用户输入标签名来代表该runner）
allow_failure	非必须	允许任务失败，但是如果失败，将不会改变提交状态
when	非必须	定义job什么时候能被执行，可以是on_success,on_failure,always或者manual
dependencies	非必须	定义了该job依赖哪一个job，如果设置该项，你可以通过artifacts设置
artifacts	非必须	所谓工件。。就是在依赖项之间传递的东西，类似cache，但原理与cache不同
cache	非必须	定义需要被缓存的文件、文件夹列表
before_script	非必须	覆盖在根元素上定义的before_script
after_script	非必须	覆盖在根元素上定义的after_script
environment	非必须	定义让job完成部署的环境名称
retry	非必须	定义job失败后的自动重试次数

 

更多详解：https://blog.csdn.net/sinat_17775997/article/details/116068193

附录（涉及的其他相关操作）

配置docker私有仓库

由于CI流程会使用到我们自己打包的一些docker镜像，镜像的上传和下载会依赖组内的私有仓库，下面介绍如何配置docker的仓库连接：

• 编辑deamon.json配置文件
  Mac电脑可以直接通过docker应用， Preferences—>Docker Engine 直接编辑配置即可：
  
   

   

  增加insecure-registries和dns配置如下：

"insecure-registries": [
    "你的私有仓库host解析地址"
],
  "dns": [
    "你的私有仓库dns地址"
    ]

　　

 

 

作者：越大大雨天
链接：https://www.jianshu.com/p/4cc441b1c8a3