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

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

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

Предпосылки

  • Код вашего приложения уже сохранен на GitHub.
  • Вы уже создали отдельный проект для каждой из ваших сред, например my-production-firebase-project и my-staging-firebase-project . Обязательно пометьте свой производственный проект Firebase тегом "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. В разделе Environment name введите имя вашей среды. Вы можете назвать среду как угодно. В этом примере это staging .
  6. Нажмите «Сохранить» .

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

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