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

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

В этом руководстве описывается, как развернуть производственную и промежуточную среду, каждую в отдельном проекте 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 есть настройка имени среды . Это поле используется для сопоставления вашего серверного компонента с файлом конфигурации конкретной среды и может быть изменено в любое время. Вы можете установить только одно имя среды для каждого бэкэнда.

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

  1. В консоли Firebase выберите промежуточный проект (в данном примере — my-staging-firebase-project).
  2. Выберите App Hosting на левой панели навигации.
  3. Нажмите «Просмотреть панель мониторинга» на выбранном вами сервере.
  4. На вкладке «Настройки» выберите «Развертывание» .
  5. В разделе «Имя среды» введите имя вашей среды. Вы можете назвать среду как угодно. В этом примере это постановка .
  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 , такие как ЦП, были перезаписаны, а также все перекрывающиеся переменные среды.

Шаг 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.

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