GitLab在Kubernetes上的CI/CD

GitLab在Kubernetes上的CI/CD

[TOC]

1. Gitlab在Kubernetes中CI/CD流程

下圖中，Gitlab在整個過程當中，參與了60%以上的工做，能夠說，開發自從push了代碼後，就能夠直接測試並上線到生產環境。

在Kubernetes中，Gitlab Runner，是一箇中介的做用，它申請pod運行stage，因此Runner並不直接運行stage。

在開始前，須要詳細閱讀.gitlab-ci.yml各名詞和用法。

2. 環境

Kubernetes version: 1.12

Gitlab version: 11.4.3

3. Kubernetes安裝

略

可以使用我寫的一鍵安裝腳本：
https://github.com/ygqygq2/kubernetes/blob/master/kubeadm/kubeadm_install_k8s.sh

4. GitLab安裝

由於已經既然已經用上Kubernetes，那乾脆把GitLab也搭建在它上面。
使用helm安裝。

1. 添加gitlab的chart地址到helm repo；
2. 下載gitlab的chart；
3. 設置相關values.yaml；
4. helm安裝；

gitlab的chart裏，模塊不少，使用--set有的並很差寫，因此建議先修改values.yaml（包含各模塊的values.yaml）。

這裏若是是不使用自帶的nginx ingress，推薦修改gitlab/values.yaml
global.ingress.annotations參數，下面增長
kubernetes.io/ingress.class: nginx

默認它會安裝prometheus、certmanager、nginx ingress，按本身需求選擇。個人環境已經有nginx ingress、prometheus了，certmanager又暫時沒用上。因此這幾個都設置爲false，不安裝。如需正式使用，注意持久存儲大小。

helm repo add gitlab https://charts.gitlab.io/
helm fetch gitlab/gitlab --untar
cd gitlab
# vim values.yaml
namespace="devops"
helm upgrade --install gitlab --timeout 600 --namespace $namespace . \
--set gitlab.migrations.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-rails-ce \
--set gitlab.sidekiq.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ce \
--set gitlab.unicorn.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-unicorn-ce \
--set gitlab.unicorn.workhorse.image=registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ce \
--set gitlab.task-runner.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-task-runner-ce \
--set certmanager-issuer.email=my_email@163.com \
--set global.hosts.domain=linuxba.com \
--set global.smtp.enabled=true \
--set global.smtp.address=smtp.163.com \
--set global.smtp.user_name=my_email@163.com \
--set global.smtp.password.key=password \
--set global.smtp.password.secret=ygqmail \
--set global.time_zone="Asia/Shanghai" \
--set gitlab.gitaly.persistence.storageClass=ceph-rbd \
--set gitlab.gitaly.persistence.size=2Gi \
--set gitlab.gitaly.persistence.storageClass=ceph-rbd \
--set postgresql.persistence.size=2Gi \
--set postgresql.persistence.storageClass=ceph-rbd \
--set minio.persistence.size=5Gi \
--set minio.persistence.storageClass=ceph-rbd \
--set redis.persistence.size=1Gi \
--set redis.persistence.storageClass=ceph-rbd \
--set nginx-ingress.enabled=false \
--set prometheus.install=false \
--set certmanager.install=false \
--set gitlab.gitlab-shell.service.externalPort=20022 \
--set gitlab.gitlab-shell.service.internalPort=20022 \
--set gitlab.gitlab-runner.rbac.clusterWideAccess=true \
--set gitlab.gitlab-runner.rbac.create=true \
--set gitlab.gitlab-runner.runners.privileged=true \
--set glabal.initialRootPassword.key="Git@linuxba.com" \
--set gitlab.migrations.initialRootPassword.key="Git@linuxba.com"

# 自定義runner secret，統一管理
# --set gitlab.gitlab-runner.runners.secret=gitlab-runner-custom

# 上面已經不安裝prometheus了，則不申請它的pvc
# --set prometheus.server.persistentVolume.storageClass=ceph-rbd \
# --set prometheus.server.persistentVolume.size=2Gi \

安裝過程當中很容易出現以下提示：

E1129 15:21:12.482144 2878016 portforward.go:178] lost connection to pod
Error: UPGRADE FAILED: transport is closing

