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