GitOps K8s 自動化佈署：ArgoCD 開發 K8s 持續佈署根本

– 16 分鐘閱讀

在現代雲原生應用開發中，持續整合（CI）和持續佈署（CD）已經成為標準實踐。在前面我們已經探討了 Tekton 和 GitHub Actions 等工具如何實作持續整合，但真正的挑戰在於：如何以符合 GitOps 理念的方式將應用佈署到 Kubernetes 環境中？

正如行業工作者 Daniel Bryant 所言：「如果你過去不用 SSH 佈署生產應用，那就別用 kubectl 在 Kubernetes 中做同樣的事。」這句話精確地點出了傳統佈署方式在雲原生環境中的侷限性。

Argo CD 正是為解決這一挑戰而生的工具 — 一個專為 Kubernetes 設計的宣告式 GitOps 持續佈署工具。Argo CD 不僅支援佈署原生 Kubernetes 資源清單，還能處理 Kustomize 和 Helm 專案，為複雜應用提供協調能力。

在本文中，玄貓將帶領大家從基礎安裝開始，探討 Argo CD 的核心功能，包括：

  • 基本安裝與首個應用佈署
  • 自動佈署與自我修復機制
  • 容器更新時的滾動佈署
  • 複雜應用的佈署協調

讓我們開始這場 GitOps 之旅，探索如何用 Argo CD 開發更可靠、更高效的應用佈署流程。

Argo CD 基礎：佈署你的第一個應用

問題背景

在採用 GitOps 模式時，我們面臨的首要問題是：如何讓 Argo CD 從 Git 倉函式庫得並佈署應用定義？傳統的佈署方式通常依賴於 CI 流程中的指令式指令碼，這與 GitOps 的宣告式理念相悖。

解決方案：Application 資源

Argo CD 的核心理念是將所有設定儲存在 Git 倉函式庫並透過 Application 資源告訴 Argo CD 在哪裡尋找這些設定。以下是實作這一目標的步驟：

1. 安裝 Argo CD

首先，讓我們在 Kubernetes 叢集中安裝 Argo CD：

kubectl apply -n argocd \
-f https://raw.githubusercontent.com/argoproj/argo-cd/v2.3.4/manifests/install.yaml

這個命令會在名為 argocd 的名稱空間中佈署 Argo CD 的所有必要元件。

可選步驟：安裝 CLI 工具與存取 Dashboard

雖然不是必需的，但安裝 Argo CD CLI 工具並存取其 Dashboard 可以幫助我們更直觀地管理應用。

  1. 從 Argo CD GitHub 發布頁面 下載適合你平台的 CLI 工具
  2. 使用連線埠轉發存取 Argo CD 伺服器：
    kubectl port-forward svc/argocd-server -n argocd 9090:443
  3. 取得初始管理員密碼：
    argoPass=$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)
  4. 登入 CLI：
    argocd login --insecure --grpc-web localhost:9090 --username admin --password $argoPass

這些憑證也可用於存取 Argo CD 的 Web 介面（http://localhost:9090）。

2. 設定並佈署範例應用

現在讓我們佈署一個簡單的 Web 應用，它會顯示一個具有設定顏色的框。該應用由三個 Kubernetes 資源組成：名稱空間、佈署和服務定義。

要讓 Argo CD 佈署這個應用，我們需要建立一個 Application 資源：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgd-app
  namespace: argocd  # Argo CD 安裝的名稱空間
spec:
  destination:
    namespace: bgd
    server: https://kubernetes.default.svc  # 目標叢集和名稱空間
  project: default  # 安裝在 Argo CD 的預設專案中
  source:
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git  # 資源清單所在的倉函式庫   path: ch07/bgd  # 資源清單的路徑
    targetRevision: main  # 要簽出的分支

內容解析：

這個 YAML 檔案告訴 Argo CD：

  • 在 argocd 名稱空間中建立一個名為 bgd-app 的應用
  • 該應用的原始碼位於指定 GitHub 倉函式庫ch07/bgd 路徑中
  • 應用應該佈署到當前叢集的 bgd 名稱空間
  • 使用 main 分支的內容

