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

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

В этом руководстве описывается, как развернуть рабочую и промежуточную среды в отдельных проектах 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 для управления настройками среды выполнения (ЦП, параллелизм, ограничения памяти и т. д.) и переменными среды для вашего приложения. Он также поддерживает ссылки на секреты, управляемые с помощью Cloud Secret Manager, что делает безопасной проверку в системе контроля версий. Подробнее о том, как настроить серверную часть…

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

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

Шаг 1. Укажите название среды

У каждого бэкенда App Hosting есть настройка Environment name (Название среды). Это поле используется для сопоставления вашего бэкенда с файлом конфигурации, зависящим от среды, и может быть изменено в любое время. Для каждого бэкенда можно задать только одно название среды.

Чтобы задать название среды бэкенда, выполните следующие действия:

  1. В консоли Firebase выберите тестовый проект (в этом примере – my-staging-firebase-project).
  2. Перейдите в раздел Hosting & Serverless (Хостинг и бессерверная архитектура) > App Hosting (Хостинг приложений).
  3. Нажмите Посмотреть рядом с нужным бэкендом.
  4. На вкладке Настройки выберите Среда.
  5. В поле Environment name (Название среды) введите название среды. Вы можете назвать среду как угодно. В нашем примере это staging.
  6. Нажмите Сохранить.

Когда для вашего бэкенда запускается развертывание 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.

Дальнейшие действия