Gitlab Cache Server Configuration Bug

gitlab version: gitlab helm chart 2.3.2，此版本前後應該都有這個問題。

使用 helm charts 安裝完成後，使用 CI/CD 功能時，發現 job日誌中關於 cache 的部分給出如下信息：

Checking cache for develop...
No URL provided, cache will not be downloaded from shared cache server. Instead a local version of cache will be extracted. 

Creating cache develop...
/builds/fengxin58/echoheader/.m2/repository/: found 2126 matching files 
No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally. 
Created cache

在 gitlab runner pod 的日誌中發現如下的日誌：

error while generating S3 pre-signed URL

在 gitlab runner 源碼中查詢如上的關鍵字，定位到 gitlab runner 源碼的 cache 部分。
通過查看 gitlab runner 源碼得知，git runner 使用 minio-go 作爲支持 s3 協議的存儲的客戶端。

於是查找 gitlab runner 源碼和 minio-go 參考文檔，查看 gitlab runner 中是如何使用 minio-go 這個 s3 協議的 sdk的。

查找 minio-go 的用法，得知 minio-go 中初始化一個 MinIO Client（S3 Client）必備的參數有 CACHE_S3_SERVER_ADDRESS，CACHE_S3_ACCESS_KEY 和 CACHE_S3_SECRET_KEY ，還有一個是否開啓 SSL 的標識。

根據 gitlab 中的慣例，查看 gitlab runner pod 的環境變量，發現只有 CACHE_S3_SERVER_ADDRESS，沒有 CACHE_S3_ACCESS_KEY 和 CACHE_S3_SECRET_KEY 的值。

gitlab helm charts 安裝時，會生成名爲 {deploy-name}-minio-secret 的 kubernetes secret ，裏面存儲的就是 minio server 的 用戶名和密碼（accesskey 和 secretkey）。於是猜測可能是 gitlab runner 啓動時自動讀取的這個 secret 裏的內容，這樣可以不需要外部設置環境變量。

查找 gitlab runner 的啓動文件，在 gitlab runner 中查找到此鏡像的入口文件內容如下：

    #!/bin/bash
    set -e
    mkdir -p /home/gitlab-runner/.gitlab-runner/
    cp /scripts/config.toml /home/gitlab-runner/.gitlab-runner/

    # Register the runner
    if [[ -f /secrets/accesskey && -f /secrets/secretkey ]]; then
      export CACHE_S3_ACCESS_KEY=$(cat /secrets/accesskey)
      export CACHE_S3_SECRET_KEY=$(cat /secrets/secretkey)
    fi

    if [[ -f /secrets/gcs-applicaton-credentials-file ]]; then
      export GOOGLE_APPLICATION_CREDENTIALS="/secrets/gcs-applicaton-credentials-file"
    else
      if [[ -f /secrets/gcs-access-id && -f /secrets/gcs-private-key ]]; then
        export CACHE_GCS_ACCESS_ID=$(cat /secrets/gcs-access-id)
        # echo -e used to make private key multiline (in google json auth key private key is oneline with \n)
        export CACHE_GCS_PRIVATE_KEY=$(echo -e $(cat /secrets/gcs-private-key))
      fi
    fi

    if [[ -f /secrets/runner-registration-token ]]; then
      export REGISTRATION_TOKEN=$(cat /secrets/runner-registration-token)
    fi

    if [[ -f /secrets/runner-token ]]; then
      export CI_SERVER_TOKEN=$(cat /secrets/runner-token)
    fi

    if ! sh /scripts/register-the-runner; then
      exit 1
    fi

    # Start the runner
    exec /entrypoint run --user=gitlab-runner \
      --working-directory=/home/gitlab-runner

在 pod 中訪問 kubernetes secret 的內容只有一種方式，就是將 secret 掛載到 pod 中，於是去查看 gitlab runner 的 deployment 文件，發現沒有掛載 minio-secret 這個 secret。

在 gitlab runner 中使用 env 命令查看所有的環境變量，再次驗證 CACHE_S3_ACCESS_KEY 和 CACHE_S3_SECRET_KEY 確實沒有。

可以確認是 gitlab 忘記掛載了這個 secret 。

知道了問題。對症下藥即可，找到 gitlab runner 的 deployment，可以使用如下的重新生成查看

$ helm install gitlab/gitlab -f values.yaml --dry-run --debug >> gitlab-tmp.yaml

找到 gitlab runner 的 deployment 部分，增加 {deploy-name}-minio-secret 的掛載即可。

也即可直接給 gitlab runner 添加 CACHE_S3_ACCESS_KEY 和 CACHE_S3_SECRET_KEY 兩個環境變量。gitlab runner 的 deployment 裏有很多的環境變量，增加上這兩個即可，值就是 {deploy-name}-minio-secret 這個 secret 的值。

參考

MinIO Go Client API Reference
gitlabhq/gitlab-runner