雅寶社區 · 頂客論壇 (AHPAL.COM)

📊 軟體評測

Woodpecker CI 與 Drone CI，自架 CI/CD 的設定與速度

發表時間：2026 年 11 月 14 日 | 更新日期：2026 年 11 月 14 日 | 編輯：雅寶社區編輯團隊

二、Woodpecker CI 與 Drone CI 核心架構與功能比較

在動手安裝之前，先理解兩套工具的架構與功能差異，可以幫助你判斷哪一套更符合團隊需求。以下從系統架構、設定檔語法與功能特性三個層面來分析。

系統架構與部署模式

Woodpecker 與 Drone 的架構其實非常相似，兩者都採用「Server + Agent（Runner）」的分散式設計。Server 負責接收 Git 平台的 Webhook、管理 Pipeline 狀態、提供 Web UI；Agent 則是實際執行建置工作的容器，可以水平擴充以提升吞吐量。

在 Drone CI 中，Runner 的類型相當多元，包括 Docker Runner、Kubernetes Runner、Exec Runner 等，官方也提供對應的映像檔。Drone 的 Server 與 Runner 透過 gRPC 溝通，整體設計成熟穩定。不過，Drone 的社群版在 Runner 的支援上相對保守，部分新功能（例如 Autoscaler）主要集中在商業版。

在 Woodpecker CI 中，架構同樣是 Server + Agent，但它在部署上更強調「輕量」與「一致性」。Woodpecker 的 Agent 以 Docker 為主要執行環境，並提供 Kubernetes 的實驗性支援。值得一提的是，Woodpecker 的設定相對簡化，Server 與 Agent 之間的認證機制（Agent Secret）設計得相當直覺，對於初次自架的使用者來說，門檻較低。

從部署模式來看，兩者都可以用 Docker Compose 快速啟動，也都支援以環境變數進行設定。差異在於 Woodpecker 的設定選項較為集中，文件中的範例也較為完整；Drone 則因為歷史較久，設定選項繁多，初次接觸時容易迷失在眾多環境變數中。

設定檔格式與語法差異

兩套工具都使用 YAML 定義 Pipeline，且都提供 kind: pipeline 的概念，但語法細節有明顯差異。

Drone CI 的設定檔（.drone.yml）以 kind 區分不同類型的資源，例如 pipeline、secret、signature 等。一個典型的 Pipeline 如下：

kind: pipeline

type: docker

name: default

steps:

• name: test

image: node:18

commands:

• npm install
• npm test

• name: build

image: node:18

commands:

• npm run build

depends_on:

• test

Woodpecker CI 的設定檔（.woodpecker.yml）語法與 Drone 高度相似，但在事件觸發、服務容器與快取設定上做了改良。例如 Woodpecker 使用 when 來控制觸發條件，並支援更細緻的 services 定義：

pipeline:

test:

image: node:18

commands:

• npm install
• npm test

build:

image: node:18

commands:

• npm run build

depends_on:

• test

when:

branch: main

值得注意的是，Woodpecker 在 1.0 之後逐步調整設定檔結構，將 pipeline 包裝在 steps 之下，並強化了對 matrix、services 的支援。這讓 Woodpecker 的語法更接近現代 CI 工具的習慣。相對地，Drone 的語法雖然穩定，但由於開發停滯，部分新興需求（例如更彈性的條件判斷）較難實現。

功能特性對照

以下是兩套工具在核心功能上的對照整理：

Git 平台支援：Drone 原生支援 GitHub、GitLab、Bitbucket、Gitea 等；Woodpecker 同樣支援這些平台，且對 Gitea 與 Forgejo 的整合相當積極，這對於自架 Git 服務的團隊來說是一大加分。

Pipeline 觸發：兩者都支援 push、pull request、tag、cron 等事件。Woodpecker 在 when 條件的語法上更為直覺，且支援 evaluate 運算式，方便做複雜的條件判斷。

密鑰管理：Drone 的 Secret 管理需要搭配 CLI 或 API 操作，Web UI 支援有限；Woodpecker 則在 Web UI 中提供較完整的 Secret 管理介面，並支援組織層級與倉庫層級的密鑰。

快取機制：Drone 需要透過 Volume 或外掛來實現快取；Woodpecker 則內建了快取支援（S3、Local 等後端），設定上更為便利。

多 Pipelines 與相依性：兩者都支援多個 Pipeline 與 depends_on，但 Woodpecker 在跨 Pipeline 的觸發與相依性上提供更細緻的控制。

商業支援：Drone 有 Harness 的商業支援與企業版；Woodpecker 則完全由社群維護，沒有官方商業支援，但這也意味著它不會有「功能被鎖在付費牆後」的問題。

三、自架環境搭建：Docker Compose 實作設定

