GitOps:Kubernetes多集羣環境下的高效CICD實踐

爲了解決傳統應用升級緩慢、架構臃腫、不能快速迭代、故障不能快速定位、問題沒法快速解決等問題，雲原生這一律念橫空出世。雲原生能夠改進應用開發的效率，改變企業的組織結構，甚至會在文化層面上直接影響一個公司的決策，能夠說，雲時代的雲原生應用大勢已來。在容器領域內，Kubernetes已經成爲了容器編排和管理的社區標準。它經過把應用服務抽象成多種資源類型，好比Deployment、Service等，提供了一個雲原生應用通用的可移植模型。在這樣的背景下，咱們如何在雲原生的環境下實踐更高效的DevOps來達到更有生產力的表現就成爲了一個新的課題和訴求。

與GitOps這個概念相比，你們可能對DevOps的概念已經耳熟能詳了。起初DevOps是爲了打破開發測試、運營這些部門之間的壁壘，經過自動化的構建、程式化的腳本，最低限度減小人工偏差，必定程度上提升應用版本的迭代效率；容器技術出現之後，輕量、標準化的能力使得DevOps技術纔有了日新月異的發展。無論技術怎樣更新迭代，DevOps最主要的核心訴求是不變的，那就是提升應用迭代的頻率和下降成本。GitOps就是DevOps的邏輯擴展，它的核心目標是爲了更加高效和安全的應用發佈。

首先咱們提取出一些用戶在作devops的過程當中遇到的痛點進行分析。第一個問題是如何自動化推動應用在環境棧中的無差異發佈.這裏我列舉了三種環境，測試環境、生產環境和預發環境，對於一個應用來講，咱們一般的設定都是把不一樣分支部署到對應環境，好比master分支的源碼對應的是線上環境，latest分支對應的是預發環境，其餘開發分支對應地部署到測試環境；目前大多數的作法是建立不一樣的job，拉取不一樣的源碼分支、部署到不一樣的環境，或者同一個job，經過添加不一樣的構建參數來決定進行怎樣的構建和發佈動做。 很是容易產生混亂和不便於管理。

第二個問題就是，生產環境的發佈權限通常都是須要嚴格控制的，一般只有應用管理員或者運維管理員纔有生產發佈權限。咱們在跟一些客戶的交流中發現，一種方式是在同一套cicd環境中建立不一樣的job，而後經過基於角色訪問控制策略來作job的隔離，只有管理員權限的人員才能看到用於發佈生產的job； 更直接的一種作法就是再建一套cicd環境專門作生產環境的發佈， 但這樣既浪費資源又下降了應用迭代的頻率。

第三個問題是說咱們想要提升應用迭代的頻率進而下降人力成本、時間成本、把精力放在新業務或創新業務的拓展上，但目前咱們的開發測試人員在應用運行狀態或測試結果的同步與反饋上有必定的隔閡，另一個是線上業務出現問題的時候，如何快速定位、復現和回滾，這是一個咱們能夠重點思考的地方。以上三點只是我列舉出來的咱們用戶在實際使用cicd的過程當中的一些痛點的子集，那接下來咱們就帶着這些問題來看一下gitops模型的設計思路是怎樣的

咱們在設計gitosp發佈模型的時候是有如下這些核心訴求的：第一個是版本管理，咱們但願每個發佈的應用的版本號都能跟git commit id關聯，這樣的好處就是每個變動都有歷史記錄查詢、能夠更快進行故障定位和修復，第二個是基線管理，這裏咱們一下子會講到分兩種類型的基線，第三個是怎麼作安全發佈，包括髮布權限管理以及安全審批的內容；最後一個是如何讓開發測試人員快速獲取反饋

首先gitops的核心思想就是將應用系統的聲明性基礎架構和應用程序存放在Git版本庫中，全部對應用的操做變動都來源於Git倉庫的更新，這也是gitops這個名稱的由來。另一個問題是，按照以往通用的作法，咱們可能會把應用如何構建如何部署的腳本以及配置文件跟應用源碼自己存放在同一個倉庫裏，這樣帶來的問題有兩個，一是開發人員可能還須要維護這個部署腳本或配置文件，不能把精力集中到產品開發上，另一個問題是部署腳本有時候會涉及環境敏感信息，安全性不夠，因此咱們這裏必定要把應用源碼倉庫與構建倉庫分開管理。

