App Hosting был разработан для простоты использования и низкого обслуживания, с настройками по умолчанию, оптимизированными для большинства случаев использования. В то же время App Hosting предоставляет инструменты для управления и настройки бэкэндов для ваших конкретных нужд. В этом руководстве описываются эти инструменты и процессы.
Создать и отредактировать apphosting.yaml
Для расширенной конфигурации, такой как переменные среды или параметры времени выполнения, такие как параллелизм, CPU и ограничения памяти, вам нужно будет создать и отредактировать файл apphosting.yaml в корневом каталоге вашего приложения. Этот файл также поддерживает ссылки на секреты, управляемые с помощью Cloud Secret Manager, что делает его безопасным для проверки в системе управления исходным кодом.
Чтобы создать apphosting.yaml , выполните следующую команду:
firebase init apphosting
Это создает базовый файл apphosting.yaml с примером (комментированной) конфигурации. После редактирования типичный файл apphosting.yaml может выглядеть следующим образом с настройками для службы Cloud Run бэкэнда, некоторыми переменными среды и некоторыми ссылками на секреты, управляемые Cloud Secret Manager:
# Settings for Cloud Run
runConfig:
minInstances: 2
maxInstances: 100
concurrency: 100
cpu: 2
memoryMiB: 1024
# Environment variables and secrets
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
- variable: API_KEY
secret: myApiKeySecret
# Same as API_KEY above but with a pinned version.
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
# Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
- variable: VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID
# Same as API_KEY above but with the long form secret reference with pinned version.
- variable: PINNED_VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID/versions/5
Остальная часть этого руководства содержит дополнительную информацию и контекст для этих примеров настроек.
Настройте параметры службы Cloud Run
С помощью настроек apphosting.yaml вы можете настроить, как будет предоставляться ваш сервис Cloud Run . Доступные настройки для сервиса Cloud Run указаны в объекте runConfig :
-
cpu– количество процессоров, используемых для каждого обслуживающего экземпляра (по умолчанию 0). -
memoryMiB– объем памяти, выделенной для каждого обслуживающего экземпляра в МиБ (по умолчанию 512) -
maxInstances– Максимальное количество контейнеров, которые могут быть запущены одновременно (по умолчанию 100 и управляется квотой) -
minInstances– Количество контейнеров, которые всегда должны поддерживаться активными (по умолчанию 0). -
concurrency– максимальное количество запросов, которые может получить каждый обслуживающий экземпляр (по умолчанию 80).
Обратите внимание на важную связь между cpu и memoryMiB ; для памяти можно задать любое целочисленное значение от 128 до 32768, но увеличение лимита памяти может потребовать увеличения лимитов ЦП:
- Более 4ГиБ требует как минимум 2 ЦП
- Более 8 ГБ требует не менее 4 ЦП
- Более 16 ГБ требует не менее 6 ЦП
- Более 24ГиБ требует не менее 8 ЦП
Аналогично, значение cpu влияет на настройки параллелизма. Если вы установите значение меньше 1 CPU, вы должны установить concurrency на 1, и CPU будет выделяться только во время обработки запроса.
Настройте среду
Иногда вам понадобится дополнительная конфигурация для процесса сборки, например, сторонние ключи API или настраиваемые параметры. App Hosting предлагает конфигурацию среды в apphosting.yaml для хранения и извлечения этого типа данных для вашего проекта.
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
Для приложений Next.js файлы dotenv, содержащие переменные среды, также будут работать с App Hosting . Мы рекомендуем использовать apphosting.yaml для детального управления переменными среды с любой структурой.
В apphosting.yaml вы можете указать, какие процессы имеют доступ к вашей переменной среды, используя свойство availability . Вы можете ограничить доступность переменной среды только для среды сборки или только для среды выполнения. По умолчанию она доступна для обеих.
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
Для приложений Next.js вы также можете использовать префикс NEXT_PUBLIC_ так же, как в файле dotenv, чтобы сделать переменную доступной в браузере.
env:
- variable: NEXT_PUBLIC_STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
Допустимые переменные ключи состоят из символов AZ или подчеркиваний. Некоторые переменные ключи среды зарезервированы для внутреннего использования. Не используйте ни один из этих ключей в ваших файлах конфигурации:
- Любая переменная, начинающаяся с
X_FIREBASE_ -
PORT -
K_SERVICE -
K_REVISION -
K_CONFIGURATION
Переопределение скриптов сборки и запуска
App Hosting выводит команду сборки и запуска вашего приложения на основе обнаруженного фреймворка. Если вы хотите использовать пользовательскую команду сборки или запуска, вы можете переопределить значения по умолчанию App Hosting в apphosting.yaml .
scripts:
buildCommand: next build --no-lint
runCommand: node dist/index.js
Переопределение команды сборки имеет приоритет над любыми другими командами сборки и исключает ваше приложение из адаптеров фреймворка и отключает любые оптимизации, специфичные для фреймворка, которые предоставляет App Hosting . Лучше всего использовать его, когда функции вашего приложения не поддерживаются адаптерами. Если вы хотите изменить команду сборки, но по-прежнему использовать наши предоставленные адаптеры, установите свой скрипт сборки в package.json , как описано в App Hosting framework adapters .
Используйте переопределение команды запуска, если для запуска приложения требуется использовать определенную команду, отличную от команды App Hosting -inferred.
Настроить вывод сборки
App Hosting оптимизирует развертывания вашего приложения по умолчанию, удаляя неиспользуемые выходные файлы, как указано фреймворком. Если вы хотите дополнительно оптимизировать размер развертывания приложения или игнорировать оптимизации по умолчанию, вы можете переопределить это в apphosting.yaml .
outputFiles:
serverApp:
include: [dist, server.js]
Параметр include принимает список каталогов и файлов относительно корневого каталога приложения, которые необходимы для развертывания вашего приложения. Если вы хотите убедиться, что все файлы сохранены, установите include на [.] , и все файлы будут развернуты.
Хранить и получать доступ к секретным параметрам
Конфиденциальная информация, такая как ключи API, должна храниться как секреты. Вы можете ссылаться на секреты в apphosting.yaml , чтобы избежать проверки конфиденциальной информации в системе управления исходным кодом.
Параметры типа secret представляют строковые параметры, имеющие значение, хранящееся в Cloud Secret Manager . Вместо того, чтобы напрямую выводить значение, секретные параметры проверяют его наличие в Cloud Secret Manager и загружают значения во время развертывания.
- variable: API_KEY
secret: myApiKeySecret
Секреты в Cloud Secret manager могут иметь несколько версий. По умолчанию значение секретного параметра, доступного для вашего работающего бэкэнда, закреплено на последней доступной версии секрета на момент создания бэкэнда. Если у вас есть требования к управлению версиями и жизненным циклом параметров, вы можете закрепить их на определенных версиях с помощью Cloud Secret Manager. Например, чтобы закрепить на версии 5:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
Вы можете создавать секреты с помощью команды CLI firebase apphosting:secrets:set , и вам будет предложено добавить необходимые разрешения. Этот поток дает вам возможность автоматически добавлять ссылку на секрет в apphosting.yaml .
Чтобы использовать полный набор функций Cloud Secret Manager, вы можете вместо этого использовать консоль Cloud Secret Manager. Если вы это сделаете, вам нужно будет предоставить разрешения для вашего бэкэнда App Hosting с помощью команды CLI firebase apphosting:secrets:grantaccess .
Настроить доступ VPC
Ваш бэкэнд App Hosting может подключаться к сети Virtual Private Cloud (VPC) . Для получения дополнительной информации и примера см. раздел Подключение Firebase App Hosting к сети VPC .
Используйте сопоставление vpcAccess в файле apphosting.yaml для настройки доступа. Используйте либо полное сетевое имя, либо идентификатор. Использование идентификаторов обеспечивает переносимость между промежуточными и производственными средами с различными коннекторами/сетями.
runConfig:
vpcAccess:
egress: PRIVATE_RANGES_ONLY # Default value
networkInterfaces:
# Specify at least one of network and/or subnetwork
- network: my-network-id
subnetwork: my-subnetwork-id
Управление бэкэндами
Команды для базового управления бэкендами App Hosting предоставляются в Firebase CLI и консоли Firebase . В этом разделе описываются некоторые из наиболее распространенных задач управления, включая создание и удаление бэкендов.
Создать бэкэнд
Бэкэнд App Hosting — это набор управляемых ресурсов, которые App Hosting создает для создания и запуска вашего веб-приложения.
Консоль Firebase : в меню «Сборка» выберите «Хостинг приложений» , а затем «Начать» .
CLI: (Версия 13.15.4 или более поздняя) Чтобы создать бэкэнд, выполните следующую команду из корня локального каталога проекта, указав свой projectID в качестве аргумента:
firebase apphosting:backends:create --project PROJECT_ID
Для консоли или CLI следуйте инструкциям по выбору региона , настройте подключение к GitHub и настройте следующие основные параметры развертывания:
Установите корневой каталог вашего приложения (по умолчанию
/)Обычно именно здесь находится файл
package.json.
Установить живую ветку
Это ветвь вашего репозитория GitHub, которая развертывается на вашем живом URL. Часто это ветвь, в которую объединяются ветви функций или ветви разработки.
Принять или отклонить автоматическое развертывание
Автоматические развертывания включены по умолчанию. После завершения создания бэкенда вы можете выбрать немедленное развертывание вашего приложения на App Hosting .
Присвойте имя своему бэкэнду.
Удалить бэкэнд
Чтобы полностью удалить бэкэнд, сначала используйте Firebase CLI или консоль Firebase , а затем вручную удалите связанные с ними ресурсы, уделяя особое внимание тому, чтобы не удалить какие-либо ресурсы, которые могут использоваться другими бэкэндами или другими аспектами вашего проекта Firebase.
Консоль Firebase : в меню «Настройки» выберите «Удалить бэкэнд» .
CLI: (Версия 13.15.4 или более поздняя)
Выполните следующую команду, чтобы удалить App Hosting Backend. Это отключит все домены для вашего backend и удалит связанную службу Cloud Run :
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID(Необязательно) На вкладке Artifact Registry консоли Google Cloud удалите образ для вашего бэкэнда в «firebaseapphosting-images».
В Cloud Secret Manager удалите все секреты, в имени которых содержится «apphosting», уделяя особое внимание тому, чтобы эти секреты не использовались другими бэкэндами или другими аспектами вашего проекта Firebase .