App Hosting разработан для удобства использования и минимального обслуживания, а настройки по умолчанию оптимизированы для большинства случаев. Кроме того, App Hosting предоставляет инструменты для управления и настройки бэкенда в соответствии с вашими конкретными потребностями. В этом руководстве описаны эти инструменты и процессы.
Создание и редактирование apphosting.yaml
Для расширенной настройки, такой как переменные среды или параметры среды выполнения, такие как ограничения параллелизма, использования процессора и памяти, вам потребуется создать и отредактировать файл 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
Допустимые ключи переменных состоят из символов A-Z или символов подчеркивания. Некоторые ключи переменных среды зарезервированы для внутреннего использования. Не используйте эти ключи в файлах конфигурации:
- Любая переменная, начинающаяся с
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 .
Используйте переопределение команды run, если для запуска приложения требуется конкретная команда, отличная от команды 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 . Это отключит все домены вашего бэкенда и удалит связанную с ним службу Cloud Run :
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID(Необязательно) На вкладке консоли Google Cloud для Artifact Registry удалите образ для вашего бэкэнда в «firebaseapphosting-images».
В Cloud Secret Manager удалите все секреты, в названии которых содержится «apphosting», уделив особое внимание тому, чтобы эти секреты не использовались другими бэкэндами или другими аспектами вашего проекта Firebase .