dagger 0.21.10 介绍与选型指南

可编程 CI/CD 引擎 dagger v0.21.10 认知篇：以容器化 Dagger Engine 为运行时、CLI 与多语言 SDK 把流水线写成代码函数；含架构拆解、功能特性、官方示例与 GitHub Actions/Jenkins/Woodpecker CI/act 量化选型对比（数据 2026-10-19 实查）。

daggerCICDDocker容器GoPython2026/10/19

dagger 0.21.10 介绍与选型指南

目标：面向需要把 CI/CD 流水线"写成代码函数"的运维与研发团队，介绍可编程 CI 引擎 dagger 的定位、架构、功能与同类选型对比。本文为认知篇，全部内容基于官方公开资料溯源编写（GitHub Releases 与 docs.dagger.io，查询日期 2026-10-19），不做本地安装实测；安装实测见《Ubuntu 22.04 安装 dagger 0.21.10 指南》。

一、环境信息

本章说明本文的信息基准，即所依据的版本号、查询日期与官方来源清单，便于读者复核。

  • 信息基准（查询日期）：2026-10-19
  • 版本依据：GitHub 仓库 dagger/dagger Releases 页面最新稳定 Release 为 v0.21.10（发布于 2026-09-30，非 prerelease、非 draft）；本文所有版本号均以该 Release 为准
  • 版本节奏佐证（主版本标签，均非 prerelease）：v0.21.10（2026-09-30）、v0.21.9（2026-08-26）、v0.21.8（2026-07-29）、v0.21.7（2026-06-17）、v0.21.6（2026-06-11）、v0.21.5（2026-06-10）、v0.21.4（2026-06-03）、v0.21.3（2026-05-30），约每月一个稳定版
  • 官方来源清单：
    • GitHub Releases：https://github.com/dagger/dagger/releases（v0.21.10 Release Notes 于 2026-10-19 经 GitHub API 实查）
    • 官方文档站：https://docs.dagger.io（0.21 版文档：https://docs.dagger.io/0.21）
    • 官方安装页/安装脚本：https://dl.dagger.io/dagger/install.sh
  • 版本口径重要说明：截至 2026-10-19，docs.dagger.io 文档站把 1.0-beta 作为默认文档版本（导航标注 "Next 1.0-beta"），0.21 版文档页顶部标注 "This is documentation for Dagger 0.21, which is no longer actively maintained"；但 GitHub Releases 最近 40 条记录中没有任何 1.0 相关标签、也没有任何 prerelease，最新稳定 Release 仍为 v0.21.10。因此本文以 v0.21.10 为版本基准，同时提示读者：1.0 尚无稳定 Release，生产选型以 v0.21.x 系列为准，跟进 1.0-beta 需自行评估风险。

二、软件概述

本章给出 dagger 的一句话定位与核心主张，帮助读者在 30 秒内判断它是否是自己要找的东西。

dagger 是一个可编程的 CI/CD 引擎（programmable CI/CD engine）：它把"流水线"从 YAML 声明式配置变成用通用编程语言写的函数，函数的输入/输出是强类型的（字符串、目录、容器等），函数之间可以像乐高一样组合成 DAG 工作流。官方 0.21 文档对它的定义是："Dagger is a platform for automating software delivery. It can build, test and ship any codebase, reliably and at scale. Dagger runs locally, in your CI server, or directly in the cloud."（来源：docs.dagger.io/0.21，查询日期 2026-10-19）

官方提出四个核心主张（来源同上）：

  • Programmable（可编程）：流水线即代码函数。官方原文："Shell scripts and proprietary YAML are no longer acceptable for automating software delivery"，dagger 提供"完整执行引擎与系统 API、8 种语言 SDK、交互式 REPL、可复用模块生态"
  • Local-first（本地优先）：同一套流水线函数可以在本地开发机与 CI 服务器上以完全相同的方式运行，本地通过即 CI 通过
  • Repeatable（可重复）：执行环境由引擎以容器化形态统一管理，缓存内建，结果可复现
  • Observable（可观测）：每次执行都有端到端的 trace，可接 OpenTelemetry

💡 技术拓展：CI/CD 引擎的"流水线定义方式"业界有三条主要路线，选型前应先看清全貌——

