GitLab Runner 全面解析:Kubernetes 环境下的应用

简介: GitLab Runner 是 GitLab CI/CD 的核心组件,负责执行由 `.gitlab-ci.yml` 定义的任务。它支持多种执行方式(如 Shell、Docker、Kubernetes),可在不同环境中运行作业。本文详细介绍了 GitLab Runner 的基本概念、功能特点及使用方法,重点探讨了流水线缓存(以 Python 项目为例)和构建镜像的应用,特别是在 Kubernetes 环境中的配置与优化。通过合理配置缓存和镜像构建,能够显著提升 CI/CD 流水线的效率和可靠性,助力开发团队实现持续集成与交付的目标。


GitLab Runner 是 GitLab CI/CD 的核心组件,负责执行由 GitLab CI 配置文件(.gitlab-ci.yml)定义的任务。无论是简单的测试脚本还是复杂的部署流程,GitLab Runner 都能高效地完成相关工作。本文将详细介绍 GitLab Runner 的基本概念、功能特点、使用方法,并深入探讨其在流水线缓存(以 Python 项目为例)和构建镜像方面的应用,特别是在 Kubernetes(K8s)环境中的使用。

一、什么是 GitLab Runner

GitLab Runner 是一个开源项目,用于在不同的环境中运行 GitLab CI/CD 管道中的作业。它可以安装在多种操作系统上,并支持多种执行方式,如 Shell、Docker、Kubernetes 等。通过配置不同的执行器,用户可以根据项目需求灵活选择最合适的运行环境。

二、流水线缓存(Pipeline Cache)

在 CI/CD 流水线中,频繁的下载依赖和构建步骤可能会消耗大量时间。GitLab Runner 提供了缓存机制,能够缓存某些文件或目录,供后续作业使用,从而加快流水线的执行速度。以下以 Python 项目构建为例,展示如何配置流水线缓存。

需要注意的是:在一个代码项目中,构建容器会产生两个挂载目录。

一个是存储仓库项目源码与构建产生的文件,一个是设置的缓存目录 key/cache.zip,就是产生的缓存文件,那么对于重复可利用的文件,就可放入到你设置的目录中,在后续的作业中引用该目录即可。

1. 为什么使用缓存

在没有缓存的情况下,每次流水线运行都会重新创建虚拟环境并安装所有依赖,这不仅耗时还增加了构建失败的风险。通过缓存 venv/.cache/pip/ 目录,可以显著减少依赖安装的时间,因为这些文件在第一次构建后会被保存并在后续构建中重用。

2. 使用与不使用缓存的时间对比

为了直观展示缓存的效果,假设有一个中等规模的 Python 项目,包含多个依赖包。以下是使用缓存与不使用缓存的构建时间对比:

场景

依赖安装时间

总构建时间

不使用缓存

120 秒

180 秒

使用缓存

30 秒

90 秒

时间节省

75%

50%



3. 配置缓存

.gitlab-ci.yml 中,通过 cache 关键字配置需要缓存的路径。例如,缓存 Python 项目的 venv 目录和 pip 缓存:以下为gitlab官方示例

image: python:latest
# Change pip's cache directory to be inside the project directory since we can
# only cache local items.
variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
##https://pip.pypa.io/en/stable/topics/caching/
cache:
   paths:
     - .cache/pip
before_script:
  - python --version ; pip --version  # For debugging
  - pip install virtualenv
  - virtualenv venv
