GitOps –用于基礎(chǔ)設(shè)施自動化的DevOps

作者：澤陽 2020-12-25 07:28:13

云計算

自動化 GitOps提供了一種自動化的管理基礎(chǔ)架構(gòu)的方法。它通過使用許多團(tuán)隊(duì)已經(jīng)使用的DevOps最佳實(shí)踐來做到這一點(diǎn)，例如版本控制，代碼審查和CI/CD管道。

創(chuàng)新互聯(lián)公司成立與2013年，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元汝城做網(wǎng)站,已為上家服務(wù),為汝城各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220

GitOps提供了一種自動化的管理基礎(chǔ)架構(gòu)的方法。它通過使用許多團(tuán)隊(duì)已經(jīng)使用的DevOps最佳實(shí)踐來做到這一點(diǎn)，例如版本控制，代碼審查和CI/CD管道。

由于DevOps具有提高生產(chǎn)力和軟件質(zhì)量的巨大潛力，因此公司一直在采用它。在此過程中，我們找到了使軟件開發(fā)生命周期自動化的方法。但是，當(dāng)涉及到基礎(chǔ)架構(gòu)的設(shè)置和部署時，它仍然主要是手動過程。

借助GitOps，團(tuán)隊(duì)可以自動化基礎(chǔ)架構(gòu)的配置過程。這是由于可以使用聲明文件將基礎(chǔ)結(jié)構(gòu)編寫為代碼(IaC)。我們可以將它們存儲在Git存儲庫中，就像存儲應(yīng)用程序開發(fā)代碼一樣。

GitOps如何工作?

GitOps概念最初由Kubernetes管理公司W(wǎng)eave w orks提出。因此，圍繞GitOps的討論主要是在Kubernetes的背景下進(jìn)行的。向在容器中運(yùn)行的微服務(wù)的轉(zhuǎn)變帶來了對業(yè)務(wù)流程平臺的需求。基于容器的應(yīng)用程序可能很復(fù)雜，并且難以進(jìn)行供應(yīng)和管理。GitOps通過應(yīng)用DevOps世界中成熟的技術(shù)來幫助簡化此過程。

如今，這個想法已成為DevOps愛好者的青睞，代表了IaC概念的升級模型。它圍繞三個主要組成部分：

1. 基礎(chǔ)架構(gòu)即代碼
2. 拉取要求
3. CI/CD

讓我們分別看看它們。

基礎(chǔ)架構(gòu)即代碼

IaC是作為聲明文件(存儲為代碼)來配置和管理基礎(chǔ)結(jié)構(gòu)的一種做法。通過利用IaC和版本控制團(tuán)隊(duì)，可以優(yōu)化所有操作程序。

GitOps圍繞IaC的聲明式模型。這就是為什么Kubernetes是實(shí)現(xiàn)的一個很好的例子。聲明式意味著配置更多是對預(yù)期狀態(tài)的聲明，而不是一組命令。例如，在Kubernetes中，您可以在清單中定義服務(wù)所需的Pod數(shù)量。然后，系統(tǒng)將自行處理。無需工程師編寫命令腳本即可獲得所需的容器編號。

任何符合聲明性模型的云原生軟件都可以視為代碼。我們使用AWS CloudFormation(一種聲明性工具)編寫AWS基礎(chǔ)架構(gòu)。這意味著我們可以將基礎(chǔ)架構(gòu)本身視為代碼。將所需狀態(tài)聲明為代碼。系統(tǒng)應(yīng)用更改以自動實(shí)現(xiàn)該狀態(tài)。

話雖如此，聲明性模型并不是必須在GitOps中受益。您也可以在命令式定義的環(huán)境中執(zhí)行操作。

拉取要求

GitOps概念背后的主要思想是版本控制系統(tǒng)是真實(shí)的唯一來源 。我們將Git用作應(yīng)用程序代碼的變更管理系統(tǒng)。我們也可以將其用于基礎(chǔ)結(jié)構(gòu)代碼。因此，整個聲明文件集都位于一個可以協(xié)作的地方。這使我們能夠使用Git的關(guān)鍵概念-對操作更改的Pull 請求。

在應(yīng)用開發(fā)工作流程中，我們使用一個主分支作為發(fā)布分支。開發(fā)人員從主分支創(chuàng)建功能分支。開發(fā)特定功能或故事，完成后創(chuàng)建Pull 請求以將其合并回主分支。相同的方法對于基礎(chǔ)結(jié)構(gòu)代碼很方便。

