Развертывание нескольких сред из базы кода

Часто развертывается несколько сред на основе одного и того же кода, каждая с немного отличающейся конфигурацией. Например, вы можете захотеть выделить меньше ресурсов ЦП и ОЗУ для тестовой среды или убедиться, что в производственной среде постоянно активен хотя бы один экземпляр, готовый обрабатывать запросы. Вы также можете указать различные переменные среды и секреты в зависимости от среды и используемых ресурсов.

This guide describes how to deploy a production and staging environment, each to a separate Firebase project. Following the same principles, you can deploy to other different kinds of environments. To learn more about environments, check out the Overview of environments and General best practices for setting up Firebase projects .

Предварительные требования

  • Код вашего приложения уже хранится на GitHub.
  • You have already created a distinct project for each of your environments—for example my-production-firebase-project and my-staging-firebase-project . Make sure to to tag your production Firebase project with the "production" environment type .
  • В каждом проекте вы создали бэкэнд App Hosting , указав в качестве рабочей ветки ту ветку GitHub, которую хотите развернуть (например, main ). См. раздел «Начало работы с App Hosting для получения дополнительной информации.

Шаг 0: Создайте конфигурацию по умолчанию в файле apphosting.yaml.

App Hosting supports a configuration file called apphosting.yaml to manage runtime settings (CPU, concurrency, memory limits, etc.) and environment variables for your app. It also supports references to secrets managed with Cloud Secret Manager, making it safe to check into source control. For more information, see Configure a backend .

To get started, create an apphosting.yaml file in your app's root directory. This is the fallback configuration file that is used when an environment-specific configuration file isn't found. The values stored in apphosting.yaml should be defaults that are safe to use for all environments.

В следующих разделах объясняется, как переопределить значения по умолчанию в apphosting.yaml для конкретных сред. В этом примере создается тестовая среда.

Шаг 1: Задайте имя среды

Each App Hosting backend has an Environment name setting. This field is used to map your backend to an environment-specific configuration file, and can be changed at any time. You can only set one environment name per backend.

Чтобы задать имя среды вашего бэкэнда,

  1. В консоли Firebase выберите свой тестовый проект (в этом примере — my-staging-firebase-project ).
  2. Перейдите в раздел «Хостинг и бессерверные вычисления» > «Хостинг приложений» .
  3. В выбранной вами административной панели нажмите «Просмотреть панель управления» .
  4. На вкладке «Настройки» выберите «Окружающая среда» .
  5. В поле «Имя среды» введите имя вашей среды. Вы можете назвать среду как угодно. В этом примере это staging .
  6. Нажмите « Сохранить ».

When an App Hosting rollout is triggered for your backend (either on git push or manually through the Firebase console), App Hosting will check for an apphosting. ENVIRONMENT_NAME .yaml file before falling back to apphosting.yaml .

Шаг 2: Создайте файл apphosting.yaml , специфичный для вашей среды.

For your environment-specific configuration, create a file with the name apphosting. ENVIRONMENT_NAME .yaml in order to specify environment-specific overrides. This file has the same format as the default apphosting.yaml and must be located in your app's root directory alongside 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

Any backends tagged with this environment name will use the specific override values you have specified in its corresponding YAML file, and fall back to apphosting.yaml when a value isn't found. For backends without an associated environment name, you can continue to use apphosting.yaml.

Следующие шаги