生产部署

现在是将 DAG 部署到生产环境的时候了。在此之前，您首先需要确保 Airflow 本身已做好生产就绪准备。让我们看看您需要采取哪些预防措施。

数据库后端

Airflow 默认附带 SQLite 后端。这允许用户无需任何外部数据库即可运行 Airflow。然而，这种设置仅用于测试目的；在生产环境中运行默认设置可能会导致多种情况下的数据丢失。如果您想运行生产级的 Airflow，请确保您将后端配置为外部数据库，例如 PostgreSQL 或 MySQL。

您可以使用以下配置更改后端：

[database]
sql_alchemy_conn = my_conn_string

更改后端后，Airflow 需要创建操作所需的所有表。请创建一个空的数据库，并授予 Airflow 用户 CREATE/ALTER 权限。完成后，您可以运行 -

airflow db migrate

migrate 会跟踪已应用的迁移，因此可以根据需要随时运行它。

警告

在 Airflow 2.7.0 版本之前，airflow db upgrade 用于应用迁移，但它已被弃用，转而使用 airflow db migrate。

多节点集群

Airflow 默认使用 LocalExecutor。对于多节点设置，您应该使用 Kubernetes 执行器 或 Celery 执行器。

配置执行器后，必须确保集群中的每个节点都包含适合其角色的 DAG 和配置。Airflow 发送类似“执行 DAG Y 的任务 X”这样的简单指令，但不会发送任何 DAG 文件或配置。为了同步 DAG，我们建议使用 DAG Bundle 机制（包括 GitDagBundle），这允许您利用 DAG 版本控制。对于对安全性敏感的部署，请限制敏感配置（JWT 签名密钥、数据库凭据、Fernet 密钥），仅将其提供给需要的组件，而不是在所有节点之间共享所有配置 —— 有关指导，请参阅 Airflow 安全模型。

Logging

如果您在集群中使用临时节点，请将日志存储配置为分布式文件系统 (DFS)，例如 S3 和 GCS，或使用外部服务，如 Stackdriver Logging、Elasticsearch 或 Amazon CloudWatch。这样，即使节点宕机或被替换，日志仍然可用。请参阅 任务日志记录 获取配置信息。

注意

只有在任务完成后，日志才会出现在您的 DFS 中。在任务运行期间，您可以在 UI 本身中查看日志。

配置

Airflow 附带一个默认的 airflow.cfg 配置文件。对于在不同部署中会变化的配置（例如元数据数据库、密码等），您应该使用环境变量。您可以使用格式 AIRFLOW__{SECTION}__{KEY} 来实现这一点。

AIRFLOW__DATABASE__SQL_ALCHEMY_CONN=my_conn_id
AIRFLOW__API__BASE_URL=http://host:port

某些配置（如 Airflow 后端连接 URI）也可以通过 bash 命令推导出来。

sql_alchemy_conn_cmd = bash_command_to_run

调度程序正常运行时间

Airflow 用户偶尔会报告调度程序毫无征兆地挂起的情况，例如在这些议题中：

为了缓解这些问题，请确保设置了健康检查，该检查将检测调度程序是否已有一段时间没有心跳。

生产级容器镜像

我们提供 用于 Apache Airflow 的 Docker 镜像 (OCI)，供在容器化环境中使用。考虑使用它以确保无论部署在何处，软件的运行方式都始终保持一致。

用于 Kubernetes 的 Helm Chart

Helm 提供了一种将软件部署到 Kubernetes 集群的简单机制。我们维护着 官方 Airflow Helm chart，帮助您定义、安装和升级部署。该 Helm Chart 使用 我们由社区维护和发布的官方 Docker 镜像和 Dockerfile。

Airflow 在线升级

Airflow 本质上是一个分布式系统，虽然 基础 Airflow 部署 通常需要完整的 Airflow 重启才能升级，但当您在 分布式部署 中运行 Airflow 时，是可以实现无停机升级的。

当 Airflow 元数据数据库架构没有更改时，这种在线升级是可能的，因此您应该尝试在升级相同次要版本的 Airflow 补丁级（错误修复）版本时，或者在查阅了 发布说明 和 数据库迁移参考 并确保它们之间没有数据库架构更改的情况下，在相邻的次要版本（功能）之间升级时执行此操作。

在某些数据库迁移不显著的情况下，在升级 Airflow 数据库之后以及在 MINOR 版本之间进行在线迁移也是有可能的，但这不推荐，您应该自担风险，仔细检查要应用于数据库架构的修改，并评估此类升级的风险——这需要对 Airflow 数据库 ERD 架构 有深入的了解，并查阅 数据库迁移参考。您应该始终先在测试环境中彻底测试此类升级。通常，为此类在线升级所做的准备成本要高于 Airflow 短暂停机的成本，因此我们强烈不建议进行此类在线升级。

在生产环境中执行之前，请务必在测试环境中测试此在线升级程序，以避免任何意外和副作用。

在在线升级 Webserver 和 Triggerer 组件时，如果您在不同的环境中运行它们，并且每个组件都有多个实例，则可以逐个进行滚动重启，而无需停机。这通常应作为升级程序的第一步。

当您在 独立 DAG 处理部署 中运行带有独立 Dag processor 的部署时，Dag processor 不会进行水平扩展——即使您有多个处理器，通常每个特定文件夹一次也只有一个 Dag processor 在运行，因此您可以直接停止它并启动一个新的——但由于 Dag processor 不是关键组件，经历短暂的停机是可以接受的。

