文章目录
- 一、前言
- 二、相关知识
- 1.相关定义
- 1.什么是 CI?
- 2.什么是 CD?
- 2.CI/CD 构建块与工具链
- 3.为什么要使用 CI/CD?
- 三、准备
- 四、实现
- 1.Runner安装与配置
- 1.更新源
- 2.安装Runner
- 3.注册Runner
- 4.启动Runner
- 5.查看Runner信息
- 2.CI/CD流程测试
- 1.CI/CD构建环境搭建
- 2.ssh权限问题解决
- 五、总结
一、前言
本次详细使用图文的形式实现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 做准备。
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 实例 URLPlease enter the registration token:
glrt-xxxxxxx ← 填写注册 token(项目页面提供)Please enter a description for the runner:
[hostname] ← 输入一个描述,如 ubuntu-runnerPlease enter tags for the runner (comma-separated):
docker,ubuntu ← (可选)指定 tags,用于匹配 CI/CD jobWhether to run untagged builds [true/false]:
true ← 是否允许跑无 tag 的 JobWhether 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- deploybuild:stage: buildscript:- npm install- npm run buildartifacts:paths:- dist/expire_in: 1 hourdeploy:stage: deploydependencies:- buildbefore_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_rsaonly:- 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 文化中扮演核心角色,不仅提升软件交付效率,而且显著增强质量与协作。具体实践中,通过工具链构建流水线,辅以策略与监控,最终实现稳定、可控、频繁的发布能力。