Gitlab Runner的分布式缓存实战

简介: 配置兼容S3的分布式缓存minio,在k8s环境支持Gitlab CI脚本的缓存语法

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos
内容:所有原创文章分类汇总及配套源码,涉及Java、Docker、Kubernetes、DevOPS等;

关于本文

本文目标是为K8S环境的Gitlab Runner准备好分布式缓存,并在pipeline脚本中使用该缓存,因此,在阅读本文前建议您对GitLab CI有一定了解,最好是阅读过甚至编写过pipeline脚本;

关于GitLab Runner

如下图所示,开发者将代码提交到GitLab后,可以触发CI脚本在GitLab Runner上执行,通过编写CI脚本我们可以完成很多使用的功能:编译、构建、生成docker镜像、推送到私有仓库等:
在这里插入图片描述

Gitlab Runner的分布式缓存

  1. 官方文档地址,有关缓存的详情可以参考此文:https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching
  2. 如下是官方的分布式缓存示例(config.toml 文件):

    [[runners]]
    limit = 10
    executor = "docker+machine"
    [runners.cache]
     Type = "s3"
     Path = "path/to/prefix"
     Shared = false
     [runners.cache.s3]
       ServerAddress = "s3.example.com"
       AccessKey = "access-key"
       SecretKey = "secret-key"
       BucketName = "runner"
       Insecure = false
    
  3. 接下来通过实战完成分布式缓存配置;

    环境和版本信息

    本次实战涉及到多个服务,下面给出它们的版本信息供您参考:

  4. GitLab:Community Edition 13.0.6

  5. GilLab Runner:13.1.0
  6. kubernetes:1.15.3
  7. Harbor:1.1.3
  8. Minio:2020-06-18T02:23:35Z
  9. Helm:2.16.1

    部署分布式缓存

  10. minio是兼用S3的分布式缓存,也是官方推荐使用的,如下图:
    在这里插入图片描述
  11. minio作为一个独立的服务部署,我将用docker部署在服务器:192.168.50.43
  12. 在服务器上准备两个目录,分别存储minio的配置和文件,执行以下命令:
mkdir -p /var/services/homes/zq2599/minio/gitlab_runner \
&& chmod -R 777 /var/services/homes/zq2599/minio/gitlab_runner \
&& mkdir -p /var/services/homes/zq2599/minio/config \
&& chmod -R 777 /var/services/homes/zq2599/minio/config
  1. 执行docker命令创建minio服务,指定服务端口是9000,并且指定了access key(最短三位)和secret key(最短八位):
sudo docker run -p 9000:9000 --name minio \
-d --restart=always \
-e "MINIO_ACCESS_KEY=access" \
-e "MINIO_SECRET_KEY=secret123456" \
-v /var/services/homes/zq2599/minio/gitlab_runner:/gitlab_runner \
-v /var/services/homes/zq2599/minio/config:/root/.minio \
minio/minio server /gitlab_runner
  1. 浏览器访问,输入access key和secret key后登录成功:
    在这里插入图片描述
  2. 如下图,点击红框中的图标,创建一个bucket,名为runner:
    在这里插入图片描述
  3. 至此,minio已备好,接下来在GitLab Runner上配置;

    GitLab Runner上配置缓存

  4. 我这里是用helm部署的GitLab Runner,因此修改的是helm的value配置,如果您没有用helm,可以参考接下来的操作直接去配置config.toml文件;
  5. helm下载了GitLab Runner的包后,解开可见配置信息如下:
    在这里插入图片描述
  6. 打开values.yaml,找到cache的配置,当前cache的配置如下图,可见值为空内容的大括号,其余信息全部被注释了:
    在这里插入图片描述
  7. 修改后的cache配置如下图,红框1中原先的大括号已去掉,红框2中的是去掉了注释符号,内容不变,红框3中填写的是minio的访问地址,红框4中的是去掉了注释符号,内容不变:
    在这里插入图片描述
  8. 上图红框4中的s3CacheInsecure参数等于false表示对minio的请求为http(如果是true就是https),但实际证明,当前版本的chart中该配置是无效的,等到运行时还是会以https协议访问,解决此问题的方法是修改templates目录下的_cache.tpl文件,打开此文件,找到下图红框中的内容:
    在这里插入图片描述
  9. 将上图红框中的内容替换成下面红框中的样子,即删除原先的if判断和对应的end这两行,直接给CACHE_S3_INSECURE赋值:
    在这里插入图片描述
  10. 以上只是cache相关的配置,helm部署GitLab Runner的其他设置还请自行处理,所有设置完成后回到values.yam所在目录,执行以下命令即可创建GitLab Runner:
