GitOps初階指南：將DevOps擴展至K8S

本文轉自Rancher Labs

在過去十年的編程中，出現了一些革命性的轉變。其中之一是源於圍繞DevOps的實踐，它將開發和運維團隊整合到一個共享的工做流程中，此外還有持續集成和持續交付（CI/CD），經過CI/CD，Devops團隊能夠向代碼庫提供持續的更新。另外一個變革來自於從單體代碼庫到基於雲的微服務的遷移，這些微服務運行在由Kubernetes等編排平臺管理的容器中。

即便有Kubernetes這樣的平臺來編排協調，在集羣系統或雲端運行的基於容器的應用程序依舊多是複雜的、難以調配和管理的。GitOps是一套新興的實踐，旨在經過應用Devops和CI/CD世界的技術來簡化這一管理任務。

GitOps的關鍵是基礎設施即代碼（IaC）的理念，它採用與DevOps用於提供應用程序同樣的方法來提供基礎設施。因此，不只是應用，還有底層的主機和網絡都被描述在文件中，這些文件能夠像版本控制系統中的其餘代碼同樣，而後由自動化流程來將現實世界的應用與這些文件中描述的應用進行融合。

用GitOps的說法，版本控制系統中的代碼是關於應用在生產中應該是什麼樣子的惟一真相來源（single source of truth）。

定義GitOps

Weaveworks是在GitOps概念普及方面貢獻最大的公司。稍後咱們會詳細介紹Weaveworks在其中扮演的角色，但首先，咱們先來看看該公司對GitOps的定義，它有兩個方面：

• Kubernetes和其餘雲原生技術的運維模式，爲統一部署、管理和監控容器化集羣和應用提供了一套最佳實踐。
• GitOps是一條通往管理應用的開發者體驗之路；在這裏，端到端的CI/CD流水線和Git workflow能夠同時應用於運維和開發。

換句話說，GitOps是一套特定的實踐，旨在管理Kubernetes和相似的平臺。隨着愈來愈多的開發團隊採用DevOps實踐，並將代碼遷移到雲端，GitOps也將會適合更普遍的應用。但要了解GitOps的祕訣和它所能解決的問題，咱們須要談談它的組成部分。

Git定義

在GitOps中Git指的是由Linus Torvalds在2005年開發的極爲流行的分佈式版本控制系統。Git是一個工具，它容許開發者團隊在一個應用程序代碼庫上共同工做，存儲各類代碼分支，在將它們合併到生產代碼以前，他們能夠對這些代碼進行修補。Git 的一個關鍵概念是拉取請求，即開發人員正式要求將他們正在編寫的一些代碼整合到代碼庫的另外一個分支中。

Git 拉取請求爲團隊成員提供了一個協做和討論的機會，而後再就是否應該將新代碼添加到應用程序中達成共識。Git 還會存儲舊版本的代碼，若是出了問題，能夠很容易地回滾到上一個好的版本，並可讓你快速查看兩次修改之間的變化。Git 最爲人所知的部分多是做爲GitHub 這一雲端託管版本控制系統的底層，但 Git 自己也是一個開源軟件，能夠部署在任何地方，不管是公司內部的服務器仍是你的PC。

須要注意的是，雖然咱們一般認爲Git是一個計算機編程工具，但實際上取決於你如何使用它。Git 很樂意將任何文本文件做爲你的 「代碼庫」，例如，它能夠被做者用來記錄合做做品的編輯狀況。這一點很重要，由於GitOps的核心代碼庫大多由聲明式配置文件而非可執行代碼組成。

在咱們繼續以前，最後要強調一件事——儘管名字中就有 「Git」，但GitOps實際上並沒必要要使用Git。 已經投入使用其餘版本控制軟件（如Subversion）的團隊也能夠實現GitOps。但在Devops領域，Git被普遍用於實現CI/CD，因此大多數GitOps項目最終都會使用Git。

什麼是CI/CD流程？

關於CI/CD的完整解釋其實不在本文討論的範圍內，可是由於CI/CD是 GitOps 工做的核心，所以咱們須要對其進行簡單的介紹。CI/CD中的一半持續集成是由版本控制倉庫（如Git）實現的。開發者能夠對代碼庫進行持續的小改進，而不是每隔幾個月或幾年就推出巨大的、單一的新版本。持續部署這一塊是經過被稱爲流水線（pipeline）的自動化系統來實現的，這些流水線能夠構建、測試和部署新的代碼到生產中。

