摘要：在容器領(lǐng)域內(nèi)，已經(jīng)成為了容器編排和管理的社區(qū)標(biāo)準(zhǔn)。就是的邏輯擴(kuò)展，它的核心目標(biāo)是為了更加高效和安全的應(yīng)用發(fā)布。第二個(gè)問題就是，生產(chǎn)環(huán)境的發(fā)布權(quán)限一般都是需要嚴(yán)格控制的，通常只有應(yīng)用管理員或者運(yùn)維管理員才有生產(chǎn)發(fā)布權(quán)限。

為了解決傳統(tǒng)應(yīng)用升級(jí)緩慢、架構(gòu)臃腫、不能快速迭代、故障不能快速定位、問題無法快速解決等問題，云原生這一概念橫空出世。云原生可以改進(jìn)應(yīng)用開發(fā)的效率，改變企業(yè)的組織結(jié)構(gòu)，甚至?xí)谖幕瘜用嫔现苯佑绊懸粋€(gè)公司的決策，可以說，云時(shí)代的云原生應(yīng)用大勢(shì)已來。在容器領(lǐng)域內(nèi)，Kubernetes已經(jīng)成為了容器編排和管理的社區(qū)標(biāo)準(zhǔn)。它通過把應(yīng)用服務(wù)抽象成多種資源類型，比如Deployment、Service等，提供了一個(gè)云原生應(yīng)用通用的可移植模型。在這樣的背景下，我們?nèi)绾卧谠圃沫h(huán)境下實(shí)踐更高效的DevOps來達(dá)到更有生產(chǎn)力的表現(xiàn)就成為了一個(gè)新的課題和訴求。

與GitOps這個(gè)概念相比，大家可能對(duì)DevOps的概念已經(jīng)耳熟能詳了。起初DevOps是為了打破開發(fā)測(cè)試、運(yùn)營這些部門之間的壁壘，通過自動(dòng)化的構(gòu)建、程式化的腳本，最低限度減少人工誤差，一定程度上提高應(yīng)用版本的迭代效率；容器技術(shù)出現(xiàn)以后，輕量、標(biāo)準(zhǔn)化的能力使得DevOps技術(shù)才有了突飛猛進(jìn)的發(fā)展。不管技術(shù)怎樣更新迭代，DevOps最主要的核心訴求是不變的，那就是提高應(yīng)用迭代的頻率和降低成本。GitOps就是DevOps的邏輯擴(kuò)展，它的核心目標(biāo)是為了更加高效和安全的應(yīng)用發(fā)布。

首先我們提取出一些用戶在做devops的過程中遇到的痛點(diǎn)進(jìn)行分析。第一個(gè)問題是如何自動(dòng)化推進(jìn)應(yīng)用在環(huán)境棧中的無差別發(fā)布.這里我列舉了三種環(huán)境，測(cè)試環(huán)境、生產(chǎn)環(huán)境和預(yù)發(fā)環(huán)境，對(duì)于一個(gè)應(yīng)用來說，我們通常的設(shè)定都是把不同分支部署到對(duì)應(yīng)環(huán)境，比如master分支的源碼對(duì)應(yīng)的是線上環(huán)境，latest分支對(duì)應(yīng)的是預(yù)發(fā)環(huán)境，其他開發(fā)分支對(duì)應(yīng)地部署到測(cè)試環(huán)境；目前大多數(shù)的做法是創(chuàng)建不同的job，拉取不同的源碼分支、部署到不同的環(huán)境，或者同一個(gè)job，通過添加不同的構(gòu)建參數(shù)來決定進(jìn)行怎樣的構(gòu)建和發(fā)布動(dòng)作。 非常容易產(chǎn)生混亂和不便于管理。

第二個(gè)問題就是，生產(chǎn)環(huán)境的發(fā)布權(quán)限一般都是需要嚴(yán)格控制的，通常只有應(yīng)用管理員或者運(yùn)維管理員才有生產(chǎn)發(fā)布權(quán)限。我們?cè)诟恍┛蛻舻慕涣髦邪l(fā)現(xiàn)，一種方式是在同一套cicd環(huán)境中創(chuàng)建不同的job，然后通過基于角色訪問控制策略來做job的隔離，只有管理員權(quán)限的人員才能看到用于發(fā)布生產(chǎn)的job； 更直接的一種做法就是再建一套cicd環(huán)境專門做生產(chǎn)環(huán)境的發(fā)布， 但這樣既浪費(fèi)資源又降低了應(yīng)用迭代的頻率。

