Gitlab-CI持续集成之Runner配置和CI脚本

 

 

 

 

Gitlab-CI持续集成之Runner配置和CI脚本

1、简介

1. 为实现持续集成，需为该项目准备如下两样东西：

1）软件集成脚本.（gitlab-ci.yml）

2）一台Runner服务器

固然，考虑到集成环境的配置，还须要docker镜像做为载体。

2. 基本流程以下：

1）安装Runner服务器，注册和项目对应的Runner Service（后续再说Shared Runner），编写集成脚本；

2） 每当push代码， 自动触发脚本，Gitlab将变更告知Gitlab-CI，CI链接Runner服务器，找到关联的Runner Service，Runner负责更新代码到本地，并执行集成脚本。

2、安装Runner

1. Centos7使用yum安装

1）添加yum源

a.官方源

1 curl –L https://package.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

b.国内源

cat << EOF >> /etc/yum.repos.d/gitlab-ci-multirunner.repo

[gitlab-ci-multi-runner]

name=gitlab-ci-multi-runner

baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7

repo_gpgcheck=0

gpgcheck=0

enabled=1

gpgkey=https://packages.gitlab.com/gpg.key

EOF

sudo yum makecache

2）安装1.11.2版本

sudo yum install gitlab-ci-multi-runner-1.11.2-1

  因为公司Gitlab版本目前是8.X,官方Gitlab最新是9.0，Runner最新版不支持9.0如下版本的Gitlab，所以只能安装该版本。视Gitlab服务器的版本而定。

3）Runner用户权限

Runner默认会在服务器上建立gitlab-runner用户， 全部的Runner Service则默认经过该用户执行集成脚本，所以该用户须要较高的权限。尤为是使用Docker镜像时，必须加入docker组。

 

sudo usermod -aG docker gitlab-runner

2.Ubuntu使用apt-get安装

1）添加apt源

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash

2）安装1.11.2版本

 

sudo yum install gitlab-ci-multi-runner-1.11.2-1

3）Runner用户权限（同上）

3.安装包安装

下载二进制文件或相应系统的安装包安装便可，gitlab-ci-multi-runner-1.11.2安装包。

3、注册Runner

1.进入本身的Project—>设置Runners

 

 

2.查看Specific Runners里面的url和token

 

 

 

3.在Runner服务器执行注册命令

gitlab-runner register --non-interactive \

    --url http://gitlab.xxxxx.com/ci \

    --registration-token GWGGXZNxbxabcdMaXZhj9 \

    --name Crowd_Job_CI \

    --tag-list 172.17.3.126 \

    --run-untagged=true \

    --executor shell \

    --builds-dir /home/gitlab-runner \

   --config "/etc/gitlab-runner/config.toml"

上述命令选项含义( * 为必选项 ) ：

--url                  项目CI地址*

-- registration-token  项目里刚才看到的token，互相关联的标志*

--name                 该Special Runner服务名，便于后台管理（查看、删除、调用）*

--tag-list             该Special Runner标签，集成脚本中能够经过指定tag关联

--run-untagged         是否运行无标签的集成脚本，必须用等号

--excutor              规定集成脚本执行的环境，还能够是docker等*

-- builds-dir          默认该文件夹，能够自定义项目集成初始化的位置

--config               默认配置文件，存储注册信息，能够自定义不一样的配置文件

刷新页面看到已经注册成功，可使用了。

 

4、运行Runner

假设集成脚本已就绪，那么就须要运行Runner

1.使用Specific Runner

     1）run-single

gitlab-ci-multi-runner run-single \

--url http://gitlab.sensenets.com/ci

--token 37fe0fa59e3475e20e24b6e6afc7c3

--executor shell

固然这里也能够指定注册时的大部分参数，不过不管如何url、token（Runner的token，而非注册时项目的token）、executor这三个参数是必须的。

run-single命令很简单的把咱们刚才注册的Runner运行起来了，若是这个Runner对应的项目有更新，这个运行的服务就会去执行脚本内容。

即使咱们不运行run-single命令，默认会有一个已经运行状态的Runner Service，名称就是gitlab-runner，会自动执行全部注册过的Runner，但同时只能执行一个任务。

 

2）run 、install、start

 

     上图说明了Runner的原理：

     安装gitlab-ci-multi-runner服务器，至关于一个劳务公司的创办，它管理Runner工人，外包各类项目Project。

注册的目的是把项目和Runner链接起来，由于部分项目的Runner可能须要定制。Runner比如是一个工人，在劳务中心（gitlab-ci-multi-runner）登记合同，供职于咱们的Project（可是当他比较闲的时候，也能够去其余公司兼职）。

可是对应的RunnerService至关于Runner工人的管理层，一个管理层能够管理一个甚至多个工人。劳务公司默认有一个公用的管理层，服务名就是上面所说的gitlab-runner，若是咱们不指定管理层，那么劳务公司全部工人都被gitlab-runner管理运行。这个管理人员比较弱，一次只能管理一个项目，其余项目会等待。

run、run-sigle至关于一次性的外包项目，很是具备针对性。

install则是把一个或者几个runner包装好，而后start，就是一个有着管理服务的工人体系，随时待命。

当Project更新，触发Runner服务器上的Runner Service（某管理队伍），Runner Service根据本身的配置信息，和项目的需求（tag指定某个工人），派遣Runner工人去执行Project给予的任务（Job）。

配置信息至关于花名册，不注册仅仅写一个花名册是不行的，working_dir至关于办公地点。

下面安装两个服务并启动：

gitlab-runner install \

    -n  "jiukun_self_runner" \

    -d "/home/jiukunz" \

    -c "/etc/gitlab-runner/config_jiukun_test.toml" \

    -u gitlab-runner

