Gitlab CI-2.CI流程

参考文档：

1. GitLab Documentation：https://docs.gitlab.com/ce/
2. Installation and Configuration using omnibus package：https://docs.gitlab.com/omnibus/README.html#installation-and-configuration-using-omnibus-package
3. Configuration of your jobs with .gitlab-ci.yml：https://docs.gitlab.com/ce/ci/yaml/README.html
4. Gitlab Community Edition 镜像：https://mirrors.tuna.tsinghua.edu.cn/help/gitlab-ce/
5. Gitlab Runner：https://docs.gitlab.com/runner/
6. GitLab Continuous Integration：https://docs.gitlab.com/ce/ci/
7. 基于OpenSSL自建CA和颁发SSL证书：http://seanlook.com/2015/01/18/openssl-self-sign-ca/

三．Gitlab CI流程

1. Gitlab-CI流程

1. 在项目repository根目录下设置".gitlab-ci.yml"文件，定义pipeline中的stage，job等具体行为（what to do）;
2. 设置runner服务器（开发或生产环境），并将runner注册到对应的project（where to do）；
3. commit或push时，gitlab触发CI pipeline（trigger，主动检测".gitlab-ci.yml"）；
4. runner从gitlab pull代码，按".gitlab-ci.yml"定义执行脚本；
5. 返回结果。

2. 相关概念

1）pipeline

合并分支或代码提交即触发一次pipeline，一次pipeline即一次构建任务。

2）stage

stage即上述构建任务中的各个构建阶段，如test，build，deploy等；一个pipeline可以定义多个stage。

stage特点：

1. 所有的stage按顺序运行，前一个stage完成后，下一个stage才会开始执行；
2. 只有当所有的stage都完成后，该构建任务(pipeline)才会成功；
3. 如果一个stage失败，那么下一个stage不会执行，该构建任务(pipeline)失败。

3）job

job是每个stage构建阶段里具体执行的工作，stage与job是一对多的关系（同pipeline与stage），即一个stage里可以定义多个job。

job特点：

1. 同一个stage中的jobs并行执行；
2. 同一个stage中的jobs都执行成功时，该stage才会成功；
3. 如果任何一个job失败，那么该stage失败，即该构建任务 (pipeline) 失败。

4）GitLab runner

GitLab runner是pipeline/job的具体执行者。

四．Gitlab-CI流程验证

1. 安装gitlab-ce

1）安装runner-repo

# gitlab-runner，使用国内镜像源；
# 另外gitlab-runner 10之前，可执行文件名称为gitlab-ci-multi-runner
[root@gitlab-runner ~]# vim /etc/yum.repos.d/gitlab-runner.repo
[gitlab-runner]
name=gitlab-runner
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-runner/yum/el7
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packages.gitlab.com/gpg.key

2）安装gitlab-runner

# 安装gitlab-runner时会创建gitlab-runner账号，后续不少操作主体即gitlab-runner账号，需要注意权限问题
[root@gitlab-runner ~]# yum makecache
[root@gitlab-runner ~]# yum install gitlab-runner -y

2. gitlab-runner注册

1）注册gitlab-runner

# gitlab-runner分shared runner，specific runner，group runner等，这里注册为specific runner；
# --tls-ca-file：由于采用了自签名的ca证书，gitlab-runner注册时，需要使用ca根证书验证gitlab服务，注意提前创建/etc/gitlab-runner/certs/目录，并上传ca根证书；
# -n：gitlab-runner注册时，可采用--interactive或--non-interactive方式，-n即--non-interactive方式；
# --url：注册地址获取方式，登陆gitlab，进入对应project，Setting-->CI/CD-->Runner(Expand) -->Setup a specific Runner manually，即可查看；
# --registration-token：每个project有唯一的token，获取方式同上；
# --name：runner名称，非必须项，建议区分；
# --tag-list：注册的runner对某分支（branch）有效，多分支时用”,”区分，非必须项，建议区分；
# --executor：在不同场景下构建（build）的执行器，常用的有shell与docker等；
# --locked：锁定runner只能被当前project所用，默认即true；
# --run-untagged：在--tag-list为空时，默认值为true；在--tag-list不为空时，默认值为false；
# runner注册成功后即运行
[root@gitlab-runner ~]# gitlab-runner register --tls-ca-file /etc/gitlab-runner/certs/ca.crt -n \
 --url https://gitlab.netonline.com/ \
 --registration-token xJBn7PkKSAYmsPE-pHQK \
 --name gitlabrunner \
 --tag-list master \
 --executor shell \
 --locked true \
 --run-untagged false

2）查看gitlab-runner

# 注册成功后，在runner服务器上生成config.toml文件，记录注册信息；
# 如果gitlab-runner以root身份执行，生成/etc/gitlab-runner/config.toml；
# 如果gitlab-runner以non-root身份执行，生成~/.gitlab-runner/config.toml；
# 通过命令”ps aux | grep gitlab-runner”即可查看执行身份，config文件以及runner用户
[root@gitlab-runner ~]# ps aux | grep gitlab-runner

# concurrent：全局参数，可运行job的限制，”0”表示不限制；此值是自动生成，如果在1台服务器注册多个runner，值也会自动更新；
# check_interval：全局参数，在多runner的情况，每runner向gitlab发起请求的间隔时间，默认值3s，如果设置为”0”或更低，使用默认值；
# [[runner]]：runner相关的设置在特定section中
[root@gitlab-runner ~]# cat /etc/gitlab-runner/config.toml