3. 註冊並同步應用

應用定義完成後，我們需要將其應用到叢集並觸發同步：

kubectl apply -f manual-bgd-app.yaml

此時，應用已在 Argo CD 中註冊，但尚未佈署。我們可以使用 CLI 檢查狀態：

argocd app list

輸出結果可能如下所示：

NAME     CLUSTER                     NAMESPACE  PROJECT  STATUS
bgd-app  https://kubernetes.default.svc  bgd       default  OutOfSync

注意 STATUS 欄位顯示為 OutOfSync，這表示 Git 倉函式庫期望狀態與叢集中的實際狀態存在差異。此時，如果檢查 bgd 名稱空間，你會發現沒有任何 Pod 執行：

kubectl get pods -n bgd
# 輸出：No resources found in bgd namespace.

這是因為 Argo CD 預設不會自動同步應用。要觸發同步，我們可以執行：

argocd app sync bgd-app

同步完成後，再次檢查 bgd 名稱空間，你會發現應用已成功佈署：

kubectl get pods -n bgd
# 輸出：NAME                  READY   STATUS    RESTARTS   AGE
#      bgd-788cb756f7-jll9n   1/1     Running   0          60s

kubectl get services -n bgd
# 輸出：NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)
#      bgd    ClusterIP   172.30.35.199   <none>        8080:32761/TCP

技術深度解析

在這個例子中，我們透過一個簡單的 Application 資源實作了 GitOps 的核心理念：

  1. 宣告式設定：我們沒有使用命令式的 kubectl create 或 kubectl apply，而是定義了一個 Application 資源來描述我們想要的狀態。

  2. 單一事實來源：所有設定都儲存在 Git 倉函式庫Argo CD 僅負責確保叢集狀態與 Git 中的定義一致。

  3. 手動觸發同步：預設情況下，Argo CD 不會自動同步應用，這讓團隊可以控制何時應用更改。

  4. 狀態視覺化：Argo CD 提供了清晰的介面來顯示應用的同步狀態，使得設定偏差一目瞭然。

這種模式與傳統 CI/CD 最大的區別在於，佈署不再是 CI 流程的延伸，而是一個獨立的、根據 Git 的協調過程。這使得佈署更加可靠、可稽核與可重現。

Argo CD 與自動化：實作自動同步與自我修復

在實際生產環境中，手動觸發每次同步操作可能會成為團隊的負擔，特別是當應用數量增加或更新頻繁時。Argo CD 提供了自動同步的能力，讓系統能夠自動回應 Git 倉函式庫更。

自動同步設定

要為應用啟用自動同步，我們需要在 Application 資源中增加同步策略：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgd-app-auto
  namespace: argocd
spec:
  destination:
    namespace: bgd
    server: https://kubernetes.default.svc
  project: default
  source:
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git
    path: ch07/bgd
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

內容解析：

這裡新增了 syncPolicy 部分，其中：

  • automated：啟用自動同步
  • prune: true：自動刪除 Git 中已移除的資源
  • selfHeal: true：當叢集中的資源與 Git 中的定義不符時自動修復

透過這些設定，Argo CD 將：

  1. 監控 Git 倉函式庫化
  2. 當檢測到變更時自動同步應用
  3. 如果有人直接修改叢集中的資源（繞過 GitOps 流程），自動將其還原為 Git 中定義的狀態

自我修復機制的實際應用

自我修復功能是 Argo CD 最強大的特性之一，它確保了叢集始終與 Git 中定義的狀態一致。讓我們透過一個實際例子來理解這一機制：

假設某個開發人員出於除錯目的，直接使用 kubectl 修改了佈署的副本數：

kubectl scale deployment bgd -n bgd --replicas=3

在沒有自我修復的情況下，這種變更會持續存在，導致實際狀態與 Git 中定義的期望狀態不一致。但有了自我修復機制，Argo CD 將檢測到這種偏差並自動將副本數還原為 Git 中定義的值。

