Apache Airflow 使用以下工具进行测试：

注意：MySQL 5.x 版本不能或有限制运行多个调度程序——请参阅调度程序文档。MariaDB 未经测试/推荐。

注意：SQLite 用于 Airflow 测试。不要在生产中使用它。我们推荐使用最新稳定版 SQLite 进行本地开发。

注意：Airflow 目前可以在符合 POSIX 标准的操作系统上运行。对于开发，它会定期在相当现代的 Linux 发行版和最新版本的 MacOS 上进行测试。在 Windows 上，您可以通过 WSL2（Linux 2 的 Windows 子系统）或通过 Linux 容器运行它。通过#10388跟踪添加 Windows 支持的工作，但它不是高优先级。您应该只使用基于 Linux 的发行版作为“生产”执行环境，因为这是唯一受支持的环境。

入门

访问 Airflow 官方网站文档（最新的稳定版本）以获得有关 安装 Airflow、 入门或完成更完整教程的帮助。

注意：如果您正在寻找主分支（最新开发分支）的文档：您可以在s.apache.org/airflow-docs上找到它。

有关气流改进建议 (AIP) 的更多信息，请访问气流维基。

提供程序包、Docker 镜像、Helm Chart 等依赖项目的文档，您可以在文档索引中找到它。

从 PyPI 安装

我们apache-airflow在 PyPI 中将 Apache Airflow 作为包发布。然而，安装它有时可能会很棘手，因为 Airflow 既是一个库又是一个应用程序。库通常会打开它们的依赖项，而应用程序通常会固定它们，但我们不应该同时做这两者。我们决定让我们的依赖项尽可能开放（在 中setup.py），以便用户可以根据需要安装不同版本的库。这意味着pip install apache-airflow将不时工作或将产生无法使用的 Airflow 安装。

constraints-main然而，为了实现可重复安装，我们在孤儿和分支中保留了一组“已知可以工作”的约束文件constraints-2-0。我们根据主要/次要 Python 版本分别保留那些“已知可以工作”的约束文件。从 PyPI 安装 Airflow 时，您可以将它们用作约束文件。请注意，您必须在 URL 中指定正确的 Airflow 标签/版本/分支和 Python 版本。

1. 仅安装 Airflow：

注意：pip目前官方仅支持安装。

虽然可以使用Poetry或 pip-tools 等工具安装 Airflow ，但它们不共享相同的工作流程 pip- 特别是在涉及约束与需求管理时。目前不支持通过Poetry或安装。pip-tools

如果您希望使用这些工具安装 Airflow，您应该使用约束文件并将它们转换为您的工具所需的适当格式和工作流程。

pip install 'apache-airflow==2.5.3' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.5.3/constraints-3.7.txt"

2. 安装附加功能（即 postgres、google）

pip install 'apache-airflow[postgres,google]==2.5.3' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.5.3/constraints-3.7.txt"

有关安装提供程序包的信息，请查看 提供程序。

官方源码

Apache Airflow 是Apache Software Foundation (ASF) 项目，我们的官方源代码发布：

• 遵循ASF 发布政策
• 可以从ASF 分发目录下载
• 由发布经理加密签名
• 在发布批准过程中由 PMC 成员正式投票选出

遵循 ASF 规则，发布的源包必须足以让用户构建和测试发布，前提是他们可以访问适当的平台和工具。

便利套餐

还有其他安装和使用 Airflow 的方法。这些是“方便”的方法——它们不是 声明的“官方发布” ASF Release Policy，但它们可以供不想自己构建软件的用户使用。

这些是——按照人们安装 Airflow 的最常见方式的顺序：

• PyPI 发布以使用标准pip工具安装 Airflow
• Docker Images通过工具安装 airflow docker，在 Kubernetes、Helm Charts 等中使用它们。docker-compose您可以在最新文档docker swarm中阅读有关使用、自定义和扩展图像的更多信息 ，并在IMAGES.rst文档中了解有关内部结构的详细信息.
• GitHub 中的标签，用于检索用于通过 git 生成官方源码包的 git 项目源