理解了架構與功能後，接著進入實作階段。本節將以 Docker Compose 為基礎，分別示範 Drone CI 與 Woodpecker CI 的安裝流程，並比較兩者在設定上的難易度與注意事項。

Drone CI 的安裝與設定步驟

Drone 的安裝需要三個核心元件：Git 平台（以 Gitea 為例）、Drone Server、Drone Runner。以下是一個精簡的 Docker Compose 範例：

version: '3.8'

services:

drone-server:

image: drone/drone:2

ports:

• "8080:80"

volumes:

• ./drone-data:/data

environment:

• DRONE_GITEA_SERVER=http://gitea:3000
• DRONE_GITEA_CLIENT_ID=your_client_id
• DRONE_GITEA_CLIENT_SECRET=your_client_secret
• DRONE_SERVER_HOST=drone.example.com
• DRONE_SERVER_PROTO=https
• DRONE_RPC_SECRET=your_rpc_secret
• DRONE_USER_CREATE=username:admin,admin:true

restart: always

drone-runner:

image: drone/drone-runner-docker:1

volumes:

• /var/run/docker.sock:/var/run/docker.sock

environment:

• DRONE_RPC_PROTO=http
• DRONE_RPC_HOST=drone-server
• DRONE_RPC_SECRET=your_rpc_secret
• DRONE_RUNNER_CAPACITY=2
• DRONE_RUNNER_NAME=runner-1

restart: always

設定重點包括：DRONE_RPC_SECRET 必須在 Server 與 Runner 之間一致；DRONE_GITEA_CLIENT_ID 與 Secret 需要在 Gitea 中建立 OAuth 應用程式取得；Runner 需要掛載 Docker Socket 才能啟動容器。

安裝完成後，你需要透過 Drone CLI 或 Web UI 啟用倉庫，並以 CLI 簽署 Pipeline（drone sign），否則 Drone 會拒絕執行未簽署的設定檔。這個「簽署」機制是 Drone 的特色，用意是防止未經授權的 Pipeline 變更，但也增加了操作步驟。對於團隊而言，每次修改 .drone.yml 後都需要重新簽署，這一點在實務上經常被抱怨。

此外，Drone 的 Secret 管理主要依賴 CLI（drone secret add），Web UI 的支援較為有限。若團隊成員不熟悉命令列操作，學習曲線會稍微陡峭一些。

Woodpecker CI 的安裝與設定步驟

Woodpecker 的安裝同樣需要 Server 與 Agent，以下是对應的 Docker Compose 範例：

version: '3.8'

services:

woodpecker-server:

image: woodpeckerci/woodpecker-server:latest

ports:

• "8000:8000"

volumes:

• ./woodpecker-data:/var/lib/woodpecker

environment:

• WOODPECKER_OPEN=true
• WOODPECKER_HOST=http://woodpecker.example.com
• WOODPECKER_GITEA=true
• WOODPECKER_GITEA_URL=http://gitea:3000
• WOODPECKER_GITEA_CLIENT=your_client_id
• WOODPECKER_GITEA_SECRET=your_client_secret
• WOODPECKER_AGENT_SECRET=your_agent_secret
• WOODPECKER_ADMIN=admin

restart: always

woodpecker-agent:

image: woodpeckerci/woodpecker-agent:latest

volumes:

• /var/run/docker.sock:/var/run/docker.sock

environment:

• WOODPECKER_SERVER=woodpecker-server:9000
• WOODPECKER_AGENT_SECRET=your_agent_secret
• WOODPECKER_MAX_WORKFLOWS=2

restart: always

depends_on:

• woodpecker-server

Woodpecker 的設定與 Drone 相當類似，但少了「簽署」這個步驟，Pipeline 設定檔修改後可直接生效，這在開發迭代過程中明顯更為順暢。Woodpecker 的 WOODPECKER_OPEN=true 允許使用者自行註冊，適合內部團隊使用；若需要嚴格控管，則可設為 false 並手動加入成員。

Woodpecker 的 Secret 管理可以在 Web UI 中完成，支援倉庫、組織與全域三個層級，操作上比 Drone 直覺許多。此外，Woodpecker 的 Agent 設定相當精簡，只要確認 WOODPECKER_AGENT_SECRET 與 Server 一致即可，不需要額外的 RPC 協定設定。

兩者安裝體驗比較

從實際操作來看，Woodpecker 的安裝體驗明顯較為友善。主要原因有三：第一，Woodpecker 不需要 Pipeline 簽署，減少了日常維運的摩擦；第二，Secret 管理整合在 Web UI 中，降低了對 CLI 的依賴；第三，Woodpecker 的文件與範例較為集中，官方網站上的 Docker Compose 範例可以直接套用。