這種機制確保了：

  1. 所有設定變更都必須透過 Git 提交
  2. 叢集設定具有高度的一致性和可預測性
  3. 臨時變更不會持久化，減少了環境漂移

技術實作原理

Argo CD 的自動同步和自我修復功能根據以下技術原理：

  1. 資源監控：Argo CD 持續監控已佈署資源的實際狀態
  2. 差異比較：將實際狀態與 Git 倉函式庫期望狀態進行比較
  3. 事件觸發：當檢測到差異時，觸發相應的同步操作
  4. 資源調和：應用必要的變更以使叢集狀態與 Git 定義一致

在 Kubernetes 生態系統中，這種模式被稱為「控制器模式」，它是宣告式 API 的核心機制。Argo CD 本質上是一個特殊的控制器，負責確保叢集中的資源與外部定義（Git 倉函式庫持一致。

整合 Kustomize 與 Helm：擴充套件 Argo CD 的應用管理能力

Argo CD 的強大之處不僅在於能夠佈署原生 Kubernetes 資源，還能無縫整合 Kustomize 和 Helm 等流行的 Kubernetes 設定工具。這使得團隊可以利用這些工具的優勢，同時享受 GitOps 的好處。

使用 Kustomize 管理環境差異

Kustomize 是 Kubernetes 原生的設定製工具，它允許我們在不同環境中重用基礎設定，同時應用環境特定的變更。結合 Argo CD，我們可以實作更靈活的多環境佈署。

以下是一個使用 Kustomize 的 Argo CD Application 範例：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kustomize-app
  namespace: argocd
spec:
  destination:
    namespace: kustomize-demo
    server: https://kubernetes.default.svc
  project: default
  source:
    repoURL: https://github.com/example/kustomize-demo.git
    path: overlays/production
    targetRevision: main
    kustomize:
      namePrefix: prod-
      images:
        - name=nginx:latest

內容解析：

這個設定告訴 Argo CD：

  • 從指定倉函式庫overlays/production 路徑取得 Kustomize 設定

Argo CD的GitOps實踐：從佈署到自動化

在現代Kubernetes環境中，GitOps已成為管理應用佈署的主流方法論。而Argo CD作為一個專為Kubernetes設計的GitOps工具，讓我們能夠直接從Git儲存函式庫並同步應用設定到叢集中。在這篇文章中，玄貓將帶領大家深入理解Argo CD的核心功能，包括應用佈署、同步策略，以及與Kustomize的整合。

驗證佈署狀態與存取服務

在GitOps流程中，驗證佈署成功是關鍵步驟。首先需要取得Minikube的IP位址：

minikube ip -p gitops
# 輸出結果: 192.168.59.100

取得IP後，我們可以透過瀏覽器存取該IP和暴露的連線埠（在這個例子中是192.168.59.100:32761）來驗證應用是否正確佈署。此時，應用介面中的圓圈應該呈現藍色。

更新應用設定與手動同步

GitOps的核心理念是透過Git管理所有設定變更。現在我們來修改應用的環境變數，讓圓圈從藍色變為綠色：

  1. 開啟bgd-deployment.yaml檔案，修改COLOR環境變數：
spec:
  containers:
  - image: quay.io/redhatworkshops/bgd:latest
    name: bgd
    env:
    - name: COLOR
      value: "green"
  1. 提交並推播變更到Git儲存函式庫
git add .
git commit -m "Updates color"
git push origin main
  1. 檢查應用狀態：
argocd app list

初始狀態可能顯示為Sync，這是因為Argo CD使用輪詢機制來檢測偏差。預設情況下，每3分鐘檢查一次。等待片刻後，狀態將變為OutOfSync，表示Git儲存函式庫義與叢集中的佈署已經不一致。

  1. 手動同步應用：
argocd app sync bgd-app

同步完成後，再次存取服務，圓圈顏色應已變為綠色。

