gitlab 的 CI/CD

gitlab-ci 有几个概念我们需要先了解下:

Pipline

Pipline 表示 gitlab 的构建流程,gitlab 触发一次 Pipline 就相当于是触发一次构建流程,构建流程可以包括很多,如:下载安装依赖,编译文件,运行测试用例,部署上线等。gitlab 上的每一次提交代码(commit)或者合并代码(merge request)都是可以触发Pipline。

Stages

构建流程是由多个阶段构成组成的,而Stages 则 定义了一个构建流程的每个阶段性构建,Stages有以下特点:

  • stage 是按顺序执行的,即上一个 stage 构建完毕,下一个 stage 才能开始
  • 所有 stage 都执行成功,这次的 Pipline 才算构建成功
  • 任何一个 stage 失败了,都会终止整个构建,并标记这次构建为失败

Jobs

一个阶段构建包含多个构建任务,Jobs 则表示构建任务。因此我们可以在一个 Stage 里面定义多个 Job ,Job有以下特点:

  • 同一个 stage 里面的 job 是并行执行的
  • 一个 stage 里所有的 job 都成功才代表这个 stage 执行成功,否则就代表失败

gitlab-runner 简介

gitlab 虽然有 CI/CD 的入口,但是本身并没有集成任务构建的执行器,真正执行任务构建的是 gitlab-runner 。可以说gitlab是通过接口服务使用 gitlab-runner 来执行 .gitlab-ci.yml 中定义的构建任务,这种方式可以使得 gitlab-runner 的运行不会影响 gitlab 的性能。

runner有两种:

  • 共享runner

    共享runner是整个gitlab项目都能使用的,需要gitlab管理员权限搭建

  • 指定的runner

    指定的runner是为某个特定项目搭建的runner,只需要项目管理员权限就能搭建

gitlab-runner 安装

服务器环境:centos x86-64

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 下载 64 位 gitlab-runner 安装包
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# 赋予执行的权限
sudo chmod +x /usr/local/bin/gitlab-runner

# 创建 gitlab-ci 的使用用户
sudo useradd --comment 'Gitlab Runner' --create-home gitlab-runner --shell /bin/bash

# 指定用户与工作控件安装gitlab-runner
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

# 启动 gitlab-runner
sudo gitlab-runner start

注册 gitlab-runner

注册一个runner,运行下面的命令并根据提示填写信息即可。

1
2
3
4
# 手动安装的使用下面命令运行
gitlab-runner register

# docker 安装的使用下面命令运行

运行注册命令后,依次根据提示填写信息:

  • 填写你的 gitlab 地址

    1
    2
    3
    Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ):

    https://xxx.gitlab.com
  • 填写项目的runner注册码

    注册码可以在项目的设置菜单下的 CI/CD 页面下的 Runners settings 下找到

    1
    2
    3
    Please enter the gitlab-ci token for this runner:

    xxx
  • 输入runner的描述

    1
    2
    3
    Please enter the gitlab-ci description for this runner:

    my-runner
  • 输入runner的标签,该标签是和 .gitlab-ci.yml 文件的标签属性相关联的

    1
    2
    3
    Please enter the gitlab-ci tags for this runner (comma separated):

    my-tag,another-tag
  • 输入runner的运行环境,这里可以根据需要选择

    1
    2
    3
    Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:

    shell
  • 如果是选择docker作为运行环境,会提示为项目添加一个默认的镜像

    1
    2
    3
    4
    Please enter the Docker image (eg. ruby:2.1):

    # 像部署前端页面,一般都会用到 nodejs 来进行打包,那么就可以把 nodejs 作为默认镜像了
    nodejs
  • 注册成功后执行重新运行命令即可链接上新注册的runner

    1
    gitlab-runner start

gitlab-ci 配置文件

gitlab-ci 默认使用项目根目录下的 .gitlab-ci.yml 文件作为配置文件(可以在 CI/CD Settings 页面下修改配置文件路径)。.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
stages:
- prebuild
- build
- deploy

# job list
prebuild_job:
stage: prebuild
only:
- develop
tags:
- dev
script:
- echo "prebuild_job"

build_job:
stage: build
only:
- develop
tags:
- dev
script:
- echo "build_job"

deploy_job:
stage: deploy
only:
- develop
tags:
- dev
script:
- echo "deploy_job"
  • stages 定义了3个构建阶段,分别是 prebuild , build , deploy ,并且这三个构建阶段是按照定义的顺序依次执行的。定义 stages 是需要在全局属性下定义的

  • jobs 是定义在文件全局属性下的。上面的配置文件就定义了 prebuild_jobbuild_jobdeploy_job 这三个任务,每个任务的名称需要是唯一的。并且有部分保留字段是不能作为任务的名称,如上面的 stages ,这些保留字段都有各自的用处

  • 一个任务都是通过定义一系列参数来定义自己的行为,如上面的几个任务,我们定义了以下几个参数来决定该任务的行为:

    • stage:定义了该任务是在哪个构建阶段执行的,如:prebuild_job 任务是定义在 prebuild 阶段执行的
    • only:定义了该任务是运行在项目的哪个分支和标签上,如:prebuild_job 任务是运行在 develop 分支上
    • tag:一个项目是可以注册多个 runner 的,tag 则定义了该任务是运行在哪个 runner 下面,如:prebuild_job 任务是定义在具有 dev 标签的 runner 下运行的
    • script:定义了该任务在 runner 下需要执行的脚本,如:prebuild_job 任务需要执行 echo "prebuild_job" 这个脚本

.gitlab-ci.yml 的详细配置信息可以查看文档:https://docs.gitlab.com/ee/ci/yaml/README.html