敏捷無敵之Gitlab CI架構(gòu)流程詳解

2.敏捷無敵之Gitlab CI架構(gòu)流程詳解

一 引子

在我們知道了Gitlab CI是什以及它能為我們帶來什么，在我們利用Gitlab CI之前，需要先了解其架構(gòu)流程，通過本節(jié)學(xué)習(xí)Gitlab CI的基礎(chǔ)概念及相關(guān)元素，更加有利于之后的三篇實(shí)戰(zhàn)理解，Gitlab CI基于自動執(zhí)行腳本，最大限度的減少在環(huán)境部署及上線時引入錯誤的可能性，當(dāng)一條Gitlab CI集成完成，從新代碼的開發(fā)到部署，極少或者根本不需要人為的干預(yù)，在每次小的迭代中不斷構(gòu)建，測試和部署，盡可能早的試錯，這種方式為最適合敏捷高效的開發(fā)。

那么如何開始我們的Gitlab CI之旅呢，其實(shí)你需要在你的項(xiàng)目中添加一個 .gitlab-ci.yml 文件，然后在組或者項(xiàng)目中注冊一個 Runner，即可進(jìn)行持續(xù)集成，那么什么又是Runner，.gitlab-ci.yml文件又該如何寫呢，相信通過本章節(jié)，讀者能清楚的了解Gitlab CI的架構(gòu)流程及其元素組件，為我們后面的實(shí)戰(zhàn)做好充分的準(zhǔn)備。

二 基礎(chǔ)概念

2.1 Gitlab-Runner

Gitlab CI的架構(gòu)為C/S模型，Gtilab為服務(wù)端，其負(fù)責(zé)代碼的托管，Gitlab CI任務(wù)的觸發(fā)及結(jié)果日志記錄等，真正運(yùn)行我們在.gitlab-ci.yml中的定義的執(zhí)行過程，是在客戶端Gitlab-Runner上執(zhí)行的，那么什么是Gitlab-Runner呢，其實(shí)就是一臺運(yùn)行有Gitlab-Runner的服務(wù)器或一個容器，只要安裝有Gitlab-Runner，并且這個服務(wù)器在Gitlab Server端進(jìn)行注冊，這個Gitlab-Runner就可以在Gitlab Server端的.gitlab-ci.yml中使用此Runner來執(zhí)行pipeline中的stage。

作為承載具體job的執(zhí)行者，Runner可以分布在不同的服務(wù)器上，針對服務(wù)器同時一臺主機(jī)也可以運(yùn)行多個Runner

Gitlab-Runner的分類：

Shared Runner：共享型Runner，所有的項(xiàng)目工程都可以利用此Runner來執(zhí)行job。

Specific Runner：特定型Runner，由于有權(quán)限控制此Runner只能為指定的項(xiàng)目工程服務(wù)。

Group Runner：如果將Runner注冊在項(xiàng)目組里面，那么該組內(nèi)的項(xiàng)目可以指定公用這個Runner。

Locked：Runner的一種狀態(tài)，此刻該Runner以及處于Locked狀態(tài)，被用項(xiàng)目鎖定，不能用于其他項(xiàng)目構(gòu)建

Paused：Runner以及被暫停，不能接受任何Job任務(wù)。

了解了Runner的分類和狀態(tài)，我們一起通過下圖更直觀的看下Runner

在上圖中，當(dāng)研發(fā)人員提交代碼或提交Merge Request時候觸發(fā)Pipeline，然后通過Runner來執(zhí)行，此時des-server可以安裝部署多個Runner，同時也可以部署一個公共的Runner服務(wù)器，然后通過該公共服務(wù)器的Runner部署代碼到des-server上。