實作自動同步策略

手動同步雖然安全，但在持續佈署環境中可能不夠高效。Argo CD支援自動同步策略，讓設定變更自動應用到叢集中。

要啟用自動同步，需要在Application定義中增加syncPolicy部分：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgd-app
  namespace: argocd
spec:
  destination:
    namespace: bgd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ch07/bgd
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git
    targetRevision: main
  syncPolicy:
    automated: {}

應用此設定後，Argo CD將自動佈署應用，無需額外命令：

kubectl apply -f bgd/bgd-app.yaml

可以透過以下命令驗證佈署狀態：

kubectl get pods -n bgd

這個自動同步設定中，syncPolicy.automated: {}表示啟用自動同步但使用預設設定。這意味著Argo CD會在檢測到Git儲存函式庫集之間的差異時自動同步，但不會自動刪除資源或修復手動更改。這是一種保守的自動化策略，確保安全性的同時提供一定程度的自動化。

深入理解自動同步策略的安全機制

Argo CD的自動同步策略包含兩個重要的安全機制：資源清理(pruning)和自我修復(self-healing)。

資源清理機制

預設情況下，當Git儲存函式庫除某個資源定義時，Argo CD不會自動刪除叢集中對應的資源，而是將應用狀態標記為OutOfSync。這樣設計是為了防止意外刪除重要資源。

啟用自動清理有兩種方式：

  1. 手動執行帶有--prune選項的同步命令：
argocd app sync --prune
  1. 在自動同步策略中啟用prune選項：
syncPolicy:
  automated:
    prune: true

自我修復機制

另一個重要機制是自我修復。預設情況下，如果有人直接在叢集中修改了應用設定（繞過Git），Argo CD不會自動修復這些更改。

讓我們透過實驗來理解這一機制：

  1. 使用kubectl patch命令直接更改佈署中的環境變數：
kubectl -n bgd patch deploy/bgd \
  --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/env/0/value", "value":"green"}]'
  1. 等待佈署完成：
kubectl rollout status deploy/bgd -n bgd

此時，應用介面中的圓圈應該變為綠色，但Argo CD會顯示應用狀態為OutOfSync，因為叢集中的設定與Git儲存函式庫定義不一致。然而，Argo CD不會自動修復這種偏差。

要啟用自我修復功能，需要設定selfHeal為true：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgd-app
  namespace: argocd
spec:
  destination:
    namespace: bgd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ch07/bgd
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

應用此設定：

kubectl apply -f bgd/heal-bgd-app.yaml

現在，如果再次嘗試直接修改佈署設定，Argo CD會自動將設定還原到Git儲存函式庫義的狀態，確保叢集與Git儲存函式庫一致。

這個增強版的自動同步設定增加了兩個重要引數：prune: true使Argo CD能夠自動刪除在Git中被移除的資源；selfHeal: true使其能夠自動修復叢集中手動引入的變更。這種設定非常適合嚴格的GitOps環境，確保叢集始終反映Git儲存函式庫預期狀態，防止任何未經授權的更改持續存在。

Kustomize與Argo CD的整合

Argo CD不僅支援原生Kubernetes清單，還支援多種組態管理工具，包括Kustomize、Helm、Ksonnet和Jsonnet。當Argo CD檢測到kustomization.yaml、kustomization.yml或Kustomization檔案時，會自動識別為Kustomize專案。

讓我們看一個使用Kustomize佈署BGD應用的例子，同時將圓圈顏色設定為黃色：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: bgdk
resources:
- ../base
- bgdk-ns.yaml
patchesJson6902:
- target:
    version: v1
    group: apps
    kind: Deployment
    name: bgd
    namespace: bgdk
  patch: |-
    - op: replace
      path: /spec/template/spec/containers/0/env/0/value
      value: yellow

這個Kustomize設定做了幾件重要的事情：

  1. 設定名稱空間為bgdk
  2. 包含基礎目錄中的標準佈署檔案（預設顯示藍色圓圈）
  3. 包含一個用於建立名稱空間的特設定檔案
  4. 使用JSON Patch格式修改佈署檔案，將環境變數COLOR的值從原來的藍色覆寫為黃色

