Cloud Composer 概览

本页面简要介绍了 Cloud Composer 环境,以及 Apache Airflow 部署使用的 Google Cloud Platform 产品。

Cloud Composer 是以 Airflow 为基础构建的托管式工作流编排服务。与本地部署类似,Cloud Composer 会部署多个组件来运行 Airflow。本页面介绍了这些 GCP 组件及其功能,同时还说明了如何运行工作流。

此外,与本地部署类似,Cloud Composer 也依赖于特定配置来成功执行您的工作流。更改 Cloud Composer 所依赖的连接或通信配置可能会产生意想不到的后果或破坏 Airflow 部署。本文指出了一些重要的环境配置。

环境

Airflow 是以微服务为基础构建的一种框架。为了在分布式设置中部署 Airflow,Cloud Composer 预配了多个 GCP 组件,统称为 Cloud Composer 环境

环境是 Cloud Composer 中的一个核心概念。您可以在一个项目中创建一个或多个 Cloud Composer 环境。环境是以 Google Kubernetes Engine 为基础的独立 Airflow 部署。这些环境通过 Airflow 内置的连接器与 GCP 服务协同工作。

您可以在受支持的区域中创建 Cloud Composer 环境,并在 Compute Engine 地区中运行这些环境。对于简单用例,您可以在一个区域中创建一个环境。对于复杂用例,您可以在一个区域中创建多个环境,也可以跨多个区域创建多个环境。Airflow 通过其他 GCP 产品的公共 API 与这些产品进行通信。

架构

当您创建环境时,Cloud Composer 会在由 Google 管理的租户项目和客户项目之间分配环境的资源,具体如下图所示:

租户项目和客户项目中的 Cloud Composer 环境资源(点击可放大)
Cloud Composer 环境资源(点击可放大)

租户项目资源

为实现统一的 Cloud Identity and Access Management 访问权限控制,并提供一层额外的数据安全保护,Cloud Composer 会在租户项目中部署 Cloud SQL 和 App Engine。

Cloud SQL

Cloud SQL 用于存储 Airflow 元数据。为保护敏感连接和工作流信息,Cloud Composer 只会允许用于创建环境的默认或指定自定义服务帐号对数据库进行访问。为最大限度地降低丢失数据的可能性,Cloud Composer 每天都会对 Airflow 元数据进行备份。

只有用于创建 Cloud Composer 环境的服务帐号才能访问 Cloud SQL 数据库中的数据。如需远程向某一应用、客户端或其他 GCP 服务授予对 Cloud SQL 数据库的访问权限,您可以使用 Cloud Composer 提供的适用于 GKE 集群的 Cloud SQL 代理

App Engine

App Engine 柔性环境用于托管 Airflow Web 服务器。默认情况下,Airflow Web 服务器已与 Cloud Identity-Aware Proxy 集成。Composer 隐藏了 Cloud IAP 集成详细信息,并支持使用 Composer IAM 政策来管理 Web 服务器访问权限。如需仅授予对 Airflow Web 服务器的访问权限,您可以分配 composer.user 角色,也可以分配其他 Cloud Composer 角色,以提供对环境中的其他资源的访问权限。对于具有其他访问权限控制要求的组织,Cloud Composer 还支持在客户项目中部署自行管理的 Airflow Web 服务器

客户项目资源

Cloud Composer 会在客户项目中部署 Cloud Storage、Google Kubernetes Engine 和 Stackdriver。

Cloud Storage

Cloud Storage 提供用于暂存 DAG插件、数据依赖项和日志存储分区。为了部署工作流 (DAG),您需要将相关文件复制到与您的环境关联的存储分区。Cloud Composer 负责在工作器、调度器和 Web 服务器之间同步 DAG。使用 Cloud Storage,您可以将工作流工件存储在 data/logs/ 文件夹中,并保留对数据的完全访问控制权,而无需担心大小限制。

Google Kubernetes Engine

