了解 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 密钥安全无虞。
- 当提交推送到您的实时分支时，Google Cloud Developer Connect 会向 Firebase App Hosting 发送事件。
- 响应此事件时，Firebase App Hosting 会为连接到代码库的后端创建新的 build。
- 首先，Firebase App Hosting 会为您的提交创建新的 Cloud Build build。在此作业中，Google Cloud buildpack 会确定您的应用中使用的框架，以创建适合您应用的容器和配置（包括环境变量、Secret、最小或最大实例数、并发内存、CPU 和 VPC 配置）。如需了解详情，请参阅App Hosting 构建流程。
- Cloud Build 作业完成后，您的容器将存储在专用于 Firebase App Hosting 的 Artifact Registry 代码库中。然后，Firebase App Hosting 使用您的映像和配置向 Cloud Run 服务添加新的 Cloud Run 修订版本。
- 当 Cloud Run 修订版本完成并验证为正常运行后，Firebase App Hosting 会修改其流量配置，以将所有新请求指向新的 Cloud Run 修订版本。至此，推出已完成。
- 当请求发送到托管在 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 还支持任何能够提供符合输出软件包规范的 build 输出的 Web 框架。如需详细了解 App Hosting 支持的框架、框架适配器和相关工具，请参阅App Hosting 的框架和工具。
App Hosting 代码库集成的工作原理
GitHub 代码库与 App Hosting 后端之间的重要连接由 Developer Connect（Google Cloud 针对外部 DevOps 工具的连接平台）处理。在创建 App Hosting 后端期间，Developer Connect 的界面工作流会引导您完成 Firebase GitHub 应用的安装。此过程中的关键步骤包括：
- 您向 Developer Connect 授予 Secret Manager Admin 角色。这样一来，系统便可将凭据安全地存储为 Cloud Secret Manager 中的“密文”。
- 您授权 Firebase GitHub 应用访问您的 GitHub 代码库。您可能需要额外的 GitHub 权限才能访问正确的代码库。
- Developer Connect 会在项目的 Secret Manager 代码库中存储一个专用的 GitHub 授权令牌；请勿修改或删除此令牌。
此外，App Hosting 还与 GitHub Checks API 集成，以提供针对发布版本的检查。通过此检查，您可以在 GitHub 中查看发布状态，并在出现任何错误时调试部署流程。
与 Firebase 和其他 Google 服务集成
App Hosting 会同时设置您的 build 和运行时环境，以便您可以使用 Google 应用默认凭据初始化 Firebase Admin SDK。这样，您的后端就可以在构建时和运行时与其他 Firebase 产品进行通信。如需详细了解如何初始化应用以及其他与 Firebase SDK 相关的主题，请参阅在 Web 应用中集成 Firebase SDK。
App Hosting 个位置
App Hosting 会在特定位置（称为主要区域）创建后端资源。虽然 App Hosting 与全球 CDN 集成以实现快速传送，但未缓存的内容会从应用的主要区域传送。Web 应用位置的这种灵活性具有以下主要优势：
- 通过将数据放置在地理位置上更接近用户的位置，提高了性能并缩短了延迟时间。
- 一个区域中 App Hosting 的灾难性故障不会影响部署在其他区域中的 Web 应用。
通过控制台或 Firebase CLI 创建 App Hosting 后端时，您可以选择以下任一区域：
us-central1（爱荷华）asia-east1（台湾）europe-west4（荷兰）
App Hosting 后端服务账号
在 build 期间和运行时，您的 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 或某些相关角色。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-08。
[null,null,["最后更新时间 (UTC)：2025-08-08。"],[],[],null,["\u003cbr /\u003e\n\nApp Hosting handles a complex series of background tasks to simplify the\ndeployment of your app. This page describes key parts of that task flow,\nproviding information about points where you might want to customize the flow\ndepending on your app's needs.\n\nKey terms and definitions\n\nTo understand the details of the App Hosting flow, it's helpful to define\nsome of the terminology very specifically. Here are the fundamental key terms:\n\n- **Backend** : The collection of managed resources that App Hosting creates to build and run your web app.\n- **Build:** A specific revision of your app, typically linked to a git commit. The [process of creating a build](/docs/app-hosting/build) has numerous subprocesses, notably the *building* of your app in Cloud Build, and the *deployment* of a revision (initially serving 0% of traffic until it is rolled out) in Cloud Run.\n- **Rollout** : The process of setting a build to actively serving traffic. When automatically triggered by a git commit, App Hosting first creates a build using your live branch, then creates a rollout to direct live traffic to it.\n- **Live branch**: The branch of your GitHub repository that gets deployed to your live URL. Often, it's the branch into which feature branches or development branches are merged.\n\nGoogle Cloud and App Hosting architecture\n\nApp Hosting orchestrates a set of Google Cloud products so you can\ndeploy, serve, and monitor your web app. Apps are built with Cloud Build,\nserved on Cloud Run, and cached in Cloud CDN. Integrated services like\nCloud Secret Manager keep your API keys safe.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n1. When a commit is pushed to your live branch, Google Cloud Developer Connect sends an event to Firebase App Hosting.\n2. Responding to this event, Firebase App Hosting creates a new build for the backend connected to the repository.\n 1. First, Firebase App Hosting creates a new Cloud Build build for your commit. In this job, [Google Cloud buildpacks](https://cloud.google.com/docs/buildpacks/overview) determine which framework is being used in your application to create a container and configuration (including environment variables, secrets, minimum or maximum instances, concurrency memory, CPU, and VPC configuration) that suits your application. See [the App Hosting build process](/docs/app-hosting/build) For more information.\n 2. When the Cloud Build job is complete, your container is stored in an Artifact Registry repository dedicated to Firebase App Hosting. Firebase App Hosting then adds a new Cloud Run Revision to a Cloud Run service using your image and configuration.\n3. Once your Cloud Run Revision is complete and verified healthy, Firebase App Hosting modifies its traffic configuration to point all new requests to your new Cloud Run Revision. At this point, the rollout is complete.\n4. When a request is sent to a website hosted on Firebase App Hosting, the request is served by Google Cloud Load Balancer with Cloud CDN enabled. Uncached requests are sent to your Cloud Run service. See [Cache app content](/docs/app-hosting/optimize-cache) for guidance on how to optimize performance with Cloud CDN.\n\nFramework integration\n\nApp Hosting provides preconfigured build and deploy support for web apps\ndeveloped in these frameworks:\n\n- Next.js 13.5.x and higher\n- Angular 18.2.x and higher\n\nSee the\n[support schedules](/docs/app-hosting/frameworks-tooling#next.js-support) for\ndetails on specific versions and levels of support.\n\nIn addition to Next.js and Angular, App Hosting also supports any web\nframework that is able to provide a build output that matches our [output bundle\nspecification](https://github.com/FirebaseExtended/firebase-framework-tools#app-hosting-output-bundle).\nSee [Frameworks and tooling for\nApp Hosting](/docs/app-hosting/frameworks-tooling) for more information\nabout frameworks, framework adapters, and related tooling supported by\nApp Hosting.\n\nHow App Hosting repository integration works\n\nThe important connection between your GitHub repository and the App Hosting\nbackend is handled by\n[Developer Connect](https://cloud.google.com/developer-connect/docs/overview),\nGoogle Cloud's connectivity platform\nfor external DevOps tools. During the creation of an App Hosting backend,\nDeveloper Connect's UI workflow guides you through the installation of the\nFirebase GitHub app. The key steps in this process are:\n\n1. You grant Developer Connect the [Secret Manager Admin](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.admin) role. This allows the system to store credentials securely as \"secrets\" in [Cloud Secret Manager](https://cloud.google.com/secret-manager/docs).\n2. You authorize the Firebase GitHub app to [access your GitHub repository](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-a-third-party). You may need additional [GitHub permissions](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-github-marketplace-for-your-organizations#requirements-to-install-a-github-app-on-an-organization) in order to access the right repository.\n3. Developer Connect stores a dedicated GitHub authorization token in your project's secret manager repository; don't modify or delete this token.\n\nAdditionally, App Hosting integrates with the GitHub checks API to provide a\ncheck for rollouts. This check lets you view the status of your rollout in\nGitHub and debug the deployment process in case of any errors.\n\nIntegration with Firebase and other Google services\n\nApp Hosting sets up both your build and runtime environments so you can\n[initialize the Firebase Admin SDK](/docs/admin/setup#initialize-sdk) with\nGoogle Application Default Credentials. That way, your backend can communicate\nwith other Firebase products at both build and run time. See [Integrate\nFirebase SDKs in your web app](/docs/app-hosting/firebase-sdks) for more\ninformation on initializing your app and other Firebase SDK-related topics.\n\nApp Hosting locations\n\nApp Hosting creates your backend resources in a specific location, called\nyour primary region. While App Hosting integrates with a global CDN for fast\ndelivery, uncached content is served from your app's primary region. This\nflexibility in the location of your web app has key advantages:\n\n- Improved performance and reduced latency by bringing the data geographically closer to your users.\n- A catastrophic failure for App Hosting in one region wouldn't affect web apps deployed in other regions.\n\nYou can choose any of these regions when you create an\nApp Hosting backend from the console or the Firebase CLI:\n\n- `us-central1` (Iowa)\n- `asia-east1` (Taiwan)\n- `europe-west4` (Netherlands)\n\nThe App Hosting backend service account\n\nDuring build and at runtime, your App Hosting backend authenticates with\nother Google services with a service account. A default service account for\nthese purposes is created the first time you enable App Hosting in a\nFirebase project:\n\n`firebase-app-hosting-compute@`\u003cvar translate=\"no\"\u003ePROJECT ID\u003c/var\u003e`.iam.gserviceaccount.com`\n\nThis service account applies to all backends by default and has a minimal set of\npermissions to allow you to build, run, and monitor your app. It also has\npermission to\n[authenticate the Admin SDK with Application Default Credentials](/docs/admin/setup#initialize-sdk), for\nperforming operations like loading data from Cloud Firestore. See\n[Firebase App Hosting roles](/docs/projects/iam/roles-predefined-product#app-hosting).\n\nIf your app needs to interact with additional Google services either at build\ntime or from a running backend, you can customize the default service account by\nadding roles. For example, if your app requires permissions for Vertex AI, you\nmight need to add\n[`roles/aiplatform.user`](https://cloud.google.com/iam/docs/understanding-roles#aiplatform.user)\nor some related role."]]
