基於GitOps的企業級CI/CD

收藏待读

基於GitOps的企業級CI/CD

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

背景

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

靈活性激發創新

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

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

基於GitOps的企業級CI/CD

P1: 通過人工的QA批准的持續交付流程

基於GitOps的企業級CI/CD

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

合規與安全

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

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

1. 訪問控制 – 控制誰能夠在什麼環境部署什麼內容

2. 審計追溯 – 記錄對環境的所有變更,包括誰改動了什麼,為什麼而改

3. 批准流程 – 對特定環境的變更需要得到授權批准以後才能進行

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

從Jenkins部署

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

基於GitOps的企業級CI/CD

P1: 通過人工的QA批准的持續交付流程

基於GitOps的企業級CI/CD

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

合規與安全

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

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

1. 訪問控制 – 控制誰能夠在什麼環境部署什麼內容

2. 審計追溯 – 記錄對環境的所有變更,包括誰改動了什麼,為什麼而改

3. 批准流程 – 對特定環境的變更需要得到授權批准以後才能進行

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

從Jenkins部署

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

基於GitOps的企業級CI/CD

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

首先,Jenkins必須有訪問所有K8S集群的帳號信息(包括生產的)。 這意味着對Jenkins的admin權限必須限制到有權限訪問生產的人, 這就限制了開發團隊選擇自己工具的能力。

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

總之,我們在jenkins裏面存放訪問信息會嚴重限制開發團隊的靈活性。 這明顯不是我們希望的,也說明了這種直接的方式為什麼是不夠的。

GitOps

我們已經看到我們的目標是實現一個CI/CD系統來滿足安全,合規,並靈活這些「衝突的」目標。如何做呢?

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

隔離以後,我們需要一種方式讓交付流程通知部署流程: 你需要部署某個應用的某個版本或者對環境做變更(比如增加一個新的環境變量)。一種簡單或者相當強大的解決方案是讓GIt當作這兩個流程的中間人。 我們可以創建一個Git repo,裏面包括我們所有的環境相關信息,然後讓部署流程監聽這個repo的變化。

基於GitOps的企業級CI/CD

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

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

GitOps最近由Weaveworks的Alexis Richardson 基於GitOps的企業級CI/CD

,已經獲得了很多矚目。基礎設施即代碼的思想已經存在好幾年了,它隨公有雲而生,因為所有的資源都可以定義為代碼。GitOps是將這種思想邏輯延伸到K8S裏面運行着的應用上。K8S的部署機制允許我們以文本文件描述我們的應用,並放到Git中。

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

1. 訪問控制 : 只有對環境的配置的git repo有寫權限的人才能對這個環境做部署

2. 批准流程 : 對於敏感的環境,我們可以允許開發團隊的jenkins創建PR,但是只有授權的人才能merge。 這就用很小的實現開銷創建了一個非常好的批准流程。

3. 審計 : 因為Git是一個版本控制系統,它天然的記錄的更新的所有信息。 每個Git commit的都包括了誰做的更改,已經對更改的描述。

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

我們只是重新做了一遍「基礎設施即代碼」?

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

結論

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

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

原文鏈接:

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

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

GitOps最近由Weaveworks的Alexis Richardson 基於GitOps的企業級CI/CD

,已經獲得了很多矚目。基礎設施即代碼的思想已經存在好幾年了,它隨公有雲而生,因為所有的資源都可以定義為代碼。GitOps是將這種思想邏輯延伸到K8S裏面運行着的應用上。K8S的部署機制允許我們以文本文件描述我們的應用,並放到Git中。

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

1. 訪問控制 : 只有對環境的配置的git repo有寫權限的人才能對這個環境做部署

2. 批准流程 : 對於敏感的環境,我們可以允許開發團隊的jenkins創建PR,但是只有授權的人才能merge。 這就用很小的實現開銷創建了一個非常好的批准流程。

3. 審計 : 因為Git是一個版本控制系統,它天然的記錄的更新的所有信息。 每個Git commit的都包括了誰做的更改,已經對更改的描述。

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

我們只是重新做了一遍「基礎設施即代碼」?

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

結論

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

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

原文鏈接: https://container-solutions.co … tops/

原文 : DockOne

相關閱讀

免责声明:本文内容来源于DockOne,已注明原文出处和链接,文章观点不代表立场,如若侵犯到您的权益,或涉不实谣言,敬请向我们提出检举。