文章目录
一、前言
本次详细使用图文的形式实现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?
- 加快开发与发布速度:频繁小步提交,缩短迭代周期
- 提高软件质量:自动化测试确保每次提交的代码都是健壮的
- 减少发布风险 & 人为失误:自动部署与故障回滚机制降低人工操作风险
- 加强团队协作:透明流程与快速反馈提升开发---测试---运维间的协作效率
三、准备
- 服务器环境:Ubuntu20.04.3 X2台(一台用于配置Runner,另一台用于部署正式代码)
- gitlab:一个gitlab代码仓库
四、实现
1.Runner安装与配置
1.更新源
添加 GitLab Runner 的 APT 软件源,并导入其 GPG 密钥,为后续安装 GitLab Runner 做准备。
bash
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash

2.安装Runner
执行下面命令,在遇到红框中的询问对话时,输入y
后按下回车
bash
sudo apt-get install gitlab-runner

3.注册Runner
在终端输入下面的命令进入GitLab Runner注册交互对话
bash
sudo gitlab-runner register

去gitlab的Runners settings页面查找相关配置:
url:http:/xxx.xxx/
注册token:xxxxxx

下面是具体的交互命令释义
bash
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
bash
sudo gitlab-runner start
下面命令可以查看运行状态
bash
sudo gitlab-runner status

查看当前已注册的 runners
bash
sudo gitlab-runner list

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

下图为Runner的详细信息
2.CI/CD流程测试
1.CI/CD构建环境搭建
我们的测试项目是基于vue3.0、node.js18环境开发的,需要在Runner服务器上安装构建环境
安装 Node.js
bash
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
安装 npm
bash
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),并在所有分支上触发部署流程。整个流程实现了从构建到自动部署的连续交付。
bash
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 # 任何分支都会触发部署
上面的配置需要我们在本地创建构建目录,并给予适当的权限,我们手动在服务器上执行下面👇🏻命令即可
bash
sudo mkdir -p /var/lib/gitlab-runner
sudo chown gitlab-runner:gitlab-runner /var/lib/gitlab-runner
然后设置好变量
在git上触发一次代码提交操作
流水线job开始工作,自动实现构建、部署操作
建议自己亲自拉代码试一下
2.ssh权限问题解决
由于我们使用ssh连接到目标服务器,所以我们要保证Runner服务器与目标服务器之间通顺:
如果我们执行下面的命令,控制台打印了"OK"则无需下面额外的操作了
bash
ssh -i /tmp/id_rsa root@xx.xx.xx.190 "echo OK"

否则 需要在runner服务器中查看对应的公钥内容
bash
ssh-keygen -y -f /tmp/id_rsa
会打印下面的内容
然后去目标服务器 将上面的公钥配置到~root/.ssh/authorized_keys
文件中,最后查看
bash
cat ~root/.ssh/authorized_keys

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