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

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.appspot.com
    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.appspot.com

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

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

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

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

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.appspot.com
    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 с помощью сервис-воркера. Основной поток задач таков:

  1. Реализуйте сервис-воркера , который добавляет правильные заголовки для вашего приложения при запросах к серверу.
  2. Получите заголовки запроса на сервере и преобразуйте их в пользователя с аутентификацией с помощью 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.

  1. Выполните следующую команду, чтобы удалить серверную часть App Hosting . Это отключает все домены вашего серверного модуля и удаляет связанную с ним службу Cloud Run :

    firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
    
  2. (Необязательно) На вкладке Google Cloud Console для Artifact Registry удалите изображение для своего бэкэнда в «firebaseapphosting-images».

  3. В Cloud Secret Manager удалите все секреты со словом «apphosting» в имени секрета, уделяя особое внимание тому, чтобы эти секреты не использовались другими серверными модулями или другими аспектами вашего проекта Firebase .