能夠等1分鐘，查看下pod是否在生成，若是在生成中，則其實已經安裝成功。也能夠再次使用上面命令，或者使用helm delete --purge刪除再從新安裝。

這也是讓人討厭的helm缺點之一，這篇文章
恕我直言，對Helm你們仍是要三思然後用有提到過。

安裝成功後，我發現安裝設置的root密碼不生效，能夠經過如下命令獲取登陸的root密碼：
kubectl get secret -n $namespace gitlab-test-gitlab-initial-root-password -ojsonpath={.data.password}|base64 -d

kubectl get ing能夠看到，有3個ingress，訪問gitlab.linuxba.com能夠訪問到gitlab界面。

注意：
HTTPS訪問，由於證書secret關係，可能須要修改ing或者使用事先準備的證書文件生成ing中名稱對應的secret。
這些都是k8s細節，這裏不做詳細描述。

5. Auto DevOps

5.1 添加Kubernetes集羣

管理員經過服務模板添加Kubernetes集羣，是生效全部項目的。

項目中也能夠添加Kubernetes集羣，優先於管理員添加的全局集羣。

• Active須要勾上；
• 添加集羣的API URL即爲Kubernetes API地址，由於這裏gitlab安裝在Kubernetes內，可使用地址：https://kubernetes.default；
• CA證書，即爲Kubernetes的ca證書內容所有複製粘貼；
• 添加集羣使用的token和博客《
  爲Kubernetes dashboard訪問用戶添加權限控制》中kubeconfig使用的token是同樣的，這裏再也不詳細描述；
• Kubernetes namespace，若添加的token的serviceaccount對應的權限爲某個namespace，這裏須要填寫其對應的namespace。默認爲空的話，在ci/cd過程當中，會自動建立項目的惟一namespace，且只有此namespace的rbac權限。

5.2 一個demo

在看demo前，先了解下gitlab中.gitlab-ci.yml流水線：

Stage
GitLab CI/CD 的執行過程當中首先驅動的是 Stage。
每一個 GitLab CI/CD 都必須包含至少一個 Stage。多個 Stage 是按照順序執行的。若是其中任何一個 Stage 失敗，則後續的 Stage 不會被執行，整個 CI 過程被認爲失敗。
默認包含三個 Stage：build、test 和deploy。
build 被首先執行。若是發生錯誤，本次 CI 馬上失敗；
test 在 build 成功執行完畢後執行。若是發生錯誤，本次 CI 馬上失敗；
deploy 在 test 成功執行完畢後執行。若是發生錯誤，本次 CI 失敗。

Job
Job 包含了真正的執行邏輯，例如調用 mvn 或者 gcc 等命令。

demo項目地址：
https://github.com/ygqygq2/kubernetes-gitlab-autodevops
https://github.com/ygqygq2/kubernetes-gitlab-autodevops/tree/master/mytest

demo是一個maven項目，用到了maven環境的docker image。
腳本中，設置了settings.xml以用於上傳image到harbor。
在.gitlab-ci.yml中，各步驟都有註釋，已經算是一個完整的流程。
腳本都是shell，如有用到數組功能，須要在運行的stage的pod基礎鏡像安裝bash，不然出現語法錯誤，比較誤導人。

如下是此demo的流水線過程：

分支流水線：

主分支流水線：

build過程：

deploy過程：

手動運行流水線：


訪問相關環境：

6. 小結

上文沒有詳細介紹demo，但從流水線圖能夠看出.gitlab-ci.yml的stage，熟悉gitlab的stage和job才能靈活配置CI/CD。建議先從最簡單的開始，全部操做使用echo代替，整個流水線跑通了，再細化各job。

參考資料：
[1] https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html
[2] https://docs.gitlab.com/ee/user/project/clusters/index.html
[3] https://docs.gitlab.com/ee/topics/autodevops/index.html
[4] https://docs.gitlab.com/ee/ci/variables/
[5] https://docs.gitlab.com/ee/ci/yaml/README.html
[6] https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
[7] http://www.ttlsa.com/auto/gitlab-cicd-gitlab-ci-yml-configuration-tasks-detailed/