GitOps自提出以來受到很多關(guān)注，被認(rèn)為是云原生最佳實踐之一。這篇文章回答了關(guān)于GitOps的常見問題，幫助感興趣的相關(guān)人員更好理解這一實踐。原文: GitOps

自從Weaveworks在2017年提出GitOps以來，已經(jīng)在Twitter和KubeCon上引發(fā)了不少爭議。這篇文章匯集了關(guān)于GitOps的常見問題，以幫助澄清關(guān)于這一主題的困惑。

GitOps是什么?

GitOps是為云原生應(yīng)用實現(xiàn)持續(xù)部署的一種方法，通過使用Git和CD工具等開發(fā)人員已經(jīng)熟悉的工具，從而在操作基礎(chǔ)設(shè)施時提供以開發(fā)人員為中心的體驗。

GitOps的核心思想是讓Git存儲庫始終包含生產(chǎn)環(huán)境中當(dāng)前所需基礎(chǔ)設(shè)施的聲明性描述，以及通過自動化過程使生產(chǎn)環(huán)境與存儲庫中描述的狀態(tài)相匹配。如果希望部署新的應(yīng)用或更新現(xiàn)有的應(yīng)用，只需要更新存儲庫即可觸發(fā)自動化流程處理其他所有事情，管理生產(chǎn)環(huán)境應(yīng)用就像自動巡航那么簡單。

GitOps:在聲明性基礎(chǔ)設(shè)施之上的版本化CI/CD。停止腳本編寫并開始發(fā)布。
— Kelsey Hightower

為什么應(yīng)該使用GitOps?

更快更頻繁的部署

好吧，客觀的說，可能每一種持續(xù)部署技術(shù)都承諾可以更快部署更頻繁的部署。GitOps的獨特之處在于，部署應(yīng)用時不需要切換工具。無論如何，所有事情都發(fā)生在用于開發(fā)應(yīng)用程序的版本控制系統(tǒng)中。

當(dāng)我們說到"高速"時，意思是每個產(chǎn)品團隊每天可以安全發(fā)布多次更新: 立即部署，實時觀察結(jié)果，并使用根據(jù)反饋決定繼續(xù)往前走還是回滾。
— Weaveworks

簡單快速的錯誤恢復(fù)

噢，不！生產(chǎn)環(huán)境崩潰了！通過GitOps，可以獲得環(huán)境隨時間變化的完整歷史，從而使得錯誤恢復(fù)就像執(zhí)行git revert那么容易。

Git記錄不僅是審計日志，也是事務(wù)日志，可以回滾或前滾到任何快照。
— Alexis Richardson

簡單的憑證管理

GitOps允許我們完全在環(huán)境內(nèi)部管理部署。為此，環(huán)境只需要訪問存儲庫和鏡像倉庫，不必讓開發(fā)人員直接訪問環(huán)境。

kubectl是新的ssh，要限制對它的訪問，只有在沒有更好的工具時才用它進行部署。
— Kelsey Hightower

自我記錄的部署

你是否曾經(jīng)SSH進入服務(wù)器并想知道那里運行的是什么？如果使用GitOps，則對任何環(huán)境的每一個更改都必須通過存儲庫進行，因此可以隨時查看主分支，并獲取部署內(nèi)容和地點的完整描述，以及對系統(tǒng)所做的每個更改的完整歷史記錄，還可以免費獲得系統(tǒng)中任何更改的審計跟蹤！

在團隊內(nèi)共享知識

使用Git存儲已部署基礎(chǔ)設(shè)施的完整描述可以讓團隊中的每個人檢查其隨時間的演變。有了優(yōu)秀的提交消息，每個人都可以重現(xiàn)更改基礎(chǔ)設(shè)施的思考過程，也很容易找到如何設(shè)置新系統(tǒng)的例子。

GitOps是實踐配置即代碼(configuration as code)的最佳工具。Git改變了我們的協(xié)作方式，但聲明式配置是處理大規(guī)?；A(chǔ)設(shè)施的關(guān)鍵，并為下一代管理工具奠定了基礎(chǔ)。
— Kelsey Hightower

GitOps如何工作?

環(huán)境配置即Git存儲庫

