近期，廣受開發者與維運團隊喜愛的容器管理平台 Portainer 正式推出了 2.39 LTS (長期支援版)。這次版本收斂了過去幾個月 STS (短期支援版) 迭代的精華，不只帶來穩定性的提升，更在規模化治理與 GitOps 整合上祭出一些新功能。同時，面對市場上容器底層引擎的快速更迭，社群中也浮現了一些值得關注的技術 Issue。
聚焦合規、自動化與 Observability
在這次 2.39 LTS 的更新中，CyberQ 實際部署後，我們可以看到 Portainer 越來越重視大規模部署下的防護與自動化能力，以下是幾個關鍵重點：
艦隊治理策略 (Fleet Governance Policies)的跨叢集合規
隨著企業管理的叢集數量攀升，設定的碎片化往往是資安與維運的夢魘。2.39 引進了 Fleet Governance Policies，讓管理者能統一定義安全、存取與配置標準。這些策略不僅會自動強制套用至現有及新加入的叢集，還具備自動修正設定 drift 的能力，這對於落實嚴謹的資安合規來說還算不錯。
共享 Git 憑證與部署強化
針對 GitOps 工作流，新版推出了共享 Git 憑證功能。管理員可統一設定憑證，讓團隊在部署時重複調用，卻不會暴露底層機密 (Secrets)，大幅降低憑證外洩風險。此外，Edge Stacks 新增了 Always clon e選項，確保每次部署都與 Git 來源保持絕對同步，Helm 部署現在也支援從 Git 直接拉取，並提供 Manifest 預覽功能，讓你在部署前就能精準掌握 K8s 資源變更。
告警系統 (Alerting) 正式 GA
過去以實驗性質提供的 Alerting 功能，終於在 2.39 版本正式 GA (一般可用)。管理者可以直接在 Observability 介面中，針對環境離線、備份失敗或高資源佔用等異常狀況設定告警，補足了原生監控的最後一哩路。
UI 體驗與 Kubernetes 管理最佳化
延續從 Angular 轉換至 React 的工程，Registry 管理介面獲得了全面重構，標籤 (Tags) 的管理變得更加快速直覺。在 K8s 支援上，現在可直接從 Portainer UI 檢查 CRD 與自訂資源，並新增了節點 YAML 的直接編輯能力，免去了頻繁切換終端機工具的麻煩。
最新 Issue 探討
儘管 2.39 LTS 帶來許多企業級亮點，但在近期的 GitHub 社群與市場實務操作中，仍有幾個與底層環境相容的災情值得維運工程師留意：
升級導致的 Stack 權限受限 (Limited) 狀態
有用戶回報在進行版本升級時，若 Docker Compose 的 Volume 映射路徑有誤，或資料目錄 (portainer_data) 遺失，會導致原本建立的 Stacks 被標記為 “Limited”，進而無法在 UI 上進行編輯、更新或刪除。這再次凸顯了更新前務必備份 Portainer Database 的重要性。
Podman 支援的侷限性
對於逐漸擁抱 Podman 的架構，官方在近期的 Release Notes 裡有特別註明，目前的支援仍處於特定條件下（如僅支援 CentOS 9 與 Podman 5 Rootful 環境），並且無法透過 Auto-onboarding 腳本直接匯入 Podman 環境，若有混用環境的團隊需特別留意。
結語與升級建議
綜合來看，Portainer 2.39 LTS 成功將產品定位往企業需求的集中管控與資安合規繼續前進，特別是 Fleet Governance 與 Shared Git Credentials 的加入，能有效解決大規模環境下的權限管控 issue。
CyberQ 實務建議，如果你正苦於分散式叢集的配置管理與機密憑證安全，2.39 LTS 可以測試後來投入升級，但若你目前的 Portainer 環境執行穩定，且沒有跨叢集治理的急迫需求，強烈建議先在 Staging (測試環境) 進行 2.39 LTS 的相容性測試，特別是確認你的 Docker/Kubernetes 底層版本是否會踩到 API 驗證的雷區，再推行至正式 Production 環境。
