運用 Helm 值分層於多源 Argo CD 應用程式中實作 GitOps 環境推進

在採用 GitOps 方法時，選擇 Helm 的組織經常遇到一些獨特的挑戰，本文將探討如何運用 Helm 的值分層結構，在多來源 Argo CD 應用程式中實作 GitOps 環境的推進。除了將 Helm 圖表儲存在 Git 之外，它們也可以儲存在專用的 Helm 倉函式庫這使得 Helm 圖表本身就具備了版本控制。

1. GitOps 倉函式庫Helm 的推薦結構

建議的 Helm 結構應該清晰地劃分通用設定和環境特定設定。這有助於在不同環境之間推廣應用程式時，保持設定的一致性和可維護性。

通用設定 (Common Settings)： 儲存在所有環境分享的基礎 values.yaml 檔案中。
環境特定設定 (Environment-Specific Settings)： 儲存在覆寫通用設定的環境特設定檔案中 (例如：values-qa.yaml、values-staging.yaml、values-prod.yaml)。

2. 何時使用 Argo CD 的多來源功能

Argo CD 的多來源功能允許應用程式從多個 Git 倉函式庫Helm 倉函式庫取設定。然而，並非所有情況都適合使用此功能。以下提供一些指引：

適合使用情境： 當應用程式的元件分散在不同的倉函式庫或需要從不同的團隊管理的不同 Helm 圖表中組裝應用程式時。
不適合使用情境： 當應用程式的設定差異僅在於環境特定值時，應優先使用 Helm 的值分層結構，而非多來源功能。

3. 建立 Helm 值層級的重要性

Helm 值層級允許您定義多個值檔案，並在安裝圖表時將它們合併。後面的檔案會覆寫前面檔案中的值，這使得建立可重用的設定成為可能。

優點： 減少設定重複，提高可維護性，並簡化在不同環境之間推廣應用程式的過程。
實踐： 建立一個 Helm 值檔案的層次結構，其中包含多數環境的通用值，以及包含個別佈署特定值的檔案。

一個可能的值層級結構如下所示：

common-values.yaml
+-----all-prod-envs.yaml
+----specific-prod-cluster.yaml

4. 常見的 Helm 不良實踐與對 Argo CD 的誤解

一些團隊嘗試在 Argo CD 中複製 Helm 已經支援的功能，或者在未先了解 Helm 基礎知識的情況下嘗試採用 Argo CD。以下是一些常見的不良實踐和誤解：

錯誤地重新發明輪子： 不要嘗試在 Argo CD 中重新實作 Helm 的值分層結構或其他內建功能。
忽略 Helm 基礎知識： 在採用 Argo CD 之前，務必充分了解 Helm 的概念和最佳實踐。
誤用多來源功能： 避免將多來源功能用於僅需環境特定設定差異的情況。

5. 使用 Helm 值層級整合 Argo CD

Argo CD 能夠直接支援 Helm 層級，無需額外設定。在 Argo CD 應用程式定義中，您可以指定一個值檔案的陣列，Argo CD 會按照指定的順序合併這些檔案。

以下是一個範例 Argo CD 應用程式定義：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    chart: my-chart
    repoURL: https://github.com/my-example-app
    targetRevision: 2.43
    helm:
      valueFiles:
        - common-values.yaml
        - all-prod-envs.yaml
        - specific-prod-cluster.yaml
  destination:
    server: "https://kubernetes.default.svc"
    namespace: default

valueFiles 屬性接受一個值檔案的陣列。與 Helm CLI 類別似，列表中提到的每個檔案都會覆寫之前檔案中的所有值。最後一個檔案會優先於之前的檔案。

6. Helm 圖表的兩種版本控制策略

您需要決定您的 Helm 圖表是否會對應到特定的應用程式。

策略一：每個應用程式一個 Helm 圖表
在這種情況下，Helm 圖表有 2 個版本。一個版本保留有關圖表本身的歷史記錄，第二個版本（圖表.yml 檔案中的 appVersion）追蹤圖表中包含的應用程式。
策略二：可重用的「單一」圖表
您擁有一個可重用的「單一」圖表，針對許多應用程式。它本身不持有特定的應用程式。您始終需要將其與定義映像/標籤/設定的值結合使用。

兩種方法都是有效的，Argo CD 支援兩者。然而，為您的組織選擇一種策略是有意義的。

7. 範例：使用 Helm 在不同環境推進應用程式