GitOps以代碼存儲庫為中心組織部署過程，至少有兩個存儲庫: 應(yīng)用程序存儲庫和環(huán)境配置存儲庫。應(yīng)用程序存儲庫包含應(yīng)用程序源代碼和用于部署應(yīng)用程序的部署清單。環(huán)境配置存儲庫包含部署環(huán)境當(dāng)前所需基礎(chǔ)設(shè)施的所有部署清單，描述了應(yīng)該在部署環(huán)境中運行哪些版本的應(yīng)用程序和基礎(chǔ)服務(wù)(消息代理、服務(wù)網(wǎng)格、監(jiān)控工具……)。

基于Push的部署 vs. 基于Pull的部署

GitOps的部署策略有兩種: 基于Push的部署和基于Pull的部署。這兩種部署類型的區(qū)別在于如何確保部署環(huán)境實際上符合預(yù)期。如果可能的話，應(yīng)該首選基于Pull的方法，因為這樣更安全，是實現(xiàn)GitOps的更好實踐。

基于Push的部署

基于Push的部署策略是由流行的CI/CD工具實現(xiàn)的，如Jenkins、CircleCI或Travis CI。應(yīng)用程序源代碼與部署應(yīng)用所需的Kubernetes YAML一起保存在應(yīng)用程序存儲庫中。每當(dāng)應(yīng)用程序代碼更新時，都會觸發(fā)流水線，構(gòu)建容器鏡像，最后用新的部署描述符更新環(huán)境配置存儲庫。

提示: 也可以只將yaml模板存儲在應(yīng)用程序存儲庫中。在構(gòu)建新版本時，可以使用模板在環(huán)境配置存儲庫中生成YAML。

對環(huán)境配置存儲庫的更改會觸發(fā)部署流水線，該流水線負(fù)責(zé)將環(huán)境配置存儲庫中的所有清單(manifests)應(yīng)用到基礎(chǔ)設(shè)施上。使用這種方法，向部署環(huán)境提供憑證必不可少，這意味著流水線啟用了上帝模式(god-mode)。在某些用例中，當(dāng)運行云基礎(chǔ)設(shè)施提供的自動化配置時，基于Push的部署不可避免。在這種情況下，強烈建議使用云供應(yīng)商的細(xì)粒度可配置授權(quán)系統(tǒng)，從而更嚴(yán)格的控制部署權(quán)限。

使用這種方法時要記住的另一件重要的事情是，部署流水線只在環(huán)境存儲庫發(fā)生變更時被觸發(fā)，無法自動注意到環(huán)境及其所需狀態(tài)的任何偏差。這意味著，它需要某種適當(dāng)?shù)谋O(jiān)控方式，以便在環(huán)境與環(huán)境存儲庫中描述的狀態(tài)發(fā)生不匹配時進行干預(yù)。

想看看怎么設(shè)置嗎？ 查看谷歌的教程，了解如何使用Cloud Builds和GKE設(shè)置基于Push的部署。

基于Pull的部署

基于Pull的部署策略與基于Push的部署策略使用相同的概念，但在部署流水線的工作方式上有所不同。傳統(tǒng)的CI/CD流水線由外部事件觸發(fā)，例如，當(dāng)新代碼被推送到應(yīng)用程序存儲庫時。結(jié)合基于Pull的部署方式，引入了operator，它通過不斷比較環(huán)境存儲庫中的期望狀態(tài)與部署的基礎(chǔ)設(shè)施中的實際狀態(tài)來接管流水線的角色。一旦發(fā)現(xiàn)差異，operator就更新基礎(chǔ)設(shè)施以匹配環(huán)境存儲庫。此外，還可以監(jiān)視鏡像倉庫，以查找要部署的新版本鏡像。

與基于Push的部署一樣，每當(dāng)環(huán)境存儲庫發(fā)生更改時，就會更新環(huán)境。然而，通過operator，也可以監(jiān)控另一個方向的變化。每當(dāng)部署的基礎(chǔ)設(shè)施以環(huán)境存儲庫中沒有描述的方式發(fā)生更改時，這些更改將被恢復(fù)，從而確保Git日志中所有的變更都可跟蹤，從而避免對集群進行任何直接更改。

這種方向上的改變解決了基于Push的部署問題，即只有在環(huán)境存儲庫更新時才更新環(huán)境。然而，這并不意味著可以在沒有任何監(jiān)視的情況下完全做到這一點。如果由于任何原因無法保證環(huán)境符合預(yù)期的狀態(tài)(例如無法獲取容器鏡像)，大多數(shù)operator都支持發(fā)送郵件或Slack通知。另外，因為沒有operator就沒有任何自動化部署過程，所以應(yīng)該為operator本身設(shè)置監(jiān)控。

