Watch demos on how to build & run AI-powered apps with Firebase at Demo Day '24. Watch now.

Эта страница переведена с помощью Cloud Translation API.

Настройка серверной части хостинга приложений и управление ею

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

Настройка серверной части

Для расширенной настройки, такой как переменные среды или параметры времени выполнения, такие как ограничения одновременного выполнения, ЦП и памяти, вам необходимо создать и отредактировать файл apphosting.yaml в корневом каталоге вашего приложения. Этот файл также поддерживает ссылки на секреты, управляемые с помощью Cloud Secret Manager, что позволяет безопасно проверять систему контроля версий.

Чтобы создать apphosting.yaml , выполните следующую команду:

firebase init apphosting

При этом создается базовый стартовый файл apphosting.yaml с примером конфигурации (с комментариями). После редактирования типичный файл apphosting.yaml может выглядеть следующим образом: с настройками серверной службы Cloud Run , некоторыми переменными среды и некоторыми ссылками на секреты, которыми управляет Cloud Secret Manager:

# Settings for Cloud Run
runConfig:
  minInstances: 2
  maxInstances: 100
  concurrency: 100
  cpu: 2
  memoryMiB: 1024

# Environment variables and secrets
env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      - BUILD
      - RUNTIME

  - variable: API_KEY
    secret: myApiKeySecret

    # Same as API_KEY above but with a pinned version.
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

    # Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
  - variable: VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID

    # Same as API_KEY above but with the long form secret reference with pinned version.
  - variable: PINNED_VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID/versions/5

Остальная часть этого руководства содержит дополнительную информацию и контекст для этих примеров настроек.

Настройка параметров службы Cloud Run

С помощью настроек apphosting.yaml вы можете настроить предоставление службы Cloud Run . Доступные настройки сервиса Cloud Run представлены в объекте runConfig :

cpu — количество процессоров, используемых для каждого обслуживающего экземпляра (по умолчанию 0).
memoryMiB — объем памяти, выделенный для каждого обслуживающего экземпляра в MiB (по умолчанию 512).
maxInstances — максимальное количество контейнеров, которые могут быть запущены одновременно (по умолчанию 100 и управляется квотой).
minInstances — количество контейнеров, которые всегда будут оставаться активными (по умолчанию 0).
concurrency — максимальное количество запросов, которые может получить каждый обслуживающий экземпляр (по умолчанию 80).

Обратите внимание на важную связь между cpu и memoryMiB ; Для памяти можно задать любое целочисленное значение от 128 до 32768, но увеличение лимита памяти может потребовать увеличения лимитов ЦП:

Для более 4 ГБ требуется как минимум 2 процессора
Для более 8 ГБ требуется как минимум 4 процессора
Для более 16 ГБ требуется как минимум 6 процессоров
Для более 24 ГБ требуется как минимум 8 процессоров

Аналогичным образом значение cpu влияет на настройки параллелизма. Если вы установите значение меньше 1 ЦП, необходимо установить для параллелизма значение 1, и ЦП будет выделяться только во время обработки запроса.

Настройте среду сборки

Иногда вам потребуется дополнительная настройка процесса сборки, например ключи стороннего API или настраиваемые параметры. App Hosting предлагает настройку среды в apphosting.yaml для хранения и получения данных этого типа для вашего проекта.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app

Для приложений Next.js файлы dotenv, содержащие переменные среды , также будут работать с App Hosting . Мы рекомендуем использовать apphosting.yaml для детального управления переменными среды в любой платформе.

В apphosting.yaml вы можете указать, какие процессы имеют доступ к вашей переменной среды, используя свойство availability . Вы можете ограничить переменную среды, чтобы она была доступна только для среды сборки или доступна только для среды выполнения. По умолчанию он доступен обоим.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

Для приложений Next.js вы также можете использовать префикс NEXT_PUBLIC_ так же, как и в файле dotenv, чтобы сделать переменную доступной в браузере.

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

