通常,我们会从同一代码库部署多个环境,每个环境的配置略有不同。例如,您可能希望为预演环境分配较少的 CPU 和 RAM,或者您可能希望确保生产环境至少保持 1 个实例处于活跃状态并准备好处理请求。您可能还希望根据您要使用的环境和资源指定不同的环境变量和密钥。
本指南介绍了如何将生产环境和预演环境分别部署到单独的 Firebase 项目。遵循相同的原则,您可以部署到其他不同类型的环境。如需详细了解环境,请查看 环境概览和设置 Firebase 项目的一般 最佳实践。
前提条件
- 您的应用代码已存储在 GitHub 中。
- 您已为每个环境创建一个不同的项目,例如
my-production-firebase-project和my-staging-firebase-project。请务必为生产 Firebase 项目标记 “生产”环境 类型。 - 在每个项目中,您都创建了一个 App Hosting 后端,并将实时
分支设置为您要部署的 GitHub 分支(例如
main)。如需了解详情,请参阅 App Hosting 使用入门。
第 0 步:在 apphosting.yaml 中创建默认配置
App Hosting 支持名为 apphosting.yaml 的配置文件,用于管理
应用的运行时设置(CPU、并发、内存限制等)和环境
变量。它还支持引用使用
Cloud Secret Manager 管理的密钥,从而确保可以安全地签入源代码控制系统。如需了解详情,请参阅配置后端。
如需开始使用,请在应用的根目录中创建一个 apphosting.yaml 文件。
这是在找不到特定于环境的配置文件时使用的回退配置文件。存储在 apphosting.yaml 中的值应是可安全用于所有环境的默认值。
以下部分介绍了如何针对特定环境替换 apphosting.yaml 中的默认值。此示例流程会创建一个预演环境。
第 1 步:设置环境名称
每个 App Hosting 后端都有一个 环境名称 设置。此字段用于将后端映射到特定于环境的配置文件,并且可以随时更改。每个后端只能设置一个环境名称。
如需设置后端的环境名称,请执行以下操作:
- 在 Firebase 控制台中,选择预演项目(在本示例中,
my-staging-firebase-project)。 - 依次前往 Hosting 和无服务器 > App Hosting。
- 点击所选后端上的查看信息中心 。
- 在设置 标签页中,选择环境 。
- 在环境名称 下,输入环境的名称。您可以随意为环境命名。在本示例中,该名称为 staging 。
- 点击保存 。
当为后端触发 App Hosting 发布(通过 git
push 或通过 Firebase 控制台手动触发)时,App Hosting 会先检查是否存在 apphosting.ENVIRONMENT_NAME.yaml 文件,然后再回退到 apphosting.yaml。
第 2 步:创建特定于环境的 apphosting.yaml 文件
对于特定于环境的配置,请创建一个名为
apphosting.ENVIRONMENT_NAME.yaml的文件,以
指定特定于环境的替换项。此文件与
默认的 apphosting.yaml 具有相同的格式,并且必须与 apphosting.yaml 一起位于
应用的根目录中。
在构建时,App Hosting 会合并这两个文件,并优先使用特定于环境的 YAML 文件中的值,而不是基本 apphosting.yaml 文件中的值。
在此示例中,您将在应用的根目录中创建一个名为 apphosting.staging.yaml 的文件:
runConfig:
cpu: 1
memoryMiB: 512
concurrency: 5
env:
- variable: API_URL
value: api.staging.service.com
availability:
- BUILD
- variable: DATABASE_URL
secret: secretStagingDatabaseURL
假设您已有一个 apphosting.yaml,其内容如下所示:
runConfig:
cpu: 3
memoryMiB: 1024
maxInstances: 4
minInstances: 0
concurrency: 100
env:
- variable: API_URL
value: api.service.com
availability:
- BUILD
- RUNTIME
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- RUNTIME
- variable: API_KEY
secret: secretIDforAPI
您可以在 Cloud Build 日志中检查最终合并的输出,其内容如下所示:
runConfig:
cpu: 1
memoryMiB: 512
maxInstances: 4
minInstances: 0
concurrency: 5
env:
- variable: API_URL
value: api.staging.service.com
availability:
- BUILD
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- RUNTIME
- variable: API_KEY
secret: secretIDforAPI
- variable: DATABASE_URL
secret: secretStagingDatabaseURL
请注意,某些 runConfig 值(例如 CPU)以及任何重叠的环境变量都已被替换。
第 3 步:部署代码库
完成对特定于环境的 apphosting.ENVIRONMENT_NAME.yaml 文件的编辑后,将文件推送到 GitHub:
$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push
任何标记有此环境名称的后端都将使用您在其对应的 YAML 文件中指定的特定替换值,并在找不到值时回退到 apphosting.yaml。对于没有关联环境名称的后端,您可以继续使用 apphosting.yaml。
后续步骤
- 深入了解:完成一个 Firebase Codelab,该 Codelab 将托管的应用与 Firebase Authentication 和 Google AI 功能集成: Next.js | Angular
- 关联自定义网域。
- 配置后端。
- 监控发布、网站使用情况和日志。