所有这些工件都不是官方发布的，但它们是使用官方发布的资源准备的。其中一些工件是“开发”或“预发布”工件，并且根据 ASF 政策明确标记它们。

用户界面

DAG：您环境中所有 DAG 的概览。

网格：跨越时间的 DAG 的网格表示。 图形：DAG 的依赖关系及其特定运行的当前状态的可视化。 任务持续时间：一段时间内在不同任务上花费的总时间。 甘特图：DAG 的持续时间和重叠。 代码：查看 DAG 源代码的快速方法。

支持 Python 和 Kubernetes 版本

从 Airflow 2.0 开始，我们同意为 Python 和 Kubernetes 支持遵循某些规则。它们基于 Python 和 Kubernetes 的官方发布时间表，在 Python Developer's Guide和 Kubernetes version skew policy中有很好的总结。

1. 当 Python 和 Kubernetes 版本到达 EOL 时，我们将停止支持它们。除了 Kubernetes 之外，如果两个主要的云供应商仍然提供对某个版本的支持，Airflow 将继续支持该版本。我们在 EOL 日期之后立即停止对 main 中的那些 EOL 版本的支持，并且当我们发布 Airflow 的第一个新的 MINOR（如果没有新的 MINOR 版本，则为 MAJOR）时，它会被有效地删除。例如，对于 Python 3.7，这意味着我们将在 2023 年 6 月 27 日之后立即放弃对 main 的支持，并且之后发布的第一个 MAJOR 或 MINOR 版本的 Airflow 将不会有它。

2. 在我们决定切换到更高版本之前，“最旧”支持的 Python/Kubernetes 版本是默认版本。“默认”仅在 CI PR 中的“冒烟测试”方面有意义，这些测试使用此默认版本和可用的默认参考图像运行。当前apache/airflow:latest 和apache/airflow:2.5.3图像是 Python 3.7 图像。这意味着当我们开始准备放弃 3.7 支持时，默认参考图像将成为默认图像，这是 Python 3.7 生命周期结束前几个月。

3. 在 Python/Kubernetes 正式发布后，我们在 main 中支持新版本，一旦我们让它们在我们的 CI 管道中工作（由于依赖项主要赶上新版本的 Python，这可能不会立即生效），我们会发布新图像/基于工作 CI 设置的 Airflow 支持。

对参考 Airflow 映像的基本操作系统支持

Airflow 社区提供方便打包的容器映像，每当我们发布 Apache Airflow 版本时都会发布这些映像。这些图像包含：

• 具有安装 Airflow 所需软件包的基本操作系统（稳定的 Debian 操作系统）
• 在 Airflow 的 MINOR 版本发布时支持的版本中的基本 Python 安装（例如，2.3 和 2.2 行可能有不同的版本）
• 连接到支持的数据库所需的库（同样，支持的数据库集取决于 Airflow 的 MINOR 版本。
• 一组预定义的流行提供程序（有关详细信息，请参阅 Dockerfile ）。
• 构建您自己的自定义图像的可能性，用户可以在其中选择他们自己的一组提供者和库（请参阅构建图像）
• 未来 Airflow 可能还支持不安装提供程序或数据库客户端的“苗条”版本

基本操作系统映像的版本是 Debian 的稳定版本。Airflow 支持使用所有当前活动的稳定版本——只要所有 Airflow 依赖项都支持构建，我们就会设置 CI 管道来构建和测试操作系统版本。在之前稳定版本操作系统的生命周期结束前大约 6 个月，Airflow 将发布的映像切换为使用最新支持的操作系统版本。例如，由于Debian Buster生命周期结束时间是 2022 年 8 月，Airflow 将main分支中的图像切换为在 2022 年 2 月/3 月使用。Debian Bullseye该版本在切换发生后的下一个 MINOR 版本中使用。如果是 Bullseye 开关 - 使用 2.3.0 版本Debian Bullseye. 在以前的 MINOR 版本中发布的图像继续使用 MINOR 版本的所有其他版本使用的版本。

