gitlab CI && Runners使用

要了解GitLab-CI与GitLab Runner，我们得先了解持续集成是什么。

一、持续集成（Continuous Integration）

软件集成:软件开发过程中的一个环节，包括以下流程：合并代码---->安装依赖---->编译---->测试---->发布

持续集成是一种软件开发实践，频繁地（一天多次）将代码集成到主干。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。从而大大减少集成的问题，让团队能够更快的开发内聚的软件。

软件集成的工作细碎繁琐，以前是由人工完成的。但是现在鼓励持续集成，那岂不是要累死人，还影响开发效率。所以，应该考虑将软件集成这个工作自动化，这就出现了所谓的持续集成系统。

持续交付、持续部署的概念

持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

image

持续集成的原则

业界普遍认同的持续集成的原则包括：

• 需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 git、svn 等；

• 开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；

• 需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；

• 必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。

持续集成系统的组成

一个完整的构建系统必须包括：

• 一个自动构建过程，包括自动编译、分发、部署和测试等。

• 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。

• 一个持续集成服务器。

二、GitLab-CI

image

GitLab CI是 GitLab 提供的持续集成服务，只要在你的仓库根目录 创建一个.gitlab-ci.yml 文件， 并为该项目指派一个Runner，当有合并请求或者 push的时候就会触发build。

这个.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。 默认有3个[stages(阶段)]: build、test、deploy。

当build完成后(返回非零值)，你会看到push的 commit或者合并请求前面出现一个绿色的对号。 这个功能很方便的让你检查出来合并请求是否会导致build失败， 免的你去检查代码。

大部分项目用GitLab's CI服务跑build测试， 开发者会很快得到反馈，知道自己是否写出了BUG。

所以简单的说，要让CI工作可总结为以下几点:

• 在仓库根目录创建一个名为.gitlab-ci.yml 的文件

• 为该项目配置一个Runner

完成上面的步骤后，每次push代码到Git仓库， Runner就会自动开始pipeline。

基于Gitlab CI快速搭建持续集成环境

• 开启 Gitlab CI 功能

• 项目 Gitlab CI 配置

• 配置一个 Runner

• 创建并配置.gitlab-ci.yml

• 推送构建配置文件

• 查看可视化的构建过程

启用构建邮件通知

三、GitLab-Runner

Gitlab-runner是.gitlab-ci.yml脚本的运行器，Gitlab-runner是基于Gitlab-CI的API进行构建的相互隔离的机器（或虚拟机）。GitLab Runner 不需要和Gitlab安装在同一台机器上，但是考虑到GitLab Runner的资源消耗问题和安全问题，也不建议这两者安装在同一台机器上。

Gitlab Runner分为两种，Shared runners和Specific runners。

Specific runners只能被指定的项目使用，Shared runners则可以运行所有开启 Allow shared runners选项的项目

目的：来自动化地完成一些软件集成工作。

想问为什么不是 GitLab CI 来运行那些构建任务？

一般来说，构建任务都会占用很多的系统资源 (譬如编译代码)，而 GitLab CI 又是 GitLab 的一部分，如果由 GitLab CI 来运行构建任务的话，在执行构建任务的时候，GitLab 的性能会大幅下降。

GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做拉！

因为 GitLab Runner 可以安装到不同的机器上，所以在构建任务运行期间并不会影响到 GitLab 的性能~

例如：当一个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

如下图所示：

image

四、注册gitlab runner

什么情况下需要注册Shared Runner？

1. 比如，GitLab上面所有的工程都有可能需要在公司的服务器上进行编译、测试、部署等工作，这个时候注册一个Shared Runner供所有工程使用就很合适。

什么情况下需要注册Specific Runner？

1. 比如，我可能需要在我个人的电脑或者服务器上自动构建我参与的某个工程，这个时候注册一个Specific Runner就很合适。

什么情况下需要在同一台机器上注册多个Runner？

1. 比如，我是GitLab的普通用户，没有管理员权限，我同时参与多个项目，那我就需要为我的所有项目都注册一个Specific Runner，这个时候就需要在同一台机器上注册多个Runner。

注册gitlab runner的前提：

• 安装 Runner 建议不要和 GitLab 服务端安装在同一台服务器。

• 获取 token 通过 GitLab 接口 注册为共享 Runner 或者特定 Runner

在 GNU/Linux 系统上注册 Runner:

运行下面命令启动注册程序:

$ gitlab-runner register

# 输入 GitLab 实例 URL::[查看地址setting 》CI/CD 》 Runners settings ]

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

# 输入获取到的用于注册 Runner 的 token:[查看地址setting 》CI/CD 》 Runners settings ]

Please enter the gitlab-ci token for this runner
xxx

# 输入该 Runner 的描述，稍后也可通过 GitLab's UI 修改:

Please enter the gitlab-ci description for this runner
[hostame] xxx

# [给该 Runner 指派 tags](https://docs.gitlab.com.cn/ce/ci/runners/#using-tags), 稍后也可以在 GitLab's UI 修改: 【tags需要定义，不同的job可以通过tag跑不同的runner】

Please enter the gitlab-ci tags for this runner (comma separated):
IDG-mamidian

#选择 Runner 是否接收[未指定 tags](https://docs.gitlab.com.cn/ce/ci/runners/#using-tags) 的任务（默认值：false）， 稍后可以在 GitLab's UI 修改：

Whether to run untagged jobs [true/false]:
[false]: false

# 选择是否为当前项目锁定该 Runner， 之后也可以在 GitLab's UI 修改。 该功能通常用于被指定为某个项目的 Runner （默认值：true）：

Whether to lock Runner to current project [true/false]:
[true]: true

# 选择 [Runner executor](https://docs.gitlab.com.cn/runner/executors/README.html):

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

# 如果你选择 Docker 作为你的 executor，注册程序会让你设置一个默认的镜像， 作用于 .gitlab-ci.yml 中未指定镜像的项目：

Please enter the Docker image (eg. ruby:2.1):
alpine:latest

# 注册成功后可在项目页面 》settings 》CI/CD 》Runner setting下看到相关配置，并可一修改runner配置

注意：Tags必填且要唯一

五 gitlab-ci.yml配置

https://segmentfault.com/a/1190000010442764

六、运行构建好的CI任务部署上线

第一次执行runner遇到的问题：

1、npm install [私有源]源没有，多麦私有组件无法安装

befort_script:
nrm -v
nrm ls
nrm add  [私有源]

image

文献：

Gitlab CI yaml官方配置文件