让 gitlab runner 支持阿里云 OSS 缓存

Gitlab Runner 容器部署

这个其实是去年的工作, 这里整理一下.

gitlab runner 是 gitlab 官方的 CI/CD 任务执行工具, 类似于 jekins 的 agent. 常见的场景是在 k8s 集群上部署 runner, 分布式执行 CI/CD 任务. 对于编译打包项目, 各种工具一般都在本地有一个目录, 缓存需要下载的依赖或者编译的中间结果, 以加速这个过程. 举例如 Maven 的 .m2 目录, 或者 pip 默认的 ~/.pip/cache, 由于 gitlab 的 CI/CD 一般是分布执行. 由于每次执行都要创建一个全新的环境, 那么利用各种云计算厂商提供的块存储(block storage)或者对象存储(object storage)服务, 来缓存这些目录就显得十分必要了.

尴尬的是 gitlab runner 这个缓存支持对于非主流的云计算厂商并不友好.

Gitlab Runner 当前对对象存储的支持

gitlab runner 最早的版本, 应该是在 2015 年开始有 cache 功能支持对象存储, 最早是支持 amazon S3, 后在 2018 年又加入了 Google GCS 支持; 2019 年又开始加入 azure 支持. 由于加入了对 azure 的支持, 代码的结果有一些变更. 其实想要增加新的厂商的用对象存储相对就简单一些.

只需要在 cache 目录中加入新的 adaptor, 并且相应在 common/config.go 定义新的配置结构就好了.

另外, 对于其它云计算厂商, gitlab runner 目前推荐使用 S3 的兼容网关 minio, 当然, 比较尴尬的是, 最近 minio 将 aliyun oss gateway 的支持剔除了(minio PR#9390).

这两个因素让我觉得可以试一下给 gitlab runner 加入 OSS 支持.

增加对 OSS 的支持

添加代码还是挺简单的, 不过这是 golang 写的, 这个项目 golang 的包管理的问题, 导致引入新的依赖会增加不少代码. 这些全放到了 vendor 目录里.

不过最新的 1.16 出来以后, GOPATH 好像成了历史. 不知道 gitlab 那边会怎么迁移这个项目, 这个可以观察一下.

当时我提了一个 MR(gitlab runner MR#2433), 然后被否了. 不过也在预料之中. 引入新的依赖看上去简单, 但是增加的代码未免太多.

实际运行起来还算可以. 我自己打了一个镜像, 可以直接使用 zhping/gitlab-runner:alpine-v13.3.1_p5.

另外执行的时候, 需要配置以下环境变量: CACHE_TYPE, CACHE_PATH, CACHE_SHARED, CACHE_OSS_SERVER_ADDRESS, CACHE_OSS_BUCKET_NAME, CACHE_OSS_ACCESS_KEY, CACHE_OSS_SECRET_KEY.