Helm 自動化佈署：CI/CD 與 GitOps 實踐

現代軟體開發講求速度與穩定性，因此 CI/CD 與 GitOps 成為不可或缺的技術。本文將逐步說明如何運用 Jenkins 建立 CI Pipeline，自動化 Helm Chart 的建置、測試與發布流程，並結合 ArgoCD 實作 GitOps 理念，讓 Kubernetes 組態管理更有效率。首先，我們會設定本地 Minikube 環境，包含建立新的名稱空間和準備程式碼倉函式庫。接著，我們會建構一個 Jenkins Pipeline，自動執行 Helm Chart 的封裝、測試與推播到儲存函式庫等步驟。最後，我們會介紹 ArgoCD 的使用方法，示範如何將 Git 倉函式庫中的 Helm Chart 同步到 Kubernetes 叢集，達成 GitOps 的目標。透過這些技術的整合，我們可以確保每次程式碼變更都能快速且可靠地佈署到 Kubernetes 叢集中，同時保持組態的一致性和可追溯性。

清理資源：

當您完成所有操作並確認不再需要所建立資源時您必須進行清理操作, 下列命令可幫助您完成清理操作:

helm uninstall myrelease --namespace default;
kubectl delete namespace default;
minikube delete;

問答題目：

helm template指令目的？與 helm lint指令有何不同？
您能如何在安裝之前驗證您的圖表範本？
哪個工具可利用以檢查您YAML資源風格？
您如何建立圖表測試？圖表測試又該如何執行？
ct 工具相較於Helm內建測試功能帶來哪些額外價值？
ci/資料夾當與ct工具使用時其目的是什麼？
–upgrade旗標對於ct lint-and-install指令有什麼改變？

自動化 Helm 流程：CI/CD 與 GitOps

在現代軟體開發中，持續整合（CI）與持續交付（CD）已成為標準做法。這些工具不僅能提供即時通知，讓開發者能夠及時解決問題，還能夠自動化許多手動流程，提升效率與可靠性。GitOps 進一步將這些概念推廣到 Kubernetes 環境中，提供更高效的組態管理方式。

CI 與 CD 的核心概念

CI 的核心特點是能夠在程式碼變更後立即執行測試與整合，並通知相關人員。這樣可以確保問題在早期階段被發現並解決，避免在後期開發過程中出現重大問題。CD 則是將 CI 的概念擴充套件到整個軟體交付生命週期，透過定義的Pipeline步驟自動化佈署與釋出過程。

GitOps：下一代 CI/CD

GitOps 是一種利用 Git 作為唯一真實來源來管理 Kubernetes 組態的方法。它的核心概念是將 Kubernetes 的組態檔案（manifests）儲存在 Git 倉函式庫中，並使用 GitOps 工具來自動同步 Git 中的組態到 Kubernetes 叢集中。這樣可以確保叢集狀態與 Git 中的組態一致，並且所有變更都可以透過 Git 歷史追蹤。

設定環境

首先，我們需要設定本地環境來進行實驗。以下是具體步驟：

刪除並重新建立 Minikube 叢集：

minikube delete
minikube start --memory=4g

建立新的 Kubernetes 名稱空間：
```
kubectl create namespace chapter7
```
建立 Packt 資料函式庫的 Fork：
- 將 Fork 的資料函式庫克隆到本地：
```
git clone https://github.com/$GITHUB_USERNAME/Learn-Helm.git
```

刪除本地 Helm 資料函式庫中的 Guestbook Chart：

進入本地 Helm 資料函式庫：
```
cd $LEARN_HELM_CHART_REPOSITORY_DIR
ls
```

刪除 guestbook-1.0.0.tgz 和 index.yaml 檔案：

rm guestbook-1.0.0.tgz index.yaml
git add --all
git commit -m 'Preparing for chapter 7'
git push origin master

建立 CI Pipeline

接下來，我們將學習如何建立一個 CI pipeline 來釋出 Helm Chart。這個 pipeline 會自動化測試與佈署過程，確保每次變更都能夠迅速且可靠地交付。

