為了解決傳統應用升級緩慢、架構臃腫、不能快速迭代、故障不能快速定位、問題無法快速解決等問題，云原生這一概念橫空出世。云原生可以改進應用開發的效率，改變企業的組織結構，甚至會在文化層面上直接影響一個公司的決策，可以說，云時代的云原生應用大勢已來。在容器領域內，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分支有更新時，就會觸發與前面的構建類似的流程把應用推進到預發環境和生產環境。

轉載于:https://blog.51cto.com/14031893/2385156

總結

以上是生活随笔為你收集整理的GitOps:Kubernetes多集群环境下的高效CICD实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。