上面理解了Gitlab Runner的概念及分類，在我們將Gitlab Runner運(yùn)行在服務(wù)器上后需要在平臺進(jìn)行注冊該Gitlab Runner，注冊的時候可以選擇該Gitlab Runner的Executor，Gitlab CI為了實(shí)現(xiàn)在不同場景下運(yùn)行構(gòu)建的任務(wù)，分為很多的執(zhí)行器。對于構(gòu)建一個項(xiàng)目，不同的Executor支持不同的平臺以及執(zhí)行不同的方法，我們來了解各個Executor的適應(yīng)場景，根據(jù)其特性并結(jié)合自己的業(yè)務(wù)來進(jìn)行選擇。

Shell：Shell Executor是配置的最簡單的執(zhí)行器，在一個服務(wù)器上安裝Gitlab Runner后，直接將其注冊到Server端口，并且后期運(yùn)行的job所需的所有依賴項(xiàng)都需要手動安裝在安裝在這臺注冊的系統(tǒng)上。

Docker：顧名思義，利用Docker 鏡像來作為Executor，其能夠保持干凈的構(gòu)建環(huán)境，并且容易進(jìn)行依賴管理(構(gòu)建項(xiàng)目的所有依賴項(xiàng)都可以放在 Docker 映像中)。

Docker Machine and Docker Machine SSH（autoscaling）：Docker Machine 是 Docker 執(zhí)行器的一個特殊版本，支持自動縮放。 它的工作原理與一般的 Docker 執(zhí)行程序類似，但使用的是 Docker Machine 的構(gòu)建機(jī)。

VirtualBox：其為運(yùn)行使用虛擬機(jī)作為執(zhí)行job的方式，Gitlab CI提供兩個系統(tǒng)虛擬化選項(xiàng): VirtualBox 和 Parallels。 然后 GitLab Runner 連接到虛擬機(jī)并在其上運(yùn)行構(gòu)建版本，這種方式可以很大程度 降低基礎(chǔ)設(shè)施成本。

SSH：為了完整性，添加了 SSH 執(zhí)行器，它是 GitLab Runner 連接到一個外部服務(wù)器，并在那里運(yùn)行構(gòu)建,類似一個跳板一樣。

Kubernete：在微服務(wù)盛行的今天，Kubernetes 執(zhí)行器允許將構(gòu)建過程放置在Kubernetes集群內(nèi)完成， 執(zhí)行者將調(diào)用 Kubernetes 集群 API，并為每個 GitLab 作業(yè)創(chuàng)建一個新的 Pod 來運(yùn)行構(gòu)建任務(wù)，構(gòu)建完成后去釋放掉次POD，當(dāng)有請求在創(chuàng)建，此中動態(tài)方式非常利用資源的利用以及環(huán)境一致性。

2.2 .gitlab-ci.yml

了解了gitlab-runner，接下來我們需要了解.gitlab-ci.yml中的個元素概念，了解了這些，后期通過這些基礎(chǔ)配置，來完成復(fù)雜高級的CI任務(wù)。

Pipeline：為一個構(gòu)建任務(wù)的集合，其為一次構(gòu)建任務(wù)，當(dāng)開發(fā)人員提交代碼或Merge Request合并的時候都可以觸發(fā)Pipeline，其內(nèi)部包含很多流程，

例如依賴安裝、編譯、測試、部署等。

Stages：為我們上面提到一個Pipeline中的各個流程，Pipeline為一個總的構(gòu)建任務(wù)，內(nèi)部包含多個Stages，Stages執(zhí)行任務(wù)需要遵循一些流程規(guī)則

所有的Stages都是從上到下順序執(zhí)行，當(dāng)?shù)谝粋€Stages執(zhí)行完成后，才開始下個Stages，以此類推；

當(dāng)其中任何一個Stages執(zhí)行失敗后，由于是順序執(zhí)行后面的Stages將不會被執(zhí)行，為了保證一致性，該P(yáng)ipeline則為失敗狀；

當(dāng)一個Pipeline中所有的Stages都成功執(zhí)行完成后，該P(yáng)ipeline狀態(tài)才為成功。

我們可以理解Pipeline為一個總體的大任務(wù)，完成這個大任務(wù)，需要很多步驟，這些步驟就是Stages，每個Stage有可以有多個jobs來組成，同Stages一樣，jobs的運(yùn)行也需要遵循一些流程規(guī)則