gitlab-runner install \

    -n  "jiukun_self2_runner" \

    -d "/home/jiukunz" \

    -c "/etc/gitlab-runner/config_jiukun_test.toml" \

    -u gitlab-runner

 

1 gitlab-runner start -n jiukun_self_runner
2 gitlab-runner start -n jiukun_self2_runner

 

 

其中，-n为安装的服务名称，-d为工做路径，-c为配置文件，-u为执行用户（服务名称和执行用户必须指定，配置文件和工做路径可使用默认路径）

 

     其实，当咱们执行上述安装命令时，gitlab-ci-multi-runner后台实际是将run命令写入/etc/systemd/system/jiukun_self_runner.service文件，使之成为一个单独的服务：

 

2.使用Shared Runner

     使用share runner须要管理员权限，联系公司gitlab管理员，获取token。而后使用和Special Runner同样的方法注册成功。

     进入任意项目的Runner页面，将看到如下内容：

 

 

 

     这里我重复注册了两次，能够看到Runner不管是名字仍是tag均可以重复，可是Runner的token却不相同，实际上区分不一样的Runner工人只须要两样东西就是url和token。固然并不建议进行相同命名，不便于管理。

     公司全部的项目默认均可以使用Shared Runner，而不须要重复配置。

1）好处：对于大多数Runner的配置实际上是彻底相同的（一样的executor，一样的配置文件和工做路径，一样的依赖环境），若是每一个项目都去一个个注册不只麻烦，并且不方便迁移，这时可使用shared runner。

2）不足：若是一个项目的编译所需的exector等其余配置（配置文件有更多可选配置），而且和其余项目须要单独管理，这时最好使用Special Runner，并锁定该Runner为项目自己使用，单独管理。

 

5、管理Runner

1.注册的runner列表

gitlab-runner list \
    --config "/etc/gitlab-runner/config_jiukun_test.toml"

2.查看runner链接状态

gitlab-runner verify \
    --config "/etc/gitlab-runner/config_jiukun_test.toml"

3.取消注册（移除）

gitlab-runner unregistry \
    --url http://gitlab.xxxxxx.com/ci \
    --token 9c1bb50065661ba766023016f6ebf2

     不能直接在project的web端进行remove操做，不然这里会执行失败

4管理gitlab-runner服务

gitlab-runner status \

    -n jiukun_self_runner.service

    不指定服务名，则默认为gitlab-runner服务

gitlab-runner stop \

    -n jiukun_self_runner.service

gitlab-runner restart \

    -n jiukun_self_runner.service

gitlab-runner uninstall \

    -n jiukun_self_runner.service

执行uninstall会卸载该服务，与之对应的runner将没法经过该服务运行，请确保对应的CI任务已中止。

6、集成脚本

     将集成脚本命名为.gitlab-ci.yml或者.gitlab-ci.yaml，放置在对应项目仓库分支的根目录下。

 

1.  yaml语法

大小写敏感、使用缩进表明层级、不容许使用Tab缩进，只能使用空格，缩进并没有统一限制，但同级关系内要保持对齐便可。#表明注释。

语言格式里存在减号和冒号这些特殊字符，所以要注意千万别写成中文的字符格式。

减号对应的是数组，冒号对应的是键值对（对象）。

2. 关键词

     1）image

若是使用docker做为Runner的executor，而且没有设置默认的镜像，此处须要设置镜像；不使用能够省略

2）sevices

若是使用docker集群服务，能够直接调用服务；不使用能够省略

3）stages

定义各个阶段名称，若是省略，CI默认为三个阶段

每一个job都必须定义其所属的阶段，若是不定义，默认均属于build阶段；同阶段任务并行对待，上一阶段全部任务执行成功，才会继续执行下一阶段；语句依次执行，若是某一语句执行失败，将返回错误码，并宣告CI失败。

若是定义stages，则job中的stage必须与之相对应。

4）before_script

           定义在全部脚本运行以前执行的语句

5）after_script

           定义在全部脚本运行以后执行的语句

     6）variables

     定义环境变量

     7）cache

     定义下个job会使用到的文件或内容

3. Jobs

     .gitlab-ci.yml脚本内容的主体为一个个job，没有数量限制，每一个Job名称能够相同也能够不一样（最好不要相同），能够大小写；每一个Job内部至少有一个关键词。经常使用关键词以下

     1）stage

     和脚本全局stages对应（若是全局未定义，可以使用默认）

     2）image、services、variables

     同全局关键词

     3）only

     规定该脚本响应分支（项目其余分支不会触发该脚本；若是不定义，会检测全部分支；与之相反的关键词是except）

     4）before_script、after_script

     同全局关键词（注意，若是同时存在，会覆盖全局关键词对应列表内容）

     5）script

     脚本主体，使用方法和在shell内同样，将在对应executor内运行一个shell环境，执行脚本内容。每一个Job的shell环境不一样（Job结束，该环境自动关闭）。

     6）tags

     指定Runner的标签（一般一个项目有不少Runner，依靠tag区分）

     7）artifacts

     指定Job的产出文件路径，若是该关键词设定，能够直接在pipeline页面下载该文件

     8）when

     默认一个job只有在上一阶段全部job成功才会执行，经过when能够改，一般用来清理环境使用，以避免失败后没法清理，有四种可选参数。

      on_success（上一阶段全部Job成功才执行）    

      on_failure（上一阶段任意Job失败就执行）

      always（老是执行）                          

      manual（此阶段由UI界面交互执行）

 

备注：以上纯属原创，学习来源为gitlab-runner官方中文文档、gitlab-runner英文文档、gitlab-ci英文文档。如需转载请注明出处，后续继续完善。