Helm 作為 Kubernetes 的套件管理工具，簡化了應用程式的佈署和管理流程。要確保 Helm Charts 的穩定性，測試至關重要。首先，需確認已安裝 Helm 和 kubectl 等必要工具，並準備好測試環境，例如 Minikube 或 Kubernetes 叢集。接著，可以透過 helm lint 指令進行 Chart 的語法和結構驗證，並使用 helm template 指令將 Chart 渲染成 Kubernetes 資源清單，以便進行本地測試和檢查。除了本地測試，更重要的是在實際環境中進行測試，可以使用 helm install 指令將 Chart 佈署到 Kubernetes 叢集中，並透過 helm test 或其他測試工具驗證應用程式的功能和效能。為了實作自動化，可以將 Helm 整合到 CI/CD 流程中，例如使用 GitHub Actions 或 Jenkins 等工具，在每次程式碼變更時自動觸發 Chart 的構建、測試和佈署。透過 CI/CD 管線，可以確保 Chart 的品質，並加速應用程式的交付速度。更進一步，可以結合 GitOps 的概念，將 Chart 的版本控制和佈署流程與 Git 儲存函式庫連結，實作基礎設施即程式碼的管理模式。
Helm Charts 環境測試
Helm 是 Kubernetes 的包管理工具，利用 Helm Charts 可以方便地佈署和管理應用。在這裡，玄貓將帶領大家深入瞭解如何測試 Helm Charts，確保其穩定性和可靠性。
應用場景與準備工作
在開始測試之前，我們需要確保所有必要的工具已經安裝並組態好。以下是基本步驟：
- 安裝 Helm：如果還沒有安裝 Helm，可以參考 Helm 安裝 進行安裝。
執行測試命令
我們將使用 chart-testing 工具來測試 Helm Charts。這個工具提供了多種組態選項，詳細內容可以參考 chart-testing 檔案。
執行 lint-and-install 命令
首先，我們需要執行 ct lint-and-install 命令來測試 Helm Charts。這個命令會對指定的 Charts 進行語法檢查和安裝測試。
$ cd $LEARN_HELM_LOCATION
$ ls
ct.yaml guestbook-operator helm-charts jenkins LICENSE nginx-cd README.md
在這個目錄下，我們可以看到 ct.yaml 檔案，它定義了 Chart 的位置。接下來，執行以下命令：
$ ct lint-and-install
如果 Chart 未修改過，則不會執行任何操作。我們需要對其中一個 Chart 進行修改來觀察測試過程。
修改 Chart 並重新測試
為了觀察 lint-and-install 的完整流程，我們需要對 Chart 進行一些修改。首先，建立一個新的分支來進行修改：
$ git checkout -b chart-testing-example
然後，修改 Learn-Helm/helm-charts/charts/guestbook/Chart.yaml 和 Learn-Helm/helm-charts/charts/nginx/Chart.yaml 的描述欄位：
description: 用於佈署 Guestbook 應用
description: 在 Kubernetes 上佈署 NGINX 例項
驗證修改後，再次執行 lint-and-install 命令：
$ ct lint-and-install
這次會檢測到兩個 Chart 的變動並進行相應的操作。由於版本號未更新，這次測試可能會失敗。
調整版本號並重新測試
為了讓測試透過，我們需要更新兩個 Chart 的版本號。在 Chart.yaml 中將版本號調整為 1.0.1：
version: 1.0.1
驗證修改後，再次執行 lint-and-install 命令：
$ ct lint-and-install
這次會完成完整的 Chart 測試流程，包括語法檢查、佈署和測試。
清理環境
完成所有測試後，我們需要清理環境。刪除名稱空間並停止 Minikube 叢集：
$ kubectl delete ns chapter6
$ minikube stop
測試 Helm Charts
在本章，我們探討了測試 Helm Charts 的各種方法。最基本的測試方式是使用 helm template 指令，對本地 Chart 目錄進行渲染，以確認其資源是否正確生成。此外，還可以使用 helm lint 指令來確保 Chart 格式正確，並使用 yamllint 指令來檢查 YAML 風格。除了本地渲染和檢查，還可以在 Kubernetes 環境中進行實際測試，使用 helm test 指令和 ct 工具。此外，Chart 測試還提供了便於在單一儲存函式庫中維護 Helm Charts 的功能。
在下一章中，我們將探討如何在持續整合/持續交付（CI/CD）和 GitOps 環境中使用 Helm，從 Chart 開發者的角度來看，這些開發者負責構建和測試 Helm Charts，以及從終端使用者的角度來看，這些使用者使用 Helm 來將應用程式佈署到 Kubernetes。
深入技術細節
本地渲染與檢查
本地渲染是測試 Chart 的基本方法之一。透過 helm template 指令，我們可以將 Chart 渲染為 Kubernetes 資源清單檔案。這樣可以確保所有範本都正確生成，並且符合 Kubernetes API 的要求。
# values.yaml
replicaCount: 2
image:
repository: nginx
tag: latest
helm template mychart .
上述命令會將 mychart 渲染為 Kubernetes 資源清單檔案，並輸出到終端機。這樣我們可以手動檢查生成的資源是否符合預期。
驗證 Chart 範本
除了本地渲染，我們還可以使用 helm lint 和 yamllint 指令來驗證 Chart 範本。
helm lint mychart
helm lint 指令會檢查 Chart 的結構和格式是否正確。例如，它會檢查 Chart.yaml 中是否包含必需的欄位、範本檔案是否存在等。
而 yamllint 則專注於 YAML 風格的檢查。例如，它會檢查縮排是否一致、是否有多餘的空行等。
yamllint mychart/templates/
實際環境測試
除了本地渲染和檢查，我們還可以在實際 Kubernetes 環境中進行測試。這樣可以確保 Chart 在真實環境中的執行情況。
helm test myrelease
helm test 指令會執行 Chart 中定義的測試案例。這些測試案例可以是 Pod 的健康狀態檢查、服務的可存取性檢查等。
此外，我們還可以使用 ct 工具來進行更複雜的測試。這個工具提供了更多的功能，例如自動化測試、多環境測試等。
ct install --chart-dir mychart --config ct.yaml
上述命令會根據 ct.yaml 組態檔案中的設定來安裝和測試 mychart。這樣我們可以在不同的 Kubernetes 環境中進行一致性測試。
CI/CD 和 GitOps
CI/CD 和 GitOps 是現代軟體開發中的兩個重要概念。CI/CD 是指持續整合和持續交付，而 GitOps 則是根據 Git 的維運方式。
CI/CD
CI/CD 的目的是透過自動化來提高軟體開發的效率和品質。它包含了以下幾個步驟：
- 持續整合（CI）：每次程式碼變更時，自動觸發構建和測試流程。
- 持續交付（CD）：透過自動化佈署流程來將變更佈署到生產環境。
GitOps
GitOps 是一種根據 Git 的維運方式。它的核心思想是所有的基礎設施組態和應用程式組態都儲存在 Git 儲存函式庫中。這樣可以透過版本控制來管理組態變更，並且透過自動化來佈署這些變更。
自動化 Helm 流程
在現代軟體開發中，自動化是不可或缺的一部分。透過 CI/CD 和 GitOps 來自動化 Helm 流程，可以大大提高開發效率和應用程式的穩定性。
建立 CI Pipeline
CI Pipeline 用於自動化構建和測試流程。以下是一個簡單的 CI Pipeline 的範例：
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Helm
uses: azure/setup-helm@v1
- name: Lint chart
run: helm lint mychart
- name: Template chart
run: helm template mychart .
上述組態檔案定義了一個 CI Pipeline，每次推播或提取請求時都會觸發構建和測試流程。首先簽出程式碼、設定 Helm、然後進行 Lint 和範本渲染。
建立 CD Pipeline
CD Pipeline 用於自動化佈署流程。以下是一個簡單的 CD Pipeline 的範例：
# .github/workflows/cd.yml
name: CD
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Helm
uses: azure/setup-helm@v1
- name: Deploy to Kubernetes
run: |
helm upgrade --install myrelease mychart --namespace default --create-namespace --wait
上述組態檔案定義了一個 CD Pipeline，每次推播到主分支時都會觸發佈署流程。首先簽出程式碼、設定 Helm、然後進行佈署操作。
高階佈署模式
接下來我們將探討一些高階的應用管理概念與可能性。
自動化 Helm 流程使用 CI/CD 和 GitOps
在前面幾章中，我們探討瞭如何作為終端使用者使用 Helm 作為包管理工具來佈署各種複雜度的應用程式到 Kubernetes 上；也探討瞭如何作為 Chart 開發者開發和測試 Helm Charts, 包括如何將 Kubernetes 的複雜性封裝到 Helm Charts 中以及如何對 Charts 進行測試以確保所需功能被成功交付給終端使用者。
然而以上兩種過程涉及呼叫各種不同的 Helm CLI 命令來完成各自任務，儘管這些命令列操作非常有效地完成其預期任務, 需要從命令列手動呼叫這些命令作為痛點：當管理多個不同的charts或者應用時非常不方便, 對於大型企業來說很難擴充套件,因此我們需要尋求替代方案來在現有Helm基礎上提供額外自動化, 在本章中我們將調查與持續整合（Continuous Integration）和持續交付（Continuous Delivery）（CI/CD）以及GitOps相關概念,這些方法論可透過Helm CLI及其他命令來實作與Git儲存函式庫內容相關的自動化工作流程來實作對應用程式的自動佈署以及Helm Charts構建、測試、封裝等Chart開發生命週期工作流程.
自動化Hlem流程涉及主題如下：
- 理解CI/CD與GitOps。
- 組態我們環境。
- 建立CI管線以封裝Helm Charts。
- 建立CD管線以便使用Helm進行應用佈署。
- 清理資源.
技術需求：
- Minikube.
- Helm.
- kubectl.
- Git.
理解CI/CD與GitOps:
至今為止, 我們已經涵蓋了許多與Helm開發密切相關的關鍵概念：構建、測試和佈署；然而之前所做探索僅限於對Helm CLI進行手動組態及呼叫：這對於剛開始接觸Helm可能還比較好處理,但當我們希望將一個Chart移動到類別似生產環境時需要考慮一些問題：
- 如何確保圖表開發及佈署最佳實踐被遵循?
- 有什麼其他人的協作者參與圖表開發及佈署過程所帶來影響?
這兩個問題是適用於任何軟體專案而不僅僅只是Helm圖表開發：雖然我們已經涵蓋了很多最佳實踐；但是當引入新協作者時可能並不會同樣瞭解這些主題或具有執行這些關鍵步驟所需紀律；因此透過引入自動化及重複性過程來解決這些挑戰已被確立：例如CI/CD便已被確立以解決一些這些挑戰.
CI：
CI作為一種建立過程：每當軟體發生變更時需要有一個可遵循過程來確保最佳實踐得以遵循：它不僅確保最佳實踐得以遵循還幫助消除許多開發人員常遇到問題：例如經常遇到"在我機器上執行沒問題"這樣的問題：之前討論過我們經常會使用版本控制系統(例如git)來儲存原始碼；但是經常每個開發者會有自己獨立副本原始碼；隨著增加更多貢獻者後很難管理程式碼函式庫.
正確啟用CI需透過引入一個自動化工具：它會每當發生變更時提取原始碼並進行預定步驟；隨著人們對這種工作方式認同度越來越高帶來需求為這類別工具提供專門設計軟體解決方案：例如Jenkins、TeamCity以及Bamboo等以及各種SaaS基礎解決方案；透過把任務責任交給第三方元件讓開發人員更願意頻繁提交程式碼並讓專案經理對團隊技能及產品穩健度信心增加.
Plantuml圖示：
此圖示展示了 CI/CD 流程中的主要步驟。從版本控制開始，透過自動化工具進行構建和測試，最後進行佈署。
CD：
CD作為持續交付過程：對於軟體變更希望能夠快速穩定交付；這種方法論帶來其特別有效果形式為實作快速穩定交付所需必要步驟稱為“藍綠”或者“金絲雀”等等；
Plantuml圖示：
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title Helm Charts 環境建置與測試實務
package "Kubernetes Cluster" {
package "Control Plane" {
component [API Server] as api
component [Controller Manager] as cm
component [Scheduler] as sched
database [etcd] as etcd
}
package "Worker Nodes" {
component [Kubelet] as kubelet
component [Kube-proxy] as proxy
package "Pods" {
component [Container 1] as c1
component [Container 2] as c2
}
}
}
api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2
note right of api
核心 API 入口
所有操作經由此處
end note
@enduml此圖示展示了 CD 流程中的主要步驟。從開發開始，經過測試和映象環境後進入生產環境並進行監控。
