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

文章目录

• 一、前言
• 二、相关知识
• • 1.相关定义
  • • [1.什么是 CI？](#1.什么是 CI？)
    • [2.什么是 CD？](#2.什么是 CD？)
  • [2.CI/CD 构建块与工具链](#2.CI/CD 构建块与工具链)
  • [3.为什么要使用 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？

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 文化中扮演核心角色，不仅提升软件交付效率，而且显著增强质量与协作。具体实践中，通过工具链构建流水线，辅以策略与监控，最终实现稳定、可控、频繁的发布能力。