GitOps –用于基礎(chǔ)設施自動化的DevOps
GitOps提供了一種自動化的管理基礎(chǔ)架構(gòu)的方法。它通過使用許多團隊已經(jīng)使用的DevOps最佳實踐來做到這一點,例如版本控制,代碼審查和CI/CD管道。
由于DevOps具有提高生產(chǎn)力和軟件質(zhì)量的巨大潛力,因此公司一直在采用它。在此過程中,我們找到了使軟件開發(fā)生命周期自動化的方法。但是,當涉及到基礎(chǔ)架構(gòu)的設置和部署時,它仍然主要是手動過程。
借助GitOps,團隊可以自動化基礎(chǔ)架構(gòu)的配置過程。這是由于可以使用聲明文件將基礎(chǔ)結(jié)構(gòu)編寫為代碼(IaC)。我們可以將它們存儲在Git存儲庫中,就像存儲應用程序開發(fā)代碼一樣。
GitOps如何工作?
GitOps概念最初由Kubernetes管理公司W(wǎng)eave w orks提出。因此,圍繞GitOps的討論主要是在Kubernetes的背景下進行的。向在容器中運行的微服務的轉(zhuǎn)變帶來了對業(yè)務流程平臺的需求?;谌萜鞯膽贸绦蚩赡芎軓碗s,并且難以進行供應和管理。GitOps通過應用DevOps世界中成熟的技術(shù)來幫助簡化此過程。
如今,這個想法已成為DevOps愛好者的青睞,代表了IaC概念的升級模型。它圍繞三個主要組成部分:
- 基礎(chǔ)架構(gòu)即代碼
- 拉取要求
- CI/CD
讓我們分別看看它們。
基礎(chǔ)架構(gòu)即代碼
IaC是作為聲明文件(存儲為代碼)來配置和管理基礎(chǔ)結(jié)構(gòu)的一種做法。通過利用IaC和版本控制團隊,可以優(yōu)化所有操作程序。
GitOps圍繞IaC的聲明式模型。這就是為什么Kubernetes是實現(xiàn)的一個很好的例子。聲明式意味著配置更多是對預期狀態(tài)的聲明,而不是一組命令。例如,在Kubernetes中,您可以在清單中定義服務所需的Pod數(shù)量。然后,系統(tǒng)將自行處理。無需工程師編寫命令腳本即可獲得所需的容器編號。
任何符合聲明性模型的云原生軟件都可以視為代碼。我們使用AWS CloudFormation(一種聲明性工具)編寫AWS基礎(chǔ)架構(gòu)。這意味著我們可以將基礎(chǔ)架構(gòu)本身視為代碼。將所需狀態(tài)聲明為代碼。系統(tǒng)應用更改以自動實現(xiàn)該狀態(tài)。
話雖如此,聲明性模型并不是必須在GitOps中受益。您也可以在命令式定義的環(huán)境中執(zhí)行操作。
拉取要求
GitOps概念背后的主要思想是版本控制系統(tǒng)是真實的唯一來源 。我們將Git用作應用程序代碼的變更管理系統(tǒng)。我們也可以將其用于基礎(chǔ)結(jié)構(gòu)代碼。因此,整個聲明文件集都位于一個可以協(xié)作的地方。這使我們能夠使用Git的關(guān)鍵概念-對操作更改的Pull 請求。
在應用開發(fā)工作流程中,我們使用一個主分支作為發(fā)布分支。開發(fā)人員從主分支創(chuàng)建功能分支。開發(fā)特定功能或故事,完成后創(chuàng)建Pull 請求以將其合并回主分支。相同的方法對于基礎(chǔ)結(jié)構(gòu)代碼很方便。
創(chuàng)建拉取請求可使代碼在集成到代碼庫的另一個分支之前,先經(jīng)過代碼審查過程。代碼審查阻止不良代碼進入測試或生產(chǎn)環(huán)境。這對于基礎(chǔ)結(jié)構(gòu)代碼而言甚至更為重要。通過代碼審查獲得正式批準對審核和故障排除很有幫助。
Git組織
GitOps中的部署過程至少需要兩個存儲庫:應用程序存儲庫和環(huán)境配置存儲庫。第一個包含應用程序的源代碼及其部署清單。第二個包含使用每個環(huán)境的聲明性規(guī)范描述的整個系統(tǒng)的期望狀態(tài)。您可以在代碼存儲庫中將環(huán)境描述為開發(fā),測試,生產(chǎn)環(huán)境,其中包含可以在該環(huán)境的特定版本中運行的應用程序和基礎(chǔ)結(jié)構(gòu)服務。
對于基礎(chǔ)設施,主分支可以代表一個環(huán)境。我們可以在功能分支中實現(xiàn)更改。然后創(chuàng)建一個拉取請求以合并主分支中的更改。這樣一來,我們就可以實現(xiàn)協(xié)作,同時對誰進行了哪些更改保持透明。由于所有更改都是在Git中提交的,因此這對于從根本原因進行問題跟蹤也很有用。
GitOps可與任何基于Git的系統(tǒng)一起使用,例如GitHub,BitBucket或GitLab。它不依賴于任何工具或技術(shù)。
CI/CD
要實現(xiàn)完整的GitOps實施,您需要一個CI/CD管道。借助自動交付管道,每次Git存儲庫中發(fā)生更改時,您都可以將基礎(chǔ)結(jié)構(gòu)更改交付到指定的環(huán)境。這里有管道將您的Git pull請求連接到業(yè)務流程系統(tǒng)。當您通過拉取請求觸發(fā)管道時,業(yè)務流程系統(tǒng)將執(zhí)行任務。
GitOps部署策略有兩種可能性:推和拉管道。它們之間的區(qū)別在于您確保部署環(huán)境類似于所需基礎(chǔ)結(jié)構(gòu)的方式。
推管道
許多流行的CI/CD工具都在使用這種策略。我們將應用程序的源代碼及其部署清單存儲在一個存儲庫中。當應用程序代碼中發(fā)生新更新時,構(gòu)建管道將觸發(fā)。管道構(gòu)建容器映像并將更改推送到環(huán)境。該策略可支持任何類型的基礎(chǔ)架構(gòu),因此帶來了更大的靈活性。缺點是它使CI/CD工具可以寫入您的環(huán)境。
基于推送的GitOps部署
拉管道
社區(qū)認為對于GitOps,拉管道方法是一種更安全的做法。通過這種方法,引入了操作員。操作員是管道和業(yè)務流程工具之間的組件。它不斷將環(huán)境存儲庫中的目標狀態(tài)與已部署的基礎(chǔ)架構(gòu)中的實際狀態(tài)進行比較。如果操作員檢測到任何更改,便會更改基礎(chǔ)結(jié)構(gòu)以適合環(huán)境存儲庫。同樣,可以監(jiān)視映像注冊表以識別要部署的映像的新版本。這就是GitOps如此特別的原因。

