欢迎访问我的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 helm 部署挂载存储 gitlab runner helm_kubernetes

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后登录成功:
  2. 如下图,点击红框中的图标,创建一个bucket,名为runner:
  3. 至此,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:
  2. gitlab helm 部署挂载存储 gitlab runner helm_minio_02

  3. 稍后就会执行成功,点开看结果:
  4. gitlab helm 部署挂载存储 gitlab runner helm_gitlab helm 部署挂载存储_03

  5. 点开build1的图标,可见此job的输出信息:
  6. gitlab helm 部署挂载存储 gitlab runner helm_gitlab ci_04

  7. 点开test1的图标,可见对应的控制台输出,上一个job写入的数据被成功读取:
  8. gitlab helm 部署挂载存储 gitlab runner helm_kubernetes_05

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