什么是GitOps | 將DevOps擴(kuò)展到Kubernetes和其他地方

作者：黃平安 翻譯 2022-11-10 08:02:41

云計(jì)算

云原生 對(duì)CI/CD的完整了解超出了本文的范圍，但我們需要對(duì)CI/CD說(shuō)幾句，因?yàn)樗荊itOps運(yùn)作的核心。CI/CD的持續(xù)集成部分是由像Git這樣的版本控制庫(kù)支持的:開(kāi)發(fā)人員可以對(duì)他們的代碼庫(kù)進(jìn)行持續(xù)的小改進(jìn)，而不是每隔幾個(gè)月或幾年就推出一個(gè)巨大的、單一的新版本。

創(chuàng)新互聯(lián)主營(yíng)烏什網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,App定制開(kāi)發(fā),烏什h5小程序定制開(kāi)發(fā)搭建,烏什網(wǎng)站營(yíng)銷推廣歡迎烏什等地區(qū)企業(yè)咨詢

?在編程領(lǐng)域，最近十年，發(fā)生了許多革命性的變化。其中之一，便是圍繞devop的一系列實(shí)踐，這些實(shí)踐將開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)整合到一個(gè)共享的工作流程中，并實(shí)現(xiàn)了持續(xù)集成和持續(xù)交付（CI/CD），其中devops團(tuán)隊(duì)會(huì)不斷向代碼庫(kù)提供了增量的更新。另一個(gè)轉(zhuǎn)變來(lái)自相關(guān)的轉(zhuǎn)變，從單個(gè)代碼庫(kù)，轉(zhuǎn)變到運(yùn)行在業(yè)務(wù)平臺(tái)（如Kubernetes）管理的容器中的基于云的微服務(wù)。

在集群系統(tǒng)或云中運(yùn)行的基于容器的應(yīng)用程序可能很復(fù)雜，并且即使使用像Kubernetes這樣的平臺(tái)來(lái)協(xié)調(diào)事物，也很難對(duì)其進(jìn)行配置和管理。GitOps是一組新興實(shí)踐，旨在通過(guò)應(yīng)用devops和CI / CD領(lǐng)域的技術(shù)來(lái)簡(jiǎn)化此管理任務(wù)。

GitOps的關(guān)鍵在于基礎(chǔ)設(shè)施即代碼的理念，它采用與devops提供應(yīng)用程序相同的方法來(lái)提供基礎(chǔ)設(shè)施。因此，不僅應(yīng)用程序，而且底層的主機(jī)和網(wǎng)絡(luò)都在文件中進(jìn)行描述，這些文件可以作為版本控制系統(tǒng)中的任何其他代碼來(lái)處理，然后將真實(shí)的應(yīng)用程序與這些文件中描述的應(yīng)用程序融合在一起。

用GitOps的說(shuō)法，版本控制系統(tǒng)中的代碼是關(guān)于應(yīng)用程序在生產(chǎn)環(huán)境中應(yīng)該是什么樣子的唯一來(lái)源。

GitOps定義 

Weaveworks是為推廣GitOps概念所做的最大努力的公司。我們將詳細(xì)介紹Weaveworks的角色，但首先，讓我們看一下該公司對(duì)GitOps的定義，它有兩個(gè)方面：

• Kubernetes和其他云原生技術(shù)的運(yùn)行模型，提供了一組最佳實(shí)踐，這些最佳實(shí)踐統(tǒng)一了容器化集群和應(yīng)用程序的部署，管理和監(jiān)視。
• 通往開(kāi)發(fā)人員管理應(yīng)用程序體驗(yàn)的途徑；端到端CI / CD管道和Git工作流同時(shí)應(yīng)用于運(yùn)營(yíng)和開(kāi)發(fā)。

換句話說(shuō)，GitOps是一組專門為管理Kubernetes和類似平臺(tái)而設(shè)計(jì)的實(shí)踐，隨著越來(lái)越多的開(kāi)發(fā)機(jī)構(gòu)采用devops實(shí)踐并將代碼遷移到云上，它也可以應(yīng)用于更廣泛的應(yīng)用。但是為了理解GitOps的秘密武器和它所解決的問(wèn)題，我們需要談?wù)勊慕M成部分。

Git定義 

GitOps中的Git是指Linus Torvalds在2005年開(kāi)發(fā)的非常流行的分布式版本控制系統(tǒng)。Git是一種工具，它允許開(kāi)發(fā)團(tuán)隊(duì)在一個(gè)應(yīng)用程序代碼庫(kù)上共同工作，存儲(chǔ)他們?cè)趯⒋a合并到生產(chǎn)代碼之前對(duì)其進(jìn)行修改的各種代碼分支。Git中的一個(gè)關(guān)鍵概念是pull request，在這個(gè)概念中，開(kāi)發(fā)人員正式要求將他們一直在工作的一些代碼集成到代碼庫(kù)中的另一個(gè)分支中。

