Introduction to GitOps

Talk about the history of GitOps, how Weaveworks has promoted the GitOps concept since 2017 and how to adopt this concept to the Kubernetes ecosystem to simplify the deployment challenge for developers and administrators.
Apart from the Kubernetes, how the GitOps concept has been used in other target environments, like the Infrastructure. how people run the Terraform and Ansible in the GitOps style?

Transcript

1. 【DevOps入 門 班】何謂 GitOps? 為什麼愈來愈多團 隊開始導入? HungWei Chiu, 2024/07/11
2. Weaveworks, “Guild to GitOps” GitOps works by using Git as a single source of truth for declarative infrastructure and applications.
3. GitOps • GitOps(Git & Ops) 這個詞是 Weaveworks 於 2017 所推廣的概念 • 上網搜尋會看到各式各樣的說法，仔細看會發現概念似乎不統 一 • 有沒有標準專案？ • 有沒有標準規則？ • Weaveworks 最初的構想是從 Kubernetes 上出發的 • 隨者時間推移， GitOps 的概念也落地到不同的環境與領域中
4. GitOps • GitOps(Git & Ops) 這個詞是 Weaveworks 於 2017 所推廣的概念 • 上網搜尋會看到各式各樣的說法，仔細看會發現概念似乎不統 一 • 有沒有標準專案？ • 有沒有標準規則？ • Weaveworks 最初的構想是從 Kubernetes 上出發的 • 隨者時間推移， GitOps 的概念也落地到不同的環境與領域中
5. Kubernetes • Kubernetes 是個容器管理平台，可以將容器 化的應 用 程式給部署到多節點的環境之中 • 使 用 者透過 YAML 格式來描述 自己 應 用 程式 的特性與設定 • 使 用 者使 用 CLI 工 具搭配 YAML 就可以完成 應 用 程式的部署 • Kubectl • Helm • …etc
6. Kubernetes • 一 個典型的 Kubernetes 應 用 程式會包含兩包檔案 • 應 用 程式原始碼 • 譬如 Java, Golang, Rust, Python 等原始碼 • 容器化的設定檔案 • Kubernetes 描述檔案 • YAML 格式
7. Kubernetes • Kubernetes 的應 用 程式開發與部署通常會經歷下列流程 • 應 用 程式 • 撰寫 • 編譯 • 容器化並且將容器給放到容器倉庫 • Kubernetes 設定檔案 • 撰寫設定檔案 • 準備 CLI 工 具 • 連接 Kubernetes 叢集 • 運 行
8. Kubernetes • 隨者團隊規模變 大 ，應 用 程式變多，Kubernetes YAML 的設定檔案也會愈來愈 多 • 這時候就需要導入 自 動化的機制來處理。 • 假設有兩個 Git repository • 一 個放程式原始碼 • 一 個放 Kubernetes 描述檔案
9. Kubernetes(應 用 程式) • 應 用 程式的 CI/CD 流 水 線 • CI • 應 用 程式檢查 • 測試 • CD • 容器化 • 將容器化結果推向容器倉庫
10. Kubernetes(YAML) • YAML 設定檔案的 CI/CD 流 水 線 • CI • YAML 格式檢查 • Kubernetes 語意檢查 • CD • 連接 Kubernetes 叢集 • 透過 CLI 工 具部署
11. Kubernetes(YAML) • 此種 方 式非常直覺，設定起來也很簡單 • Weaveworks 稱其為 CIOps • 認為其有諸多缺點 • 安全性 • 規模 大 會使得環境複雜化 • 環境多 • 應 用 程式多
12. CIOps 的問題
13. Kubernetes(YAML) • 其他的問題包含 • 如果應 用 程式有問題，要如何觸發對應的 CI/CD pipeline 重新部署 • 如果環境有問題，需要全部重新部署，要如何部署全部的應 用 程式？ • 一 個應 用 程式就 一 個 pipeline，那 一 百套就會有 一 百個 pipeline • 平 行 化處理還是依序處理？ 重建時間會不會拉長？
14. GitOps • 為了讓 Kubernetes 的應 用 程式更容易部署，同時能夠解決上述的各種問題 • Weaveworks 提出了 GitOps 概念，其核 心 概念是 • 所有設定都是基於 “Declaratively（宣告式）” 的概念去描述應 用 程式的最終狀態 • 應 用 程式要跑五份，應 用 程式要開 Port 80 • 使 用 Git 作為 Single Source of Truth • 任何修改最終狀態的設定都要 自 動地套 用 到遠 方 系統 • 會有 一 個軟體的應 用 程式去同步狀態並且檢查 一 制性
15. GitOps
16. GitOps • 同步軟體會定期不停檢查 Git 內的 目 標狀態與系統上的運 行 狀態 • 確保兩邊 一 樣 • 若不 一 樣，通知管理員告知環境有分叉 • 譬如有 人手 動去改系統環境
17. GitOps • GitOps 帶來的好處 • 提 高 效率 • 大 家只要將 YAML 放進去，剩下就由系統 自 己 同步 • 所有 手 動修改都會被抓出來，因為 Git 就是所有狀態來源 • 系統不需要存放各種 Kubernetes 環境的存取資訊 • 更容易去描述每個環境需要安裝的應 用 程式設定與版本 • 透過 Git 的機制來管理部署的應 用 程式，搭配 Git 退版就可以輕鬆將應 用 程式退版
18. GitOps
19. GitOps
20. GitOps • 如果是 Kubernetes 的使 用 者，去搜尋 GitOps 會看到很多 文 章，其中最常被看 到的幾個詞 大 概是 • ArgoCD (Argo) • Flux (Weaveworks) • Jenkins X • Fleet (Rancher, OpenSUSE) • …等
21. ArgoCD 範例 • 專 門 為 Kubernetes 所打造的 GitOps 專案 • 將所有跟 Kubernetes 有關的 YAML 都放到 Git 內 • 透過 一 個介 面 去呈現各種狀態 • 目 前是否有同步？ • 半 自 動/全 自 動 • 目 前是否有 人手 動修改？ • 是否要覆蓋？ • 目 前對應的 Git Branch/Tag
22. ArgoCD 範例 https://www.hwchiu.com/docs/2020/iThome_Challenge/cicd-18 • 有漂亮的 GUI 顯 示 當前狀態 • OutOfSync • Git 有描述 • 目 標 K8s 還沒安裝
23. ArgoCD 範例 https://www.hwchiu.com/docs/2020/iThome_Challenge/cicd-18 • 有漂亮的 GUI 顯 示 當前狀態 • Synced • Git 描述與 K8s 環境 內資源符合 • 顯 示 所有部署資源 狀況
24. ArgoCD 範例 https://www.hwchiu.com/docs/2020/iThome_Challenge/cicd-18 • 有漂亮的 GUI 顯 示 當前狀態 • 假設有 人手 動修改 K8s 內物件狀態 • OutOfSync • 告知你有哪些物件被修 改 • 可以決定要不要 用 Git 內的描述覆蓋回去
25. ArgoCD 範例 https://www.hwchiu.com/docs/2020/iThome_Challenge/cicd-18 • GUI 告知你差異
26. GitOps • GitOps 最初是為了解決 Kubernetes 內的部署問題，相關 文 件與 示 範全部都跟 Kubernetes 強烈綁定 • 但是 Weavework 認為 GitOps 更重要的是 Git 的核 心 ，Kubernetes 只是其中 一 個應 用 ，其他的環境與應 用 也都可以套入 GitOps 的核 心 概念 • 以 Git 為單 一 入 口 來源 • 所有設定都採取宣告式的描述，描述最終狀態
27. GitOps • 重新看 一 次 GitOps 的核 心 元件 • 所有設定都是基於 “Declaratively（宣告式）” 的概念去描述應 用 程式的最終 狀態 • 使 用 Git 作為 Single Source of Truth • 任何修改最終狀態的設定都要 自 動地套 用 到遠 方 系統 • 會有 一 個軟體的應 用 程式去同步狀態並且檢查 一 制性 • 這個概念似乎不容易套 用 到所有應 用 與環境
28. GitOps 範例 • 我是 一 個 Infrastructure 管理 人 員，我需要透過 Cloud Provider 準備三台 VM 供團隊使 用 • 我透過 IaC (Infrastructure as Code) 的概念撰寫了 一 些 工 具，可以透過該 工 具去創建資源 • 創建資源時會確保 三台 VM 都有正常運 行 • VM 若不存在，就創建 • VM 若關機，就開機 • VM 若設定不 一 樣，就調整設定 • 因為 IaC 也是程式碼，所以可以將這個概念放到 Git 內，並且搭配 Pipeline 來 自 動創建
29. GitOps 範例
30. GitOps 範例 • 理想很美好，現實很殘酷 • 同步軟體的複雜度比想像中 高 ，並不是所有架構與專案都有與之對應的同步軟體 • 邏輯複雜，需要 • 讀取 Git • 判別兩邊狀態差異，並且嘗試修正到 一 致 • 不是每種資源都可以即時更新 • 直接更新 • 砍舊建新
31. GitOps 範例 • 所以最後會退 而 求其次，移除同步軟體的情境，但是其餘 GitOps 的核 心 要保 留
32. GitOps 範例 • 仔細觀看可以發現，這個流向與最初 Weaveworks 的 CIOps 幾乎沒有差異 • 唯 一 的差異是 • 人 們 用 什麼樣的概念與準則來控管這些服務與流程 • 以 Git 為單 一 入 口 來源，不要有 手 動介入 • 以檔案描述所有檔案的最終狀態，並且搭配 Git 進 行 版本控制 • 自 動化將 Git 上的描述給套 用 到環境中 • 搭配 Git 的 工 作流程，如 MR/PR 等
33. Push Mode v.s Pull Mode • GitOps 的實作如果要再仔細檢視， 又 可以分成 Push Mode 與 Pull Mode • 可以將 Weavework 最初的理想視為 Pull Mode • 由 一 個同步軟體 自行 去 Pull Git 來獲取最新資訊，並且套 用 到系統上 • 反之，由 Pipeline 出發，並且主動將應 用 程式套 用 到環境的稱為 Push Mode • Push Mode 實作上 又 可以分成幾種 方 式
34. Push Mode (Webhook)
35. 其他 工 具 • 以前述 IaC 工 具為範例，最常 見 的 大 概就是 Terraform, Ansible 工 具 • 有些開源專案有嘗試幫忙實作該同步軟體 • Terraform-controller (Pull Mode) • https://github.com/ f lux-iac/tofu-controller • Ansible Automation Controller (Push Mode with Webhook)
36. GitOps 痛點 • 以 ArgoCD 為範例， ArgoCD 讓 Kubernetes 的管理 人 員有 一 個系統性的 方 式 去控管應 用 程式的部署 • 避免 人 為修改 • 簡化應 用 程式 (YAML) 檔案的結構與位置 • 透過 Argo 的格式與 方 式統 一 化 • 一 開始的時候都會覺得很新鮮，覺得 ArgoCD 真的很 方 便， 大 家都可以輕鬆部 署 Application 到 Kubernetes
37. GitOps 痛點 • 久了就會 面 臨 一 個問題， Git 內的檔案誰來寫？ • K8s 管理 人 員: • 我都幫你裝 ArgoCD 了 你應該要可以 自己 去 撰寫 YAML 部署吧 • 應 用 程式開發 人 員 自行 處理才對
38. GitOps 痛點 • 久了就會 面 臨 一 個問題， Git 內的檔案誰來寫？ • 應 用 程式開發 人 員 • 我只會寫 Code，我哪知 到 Kubernetes，更別說 一 堆複雜要命的 YAML 內 容。 • GitOps 不應該成為藉 口 團隊應該要幫忙包裝 一 層 抽象化讓我們更簡單使 用 才對
39. Today • Weavework 公司倒閉，但是 GitOps 這個詞已經到處都是 • 是不是遵循 Weavework 2017 所闡述的標準已經不是重點 • 該同步軟體只是流程的 一 部分 • 重點還是整個核 心 精神 • 以 Git 為單 一 入 口 來源 • 透過 Git 管理狀態與對應版本 • 所有合併到 Git 上的修改都要可以 自 動的套 用 到 目 標環境中