假設有一個經典的 QA/Staging/Prod 三環境設定，您應該能夠輕鬆地安裝具有適當設定的任何圖表，如下所示：

helm install ./my-chart/ --generate-name -f values-qa.yaml
helm install ./my-chart/ --generate-name -f values-staging.yaml
helm install ./my-chart/ --generate-name -f values-production.yaml

在這個簡單的例子中，圖表作為普通檔案與其可能的設定一起儲存在 Git 中。

8. 更複雜的 Helm 值層級範例：

如果您有屬性同時存在於 common.yaml 和 more.yaml 中，則以後者為準。同樣，所有在 some-more.yaml 中定義的屬性將作為對您在之前檔案中定義的所有其他屬性的「覆寫」。

要使這個工作，您需要按照預期的順序應用所有檔案——記住最後一個的優先權。

helm install ./my-chart/ --generate-name -f common-values.yaml -f all-prod-envs.yaml -f specific-prod-cluster.yaml

如果您正在為自己的應用程式使用 Helm，則必須為所有 Helm 應用程式建立適當的層次結構，以平衡靈活性和最小重複。還要記住，Helm 內建了這些層級。它們與 Argo CD 無關。

總而言之，透過理解 Helm 的值分層結構，並結合 Argo CD 的強大功能，可以有效地管理多來源應用程式，並將其順暢地推進到不同的 GitOps 環境中。關鍵在於選擇適合組織需求的 Helm 結構，避免常見的不良實踐和誤解，並充分利用 Argo CD 對 Helm 的原生支援，實作自動化、可重複與可稽核的佈署流程。

在 Kubernetes 的世界中，Helm 和 Argo CD 已成為應用程式佈署的關鍵工具。Helm 簡化了 Kubernetes 資源的管理，而 Argo CD 則確保應用程式狀態與 Git 倉函式庫宣告一致，實作 GitOps 的核心原則。本文將探討如何結合 Helm Value 結構與 Argo CD 的多重來源功能，以更有效的方式管理和佈署應用程式，同時避免常見的陷阱。

1. 避免 Helm Value 的過度範本化

許多團隊在使用 Helm 時，為了複製 Helm Value 的層次結構，會在應用程式或應用程式集上新增額外的範本層。這種做法往往會導致複雜性增加，降低可維護性。更好的做法是充分利用 Argo CD 內建的 Helm Value 結構支援，避免不必要的範本層疊。

2. 運用來自 Helm 倉函式庫表

雖然建議將 Helm 圖表及其 Value 儲存在 Git 中，但有些組織更傾向於使用 Helm 倉函式庫elm Repository）或 OCI 註冊中心（OCI Registry）。Argo CD 支援這種情況，但需要注意以下幾點：

可變性（Mutability）： Helm 倉函式庫OCI Artifacts 是可變的，這意味著同一版本的圖表在不同時間下載，內容可能不同。這與 GitOps 的不變性原則相悖。
稽核與歷史（Audit and History）： 使用 Helm 倉函式庫內建的稽核與歷史記錄功能，而 Git 可以免費提供這些功能。
完整性與安全性（Integrity and Security）： 難以驗證從註冊中心下載的圖表是否未被篡改。

如果必須從外部倉函式庫圖表，強烈建議將自己的 Value 儲存在 Git 倉函式庫Argo CD 可以使用多重來源（Multiple Sources）功能合併這兩者。

3. Argo CD 多重來源的應用

多重來源是 Argo CD 專為合併外部 Helm 圖表與自定義 Value 而設計的功能。在最基本的情況下，需要定義兩個來源：

包含外部 Helm 圖表的來源
包含 Helm Value 的來源

以下是一個範例：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-fancy-app
  namespace: argocd
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: prod-us
  sources:
  - repoURL: https://acme.github.io/my-charts/
    chart: my-app
    targetRevision: 2.43
    helm:
      valueFiles:
      - $values/common-values.yaml
      - $values/all-prod-envs.yaml
      - $values/specific-prod-cluster.yaml
  - repoURL: 'https://github.com/example-org/all-my-values.git'
    targetRevision: HEAD
    ref: values

在這個範例中，ref: values 欄位與 helm 屬性中的 $values 字首相關聯。Argo CD 會從外部來源載入圖表，並將其與按順序定義的所有 Value 檔案合併（後面的檔案會覆寫前面的檔案）。

