昨天我們建立了企業級的私有映像檔倉庫 Harbor，解決了容器映像檔的集中存儲、權限管理和安全掃描等問題。有了 Harbor，我們可以安全地管理所有應用的映像檔，控制誰可以推送或拉取，追蹤映像檔的使用情況，甚至自動掃描漏洞。
想像一個典型的開發場景：開發者寫完程式碼，推送到 Git 倉庫，然後要手動打包、測試、構建 Docker 映像檔、推送到 Harbor、更新 Kubernetes 的 Deployment。每次程式碼變更都要重複這些步驟，不僅耗時，還容易出錯。如果一天有多個部署要執行呢？如果有十個微服務需要部署呢？這種手動流程很快就會成為開發效率的瓶頸。
這就是 CI/CD（持續整合/持續交付/持續部署） 要解決的問題。今天我們要來看看 Jenkins，就是 CI/CD 領域最經典也最強大的工具之一。它能夠自動化整個交付流程：從程式碼提交到測試、構建、部署，全程無需人工介入。配合 GitLab、Harbor 和 Kubernetes，我們將打造一條完整的自動化交付流水線。
在深入 Jenkins 之前，我們需要理解 CI/CD 的核心概念。CI/CD 是 DevOps 實踐的基礎，它透過自動化來加速軟體交付，同時提高品質和穩定性。
持續整合的核心思想是：開發者頻繁地將程式碼整合到主分支，每次整合都透過自動化構建和測試來驗證。這個概念最早由極限編程（Extreme Programming）提出，目的是解決傳統開發中的「整合地獄」問題。
在傳統的開發模式中，多個開發者各自開發功能，可能幾週甚至幾個月才整合一次。整合時會發現大量衝突和問題，解決這些問題可能需要花費數天甚至數週。持續整合的做法是每次整合都運行自動化測試。這樣問題會在早期被發現，修復成本很低。
一個典型的 CI 流程包括：開發者提交程式碼到版本控制系統、CI 系統自動檢測到變更、自動執行構建（編譯程式碼、打包）、自動執行測試（單元測試、整合測試）、如果失敗立即通知開發者。整個過程通常在幾分鐘內完成，讓開發者能快速得到反饋。
持續交付在持續整合的基礎上更進一步，確保軟體隨時處於可發布狀態。它的目標是讓構建、測試、發布的過程變得快速且頻繁，降低軟體發布的風險。
持續交付的核心是自動化部署管道（Pipeline）。程式碼經過 CI 階段後，會自動部署到測試環境、預發布環境，經過各種自動化測試和人工驗收。雖然最終的生產部署可能還需要人工審批，但整個過程都是自動化的，隨時可以一鍵發布到生產環境。
持續交付強調的是「隨時可發布」，而不是「隨時都發布」。團隊可以根據業務需求決定何時發布，但技術上隨時都能發布。這種能力讓團隊能夠快速響應市場變化，快速修復問題。
在持續部署中，每次程式碼變更通過所有測試後，會自動部署到生產環境，完全不需要人工干預。這聽起來很激進，但對於成熟的團隊來說，這是最高效的方式。
持續部署需要極高的自動化測試覆蓋率和監控能力。因為每次提交都會自動上線，測試必須足夠完善，能夠捕捉絕大多數問題。同時需要完善的監控和告警系統，一旦發現問題能立即回滾。還需要一些部署策略，比如金絲雀發布、藍綠部署等，來降低發布風險。
很多人會混淆持續交付和持續部署，關鍵區別在於：持續交付需要人工決定何時發布到生產，持續部署則是完全自動化。選擇哪種方式取決於團隊的成熟度和實際業務需求。
DevOps 是一種文化和理念，強調開發團隊（Dev）和運維團隊（Ops）之間的協作。傳統模式中，開發團隊寫程式碼，運維團隊負責部署和維護，兩個團隊之間經常有矛盾。開發追求快速迭代，運維追求系統穩定，目標衝突導致效率低下。
DevOps 打破了這種隔閡，透過自動化工具和流程，讓開發和運維協同工作。CI/CD 是 DevOps 的核心實踐，它透過自動化來實現快速交付和穩定運行的平衡。開發者可以頻繁發布新功能，同時透過自動化測試和監控確保品質。運維不再是瓶頸，而是建設者，負責構建和維護自動化基礎設施。
Jenkins 是一個用 Java 編寫的開源持續整合工具，經過十多年的發展，Jenkins 已經成為 CI/CD 領域最流行的工具之一。
Jenkins 的強大之處在於它的靈活性和可擴展性。它提供了超過 1500 個插件，幾乎可以整合任何工具和服務。無論用的是 Git、SVN 還是其他版本控制系統，無論要部署到 Kubernetes、Docker 還是傳統服務器，Jenkins 都有對應的插件支援。
Jenkins 採用主從架構，可以輕鬆擴展。主節點（Master）負責調度任務，從節點（Agent）負責實際執行。可以根據需要添加更多的 Agent，分散構建負載。這種架構讓 Jenkins 能夠支撐大規模的構建需求。
Jenkins 的另一個優勢是強大的 Pipeline 功能。可以用程式碼（Groovy DSL）來定義整個 CI/CD 流程，這些程式碼可以版本化、審查、重用。相比圖形化配置，Pipeline as Code 更加靈活和可維護。
開源和社群支持也是 Jenkins 的重要優勢。作為一個成熟的開源項目，Jenkins 有龐大的社群，遇到問題很容易找到解決方案。而且免費，沒有許可證成本，對於預算有限的團隊來說非常友好。
Job（任務） 是 Jenkins 的基本工作單位。一個 Job 定義了要執行的一系列步驟，比如拉取程式碼、執行測試、構建映像檔等。Job 有多種類型，最常用的是 Freestyle Project（自由風格項目）和 Pipeline（流水線項目）。
Build（構建） 是 Job 的一次執行實例。每次 Job 運行都會創建一個新的 Build，有唯一的編號。Build 可以手動觸發，也可以自動觸發（比如程式碼提交時）。每個 Build 都有詳細的日誌，記錄執行過程中的所有輸出。
Workspace（工作空間） 是 Job 執行時使用的目錄。程式碼會被拉取到這個目錄，構建產物也會生成在這裡。每個 Job 有獨立的 Workspace，互不干擾。
Plugin（插件） 是 Jenkins 的擴展機制。核心的 Jenkins 功能其實很簡單，大部分功能都是透過插件實現的。比如要整合 GitLab，需要安裝 GitLab 插件；要構建 Docker 映像檔，需要安裝 Docker 插件。
Credentials（憑證） 用來存儲敏感資訊，比如 Git 的 SSH 金鑰、Docker Registry 的帳號密碼等。Jenkins 提供了安全的憑證管理機制，確保這些敏感資訊不會洩露。
在實際使用 Jenkins 的過程中，有一些最佳實踐值得注意。
盡量使用 Pipeline 而不是 Freestyle Project。Pipeline 的配置可以版本化，放在 Git Repo 中，這樣配置的變更可以追蹤、審查、回滾。而且 Pipeline 更靈活，支援複雜的邏輯。
對於團隊共用的流程，可以創建 Shared Library。Shared Library 是一組可重用的 Pipeline 程式碼，可以被多個專案引用。這避免了在每個專案中重複相同的程式碼，也便於統一更新。
Jenkins 的憑證管理非常重要。所有敏感資訊（SSH 金鑰、密碼、API Token 等）都應該存儲在 Jenkins 的 Credentials 中，而不是寫在程式碼裡。Credentials 是加密存儲的，只有授權的 Job 才能訪問。
對於生產環境的部署，建議設定人工審批。在 Pipeline 中可以使用 input 步驟來暫停流程，等待人工確認後再繼續。這樣可以避免自動部署帶來的風險。
Jenkins 本身的安全也很重要。啟用 HTTPS、設定強密碼、限制訪問權限、定期更新插件和核心版本，這些都是基本的安全措施。
隨著專案增多，構建可能變慢。有幾個優化方向：使用 Docker 層快取，避免每次都重新下載依賴。並行執行多個 Stage，充分利用資源。使用多個 Agent 分散負載。清理舊的構建產物，避免磁碟空間耗盡。
對於大型專案，可以考慮使用增量構建。只構建變更的部分，而不是每次都完整構建。這需要精心設計構建腳本，但可以大幅提升速度。
CI/CD 的核心是自動化測試。沒有完善的測試，頻繁部署只會帶來更多問題。建議建立多層測試：單元測試（快速、覆蓋率高）、整合測試（驗證模組間的交互）、端到端 (end-to-end) 測試（模擬真實用戶場景）、效能測試（確保效能沒有退化）。
測試要快速且穩定，慢的測試會拖慢整個流程，投入時間優化測試是值得的。
常見的做法是滾動更新（Rolling Update），逐步替換舊版本的 Pod。藍綠部署（Blue-Green Deployment），先部署新版本（綠），測試通過後切換流量，舊版本（藍）保留作為備份。金絲雀發布（Canary Release），先讓一小部分用戶使用新版本，觀察穩定後再全面推廣。
這些策略在前面學習的 Istio 和 Kubernetes 中都有支援。Jenkins 負責觸發部署，具體的部署策略由 Kubernetes 或 Istio 來實現。
今天內容一樣先到這邊，目前 CKAD 官方考試還不支援我電腦的 MacOS 26，但我一樣繼續刷題練習，待證照考過之後會補上實戰內容，明天就是鐵人賽最後一天，要來看看 Prometheus 搭配 Grafana！
iThome鐵人賽
看影片追技術