pipeline {
    agent any

    stages {
        stage('Clone Repository') {
            steps {
                git 'https://github.com/$GITHUB_USERNAME/Learn-Helm.git'
            }
        }

        stage('Build Chart') {
            steps {
                sh 'helm package ./charts/mychart'
            }
        }

        stage('Test Chart') {
            steps {
                sh 'helm lint ./charts/mychart'
            }
        }

        stage('Push to Repository') {
            steps {
                sh '''
                curl -u $HELM_REPO_USER:$HELM_REPO_PASSWORD \
                     --data-binary "@mychart-0.1.0.tgz" \
                     https://$HELM_REPO_URL/charts/
                '''
            }
        }
    }
}

內容解密：

Clone Repository：使用 Git 命令從指定的 URL 克隆資料函式庫。
Build Chart：使用 Helm 命令封裝指定的 Chart。
Test Chart：使用 Helm 命令對 Chart 進行語法檢查。
Push to Repository：使用 cURL 命令將封裝好的 Chart 推播到遠端倉函式庫。

GitOps 工具

GitOps 工具如 ArgoCD 和 Flux 可以用來監控 Kubernetes 叢集狀態，並根據 Git 中的組態進行自動化同步。這些工具利用 Kubernetes 的控制器模式來觀察叢集狀態，並在需要時應用組態變更。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mychart-app
spec:
  project: default
  source:
    repoURL: 'https://github.com/$GITHUB_USERNAME/Learn-Helm.git'
    targetRevision: HEAD
    path: charts/mychart
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: chapter7

內容解密：

apiVersion 和 kind：定義 ArgoCD 應用的 API 型別和種類別。
metadata：應用的後設資料，包括名稱。
spec：應用的規格，
- project：應用所屬的專案。
- source：資料來源，包括資料函式庫 URL、分支和路徑。
- destination：佈署目的地，包括 Kubernetes API Server 和名稱空間。

結語

透過結合 CI/CD 和 GitOps，我們可以實作更高效、更可靠的軟體交付與組態管理。這些工具和方法不僅適用於 Kubernetes 環境，也可以應用於其他雲原生技術中。希望這篇文章能夠幫助你理解並掌握這些技術，提升你的開發效率和系統穩定性。

自動化 Helm 流程使用 CI/CD 和 GitOps

利用 CI/CD 建立 Helm charts 的管線

CI（持續整合）的概念可以應用於 Helm chart 開發者的角度，這些開發者會建立、測試、封裝及釋出 Helm charts 到 chart 儲存函式庫。在本文中，玄貓將描述使用端對端 CI 管線來簡化此流程的可能性，並帶領讀者建立範例管線。首先，我們需要設計範例管線所需的元件。

設計管線

在前幾章中，開發 Helm charts 幾乎是手動的過程。雖然 Helm 提供了自動化測試鉤子的功能，但使用 helm lint、helm test 或 ct lint-and-install 命令來確保測試透過仍然需要手動執行。一旦 lint 和測試在程式碼變更後持續透過，便可以使用 helm package 命令來封裝 chart。如果 chart 是使用 GitHub Pages 儲存函式庫提供（如第 5 章所建立的那個），則可以透過執行 helm repo index 命令來建立 index.yaml 檔案，並將 index.yaml 檔案與封裝後的 chart 推播到 GitHub 儲存函式庫。

雖然手動執行每個命令是可行的，但隨著開發更多的 Helm charts 或新增更多貢獻者，這種工作流程會變得越來越難以維持。手動工作流程很容易允許未經測試的變更被應用到 chart 上，並且難以確保貢獻者遵循測試和貢獻準則。幸運的是，這些問題可以透過建立自動化釋出流程的 CI 管線來避免。

以下步驟概述了使用本文至今所討論的命令和工具建立範例 CI 工作流程。它假設結果 charts 被儲存在 GitHub Pages 儲存函式庫：