請注意： 不要濫用 Argo CD 的多重來源功能。它不是一種通用的應用程式分組方式。通常，應該只有 2 個來源來形成單一應用程式的相關資料。如果發現自己在分組不相關的應用程式或擁有超過 2 到 3 個來源，應考慮使用應用程式的應用程式（Application of Applications）和應用程式集（Application Sets）。

4. 結合 Helm Value 層級的應用程式集

如果將 Helm 圖表作為單獨的 Argo CD 應用程式進行佈署，則應對應用程式集執行相同操作。應用程式集也支援 Helm Value 層次結構。與應用程式中的其他所有內容一樣，可以對圖表 Value、資料夾、修訂版本或任何其他想要的內容進行範本化。

應用程式集也可以與多個來源一起使用。因此，可以將到目前為止看到的所有內容合併到一個應用程式集中，如下所示：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-fancy-apps
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
  - list:
      elements:
      - env: qa
        type: non-prod
      - env: prod-eu
        type: prod
      - env: prod-us
        type: prod
  template:
    metadata:
      name: '{{.env}}'
    spec:
      project: default
      sources:
      - repoURL: https://acme.github.io/my-charts/
        chart: my-chart
        targetRevision: 2.43
        helm:
          valueFiles:
          - $values/common-values.yaml
          - $values/all-{{.type}}-envs.yaml
          - $values/{{.env}}-values.yaml
      - repoURL: 'https://github.com/example-org/all-my-values.git'
        targetRevision: HEAD
        ref: values
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{.env}}'

這個應用程式集定義了 3 個環境（qa、prod-eu、prod-us）。它使用 Helm 層級和一個外部圖表。請注意，可以在不需要任何額外範本解決方案的情況下，對所有 Value 檔案的位置進行範本化。

許多團隊將他們的應用程式 CRD（或 ApplicationSet CRD）放在 Helm 圖表中，以便在第二層進行範本化。這種複雜性是不必要的。Application Sets 本身涵蓋了大多數常見場景。Application Sets 是一種範本化的方式（與 Helm 相同）。使用 Helm 生成 Application Sets（或 Applications）是一個災難的配方。如果有些東西無法使用應用程式集進行範本化，最好是提出增強請求，而不是再增加另一層範本化。

透過充分利用 Helm Value 結構和 Argo CD 的多重來源功能，可以更有效地管理和佈署 Kubernetes 應用程式，避免不必要的複雜性。重要的是要理解這些工具的優勢和限制，並根據實際需求做出明智的選擇。最終，一個清晰、簡潔與可維護的佈署流程，將有助於團隊更快速、更可靠地交付價值。

在現代雲原生應用程式開發中，管理多個環境的佈署是一項複雜的挑戰。為了簡化此流程，我們可以結合 Argo CD 和 Helm 價值階層，實作更有效率與一致的佈署策略。本文將探討如何運用 Helm 的可重用價值結構，並透過 Argo CD 應用程式集，自動化跨區域應用程式的佈署。

Helm 價值階層：可重用的設定結構

Helm 價值階層提供了一種可重用的設定方式，允許開發者以層次化的方式組織和管理應用程式的設定。這種結構類別似於 Kustomize 的可重用元件，但這次我們使用 Helm 值而不是 Kustomize 覆寫。

假設我們有以下環境：

整合測試（非 GPU 和啟用 GPU）
QA（僅一個例項，位於美國）
測試階段（位於歐洲、亞洲、美國）
生產環境（僅位於歐盟和美國）

如同 Kustomize 的可重用元件，我們也擁有一種可重用的 Helm 價值結構，可以層次化的方式使用。目標是形成一個完整的 Helm 發布，這需要依序結合多個價值檔案。

例如，若要將應用程式佈署到位於歐盟地區的 “Staging” 環境，傳統上需要使用 Helm 執行以下指令：

helm install ./my-chart/ --generate-name --create-namespace -n staging-eu \
-f my-values/common-values.yaml \
-f my-values/app-version/staging-values.yaml \
-f my-values/env-type/non-prod-values.yaml \
-f my-values/regions/eu-values.yaml \
-f my-values/envs/staging-eu-values.yaml

請注意，最後的設定會覆寫先前的設定。您可以隨時使用樹狀結構中更深層檔案中的不同設定，來覆寫通用設定。

Argo CD 應用程式：自動化 Helm 佈署

