GitOps提供一種自動化基礎設施管理方法,已經在衆多團隊中獲得應用的DevOps最佳實踐——包括版本控制、代碼審查以及CI/CD流水線——都將被囊括於其中。目前,許多公司都在採用DevOps,看中的正是它在提升生產率和軟件質量方面擁有的巨大潛力。在這一過程當中,咱們已經找到了自動化軟件開發生命週期的方法。可是,當涉及到基礎設施的設置和部署時,手動操做的比重仍然至關可觀。有了GitOps,團隊就能夠自動化基礎設施配置過程。這是因爲在GitOps方法中,咱們可以使用聲明將基礎設施編寫爲代碼(IaC),然後像存儲應用程序開發代碼同樣將基礎設施即代碼存儲在Git repo當中。git
GitOps的概念最初是由Kubernetes管理公司Weaveworks所提出,所以關於GitOps的討論主要是在Kubernetes的背景下進行的。隨着總體設施轉向運行在容器內的微服務架構,咱們天然須要更多可行的編排平臺做爲支撐。事實上,基於容器的應用程序也每每擁有極爲複雜且難以管理的配置體系。GitOps則經過應用在DevOps領域已經獲得實際驗證的技術,幫助咱們簡化了這一過程。現在,這一思路已經在DevOps支持者中獲得普遍承認,也表明着IaC概念的升級模型。其中包含三大主要組成部分:安全
下面具體來看。服務器
基礎設施即代碼架構
IaC是一種將基礎設施以聲明文件的形式進行配置和管理,並將其存儲爲代碼的實踐。經過利用IaC和版本控制,團隊便可輕鬆優化全部的運營過程。GitOps以IaC的聲明性模型爲核心,同時也爲Kubernetes提供了良好的施展平臺。聲明性意味着配置更多關注指向預期狀態的聲明,而不是一組具體命令。例如,在Kubernetes中,你能夠在manifest中定義服務所需的Pod數量。以此爲基礎,系統將根據服務的運行狀態自動爲其提供Pod,而再也不由工程師編寫固定的Pod配置數量。任何符合聲明式模型的雲原生軟件均可以被視爲代碼。咱們使用AWS CloudFormation(一種聲明性工具)來編寫AWS基礎設施,藉此實現基礎設施即代碼原則。所需的狀態將被聲明爲代碼形式,系統則應用更改以自動達到這一目標狀態。固然,聲明式模型並非實現GitOps的惟一途徑。你們也可使用命令式定義環境實現相同的運營效果。框架
Pull請求運維
GitOps概念背後的核心思路,是將版本控制系統視爲單一的客觀來源。咱們使用Git做爲應用程序代碼的變動管理系統,也能夠將其用於基礎架構代碼。因此全部的聲明文件都託管在統一位置以供協做使用。在此基礎之上,咱們得以使用Git的關鍵概念——操做更改的pull請求。在應用程序開發工做流中,咱們使用一個主分支做爲發佈分支。開發人員在主分支內建立功能分支。在開發一項特定的功能或故事以後,咱們建立一個pull請求以將其合併回主分支。一樣的方法也能在基礎設施代碼中便捷起效。經過建立pull請求,咱們能夠保證代碼在被集成至代碼庫的另外一個分支以前,首先通過完整的代碼審查流程。代碼審查能夠阻止低質量代碼進入測試或生產環境,這一點對於基礎架構代碼來講尤其重要。經過代碼審查得到正式的批准,也將有助於後續的審覈和故障排查工做。分佈式
Git組織微服務
GitOps的部署過程至少須要兩個repo:應用程序repo與環境配置repo。前者包含應用程序的源代碼及其部署manifest;後者則包含了整個系統所需的狀態,該狀態使用聲明性規範來對環境中的各項要素加以描述。你能夠在代碼repo中將環境描述爲開發、測試和生產環境,同時包含能夠在該環境的特定版本中運行的應用程序和基礎設施服務。在基礎設施的狀況下,主分支能夠表示一個環境。咱們能夠在功能分支中實現這些更改,然後建立一個pull請求來合併主分支中的變動。經過這種方式,咱們能夠在實現協做的同時,以更加透明的方式瞭解誰執行了哪些更改。由於全部的更改都是在Git中提交完成,所以這也有利於跟蹤引起問題的根本緣由。GitOps適用於任何基於Git的系統,包括GitHub、BitBucket或GitLab。其不依賴於任何特定工具或技術。工具
CI/CD測試
爲了創建完整的GitOps實現,你還須要一條CI/CD流水線。經過使用自動化的交付流水線,每當Git存儲庫中發生更改時,你均可以將基礎設施更改交付到指定環境當中。這條流水線將你的Git pull請求鏈接到業務流程系統。當你使用pull請求觸發流水線時,業務流程系統將相應執行該任務。GitOps的部署策略有兩種方式:push與pull流水線。兩者的區別,主要體如今構建基礎設施時所採起的環境部署方式之上。
Push流水線
許多流行的CI/CD工具都在使用這種策略。咱們將應用程序的源代碼及其部署manifest存儲在一個repo當中。當應用程序代碼中發生新的更新時,構建流水線將觸發。流水線將構建容器鏡像並將更改推送到環境。這種策略帶來了更高的靈活性,足以支持任意類型的基礎設施。固然,這種方法也有缺點,即容許CI/CD工具直接訪問你的環境。
Pull流水線
社區廣泛認爲,pull流水線方法對GitOps來講是一種更爲安全的實踐方案。這種方法引入引入了操做符。操做符屬於流水線和業務流程工具之間的組件,它會不斷將環境repo中的目標狀態與已部署基礎設施中的實際狀態進行比較。一旦檢測到任何更改,則操做符會更改基礎設施以適應環境repo。此外,它還能夠監控鏡像倉庫,識別待部署的新版本鏡像。正是這一切,讓GitOps變得如此特別。在GitOps中,只有在環境repo中發生了更改時,纔會引起環境更新。若是實現的基礎設施以環境repo中未經定義的任何其餘方式發生更改,系統將恢復所作的任何修改。大多數應用程序可能須要同時使用多個環境。GitOps容許您建立多個能夠更改環境repo的流水線。您能夠在環境repo中使用單獨的分支以管理更多環境。面對分支變動,運維人員能夠在響應中將此項變動部署到生產環境當中,同時未來自另外一分支的其餘變動部署到測試環境。
DevOps最佳實踐
GitOps是一套專一於現有Git工做流、IaC、CI/CD流水線、不可變服務器、跟蹤與可觀察性最佳實踐的模型,也表明着Kubernetes在雲原生應用程序管理領域的先進的理念。所以,其技術棧與操做體驗可以切實爲企業用戶帶來諸多助益。
持續部署——簡化
持續部署意味着更快、更頻繁的部署節奏。出於多種不一樣考量,例如系統的有狀態性、宕機彈性、上游/下游的依賴關係,以及組織內常見的其餘過程與依賴項,不少朋友可能發現愈來愈難以創建適當的持續部署機制。GitOps不只可以實現持續部署,同時也讓你們擺脫了對大量工具方案的單獨管理——這是由於全部操做都發生在版本控制系統以內。做爲另外一大助力,部署操做符則負責提供結構和自動化支持。這也提升了生產力並帶來更快的MTTD(平均部署時間)。自動化持續部署確保團隊天天能夠交付30-100倍以上的更改,將平均生產效能提升2-3倍。
Rancher 2.5經過Rancher持續交付(Continuous Delivery)簡化了部署和管理。這是一項全新的功能,經過使用Git倉庫自動存儲和管理應用程序和配置信息,以確保部署的一致性,大大減輕了客戶的負擔,從而簡化跨私有云、公有云、混合雲或多雲環境的部署流程。
Rancher於2020年推出了海量集羣管理項目Fleet,這個項目成爲了Rancher持續交付的引擎。Fleet是一個Kubernetes集羣控制器,旨在解決全球內成千上萬集羣的挑戰。
低MTTR(平均修復時間)
MTTR是DevOps團隊須要衡量的關鍵指標之一。在微服務架構中,即便是極微小的問題也可能難以修復。因爲GitOps將全部更改保存在版本控制系統中,同時輔以自動化管理手段,所以有望顯著縮短MTTR。你能夠全面瞭解環境的變化進程,同時極大下降錯誤恢復難度。
簡化Kubernetes管理
即便對Kubernetes不甚瞭解,開發人員可使用熟悉的工具(如Git)輕鬆獲取Kubernetes升級與功能實現。新手嵌入式開發人員可以很快跟上進度,將本來須要數月的適應期壓縮到幾天時間。
改進企業總體的標準化水平
你能夠在整個企業中創建起透明的端到端工做流,這要歸功GitOps提供的用於呈現應用程序、軟件和Kubernetes附加組件修改的呈現框架。Git還可以全面重現你的各項操做活動。
創建穩定的代碼審查與測試過程
深刻檢查代碼更改將幫助咱們準確識別某些重要操做,例如添加全局變量,藉此防止低質量代碼被髮布到測試甚至生產環境當中。以此爲基礎,您能夠經過pull請求提交驗證過的代碼,且嚴格禁止開發人員直接提交更改。一旦pull請求完成審查與合併,便可觸發流水線。這是也維護高標準代碼、進而加強系統穩定性的第一步。
測試,測試,仍是測試
GitOps的介入意味着整個自動化水平都將提高到新的高度,這也要求咱們對流水線發佈的應用程序進行完全測試。儘管GitOps能幫助咱們相對輕鬆地完成回滾,但發佈通過良好測試的高質量代碼纔是真正提高進程可靠性的最佳途徑。
監控爲王
GitOps可以重播操做過程,持續跟蹤系統狀態並加以改進,最終據此執行發佈與回滾。嚴格的監控體系能夠幫助你識別並防止配置中出現任何非預期的漂移與系統更改。所以,在開始使用GitOps以前,請檢查你的監控技能並着手增強,確保其有能力處理這種變化。
擁抱新文化
傳統的流程約束以及較長的發佈時間只會拖慢業務節奏。全面擁抱DevOps文化,意味着咱們應當全面利用最佳戰略並幫助團隊理解開發和運維行動的價值。與此同時,開發與運維團隊必須聯手協做,創建起總體穩定的基礎設施,更快速、更順暢地運行應用程序,進而提高系統管理效率。而DevOps文化的欠缺將嚴重阻礙咱們享受GitOps帶來的好處。
GitOps是一種強大的工做流模式,能夠幫助您高效治理雲基礎設施。GitOps能夠爲工程團隊帶來諸多優點,極大加強系統的協調能力、透明度、穩定性與持久性。
原文連接: https://microtica.com/blog/gi...
文章來源:分佈式實驗室,點擊查看原文