Istio Gateway Helm Chart Volume Mount Path¶
概念概覽
雙路徑問題根因¶
核心知識¶
雙路徑問題根因¶
| 路徑 | 說明 | Repo |
|---|---|---|
trident-jenkins/helm/IstioGateway/ |
本地修改路徑 | trident-jenkins repo |
/aws/helm/IstioGateway/ |
腳本實際讀取路徑 | devops/helm.git（volume mount） |
3_3_installGateway.sh 腳本讀取的是 container 內 /aws/helm/IstioGateway，該路徑來自 devops/helm.git 的 volume mount。
症狀：本地修改了 values.yaml，但 helm template --dry-run 輸出仍顯示舊版本，令人困惑。
修改生效的兩種方式¶
# 方法一（推薦）：push 到正確 repo
git push devops/helm.git # 推送到 devops/helm.git 對應 repo
# 方法二（臨時）：直接 cp 進 container
docker cp values.yaml <container_id>:/aws/helm/IstioGateway/values.yaml
驗證步驟¶
修改後先用 dry-run 確認新設定出現，再正式執行：
# dry-run 確認
bash 3_3_installGateway.sh --dry-run | grep -A5 'valkeyServerlessRule'
# 確認出現後正式部署（實際案例：REVISION: 31, STATUS: deployed）
bash 3_3_installGateway.sh
經驗教訓¶
-
Jenkins 腳本中使用絕對路徑讀取 helm chart 時，必須先確認該路徑對應的 repo，而不是假設等同本地路徑
-
dry-run 顯示舊版本是排查路徑問題的關鍵線索，不是 helm cache 問題
常見陷阱¶
-
修改本地 helm chart 後直接執行腳本，結果使用的仍是 container 內舊版本，浪費排查時間
-
無獨立 Pipeline 的 IstioGateway 修改容易因手動流程遺漏 push 步驟
最佳實踐¶
-
每次修改 IstioGateway chart 後，dry-run 輸出中確認新設定存在再正式部署
-
建立 IstioGateway 修改 SOP，明確標注需要 push 到 devops/helm.git 的步驟
相關概念¶
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-04-08 | 4704b57e-d74e-48ab-811d-8bf398552c49 | 揭示 IstioGateway helm chart 本地路徑與 container 內路徑是兩個不同 repo，修改本地後 dry-run 仍顯示舊版本的根因 |