基于 gitlab 的 CI/CD

,
loading...

前言

GitLab CI/CD 是一个内置在GitLab中的工具，用于通过持续方法进行软件开发：

  • Continuous Integration (CI) 持续集成
  • Continuous Delivery (CD) 持续交付
  • Continuous Deployment (CD) 持续部署

原理:

持续集成的工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。
持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。

预备知识

  • gitlab-ci涉及的抽象概念
  • YML文件的基本语法规则
  • .gitlab-ci.yml配置的特定关键字

gitlab-ci涉及的抽象概念

首先要了解的是gitlab-ci中涉及的一些基本概念

Pipeline & Job

Pipeline是Gitlab根据项目的.gitlab-ci.yml文件执行的流程，它由许多个任务节点组成, 而这些Pipeline上的每一个任务节点，都是一个独立的JobJob在YML中的配置我们将会在下面介绍，现在需要知道的是：每个Job都会配置一个stage属性，来表示这个Job所处的阶段。一个Pipleline有若干个stage,每个stage上有至少一个Job，如下图所示：
7

Runner

Runner可以理解为：在特定机器上根据项目的.gitlab-ci.yml文件，对项目执行pipeline的程序。Runner可以分为两种： Specific Runner 和 Shared Runner

  • Shared Runner是Gitlab平台提供的免费使用的runner程序，它由Google云平台提供支持，每个开发团队有十几个。对于公共开源项目是免费使用的，如果是私人项目则有每月2000分钟的CI时间上限。
  • Specific Runner是我们自定义的，在自己选择的机器上运行的runner程序，gitlab给我们提供了一个叫gitlab-runner的命令行软件，只要在对应机器上下载安装这个软件，并且运行gitlab-runner register命令，然后输入从gitlab-ci交互界面获取的token进行注册, 就可以在自己的机器上远程运行pipeline程序了。
    Gitlab-runner下载链接：
  1. Shared Runner 和 Specific Runner的区别
  2. Shared Runner是所有项目都可以使用的，而Specific Runner只能针对特定项目运行
  3. Shared Runner默认基于docker运行，没有提前装配的执行pipeline的环境，例如node等。而Specific Runner你可以自由选择平台，可以是各种类型的机器，如Linux/Windows等，并在上面装配必需的运行环境，当然也可以选择Docker/K8s等
    私人项目使用Shared Runner受运行时间的限制，而Specific Runner的使用则是完全自由的。

Executor

什么是Executor？ 我们上面说过 Specific Runner是在我们自己选择的平台上执行的，这个平台就是我们现在说到的“Executor”，我们在特定机器上通过gitlab-runner这个命令行软件注册runner的时候，命令行就会提示我们输入相应的平台类型。可供选择的平台一共有如下几种，下面是一张它们各方面特点的比较表格

下面是表格的原文链接
原文链接

gitlab-ci.yml配置的特定关键字

在了解了YML文件的语法格式后，接下来需要了解的就是gitlab-ci独特的配置关键字，这些关键字将在.gitlab-ci.yml中使用，并用来控制一个pipeline具体的运作过程

gitlab提供了很多配置关键字，其中最基础和常用的有这么几个

  • stages
  • stage
  • script
  • tags
  • stages & stage

stages & stage

stages定义在YML文件的最外层，它的值是一个数组，用于定义一个pipeline不同的流程节点

stage

是一个字符串，且是stages数组的一个子项，表示的是当前的pipeline节点。

script

它是当前pipeline节点运行的shell脚本（以项目根目录为上下文执行）。
这个script是我们控制CI流程的核心，我们所有的工作：从安装，编译到部署都是通过script中定义的shell脚本来完成的。
如果脚本执行成功，pipeline就会进入下一个Job节点，如果执行失败那么pipeline就会终止

tags

tags是当前Job的标记，这个tags关键字是很重要，因为gitlab的runner会通过tags去判断能否执行当前这个Job

gitlab 实现流程