helm install \
--name-template gitlab-runner \
-f values.yaml . \
--namespace gitlab-runner
  1. 配置完毕,启动Riglab Runner成功后,一起来验证一下;

    验证

  2. 在GitLab仓库中,增加名为.gitlab-ci.yml的文件,内容如下:
# 设置执行镜像
image: busybox:latest

# 整个pipeline有两个stage
stages:
- build
- test

# 定义全局缓存,缓存的key来自分支信息,缓存位置是vendor文件夹
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
  - vendor/

before_script:
  - echo "Before script section"

after_script:
  - echo "After script section"

build1:
  stage: build
    tags:
  - k8s
  script:
    - echo "将内容写入缓存"
    - echo "build" > vendor/hello.txt

test1:
  stage: test
  script:
    - echo "从缓存读取内容"
    - cat vendor/hello.txt
  1. 提交上述脚本到GitLab,如下图,可见pipeline会被触发,状态为pending是因为正在等待runner创建executor pod:
    在这里插入图片描述

  2. 稍后就会执行成功,点开看结果:
    在这里插入图片描述

  3. 点开build1的图标,可见此job的输出信息:
    在这里插入图片描述
  4. 点开test1的图标,可见对应的控制台输出,上一个job写入的数据被成功读取:
    在这里插入图片描述
  5. 至此,可见分布式缓存已经生效,在多台机器的环境中也可以使用pipeline语法的缓存功能了;

欢迎关注阿里云开发者社区:程序员欣宸

学习路上,你不孤单,欣宸原创一路相伴...

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
2月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
4月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
340 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
10天前
|
存储 缓存 NoSQL
Redis专题-实战篇二-商户查询缓存
本文介绍了缓存的基本概念、应用场景及实现方式,涵盖Redis缓存设计、缓存更新策略、缓存穿透问题及其解决方案。重点讲解了缓存空对象与布隆过滤器的使用,并通过代码示例演示了商铺查询的缓存优化实践。
73 1
Redis专题-实战篇二-商户查询缓存
|
4月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
168 11
|
6月前
|
数据采集 存储 数据可视化
分布式爬虫框架Scrapy-Redis实战指南
本文介绍如何使用Scrapy-Redis构建分布式爬虫系统,采集携程平台上热门城市的酒店价格与评价信息。通过代理IP、Cookie和User-Agent设置规避反爬策略,实现高效数据抓取。结合价格动态趋势分析,助力酒店业优化市场策略、提升服务质量。技术架构涵盖Scrapy-Redis核心调度、代理中间件及数据解析存储,提供完整的技术路线图与代码示例。
601 0
分布式爬虫框架Scrapy-Redis实战指南
|
2月前
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
分布式新闻数据采集系统的同步效率优化实战
|
2月前
|
存储 缓存 安全
Go语言实战案例-LRU缓存机制模拟
本文介绍了使用Go语言实现LRU缓存机制的方法。LRU(最近最少使用)是一种常见缓存淘汰策略,当缓存满时,优先删除最近最少使用的数据。实现中使用哈希表和双向链表结合的方式,确保Get和Put操作均在O(1)时间内完成。适用于Web缓存、数据库查询优化等场景。
|
3月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
1026 7
|
8月前
|
缓存 Kubernetes Docker
GitLab Runner 全面解析:Kubernetes 环境下的应用
GitLab Runner 是 GitLab CI/CD 的核心组件,负责执行由 `.gitlab-ci.yml` 定义的任务。它支持多种执行方式(如 Shell、Docker、Kubernetes),可在不同环境中运行作业。本文详细介绍了 GitLab Runner 的基本概念、功能特点及使用方法,重点探讨了流水线缓存(以 Python 项目为例)和构建镜像的应用,特别是在 Kubernetes 环境中的配置与优化。通过合理配置缓存和镜像构建,能够显著提升 CI/CD 流水线的效率和可靠性,助力开发团队实现持续集成与交付的目标。