現在，我們不直接使用 Helm，而是透過 Argo CD 安裝相同的層級。以下是一個範例 Argo CD 應用程式，它使用 Helm 價值檔案的層次結構：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: staging-eu-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: staging-eu
  sources:
    - repoURL: https://github.com/kostis-codefresh/multi-sources-example.git
      path: my-chart
      targetRevision: HEAD
      helm:
        valueFiles:
          - $values/my-values/common-values.yaml
          - $values/my-values/app-version/staging-values.yaml
          - $values/my-values/env-type/non-prod-values.yaml
          - $values/my-values/regions/eu-values.yaml
          - $values/my-values/envs/staging-eu-values.yaml
    - repoURL: 'https://github.com/kostis-codefresh/multi-sources-example.git'
      targetRevision: HEAD
      ref: values
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true
      selfHeal: true

此檔案遵循應用程式集中概述的最佳實務。透過 Argo CD 佈署此應用程式，您可以輕鬆驗證設定是否根據所有合併的價值，以正確的順序正確定義（在屬性重複的情況下，最後一個勝出）。

應用程式集：管理多個應用程式

正如我們之前多次提到的，您不應該處理單個應用程式。我們也可以將 Helm 階層與應用程式集結合使用。有許多方法可以切割和處理您的應用程式。以下範例僅展示 Helm 階層的可能組合。

單一維度的應用程式設定

以下是一個非常簡單的應用程式集，其中包括一個列表產生器（List Generator），用於建模單個應用程式的區域。

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-staging-appset
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    - list:
        elements:
          - region: us
          - region: eu
          - region: asia
  template:
    metadata:
      name: 'staging-{{.region}}'
    spec:
      project: default
      sources:
        - repoURL: https://github.com/kostis-codefresh/multi-sources-example.git
          path: my-chart
          targetRevision: HEAD
          helm:
            valueFiles:
              - $values/my-values/common-values.yaml
              - $values/my-values/app-version/staging-values.yaml
              - $values/my-values/env-type/non-prod-values.yaml
              - $values/my-values/regions/{{.region}}-values.yaml
              - $values/my-values/envs/staging-{{.region}}-values.yaml
        - repoURL: 'https://github.com/kostis-codefresh/multi-sources-example.git'
          targetRevision: HEAD
          ref: values
      destination:
        server: https://kubernetes.default.svc
        namespace: 'staging-{{.region}}'
      syncPolicy:
        syncOptions:
          - CreateNamespace=true
        automated:
          prune: true
          selfHeal: true

在此範例中，Helm 價值檔案的位置會根據應用程式的區域進行範本化。另一種選擇是使用列表產生器來取得應用程式、叢集或環境類別的列表。佈署此應用程式集會建立 3 個應用程式，每個區域一個。

再次強調，您可以輕鬆驗證每個佈署是否根據各自的 Helm 價值階層獲得適當的設定。

透過結合 Argo CD 和 Helm 價值階層，您可以有效地管理多個環境的應用程式佈署。Helm 價值階層提供了一種可重用的設定方式，而 Argo CD 應用程式集則可以自動化跨區域應用程式的佈署。這種方法不僅簡化了佈署流程，還確保了不同環境之間設定的一致性，從而提高了應用程式的可靠性和可維護性。透過 Argo CD 提供的集中管理介面，團隊可以更輕鬆地監控和管理應用程式的佈署狀態，快速識別和解決潛在問題，進而提升整體開發和維運效率。

利用 Argo CD ApplicationSet 實作多環境佈署自動化

在雲原生應用程式的生命週期管理中，多環境佈署是一個常見與重要的環節。有效的環境管理策略能夠提高開發效率、降低錯誤風險，並確保應用程式在不同階段（如開發、測試、生產）的穩定執行。Argo CD 作為一個流行的 GitOps 工具，其 ApplicationSet 功能為多環境佈署提供了強大的自動化能力。本文將探討如何使用 ApplicationSet，結合 Helm 圖表和 Git 檔案生成器，實作多環境設定的自動化管理。

ApplicationSet 簡介

ApplicationSet 是 Argo CD 的一個擴充套件控制器，它允許使用者根據範本和生成器自動建立和管理 Argo CD 應用程式。透過定義一個 ApplicationSet 資源，可以根據不同的生成器（如列表、叢集、Git）自動生成多個應用程式，每個應用程式對應一個特定的環境或設定。

使用列表生成器管理多環境