2022 年 8 月完全放弃了对图像的支持Debian Buster，预计每个人都将停止使用Debian Buster.

用户将继续能够使用稳定的 Debian 版本构建他们的镜像，直到生命周期结束，镜像的构建和验证发生在我们的 CI 中，但没有使用该镜像在分支中执行单元测试main。

Airflow依赖的方法

Airflow 有很多依赖项——直接的和可传递的，Airflow 既是库又是应用程序，因此我们对依赖项的策略必须包括两者——应用程序安装的稳定性，以及为那些开发的用户安装更新版本的依赖项的能力DAG。constraints我们开发了用于确保可以以可重复的方式安装 airflow 的方法，同时我们不限制我们的用户升级大部分依赖项。因此，我们决定默认情况下不对 Airflow 依赖项进行上限版本，除非我们有充分的理由相信由于依赖项的重要性以及升级特定依赖项所涉及的风险而需要对它们进行上限。我们还限制了我们知道会导致问题的依赖项。

我们的约束机制负责自动查找和升级所有非上限依赖项（前提是所有测试都通过）。main如果存在破坏我们测试的依赖项版本，我们的构建失败将表明 - 表明我们应该对它们进行上层绑定，或者我们应该修复我们的代码/测试以说明来自这些依赖项的上游更改。

每当我们限制这样的依赖时，我们应该总是说明我们为什么这样做——即我们应该有一个很好的理由说明为什么依赖是上限。我们还应该提到解除绑定的条件是什么。

Airflow Core 的依赖关系方法

这些extras和providers依赖项在setup.cfg.

我们认为很少有依赖项足够重要，可以在默认情况下对它们进行上限限制，因为众所周知，它们遵循可预测的版本控制方案，而且我们知道这些依赖项的新版本很可能会带来重大变化。我们承诺定期审查并尝试升级到新版本的依赖项，但这是手动过程。

重要的依赖项是：

• SQLAlchemy：特定 MINOR 版本的上限（众所周知，SQLAlchemy 会删除弃用并引入重大更改，尤其是对不同数据库的支持会有所不同，并且会以不同的速度进行更改（例如：SQLAlchemy 1.4 破坏了 Airflow 的 MSSQL 集成）
• Alembic：以可预测和高效的方式处理我们的迁移很重要。它与 SQLAlchemy 一起开发。我们使用 Alembic 的经验是它在 MINOR 版本中非常稳定
• Flask：我们使用 Flask 作为我们的 web UI 和 API 的主干。我们知道 Flask 的主要版本很可能会在这些版本之间引入重大更改，因此将其限制为主要版本是有道理的
• werkzeug：已知该库会在新版本中引起问题。它与 Flask 库紧密耦合，我们应该一起更新它们
• celery：Celery 是 Airflow 的重要组成部分，因为它用于 CeleryExecutor（和类似的）。Celery 遵循 SemVer，所以我们应该将它上界到下一个 MAJOR 版本。此外，当我们修改库的上层版本时，我们应该确保 Celery Provider 的最低 Airflow 版本已更新）。
• kubernetes：Kubernetes 是 Airflow 的重要组成部分，因为它用于 KubernetesExecutor（和类似的）。Kubernetes Python 库遵循 SemVer，因此我们应该将其上限绑定到下一个 MAJOR 版本。此外，当我们更新库的上层版本时，我们应该确保更新了 Kubernetes Provider 的最低 Airflow 版本。

Airflow Providers 和 extras 中的依赖方法

这些extras和providers依赖关系在每个提供者中维护provider.yaml。

默认情况下，我们不应该为提供者设置上限依赖，但是每个提供者的维护者可能会决定添加额外的限制（并通过评论证明它们的合理性）