接下來就是基線管理，基線管理分兩種，一種是環境棧基線，如圖所示，咱們的設定是，生產環境只能部署master分支的代碼，預發環境只能部署latest分支的代碼，預覽環境用來部署其餘開發分支，這裏有個名詞叫預覽環境，其實也就是測試環境，但咱們會在開發分支經過測試、經過驗證成功合併到latest分支之後動態銷燬這個測試環境，固然這在kubernetes容器集羣下是很是容器作到的，在其餘具體的場景下能夠用不一樣的策略。這個基線咱們能夠把它稱爲小基線，它是用來明確管理應用在預覽、預發、生產環境中的推動的。大基線是針對線上發佈版本的管理的，這能保證咱們在線上出現故障的時候能快速回滾到上一個穩定的版本。這在生產發佈管理中是必不可少的，在gitops中咱們還能快速定位故障精確到某個git commit。

而後是應用發佈的權限管理和安全審批，gitops中的權限管理是經過代碼合併的控制來作的，在這個模型中，普通的開發人員沒有cicd環境好比jenkins的訪問權限，更精確地說的話是隻有日誌查看的權限，在git這一端，普通開發者只有向開發測試分支推送代碼的權限，並能夠申請向latest分支合併代碼，即提交MR/PR的權限，當普通開發者新建MR/PR後，就會觸發構建把應用部署到預覽環境，管理員經過查看這個新分支的構建部署是否經過一系列測試和驗證來決定是否接受這個MR/PR， 只有管理員接受MR/PR的合併後，latest分支代碼纔會從新構建和部署到預發環境，這樣就經過MR/PR的接受和拒絕來達到應用發佈安全審批的目的。

最後是如何進行快速反饋和團隊成員間的互動，這包括兩部份內容：一個是普通開發測試人員在推送源碼後，能經過郵件、釘釘、slack等工具實時地獲取構建結果，對本身的應用進行高效開發測試，；另外一方面是能在MR/PR的頁面上查看自動化測試的反饋結果、應用預覽連接、其餘團隊成員的comment等。

下面是使用GitOps管理應用發佈到不一樣kubernetes集羣的架構圖和時序圖。首先是應用源碼與構建源碼分離。最上面有一條虛線，虛線上面是普通開發者能看到的，或者說是有權限進行操做的部分，剩下其餘的部分都是管理員纔有權限作的，綠色區域是Jenkins的流水線任務。普通開發者沒有Jenkins環境的建立Job和構建Job的權限，他有的只是構建Job的日誌查看權限。這個普通應用是在Git倉庫裏，它有不一樣的分支，有必定設定的關係，每次有構建的時候會從另一個Git倉庫裏作，好比preview-plpeline、prod-plpeline，在這裏面能夠存放一些信息，只有應用管理員才能看到，普通開發者沒有權限看到信息。 而後咱們須要設置應用發佈環境棧，這在個示例中咱們有預覽環境、預發環境、生產環境的設置，應用在預發環境和生產環境中的發佈是須要通過管理員安全審批的。

最後是一個時序圖，開發人員提交新的feature，建立指向latest分支的MR，建立MR的動做會觸發preview-plpeline的構建，構建會拉取preview-plpeline的構建倉庫，構建倉庫存放的是構建腳本以及要部署的環境信息。而後就是自動化的構建流程，首先會從應用源碼倉庫把應用源碼拉取下來作構建，靜態代碼測試、單元測試，測試結果會反饋到MR上，而後打包容器鏡像並把鏡像推送到鏡像倉庫，最後會把應用經過文件部署到Kubernetes的集羣裏並進行功能測試，測試結果反饋到MR上，部署以後會收集應用相關信息，經過釘釘通知發送到開發羣裏。開發人員收到釘釘通知，能夠直接點擊連接查看應用狀態，若是有問題，能夠返回來本身從新開發，再從新進行提交，把前面的流程再走一遍，沒問題就能夠請求管理員進行審批，把代碼合併到latest分支。latest分支和master分支有更新時，就會觸發與前面的構建相似的流程把應用推動到預發環境和生產環境。

---

本文做者：流生

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。