日常--记一次gitlab Runner配置与CI/CD环境搭建流程

发布于:2025-07-10 ⋅ 阅读:(19) ⋅ 点赞:(0)


一、前言

本次详细使用图文的形式实现gitlab Runner配置与CI/CD环境搭建,网上搜了一些教程都是docker的,我们的架构比较简单,开发语言多是vue,所以本次使用shell实现CI流程。

二、相关知识

1.相关定义

持续集成(CI)与持续交付/部署(CD)合称为 CI/CD,是现代软件开发中 DevOps 实践的重要组成,旨在通过 构建—测试—部署 的自动化流水线,实现高效、稳定地发布代码。以下是系统性的介绍:
在这里插入图片描述

1.什么是 CI?

Continuous Integration(持续集成):开发者将代码频繁(理想情况每天多次)合并到共享主干,自动触发构建和测试流程,以便尽早发现集成问题,避免“集成地狱”

2.什么是 CD?

CD 有两种定义方式,依实施程度不同:

Continuous Delivery(持续交付):

构建完成且通过测试后,代码自动部署到预发布环境,但进入生产环境前还需人为审批

Continuous Deployment(持续部署):

每次构建并测试通过后,自动部署到生产环境,无需人工干预
CD 的典型流程包括从构建、打包到自动部署、监控反馈与回滚机制等,目标是实现代码随时可发布,并且发布快速稳定

2.CI/CD 构建块与工具链

版本控制系统:Git、SVN 等
CI 工具:Jenkins、Travis CI、CircleCI、GitLab CI、GitHub Actions
构建与测试工具:Maven、Gradle、pytest、JUnit、Selenium 等
部署工具与平台:Docker、Kubernetes、Ansible、Terraform、Argo CD等
监控与反馈:Prometheus、Grafana、日志分析、性能监控等

3.为什么要使用 CI/CD?

  1. 加快开发与发布速度:频繁小步提交,缩短迭代周期
  2. 提高软件质量:自动化测试确保每次提交的代码都是健壮的
  3. 减少发布风险 & 人为失误:自动部署与故障回滚机制降低人工操作风险
  4. 加强团队协作:透明流程与快速反馈提升开发—测试—运维间的协作效率

三、准备

  1. 服务器环境:Ubuntu20.04.3 X2台(一台用于配置Runner,另一台用于部署正式代码)
  2. gitlab:一个gitlab代码仓库

四、实现

1.Runner安装与配置

1.更新源

添加 GitLab Runner 的 APT 软件源,并导入其 GPG 密钥,为后续安装 GitLab Runner 做准备。

 curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash

在这里插入图片描述

2.安装Runner

执行下面命令,在遇到红框中的询问对话时,输入y后按下回车

sudo apt-get install gitlab-runner

在这里插入图片描述

3.注册Runner

在终端输入下面的命令进入GitLab Runner注册交互对话

sudo gitlab-runner register

在这里插入图片描述
去gitlab的Runners settings页面查找相关配置:

url:http:/xxx.xxx/
注册token:xxxxxx

在这里插入图片描述
下面是具体的交互命令释义

Please enter the GitLab instance URL:
https://gitlab.com   ← 填写你项目所在的 GitLab 实例 URL

Please enter the registration token:
glrt-xxxxxxx         ← 填写注册 token(项目页面提供)

Please enter a description for the runner:
[hostname]           ← 输入一个描述,如 ubuntu-runner

Please enter tags for the runner (comma-separated):
docker,ubuntu        ← (可选)指定 tags,用于匹配 CI/CD job

Whether to run untagged builds [true/false]:
true                 ← 是否允许跑无 tag 的 Job

Whether to lock the Runner to current project [true/false]:
false                ← 是否锁定 Runner 到当前项目

Please enter the executor:
shell                ← 推荐用 docker 或 shell

值得一提的是,这里我们选择了shell作为环境,但是博主推荐docker,因为能实现环境的隔离。
在这里插入图片描述

