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

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

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

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