基於GitOps的企業級CI/CD-知識星球

實現企業級的持續交付（CD）是一個巨大的挑戰。每一個公司都在對他們的軟體交付方式做創新，我們需要允許各個團隊學習構建並最佳化他們自己的交付流水線。在雲原生的世界裡正在發生，許多的最佳實踐正在萌芽。儘管如此，給予團隊靈活性做創新試驗時，也需要兼顧公司的安全和合規方面的要求。在這篇文章裡面，我將講述我們如何為一個大型企業客戶成功使用GitOps架構模型來獲得靈活性和安全性之間的平衡。

背景

這篇文章關註的物件是擁有數十個或者數百個開發團隊的公司。我假定他們都以Kubernetes作為應用的執行平臺。雖然文章裡面的原則也可以用在其他地方，但是Kubernetes確實讓我們的持續交付平臺的實現變得簡化，這種簡化也使得這篇文章能更加聚焦在我們需要討論的問題上。最後宣告，雖然這是一篇技術檔案，但是不會非常的深入。我將會使用方框和箭頭來描述解決方案，以後我可能會另寫一篇文章敘述技術細節。

靈活性激發創新

如果一個大公司裡面的每個團隊都被鎖定在同一個開發流程裡面，創新是非常困難的。因為創新常需要從上至下而且常常充滿風險；任何新的方法都是為了取代舊的。在一個大的複雜組織裡面改變工作流程是一項困難的工作，所以：從小處開始非常必要；之後有足夠大的空間去成長。

這裡給出兩個例子來描述一個團隊可能採用的不同流程。第一個嚴重依賴人力工作和批准；第一個比較成熟一些，依賴於自動化測試且省去了管理批准。這2個例子說明瞭在一個組織裡面給幾十或者幾百個團隊強制一種解決方案是多麼的荒唐。每個團隊有自身的獨特情況，會基於此來對他們的軟體交付方式做創新。

P1：透過人工的QA批准的持續交付流程

P2: 透過全自動的測試實現的持續交付流程

合規與安全

讓我們近距離觀察合規與安全需求！在合規方面，企業自身有嚴格的需求之外，也必須符合政府相關的規範。

在軟體交付領域中一般有如下的合規&安全需求：

訪問控制——控制誰能夠在什麼環境部署什麼內容
審計追溯——記錄對環境的所有變更，包括誰改動了什麼，為什麼而改
批准流程——對特定環境的變更需要得到授權批准以後才能進行

由於持續交付流程改變了關鍵的軟體環境，它在滿足這些需求方面也有很大的責任。如果開發團隊不準接觸生產環境，那麼CD平臺也不行，除非它有能夠做這個部署操作的授權。這僅僅是一個例子而已。我們接下來深入闡述建立一個滿足靈活，安全，合規的平臺有多困難。

從Jenkins部署

我們先看一下使用流行的Jenkins Pipeline外掛實現的原生的持續交付流水線。這是實現CD流水線的一種簡單方式，對大多數環境已經足夠了，但是不適用於我們的場景。

這個流水線會構建Docker image並部署到Kubernetes上，非常好。但是問題在哪？

首先，Jenkins必須有訪問所有Kubernetes叢集的帳號資訊（包括生產的）。這意味著對Jenkins的admin許可權必須限制到有許可權訪問生產的人，這就限制了開發團隊選擇自己工具的能力。

其次，任何可以訪問Jenkinsfile的人都可以修改流水線，他們可以直接列印生產環境的訪問賬戶，並對生產環境做修改。這表示我們甚至不能讓開發人員去修改Jenkinsfile。這會是一個極大的限制，因為每個團隊的pipeline都是不同的，甚至同一個團隊的不同服務也是不同的（靈活性的需求）。

總之，我們在Jenkins裡面存放訪問資訊會嚴重限制開發團隊的靈活性。這明顯不是我們希望的，也說明瞭這種直接的方式為什麼是不夠的。

GitOps

我們已經看到我們的標的是實現一個安全，合規，同時又靈活的CI/CD系統。我們該如何做呢？

我們可以將部署交付流程從部署流程中剝離開始。這樣叢集的訪問資訊就從執行交付的Jenkins流水線裡面移除了，部署流程可以放到另一個Jenkins或者其他工具中——這裡我為了簡單起見仍然用Jenkins。

隔離以後，我們需要一種方式讓交付流程通知部署流程：你需要部署某個應用的某個版本或者對環境做變更（比如增加一個新的環境變數）。一種簡單或者相當強大的解決方案是讓Git當作這兩個流程的中間人。我們可以建立一個Git repo，裡麵包括我們所有的環境相關資訊，然後讓部署流程監聽這個repo的變化。

P3: 基於GitOps的持續交付架構

註意Git repo是如何將我們的部署流程從交付流程中剝離的。從交付流程來看，部署就代表著往中間的git repo做一個commit。這樣交付流程不會接觸到Kubernetes叢集。同時任何時候有程式碼merge進這個git repo中交付流程就會啟動。

GitOps最近由Weaveworks的Alexis Richardson提出，已經獲得了很多矚目。基礎設施即程式碼的思想已經存在好幾年了，它隨公有雲而生，因為所有的資源都可以定義為程式碼。GitOps是將這種思想邏輯延伸到Kubernetes裡面執行著的應用上。Kubernetes的部署機制允許我們以文字檔案描述我們的應用，並放到Git中。

讓我們看看GitOps是如何幫助我們解決三個合規性問題的：

訪問控制：只有對環境的配置的git repo有寫許可權的人才能對這個環境做部署。
批准流程：對於敏感的環境，我們可以允許開發團隊的Jenkins建立PR，但是隻有授權的人才能merge。這就用很小的實現開銷建立了一個非常好的批准流程。
審計：因為Git是一個版本控制系統，它天然的記錄的更新的所有資訊。每個Git commit的都包括了誰做的更改，已經對更改的描述。

最後引入GitOps讓我們能夠在滿足合規需求的情況下建立了一個安全的軟體交付流程。如果運維的repo上的使用者管理配置合理——只有授權以後的人才能做merge PR的操作。開發團隊在沒有運維團隊授權的情況下是無法更改生產環境的。

我們只是重新做了一遍“基礎設施即程式碼”？

基礎設施即程式碼的思想還沒到達GitOps這個層次。類似於CloudFormation和Terraform的工具很流行，可以讓我們輕鬆的管理基礎設施程式碼。這些工具用來描述基礎設施，而Kubernetes聚集於以容器的方式執行應用（微服務）。在容器裡面不斷更新的程式碼是我們需要做持續交付的地方。我們喜歡利用已經有的CI工具來處理這些快速的釋出，而且CD本身就是CI的持續。

結論

使用Git做為中介來將部署流程從交付流水線裡面解耦是一種有效的方式來實現在安全和合規限制嚴苛的環境下實現持續交付的手段。它省去了我們必須找到一個完美的工具，既能夠做好持續交付和部署的靈活性；同時又有高階的使用者管理，授權以及審計的能力。雖然解耦後的方案增加了一定的複雜度，但是我們能夠實現為不同的交付流水線和執行部署選擇不同工具的標的。

在一個企業的環境中，這樣的自由性有很大的收益——可以允許一次改動一小部分，也讓未來遷移到更好的工具變得容易許多。

原文連結：https://container-solutions.com/enterprise-grade-ci-cd-with-gitops/

基於GitOps的企業級CI/CD

相關推薦

熱門標籤

熱門文章

分享創造快樂