創(chuàng)建拉取請求可使代碼在集成到代碼庫的另一個分支之前，先經(jīng)過代碼審查過程。代碼審查阻止不良代碼進(jìn)入測試或生產(chǎn)環(huán)境。這對于基礎(chǔ)結(jié)構(gòu)代碼而言甚至更為重要。通過代碼審查獲得正式批準(zhǔn)對審核和故障排除很有幫助。

Git組織

GitOps中的部署過程至少需要兩個存儲庫：應(yīng)用程序存儲庫和環(huán)境配置存儲庫。第一個包含應(yīng)用程序的源代碼及其部署清單。第二個包含使用每個環(huán)境的聲明性規(guī)范描述的整個系統(tǒng)的期望狀態(tài)。您可以在代碼存儲庫中將環(huán)境描述為開發(fā)，測試，生產(chǎn)環(huán)境，其中包含可以在該環(huán)境的特定版本中運(yùn)行的應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)服務(wù)。

對于基礎(chǔ)設(shè)施，主分支可以代表一個環(huán)境。我們可以在功能分支中實(shí)現(xiàn)更改。然后創(chuàng)建一個拉取請求以合并主分支中的更改。這樣一來，我們就可以實(shí)現(xiàn)協(xié)作，同時對誰進(jìn)行了哪些更改保持透明。由于所有更改都是在Git中提交的，因此這對于從根本原因進(jìn)行問題跟蹤也很有用。

GitOps可與任何基于Git的系統(tǒng)一起使用，例如GitHub，BitBucket或GitLab。它不依賴于任何工具或技術(shù)。

CI/CD

要實(shí)現(xiàn)完整的GitOps實(shí)施，您需要一個CI/CD管道。借助自動交付管道，每次Git存儲庫中發(fā)生更改時，您都可以將基礎(chǔ)結(jié)構(gòu)更改交付到指定的環(huán)境。這里有管道將您的Git pull請求連接到業(yè)務(wù)流程系統(tǒng)。當(dāng)您通過拉取請求觸發(fā)管道時，業(yè)務(wù)流程系統(tǒng)將執(zhí)行任務(wù)。

GitOps部署策略有兩種可能性：推和拉管道。它們之間的區(qū)別在于您確保部署環(huán)境類似于所需基礎(chǔ)結(jié)構(gòu)的方式。

推管道

許多流行的CI/CD工具都在使用這種策略。我們將應(yīng)用程序的源代碼及其部署清單存儲在一個存儲庫中。當(dāng)應(yīng)用程序代碼中發(fā)生新更新時，構(gòu)建管道將觸發(fā)。管道構(gòu)建容器映像并將更改推送到環(huán)境。該策略可支持任何類型的基礎(chǔ)架構(gòu)，因此帶來了更大的靈活性。缺點(diǎn)是它使CI/CD工具可以寫入您的環(huán)境。

基于推送的GitOps部署

拉管道

社區(qū)認(rèn)為對于GitOps，拉管道方法是一種更安全的做法。通過這種方法，引入了操作員。操作員是管道和業(yè)務(wù)流程工具之間的組件。它不斷將環(huán)境存儲庫中的目標(biāo)狀態(tài)與已部署的基礎(chǔ)架構(gòu)中的實(shí)際狀態(tài)進(jìn)行比較。如果操作員檢測到任何更改，便會更改基礎(chǔ)結(jié)構(gòu)以適合環(huán)境存儲庫。同樣，可以監(jiān)視映像注冊表以識別要部署的映像的新版本。這就是GitOps如此特別的原因。

基于拉式的GitOps部署

在GitOps中，僅當(dāng)環(huán)境存儲庫中有更改時才進(jìn)行環(huán)境更新。如果已實(shí)施的基礎(chǔ)架構(gòu)以環(huán)境存儲庫中未定義的任何方式更改，則系統(tǒng)將還原所做的任何修改。

對于大多數(shù)應(yīng)用程序，您可能需要多個環(huán)境。GitOps允許您創(chuàng)建可以更改環(huán)境存儲庫的多個管道。您可以在環(huán)境存儲庫中使用單獨(dú)的分支來管理更多環(huán)境。操作員可以通過部署到生產(chǎn)來對一個分支的更改做出反應(yīng)，而可以通過部署到測試來對另一個分支進(jìn)行響應(yīng)。

GitOps有什么好處?

使用DevOps最佳做法

由于GitOps是專注于Git工作流，IaC，CI/CD管道，不可變服務(wù)器，跟蹤和可觀察性的現(xiàn)有最佳實(shí)踐的模型，因此它代表了Kubernetes的云原生應(yīng)用程序管理的更高級狀態(tài)。因此，公司現(xiàn)有的體系和經(jīng)驗(yàn)可以為您提供很多幫助。

