搭建GitLab CI服务器

技术开发CI
CI, Gitlab

写在前面

之前已经用Bitnami-gitlab一体包已经在虚拟机上搭建了Git服务器，在项目开发过程中，经常面临频繁打包的问题，搞得软件研发人员很疲惫，之前就听说过可以使用“持续集成”的思路解决这样的问题，并且能够提高工作效率，所在才有了今天在持续集成上的尝试。

什么是“持续集成”

持续集成（Continuous Integration）指的是，频繁地（一天多次）将代码集成到主干。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。
它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

使用GitLab CI进行持续集成

我这里因为已经使用了Gitlab作为代码服务器，而Gitlab本身已经支持了CI，所以我这里就选择了使用Gitlab CI进行持续集成。

在开始之前先了解一些持续集成的相关概念。

Pipeline

一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。
任何提交或者 Merge Request 的合并都可以触发 Pipeline，如下图所示：

1
2
3
4
5
+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

Stages

Stages 表示构建阶段，说白了就是上面提到的流程。
我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：

  1. 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
  2. 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
  3. 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

因此，Stages 和 Pipeline 的关系就是：

1
2
3
4
5
6
7
8
9
+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

Jobs

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。
我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

  1. 相同 Stage 中的 Jobs 会并行执行
  2. 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
  3. 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

所以，Jobs 和 Stage 的关系图就是：

1
2
3
4
5
6
7
8
9
+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+

GitLab Runner

简介
理解了上面的基本概念之后，有没有觉得少了些什么东西 —— 由谁来执行这些构建任务呢？
答案就是 GitLab Runner 了！

想问为什么不是 GitLab CI 来运行那些构建任务？
一般来说，构建任务都会占用很多的系统资源 (譬如编译代码)，而 GitLab CI 又是 GitLab 的一部分，如果由 GitLab CI 来运行构建任务的话，在执行构建任务的时候，GitLab 的性能会大幅下降。

GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做拉！
因为 GitLab Runner 可以安装到不同的机器上 ，所以在构建任务运行期间并不会影响到 GitLab 的性能.

我这里采用的是：
git服务器地址为：192.168.1.113，
Gitlab runner地址为192.168.1.120

安装GitLab Runner

参照官网,选择一种方式进行安装：

1
2
3
4
5
# For RHEL/CentOS/Fedora
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

# For RHEL/CentOS/Fedora
sudo yum install gitlab-runner

注册 Runner

安装好 GitLab Runner 之后，我们只要启动 Runner 然后和 CI 绑定就可以了。

  • 打开你 GitLab 中的项目页面，在项目设置中找到 runners
  • 运行 sudo gitlab-ci-multi-runner register
  • 输入 CI URL
  • 输入 Token
  • 输入 Runner 的名字
  • 输入 gitlab-ci tags
  • 完成

当注册好 Runner 之后，可以用 sudo gitlab-runner list 命令来查看各个 Runner 的状态：

1
2
3
# sudo gitlab-runner list
Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
localhost.localdomain                               Executor=shell Token=2a627041123ff25c490629d80f0834 URL=https://192.168.1.113/

Register问题1
这一步比较坑，因为bitnami-gitlab一体包采用的是https的访问方式，所以在注册Runner的过程，一直报如下错误：

1
2
ERROR: Registering runner... failed                 runner=5nuRqxMY status=couldn't execute POST against https://192.168.1.113/api/v4/runners: Post https://192.168.1.113/api/v4/runners: x509: cannot validate certificate for 192.168.1.113 because it doesn't contain any IP SANs
PANIC: Failed to register this runner. Perhaps you are having network problems

解决方式参考如下地址，gitlab-ci-runner-ignore-self-signed-certificate

  • First edit ssl configuration on the GitLab server (not the runner)

    1
    2
    3
    4
    vim /opt/gitlab/embedded/ssl/openssl.cnf

    [ v3_ca ]
    subjectAltName=IP:192.168.1.1 <---- Add this line. 192.168.1.1 is your GitLab server IP.

  • Re-generate self-signed certificate

    1
    2
    3
    4
    cd /etc/gitlab/ssl
    sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/gitlab/ssl/192.168.1.1.key -out /etc/gitlab/ssl/192.168.1.1.crt
    sudo openssl dhparam -out /etc/gitlab/ssl/dhparam.pem 2048
    sudo gitlab-ctl restart

  • Copy the new CA to the GitLab CI runner

    1
    scp /etc/gitlab/ssl/192.168.1.113.crt root@192.168.1.120:/etc/gitlab-runner/certs

这样就解决Https证书问题了。

Register问题2
在mac端配置Runner的时候，会遇到如下问题：

1
x509: certificate signed by unknown authority

主要是mac对git代码服务器的证书不信任，在注册的时候加上ca证书就行了。

1
sudo gitlab-runner register --tls-ca-file 192.168.1.113.crt

unregister Runner

  • 所有runners

    1
    gitlab-runner unregister --all-runners

  • By URL and token:

    1
    gitlab-runner unregister --url http://gitlab.example.com/ --token t0k3n

  • By name:

    1
    gitlab-runner unregister --name test-runner

完毕！

如果想知道如何用Gitlab-CI设置Android项目，请参考我下一篇文章Android项目在Gitlab-CI上的使用;

参考资料

分享到