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

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

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

Предпосылки

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

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