Допустимые переменные ключи состоят из символов AZ или символов подчеркивания. Некоторые ключи переменных среды зарезервированы для внутреннего использования. Не используйте ни один из этих ключей в файлах конфигурации:

Любая переменная, начинающаяся с X_FIREBASE_
PORT
K_SERVICE
K_REVISION
K_CONFIGURATION

Храните и получайте доступ к секретным параметрам

Конфиденциальная информация, такая как ключи API, должна храниться как секрет. Вы можете ссылаться на секреты в apphosting.yaml , чтобы избежать проверки конфиденциальной информации в системе контроля версий.

Параметры типа secret представляют собой строковые параметры, значение которых хранится в Cloud Secret Manager . Вместо прямого получения значения секретные параметры проверяют наличие в Cloud Secret Manager и загружают значения во время развертывания.

  -   variable: API_KEY
      secret: myApiKeySecret

Секреты в Cloud Secret Manager могут иметь несколько версий. По умолчанию значение секретного параметра, доступного вашему действующему бэкэнду, привязано к последней доступной версии секрета на момент создания бэкэнда. Если у вас есть требования к управлению версиями и жизненным циклом параметров, вы можете закрепить их за конкретными версиями с помощью Cloud Secret Manager. Например, чтобы закрепить версию 5:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Вы можете создавать секреты с помощью команды CLI firebase apphosting:secrets:set , и вам будет предложено добавить необходимые разрешения. Этот процесс дает вам возможность автоматически добавлять секретную ссылку на apphosting.yaml .

Чтобы использовать полный набор функций Cloud Secret Manager, вы можете использовать консоль Cloud Secret Manager. Если вы это сделаете, вам нужно будет предоставить разрешения серверной части App Hosting с помощью команды CLI firebase apphosting:secrets:grantaccess .

Синхронизировать состояние аутентификации Firebase

Приложениям, использующим Firebase Auth, следует рассмотреть возможность использования Firebase Web SDK, чтобы обеспечить синхронизацию состояния аутентификации между клиентом и сервером. Этому можно способствовать, реализовав FirebaseServerApp с помощью сервис-воркера. Основной поток задач таков:

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

Управление бэкэндами

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

Создать серверную часть

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

Консоль Firebase : в меню «Сборка» выберите «Хостинг приложений» , а затем «Начало» .

CLI: (версия 13.15.4 или новее). Чтобы создать серверную часть, запустите следующую команду из корня локального каталога проекта, указав свой идентификатор проекта и предпочтительный регион в качестве аргументов:

firebase apphosting:backends:create --project PROJECT_ID --location us-central1

Как для консоли, так и для интерфейса командной строки следуйте инструкциям, чтобы присвоить имя серверной части, настроить соединение GitHub и настроить следующие основные параметры развертывания:

Установите корневой каталог вашего приложения (по умолчанию / ).
Обычно здесь находится ваш файл package.json .

Установить живую ветку
Это ветка вашего репозитория GitHub, которая развертывается по вашему действующему URL-адресу. Часто это ветка, в которую объединяются ветки функций или ветки разработки.
Принять или отклонить автоматическое внедрение
Автоматическое развертывание включено по умолчанию. По завершении создания серверной части вы можете выбрать немедленное развертывание вашего приложения на App Hosting .

Удаление серверной части

Чтобы полностью удалить серверную часть, сначала используйте интерфейс командной строки Firebase , а затем вручную удалите связанные ресурсы, уделяя особое внимание тому, чтобы не удалить ресурсы, которые могут использоваться другими серверными модулями или другими аспектами вашего проекта Firebase.

Выполните следующую команду, чтобы удалить серверную часть App Hosting . Это отключает все домены вашего серверного модуля и удаляет связанную с ним службу Cloud Run :
```
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
```
(Необязательно) На вкладке Google Cloud Console для Artifact Registry удалите изображение для своего бэкэнда в «firebaseapphosting-images».
В Cloud Secret Manager удалите все секреты со словом «apphosting» в имени секрета, уделяя особое внимание тому, чтобы эти секреты не использовались другими серверными модулями или другими аспектами вашего проекта Firebase .