Понимание хостинга приложений и того, как он работает

App Hosting выполняет ряд сложных фоновых задач, упрощая развертывание вашего приложения. На этой странице описаны ключевые части этого потока задач, предоставляя информацию о точках, где вы можете настроить поток в зависимости от потребностей вашего приложения.

Интеграция фреймворка

App Hosting обеспечивает предварительно настроенную поддержку сборки и развертывания веб-приложений, разработанных в следующих средах:

  • Next.js 13+
  • Угловой 17.2+

App Hosting определяет, какую платформу вы используете, проверяя файл package-lock.json или другой файл блокировки в вашем репозитории. Если вы попытаетесь развернуть приложение Node.js, в котором отсутствует файл блокировки, App Hosting не сможет собрать и запустить ваше приложение. Вы можете создать package-lock.json , запустив npm install в корневом каталоге.

Каркасные адаптеры

Адаптеры платформы App Hosting выполняют две ключевые роли:

  1. Они анализируют ваш исходный код и любые файлы конфигурации, специфичные для платформы (например, next.config.js ), и генерируют выходной пакет , который может быть обработан остальной частью инфраструктуры хостинга приложений.
  2. Они запускают команду сборки вашего приложения, чтобы сгенерировать статические ресурсы и создать оптимизированную версию вашего приложения для производства.

Адаптеры платформы создают приложение Node.js с помощью npm run build , который лучше всего работает со сценариями сборки по умолчанию для каждой платформы: next build для Next.js и ng build для Angular. App Hosting будет пытаться выполнить сборку с использованием пользовательских команд сборки, но не может надежно гарантировать успех.

Исходный код адаптеров Next.js и Angular доступен в firebase-framework-tools .

Другие рамки

Помимо Nextjs и Angular, хостинг приложений также поддерживает любую веб-платформу, способную обеспечить выходные данные сборки, соответствующие нашей спецификации выходного пакета . Авторы платформы могут воспользоваться спецификацией выходного пакета, чтобы гарантировать поддержку своей платформы хостингом приложений.

Если вам нужна поддержка дополнительных платформ, вы можете создать адаптер или обратиться к сопровождающим платформы, чтобы преобразовать выходные данные сборки в формат хостинга приложений. Адаптеры Nextjs и Angular — хорошие справочные примеры для всех, кто создает адаптер.

Поддерживаемые фреймворки можно найти в Firebase Open Source .

Как работает интеграция репозитория App Hosting

Важную связь между вашим репозиторием GitHub и серверной частью App Hosting обеспечивает Developer Connect — платформа подключения Google Cloud для внешних инструментов DevOps. Во время создания серверной части App Hosting рабочий процесс пользовательского интерфейса Developer Connect поможет вам установить приложение Firebase GitHub. Ключевыми шагами в этом процессе являются:

  1. Вы предоставляете Developer Connect роль администратора Secret Manager . Это позволяет системе безопасно хранить учетные данные как «секреты» в Cloud Secret Manager .
  2. Вы разрешаете приложению Firebase GitHub доступ к вашему репозиторию GitHub .
  3. Developer Connect хранит специальный токен авторизации GitHub в репозитории секретного менеджера вашего проекта; не изменяйте и не удаляйте этот токен.

Кроме того, App Hosting интегрируется с API проверок GitHub, обеспечивая проверку развертываний. Эта проверка позволяет вам просмотреть статус вашего развертывания в GitHub и отладить процесс развертывания в случае каких-либо ошибок.

Интеграция с Firebase и другими сервисами Google.

App Hosting настраивает среду сборки и выполнения, чтобы вы могли инициализировать Firebase Admin SDK с учетными данными приложения Google по умолчанию. Таким образом, ваш бэкэнд может взаимодействовать с другими продуктами Firebase как во время сборки, так и во время развертывания.

Расположение App Hosting

Развертывание App Hosting создает ваши серверные ресурсы в определенном месте. Такая гибкость в расположении вашего веб-приложения имеет ключевые преимущества:

  • Повышение производительности и сокращение задержек за счет географического приближения данных к вашим пользователям.
  • Катастрофический сбой App Hosting в одном регионе не повлияет на веб-приложения, развернутые в других регионах.

Вы можете выбрать любой из этих регионов при создании серверной части App Hosting из консоли или интерфейса командной строки Firebase :

  • 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 с учетными данными приложения по умолчанию для выполнения таких операций, как загрузка данных из Cloud Firestore . См . раздел Роли App Hosting Firebase .

Если вашему приложению необходимо взаимодействовать с дополнительными сервисами Google либо во время сборки, либо из работающего серверного модуля, вы можете настроить учетную запись службы по умолчанию, добавив роли. Например, если вашему приложению требуются разрешения для Vertex AI, вам может потребоваться добавить roles/aiplatform.user или какую-либо связанную роль.

Ключевые термины и определения

  • Серверная часть : коллекция управляемых ресурсов, которые создает App Hosting для создания и запуска вашего веб-приложения.
  • Развертывание : конкретная версия вашего действующего приложения, связанная с коммитом git.
  • Живая ветка : ветка вашего репозитория GitHub, которая развертывается по вашему действующему URL-адресу. Часто это ветка, в которую объединяются ветки функций или ветки разработки.

Известные проблемы и ограничения

Предварительная версия App Hosting имеет некоторые известные ограничения:

  • В некоторых случаях серверная часть App Hosting может возвращать сообщения Intermittent connection error по URL-адресу вашего приложения. Исправление будет доступно в более поздней версии.
  • Заголовки Cache-Control изменены, чтобы ограничить кэши CDN до 60 секунд; в будущем, когда App Hosting появится возможность быстро очищать кеш при развертывании, это ограничение будет снято.
  • Оптимизация изображений выполняется в Cloud Run по умолчанию, и оптимизированные изображения не сохраняются — мы рекомендуем отключить оптимизацию изображений или вручную указать загрузчик , пока не будет доступно лучшее решение.
  • Некэшированные статические файлы передаются из Cloud Run ; в более поздней версии они будут храниться и обслуживаться из источника App Hosting для повышения производительности.
  • Артикул App Hosting может не отображаться на странице использования серверной части в консоли Firebase . Они будут доступны в более поздней версии.
  • Консоль Firebase может периодически отображать ошибку «Сборка не найдена и недействительна» при создании серверной части.
  • В настоящее время все серверные части в одном проекте используют одну организацию/учетную запись GitHub. Их можно подключить к разным репозиториям в этой организации/учетной записи. Чтобы создать серверные части, подключенные к разным учетным записям GitHub, поместите их в отдельные проекты.
  • Промежуточное программное обеспечение Next.js, перезапись и перенаправление выполняются в Cloud Run за CDN. Поскольку они не защитят кэшированные ответы, обязательно установите соответствующие директивы управления для отображаемого контента.