Apache Airflow 的 Docker 镜像¶
为了便于在生产环境中部署，社区发布了一个生产就绪的参考容器镜像。
Apache Airflow 社区发布了作为 Apache Airflow 的 参考镜像 的 Docker 镜像。每当发布新版本的 Airflow 时，都会在 apache/airflow DockerHub 中为所有支持的 Python 版本准备相应的镜像。
您可以在那里找到以下镜像（假设 Airflow 版本为 3.0.0）：
apache/airflow:latest- 默认 Python 版本的最新发布的 Airflow 镜像（当前为 3.12）apache/airflow:latest-pythonX.Y- 特定 Python 版本的最新发布的 Airflow 镜像apache/airflow:3.0.0- 默认 Python 版本的版本化 Airflow 镜像（当前为 3.12）apache/airflow:3.0.0-pythonX.Y- 特定 Python 版本的版本化 Airflow 镜像
这些是“参考”标准镜像。它们包含了用户常用的一组附加功能包、依赖项和提供程序，非常适合您想要快速尝试 Airflow 时使用，
您也可以使用仅包含核心 Airflow 且大小约为“标准”镜像一半的 “slim” 镜像，但您需要通过 构建镜像 单独添加所有您需要的 附加功能包参考 和提供程序。
apache/airflow:slim-latest- 默认 Python 版本的最新发布的 Airflow Slim 镜像（当前为 3.12）apache/airflow:slim-latest-pythonX.Y- 特定 Python 版本的最新发布的 Airflow Slim 镜像apache/airflow:slim-3.0.0- 默认 Python 版本的版本化 Airflow Slim 镜像（当前为 3.12）apache/airflow:slim-3.0.0-pythonX.Y- 特定 Python 版本的版本化 Airflow Slim 镜像
作为便利包提供的 Apache Airflow 镜像已针对大小进行了优化，它仅安装了最少的附加功能包和依赖项，在大多数情况下，您需要扩展或自定义该镜像。您可以在 附加功能包参考 中查看所有可能的附加功能包。Airflow 生产镜像中使用的一组附加功能包可在 Dockerfile 中找到。
然而，Airflow 有 60 多个由社区管理的提供程序（可通过附加功能包安装），并且并非所有人都使用一些默认安装的附加功能包/提供程序，有时需要其他附加功能包/提供程序，有时（实际上非常频繁地）您需要添加自己的自定义依赖项、软件包甚至自定义提供程序。您可以在 构建镜像 中了解如何操作。
生产镜像是在 DockerHub 中根据发布的版本和发布候选版本构建的。也有从分支发布的镜像，但它们主要用于开发和测试目的。有关详细信息，请参阅 Airflow Git 分支策略。
发布时的镜像修复¶
发布的“版本化”参考镜像在 Airflow 版本发布时基本固定，仅在特殊情况下更新。例如，当我们发现存在可能阻止重要的 Airflow 或嵌入式提供程序功能正常工作的依赖项错误时。正常情况下，即使发布了新版本的 Airflow 依赖项，镜像在发布后也不会更改——即使这些新版本包含关键安全修复。Airflow 的发布流程旨在在适用时自动升级依赖项，但这只发生在发布 Airflow 新版本时，而不是针对已发布的版本。
如果我的安全扫描显示镜像中存在关键和高危漏洞，我该怎么办？¶
我们经常听到用户使用各种安全扫描工具扫描镜像，发现镜像中存在一些关键和高危漏洞——这些漏洞并非来自 Airflow 本身，而是来自其他一些组件。一般来说，在镜像发布和固定后发现此类漏洞是正常且预期的——这正是因为我们在镜像发布后 不会 进行更新，如上所述。此外，有时即使是最新版本也包含在我们使用的基础镜像或我们使用的且无法升级的依赖项中尚未修复的漏洞，因为我们的一些提供程序有版本限制，尚未完成升级，对此我们无法控制。因此，即使是我们镜像的最新版本，也可能存在一些尚未修复的高危和关键漏洞。
在这种情况下，您能做些什么？
首先——您应该知道 不该 做什么。
不要 将扫描结果私下发送电子邮件给 Airflow 安全团队，询问该怎么办。Airflow 的安全团队仅负责 Airflow 本身未披露的漏洞，而不负责依赖项或基础镜像中的漏洞。安全电子邮件仅应用于私下报告可通过 Airflow 被利用的任何安全问题。我们的 安全策略 中对此有详细说明，您可以在其中找到更多详情，包括需要提供可重现的场景以及 每封邮件提交一个问题。切勿 在一封邮件中提交多个漏洞——这些将被立即拒绝，因为这会使处理问题的过程对包括报告者在内的所有人来说都更加困难。
同样，不要 在 GitHub Issue 中发布扫描结果并询问该怎么办。GitHub Issue 用于报告 Airflow 本身的问题和功能请求，而不是用于寻求有关第三方组件安全扫描的帮助。
那么您有哪些选择？
您有四种选择：
按照我们分享的示例构建您自己的自定义镜像——使用最新的基础镜像，并可能手动提升您想要提升的依赖项版本。在 构建镜像 中有很多示例供您参考。您可以使用“slim”镜像作为您自己镜像的基础，而不是基于安装了大量附加功能包和提供程序的“参考”镜像，您只需安装您实际需要的，并升级一些否则无法升级的依赖项——因为一些提供程序库有版本限制，尚未完成升级，对此我们无法控制。这是构建您自己镜像最灵活的方式，您可以将此过程与快速升级到最新的 Airflow 版本（见下文第 2 点）结合起来。
等待新版本的 Airflow 并升级。Airflow 镜像在发布时会更新到最新的“无冲突”依赖项，并使用最新的“基础”镜像，因此我们在发布镜像/版本时，参考镜像中包含的是当前在使用我们所用基础平台（我们使用的参考镜像是 Debian Bookworm）上可获得的“最新最优”内容。这是您可以采取的一个很好的策略——建立一个定期升级 Airflow 版本的流程——在社区发布后尽快升级，这将帮助您跟上依赖项中的最新安全修复。
如果我们使用的基础平台（当前为 Debian Bookworm）不包含您想要的最新版本，并且您想使用其他基础镜像，您可以查看最新 Airflow
Dockerfile中安装的系统依赖项和脚本，从中获取灵感，构建您自己的镜像或复制并根据您的需要进行修改。请参阅最新版本的 Dockerfile。研究该漏洞是否影响您。即使存在具有高危或关键漏洞的依赖项，也并不意味着它可以在 Airflow 中被利用（或特别是在您使用 Airflow 的方式中）。如果您确实有关于如何在 Airflow 中利用漏洞的可重现场景，您当然应该私下将其报告给安全团队。但如果您没有可重现的场景，请进行一些研究，尝试了解该漏洞对 Airflow 的影响。您的研究如果表明 Airflow 可能不受影响，可以在公共 GitHub Discussion 中讨论该漏洞的影响；如果您找到了如何利用它的可重现场景，则可以发送私有安全电子邮件。
如何在公共场合讨论镜像中的公共 CVE？
安全扫描报告的是 Airflow 第三方组件中的公共漏洞。由于这些已经是公共漏洞，您可以讨论它，其他人也在讨论。所以您可以先自己进行研究。尝试查找关于这些问题的讨论，了解其他人是如何处理的，甚至可以尝试探索该漏洞是否可以在 Airflow 中被利用。这是一项非常有价值的社区贡献，您可以借此帮助其他人理解漏洞对 Airflow 的影响。我们高度赞赏我们的商业用户这样做，因为 Airflow 由志愿者维护，所以如果您或您的公司能够投入一些安全研究人员的时间和技能来帮助社区理解漏洞对 Airflow 的影响，这将是对社区的巨大贡献，也是回馈您公司免费使用的项目的一种方式。
您可以自由地公开讨论，开启一个 GitHub Discussion，说明您的发现和迄今为止所做的研究。理想情况下（作为对 Airflow 的贡献方式），您应该解释您公司内部安全团队的发现，以帮助研究和理解该漏洞对 Airflow（以及您的使用方式）的影响。再次强调——强烈建议 每个漏洞开启一个讨论。您不应批量发布扫描结果——这不利于讨论，如果您尝试在一个讨论串中讨论所有问题，您将不会得到有意义的答案。
是的——我们知道复制粘贴结果并询问他人该怎么办是最简单的方式，但这很可能导致无人回应，因为社区认为这种行为是相当自私的，通过占用其他志愿者的时间来解决您的问题，而您却没有花时间让志愿者更容易提供帮助。如果您确实想获得社区的帮助，请将讨论重点放在特定的 CVE 上，提供您的发现——包括详细分析您的报告，找出是哪些二进制文件和基础镜像导致扫描工具报告了该漏洞。请记住，只有您有权访问您的扫描工具，您应该提供尽可能多的有用信息，以便其他人能够对此发表评论。表明您已经做了功课，并且正在为社区带来有价值的信息。
为这类问题开启一个 GitHub Discussion 也是与维护者和安全团队进行公开透明沟通的绝佳方式——无需诉诸于私有安全邮件列表（如上所述，其用途不同），也无需使用专门用于 Airflow 本身问题而非第三方组件公共安全问题的 GitHub Issue。
支持¶
参考 Docker 镜像支持以下平台和数据库：
Intel 平台 (x86_64)¶
Postgres 客户端
MySQL 客户端
MSSQL 客户端
ARM 平台 (aarch64)¶
ARM 支持是实验性的，可能随时更改。
Postgres 客户端
MySQL 客户端 (MySQL 8)
MSSQL 客户端
请注意，arm 上的 MySQL 通过 MariaDB 客户端库提供实验性支持。
用法¶
AIRFLOW_HOME 默认设置为 /opt/airflow/ ——这意味着 dags 默认位于 /opt/airflow/dags 文件夹中，logs 位于 /opt/airflow/logs 中。
工作目录默认设置为 /opt/airflow。
如果未设置 AIRFLOW__DATABASE__SQL_ALCHEMY_CONN 变量，则会在 ${AIRFLOW_HOME}/airflow.db 中创建一个 SQLite 数据库。
有关启动 Airflow 的示例命令，请参阅： 执行命令。
Airflow 作为分布式应用需要许多组件才能运行。因此，您可能也会对在 Docker Compose 环境中启动 Airflow 感兴趣，请参阅： 在 Docker 中运行 Airflow。
您也可以在 Helm Chart 中使用此镜像。