转载:Gitlab-CI使用及.gitlab-ci.yml配置入门一篇就够了 - 简书 (jianshu.com)
一、 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的具体工作流和概念,黄色部分为主要涉及的概念,将在后文重点说明:
![](https://img2020.cnblogs.com/blog/1755541/202106/1755541-20210602142139036-1450674924.png)
- 你当前的代码库托管在Gitlab上, 且已经为代码仓库配置了
gitlab-runner
服务, 它是用来实际执行CI任务的服务器; - 提交代码,且根目录中包含一个名为
.gitlab-ci.yml
文件,该文件是用来指定构建、测试和部署流程、以及CI触发条件的脚本,其概念类似于docker-compose.yml文件; - Gitlab检测到
.gitlab-ci.yml
文件,若当前提交符合文件中指定的触发条件,则会使用配置的gitlab-runner
服务运行该脚本进行测试等工作; - 若
.gitlab-ci.yml
中定义的某个自动化脚本运行失败,将判定为此次CI不通过,则需要提交者修复问题代码后重复提交,直至自动化CI通过。 - 没有问题的提交才能被项目负责人merge到主分支,进行后续的部署工作(此文暂不涉及CD自动化部署)
三、 如何编写.gitlab-ci.yml
文件
.gitlab-ci.yml
文件中指定了CI的触发条件、工作内容、工作流程,编写和理解此文件是CI实战中最重要的一步,该文件指定的任务内容总体构成了1个pipeline
、1个pipeline
包含不同的stage
执行阶段、每个stage
包含不同的具体job
脚本任务。
.gitlab-ci.yml示例文件及常用说明
![](https://img2020.cnblogs.com/blog/1755541/202106/1755541-20210602142245268-1175031049.png)
Pipeline说明
一个.gitlab-ci.yml
文件触发后会形成一个pipeline
任务流由gitlab-runner
来运行处理,pipeline
中stage
、job
概念如下,需要按照项目实际情况定义不同stage
和job
, 自己绘制了一个流程示意图帮助理解:
![](https://img2020.cnblogs.com/blog/1755541/202106/1755541-20210602142254156-1552085971.png)
示例 .gitlab-ci.yml
文件运行顺序及逻辑说明
按1.
所示在项目根目录中编写好yml文件,
-
首先绿色方框中定义了
stage
的阶段顺序,总共定义了3个阶段,按顺序依次命名为build、test、deploy; -
第一个蓝色方框定义了build阶段的一个
job
,该job
仅在tags阶段的分支提交时触发,执行script中的脚本,按照DockerfileCI文件将项目打包为成名为img的镜像,并推送到仓库中,然后移除本地镜像; -
第二个蓝色方框定义了test阶段的一个
job
,该job
没有限制触发条件,将在每次提交时执行。Image
指定了该阶段使用的基础镜像,该镜像为本地手动提前创建并推送;services
指定了该阶段依赖使用的服务,mongo和redis,该job运行时会初始化指定服务版本的容器,并分别暴露域名为mongo:27017、redis:6379,需要在配置文件中提前配置好CI专用的配置文件;befor_script
指定了在执行正式脚本之前预先执行的命令,打印python版本信息、将CI专用测试配置文件置为项目读取的配置文件、运行测试数据初始化脚本、npm构建前端部分;script
指定了正式脚本执行命令,开始执行django的单元测试。
-
其他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
-
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
目录。
- 进入本地项目根目录,即包含了
.gitlab.yml
的目录 - 执行
gitlab-runner
命令:
gitlab-runner exec docker test_job --docker-pull-policy=never
![](https://img2020.cnblogs.com/blog/1755541/202106/1755541-20210602144726868-1952269357.png)
gitlab-runner本地运行示例
- 参数释义
-
gitlab-runner exec docker
为固定命令写法; -
test_job
为.gitlab.yml
中定义的一个job
; -
--docker-pull-policy=never
表示使用本地的docker镜像而非网络仓库
-
这样很简单的安装和命令便能在本地运行一个gitlab-runner
的测试了。
推送代码到gitlab分支
本地测试没问题后便可放心的将代码推送至远程分支了,如果当前是fork仓库,则需要同时将代码推送至upstream触发主仓库的CI流程,CI通过后,后续才可将分支代码合并至master。
附录(涉及的其他相关操作)
配置docker私有仓库
由于CI流程会使用到我们自己打包的一些docker镜像,镜像的上传和下载会依赖组内的私有仓库,下面介绍如何配置docker的仓库连接:
- 编辑
deamon.json
配置文件
Mac电脑可以直接通过docker应用, Preferences—>Docker Engine 直接编辑配置即可:
deamon.json配置
增加insecure-registries和dns配置如下:
"insecure-registries": [ "你的私有仓库host解析地址" ], "dns": [ "你的私有仓库dns地址" ]
其中,only和except的使用参考:Choose when to run jobs | GitLab
only定义job什么时候run;except定义job什么时候不run