Executor 推荐程度 说明
docker ⭐⭐⭐⭐⭐ 最推荐。如果你的系统支持 Docker,Runner 会用容器执行每个 Job,干净、安全、易管理。
shell ⭐⭐⭐ 最简单的方式,Runner 直接在宿主机的 shell 里执行。适合没有 Docker 的环境,但缺乏隔离性。
ssh ⭐⭐ 通过 SSH 在远程服务器上执行 Job。用于部署时可能有用,但设置复杂。
docker+machine ⭐⭐⭐ 动态创建 VM + Docker,用于大规模 CI/CD。配置复杂,适合企业级。
其他 ⭐ 或无 kubernetes, parallels, virtualbox 等,特定场景下用,配置成本较高。

4.启动Runner

输入下面命令,启动Runner

sudo gitlab-runner start 

下面命令可以查看运行状态

sudo gitlab-runner status

在这里插入图片描述

查看当前已注册的 runners

sudo gitlab-runner list 

在这里插入图片描述

5.查看Runner信息

这时,我们已经可以在gitlab后台的Runner设置页面里看到已经启用的Runner了

在这里插入图片描述
下图为Runner的详细信息
在这里插入图片描述

2.CI/CD流程测试

1.CI/CD构建环境搭建

我们的测试项目是基于vue3.0、node.js18环境开发的,需要在Runner服务器上安装构建环境

安装 Node.js

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -

安装 npm

sudo apt install -y nodejs

在git项目中创建.gitlab-ci.yml

这段 GitLab CI/CD 配置定义了一个简单的两阶段流水线:build 和 deploy。在 build 阶段中,使用 Node.js 命令安装依赖并构建项目,构建产物(dist/ 目录)作为 artifact 保存 1 小时;在 deploy 阶段,依赖 build 阶段的输出,通过 SSH 将构建结果部署到远程服务器(包括建立 SSH 连接、复制文件、重启 Nginx),并在所有分支上触发部署流程。整个流程实现了从构建到自动部署的连续交付。

stages:
  - build
  - deploy

build:
  stage: build
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour

deploy:
  stage: deploy
  dependencies:
    - build
  before_script:
    - which ssh || (echo "SSH not installed!" && exit 1)
  script:
    - echo "$SSH_PRIVATE_KEY" | tee /tmp/id_rsa > /dev/null
    - chmod 600 /tmp/id_rsa
    - ssh -o StrictHostKeyChecking=no -i /tmp/id_rsa $SSH_USER@$SSH_HOST "echo 'SSH connected successfully'"
    - scp -o StrictHostKeyChecking=no -i /tmp/id_rsa -r dist/ $SSH_USER@$SSH_HOST:/www/movie_tmp/
    - ssh -o StrictHostKeyChecking=no -i /tmp/id_rsa $SSH_USER@$SSH_HOST "sudo service nginx restart"
    - rm -f /tmp/id_rsa
  only:
    - branches  # 任何分支都会触发部署

上面的配置需要我们在本地创建构建目录,并给予适当的权限,我们手动在服务器上执行下面👇🏻命令即可

sudo mkdir -p /var/lib/gitlab-runner
sudo chown gitlab-runner:gitlab-runner /var/lib/gitlab-runner

然后设置好变量
在这里插入图片描述

在git上触发一次代码提交操作
在这里插入图片描述
流水线job开始工作,自动实现构建、部署操作
在这里插入图片描述
建议自己亲自拉代码试一下

2.ssh权限问题解决

由于我们使用ssh连接到目标服务器,所以我们要保证Runner服务器与目标服务器之间通顺:
如果我们执行下面的命令,控制台打印了“OK”则无需下面额外的操作了

ssh -i /tmp/id_rsa root@xx.xx.xx.190 "echo OK"

在这里插入图片描述

否则 需要在runner服务器中查看对应的公钥内容

ssh-keygen -y -f /tmp/id_rsa

会打印下面的内容
在这里插入图片描述
然后去目标服务器 将上面的公钥配置到~root/.ssh/authorized_keys文件中,最后查看

cat ~root/.ssh/authorized_keys

在这里插入图片描述

五、总结

本次和大家分享了gitlab Runner配置与CI/CD环境搭建流程。

CI/CD 是自动化构建—测试—部署流程的集大成,在 DevOps 文化中扮演核心角色,不仅提升软件交付效率,而且显著增强质量与协作。具体实践中,通过工具链构建流水线,辅以策略与监控,最终实现稳定、可控、频繁的发布能力。


网站公告

今日签到

点亮在社区的每一天
去签到