透過這種方式，我們可以在不直接修改原始佈署檔案的情況下，為不同環境或使用案例定製應用設定。這是Kustomize的核心優勢之一，而Argo CD原生支援這種工作流程。

Argo CD自動化佈署的最佳實踐

在實際使用Argo CD進行自動化佈署時，有幾點最佳實踐值得注意：

  1. 謹慎使用自動清理：雖然自動清理可以保持叢集整潔，但也可能導致意外刪除重要資源。在生產環境中，建議先手動驗證同步計劃，確認無誤後再啟用自動清理。

  2. 分階段啟用自我修復：自我修復功能強大，但可能會覆寫緊急修復。建議在非關鍵環境中先試用，熟悉其行為後再在生產環境啟用。

  3. 適當設定同步間隔：預設的3分鐘同步間隔可能不適合所有場景。對於關鍵應用，可以縮短間隔；對於變更不頻繁的應用，可以延長間隔以減少資源消耗。

  4. 利用應用集(ApplicationSets)：對於需要佈署到多個叢集或名稱空間的應用，使用ApplicationSets可以大簡化管理。

  5. 實施漸進式同步：對於大型應用，可以使用Argo CD的漸進式同步功能，按照特定順序應用更改，減少服務中斷風險。

  6. 結合CI管道：將Argo CD與CI管道整合，實作程式碼更改自動測試、構建和佈署的完整流程。

Argo CD為Kubernetes環境提供了強大的GitOps實作方案，從手動同步到全自動佈署，從基本設定到Kustomize整合，滿足了各種複雜度的佈署需求。透過合理設定自動同步策略，可以在確保安全的同時提高佈署效率。

在實際專案中，玄貓建議從簡單的手動同步開始，逐步引入自動化功能，同時建立完善的監控和回復機制。隨著對Argo CD的深入理解，可以進一步探索其高階功能，如藍綠佈署、金絲雀發布等，開發更加強大的持續佈署流程。

GitOps的核心理念是"以Git為單一事實來源"，而Argo CD則是將這一理念落地為實用工具的絕佳選擇。透過本文介紹的實踐方法，相信你已經掌握了Argo CD的基本使用技巧，可以開始在實際專案中實施GitOps了。

Argo CD 的多元化佈署策略：超越基礎應用

在實際的 Kubernetes 環境中，我們通常需要比基礎 GitOps 佈署更靈活的解決方案。隨著應用程式複雜度增加，管理設定變異性、整合不同工具和自動化更新容器映像等需求變得日益重要。在這篇文章中，我將分享在多年實踐過程中，如何利用 Argo CD 與主流 Kubernetes 設定工具的整合能力，開發強大而靈活的 GitOps 工作流程。

Kustomize 整合：靈活定製佈署設定

Kustomize 是 Kubernetes 原生的組態管理工具，能讓我們在不修改原始 YAML 檔案的情況下，對應用程式設定進行客製化。當 Argo CD 偵測到佈署目錄中有 kustomization.yaml 檔案時，會自動使用 Kustomize 進行資源處理。

佈署 Kustomize 應用

讓我們來看一個實際案例，使用 Argo CD 佈署一個透過 Kustomize 管理的應用程式：

首先，我們需要建立一個 Application 資源檔案來定義應用程式佈署：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgdk-app
  namespace: argocd
spec:
  destination:
    namespace: bgdk
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ch07/bgdk/bgdk
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git
    targetRevision: main
  syncPolicy:
    automated: {}

這個 Argo CD Application 資源定義了一個名為 bgdk-app 的應用程式：

  • metadata 部分指定了應用程式的名稱和名稱空間
  • spec.destination 指定佈署目標為本地 Kubernetes 叢集的 bgdk 名稱空間
  • spec.source 定義了來源設定，指向 GitHub 儲存函式庫特定路徑，Argo CD 會自動偵測此路徑下的 kustomization.yaml 檔案
  • syncPolicy.automated 啟用了自動同步功能，當 Git 儲存函式庫設定變更時，Argo CD 將自動更新佈署

