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

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

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

Предварительные требования

  • Your application code is already stored in GitHub.
  • Вы уже создали отдельный проект для каждой из ваших сред — например, my-production-firebase-project и my-staging-firebase-project . Убедитесь, что вы пометили свой производственный проект Firebase тегом "production" .
  • In each project, you've created an App Hosting backend, with the live branch set to the GitHub branch you want to deploy (such as main ). See Get started with App Hosting for more information.

Step 0: Create a default configuration in apphosting.yaml

App Hosting поддерживает конфигурационный файл apphosting.yaml для управления настройками среды выполнения (процессор, параллелизм, ограничения памяти и т. д.) и переменными окружения для вашего приложения. Он также поддерживает ссылки на секреты, управляемые с помощью Cloud Secret Manager, что делает безопасным добавление в систему контроля версий. Для получения дополнительной информации см. раздел «Настройка бэкенда» .

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

The next sections explain how to override default values in apphosting.yaml for specific environments. This example flow creates a staging environment.

Шаг 1: Задайте имя среды

Для каждого бэкэнда App Hosting есть параметр « Имя среды» . Это поле используется для сопоставления вашего бэкэнда с конфигурационным файлом, специфичным для данной среды, и может быть изменено в любое время. Для каждого бэкэнда можно задать только одно имя среды.

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

  1. In the Firebase console, select your staging project (in this example, my-staging-firebase-project ).
  2. Перейдите в раздел «Хостинг и бессерверные вычисления» > «Хостинг приложений» .
  3. Нажмите «Просмотреть» в выбранной вами административной панели.
  4. На вкладке «Настройки» выберите «Окружающая среда» .
  5. Under Environment name, enter the name of your environment. You can name the environment whatever you like. In this example, it's staging .
  6. Нажмите « Сохранить ».

Когда для вашего бэкэнда запускается развертывание App Hosting (либо при отправке изменений в Git, либо вручную через консоль Firebase ), App Hosting проверит наличие файла apphosting. ENVIRONMENT_NAME .yaml , прежде чем вернуться к использованию файла apphosting.yaml .

Step 2: Create your environment-specific apphosting.yaml file

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

At build time, App Hosting merges these two files, with priority given to values in the environment-specific YAML file over the base apphosting.yaml file.

In this example, you'll create a file named apphosting.staging.yaml in the app's root directory:


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Suppose you already had an apphosting.yaml that looked like:

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

The final merged output, which you can inspect in your Cloud Build logs, would look like this:

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

Note that certain runConfig values such as CPU have been overwritten as well as any overlapping environment variables.

Шаг 3: Разверните свой код.

Once you are finished editing your environment specific apphosting. ENVIRONMENT_NAME .yaml file, push your file to GitHub:

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

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

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

,

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

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

Предварительные требования

  • Your application code is already stored in GitHub.
  • Вы уже создали отдельный проект для каждой из ваших сред — например, my-production-firebase-project и my-staging-firebase-project . Убедитесь, что вы пометили свой производственный проект Firebase тегом "production" .
  • In each project, you've created an App Hosting backend, with the live branch set to the GitHub branch you want to deploy (such as main ). See Get started with App Hosting for more information.

Step 0: Create a default configuration in apphosting.yaml

App Hosting поддерживает конфигурационный файл apphosting.yaml для управления настройками среды выполнения (процессор, параллелизм, ограничения памяти и т. д.) и переменными окружения для вашего приложения. Он также поддерживает ссылки на секреты, управляемые с помощью Cloud Secret Manager, что делает безопасным добавление в систему контроля версий. Для получения дополнительной информации см. раздел «Настройка бэкенда» .

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

The next sections explain how to override default values in apphosting.yaml for specific environments. This example flow creates a staging environment.

Шаг 1: Задайте имя среды

Для каждого бэкэнда App Hosting есть параметр « Имя среды» . Это поле используется для сопоставления вашего бэкэнда с конфигурационным файлом, специфичным для данной среды, и может быть изменено в любое время. Для каждого бэкэнда можно задать только одно имя среды.

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

  1. In the Firebase console, select your staging project (in this example, my-staging-firebase-project ).
  2. Перейдите в раздел «Хостинг и бессерверные вычисления» > «Хостинг приложений» .
  3. Нажмите «Просмотреть» в выбранной вами административной панели.
  4. На вкладке «Настройки» выберите «Окружающая среда» .
  5. Under Environment name, enter the name of your environment. You can name the environment whatever you like. In this example, it's staging .
  6. Нажмите « Сохранить ».

Когда для вашего бэкэнда запускается развертывание App Hosting (либо при отправке изменений в Git, либо вручную через консоль Firebase ), App Hosting проверит наличие файла apphosting. ENVIRONMENT_NAME .yaml , прежде чем вернуться к использованию файла apphosting.yaml .

Step 2: Create your environment-specific apphosting.yaml file

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

At build time, App Hosting merges these two files, with priority given to values in the environment-specific YAML file over the base apphosting.yaml file.

In this example, you'll create a file named apphosting.staging.yaml in the app's root directory:


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Suppose you already had an apphosting.yaml that looked like:

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

The final merged output, which you can inspect in your Cloud Build logs, would look like this:

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

Note that certain runConfig values such as CPU have been overwritten as well as any overlapping environment variables.

Шаг 3: Разверните свой код.

Once you are finished editing your environment specific apphosting. ENVIRONMENT_NAME .yaml file, push your file to GitHub:

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

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

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