适用于 Apache Airflow 的 Docker 镜像¶

为了便于在生产环境中部署，社区发布了一个生产就绪的参考容器镜像。

Apache Airflow 社区发布了 Docker 镜像，这些镜像作为 Apache Airflow 的参考镜像。每次发布新版本的 Airflow 时，都会在 apache/airflow DockerHub 中为所有受支持的 Python 版本准备镜像。

您可以在那里找到以下镜像（假设 Airflow 版本为 2.9.2）

apache/airflow:latest - 具有默认 Python 版本（当前为 3.8）的最新发布的 Airflow 镜像
apache/airflow:latest-pythonX.Y - 具有特定 Python 版本的最新发布的 Airflow 镜像
apache/airflow:2.9.2 - 具有默认 Python 版本（当前为 3.8）的版本化的 Airflow 镜像
apache/airflow:2.9.2-pythonX.Y - 具有特定 Python 版本的版本化的 Airflow 镜像

这些是“参考”常规镜像。它们包含用户经常使用的最常见的额外组件、依赖项和提供程序集，当您只想试用 Airflow 时，它们非常适合“试用”，

您还可以使用“slim”镜像，它们只包含核心 airflow，大小约为“常规”镜像的一半，但您需要通过构建镜像单独添加所有需要的软件包额外组件参考和提供程序。

apache/airflow:slim-latest - 具有默认 Python 版本（当前为 3.8）的最新发布的 Airflow 镜像
apache/airflow:slim-latest-pythonX.Y - 具有特定 Python 版本的最新发布的 Airflow 镜像
apache/airflow:slim-2.9.2 - 具有默认 Python 版本（当前为 3.8）的版本化的 Airflow 镜像
apache/airflow:slim-2.9.2-pythonX.Y - 具有特定 Python 版本的版本化的 Airflow 镜像

作为便利包提供的 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）不包含您想要的最新版本，并且您想使用其他基础镜像，您可以查看安装了哪些系统依赖项以及最新 Dockerfile 中的脚本，并从中汲取灵感，构建您自己的镜像，或者复制它并根据您的需要进行修改。有关最新版本，请参阅 Dockerfile。
研究漏洞是否会影响您。即使存在具有高危或严重漏洞的依赖项，也不意味着它可以在 Airflow 中被利用（或者特别是在您使用 Airflow 的方式中）。如果您确实有一个可重现的场景，说明如何在 Airflow 中利用漏洞，那么您当然应该私下向安全团队报告。但是，如果您没有可重现的场景，请进行一些研究，并尝试了解漏洞对 Airflow 的影响。这项研究可能会导致公开的 GitHub 讨论，如果您在研究中表明 Airflow 可能不受影响，您可以在其中讨论漏洞的影响，或者如果您找到了如何利用漏洞的可重现场景，则可以发送私人安全电子邮件。

我如何公开讨论镜像中的公共 CVE？

安全扫描报告了 Airflow 第三方组件中的公共漏洞。由于这些已经是公开的漏洞，因此您可以谈论这些漏洞，但其他人也在谈论这些漏洞。所以您可以先自己做些研究。尝试查找有关这些问题的讨论，其他人是如何处理这些问题的，甚至可以尝试探索这些漏洞是否可以在 Airflow 中被利用。这是您可以为社区做出的一项非常宝贵的贡献，可以帮助其他人了解漏洞对 Airflow 的影响。我们非常感谢我们的商业用户这样做，因为 Airflow 是由志愿者维护的，因此，如果您或您的公司能够花一些时间和安全研究人员的技能来帮助社区了解漏洞对 Airflow 的影响，这将是对社区的巨大贡献，也是回馈贵公司免费使用的项目的一种方式。

您可以自由地公开讨论，打开一个 GitHub 讨论，提及您的发现和迄今为止所做的研究。理想情况下（作为对 Airflow 做出贡献的一种方式），您应该解释贵公司安全团队的发现，以帮助研究和了解漏洞对 Airflow（以及您使用 Airflow 的方式）的影响。再次强调 - 强烈建议每个漏洞打开一个讨论。您不应该批量发布扫描结果 - 这对讨论没有帮助，如果您试图在一个讨论线程中讨论所有问题，您将得不到有意义的答案。

是的，我们知道复制粘贴结果并询问他人该怎么做是最简单的方法，但这样做很可能会导致无人回应，因为在社区中，这种行为被视为一种非常自私的解决问题的方式，它利用了其他志愿者的时间，而你却没有花时间让他们更容易地提供帮助。如果你真的想从社区获得帮助，请将你的讨论集中在特定的 CVE 上，提供你的发现 - 包括详细分析你的报告，并找出究竟是哪些二进制文件和基础镜像导致扫描器报告漏洞。请记住，只有你可以访问你的扫描器，你应该提供尽可能多的有用信息，以便其他人可以对此发表评论。表明你已经做好了功课，并且你为社区带来了有价值的信息。

针对此类问题发起 GitHub 讨论也是一种以公开透明的方式与维护者和安全团队沟通的好方法 - 无需回复私人安全邮件列表（如上所述，该列表用于不同的目的）。如果在这样的讨论之后，有一种方法可以从扫描的镜像中删除这样的漏洞 - 太好了，你甚至可以向 Dockerfile 贡献一个 PR，以从镜像中删除该漏洞。也许这样的讨论会导致一个 PR，允许 Airflow 升级到修复该漏洞或完全删除该漏洞的新依赖项，或者也许已经有一种方法可以缓解它，或者也许已经有一个 PR，有人正在努力修复它。所有这些都可以在 GitHub 讨论中公开透明地讨论，而不是通过私人安全电子邮件或 GitHub Issues，后者专门针对 Airflow 问题，而不是第三方组件的公共安全问题。

支持¶

参考 Docker 镜像支持以下平台和数据库

Intel 平台 (x86_64)¶

Postgres 客户端
MySQL 客户端
MSSQL 客户端

ARM 平台 (aarch64)¶

ARM 支持尚处于实验阶段，随时可能发生变化。

Postgres 客户端
MySQL 客户端 (MySQL 8)
MSSQL 客户端

请注意，ARM 上的 MySQL 通过 MariaDB 客户端库提供实验性支持。

用法¶

AIRFLOW_HOME 默认设置为 /opt/airflow/ - 这意味着 DAG 默认位于 /opt/airflow/dags 文件夹中，日志位于 /opt/airflow/logs 中

默认情况下，工作目录为 /opt/airflow。

如果未设置 AIRFLOW__DATABASE__SQL_ALCHEMY_CONN 变量，则会在 ${AIRFLOW_HOME}/airflow.db 中创建 SQLite 数据库。

有关启动 Airflow 的示例命令，请参阅：执行命令。

Airflow 需要许多组件才能正常工作，因为它是一个分布式应用程序。因此，你可能还有兴趣在 Docker Compose 环境中启动 Airflow，请参阅：在 Docker 中运行 Airflow。

你也可以在 Helm Chart 中使用此镜像。