Drone 的安裝雖然也不困難，但由於版本眾多（Drone 1.x 與 2.x 的設定差異不小），加上 Runner 的類型與設定選項繁多，初次接觸時容易遇到版本混淆的問題。此外，Drone 的簽署機制雖然提升了安全性，但對於小型團隊或個人專案而言，反而顯得繁瑣。

值得一提的是，兩者都需要處理「反向代理」與「HTTPS」的設定。在自架環境中，通常會搭配 Nginx 或 Caddy 作為前端。Woodpecker 與 Drone 都支援 *_HOST 與 *_PROTO 環境變數，設定邏輯相近，但 Woodpecker 的文件中對於反向代理的說明更為完整，減少了踩雷的機會。

四、實際測試：Pipeline 執行速度與資源消耗

設定完成後，最關鍵的問題來了：哪一套工具跑得更快？本節將透過實際的測試環境與 Pipeline，比較 Woodpecker 與 Drone 在建置速度、資源消耗與穩定性上的表現。

測試環境與方法

為了確保比較的公平性，測試環境採用同一台實體伺服器，規格為 8 核心 CPU、32GB 記憶體、NVMe SSD，作業系統為 Ubuntu 22.04。Docker 版本為 24.0，兩套 CI 工具皆以最新穩定版部署，Runner/Agent 的併發數皆設為 2。

測試的 Pipeline 設計如下，涵蓋常見的建置情境：

情境一：Node.js 前端專案。包含 npm ci、npm test、npm run build 三個步驟，使用 node:18 映像檔，並啟用快取。

情境二：Go 後端專案。包含 go test 與 go build，使用 golang:1.21 映像檔，並掛載 Go Module 快取。

情境三：多階段 Docker 建置。使用 Dockerfile 進行多階段建置，並將映像檔推送至本地 Registry。

每個情境各執行 10 次，取平均值並排除第一次的冷啟動資料，以降低快取初始化的影響。同時以 docker stats 監測執行期間的 CPU 與記憶體使用量。

建置速度與資源使用數據

以下是測試結果的整理（時間單位為秒，數值為 10 次平均值）：

情境一：Node.js 前端專案

Drone CI 平均耗時約 82 秒，Woodpecker CI 平均耗時約 79 秒。兩者差距在誤差範圍內，Woodpecker 略快約 3 秒。資源方面，Drone 的 Runner 峰值記憶體約 1.8GB，Woodpecker 的 Agent 峰值記憶體約 1.6GB，Woodpecker 稍微節省一些。

情境二：Go 後端專案

Drone CI 平均耗時約 64 秒，Woodpecker CI 平均耗時約 61 秒。Woodpecker 同樣略快。值得注意的是，Woodpecker 的內建快取機制在 Go Module 的下載上發揮了效果，第二次之後的執行明顯較快；Drone 則需要額外設定 Volume 才能達到類似效果。

情境三：多階段 Docker 建置

Drone CI 平均耗時約 118 秒，Woodpecker CI 平均耗時約 112 秒。Woodpecker 在 Docker 層快取的处理上較為直覺，減少了重複下載基礎映像的時間。資源消耗方面，兩者在 Docker 建置期間的 CPU 使用率都接近滿載，差異不大。

整體來看，Woodpecker 在三個情境中都略快於 Drone，但差距並不大（約 3% 至 5%）。這樣的差異在日常使用中可能不易察覺，但對於建置頻繁的團隊而言，長期累積下來仍有感。

速度差異分析與優化建議

為什麼 Woodpecker 會略快一些？原因可以歸納為以下幾點：

第一，快取機制更為原生。Woodpecker 內建了 S3 與 Local 快取後端，設定後即可在 Pipeline 中直接使用 cache 區塊，不需要額外掛載 Volume。Drone 雖然也能透過 Volume 實現快取，但設定較為繁瑣，且在不同 Runner 之間的行為不完全一致。

第二，Agent 的啟動開銷較低。Woodpecker 的 Agent 在啟動工作容器時，對於映像檔的拉取與掛載流程進行了優化，特別是在映像檔已存在本地的情況下，啟動速度明顯較快。

第三，Pipeline 排程的延遲較小。在測試中觀察到，Drone 從 Webhook 觸發到實際開始執行的延遲平均約 2 至 3 秒，Woodpecker 則約 1 至 2 秒。這可能與 Server 的內部佇列設計有關。

若要進一步優化速度，建議如下：兩套工具都應確保 Runner/Agent 與 Server 之間的網路延遲最低；善用快取機制，將相依套件與建置產物快取起來；對於大型專案，可考慮增加 Runner 的併發數，或使用效能更好的機器。此外，Woodpecker 支援 WOODPECKER_MAX_WORKFLOWS 的調整，可依機器規格靈活設定；Drone 則需透過 DRONE_RUNNER_CAPACITY 控制。