將此設定應用到叢集後，可以執行以下命令：

kubectl apply -f bgdk/bgdk-app.yaml

佈署完成後，你會發現應用程式中的圓圈從原本的藍色變成了黃色，這正是 Kustomize 設定所定義的變化。若要移除應用程式，可以使用以下命令：

argocd app delete bgdk-app

覆寫 Argo CD 工具偵測機制

在某些情況下，我們可能需要明確指定要使用的工具，而不依賴 Argo CD 的自動偵測演算法。例如，即使存在 kustomization.yaml 檔案，我們也可以強制使用純目錄策略：

source:
  directory:
    recurse: true

Argo CD 支援多種佈署策略，包括：

  • directory
  • chart
  • helm
  • kustomize
  • path
  • plugin

值得注意的是，在 Argo CD 中使用 Kustomize 時，所有 Kustomize 的功能都能正常運作，這使得組態管理變得更加靈活。

Helm 整合：強大的包管理能力

Helm 是 Kubernetes 生態系統中廣泛使用的包管理工具，提供了範本化、版本控制和相依性管理等功能。Argo CD 能夠整合 Helm，當它在佈署目錄中偵測到 圖表.yaml 檔案時，會自動以 Helm 方式佈署應用程式。

佈署 Helm 應用

讓我們使用 Helm 佈署相同的 BGD 應用程式：

在 GitHub 儲存函式庫已經準備好了一個標準的 Helm 專案結構：

├── 圖表.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── ns.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

接著，我們建立 Application 資源來定義 Argo CD 佈署：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgdh-app
  namespace: argocd
spec:
  destination:
    namespace: bgdh
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ch07/bgdh
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git
    targetRevision: main
  syncPolicy:
    automated: {}

這個 Application 資源與前面的 Kustomize 範例類別似，主要差別在於：

  • 應用程式名稱為 bgdh-app
  • 佈署名稱空間為 bgdh
  • 來源路徑指向 Helm 圖表 所在位置

將此設定應用到叢集：

kubectl apply -f bgdh/bgdh-app.yaml

驗證 Pod 是否在 bgdh 名稱空間中執行：

kubectl get pods -n bgdh
NAME                         READY   STATUS    RESTARTS   AGE
bgdh-app-556c46fcd6-ctfkf   1/1     Running   0          5m43s

Helm 環境變數與引數覆寫

Argo CD 在處理 Helm 清單時，會自動填入一系列環境變數，這些變數也適用於 Kustomize、Jsonnet 和自定義工具：

  • ARGOCD_APP_NAME
  • ARGOCD_APP_NAMESPACE
  • ARGOCD_APP_REVISION
  • ARGOCD_APP_SOURCE_PATH
  • ARGOCD_APP_SOURCE_REPO_URL
  • ARGOCD_APP_SOURCE_TARGET_REVISION
  • KUBE_VERSION
  • KUBE_API_VERSIONS

我們可以在 Application 定義中使用這些環境變數：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgdh-app
  namespace: openshift-gitops
spec:
  destination:
    # ...省略
  source:
    path: ch07/bgd
    # ...省略
    helm:
      parameters:
        - name: app
          value: $ARGOCD_APP_NAME

在這個範例中：

  • 我們在 source 部分增加了 helm 設定區塊
  • 透過 parameters 設定 Helm 引數，優先順序高於 values.yaml 中的設定
  • 使用 $ARGOCD_APP_NAME 環境變數作為引數值，這將被替換為應用程式的實際名稱

Argo CD 也支援使用不同的 values.yaml 檔案或直接設定引數覆寫原有的值：

argocd app set bgdh-app --values new-values.yaml
argocd app set bgdh-app -p service.type=LoadBalancer

