GitLab CI搭整合Pipeline
| 編輯推薦: |
| 本文來自騰訊雲，文章介紹瞭如何設定GitLab CI以監視儲存庫的更改並執行自動化測試以驗證新程式碼等相關知識。 |
介紹
GitLab Community Edition是一個自託管的Git儲存庫提供程式，具有幫助專案管理和軟體開發的附加功能。GitLab提供的最有價值的功能之一是內建的持續整合和交付工具GitLab CI。
在本教程中，我們將演示如何設定GitLab CI以監視儲存庫的更改並執行自動化測試以驗證新程式碼。我們將從執行的GitLab安裝開始，我們將為基本的Node.js應用程式複製示例儲存庫。在配置我們的CI過程之後，當新的提交被推送到儲存庫時，GitLab將使用CI runner來針對隔離的Docker容器中的程式碼執行測試套件。
準備
在開始之前，您需要設定一個初始環境。我們需要一個安全的GitLab伺服器，用於儲存我們的程式碼並管理我們的CI/CD流程。此外，我們需要一個地方來執行自動化測試。這個地方可以是GitLab所在的伺服器，也可以是單獨的主機，詳情請看下面的教程。
使用SSL保護的GitLab伺服器
要儲存原始碼並配置我們的CI/CD任務，我們需要在Ubuntu 16.04伺服器上安裝GitLab例項。GitLab目前推薦一款至少具有2個CPU核心和4GB記憶體的伺服器。可以直接使用騰訊雲伺服器作為GitLab伺服器，如果你有域名，保護你網站的最簡單方法是使用騰訊雲SSL證書服務，它提供免費的可信證書。
我們將演示如何在專案之間共享CI/CD執行程式（執行自動化測試的元件）以及如何將它們鎖定到單個專案。如果您希望在專案之間共享CI runners ，我們強烈建議您限制或禁用公共註冊。
一個或多個伺服器用作GitLab CI Runners
GitLab CI Runners是檢查程式碼並執行自動化測試以驗證新更改的伺服器。為了隔離測試環境，我們將在Docker容器中執行所有自動化測試。為此，我們需要在將執行測試的伺服器或伺服器上安裝Docker。
從GitHub複製示例儲存庫
首先，我們將在GitLab中建立一個包含示例Node.js應用程式的新專案。我們將直接從GitHub匯入原始儲存庫，這樣我們就不必手動上傳它。
登入GitLab並單擊右上角的加號圖示，然後選擇新建專案以新增新專案：
在新專案頁面上，單擊“ 匯入專案”選項卡：
接下來，單擊Repo by URL按鈕。雖然有一個GitHub匯入選項，但它需要一個Personal訪問令牌，用於匯入儲存庫和其他資訊。我們只對程式碼和Git歷史記錄感興趣，因此通過URL匯入更容易。
在Git儲存庫URL欄位中，輸入以下GitHub儲存庫URL：
它應該如下所示：
由於這是演示，因此最好將儲存庫標記為Private。完成後，單擊“ 建立專案”。
將根據從GitHub匯入的儲存庫建立新專案。
瞭解 .gitlab-ci.yml檔案
GitLab CI在每個儲存庫中查詢檔案.gitlab-ci.yml，以確定它應如何測試程式碼。我們匯入的儲存庫已經為專案配置了一個gitlab-ci.yml檔案。您可以通過閱讀.gitlab-ci.yml參考文件來了解有關該格式的更多資訊。
單擊我們剛剛建立的專案的GitLab介面中的.gitlab-ci.yml檔案。CI配置應如下所示：
.gitlab-ci.yml
image: node:latest
stages:
- build
- test
cache:
paths:
- node_modules/
install_dependencies:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
test_with_lab:
stage: test
script: npm test
該檔案使用GitLab CI YAML配置語法來定義應採取的操作、應執行的操作順序、應在何種條件下執行，以及完成每項任務所需的資源。編寫自己的GitLab CI檔案時，可以通過在GitLab例項中轉到/ci/lint從而訪問語法linter來驗證檔案格式是否正確，。
配置檔案首先宣告Docker image應該用於執行測試套件的。由於Hapi是Node.js框架，我們使用最新的Node.js image：
接下來，我們明確定義將執行的不同持續整合階段：
stages:
- build
- test
您在此處選擇的名稱是任意的，但順序決定了後續步驟的執行順序。Stages是可以應用於單個作業的標籤。GitLab將並行運行同一階段的作業，並等待執行下一階段，直到當前階段的所有作業完成。如果沒有的階段定義，GitLab將使用三個名為build，test以及deploy的階段並將所有任務預設分配到test階段。
定義階段完成後，該配置會包含一個cache定義：
cache:
paths:
- node_modules/
這指定了在執行或階段之間可以快取（儲存以供以後使用）的檔案或目錄。這有助於減少執行依賴於執行之間可能不會更改的資源的作業所花費的時間。在這裡，我們正在快取node_modules目錄，npm將會把下載的依賴項安裝在此目錄中。
我們的第一個任務叫做install_dependencies：
install_dependencies:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
任務名稱可以自定義，通常，npm install可以與下一個測試階段結合使用，但為了更好地演示階段之間的互動，我們正在提取此步驟以在其自己的階段中執行。
我們將該階段明確標記為使用stage指令的“build”。接下來，我們指定使用script指令執行的實際命令。您可以通過在script部分中新增其他行來包含多個命令。
artifacts子部分用於指定要在階段之間儲存和傳遞的檔案或目錄路徑。由於npm install命令會為專案安裝依賴項，因此下一步將需要訪問下載的檔案。宣告node_modules路徑可確保下一個階段可以訪問檔案。這些也可以在測試後在GitLab UI中檢視或下載，因此這對於二進位制檔案等構建工件也很有用。如果要儲存現階段中生成的所有內容，請將整個paths部分替換為untracked:true。
最後，第二個名為test_with_lab的任務聲明瞭實際執行測試套件的命令：
test_with_lab:
stage: test
script: npm test
script: npm test
我們把它放在test階段。由於這是後期階段，因此它可以訪問build階段生成的工件，這是我們案例中的專案依賴關係。這裡，script部分演示了當只有一個專案時可以使用的單行YAML語法。我們可以在之前的作業中使用相同的語法，因為只指定了一個命令。
現在您已經瞭解.gitlab-ci.yml檔案如何定義CI/CD任務，我們可以定義一個或多個能夠執行測試計劃的執行程式。
觸發持續整合執行
由於我們的儲存庫包含一個.gitlab-ci.yml檔案，因此任何新的提交都將觸發新的CI執行。如果沒有可用的runner，則CI執行將設定為“pending”。在我們定義執行器之前，讓我們觸發CI執行以檢視任務在待處理狀態下的狀態。一旦runner可用，它將立即開始執行。
回到hello_hapiGitLab專案儲存庫檢視，單擊分支和專案名稱旁邊的加號，然後從選單中選擇New file：
在接下來的頁面中，在檔名稱欄位輸入dummy_file並在主編輯視窗中輸入一些文字：
完成後，單擊底部的提交更改。
現在，返回主專案頁面。最近的提交將附加一個小的暫停圖示。如果將滑鼠懸停在圖示上，則會顯示“Commit:pending”：
這意味著驗證程式碼更改的測試尚未執行。
要獲取更多資訊，請轉到頁面頂部，然後單擊“Piplines”。您將進入pipeline概述頁面，您可以在其中看到CI執行被標記為待處理並標記為“stuck”：
注意：右側是CI Lint工具的按鈕。您可以在此處檢查您編寫的任何gitlab-ci.yml檔案的語法。
從這裡，您可以單擊pending狀態以獲取有關執行的更多詳細資訊。此檢視顯示我們執行的不同階段，以及與每個階段關聯的各個任務：
最後，單擊install_dependencies任務。這將為您提供有關延遲執行的具體細節：
此處，該訊息表明由於缺少runner而導致作業停滯。這是預料之中的，因為我們還沒有配置任何。一旦runner可用，可以使用相同的介面檢視輸出。這也是您可以下載構建期間生成的工件的位置。
現在我們知道待處理的任務是什麼樣的，我們可以為我們的專案分配一個CI執行器來獲取待處理的任務。
安裝GitLab CI Runner服務
我們現在準備建立一個GitLab CI runner。為此，我們需要在系統上安裝GitLab CI runner包並啟動GitLab runner服務。該服務可以為不同的專案執行多個執行程式例項。
安裝GitLab CI runner服務的過程類似於用於安裝GitLab本身的過程。我們將下載一個指令碼，將GitLab儲存庫新增到apt源列表中。執行指令碼後，我們將下載runner包。然後我們可以將其配置為服務我們的GitLab例項。
首先將最新版本的GitLab CI runner儲存庫配置指令碼下載到/tmp目錄
您可以隨意檢查下載的指令碼，以確保您對所需的操作感到滿意。
請執行安裝程式：
該指令碼將設定您的伺服器以使用GitLab維護的儲存庫。這使您可以使用與其他系統軟體包相同的軟體包管理工具來管理GitLab runner包。完成後，您可以使用apt-get命令繼續安裝：
這將在系統上安裝GitLab CI runner包並啟動GitLab runner服務。
設定GitLab Runner
接下來，我們需要設定一個GitLab CI runner，以便它可以開始接受任務。
為此，我們需要一個GitLab runner令牌，以便執行器可以使用GitLab伺服器進行身份驗證。我們需要的令牌型別取決於我們如何使用此runner。
如果您對於runner有具體要求，具體專案runner將會非常有用。例如，如果您的gitlab-ci.yml檔案定義了需要憑據的部署任務，則可能需要特定的執行程式在部署環境中正確進行身份驗證。特定於專案的runner不接受來自其他專案的任務。
另一方面，共享runner是可以由多個專案使用的通用runner。Runner將根據一種演算法從專案中獲取任務，該演算法考慮了每個專案當前正在執行的任務數量。這種型別的runner更靈活。您需要使用管理員帳戶登入GitLab以設定共享runner。
我們將演示如何獲得以下兩種runner型別的runner令牌。選擇最適合您的方法。
收集資訊以註冊特定專案的runner
如果您希望將runner繫結到特定專案，請首先導航到GitLab介面中的專案頁面。
在此處，單擊左側選單中的“設定”項。然後，單擊子選單中的CI / CD項：
在此頁面上，您將看到“ runner設定”部分。單擊“展開”按鈕以檢視更多詳細資訊。在詳細檢視中，左側將說明如何註冊專案特定的runner。複製說明的第4步中顯示的註冊令牌：
如果要為此專案禁用任何活動的共享執行程式，可以通過單擊右側的“禁用共享執行程式”按鈕來執行此操作。這是可選的。
準備就緒後，請跳過前面的內容，瞭解如何使用您從此頁面收集的資訊註冊runner。
收集資訊以註冊共享runner
要查詢註冊共享執行程式所需的資訊，您需要使用管理帳戶登入。
首先，單擊頂部導航欄中的扳手圖示以訪問管理區域。在左側選單的“概述”部分中，單擊“Runner”以訪問共享執行器配置頁面：
將顯示的註冊令牌複製到頁面頂部：
我們將使用此令牌為專案註冊GitLab CI runner。
使用GitLab伺服器註冊GitLab CI Runner
現在您有了令牌，請返回安裝了GitLab CI runner服務的伺服器。
要註冊新的runner，請輸入以下命令：
您將被問到一系列問題來配置runner：
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/)
輸入您的GitLab伺服器的域名，https://用於指定SSL。您可以選擇附加/ci到域的末尾，但最新版本會自動重定向。
Please enter the gitlab-ci token for this runner
您在上一部分中複製的令牌。
Please enter the gitlab-ci description for this runner
這個特定runner的名字。這將顯示在命令列和GitLab介面中的runner服務的runner列表中。
Please enter the gitlab-ci tags for this runner （逗號分隔）
這些是您可以分配給runner的標籤。GitLab作業可以表達這些標記的要求，以確保它們在具有正確依賴關係的主機上執行。在這種情況下，您可以將此處留空。
Whether to lock Runner to current project true/false
將runner分配給特定專案。它不能被其他專案使用。在這裡選擇“false”。
Please enter the executor
runner用來完成任務的方法。在這裡選擇“docker”。
Please enter the default Docker image (e.g. ruby:2.1)
當.gitlab-ci.yml檔案不包含映象特性時，該預設映象將用於執行任務。最好在此處指定一般映象，並像我們一樣在.gitlab-ci.yml檔案中定義更具體的映象。
我們將在這裡輸入“alpine：latest”作為一個小的，安全的預設值。
在回答提示後，將建立一個能夠執行專案的CI/CD任務的新runner。
您可以通過輸入以下內容來檢視GitLab CI轉輪服務當前具有的runner：
Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml
example-runner Executor=docker Token=e746250e282d197baa83c67eda2c0b URL=https://example.com
現在我們有一個runner，我們可以回到GitLab的專案。
在GitLab中檢視CI/CD執行
返回Web瀏覽器，返回GitLab中的專案。根據註冊runner的時間長短，runner可能正在執行：
或者它可能已經完成：
無論狀態如何，單擊正在執行或已通過的圖示（如果遇到問題，則會失敗）以檢視CI執行的當前狀態。單擊頂部“Pipeline”選單可以獲得類似的檢視。
您將進入pipeline概述頁面，您可以在其中檢視GitLab CI執行的狀態：
在Stages標題下，將有一個圓圈表示執行中每個階段的狀態。如果單擊stage，則可以看到與stage關聯的各個任務：
單擊構建階段中的install_dependencies任務。這將帶您進入任務概述頁面：
現在，不顯示關於沒有可用的runner的訊息，而是顯示任務的輸出。在我們的例子中，這意味著您可以看到npm安裝每個包的結果。
在右側，您還可以看到其他一些專案。您可以通過更改階段並單擊下面的執行來檢視其他任務。您還可以檢視或下載執行生成的任何工件。
結論
在本教程中，我們向GitLab例項添加了一個演示專案，以展示GitLab CI的持續整合和部署功能。我們討論瞭如何在gitlab-ci.yml檔案中定義pipeline以構建和測試應用程式，以及如何將作業分配給stage以定義彼此之間的關係。然後，我們設定了一個GitLab CI runner來為我們的專案選擇CI任務，並演示瞭如何查詢有關各個GitLab CI執行的資訊。