Cloud Composer 会在 GKE 集群中部署 Airflow 调度器、工作器节点和 CeleryExecutor 等核心组件。Redis 是 CeleryExecutor 的消息代理,它作为 StatefulSet 应用运行,旨在确保消息在容器重启后得到保留。

通过在 GKE 上运行调度器和工作器,您可以使用 KubernetesPodOperator 来运行任何容器工作负载。默认情况下,Cloud Composer 支持自动升级自动修复,从而保护 GKE 集群免受安全漏洞的影响。如果您需要在自动升级周期之前升级 Cloud Composer GKE 集群,可以执行手动升级

请注意,Airflow 工作器和调度器节点与 Airflow Web 服务器使用不同的服务帐号运行。

  • 调度器和工作器:如果您未在创建环境期间指定一个服务帐号,则系统将使用默认 Compute Engine 服务帐号运行环境。
  • Web 服务器:系统会在环境创建期间根据 Web 服务器网域自动生成一个服务帐号。例如,如果网域为 foo-tp.appspot.com,则服务帐号为 foo-tp@appspot.gserviceaccount.com

您可以在环境详情中查看 serviceAccountairflowUri 信息。

Stackdriver

Cloud Composer 集成了 Stackdriver Logging 和 Stackdriver Monitoring,因此您可以从一个中心位置查看所有 Airflow 服务和工作流日志

得益于 Stackdriver Logging 的流式传输特性,您可以立即查看由 Airflow 调度器和工作器发出的日志,而无需等待 Airflow 日志记录模块同步。此外,由于 Cloud Composer 的 Stackdriver 日志基于 google-fluentd,因此您可以访问调度器和工作器容器生成的所有日志。这些日志可提供实用的系统级和 Airflow 依赖项信息,从而大大改善了调试体验。

Stackdriver Monitoring 会从 Cloud Composer 中收集并提取指标、事件和元数据,并通过信息中心和图表生成数据洞见

重要配置信息

  • 某些 Airflow 参数已针对 Cloud Composer 环境进行了预配置,不得更改。对于其他参数,您可以在创建环境时进行配置。
  • Cloud Composer 在 Airflow 部署中使用的独立 GCP 产品需遵循的任何配额或限制也同样适用于您的环境。
  • Cloud Composer 依赖以下配置来成功执行工作流:
    • Cloud Composer 服务后端使用订阅通过 Cloud Pub/Sub 与其 GKE 服务代理进行协调,并依赖 Cloud Pub/Sub 的默认行为来管理消息。请勿删除 .*-composer-.* 主题。Cloud Pub/Sub 最多支持每个项目 1 万个主题
    • Cloud Composer 服务会与 Stackdriver 协调日志记录。如需限制 GCP 项目中的日志数,您可以停止所有日志提取。请勿停用 Stackdriver。
    • 请勿修改 Cloud Composer 服务帐号的 Cloud Identity and Access Management 政策绑定,例如 service-your-project-number@cloudcomposer-accounts.iam.gserviceaccount.com
    • 请勿更改 Airflow 数据库架构。
  • 您可以使用 gcloud 命令行工具运行 Airflow CLI。为避免影响数据库操作,请勿发出 resetdbinitdbupgradedb Airflow 命令。
  • 运行稳定 Airflow 版本的 Cloud Composer 版本可以包含从未来 Airflow 版本向后移植的 Airflow 更新
  • 与 Airflow Web 服务器相比,工作器和调度器节点具有不同的容量,并且使用不同的服务帐号。为避免 Airflow Web 服务器出现 DAG 故障,请勿在 DAG 解析时执行重量级计算或访问 Web 服务器无权访问的 GCP 资源。
  • 删除环境并不会删除客户项目中的以下数据:与您的环境关联的 Cloud Storage 存储分区和 Stackdriver 日志。为避免系统向您的 GCP 帐号收取费用,请根据需要导出和删除您的数据。

后续步骤

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Cloud Composer