带有minio服务的kubernetes上的gitlab-ci缓存不再起作用

本文介绍了带有minio服务的kubernetes上的gitlab-ci缓存不再起作用的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在将gitlab 10.4.3与gitlab-runner 10.4.0一起作为kubernetes部署与kubernetes Runner和用于缓存的minio服务器一起运行.我根据 gitlab文档进行安装

I'm running gitlab 10.4.3 with gitlab-runner 10.4.0 as a kubernetes deployment with kubernetes runner and a minio-server for caching. I installed it according to the gitlab docs.

将适当的设置添加到.gitlab-ci.yml-文件时，一切都能按预期使用缓存:

Everything worked with the cache as expected, when adding the appropriate settings to the .gitlab-ci.yml-file:

build:
  stage: build
  variables:
    GIT_STRATEGY: fetch
  cache:
    key: "$CI_BUILD_REF_NAME"
    paths:
      - node_modules/
  script:
    - compile-templates.sh
    - yarn install
    - yarn run build

管道输出确实第一次填充了缓存，并且随后在同一分支上的后续运行正确地拉入并推送了缓存:

The pipeline output did fill the cache the first time and subsequent runs on the same branch correctly pulled and pushed the cache:

Running on gitlab/runner-abcdefg-project-123-concurrent-123456 via gitlab-runner-123456-987654...
Cloning repository for feature/gitlab-cache with git depth set to 1...
Cloning into '/group/project'...
Checking out b1348594 as feature/gitlab-cache...
Skipping Git submodules setup
Checking cache for feature/gitlab-cache...
Downloading cache.zip from http://minio-service:9000/runner/runner/abcdefg/project/123/feature/gitlab-cache
Successfully extracted cache
$ docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
Login Succeeded
[...snip...]
Creating cache feature/gitlab-cache...
node_modules/: found 26281 matching files
Uploading cache.zip to http://minio-service:9000/runner/runner/abcdefg/project/123/feature/gitlab-cache
Created cache

但是，运行了一段时间后，它突然停止工作-我不知道为什么.我也尝试了一个作业全局缓存定义，但没有用-似乎gitlab-runner只是忽略了设置，只是跳过了检查缓存部分":

However, after some runs it suddenly stopped working - and I do not know why. I've also tried a job-global cache-definition to no avail - it seems that the gitlab-runner is simply ignoring the setting and just skips the "Checking cache part":

Running on gitlab/runner-abcdefg-project-123-concurrent-123456 via gitlab-runner-123456-987654...
Cloning repository for feature/gitlab-cache with git depth set to 1...
Cloning into '/group/project'...
Checking out b1348594 as feature/gitlab-cache...
Skipping Git submodules setup
$ docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
Login Succeeded
[...snip...]
Job succeeded

我的gitlab-runner config.toml具有适当的设置:

My gitlab-runner config.toml has the appropriate settings:

[[runners]]
  // ...
  [runners.kubernetes]
  // ...
  [runners.cache]
    Type = "s3"
    // I've also tried http://minio-service:9000 to no avail
    ServerAddress = "minio-service:9000"
    AccessKey = "xxxxxxxxxxxxxxxxxxxxxxxx"
    SecretKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    BucketName = "runner"
    Insecure = true

注意:如果将设置更改为无效的设置，则在跑步者日志中不会收到任何错误消息.

Note: If I change the settings to invalid ones, I do not get any error messages in the runners logs.

可以从跑步者本身和从作业吊舱到达端口:

The port is reachable from the runner itself and from job pods:

$ curl -s "http://minio-service:9000"
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Access Denied.</Message><Key></Key><BucketName></BucketName><Resource>/</Resource><RequestId>12345</RequestId><HostId>12345</HostId></Error>

通过minio客户端mc在本地卷和中选中的minio上的存储桶存在.

The bucket on minio exists as checked in the local volume and via the minio client mc.

gitlab-runner或minio-server的pod的日志中没有错误.

There are no errors in the logs of the pods of gitlab-runner or the minio-server.

这就像.gitlab-ci.yml的缓存设置被简单地忽略了一样，我对剩下的要检查的东西也一无所知.任何有想法的人吗?

It's just like the cache-settings of the .gitlab-ci.yml are simply ignored and I'm out of ideas on what's left to check. Anyone with any ideas?

推荐答案

因此，问题在于无效的文档以及对无效cache:keys的无提示忽略.如果分支是例如名为feature/some-new-thing的结果，"$CI_BUILD_REF_NAME"的键将导致无效的cache:key包含"/"字符-反过来将使整个cache-section无效，但将被忽略.

So, the problem was an invalid documentation in combination with a silent ignore of invalid cache:keys. If a branch is e.g. named feature/some-new-thing, the resulting key of "$CI_BUILD_REF_NAME" would lead to an invalid cache:key containing a "/"-character - which in turn would render the whole cache-section invalid, but which is silently ignored.

相反，只需使用"${CI_BUILD_REF_SLUG}"，它将包含url-safe-并因此包含cache:key-safe-分支名称的版本:

Instead, just use "${CI_BUILD_REF_SLUG}", which will contain an url-safe - and therefore cache:key-safe - version of the branch name:

cache:
  key: "${CI_BUILD_REF_SLUG}"
  paths:
    - node_modules/

错误报告已打开.

这篇关于带有minio服务的kubernetes上的gitlab-ci缓存不再起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

Some