在同一個Stage中可能含有多個Job，這些Jobs在執(zhí)行過程中會并行執(zhí)行；

一個Stage中的任何一個job執(zhí)行失敗，那么該Stage失敗，同樣的Pipeline狀態(tài)也為失敗；

只有當(dāng)一個Stage中的所有job都執(zhí)行成功時，該Stage才為成功。

了解了上面的基本概念，我們以圖的形式再來回顧下各個概念：

如上圖，一個Pipeline為一次構(gòu)建任務(wù)，其中包含多個步驟Stage，例如安裝依賴/測試/部署等，例如在安裝依賴一個Stage內(nèi)又有多個Job，這些job并行運(yùn)行，例如安裝多個軟件，這些Job如果有一個失敗，那個這個Stage就為失敗，Stage是從上到下順序執(zhí)行，如果其中有一個Stage狀態(tài)失敗，則本次構(gòu)建任務(wù)也就是這個Pipeline就是失敗的。

三 Gitlab CI/CD工作流程

在我們了解了Gitlab CI的相概念后，讓我們來全局性的了解Gitlab CI/CD的工作流程，如下圖所示：

我們可以從圖中看到Gitlab 的CI/CD工作流只要分為三個階段

3.1 校驗(yàn)

在該步驟中Gitlab 主要完成CI功能，

開放人員提交代碼到一個特定的分支，改分支具有Gitlab CI

Gitlab CI完整構(gòu)建在其中有代碼掃描，性能測試，單元測試，容器掃描，依賴掃描等

在其中Gitlab的那個stage失敗后，需要開發(fā)者去進(jìn)行對應(yīng)修復(fù)，直到該分支的pipeline都構(gòu)建和測試正常

3.2 打包

之后可以通過應(yīng)用進(jìn)行預(yù)覽應(yīng)用，最終將成功的進(jìn)行制品管理

通過：Container Registry存儲docker鏡像

通過：NPM Registry存儲NPM包

通過Maven Repository存儲Maven工件

通過：Conan Repository存儲Conan包

3.3 發(fā)布

持續(xù)部署，將通過測試和構(gòu)建的分支merge 到主分支

通過手動確認(rèn)審批部署將應(yīng)用部署進(jìn)入正式環(huán)境，進(jìn)行應(yīng)用發(fā)布

通過GitLab Pages部署靜態(tài)網(wǎng)站

進(jìn)行金絲雀發(fā)布，讓一定比例的用戶群新功能

通過GitLab Releases增加發(fā)新的記錄

四 Gitlab CI中的關(guān)鍵字

4.1 關(guān)鍵字

在上面我們?nèi)值牧私釭itlab CI/CD的工作流程后，那們我們該怎樣開始我們的CI之旅呢，在開始之前，我們需要對應(yīng)gitlab-ci.yml中的核心關(guān)鍵字需要有非常清楚的認(rèn)識，在后續(xù)實(shí)戰(zhàn)中，完成具體的CI功能全部都是依賴于這些關(guān)鍵字,在此僅列出一些我們經(jīng)常用的核心關(guān)鍵字，后續(xù)如果根據(jù)實(shí)戰(zhàn)案例有自己自定義的需求，可以參考官方文檔進(jìn)行查閱：https://docs.gitlab.com/ce/ci/yaml/README.html

注意：在以下的核心關(guān)鍵字作為Gitlab CI內(nèi)置的保留字段，不能夠作為job的名稱

4.2 示例

上面我們了解了一些核心的關(guān)鍵字，下面讓我們以一個前端項(xiàng)目的示例來更為直觀的對關(guān)鍵字進(jìn)行說明

