English version: 《Dagger In-Depth: Everything You Need to Know》
Author: @Tiexin Guo(郭铁心)
翻译：Runrunniu
1 什么是 Dagger ？
TL;DR：Dagger 是在 Docker 容器中本地运行 CI/CD 流水线的工具
说实话， Dagger 很难有具体的定义。媒体称之为“DevOps 平台”；风投机构称其为“DevOps 操作系统”。
但 Dagger 并不能这样定义。在我们讲 Dagger 是什么之前，先来了解以下内容：
2 Dagger 的特点
2.1 BuildKit
Dagger 的配置在 BuildKit 中执行，这是 Docker 的核心执行引擎(镜像构建神器)。
BuildKit 作为 Moby 项目一部分被开发，是一个开放框架，用于组装专门的容器系统，而无需 Docker 重新组装。本质上，它是一个工具包，能够高效、可重复地将源代码转换为构建工具。2017年，BuildKit 首次发布，并在2018年9月与 Docker Engine 一起发布了 2018 版本。
2.2 CUE
与大多数 CI 系统不同，你不需要用 Dagger 编写 YAML，只需要编写 CUE。
CUE 是一种开源的数据验证语言和推理引擎，本质上是逻辑编程，旨在简化涉及定义和使用数据的任务。实际上是 JSON 的超集，熟练使用 JSON 的用户可以快速上手，另外CUE还具有内置的自动格式化功能。
尽管它不是通用编程语言，但它有很多应用，例如数据验证、数据模板、配置、查询、代码生成，甚至脚本编写等等。
2.3 请等一下
既然为配置执行重用 Docker 的部分，为什么不重复使用另一部分的文件呢？
Dagger 的创始人 Solomon Hykes 在他们的官方 Discord 频道上明确地回答了这个问题：
· 我们需要一个正式规范的独立社区，具有类型系统、包装管理器、原生 Yaml 和 json 相互配合的声明性语言。
· Docker 文件也是专门构建的，但 Dagger 更通用。
· Docker 文件无法支持不同版本的需求。
3 Dagger 能做些什么？
3.1 这不是 Dagger
首先，我们引用关于 Dagger 的官方文献来避开歧义：
· Dagger 不会取代 CI，只是会通过在添加 Wrapper Layer 进行改进。
Dagger 没有 替换 现有的 CI ，而是通过添加 Wrapper Layer 来改进 CI。
我们可以把“ Wrapper ”换成比较官方高级的说法——“可移植开发层”。
3.2 所以 Dagger 只是一个 Wrapper ？
我们来看看 DevOps/cloud 的其他例子：
· Terraform。需要管理复杂的环境，即使有可以重复使用的模快和角色，仍然需要跨环境重复使用代码。Terragrunt 是一个能提供额外工具来保持配置简单、不重复的 Wrapper layer 。
· AWS CDK。它本质上是 CloudFormation 之上的一个 Wrapper layer ，允许使用熟悉的编程语言来定义和预置 AWS 云基础设施。这样就不必处理 CloudFormation 的不可读配置。当然，代码仍会转换为 CloudFormation 的可读格式，并且由 CloudFormation 管理基础架构； AWS CDK 与 AWS API 不会直接交互。
· 至于 CDKTF （CDK for Terraform），其实和 AWS CDK 没有什么不同，也许AWS CDK 给CDKTF带来了灵感，并且AWS 的jsii库可以实现多语言功能。它是 Terraform 之上的一个 Wrapper layer ，可将代码转换为 Terraform HCL，这样就不必学习 HCL 。但本质上， 基础设施由Terraform HCL 管理，而不是直接由代码管理。所以，它是另一个 Wrapper 。
那么 Dagger 到底是做什么的呢？Dagger 到底包装了什么？
3.3 Dagger 能做什么
在 CI 系统中，你可以以某种格式（最有可能是 YAML）定义一些步骤和操作，。例如，在 Jenkins 中，也许你会编写一些 groovy 文件。在 GitHub Actions 中，你会编写一些包含多个步骤的 YAML。
Dagger 在 Docker 中运行这些“步骤和操作”。那么 Dagger docker 本身在哪里运行呢？这是个好问题：可以在本地运行或在 CI 系统中。 Dagger 不会包装 CI 流水线和系统，它把所有琐碎的步骤和操作放在一个 Docker 容器中，在 CI 系统中运行，就像在编写一个大的Docker文件，它会运行 git 克隆、源代码静态扫描、测试、构建、工件上传等等所有内容。
4 Dagger 到底是什么
说 Dagger 是 Wrapper ，这没错。
但它不包含 CI 系统，而是将流水线步骤和操作包装到一个容器中（必须用 Dagger 的语法编写这些步骤和操作），并且包装的结果可以在另一个 CI 中运行。
从这个意义上说，Dagger 是 另一个 CI 系统，只是 CI 在容器中运行，而大多数 CI 系统恰好能够运行容器。
5 Dagger 的优势
Dagger 有三大优势
5.1 本地开发
首先，不需要安装 任何 该应用程序的特定依赖项，Dagger 管理 Docker 内的所有中间步骤和临时依赖项。
如果我们讨论 CI ，这可能不是一个优势，但如果我们谈论本地开发，这就是 Dagger 的一个优势。
Go 和 Nodejs，要么需要安装模块，要么甚至可能需要切换 Node 版本才能安装。而现在你可以在一个容器内完成所有这些操作，并且只将最终结果发送到本地。
5.2 自建 CI
现在可以在本地运行流水线，因为你可以轻松地在本地启动和运行 Docker 桌面。
不过，我们现在都有功能齐全的电脑；你可以在本地运行 CI 系统，那为什么还要在这些系统上浪费钱呢？只要 Docker 可用，就可以在任何地方运行，如果不想购买 CI 作为服务，你可以在自己的基础架构中运行 Dagger。
5.3 迁移到另一个 CI
既然“步骤和操作”需要一个容器，可以在 CI 系统中运行。
如果你需要迁移到另一个 CI 系统，则无需再重复 CI 步骤。例如，你不想再使用公司的旧 Jenkins 实例，但已经在使用 Dagger 和 Jenkins，现在想尝试一下 GitHub Actions。
在这种场景下，有两点要做：
· 如果现在正在使用 Jenkins，并且想要将这些 Jenkins 流水线迁移到 Dagger 中，则需要手动完成。成本与用 GitHub Actions 的语法重写整个流水线相同（如果工作量不大的话）。
· 你仍需要了解新的 CI 系统如何触发作业、如何使用语法等。Dagger 确实提供了一个避免 CI 锁定的解决方案，但这并不是一个从根本上解决灵活性以及运行规则问题的方案。
对于 DevOps 工程师来说，能够满足不同团队、不同需求、不同优先级的 DevOps 工具链更具吸引力。每个组件都是可模块化和可插拔的，可以少做很多繁琐的工作。
理想状态下，你可以在可读的 YAML 配置文件中定义所需的 DevOps 工具，并且通过命令可以设置或更改整个 DevOps 工具链和 SDLC 工作流程。
如果你对 “ DevOps toolchain as code ”感兴趣，欢迎了解 DevStream！
6 现在应该使用 Dagger 吗？
Dagger 有前途吗？大概有的。现在就用 Dagger 吗？倒也不必，原因有三：
· Dagger 项目本身仍然使用 GitHub Actions。因为它有局限性，不能通过 GitHub Actions 完成所有事情。
· 我们通常不会每 6 个月更改一次 CI 系统。如果 4 年更新一次，那何必用这个 Wrapper？
· Dagger 是最近新发布的，还没有支持很多 CI 系统，暂时不能保证在不同的 CI 系统中正常使用。
欢迎大家讨论，下期文章见！
本文由博客群发一文多发等运营工具平台 OpenWrite 发布