Git pull請(qǐng)求為團(tuán)隊(duì)成員提供了一個(gè)協(xié)作和討論的機(jī)會(huì)，然后就是否應(yīng)該將新代碼添加到應(yīng)用程序達(dá)成一致意見(jiàn)。Git還存儲(chǔ)了較舊版本的代碼，這使得在出現(xiàn)錯(cuò)誤時(shí)很容易回到上一個(gè)好版本，并讓您快速查看不同版本之間的更改。Git最出名的可能是作為GitHub的基礎(chǔ)，GitHub是一種云托管版本控制系統(tǒng)，但是Git本身是一種開(kāi)源軟件，可以部署在任何地方，從公司內(nèi)部的服務(wù)器到你的個(gè)人電腦。

請(qǐng)注意，雖然我們通常認(rèn)為Git是一種計(jì)算機(jī)編程工具，但它實(shí)際上并不知道您使用它來(lái)做什么內(nèi)容。Git將樂(lè)于將任何文本文件集作為“代碼庫(kù)”，例如，作者可以使用它來(lái)跟蹤協(xié)作工作的編輯。這一點(diǎn)很重要，因?yàn)镚itOps核心的大部分代碼基由聲明性配置文件組成，而不是可執(zhí)行代碼。

在我們繼續(xù)之前，還有最后一件事要說(shuō):盡管名稱中有“Git”，但GitOps實(shí)際上并不需要使用Git。已經(jīng)投入了其他版本控制軟件(如Subversion)的公司也可以實(shí)現(xiàn)GitOps。但是Git在devops中被廣泛用于實(shí)現(xiàn)CI/CD，所以大多數(shù)GitOps項(xiàng)目最終都將使用Git。

CI / CD流程是什么？

對(duì)CI/CD的完整了解超出了本文的范圍，但我們需要對(duì)CI/CD說(shuō)幾句，因?yàn)樗荊itOps運(yùn)作的核心。CI/CD的持續(xù)集成部分是由像Git這樣的版本控制庫(kù)支持的:開(kāi)發(fā)人員可以對(duì)他們的代碼庫(kù)進(jìn)行持續(xù)的小改進(jìn)，而不是每隔幾個(gè)月或幾年就推出一個(gè)巨大的、單一的新版本。連續(xù)部署部分是由稱為管道的自動(dòng)化系統(tǒng)實(shí)現(xiàn)的，這些系統(tǒng)構(gòu)建、測(cè)試并將新代碼部署到生產(chǎn)環(huán)境中。

同樣，我們?cè)谶@里一直在討論代碼，這通常會(huì)讓人聯(lián)想到用C、Java或JavaScript等編程語(yǔ)言編寫(xiě)的可執(zhí)行代碼。但在GitOps中，我們管理的“代碼”主要是由配置文件組成的。這不僅僅是一個(gè)小細(xì)節(jié)——這是GitOps工作的核心。正如我們所說(shuō)的，這些配置文件是描述我們的系統(tǒng)應(yīng)該是什么樣子的“真實(shí)的單一來(lái)源”。它們是陳述性的，而不是啟發(fā)性的。這意味著配置文件不是說(shuō)“啟動(dòng)10臺(tái)服務(wù)器”，而是簡(jiǎn)單地說(shuō)“這個(gè)系統(tǒng)包括10臺(tái)服務(wù)器”。

GitOps等式的CI部分允許開(kāi)發(fā)者快速地對(duì)這些配置文件進(jìn)行調(diào)整和改進(jìn);當(dāng)自動(dòng)化軟件代理盡其所能確保應(yīng)用程序的活版本反映配置文件中的描述時(shí)，CD的一半就發(fā)生了——它用GitOps的語(yǔ)言聚合到聲明式模型。

GitOps和Kubernetes

如前所述，GitOps的概念最初是圍繞管理Kubernetes應(yīng)用程序開(kāi)發(fā)的。有了我們現(xiàn)在對(duì)GitOps的了解，讓我們?cè)賮?lái)看看Weaveworks對(duì)GitOps的討論。這里有一個(gè)總結(jié):

1、開(kāi)發(fā)人員為一個(gè)新特性發(fā)出一個(gè)Git pull請(qǐng)求。

2、代碼會(huì)被審查和批準(zhǔn)，然后合并到主代碼庫(kù)中。

3、合并將觸發(fā)CI/CD管道，該管道將自動(dòng)測(cè)試并重新構(gòu)建新代碼，并將其部署到注冊(cè)表中。

4、軟件代理注意到更新，從注冊(cè)表中提取新代碼，并更新配置存儲(chǔ)庫(kù)中的配置文件(用YAML編寫(xiě))。

