本文目標：

• GitOps 介紹
• ArgoCD 使用教學

進入正題

GitOps 是一種 Continuous Delivery（CD）的方式，它是在 2017 年由 Weaveworks 提出的，特色如下：

• 依賴於 Git：當 Git 版本控制庫的狀態改變時，會觸發 deployment。
• Declarative CD 概念
• 沒有人能夠直接的修改部署服務環境的設定
• 持續關注並且同步 Git repository 的差異
  • 所有的 Config 都會儲存在 Git Repository 上
  • 如果要更改 Config，必須要提出 Pull Request
  • 當 Pull Request 被接受且合併到主要的（Production）branch，CI/CD pipeline 會確保 Git Repository 的更變是否同步到部署的服務上

GitOps 的缺點

前面有提到：所有的 Config 都會儲存在 Git Repository 上以及如果要更改 Config，必須要提出 Pull Request，這也反應出 GitOps 的一些缺點及隱憂：

• Git Repository 的 commit 數量會增長的很快
• Git Repository 的衝突問題
• 難以管理敏感資料（Secret）

GitOps Tool 與 Kubernetes 的整合

GitOps Tool 在整個 CI/CD Pipeline 中扮演了很重要的角色，它需要：

• 持續關注與比較 Git Repository 的變化
• 將這些變化套用到部署環境

而這樣的部署方式其實非常適合應用在 Kubernetes 環境上，我們可以用 Git 管理服務與 K8s 的 configuration，每當 Git Repository 的內容更新時，GitOps Tool 會幫我們更新 Kubernetes 上已存在的 deployment。在這個情境下，不會有維運人員使用 kubectl 修改 Kubernetes 的狀態，所以發生問題時比較容易找到錯誤來源，也更容易做到版本的回溯。

下面兩篇文章很好的介紹了幾個 CD/CD Solution：

• GitOps: FluxCD vs. ArgoCD vs. Spinnaker vs. Jenkins X
• A comparison of CD platforms: Spinnaker vs Argo CD

而本篇文章會挑選 ArgoCD 作為範例。

ArgoCD 的安裝

argocd 需要安裝到指定的 namespace，所以我們需要為他建立 Namespace：

$ kubectl create namespace argocd

參考來源：GitHub Issue

[可選] 指定 argocd 為預設的 namespace：

$ kubectl config set-context --current --namespace=argocd

使用 kubectl 安裝 argoCD：

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

將 argocd-server 的 Service Type 改為 LoadBalancer：

$ kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

查看 argoCD svc：

$ kubectl get svc argocd-server -n argocd

上述指令會顯示 GUI 的網址，我們就能看到 argoCD 的登入畫面囉：

第一次登入時 argocd 會讓我們重設密碼，在登入之前可以使用以下命令取得預設的密碼：

$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

補充：預設帳號為 admin

建立 GitOps pipeline

登入後，我們可以在 ArgoCD 連接 Git Repository：

連接至 Git Repository 後，選擇 Create application：

設定同步的策略：

設定 Path 與 Cluster Url：

確定內容無誤，按下 Create 後，ArgoCD 就會為我們部署 free5GC 至 Kubernetes cluster 上囉！

總結

有了 ArgoCD 後，它可以幫助我們打造出類似於下方的 CI/CD 流程：

不過要把核心網路部署整合好其實會有很多開放式的問題：

• Source code 跟 Helm chart 要怎麼管理？
• 正式上線前可能會需要先搭建一個測試用環境通過所有測試，這一段該如何設計？
• 測試完成後要將應用部署到 production enviroonment 並且再次執行測試，又該如何處理？

本系列文大致介紹了將核心網路視為雲原生應用程式後如何整合一些現有的 solution（容器化、告警、日誌追蹤、測試與持續整合持續交付），剩下的部分就留給大家練習啦！