App Hosting обрабатывает сложную серию фоновых задач, упрощая развёртывание вашего приложения. На этой странице описаны ключевые этапы этого процесса, а также предоставлена информация о точках, где вы можете настроить этот процесс в зависимости от потребностей вашего приложения.
Ключевые термины и определения
Чтобы понять детали процесса App Hosting , полезно дать точные определения некоторым терминам. Вот основные ключевые термины:
- Бэкэнд : набор управляемых ресурсов, которые App Hosting создает для создания и запуска вашего веб-приложения.
- Сборка: определённая версия вашего приложения, обычно связанная с коммитом git. Процесс создания сборки включает в себя множество подпроцессов, в частности, сборку приложения в Cloud Build и развёртывание версии (первоначально обслуживающей 0% трафика до её полного развертывания) в Cloud Run .
- Развёртывание : процесс настройки сборки для активной обработки трафика. При автоматическом запуске с помощью коммита git, App Hosting сначала создаёт сборку с использованием вашей активной ветки, а затем создаёт развёртывание для направления на неё активного трафика.
- Ветка Live : Ветка вашего репозитория GitHub, которая развёртывается по вашему URL-адресу Live. Часто это ветка, в которую объединяются ветки функций или ветки разработки.
Архитектура 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 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 . См. раздел Роли App Hosting Firebase .
Если вашему приложению требуется взаимодействие с дополнительными сервисами Google во время сборки или через работающий бэкенд, вы можете настроить учётную запись сервиса по умолчанию, добавив роли. Например, если вашему приложению требуются разрешения для Vertex AI, вам может потребоваться добавить roles/aiplatform.user или другую связанную роль.