基于拉式的GitOps部署
在GitOps中,僅當環(huán)境存儲庫中有更改時才進行環(huán)境更新。如果已實施的基礎(chǔ)架構(gòu)以環(huán)境存儲庫中未定義的任何方式更改,則系統(tǒng)將還原所做的任何修改。
對于大多數(shù)應用程序,您可能需要多個環(huán)境。GitOps允許您創(chuàng)建可以更改環(huán)境存儲庫的多個管道。您可以在環(huán)境存儲庫中使用單獨的分支來管理更多環(huán)境。操作員可以通過部署到生產(chǎn)來對一個分支的更改做出反應,而可以通過部署到測試來對另一個分支進行響應。
GitOps有什么好處?
使用DevOps最佳做法
由于GitOps是專注于Git工作流,IaC,CI/CD管道,不可變服務器,跟蹤和可觀察性的現(xiàn)有最佳實踐的模型,因此它代表了Kubernetes的云原生應用程序管理的更高級狀態(tài)。因此,公司現(xiàn)有的體系和經(jīng)驗可以為您提供很多幫助。
持續(xù)部署-簡化
持續(xù)部署意味著更快,更頻繁地部署。由于各種考慮因素,例如系統(tǒng)的狀態(tài),停機時間的阻力,上游/下游的依存關(guān)系以及許多其他組織相關(guān)的流程和依存關(guān)系,正確的連續(xù)部署一直是非常具有挑戰(zhàn)性的。
GitOps允許您執(zhí)行此操作,而無需管理大量工具,因為一切都發(fā)生在版本控制系統(tǒng)中。由于部署操作員,它提供了結(jié)構(gòu)和自動化。
這也提高了生產(chǎn)率并加快了MTTD(平均部署時間)。自動連續(xù)部署可確保團隊每天發(fā)送30-100倍以上的變更,從而將平均生產(chǎn)性能提高2-3倍。
較低的MTTR(平均修復時間)
MTTR是DevOps團隊應衡量的關(guān)鍵指標之一。在微服務體系結(jié)構(gòu)中,即使是很小的問題也很難修復。由于GitOps保留了版本控制系統(tǒng)中的所有更改,并且管理是自動化的,因此可以顯著降低MTTR。您可以全面了解環(huán)境如何發(fā)生變化,錯誤恢復變得非常容易。
簡化的Kubernetes管理
在不完全了解Kubernetes的情況下,開發(fā)人員可以使用熟悉的工具(如Git)更輕松地處理Kubernetes升級和功能。新嵌入的開發(fā)人員將輕松上手,并在幾天而不是幾個月內(nèi)活躍起來。
改善了整個公司的標準化
您擁有貫穿整個企業(yè)的透明的端到端工作流程,因為GitOps具有一個用于渲染應用程序,軟件和Kubernetes附加修改的框架。Git還可以完全復制您的運營活動。
如何準備GitOps?
- 建立穩(wěn)定的代碼審查和測試過程仔細檢查代碼更改可能會指出一些明顯的操作,例如添加全局變量。它可以防止錯誤代碼被釋放。然后,您可以通過請求提交經(jīng)過驗證的代碼,從而使開發(fā)人員無法直接提交任何更改。查看并合并拉取請求后,即可觸發(fā)管道。這是保持高標準代碼和后續(xù)系統(tǒng)穩(wěn)定性的第一步。
- 測試,測試,測試集成GitOps意味著具有高級自動化,需要對發(fā)布的應用程序進行徹底的測試。即使GitOps允許您相對輕松地回滾,釋放經(jīng)過良好測試用例的良好代碼也可以使您的過程更加可靠。
- 專注于監(jiān)控GitOps允許可重復的操作流程,可追溯系統(tǒng)狀態(tài)的改進,推出和回滾。仔細的監(jiān)視可以幫助您識別并防止任何意外的漂移和系統(tǒng)配置更改。因此,在開始使用GitOps之前,請復查您的監(jiān)視技能,并以他們可以處理此更改的方式來增強它們。
- 擁抱文化具有較長發(fā)布時間的常規(guī)流程限制只能使您退縮。擁有DevOps文化意味著運用最佳戰(zhàn)略,這將幫助團隊理解開發(fā)和運營行動的價值。同時,他們必須共同協(xié)作以創(chuàng)建整體穩(wěn)定的基礎(chǔ)架構(gòu),更快速,更流暢地執(zhí)行應用程序以及有效地管理系統(tǒng)。缺乏DevOps文化會阻止您享受GitOps的好處。
為什么選擇GitOps?
GitOps是一種非常好的工作流程模式,可以幫助您有效地處理云基礎(chǔ)架構(gòu)。GitOps可以為工程團隊提供眾多優(yōu)勢,包括更好的協(xié)調(diào)性,透明度,穩(wěn)定性和系統(tǒng)耐用性。