关于云计算: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/runne…
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的分布式缓存，也是官网举荐应用的，如下图：

1. minio作为一个独立的服务部署，我将用docker部署在服务器：<font color=”blue”>192.168.50.43</font>
2. 在服务器上筹备两个目录，别离存储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后登录胜利：

1. 如下图，点击红框中的图标，创立一个bucket，名为runner：

1. 至此，minio已备好，接下来在GitLab Runner上配置；

GitLab Runner上配置缓存

1. 我这里是用helm部署的GitLab Runner，因而批改的是helm的value配置，如果您没有用helm，能够参考接下来的操作间接去配置<font color=”blue”>config.toml</font>文件；
2. helm下载了<font color=”blue”>GitLab Runner</font>的包后，解开可见配置信息如下：

1. 关上<font color=”blue”>values.yaml</font>，找到cache的配置，以后cache的配置如下图，可见值为空内容的大括号，其余信息全副被正文了：

1. 批改后的cache配置如下图，红框1中原先的大括号已去掉，红框2中的是去掉了正文符号，内容不变，红框3中填写的是minio的拜访地址，红框4中的是去掉了正文符号，内容不变：

1. 上图红框4中的<font color=”blue”>s3CacheInsecure</font>参数等于<font color=”red”>false</font>示意对minio的申请为http(如果是true就是https)，但实际证明，<font color=”red”>以后版本的chart中该配置是有效的</font>，等到运行时还是会以https协定拜访，解决此问题的办法是批改templates目录下的_cache.tpl文件，关上此文件，找到下图红框中的内容：

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

1. 以上只是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. 稍后就会执行胜利，点开看后果：

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

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

1. 至此，可见分布式缓存曾经失效，在多台机器的环境中也能够应用pipeline语法的缓存性能了；

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

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

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

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