Apache Airflow 的 Docker 镜像¶
为方便在生产环境部署，社区发布了可直接用于生产的参考容器镜像。
Apache Airflow 社区发布的 Docker 镜像是reference images（参考镜像）。每当 Airflow 发布新版本时，都会在apache/airflow DockerHub上为所有受支持的 Python 版本准备相应镜像。
我们发布的镜像为多平台 AMD/ARM 镜像。
参考镜像的默认 Python 版本——即当未指定 Python 版本时使用的——是 Airflow 发布时支持的最新 Python 版本，且能够兼容在常规参考镜像中已发布的所有 provider。
例如，即使我们在 Airflow 3.0 中加入了对 Python 3.13 的支持，但常规参考镜像中默认安装的某些 provider 并未支持 Python 3.13，此时该镜像的“默认”Python 版本应仍为 Python 3.12。
“slim” 镜像同样遵循此规则。
下面是可用的镜像（假设 Airflow 版本为 3.2.0）
apache/airflow:latest- 带有默认 Python 版本的最新发布的 Airflow 镜像（当前为 3.12）apache/airflow:latest-pythonX.Y- 带有指定 Python 版本的最新发布的 Airflow 镜像apache/airflow:3.2.0- 带有默认 Python 版本的特定版本 Airflow 镜像（当前为 3.12）apache/airflow:3.2.0-pythonX.Y- 带有指定 Python 版本的特定版本 Airflow 镜像
这些是“参考”常规镜像。它们包含了用户最常使用的一套 extras、依赖和 provider，适合在想快速试用 Airflow 时使用。
您也可以使用仅包含核心 Airflow 的 “slim” 镜像，它的体积约为“常规”镜像的一半，但需要自行通过构建镜像添加包 extras 参考以及所需的 provider。
apache/airflow:slim-latest- 带有默认 Python 版本的最新发布的 Airflow “slim” 镜像（当前为 3.12）apache/airflow:slim-latest-pythonX.Y- 带有指定 Python 版本的最新发布的 Airflow “slim” 镜像apache/airflow:slim-3.2.0- 带有默认 Python 版本的特定版本 Airflow “slim” 镜像（当前为 3.12）apache/airflow:slim-3.2.0-pythonX.Y- 带有指定 Python 版本的特定版本 Airflow “slim” 镜像
作为便利包提供的 Apache Airflow 镜像经过了体积优化，仅安装了最小化的 extras 和依赖，在大多数情况下您需要对其进行扩展或自定义。所有可选的 extras 请参见包 extras 参考。Airflow 生产镜像所使用的 extras 集合可在Dockerfile 中查看。
然而，Airflow 拥有超过 60 个社区维护的 provider（通过 extras 可安装），其中一些默认的 extras/provider 并非所有人都需要，另外还有一些 extras/provider 是必须的，且（实际上经常）需要添加自定义依赖、包或自定义 provider。您可以在构建镜像章节了解如何操作。
生产镜像通过 DockerHub 从正式版和候选版构建。也会有来自分支的镜像发布，但主要用于开发和测试。详细信息请参见Airflow Git 分支策略。
在发布时固定镜像¶
已发布的“有版本号”的参考镜像在我们发布 Airflow 版本时大多是fixed（固定）的，只有在特殊情况下才会更新。例如，当我们发现某些依赖错误可能导致 Airflow 或内嵌 provider 的关键功能失效时才会进行修改。正常情况下，镜像在发布后不会再改变，即便后续出现了包含关键安全修复的依赖新版本也不会自动更新。Airflow 的发布流程是围绕在需要时自动升级依赖——仅在我们发布新版本的 Airflow 时进行，而不会针对已发布的旧版本再做更新。
如果安全扫描显示镜像中存在严重（critical）和高危（high）漏洞，我该怎么办？¶
我们经常收到用户使用各种安全扫描工具对镜像进行检查后，发现镜像中存在一些严重或高危漏洞的询问——这些漏洞并非来源于 Airflow 本身，而是其他组件的。总体而言，这类在镜像发布后才被发现并修复的漏洞是正常且预期的，因为正如上文所述，我们**不**在镜像发布后进行更新。有时即使是最新的镜像，也可能因为我们使用的基础镜像或依赖尚未修复而包含漏洞，原因在于部分 provider 对依赖版本有上限，尚未能升级，我们也无法控制。因此，即使是最近的镜像，仍可能存在尚未修复的 High 和 Critical 等级漏洞。
面对这种情况，我可以做些什么？
首先——您需要了解**不要**做的事情。
不要向 Airflow 安全团队发送包含扫描结果的私人邮件并询问该怎么处理。Airflow 的安全团队只负责处理 Airflow 本身的未公开漏洞，并不负责依赖或基础镜像的安全问题。安全邮件仅用于私下报告可通过 Airflow 被利用的安全缺陷。相关细则请参考我们的安全政策，其中说明了需提供可复现的情景且每封邮件只能提交**一个**问题。**绝不可**在一封邮件中提交多个漏洞——这种做法会立即被拒绝，因为它会极大增加处理难度。
同样，请不要在 GitHub 上打开 Issue 并附上扫描结果，询问该如何处理。GitHub Issue 仅用于报告 Airflow 本身的缺陷或功能需求，而非第三方组件的安全扫描求助。
那么，我有哪些选择？
您有四种可选方案：
1. 按照我们提供的示例自行构建自定义镜像——使用最新的基础镜像，并根据需要手动升级想要提升的依赖。构建镜像章节中提供了大量示例。您可以以 “slim” 镜像作为构建基底，而不是在已经预装大量 extras 和 provider 的 “reference” 镜像上再进行修改。这样您只会安装真正需要的内容，并且能够升级那些在官方镜像中受限而无法升级的依赖——因为某些 provider 的库存在上限且我们无法控制。此方式最为灵活，且您可以将其与快速升级至最新 Airflow 版本的流程结合（见下文第 2 点）。
2. 等待 Airflow 的新版本并进行升级。Airflow 镜像在发布时会使用最新版的“非冲突”依赖，并基于最新的基础镜像（我们默认使用 Debian Bookworm）。因此，您拿到的参考镜像始终是当时可用的 “最新、最好的” 组合。建议您建立一个流程， 在社区发布新版本后立即升级，这样可以及时获取依赖中的最新安全修复。
3. 如果当前使用的基础平台（目前为 Debian Bookworm）不包含您需要的最新版本，且您想使用其他基础镜像，可以查看最新的
Dockerfile中安装的系统依赖和脚本，从中获取灵感并自行构建镜像或在此基础上进行修改。最新的 Dockerfile 请参考Dockerfile。4. 评估该漏洞是否真的影响到您。即使某个依赖被标记为 High 或 Critical，并不一定意味着它可以在 Airflow（或您具体使用的方式）中被利用。如果您拥有可复现的利用场景，请务必**私下**向安全团队报告。但若没有明确的复现路径，请自行研究漏洞对 Airflow 的实际影响。研究结果可在 GitHub Discussion 中公开讨论——如果研究表明 Airflow 可能不受影响，也可以仅通过私密安全邮件报告可复现的利用方式。
我该如何在公开渠道讨论镜像中的公开 CVE？
安全扫描报告的都是第三方组件的公开漏洞。既然这些漏洞已经公开，您完全可以在社区中进行讨论——与此同时，其他人也在讨论。建议您先自行调研，查找已有的讨论、他人的处理方式，甚至尝试验证该漏洞在 Airflow 中是否真的可被利用。这类调研对社区贡献巨大，特别是对商业用户而言，更是帮助志愿者们了解漏洞影响的宝贵资源，因为 Airflow 完全由志愿者维护，您的研究可以为项目的安全生态注入重要力量。
您可以在GitHub Discussion 中公开发起讨论，说明您已完成的调查和研究成果。作为对 Airflow 的贡献，最好围绕单个漏洞开启**一个**讨论，切勿一次性发布大量扫描结果——这会使讨论难以进行，也难以得到有价值的回复。
我们知道直接复制粘贴扫描结果并求助的方式非常快捷，但这种做法往往只会得到沉默，因为它被视为一种自私的行为——把解决问题的时间全部寄望在其他志愿者身上，却不主动提供帮助信息。若想获得社区的帮助，请聚焦于具体的 CVE，提供您发现的细节——包括分析报告中哪些二进制文件或基础镜像触发了漏洞检测。记住，只有您自己才拥有扫描器的完整信息，提供越多有价值的线索，社区成员就越容易给出建设性的反馈。展示您已经完成的功课，说明您为社区带来了有价值的信息。
在此类问题上发起 GitHub Discussion 也是与维护者和安全团队进行公开、透明沟通的好方式——无需转向私人安全邮件列表（该列表有别的用途，已在上文说明）。如果通过讨论能够找到从镜像中移除该漏洞的方法，您甚至可以提交针对 Dockerfile 的 PR 来实际消除该漏洞。也可能因此产生一个 PR，使 Airflow 能升级到修复该漏洞的更高版本，或直接移除相关依赖。所有这些都应该在 GitHub Discussion 中公开讨论，而不是通过私人安全邮件或仅用于报告 Airflow 本身缺陷的 GitHub Issue。
支持¶
参考 Docker 镜像支持以下平台和数据库：
Postgres 客户端
MySQL 客户端（8 及以上）
MSSQL 客户端
请注意，MySQL 在 ARM 平台上仅通过 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 中使用此镜像。