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

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

Вот как может выглядеть типичный файл 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 или настраиваемые параметры. Хостинг приложений предлагает настройку среды в apphosting.yaml для хранения и получения данных этого типа для вашего проекта.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com

Для приложений Next.js файлы dotenv, содержащие переменные среды, также будут работать с хостингом приложений. Мы рекомендуем использовать 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. Если вы это сделаете, вам нужно будет предоставить разрешения серверной части хостинга приложений с помощью команды CLI firebase apphosting:secrets:grantaccess .

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

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

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