[Day 13] 一次管好一堆應用：Argo CD App-of-Apps 實戰

2025 iThome 鐵人賽

DAY 13

Cloud Native

EKS in Practice：IaC × GitOps 實戰 30 天系列第 13 篇

17th鐵人賽 argocd application app of apps

Jac

2025-09-13 16:00:24

86 瀏覽

分享至

昨天我們已經將 ArgoCD 需要讀取的 Repo、以及需要管理的 cluster 註冊完畢。今天開始，我們會深入介紹我們昨天提過的架構圖，並且要讓 Argo CD 真正發揮 GitOps 的威力：透過 Application 與 App-of-Apps Pattern 來一次管理多個應用。

前情提要：Central Argo CD

在我們的架構裡，會有一個 central cluster 部署 ArgoCD，並且透過它來把 manifest 部署到多個 project cluster 中。Central Argo CD 從 GitLab 拉取設定，再透過 Application 的 destination 欄位、把資源套用到各個 project cluster。這樣做的好處主要是，Central 只持有到各叢集 API 的最小權限，讓每個專案的機密資訊留在該專案所屬的帳號裡，達到安全性的隔離。

Application：Argo CD 的最小單位

在 Argo CD 的世界裡，Application 是部署的最小單位。它描述了：

Git Repo 在哪裡？
要部署哪個 path 或 chart？
目標 cluster 與 namespace 是什麼？
要怎麼同步（自動/手動）？

只要寫好一個 Application manifest，Argo CD 就會幫你自動化這個部署。最小化的範例 YAML 長這樣：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx
  namespace: argocd
spec:
  project: default # 實務上會用自訂的 Project 來加強隔離，而不是直接用 default
  source:
    repoURL: https://charts.bitnami.com/bitnami ### git repo 在哪？
    chart: nginx                                ### 部署哪張 chart？
    targetRevision: 15.10.2
    helm:
      values: |
        replicaCount: 2
  destination:
    server: https://kubernetes.default.svc      ### 部署在哪個 cluster
    namespace: demo                             ### 部署在哪個 namespace

為什麼需要 App-of-Apps？

如果平台上只有一兩個應用，直接寫 Application YAML 就很足夠。但實務上，我們面對的是大量應用，不只是一兩個，而是十幾甚至數十個應用需要同步；這時候就必須用到 App-of-Apps Pattern。

它的核心概念是：

建立一個 Root Application；
Root App 指向一個 Git 目錄；
在該目錄下，存放多個子 Application 的描述；
Root App 一同步，所有子 Application 就會被一起建立。

這種模式的好處：

集中管理：只要 apply Root App，就能一次把所有應用部署起來。
環境清楚：可以依據 dev/testing/prod 做不同子目錄，Root App 指定 path 即可。
擴充容易：新增一個應用，只需在 Git 新增一個 Application YAML。

實作方式：Root Chart + Shared Child Chart

在我們的架構裡，App-of-Apps 不是直接放一堆裸裝 Application YAML，而是進一步用 Helm Chart 來管理。

Root Helm Chart

我們有一個專門的 Root Helm Chart，裡面 templates/ 下的每一個檔案，都是一個 Application manifest。

例如 dev-backstage.yaml、testing-worker.yaml 都是一個 Application；
每個 Application 都會指向同一個共用 chart（general-http）；
透過 values/ 下的對應檔案，注入各自的設定。

這樣一來，我們就可以用同一個 Base Chart，產生出許多不同應用的 Application。

Shared Child Chart（general-http）

所有子 Application 的 source 都會指向同一個 chart，也就是 general-http。

這個 chart 定義了 Deployment、Service、Ingress、Secret、Keda Scaler 等常見元件。

各個應用並不需要自己重新定義這些模板；
只要準備對應的 values.yaml，就能依需求覆寫設定。

Application + Value File 的組合

最後，每個 Application manifest 裡的 helm.valueFiles，都會指定對應的 values 檔案，讓它套用 child chart。

換句話說：

Application：決定要部署哪個應用、部署到哪個 cluster/namespace；
Chart（general-http）：定義應用的基礎模板；
Values：注入每個應用不同的設定（image/tag、replica、env 變數…）。
這樣我們就能用一套通用 chart，快速產生出許多不同的應用部署，既統一又具彈性。

可以看到 worker application 的 yaml 中，有指定一些 ArgoCD Image Updater 的 annotation。這邊的細節會留到後續講 CI/CD 時再進一步做介紹哦 O.<

總結

今天我們介紹了：

Application 是 Argo CD 的基本單位。
App-of-Apps Pattern 能集中管理同個環境中、不同的 applications，減少重複設定。
在我們的實作中，App-of-Apps 進一步結合了 Root Helm Chart + 共用 Child Chart：
- Root Chart 管理所有子 Application；
- 子 Application 指向同一個共用 chart（general-http）；
- 每個 Application 套用對應的 values file，生成專屬的配置。

今天我們解決了單一環境中，有可能要部署多個 applications 的管理問題。不過，要是 同一個應用需要同時部署在多個 cluster，那就是另一個挑戰了。這部分就不是 App-of-Apps 的重點，而會交給 ApplicationSet 來解決。這就是我們明天要探討的主題。