最近在復盤我自己在 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 系統、插件、各團隊的 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 部署的「必修課」梳理了一遍。對我自己來說，最大收獲是：別想著一步到位，要根據團隊階段選擇最合適的模式。