注意，自定義的 values 檔案必須與 Helm 圖表 位於同一個 Git 儲存函式庫此外，Argo CD 也支援 Helm hooks，這讓佈署流程更加靈活。

Image Updater：自動化容器映像更新

在持續交付過程中，最常見的重複性任務之一就是佈署新版本的容器映像。在純 Argo CD 的解決方案中，當新的容器映像發布到容器倉函式庫我們需要手動更新 Kubernetes/Kustomize/Helm 清單檔案，並將變更推播到 Git 儲存函式庫個過程通常包括：

  1. 複製儲存函式庫. 解析 YAML 檔案並進行相應更新
  2. 提交並推播變更

雖然這種方法可行，但過程繁瑣與重複性高。理想情況下，叢集應能自動偵測到容器倉函式庫新映像並更新佈署。這正是 Argo CD Image Updater (簡稱 ArgoCD IU) 的功能 — 它是一個 Kubernetes 控制器，能監控容器映像的新版本並自動更新 Argo CD Application 中定義的資源。

Argo CD Image Updater 工作流程

Argo CD IU 與 Argo CD 協同工作的流程如下：

  1. 容器映像被推播到容器倉函式庫. Argo CD IU 偵測到新映像
  2. Argo CD IU 更新資源清單（可透過 Git 或 Argo CD API）
  3. Argo CD 偵測到 Git 儲存函式庫或直接收更新
  4. Argo CD 佈署新版本的應用程式

目前，Argo CD IU 僅支援更新 Kustomize 或 Helm 資源清單。對於 Helm，它需要能夠透過引數（如 image.tag）指定映像標籤。

安裝 Argo CD Image Updater

讓我們在 Argo CD 所在的名稱空間中安裝控制器：

kubectl apply -f \
  https://raw.githubusercontent.com/argoproj-labs/argocd-imageupdater/v0.12.0/manifests/install.yaml -n argocd

驗證安裝是否成功：

kubectl get pods -n argocd
NAME                                    READY   STATUS    RESTARTS   AGE
argocd-image-updater-59c45cbc5c-kjjtp   1/1     Running   0          40h

設定 Git 認證

在使用 Argo CD IU 之前，我們需要建立一個 Kubernetes Secret 來儲存 Git 認證，以便更新的資源清單能夠推播到儲存函式庫

kubectl -n argocd create secret generic git-creds \
  --from-literal=username=<git_user> \
  --from-literal=password=<git_password_or_token>

建立映像更新自動化應用

接下來，我們使用特殊註解來標記 Application 資源，使控制器開始監控容器倉函式庫

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bgdk-app
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/image-list: myalias=quay.io/rhdevelopers/bgd
    argocd-image-updater.argoproj.io/write-back-method: git:secret:openshift-gitops/git-creds
    argocd-image-updater.argoproj.io/git-branch: main
spec:
  destination:
    namespace: bgdk
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ch07/bgdui/bgdk
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git
    targetRevision: main
  syncPolicy:
    automated: {}

在這個範例中，我們增加了三個重要的註解：

  • image-list：指定要監控的映像，格式為 <別名>=<映像路徑>
  • write-back-method：指定更新傳播方法，這裡使用 Git 方法並指定認證位置 (<名稱空間>/<金鑰名稱>)
  • git-branch：指定要推播變更的分支

將此設定應用到叢集：

kubectl apply -f bgdui/bgdui-app.yaml

此時，版本 1.0.0 的應用程式已在 bgdk 名稱空間中執行，並且 Argo CD IU 已準備好監控容器倉函式庫更。

測試自動更新功能

為了測試自動更新功能，我們可以為容器映像增加一個新標籤 (如 1.1.0)，模擬發布新版本。當 Argo CD IU 偵測到新映像時，它將：

  1. 更新 Git 儲存函式庫資源清單
  2. Argo CD 偵測到變更並佈署新版本
  3. 應用程式自動更新到最新版本

這個流程完全自動化，無需人工干預，大提高了持續佈署的效率。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。