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
— объем памяти, выделенный для каждого обслуживающего экземпляра в MiB (по умолчанию 512). -
maxInstances
— максимальное количество контейнеров, которые могут быть запущены одновременно (по умолчанию 100 и управляется квотой). -
minInstances
— количество контейнеров, которые всегда будут оставаться активными (по умолчанию 0). -
concurrency
— максимальное количество запросов, которые может получить каждый обслуживающий экземпляр (по умолчанию 80).
Обратите внимание на важную связь между cpu
и memoryMiB
; Для памяти можно задать любое целочисленное значение от 128 до 32768, но увеличение лимита памяти может потребовать увеличения лимитов ЦП:
- Для более 4 ГБ требуется как минимум 2 процессора
- Для более 8 ГБ требуется как минимум 4 процессора
- Для более 16 ГБ требуется как минимум 6 процессоров
- Для более 24 ГБ требуется как минимум 8 процессоров
Аналогичным образом значение cpu
влияет на настройки параллелизма. Если вы установите значение меньше 1 ЦП, необходимо установить для параллелизма значение 1, и ЦП будет выделяться только во время обработки запроса.
Настройка среды
Иногда вам потребуется дополнительная настройка процесса сборки, например ключи стороннего 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 .
Используйте переопределение команды запуска, если для запуска приложения вы хотите использовать конкретную команду, отличную от команды, указанной в App Hosting .
Настройка вывода сборки
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 может подключаться к сети виртуального частного облака (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 и консоли Firebase . В этом разделе описаны некоторые из наиболее распространенных задач управления, включая создание и удаление серверных частей.
Создать серверную часть
Серверная часть App Hosting — это набор управляемых ресурсов, которые App Hosting создает для создания и запуска вашего веб-приложения.
Консоль Firebase : в меню «Сборка» выберите «Хостинг приложений» , а затем «Начало» .
CLI: (версия 13.15.4 или новее). Чтобы создать серверную часть, запустите следующую команду из корня локального каталога проекта, указав идентификатор проекта и предпочтительный регион в качестве аргументов:
firebase apphosting:backends:create --project PROJECT_ID --location us-central1
Как для консоли, так и для интерфейса командной строки следуйте инструкциям, чтобы выбрать регион, настроить соединение GitHub и настроить следующие основные параметры развертывания:
Установите корневой каталог вашего приложения (по умолчанию
/
).Обычно здесь находится ваш файл
package.json
.
Установить живую ветку
Это ветка вашего репозитория GitHub, которая развертывается по вашему действующему URL-адресу. Часто это ветка, в которую объединяются ветки функций или ветки разработки.
Принять или отклонить автоматическое внедрение
Автоматическое развертывание включено по умолчанию. По завершении создания серверной части вы можете выбрать немедленное развертывание вашего приложения на App Hosting .
Присвойте имя своему серверу.
Удаление серверной части
Чтобы полностью удалить серверную часть, сначала используйте интерфейс командной строки Firebase или консоль Firebase , чтобы удалить ее, а затем вручную удалите связанные ресурсы, уделяя особое внимание тому, чтобы не удалить какие-либо ресурсы, которые могут использоваться другими серверными модулями или другими аспектами вашего проекта Firebase.
Консоль Firebase : в меню «Настройки» выберите «Удалить серверную часть» .
CLI: (версия 13.15.4 или новее)
Выполните следующую команду, чтобы удалить серверную часть App Hosting . Это отключает все домены вашего серверного модуля и удаляет связанную с ним службу Cloud Run :
firebase apphosting:backends:delete
BACKEND_ID --projectPROJECT_ID --location us-central1(Необязательно) На вкладке Google Cloud Console для Artifact Registry удалите изображение для своего бэкэнда в «firebaseapphosting-images».
В Cloud Secret Manager удалите все секреты со словом «apphosting» в имени секрета, уделяя особое внимание тому, чтобы эти секреты не использовались другими серверными модулями или другими аспектами вашего проекта Firebase .