作者：張海立，KubeSphere 社群 Ambassador、Talented Speaker，社群使用者委員會上海站副站長
原文連結：https://kubesphere.com.cn/blo...
新年伊始，“極狐(GitLab) 聯合青雲（QingCloud 公有云服務和 KubeSphere 容器平臺）、上海雲軸（ZStack Cloud 雲平臺和 ZStack Cube 超融合一體機)、寶德計算、上海恆嶽等國內多家知名雲廠商和伺服器廠商，首發 GitNative 系列產品解決方案，針對不同部署環境和應用場景，推出支援公有云、私有云、本地資料中心部署的 ‘GitNative 一體化 DevOps 平臺’ 和 ‘GitNative CI/CD流水線引擎’ 解決方案。”
在社群看到上面 這條新聞 的時候有種 “虎軀一震” 的感覺，確實很高興能看到國內的雲社群、雲廠商能在 DevOps 領域有這樣接地氣的商業產品合作，相信更多這樣跨界合作產品的出現也會推動我們國內的 DevOps 社群及產品有進一步發展。那麼對於我們開源社群的小夥伴而言，通過 GitLab 社群版以及 KubeSphere 平臺提供的 DevOps 能力，其實也可以自己嘗試搭建一套類似的 DevOps 平臺來一起感受一下 Kubernetes 時代下 GitOps 體系的魅力。
所以我們本次分享將和大家一起動手來實踐一下在 KubeSphere 部署 GitLab CE（Community Edition 社群版）並構建與之聯動的 DevOps 專案。
前提條件
安裝 KubeSphere
安裝 KubeSphere 有兩種方法。一是在 Linux 上直接安裝，可以參考文件：在 Linux 安裝 KubeSphere； 二是在已有 Kubernetes 中安裝，可以參考文件：在 Kubernetes 安裝 KubeSphere。
在 KubeSphere 中啟用 DevOps 套件
在 KubeSphere 中啟用 DevOps 套件可以參考文件：啟用可插拔組建 · KubeSphere DevOps 系統。安裝完成後可以在「平臺管理」頁面的「系統組建」部分看到 Jenkins 頭像圖示。
基於 Jenkins 的 KubeSphere DevOps 系統是專為 Kubernetes 中的 CI/CD 工作流設計的，它提供了一站式的解決方案，幫助開發和運維團隊用非常簡單的方式構建、測試和釋出應用到 Kubernetes。它還具有外掛管理、Binary-to-Image (B2I)、Source-to-Image (S2I)、程式碼依賴快取、程式碼質量分析等功能。文字只會涉及 KubeSphere DevOps 其中關於流水線使用的部分。
安裝 GitLab CE
我們先這次的演練建立一個名為devops的企業空間，同時建立一個名為gitlab的專案供 GitLab CE 部署使用。
通過應用倉庫部署 GitLab 應用
首先我們還是要現在 devops企業空間中新增 GitLab 的官方 Helm Chart 倉庫，推薦用這種自管理的方式來保障倉庫內容是得到及時同步的。通過「應用管理」下面的「應用倉庫」來新增如下的 GitLab 倉庫（倉庫 URL：https://charts.gitlab.io/）。
接下來進入先前建立的gitlab專案，從「應用負載」下面的「應用」頁面建立 GitLab 應用：選擇「從應用模版」建立即可得到如下介面，由於倉庫內可安裝的 Helm Chart 較多，注意選擇紅框指示的這個應用（撰稿時 Chart 最新版為 5.7.0，對於 GitLab 版本為 14.7.0）。
下面這一步十分重要，需要配置 Helm Chart 部署應用的引數。由於 GitLab 預設的可配置項非常多（有上千行），因此我們這次只挑選 可保障基礎業務使用的最小功能集 的相關引數進行改寫，關於每個引數具體代表的含義請參見引數項上一行的註釋（並留意【注意】部分）。其它配置項請大家參見 極狐GitLab Helm Chart 快速開始指南 及其中的 完整屬性列表。
global:
## 確保使用的版本是 Community Edition
edition: ce
## 全域性 Host 配置：https://docs.gitlab.cn/charts/charts/globals.html#host-%E9%85%8D%E7%BD%AE
#【注意】這裡我們只繫結 GitLab 主體服務的域名，其它都可以使用預設值（不影響演練使用）
hosts:
#【注意】這個基礎域名需要是 “部署 GitLab 的叢集” 內可以訪問的域名，否則各元件互聯可能存在問題
domain: example.com
#【注意】我們演練環境為了部署方便不啟用 HTTPS，否則需要提供和填寫的基礎域名對應的證書
https: false
gitlab:
name: gitlab.example.com
## 全域性 Ingress 配置：https://docs.gitlab.cn/charts/charts/globals.html#ingress-%E9%85%8D%E7%BD%AE
ingress:
#【注意】我們由於全面關閉 HTTPS，所以這裡也需要關閉 GitLab 自帶的證書生成器
configureCertmanager: false
#【注意】由於預設是使用自帶 Nginx，即使用 "gitlab-nginx"，需要改為 KubeSphere 閘道器適配的值
class: nginx
#【注意】預設是 true，需要強制關閉 HTTPS，和其它配置保持一致
tls:
enabled: false
## 自帶的 cert-manager 配置：https://github.com/jetstack/cert-manager
#【注意】這裡強制選擇不安裝 cert-manager
certmanager:
installCRDs: false
install: false
## 自帶的 Nginx Ingress 配置：https://docs.gitlab.cn/charts/charts/nginx/
#【注意】由於演練會直接使用 KubeSphere 專案/叢集閘道器，這裡直接關閉此項的安裝配置
nginx-ingress:
enabled: false
## 自帶的工件倉庫元件：https://docs.gitlab.cn/charts/charts/registry/
#【注意】由於不開啟 HTTPS，使用各類工件倉庫會有問題，這裡建議就直接關閉此項安裝配置
registry:
enabled: false
## 自帶的 MinIO 配置：https://docs.gitlab.cn/charts/charts/minio/
#【注意】由於可以後續自行在 KubeSphere 中開啟應用路由，這裡建議直接關閉閘道器路由配置
minio:
ingress:
enabled: false
## 自帶的 GitLab Runner 配置：https://docs.gitlab.cn/charts/charts/gitlab/gitlab-runner/
#【注意】由於演練環境我們直接接入 KubeSphere DevOps 做 CI/CD，這裡建議就先不安裝 Runner
gitlab-runner:
install: false雖然已經是最小功能集部署，但由於部署的服務及其資源開銷較多，部署過程還是比較長的。部署完成後可以在 gitlab應用的「工作負載」部分檢視到所有負載都在執行中的狀態。
此時gitlab應用狀態處於正在建立，這是由於應用部署超時導致的，只要所有工作負載可以正常進入執行狀態，是並不影響應用正常使用的。
由於部署時間很長，容易導致 MinIO 元件的舒適化 Bucket 任務失敗，建議檢查「應用負載」下的gitlab-minio-create-buckets-1任務，如果失敗可以通過詳情頁左側「更多操作」來「重新執行」，最終得到已完成（1/1）的狀態即可認為成功。
確認所有工作負載執行後，如之前您已經配置過叢集或專案閘道器並使能過gitlab.example.com的域名解析，那麼您就可以直接訪問該域名來開啟 GitLab 的站點頁面。
關於如何在 KubeSphere 中設定叢集或專案閘道器，您可以參考我們之前的 技術部落格。同時請確保您的閘道器是可以直接使用 HTTP 標準的**80**埠來提供訪問能力的！在 GitLab 中建立一個示例專案
首先讓我們來登陸 GitLab。GitLab 的初始密碼被作為 Secret 儲存，我們可以回到專案首頁，在「配置」下的「保密字典」中搜尋initial可以找到 gitlab-initial-root-password的條目。點選該字典條目，並在「資料」區塊中點選最右側的眼睛圖示來展示password資料項的內容。
複製該密碼，並使用root作為使用者名稱，即可登陸 GitLab 得到如下圖所示的介面。
點選「New Project」按鈕進入建立專案的頁面，通過「Create from Template」我們可以來建立一個示例專案用於後面的流水線演練。
讓我們選擇NodeJS Express這個專案模版來建立應用，所有模版都可以通過 Preview 按鈕來預覽其中的內容，使用模版後得到如下建立專案介面。
填入您偏好的專案名稱，並在專案可見度這裡選擇預設的Private來建立私有專案，以便於後續演示如果訪問私有專案。完成匯入後可以得到如下的專案頁面。
關閉 Auto DevOps 並建立 Jenkinsfile
由於我們後續要使用 KubeSphere DevOps，而 GitLab 預設開啟了 Auto DevOps 功能（會為無 CI 配置的專案自動提供流水線支援），為了避免混亂，我們先暫時關閉 Auto DevOps。
找到專案頁面中間部位的檔案及功能快捷入口區域，點選「Auto DevOps enabled」按鈕塊，進入配置頁面後取消Default to Auto DevOps pipeline的勾選並「Save changes」，即可完成 Auto DevOps 功能的關閉。
接下來，我們還需要為這個專案建立一個 Jenkinsfile 用於後續 KubeSphere DevOps 流水線的構建。在master分支下直接建立一個名為Jenkinsfile的檔案，填入以下內容即可。
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
always {
echo 'I will always say Hello again!'
}
}
}使用 KubeSphere DevOps 為 GitLab 提供流水線
我們首先在devops的企業空間中建立一個名為demo的 DevOps 專案，用於後續演練如何為 GitLab 建立流水線。
將 GitLab 與 KubeSphere Jenkins 進行繫結
由於 KubeSphere Jenkins 預設繫結的 GitLab 服務是官方的gitlab.com，因此在建立流水線前需要先重新繫結到我們建立的私有 GitLab 服務上。首先，我們需要開啟 KubeSphere Jenkins 的頁面，為了操作方便，我們直接為kubesphere-devops-system名稱空間下的devops-jenkins開放 NodePort。
使用 KubeSphere 賬號登陸 Jenkins（如果登陸失敗可能是賬號同步問題，可以修改一次密碼再次嘗試）。通過「Manage Jenkins ➡️ Configure System」進入系統配置頁面，找到 GitLab Servers配置區，點選「Add GitLab Server」開始新增我們的 GitLab 服務。
如上圖所示，需要填寫或編輯的配置項一共有三項：
Server URL：這裡填入我們剛剛部署完成的 GitLab 服務的訪問方式（如果是域名訪問，一定需要是 Jenkins 也可達的域名）Crendentials：這裡選擇或建立一個 Jenkins 的的憑證項，該憑證需要是 GitLab 某個使用者的 Personal Access Token（下面我們會繼續說明如何建立）Web Hook：這個一定要勾選Manage Web Hooks這項，用於我們之後同步 Jenkins Pipeline 的狀態到我們的 GitLab 服務中
建立 GitLab Personal Access Token 的 Jenkins Crendential
首先，我們回到 GitLab 中，可以直接通過<gitlab-url>/-/profile/personal_access_tokens（例如本文可使用[http://gitlab.example.com/-/profile/personal_access_tokens](http://gitlab.example.com:30433/-/profile/personal_access_tokens)）來訪問 Personal Access Tokens 的建立頁面。按 Jenkins 的要求，我們建立一個名為 jenkins且具備api`read_repository`write_repository許可權的令牌，複製令牌字串備用。
然後我們回到 Jenkins 首頁，從「Manage Jenkins ➡️ Manage Crendentials ➡️ Stores scoped to Jenkins ➡️ Jenkins ➡️ Global crendentials (unrestricted)」進入憑證建立頁面。
點選左側皮膚的「Add Credentials」即可開始建立憑證，填寫完成後點選Ok儲存即可完成憑證建立：
Kind選擇GitLab Personal Access TokenScope選擇預設的Global，ID填入任意不產生命名衝突的 IDToken填入剛剛複製備用的 GitLab 令牌字串（可忽略字串長度的提示）
完成這部分配置之後，KubeSphere DevOps 流水線的狀態也會和我們 GitLab 中的 Pipeline 狀態形成聯動，大家可以參看視訊中的效果。
使用 Jenkinsfile 建立 KubeSphere DevOps 流水線
讓我們進入之前建立的demoDevOps 專案，開始「建立」流水線。
在彈出的「建立流水線」對話方塊中，我們填入一個流水線「名稱」並點選下方「程式碼倉庫（可選）」這個區域來進行程式碼倉庫繫結。
進入到「選擇程式碼倉庫」皮膚後，我們選擇GitLab標籤頁，然後在「GitLab 伺服器地址」下拉框中選擇我們上一小節在 Jenkins 中新增到GitLab CE伺服器。
由於我們演練的是私有倉庫訪問，下面需要先選擇一個憑證用於訪問私有程式碼倉庫。在之前沒有建立的情況下，這裡我們點選綠色的「建立憑證」連結開始建立。
在彈出的「建立憑證」對話方塊中，輸入「名稱」後選定型別為使用者名稱和密碼；然後在「使用者名稱」文字框中輸入我們的賬號root，在「密碼/令牌」中輸入之前從保密字典中獲取到的初始密碼。
通過「確定」按鈕儲存憑證後回到「選擇程式碼皮膚」，在「憑證」下拉框中選擇剛剛建立的gitlab-root，然後在「專案組/所有者」文字庫中填入我們的賬號root，點選「程式碼倉庫」下拉框可看到root賬號下所有的程式碼倉庫，這裡我們可以看到並選擇之前建立的示例專案root/nodejs-demo。
通過 ☑️ 按鈕確認並儲存配置後會再次回到「建立流水線」皮膚，此時可以看到「程式碼倉庫」已出現我們選擇的root/nodejs-demo專案，點選「下一步」進入「高階設定」標籤頁，這裡我們不做額外的配置，直接點選「確定」來建立流水線。建立成功後，我們可以看到如下一個「分支數量」為0並且健康的流水線。
稍後片刻點選進入新建的file流水線，可以看到系統已經掃描到帶有Jenkinsfile的master分支並已經開始執行流水線。
點選master分支進入分支詳情頁面，不管執行成功還是失敗都可以進一步點選「執行 ID」一欄中的序號來檢視詳細的執行日誌及製品等。
等待一段時間後執行成功，進入執行 ID 為1的執行記錄可以看到如下圖展示的介面。進一步我們可以點選右上角的「檢視日誌」按鈕來了解詳細的流水線執行情況。
注意：對於多分支流水線，預設會先執行checkout scm步驟，然後再執行 Jenkinsfile 中定義的流水線內容。使用圖形編輯器建立 KubeSphere DevOps 流水線
本小節內容可參考 KubeSphere 官方文件：DevOps 使用者指南 / 使用 DevOps / 使用圖形編輯皮膚建立流水線
KubeSphere DevOps 流水線也可以通過圖形編輯介面來進行建立，讓我們重新回到demoDevOps 專案首頁，「建立」一個新流水線。這次在「建立流水線」皮膚中我們不繫結程式碼倉庫，直接「下一步」再直接「建立」一個名為gui的流水線。
進入流水線詳情頁面後，我們可以在右側皮膚看到「編輯流水線」的按鈕，點選後在彈出的「選擇流水線模版」對話方塊中，我們選擇自定義流水線。
另兩個流水線模版包含了更完整的 CI / CD 流水線構建示例，但內容相對複雜，歡迎大家線下自行選用進行體驗！
下面我們嘗試用圖形編輯器復現前一小節的兩個操作步驟，即拉起程式碼，並列印一條 Hello World 訊息。首先，我們點選左側皮膚的+按鈕，然後選中新增出來的一個階段塊。
接著我們點選左側階段塊上的「+ 新增步驟」，並在右側刷出的「新增步驟」皮膚中選則git步驟，在彈出的對話方塊中填入我們示例程式碼倉庫的地址 HTTP Git 地址（如[http://gitlab.example.com/root/nodejs-demo.git](http://gitlab.example.com/root/nodejs-demo.git)），憑證選用之前建立的gitlab-root，分支填寫master。
完成後我們依樣畫葫蘆，再次新增一個列印訊息步驟並填入Hello World!作為內容，最後得到如下圖所示的整體效果。
完成編輯後「確定」再「確定」來儲存流水線，回到詳情頁面後，可以通過右上角的「執行」按鈕來執行流水線。
執行成功後可以再次檢視流水線執行記錄，並檢視執行日誌，得到如下圖所示結果。
【番外】使用 SSH 訪問 Kubernetes 叢集中的 GitLab 程式碼倉庫
前文介紹的程式碼倉庫的訪問方式都是通過 HTTP 的形式，但現實工作中我們最常用的還是 SSH 的訪問方式，那是否可以直接通過git clone git@gitlab.example.com:root/nodejs-demo.git這樣的方式來拉取和推送程式碼呢？
答案是肯定的：可以！但是這裡有一個大坑需要注意 —— 預設 SSH 用的是22埠，但多了一層 Kubernetes 網路之後，不管是否使用這個預設埠都需要處理好 GitLab 如何對外暴露 SSH 服務。
假設我們可以接受重新繫結一個埠來使用 GitLab SSH，那麼可以這樣操作：
- 首先，我們回到 GitLab 部署專案中，找到
gitlab-shell服務併為它開放 NodePort 外部訪問埠
- 基於這個埠，把 Git 訪問的地址都改為
ssh://git@<gitlab-url>:<gitlab-shell-port>/<username>/<repo>.git的形式，例如ssh://git@gitlab.example.com:32222/root/nodejs-demo.git
寫在最後：感謝您這麼耐心的看完這整個教程！如果您覺得這些內容如果自己部署起來確實有點挑戰，那推薦可以看看 極狐GitLab 和 KubeSphere Cloud 的一些商業產品，讓專業的人做專業的事兒，釋放大家的時間更好的打磨自己的業務產品。也期待看到更多的開源社群和商業產品的良性互動，一起推動我們國內的軟體產業在虎年 “虎踞龍盤今勝昔，天翻地覆慨而慷”！
本文由部落格一文多發平臺 OpenWrite 釋出！