在 K8s 中快速部署使用 GitLab 並構建 DevOps 項目

作者：張海立，KubeSphere 社區 Ambassador、Talented Speaker，社區用戶委員會上海站副站長

原文鏈接：https://kubesphere.com.cn/blogs/kubesphere-gitlab-devops/

新年伊始，“極狐(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 Token
• Scope選擇默認的Global，ID填入任意不產生命名沖突的 ID
• Token填入剛剛復制備用的 GitLab 令牌字符串（可忽略字符串長度的提示）

完成這部分配置之后，KubeSphere DevOps 流水線的狀態也會和我們 GitLab 中的 Pipeline 狀態形成聯動，大家可以參看視頻中的效果。

• https://www.bilibili.com/video/BV18U4y1T7tv

使用 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 [e-mail]: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://[e-mail]:32222/root/nodejs-demo.git

寫在最后：感謝您這么耐心的看完這整個教程！如果您覺得這些內容如果自己部署起來確實有點挑戰，那推薦可以看看 極狐GitLab 和 KubeSphere Cloud 的一些商業產品，讓專業的人做專業的事兒，釋放大家的時間更好的打磨自己的業務產品。也期待看到更多的開源社區和商業產品的良性互動，一起推動我們國內的軟件產業在虎年 “虎踞龍盤今勝昔，天翻地覆慨而慷”！
本文由博客一文多發平台 OpenWrite 發布！