关于云计算: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