App Hosting обрабатывает сложную серию фоновых задач для упрощения развертывания вашего приложения. На этой странице описываются ключевые части этого потока задач, предоставляя информацию о точках, где вы можете захотеть настроить поток в зависимости от потребностей вашего приложения.
Основные термины и определения
Чтобы понять детали потока App Hosting , полезно определить некоторые термины очень конкретно. Вот основные ключевые термины:
- Бэкэнд : набор управляемых ресурсов, которые App Hosting создает для создания и запуска вашего веб-приложения.
- Сборка: Конкретная редакция вашего приложения, обычно связанная с коммитом git. Процесс создания сборки имеет множество подпроцессов, в частности, сборку вашего приложения в Cloud Build и развертывание редакции (первоначально обслуживающей 0% трафика до тех пор, пока она не будет развернута) в Cloud Run .
- Развертывание : процесс настройки сборки для активного обслуживания трафика. При автоматическом запуске коммитом git App Hosting сначала создает сборку с использованием вашей живой ветки, а затем создает развертку для направления на нее живого трафика.
- Live branch : Ветка вашего репозитория GitHub, которая развертывается на вашем live URL. Часто это ветка, в которую объединяются ветви функций или ветви разработки.
Архитектура Google Cloud и App Hosting
App Hosting организует набор продуктов Google Cloud, чтобы вы могли развертывать, обслуживать и контролировать свое веб-приложение. Приложения создаются с помощью Cloud Build , обслуживаются в Cloud Run и кэшируются в Cloud CDN. Интегрированные сервисы, такие как Cloud Secret Manager, обеспечивают безопасность ваших ключей API.

- Когда коммит отправляется в вашу активную ветку, Google Cloud Developer Connect отправляет событие в Firebase App Hosting .
- В ответ на это событие Firebase App Hosting создает новую сборку для бэкэнда, подключенного к репозиторию.
- Сначала Firebase App Hosting создает новую сборку Cloud Build для вашего коммита. В этой работе Google Cloud buildpacks определяют, какой фреймворк используется в вашем приложении для создания контейнера и конфигурации (включая переменные среды, секреты, минимальные или максимальные экземпляры, параллельную память, ЦП и конфигурацию VPC), которая подходит вашему приложению. См. процесс сборки App Hosting для получения дополнительной информации.
- После завершения работы Cloud Build ваш контейнер сохраняется в репозитории Artifact Registry выделенном для Firebase App Hosting . Затем Firebase App Hosting добавляет новую версию Cloud Run в службу Cloud Run используя ваш образ и конфигурацию.
- После того, как ваша Cloud Run Revision будет завершена и проверена на работоспособность, Firebase App Hosting изменяет свою конфигурацию трафика, чтобы направлять все новые запросы на вашу новую Cloud Run Revision. На этом этапе развертывание завершено.
- Когда запрос отправляется на веб-сайт, размещенный на Firebase App Hosting , запрос обслуживается Google Cloud Load Balancer с включенным Cloud CDN. Некэшированные запросы отправляются в ваш сервис Cloud Run . См. Кэширование содержимого приложения для получения рекомендаций по оптимизации производительности с помощью Cloud CDN.
Интеграция фреймворка
App Hosting обеспечивает предварительно настроенную поддержку сборки и развертывания веб-приложений, разработанных в следующих фреймворках:
- Next.js 13.5.x и выше
- Angular 18.2.x и выше
Подробную информацию о конкретных версиях и уровнях поддержки см. в графиках поддержки .
В дополнение к Next.js и Angular, App Hosting также поддерживает любой веб-фреймворк, который может предоставить вывод сборки, соответствующий нашей спецификации выходного пакета . См. Фреймворки и инструменты для App Hosting для получения дополнительной информации о фреймворках, адаптерах фреймворков и связанных инструментах, поддерживаемых App Hosting .
Как работает интеграция репозитория App Hosting
Важное соединение между вашим репозиторием GitHub и бэкэндом App Hosting обрабатывается Developer Connect , платформой подключения Google Cloud для внешних инструментов DevOps. Во время создания бэкэнда App Hosting рабочий процесс пользовательского интерфейса Developer Connect проведет вас через установку приложения Firebase GitHub. Ключевые шаги в этом процессе:
- Вы предоставляете Developer Connect роль администратора Secret Manager . Это позволяет системе безопасно хранить учетные данные как «секреты» в Cloud Secret Manager .
- Вы разрешаете приложению Firebase GitHub доступ к вашему репозиторию GitHub . Вам могут потребоваться дополнительные разрешения GitHub для доступа к нужному репозиторию.
- Developer Connect хранит выделенный токен авторизации GitHub в репозитории менеджера секретов вашего проекта; не изменяйте и не удаляйте этот токен.
Кроме того, App Hosting интегрируется с API проверки GitHub для проверки развертываний. Эта проверка позволяет вам просматривать статус вашего развертывания в GitHub и отлаживать процесс развертывания в случае возникновения ошибок.
Интеграция с Firebase и другими сервисами Google
App Hosting настраивает как среду сборки, так и среду выполнения, чтобы вы могли инициализировать Firebase Admin SDK с учетными данными Google Application Default. Таким образом, ваш бэкэнд может взаимодействовать с другими продуктами Firebase как во время сборки, так и во время выполнения. Подробнее об инициализации приложения и других темах, связанных с Firebase SDK, см. в разделе Интеграция Firebase SDK в ваше веб-приложение.
Места App Hosting
App Hosting создает ваши внутренние ресурсы в определенном месте, называемом вашим основным регионом. В то время как App Hosting интегрируется с глобальной CDN для быстрой доставки, некэшированный контент обслуживается из основного региона вашего приложения. Такая гибкость в расположении вашего веб-приложения имеет ключевые преимущества:
- Повышение производительности и сокращение задержек за счет географического приближения данных к вашим пользователям.
- Катастрофический сбой App Hosting в одном регионе не повлияет на веб-приложения, развернутые в других регионах.
Вы можете выбрать любой из этих регионов при создании бэкэнда App Hosting из консоли или Firebase CLI:
-
us-central1
(Айова) -
asia-east1
(Тайвань) -
europe-west4
(Нидерланды)
Учетная запись бэкэнд-службы App Hosting
Во время сборки и во время выполнения ваш бэкэнд App Hosting аутентифицируется в других сервисах Google с помощью учетной записи службы. Учетная запись службы по умолчанию для этих целей создается при первом включении App Hosting в проекте Firebase:
firebase-app-hosting-compute@ PROJECT ID .iam.gserviceaccount.com
Эта учетная запись службы применяется ко всем бэкендам по умолчанию и имеет минимальный набор разрешений, позволяющий вам создавать, запускать и контролировать ваше приложение. Она также имеет разрешение на аутентификацию Admin SDK с Application Default Credentials для выполнения таких операций, как загрузка данных из Cloud Firestore . См. Роли Firebase App Hosting .
Если вашему приложению необходимо взаимодействовать с дополнительными службами Google либо во время сборки, либо из работающего бэкенда, вы можете настроить учетную запись службы по умолчанию, добавив роли. Например, если вашему приложению требуются разрешения для Vertex AI, вам может потребоваться добавить roles/aiplatform.user
или какую-либо связанную роль.