第三個(gè)問題是說我們想要提高應(yīng)用迭代的頻率進(jìn)而降低人力成本、時(shí)間成本、把精力放在新業(yè)務(wù)或創(chuàng)新業(yè)務(wù)的拓展上，但目前我們的開發(fā)測(cè)試人員在應(yīng)用運(yùn)行狀態(tài)或測(cè)試結(jié)果的同步與反饋上有一定的隔閡，另外一個(gè)是線上業(yè)務(wù)出現(xiàn)問題的時(shí)候，如何快速定位、復(fù)現(xiàn)和回滾，這是一個(gè)我們可以重點(diǎn)思考的地方。以上三點(diǎn)只是我列舉出來的我們用戶在實(shí)際使用cicd的過程中的一些痛點(diǎn)的子集，那接下來我們就帶著這些問題來看一下gitops模型的設(shè)計(jì)思路是怎樣的

我們?cè)谠O(shè)計(jì)gitosp發(fā)布模型的時(shí)候是有以下這些核心訴求的：第一個(gè)是版本管理，我們希望每一個(gè)發(fā)布的應(yīng)用的版本號(hào)都能跟git commit id關(guān)聯(lián)，這樣的好處就是每一個(gè)變更都有歷史記錄查詢、可以更快進(jìn)行故障定位和修復(fù)，第二個(gè)是基線管理，這里我們一會(huì)兒會(huì)講到分兩種類型的基線，第三個(gè)是怎么做安全發(fā)布，包括發(fā)布權(quán)限管理以及安全審批的內(nèi)容；最后一個(gè)是如何讓開發(fā)測(cè)試人員快速獲取反饋

首先gitops的核心思想就是將應(yīng)用系統(tǒng)的聲明性基礎(chǔ)架構(gòu)和應(yīng)用程序存放在Git版本庫中，所有對(duì)應(yīng)用的操作變更都來源于Git倉庫的更新，這也是gitops這個(gè)名稱的由來。另外一個(gè)問題是，按照以往通用的做法，我們可能會(huì)把應(yīng)用如何構(gòu)建如何部署的腳本以及配置文件跟應(yīng)用源碼本身存放在同一個(gè)倉庫里，這樣帶來的問題有兩個(gè)，一是開發(fā)人員可能還需要維護(hù)這個(gè)部署腳本或配置文件，不能把精力集中到產(chǎn)品開發(fā)上，另外一個(gè)問題是部署腳本有時(shí)候會(huì)涉及環(huán)境敏感信息，安全性不夠，所以我們這里一定要把應(yīng)用源碼倉庫與構(gòu)建倉庫分開管理。

接下來就是基線管理，基線管理分兩種，一種是環(huán)境?；€，如圖所示，我們的設(shè)定是，生產(chǎn)環(huán)境只能部署master分支的代碼，預(yù)發(fā)環(huán)境只能部署latest分支的代碼，預(yù)覽環(huán)境用來部署其他開發(fā)分支，這里有個(gè)名詞叫預(yù)覽環(huán)境，其實(shí)也就是測(cè)試環(huán)境，但我們會(huì)在開發(fā)分支通過測(cè)試、通過驗(yàn)證成功合并到latest分支以后動(dòng)態(tài)銷毀這個(gè)測(cè)試環(huán)境，當(dāng)然這在kubernetes容器集群下是非常容器做到的，在其他具體的場(chǎng)景下可以用不同的策略。這個(gè)基線我們可以把它稱為小基線，它是用來明確管理應(yīng)用在預(yù)覽、預(yù)發(fā)、生產(chǎn)環(huán)境中的推進(jìn)的。大基線是針對(duì)線上發(fā)布版本的管理的，這能保證我們?cè)诰€上出現(xiàn)故障的時(shí)候能快速回滾到上一個(gè)穩(wěn)定的版本。這在生產(chǎn)發(fā)布管理中是必不可少的，在gitops中我們還能快速定位故障精確到某個(gè)git commit。

