成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

你了解DevOps的自動(dòng)化架構(gòu)GitOps嗎?

譯文
開發(fā) 前端 自動(dòng)化
GitOps通過使用成熟的DevOps優(yōu)秀實(shí)踐(包括:版本控制、代碼審查、以及CI/CD管道等),提供了一整套自動(dòng)化的管理方法。本文向您介紹GitOps基本原理、組成與優(yōu)勢。

【51CTO.com快譯】如今,許多團(tuán)隊(duì)都在各種項(xiàng)目中爭相使用著諸如:版本控制、代碼審查、以及CI/CD管道等,與DevOps有關(guān)的優(yōu)秀實(shí)踐。不過,您是否注意到,這些方法主要針對(duì)的是軟件開發(fā)生命周期中的自動(dòng)化。而在涉及到基礎(chǔ)架構(gòu)的設(shè)置和部署時(shí),項(xiàng)目團(tuán)隊(duì)仍然主要依賴的是手動(dòng)的過程。

[[355786]]

對(duì)此,GitOps提供了一套管理基礎(chǔ)架構(gòu)的自動(dòng)化方法。項(xiàng)目團(tuán)隊(duì)可以借助GitOps,并通過使用各種聲明文件,將基礎(chǔ)架構(gòu)編寫為代碼(infrastructure as code,IaC),進(jìn)而自動(dòng)化配置的過程。也就是說,我們可以像存儲(chǔ)應(yīng)用程序的開發(fā)代碼那樣,將基礎(chǔ)架構(gòu)存儲(chǔ)放在Git存儲(chǔ)庫中,以提高整體的交付能力和產(chǎn)品質(zhì)量。

GitOps的工作原理

GitOps的概念最初是由Kubernetes管理公司--Weaveworks(請(qǐng)參見https://www.weave.works/)提出的。眾所周知,基于容器的應(yīng)用往往比較復(fù)雜,而且難以進(jìn)行配置和管理。因此,GitOps主要針對(duì)的是:在Kubernetes背景下,如何將編排平臺(tái)轉(zhuǎn)換到運(yùn)行在容器中的微服務(wù)上,并采用DevOps領(lǐng)域的成熟技術(shù),來協(xié)助簡化該過程。下面我們將深入討論GitOps的各個(gè)主要組成部分:

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

如前所述,IaC可以通過將各種聲明性文件存儲(chǔ)為代碼,進(jìn)而實(shí)現(xiàn)基礎(chǔ)架構(gòu)的配置和管理。據(jù)此,通過利用IaC和版本控制,項(xiàng)目團(tuán)隊(duì)可以優(yōu)化當(dāng)前的各項(xiàng)操作進(jìn)程。此處提到的聲明式(Declarative),意味著您的配置將不再是一組命令,而是對(duì)某種預(yù)期狀態(tài)的聲明。例如,在Kubernetes中,您可以在清單文件(manifest)中定義服務(wù)所需的Pod數(shù)量。系統(tǒng)將通過自行處理,獲取所需的容器編號(hào),而無需工程師額外編寫命令腳本。

在此,任何符合聲明性模型的云原生軟件,都可以被視為代碼。通常,我們會(huì)將各種所需的狀態(tài)聲明為代碼,并通過系統(tǒng)應(yīng)用的更改,以自動(dòng)化的方式實(shí)現(xiàn)目標(biāo)狀態(tài)。例如:我們可以使用諸如AWS CloudFormation之類的聲明性工具,來編寫AWS的基礎(chǔ)架構(gòu)。

拉取請(qǐng)求(Pull Requests)

GitOps概念背后的主要思想是:版本控制系統(tǒng)是唯一的來源。我們既可以將Git用作應(yīng)用代碼的變更管理系統(tǒng),通過拉取請(qǐng)求來實(shí)現(xiàn)各項(xiàng)操作性的變更,又可以將其用于基礎(chǔ)架構(gòu)的代碼上,以便將整個(gè)聲明文件集中于一處。

在應(yīng)用開發(fā)的工作流中,我們需要將某個(gè)主分支作為發(fā)布分支。在此基礎(chǔ)上,開發(fā)人員會(huì)從主分支處創(chuàng)建各個(gè)功能性分支,以便開發(fā)出特定的功能或故事線。而在功能性分支上,一旦完成了更改,他們會(huì)通過創(chuàng)建拉取請(qǐng)求的方式,重新合并回主分支。這樣一來,我們就可以在方便實(shí)現(xiàn)協(xié)作的同時(shí),透明地獲悉到誰在何處進(jìn)行何種更改。而且,由于所有更改都是在Git處被提交的,因此這對(duì)于開發(fā)團(tuán)隊(duì)從根本原因處進(jìn)行問題的跟蹤,也是非常實(shí)用的。

可見,創(chuàng)建拉取請(qǐng)求的好處在于,我們可以讓代碼在被集成到代碼庫的另一個(gè)分支之前,事先經(jīng)歷代碼的審查過程。而代碼審查恰好能夠阻止各種不良的代碼,進(jìn)入測試或生產(chǎn)環(huán)境。顯然,這對(duì)于故障的消除,以及基礎(chǔ)架構(gòu)代碼而言,都是非常重要的。

Git的組成

GitOps并不依賴于任何工具或技術(shù)。它可以與諸如:GitHub、BitBucket或GitLab等,任何基于Git的系統(tǒng)協(xié)同使用。

而在部署過程中,GitOps至少需要兩個(gè)存儲(chǔ)庫,即:包含了應(yīng)用源代碼、及其部署清單的應(yīng)用程序存儲(chǔ)庫;和使用著每個(gè)環(huán)境的聲明性規(guī)范描述的,包含了整個(gè)系統(tǒng)目標(biāo)狀態(tài)的環(huán)境配置存儲(chǔ)庫。您可以在代碼存儲(chǔ)庫中將目標(biāo)環(huán)境定義并描述為開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境、或是包含了運(yùn)行著特定版本的應(yīng)用和基礎(chǔ)架構(gòu)服務(wù)的環(huán)境。

CI/CD

要實(shí)現(xiàn)完整的GitOps,您勢必需要一個(gè)CI/CD管道,以實(shí)現(xiàn)Git存儲(chǔ)庫在每次發(fā)生更改時(shí),開發(fā)團(tuán)隊(duì)都能將對(duì)應(yīng)的基礎(chǔ)架構(gòu)變更交付到指定的環(huán)境中。該自動(dòng)交付管道能夠?qū)it的拉取請(qǐng)求連接到編排系統(tǒng)中,以便通過請(qǐng)求來觸發(fā)管道,并讓編排系統(tǒng)執(zhí)行指定的任務(wù)。