路线代表特点适用场景
YAML 声明式GitHub Actions / GitLab CI / Woodpecker CI上手快、与代码托管强绑定，复杂逻辑被迫塞进 shell 片段标准化构建/测试/发布
插件式 GUI/DSLJenkins（Jenkinsfile + 插件）生态最全、历史包袱重，维护成本高大而全的自托管企业流水线
代码函数式dagger流水线=强类型函数，任意语言编写，本地/CI 同构团队有编程能力、追求可测试可复用的流水线逻辑

本文介绍的 dagger 属于第三条路线的代表；若团队已在 GitHub 托管且逻辑简单，《GitHub Actions 介绍与选型指南》声明式路线成本最低；若需要本地复现 Actions 语法，《act 介绍与选型指南》是补充工具而非引擎。

三、核心架构

本章拆解 dagger 的三大组成与一次调用的完整链路，理解架构才能理解它"本地/CI 同构"的底气。

dagger 由三部分组成（来源：docs.dagger.io/0.21 Core Concepts 与 GitHub Releases 资产结构，查询日期 2026-10-19）：

  1. Dagger Engine（引擎）：负责实际执行构建、测试、发布等操作的核心。它以容器化引擎形态交付（官方镜像 registry.dagger.io/engine:v0.21.10，与 CLI 版本一一对应），内含 BuildKit 级别的执行层与缓存层。v0.21.10 Release Notes 还新增了引擎的 cgroup v2 CPU/内存资源遥测（在 /etc/dagger/engine.json 中开启 telemetry.resourceMetrics 并设置 OTEL_EXPORTER_OTLP_METRICS_ENDPOINT，默认关闭）。
  2. CLI（命令行工具）：单二进制 dagger，是引擎的统一入口。CLI 负责按需拉起/连接引擎（本地无引擎时自动创建同名 dagger-engine-<版本> 的运行实例）、把 dagger call 等命令翻译成 GraphQL 调用、渲染执行进度。
  3. SDK（多语言软件开发包）：官方维护 Go、Python、TypeScript、Rust、Elixir、PHP 等语言 SDK（以 GitHub Releases 中 sdk/<lang>/v0.21.10 标签为准；0.21 文档表述为 "SDKs for 8 languages"）。SDK 让开发者用自己熟悉的语言编写 Dagger Function。

一次调用的链路：

dagger call hello --name world
   └─> CLI 加载当前目录模块（dagger.json）
        └─> 连接 Dagger Engine（按需创建/启动 engine 实例）
             └─> GraphQL API 调用（函数输入/输出均为强类型）
                  └─> 引擎在沙箱化执行环境中跑函数，命中缓存则直接复用
                       └─> 返回结果 / 导出文件

关键设计点：

  • 模块（Module）：函数的组织单元。每个模块根目录有一个 dagger.json（记录 name、engineVersion、sdk、dependencies），代码放在 src/。模块可以互相依赖（dagger install），形成可复用的流水线组件生态（Daggerverse）。
  • GraphQL API 是中枢：CLI 的 dagger call、dagger query，以及所有 SDK，最终都走同一套 GraphQL API；引擎本地会暴露会话端点（DAGGER_SESSION_PORT/DAGGER_SESSION_TOKEN），可用 dagger run 包裹任意进程直接调用。
  • 本地/CI 同构：本地与 CI 跑的是同一版本引擎、同一模块代码、同一缓存语义，"本地能跑 CI 就能跑"不是口号而是架构保证。这是它与声明式 YAML 路线最本质的差异。

四、功能特性

本章按官方 0.21 文档 Features 页的分类列出核心功能（来源：https://docs.dagger.io/0.21/features，查询日期 2026-10-19），并补充 v0.21.10 Release Notes 的增量。

  • Programmable Workflows（可编程工作流）：函数接受强类型输入、返回强类型输出，可用 Go/Python/TypeScript 等语言编写，支持组合成任意复杂度的工作流
  • Built-In Caching（内建缓存）：执行步骤与产物自动缓存，未变化的步骤直接命中，多机共享可配远程缓存
  • Sandboxed Runtime（沙箱化运行时）：函数操作在引擎管理的隔离执行环境中进行，不污染宿主机
  • Observability（可观测）：内置 trace，v0.21.10 新增引擎 CPU/内存资源指标（cgroup v2，opt-in）
  • Composition & Reusability（组合与复用）：模块化封装 + 模块间依赖（dagger install）+ Daggerverse 社区模块生态；Ephemeral Services 支持临时起服务做集成测试后即焚
  • Secrets（密钥管理）：内置 Secret 类型，避免敏感值进入日志与缓存
  • Local Defaults（.env 本地默认值）：本地开发可通过 .env 提供默认参数
  • Interactive Shell（交互式 Shell）：REPL 式交互调试流水线
  • LLM Integration（LLM 集成）：GraphQL API 中内置 LLM 类型，可在流水线中直接编排大模型调用（CLI 全局参数中的 --allow-llm、--model 即对应此能力）

