Gitlab Runner的分佈式緩存實戰
- 2020 年 12 月 29 日
- 筆記
歡迎訪問我的GitHub
//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的分佈式緩存
- 官方文檔地址，有關緩存的詳情可以參考此文：//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
- 提交上述腳本到GitLab，如下圖，可見pipeline會被觸發，狀態為pending是因為正在等待runner創建executor pod：
- 稍後就會執行成功，點開看結果：
4. 點開build1的圖標，可見此job的輸出信息：
5. 點開test1的圖標，可見對應的控制台輸出，上一個job寫入的數據被成功讀取：
- 至此，可見分佈式緩存已經生效，在多台機器的環境中也可以使用pipeline語法的緩存功能了；
你不孤單，欣宸原創一路相伴
歡迎關注公眾號：程序員欣宸
微信搜索「程序員欣宸」，我是欣宸，期待與您一同暢遊Java世界…
//github.com/zq2599/blog_demos
