了解 App Hosting 及其工作原理

App Hosting 会处理一系列复杂的后台任务，以简化应用的部署。本页介绍了该任务流程的关键部分，并提供了有关您可能需要根据应用需求自定义流程的位置的信息。

关键术语和定义

为了解 App Hosting 流程的详细信息，最好先明确定义一些术语。以下是基本关键术语：

  • 后端：App Hosting 为构建和运行 Web 应用而创建的代管式资源的集合。
  • build：应用的特定修订版本，通常与 git 提交相关联。创建 build 的过程包含许多子过程，其中最值得注意的是在 Cloud Build 中构建应用，以及在 Cloud Run 中部署修订版本（最初处理 0% 的流量，直到发布）。
  • 发布：将 build 设置为主动传送流量的过程。当由 git 提交自动触发时，App Hosting 会先使用活动分支创建 build，然后创建发布以将实时流量定向到该 build。
  • 实际分支：GitHub 代码库中部署到实际网址的分支。通常，它是功能分支或开发分支合并到的分支。

Google Cloud 和 App Hosting 架构

App Hosting 编排了一组 Google Cloud 产品，以便您部署、传送和监控 Web 应用。应用使用 Cloud Build 构建，在 Cloud Run 上传送，并缓存在 Cloud CDN 中。Cloud Secret Manager 等集成服务可确保 API 密钥安全无虞。

本页中介绍的架构的图表。

  1. 当提交推送到您的实时分支时，Google Cloud Developer Connect 会向 Firebase App Hosting 发送事件。
  2. 为了响应此事件，Firebase App Hosting 会为连接到代码库的后端创建新的 build。
    1. 首先，Firebase App Hosting 会为您的提交创建一个新的 Cloud Build build。在此作业中，Google Cloud buildpack 会确定应用中使用的框架，以创建适合应用的容器和配置（包括环境变量、Secret、实例数下限或上限、并发、内存、CPU 和 VPC 配置）。如需了解详情，请参阅 App Hosting 构建流程。
    2. Cloud Build 作业完成后，您的容器会存储在专用于 Firebase App Hosting 的 Artifact Registry 代码库中。然后，Firebase App Hosting 会使用您的映像和配置向 Cloud Run 服务添加新的 Cloud Run 修订版本。
  3. Cloud Run 修订版本完成并验证为正常后，Firebase App Hosting 会修改其流量配置，以将所有新请求指向新的 Cloud Run 修订版本。此时，发布已完成。
  4. 当请求发送到托管在 Firebase App Hosting 上的网站时，该请求由启用了 Cloud CDN 的 Google Cloud 负载均衡器提供服务。未缓存的请求会发送到您的 Cloud Run 服务。如需了解如何使用 Cloud CDN 优化性能，请参阅缓存应用内容。

框架集成

App Hosting 为使用以下框架开发的 Web 应用提供预配置的构建和部署支持：

  • Next.js 13.5.x 及更高版本
  • Angular 18.2.x 及更高版本

如需了解特定版本和支持级别的详细信息，请参阅支持时间表。

除了 Next.js 和 Angular 之外，App Hosting 还支持任何能够提供与我们的输出软件包规范相匹配的构建输出的 Web 框架。如需详细了解 App Hosting 支持的框架、框架适配器和相关工具，请参阅适用于 App Hosting 的框架和工具。

App Hosting 代码库集成的工作原理

GitHub 代码库与 App Hosting 后端之间的重要连接由 Developer Connect 处理，后者是 Google Cloud 针对外部 DevOps 工具的连接平台。设置此连接时（通常是在创建 App Hosting 后端期间），Developer Connect 的界面工作流会引导您完成 Firebase GitHub 应用的安装。此过程中的关键步骤如下：

  1. 您向 Developer Connect 授予 Secret Manager Admin 角色。这样，系统就可以将凭证作为“Secret”安全地存储在 Cloud Secret Manager 中。
  2. 您授权 Firebase GitHub 应用访问您的 GitHub 代码库。您可能需要额外的 GitHub 权限才能访问正确的代码库。
  3. Developer Connect 会在项目的 Secret Manager 代码库中存储一个专用的 GitHub 授权令牌；请勿修改或删除此令牌。

此外，App Hosting 还与 GitHub Checks API 集成，以便为发布提供检查。通过此检查，您可以在 GitHub 中查看发布状态，并在出现任何错误时调试部署过程。

与 Firebase 和其他 Google 服务集成

App Hosting 会设置您的构建和运行时环境，以便您可以使用 Google 应用默认凭证初始化 Firebase Admin SDK。这样，您的后端就可以在构建和运行时与其他 Firebase 产品进行通信。如需详细了解如何初始化应用以及其他与 Firebase SDK 相关的主题，请参阅在 Web 应用中集成 Firebase SDK。

App Hosting 个位置

App Hosting 会在特定位置（称为主要区域）创建后端资源。虽然 App Hosting 与全球 CDN 集成以实现快速交付，但未缓存的内容会从应用的主要区域传送。Web 应用位置的这种灵活性具有以下主要优势：

  • 通过将数据放置在地理位置上更靠近用户的位置，提高性能并缩短延迟时间。
  • 一个区域中 App Hosting 的灾难性故障不会影响在其他区域中部署的 Web 应用。

从 Firebase 控制台或 Firebase CLI 创建 App Hosting 后端时，您可以选择以下任一区域：

  • us-central1（爱荷华）
  • us-east4 (N. 弗吉尼亚）
  • us-east5（哥伦布）
  • asia-east1（台湾）
  • asia-southeast1（新加坡）
  • europe-west4（荷兰）

App Hosting 后端服务账号

在构建期间和运行时，App Hosting 后端会使用服务账号向其他 Google 服务进行身份验证。首次在 Firebase 项目中启用 App Hosting 时，系统会创建一个用于这些用途的默认服务账号：

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

此服务账号默认适用于所有后端，并具有一组最低权限，可让您构建、运行和监控应用。它还具有使用应用默认凭证对 Admin SDK 进行身份验证的权限，以便执行从 Cloud Firestore 加载数据等操作。请参阅 Firebase App Hosting 角色。

如果您的应用需要在构建时或从正在运行的后端与其他 Google 服务进行交互，您可以通过添加角色来自定义默认服务账号。例如，如果您的应用需要 Vertex AI 的权限，您可能需要添加 roles/aiplatform.user 或一些相关角色。