Часто развертывается несколько сред на основе одного и того же кода, каждая с немного отличающейся конфигурацией. Например, вы можете захотеть выделить меньше ресурсов ЦП и ОЗУ для тестовой среды или убедиться, что в производственной среде постоянно активен хотя бы один экземпляр, готовый обрабатывать запросы. Вы также можете указать различные переменные среды и секреты в зависимости от среды и используемых ресурсов.
В этом руководстве описано, как развернуть производственную и тестовую среды, каждая в отдельном проекте 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 есть параметр « Имя среды» . Это поле используется для сопоставления вашего бэкэнда с конфигурационным файлом, специфичным для данной среды, и может быть изменено в любое время. Для каждого бэкэнда можно задать только одно имя среды.
Чтобы задать имя среды вашего бэкэнда,
- In the Firebase console, select your staging project (in this example,
my-staging-firebase-project). - Перейдите в раздел «Хостинг и бессерверные вычисления» > «Хостинг приложений» .
- Нажмите «Просмотреть» в выбранной вами административной панели.
- На вкладке «Настройки» выберите «Окружающая среда» .
- Under Environment name, enter the name of your environment. You can name the environment whatever you like. In this example, it's staging .
- Нажмите « Сохранить ».
Когда для вашего бэкэнда запускается развертывание 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.
Следующие шаги
- Go deeper: walk through a Firebase codelab that integrates a hosted app with Firebase Authentication and Google AI features: Next.js | Angular
- Подключите собственный домен .
- Настройте свой бэкэнд .
- Отслеживайте развертывание, использование сайта и журналы событий .
Часто развертывается несколько сред на основе одного и того же кода, каждая с немного отличающейся конфигурацией. Например, вы можете захотеть выделить меньше ресурсов ЦП и ОЗУ для тестовой среды или убедиться, что в производственной среде постоянно активен хотя бы один экземпляр, готовый обрабатывать запросы. Вы также можете указать различные переменные среды и секреты в зависимости от среды и используемых ресурсов.
В этом руководстве описано, как развернуть производственную и тестовую среды, каждая в отдельном проекте 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 есть параметр « Имя среды» . Это поле используется для сопоставления вашего бэкэнда с конфигурационным файлом, специфичным для данной среды, и может быть изменено в любое время. Для каждого бэкэнда можно задать только одно имя среды.
Чтобы задать имя среды вашего бэкэнда,
- In the Firebase console, select your staging project (in this example,
my-staging-firebase-project). - Перейдите в раздел «Хостинг и бессерверные вычисления» > «Хостинг приложений» .
- Нажмите «Просмотреть» в выбранной вами административной панели.
- На вкладке «Настройки» выберите «Окружающая среда» .
- Under Environment name, enter the name of your environment. You can name the environment whatever you like. In this example, it's staging .
- Нажмите « Сохранить ».
Когда для вашего бэкэнда запускается развертывание 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.
Следующие шаги
- Go deeper: walk through a Firebase codelab that integrates a hosted app with Firebase Authentication and Google AI features: Next.js | Angular
- Подключите собственный домен .
- Настройте свой бэкэнд .
- Отслеживайте развертывание, использование сайта и журналы событий .