Chart 開發者對 git monorepo 中的 chart 或一組 charts 做出程式碼變更。
開發者將變更推播到遠端儲存函式庫。
被修改的 charts 會自動在 Kubernetes 名稱空間中進行 lint 和測試，這是透過執行 ct lint 和 ct install 命令來完成的。
如果 lint 和測試成功，則會自動使用 helm package 命令封裝 charts。
自動使用 helm repo index 命令生成 index.yaml 檔案。
封裝後的 charts 和更新後的 index.yaml 檔案會自動推播到儲存函式庫。根據工作執行所針對分支推播到 stable 或 staging。

在下一節中，玄貓將使用 Jenkins 執行此流程。讓我們從瞭解 Jenkins 是什麼以及它如何運作開始。

Jenkins 的理解

Jenkins 是一個用於執行自動化任務和工作流程的開源伺服器。它通常用於透過 Jenkins 的程式碼管線功能建立 CI/CD 管線，該功能在名為 Jenkinsfile 的檔案中定義了一個 Jenkins 管線。

Jenkins 管線是使用 Groovy Domain-Specific Language (DSL) 編寫的。Groovy 是一種類別似於 Java 的語言，但與 Java 不同的是，它可以作為導向物件的指令碼語言使用，這使得它非常適合編寫易於閱讀的自動化指令碼。在本章中，玄貓將帶領讀者瞭解兩個已經為您準備好的現有 Jenkinsfile 檔案。您不需要有任何從頭編寫 Jenkinsfile 檔案的經驗，因為探討 Jenkins 的內容超出了本文的範圍。然而，到了本章結束時，您應該能夠將學到的概念應用於您選擇的自動化工具。雖然本章以 Jenkins 作為主題，但其概念可以應用於任何其他自動化工具。

當建立一個 Jenkinsfile 檔案時，定義工作流程步驟會在 Jenkins 伺服器上或在專門委派執行工作的單獨代理上執行。可以透過自動安排 Jenkins 代理作為單獨 Pod 在每次啟動構建時來簡化代理建立和管理。當代理完成時，它可以組態為自動終止，以便下一次構建可以在乾淨、新鮮的 Pod 中執行。在本章中，我們將使用 Jenkins 代理執行範例管線。

Jenkins 也非常適合 GitOps 的概念，因為它提供了掃描原始碼控制儲存函式庫以檢查 Jenkinsfile 檔案存在與否的能力。對於每個包含 Jenkinsfile 檔案的分支都會自動組態一個新工作，該工作將開始克隆目標分支上的儲存函式庫。這使得測試新功能和修補程式變得簡單，因為新作業可以與其相應分支一起自動建立。

安裝 Jenkins

與許多常見佈署在 Kubernetes 上的應用程式一樣，Jenkins 可以使用來自 Helm Hub 的多種社群 Helm chart 安裝之一來佈署。在此章節中，玄貓將使用 Codecentric 軟體開發公司提供的 Jenkins Helm chart：

$ helm repo add codecentric https://codecentric.github.io/helm-charts

除了預期 Kubernetes 相關值（如組態資源限制和服務型別）外，codecentric Jenkins Helm chart 包含其他與 Jenkins 相關值以自動組態不同元件。

由於組態這些值需要對 Jenkins 有更深入瞭解超出本文範圍之外的一些部分，因此提供了一個 values 檔案供您使用它來自動準備以下 Jenkins 組態：

新增不包括在基礎映像中的相關外掛。
組態與 GitHub 驗證所需憑證。
組態專門設計用於測試和安裝 Helm charts 的 Jenkins 代理。
組態當檢測到 Jenkinsfile 檔案時自動建立新工作。
跳過新安裝啟動時通常發生的手動提示。
則停用身份驗證以簡化此章節中的 Jenkins 資訊。

values 檔案還會組態以下 Kubernetes 相關詳細資訊：

在 Jenkins 處理伺服器上設定資源限制。
將 Jenkins 支援型別設定為 NodePort。
建立代表 Jenkins 和 Jenkins 代理需要執行作業和佈署 Helm charts 的 ServiceAccounts 和 RBAC 原則在 Kubernetes環境中。
組態大小為2GiB之Jenkins PersistentVolumeClaim

玄貓 BlackCat

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