列表生成器（List Generator）是最簡單的 ApplicationSet 生成器之一。它允許使用者定義一個靜態的環境列表，並為每個環境生成一個應用程式。以下範例展示如何使用列表生成器管理多個環境的 Helm 圖表佈署：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-env-appset
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    - list:
        elements:
          - env: integration
            region: us-east-1
            type: non-prod
            version: qa
          - env: staging
            region: us-west-2
            type: non-prod
            version: staging
          - env: production
            region: eu-central-1
            type: prod
            version: prod
  template:
    metadata:
      name: '{{.env}}-app'
    spec:
      project: default
      sources:
        - repoURL: https://github.com/example/my-app.git
          path: charts/my-chart
          targetRevision: HEAD
          helm:
            valueFiles:
              - $values/values.yaml
              - $values/values-{{.env}}.yaml
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{.env}}'

在上述範例中，elements 列表定義了三個環境：integration、staging 和 production。ApplicationSet 將會為每個環境建立一個 Argo CD 應用程式，並根據範本中的定義，從 Git 倉函式庫 Helm 圖表進行佈署。valueFiles 欄位指定了不同環境的 Helm Values 檔案，實作了環境特定的設定管理。

結合 Helm 值層級實作精細設定

Helm 圖表允許使用分層的 Values 檔案，以實作更精細的設定管理。ApplicationSet 可以與 Helm 圖表的值層級結構結合使用，為每個環境提供定製化的設定。例如，可以根據應用程式版本、環境類別和地區等因素，定義不同的 Values 檔案：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-env-appset-helm
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    - list:
        elements:
          - env: integration
            gpuregion: us-east-1
            type: non-prod
            version: qa
          - env: staging
            gpuregion: us-west-2
            type: non-prod
            version: staging
          - env: production
            gpuregion: eu-central-1
            type: prod
            version: prod
  template:
    metadata:
      name: '{{.env}}-app'
    spec:
      project: default
      sources:
        - repoURL: https://github.com/example/my-app.git
          path: charts/my-chart
          targetRevision: HEAD
          helm:
            valueFiles:
              - $values/my-values/common-values.yaml
              - $values/my-values/app-version/{{.version}}-values.yaml
              - $values/my-values/env-type/{{.type}}-values.yaml
              - $values/my-values/regions/{{.gpuregion}}-values.yaml
              - $values/my-values/envs/{{.env}}-values.yaml
        - repoURL: 'https://github.com/example/my-app-config.git'
          targetRevision: HEAD
          ref: values
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{.env}}'

在上述範例中，Helm 的 valueFiles 欄位指向了多個不同的 Values 檔案，這些檔案根據環境變數（如 version、type、region 和 env）進行組織。這種方式可以將設定資訊分散到多個檔案中，提高可維護性和可讀性。

使用 Git 檔案生成器簡化設定

當環境數量增多時，直接在 ApplicationSet 資源中定義環境列表可能會變得冗長與難以管理。Git 檔案生成器（Git File Generator）允許從 Git 倉函式庫取環境設定資訊，從而簡化 ApplicationSet 的定義。以下範例展示如何使用 Git 檔案生成器：

在現代雲原生應用程式的佈署中，環境設定管理是一個複雜與至關重要的環節。Argo CD 作為一款流行的 GitOps 工具，提供了強大的應用程式佈署和管理能力。結合 Helm 的靈活性，我們可以更有效地管理不同環境的設定。本文將探討如何運用 Argo CD 的多重來源（Multi-Source）功能，以及 Helm 的值層級結構，來簡化和最佳化設定管理流程。

Argo CD 多重來源設定的核心概念

Argo CD 的多重來源功能允許我們從多個 Git 儲存函式庫地檔案夾中提取設定資訊，並將其整合到單一應用程式佈署中。這種方法特別適用於具有多個環境（例如：開發、測試、生產）的專案，每個環境可能需要不同的設定引數。

透過多重來源，我們可以將通用的設定資訊儲存在一個地方，而將特定於環境的設定儲存在其他地方。Argo CD 會自動將這些設定合併，以生成最終的應用程式設定。

Helm 值層級結構的應用

Helm 是一個 Kubernetes 的套件管理工具，它使用圖表的概念來定義、安裝和升級應用程式。Helm 圖表允許我們定義可設定的引數，這些引數可以透過值檔案（values.yaml）進行設定。