一般而言,GitOps有兩種可能的部署策略:推送管道和拉取管道。您可以根據(jù)當(dāng)前架構(gòu)需要部署的實(shí)際環(huán)境,在兩者間做出選擇。下面我們來具體看看兩種策略的各種特點(diǎn):

推送管道(Push Pipelines)

目前,許多流行的CI/CD工具都在使用這種策略。開發(fā)人員通常將應(yīng)用程序的源代碼、及其部署清單存儲(chǔ)在一個(gè)存儲(chǔ)庫中。當(dāng)應(yīng)用代碼發(fā)生變更時(shí),管道將觸發(fā)容器映像的構(gòu)建,并將變更推送到相應(yīng)的環(huán)境中。由于該策略支持任何類型的基礎(chǔ)架構(gòu),因此它具有較大的靈活性。不過,其缺點(diǎn)是:它會(huì)賦予CI/CD工具對(duì)于目標(biāo)環(huán)境的寫入權(quán)限。

基于推送的DevOps部署

拉取管道(Pull Pipelines)

在開發(fā)者社區(qū)中,人們普遍認(rèn)為:對(duì)于GitOps的拉取管道方法是一種更安全的策略。這種方法引入了操作符(operator)的概念。它是管道和業(yè)務(wù)流程工具之間的組件。操作符能夠不斷將環(huán)境存儲(chǔ)庫中的目標(biāo)狀態(tài),與已部署的基礎(chǔ)架構(gòu)的實(shí)際狀態(tài),進(jìn)行比較。如果操作符檢測到任何修改,那么它就會(huì)更改基礎(chǔ)架構(gòu),以適應(yīng)環(huán)境存儲(chǔ)庫。同樣地,它也可以監(jiān)視鏡像注冊(cè)表,以識(shí)別出需要部署的鏡像新版本。

基于拉取的DevOps部署

可見,在GitOps中,只有在環(huán)境存儲(chǔ)庫中出現(xiàn)修改時(shí),對(duì)應(yīng)的環(huán)境才會(huì)更新。相反,如果已實(shí)施的基礎(chǔ)架構(gòu)在環(huán)境存儲(chǔ)庫中并未定義任何方式的修改,那么系統(tǒng)將會(huì)自動(dòng)還原。