在升级调度程序和工作节点时，可以使用您所使用的执行器的在线升级功能。

  • 对于 Local 执行器，您的任务作为调度程序的子进程运行，您无法在不终止其所运行的任务的情况下升级调度程序。您可以暂停所有 DAG 并等待运行中的任务完成，或者直接停止调度程序并终止它运行的所有任务——然后在升级完成后手动清理并重启这些任务（或者依赖为停止的任务设置的 retry 重试机制）。

  • 对于 Celery 执行器，您必须首先将工作节点置于离线模式（通常通过向工作节点发送单个 TERM 信号），等待工作节点完成所有正在运行的任务，然后升级代码（例如，通过替换工作节点运行的镜像并重启工作节点）。您可以通过 flower 监控工具监控您的工作节点，查看正在运行的任务数量降至零。一旦工作节点升级完毕，它们将自动进入在线模式并开始接收新任务。然后，您可以以滚动重启模式升级 Scheduler。

  • 对于 Kubernetes 执行器，您可以以滚动重启模式升级调度程序、触发器和 Web 服务器，通常无需担心工作节点，因为它们由 Kubernetes 集群管理，并且会在调度程序升级和重启时被自动接管。

大多数滚动重启升级场景已在 Apache Airflow 的 Helm Chart 中实现，因此您可以使用它在零停机的情况下升级您的 Airflow 部署——特别是在进行 Airflow 补丁级升级时。

Kerberos 认证工作节点

Apache Airflow 具有内置机制，用于向 KDC（密钥分发中心）进行操作认证。Airflow 有一个单独的命令 airflow kerberos，充当令牌刷新器。它使用预配置的 Kerberos Keytab 在 KDC 中进行认证以获取有效令牌，然后在当前令牌到期窗口内的定期时间间隔内刷新有效令牌。

每次刷新请求都使用配置的主体（principal），并且只有对指定主体有效的 Keytab 才能检索认证令牌。

在这种情况下实现适当安全机制的最佳实践是：确保工作节点负载无法访问 Keytab，而只能访问定期刷新的临时认证令牌。在 Docker 环境中，可以通过在单独的容器中运行 airflow kerberos 命令和工作节点命令来实现——只有 airflow kerberos 令牌有权访问 Keytab 文件（最好配置为 secret 资源）。这两个容器应共享一个卷，临时令牌由 airflow kerberos 写入，并由工作节点读取。

在 Kubernetes 环境中，这可以通过 Sidecar 概念实现，即 Kerberos 令牌刷新器和工作节点作为同一个 Pod 的一部分。只有 Kerberos Sidecar 有权访问 Keytab secret，并且同一个 Pod 中的两个容器共享一个卷，临时令牌由 Sidecar 容器写入，并由工作节点容器读取。

此概念已在 Apache Airflow 的 Helm Chart 中实现。

Google Cloud 上的安全服务器和服务访问

本节介绍当您的 Airflow 环境部署在 Google Cloud 上、连接到 Google 服务或连接到 Google API 时，用于安全访问服务器和服务的技术与解决方案。

IAM 和服务账户

您不应将内部网络分段或防火墙作为我们的主要安全机制。为了保护您组织的数据，您发出的每个请求都应包含发送者身份。对于 Google Cloud，该身份由 IAM 和服务账户提供。每个 Compute Engine 实例都有关联的服务账户身份。它提供了加密凭据，您的工作负载在调用 Google API 或第三方服务时可以使用这些凭据证明其身份。每个实例只能访问短期凭据。如果您使用 Google 管理的服务账户密钥，则私钥始终由系统托管，永远不会直接可见。

如果您使用 Kubernetes Engine，可以使用 Workload Identity 为各个 Pod 分配身份。

有关 Airflow 中服务账户的更多信息，请参阅 Google Cloud 连接

模拟服务账户

如果您需要访问其他服务账户，可以模拟其他服务账户，将默认身份的令牌交换为另一个服务账户的令牌。这样，账户密钥仍由 Google 管理，且无法被您的工作负载读取。

不建议生成服务账户密钥并将它们存储在元数据数据库或 secret 后端中。即使使用了后端 secret，服务账户密钥对于您的工作负载也是可见的。

访问 Compute Engine 实例

如果您想建立到 Compute Engine 实例的 SSH 连接，则必须拥有该实例的网络地址和访问凭据。为简化此任务，您可以使用 ComputeEngineHook 代替 SSHHook

ComputeEngineHook 支持使用 Google OS Login 服务进行授权。这是一种极其实用的方法，可以妥善管理 Linux 访问权限，因为它在元数据服务中存储短期 SSH 密钥，提供用于访问和 sudo 权限检查的 PAM 模块，并提供对元数据服务的 nsswitch 用户查找功能。

它还解决了随基础设施增长而产生的发现问题。您可以使用实例名称代替网络地址。

访问 Amazon Web Service

多亏了 Web Identity Federation（Web 身份联盟），您可以将 Google Cloud Platform 身份交换为 Amazon Web Service 身份，这意味着可以有效访问 Amazon Web Service 平台。有关更多信息，请参阅：使用 Web 身份联盟的 Google Cloud 到 AWS 认证

此条目是否有帮助？