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 выполняют две ключевые роли:
- Они анализируют ваш исходный код и любые файлы конфигурации, специфичные для платформы (например,
next.config.js), и генерируют выходной пакет , который может быть обработан остальной частью инфраструктуры хостинга приложений. - Они запускают команду сборки вашего приложения, чтобы сгенерировать статические ресурсы и создать оптимизированную версию вашего приложения для производства.
Адаптеры платформы создают ваше приложение 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. Ключевыми шагами в этом процессе являются:
- Вы предоставляете Developer Connect роль администратора Secret Manager . Это позволяет системе безопасно хранить учетные данные как «секреты» в Cloud Secret Manager .
- Вы разрешаете приложению Firebase GitHub доступ к вашему репозиторию GitHub .
- 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 по умолчанию, и оптимизированные изображения не сохраняются — мы рекомендуем отключить оптимизацию изображений или вручную указать загрузчик , пока не будет доступно лучшее решение.
- URL-пути, содержащие символы в процентном кодировании, декодируются Cloud Run . Это может вызвать проблемы с функциями, которые ожидают только закодированные URL-пути, такими как параллельная маршрутизация Next.js.
- Некэшированные статические файлы передаются из Cloud Run ; в более поздней версии они будут храниться и обслуживаться из источника App Hosting для повышения производительности.
- Артикул App Hosting может не отображаться на странице использования серверной части в консоли Firebase . Они будут доступны в более поздней версии.
- Консоль Firebase может периодически отображать ошибку «Сборка не найдена и недействительна» при создании серверной части.
- Все серверные части в одном проекте используют одну организацию/учетную запись GitHub. Их можно подключить к разным репозиториям в этой организации/учетной записи. Чтобы создать серверные части, подключенные к разным учетным записям GitHub, поместите их в отдельные проекты.
- Промежуточное программное обеспечение Next.js, перезапись и перенаправление выполняются в Cloud Run за CDN. Поскольку они не защитят кэшированные ответы, обязательно установите соответствующие директивы управления для отображаемого контента.