Обычно на основе одной и той же кодовой базы развертывается несколько сред, каждая из которых имеет несколько разную конфигурацию. Например, вы можете захотеть выделить меньше ЦП и ОЗУ для промежуточной среды или убедиться, что в вашей производственной среде хотя бы один экземпляр остается активным и готовым обслуживать запросы. Вы также можете указать различные переменные среды и секреты в зависимости от среды и ресурсов, которые вы хотите использовать.
В этом руководстве описывается, как развернуть производственную и промежуточную среду, каждую в отдельном проекте 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 есть настройка имени среды . Это поле используется для сопоставления вашего серверного компонента с файлом конфигурации конкретной среды и может быть изменено в любое время. Вы можете установить только одно имя среды для каждого бэкэнда.
Чтобы установить имя среды вашего бэкэнда,
- В консоли Firebase выберите промежуточный проект (в данном примере — my-staging-firebase-project).
- Выберите App Hosting на левой панели навигации.
- Нажмите «Просмотреть панель мониторинга» на выбранном вами сервере.
- На вкладке «Настройки» выберите «Развертывание» .
- В разделе «Имя среды» введите имя вашей среды. Вы можете назвать среду как угодно. В этом примере это постановка .
- Нажмите Сохранить .
Когда для вашего бэкэнда запускается развертывание 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.appspot.com
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.appspot.com
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.
Следующие шаги
- Идите глубже: ознакомьтесь с кодовой лабораторией Firebase, которая интегрирует размещенное приложение с функциями аутентификации Firebase и Google AI: Next.js | Угловой
- Подключите личный домен .
- Настройте свой бэкэнд .
- Отслеживайте развертывание, использование сайта и журналы .
Обычно на основе одной и той же кодовой базы развертывается несколько сред, каждая из которых имеет несколько разную конфигурацию. Например, вы можете захотеть выделить меньше ЦП и ОЗУ для промежуточной среды или убедиться, что в вашей производственной среде хотя бы один экземпляр остается активным и готовым обслуживать запросы. Вы также можете указать различные переменные среды и секреты в зависимости от среды и ресурсов, которые вы хотите использовать.
В этом руководстве описывается, как развернуть производственную и промежуточную среду, каждую в отдельном проекте 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 есть настройка имени среды . Это поле используется для сопоставления вашего серверного компонента с файлом конфигурации конкретной среды и может быть изменено в любое время. Вы можете установить только одно имя среды для каждого бэкэнда.
Чтобы установить имя среды вашего бэкэнда,
- В консоли Firebase выберите промежуточный проект (в данном примере — my-staging-firebase-project).
- Выберите App Hosting на левой панели навигации.
- Нажмите «Просмотреть панель мониторинга» на выбранном вами сервере.
- На вкладке «Настройки» выберите «Развертывание» .
- В разделе «Имя среды» введите имя вашей среды. Вы можете назвать среду как угодно. В этом примере это постановка .
- Нажмите Сохранить .
Когда для вашего бэкэнда запускается развертывание 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.appspot.com
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.appspot.com
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.
Следующие шаги
- Идите глубже: ознакомьтесь с кодовой лабораторией Firebase, которая интегрирует размещенное приложение с функциями аутентификации Firebase и Google AI: Next.js | Угловой
- Подключите личный домен .
- Настройте свой бэкэнд .
- Отслеживайте развертывание, использование сайта и журналы .