Gitlab系列（3）—— 基于Gitlab-runner 的CI/CD集成

概念

Gitlab从8.0开始内部集成CI组件.
主要的几个角色：

• Gitalb服务器（Runner也可以和Gitlab在一台服务器，但不推荐）
• 应用服务器
  一般来说：这三者应该是互相独立的服务器；

职责划分：

• Gitlab管理源代码仓库
• Gitlab-runner执行CI/CD任务
• 应用服务器运行应用。

CI集成流程

• 部署runner
• 将runner注册到gitlab中
• 项目中添加ci配置文件（默认为：根目录下 名为 .gitlab-ci.yml 的配置文件）

安装runner

这里采用docker的方式

[root@origin ~]# mkdir -p /opt/docker-compose/gitlab-runner
[root@origin ~]# cd /opt/docker-compose/gitlab-runner/
[root@origin gitlab-runner]# vim docker-compose.yml

加入以下内容

version: "3.8"
services:
  gitlab-ruuner:
    image: gitlab/gitlab-runner:alpine-v14.2.0
    container_name: gitlab-runner
    restart: always
    environment:
      TZ: Asia/Shanghai
    volumes:
    - 'gitlab-runner-config:/etc/gitlab-runner'
    - '/var/run/docker.sock:/var/run/docker.sock'
volumes:
  gitlab-runner-config: {}

启动

[root@origin gitlab-runner]# docker-compose up -d
Creating network "gitlab-runner_default" with the default driver
Creating volume "gitlab-runner_gitlab-runner-config" with default driver
Pulling gitlab-ruuner (gitlab/gitlab-runner:alpine-v14.2.0)...
alpine-v14.2.0: Pulling from gitlab/gitlab-runner
df20fa9351a1: Pull complete
68b5efbe3d56: Pull complete
4343faab059b: Pull complete
8eaac47311c7: Pull complete
05ca9b892c72: Pull complete
1e464858e46d: Pull complete
bc6ed1be2837: Pull complete
Digest: sha256:577ed084b426f819eaf612889922f66bdf7edbe87522ee49c3cf38a906a578ab
Status: Downloaded newer image for gitlab/gitlab-runner:alpine-v14.2.0
Creating gitlab-runner ... done

注册runner(DIND)

官方一共提供了3种runner，根据需要自行选择，这里以项目级runner为例

使用docker执行CI流水线，官方提供了三种方式，这里采用的是docker executor ，所以选择后两种都可以；shell excutor 需要在宿主机中搭建流水线所需环境

这里分别展示后两种方式

• 第二种(dind)
  这种方式实际上是在docker 容器内起了一个docker服务，用于处理流水线任务；进入容器

gitlab-runner register -n \
--url http://blog_gitlab.kalpana.top:9080/ \
--registration-token xxxxxxxxxxxxx\
--executor docker \
--description "dind" \
--tag-list "dind" \
--docker-image "docker:20.10.8" \
--docker-privileged \
--docker-volumes "/certs/client"

执行结果


至此Gitlab服务器端的工作就已经完成了，接下来需要到对应的项目中添加流水线配置文件

注册runner(BIND)

与上面（DIND）不同的是，这种方式只在docker容器内部，安装一个客户端，而直接与runner宿主机的docker server 交互；这得益于docker的C/S架构

• 进入容器，执行以下命令

gitlab-runner register -n \
--url http://blog_gitlab.kalpana.top:9080/ \
--registration-token xxxxxxxxxxxxx\
--executor docker \
--description "bind" \
--tag-list "bind" \
--docker-image "docker:20.10.8" \
--docker-volumes /var/run/docker.sock:/var/run/docker.sock

• 执行成功
  

项目配置CI(DIND)

• 在项目根目录添加配置文件 .gitlab-ci.yml

image: docker:20.10.8

variables:
  DOCKER_TLS_CERTDIR: "/certs"

services:
  - name: docker:20.10.8-dind
  command: ["--registry-mirror", "自定义镜像仓库"]

before_script:
  - docker info

build:
  stage: build
  tags:
    - dind
  only:
    - dev
  script:
    echo "ci success"

这里有个点需要注意，如果在注册runner时，指定了tags，那么在这个配置文件中也需要指定tags，否则这个流水线会卡住，因为 tags 本身的作用就是对runner的一种限定；话句话说，不指定对应的tag，gitlab就不知道去调用哪个runner；可以通过 --run-untagged=“true” 取消这个设定，即未指定tag的流水线也会触发这个runner

• 提交这个文件
  
  可以看到这里有两个流水线任务，下面那个就是第一次未指定 tags ，卡住的任务。
  可以看到任务已经执行成功。
  

项目配置CI(BIND)

• 与DIND的区别在于脚本内容

image: docker:20.10.8

before_script:
  - docker info

build:
  stage: build
  tags:
    - bind
  only:
    - dev
  script:
    - echo "bind ci success"
    - docker images

• 提交配置文件，查看流水线任务
  
  成功

其他配置

复用本地镜像开启debug模式：链接

接下来，将介绍常用的关键字以及项目实战。