Gitlab Runner的分布式缓存实战

欢迎访问我的GitHub

github.com/zq2599/blog…

内容:所有原创文章分类汇总及配套源码,涉及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
复制代码
  1. 接下来通过实战完成分布式缓存配置;

环境和版本信息

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

  1. GitLab:Community Edition 13.0.6
  2. GilLab Runner:13.1.0
  3. kubernetes:1.15.3
  4. Harbor:1.1.3
  5. Minio:2020-06-18T02:23:35Z
  6. Helm:2.16.1

部署分布式缓存

  1. minio是兼用S3的分布式缓存,也是官方推荐使用的,如下图:

2. minio作为一个独立的服务部署,我将用docker部署在服务器:192.168.50.43 3. 在服务器上准备两个目录,分别存储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后登录成功:

6. 如下图,点击红框中的图标,创建一个bucket,名为runner: 7. 至此,minio已备好,接下来在GitLab Runner上配置;

GitLab Runner上配置缓存

  1. 我这里是用helm部署的GitLab Runner,因此修改的是helm的value配置,如果您没有用helm,可以参考接下来的操作直接去配置config.toml文件;
  2. helm下载了GitLab Runner的包后,解开可见配置信息如下:

3. 打开values.yaml,找到cache的配置,当前cache的配置如下图,可见值为空内容的大括号,其余信息全部被注释了:

4. 修改后的cache配置如下图,红框1中原先的大括号已去掉,红框2中的是去掉了注释符号,内容不变,红框3中填写的是minio的访问地址,红框4中的是去掉了注释符号,内容不变:

5. 上图红框4中的s3CacheInsecure参数等于false表示对minio的请求为http(如果是true就是https),但实际证明,当前版本的chart中该配置是无效的,等到运行时还是会以https协议访问,解决此问题的方法是修改templates目录下的_cache.tpl文件,打开此文件,找到下图红框中的内容:

6. 将上图红框中的内容替换成下面红框中的样子,即删除原先的if判断和对应的end这两行,直接给CACHE_S3_INSECURE赋值:

7. 以上只是cache相关的配置,helm部署GitLab Runner的其他设置还请自行处理,所有设置完成后回到values.yam所在目录,执行以下命令即可创建GitLab Runner:

helm install \
--name-template gitlab-runner \
-f values.yaml . \
--namespace gitlab-runner
复制代码
  1. 配置完毕,启动Riglab Runner成功后,一起来验证一下;

验证

  1. 在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:
  1. 稍后就会执行成功,点开看结果:

4. 点开build1的图标,可见此job的输出信息:

5. 点开test1的图标,可见对应的控制台输出,上一个job写入的数据被成功读取:

  1. 至此,可见分布式缓存已经生效,在多台机器的环境中也可以使用pipeline语法的缓存功能了;

你不孤单,欣宸原创一路相伴

  1. Java系列
  2. Spring系列
  3. Docker系列
  4. kubernetes系列
  5. 数据库+中间件系列
  6. DevOps系列

欢迎关注公众号:程序员欣宸

微信搜索「程序员欣宸」,我是欣宸,期待与您一同畅游Java世界…

github.com/zq2599/blog…

稀土掘金
我还没有学会写个人说明!
上一篇

《守望先锋2》新地图、英雄新造型、敌方单位公布

下一篇

Hive动态分区详解,你知道吗?

你也可能喜欢

评论已经被关闭。

插入图片