在實(shí)際項(xiàng)目中,大多數(shù)應(yīng)用程序都會(huì)同時(shí)涉及到多個(gè)環(huán)境。對(duì)此,GitOps允許您創(chuàng)建多個(gè)管道,以同時(shí)更改多個(gè)環(huán)境存儲(chǔ)庫。當(dāng)然,您也可以在環(huán)境存儲(chǔ)庫中使用單獨(dú)的分支,來管理多個(gè)環(huán)境。我們既可以通過將操作符部署到生產(chǎn)環(huán)境中,來對(duì)單個(gè)分支的修改及時(shí)做出反應(yīng),又可以通過部署到測試環(huán)境中,來響應(yīng)另一個(gè)分支。

GitOps的優(yōu)勢

由于GitOps專注于Git工作流、IaC、CI/CD管道,不可變服務(wù)器(immutable servers)、跟蹤、以及可觀測性等優(yōu)秀實(shí)踐模型,因此它代表了對(duì)于Kubernetes云原生應(yīng)用管理的高級(jí)狀態(tài)。據(jù)此,開發(fā)團(tuán)隊(duì)可以從如下方面受益:

簡化持續(xù)部署

顧名思義,持續(xù)部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味著更快、更頻繁的部署。通過GitOps,部署操作符提供了必要的結(jié)構(gòu)和自動(dòng)化,而且這一切都在版本控制系統(tǒng)中發(fā)生,因此我們無需各種工具,便可管理系統(tǒng)的狀態(tài)、停機(jī)時(shí)間、上游/下游依賴關(guān)系、以及其他與組織相關(guān)的流程。

此外,GitOps不但提高了項(xiàng)目團(tuán)隊(duì)的生產(chǎn)率,而且加快了他們的平均部署時(shí)間(Mean-time-to-deployment,MTTD)。有證據(jù)表明,自動(dòng)化持續(xù)部署能夠確保團(tuán)隊(duì)每天觸發(fā)30到100次以上的變更,并將生產(chǎn)環(huán)境的性能平均提高2到3倍。

縮短平均修復(fù)時(shí)間(Mean-time-to-repair,MTTR)

MTTR是衡量DevOps團(tuán)隊(duì)績效的一項(xiàng)關(guān)鍵指標(biāo)(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系統(tǒng)中的所有修改,并且能夠?qū)崿F(xiàn)自動(dòng)化的管理,因此,開發(fā)團(tuán)隊(duì)能夠全面了解目標(biāo)環(huán)境中的變化,輕松發(fā)現(xiàn)和修復(fù)錯(cuò)誤,從而顯著降低MTTR。

簡化Kubernetes管理

在無需透徹了解Kubernetes的情況下,開發(fā)人員可以使用Git等較為熟悉的工具,更加輕松地管理Kubernetes的升級(jí)和各項(xiàng)功能。據(jù)此,新加入的成員也能夠在幾天時(shí)間快速上手Kubernetes。

全面掌握并標(biāo)準(zhǔn)化工作流

由于GitOps提供了一站式的應(yīng)用程序、軟件、以及針對(duì)Kubernetes修改的框架,因此開發(fā)團(tuán)隊(duì)可以清晰地洞悉整個(gè)項(xiàng)目的端到端工作流,并能通過Git來完全復(fù)現(xiàn)日常的業(yè)務(wù)運(yùn)營活動(dòng)。

GitOps的實(shí)現(xiàn)

  • 建立穩(wěn)定的代碼審查與測試過程。通過仔細(xì)地檢查代碼的更改,我們能夠及時(shí)發(fā)現(xiàn)諸如全局變量的添加等操作,并且可以通過提交拉取請(qǐng)求(而非直接提交更改的方式),來驗(yàn)證代碼。而在拉取請(qǐng)求被檢查與合并之后,管道才會(huì)被觸發(fā)。此舉在避免發(fā)布錯(cuò)誤的代碼的同時(shí),有效地保持了高標(biāo)準(zhǔn)的代碼,以及系統(tǒng)后續(xù)的穩(wěn)定性。
  • 持續(xù)測試。合并到GitOps中,往往意味需要通過高級(jí)的自動(dòng)化機(jī)制,對(duì)待發(fā)布的應(yīng)用程序進(jìn)行徹底的測試。有了GitOps,我們不但能夠相對(duì)輕松地實(shí)現(xiàn)回滾,還能夠通過良好的測試用例,保障代碼的質(zhì)量和可靠性。
  • 專注監(jiān)控。GitOps允許開發(fā)人員重復(fù)各項(xiàng)操作流程,改進(jìn)、發(fā)布并回顧各種可追溯的系統(tǒng)狀態(tài)。而通過專注于監(jiān)控,我們可以識(shí)別并防止任何意外的漂移(drift)、以及系統(tǒng)配置的變更。因此,在開始使用GitOps之前,開發(fā)團(tuán)隊(duì)有必要檢查自己的監(jiān)控水平,以及處理變更的能力。
  • 擁抱文化。作為目前在開發(fā)領(lǐng)域的優(yōu)秀戰(zhàn)略,DevOps文化能夠促進(jìn)團(tuán)隊(duì)的共同協(xié)作,更有效地管理基礎(chǔ)架構(gòu)的穩(wěn)定性,更快、更流暢地執(zhí)行應(yīng)用程序。而GitOps又能夠讓我們?cè)诖嘶A(chǔ)上,進(jìn)一步理解開發(fā)和運(yùn)營的協(xié)同價(jià)值,提供一整套自動(dòng)化的管理方法。