stages: # 定義該pipeline執(zhí)行的stage有三個，結(jié)構(gòu)為列表 - build # 構(gòu)建stage - test # 測試stage - deploy # 部署stage variables: # 定義變量，結(jié)構(gòu)為字典 BASE_DIR: "/data/frontendadmin/" # 變量的key為BASE_DIR， value為具體的主路徑 cache: # 定義緩存 paths: # 定義緩存的目錄，結(jié)果為列表 - node_modules/ # 具體需要緩存的路徑 - dist/ before_script: # 在開始job之前執(zhí)行的操作，一般用來初始化環(huán)境等 - cp ${BASE_DIR}.env.example ${BASE_DIR}.env - yarn install - yarn build build_job: # 定義構(gòu)建job的名稱 stage: build # 具體飲用stages中的job，需要名字保持一致 script: # 在該job中執(zhí)行的腳本 - yarn build tags: # 選擇使用那個gitlab runner來執(zhí)行此job - dev only: - develop # 選定改項(xiàng)目git倉庫中的develop分支進(jìn)行執(zhí)行改job when: always # 無論什么條件都執(zhí)行改job test_job: stage: test script: - yarn test tags: - dev only: - develop when: manual # 指定需要手動點(diǎn)擊才執(zhí)行改job deploy_job: stage: deploy only: - master # 僅對master分支進(jìn)行執(zhí)行改job script: - pm2 delete api || true - pm2 start dist/index.js --name api tags: - dev when: always

通過上門這個.gitlab-ci.yml我們能夠更加更加直觀的認(rèn)識到Gitlab CI中的一些關(guān)鍵字的作用和整個CI文件的大體結(jié)構(gòu)，

在這個pipeline中，定義來三個stage

在全局定義了環(huán)境變量BASE_DIR，可以在后續(xù)的job中進(jìn)行引用，如果定義在某一個job中則只能被改job引用，引用方式:${BASE_DIR}

定義了cache環(huán)境，用戶為各job中傳遞一些持久化的緩存文件,例如在java項(xiàng)目中編譯的jar/war包等。

利用before_script，在運(yùn)行stage前對我們部署的環(huán)境進(jìn)行了初始化

build：不管什么情況下，也就是總是對項(xiàng)目的develop分支利用tag為dev的gitlab runner進(jìn)行構(gòu)建

test：需要手動去點(diǎn)擊執(zhí)行job，同樣對develop分支進(jìn)利用tag為dev的gitlab runner執(zhí)行測試

deploy：總是對master分支，利用tag為dev的gitlab runner執(zhí)行改部署job

上面的示例是為了我們了解各關(guān)鍵字而設(shè)立的一個前端項(xiàng)目，在后面章節(jié)的實(shí)戰(zhàn)項(xiàng)目中，我們能夠結(jié)合實(shí)際案例來更清楚的了解每一個步驟，同時我們可以對自己現(xiàn)有的項(xiàng)目的CI進(jìn)行抽象化為各個stage，自己去編寫.gitlab-ci.yml進(jìn)行不斷的測試來了解關(guān)鍵字即結(jié)構(gòu)。

五 總結(jié)

通過該章節(jié)我們能夠系統(tǒng)的學(xué)習(xí)到gitlab中的關(guān)鍵組建的含義/分類以及.gitlab-ci.yml的語法及關(guān)鍵字，其次對Gitlab CI/CD的工作流程有了直觀的認(rèn)識，通過實(shí)例更清楚直觀的學(xué)習(xí)其中關(guān)鍵字的用戶和CI文件的結(jié)構(gòu)。

總結(jié)來說，想要使我們的項(xiàng)目能夠集成Gitlab CI，只需要在項(xiàng)目中注冊gitlab runner，其次在項(xiàng)目目錄下根據(jù)自己業(yè)務(wù)編寫.gitlab-ci.yml即可，至此我們的項(xiàng)目已經(jīng)擁有了CI的能力，那么我們在什么樣的場景下該如何根據(jù)自己的業(yè)務(wù)編寫CI文件呢，后續(xù)我們將幾個典型的實(shí)戰(zhàn)項(xiàng)目，從零到一實(shí)戰(zhàn)Gitlab CI，相信通過實(shí)戰(zhàn)定會對你后續(xù)的項(xiàng)目有更深層次的理解和認(rèn)識。

Git GitHub 敏捷開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。