一、什么是GitLab-CI
CI，Continuous Integration，持续集成，是软件开发过程中一个非常重要的环节，在互联网敏捷开发的过程中，持续集成通常用来进行日常编译和自动化测试，来保证及时发现提交的问题，避免影响项目进度。
通常持续集成的过程包括：
- 提交（合并）代码
- 编译
- 测试
- 发布
以前软件集成的工作是由人工完成的，但是现在鼓励持续集成，所以，应该考虑将软件集成这个工作自动化，这就出现了所谓的持续集成系统。
GitLab-CI就是一套配合GitLab使用的持续集成系统（当然，还有其它的持续集成系统，同样可以配合GitLab使用，比如Jenkins）。而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。配置好GitLab-CI后，能够快速验证每次提交的可用性。
二、GitLab-Runner 和 GitLab-CI
GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。
所以，GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下：Runner就像一个个的工人，而GitLab-CI就是这些工人的一个管理中心，所有工人都要在GitLab-CI里面登记注册，并且表明自己是为哪个工程服务的。当相应的工程发生变化时，GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示：
Runner类型
GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。
Shared Runner： 这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
Specific Runner： 这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。
我们后面的介绍所注册的runner都是Special Runner
三、.gitlab-ci.yml文件又是什么
.gitlab-ci.yml 用来配置GitLab-CI用你的项目做哪些操作，这个文件位于仓库的根目录，如果没有可以自己创建。
当有新内容push到仓库，或者有代码合并后，GitLab-CI会查找是否有 .gitlab-ci.yml文件，如果文件存在，GitLab-CI会依据文件内容通知某个Runner去执行.gitlab-ci.yml中定义的操作。
.gitlab-ci.yml 使用YAML语法， 你需要格外注意缩进格式，要用空格来缩进，不能用tabs来缩进。
.gitlab-ci.yml文件中的几个重要概念
Stages
Stages 表示构建阶段，说白了就是上面提到的流程。默认有3个stages：build, test, deploy。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：
- 所有
Stages会按照顺序运行，即当一个Stage完成后，下一个Stage才会开始 - 只有当所有
Stages完成后，该构建任务 (Pipeline) 才会成功 - 如果任何一个
Stage失败，那么后面的Stages不会执行，该构建任务 (Pipeline) 失败
Jobs
Jobs 表示构建工作，表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
1、相同 Stage 中的 Jobs 会并行执行
2、相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
3、如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败
文章后面附注了更多关键字的解释，详细了解关键字以及YAML语法可以自己查。
四、安装并注册GitLab-Runner
1.安装GitLab-Runner
之前我们说，runner就是一个工人，它在你的服务器上等待GitLab-CI给它派活，所以我们在服务器上安装GitLab-Runner。
安装环境：ubuntu
其他环境参考：https://docs.gitlab.com/runner/install
-
下载
sudo bash curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 -
添加权限
chmod +x /usr/local/bin/gitlab-runner -
新建gitlab-runner用户
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash -
安装
安装时需要指定我们上面新建的用户gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner -
启动
gitlab-runner start
2.获取注册信息
进入你的gitlab项目 ——> settings —— > CI/CD ——> Runners
这里需要记住4(URL)和5(token)
3.注册
-
运行注册
gitlab-runner register -
输入URL(你之前记住的URL)
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): -
输入token(你之前记住的token)
Please enter the gitlab-ci token for this runner: -
输入description（以后可以修改）
Please enter the gitlab-ci description for this runner: -
输入tag(以后可修改)
Please enter the gitlab-ci tags for this runner (comma separated): -
输入exector
Please enter the executor: docker, docker-ssh, shell, docker-ssh+machine, kubernetes, custom, parallels, ssh, virtualbox, docker+machine: docker这里决定你的运行平台，我们一般用docker（服务器需要安装docker，安装教程在第六节），然后回要求你输入要使用的docker image,你可以用已有的image，也可以用自己维护的image。
Please enter the default Docker image (e.g. ruby:2.6):到这里，Runner就注册好了，返回你的gitlab页面，在settings —— > CI/CD ——> Runners就可以看到你注册的Runner。
4. 设置（可选）
如果注册过程中设置了tag，那么需要在这里设置一下，让.gitlab-ci.yml的job没有tag也可以运行。
点击编辑
勾选没有tag可运行
五、编写.gitlab-ci.yml文件
- 在你项目根目录下创建文件：.gitlab-ci.yml
示例程序：
stages:
- build
- test
- deploy
build_maven:
stage: build
script:
- echo "build maven....."
- echo "mvn clean"
- echo "done"
test_springboot:
stage: test
script:
- echo "run java test....."
- echo "java -test"
- echo "done"
deploy_springboot:
stage: deploy
script:
- echo "deploy springboot...."
- echo "run mvn install"
- echo "done"
script是你要执行的命令
-
当你项目push到gitlab中之后，在CI/CD ——> pipelines 中即可看到效果
![在这里插入图片描述]()
-
点击stage可以查看实际执行结果
![在这里插入图片描述]()
六、 docker安装
-
开始安装
由于apt官方库里的docker版本可能比较旧，所以先卸载可能存在的旧版本：$ sudo apt-get remove docker docker-engine docker-ce docker.io更新apt包索引：
$ sudo apt-get update安装以下包以使apt可以通过HTTPS使用存储库（repository）：
$ sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common添加Docker官方的GPG密钥：
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -使用下面的命令来设置stable存储库：
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"再更新一下apt包索引：
$ sudo apt-get update安装最新版本的Docker CE：
$ sudo apt-get install -y docker-ce验证docker -
查看docker服务是否启动：
$ systemctl status docker
docker 使用参考：https://www.runoob.com/docker/docker-container-usage.html
如果你在执行docker命令时，每次都需要sudo，可以执行下面的几行命令
sudo groupadd docker #添加docker用户组
sudo gpasswd -a $USER docker #将登陆用户加入到docker用户组中
newgrp docker #更新用户组
docker ps #测试docker命令是否可以使用sudo正常使用
七、问题
1.不安装runner可以验证每次提交的可用性吗？
可以是可以的，只要你在根目录添加了.gitlab-ci.yml文件，就可以执行一些简单的验证，这种情况使用的平台是docker+machine，也可以直接在yml文件中指定docker image，看起来这样完全可以满足需求，但是不在服务器注册runner，你的每个阶段进行的检测都会很慢，因为每次都需要pull image，其次，这种情况下，你只有一个runner可用，并不是很方便。所以还是老老实实注册runner吧！！！
后续有新的要求，持续更新！
附录一：.gitlab-ci.yml关键字
script 由Runner执行的Shell脚本。
image 使用docker镜像， image：name
service 使用docker services镜像, services：name
before_script 执行作业前运行的脚本
after_script 作业完成后运行的脚本
stages 定义管道中的步骤，依次运行
stage 定义管道中步骤的作业段
only 指定作业限制only:refs，only:kubernetes，only:variables，和only:changes
tags 指定执行作业的runner
allow_failure 允许job失败
when 什么时候开始工作，
on_success 只有当前一个阶段的所有工作都成功时才执行工作 。这是默认值。
on_failure 仅当前一阶段的至少一个作业失败时才执行作业。
always 无论先前阶段的工作状态如何，都可以执行工作。
manual 手动执行作业
delayed 延迟作业。最长可延迟1小时。
environment 作业部署到的环境名称
cache 启用缓存
artifacts job成功时附加到作业的文件或目录
dependencies 此job依赖其他jobz,主要作用于作业优先级
converage 给定作业代码覆盖率设置
retry 在发生故障时，可以自动重试作业的次数。
parallel 应该并行运行多少个作业实例
trigger 定义下游管道触发器
include 允许此作业包含外部YAML
extends 此作业将继承的配置项
pages 上传作业结果用于gitlab pages
variables 作业级别定义作业变量
参考文章
https://blog.csdn.net/junmoxi/article/details/82762413
https://www.jianshu.com/p/30e3f2940078
https://www.jianshu.com/p/2b43151fb92e
https://segmentfault.com/a/1190000019540360
https://blog.csdn.net/jinking01/article/details/82490688