Gitlab Runner的分布式缓存实战

欢迎访问我的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. 接下来通过实战完成分布式缓存配置；

环境和版本信息

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

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

4. 执行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

5. 浏览器访问，输入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

8. 配置完毕，启动Riglab Runner成功后，一起来验证一下；

验证

1. 在GitLab仓库中，增加名为.gitlab-ci.yml的文件，内容如下：

# 设置执行镜像image: busybox:latest# 整个pipeline有两个stagestages:- 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.txttest1: stage: test script: - echo "从缓存读取内容" - cat vendor/hello.txt

2. 提交上述脚本到GitLab，如下图，可见pipeline会被触发，状态为pending是因为正在等待runner创建executor pod：

3. 稍后就会执行成功，点开看结果：

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

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

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

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

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

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

微信搜索「程序员欣宸」，我是欣宸，期待与您一同畅游Java世界...
https://github.com/zq2599/blog_demos

原文转载：http://www.shaoqun.com/a/504409.html

跨境电商：https://www.ikjzd.com/

skyee：https://www.ikjzd.com/w/290

鸥鹭：https://www.ikjzd.com/w/2568

欢迎访问我的GitHubhttps://github.com/zq2599/blog_demos内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；关于本文本文目标是为K8S环境的GitlabRunner准备好分布式缓存，并在pipeline脚本中使用该缓存，因此，在阅读本文前建议您对GitLabCI有一定了解，最好是阅读过甚至编写过pipeli
贝恩资本：贝恩资本
马士基航运：马士基航运
疫情天下事（2月11日）：足不出户尽掌跨境电商要闻：疫情天下事（2月11日）：足不出户尽掌跨境电商要闻
僰王山有吃饭的地方吗?宜宾僰王山农家乐哪家好?：僰王山有吃饭的地方吗?宜宾僰王山农家乐哪家好?
eBay物流新安排：橙联SpeedPAK将于5月1日全线休息！：eBay物流新安排：橙联SpeedPAK将于5月1日全线休息！