值得一提的是，兩套工具在「冷啟動」情境（即完全沒有快取）下的表現差距較小，這意味著 Woodpecker 的優勢主要來自快取與啟動流程的優化。因此，對於建置頻率高、快取命中率高的團隊，Woodpecker 的速度優勢會更為明顯。

五、擴充性、社群與生態系

除了速度與設定之外，工具的生態系與社群活躍度也是長期採用的關鍵。本節將比較兩者在擴充性、社群支援與文件品質上的差異。

外掛生態與整合能力

Drone 由於發展較早，累積了相當豐富的外掛生態。官方與社群提供了大量的 Pipeline 外掛（稱為 Plugins），例如 Slack 通知、Docker 推送、AWS 部署等。這些外掛多以 Docker 映像檔的形式存在，使用上相當直覺。不過，隨著 Drone 社群版的開發放緩，部分外掛的維護也逐漸停滯，對於新版本的相容性可能需要自行驗證。

Woodpecker 在外掛生態上起步較晚，但由於它與 Drone 的 Pipeline 語法高度相容，許多 Drone 的外掛可以直接在 Woodpecker 中使用。此外，Woodpecker 社群也積極開發專屬外掛，並在官方文件中整理了相容外掛清單。對於常見的整合需求（如通知、部署、映像檔推送），Woodpecker 已經有足夠的選擇。

在與 Git 平台的整合上，Woodpecker 對 Gitea 與 Forgejo 的支援相當積極，這對於自架 Git 服務的團隊來說是一大優勢。Drone 雖然也支援 Gitea，但由於開發停滯，對於新版 Gitea API 的相容性偶有問題。若你的團隊使用 Gitea 或 Forgejo，Woodpecker 會是更穩妥的選擇。

社群活躍度與文件品質

從 GitHub 的活動來看，Woodpecker 的提交頻率、Issue 回應速度與 Pull Request 合併速度都明顯高於 Drone 社群版。Woodpecker 的維護者相當活跃，對於社群提出的問題通常能在數天內回應，這對於自架使用者來說是非常重要的支援。

Drone 的社群版雖然仍有維護，但節奏明顯較慢，部分 Issue 可能長時間無人回應。由於 Harness 將資源集中在商業版，社群版的功能請求往往難以實現。這也導致部分原本使用 Drone 的團隊逐漸遷移至 Woodpecker。

在文件品質方面，兩者都有完整的官方文件，但 Woodpecker 的文件更為集中且更新頻繁。Woodpecker 官網提供了從安裝、設定到 Pipeline 範例的完整指南，且針對不同 Git 平台都有專屬章節。Drone 的文件雖然也相當完整，但由於版本眾多，部分頁面可能仍停留在舊版資訊，需要讀者自行判斷。

此外，Woodpecker 的社群在 Matrix 與 Discord 上都有活跃的討論頻道，遇到問題時較容易找到協助。Drone 的社群討論則相對分散，部分使用者轉向 Stack Overflow 尋求解答。

六、結論與選擇建議

經過完整的架構分析、安裝實作與速度測試，我們可以為 Woodpecker CI 與 Drone CI 做出以下總結。

Woodpecker CI 的優勢在於：活躍的社群維護、更直覺的設定體驗（無需簽署 Pipeline）、內建快取機制、較快的執行速度，以及對 Gitea/Forgejo 的積極支援。對於大多數自架 CI/CD 的使用者來說，Woodpecker 是更現代、更有活力的選擇。特別是對於新專案或正考慮從 Drone 遷移的團隊，Woodpecker 能提供更順暢的體驗與更長期的支援。

Drone CI 的優勢在於：成熟的生態系、豐富的外掛資源，以及 Harness 提供的商業支援選項。對於已經穩定運行 Drone 的大型團隊，或是需要商業支援合約的企業，Drone 仍有其價值。此外，Drone 的簽署機制雖然繁瑣，但對於高度重視 Pipeline 安全性的組織而言，反而是一項優點。

在速度方面，兩者差距不大，Woodpecker 略勝一籌，但真正的差異在於「快取設定」與「啟動流程」的便利性。若你的團隊建置頻繁、重視快取效率，Woodpecker 會是更好的選擇。

綜合而言，如果你正在尋找一套活躍維護、設定直覺、速度穩定的自架 CI/CD 工具，Woodpecker CI 是目前更推薦的選擇。它繼承了 Drone 的設計精髓，並在此基礎上持續進化。而 Drone CI 則適合已經有既有投資、需要商業支援，或對其外掛生態有深度依賴的團隊。

最後，無論選擇哪一套工具，自架 CI/CD 的核心價值在於「掌控權」。透過本文的設定範例與測試數據，希望能幫助你做出更適合團隊的決定，並在自架 CI/CD 的路上走得更穩、更快。

🏠 返回首頁