Dagger v0.13.2 发布解读新增Container.upAPI一键启动容器服务并转发端口【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger本篇技术指南以 Dagger 官方变更记录 .changes/v0.13.2.md同步收录于 CHANGELOG.md为主线深入讲解 v0.13.2 版本引入的新 APIContainer.up并结合仓库源码分析其底层实现原理与修复项。读完本文你将掌握如何在 Dagger 模块中直接用up替代.AsService().Up()启动容器服务、如何配置端口转发以及该能力在 CLI 与 SDK 中的真实调用形态。版本概览一次聚焦开发者体验的小版本发布Dagger v0.13.2 于2024-09-20发布紧随 2024-09-18 的 v0.13.1 之后。与 .changes/v0.13.0.md 包含大量 Breaking Changes 的版本不同v0.13.2 是一个小而精的维护版本全部改动集中在三个方面类别内容贡献者Added新增Container.upAPI作为.AsService().Up()的别名rajatjindalPR #8479Fixed移除日志中噪音较大的 check for updates spanvitoPR #8491Fixed修复日志输出出现多余空行的问题vitoPR #8500其中Container.up是本版本最值得关注的开发者功能下面重点展开。新 APIContainer.up它是什么.changes/v0.13.2.md中的原文说明非常简洁NewContainer.upAPI — This is an alias to.AsService().Up().即在 v0.13.2 中Container对象新增了一个up字段其语义等价于先调用AsService()将容器转换为Service再调用Service.Up()启动它。这样开发者无需显式做类型转换就能直接把容器跑起来。为什么需要它在此之前要在本地把容器作为一个服务跑起来标准的 Dagger 写法是svc : ctr.AsService() // 先把容器转为 Service svc.Up(ctx) // 再启动服务并创建本地隧道这种写法要求开发者理解Container与Service两个类型之间的转换关系心智负担较重。Container.up将两步合成一步让启动容器服务这一高频操作变得更加直观同时保持行为完全一致alias而非新的语义。在 SDK 中的实际形态虽然 v0.13.2 于 2024 年 9 月发布但该 API 在后续版本中持续演进。以当前仓库 sdk/go/dagger.gen.go 中的 Go SDK 生成为例可以确认该 API 的真实签名// Starts a Service and creates a tunnel that forwards traffic from the callers // network to that service. // // Be sure to set any exposed ports before calling this api. func (r *Container) Up(ctx context.Context, opts ...ContainerUpOpts) error { if r.up ! nil { return nil } q : r.query.Select(up) // ...逐个设置可选参数... }可以看到Go SDK 中的Container.Up直接通过 GraphQL 查询选择up字段对应的可选参数来自ContainerUpOpts包括参数含义默认值Random将每个隧道端口绑定到宿主机随机端口falsePorts前端/后端端口映射列表前端为宿主机接收流量的端口后端为服务端口[]Args替代容器默认命令执行的命令如[go, run, main.go]空使用默认命令UseEntrypoint若容器有 entrypoint将其前置拼接到 args 前falseExperimentalPrivilegedNesting为执行的命令提供访问 Dagger API 的能力falseInsecureRootCapabilities以所有 root 权限执行命令类似docker run --privileged仅在绝对必要时用于受信任命令falseExpand按容器内环境变量展开 args 中的${VAR}/$VAR如/$VAR/foofalseNoInit跳过默认注入的 init 进程使目标进程成为容器内 PID 1false对应地Container.AsService的实现位于 sdk/go/dagger.gen.go 第 1521 行附近同样通过Select(asService)构造查询两者的 GraphQL 底层路径是一致的。说明以上 SDK 签名为当前仓库较新版本的实际内容。v0.13.2 时代的功能形态以变更记录描述Container.up别名为准参数细节以实际使用版本为准。底层实现up如何变成一条可执行的隧道Container.up能被称为.AsService().Up()的别名从当前仓库的核心实现中可以找到直接证据。服务模式的up解析在核心 schema core/schema/service.go 中Container上注册了名为up的 GraphQL 字段。其中面向新版本的实现containerUp第 304 行起的代码路径清晰展示了别名的含义func (s *serviceSchema) containerUp(ctx context.Context, ctr dagql.ObjectResult[*core.Container], args struct { UpArgs core.ContainerAsServiceArgs }) (res dagql.Nullable[core.Void], _ error) { // ...将 args、useEntrypoint 等参数组装为 dagql.NamedInput... // 首先在 GraphQL 层选择 asService 字段得到 Service 对象 err srv.Select(ctx, ctr, svc, dagql.Selector{Field: asService, View: curCall.View, Args: inputs}, ) if err ! nil { return res, err } // 再调用通用的 up 逻辑启动服务 return s.up(ctx, svc, args.UpArgs) }即Container.up在 schema 层就是先做一次asService选择再走与Service.Up()完全相同的up处理函数——这就是alias在实现层面的落地。隧道启动host.tunnel 与端口映射真正的启动逻辑在 core/schema/service.go 的up函数第 528 行起func (s *serviceSchema) up(ctx context.Context, svc dagql.ObjectResult[*core.Service], args UpArgs) (res dagql.Nullable[core.Void], _ error) { useNative : !args.Random len(args.Ports) 0 // 通过 host.tunnel 创建宿主机隧道 err srv.Select(ctx, srv.Root(), hostSvc, dagql.Selector{Field: host}, dagql.Selector{ Field: tunnel, Args: []dagql.NamedInput{ {Name: service, Value: dagql.NewID*core.Service}, {Name: ports, Value: ...args.Ports...}, {Name: native, Value: dagql.Boolean(useNative)}, }, }, ) // ... runningSvc, err : svcs.Start(ctx, hostSvcDig, hostSvc.Self(), true) // 打印每个端口的访问信息如 http://localhost:PORT // 阻塞等待 ctx 取消如 CtrlC -ctx.Done() return void, nil }这段实现揭示了up的完整行为链路端口映射决策当既未指定--random也未指定--ports时使用native模式useNative true即直接暴露容器声明的端口否则按用户给定的映射建立隧道。创建宿主机隧道通过host.tunnel将服务端口与宿主机端口打通。启动服务并输出访问地址启动后通过 span 日志输出形如http://localhost:PORT端口 443 时为https://localhost:443的访问信息便于开发者直接打开浏览器验证。阻塞等待取消-ctx.Done()使命令持续运行直到用户按下 CtrlC。另外当前仓库还为该字段标明了DoNotCache(Starts a host tunnel, possibly with ports that change each time its started.)见 core/schema/service.go 第 54/65 行意思是该操作因端口可能随启动变化而不应被缓存这也印证了up是每次运行都会真实起服务的过程而非纯函数。端口冲突检测与优雅退出在较新的实现中模块服务的批量启动还具备两阶段保障见 core/up.goPhase 1并行预评估所有服务收集各自期望的宿主机端口任一服务评估失败则整体放弃启动端口冲突检查若两个服务声明了相同的宿主机端口通过checkPortCollisions直接报错并中止避免半启动的尴尬状态Phase 2并行启动所有服务每个服务一旦通过健康检查即返回启动失败的服务能立刻暴露问题不会让其他 goroutine 挂起。这段设计UpGroup.Runcore/up.go 第 78 行起对应的是模块中多个up服务函数的批量场景与Container.up单服务场景共用同一套启动与隧道机制。在 CLI 中的用法与测试验证Container.up不只是 SDK 可用CLI 同样支持仓库的集成测试 core/integration/module_up_test.go 提供了完整的实测样例# 直接对返回容器的模块函数调用 upnative 模式暴露容器声明的端口 dagger -m . call ctr up # 绑定随机宿主机端口 dagger -m . call ctr up --random # 显式指定端口映射宿主机23101 - 容器23100 dagger -m . call ctr up --ports 23101:23100 # 结合 CLI 侧 --port 与函数侧 --ports 一起使用 dagger -m . call --port 23102 ctr up --ports 23102:23102 # 不暴露端口的情况下用 --args 覆盖命令并映射端口 dagger -m . call ctr without-exposed-port --port 23100 \ with-exposed-port --port 23103 up --args python,-m,http.server,23103 \ --ports 23103:23103 # 等价旧写法先 as-service 再 up dagger -m . call ctr as-service up dagger -m . call ctr as-service up --random dagger -m . call ctr as-service up --ports 23201:23200测试注释core/integration/module_up_test.go 第 1-8 行说明了这些用例的覆盖目标验证dagger call ... up与dagger script ... up的端点发现、端口映射以及本地开发场景下把模块结果跑成服务的能力。测试还特别提醒每个用例使用唯一端口以避免并发冲突。本次修复的两处细节v0.13.2 同时修复了两个开发者日常可感知的问题1. 移除噪音日志 check for updatesDagger CLI 在每次执行命令时会在后台检查是否有新版本可用见 internal/cmd/dagger/main.go 第 386 行的checkForUpdates。该检查本身是异步的并且通过环境变量DAGGER_NO_UPDATE_CHECK可关闭非空即跳过检查失败时静默忽略错误若命令在检查完成前退出则取消检查。v0.13.2 之前这条检查更新的过程会产生一条对用户毫无价值的 span 输出干扰日志阅读本次修复将其移除让输出更干净。2. 修复日志输出多余空行v0.13.0 曾修复过plain progress 正确显示回车符的问题见 .changes/v0.13.0.mdv0.13.2 则进一步修复了日志输出中额外空行的问题保证终端与结构化日志的输出整洁一致。升级建议与注意事项升级路径从 v0.13.1 升级到 v0.13.2 无 Breaking Changes改动集中在增量 API 与输出清理风险较低。up的适用场景本地调试、端口转发验证、将模块函数返回的容器/服务临时跑起来。它与纯函数式的 Dagger 调用不同——它会真实占用宿主机端口并阻塞运行因此在 CI 流水线中需要谨慎使用通常配合超时或测试后清理。端口前置条件正如 SDK 注释Be sure to set any exposed ports before calling this api与 core/container.go 第 7019 行AsService实现所示容器必须存在可执行命令args、cmd或entrypoint至少其一否则会返回ErrNoSvcCommand错误要暴露端口请先调用with-exposed-port或等价 API。多服务端口规划若同时启动多个服务注意宿主机端口冲突会被引擎直接拒绝启动参见 core/up.go 的checkPortCollisions。小结v0.13.2 是 Dagger 在 2024 年 9 月的一次轻量级迭代核心功能只有一个——新增Container.upAPI用一步调用封装了.AsService().Up()的完整流程。从当前仓库源码core/schema/service.go 的containerUp/up实现可以确认这个别名在底层就是先选择asService字段再走统一的隧道启动逻辑背后依赖host.tunnel实现宿主机端口转发并通过DoNotCache保证每次运行都真实生效。配合两项日志输出修复v0.13.2 让把容器跑成本地服务变得更顺手、更安静。如需查看该版本相关的其他上下文可继续阅读仓库内的相邻版本变更记录如 .changes/v0.13.1.md 与 .changes/v0.13.0.md。【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dagger v0.13.2 发布解读：新增 `Container.up` API，一键启动容器服务并转发端口
Dagger v0.13.2 发布解读新增Container.upAPI一键启动容器服务并转发端口【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger本篇技术指南以 Dagger 官方变更记录 .changes/v0.13.2.md同步收录于 CHANGELOG.md为主线深入讲解 v0.13.2 版本引入的新 APIContainer.up并结合仓库源码分析其底层实现原理与修复项。读完本文你将掌握如何在 Dagger 模块中直接用up替代.AsService().Up()启动容器服务、如何配置端口转发以及该能力在 CLI 与 SDK 中的真实调用形态。版本概览一次聚焦开发者体验的小版本发布Dagger v0.13.2 于2024-09-20发布紧随 2024-09-18 的 v0.13.1 之后。与 .changes/v0.13.0.md 包含大量 Breaking Changes 的版本不同v0.13.2 是一个小而精的维护版本全部改动集中在三个方面类别内容贡献者Added新增Container.upAPI作为.AsService().Up()的别名rajatjindalPR #8479Fixed移除日志中噪音较大的 check for updates spanvitoPR #8491Fixed修复日志输出出现多余空行的问题vitoPR #8500其中Container.up是本版本最值得关注的开发者功能下面重点展开。新 APIContainer.up它是什么.changes/v0.13.2.md中的原文说明非常简洁NewContainer.upAPI — This is an alias to.AsService().Up().即在 v0.13.2 中Container对象新增了一个up字段其语义等价于先调用AsService()将容器转换为Service再调用Service.Up()启动它。这样开发者无需显式做类型转换就能直接把容器跑起来。为什么需要它在此之前要在本地把容器作为一个服务跑起来标准的 Dagger 写法是svc : ctr.AsService() // 先把容器转为 Service svc.Up(ctx) // 再启动服务并创建本地隧道这种写法要求开发者理解Container与Service两个类型之间的转换关系心智负担较重。Container.up将两步合成一步让启动容器服务这一高频操作变得更加直观同时保持行为完全一致alias而非新的语义。在 SDK 中的实际形态虽然 v0.13.2 于 2024 年 9 月发布但该 API 在后续版本中持续演进。以当前仓库 sdk/go/dagger.gen.go 中的 Go SDK 生成为例可以确认该 API 的真实签名// Starts a Service and creates a tunnel that forwards traffic from the callers // network to that service. // // Be sure to set any exposed ports before calling this api. func (r *Container) Up(ctx context.Context, opts ...ContainerUpOpts) error { if r.up ! nil { return nil } q : r.query.Select(up) // ...逐个设置可选参数... }可以看到Go SDK 中的Container.Up直接通过 GraphQL 查询选择up字段对应的可选参数来自ContainerUpOpts包括参数含义默认值Random将每个隧道端口绑定到宿主机随机端口falsePorts前端/后端端口映射列表前端为宿主机接收流量的端口后端为服务端口[]Args替代容器默认命令执行的命令如[go, run, main.go]空使用默认命令UseEntrypoint若容器有 entrypoint将其前置拼接到 args 前falseExperimentalPrivilegedNesting为执行的命令提供访问 Dagger API 的能力falseInsecureRootCapabilities以所有 root 权限执行命令类似docker run --privileged仅在绝对必要时用于受信任命令falseExpand按容器内环境变量展开 args 中的${VAR}/$VAR如/$VAR/foofalseNoInit跳过默认注入的 init 进程使目标进程成为容器内 PID 1false对应地Container.AsService的实现位于 sdk/go/dagger.gen.go 第 1521 行附近同样通过Select(asService)构造查询两者的 GraphQL 底层路径是一致的。说明以上 SDK 签名为当前仓库较新版本的实际内容。v0.13.2 时代的功能形态以变更记录描述Container.up别名为准参数细节以实际使用版本为准。底层实现up如何变成一条可执行的隧道Container.up能被称为.AsService().Up()的别名从当前仓库的核心实现中可以找到直接证据。服务模式的up解析在核心 schema core/schema/service.go 中Container上注册了名为up的 GraphQL 字段。其中面向新版本的实现containerUp第 304 行起的代码路径清晰展示了别名的含义func (s *serviceSchema) containerUp(ctx context.Context, ctr dagql.ObjectResult[*core.Container], args struct { UpArgs core.ContainerAsServiceArgs }) (res dagql.Nullable[core.Void], _ error) { // ...将 args、useEntrypoint 等参数组装为 dagql.NamedInput... // 首先在 GraphQL 层选择 asService 字段得到 Service 对象 err srv.Select(ctx, ctr, svc, dagql.Selector{Field: asService, View: curCall.View, Args: inputs}, ) if err ! nil { return res, err } // 再调用通用的 up 逻辑启动服务 return s.up(ctx, svc, args.UpArgs) }即Container.up在 schema 层就是先做一次asService选择再走与Service.Up()完全相同的up处理函数——这就是alias在实现层面的落地。隧道启动host.tunnel 与端口映射真正的启动逻辑在 core/schema/service.go 的up函数第 528 行起func (s *serviceSchema) up(ctx context.Context, svc dagql.ObjectResult[*core.Service], args UpArgs) (res dagql.Nullable[core.Void], _ error) { useNative : !args.Random len(args.Ports) 0 // 通过 host.tunnel 创建宿主机隧道 err srv.Select(ctx, srv.Root(), hostSvc, dagql.Selector{Field: host}, dagql.Selector{ Field: tunnel, Args: []dagql.NamedInput{ {Name: service, Value: dagql.NewID*core.Service}, {Name: ports, Value: ...args.Ports...}, {Name: native, Value: dagql.Boolean(useNative)}, }, }, ) // ... runningSvc, err : svcs.Start(ctx, hostSvcDig, hostSvc.Self(), true) // 打印每个端口的访问信息如 http://localhost:PORT // 阻塞等待 ctx 取消如 CtrlC -ctx.Done() return void, nil }这段实现揭示了up的完整行为链路端口映射决策当既未指定--random也未指定--ports时使用native模式useNative true即直接暴露容器声明的端口否则按用户给定的映射建立隧道。创建宿主机隧道通过host.tunnel将服务端口与宿主机端口打通。启动服务并输出访问地址启动后通过 span 日志输出形如http://localhost:PORT端口 443 时为https://localhost:443的访问信息便于开发者直接打开浏览器验证。阻塞等待取消-ctx.Done()使命令持续运行直到用户按下 CtrlC。另外当前仓库还为该字段标明了DoNotCache(Starts a host tunnel, possibly with ports that change each time its started.)见 core/schema/service.go 第 54/65 行意思是该操作因端口可能随启动变化而不应被缓存这也印证了up是每次运行都会真实起服务的过程而非纯函数。端口冲突检测与优雅退出在较新的实现中模块服务的批量启动还具备两阶段保障见 core/up.goPhase 1并行预评估所有服务收集各自期望的宿主机端口任一服务评估失败则整体放弃启动端口冲突检查若两个服务声明了相同的宿主机端口通过checkPortCollisions直接报错并中止避免半启动的尴尬状态Phase 2并行启动所有服务每个服务一旦通过健康检查即返回启动失败的服务能立刻暴露问题不会让其他 goroutine 挂起。这段设计UpGroup.Runcore/up.go 第 78 行起对应的是模块中多个up服务函数的批量场景与Container.up单服务场景共用同一套启动与隧道机制。在 CLI 中的用法与测试验证Container.up不只是 SDK 可用CLI 同样支持仓库的集成测试 core/integration/module_up_test.go 提供了完整的实测样例# 直接对返回容器的模块函数调用 upnative 模式暴露容器声明的端口 dagger -m . call ctr up # 绑定随机宿主机端口 dagger -m . call ctr up --random # 显式指定端口映射宿主机23101 - 容器23100 dagger -m . call ctr up --ports 23101:23100 # 结合 CLI 侧 --port 与函数侧 --ports 一起使用 dagger -m . call --port 23102 ctr up --ports 23102:23102 # 不暴露端口的情况下用 --args 覆盖命令并映射端口 dagger -m . call ctr without-exposed-port --port 23100 \ with-exposed-port --port 23103 up --args python,-m,http.server,23103 \ --ports 23103:23103 # 等价旧写法先 as-service 再 up dagger -m . call ctr as-service up dagger -m . call ctr as-service up --random dagger -m . call ctr as-service up --ports 23201:23200测试注释core/integration/module_up_test.go 第 1-8 行说明了这些用例的覆盖目标验证dagger call ... up与dagger script ... up的端点发现、端口映射以及本地开发场景下把模块结果跑成服务的能力。测试还特别提醒每个用例使用唯一端口以避免并发冲突。本次修复的两处细节v0.13.2 同时修复了两个开发者日常可感知的问题1. 移除噪音日志 check for updatesDagger CLI 在每次执行命令时会在后台检查是否有新版本可用见 internal/cmd/dagger/main.go 第 386 行的checkForUpdates。该检查本身是异步的并且通过环境变量DAGGER_NO_UPDATE_CHECK可关闭非空即跳过检查失败时静默忽略错误若命令在检查完成前退出则取消检查。v0.13.2 之前这条检查更新的过程会产生一条对用户毫无价值的 span 输出干扰日志阅读本次修复将其移除让输出更干净。2. 修复日志输出多余空行v0.13.0 曾修复过plain progress 正确显示回车符的问题见 .changes/v0.13.0.mdv0.13.2 则进一步修复了日志输出中额外空行的问题保证终端与结构化日志的输出整洁一致。升级建议与注意事项升级路径从 v0.13.1 升级到 v0.13.2 无 Breaking Changes改动集中在增量 API 与输出清理风险较低。up的适用场景本地调试、端口转发验证、将模块函数返回的容器/服务临时跑起来。它与纯函数式的 Dagger 调用不同——它会真实占用宿主机端口并阻塞运行因此在 CI 流水线中需要谨慎使用通常配合超时或测试后清理。端口前置条件正如 SDK 注释Be sure to set any exposed ports before calling this api与 core/container.go 第 7019 行AsService实现所示容器必须存在可执行命令args、cmd或entrypoint至少其一否则会返回ErrNoSvcCommand错误要暴露端口请先调用with-exposed-port或等价 API。多服务端口规划若同时启动多个服务注意宿主机端口冲突会被引擎直接拒绝启动参见 core/up.go 的checkPortCollisions。小结v0.13.2 是 Dagger 在 2024 年 9 月的一次轻量级迭代核心功能只有一个——新增Container.upAPI用一步调用封装了.AsService().Up()的完整流程。从当前仓库源码core/schema/service.go 的containerUp/up实现可以确认这个别名在底层就是先选择asService字段再走统一的隧道启动逻辑背后依赖host.tunnel实现宿主机端口转发并通过DoNotCache保证每次运行都真实生效。配合两项日志输出修复v0.13.2 让把容器跑成本地服务变得更顺手、更安静。如需查看该版本相关的其他上下文可继续阅读仓库内的相邻版本变更记录如 .changes/v0.13.1.md 与 .changes/v0.13.0.md。【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考