💡 说明：以上为 0.21 稳定版能力面。1.0-beta 文档轨引入了 Toolchains/Checks 等新概念并标注为 Next，生产环境暂不应依赖未发稳定版的特性。

五、快速上手

本章展示两个官方文档中的最小示例（引自官方文档并标注来源，本文不做本地实测；实测过程与真实回显见《dagger 0.21.10 常用 CLI 命令与工具详解》《dagger 0.21.10 SDK 与 API 使用详解》两篇）。

5.1 一条 GraphQL 查询跑起容器（来源：docs.dagger.io）

{
  container {
    from(address:"hello-world") {
      withExec(args:["/hello"]) {
        stdout
      }
    }
  }
}

保存为查询文件或通过标准输入传给 dagger query，即可拉起 hello-world 镜像执行并返回 stdout。这条查询体现了 dagger API 的链式风格：container → from → withExec → stdout，每一步都有类型、可静态检查。

5.2 用 Go 写一个构建函数（来源：docs.dagger.io/0.21 Core Concepts/Functions）

func (m *MyModule) Build() *Container {
    return dag.Container().
        From("node:20").
        WithDirectory("/app", m.Source).
        WithWorkdir("/app").
        WithExec([]string{"npm", "install"}).
        WithExec([]string{"npm", "run", "build"})
}

这是一个标准的 Dagger Function：输入是 m.Source（一个 Directory 类型），输出是 *Container。写完保存后 dagger call build 即可执行；同一个函数不加任何修改即可在本地与 CI 中运行。

六、适用场景与限制

本章给出"什么该用 dagger、什么不该用"的边界判断，避免选型错位。

适用场景：

  • 多语言团队统一流水线逻辑：构建/测试逻辑写成函数，Go/Python/TS 团队各用母语，API 类型互通
  • 本地与 CI 严格一致诉求：排查"本地好好的 CI 就是挂"类问题时，同构执行是根治方案
  • 复杂构建编排：多阶段构建、动态矩阵、服务联调（临时服务）等 YAML 写起来痛苦的场景
  • 流水线逻辑需要单元测试/代码评审：函数即代码，可直接进 code review 与测试体系
  • 需要把 AI 能力编进流水线：原生 LLM 类型适合做智能代码审查、生成类任务

限制与注意：

  • 依赖容器运行时：引擎以容器化形态运行，宿主机需具备可用的容器运行时（Linux 上为 Docker 等）；无容器环境不可用
  • 引擎拉取镜像走引擎自身网络栈：受限网络下需给引擎实例配置代理（实测方法与报错样本见 B1/D1 篇）
  • 1.0 过渡期口径：文档站主推 1.0-beta 而 GitHub 稳定 Release 仍为 v0.21.x，选型落地时锁定 v0.21.x 并关注 1.0 稳定版发布节奏
  • 学习曲线：需要团队具备至少一门编程语言；纯 YAML 心智的团队迁移成本高于换一个 YAML 引擎
  • 版本迭代快：v0.21.x 约每月一版，函数 API 偶有破坏性调整，模块需跟随 engineVersion 升级

七、同类选型对比

本章对 dagger 与 GitHub Actions（转述官方资料）、Jenkins、Woodpecker CI、act 做量化对比。社区与版本数据于 2026-10-19 经 GitHub API 实查（仓库 stars/forks/open issues/创建时间/许可证，及最近 5 个非 prerelease Release）；GitHub Actions 为 GitHub 托管服务、无独立开源仓库，其条目为对 GitHub 官方文档（docs.github.com）的转述。

7.1 量化对比表

