App Hosting выполняет сложную серию фоновых задач, чтобы упростить развертывание вашего приложения. На этой странице описаны ключевые части этого потока задач и представлена информация о точках, в которых вы можете настроить поток в зависимости от потребностей вашего приложения.
Основные термины и определения
Чтобы понять, как работает App Hosting, нужно разобраться в терминологии. Вот основные термины:
- Бэкенд. Набор управляемых ресурсов, которые App Hosting создает для сборки и запуска веб-приложения.
- Сборка. Определенная версия приложения, обычно связанная с фиксацией Git. Процесс создания сборки состоит из нескольких подпроцессов, в частности сборки приложения в Cloud Build и развертывания версии (изначально обслуживающей 0 % трафика до ее выпуска) в Cloud Run.
- Развертывание. Процесс настройки сборки для активной обработки трафика. При автоматическом запуске с помощью коммита git App Hosting сначала создает сборку, используя вашу активную ветку, а затем создает развертывание, чтобы направить на нее активный трафик.
- Активная ветвь. Ветвь хранилища GitHub, которая развертывается по 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 определяют, какой фреймворк используется в вашем приложении, чтобы создать контейнер и конфигурацию (включая переменные среды, секреты, минимальное или максимальное количество экземпляров, параллелизм, память, ЦП и конфигурацию VPC), подходящую для вашего приложения. Подробнее о процессе сборки App Hosting…
- Когда задание Cloud Build будет выполнено, ваш контейнер будет сохранен в хранилище Artifact Registry, предназначенном для Firebase App Hosting. Firebase App Hosting добавляет новую версию Cloud Run в сервис Cloud Run, используя ваш образ и конфигурацию.
- После того как новая версия Cloud Run будет создана и проверена, Firebase App Hosting изменит конфигурацию трафика, чтобы направлять все новые запросы в эту Cloud Run версию. На этом этапе развертывание завершено.
- Когда запрос отправляется на сайт, размещенный в Firebase App Hosting, он обрабатывается балансировщиком нагрузки Google Cloud с включенной сетью доставки контента 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 в хранилище Secret Manager вашего проекта. Не изменяйте и не удаляйте этот токен.
Кроме того, App Hosting интегрируется с GitHub Checks API, чтобы проверять развертывания. Эта проверка позволяет посмотреть статус развертывания в GitHub и отладить процесс развертывания в случае возникновения ошибок.
Интеграция с Firebase и другими сервисами Google
App Hosting настраивает среды сборки и выполнения, чтобы вы могли инициализировать Firebase Admin SDK с помощью Application Default Credentials. Это позволит вашему бэкенду взаимодействовать с другими продуктами Firebase как во время сборки, так и во время выполнения. Дополнительную информацию об инициализации приложения и других темах, связанных с Firebase SDK, можно найти в статье Как интегрировать Firebase SDK в веб-приложение.
App Hosting местоположения
App Hosting создает ресурсы бэкенда в определенном местоположении, которое называется основным регионом. Хотя App Hosting интегрируется с глобальной сетью доставки контента для быстрой доставки, некешированный контент обслуживается из основного региона вашего приложения. Такая гибкость в расположении вашего веб-приложения имеет ключевые преимущества:
- Повышение производительности и снижение задержки за счет географического приближения данных к пользователям.
- Катастрофический сбой в работе App Hosting в одном регионе не повлияет на веб-приложения, развернутые в других регионах.
Вы можете выбрать любой из этих регионов при создании бэкенда App Hosting в консоли Firebase или CLI Firebase:
us-central1(Айова)us-east4(N. Виргиния)us-east5(Колумбус)asia-east1(Тайвань)asia-southeast1(Сингапур)europe-west4(Нидерланды)
Сервисный аккаунт бэкенда App Hosting
Во время сборки и выполнения серверная часть App Hosting проходит аутентификацию в других сервисах Google с помощью сервисного аккаунта. Сервисный аккаунт по умолчанию для этих целей создается при первом включении App Hosting в проекте Firebase:
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
Этот сервисный аккаунт по умолчанию применяется ко всем серверным частям и имеет минимальный набор разрешений, позволяющий создавать, запускать и отслеживать приложение. У него также есть разрешение на аутентификацию Admin SDK с помощью учетных данных по умолчанию для приложения, чтобы выполнять такие операции, как загрузка данных из Cloud Firestore. Подробнее о ролях Firebase App Hosting…
Если вашему приложению необходимо взаимодействовать с дополнительными сервисами Google во время сборки или из работающего бэкенда, вы можете настроить сервисный аккаунт по умолчанию, добавив роли. Например, если вашему приложению требуются разрешения для Vertex AI, вам может потребоваться добавить роль roles/aiplatform.user или другую связанную роль.