完整程式碼可在 GitHub 專案中找到：Finetune-30-days-demo / day-24

在前 20 天，我們已經逐步打造出一個能運作的微調平台，並透過 Docker Compose 與 Kubernetes Manifests 在不同環境中進行部署。然而，當系統逐漸擴展並需要同時支援 開發、測試、正式 等多個環境時，這些方式開始暴露出維護上的困難：每個環境都需要維護不同的 YAML，參數散落在各處，Pod、Service、ConfigMap、Secret 等資源也缺乏集中化的管理。

Helm 的價值就在於解決這些問題。它能將一整組 Kubernetes 資源 打包成 Chart，透過 values.yaml 統一管理差異化參數，並提供升級、回滾與模板化等功能。這讓部署從「零散的 YAML 集合」進化為「可維護、可擴展的套件化方案」，大幅降低跨環境維護與擴展的成本。

一、Compose / K8s / Helm 的定位與演進

這三者不是互斥，而是演進路徑：
本地驗證（Compose） → 叢集落地（K8s YAML） → 生產管理（Helm Chart）。

二、Helm 重構的實作

1. 模組化 Manifests

將原本的 K8s YAML（API、Worker、Redis、UI）模組化，抽出成 templates。
共用參數（端口、映像檔 tag、資源配置）統一放進 values.yaml。

2. Helm Chart 結構

charts/finetune-platform/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── api-deployment.yaml
    ├── worker-deployment.yaml
    ├── redis-statefulset.yaml
    ├── ui-deployment.yaml
    ├── secret.yaml
    ├── service.yaml
    └── _helpers.tpl

其中 _helpers.tpl 是 Helm Chart 的模板工具檔，通常用來集中管理命名規則或常用片段（例如 fullname、labels、annotations），避免多個檔案重複寫相同邏輯。這樣不僅能保持 命名一致性，也能讓 Chart 更容易維護與擴展。

3. values.yaml 與多環境設定

values.yaml 定義的是平台的預設配置，通常用於本地開發或一般部署。但在實際情境下，不同環境（dev/test/prod）往往需要不同參數，例如：

• replicas：開發環境可能只要 1 個副本，正式環境需要 3–5 個以確保高可用。
• resources：正式環境需要更嚴格的 CPU/記憶體限制。
• secrets：不同環境的憑證與金鑰會有差異。

因此，我另外維護了 values.prod.yaml，用來覆蓋正式環境所需的設定。

# 本地開發
helm install finetune charts/finetune-platform -f values.yaml

# 部署正式環境
helm install finetune charts/finetune-platform -f values.yaml -f values.prod.yaml

同時，Helm 也提供升級與回收機制，搭配不同環境設定檔非常靈活：

# 升級正式環境
helm upgrade finetune charts/finetune-platform -f values.prod.yaml

# 回收資源
helm uninstall finetune

這樣的分層與策略，讓 values.yaml 保持簡潔（只放通用配置），而環境專屬的調整則集中在 values.*.yaml 中，搭配 helm upgrade/uninstall，能快速切換或回收環境。

三、敏感資訊管理

在這次重構中，我也把 JWT_SECRET 移出程式碼，交由 Helm + Kubernetes Secret 管理。
只需在 values.yaml 定義 Secret 名稱與值，Helm 會自動生成 Secret，並在 Deployment 中注入到容器的環境變數。

這樣的做法有三個好處：

• 集中管理：所有 Secret 設定都集中在 values.yaml。
• 安全性：敏感資訊不再出現在程式碼或 Deployment。
• 跨環境靈活性：不同環境可使用不同的 values.*.yaml 來覆蓋設定。

透過這次的重構，我們讓部署方式從「零散的 YAML 集合」進化為 Helm Chart 套件化管理。不論是開發、測試還是正式環境，都能透過 values.yaml + values.*.yaml 的分層方式輕鬆切換，並且在升級或回收時享受 Helm 的便利。

更重要的是，這樣的部署策略不只是「能跑起來」，而是建立了一套 可維護、可擴展、可管理 的基礎。未來當平台逐步走向 CI/CD、自動化與多租戶場景時，Helm 會是我們在雲端環境中保持秩序與彈性的關鍵工具。

📎 AI 協作記錄：今日開發指令

請幫我針對專案新增 Helm Chart，具體修改如下：

1. 建立最小 Helm Chart：
   - 新增目錄 `charts/finetune-platform/`
   - 在 `templates/` 下新增以下檔案：
     - `deployment-api.yaml`
     - `deployment-worker.yaml`
     - `deployment-redis.yaml`
     - `deployment-ui.yaml`
     - `service.yaml`
   - values.yaml 需包含以下參數：
     - image.repository / image.tag
     - replicas
     - service.port
     - resources (cpu/memory)

2. 修改 K8s 舊有部署檔案：
   - 移除 `k8s/*.yaml` 中硬編碼的 replica、port
   - 改為引用 Helm Chart values

請保留原本的 Docker Compose 與 k8s/ 檔案，確保使用者仍可選擇不同方式部署。