GitLab Runner部署(kubernetes環境)

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

歡迎訪問我的GitHub

https://github.com/zq2599/blog_demos

內容：所有原創文章分類彙總及配套原始碼，涉及Java、Docker、Kubernetes、DevOPS等；

關於GitLab CI

如下圖所示，開發者將程式碼提交到GitLab後，可以觸發CI指令碼在GitLab Runner上執行，通過編寫CI指令碼我們可以完成很多使用的功能：編譯、構建、生成docker映象、推送到私有倉庫等：
在這裡插入圖片描述

本次實戰內容

今天我們們會一起完成以下操作：

  1. 部署minio，pipeline指令碼中的cache功能由minio來實現；
  2. 配置和部署GitLab Runner；
  3. 編寫和執行pipeline指令碼；

環境和版本資訊

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

  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. 部署好GitLab，參考《群暉DS218+部署GitLab》
  2. 部署好Harbor，參考《群暉DS218+部署Harbor(1.10.3)》
  3. 部署好Helm，參考《部署和體驗Helm(2.16.1版本)》

準備完畢後開始實戰；

部署minio

minio作為一個獨立的服務部署，我將用docker部署在伺服器：192.168.50.43

  1. 在宿主機準備兩個目錄，分別儲存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
  1. 執行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
  1. 瀏覽器訪問，輸入access key和secret key後登入成功：
    在這裡插入圖片描述
  2. 如下圖，點選紅框中的圖示，建立一個bucket，名為runner：
    在這裡插入圖片描述
  3. 至此，minio已備好，接下來在kubernetes環境部署GitLab Runner；

GitLab Runner的型別

從使用者的維度來看，GitLab Runner的型別分為shared和specific兩種：

  1. 如果您想建立的GitLab Runner給所有GitLab倉庫使用，就要建立shared型別；
  2. 如果您的GitLab Runner只用於給某個固定的Gitlab倉庫，就要建立specific型別；

今天的實戰，我們建立的是specific型別，即先有GitLab程式碼倉庫，然後建立該倉庫專用的runner，所以請您提前準備好GitLab倉庫；

準備GitLab配置資訊(specific)

在部署GitLab Runner之前，要準備兩個關鍵的配置資訊，以便GitLab Runner啟動後可以順利連線上GitLab：

  1. 瀏覽器訪問GitLab，開啟用來做CI的程式碼倉庫，點選Settings -> CI/CD -> Runners -> Expand：
    在這裡插入圖片描述
  2. 如下圖，紅框1中是gitlab url，紅框2中是registration token，記好這兩個引數，稍後會用到：
    在這裡插入圖片描述

準備GitLab配置資訊(shared)

本次實戰不會建立shared型別的runner，如果您要建立該型別runner，只需按照以下方法準備資訊即可，建立出來的runner就是所有倉庫都能使用的了：

  1. 以管理員身份登入GitLab；
  2. 按照下圖紅框的順序取得gitlab url和registration token：
    在這裡插入圖片描述

部署RitLab Runner

  1. 請確保當前可以通過kubectl命令在kubernetes進行常規操作；
  2. 建立名為gitlab-runner的namespace：
kubectl create namespace gitlab-runner
  1. 建立一個secret，把minio的access key和secret key存進去，在後面配置cache的時候會用到：
kubectl create secret generic s3access \
--from-literal=accesskey="access" \
--from-literal=secretkey="secret123456" -n gitlab-runner
  1. 用helm部署GitLab Runner之前，先把chart的倉庫新增到helm的倉庫列表中：
helm repo add gitlab https://charts.gitlab.io
  1. 下載GitLab Runner的chart：
helm fetch gitlab/gitlab-runner
  1. 當前目錄會多出一個檔案gitlab-runner-0.18.0.tgz，解壓：
tar -zxvf gitlab-runner-0.18.0.tgz
  1. 解壓後是名為gitlab-runner的資料夾，內容如下圖所示，接下來要修改裡面的三個檔案：

在這裡插入圖片描述
8. 開啟values.yaml，裡面有四處需要修改：
9. 第一處，找到已被註釋掉的gitlabUrl引數位置，新增gitlabUrl的配置，其值就是前面在GitLab網頁取得的gitlab url引數，如下圖紅框：