1

  1. 开发者在commit代码或者提交merge request会自动触发CI/CD流程。
  2. 流程开始后，会主动读取项目根目录下的.gitlab_ci.yml文件，获取构建镜像，构建步骤，构建命令等,并运行一个CI pipeline（一个pipeline通常分为三个阶段：build，test，deploy）
  3. 根据.gitlab_ci.yml中配置的stage中的tags，选择对应的gitlab runner，根据配置的image启动容器，并在该容器中执行stage中的构建命令。

手动实现

其实它只是省略了一些我们的手动发布部署过程，将其自动化，但原来的流程还是一个不能少。所以，我们要进行的第一步，就是手动实现一遍流程。

2

  1. (gitlab服务器) 创建代码仓库
  2. (开发PC) git clone
  3. (开发pc) 修改代码，
  4. (开发pc) git push
  5. (部署服务器) git pull
  6. (部署服务器) 执行部署步骤

此说明只讲解gitlab CI流程，手动实现此处仅写出步骤，暂不深究

使用gitlab CI来替代手动部署工作

安装gitlab-runner

下载二进制文件

1
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

赋予权限：

1
sudo chmod +x /usr/local/bin/gitlab-runner

创建gitlabCI用户：

1
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

安装并作为运行服务：

1
2
sudo /usr/local/bin/gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo /usr/local/bin/gitlab-runner start

注册gitlab-runner：

打开gitlab

Gitlab项目首页=> setting => CI/CD => Runners => Specific Runners
记住这个url和token

现在转到测试或者部署的服务器上执行注册步骤

  1. 执行sudo gitlab-runner register， 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    $ sudo gitlab-runner register
    [sudo] password for username:
    Runtime platform                                    arch=amd64 os=linux pid=389259 revision=bd40e3da version=14.9.1
    Running in system-mode.

    Enter the GitLab instance URL (for example, https://gitlab.com/):
    http://127.0.0.1/  #输入对应的url 回车
    Enter the registration token:
    **************** # 输入token 回车
    Enter a description for the runner:# 描述
    [yp-virtual-machine]: a test machine
    Enter tags for the runner (comma-separated):
    test-tag # tag 标签
    Enter optional maintenance note for the runner:
    A machine that tests the release process # 维护说明
    Registering runner... succeeded                     runner=qsbMJBJ1
    Enter an executor: virtualbox, docker-ssh, parallels, shell, ssh, docker+machine, docker-ssh+machine, kubernetes, custom, docker:
    shell # 以shell 脚本运行
    Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
  2. 之后就可以在gitlab的设置中看见注册的runner
    5
    其中tag 描述以及运行方式都是可以在注册之后修改的，所以可以放心填写。
    4
  3. 设置一下
    6
    它可以使.gitlab-ci.yml在没有指定tag标签值时也能运行

参考链接

激活

注册完了可能还需要激活，这时我们可以看下面板，如果有个黑色的感叹号，这说明runner注册成功了，但是尚未激活（如果是绿色的说明已经激活，本步骤跳过）
5
激活方法是本地运行：

1
sudo gitlab-runner verify

编写.gitlab-ci.yml

在项目根目录中添加名为.gitlab-ci.yml的文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
before_script:
  - export 
stages:
  - test
  - build
  - deploy

test:
  stage: test
  retry: 2
  tags:
    - test-tag
  script:
    - echo 'testing'
    - go test ./... 

build:
  stage: build
  retry: 2
  tags:
    - test-tag
  script:
    - echo 'build'
    - go build -o app .
  only:
    - master

deploy:
  stage: deploy
  retry: 2
  script:
    - ./app 
  tags:
    - test-tag
  only:
    - master

开发PC gitpush实现自动化部署

git push之后在项目的CI/CD中可以看到命令详情

在CI/CD中可以看见管道执行情况

11

至此项目CI测试部署流程执行成功

注意点

需要注意权限环境变量这些问题。

参考链接

参考链接1
参考链接2
参考链接3