了解 App Hosting 及其工作原理

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

关键术语和定义

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

  • 后端：App Hosting 创建的一组托管资源，用于构建和运行 Web 应用。
  • 构建 ：应用的特定修订版本，通常与 Git 提交相关联。创建构建的过程包含 许多子流程，特别是 构建 应用在 Cloud Build 中， 以及修订版本的 部署（最初提供 0% 的流量，直到 推出为止）在 Cloud Run 中。
  • 推出：将构建设置为主动提供流量的过程。 当由 Git 提交自动触发时，App Hosting 会先使用实际分支创建构建，然后创建推出以将实际流量定向到该构建。
  • 实际分支：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 会响应此事件，为 连接到代码库的后端创建新构建。 Firebase App Hosting
    1. 首先，Firebase App Hosting 会为 您的提交创建新的 Cloud Build 构建。在此作业中， Google Cloud buildpack 会确定您的应用中使用的框架，以创建适合您应用的容器和配置（包括 环境变量、密钥、最小或最大实例数、并发 内存、CPU 和 VPC 配置）。 如需了解详情，请参阅 the App Hosting 构建流程 For 。
    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 支持的框架、框架适配器和相关工具，请参阅 Frameworks and tooling for 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 角色。这样，系统就可以将凭据安全地存储为 “密钥”在 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（北弗吉尼亚）
  • 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 或某些相关角色。