今天要來介紹 GitLab 最大的功能,也就是 Runner,安裝 Shell executor 以後,講解一下 Kubernetes executor 跟 Shell executor 之間差異,並且分配工作給指定 Runner。
這邊有兩個 Runner 需要講解,一個是 Kubernetes executor,另一個是 Shell executor,但在那之前,我們先來安裝 Shell executor 在 gitlab-runner
上。
點到 Admin > Overview > Runners
有個 Register an instance runner
久違來連線一下快被遺忘的 gitlab-runner
輸入上面的 Download and install binary
再到 Command to register runner
到 Command to register runner
會有一連串的問題詢問:
https://gitlab.yjerry.tw
你的 Token
gitlab-shell-runner
shell
shell
輸入完後面就會顯示:
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"
借一下 Day06 的 Script 來安裝 kubectl
curl -LO "https://dl.k8s.io/release/v1.23.7/bin/linux/amd64/kubectl"
curl -LO "https://dl.k8s.io/v1.23.7/bin/linux/amd64/kubectl.sha256"
echo "$(cat kubectl.sha256) kubectl" | sha256sum --check
# Check OK 就可以安裝
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
# 刪除安裝的殘餘檔案
rm kubectl*
把 bastion-host
的 .kube/config
放到 /home/gitlab-runner/.kube/config
,這部分就各位自行想辦法處理,相信使用 sudo su 搭配 mv 還有 chmod 應該不會太困難。
ubuntu@gitlab-runner:~$ sudo su
root@gitlab-runner:/home/ubuntu# mkdir -p /home/gitlab-runner/.kube
root@gitlab-runner:/home/ubuntu# mv config /home/gitlab-runner/.kube
root@gitlab-runner:/home/ubuntu# cd /home/gitlab-runner
root@gitlab-runner:/home/gitlab-runner# chown -R gitlab-runner:gitlab-runner .kube
root@gitlab-runner:/home/ubuntu# exit
那這樣接好以後,就可以嘗試在 Shell Runner 上跑跑看 kubectl。
那就可以來建立新專案在 GitLab 上,點一下 Create project
建立好 Project 以後,就點到 CI/CD > Editor
就可以來 Configure pipeline
下面的範例內容貼上去:
stages: # List of stages for jobs, and their order of execution
- build
- test
- deploy
build-job: # This job runs in the build stage, which runs first.
stage: build
script:
- echo "Compiling the code..."
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 60
- echo "Code coverage is 90%"
lint-test-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 10
- echo "No lint issues found."
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
tags:
- shell
environment: production
script:
- echo "Deploying application..."
- kubectl get node
- echo "Application successfully deployed."
看到 deploy-job
的時候,就會發現有出錯。
點進去下面那個連結,裡面說明有句話這樣寫:A common failure is when you have a .bash_logout
that tries to clear the console.
也就是說 .bash_logout
會嘗試把 Console 的輸出給清空,這是為了安全所做的,但是在 GitLab Shell Runner 造成了阻礙,因此需要把它移除。
root@gitlab-runner:/home/gitlab-runner# rm .bash_logout
設定完以後,就讓 Job Retry。
Job Retry 以後就 Passed,也證明 Shell Runner 可以連線到 K8s 上了。
接下來就來說說 Shell Runner 跟 K8s Runner 的差異吧!
Shell executor 顧名思義就是跑在 Shell 上,也就是在 Local 端,Host 本身就要安裝 Build 時候要跑的相關內容,不然系統會無法執行。
但沒辦法像 Docker 或 Kubernetes executor 區隔環境,編譯&測試就無法給它,剩下一個就是部署的部分,設定好部署的相關環境(E.g. kubectl)就可以執行。
Kubernetes executor 就是跑在 K8s 上的 Runner,Runner 會常駐在 K8s Cluster 裡面,會去看看 GitLab 本身有沒有要排的 Job,如果有就呼叫 Kubernetes API 去建立 Pod 還有對應的資源執行 Jobs。
這個是 Kubernetes executor 執行的狀態:
看到裡面就會寫 Pod 的執行狀態,看看系統是不是在 Running。
大致流程圖會是這樣:
不過 Kubernetes executor 會有個需要注意的點,因為 Container 沒有打開 Privileged container,部署是不能使用 Docker 去 Build,需要使用 Unprivileged 的 Kaniko 來建立 Docker Image。
下一篇就是要來實戰 Registry 搭配 CI/CD 一起搭配完成部署了。
本系列內容也會同步貼到我的 Blog https://blog.yangjerry.tw 歡迎來我的 Blog 點一下 RSS 追蹤,那我們就下一篇文章見啦!