5、Kubernetes集群中的一個(gè)軟件代理根據(jù)配置文件檢測(cè)集群過(guò)期，提取更改并部署新特性。

Weaveworks和GitOps

顯然，步驟4和步驟5是最重要的部分。神奇地將Git存儲(chǔ)庫(kù)中的“真相之源”與真實(shí)的Kubernetes應(yīng)用程序同步的軟件代理使GitOps成為可能。正如我們所說(shuō)的，在GitOps術(shù)語(yǔ)中，使動(dòng)態(tài)系統(tǒng)更像配置文件中描述的理想系統(tǒng)的過(guò)程稱為收斂。(當(dāng)動(dòng)態(tài)系統(tǒng)和理想系統(tǒng)不同步時(shí)，就是發(fā)散。)理想情況下，融合可以通過(guò)自動(dòng)化過(guò)程來(lái)實(shí)現(xiàn)，但是自動(dòng)化所能做的是有限的，有時(shí)需要人工干預(yù)。

我們?cè)谶@里用通用的術(shù)語(yǔ)描述了這個(gè)過(guò)程，但實(shí)際上，如果你真的去看Weaveworks的頁(yè)面，我們提到的“軟件代理”是該公司W(wǎng)eave云平臺(tái)的一部分。“GitOps”一詞是由Weaveworks首席執(zhí)行官Alexis Richardson創(chuàng)造的，這在一定程度上是為了讓W(xué)eaveworks平臺(tái)吸引那些已經(jīng)沉浸在devops和CI/CD世界的開(kāi)發(fā)者。

但Weaveworks從未宣稱壟斷過(guò)GitOps，它更像是一種哲學(xué)和一套最佳實(shí)踐，而不是一種特定的產(chǎn)品。正如CloudBees(一家提供CI/CD解決方案的公司)的博客所指出的，GitOps代表了一種開(kāi)放的、與供應(yīng)商無(wú)關(guān)的模型，這種模型是針對(duì)大型云供應(yīng)商如亞馬遜、谷歌和微軟推出的托管專有Kubernetes解決方案而開(kāi)發(fā)的。CloudBees提供了自己的GitOps解決方案，該領(lǐng)域的許多參與者也是如此。

GitOps和devops

Atlassian是一家為敏捷開(kāi)發(fā)人員提供多種工具的公司，它有一篇關(guān)于GitOps歷史和目的的深度博客，值得你花時(shí)間去了解。在他們看來(lái)，GitOps代表了devops中各種想法的邏輯延伸。具體地說(shuō)，GitOps是對(duì)“基礎(chǔ)設(shè)施即代碼”概念的精化，它本身就是源自devops環(huán)境的一個(gè)想法。在Atlassian看來(lái)，GitOps填補(bǔ)了現(xiàn)有devops技術(shù)與分布式云托管應(yīng)用程序之間的關(guān)鍵差距，后者已經(jīng)發(fā)展到解決系統(tǒng)管理問(wèn)題的程度。各種云供應(yīng)商提供的自動(dòng)融合正是GitOps的獨(dú)特之處。

盡管GitOps今天仍然專注于Kubernetes，我們希望我們已經(jīng)明確了它是如何應(yīng)用于更廣泛的分布式、基于云的應(yīng)用的。開(kāi)源安全廠商WhiteSource的一篇博客文章概述了GitOps的優(yōu)勢(shì):

• 可觀察性：GitOps系統(tǒng)提供對(duì)復(fù)雜應(yīng)用程序的監(jiān)視、日志記錄、跟蹤和可視化，這樣開(kāi)發(fā)人員就可以看到哪里出了問(wèn)題。
• 版本控制和變更管理：顯然，這是使用像Git這樣的版本控制系統(tǒng)的一個(gè)關(guān)鍵好處。有缺陷的更新可以輕松回滾。
• 易于采用：GitOps建立在許多開(kāi)發(fā)人員已經(jīng)具備的devops技能之上。
• 生產(chǎn)力：GitOps提高了生產(chǎn)力，就像devops和CI/CD帶給其他領(lǐng)域的生產(chǎn)力一樣。
• 審計(jì)：由于有了Git，每個(gè)操作都可以跟蹤到一個(gè)特定的提交，這使得跟蹤錯(cuò)誤的原因變得更加容易。

即使你不使用Kubernetes, GitOps遲早也會(huì)成為你工作流程的一部分。

*原文鏈接：https://www.infoworld.com/article/3566555/what-is-gitops-extending-devops-to-kubernetes-and-beyond.html?

當(dāng)前標(biāo)題：什么是GitOps|將DevOps擴(kuò)展到Kubernetes和其他地方
本文地址：http://www.5511xx.com/article/dphdheh.html