在這裡插入圖片描述
10. 第二處，找到已被註釋掉的runnerRegistrationToken引數位置，新增runnerRegistrationToken的配置，其值就是前面在GitLab網頁取得的registration token引數，如下圖紅框：

在這裡插入圖片描述
11. 找到rbac的配置，將create和clusterWideAccess的值都改成true(建立RBAC、建立容器gitlab-bastion用於管理job的容器)：

在這裡插入圖片描述
12. 設定此GitLab Runner的tag為k8s，在pipeline指令碼中可以通過指定tag為k8s，這樣pipeline就會在這個Gitlab Runner上允許：

在這裡插入圖片描述
13. 找到cache的配置，在修改之前，cache的配置如下圖，可見值為空內容的大括號，其餘資訊全部被註釋了：

在這裡插入圖片描述
14. 修改後的cache配置如下圖，紅框1中原先的大括號已去掉，紅框2中的是去掉了註釋符號，內容不變，紅框3中填寫的是minio的訪問地址，紅框4中的是去掉了註釋符號，內容不變：

在這裡插入圖片描述
15. 上圖紅框4中的s3CacheInsecure引數等於false表示對minio的請求為http(如果是true就是https)，但實際證明，當前版本的chart中該配置是無效的，等到執行時還是會以https協議訪問，解決此問題的方法是修改templates目錄下的_cache.tpl檔案，開啟此檔案，找到下圖紅框中的內容：

在這裡插入圖片描述
16. 將上圖紅框中的內容替換成下面紅框中的樣子，即刪除原先的if判斷和對應的end這兩行，直接給CACHE_S3_INSECURE賦值：
在這裡插入圖片描述
17. 接下來要修改的是templates/configmap.yaml檔案，在這裡面將宿主機的docker的sock對映給runner executor，這樣job中的docker命令就會發到宿主機的docker daemon上，由宿主機來執行，開啟templates/configmap.yaml，找到下圖位置，我們要在紅框1和紅框2之間新增一段內容：

在這裡插入圖片描述
18. 要在上圖紅框1和紅框2之間新增的內容如下：

cat >>/home/gitlab-runner/.gitlab-runner/config.toml <<EOF
            [[runners.kubernetes.volumes.host_path]]
              name = "docker"
              mount_path = "/var/run/docker.sock"
              read_only = true
              host_path = "/var/run/docker.sock"
    EOF
  1. 新增上述內容後，整體效果如下，紅框中就是新增內容：

在這裡插入圖片描述
20. 修改完畢，回到values.yam所在目錄，執行以下命令即可建立GitLab Runner：

helm install \
--name-template gitlab-runner \
-f values.yaml . \
--namespace gitlab-runner
  1. 檢查pod是否正常：

在這裡插入圖片描述
22. 看pod日誌也並未發現異常：

在這裡插入圖片描述
23. 回到GitLab的runner頁面，可見新增一個runner：

在這裡插入圖片描述
至此，整個GitLab CI環境已部署完畢，接下來簡單的驗證環境是否OK；

驗證

  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
  1. 提交上述指令碼到GitLab，如下圖，可見pipeline會被觸發，狀態為pending是因為正在等待runner建立executor pod：

在這裡插入圖片描述
3. 稍後就會執行成功，點開看結果：

在這裡插入圖片描述
4. 點開build1的圖示，可見此job的輸出資訊：

在這裡插入圖片描述
5. 點開test1的圖示，可見對應的控制檯輸出，上一個job寫入的資料被成功讀取：

在這裡插入圖片描述

至此，GitLab Runner已經成功在kubernetes環境部署和執行，接下來的文章，我們會一起實戰將SpringBoot應用構建成docker映象並推送到Harbor；

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

  1. Java系列
  2. Spring系列
  3. Docker系列
  4. kubernetes系列
  5. 資料庫+中介軟體系列
  6. DevOps系列

歡迎關注公眾號：程式設計師欣宸

微信搜尋「程式設計師欣宸」，我是欣宸，期待與您一同暢遊Java世界...
https://github.com/zq2599/blog_demos

相關文章