通过gitlab portal查看：登陆gitlab，进入对应project，Setting-->CI/CD-->Runner(Expand) -->Setup a specific Runner manually，即可查看，如下：

3. 配置.gitlab-ci.yml

# 以一个简单的shell脚本执行为例，在.gitlab-ci.yml中定义执行脚本，需要注意yaml文件的格式；
# .gitlab-ci.yml位于repository的根目录
[root@gitlab-runner ~]# cd ~/gitlab/
[root@gitlab-runner gitlab]# vim .gitlab-ci.yml
# stage：定义pipeline的执行顺序，阶段名也可自定义，但不能与默认的”test”，“build”，“deploy”等冲突；
# stage为可选项，如果job无执行顺序要求即可取消
stages:
  - test
  - build

# job名可自定义；
# 如果定义了stage，job中可声明stage的阶段；
# tag：声明触发的分支，如果不指定，默认无法触发CI流程；但可开启已注册runner的”Run untagged jobs”参数使无tag的job可触发流程；
# script：定义具体的任务，这里需要注意执行任务的主体的权限；
# 如在某阶段多分支执行相同的job，但在其他阶段需要根据分支不同执行不同的job时，可采用only字段区分分支；
# 更多关键字段可查看：https://docs.gitlab.com/ce/ci/yaml/README.html
job_1:
  stage: test
  tags:
    - master
  script:
    - whoami
    - pwd

job_2:
  stage: build
  tags:
    - master
  script:
    - touch ci.txt

4. 触发CI流程

# 提交.gitlab-ci.yml到gitlab对应repository；
# 第一次push时，带上-u参数，如：git push -u orogin master；
[root@gitlab-runner gitlab]# git add .
[root@gitlab-runner gitlab]# git commit -m "commit .gitlab-ci.yml"
[root@gitlab-runner gitlab]# git push -u origin master

5. 查看执行结果

1）pipelins

通过gitlab portal查看：登陆gitlab，进入对应project，CI/CD-->Pipelines，如下：

2）job

点击pipelie的status，这里即"passed"（也有"failed"，"pending"等状态），进入具体pipeline详情页面（或：登陆gitlab，进入对应project，CI/CD-->Jobs，即可查看），点击对应的job，即可查看job的执行返回结果，如下：

Job_1

从job的返回结果得到以下信息：

1. 执行器是shell；
2. 执行者从gitlab repository拉取代码，存放在执行者home目录下，具体路径为~/builds/RUNNER-TOEKN/X/GITLAB-USER/PROJECT-NAME/目录下；
3. 执行者是gitlab-runner账号（涉及到执行权限问题）

Job_2

6. docker executor

以下为设置docker executor的简单介绍，CI流程不再演示。

1）以container的形式运行gitlab-runner

采用docker executor的模式不是一定需要在gitlab-runner container中注册，也可在宿主机中注册，这里只是演示另一种启动gitlab-runner服务的可能性。

# 因验证用的gitlab域名无法被dns解析，将本地/etc/hosts文件映射到容器内；
# 映射自签名的ca根证书，注册时需要；
# 将注册生成的config.toml文件映射到宿主机，便于修改参数；
# 将docker daemon的sock映射到容器中，container可以利用宿主机docker来创建container
[root@gitlab-runner ~]# docker run -d --name gitlabrunner \
 --restart=always \
 -v /etc/hosts:/etc/hosts \
 -v /etc/gitlab-runner/certs/ca.crt:/etc/gitlab-runner/certs/ca.crt \
 -v /srv/gitlab-runner/gitlabrunner/config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:latest

# 查看
[root@gitlab-runner ~]# docker ps

2）注册docker executor

# 虽然executor container是由gitlab-runner container创建的，但其与运行gitlab-runner服务的container是同等关系而非从属关系；
# 使用container做executor，使得每一个pipeline的虚拟构建环境都干净、轻量，相互隔离，互不影响；
# executor设置为docker时，定义executor的镜像为：docker:stable，为官方推荐，此镜像集成了docker客户端；
# 如果job是构建镜像，则executor必须使用具备docker客户端的镜像；
# docker socket binding模式：通过参数”--docker-volumes /var/run/docker.sock:/var/run/docker.sock”实现，将docker daemon的sock映射到容器中，container可以利用宿主机docker来创建container，
# 如果是在宿主机中注册，也可以使用”--docker-privileged”（docker-in-docker executor模式，如果需要编译构建镜像，需要在.gitlab-ci.yml中使用docker:dind services，并通过变量指定docker daemon的tcp端口）代替docker socket binding模式；
# 两种模式在config.toml文件中均有体现，个人建议docker socket binding模式
[root@gitlab-runner ~]# docker exec -it gitlabrunner \
 gitlab-runner register --tls-ca-file /etc/gitlab-runner/certs/ca.crt -n \
 --url https://gitlab.netonline.com/ \
 --tag-list "dev" \
 --registration-token xJBn7PkKSAYmsPE-pHQK \
 --name gitlabrunnerdev \
 --executor docker \
 --docker-image docker:stable \
 --docker-volumes /etc/hosts:/etc/hosts \
 --docker-volumes /var/run/docker.sock:/var/run/docker.sock

3）查看config.toml

[root@gitlab-runner ~]# cat /srv/gitlab-runner/gitlabrunner/config/config.toml