run:
  script:
    - pip install .
    # run the command here a
  artifacts:
    paths:
      - build/*
deploy:
  stage: deploy
  script: echo "Define your deployment script!"
  environment: production

2. 解释

  • key:使用 $CI_COMMIT_REF_SLUG 作为缓存键,确保不同分支或标签有独立的缓存,防止依赖冲突。
  • paths:指定需要缓存的目录,如 venv/ .cache/pip/,以加快后续作业的依赖安装速度。

3. 缓存策略

GitLab 提供多种缓存策略,可以根据项目需求和基础设施选择最合适的方案:

  • local:缓存存储在 Runner 本地,对于单 Runner 或低频次的流水线适用。
  • s3:使用 Amazon S3 作为缓存存储,适合分布式 Runner 环境。也可使用阿里云OSS作为缓存
  • gcs:使用 Google Cloud Storage 作为缓存存储,适合云环境的 CI/CD 流水线。

在 Kubernetes 环境中,可以结合对象存储服务(如 S3、GCS)配置缓存,提升缓存的可用性和访问速度。

4. 示例:Python 项目构建

完整的 .gitlab-ci.yml 示例:

stages:
  - setup
  - test
  - build
variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - venv/
    - .cache/pip/
setup_job:
  stage: setup
  image: python:3.9
  script:
    - python3 -m venv venv
    - source venv/bin/activate
    - pip install --upgrade pip
    - pip install -r requirements.txt
test_job:
  stage: test
  image: python:3.9
  script:
    - source venv/bin/activate
    - pytest
build_job:
  stage: build
  image: python:3.9
  script:
    - source venv/bin/activate
    - python setup.py sdist bdist_wheel
  artifacts:
    paths:
      - dist/

在这个示例中:

  • setup_job:创建虚拟环境并安装依赖,缓存 venv/ 和 pip 缓存目录 .cache/pip/
  • test_job:使用缓存的虚拟环境运行测试,避免重复安装依赖。
  • build_job:构建 Python 包,并使用 artifacts 存储构建产物。

三、构建镜像(Building Images)

在现代应用开发中,容器化已成为主流趋势。GitLab Runner 支持在流水线中构建 Docker 镜像,并将其推送到镜像仓库。通常在集群中构建镜像有两种方式,Docker in Docker或者Kaniko,而后者更加高效,故以下步骤展示如何在 Gitlab runner的Kubernetes 环境中使用Kaniko构建和推送 Docker 镜像。

1. 使用 k8s 执行器

要在流水线中使用 集群,首先需要将 Runner 的执行器类型设置为 kubernates。在 Kubernetes 环境中,推荐使用 kaniko方式,允许在 Runner Pod 中运行 Docker 服务。

2. 配置 Runner

在 GitLab Runner 的 config.toml 文件中,配置 Docker 执行器和 DinD 服务。例如:

[[runners]]
  name = "k8s-runner"
  token = "YOUR_REGISTRATION_TOKEN"
  executor = "kubernetes"
  [runners.kubernetes]
    namespace =  "{{.Release.Namespace}}"
    cpu_limit = "2"
    cpu_request = "2"
    memory_limit = "4Gi"
    memory_request = "4Gi"
    pod_labels_overwrite_allowed = ".*"
    [runners.kubernetes.pod_labels]
      "alibabacloud.com/compute-qos" = "best-effort"
      "alibabacloud.com/compute-class" = "general-purpose"
      "alibabacloud.com/eci" = "true"
  • cpu_request:Job调度时申请的Pod的CPU核数
  • memory_request:Job调度时申请的Pod的内存限制
  • runners.kubernetes.pod_labels:Pod上具有的一些标签,如在阿里云ACK中运行时可申请性价比最高的Pod。

3. 编写构建镜像的作业

.gitlab-ci.yml 中定义构建和推送 Docker 镜像的作业。例如:

stages:          # List of stages for jobs, and their order of execution
  - build
  - test
  - deploy
variables:
  KUBERNETES_POD_LABELS_1: "alibabacloud.com/compute-class=general-purpose"
  KUBERNETES_POD_LABELS_2: "alibabacloud.com/compute-qos=best-effort"
build-job:       # This job runs in the build stage, which runs first.
  stage: build
  cache:
    key: test
    paths:
      - target/
  image:
    name: registry.cn-hangzhou.aliyuncs.com/acs-demo-ns/kaniko-executor:v1.21.0-amd64-debug
    entrypoint: [""] 
  script:
    - echo "{\"auths\":{\"${ACR_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor
      --context "$CI_PROJECT_DIR"
      --dockerfile "$CI_PROJECT_DIR/Dockerfile"
      --destination ${ACR_REGISTRY}:latest
      --cache=true

4. 安全认证

为了确保镜像推送的安全性,需要在 GitLab 的项目设置中配置以下变量:

  • CI_REGISTRY_USER:镜像仓库的用户名。
  • CI_REGISTRY_PASSWORD:镜像仓库的密码或访问令牌。
  • ACR_REGISTRY:仓库地址

这些变量可在项目的 Settings > CI/CD > Variables 中配置,并确保设置为 Protected,避免在非受保护分支泄露。

5. 详细解释

  • variables:定义镜像名称变量,便于重复使用。里面可定义Pod的标签
  • build-job
  • 从项目中取出变量进行替换,如CI_REGISTRY_USER等
  • 基于替换后的变量登录到阿里云镜像仓库。
  • /kaniko/executor:调用Kaniko进行镜像构建,并使用层缓存
  • 如果这个时候是通过Maven构建,那么同样可以将相关的Jar包依赖缓存下来,减少流水线执行时间。
  • 以下是使用了Kaniko层级缓存和未使用缓存的对比效果图。
  • 使用了缓存后,构建时间缩短为不足原来的一半,这个是个小项目,如果是更大型镜像的构建,那么可优化的时间则会更多。

7. 完整示例

完整的 .gitlab-ci.yml 配置如下:

stages:          # List of stages for jobs, and their order of execution
  - build
  - test
  - deploy
variables:
  KUBERNETES_POD_LABELS_1: "alibabacloud.com/compute-class=general-purpose"
  KUBERNETES_POD_LABELS_2: "alibabacloud.com/compute-qos=best-effort"
build-job:       # This job runs in the build stage, which runs first.
  stage: build
  cache:
    key: test
    paths:
      - target/
  image:
    name: registry.cn-hangzhou.aliyuncs.com/acs-demo-ns/kaniko-executor:v1.21.0-amd64-debug
    entrypoint: [""] 
  script:
    - echo "{\"auths\":{\"${ACR_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor
      --context "$CI_PROJECT_DIR"
      --dockerfile "$CI_PROJECT_DIR/Dockerfile"
      --destination ${ACR_REGISTRY}:latest
      --cache=true
unit-test-job:   # This job runs in the test stage.
  stage: test    # It only starts when the job in the build stage completes successfully.
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 60
    - echo "Code coverage is 90%"
lint-test-job:   # This job also runs in the test stage.
  stage: test    # It can run at the same time as unit-test-job (in parallel).
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 10
    - echo "No lint issues found."
deploy-job:      # This job runs in the deploy stage.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  environment: production
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."

四、总结

GitLab Runner 是 GitLab CI/CD 流水线的执行引擎,具备强大的功能和灵活的配置能力。在 Kubernetes 环境下部署 GitLab Runner,可以充分利用 Kubernetes 的扩展性和管理能力,实现 Runner 的自动伸缩和高可用性。通过合理配置流水线缓存(以 Python 项目为例)和构建镜像,能够显著提升 CI/CD 流水线的效率和可靠性。无论是小型项目还是大型企业级应用,GitLab Runner 在 Kubernetes 上的应用都能提供稳健的支持,助力开发团队实现持续集成与持续交付的目标。

五、一键部署

部署流程

  1. 访问计算巢 部署链接,按提示填写部署参数
  2. 填写是否新建或选择已有的集群 image.png
  3. 填写Helm配置 image.png
  4. 第一个参数为该Helm应用运行的命名空间,默认值为gitlab runner
  5. 第二个参数为Chart values,即Helm应用运行是要的参数。注意此处必须将内部参数的GitlabUrl和GitlabRunnerToken进行替换
  6. GitlabUrl是您的Gitlab对外暴露的地址,GitlabRunnerToken为Gitlab处注册的runner的token,用于Gitlab和Runner进行认证,获取Token可参考下两图所示: image.png

新建Runner

image.png

  1. 注册在Gitlab处成功创建好Runner的示意图如图所示,注意当前界面关闭后则无法再次查看Token: image.png
  2. 默认配置的值中,concurrent为并发作业数量,如当前并未部署自己的Gitlab可以采用官方的地址,即填写:https://gitlab.com。
  3. 注意:Gitlab Runner的manager节点和被调度的job节点都工作在{{.Release.Namespace}}下,请不要对此项配置进行修改,否则会出现权限问题。
  4. 其他参数的调整可参考官方文档
  5. 点击立即创建,等待服务实例部署完成 image.png
  6. 服务实例部署完成后,点击实例ID进入到详情界面,如图所示,提示已经部署成功 image.png
  7. 接下来就可以在原Gitlab中创建流水线和执行了

更多有意思,又好玩又有深度的服务,请访问计算巢网址

相关实践学习
Docker镜像管理快速入门
本教程将介绍如何使用Docker构建镜像,并通过阿里云镜像服务分发到ECS服务器,运行该镜像。
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
5月前
|
机器学习/深度学习 文字识别 监控
安全监控系统:技术架构与应用解析
该系统采用模块化设计,集成了行为识别、视频监控、人脸识别、危险区域检测、异常事件检测、日志追溯及消息推送等功能,并可选配OCR识别模块。基于深度学习与开源技术栈(如TensorFlow、OpenCV),系统具备高精度、低延迟特点,支持实时分析儿童行为、监测危险区域、识别异常事件,并将结果推送给教师或家长。同时兼容主流硬件,支持本地化推理与分布式处理,确保可靠性与扩展性,为幼儿园安全管理提供全面解决方案。
217 3
|
6月前
|
人工智能 API 开发者
HarmonyOS Next~鸿蒙应用框架开发实战:Ability Kit与Accessibility Kit深度解析
本书深入解析HarmonyOS应用框架开发,聚焦Ability Kit与Accessibility Kit两大核心组件。Ability Kit通过FA/PA双引擎架构实现跨设备协同,支持分布式能力开发;Accessibility Kit提供无障碍服务构建方案,优化用户体验。内容涵盖设计理念、实践案例、调试优化及未来演进方向,助力开发者打造高效、包容的分布式应用,体现HarmonyOS生态价值。
269 27
|
6月前
|
供应链 项目管理 容器
深入探索 BPMN、CMMN 和 DMN:从定义到应用的全方位解析
在当今快速变化的商业环境中,对象管理组织(OMG)推出了三种强大的建模标准:BPMN(业务流程模型和符号)、CMMN(案例管理模型和符号)和DMN(决策模型和符号)。它们分别适用于结构化流程管理、动态案例处理和规则驱动的决策制定,并能相互协作,覆盖更广泛的业务场景。BPMN通过直观符号绘制固定流程;CMMN灵活管理不确定的案例;DMN以表格形式定义清晰的决策规则。三者结合可优化企业效率与灵活性。 [阅读更多](https://example.com/blog)
深入探索 BPMN、CMMN 和 DMN:从定义到应用的全方位解析
|
6月前
|
存储 弹性计算 安全
阿里云服务器ECS通用型规格族解析:实例规格、性能基准与场景化应用指南
作为ECS产品矩阵中的核心序列,通用型规格族以均衡的计算、内存、网络和存储性能著称,覆盖从基础应用到高性能计算的广泛场景。通用型规格族属于独享型云服务器,实例采用固定CPU调度模式,实例的每个CPU绑定到一个物理CPU超线程,实例间无CPU资源争抢,实例计算性能稳定且有严格的SLA保证,在性能上会更加稳定,高负载情况下也不会出现资源争夺现象。本文将深度解析阿里云ECS通用型规格族的技术架构、实例规格特性、最新价格政策及典型应用场景,为云计算选型提供参考。
|
6月前
|
数据采集 机器学习/深度学习 存储
可穿戴设备如何重塑医疗健康:技术解析与应用实战
可穿戴设备如何重塑医疗健康:技术解析与应用实战
191 4
|
6月前
|
人工智能 自然语言处理 算法
DeepSeek大模型在客服系统中的应用场景解析
在数字化浪潮下,客户服务领域正经历深刻变革,AI技术成为提升服务效能与体验的关键。DeepSeek大模型凭借自然语言处理、语音交互及多模态技术,显著优化客服流程,提升用户满意度。它通过智能问答、多轮对话引导、多模态语音客服和情绪监测等功能,革新服务模式,实现高效应答与精准分析,推动人机协作,为企业和客户创造更大价值。
560 5
|
6月前
|
机器学习/深度学习 JSON 算法
淘宝拍立淘按图搜索API接口系列的应用与数据解析
淘宝拍立淘按图搜索API接口是阿里巴巴旗下淘宝平台提供的一项基于图像识别技术的创新服务。以下是对该接口系列的应用与数据解析的详细分析
|
6月前
|
机器学习/深度学习 人工智能 自然语言处理
DeepSeek 实践应用解析:合力亿捷智能客服迈向 “真智能” 时代
DeepSeek作为人工智能领域的创新翘楚,凭借领先的技术实力,在智能客服领域掀起变革。通过全渠道智能辅助、精准对话管理、多语言交互、智能工单处理、个性化推荐、情绪分析及反馈监控等功能,大幅提升客户服务效率和质量,助力企业实现卓越升级,推动智能化服务发展。
236 1
|
7月前
|
存储 人工智能 程序员
通义灵码AI程序员实战:从零构建Python记账本应用的开发全解析
本文通过开发Python记账本应用的真实案例,展示通义灵码AI程序员2.0的代码生成能力。从需求分析到功能实现、界面升级及测试覆盖,AI程序员展现了需求转化、技术选型、测试驱动和代码可维护性等核心价值。文中详细解析了如何使用Python标准库和tkinter库实现命令行及图形化界面,并生成单元测试用例,确保应用的稳定性和可维护性。尽管AI工具显著提升开发效率,但用户仍需具备编程基础以进行调试和优化。
520 9
|
7月前
|
开发框架 监控 JavaScript
解锁鸿蒙装饰器:应用、原理与优势全解析
ArkTS提供了多维度的状态管理机制。在UI开发框架中,与UI相关联的数据可以在组件内使用,也可以在不同组件层级间传递,比如父子组件之间、爷孙组件之间,还可以在应用全局范围内传递或跨设备传递。
147 2

推荐镜像

更多