GitLab平台太单调? 配置Pipeline流水线，装上这个流水线“瀑布灯”！

博客：https://www.mintimate.cn Mintimate’s Blog，只为与你分享

头图可以少？

在上一篇文章中，我们介绍了如何使用Docker搭建自己的GitLab代码托管平台。

GitLab作为一个成熟的DevOps工具，不仅提供了代码托管的功能，还内置了强大的CI/CD流水线。利用GitLab的CI/CD能力，配置Pipeline来实现自动化的编译、测试和部署。

本文将继续上篇的内容，重点介绍在自己搭建的GitLab平台上，如何配置Pipeline实现CI/CD：

• 学习Pipeline的基本概念、语法结构；
• 借助GitLab Runner来执行Pipeline中的job；
• 配置.gitlab-ci.yml文件，实现代码提交后自动编译、测试、部署到服务器。

Yo~

其实配置起来，和GitHub Action类似，写法也和Docker Compose也类似。

GitLab Runner

GitLab Runner是GitLab CI/CD的核心组件,用于运行Pipeline中的 jobs。

GitLab CI/CD

它是一个独立的应用程序,需要单独安装。主要有以下几个主要版本:

1. Shell Runner:最基础的Runner版本，在本地直接调用shell命令来执行jobs。
2. Docker Runner:使用Docker容器来运行jobs,提供隔离的运行环境。
3. Kubernetes Runner:在Kubernetes集群上运行jobs,可以动态规模扩展。
4. Custom Runner:支持使用其他脚本语言如Python、Ruby来自定义Runner,提高扩展性。
5. Group Runner:顾名思义,是面向特定组织或组内项目统一提供服务的Runner。

工作流程

为什么GitLab使用Pipeline流水线需要另外安装或者激活GitLab Runner呢？ 其实GitLab Runner和GitLab基本是相互独立的。官方的流程图：

GitLab Runner和GitLab的联系

简单复述一下:

好的,关于GitLab Runner和GitLab的交互作业流程,可以这样理解:

1. 开发者提交代码到GitLab,触发一个Pipeline。
2. GitLab生成一个唯一的token,标识这个job,然后将这个job以及token发送给指定的Runner。
3. Runner使用这个token来请求增加权限,访问代码仓库和构建工件。
4. GitLab验证token,授权Runner获得临时访问权限。
5. Runner利用授权的token,拉取代码,运行scripts,产生构建工件。
6. 构建完成后,Runner上传工件到GitLab,在工作流中标记job成功或失败。
7. GitLab使用token验证上传,确保来自授权的Runner,避免非法上传。
8. GitLab标记job状态为success或failed。

这实现了一个 tokenized 的工作流,保证了job的安全性。

Runner和GitLab之间通过token来验证对方身份和授权，实现了解耦和安全隔离，避免因为Runner的部署影响到GitLab的正常运行。

版本对比

我们参考官方文档：https://docs.gitlab.com/runner/executors/

我这里总结一下：

我们GitLab都是Docker部署的，所以Shell的方式是走不通了；为了方便操作，我这里演示Docker版本。

注册Runner

我们这次演示注册Docker版本的Runner，在服务器上部署Runner之前，我们需要在GitLab的Web控制面板上，创建一个Runner实例，

创建Runner实例

我的服务器是腾讯云的轻量应用服务器，使用Debian的Linux镜像，所以我这里选择Linux：

选择Linux

重要的来了，出现了配置命令：

配置命令

这个时候，我们需要记下：

• url: 你GitLab的直连域名/IP；
• token: 用于权限和交互的token，只会出现一次。

假设，url为example.gitlab,com，token为helloworld。

Docker部署Runner

在一台安装好Docker的服务器设备上，我们运行GitLab Runner的镜像拉取：

sudo docker run -d --name gitlab-runner --restart always \
  -v /dockerData/gitlab-runner:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

其中：

• -v /dockerData/gitlab-runner:/etc/gitlab-runner: 将/dockerData/gitlab-runner目录挂载到容器内的/etc/gitlab-runner，用于保存runner的配置文件
• -v /var/run/docker.sock:/var/run/docker.sock: 将docker宿主机的docker.sock挂载到容器内，这样runner容器可以访问宿主机的docker服务。

拉取的服务

查看日志，如果报的是找不到配置文件，那么是无需担心的：

找不到配置文件

接下来，我们需要关联到GitLab平台上。

关联到GitLab

刚刚，我们已经新建了应该runner的注册信息：

url为example.gitlab.com，token为helloworld

这个时候，我们需要在部署了GitLab Runner的Docker服务器上，关联上：

sudo docker run --rm -it -v /dockerData/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register

关联注册

依次填写我们的url和token：

填写的结果

后面的配置，依次为：别名、executor 类型、默认的镜像。

这里只是默认镜像，.gitlab-ci.yml没有为某个 job 指定镜像，会使用默认镜像。比如这里设置默认的镜像为node:20.8.0-bullseye。

到此，我们的Runner就应该关联和注册好了：

Runner注册和关联好

Pipeline流水线

接下来，我们编写一个流水线。这里简单介绍一下，具体可以参考官网：

• https://docs.gitlab.com/ee/ci/pipelines/

简单概括一下GitLab Pipeline的主要步骤: 在每次的Git Push后，GitLab会读取根目录.gitlab-ci.yml文件进行构建、测试和打包等操作。

gitlab-ci.yaml语法

.gitlab-ci.yml 使用 YAML 格式,主要包含以下几类语法:

全局定义

配置执行器,指令等全局信息。例如:

image: ruby:2.6
services:
    - mysql

作业定义

每个作业至少包含 script 定义。例如:

build:
    script:
    - gem install bundler
    - bundle install

阶段定义

用 stage 指定作业执行阶段。例如:

stages:
    - build
    - test
    - deploy

build_job:
    stage: build 

作业规则

定义作业的规则、环境等信息。例如:

rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
environment: production

定义作业间依赖关系。例如:

deploy:
    needs: [build, test]

我们可以组合这些语法构建完整的管道配置。

环境变量

有时候，我们需要设置一下服务器的密钥、服务器的IP，直接在.gitlab-ci.yaml内写肯定是不安全的。我们可以设置环境变量：

环境变量

之后，在编写时候调用：

部署阶段调用

Demo: 部署VitePress

接下来，我们演示一下如何在Pipeline部署我们的VitePress。是一款不错的文档框架，改天有机会和大家介绍一下：

部署效果

我们写一个.gitlab-ci.yaml：

image: node:lts-buster

cache:           # 设置缓存
  paths:
    - .vitepress/dist/   # 缓存生成出来的文件目录

stages:          # 全部的步骤
  - build
  - deploy

build-job:       # 打包阶段
  stage: build
  script:
    - echo "设置国内更新源"
    - npm config set registry http://mirrors.cloud.tencent.com/npm/ # 设置国内源
    - echo "执行依赖的更新"
    - npm install
    - echo "执行打包操作"
    - npm run build

deploy-job:      # 部署阶段
  stage: deploy
  script:
    - echo "开始部署……"
    - cp /etc/apt/sources.list /etc/apt/sources.list.bak
    - echo "设置更新源"
    - bash -c 'echo "deb http://mirrors.cloud.tencent.com/debian/ buster main non-free contrib" > /etc/apt/sources.list'
    - bash -c 'echo "deb-src http://mirrors.cloud.tencent.com/debian/ buster main non-free contrib" >> /etc/apt/sources.list' 
    - bash -c 'echo "deb http://mirrors.cloud.tencent.com/debian/ buster-updates main non-free contrib" >> /etc/apt/sources.list'
    - bash -c 'echo "deb-src http://mirrors.cloud.tencent.com/debian/ buster-updates main non-free contrib" >> /etc/apt/sources.list'
    - bash -c 'echo "deb http://mirrors.cloud.tencent.com/debian/ buster-backports main non-free contrib" >> /etc/apt/sources.list'  
    - bash -c 'echo "deb-src http://mirrors.cloud.tencent.com/debian/ buster-backports main non-free contrib" >> /etc/apt/sources.list'
    - bash -c 'echo "deb http://security.debian.org/ buster/updates main contrib non-free" >> /etc/apt/sources.list'
    - bash -c 'echo "deb-src http://security.debian.org/ buster/updates main contrib non-free" >> /etc/apt/sources.list'
    - apt update
    - echo "安装rsync"
    - apt install rsync -y
    - echo "设置SSH无感验证"
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - mkdir -p ~/.ssh
    - eval $(ssh-agent -s)
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
    - echo "SCP传输"
    - ssh-add <(echo "$MINE_SERVER_KEY")
    - rsync -r --delete .vitepress/dist/ ${MINE_SERVER_USER}@${MINE_SERVER_IP}:${MINE_SERER_PATH}
    - echo "应用部署完成"

主要分为两个阶段：

• 打包阶段: 把VitePress打包为静态文件，用于部署到Nginx服务器上；
• 部署阶段: 将打包出来的静态文件，使用rsync部署到远程服务器上的Ngixn目录。

打包阶段

1. 使用node LTS buster系统镜像,提供构建环境
2. 设置npm国内源,加速下载依赖
3. 安装依赖
4. 执行打包构建,生成结果存放在缓存目录
5. 缓存目录可重复利用,加速后续构建

部署阶段

1. 替换apt源,安装rsync,提高部署效率
2. 配置SSH免密登录,实现无感部署
3. 使用rsync将打包结果同步到服务器
4. 环境变量隐藏服务器信息,保证安全
5. 完成结果部署到服务器指定目录

这样通过打包和部署两个阶段，使用脚本自动化执行，利用缓存、环境配置等特性，可以高效、安全的实现持续集成和持续部署。

最后在一次的Git提交后，可以触发打包和部署：

GitLab部署状况

其实点进去也可以看到具体的日志：

日志

说实话，比较难的是SSH的密钥添加部分，需要在GitLab CI作业中配置 SSH 免密登录，主要步骤：

# 检查是否存在 ssh-agent,如果不存在则安装 openssh-client
'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'

# 创建 .ssh 目录
mkdir -p ~/.ssh 

# 启动 ssh-agent 管理私钥
eval $(ssh-agent -s)

# 如果在 Docker 中运行,配置 SSH 免密登录
# [[ -f /.dockerenv ]] 检查是否存在 Docker 环境标志文件
# echo -e "Host *\n\tStrictHostKeyChecking no\n\n" 
# 向 ~/.ssh/config 写入禁用 StrictHostKeyChecking 的配置 
[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config

实现了无需输入密码就能 SSH 登录到 GitLab Runner 中,从而自动化部署到服务器。

当然，流水线的其他配置还可以很多，有时间，我们单独起一篇文章为大家讲解~~

END

文章演示了如何通过Docker来部署Runner，并与GitLab项目实例关联注册,使其可以运行流水线作业。

一系列操作，让我们的GitLab更加丰富多彩。当然，有机会，教大家更详细的书写Pipeline的流水线脚本，让大家像写GitHub Action一样能熟练地书写脚本。

什么？ 你还没用过GitHub Action？ 改天有机会，也教大家如何进行书写~~

我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表