然后是應(yīng)用發(fā)布的權(quán)限管理和安全審批，gitops中的權(quán)限管理是通過代碼合并的控制來做的，在這個(gè)模型中，普通的開發(fā)人員沒有cicd環(huán)境比如jenkins的訪問權(quán)限，更精確地說的話是只有日志查看的權(quán)限，在git這一端，普通開發(fā)者只有向開發(fā)測(cè)試分支推送代碼的權(quán)限，并可以申請(qǐng)向latest分支合并代碼，即提交MR/PR的權(quán)限，當(dāng)普通開發(fā)者新建MR/PR后，就會(huì)觸發(fā)構(gòu)建把應(yīng)用部署到預(yù)覽環(huán)境，管理員通過查看這個(gè)新分支的構(gòu)建部署是否通過一系列測(cè)試和驗(yàn)證來決定是否接受這個(gè)MR/PR， 只有管理員接受MR/PR的合并后，latest分支代碼才會(huì)重新構(gòu)建和部署到預(yù)發(fā)環(huán)境，這樣就通過MR/PR的接受和拒絕來達(dá)到應(yīng)用發(fā)布安全審批的目的。

最后是如何進(jìn)行快速反饋和團(tuán)隊(duì)成員間的互動(dòng)，這包括兩部分內(nèi)容：一個(gè)是普通開發(fā)測(cè)試人員在推送源碼后，能通過郵件、釘釘、slack等工具實(shí)時(shí)地獲取構(gòu)建結(jié)果，對(duì)自己的應(yīng)用進(jìn)行高效開發(fā)測(cè)試，；另一方面是能在MR/PR的頁面上查看自動(dòng)化測(cè)試的反饋結(jié)果、應(yīng)用預(yù)覽鏈接、其他團(tuán)隊(duì)成員的comment等。

下面是使用GitOps管理應(yīng)用發(fā)布到不同kubernetes集群的架構(gòu)圖和時(shí)序圖。首先是應(yīng)用源碼與構(gòu)建源碼分離。最上面有一條虛線，虛線上面是普通開發(fā)者能看到的，或者說是有權(quán)限進(jìn)行操作的部分，剩下其他的部分都是管理員才有權(quán)限做的，綠色區(qū)域是Jenkins的流水線任務(wù)。普通開發(fā)者沒有Jenkins環(huán)境的創(chuàng)建Job和構(gòu)建Job的權(quán)限，他有的只是構(gòu)建Job的日志查看權(quán)限。這個(gè)普通應(yīng)用是在Git倉庫里，它有不同的分支，有一定設(shè)定的關(guān)系，每次有構(gòu)建的時(shí)候會(huì)從另外一個(gè)Git倉庫里做，比如preview-plpeline、prod-plpeline，在這里面可以存放一些信息，只有應(yīng)用管理員才能看到，普通開發(fā)者沒有權(quán)限看到信息。 然后我們需要設(shè)置應(yīng)用發(fā)布環(huán)境棧，這在個(gè)示例中我們有預(yù)覽環(huán)境、預(yù)發(fā)環(huán)境、生產(chǎn)環(huán)境的設(shè)置，應(yīng)用在預(yù)發(fā)環(huán)境和生產(chǎn)環(huán)境中的發(fā)布是需要經(jīng)過管理員安全審批的。

最后是一個(gè)時(shí)序圖，開發(fā)人員提交新的feature，創(chuàng)建指向latest分支的MR，創(chuàng)建MR的動(dòng)作會(huì)觸發(fā)preview-plpeline的構(gòu)建，構(gòu)建會(huì)拉取preview-plpeline的構(gòu)建倉庫，構(gòu)建倉庫存放的是構(gòu)建腳本以及要部署的環(huán)境信息。然后就是自動(dòng)化的構(gòu)建流程，首先會(huì)從應(yīng)用源碼倉庫把應(yīng)用源碼拉取下來做構(gòu)建，靜態(tài)代碼測(cè)試、單元測(cè)試，測(cè)試結(jié)果會(huì)反饋到MR上，然后打包容器鏡像并把鏡像推送到鏡像倉庫，最后會(huì)把應(yīng)用通過文件部署到Kubernetes的集群里并進(jìn)行功能測(cè)試，測(cè)試結(jié)果反饋到MR上，部署之后會(huì)收集應(yīng)用相關(guān)信息，通過釘釘通知發(fā)送到開發(fā)群里。開發(fā)人員收到釘釘通知，可以直接點(diǎn)擊鏈接查看應(yīng)用狀態(tài)，如果有問題，可以返回來自己重新開發(fā)，再重新進(jìn)行提交，把前面的流程再走一遍，沒問題就可以請(qǐng)求管理員進(jìn)行審批，把代碼合并到latest分支。latest分支和master分支有更新時(shí)，就會(huì)觸發(fā)與前面的構(gòu)建類似的流程把應(yīng)用推進(jìn)到預(yù)發(fā)環(huán)境和生產(chǎn)環(huán)境。

閱讀原文

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。