原文做者Jason Bloomberg是Intellyx的創始人兼總裁，他爲SiliconANGLE撰寫了這篇文章，就其數字化轉型戰略向商業領袖和技術供應商提供了建議。本文經D2iQ翻譯並有所刪改。原文地址：https://siliconangle.com/2020/09/11/meet-gitops-key-launching-effective-software-releases-cloud-native-era/git
導讀數據庫
GitOps是一種雲原生運維模型，將軟件開發領域面向Git的最佳實踐擴展到了Ops，與雲原生運維所需的基於配置的方法保持一致。GitOps具備充分的資格來抽象化大規模處理臨時軟件資產所需的環境、部署和配置之間的全部差別，有望在規模上甚至在機羣級別上起做用。服務器
DevOps背後的自動化故事主要圍繞CI/CD，即持續集成和部署，從而爲生產作好工做代碼的準備。微信
然而，部署並不是這一流程的終點。代碼發佈每每是被忽略的步驟——將新軟件展現給客戶和最終用戶，同時確保知足業務的持續目標。網絡
在傳統的本地和雲環境中，要實現這種以客戶爲中心的CI/CD快速部署很是困難。可是，當將其部署到Kubernetes驅動的雲原生環境時，因爲運維環境的超大規模和即時性，須要從新的端到端思考——如何將軟件發佈到生產環境中以及如何運維。架構
對雲原生計算的空前需求app
雖然目前大多數企業都在加緊摸索Kubernetes部署，但部分行業，尤爲是電信行業，已經開始展望空前的規模需求。框架
做爲5G擴建的一部分，電信公司正在基站和存在點創建小型數據中心。可是「小型」是一個具備誤導性的形容詞，由於這些數據中心自己本質上就是雲，每一個數據中心可能運行數十萬甚至數百萬個Kubernetes集羣。運維
從電信業務的角度來看，產品經理但願可以以複雜、動態的方式向客戶推出新服務。他們可能但願向一小部分客戶推出新功能，而後隨着時間的推移擴展其部署。他們可能會針對地理位置而推出特定的產品。或者，他們可能會經過合規性限制來劃分不一樣的服務類別。分佈式
此外，電信公司身先士卒。許多行業，從銀行業到汽車業，再到媒體業，也在尋求利用相似的功能來提升市場份額和客戶價值。
此類企業可能但願向其各自客戶羣的不一樣細分市場儘量推出普遍多樣的服務產品。一樣，他們的技術基礎設施及支持人員的規模也遠遠超出了幾年前的需求。
一方面，這種針對短暫性和規模的業務需求的爆炸性增加正在推進Kubernetes生態系統異常迅速地走向成熟。
另外一方面，全部這些尖端技術都必須發揮切實的做用。而這正是雲原生運維的用武之地。
雲原生運維的基礎
雲原生計算採用既定的「基礎設施即代碼」原則，並將其擴展到模型驅動、基於配置的基礎設施。雲原生還利用了「shift left」、基礎設施不變原則，偏重可擴展性而非定製性，這自己就是一種模型驅動的實踐。
儘管要實現雲原生計算的目標，須要模型驅動、基於配置的軟件部署方法，可是這不足以應對在雲原生環境中確保已部署軟件的規模和短暫性的挑戰。
軟件團隊必須將這種可配置性擴展到生產環境中，對生產中的持續變化做出預期和處理。爲此，必須使用金絲雀部署、藍/綠部署、自動回滾和其餘技術來應對和利用生產環境中不斷髮生的、沒法預測的變化。
跨不一樣的生產環境中進行提取也是一個重要的挑戰。不管是不一樣的公共雲、不一樣的Kubernetes發行版，仍是將雲和本地環境混合在一塊兒的混合IT挑戰（可能出於合規性緣由），雲原生髮布編排都必須抽象化此類差別，以便提供一致的、基於配置的方法，跨此類差別實現自動化部署。
依賴性管理也是必不可少的。不管是單個微服務之間的依賴關係，仍是對提供其餘類型軟件組件訪問權限的 API 的依賴關係，重要的是，即便單個組件是臨時的，意外的依賴關係也不得破壞部署。
最後，軟件團隊必須可以應對空前的規模。Kubernetes自己是按規模構建的，其架構可將微服務部署到容器中，將容器部署到pod中，將pod部署到集羣中，可是光有集羣還不夠。
企業已經在研究複雜的多集羣Kubernetes部署。軟件團隊還必須考慮集羣組、集羣組的「機羣」。這樣的機羣一般會覆蓋多個區域或數據中心，這給雲原生部門帶來了更大的挑戰。
GitOps：雲原生運維模型
一個有用的、極簡的作法是，雲原生社區將組織須要進行的全部工做簡化，使Kubernetes可以在「3天」內全面投入生產。
Day 0是計劃日。Day 1是部署Kubernetes和其餘雲原生生態系統的日子。Day 2則表明大規模全面運維的日子。
業內將如此複雜、相互關聯的一系列任務劃分爲3個獨立的日子，突顯出了一個重要的事實：迄今爲止，Day 2的任務一直未受到重視。爲了充分關注Day 2的問題，社區創造了一個術語：GitOps。
GitOps是一種雲原生運維模型，將本文迄今所討論的全部概念都歸入了考慮，包括在支持大規模動態生產環境的不可變基礎設施上進行模型驅動的、基於配置的部署。
GitOps的名字來自廣受歡迎的開源代碼管理工具Git。然而，SCM主要關注軟件生命週期的預發佈部分，但GitOps比Git更關注Ops。
GitOps將軟件開發領域面向Git的最佳實踐擴展到了Ops，與雲原生運維所需的基於配置的方法保持一致——直到如今，團隊才使用Git來管理和部署配置以及源代碼。
因爲GitOps具備充分的資格來抽象化大規模處理臨時軟件資產所需的環境、部署和配置之間的全部差別，所以這種方法有望在規模上甚至在機羣級別上起做用。
GitOps還承諾提供一種新的軟件治理方法，以解決瓶頸問題。在傳統的軟件開發（包括Agile）中，質量控制或變動控制委員會的審查要求可能會使軟件部署停滯不前。取而代之的是，GitOps對致使這種緩慢的政策進行了抽象化處理，使組織可以更好地利用自動化來快速交付適當的軟件管理。
供應商和開源項目逐步升級到雲原平生臺
雲原生計算的核心是開源軟件，所以，開源項目在雲原生運維中發揮先鋒做用是合乎邏輯的。
例如，用於Kubernetes的Argo CD是聲明性的、以GitOps爲中心的CD工具。一樣，Tekton是用於建立CI/CD系統的靈活開源框架，容許開發人員跨雲提供商和本地系統進行構建、測試和部署。
可是，從許多方面來看，此類項目只是雲原生運維難題中的冰山一角，將這些難題集中在一塊兒的是供應商。首先，許多供應商推銷基於模型驅動的配置方法。這裏有幾個例子。
例如，Digital.ai軟件公司採用模型驅動的可擴展方法，使更改易於執行並能夠傳播到全部環境。藉助Digital.ai，開發人員無需爲每一個部署實例維護複雜的腳本或工做流。
Octopus Deploy公司採用相似的方法，使用模型驅動的Ops配置在異構環境（例如，本地和雲）中提供簡單的配置抽象。
藉助Octopus，開發人員能夠將這些腳本放入Octopus中並對其進行參數化處理，從而建立抽象的配置和展示形式，而沒必要爲每一個環境編寫單獨的腳本。與單獨的CI/CD工具、ops工具和runbook自動化不一樣，Octopus提供了一個跨全部工具、環境和平臺的部署工具。
與Octopus相似，ShuttleOps公司將大量鏈接器、本身編碼的應用程序和基礎設施配置封裝起來，並將它們做爲管道工做流中的步驟進行參數化。而後將結果報告給所選的編排和管理工具。
CircleCI（Circle互聯網服務公司）和Cloudbees公司是另外兩個經過聲明性配置文件表示完整部署的供應商。
許多供應商還解決了生產中微服務（以及其餘組件）之間相互依賴性的問題。Cloud66公司使開發人員和架構師可以以抽象但肯定的方式定義服務依賴關係。這些依賴關係定義了運維必須管理的工做流。
接着，Cloud66能夠告訴開發人員什麼時候須要某個特定軟件的新版原本解決這種依賴關係，而且告訴運維人員他們須要作什麼來支持它。
Harness公司提供所謂的「連續交付抽象模型」，該模型使用模板消除依賴關係。CDAM經過自動回滾解決了上游和下游微服務依賴關係的影響。
運做中的GitOps
有多家供應商將雲原生運維與GitOps產品整合在一塊兒。
在WeaveWorks公司，GitOps具備環境感知能力，可生成表明其所需狀態的整個系統模型。WeaveWorks支持多種變體，例如，本地自定義平臺即服務——做爲同一綜合模型的一部分。WeaveWorks利用分佈式數據庫進行配置，這些配置可能支持數百萬個集羣，而且能夠在高延遲和偶爾斷開鏈接的環境中工做。
GitLab公司是另外一家提供顯式GitOps支持的供應商。GitLab提供了一個單一的平臺，它將基礎設施做爲代碼方法，將配置和策略定義爲「代碼」，同時利用自動化將更改與Git合併請求一塊兒應用。
GitLab中的這種自動化支持解決了許多治理問題，由於它能夠減小審批瓶頸。GitLabs的GitOps策略全都涉及自動化，例如，自動回滾。GitLab還支持版本證據，它能夠對每一個版本中包含的全部內容以及相關的元數據進行審計跟蹤。
D2IQ公司推出了本身的GitOps產品，稱之爲GitNative，它結合了GitOps和Kubernetes原生CI/CD。目標是經過從DevOps到GitOps再到GitNative的全生命週期Git自動化，最大限度地提升速度、規模和質量。
D2IQ採用了基礎設施不可變的方式——利用Kubernetes API和原語。D2IQ Kubernetes Platform既是無服務器又無狀態的，也可在本地運行。D2IQ還同時利用了Argo CD和Tekton開源項目。
最後一個以GitOps爲中心的供應商是Codefresh公司.，它使用Git做爲事實的惟一來源，自動並保護拉取請求和部署。它處理源代碼的來源並支持多個區域。
以機羣的規模航行
「Day 2 Kubernetes部署「的關鍵在於它們可否處理數以百萬計的大規模集羣。
一些供應商在推銷這種功能。WeaveWorks提供集羣管理，它運行在客戶選擇的託管Kubernetes平臺上，還能夠進行應用程序管理，包括髮布自動化和可擴展到機羣的漸進式CD。
Vamp.io BV利用基於Kubernetes的環境爲包含大量臨時微服務的應用程序提供發佈編排。該供應商爲DevOps提供了版本編排，能夠徹底自動化發佈，包括A/B測試，細粒度分段和多租戶發佈。
D2IQ提供大規模GitOps，能夠很好地處理大量異構節點，包括集羣、集羣組和機羣。D2IQ還提供單一管理平面來治理Kubernetes集羣的機羣。
最後
對於"傳統"企業中的任何人來講，他們很容易看到雲原生部署的大規模性和短暫性特徵，並想知道他們的組織是否須要遵循這些模式的軟件，這些軟件與當今企業環境中他們熟悉的大多數軟件有着天壤之別。
誠然，行業需求會有所不一樣，各個公司將面臨來自競爭對手的不一樣挑戰，但任何人都不該該所以認定本文提出的Day 2願景對本身不適用。
請記住，若是一種技術能力可以提升某些組織推出知足客戶需求的差別化產品和服務的能力，那麼他們的競爭對手也必須利用相似的能力，不然就會面臨失去競爭力的風險，最終沒法生存。
換句話說，雲原生計算已經到來。它已經爲那些利用這些能力向各自市場提供差別化產品和服務的企業提供大規模性和短暫性。若是您的組織不盡快跟上這股潮流，您的將來就會問題重重。不要掉隊！
*在原做者撰寫本文時，Digital.ai和Dynatrace之前是Intellyx的客戶。本文中提到的其餘任何組織都不是其客戶。
往期精彩文章
關於D2iQ
點擊「閱讀原文」，瞭解更多D2iQ Kubernetes Platform
本文分享自微信公衆號 - D2iQ（d2iq_apac）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。