operator應(yīng)該始終處于與要部署的應(yīng)用相同的環(huán)境或集群中，從而防止基于Push的方法所出現(xiàn)的上帝模式(god-mode)，即CI/CD流水線需要獲取執(zhí)行部署的證書。當(dāng)部署實例位于完全相同的環(huán)境中時，外部服務(wù)不需要任何憑證?？梢岳貌渴鹌脚_的授權(quán)機制來限制執(zhí)行部署的權(quán)限，這對安全有很大影響，當(dāng)使用Kubernetes時，可以利用RBAC配置和服務(wù)帳戶。

想看看怎么設(shè)置嗎？ 查看在谷歌GKE上使用weveworks Flux設(shè)置基于Pull的GitOps的教程。

在多應(yīng)用環(huán)境中使用

當(dāng)然，對于大多數(shù)應(yīng)用程序來說，只使用一個應(yīng)用程序存儲庫和一個環(huán)境是不現(xiàn)實的。使用微服務(wù)架構(gòu)時，可能希望將每個服務(wù)保存在自己的存儲庫中。

GitOps也可以處理這樣的用例，總是可以設(shè)置多個構(gòu)建流水線來更新環(huán)境存儲庫，從而通過常規(guī)的自動化GitOps工作流啟動并部署應(yīng)用程序的所有部分。

只需在環(huán)境存儲庫中使用獨立分支，就可以利用GitOps管理多個環(huán)境?？梢栽O(shè)置operator或部署流水線，對某一個分支上的變更部署到生產(chǎn)環(huán)境上，對另一個分支上的變更部署到預(yù)發(fā)環(huán)境上。

FAQ

我的項目為GitOps做好準(zhǔn)備了嗎?

大部分情況下，是的！GitOps最酷的地方在于，不需要編寫任何特殊代碼，所需要的只是使用聲明式基礎(chǔ)設(shè)施作為代碼工具進行管理的基礎(chǔ)設(shè)施。

不用Kubernetes，還能使用GitOps嗎?

是的！GitOps并不僅限于Kubernetes。原則上，可以使用任何提供可觀察性和聲明性描述的基礎(chǔ)設(shè)施，并擁有可用的基礎(chǔ)設(shè)施作為代碼工具。然而，目前大多數(shù)基于Pull的GitOps operator都是基于Kubernetes實現(xiàn)的。

GitOps只是將基礎(chǔ)設(shè)施版本化為代碼嗎?

GitOps只是基礎(chǔ)設(shè)施即代碼的新名字嗎?
— sholom

不是。聲明性基礎(chǔ)設(shè)施即代碼在實現(xiàn)GitOps中扮演著重要角色，但不僅僅是這樣。GitOps采用了Git周圍的整個生態(tài)系統(tǒng)和工具，并將其應(yīng)用于基礎(chǔ)設(shè)施。持續(xù)部署系統(tǒng)保證在生產(chǎn)環(huán)境中基于期望的狀態(tài)部署基礎(chǔ)設(shè)施。除此之外，還可以獲得代碼審查、pull request和基礎(chǔ)設(shè)施變更注釋等其他好處。

如何在環(huán)境中獲取密鑰但不存儲在git中?

首先，永遠不要在git中以明文形式存儲密鑰！永遠不要！

也就是說，你在環(huán)境中創(chuàng)建了一些密鑰，這些密鑰永遠不會離開環(huán)境，應(yīng)用程序獲取需要的密鑰，但不向外界暴露。例如，環(huán)境中有數(shù)據(jù)庫，只將密鑰提供給與該數(shù)據(jù)庫交互的應(yīng)用程序。

另一種方法是在環(huán)境中添加私鑰(可能是由專門的運維團隊執(zhí)行)，然后可以在環(huán)境存儲庫中添加由公鑰加密的密鑰。在K8S生態(tài)系統(tǒng)中，甚至有工具支持這種加密密鑰。

GitOps如何處理研發(fā)環(huán)境到生產(chǎn)環(huán)境的發(fā)布?

GitOps沒有提供將更改從一個階段傳播到下一個階段的解決方案。我們建議只使用一個環(huán)境，避免分階段部署。但是如果需要多個階段(例如研發(fā)、QA、生產(chǎn)等)，每個階段都有一個環(huán)境，就需要處理GitOps范圍之外的發(fā)布，也許可以通過CI/CD流水線實現(xiàn)。

我們已經(jīng)在做DevOps了，和GitOps有什么不同?