维度dagger v0.21.10GitHub Actions（转述）Jenkins 2.586Woodpecker CI v3.19.0act v0.2.89
形态自托管可编程 CI 引擎（引擎容器化）GitHub 托管 CI/CD 服务自托管插件式 CI 服务端自托管轻量 pipeline CI本地 GitHub Actions 运行器
开源仓库dagger/dagger无独立仓库（服务内置）jenkinsci/jenkinswoodpecker-ci/woodpeckernektos/act
Stars（2026-10-19）16,351—（生态内置于 GitHub）26,6778,01972,377
Forks934—9,8417132,069
Open issues224—3,593391398
仓库创建2019-11-20—2010-11-222019-04-032019-01-02
许可证Apache-2.0—MITApache-2.0MIT
版本节奏（近 5 个稳定版）09-30 / 08-26 / 07-29 / 06-17 / 06-11（约每月）持续托管更新，无版本号10-13 / 10-06 / 09-30 / 09-29 / 09-22（每周）10-07 / 09-08 / 08-24 / 07-31 / 06-27（约 4-6 周）06-01 / 05-01 / 04-01 / 03-25 / 03-23（约每月）
流水线定义代码函数（Go/Python/TS/Rust/Elixir/PHP 等）workflow YAMLJenkinsfile（Groovy DSL）+ 插件pipeline YAML兼容 GitHub Actions workflow YAML
本地/CI 同构原生同构（同一引擎同一函数）本地不可直接跑（需《act 介绍与选型指南》模拟）需另起 Jenkins 实例需部署服务端仅本地模拟 Actions，无引擎概念
依赖宿主容器运行时无（GitHub 云）JVM二进制/容器宿主容器运行时

表格解读：Stars 上 act 最高（72k+，因为它是全体 Actions 用户的本地调试刚需）、Jenkins 次之（26k+，二十年存量）、dagger 16k+ 但增速集中在近三年；版本节奏上 Jenkins 每周发版最勤、dagger 与 act 约每月、Woodpecker 4-6 周；open issues 绝对值 Jenkins 最大（3,593，与其巨型插件生态一致）。比的是不同物种：act 是"本地跑 Actions"的工具，Jenkins/Woodpecker 是"服务端流水线引擎"，dagger 是"引擎即代码函数"——选型先分清物种，再谈数据。

7.2 逐个对比与"如果……则……"选型建议

  • dagger vs GitHub Actions：Actions 赢在零运维、与 GitHub 深度集成、marketplace 生态庞大；dagger 赢在流水线逻辑可编程可测试、本地同构执行、不被单一代码托管平台锁定。如果你的代码全在 GitHub 且流水线以标准构建/测试/部署为主，直接用《GitHub Actions 介绍与选型指南》；如果流水线里有大量复杂逻辑、或者要跨平台（代码不在 GitHub）、或者团队吃够了"本地跑不了 CI"的苦，dagger 是补位者——两者也常组合：Actions 只做触发器，函数逻辑跑在 dagger 引擎上。
  • dagger vs Jenkins：Jenkins 生态最全（近二十年插件积累）、企业遗留系统兼容性无敌，但 JVM 资源占用、插件冲突、GUI 配置漂移是长期痛点。新建自托管 CI 不建议再选 Jenkins，存量 Jenkins 可逐步把构建逻辑抽成 dagger 函数迁移；Jenkins 的迁移路线详见《Jenkins 2.568.3 介绍与选型指南》。
  • dagger vs Woodpecker CI：Woodpecker 是 Drone 社区分支，轻量、与《Forgejo 17.0 介绍与选型指南》《Gitea 28.1 介绍与选型指南》等自托管 Git 服务配合好、pipeline YAML 上手快；dagger 函数式更强但要求编程能力。团队用 Forgejo/Gitea 自托管且流水线标准化程度高 → 《Woodpecker CI v3.19.0 介绍与选型指南》；流水线逻辑复杂多变、需要本地联调 → dagger。两者亦可共存：Woodpecker 触发，dagger 执行。
  • dagger vs act：act 解决的是"本地复现 GitHub Actions workflow"，它不是独立引擎、不管理自己的函数体系；如果你要的就是本地跑 Actions，用《act 介绍与选型指南》；如果你要从头构建可编程流水线（尤其非 GitHub 托管），用 dagger。act 的 stars（72k+）远高于 dagger（16k+）正说明"本地跑 Actions"是刚需，而 dagger 把这个需求升级成了"本地与 CI 跑同一套引擎"。

一句话结论：要"流水线即代码 + 本地/CI 同构"，dagger 是当前开源阵营最成熟的专用引擎；要托管省心选 GitHub Actions，要轻量自托管 YAML 选 Woodpecker CI，要本地调试 Actions 选 act，要兼容存量企业流水线才留 Jenkins。

八、参考链接