持續(xù)部署-簡化

持續(xù)部署意味著更快，更頻繁地部署。由于各種考慮因素，例如系統(tǒng)的狀態(tài)，停機(jī)時間的阻力，上游/下游的依存關(guān)系以及許多其他組織相關(guān)的流程和依存關(guān)系，正確的連續(xù)部署一直是非常具有挑戰(zhàn)性的。

GitOps允許您執(zhí)行此操作，而無需管理大量工具，因?yàn)橐磺卸及l(fā)生在版本控制系統(tǒng)中。由于部署操作員，它提供了結(jié)構(gòu)和自動化。

這也提高了生產(chǎn)率并加快了MTTD(平均部署時間)。自動連續(xù)部署可確保團(tuán)隊(duì)每天發(fā)送30-100倍以上的變更，從而將平均生產(chǎn)性能提高2-3倍。

較低的MTTR(平均修復(fù)時間)

MTTR是DevOps團(tuán)隊(duì)?wèi)?yīng)衡量的關(guān)鍵指標(biāo)之一。在微服務(wù)體系結(jié)構(gòu)中，即使是很小的問題也很難修復(fù)。由于GitOps保留了版本控制系統(tǒng)中的所有更改，并且管理是自動化的，因此可以顯著降低MTTR。您可以全面了解環(huán)境如何發(fā)生變化，錯誤恢復(fù)變得非常容易。

簡化的Kubernetes管理

在不完全了解Kubernetes的情況下，開發(fā)人員可以使用熟悉的工具(如Git)更輕松地處理Kubernetes升級和功能。新嵌入的開發(fā)人員將輕松上手，并在幾天而不是幾個月內(nèi)活躍起來。

改善了整個公司的標(biāo)準(zhǔn)化

您擁有貫穿整個企業(yè)的透明的端到端工作流程，因?yàn)镚itOps具有一個用于渲染應(yīng)用程序，軟件和Kubernetes附加修改的框架。Git還可以完全復(fù)制您的運(yùn)營活動。

如何準(zhǔn)備GitOps?

• 建立穩(wěn)定的代碼審查和測試過程仔細(xì)檢查代碼更改可能會指出一些明顯的操作，例如添加全局變量。它可以防止錯誤代碼被釋放。然后，您可以通過請求提交經(jīng)過驗(yàn)證的代碼，從而使開發(fā)人員無法直接提交任何更改。查看并合并拉取請求后，即可觸發(fā)管道。這是保持高標(biāo)準(zhǔn)代碼和后續(xù)系統(tǒng)穩(wěn)定性的第一步。
• 測試，測試，測試集成GitOps意味著具有高級自動化，需要對發(fā)布的應(yīng)用程序進(jìn)行徹底的測試。即使GitOps允許您相對輕松地回滾，釋放經(jīng)過良好測試用例的良好代碼也可以使您的過程更加可靠。
• 專注于監(jiān)控GitOps允許可重復(fù)的操作流程，可追溯系統(tǒng)狀態(tài)的改進(jìn)，推出和回滾。仔細(xì)的監(jiān)視可以幫助您識別并防止任何意外的漂移和系統(tǒng)配置更改。因此，在開始使用GitOps之前，請復(fù)查您的監(jiān)視技能，并以他們可以處理此更改的方式來增強(qiáng)它們。
• 擁抱文化具有較長發(fā)布時間的常規(guī)流程限制只能使您退縮。擁有DevOps文化意味著運(yùn)用最佳戰(zhàn)略，這將幫助團(tuán)隊(duì)理解開發(fā)和運(yùn)營行動的價值。同時，他們必須共同協(xié)作以創(chuàng)建整體穩(wěn)定的基礎(chǔ)架構(gòu)，更快速，更流暢地執(zhí)行應(yīng)用程序以及有效地管理系統(tǒng)。缺乏DevOps文化會阻止您享受GitOps的好處。

為什么選擇GitOps?

GitOps是一種非常好的工作流程模式，可以幫助您有效地處理云基礎(chǔ)架構(gòu)。GitOps可以為工程團(tuán)隊(duì)提供眾多優(yōu)勢，包括更好的協(xié)調(diào)性，透明度，穩(wěn)定性和系統(tǒng)耐用性。

當(dāng)前名稱：GitOps –用于基礎(chǔ)設(shè)施自動化的DevOps
新聞來源：http://www.5511xx.com/article/cdpehgs.html