Git(12)GitLab持续集成(CICD)
Git(12)之GitLab持续集成(CI/CD)
Author: Once Day Date: 2025年3月18日
一位热衷于Linux学习和开发的菜鸟,试图谱写一场冒险之旅,也许终点只是一场白日梦…
漫漫长路,有人对你微笑过嘛…
全系列文章可查看专栏: Git使用记录_Once_day的博客-CSDN博客
参考文章:
- 创建并运行您的第一个极狐GitLab CI/CD 流水线 | 极狐GitLab
- GitLab CI/CD - 废物大师兄 - 博客园
- GitLab CI-CD 学习笔记 - 低吟不作语 - 博客园
- CI/CD YAML 语法参考 | 极狐GitLab
- Install GitLab Runner manually on GNU/Linux | GitLab Docs
文章目录
- Git(12)之GitLab持续集成(CI/CD)
- 1. GitLab CI/CD介绍
- 2. GitLab CI/CD运行条件
- 3. 安装和注册GitLab Runner
- 4. `.gitlab-ci.yml`语法参考
1. GitLab CI/CD介绍
GitLab CI/CD 是一个内置在GitLab中的工具,用于通过持续方法进行软件开发:
- Continuous Integration (CI) 持续集成:假设一个应用程序,其代码存储在GitLab的Git仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送,都可以创建一组脚本来自动构建和测试你的应用程序,从而减少了向应用程序引入错误的机会。
- Continuous Delivery (CD) 持续交付:应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试,而且,尽管部署是手动触发的,但作为一个附加步骤,它也可以连续部署。此方法可确保自动检查代码,但需要人工干预才能从策略上手动触发以必输此次变更。
- Continuous Deployment (CD) 持续部署:无需将其手动部署,而是将其设置为自动部署。完全不需要人工干预即可部署应用程序。
持续集成的工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中,并且每次推送时,都要运行一系列脚本来构建、测试和验证代码更改,然后再将其合并到主分支中。
持续交付和部署相当于更进一步的CI,可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。
这些方法使得可以在开发周期的早期发现bugs和errors,从而确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。
GitLab CI/CD帮助开发团队自动化软件开发流程,提高代码质量和交付速度,其关键特点如下:
- 流水线(Pipeline):GitLab使用流水线来定义、管理和执行CI/CD过程。流水线由多个阶段(Stages)组成,每个阶段包含一个或多个任务(Jobs)。
.gitlab-ci.yml
文件:流水线的配置保存在项目根目录的.gitlab-ci.yml
文件中。该文件定义了流水线的结构、阶段和任务,以及任务执行的条件和环境。- Runners:Runners是执行CI/CD任务的代理程序。它们可以运行在各种环境中,如Docker容器、虚拟机或物理服务器上。用户可以使用GitLab提供的共享Runners,也可以自行注册和管理专用Runners。
- 触发器:流水线可以通过多种方式触发,例如推送代码、创建合并请求(Merge Request)、手动触发或API调用等。
- 工件(Artifacts):任务可以生成工件,如编译后的二进制文件、测试报告或文档。工件可以在流水线的后续阶段中使用,或下载供离线分析。
- 环境(Environments):GitLab支持将应用程序部署到不同的环境,如开发、测试、预发布和生产环境。可以为每个环境定义不同的部署策略和访问控制。
- 部署:GitLab提供了多种部署方式,包括手动部署、自动部署和渐进式交付。用户可以使用内置的部署工具,或集成第三方工具如Kubernetes或AWS。
- 安全测试:GitLab集成了多种安全测试工具,如SAST(静态应用程序安全测试)、DAST(动态应用程序安全测试)和依赖项扫描等,帮助及早发现和修复安全漏洞。
2. GitLab CI/CD运行条件
要在GitLab中实现CI/CD工作流,需要满足以下必备条件:
gitlab-ci.yml
文件:该文件是GitLab CI/CD的核心配置文件,定义了CI/CD流水线的结构和行为。它位于项目仓库的根目录,使用YAML语法编写。.gitlab-ci.yml
文件包含了流水线的阶段、任务、脚本、依赖关系和其他配置选项。GitLab在检测到.gitlab-ci.yml
文件后,会自动触发流水线的执行。- GitLab Runner:GitLab Runner是一个用于执行CI/CD任务的代理程序。Runner可以运行在各种环境中,如Linux、macOS、Windows、Docker容器或Kubernetes集群等。用户可以使用GitLab提供的共享Runner,也可以自行注册和管理专用Runner。Runner负责从GitLab服务器获取任务,并根据
.gitlab-ci.yml
文件中的定义执行相应的脚本和命令。Runner将任务的执行结果和工件上传回GitLab服务器,以供后续阶段使用或下载。 - GitLab服务器:GitLab服务器是整个CI/CD工作流的核心,负责存储代码仓库、管理流水线、调度任务和协调Runner。用户可以使用GitLab.com提供的云服务,或自行搭建GitLab社区版或企业版服务器。GitLab服务器需要与Runner建立通信,以发送任务和接收执行结果。
- 代码仓库:GitLab的CI/CD工作流基于Git版本控制系统构建。用户需要将项目代码托管在GitLab服务器的代码仓库中。当代码发生变更(如推送新的提交或创建合并请求)时,可以触发相应的CI/CD流水线。
- 构建环境和依赖项:为了成功执行CI/CD任务,Runner需要具备适当的构建环境和依赖项。这可能包括编程语言的运行时、构建工具、测试框架、数据库等。用户可以通过
.gitlab-ci.yml
文件中的image
和services
关键字指定所需的Docker镜像和服务。Runner会自动拉取指定的镜像,并在隔离的容器环境中执行任务。
满足以上条件后,就可以开始在GitLab中定义CI/CD流水线,自动化构建、测试和部署流程了。GitLab提供了丰富的文档和示例,帮助用户快速上手并充分利用其CI/CD功能。
3. 安装和注册GitLab Runner
首先,需要在目标机器上安装GitLab Runner。
根据操作系统的不同,可以选择不同的安装方式,如二进制文件、Docker镜像或包管理器等。
以Linux为例,可以使用以下命令安装GitLab Runner:
# 添加GitLab的官方仓库
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
# 安装GitLab Runner
sudo apt-get install gitlab-runner
安装完成后,需要将GitLab Runner注册到GitLab服务器上。
在GitLab项目或组的"Settings" -> “CI/CD” -> "Runners"页面中,可以找到注册Runner所需的URL和令牌(token)。
在目标机器上运行以下命令来注册Runner:
sudo gitlab-runner register
根据提示,输入GitLab服务器的URL、令牌、Runner的描述、标签等信息。选择Runner的执行器(executor),常见的有Shell、Docker、Kubernetes等。完成注册后,Runner就可以接收并执行GitLab分发的CI/CD任务了。
./gitlab-runner register \
--non-interactive \
--url "https://your-gitlab-instance.com/" \
--registration-token "your-runner-token" \
--executor "docker" \
--docker-image alpine:latest \
--description "docker-runner" \
--tag-list "docker" \
--run-untagged="true" \
--locked="false" \
--access-level="not_protected"
- GitLab instance URL:这一步需要输入您的 GitLab 实例的 URL。通常是类似 https://gitlab.example.com 的形式。如果您使用的是 GitLab.com 的服务,那么这里应该输入 https://gitlab.com。Runner 将通过这个 URL 与您的 GitLab 实例通信。请确保 URL 能够被 Runner 访问到。
- Registration token:输入 Runner 的注册 token。这个 token 用于将 Runner 与 GitLab 实例关联起来。可以在 GitLab 的 Admin Area -> Overview -> Runners 页面找到这个 token,或者在项目的 Settings -> CI/CD -> Runners 页面。 token 通常是一串随机的字符,格式类似 xxxxxxxxxxxxxxxx。
- Description:这一步是输入对这个 Runner 的描述信息,方便在 GitLab 界面上区分与管理多个 Runner。可以输入诸如"my-first-runner"、“ruby-runner”、"node-runner"之类的名字,或者其他任何有意义的描述。
- Tags:为 Runner 设置标签,多个标签以逗号分隔。设置标签后,可以在创建 job 时通过 tags 关键字选择特定的 Runner 来执行。比如,如果某个 Runner 设置了 ruby 和 node 标签,那么只有同时设置了这两个标签的 job 会被该 Runner 接受并执行。
- Optional maintenance note:可选步骤,用于设置 Runner 的维护备注信息,比如该 Runner 的维护人员或部门。这个信息会显示在 GitLab Admin Area -> Runners 页面,方便管理员了解 Runner 的归属。
- Enter an executor:选择 Runner 的 executor 类型,常见的:
- shell,直接在 Runner 所在机器上执行。
- docker,在 Docker 容器中执行。
- ssh,通过 SSH 连接到远程机器执行(最好手动连接一下,因为ssh有一些前置条件)。
- virtualbox,在 VirtualBox 虚拟机中执行。
- parallels,在 Parallels 虚拟机中执行。
- kubernetes,在Kubernetes 集群上执行。
注册完成后,可以对GitLab Runner进行进一步的配置。Runner的配置文件通常位于/etc/gitlab-runner/config.toml
。可以编辑该文件,修改Runner的并发数、缓存目录、日志级别等选项。如果使用Docker执行器,还可以配置Docker镜像、挂载卷等。
启动和管理GitLab Runner:
注册和配置完成后,可以启动GitLab Runner:
sudo gitlab-runner start
可以使用以下命令来管理GitLab Runner的状态:
sudo gitlab-runner status # 查看Runner的状态
sudo gitlab-runner stop # 停止Runner
sudo gitlab-runner restart # 重启Runner
注册的Runner会显示在GitLab项目或组的"Settings" -> “CI/CD” -> "Runners"页面中。可以在.gitlab-ci.yml
文件中使用tags
关键字来指定Runner的标签,以将任务分配给特定的Runner执行。
Runner会根据.gitlab-ci.yml
文件中定义的阶段和任务,自动执行相应的脚本和命令。
下面是一个gitlab-runner/config.toml配置实例:
concurrent = 32
check_interval = 0
connection_max_age = "15m0s"
shutdown_timeout = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "work-book"
url = "http://10.51.134.12:8080/"
id = 21
token = "mEnaxAKF6ARozj"
token_obtained_at = 2025-03-18T06:31:34Z
token_expires_at = 0001-01-01T00:00:00Z
executor = "docker"
[runners.cache]
MaxUploadedArchiveSize = 0
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "ubuntu:24.04"
pull_policy = "if-not-present"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
network_mtu = 0
4. .gitlab-ci.yml
语法参考
下面是.gitlab-ci.yml
文件中常见的关键字及其功能描述。这些关键字用于配置CI/CD流水线的各个方面,如任务定义、阶段划分、依赖关系、缓存、工件、触发器等。通过合理使用这些关键字,可以构建复杂而灵活的CI/CD流程,自动化软件开发的各个环节。
关键字名称 | 功能描述 |
---|---|
job | 定义一个任务,包含该任务的所有配置。 |
script | 指定任务要执行的脚本或命令。 |
before_script | 指定在每个任务之前执行的脚本或命令。 |
after_script | 指定在每个任务之后执行的脚本或命令。 |
stages | 用于定义流水线的阶段,阶段按顺序执行。 |
stage | 指定任务所属的阶段。 |
.pre | 定义在所有任务之前运行的隐藏任务。 |
.post | 定义在所有任务之后运行的隐藏任务。 |
variables | 定义全局变量或任务级别的变量。 |
tags | 用于指定运行任务的Runner的标签。 |
allow_failure | 允许任务失败而不影响流水线的整体状态。 |
when | 指定任务的执行条件,如always、on_success、on_failure等。 |
retry | 指定任务失败时的重试次数。 |
timeout | 指定任务的超时时间。 |
parallel | 指定并行执行的任务数量。 |
rules | 根据条件动态地包含或排除任务。 |
workflow-rules | 定义流水线级别的规则。 |
cache | 指定在任务之间缓存的文件或目录,以加速任务的执行。 |
artifacts | 指定任务生成的工件,可以在后续任务中使用或下载。 |
dependencies | 指定任务的依赖关系,确保依赖任务先执行。 |
needs | 指定任务需要的资源或工件。 |
includes | 引入外部YAML文件,扩展流水线配置。 |
extends | 继承其他任务的配置。 |
triggers | 定义触发器,用于触发其他流水线。 |
image | 指定任务运行时使用的Docker镜像。 |
services | 指定任务运行时使用的Docker服务。 |
environment | 用于定义任务部署到的环境。 |
一个简单.gitlab-ci.yml
配置文件如下所示:
build-job:
stage: build
script:
- echo "Hello, $GITLAB_USER_LOGIN!"
test-job1:
stage: test
script:
- echo "This job tests something"
test-job2:
stage: test
script:
- echo "This job tests something, but takes more time than test-job1."
- echo "After the echo commands complete, it runs the sleep command for 20 seconds"
- echo "which simulates a test that runs 20 seconds longer than test-job1"
- sleep 20
deploy-prod:
stage: deploy
script:
- echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
environment: production
在GitLab Web界面可以查看这个流水线作业情况:
这是一个具备三个stage的流水线,其中测试阶段两个任务可以并发执行。