知乎:zhuanlan.zhihu.com/p/80438837作者:Charl
GitLab CI 工作流程
- Gitlab CI 基本概念
在介绍 Gitlab CI 之前,首先简单介绍一下 Gitlab CI 里的一些基本概念,具体如下:
- Pipeline:Gitlab CI 里的流水线,每一次代码的提交触发 Gitlab CI 都会产生一个 Pipeline。
- Stage:每个 Pipeline 由多个 Stage 组成, 并且每个 Stage 是有先后顺序的。
- Job:Gitlab CI里的最小任务单元,负责完成具有一件事情,例如编译,测试,构建镜像等。每个Job都需要指定 Stage ,所以Job的执行顺序可以通过制定不同的 Stage 来实现。
- GitLab Runner:是具体执行 Job 的环境,每个 runner 在同一时间只能执行一个 Job 。
- Executor:每个 Runner 在向gitlab注册的时候需要指定 Executor,来决定通过何种类型的执行器来完成 Job。
2. Gitlab CI 的工作流程
当有代码 push 到 GitLab 时,就会触发一个 Pipeline。然后进行编译,测试和镜像构建等操作等操作,其中每一步操作都为一个 Job。在 CD 阶段,会将 CI 阶段构建出来的结果根据情况部署到测试环境或生产环境。
Gitlab Runner介绍
- Gitlab Runner 分类
GitLab 中有三种类型的 Runner ,分别为
- shared:所有项目使用
- group:group下项目使用
- specific:指定项目使用
我们可以根据需要向 gitlab 注册不同类型的 Runner,注册的方式是相同的。
2. Gitlab Runner工作过程
Runner 首先会向 Gitlab 发起注册请求,请求内容中包含 token、tag 等信息,注册成功后 GitLab 会向 Runner 返回一个 token,后续的请求,Runner 都会携带这个请求。
注册成功后,Runner 就会不停的向 GitLab 请求 Job,时间间隔是 3s。若没有请求到 Job,GitLab 返回 204 No Content。如果请求到 Job,GitLab 会把 Job 信息返回回来,Runner 在接收到 Job 之后,会向 GitLab 发送一个确认请求,同时更新任务的状态。之后,Runner 开始 Job 的执行, 并且会定时地将中间数据,以 Patch 请求的方式发送给 Gitlab。
3. Gitlab Runner 的 Executor
Runner 在实际执行 Job 时,是通过调用 Executor 来完成的。Runner 在注册时提供了 ssh、shell、docker、docker-ssh、virtualbox、kubernates 等不同类型的 Executor 来满足不同的场景和需求。
其中我们常用的有 shell 和 docker 等 Executor,shell 类型主要是利用 Runner 所在主机的环境进行 Job的执行。而 docker 类型的 Executor 在每个 Job 开始时,拉取镜像生产一个容器,在容器里完成 Job,在 Job 完成后,对应的容器就会被销毁。由于docker 隔离性强、轻量且回收,我们在使用时选用 docker 类型的 Executor 去执行 Job,我们只要提前做好 Job 所需环境的 docker 镜像,在每个 Job 定义好 image 即可使用对应的环境,操作便捷。
Gitlab Runner 安装与配置
Docker 安装
由于我们需要使用 docker 类型的 Executor,所以需要在运行 Runnner 的服务器上先安装 docker,具体步骤如下(Centos 环境):
- 安装需要的软件包,yum-util 提供 yum-config-manager 功能,另外两个是 devicemapper 驱动依赖
yum install -y yum-utils device-mapper-persistent-data lvm2 2. 设置 yum 源
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo3. 安装 docker
yum install docker-ce -y 4. 启动并加入开机启动
systemctl start docker
systemctl enable dockerGitlab runner 安装与启动
执行下面的命令进行 gitlab runner 的安装和启动
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
sudo yum install gitlab-runner -y
gitlab-runner startGitlab runner 注册与配置更新
启动 gitlab runner 后还需要向Gitlab进行注册,在注册前需要从 gitlab 里查询 token。不同类型的 runner 对应的 token 获取的路径不同。shared Runner 需要 admin 权限的账号,按如下方式可以获取对应的 token。
其他两种类型在对应的页面下( group 或 project 主页)的 setting—>CI/CD—>Runner 可以获取到 token。
Runner 的注册方式分为交互式和非交互式两种。其中交互式注册方式,在输入 gitlab-runner register 命令后,按照提示输入注册所需要的信息,包括 gitlab url、token 和 Runner 名字等。这边个人比较推荐非交互式命令,可以事先准备好命令,完成一键注册,并且非交互式注册方式提供了更多的注册选项,可以满足更多样化的需求。
按如下示例即可完成一个 Runner 的注册:
gitlab-runner register --non-interactive \
--url "http://git.xxxx.cn" \
--registration-token "xxxxxxxxxxx" \
--executor "docker" \
--docker-image alpine:latest \
--description "base-runner-docker" \
--tag-list "base-runner" \
--run-untagged="true" \
--docker-privileged="true" \
--docker-pull-policy "if-not-present" \
--docker-volumes /etc/docker/daemon.json:/etc/docker/daemon.json \
--docker-volumes /etc/gitlab-runner/key/docker-config.json:/root/.docker/config.json \
--docker-volumes /etc/gitlab-runner/find_diff_files:/usr/bin/find_diff_files \
--docker-volumes /etc/gitlab-runner/key/id_rsa:/root/.ssh/id_rsa \
--docker-volumes /etc/gitlab-runner/key/test-kube-config:/root/.kube/config我们可以通过 --docker-pull-policy 指定 Executor 执行 Job 时 dokcer 镜像下载策略。 --docker-volumes 指定容器与宿主机(即 Runner 运行的服务器)的文件挂载映射关系。上面挂载的文件主要是用于 Runner 在执行 Job时,运用的一些 key,包括访问 gitlab、docker harbor 和 k8s 集群的 key。当然,如果还有其他文件需要共享给容器,可以通过 --docker-volumes 去指定。
/etc/docker/daemon.json 文件主要为了可以以 http 方式访问 docker horbor 所做的设置{ "insecure-registries" : ["http://docker.vpgame.cn"] }
完成注册后,重启 Runner 即可
gitlab-runner restart部署完成后,可以在 gitlab 的 web 管理界面查看到不同 Runner 的信息。
此外,如果一台服务需要注册多个 Runner ,可以修改 /etc/gitlab-runner/config.toml 中的 concurrent 值增加 Runner 的并发数,修改完之后同样需要重启 Runner。