Gitlab Runner的分散式快取實戰

程式設計師欣宸發表於2020-12-29

Gitlab分散式快取

歡迎訪問我的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的分散式快取

官方文件地址，有關快取的詳情可以參考此文：https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching
如下是官方的分散式快取示例(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

接下來通過實戰完成分散式快取配置；

環境和版本資訊

本次實戰涉及到多個服務，下面給出它們的版本資訊供您參考：

GitLab：Community Edition 13.0.6
GilLab Runner：13.1.0
kubernetes：1.15.3
Harbor：1.1.3
Minio：2020-06-18T02:23:35Z
Helm：2.16.1

部署分散式快取

minio是兼用S3的分散式快取，也是官方推薦使用的，如下圖：
minio作為一個獨立的服務部署，我將用docker部署在伺服器：192.168.50.43
在伺服器上準備兩個目錄，分別儲存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

執行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

瀏覽器訪問，輸入access key和secret key後登入成功：
如下圖，點選紅框中的圖示，建立一個bucket，名為runner：
至此，minio已備好，接下來在GitLab Runner上配置；

GitLab Runner上配置快取

我這裡是用helm部署的GitLab Runner，因此修改的是helm的value配置，如果您沒有用helm，可以參考接下來的操作直接去配置config.toml檔案；
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

配置完畢，啟動Riglab Runner成功後，一起來驗證一下；

驗證

在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