Helm 值層級結構指的是，我們可以定義多個值檔案，並按照一定的優先順序將它們合併。這使得我們可以輕鬆地管理不同環境的設定差異。例如，我們可以定義一個通用的 values.yaml 檔案，其中包含所有環境共用的設定，然後為每個環境定義一個特定的值檔案，其中包含該環境獨有的設定。

實作範例：多環境設定管理

假設我們有一個應用程式，需要在多個環境中佈署，包括 qa（測試環境）和 prod-us（美國生產環境）。每個環境可能需要不同的設定，例如：不同的圖表版本、不同的資源限制等。

為了實作這種設定管理，我們可以按照以下步驟進行設定：

定義通用的 Argo CD 應用程式集（ApplicationSet）： 應用程式集允許我們根據一定的規則自動生成多個 Argo CD 應用程式。在這個例子中，我們可以定義一個應用程式集，根據環境名稱自動生成對應的應用程式。

使用多重來源提取設定： 應用程式集可以設定為從多個 Git 儲存函式庫地檔案夾中提取設定資訊。在這個例子中，我們可以從一個 Git 儲存函式庫取通用的設定，然後從另一個 Git 儲存函式庫取特定於環境的設定。

以下是一個範例，展示如何使用多重來源設定：

project: default
sources:
  - repoURL: https://kostis-codefresh.github.io/multi-sources-example
    chart: my-chart
    targetRevision: '{{.chart}}'
    helm:
      valueFiles:
        - $values/my-values/common-values.yaml
        - $values/my-values/app-version/{{.version}}-values.yaml
        - $values/my-values/env-type/{{.type}}-values.yaml
        - $values/my-values/regions/{{.region}}-values.yaml
        - $values/my-values/envs/{{.env}}-values.yaml
  - repoURL: 'https://github.com/kostis-codefresh/multi-sources-example.git'
    targetRevision: HEAD
    ref: values
destination:
  server: https://kubernetes.default.svc
  namespace: '{{.env}}'

在這個例子中，我們定義了兩個來源：

第一個來源指向一個 Helm 圖表儲存函式庫中包含通用的圖表和值檔案。
第二個來源指向一個 Git 儲存函式庫中包含特定於環境的設定檔案。

我們使用 Helm 的 valueFiles 引數指定要使用的值檔案。這些值檔案可以包含對應環境的特定設定。

使用 Helm 值層級結構： 在 Helm 圖表中，我們可以定義多個值檔案，並按照一定的優先順序將它們合併。這使得我們可以輕鬆地管理不同環境的設定差異。
例如，我們可以定義一個通用的 common-values.yaml 檔案，其中包含所有環境共用的設定，然後為每個環境定義一個特定的值檔案，例如 qa-values.yaml 和 prod-us-values.yaml。
以下是一些範例設定：
prod-us/config.json：
```
{"env": "prod-us","region": "us","type": "prod","version": "prod","chart": "0.1.0"}
```
qa/config.json：
```
{"env": "qa","region": "us","type": "non-prod","version": "qa","chart": "0.2.0"}
```
透過這種方式，我們可以為每個環境定義不同的圖表版本。

實務情境範例

以下是一些實務情境範例，展示如何使用這種方法來管理設定：

情境 1： 一步驟啟動所有應用程式 -> 佈署應用程式集。
情境 2： 將新設定新增到所有歐洲佈署 -> 更改檔案 my-values/regions/eu-values.yaml。
情境 3： 對所有環境進行共同更改，除了生產環境 -> 更改檔案 my-values/env-type/non-prod-values.yaml。
情境 4： 在生產環境中更改圖表版本 -> 更改檔案 env-config/prod/us/config.json。
情境 5： 使 QA 環境繼承來自歐洲地區的設定，而不是美國 -> 更改檔案 env-config/qa/config.json。
情境 6： 建立一個名為負載測試的新環境，並使用與整合 (GPU) 相同的設定 -> 將資料夾 env-config/integration/gpu/ 複製到 env-config/load-testing，並相應地編輯 config.json 檔案。

簡化設定管理，從簡單開始

本文展示瞭如何將不同的設定與您的 Helm 圖表結合，以及如何利用 Helm 值層級結構來建模您的環境，而無需重複設定。透過正確使用 Argo CD 的多重來源功能，我們可以最小的努力涵蓋大多數情況。

建議將此結構作為您組織的起點。只有在業務需求真正需要的情況下，才新增複雜性。從簡單開始，逐步演進，才能更好地管理複雜的環境設定。

玄貓

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