DevOps的核心是改變組織文化，讓人們更好的一起工作。GitOps是一種實現(xiàn)持續(xù)交付的技術(shù)。雖然DevOps和GitOps共享自動化和自助服務(wù)基礎(chǔ)設(shè)施等原則，但對它們進行比較并沒有意義。然而，如果你已經(jīng)在積極使用DevOps技術(shù)，這些共同原則肯定會使你更容易采用GitOps工作流程。

那么，GitOps基本上是NoOps嗎?

可以使用GitOps來實現(xiàn)NoOps，但它不會自動使所有運維任務(wù)過時。如果你正在使用云資源，那么可以使用GitOps來實現(xiàn)自動化。但是，通常情況下，使用的某些基礎(chǔ)設(shè)施，如網(wǎng)絡(luò)配置或Kubernetes集群，不是由你自己去中心化的管理，而是由運維團隊集中管理，所以運維永遠不會消失。

還有SVNOps嗎?

在某種程度上，是的，原則上可以使用任何想要的版本控制系統(tǒng)。GitOps的核心思想之一是讓開發(fā)人員使用熟悉的工具來操作基礎(chǔ)設(shè)施。如果你更喜歡SVN而不是Git，那也很酷！但是，你可能需要花更多精力尋找合適的工具，甚至需要編寫自己的工具，當(dāng)前所有可用的operator只基于Git存儲庫，抱歉！

應(yīng)該為團隊雇傭GitOps工程師嗎?

不！沒有GitOps工程師。GitOps不是一種角色(DevOps也一樣)。GitOps是一組實踐。你可以尋找有GitOps實踐經(jīng)驗的開發(fā)人員，或者讓團隊內(nèi)的開發(fā)人員嘗試這些實踐。

工具、文章和討論

工具

• ArgoCD: 具有web界面的Kubernetes的GitOps operator
• Flux: 由GitOps的提出者Weaveworkks提供的GitOps Kubernetes operator
• Gitkube: 基于git push在Kubernetes上構(gòu)建和部署docker鏡像的工具
• JenkinsX: 內(nèi)置GitOps的Kubernetes持續(xù)交付工具
• Terragrunt: Terraform的包裝器，保持配置簡潔、可復(fù)用，并管理遠程狀態(tài)
• WKSctl: 基于GitOps原則的Kubernetes集群配置管理工具
• Helm Operator: 在K8S上通過Helm使用Git的operator
• werf: 用于構(gòu)建鏡像并通過push方式部署到Kubernetes的CLI工具

更多工具請查看Weavework的Awesome-GitOps。

博客文章和社交媒體

• An Inside Look at GitOps
• GitOps - Operations by Pull Request
• GitOps: What, Why, and How
• What Is GitOps and Why It Might Be The Next Big Thing for DevOps
• What is GitOps Really?
• GitOps mit Helm und Kubernetes (German)

討論

• GitOps - Operations by Pull Request [B] - Alexis Richardson, Weaveworks & William Denniss, Google
• Tutorial: Hands-on Gitops - Brice Fernandes, Weaveworks
• What is GitOps? Next level delivery with Flux & Kubernetes by Rafa? Lewandowski

作者

Florian Beetz，目前在班貝格大學(xué)(University of Bamberg)學(xué)習(xí)國際軟件系統(tǒng)科學(xué)，對云計算、clean code和軟件工程技術(shù)感興趣，空閑時間喜歡去攀巖。

Anja Kammer，INNOQ顧問，構(gòu)建云原生網(wǎng)絡(luò)應(yīng)用程序。擅長處理部署自動化和CI/CD系統(tǒng)，專注于DevOps、云基礎(chǔ)設(shè)施和Kubernetes等主題。業(yè)余時間為Kubernetes開發(fā)了名為anya的開源云原生CI/CD系統(tǒng)。

Simon Harrer博士，在INNOQ工作，充滿好奇心，喜歡分享知識，是Java by Comparison、Remote Mob Programming、GitOps以及最近的Data Mesh的共同作者之一。

你好，我是俞凡，在Motorola做過研發(fā)，現(xiàn)在在Mavenir做技術(shù)工作，對通信、網(wǎng)絡(luò)、后端架構(gòu)、云原生、DevOps、CICD、區(qū)塊鏈、AI等技術(shù)始終保持著濃厚的興趣，平時喜歡閱讀、思考，相信持續(xù)學(xué)習(xí)、終身成長，歡迎一起交流學(xué)習(xí)。
微信公眾號：DeepNoMind