小結(jié)

作為一種非常好的工作流模式,GitOps不但可以幫助我們有效地處理云基礎(chǔ)架構(gòu),還能夠?yàn)楣こ虉F(tuán)隊(duì)提供:更好的協(xié)調(diào)性、透明度、穩(wěn)定性、以及系統(tǒng)耐用性等方面的諸多好處。

原文標(biāo)題:GitOps – DevOps for Infrastructure Automation,作者:Sara Miteva

【51CTO譯稿,合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】

 

責(zé)任編輯:華軒 來源: 51CTO
相關(guān)推薦

2020-12-25 07:28:13

GitOpsDevOps云基礎(chǔ)架構(gòu)

2022-06-26 09:55:00

接口自動(dòng)化項(xiàng)目

2014-04-17 16:42:03

DevOps

2021-11-19 10:55:03

GitOps運(yùn)維自動(dòng)化

2016-01-13 10:09:49

自動(dòng)化運(yùn)維運(yùn)維思想

2022-01-21 08:55:00

云計(jì)算DevOps自動(dòng)化

2015-11-09 10:44:37

DevOpsIT運(yùn)維

2012-05-25 09:43:46

DevOps運(yùn)動(dòng)DevOps網(wǎng)絡(luò)自動(dòng)化

2016-01-08 13:19:30

開源自動(dòng)化運(yùn)維

2023-03-06 16:38:30

SQL數(shù)據(jù)庫

2022-09-14 10:00:12

前端自動(dòng)化測試

2020-10-29 10:26:28

DevOps軟件自動(dòng)化

2021-10-14 06:52:47

自動(dòng)化開發(fā)環(huán)境

2017-06-14 08:08:40

運(yùn)維監(jiān)控自動(dòng)化

2023-12-01 07:03:16

2015-02-04 09:17:38

亞馬遜AWS云自動(dòng)化

2013-12-17 17:43:45

DevOps自動(dòng)化云管理

2021-12-06 20:00:59

人工智能AI自動(dòng)化

2009-12-15 17:28:11

Ruby自動(dòng)化腳本框架

2017-09-21 16:06:43

DevOps自動(dòng)化測試代碼
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板: 91中文视频 | 成人精品一区二区三区中文字幕 | 亚洲国产精品人人爽夜夜爽 | 精品一区av | 欧美专区在线观看 | 狠狠爱免费视频 | 成人午夜在线 | 国产综合久久久久久鬼色 | h视频在线观看免费 | 精品国产一级 | 久久久久国产成人精品亚洲午夜 | 99久久中文字幕三级久久日本 | 日本不卡一区二区三区在线观看 | 亚洲精品一区二区冲田杏梨 | 久久精品91久久久久久再现 | 成人一区二区三区视频 | 欧美精品网站 | 91.com在线观看| 狠狠干影院 | 国产羞羞视频在线观看 | 又爽又黄axxx片免费观看 | 国产成人精品免费视频大全最热 | 一级片子| 亚洲男人天堂网 | 天天爱av| 精品国产一二三区 | 岛国av免费观看 | 精品二区| 国产精品揄拍一区二区 | 日韩精品一区二区在线观看 | 97狠狠干| 久久一区二区三区电影 | 亚洲精品国产第一综合99久久 | 久久伊人一区 | 一区二区在线 | 日本精品久久 | 少妇一级淫片免费播放 | 国产精品一区在线 | www国产精品| 久久成人免费视频 | 亚洲午夜av久久乱码 |