Gitlab Runner的分佈式緩存實戰

歡迎訪問個人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的分佈式緩存

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

3. 接下來經過實戰完成分佈式緩存配置；

環境和版本信息

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

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

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

5. 瀏覽器訪問，輸入access key和secret key後登陸成功：
   
6. 以下圖，點擊紅框中的圖標，建立一個bucket，名爲runner：
   
7. 至此，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

8. 配置完畢，啓動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

2. 提交上述腳本到GitLab，以下圖，可見pipeline會被觸發，狀態爲pending是由於正在等待runner建立executor pod：

3. 稍後就會執行成功，點開看結果：

4. 點開build1的圖標，可見此job的輸出信息：

5. 點開test1的圖標，可見對應的控制檯輸出，上一個job寫入的數據被成功讀取：

6. 至此，可見分佈式緩存已經生效，在多臺機器的環境中也可使用pipeline語法的緩存功能了；

你不孤單，欣宸原創一路相伴

1. Java系列
2. Spring系列
3. Docker系列
4. kubernetes系列
5. 數據庫+中間件系列
6. DevOps系列

歡迎關注公衆號：程序員欣宸

微信搜索「程序員欣宸」，我是欣宸，期待與您一同暢遊Java世界...
https://github.com/zq2599/blog_demos