_images/docker-logo.png

Apache Airflow 的 Docker 镜像

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

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

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

  • apache/airflow:latest - 最新发布的 Airflow 镜像，带有默认 Python 版本（当前为 3.8）

  • apache/airflow:latest-pythonX.Y - 最新发布的 Airflow 镜像，带有特定 Python 版本

  • apache/airflow:2.10.4 - 版本化的 Airflow 镜像，带有默认 Python 版本（当前为 3.8）

  • apache/airflow:2.10.4-pythonX.Y - 版本化的 Airflow 镜像，带有特定 Python 版本

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

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

  • apache/airflow:slim-latest - 最新发布的 Airflow 精简镜像，带有默认 Python 版本（当前为 3.8）

  • apache/airflow:slim-latest-pythonX.Y - 最新发布的 Airflow 精简镜像，带有特定 Python 版本

  • apache/airflow:slim-2.10.4 - 版本化的 Airflow 精简镜像，带有默认 Python 版本（当前为 3.8）

  • apache/airflow:slim-2.10.4-pythonX.Y - 版本化的 Airflow 精简镜像，带有特定 Python 版本

作为方便包提供的 Apache Airflow 镜像针对大小进行了优化，它仅提供最基本的额外组件和依赖项，在大多数情况下，您需要扩展或自定义该镜像。您可以在 软件包额外组件参考 中查看所有可能的额外组件。Airflow 生产镜像中使用的额外组件集在 Dockerfile 中提供。

但是，Airflow 有 60 多个社区管理的提供程序（可通过额外组件安装），并且并非每个人都使用某些默认的额外组件/提供程序，有时需要其他额外组件/提供程序，有时（实际上非常频繁）您需要添加自己的自定义依赖项、软件包甚至是自定义提供程序。您可以在 构建镜像 中了解如何操作。

生产镜像是在 DockerHub 中从发布的版本和候选版本构建的。还有从分支发布的镜像，但它们主要用于开发和测试目的。有关详细信息，请参阅 Airflow Git 分支。

在发布时修复镜像

当发布 Airflow 版本时，发布的“版本化”参考镜像大多是 固定的，我们仅在特殊情况下更新它们。例如，当我们发现可能阻止重要的 Airflow 或嵌入式提供程序功能工作的依赖项错误时。在正常情况下，即使发布了新版本的 Airflow 依赖项，镜像也不会在发布后更改，甚至在这些版本包含关键安全修复程序时也不会更改。Airflow 发布过程旨在在适用的情况下自动升级依赖项，但仅当我们发布新版本的 Airflow 时，而不是针对已发布的版本。

如果我的安全扫描显示镜像中存在严重和高危漏洞，我该怎么办？

我们经常听到用户在镜像上使用各种安全扫描程序，并发现镜像中存在一些严重和高危漏洞的问题 - 不是来自 Airflow，而是来自其他组件。一般来说，这是正常的，并且预期在镜像发布和修复后会在镜像中发现此类漏洞 - 正是由于我们不会在如上所述发布后更新镜像。有时，即使是最新版本，也包含我们使用的基础镜像或我们使用的依赖项中尚未修复的漏洞，并且无法升级，因为我们的一些提供程序有局限性并且尚未设法升级，我们无法控制。因此，即使是我们镜像的最新版本，也可能存在一些尚未修复的高危和严重漏洞。

在这种情况下，您可以做什么？

首先 - 您应该知道您不应该做什么。

请勿向 Airflow 安全团队发送包含扫描结果并询问该怎么做的私人电子邮件。Airflow 的安全团队仅负责处理 Airflow 本身中未公开的漏洞，而不是依赖项或基础镜像中的漏洞。安全电子邮件仅应用于私下报告任何可以通过 Airflow 利用的安全问题。这在我们的 安全策略 中得到了很好的解释，您可以在其中找到更多详细信息，包括需要提供可重现的场景并每封电子邮件提交一个问题。切勿在一封电子邮件中提交多个漏洞 - 它们会被立即拒绝，因为它们使每个人（包括报告者）处理问题的过程变得更加困难。

也不要打开一个 GitHub 问题，其中包含扫描结果并询问该怎么做。GitHub 问题用于向 Airflow 本身报告错误和功能请求，而不是用于请求有关第三方组件安全扫描的帮助。

那么您有哪些选择？

您有四种选择

  1. 按照我们在此处分享的示例构建您自己的自定义镜像 - 使用最新的基础镜像，并可能手动提升您想要提升的依赖项。在 构建镜像 中有许多示例，您可以遵循这些示例。您可以使用“精简”镜像作为您的镜像的基础，而不是将您的镜像基于安装了许多额外组件和提供程序的“参考”镜像，您可以只安装您实际需要的组件并升级一些依赖项，否则这些依赖项将无法升级 - 因为某些提供程序库有限制并且尚未设法升级，我们无法控制。这是构建镜像的最灵活的方式，您可以构建您的流程，将其与快速升级到最新 Airflow 版本相结合（请参阅下面的第 2 点）。

  2. 等待新版本的 Airflow 并升级到它。Airflow 镜像会在发布时更新为最新的“非冲突”依赖项并使用最新的“基础”镜像，因此我们在发布镜像/发布版本时，参考镜像中包含的是当时可用的“最新最好的”版本，并带有我们使用的基础平台（Debian Bookworm 是我们使用的参考镜像）。这是您可以采取的良好策略之一 - 构建一个流程以定期升级您的 Airflow 版本 - 在社区发布后尽快升级，这将帮助您及时了解依赖项中的最新安全修复程序。

  3. 如果我们使用的基础平台（当前为 Debian Bookworm）不包含您想要的最新版本，并且您想使用其他基础镜像，您可以查看安装了哪些系统依赖项以及最新 Dockerfile 中的脚本，并从中获得灵感并构建您自己的镜像或复制它并根据您的需要进行修改。请参阅 Dockerfile 以获取最新版本。

  4. 研究漏洞是否会影响您。即使存在具有高危或严重漏洞的依赖项，也并不意味着它可以在 Airflow 中被利用（或特别是在您使用 Airflow 的方式中）。如果您确实有一个关于如何在 Airflow 中利用漏洞的可重现场景，您当然应该私下向安全团队报告。但是，如果您没有可重现的场景，请进行一些研究并尝试了解该漏洞对 Airflow 的影响。如果您的研究表明 Airflow 可能不受影响，则该研究可能会引发公开的 GitHub 讨论，您可以在其中讨论漏洞的影响；如果您找到关于如何利用该漏洞的可重现场景，则该研究可能会引发私下安全电子邮件。

我如何在公开场合讨论镜像中的公开 CVE？

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

您可以自由地公开讨论它，打开一个 GitHub 讨论，提及您迄今为止的发现和研究。理想情况下（作为对 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 中使用此镜像。

此条目是否有帮助？