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

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

Поддержка фреймворка

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

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

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

Адаптеры платформы хостинга приложений выполняют две ключевые роли:

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

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

Как работает интеграция репозитория хостинга приложений

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

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

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

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

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

Учетная запись серверной службы хостинга приложений

Во время сборки и во время выполнения серверная часть вашего хостинга приложений выполняет аутентификацию в других службах Google с помощью учетной записи службы. Учетная запись службы по умолчанию для этих целей создается при первом включении хостинга приложений в проекте Firebase:

firebase-app-hosting-compute@ PROJECT ID .iam.gserviceaccount.com

Эта учетная запись службы по умолчанию применяется ко всем серверным модулям и имеет минимальный набор разрешений, позволяющих создавать, запускать и отслеживать ваше приложение. Он также имеет разрешение на аутентификацию Admin SDK с учетными данными приложения по умолчанию для выполнения таких операций, как загрузка данных из Cloud Firestore. См. раздел Роли хостинга приложений Firebase .

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

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

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

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

Предварительная версия хостинга приложений имеет некоторые известные ограничения:

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