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

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

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 поддерживает конфигурационный файл apphosting.yaml для управления настройками среды выполнения (процессор, параллелизм, ограничения памяти и т. д.) и переменными окружения для вашего приложения. Он также поддерживает ссылки на секреты, управляемые с помощью Cloud Secret Manager, что делает безопасным добавление в систему контроля версий. Для получения дополнительной информации см. раздел «Настройка бэкенда» .

Для начала создайте файл apphosting.yaml в корневом каталоге вашего приложения. Это резервный файл конфигурации, который используется, если файл конфигурации для конкретной среды не найден. Значения, хранящиеся в apphosting.yaml должны быть значениями по умолчанию, безопасными для использования во всех средах.

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

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

Для каждого бэкэнда App Hosting есть параметр « Имя среды» . Это поле используется для сопоставления вашего бэкэнда с конфигурационным файлом, специфичным для данной среды, и может быть изменено в любое время. Для каждого бэкэнда можно задать только одно имя среды.

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

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

Когда для вашего бэкэнда запускается развертывание App Hosting (либо при отправке изменений в Git, либо вручную через консоль), 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

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.

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