導語編程
過去十年的編程經歷了一系列革命性的轉變。其中之一來自於圍繞devop的一組實踐，這些實踐使開發和運營團隊在一個共享的工做流程以及持續集成和分發（CI / CD）中保持一致，在這些實踐中devop團隊能夠提供不斷增量更新代碼庫。從單片代碼庫過渡到由編排平臺（如Kubernetes）管理的容器上運行的基於雲的微服務，這一轉變帶來了另外一種轉變。安全
正文服務器
在集羣或雲系統上運行的基於容器的應用程序可能很複雜，而且即便使用像Kubernetes這樣的平臺來編排事物，也很難對其進行配置和管理。GitOps是一組新興實踐，旨在經過應用devops和CI / CD 領域的技術來簡化此管理任務。微信
GitOps的關鍵是將基礎架構視爲代碼的想法，它採用與devop用來供應應用程序相同的基礎設施供應方法。所以，不只文件中描述了應用程序，並且底層主機和網絡都在文件中進行了描述，這些文件能夠像版本控制系統中的任何其餘代碼同樣被處理，並具備自動過程，可使實際應用程序收斂。與那些文件中所述的那個。網絡
在GitOps語言中，版本控制系統中的代碼是有關應用程序在生產中應該是什麼樣的惟一真實來源。架構
GitOps定義編程語言
Weaveworks是爲推廣GitOps概念所作的最大努力的公司。稍後咱們將詳細介紹Weaveworks角色，但首先讓咱們看一下GitOps的定義，該定義分爲兩部分：分佈式
Kubernetes和其餘雲原生技術的運營模型，提供了一套最佳實踐，能夠統一集羣，容器化應用程序的部署，管理和監視。svg
在應用程序管理中得到開發人員體驗的途徑，將端到端 CI / CD通道和Git工做流應用於操做和開發。微服務
換句話說，GitOps是一組專門用於管理Kubernetes和相似平臺的實踐，隨着愈來愈多的dev商店採用devop實踐並將代碼遷移到雲中，GitOps也適合更普遍的應用程序。可是，要了解GitOps的祕訣及其解決的問題，咱們必須談論其組件。
Git的定義
GitOps中的Git是指Linus Torvalds在2005年開發的流行的分佈式版本控制系統。Git是一種工具，它容許開發人員團隊在應用程序代碼庫中一塊兒工做，存儲他們先前修改的各類代碼分支。將它們合併到生產代碼中。Git中的一個關鍵概念是拉取請求，在該請求中，開發人員正式要求將他一直在從事的某些代碼集成到代碼庫中的另外一個分支中。
Git拉取請求爲團隊成員提供了機會，在就是否應將新代碼添加到應用程序達成共識以前進行協做和討論。Git還存儲了舊版本的代碼，若是出現問題，能夠輕鬆地返回到最新的良好版本，並容許您快速查看兩次修訂之間的更改。Git可能更被稱爲GitHub（雲託管版本控制系統）的基礎，可是Git自己是開源軟件，能夠部署在從內部公司服務器到PC的任何地方。
請記住，儘管咱們一般將Git視爲一種計算機編程工具，但實際上它與您所使用的內容無關。Git將很高興將任何文本文件集視爲其「 代碼庫 」，例如，但願跟蹤協做工做編輯的做者可使用Git 。這很重要，由於GitOps核心中的許多代碼庫都由聲明性配置文件而不是可執行代碼組成。
在進一步介紹以前要說的最後一件事：即便以「 Git」爲名，GitOps實際上並不須要使用Git。已經投資了其餘版本控制軟件（例如Subversion）的商店也能夠實現GitOps。可是，Git在開發人員世界中普遍用於實現CI / CD，所以大多數GitOps項目最終都將使用Git。
CI / CD流程是什麼？
對CI / CD的完整介紹不在本文的討論範圍以內，可是咱們須要說幾句話，由於它與理解GitOps的工做方式有關。經過諸如Git之類的版本控制存儲庫，能夠實現持續的CI / CD集成：開發人員能夠對其代碼庫進行不斷的細微改進，而沒必要每隔幾個月或幾年推出巨大的總體式版本。經過稱爲「 管道 」 的自動化系統，能夠在生產環境中構建，測試和部署新代碼，從而實現連續部署。
再說一次，咱們仍在談論代碼，一般會將以C，Java或JavaScript之類的編程語言編寫的可執行代碼的願景聚集在一塊兒。可是在GitOps中，咱們處理的「代碼」主要由配置文件組成。這不只是一個小細節，並且是GitOps的核心。正如咱們已經說過的，這些配置文件是「惟一的真理源」，描述了咱們的系統應如何。它們是聲明性的，而不是指導性的。這意味着配置文件不會說「啓動十臺服務器」，而只會說「該系統包括十臺服務器」。
GitOps公式的CI一半使開發人員能夠快速對這些配置文件進行調整和加強。當自動化軟件代理盡最大努力確保應用程序的實時版本可以反映配置文件中的描述時，就會產生一半的CD（使用GitOps語言與聲明性模型相融合）。
GitOps和Kubernetes
如前所述，GitOps概念最初是圍繞Kubernetes應用程序的管理而開發的。有了咱們如今所知道的，讓咱們回到這裏的Weaveworks GitOps討論，看看它們如何描述如何根據GitOps原理對託管Kubernetes進行更新。總結以下：
開發人員向Git請求新功能。
該代碼通過審覈和批准，而後合併到主代碼庫中。
合併激活CI / CD通道，該通道將自動測試和重建新代碼並將其顯示在註冊表中。
軟件代理會注意到更新，從註冊表中提取新代碼，並更新配置庫中的配置文件（以YAML編寫）。
Kubernetes集羣中的軟件代理會根據配置文件檢測到它已過期，刪除更改並實施新功能。
Weaveworks和GitOps
步驟4和5顯然是在作不少繁重的工做。使Git存儲庫中的「真相源」與實際的Kubernetes應用程序神奇地同步的軟件代理，使GitOps成爲可能。如前所述，就GitOps而言，使活動系統更像配置文件中描述的理想系統的過程稱爲收斂。（當實時系統與理想系統不一樣步時，稱爲發散。）理想狀況下，將經過自動化過程實現融合，可是自動化能夠作什麼存在侷限性，有時須要人工干預。
咱們已經用通用術語描述了該過程，可是若是您真的要看到Weaveworks頁面，則咱們提到的「軟件代理」是公司Weave Cloud平臺的一部分。「 GitOps 」一詞是由Weaveworks首席執行官Alexis Richardson創造的，它的部分做用是使Weaveworks平臺對已經沉迷於devop和CI / CD世界的開發人員具備吸引力。
可是Weaveworks從未聲稱過GitOps的壟斷，這不是特定產品，而是更多的哲學和最佳實踐。正如提供CI / CD解決方案的公司CloudBees的博客所指出的那樣，GitOps 表明了一種開放的，與供應商無關的模型，該模型是對Amazon等大型雲提供商部署的Kubernetes專有託管解決方案的一種反應。，Google和Microsoft。CloudBees提供了本身的GitOps解決方案，這一領域的衆多參與者也是如此。
GitOps和devops
Atlassian是一家開發了幾種敏捷開發人員工具的公司，在其博客文章中值得一讀，其中談到了GitOps的歷史和目的，他們認爲GitOps表明了這一思想的邏輯延伸。加入了devops。具體來講，GitOps是對基礎架構概念（即代碼）的詳細闡述，該概念源於devops環境。正如Atlassian所見，GitOps橋接了devop技術現有解決方案，這些解決方案已發展爲解決系統管理問題以及分佈式雲託管應用程序的特定需求。各類雲提供商所提供的自動融合使GitOps獨樹一幟。
儘管GitOps繼續專一於Kubernetes，但咱們但願咱們已經闡明瞭它如何適用於更普遍的分佈式和基於雲的應用程序世界。一個博客帖子由開源安全提供WhiteSource總結GitOps的好處：
可觀察性：GitOps系統在複雜的應用程序中提供監視，日誌記錄，跟蹤和可視化，所以開發人員能夠看到發生了什麼以及在哪裏發生了什麼。
版本控制和變動管理：顯然，這是使用版本控制系統（如Git）的主要好處。有缺陷的更新能夠輕鬆刪除/撤消。
易於採用：GitOps創建在許多開發人員已經具有的 devops技能的基礎上。
生產率：GitOps提供了devop和CI / CD在其餘方面的生產率提升。
審覈：藉助Git，能夠將每一個操做追溯到特定的承諾，從而能夠更輕鬆地跟蹤錯誤緣由。
即便您不使用Kubernetes，早晚極可能GitOps也將成爲您工做流程的一部分。
渠道激活專題文章推薦：
進入2020年，新冠狀病毒疫情突發，雲計算市場渠道招募和拓展工做也受到了一些影響，甚至在業界，已經不多人再談及渠道一詞了。但，毫不會永遠這樣。
從開源雲計算廠商此前進行的渠道拓展來看：首先，整個渠道拓展體系從不是隨意創建，而是須要根據不一樣區域市場狀況，以及渠道夥伴擁有的不一樣技術能力來進行內容宣導。其次，渠道內容的設計和組織也不是自由的，要根據行業客戶實際場景需求來作相應輸出。
開源雲計算廠商一般會構建大量的產品線和複雜的解決方案體系，這就須要藉助渠道夥伴的力量面向最終用戶輸出，以此保障最佳客戶體驗和售後支持。所以，渠道夥伴在開源雲計算市場拓展方面的能力強弱，關係到廠商總體的市場戰略實施效果。
在近幾年，不少開源雲計算廠商攜手渠道夥伴共同應對雲化時代的變化與挑戰，加速行業雲計算轉型。實際上，這一調整意味着開源雲計算廠商將更加劇視與夥伴的生態合做，並鼓勵合做夥伴發揮各自優點，協同爲客戶傳遞價值。但開源村也發現，也還有不少開源雲計算廠商沒有成功創建起本身的渠道體系。
雲化時代到來之際，行業客戶業務場景會根據雲化轉型的節奏進行調整。開源雲計算服務提供商在此時的做用是幫助渠道夥伴學會藉助平臺之力，知足行業客戶的真實需求。這是相比友商而言，更具競爭優點之處。優質的平臺，會助力渠道夥伴得到更多行業用戶的信任。
對於開源雲計算廠商而言，若是但願在搶灘新基建上構建差別化競爭優點，具有高超的售前技能、售後體驗，並擁有創新的技術服務能力與解決方案構建能力是實有必要的。巧了，這些都與渠道構建息息相關。
私有云涼了麼？固然沒有！連當事人都出來闢謠了！私有云需不須要渠道？固然須要！沒有渠道，開源雲廠商怎麼爲私有云產品、營銷和銷售提供售前支持？沒有渠道，開源雲廠商怎麼可以既少花錢，又能實現高效、便捷、快速的售後服務？
開源雲計算市場競爭激烈、用戶需求多變，對於怎樣帶貨，怎樣推進市場增加，也成爲讓不少廠商頭疼的事。開源村以爲，開源雲計算渠道雖不比網紅，但此時應當敢於站出，全面激發和表現出自身的「帶貨」實力。
有報道稱，一名開發者用兩年的業餘時間開發並維護了一個開源項目由於微軟的剽竊而被迫停止。有網友評論說，這也是不少大公司的通用策略，好比組織技術人員與之交流，而後套取有用信息，而後發展本身的產品，這在中國叫作「偷藝」。事實上，設想一下，若是這個項目可以早日產品化，而且建構好了一套成熟的市場分發渠道，或許形勢就會徹底不一樣。
本文分享自微信公衆號 - 開源村OSV（osvosvosv）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。