在 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 [email protected]: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://[email protected]:32222/root/nodejs-demo.git

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423830.html

標籤：其他

上一篇：到底什么是TORCH.NN？

下一篇：統計學習：邏輯回歸與交叉熵損失（Pytorch實作）