前言
公司的一个APP项目目前处在快速迭代期间,服务端有时会一天发几个版本,由于没有专门的运维岗,所以发布版本的工作只能由开发来做。
频繁的发版对本身就很忙的开发来讲无疑增加了不少的工作量,于是花了点时间研究了一下通过GitLab来实现了项目的CI(持续集成)以及CD(持续部署)。
目录
- GitLab搭建及一些隐藏的坑
- GitLab的CI/CD工作原理浅析
- 基于Maven项目的CI/CD实战
- 总结
GitLab搭建及一些隐藏的坑
GitLab分为企业版和社区版,社区版是基于MIT授权,企业版在社区版的基础之上加入了一些新的特性和功能,需要授权使用。
由于社区版功能已经比较完善,所以我们直接搭建社区版。
GitLab的安装需要依赖Nginx、Ruby on rails、git、redis、postgresql等模块,手动安装的话难度相对较大,好在GitLab提供了官方Docker镜像,我们通过Docker技术可以很方便的就能搭建起GitLab。
搭建环境参考:
系统:CentOS 7
内存:8G(官方建议至少4G以上,考虑到后面还要集成CI/CD,所以内存需要更大一点)
gitlab ce版本:11.10.4
搭建步骤:
1、确保系统已经安装Docker环境,通过docker pull gitlab/gitlab-ce命令拉取gitlab社区版镜像:
![cc30ef4f8780612954eab237b1de8a97.png](https://i-blog.csdnimg.cn/blog_migrate/e76d02089618cfbcac15ea947a046ff7.jpeg)
拉取完成之后通过docker images命令查看发现gitlab的镜像大小有2G,还是蛮大的。(网慢的小伙伴请耐心等待)
2、通过docker run命令运行容器:
![606be8d5ec98251a9802c648dff7e20d.png](https://i-blog.csdnimg.cn/blog_migrate/3a4fbf127c6b5d13b6bdc17b47885ccf.jpeg)
- 将容器的80以及443端口分别映射到宿主机的80和443端口,后面可以通过宿主机ip或域名直接访问到GitLab主页;因为宿主机的ssh默认的22端口已经改成了其他端口,所以为了后面方便使用git命令,所以直接将容器的22端口映射到宿主机22端口。
- 定义容器名称为gitlab。
- 通过volume将宿主机目录挂载到容器,实现容器数据的持久化。
- 启动容器使用的镜像名称。
因为初始化的东西比较多,所以需要等待一段时间,容器起来之后我们就可以登录GitLab系统了。
搭建中出现的问题:
当我们从GitLab上clone项目,点开Clone按钮,会发现一个奇怪的情况:
![544221a210580c72039b5c895247d821.png](https://i-blog.csdnimg.cn/blog_migrate/1a8e25119e098e736d7790b3a8cf2d14.jpeg)
不管是SSH还是HTTP,显示的项目地址看起来有点奇怪,实际上通过这个链接也根本clone不了项目
后来发现这一串字符代表的是Docker容器的ID,这里原本应该显示服务器的ip或是域名才对,一番查找,原来是在启动容器的时候没有指定hostname。
解决方案:重新运行docker run命令加上--hostname=ip配置。
GitLab的CI/CD工作原理浅析
采用GitLab作为公司代码管理平台,很大一部分原因就是看中它自带的CI/CD功能。
原理浅析
GitLab的CI/CD功能主要是通过GitLab Runner来执行:
![77a8247fec0e086f3392a655c4389323.png](https://i-blog.csdnimg.cn/blog_migrate/27fe8b375ba5b3ae4cd2339b86e70828.jpeg)
- 首先每个项目需要注册一个GitLab Runner实例,后面这个项目的持续集成、持续部署等动作都由该Runner负责执行。
- 当我们将代码push或者merge到远程仓库的指定分支时会触发GitLab Runner执行,具体的触发规则我们可以通过配置文件进行自定义配置。
- 通常一次完整的构建发布流程包括测试、编译、部署等几个阶段,GitLab Runner会按照配置文件分阶段去执行任务。
架构方案
因为每个项目都需要注册一个GitLab Runner,这些Runner既可以全部放到一台服务器,也可以跟着项目分散到不同的服务器。考虑到有些项目需要依赖其他项目以及一些公共模块,方便起见决定将所有Runner集中到一台服务器,这样依赖其他项目比较方便。
![181798147a547ebbabe661a731d1b7ff.png](https://i-blog.csdnimg.cn/blog_migrate/30ec9fd88fb3b894f860187664916632.jpeg)
主要流程:
- GitLab Runner编译代码之后,通过rsync命令将可执行文件发送到待部署的服务器。
- 通过ssh命令登录到目标服务器,执行部署命令。
基于Maven项目的CI/CD实战
安装GitLab Runner
1、添加GitLab官方源,执行命令:
![0e805867a98d543bbcea9e1efc802d60.png](https://i-blog.csdnimg.cn/blog_migrate/37675d6bead7c556be738a0b94c20ce0.jpeg)
2、安装最新版本的GitLab Runner,执行命令:
![cf970e2ad3763b0924cb11fd965f425e.png](https://i-blog.csdnimg.cn/blog_migrate/22446620622254a2029c60e52d9893e9.jpeg)
安装好GitLab Runner之后还不能使用,因为此时GitLab Runner还没有注册到我们的GitLab上的项目上。
注册GitLab Runner
打开GitLab项目主页,点击Settings->CI/CD,展开Runner选项:
![22313a07115685ee2a884141964453c3.png](https://i-blog.csdnimg.cn/blog_migrate/173d09ea4d2cf6968267b959dbf3a3dd.jpeg)
记住GitLab的URL地址以及项目注册token,后面会用到。
执行gitlab-runner register命令开始注册:
![9254959ce0f0caf8a002573d916c6482.png](https://i-blog.csdnimg.cn/blog_migrate/9c0f33a271d432c490a3ef46497c809a.jpeg)
- 对应前面记住的GitLab的URL地址。
- 对应前面记住的项目注册token。
- 对当前runner的描述。
- 对当前runner进行tag分类。
- 设置runner的执行方式。(这里选择以shell命令的方式执行)
配置文件
注册好GitLab Runner之后,我们还需要提供一个叫.gitlab-ci.yml的配置文件来配置Runner的触发场景。
![fd5ca622fe2fd850443bd06562d9436f.png](https://i-blog.csdnimg.cn/blog_migrate/4130dc3160a3aa3e010d3f225c8451dd.jpeg)
步骤:
- 定义我们的整个流程分为build和deploy两个阶段。
- 定义build阶段所需要执行的任务,任务有3个执行时机,分别是执行前、执行中和执行后,执行前我们运行test测试用例,执行中可以执行具体的编译脚本,执行后我们可以推送执行结果。
- 定义deploy阶段所需要执行的任务,任务同样有3个执行时机,作用同上。
项目构建的历史记录可以在GitLab上项目主页CI/CD -> Pipelines看到:
![99b1c813706291557c3823ada1237ba6.png](https://i-blog.csdnimg.cn/blog_migrate/977fbb9cbfb6b251640e7f7d323c08a9.jpeg)
总结
持续集成(CI),即在源代码变更后后自动进行构建和单元测试的过程,持续集成的目标是尽早地暴露集成错误。
持续部署(CD)是通过自动化的构建、和部署循环来快速交付高质量的产品。
GitLab作为一个代码管理平台,内部集成了CI/CD功能,通过CI/CD功能我们能够很方便实现项目的持续集成和持续部署工作。
“分享知识,收获快乐”
我是一名程序员,喜欢我的文章欢迎 关注 及 转发,我会经常与大家分享一些工作当中的编程技巧与经验。