deepfacelab集成环境版_DevOps：一个基于GitLab实现的持续集成CI和持续部署CD方案

前言

公司的一个APP项目目前处在快速迭代期间，服务端有时会一天发几个版本，由于没有专门的运维岗，所以发布版本的工作只能由开发来做。

频繁的发版对本身就很忙的开发来讲无疑增加了不少的工作量，于是花了点时间研究了一下通过GitLab来实现了项目的CI(持续集成)以及CD(持续部署)。

目录

1. GitLab搭建及一些隐藏的坑
2. GitLab的CI/CD工作原理浅析
3. 基于Maven项目的CI/CD实战
4. 总结

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社区版镜像：

拉取完成之后通过docker images命令查看发现gitlab的镜像大小有2G，还是蛮大的。(网慢的小伙伴请耐心等待)

2、通过docker run命令运行容器：

1. 将容器的80以及443端口分别映射到宿主机的80和443端口，后面可以通过宿主机ip或域名直接访问到GitLab主页；因为宿主机的ssh默认的22端口已经改成了其他端口，所以为了后面方便使用git命令，所以直接将容器的22端口映射到宿主机22端口。
2. 定义容器名称为gitlab。
3. 通过volume将宿主机目录挂载到容器，实现容器数据的持久化。
4. 启动容器使用的镜像名称。

因为初始化的东西比较多，所以需要等待一段时间，容器起来之后我们就可以登录GitLab系统了。

搭建中出现的问题：

当我们从GitLab上clone项目，点开Clone按钮，会发现一个奇怪的情况：

不管是SSH还是HTTP，显示的项目地址看起来有点奇怪，实际上通过这个链接也根本clone不了项目

后来发现这一串字符代表的是Docker容器的ID，这里原本应该显示服务器的ip或是域名才对，一番查找，原来是在启动容器的时候没有指定hostname。

解决方案：重新运行docker run命令加上--hostname=ip配置。

GitLab的CI/CD工作原理浅析

采用GitLab作为公司代码管理平台，很大一部分原因就是看中它自带的CI/CD功能。

原理浅析

GitLab的CI/CD功能主要是通过GitLab Runner来执行：

1. 首先每个项目需要注册一个GitLab Runner实例，后面这个项目的持续集成、持续部署等动作都由该Runner负责执行。
2. 当我们将代码push或者merge到远程仓库的指定分支时会触发GitLab Runner执行，具体的触发规则我们可以通过配置文件进行自定义配置。
3. 通常一次完整的构建发布流程包括测试、编译、部署等几个阶段，GitLab Runner会按照配置文件分阶段去执行任务。

架构方案

因为每个项目都需要注册一个GitLab Runner，这些Runner既可以全部放到一台服务器，也可以跟着项目分散到不同的服务器。考虑到有些项目需要依赖其他项目以及一些公共模块，方便起见决定将所有Runner集中到一台服务器，这样依赖其他项目比较方便。

主要流程：

1. GitLab Runner编译代码之后，通过rsync命令将可执行文件发送到待部署的服务器。
2. 通过ssh命令登录到目标服务器，执行部署命令。

基于Maven项目的CI/CD实战

安装GitLab Runner

1、添加GitLab官方源，执行命令：

2、安装最新版本的GitLab Runner，执行命令：

安装好GitLab Runner之后还不能使用，因为此时GitLab Runner还没有注册到我们的GitLab上的项目上。

注册GitLab Runner

打开GitLab项目主页，点击Settings->CI/CD，展开Runner选项：

记住GitLab的URL地址以及项目注册token，后面会用到。

执行gitlab-runner register命令开始注册：

1. 对应前面记住的GitLab的URL地址。
2. 对应前面记住的项目注册token。
3. 对当前runner的描述。
4. 对当前runner进行tag分类。
5. 设置runner的执行方式。(这里选择以shell命令的方式执行)

配置文件

注册好GitLab Runner之后，我们还需要提供一个叫.gitlab-ci.yml的配置文件来配置Runner的触发场景。

步骤：

1. 定义我们的整个流程分为build和deploy两个阶段。
2. 定义build阶段所需要执行的任务，任务有3个执行时机，分别是执行前、执行中和执行后，执行前我们运行test测试用例，执行中可以执行具体的编译脚本，执行后我们可以推送执行结果。
3. 定义deploy阶段所需要执行的任务，任务同样有3个执行时机，作用同上。

项目构建的历史记录可以在GitLab上项目主页CI/CD -> Pipelines看到：

总结

持续集成(CI)，即在源代码变更后后自动进行构建和单元测试的过程，持续集成的目标是尽早地暴露集成错误。

持续部署(CD)是通过自动化的构建、和部署循环来快速交付高质量的产品。

GitLab作为一个代码管理平台，内部集成了CI/CD功能，通过CI/CD功能我们能够很方便实现项目的持续集成和持续部署工作。

“分享知识，收获快乐”

我是一名程序员，喜欢我的文章欢迎 关注 及 转发，我会经常与大家分享一些工作当中的编程技巧与经验。