Airflow 运维实战：开发与部署笔记

最近在复盘我自己在 Apache Airflow 上的维实运维经验时，我发现一个规律：很多坑，战开其实书上都写过，发部只是署笔我们第一次做的时候没太重视。今天这篇文章，维实我就结合《Airflow Ops: Development and 战开Deployment》这一章的内容，把我对 Airflow 开发与部署 的发部理解整理成一篇笔记式博客，既是署笔给大家的参考，也算是维实我自己的总结。

一、战开前置要求

如果你要读懂这一篇，发部建议你已经具备以下基础：

• 熟悉 Airflow 的署笔基本概念和组件；

• 至少用过一种 CI/CD 工具（Jenkins / GitLab CI / GitHub Actions / Travis CI 等）；

• 对 Docker 或容器化应用 有一定了解，知道怎么构建和分发镜像。维实

我不会写具体的战开 CI/CD 实现细节，因为每家公司的发部技术栈不同，但我会总结一些常见模式，大家可以结合自己环境去落地。

二、DAG 部署方式

Airflow 的核心是 DAG（工作流），而在生产环境下，高防服务器我们最常面对的问题就是：如何把 DAG 部署到运行的 Airflow 集群。

主要有两类模式：

1. Bundling（打包部署）

最直接的方法：把 DAG 和 Airflow 本身打包到同一个镜像里。典型流程是：

• 在构建镜像时安装 Airflow；

• 把 DAG 文件拷贝进去；

• 打上 tag，然后分发。

优点：

• 所有组件（Airflow、插件、DAG）版本完全一致，强一致性；

• 部署完就能跑，几乎不会出现「某台机器少了一个 DAG」的情况。

缺点：

• 镜像大、构建慢；

• 每次改 DAG 都要重启所有服务，停机时间长。

👉 我的经验：适合 初期 或者 快速试错 阶段，改 DAG 的频率高但团队还没完全稳定时，可以用这个模式。

2. Decoupled DAG Delivery（解耦 DAG 交付）

这里把 Airflow 系统 和 DAG 分开管理。Airflow 镜像本身比较稳定，DAG 通过挂载 volume 的方式动态加载。

优点：

• DAG 更新独立，不用动整个 Airflow 部署；

• Airflow 本身作为长期运行系统更稳定。

缺点：

• 需要额外的文件分发机制（共享存储、Git 同步等）；

• DAG 的依赖管理要自己控制。亿华云

在这个模式下，有两种具体玩法：

• Push 模式：CI/CD 直接把 DAG 推到 Airflow 的共享文件系统。实现简单，但灾难恢复时需要手动再触发。

• Pull 模式：Airflow 自己拉取 DAG，比如用 git-sync[1] 定时拉取代码库。自动化程度高，更推荐。

👉 我的建议：前期用 Bundling，后期系统稳定后切到 Pull 模式的解耦方案，这样能兼顾效率和灵活性。

三、代码库结构

看似是小事，其实非常关键。Airflow 项目的 repo 结构决定了团队的协作模式。

1. Mono-repo（单仓库）

所有东西放一个仓库：Airflow 构建脚本、插件、DAG 全都在里面。

优点：

• 适合「Working at HEAD」模式，大家改的代码随时能看到；

• 协作简单，依赖关系透明。

缺点：

• 仓库大，CI/CD 流水线复杂；

• 多团队并行时容易打架。

2. Multi-repo（多仓库）

把 Airflow 系统、插件、各团队的b2b供应网 DAG 分开维护，互相独立。

优点：

• 各团队能独立开发和部署；

• CI/CD 更轻量。

缺点：

• 协调成本高，容易出现版本不一致；

• 需要更强的集成测试。

👉 我的实践：推荐 混合模式：

• 一个 核心 mono-repo 放 Airflow 镜像和内部插件；

• 各团队自己维护 DAG 的 repo，依赖核心镜像做本地测试。

这样既能保证稳定性，也能让团队灵活。

四、连接与变量管理

Airflow 的 Connection 和 Variable 是 DAG 运行的关键参数，很多时候里面还会包含敏感信息。

• 环境变量：可以直接用 AIRFLOW_VAR_XXX 或 AIRFLOW_CONN_XXX 注入。但不太安全，一般要配合 外部密钥管理系统。

• Secrets Backend：Airflow 原生支持 AWS Secrets Manager、GCP Secret Manager、HashiCorp Vault、Azure Key Vault 等。推荐在生产环境使用。

👉 建议：和安全团队沟通好，统一走 密钥管理系统，不要在 WebUI 里手工点配置。

五、Airflow 部署方式

根据团队基础设施的成熟度，可以选择不同的部署方式：

• Kubernetes：官方 Helm Chart 非常成熟，推荐优先选择。

• 虚拟机 / 裸机：除非已有历史包袱，否则不建议自建，太重。

• 托管服务：比如 Astronomer、MWAA（AWS Managed Workflows for Apache Airflow）、Google Composer，能大大降低运维成本，但会有一定厂商锁定。

六、本地开发环境

要写 DAG，最重要的就是 快速试错。常见的本地环境有三种：

• Python venv：轻量，适合入门，但和生产环境差异大。

• Docker Compose：能模拟多组件，更接近生产，但需要多一些本地资源。

• 云开发环境：弹性最好，但搭建门槛高。

👉 我个人偏爱 Docker Compose，既能跑出一个小型 Airflow 集群，又不会太重。

七、测试策略

Airflow 的测试很容易被忽视。我的体会是：测试不在于多，而在于「能不能让我们少掉坑」。

常见的测试层级：

• DAG 测试

Smoke Test：检查 DAG 合法性（能不能 import）。

Unit Test：单元测试 DAG 中的自定义函数。

Functional Test：验证 DAG 在特定数据下的行为。

Performance Test：检查性能指标（时延、内存、CPU 等）。

• Provider 测试

          Smoke Test：能否安装。

         Unit Test：用 Mock 框架模拟外部服务。

         Integration Test：和真实服务打通。

        Airflow 本身不建议自己测，交给社区维护者就好，除非你改了 Airflow 源码。

八、总结

这篇笔记大致涵盖了 Airflow 部署和开发的一整套流程：

1. 选择合适的 DAG 部署模式（前期 bundling，后期 decoupled + pull）。

2. 设计合理的 repo 结构（核心 mono-repo + 多个 DAG repo）。

3. 用 secrets backend 管理敏感信息。

4. 根据团队情况选择部署方式（K8s / VM / 托管服务）。

5. 给开发者提供本地或云端环境，保证迭代效率。

6. 制定合理的测试分层方案，保证稳定性。

写到这里，感觉这篇笔记算是把 Airflow 部署的「必修课」梳理了一遍。对我自己来说，最大收获是：别想着一步到位，要根据团队阶段选择最合适的模式。

本文地址：http://www.bzuk.cn/news/89e8599825.html