一樣，咱們在這裏一直在談論代碼，這一般會讓人聯想到用C語言、Java或JavaScript等編程語言編寫的可執行代碼。但在GitOps中，咱們所管理的 「代碼」 主要是由配置文件組成的。這不是一個小細節，而是GitOps工做的核心。正如咱們所說，這些配置文件是描述咱們的系統應該是什麼樣子的 「惟一真理來源（single source of truth）」。它們是聲明式的，而不是指導性的。這意味着，配置文件不會說 「啓動十臺服務器」，而會簡單地說 「這個系統包括十臺服務器」。

GitOps方程中的CI那一半容許開發人員快速推出對這些配置文件的調整和改進；當自動化軟件代理不遺餘力確保應用程序的實時版本可以反映配置文件中的描述時，CD這一部分會以GitOps語言趨向於聲明式模型。

GitOps和Kubernetes

正如咱們所提到的，GitOps的概念最初是圍繞管理Kubernetes應用而出現的。經過咱們如今對GitOps的瞭解，讓咱們重溫一下Weaveworks的GitOps討論，看看他們是如何描述如何對基於GitOps原則管理的Kubernetes進行更新的。下面是對整個流程的總結：

• 一個開發者爲一個新功能提出Git 拉取請求。
• 審查和批准代碼，而後將其合併到主代碼庫中。
• 合併會觸發 CI/CD 流水線、自動測試和重建新代碼，並將其部署到倉庫。
• 軟件代理注意到更新，從倉庫中提取新代碼，並更新配置倉庫中的配置文件（用YAML編寫）。
• Kubernetes集羣中的軟件代理根據配置文件，檢測到集羣已通過時，拉取更改，並部署新功能。

Weaveworks和GitOps

顯然，這裏的第4步和第5步作了不少繁重的工做。將Git倉庫中的 "真理來源 "與現實世界中的Kubernetes應用進行神奇同步的軟件代理，就是讓GitOps成爲可能的魔法。正如咱們所說，在GitOps術語中，讓實時系統更像配置文件中描述的理想系統的過程叫作融合。當實時系統和理想系統不一樣步時，那就是分歧。理想狀況下，融合能夠經過自動化流程來實現，但自動化所能作的事情是有限度的，有時人工干預是必要的。

咱們在這裏用通用術語描述了這個過程，但事實上，若是你真的去看Weaveworks的頁面，咱們提到的 「軟件代理」 是該公司Weave Cloud平臺的一部分。「GitOps」 這個詞是由Weaveworks的CEO Alexis Richardson創造的，它的部分做用是讓Weaveworks平臺對已經沉浸在DevOps和CI/CD世界的開發者有吸引力。

但Weaveworks從未宣稱本身壟斷了GitOps，GitOps更多的是一種理念和一套最佳實踐，而不是某種具體的產品。 正如提供CI/CD解決方案的公司CloudBees的博客所指出的那樣，GitOps表明了一種開放的、廠商中立的模式，它是針對亞馬遜、谷歌和微軟等大型雲廠商推出的管理型專有Kubernetes解決方案而開發的。CloudBees提供了本身的GitOps解決方案，這個領域的另外一些玩家也是如此。

GitOps和DevOps

Atlassian是一家爲敏捷開發者製造了許多工具的公司，它有一篇關於GitOps的歷史和目的的深度博文（https://www.atlassian.com/git... ），值得你花時間去了解。在他們看來，GitOps表明了做爲devops的理念的邏輯延伸。具體來講，GitOps是對基礎架構即代碼（IaC）這一律唸的闡述，而基礎架構自己就是DevOps環境下產生的一種思想。在Atlassian看來，GitOps彌補了現有DevOps技術與分佈式、雲託管應用的特殊需求之間的關鍵差距，現有DevOps技術是爲了解決系統管理問題而發展起來的。各個雲廠商提供的自動融合是GitOps的特別之處。

雖然GitOps今天仍然專一於Kubernetes，但咱們但願咱們已經明確了它如何適用於更普遍的分佈式、基於雲的應用世界。開源安全廠商WhiteSource的一篇博文概述了GitOps的優點：

• 可觀察性：GitOps系統爲複雜的應用提供了監控、日誌、跟蹤和可視化功能，所以開發人員能夠看到什麼地方出現了故障，在哪裏出現了故障。
• 版本控制和變動管理：很明顯，這是使用Git這樣的版本控制系統的一個關鍵優點。有缺陷的更新能夠輕鬆回滾。
• 易於採用：GitOps創建在許多開發人員已經掌握的開發技能之上。
• 提升生產力：GitOps 能夠像開發項目和 CI/CD 那樣提升工做效率。
• 審計：有了Git，每個操做均可以追蹤到一個特定的提交，這樣就能夠很容易地追蹤到錯誤的緣由。

即便你不使用Kubernetes，GitOps也頗有可能早晚會成爲你工做流程的一部分。